thammond – 2007 October 17
So, back on the old XMP tack. The simple vision from the XMP spec is that XMP packets are embedded in media files and transported along with them - and as such are relatively self-contained units, see Fig 1.
Fig. 1 - Media files with fully encapsulated descriptions.
But this is too simple. Some preliminary considerations lead us to to see why we might want to reference additional (i.e. external) sources of metadata from the original packet:
Thus the two cases - PDF documents and images - are not dissimilar. Fig. 2 shows a “wall-to-wall” XMP architecture whereby the standalone metadata documents for the work and for additional sources are expressed in XMP.
Fig. 2 - XMP “wall-to-wall” architecture.
Fig. 3 presents a variant on this theme whereby additional sources are presented as generic RDF/XML. (In the most general case only RDF need be assumed, the serialization being a matter of choice.)
Fig. 3 - XMP authority metadata with references to generic RDF/XML
And finally, Fig. 4 shows the most extreme case whereby XMP is used merely to “bootstrap” RDF descriptions for media objects. The XMP is used to embed a minimal description into the media file with references to a fuller work description and to additional sources which are presented as generic RDF/XML. That is, the metadata descriptions use generic RDF/XML exclusively and only resort to the idiomatic RDF/XML employed by XMP for embedding descriptions into binary structures.
Fig. 4 - XMP “bootstrap” only - metadata descriptions proper are generic RDF/XML.
If I were to choose I might opt for the scenario presented in Fig. 3, but the scenarios in both Figs. 2 and 4 leave room for thought. Such a hybrid solution may be a means to bridge two different concerns:
2020 February 21
2020 February 14
2020 February 05
2020 January 14