XMP metadata
XMP defines an extensible metadata model and RDF/XML serialization whose namespaced properties can be embedded in resources or carried in associated sidecars.
XMP, the Extensible Metadata Platform, defines a metadata model and its serialization. A packet can be embedded in a supported resource or carried in an associated sidecar.
The XML text is a representation of structured properties. Its readability does not by itself establish that every consumer recognizes their meaning.
Model, serialization and storage are separate
| Layer | Responsibility |
|---|---|
| Data model | Properties and their structured values |
| RDF/XML serialization | How that model is written as XML |
| Schema/namespace | Identity and meaning of named properties |
| File embedding or sidecar association | Where the serialized record is carried |

Adobe's specifications separate the core model, additional properties and storage in files. This explains why a .xmp sidecar and an embedded packet can use the same metadata model while having different association/preservation behavior.
Namespaces identify properties
A prefix such as dc is a convenient local abbreviation for a namespace. The property's identity depends on the namespace and local name, not on a universal requirement to spell that prefix identically in every document.
Here is an original small packet with an invented creator and description:
<x:xmpmeta xmlns:x="adobe:ns:meta/">
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about=""
xmlns:dc="http://purl.org/dc/elements/1.1/">
<dc:creator>
<rdf:Seq><rdf:li>Ana Lee</rdf:li></rdf:Seq>
</dc:creator>
<dc:subject>
<rdf:Bag><rdf:li>railway</rdf:li><rdf:li>dawn</rdf:li></rdf:Bag>
</dc:subject>
<dc:description>
<rdf:Alt>
<rdf:li xml:lang="x-default">Platform at dawn.</rdf:li>
<rdf:li xml:lang="en">Platform at dawn.</rdf:li>
<rdf:li xml:lang="fr">Quai à l'aube.</rdf:li>
</rdf:Alt>
</dc:description>
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>
The namespace URIs are identifiers in the syntax, not instructions to download a schema or image from those addresses.
Structured values retain distinctions
The default description appears first and is repeated with its actual English language qualifier; the French alternative remains a separate value.
The creator sequence represents ordered entries. The subject bag represents a collection whose ordering does not carry that same meaning. The description alternatives retain language qualifiers.
Flattening those values into one string can lose ordering, element boundaries or language context. A generic XML parser finding text does not perform the schema-aware mapping automatically.
Properties can additionally use defined structures and types. A supported edit instruction and a descriptive keyword are not interchangeable just because both are inside the same packet.
Reconcile overlapping records deliberately
The same image can carry Exif, IPTC-related properties and XMP. Applicable storage/reconciliation rules help keep overlapping claims coherent when they refer to the same fact.
That is different from blindly making all similarly named date fields equal. Capture time, export time and filesystem time can describe different events.
For an Emby resource, keep packet validity, supported property mapping and selected library values as separate observations. A well-formed external packet still needs a recognized association and reader; a mapped value can then interact with provider or edited values through precedence.