Tiêu chuẩn iso 16684 1 2012

Graphic technology — Extensible metadata platform (XMP) specification — Part 1 Data model, serialization and core properties Reference number ISO 16684 1 2012(E) © ISO 2012 INTERNATIONAL STANDARD ISO[.]

General

Conforming XMP packets must meet all the specifications outlined in this International Standard, and they are only required to utilize features that are explicitly mandated by this standard.

NOTE The proper mechanism by which XML can presumptively identify itself as being an XMP packet is described in 7.3,

“Optional outer XML”, and 7.4, “rdf:RDF and rdf:Description elements”.

Table 1 — Conventions for type styles

Bold XMP property names For example, xmp:CreateDate

Copyright International Organization for Standardization

Provided by IHS under license with ISO

Conforming readers

A conforming reader must adhere to all functional behavior requirements outlined in this International Standard, which specifies general functional requirements applicable to all conforming readers It is essential for a conforming reader to accept all output from conforming writers, including any optional output they may generate Notably, this International Standard does not dictate specific technical designs, user interfaces, or implementation details for conforming readers.

Conforming writers

A conforming writer must adhere to the functional behavior requirements outlined in this International Standard, which emphasizes the creation of compliant XMP packets The standard specifies general functional requirements for all conforming writers without dictating specific technical designs, user interfaces, or implementation details.

Conforming products

A conforming product shall comply with all requirements regarding reader and writer functional behaviour as specified in this International Standard

XMP packets

An XMP packet represents an instance of the XMP data model, consisting of a collection of XMP metadata properties Each property within the packet is defined by a unique name and its corresponding value, ensuring that no two property names are the same within a single XMP packet.

The restriction on unique names in an XMP packet prohibits multiple occurrences of the same property name Instead of using three separate dc:subject properties for individual keywords, a single dc:subject property should be utilized as an array containing all three items.

Each XMP packet must represent a single resource, although multiple packets can describe the same resource This International Standard does not address conflict resolution for separate packets that pertain to the same resource.

Lower-level components of an XMP packet (structure fields or array items) may describe one or more other resources.

The provision for lower-level components regarding other resources is not an official addition to the data model and is not explicitly represented in written XMP Instead, it serves to clarify the "one packet about one resource" rule, ensuring that certain data models are not excluded The XMP for a compound resource may include a list of its constituent resources and copies of XMP related to those constituents, all modeled using the established XMP value forms.

This International Standard does not cover the composition of a resource or the exact association of an XMP packet with it However, whenever possible, an XMP packet should be physically linked to the resource it describes.

A common resource refers to a complete digital file or a specific part of a digital file, such as an embedded image within a PDF The details regarding the structure of a PDF file and the association of XMP with its components are not covered in this section of ISO 16684.

To ensure a proper association between the XMP packet and a digital file, it is essential to embed the XMP packet within the file using the standard features of the file format However, the specific embedding mechanisms for various file formats are not covered by this International Standard.

An XMP packet can include a URI known as the AboutURI, which identifies the resource described by the packet However, the specifics of the URI scheme, its syntax, and its connection to any target entity are not covered in this International Standard.

An XMP packet may lack an AboutURI and not have a direct physical link to the resource; instead, it can be associated through external means.

The statement "The author of Moby Dick is Herman Melville" illustrates how metadata is structured, where the resource is the book "Moby Dick," the property name is "author," and the property value is "Herman Melville." This representation highlights the relationship between the book and its author, as depicted in the accompanying diagram.

Figure 1 — Simple properties example diagram

NOTE 5 Notation such as that in Figure 1 is used in this International Standard to illustrate the XMP data model.

An XMP processor should accept all well-formed XMP as input, regardless of the data model expressed, and should by default preserve all unanticipated XMP when modifying a resource.

The rules governing XMP emphasize its flexibility for extending properties, allowing users to create custom metadata freely XMP-aware applications are expected to support the creation, modification, and viewing of this metadata Consequently, this is presented as a recommendation rather than a strict requirement, as local policies regarding XMP usage may vary in different environments.

XMP names

XMP properties, fields of structure values, and qualifiers are identified by names that follow XML expanded naming conventions, which include a non-empty namespace URI and a local name Two XMP names are considered equivalent when both their namespace URIs and local names match exactly, requiring a strict byte-for-byte comparison using the same Unicode encoding, without applying any additional processing such as Unicode character normalizations.

XML namespace URIs should be treated as string literals rather than guaranteed links to web resources While many of these URIs start with "http://", it is important to note that they may not correspond to an actual HTTP page.

In XML and XMP, the namespace prefix acts as a key for retrieving the corresponding URI This International Standard typically presents XMP names in a prefix:local format, such as dc:title The URI associated with the prefix in this document may be explicitly stated, inferred from the local context, or deemed irrelevant, particularly in generic value-form diagrams where the specific URI is not significant.

The dc:title element offers a more concise and readable alternative to lengthy namespace URIs, such as ("http://purl.org/dc/elements/1.1/", creator), particularly when the namespace URI is recognized and significant This advantage is particularly evident in scenarios where the exact URI is not crucial, as illustrated in hypothetical examples.

A namespace URI in XMP should conclude with a character that is not permitted in an XML NCName, such as a slash ("/") or a number sign ("#") This practice enhances compatibility with applications that combine the namespace URI and local name, thereby reducing the risk of collisions.

NOTE 3 The textual concatenation of a namespace URI and local name is seen in generic RDF processors that utilize the RDF triple notation See B.3, “Namespace URI termination”, for details

All namespaces mentioned in section 6, "Data model," and Figure 5, "Qualifiers example," except for xml: and rdf:, are purely illustrative Notably, the URI "http://ns.adobe.com/xmp-example/" is fictional, and the specific XMP names used in the illustrations do not indicate their definition in this International Standard In contrast, the namespaces outlined in section 8, "Core properties," are considered normative.

To adhere to standard XML and web practices, XMP names should be created using a namespace URI that includes a domain name owned by the creator This approach reduces the likelihood of namespace collisions and clearly indicates the source of the namespace.

In this International Standard, the `xml:` prefix is associated with the URI "http://www.w3.org/XML/1998/", as outlined in the Extensible Markup Language specification Similarly, the `rdf:` prefix is linked to the URI "http://www.w3.org/1999/02/22-rdf-syntax-ns#", defined in the RDF/XML Syntax Specification Both specifications impose strict limitations on the usage of these namespaces.

XMP value forms

The XMP data model comprises values in three forms: simple, structure, and array Simple values can be categorized into normal and URI variants, while arrays can be classified as unordered, ordered, or alternative Both structures and arrays can contain any value form, allowing for a flexible and complex approach to XMP data modeling.

The primitive values of XMP serve as the foundational data types, while higher-level data types can be created by integrating these primitives with added constraints, as outlined in section 8, “Core properties.”

A simple value is a string of Unicode text as defined in The Unicode Standard The string may be empty.

There are two types of simple values: normal and URI The URI variant is specifically designed for values that represent URIs, while the normal variant is intended for all other simple values.

The difference between normal and URI simple values is not essential for structuring the abstract XMP data model; however, it influences RDF serialization, as discussed in section 7.5, “Simple valued XMP properties.” This distinction enables XMP data modeling to better align with general RDF data modeling.

EXAMPLE In Figure 2, the document XMP_Specification.pdf is shown with two properties, each with a simple value: The value of the property dc:format is "application/pdf"

Figure 2 — Simple values example 6.3.3 Structure values

A structure is a container for zero or more named fields The order of fields in a structure shall not be significant Fields may be optional or required.

In a structure, every field must have a distinct name, which should be represented as XML expanded names It is not necessary for the fields to share the same namespace as their parent structure or with other fields within the same structure.

Each field in a structure may have any value form The usage and consistency of fields in a given structure type is beyond the scope of this International Standard.

EXAMPLE Figure 3 shows a single structured property with three fields: stDim:w (width), stDim:h (height) and stDim:unit (units), whose values are "8.5", "11.0", and "inch".

Figure 3 — Example of structure values 6.3.4 Array values

An array is a data structure that holds zero or more elements, each identified by a unique ordinal index starting from 1 The elements within an array can be of any XMP value type, but it is essential that all items share the same data type.

There are three variants of array: ordered, unordered, and alternative The variant indicates the anticipated use of the array and constrains what XMP processors may do with it:

 An unordered array shall have no meaning or constraints on the order of items within it The items in an unordered array may be reordered at any time

In an ordered array, items are arranged according to their indices and cannot be reordered arbitrarily The significance of this order is determined by the data type or the specific application This International Standard does not impose any assumptions or specifications beyond the data types outlined in section 8, "Core properties."

"8.5" xmpTPg:MaxPageSize stDim:w stDim:h stDim:unit

8 default meaning to the order of items in an ordered array

An alternative array maintains a specific order that should not be changed arbitrarily, with the order determined by either the data type or the application This International Standard does not establish any default ordering, except for the data types outlined in section 8, "Core properties." If a preferred default item exists, it should be placed first in the array, which is the case when no other criteria are applicable Additionally, an alternative array does not require a designated default item.

NOTE 1 The intent is that a reader who has no idea how to choose an item from the alternative array is encouraged to pick the first item.

The expected use of unordered or ordered arrays involves considering all items collectively, such as a list of keywords or authors In contrast, an alternative array is designed to select a single item based on specific criteria, like choosing a resource description in a user's preferred language Both ordered and alternative arrays contain ordered items, with the choice of array variant depending on the intended usage.

EXAMPLE Figure 4 shows an example of the Dublin Core property dc:subject (see 8.3, “Dublin Core namespace”), which is an unordered array In this example, it contains three items.

Qualifiers

XMP qualifiers may be used to attach annotations to any XMP value, without changing the form of that value.

A simple value retains its identity even when arbitrary qualifiers are added by an XMP processor Qualifiers serve as metadata for the associated value, each having a unique name and value The names of these qualifiers must be XML expanded names and must be distinct within the same value Additionally, a qualifier's value can take any XMP value form and may also include its own qualifiers.

The xml:lang qualifier must have a straightforward non-URI value without any additional qualifiers It serves as the default language for the fields of a structure or items in an array Following IETF RFC 3066, the xml:lang value should be a language code, and all comparisons of xml:lang values are case-insensitive.

EXAMPLE Figure 5 shows an example of qualifiers.

General

The abstract XMP data model requires a tangible representation for digital files or printed documents This International Standard establishes a canonical serialization of XMP metadata utilizing a subset of RDF metadata syntax, which must employ Unicode text as outlined in The Unicode Standard The specific choice of Unicode encoding, whether UTF-8, UTF-16, or UTF-32, is not addressed in this International Standard, as other standards may dictate the appropriate Unicode encoding for file embedding or usage.

For this serialization, a single XMP packet shall be serialized using a single rdf:RDF XML element

Serialized XMP shall be well-formed XML and well-formed RDF An XMP reader shall conform to the rules of XML and RDF given in their respective specifications.

An XMP reader must acknowledge the leading Unicode U+FEFF character as a byte-order marker When using UTF-16 or UTF-32, an XMP writer should incorporate this leading character While an XMP writer using UTF-8 may include the U+FEFF character, it is generally not advisable.

Avoid using the U+FEFF character with UTF-8, as some devices may only read UTF-8 and may not recognize a leading U+FEFF The sole purpose of including a leading U+FEFF in UTF-8 is to serve as an encoding marker for distinguishing between UTF-8 and UTF-16/32.

The XMP serialization is designed as a fragment of an XML document, consisting of a single outer XML element and its content, without including the XML document prolog This approach facilitates the integration of multiple XMP packets within larger XML documents.

Equivalent RDF and XML

The normative statements in sections 7.4 to 7.8 establish a standard usage of RDF syntax, while section 7.9 outlines the allowed and prohibited equivalent forms of RDF It is important to note that XMP serialization utilizes only a limited subset of the RDF syntax, and any parts of the RDF syntax not included in this International Standard must not be used in serialized XMP.

XML white space, comments, and processing instructions can be placed anywhere permitted by the RDF/XML Syntax Specification, unless stated otherwise However, non-white character data is strictly limited by RDF and XMP, and should only be utilized within the content of leaf elements that denote simple XMP values.

Pirates of Penzance ordered dc:creator xe:role

Comments and processing instructions may be ignored when reading and need not be preserved when updating an XMP packet.

The International Standard specifies that phrases like “… element content shall consist of only …” do not explicitly prohibit the inclusion of white space, comments, or processing instructions Instead, these phrases limit the use of XML elements, attributes, and non-white character data.

The RDF serialization of XMP is designed to represent an instance of the XMP data model XML comments and processing instructions do not influence the XMP data model, regardless of their placement Additionally, white space outside the rdf:RDF element is irrelevant to the XMP data model However, allowed white space within the rdf:RDF element does not affect the model, except when it is included as part of the content for a simple value, where it becomes integral to the value itself.

All equivalent forms of XML text may be written This includes but is not limited to:

 Use of either an empty-element tag (of the form ) or an element with empty element content (of the form )

 Use of either QUOTEs or APOSTROPHEs for attribute values

 Order of attributes within an element.

 The specific prefix associated with an XML namespace URI.

When embedding XMP within digital files, including white-space padding can be beneficial as it allows for in-place modification of the XMP packet without affecting the rest of the file This approach can prevent the need to rewrite the entire file if the size of the XMP changes Suitable padding consists of SPACE characters placed in permissible white space areas according to XML syntax and XMP serialization rules, with a linefeed (U+000A) added approximately every 100 characters for better readability The optimal amount of padding varies by workflow, but around 2000 bytes is typically considered reasonable.

Optional outer XML

The rdf:RDF element may be surrounded by additional XML elements The XML processing instructions and elements outlined in this section can help identify the XMP packet in various scenarios.

A wrapper can be created using a pair of XML processing instructions (PIs) surrounding the rdf:RDF element This wrapped packet layout must include, in sequence, a header PI, the serialized XMP data model (the XMP packet) with optional white-space padding, and a trailer PI.

Certain file formats or use cases may prohibit the use of a packet wrapper, particularly in scenarios where minimizing size is critical or when the stored XMP is not contiguous This lack of contiguity in XMP can arise in file formats that simulate paged virtual memory.

The packet wrapper serves solely to assist in primitive byte-oriented XMP packet scanning and in-place editing within data streams of unknown formats Its only function is to provide markers that help the packet scanner identify the boundaries of the XMP packet Once the XMP is located, either through scanning or format knowledge, the packet wrapper holds no significance It is advisable to utilize format knowledge to locate the XMP whenever feasible, as byte-oriented packet scanning is considered fragile and should only be used as a last resort.

EXAMPLE This outline of a wrapped XMP packet shows the text of the header and trailer:

The header PI must follow the specific XML processing instruction format illustrated in Figure 6, which includes a GUID to minimize accidental occurrences in the data stream Additionally, the character  denotes the Unicode character U+FEFF, utilized as a byte-order marker, although it can be excluded from the begin="" attribute.

Values for "begin" and "id" should be enclosed in quotes, with apostrophes as an alternative Ensure there is a single space before both "begin" and "id" Any additional text preceding the closing "?>" will be disregarded.

The trailer PI must be an XML processing instruction in one of the specified forms The value assigned to "end" should be enclosed in QUOTEs, although APOSTROPHEs are also acceptable Additionally, there should be no white space within the trailer PI, except for a single SPACE preceding the "end".

Figure 7 — Allowed forms of the trailer PI

The end="w" and end="r" attributes are utilized by packet scanning processors to assess if the XMP can be modified in-place, with end="w" signifying writable and end="r" indicating read-only However, all "smart" processors, which do not rely on packet scanning, should disregard these writable or read-only indications.

A smart processor can utilize various methods, such as file system permissions or updating checksums, to determine if it is permissible to modify the XMP and the associated file In contrast, a packet scanner only has access to the information contained within the packet itself, lacking any additional context.

An optional x:xmpmeta element may be placed around the rdf:RDF element The element’s namespace URI shall be "adobe:ns:meta/".

The x:xmpmeta element is designed to identify XMP metadata within XML text that may also include non-XMP RDF uses Although this element can be utilized in any XMP context, it holds no significance outside of it An XMP processor should be capable of handling the x:xmpmeta element in any input and should search within it for the rdf:RDF element.

When both a packet wrapper and an x:xmpmeta element exist, the x:xmpmeta element can be positioned either inside or outside the packet wrapper Although there are no standard attributes for the x:xmpmeta element, XMP processors have the capability to create custom attributes, which will be disregarded during the reading process if they are unknown.

EXAMPLE An example of x:xmpmeta:

rdf:RDF and rdf:Description elements

An XMP packet must be serialized within a single rdf:RDF XML element, which can contain multiple rdf:Description elements.

Top-level rdf:Description elements can contain multiple XML elements representing XMP properties, which can be distributed freely among these elements.

The recommended approach is to have either a single rdf:Description element containing all XMP properties or a separate rdf:Description element for each XMP property namespace.

If the XMP data model includes an AboutURI, this URI must be assigned as the value of the rdf:about attribute in each top-level rdf:Description element If there is no AboutURI, the rdf:about attributes for all top-level rdf:Description elements should be included but left empty It is important to note that the rdf:about attribute is not applicable to more deeply nested rdf:Description elements.

To ensure compatibility with early XMP implementations, XMP readers should accept the absence of the rdf:about attribute, interpreting it as an empty value Additionally, XMP readers are advised to handle a combination of empty and nonempty rdf:about values, provided that all nonempty values are consistent.

EXAMPLE An rdf:RDF element containing one rdf:Description element:

The RDF serialization of an XMP property is represented as an XML element named after the XMP property itself The content of this element is defined by the type of XMP value being serialized, which can be simple, structured, or an array, and it also takes into account whether the XMP value includes qualifiers.

Simple valued XMP properties

An unqualified XMP property with a normal simple value must consist of text that conveys the value, adhering to the guidelines outlined in section 6.3.2 on simple values This text is limited to character data, entity references, character references, and CDATA sections, and must not include any nested XML elements.

EXAMPLE 1 See xmp:Rating in the example in 7.4, “rdf:RDF and rdf:Description elements”.

For an XMP property with a URI simple value, the element content must be empty, and the value should be specified using the rdf:resource attribute associated with the XML element.

General RDF permits the use of the rdf:parseType="Literal" attribute in specific XML elements, indicating that the complete XML content of that element should be interpreted as a single literal string However, it is important to note that the rdf:parseType="Literal" attribute is not applicable in XMP.

When an XMP simple value contains XML markup characters, the value shall be written using XML entities or CDATA sections.

NOTE The use of CDATA sections is discouraged They are not necessary and there is no way to escape the presence of

"]]>" in a value XML entities are sufficient for all cases.

Embedded <bold>XML</bold> markup

XML markup]]>

Structure valued XMP properties

An unqualified XMP property with a structure value must contain a nested rdf:Description element This nested element should include zero or more XML elements, each named after the fields of the XMP structure.

The content for each field in the structure must adhere to the property rules, which differ based on the type of XMP value being serialized—whether it is simple, structured, or an array—and whether the XMP value includes qualifiers For instance, a serialized XMP property can contain a structured value.

inch

NOTE Many XMP processors use a more concise notation for structure values as described in 7.9.2.3,

Array valued XMP properties

An unqualified XMP property with an array value must contain exactly one nested element, which can be one of the specified types.

 An rdf:Bag element for an unordered array.

 An rdf:Seq element for an ordered array.

 An rdf:Alt element for an alternative array

The nested element’s element content shall consist of zero or more rdf:li elements, one for each item in the array.

The content of the rdf:li element for each array item must adhere to property rules, which differ based on the serialization form of the XMP value—whether it is simple, structured, or an array—and the presence of qualifiers in the XMP value.

XMP

metadata

ISO standard

Qualifiers

Except for the xml:lang qualifier, the presence of qualifiers significantly modifies the RDF serialization of an XMP value

The xml:lang attribute is not included in the formal grammar of RDF According to the RDF/XML Syntax Specification, it can be applied to any node or property element to specify the language of the content.

The xml:lang qualifier must be represented as an xml:lang attribute linked to the relevant XML element for properties, structure fields, array items (rdf:li), or qualifiers that possess the qualified value This attribute can be applied to any of these elements, irrespective of the value's form However, it is important to note that the xml:lang attribute is not permitted on rdf:Description, rdf:Bag, rdf:Seq, rdf:Alt, or rdf:value elements.

Clause 6.4, titled "Qualifiers," specifies that the xml:lang qualifier must have a straightforward non-URI value and should not include any qualifiers This limitation is in place due to the serialization of the xml:lang qualifier as an XML attribute, adhering to standard RDF practices.

EXAMPLE 1 Serialized XMP with xml:lang qualifiers:

Adobe XMP Specification, April 2010

XMP

metadata

ISO standard

Norme internationale de l’ISO

When a value includes qualifiers beyond xml:lang, it must be serialized as a nested rdf:Description element This element should contain one rdf:value element and one or more XML elements named after the qualifiers However, this structure is not applicable if there are no qualifiers other than xml:lang.

The rdf:value element must contain the original, qualified XMP value being serialized The content of the rdf:value element, along with the qualifier elements, must adhere to property rules that vary based on the type of XMP values being serialized—whether they are simple, structured, or in an array format—and whether the qualifier values are additionally qualified.

The rdf:value element shall not contain an xml:lang attribute and shall not contain nested general qualifiers.

The rdf:value element resembles a structure field but is distinct from it, as it cannot include qualifiers in the start tag (such as xml:lang) or in its content (like nested general qualifiers) This limitation is exemplified in Example 3, which demonstrates the prohibited nesting of general qualifiers.

EXAMPLE 2 Serialized XMP with general qualifiers:

The RDF Concepts Vocabulary defines essential terms and data types used in RDF, including HTML, language-tagged strings, and plain literals It outlines the structure of RDF statements, which consist of subjects, predicates, and objects, and categorizes properties and classes such as Bag, Seq, and Alt for organizing data Additionally, it introduces the concept of RDF Lists and their components, including the first item and the rest of the list The vocabulary also encompasses various literal types, including XMLLiteral and JSON, which are crucial for representing structured data in RDF.

artificial example

XMP

metadata

artificial example

ISO standard

EXAMPLE 3 Prohibited nesting of general qualifiers:

one

two

one

two

Equivalent forms of RDF

The RDF outlined in sections 7.4 to 7.8 establishes a standard format for XMP serialization The RDF/XML Syntax Specification offers various equivalent forms, each utilizing different XML structures that represent the same RDF data model and, consequently, the same XMP data model While certain RDF forms are permitted in XMP, others are not allowed.

7.9.2.2 rdf:Description with property attributes

In the property and structure field, elements with standard simple values can be substituted with attributes within the rdf:Description element This substitution also extends to general qualifiers, including the rdf:value element, allowing for a combination of element and attribute forms.

EXAMPLE Simple valued elements shortened to attributes:

The RDF Concepts Vocabulary (RDF) defines essential terms and data types used in RDF 1.1, including HTML, language-tagged strings, and plain literals It categorizes RDF properties and classes, such as statements, subjects, predicates, and objects, which are fundamental to RDF structure Additionally, it introduces various container classes like Bag, Seq, and Alt, which organize data in different ways The vocabulary also encompasses data types for XML and JSON literals, as well as compound literals that include language and direction components.

inch

The rdf:Description element in a structure can be substituted with an rdf:parseType="Resource" attribute This substitution is also relevant for the pseudo-structure used for general qualifiers.

EXAMPLE Structure replacing rdf:Description with rdf:resource attribute:

The RDF (Resource Description Framework) is a framework for representing information about resources in the web It includes various data types such as HTML, language-tagged strings, and plain literals RDF properties define relationships between resources, with key properties including subject, predicate, and object RDF also categorizes data into classes like Bag, Seq, and Alt, which represent different types of containers Additionally, RDF supports structured values through properties like value, first, and rest, and includes data types for XML and JSON literals Overall, RDF provides a comprehensive vocabulary for describing and interlinking data on the web.

inch

artificial example

7.9.2.4 Structure element with field attributes

When all fields of a structure contain normal simple values, they can be represented as attributes of the structure element rather than using nested rdf:Description elements In this case, the structure element will have empty content It is essential that all fields are consistently formatted, either as nested elements or attributes This shorthand notation can also be applied to pseudo-structures for general qualifiers, but should not be combined with the rdf:parseType="Resource" attribute.

EXAMPLE Structure with all simple fields as attributes:

RDF introduces Typed Nodes, enabling any named element to replace an expected rdf:Description element This functions similarly to an rdf:Description containing a nested rdf:type element, while preserving all other attributes and nested content The rdf:type element added has no content but includes an rdf:resource attribute, which combines the original element's namespace URI and local name.

EXAMPLE 1 The following two snippets are equivalent in general RDF:

The conversion of XML qualified names to rdf:type values highlights the importance of terminating namespace URIs with a character that is not part of an XML NCName, as recommended in section 6.2 on XMP names However, converting in the opposite direction poses challenges, as the rdf:type value is a literal and may not have a defined associated namespace URI, leading to potentially unfounded assumptions about the separation between the namespace URI and the local name.

The use of Typed Nodes in XMP is limited and has distinct semantics compared to RDF textual equivalence The elements rdf:Bag, rdf:Seq, and rdf:Alt, which are utilized for XMP arrays, are essentially applications of RDF Typed Nodes, as outlined in section 7.9.3.2, “Arrays not using Typed Node form.”

The rdf:Description element in XMP serves three primary functions: it acts as a container for properties, structure fields, and general qualifiers, necessitating the definition of Typed Nodes in these contexts.

Top-level typed nodes, immediately within the rdf:RDF element, shall not be used in XMP An rdf:type property may be explicitly used in XMP.

EXAMPLE 2 Top-level Typed Node and rdf:type property:

Using an inner Typed Node in XMP adds an rdf:type qualifier to the containing element, where the rdf:type value is a URI formed by combining the Typed Node's namespace URI with its local name The interpretation remains consistent as if an rdf:Description element had been utilized in place of the original Typed Node.

The inclusion of the rdf:type qualifier will greatly change how the equivalent XMP representation of the Typed Node is serialized, as XMP processing involves more complexity than a straightforward textual substitution like RDF.

EXAMPLE 3 Inner Typed Node interpretation in XMP:

value

An explicit structure field named rdf:type may be used in XMP.

value

The following equivalent forms of RDF shall not be used when serializing XMP.

7.9.3.2 Arrays not using Typed Node form

The canonical RDF for an XMP array employs RDF Typed Node notation, as highlighted in section 7.9.2.5, “RDF Typed Nodes.” Specifically, the rdf:Bag, rdf:Seq, and rdf:Alt elements exemplify this syntax and must be utilized for XMP arrays It is important to note that the alternative RDF representation using rdf:Description and rdf:type elements is not permitted in XMP.

RDF enables the replacement of rdf:li elements with uniquely named elements like rdf:_1, rdf:_2, etc This allows for element-to-attribute substitution, similar to the method described in section 7.9.2.2 regarding "rdf:Description with property attributes." However, in XMP, the rdf:li element must be used, and the rdf:_n format is not permitted.

Overview

XMP processors should generally allow unrestricted use of XMP properties across various namespaces, unless local conditions require otherwise The properties outlined in this document are not intended to be the sole options available.

This clause outlines a set of XMP properties that are widely applicable across various usage domains and digital file formats, detailing the data types used to represent these properties' values The XMP names mentioned are derived from other standards and specifications, as indicated by the namespace URIs associated with their original owners This International Standard does not assert ownership over these namespaces, allowing their respective owners to define additional XMP names, including properties, structure fields, or qualifiers.

Core value types

Boolean values shall be "True" or "False"

A date-time value, is represented using a subset of the formats as defined in Date and Time Formats:

YYYY-MM-DDThh:mm:ssTZD

YYYY-MM-DDThh:mm:ss.sTZD

 MM = two-digit month (01=January)

 DD = two-digit day of month (01 to 31)

 hh = two digits of hour (00 to 23)

 mm = two digits of minute (00 to 59)

 ss = two digits of second (00 to 59)

 s = one or more digits representing a decimal fraction of a second

 TZD = time zone designator (Z or +hh:mm or –hh:mm)

The time zone designator is optional in XMP; if it is absent, the time zone remains unknown Consequently, an XMP processor should not make any assumptions regarding the missing time zone.

Local time-zone designators +hh:mm or –hh:mm should be used when possible instead of converting to UTC

NOTE If a file was saved at noon on October 23, a timestamp of 2004-10-23T12:00:00-06:00 conveys more information than 2004-10-23T18:00:00Z.

A signed or unsigned numeric string used as an integer number representation The string consists of an arbitrary-length decimal numeric string with an optional leading “+” or “–” sign.

A floating-point numeric value is represented as a simple text value in decimal notation, which may include an optional sign, an integer part, and a fraction part The sign can be either "+" or "–", while the integer part consists of one or more decimal digits It is important to note that either the integer part or the fraction part can be omitted, but not both If the fraction part is included, it starts with a decimal point followed by one or more decimal digits.

This International Standard does not define the exact range and precision for the general type An XMP processor must support a minimum of 32-bit IEEE 754 range and precision, and it is recommended to also support at least 64-bit IEEE 754 range and precision for specific applications of the Real type.

22 specify a required range or precision, such as nonnegative or microsecond resolution (for a duration in seconds).

The name of an XMP processor, a Text value.

It is recommended that the value use this format convention:

Organization Software_name Version (token;token; )

 Organization: The name of the company or organization providing the software, no SPACEs.

 Software_name: The full name of the software, SPACEs allowed.

 version: The version of the software, no SPACEs.

 tokens: Can be used to identify an operating system, plug-in, or more detailed version information.

EXAMPLE "Adobe Acrobat 9.0 (Mac OS X 10.5)"

A value chosen from a vocabulary of values Vocabularies provide a means of specifying a limited and possibly extensible set of values for a property

A choice can be open or closed:

 An open choice has one or more lists of preferred values, but other values can be used freely.

 A closed choice has one or more lists of allowed values, other values shall not be used.

An XMP reader would be more effective if it could handle unexpected values for closed choice types, especially as the set of allowed values is likely to expand over time.

A GUID, or globally unique identifier, is a simple value that resembles a URI string but is not formatted as one This document does not specify a method for creating or formatting GUIDs as XMP values The primary operations permitted on GUIDs include creating them, assigning one to another, and comparing two GUIDs for equality This comparison is performed using a direct byte-for-byte check of the Unicode string value.

An alternative array of simple text items allows for the selection of text based on language preferences, with each item featuring a unique xml:lang qualifier According to IETF RFC 3066, the xml:lang value consists of a primary language subtag and may include additional subtags The primary subtag can be used independently or with lower-level subtags If a default value is available, it should be listed as the first item in the array, while the order of subsequent items is not specified by the International Standard.

The "x-default" xml:lang value is used to indicate a default item, which should be placed first in the array Its simple text value must also appear in another item with the corresponding actual language specified by xml:lang In some cases, the "x-default" item may stand alone, representing a default value without a defined language.

EXAMPLE 1 Language alternative with an "x-default" item:

XMP - Une Platforme Extensible pour les Métadonnées

A simple text value denoting a language code as defined in IETF RFC 3066.

A simple text value denoting a digital file format as defined in IETF RFC 2046.

A simple text value denoting the name of a person or organization.

The Open Choice value is a straightforward text representation indicating the intended usage of a resource It consists of a series of colon-separated tokens and parameters, with the first token specifying the primary usage of the rendition While additional tokens are optional, they offer specific characteristics of the rendition, as detailed in Table 2.

 The field namespace URI shall be "http://ns.adobe.com/xap/1.0/sType/ResourceRef#".

 The preferred field namespace prefix is stRef.

Table 3 lists the fields available in ResourceRef Fields need not be present The fields, if used, shall be of the specified types The field content should be as described.

Text denoting an Internet Uniform Resource Identifier as defined in IETF RFC 3986.

The article discusses the definitions and clarifications of Internet Uniform Resource Locators (URLs) as outlined in URIs, URLs, and URNs It categorizes various types of resources, including the "default" as the master resource with no additional tokens, "draft" as a review rendition, "low-res" as a low-resolution stand-in, "proof" as a review proof, "screen" for screen resolution or web rendition, and "thumbnail" as a simplified preview Additional tokens can be used to specify characteristics of these resources.

The recommended order is: thumbnail:format:size:colorspace

EXAMPLE thumbnail:jpeg, thumbnail:16x16, thumbnail:gif:8x8:bw.

The stRef:documentID property contains the GUID value of the xmpMM:DocumentID from the referenced resource Additionally, the stRef:filePath provides the URI for the file path or URL of the referenced resource Lastly, the stRef:instanceID holds the GUID value of the xmpMM:InstanceID from the same resource.

The distinction in capitalization between \$stRef:documentID\$ and \$xmpMM:DocumentID\$ is significant and stems from historical reasons, a fact that also applies to other ResourceRef fields The property \$stRef:renditionClass\$ corresponds to the value of the \$xmpMM:RenditionClass\$ from the referenced resource, while \$stRef:renditionParams\$ reflects the value of the \$xmpMM:RenditionParams\$ property from the same resource.

Table 2 — Defined values for rendition tokens

Dublin Core namespace

The Dublin Core namespace offers a collection of widely utilized properties, with their names and applications defined by the Dublin Core Metadata Element Set established by the Dublin Core Metadata Initiative (DCMI).

 The namespace URI shall be "http://purl.org/dc/elements/1.1/".

 The preferred namespace prefix is dc

NOTE 1 The Dublin Core elements as defined by DCMI all have URIs of the form "http://purl.org/dc/elements/1.1/" where the part differs.

The Dublin Core elements are specified in XMP as properties under the namespace URI "http://purl.org/dc/elements/1.1/," where the local names represent the leaf components of the DCMI URI.

The XMP data modelling of these is consistent with the apparent Dublin Core intent, but specific to XMP.

As a corollary of the data modelling, the RDF serialization of Dublin Core in XMP might not exactly match other RDF usage of the Dublin Core element set.

XMP does not “include Dublin Core” in any fuller sense.

Table 4 lists properties in the Dublin Core namespace The properties, if used, shall be of the specified types. The property content should be as described

Table 4 includes subsections for the DCMI definition and comment, along with an XMP addition The DCMI definition and comment are sourced directly from the Dublin Core Metadata Element Set, while the XMP addition pertains specifically to this International Standard.

Name Type Property content dc:contributor Unordered array of ProperName

DCMI definition: An entity responsible for making contributions to the resource

DCMI comment: Examples of a contributor include a person, an organization, or a service Typically, the name of a contributor should be used to indicate the entity.

XMP addition involves a list of contributors that should exclude those identified in dc:creator According to the DCMI definition, dc:coverage refers to the spatial or temporal topic of the resource, its spatial applicability, or the relevant jurisdiction.

XMP addition: XMP usage is the extent or scope of the resource. dc:creator Ordered array of ProperName

The Dublin Core Metadata Initiative (DCMI) defines a creator as the primary entity responsible for producing a resource This can include individuals, organizations, or services, and it is essential to use the name of the creator to accurately represent the entity involved.

XMP addition: XMP usage is a list of creators Entities should be listed in order of decreasing precedence, if such order is significant. dc:date Ordered array of Date

DCMI definition: A point or period of time associated with an event in the life cycle of the resource dc:description Language

DCMI definition: An account of the resource

26 dc:format MIMEType DCMI definition: The file format, physical medium, or dimensions of the resource.

DCMI comment: Examples of dimensions include size and duration

Recommended best practice is to use a controlled vocabulary such as the list of Internet Media Types [MIME].

XMP addition utilizes a MIME type for its functionality, while dimensions are recorded through a media-specific property that falls outside the parameters of this International Standard According to the DCMI definition, the dc:identifier serves as a clear and unambiguous reference to the resource within a specific context.

DCMI comment: Recommended best practice is to identify the resource by means of a string conforming to a formal identification system. dc:language Unordered array of Locale

DCMI definition: A language of the resource.

XMP addition: XMP usage is a list of languages used in the content of the resource dc:publisher Unordered array of ProperName

DCMI refers to an entity that is responsible for making a resource available, which can be a person, organization, or service It is important to use the name of the publisher to clearly identify this entity.

XMP addition: XMP usage is a list of publishers. dc:relation Unordered array of Text DCMI definition: A related resource

DCMI comment: Recommended best practice is to identify the related resource by means of a string conforming to a formal identification system.

XMP addition: XMP usage is a list of related resources dc:rights Language

Alternative DCMI definition: Information about rights held in and over the resource

DCMI comment: Typically, rights information includes a statement about various property rights associated with the resource, including intellectual property rights.

XMP addition: XMP usage is a list of informal rights statements, given in various languages. dc:source Text DCMI definition: A related resource from which the described resource is derived.

The resource may be partially or fully derived from a related resource, and it is recommended to identify this related resource using a string that adheres to a formal identification system Additionally, the topic of the resource is defined as an unordered array of text, as per DCMI standards.

To effectively represent the subject of a resource, it is advisable to utilize keywords, key phrases, or classification codes, adhering to a controlled vocabulary as a best practice Additionally, the dc:coverage element should be employed to accurately describe the spatial or temporal aspects of the resource.

XMP addition: XMP usage is a list of descriptive phrases or keywords that specify the content of the resource.

Table 4 — Dublin Core properties (continued)

XMP namespace

The XMP basic namespace contains properties that provide basic descriptive information.

 The namespace URI shall be "http://ns.adobe.com/xap/1.0/".

 The preferred namespace prefix is xmp. dc:title Language

Alternative DCMI definition: A name given to the resource

DCMI comment: Typically, a title will be a name by which the resource is formally known.

XMP addition: XMP usage is a title or name, given in various languages. dc:type Unordered array of Text DCMI definition: The nature or genre of the resource

For optimal results, it is advisable to utilize a controlled vocabulary like the DCMI Type Vocabulary [DCMITYPE] To accurately describe the file format, physical medium, or dimensions of a resource, the dc:format element should be employed.

XMP addition: See the dc:format entry for clarification of the XMP usage of that element.

Table 4 — Dublin Core properties (continued)

Table 5 — Properties in the XMP namespace

The xmp:CreateDate property indicates the date and time a resource was created, which may differ from the file-system creation time for digital files For newly created resources, this date should be close to the actual creation time, accounting for any delays in file writing The xmp:CreatorTool property specifies the name of the first tool used to create the resource Additionally, the xmp:Identifier property consists of an unordered array of text strings that uniquely identify the resource within a specific context, with the option to qualify each item using xmpidq:Scheme to indicate the formal identification system it adheres to.

The xmp:Identifier property was introduced to maintain compatibility with existing XMP processors, as the dc:identifier in the original XMP specification was defined as a single identifier rather than an array Additionally, the xmp:Label Text serves as a word or short phrase that designates a resource as part of a user-defined collection.

NOTE One anticipated usage is to organize resources in a file browser. xmp:MetadataDate Date The date and time any metadata for this resource was last changed.

It should be the same as or more recent than xmp:ModifyDate

Table 5 outlines the properties within the XMP namespace, specifying that any utilized properties must adhere to the defined types The content of these properties should align with the descriptions provided in Table 5, as per © ISO 2012 - All rights reserved.

 The namespace URI shall be "http://ns.adobe.com/xap/1.0/mm/" xmp:ModifyDate Date The date and time the resource was last modified

The value of this property may differ from the file's system modification date, as it is usually established prior to the file being saved The xmp:Rating is marked as Closed.

A user-assigned rating for this file The value shall be –1 or in the range [0 5], where –1 indicates “rejected” and 0 indicates “unrated”

If xmp:Rating is not present, a value of 0 should be assumed. NOTE Anticipated usage is for a typical “star rating” UI, with the addition of a notion of rejection.

Table 5 — Properties in the XMP namespace (continued)

Table 6 — Properties in the XMP Rights Management namespace

Name Type Property content xmpRights:Certificate Text A Web URL for a rights management certificate.

NOTE This is a normal (non-URI) simple value because of historical usage. xmpRights:Marked Boolean When true, indicates that this is a rights-managed resource

When false, indicates that this is a public-domain resource Omit if the state is unknown. xmpRights:Owner Unordered array of ProperName

A list of legal owners of the resource. xmpRights:UsageTerms Language

This resource includes a collection of text instructions detailing its legal usage, available in multiple languages Additionally, it provides a web URL that outlines the ownership and usage rights associated with the resource.

NOTE This is a normal (non-URI) simple value because of historical usage.

XMP Rights Management namespace

The XMP Rights Management namespace contains properties that provide information regarding the legal restrictions associated with a resource

 The namespace URI shall be "http://ns.adobe.com/xap/1.0/rights/"

 The preferred namespace prefix is xmpRights.

NOTE These XMP properties are intended to provide a means of rights expression They are not intended to provide digital rights management (DRM) controls.

Table 6 lists XMP Rights Management properties The properties, if used, shall be of the specified types The property content should be as described

XMP Media Management namespace