Warning:
This wiki has been archived and is now read-only.

XMP

From Media Annotations Working Group Wiki
Jump to: navigation, search

Background

Purpose

Analyzing the standard schemas defined by XMP. "Analyzing" means: for each property in the schema saying "yes, we need it", or "no, we don't". For the "yes" case the basic rational is that we want to be aligned with XMP. For the "no" case it would be good to add a rational why a property should be dropped.

Reference Material

XMP Specification Part 2, see the section "standard schemas".

XMP Standard Schemas

Dublin Core schema

Review during December 2008: all f2f participants agree with "yes" for DC properties.

Reviewer: Thierry

The Dublin Core Metadata Element Set is a vocabulary of fifteen properties for use in resource description. Its elements are broad and generic, usable for describing a wide range of resources. See http://dublincore.org/documents/dces/

XMP adopts just DC basic terms.

These properties may overlap with properties from other Schema (see below). I suggest we should try to reuse the Dublin Core Metadata when we meet such redundancies.

Mapping back into Dublin Core has the problem of information loss. E.g. if you have Dublin Core and MPEG-7, Dublin Core will have less detailed information.

dc:spatial and dc:temporal are not in the list below, we may need them.

dc:contributor -> bag ProperName
Contributors to the resource (other than the authors).
Comment: Useful.
inShort: yes, but may need refinements (e.g. roles like actor, director, ...).

dc:coverage -> Text
The extent or scope of the resource.
Comment: Useful.
inShort: yes

dc:creator -> seq ProperName
The authors of the resource (listed in order of precedence, if significant).
Comment: Very Useful.
inShort: yes

dc:date -> seq Date
External Date(s) that something interesting happened to the resource.
Comment: Very Useful.
inShort: yes

dc:description -> Lang Alt
A textual description of the content of the resource. Multiple values may be present for different languages.
Comment: Very Useful.
inShort: yes

dc:format -> MIMEType Internal
The file format used when saving the resource. Tools and applications should set this property to the save format of the data. It may include appropriate qualifiers.
Comment: Very Useful.
inShort: yes

dc:identifier ->Text
Unique identifier of the resource.
Comment: Very Useful..
inShort: yes

dc:language ->bag Locale
An unordered array specifying the languages used in the resource.
Comment: Useful.
inShort: yes

dc:publisher -> bag ProperName
External Publishers.
Comment: Useful.
inShort: yes

dc:relation -> bag Text
Relationships to other documents.
Comment: Useful.
inShort: yes

dc:rights -> Lang Alt
Informal rights statement, selected by language.
Comment: Useful.
inShort: yes

dc:source -> Text
Unique identifier of the work from which this resource was derived.
Comment: Useful.
inShort: yes

dc:subject -> bag Text
An unordered array of descriptive phrases or keywords that specify the topic of the content of the resource.
Comment: Useful.
inShort: yes

dc:title -> Lang Alt
The title of the document, or the name given to the resource. Typically, it will be a name by which the resource is formally known.
Comment: Very Useful..
inShort: yes

dc:type -> bag open Choice
A document type; for example, novel, poem, or working paper.
Comment: Useful.
inShort: yes

XMP Basic schema

Review during December 2008 f2f.

xmp:Advisory -> Xpath
Array for properties edited outside the authoring application
Comment: IMO we do not need a dependance on XPath here
inShort: no

xmp:baseURL -> URL
The base URL for relative URLs in the document content.
Comment: Useful. However we should use URIs instead of URLs.
inShort: yes

xmp:CreateDate -> Date
The date and time the resource was originally created
Comment: Necessary
inShort: yes

xmp:CreatorTool -> AgentName
The name of the first known tool used to create the resource.
Comment: Useful, not sure if necessary
inShort: yes

xmp:Identifier -> bag Text
An unordered array of text strings that unambiguously identify the resource within a given context.
Comment: The description says that this is used instead of dc:identifier. I would rather propose to not use xmp:Identifier and dc:identifier instead, since the latter seems more general applicable to me.
inShort: yes

xmp:Label-> Text
A word or short phrase that identifies a document as a member of a user-defined collection.
Comment: Useful.
inShort: yes

xmp:MetadataDate -> Date
The date and time that any metadata for this resource was last changed.

inShort: yes

xmp:Nickname -> Text
A short informal name for the resource
Comment: Propose to drop, seems not to have wide adoption
inShort: no

xmp:Rating -> Closed Choice of Integer
A number that indicates a document’s status relative to other documents, used to organize documents in a file browser.
inShort: yes, need to describe what kind of rating (e.g. parentral control, ...).

xmp:Thumbnails -> alt Thumbnail
An alternative array of thumbnail images for a file
Comment: Useful
inShort: yes

xmpidq:Scheme -> Text
The name of the formal identification system used in the value of the associated xmp:Identifier item
inShort: yes

XMP Rights Management schema

Reviewer: Felix

December 2008 f2f: Agreement to have a slot (= a text field and a field for an URI), to convey information like below. Applications which need more detailed rights, signature and certification information can define related properties and take in these the XMP properties into account again.

The following properties are defined: xmpRights:Certificate, xmpRights:Marked, xmpRights:Owner, xmpRights:UsageTerms, xmpRights:WebStatement

I think we do not need these properties, but just one slot for rights information with any content, and another slot to link to external information. Note that such a slot could also be filled with these properties, but I think it is enough for us to have a container for them or other rights related information.

XMP Media Management schema

Discussed during December 2008 f2f.

Reviewer: Veronique

The part of the XMP that I have reviewed contains several properties, the review is as follows:
name of the property -> type of expected value
intended meaning for the property
Comment: my comment about it, including sometimes questions to the group
inShort: my opinion about including it or not in our Ontology.

Looking forwards to the group's comments!


xmpMM:DerivedFrom -> ResourceRef
This property is meant to point to an original document, from which the current one is defined
Comment: this could be taken care of by a schema describing different level of a document, distinguishing between the idea and different realisations. If we choose to opt for a simple format that would not make these distinctions, then this property should not be adopted
-> property relevant if we distinguish between the idea and different realisations of the same document
-> I would say that we need a way to point to different versions of a doc, but I think that we still have to decide by which mechanism to do this. this Property is an option for that.
InShort: Yes, to be related to dc:soure. Separate question: role of this property for use cases (cultural heritage).

xmpMM:DocumentID -> URI
Comment: we definitely need a unique identifier for the document
InShort: yes

xmpMM:History -> an ordered array of high level user actions that resulted in this resource
InShort: yes, probably not for all use case.

xmpMM:Ingredients -> an unordered array of references that were incorporated (inclusion or ref) to the document
Comment: this property concerns the media fragment WG, I would say, and the link between us and them. We need a way to point to segments of a MM document, but I don't like this term of "Ingredients". What about a more generic property "PartOf" for our ontology, that would specialise in this one?
InShort: yes, but maybe keep a more generic name (partOf? it is a composition-type of part-of), to be discussed with Media Fragment WG

xmpMM:InstanceID -> URI
Property meant for an incarnation of a document: each time a document is saved.
Comment: we have the same discussion here as with xmpMM:DerivedFrom: do we adopt a description scheme that takes different levels into account? This level is the one of the individual instances. I would go for a three level model (idea/realisation/instance). What do other people think?
InShort: yes. This property is related to a 3 level description model, we need to decide whether we go for it or not?

xmpMM:ManagedFrom -> ResourceRef
Property meant to keep track of a previous system where the document was managed.
Comment: I do not think that the reference of the management system is in the scope of our core ontology, I would rather leave it to the system side (which XMP also suggests by typing this property as "Internal")
InShort: no

xmpMM:Manager -> AgentNAme
Property labeled as "Internal", to keep the reference of the asset management system used
Comment: I do not think that the reference of the management system is in the scope of our core ontology, I would rather leave it to the system side (which XMP also suggests by typing this property as "Internal")
InShort: no

xmpMM:ManageTo -> URI
Internal identifier in the asset management system
Comment: I do not think that this is in the scope of our ontology, it is at the application side
InShort: no

xmp:MM:ManageUI ->URI
Link to some information about the document accessible via Internet
Comment: I think that such a link is very useful, if we decide that metadata and the document itself should be in different documents. This property could also be replaced, as in the case of the machine readable vs human readable licenses, by two different URI, one that would be accessed for human display, one for machine usage as was suggested at the face to face.
InShort: maybe not necessary for information already published, but rather in a step before. Yes, if we go for metadata in a different file than the document itself. Maybe mapping to dc:description.

xmpMM:ManagerVariant -> Text
Property to specify a variant of the media asset management system
Comment: out of scope, I think, this is on the application side
InShot: no

xmpMM:OriginalDocumentID -> URI
Property meant for identifying all versions and renditions of a document
Comment: this way of naming the unique URI can be misleading: how about a simpler name? We still have to decide on the levels that such a URI will adress (different versions? Instances?)
InShort: yes. General property could be named "hasURI". Potentially mapping to XMP:Identifer.

xmp:MMPantry -> components, all described by a full XMP desciption
Comment: this seems to be the way to refer to different (descriptions of) instances related to the same document.
InShort: yes, if we go for a description model that takes into account different levels

xmp:MMRenditionClass -> a set of values as rendition classes (high res, thumbnail etc)
Comment: we had this discussion before, I think that we did not decide yet on whether to represent this as different URIs or a property... Am I mistaken?
InShort: yes if we represent the rendition as a property

xmp:MMRenditionParams -> text
Propety to add additional information about the rendition class
InShort: no, too detailed

xmpMM:VersionID -> text
Property for associating an identifier to each version of a document.
InShort: yes if we go for a 3 level description scheme

xmpMM:Versions -> seq Version
Property for recording the succession of versions of a document.
Comment: too detailed for a core ontology, can be attached to Version as a specilaisation, so it should be application dependant
InShort: no, but how does to it relate to xmp:history

XMP Basic Job Ticket schema

Reviewer: Wonsuk

xmpBJ:JobRef --> This property references an external job management file for a job process in which the document is being used. Typical use would be to identify all documents that are part of a particular job or contract.
My Opinion: We don't need this. This is out of scope. Because this is related to describe a link among the document and job process in terms of workflow.

XMP Paged-text schema

Reviewer: Wonsuk

This schema is used for text appearing on a page in a document.
My opinion: we don't need below all properties. Because these are properties for showing the document.

xmpTPg:MaxPageSize --> The size of the largest page in the document
xmpTPg:NPages --> The number of pages in the document
xmpTPg:Fonts --> An unordered array of fonts that are used in the document
xmpTPg:Colorants --> An ordered array of colorants (swatches) that are used in the document
xmpTPg:PlateNames --> An ordered array of plate names that are needed to print the document

XMP Dynamic Media schema

Reviewer: Joakim

Excluded Properties

xmpDM:absPeakAudioFilePath The absolute path to the file’s peak audio file.
Comment: Too detailed

xmpDM:altTapeName An alternative tape name
Comment: Too detailed

xmpDM:altTimecode A timecode set by the user. When specified, it is used instead of the startTimecode.
Comment: Too detailed

xmpDM:beatSpliceParams Additional parameters for BeatSplice stretch mode.
Comment: Too detailed

xmpDM:introTime The duration of lead time for queuing music.
Comment: Little adoption

xmpDM:logComment User’s log comments.
Comment: Not sure!?


xmpDM:outCue The time at which to fade out.
Comment: Not relevant to our task

xmpDM:relativeTimestamp The start time of the media inside the audio project.
Comment: Not relevant to our task

xmpDM:resampleParams Additional parameters for Resample stretch mode.
Comment: Too detailed

xmpDM:relativePeakAudioFilePath The relative path to the file’s peak audio file.
Comment: Not relevant to our task

xmpDM:speakerPlacement A description of the speaker angles from center front in degrees.
Comment: Not relevant to our task

xmpDM:stretchMode The audio stretch mode.
Comment: Too detailed

xmpDM:engineer The engineer’s name.


Included Properties

xmpDM:album The name of the album. In dc title.

xmpDM:artist The name of the artist or artists. In dc contributor?.

xmpDM:audioModDate The date and time when the audio was last modified.

xmpDM:audioSampleRate The audio sample rate. Can be any value, but commonly 32000,

xmpDM:audioSampleType The audio sample type.

xmpDM:audioChannelType The audio channel type.

xmpDM:audioCompressor The audio compression used. For example, MP3.

xmpDM:composer The composer’s name. In dc creator.

xmpDM:copyright

xmpDM:duration The duration of the media file. Related to dc extend (not part of basic dc set).

xmpDM:fileDataRate The file data rate in megabytes per second.

xmpDM:genre The name of the genre.

xmpDM:instrument The musical instrument. Belong to dc:description.

xmpDM:key The audio’s musical key. Belong to dc:description.

xmpDM:loop When true, the clip can be looped seamlessly.

xmpDM:numberOfBeats The number of beats. Belong to dc:description.

xmpDM:metadataModDate The date and time when the metadata was last modified. Related to xmp:history and possibly xmp:modifyDate

xmpDM:projectRef A reference to the project that created this file.

xmpDM:releaseDate The date the title was released.

xmpDM:scaleType The musical scale used in the music.

xmpDM:scene The name of the scene.

xmpDM:shotDate The date and time when the video was shot.

xmpDM:shotLocation The name of the location where the video was shot.

xmpDM:shotName The name of the shot or take.

xmpDM:contributedMedia An unordered list of all media used to create this media

xmpDM:startTimecode The timecode of the first frame of video in the file, as obtained from the device control.

xmpDM:tapeName The name of the tape from which the clip was captured, as set during the capture process.

xmpDM:tempo The audio’s tempo.

xmpDM:timeScaleParams The time signature of the music.

xmpDM:trackNumber A numeric value indicating the order of the audio file within its original recording.

xmpDM:Tracks An unordered list of tracks. A track is a named set of markers, which can specify a frame rate for all markers in the set. Interesting for media fragments WG, see http://www.w3.org/2008/12/09-mediafrag-irc#T14-58-31-1

xmpDM:markers An ordered list of markers.

xmpDM:Tracks.

xmpDM:videoAlphaMode straight / pre-multiplied

xmpDM: videoAlphaPremultipleColor A color in CMYK or RGB to be used as the pre-multiple color when alpha mode is pre-multiplied.

xmpDM: videoAlphaUnityIsTransparent When true, unity is clear, when false, it is opaque.

xmpDM:videoColorSpace The color space.

xmpDM:videoCompressor Video compression used. For example, jpeg.

xmpDM:videoFieldOrder The field order for video.

xmpDM:videoFrameRate The video frame rate.

xmpDM:videoFrameSize The frame size. For example: w:720, h: 480, unit:pixels

xmpDM:videoModDate The date and time when the video was last modified.

xmpDM:videoPixelDepth The size in bits of each color component of a pixel.

xmpDM:videoPixelAspectRatio The aspect ratio, expressed as wd/ht. For example: “648/720” = 0.9