ISO 16684-1:2012
(Main)Graphic technology — Extensible metadata platform (XMP) specification — Part 1: Data model, serialization and core properties
Graphic technology — Extensible metadata platform (XMP) specification — Part 1: Data model, serialization and core properties
ISO 16684-1 defines two essential components of XMP metadata: - Data model: The data model is the most fundamental aspect. This is an abstract model that defines the forms of XMP metadata items, essentially the structure of statements that XMP can make about resources.- Serialization: The serialization of XMP defines how any instance of the XMP data model can be recorded as XML.In addition, this document defines a collection of core properties, which are XMP metadata items that can be applied across a broad range of file formats and domains of usage.The embedding of XMP packets in specific file formats and domain-specific XMP properties are beyond the scope of this document.
Technologie graphique — Spécification de la plate-forme de métadonnées extensibles (XMP) — Partie 1: Modèle de données, mise en série et paramètres principaux
Grafična tehnologija - Specifikacija razširljive metapodatkovne platforme (XMP) - 1. del: Podatkovni model, serializacija in glavne lastnosti
General Information
Relations
Buy Standard
Standards Content (Sample)
SLOVENSKI STANDARD
SIST ISO 16684-1:2020
01-april-2020
Grafična tehnologija - Specifikacija razširljive metapodatkovne platforme (XMP) -
1. del: Podatkovni model, serializacija in glavne lastnosti
Graphic technology - Extensible metadata platform (XMP) specification - Part 1: Data
model, serialization and core properties
Technologie graphique - Spécification de la plate-forme de métadonnées extensibles
(XMP) - Partie 1: Modèle de données, mise en série et paramètres principaux
Ta slovenski standard je istoveten z: ISO 16684-1:2012
ICS:
35.240.30 Uporabniške rešitve IT v IT applications in information,
informatiki, dokumentiranju in documentation and
založništvu publishing
37.100.99 Drugi standardi v zvezi z Other standards related to
grafično tehnologijo graphic technology
SIST ISO 16684-1:2020 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
SIST ISO 16684-1:2020
---------------------- Page: 2 ----------------------
SIST ISO 16684-1:2020
INTERNATIONAL ISO
STANDARD 16684-1
First edition
2012-02-15
Graphic technology — Extensible
metadata platform (XMP) specification —
Part 1:
Data model, serialization and core
properties
Technologie graphique — Spécification de la plate-forme de
métadonnées extensibles (XMP) —
Partie 1: Modèle de données, mise en série et paramètres principaux
Reference number
ISO 16684-1:2012(E)
©
ISO 2012
---------------------- Page: 3 ----------------------
SIST ISO 16684-1:2020
ISO 16684-1:2012(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2012
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2012 – All rights reserved
---------------------- Page: 4 ----------------------
SIST ISO 16684-1:2020
ISO 16684-1:2012(E)
Contents Page
Foreword. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Normative references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
3 Terms and definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4 Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5 Conformance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5.2 Conforming readers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.3 Conforming writers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.4 Conforming products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6 Data model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1 XMP packets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.2 XMP names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.3 XMP value forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.4 Qualifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7 Serialization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2 Equivalent RDF and XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.3 Optional outer XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.4 rdf:RDF and rdf:Description elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.5 Simple valued XMP properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.6 Structure valued XMP properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.7 Array valued XMP properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.8 Qualifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.9 Equivalent forms of RDF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8 Core properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.2 Core value types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.3 Dublin Core namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.4 XMP namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.5 XMP Rights Management namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.6 XMP Media Management namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.7 xmpidq namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Annex A (informative) Document and instance IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Annex B (informative) Implementation guidance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Annex C (informative) RDF parsing information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
%LEOLRJUDSK\
© ISO 201 – All rights reserved iii
---------------------- Page: 5 ----------------------
SIST ISO 16684-1:2020
ISO 16684-1:2012(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
ISO 16684-1 was prepared by Adobe (as XMP S pecification Part 1, Data Model Serialization, and Core
Properties, July 2010) and was adopted, under a special “fast-track procedure”, by Technical Committee
ISO/TC 130, Graphic technology, in parallel with its approval by the ISO member bodies.
ISO 16684 consists of the following parts, under the general title Graphic technology — Extensible metadata
platform (XMP) specification:
— Part 1: Data model, serialization and core properties
Future parts will address formal validation of XMP and XML syntax for describing XMP UI elements.
iv © ISO 2012 – All rights reserved
---------------------- Page: 6 ----------------------
SIST ISO 16684-1:2020
ISO 16684-1:2012(E)
Introduction
This International Standard specifies a standard for the definition, creation, and processing of metadata that
can be applied to a broad range of resource types. The Extensible Metadata Platform (XMP) was introduced
by Adobe Systems Incorporated in 2001 and has since established itself as a critical technology for improving
business efficiency in many industries. The Adobe Systems XMP Specification Part 1 version of July 2010 is
the basis for this International Standard. Establishing this International Standard ensures the stability and
longevity of its definitions and encourages broader integration and interoperability of XMP with existing
standards.
Metadata is data that describes the characteristics or properties of a resource. It can be distinguished from the
main content of a resource. For example, for a word processing document, the content includes the actual text
data and formatting information, while the metadata might include properties such as author, modification date,
or copyright status.
Some information could be treated as either content or metadata, depending on context. In general, metadata
is useful without regard for a resource’s content. For example, a list of all fonts used in a document could be
useful metadata, while information about the specific font used for a specific paragraph on a page would be
logically treated as content.
Metadata allows users and applications to work more effectively with resources. Applications can make use of
metadata, even if they cannot understand the native format of the resource’s content. Metadata can greatly
increase the utility of resources in collaborative production workflows. For example, an image file might contain
metadata such as its working title, description, and intellectual property rights. Accessing the metadata makes
it easier to perform such tasks as searching for images, locating image captions, or determining the copyright
clearance to use an image.
File systems have typically provided metadata such as file modification dates and sizes. Other metadata can
be provided by other applications, or by users. Metadata might or might not be stored as part of the resource
with which it is associated.
This International Standard provides a thorough understanding of the XMP data model. It is useful for anyone
who wishes to use XMP metadata, including both developers and end-users of applications that handle
metadata for resources of any kind.
The serialization information is vital for developers of applications that will generate, process, or manage files
containing XMP metadata. The serialization information will also interest application developers wishing to
understand file content. This International Standard also provides additional guidelines for programmers who
will implement XMP metadata processors.
The International Organization for Standardization (ISO) draws attention to the fact that it is claimed that
compliance with this document may involve the use of a patent concerning the creation, processing,
modification, and storage of XMP metadata.
ISO takes no position concerning the evidence, validity and scope of this patent right. The holder of this patent
right has assured ISO that he is willing to negotiate licences under reasonable and non-discriminatory terms
and conditions with applicants throughout the world. In this respect, the statement of the holder of this patent
right is registered with ISO. Information may be obtained from:
Adobe Systems Incorporated
345 Park Avenue
San Jose, California, 95110-2704
USA
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights other than those identified above. ISO shall not be held responsible for identifying any or all such patent
rights.
© ISO 2012 - All rights reserved v
---------------------- Page: 7 ----------------------
SIST ISO 16684-1:2020
---------------------- Page: 8 ----------------------
SIST ISO 16684-1:2020
INTERNATIONAL STANDARD ISO 16684-1:2012(E)
Graphic technology — Extensible metadata platform (XMP)
specification —
Part 1:
Data model, serialization and core properties
1 Scope
This part of ISO 16684 defines two essential components of XMP metadata:
Data model: The data model is the most fundamental aspect. This is an abstract model that defines the
forms of XMP metadata items, essentially the structure of statements that XMP can make about resources.
Serialization: The serialization of XMP defines how any instance of the XMP data model can be recorded
as XML.
In addition, this part of ISO 16684 defines a collection of core properties, which are XMP metadata items
that can be applied across a broad range of file formats and domains of usage.
The embedding of XMP packets in specific file formats and domain-specific XMP properties are beyond the
scope of this part of ISO 16684.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced document
(including any amendments) applies.
IEEE 754, Standard for Binary Floating-Point Arithmetic
http://grouper.ieee.org/groups/754/
IETF RFC 2046, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, November 1996
http://www.ietf.org/rfc/rfc2046.txt
IETF RFC 3066, Tags for the Identification of Languages, January 2001
http://www.ietf.org/rfc/rfc3066.txt
IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, January 2005
http://www.ietf.org/rfc/rfc3986.txt
Date and Time Formats, W3C submission, September 1997
http://www.w3.org/TR/NOTE-datetime
Dublin Core Metadata Element Set, Version 1.1, October 2010
http://dublincore.org/documents/dces/
Extensible Markup Language (XML) 1.0 (Fifth Edition), W3C Recommendation 26 November 2008
http://www.w3.org/TR/2008/REC-xml-20081126/
Namespaces in XML 1.0 (Second Edition), August 2006
http://www.w3.org/TR/2006/REC-xml-names-20060816/
RDF/XML Syntax Specification (Revised), W3C Recommendation 10 February 2004
http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/
The Unicode Standard
http://www.unicode.org/standard/standard.html
© ISO 2012 - All rights reserved 1
---------------------- Page: 9 ----------------------
SIST ISO 16684-1:2020
ISO 16684-1:2012(E)
URIs, URLs, and URNs: Clarifications and Recommendations 1.0, W3C Note 21 September 2001
http://www.w3.org/TR/2001/NOTE-uri-clarification-20010921/
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
character data
XML text that is not markup
[Extensible Markup Language specification, Section 2.4]
3.2
element content
XML text between the start-tag and end-tag of an element
[Extensible Markup Language specification, Section 3.1, syntax production 43]
3.3
empty-element tag
XML tag identifying an element with no content
[Extensible Markup Language specification, Section 3.1]
3.4
NCName
XML name that does not contain a colon (‘:’, U+003A)
[Namespaces in XML, Section 3, syntax production 4]
3.5
property
named container for a metadata value at the top level of an XMP packet
NOTE Lower-level components of an XMP packet are structure fields, array items, and qualifiers.
3.6
RDF
Resource Description Framework, an XML syntax for describing metadata
[RDF/XML Syntax Specification]
3.7
rendition (of a resource)
resource that is a rendering of some other resource in a particular form
NOTE Various renditions of a resource have the same content in differing forms. For example, a digital image could have
high resolution, low resolution, or thumbnail renditions. A text document could be in a word processor format for editing or
rendered as a PDF for sharing. See also version (of a resource).
3.8
URI
Uniform Resource Identifier, a compact sequence of characters that identifies an abstract or physical resource
[IETF RFC 3986]
2 © ISO 2012 – All rights reserved
---------------------- Page: 10 ----------------------
SIST ISO 16684-1:2020
ISO 16684-1:2012(E)
3.9
version (of a resource)
resource that is the result of editing some other resource
NOTE Different versions of a resource typically have differing content in the same form. See also rendition (of a resource).
3.10
XML element
primary component of XML syntax
[Extensible Markup Language specification, Section 3, syntax production 39]
3.11
XML expanded name
pair of strings consisting of a namespace URI and a local name
[Namespaces in XML, Section 2.1]
3.12
XMP processor
hardware or software component that is responsible for reading, modifying, or writing XMP
3.13
white space
XML text consisting of one or more space characters, carriage returns, line feeds, or tabs
[Extensible Markup Language specification, Section 2.3]
4 Notations
The following type styles are used for specific types of text:
Table 1 — Conventions for type styles
Typeface style Used for
Bold XMP property names. For example, xmp:CreateDate
Italic Terms when defined in text, document titles, or emphasis.
The following names are used for important Unicode characters:
SPACE - U+0020
QUOTE - U+0022 (")
APOSTROPHE - U+0027 (')
5 Conformance
5.1 General
Conforming XMP packets shall adhere to all requirements of this International Standard and conforming XMP
packets are not required to use any feature other than those explicitly required by this International 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”.
© ISO 2012 - All rights reserved 3
---------------------- Page: 11 ----------------------
SIST ISO 16684-1:2020
ISO 16684-1:2012(E)
5.2 Conforming readers
A conforming reader shall comply with all requirements regarding reader functional behaviour specified in this
International Standard. The requirements of this International Standard with respect to reader behaviour are
stated in terms of general functional requirements applicable to all conforming readers. A conforming reader
shall accept all output from conforming writers, including optional output that conforming writers may produce.
This International Standard does not prescribe any specific technical design, user interface, or implementation
details for conforming readers.
5.3 Conforming writers
A conforming writer shall comply with all requirements regarding writer functional behaviour specified in this
International Standard. The requirements of this International Standard with respect to writer behaviour are
stated in terms of general functional requirements applicable to all conforming writers and focus on the creation
of conforming XMP packets. This International Standard does not prescribe any specific technical design, user
interface, or implementation details for conforming writers.
5.4 Conforming products
A conforming product shall comply with all requirements regarding reader and writer functional behaviour as
specified in this International Standard.
6 Data model
6.1 XMP packets
An instance of the XMP data model is called an XMP packet. An XMP packet is a set of XMP metadata
properties. Each property has a name and a value. Each property name in an XMP packet shall be unique
within that packet.
NOTE 1 The restriction for unique names means that it is invalid to have multiple occurrences of the same property name
in an XMP packet. Multiple values are represented using an XMP array value (see 6.3.4, “Array values”). Instead of having
three dc:subject properties that each hold one keyword, there would be one dc:subject property that is an array with three
items.
All properties in a single XMP packet shall describe a single resource. Separate XMP packets may describe the
same resource. Conflict resolution for separate packets that describe the same resource is beyond the scope
of this International Standard.
Lower-level components of an XMP packet (structure fields or array items) may describe one or more other
resources.
NOTE 2 The provision for lower-level components about some other resource is not an addition to the data model, in that
this is not a formal feature of the data model and is not reflected in written XMP in any specific manner. Rather, it is a
clarification to the “one packet about one resource” rule, to avoid disallowing certain data models. The XMP about a
compound resource might have a list of constituent resources and even copies of XMP about those constituents. This
would all be modelled using the defined XMP value forms.
The composition of a resource and the precise association of an XMP packet with a resource is beyond the
scope of this International Standard. Where feasible, an XMP packet should be physically associated with the
resource that it describes.
NOTE 3 A common resource is a complete digital file, or an identifiable part of a digital file such as an embedded image in
PDF. The structure of a PDF file and the manner of associating XMP with any particular component of a PDF file is beyond
the scope of this part of ISO 16684.
4 © ISO 2012 – All rights reserved
---------------------- Page: 12 ----------------------
SIST ISO 16684-1:2020
ISO 16684-1:2012(E)
The XMP packet that describes a digital file or part of a digital file should be embedded in the file using
standard features of the file format to provide the association between the XMP packet and the resource. The
embedding mechanisms for specific file formats are beyond the scope of this International Standard.
An XMP packet may contain a URI, called the AboutURI, that identifies the resource that the packet describes.
The URI scheme, detailed URI syntax, and association of the URI with any target entity is beyond the scope of
this International Standard.
NOTE 4 It is possible for an XMP packet to not contain an AboutURI and not have a physical association with the
resource. Instead, there can be an external means of association.
EXAMPLE Consider the statement, “The author of Moby Dick is Herman Melville”. This statement is represented by
metadata in which the resource is the book “Moby Dick”, the property name is “author”, and the property value is “Herman
Melville”, as in Figure 1. (This is only a diagram, not an example of well-formed XMP.)
Moby Dick
Author Date Written
"Herman Melville" "1851"
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.
NOTE 6 The intent of these rules is that XMP is generally open to arbitrary extension of properties. Users of XMP are
allowed to freely invent custom metadata and to expect XMP-aware applications to support the creation, modification, and
viewing of that metadata. Therefore, this is expressed as a recommendation instead of as a requirement because any
particular environment could have local policies about XMP usage.
6.2 XMP names
Properties (6.1, “XMP packets”) have names, as do fields of structure values (6.3.3, “Structure values”) and
qualifiers (6.4, “Qualifiers”). All names in XMP shall be XML expanded names, consisting of a namespace URI
and a local name. The namespace URI for an XMP name shall not be empty. Two XMP names shall be
equivalent if their namespace URIs are identical and their local names are identical. This comparison shall be
physical, byte-for-byte equality using the same Unicode encoding. Other processing, including but not limited to
Unicode character normalizations, shall not be applied.
NOTE 1 XML namespace URIs are generally best viewed as string literals. There is no commitment that the URI is
resolvable to a Web resource. Although many XML namespace URIs begin with "http://", there might be no HTTP page at
that address.
The namespace prefix used in written XML—and, as a consequence, in XMP—serves only as a key to look up
the appropriate URI. For convenience in this International Standard, XMP names are commonly written in a
prefix:local style, for example, dc:title. The relevant URI for the prefix used in this document is either explicit,
clear from local context, or irrelevant (as in the generic value-form diagrams where the specific URI does not
matter).
NOTE 2 The specific convenience is that dc:title is more concise and readable than something like ("http://purl.org/dc/
elements/1.1/", creator) in the cases where the namespace URI is known and meaningful. This is especially so when the
precise URI is not relevant, as in an artificial example.
© ISO 2012 - All rights reserved 5
---------------------- Page: 13 ----------------------
SIST ISO 16684-1:2020
ISO 16684-1:2012(E)
A namespace URI used in XMP should end in a character that is not allowed in an XML NCName (the local
name). Recommended characters are the slash ("/", U+002F) or the number sign ("#", U+0023). This can
improve compatibility with applications that concatenate the namespace URI and local name, avoiding potential
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.
Other than xml: and rdf:, all namespaces used in 6, “Data model”, and Figure 5, “Qualifiers example”, are
illustrative. I n particular, the "http://ns.adobe.com/xmp-example/" URI is fictional. The use of specific XMP
names in the illustrations does not imply that they are defined in this International Standard. The namespaces
defined in 8, “Core properties”, are normative.
Following typical XML and World Wide Web practice, the creation of XMP names should use a namespace URI
that incorporates a domain name owned by the creator. This diminishes the chance of namespace collisions
and identifies the origin of the namespace.
In this International Standard, the xml: prefix is bound to the URI "http://www.w3.org/XML/1998/" that is defined
in the Extensible Markup Language specification. The rdf: prefix is bound to the URI "http://www.w3.org/1999/
02/22-rdf-syntax-ns#" that is defined in the RDF/XML Syntax Specification. The Extensible Markup Language
specification and the RDF/XML Syntax Specification heavily restrict the use of these namespaces. Except for
rdf:type, these namespaces shall not be used for any XMP property or structure field. Except for rdf:type and
xml:lang, these namespaces shall not be used for any XMP qualifier. See also 7.9.2.5, “RDF Typed Nodes”.
6.3 XMP value forms
6.3.1 General
Values in the XMP data model have one of three forms: simple, structure, or array. There are two variants of
simple values: normal and URI. There are three variants of the array form: unordered array, ordered array, and
alternative array. The fields in structures and the items in arrays may have any value form. There is no fixed
bound on the complexity of XMP data modelling.
These forms are the primitive values of XMP. Higher-level data types may be defined that combine these
primitive forms with additional constraints, such as those defined in 8, “Core properties”.
6.3.2 Simple values
A simple value is a string of Unicode text as defined in The Unicode Standard. The string may be empty.
There are two variants of simple values: normal and URI. The URI variant of a simple value should be used for
values that represent URIs; the normal variant should be used for all other simple values.
NOTE The distinction between normal and URI simple values is not critical to the organization of the abstract XMP data
...
INTERNATIONAL ISO
STANDARD 16684-1
First edition
2012-02-15
Graphic technology — Extensible
metadata platform (XMP) specification —
Part 1:
Data model, serialization and core
properties
Technologie graphique — Spécification de la plate-forme de
métadonnées extensibles (XMP) —
Partie 1: Modèle de données, mise en série et paramètres principaux
Reference number
ISO 16684-1:2012(E)
©
ISO 2012
---------------------- Page: 1 ----------------------
ISO 16684-1:2012(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2012
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2012 – All rights reserved
---------------------- Page: 2 ----------------------
ISO 16684-1:2012(E)
Contents Page
Foreword. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Normative references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
3 Terms and definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4 Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5 Conformance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5.2 Conforming readers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.3 Conforming writers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.4 Conforming products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6 Data model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1 XMP packets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.2 XMP names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.3 XMP value forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.4 Qualifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7 Serialization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2 Equivalent RDF and XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.3 Optional outer XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.4 rdf:RDF and rdf:Description elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.5 Simple valued XMP properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.6 Structure valued XMP properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.7 Array valued XMP properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.8 Qualifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.9 Equivalent forms of RDF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8 Core properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.2 Core value types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.3 Dublin Core namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.4 XMP namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.5 XMP Rights Management namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.6 XMP Media Management namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.7 xmpidq namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Annex A (informative) Document and instance IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Annex B (informative) Implementation guidance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Annex C (informative) RDF parsing information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
%LEOLRJUDSK\
© ISO 201 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO 16684-1:2012(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
ISO 16684-1 was prepared by Adobe (as XMP S pecification Part 1, Data Model Serialization, and Core
Properties, July 2010) and was adopted, under a special “fast-track procedure”, by Technical Committee
ISO/TC 130, Graphic technology, in parallel with its approval by the ISO member bodies.
ISO 16684 consists of the following parts, under the general title Graphic technology — Extensible metadata
platform (XMP) specification:
— Part 1: Data model, serialization and core properties
Future parts will address formal validation of XMP and XML syntax for describing XMP UI elements.
iv © ISO 2012 – All rights reserved
---------------------- Page: 4 ----------------------
ISO 16684-1:2012(E)
Introduction
This International Standard specifies a standard for the definition, creation, and processing of metadata that
can be applied to a broad range of resource types. The Extensible Metadata Platform (XMP) was introduced
by Adobe Systems Incorporated in 2001 and has since established itself as a critical technology for improving
business efficiency in many industries. The Adobe Systems XMP Specification Part 1 version of July 2010 is
the basis for this International Standard. Establishing this International Standard ensures the stability and
longevity of its definitions and encourages broader integration and interoperability of XMP with existing
standards.
Metadata is data that describes the characteristics or properties of a resource. It can be distinguished from the
main content of a resource. For example, for a word processing document, the content includes the actual text
data and formatting information, while the metadata might include properties such as author, modification date,
or copyright status.
Some information could be treated as either content or metadata, depending on context. In general, metadata
is useful without regard for a resource’s content. For example, a list of all fonts used in a document could be
useful metadata, while information about the specific font used for a specific paragraph on a page would be
logically treated as content.
Metadata allows users and applications to work more effectively with resources. Applications can make use of
metadata, even if they cannot understand the native format of the resource’s content. Metadata can greatly
increase the utility of resources in collaborative production workflows. For example, an image file might contain
metadata such as its working title, description, and intellectual property rights. Accessing the metadata makes
it easier to perform such tasks as searching for images, locating image captions, or determining the copyright
clearance to use an image.
File systems have typically provided metadata such as file modification dates and sizes. Other metadata can
be provided by other applications, or by users. Metadata might or might not be stored as part of the resource
with which it is associated.
This International Standard provides a thorough understanding of the XMP data model. It is useful for anyone
who wishes to use XMP metadata, including both developers and end-users of applications that handle
metadata for resources of any kind.
The serialization information is vital for developers of applications that will generate, process, or manage files
containing XMP metadata. The serialization information will also interest application developers wishing to
understand file content. This International Standard also provides additional guidelines for programmers who
will implement XMP metadata processors.
The International Organization for Standardization (ISO) draws attention to the fact that it is claimed that
compliance with this document may involve the use of a patent concerning the creation, processing,
modification, and storage of XMP metadata.
ISO takes no position concerning the evidence, validity and scope of this patent right. The holder of this patent
right has assured ISO that he is willing to negotiate licences under reasonable and non-discriminatory terms
and conditions with applicants throughout the world. In this respect, the statement of the holder of this patent
right is registered with ISO. Information may be obtained from:
Adobe Systems Incorporated
345 Park Avenue
San Jose, California, 95110-2704
USA
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights other than those identified above. ISO shall not be held responsible for identifying any or all such patent
rights.
© ISO 2012 - All rights reserved v
---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO 16684-1:2012(E)
Graphic technology — Extensible metadata platform (XMP)
specification —
Part 1:
Data model, serialization and core properties
1 Scope
This part of ISO 16684 defines two essential components of XMP metadata:
Data model: The data model is the most fundamental aspect. This is an abstract model that defines the
forms of XMP metadata items, essentially the structure of statements that XMP can make about resources.
Serialization: The serialization of XMP defines how any instance of the XMP data model can be recorded
as XML.
In addition, this part of ISO 16684 defines a collection of core properties, which are XMP metadata items
that can be applied across a broad range of file formats and domains of usage.
The embedding of XMP packets in specific file formats and domain-specific XMP properties are beyond the
scope of this part of ISO 16684.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced document
(including any amendments) applies.
IEEE 754, Standard for Binary Floating-Point Arithmetic
http://grouper.ieee.org/groups/754/
IETF RFC 2046, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, November 1996
http://www.ietf.org/rfc/rfc2046.txt
IETF RFC 3066, Tags for the Identification of Languages, January 2001
http://www.ietf.org/rfc/rfc3066.txt
IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, January 2005
http://www.ietf.org/rfc/rfc3986.txt
Date and Time Formats, W3C submission, September 1997
http://www.w3.org/TR/NOTE-datetime
Dublin Core Metadata Element Set, Version 1.1, October 2010
http://dublincore.org/documents/dces/
Extensible Markup Language (XML) 1.0 (Fifth Edition), W3C Recommendation 26 November 2008
http://www.w3.org/TR/2008/REC-xml-20081126/
Namespaces in XML 1.0 (Second Edition), August 2006
http://www.w3.org/TR/2006/REC-xml-names-20060816/
RDF/XML Syntax Specification (Revised), W3C Recommendation 10 February 2004
http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/
The Unicode Standard
http://www.unicode.org/standard/standard.html
© ISO 2012 - All rights reserved 1
---------------------- Page: 6 ----------------------
ISO 16684-1:2012(E)
URIs, URLs, and URNs: Clarifications and Recommendations 1.0, W3C Note 21 September 2001
http://www.w3.org/TR/2001/NOTE-uri-clarification-20010921/
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
character data
XML text that is not markup
[Extensible Markup Language specification, Section 2.4]
3.2
element content
XML text between the start-tag and end-tag of an element
[Extensible Markup Language specification, Section 3.1, syntax production 43]
3.3
empty-element tag
XML tag identifying an element with no content
[Extensible Markup Language specification, Section 3.1]
3.4
NCName
XML name that does not contain a colon (‘:’, U+003A)
[Namespaces in XML, Section 3, syntax production 4]
3.5
property
named container for a metadata value at the top level of an XMP packet
NOTE Lower-level components of an XMP packet are structure fields, array items, and qualifiers.
3.6
RDF
Resource Description Framework, an XML syntax for describing metadata
[RDF/XML Syntax Specification]
3.7
rendition (of a resource)
resource that is a rendering of some other resource in a particular form
NOTE Various renditions of a resource have the same content in differing forms. For example, a digital image could have
high resolution, low resolution, or thumbnail renditions. A text document could be in a word processor format for editing or
rendered as a PDF for sharing. See also version (of a resource).
3.8
URI
Uniform Resource Identifier, a compact sequence of characters that identifies an abstract or physical resource
[IETF RFC 3986]
2 © ISO 2012 – All rights reserved
---------------------- Page: 7 ----------------------
ISO 16684-1:2012(E)
3.9
version (of a resource)
resource that is the result of editing some other resource
NOTE Different versions of a resource typically have differing content in the same form. See also rendition (of a resource).
3.10
XML element
primary component of XML syntax
[Extensible Markup Language specification, Section 3, syntax production 39]
3.11
XML expanded name
pair of strings consisting of a namespace URI and a local name
[Namespaces in XML, Section 2.1]
3.12
XMP processor
hardware or software component that is responsible for reading, modifying, or writing XMP
3.13
white space
XML text consisting of one or more space characters, carriage returns, line feeds, or tabs
[Extensible Markup Language specification, Section 2.3]
4 Notations
The following type styles are used for specific types of text:
Table 1 — Conventions for type styles
Typeface style Used for
Bold XMP property names. For example, xmp:CreateDate
Italic Terms when defined in text, document titles, or emphasis.
The following names are used for important Unicode characters:
SPACE - U+0020
QUOTE - U+0022 (")
APOSTROPHE - U+0027 (')
5 Conformance
5.1 General
Conforming XMP packets shall adhere to all requirements of this International Standard and conforming XMP
packets are not required to use any feature other than those explicitly required by this International 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”.
© ISO 2012 - All rights reserved 3
---------------------- Page: 8 ----------------------
ISO 16684-1:2012(E)
5.2 Conforming readers
A conforming reader shall comply with all requirements regarding reader functional behaviour specified in this
International Standard. The requirements of this International Standard with respect to reader behaviour are
stated in terms of general functional requirements applicable to all conforming readers. A conforming reader
shall accept all output from conforming writers, including optional output that conforming writers may produce.
This International Standard does not prescribe any specific technical design, user interface, or implementation
details for conforming readers.
5.3 Conforming writers
A conforming writer shall comply with all requirements regarding writer functional behaviour specified in this
International Standard. The requirements of this International Standard with respect to writer behaviour are
stated in terms of general functional requirements applicable to all conforming writers and focus on the creation
of conforming XMP packets. This International Standard does not prescribe any specific technical design, user
interface, or implementation details for conforming writers.
5.4 Conforming products
A conforming product shall comply with all requirements regarding reader and writer functional behaviour as
specified in this International Standard.
6 Data model
6.1 XMP packets
An instance of the XMP data model is called an XMP packet. An XMP packet is a set of XMP metadata
properties. Each property has a name and a value. Each property name in an XMP packet shall be unique
within that packet.
NOTE 1 The restriction for unique names means that it is invalid to have multiple occurrences of the same property name
in an XMP packet. Multiple values are represented using an XMP array value (see 6.3.4, “Array values”). Instead of having
three dc:subject properties that each hold one keyword, there would be one dc:subject property that is an array with three
items.
All properties in a single XMP packet shall describe a single resource. Separate XMP packets may describe the
same resource. Conflict resolution for separate packets that describe the same resource is beyond the scope
of this International Standard.
Lower-level components of an XMP packet (structure fields or array items) may describe one or more other
resources.
NOTE 2 The provision for lower-level components about some other resource is not an addition to the data model, in that
this is not a formal feature of the data model and is not reflected in written XMP in any specific manner. Rather, it is a
clarification to the “one packet about one resource” rule, to avoid disallowing certain data models. The XMP about a
compound resource might have a list of constituent resources and even copies of XMP about those constituents. This
would all be modelled using the defined XMP value forms.
The composition of a resource and the precise association of an XMP packet with a resource is beyond the
scope of this International Standard. Where feasible, an XMP packet should be physically associated with the
resource that it describes.
NOTE 3 A common resource is a complete digital file, or an identifiable part of a digital file such as an embedded image in
PDF. The structure of a PDF file and the manner of associating XMP with any particular component of a PDF file is beyond
the scope of this part of ISO 16684.
4 © ISO 2012 – All rights reserved
---------------------- Page: 9 ----------------------
ISO 16684-1:2012(E)
The XMP packet that describes a digital file or part of a digital file should be embedded in the file using
standard features of the file format to provide the association between the XMP packet and the resource. The
embedding mechanisms for specific file formats are beyond the scope of this International Standard.
An XMP packet may contain a URI, called the AboutURI, that identifies the resource that the packet describes.
The URI scheme, detailed URI syntax, and association of the URI with any target entity is beyond the scope of
this International Standard.
NOTE 4 It is possible for an XMP packet to not contain an AboutURI and not have a physical association with the
resource. Instead, there can be an external means of association.
EXAMPLE Consider the statement, “The author of Moby Dick is Herman Melville”. This statement is represented by
metadata in which the resource is the book “Moby Dick”, the property name is “author”, and the property value is “Herman
Melville”, as in Figure 1. (This is only a diagram, not an example of well-formed XMP.)
Moby Dick
Author Date Written
"Herman Melville" "1851"
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.
NOTE 6 The intent of these rules is that XMP is generally open to arbitrary extension of properties. Users of XMP are
allowed to freely invent custom metadata and to expect XMP-aware applications to support the creation, modification, and
viewing of that metadata. Therefore, this is expressed as a recommendation instead of as a requirement because any
particular environment could have local policies about XMP usage.
6.2 XMP names
Properties (6.1, “XMP packets”) have names, as do fields of structure values (6.3.3, “Structure values”) and
qualifiers (6.4, “Qualifiers”). All names in XMP shall be XML expanded names, consisting of a namespace URI
and a local name. The namespace URI for an XMP name shall not be empty. Two XMP names shall be
equivalent if their namespace URIs are identical and their local names are identical. This comparison shall be
physical, byte-for-byte equality using the same Unicode encoding. Other processing, including but not limited to
Unicode character normalizations, shall not be applied.
NOTE 1 XML namespace URIs are generally best viewed as string literals. There is no commitment that the URI is
resolvable to a Web resource. Although many XML namespace URIs begin with "http://", there might be no HTTP page at
that address.
The namespace prefix used in written XML—and, as a consequence, in XMP—serves only as a key to look up
the appropriate URI. For convenience in this International Standard, XMP names are commonly written in a
prefix:local style, for example, dc:title. The relevant URI for the prefix used in this document is either explicit,
clear from local context, or irrelevant (as in the generic value-form diagrams where the specific URI does not
matter).
NOTE 2 The specific convenience is that dc:title is more concise and readable than something like ("http://purl.org/dc/
elements/1.1/", creator) in the cases where the namespace URI is known and meaningful. This is especially so when the
precise URI is not relevant, as in an artificial example.
© ISO 2012 - All rights reserved 5
---------------------- Page: 10 ----------------------
ISO 16684-1:2012(E)
A namespace URI used in XMP should end in a character that is not allowed in an XML NCName (the local
name). Recommended characters are the slash ("/", U+002F) or the number sign ("#", U+0023). This can
improve compatibility with applications that concatenate the namespace URI and local name, avoiding potential
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.
Other than xml: and rdf:, all namespaces used in 6, “Data model”, and Figure 5, “Qualifiers example”, are
illustrative. I n particular, the "http://ns.adobe.com/xmp-example/" URI is fictional. The use of specific XMP
names in the illustrations does not imply that they are defined in this International Standard. The namespaces
defined in 8, “Core properties”, are normative.
Following typical XML and World Wide Web practice, the creation of XMP names should use a namespace URI
that incorporates a domain name owned by the creator. This diminishes the chance of namespace collisions
and identifies the origin of the namespace.
In this International Standard, the xml: prefix is bound to the URI "http://www.w3.org/XML/1998/" that is defined
in the Extensible Markup Language specification. The rdf: prefix is bound to the URI "http://www.w3.org/1999/
02/22-rdf-syntax-ns#" that is defined in the RDF/XML Syntax Specification. The Extensible Markup Language
specification and the RDF/XML Syntax Specification heavily restrict the use of these namespaces. Except for
rdf:type, these namespaces shall not be used for any XMP property or structure field. Except for rdf:type and
xml:lang, these namespaces shall not be used for any XMP qualifier. See also 7.9.2.5, “RDF Typed Nodes”.
6.3 XMP value forms
6.3.1 General
Values in the XMP data model have one of three forms: simple, structure, or array. There are two variants of
simple values: normal and URI. There are three variants of the array form: unordered array, ordered array, and
alternative array. The fields in structures and the items in arrays may have any value form. There is no fixed
bound on the complexity of XMP data modelling.
These forms are the primitive values of XMP. Higher-level data types may be defined that combine these
primitive forms with additional constraints, such as those defined in 8, “Core properties”.
6.3.2 Simple values
A simple value is a string of Unicode text as defined in The Unicode Standard. The string may be empty.
There are two variants of simple values: normal and URI. The URI variant of a simple value should be used for
values that represent URIs; the normal variant should be used for all other simple values.
NOTE The distinction between normal and URI simple values is not critical to the organization of the abstract XMP data
model. The distinction does have an effect on the RDF serialization, as seen in 7.5, “Simple valued XMP properties”. This
allows XMP data modelling to more closely align with general RDF data modelling.
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".
The value of the property xmp:CreateDate is "2002-08-15T17:10:04-06:00".
6 © ISO 2012 – All rights reserved
---------------------- Page: 11 ----------------------
ISO 16684-1:2012(E)
XMP_Specification.pdf
xmp:CreateDate
dc:format
"application/pdf" "2002-08-15T17:10:04-06:00"
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.
Each field in a structure shall have a unique name within that structure. Field names shall be XML expanded
names. Fields need not be in the same namespace as their parent structure nor in the same namespace as
other fields in the 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 (
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.