GUIDELINES
`FOR HANDLING
`IMAGE METADATA
`
`Version 1.0
`September 2008
`
`www.metadataworkinggroup.org
`
`Petitioner Apple Inc. - Ex. 1038, p. 1
`
`

`

`Metadata Working Group
`Guidelines For Handling Image Metadata
`__________________________________________________________________________
`
`
`Copyrights
`
`© Copyright 2008 by Adobe Systems Inc., Apple Inc., Canon Inc., Microsoft Corp., Nokia Corp. and
`Sony Corp. All rights reserved.
`
`Terms and Conditions
`
`This document is made available by Adobe Systems Inc., Apple Inc., Canon Inc., Microsoft Corp.,
`Nokia Corp. and Sony Corp. (collectively, the “Authors”) and grants you (either an individual or an
`entity) and your affiliates (“Licensee”) this license. Licensee agrees that Licensee has read,
`understood and will comply with these terms and conditions.
`
`1. Definitions
`
`1.1 “Licensed Products” means only those specific portions of products (hardware, software or
`combinations thereof) that implement and are compliant with all Normative Portions of the
`Guidelines.
`
`1.2 “Normative Portions” means a portion of the Guidelines that must be implemented to comply
`with such guidelines. If such guidelines define optional parts, Normative Portions include those
`portions of the optional part that must be implemented if the implementation is to comply with
`such optional part.
`
`1.3 “Necessary Claims” are those claims of a patent or patent application, throughout the world,
`excluding design patents and design registrations, owned or controlled, or that can be
`sublicensed in compliance with the requirements of this Agreement, by the party or its affiliates
`now or at any future time and which would necessarily be infringed by implementation of the
`Guidelines. A claim is necessarily infringed hereunder only when it is not possible to avoid
`infringing it because there is no non-infringing alternative for implementing the Normative
`Portions of the Guidelines. Notwithstanding the foregoing, Necessary Claims shall not include
`any claims other than as set forth above even if contained in the same patent as Necessary
`Claims; or that read solely on any implementations of any portion of the Guidelines that are not
`required by the Normative Portions of the Guidelines, or that, if licensed, would require a
`payment of royalties by the licensor to unaffiliated third parties. Moreover, Necessary Claims
`shall not include (i) any enabling technologies that may be necessary to make or use any
`Licensed Product but are not themselves expressly set forth in the Guidelines (e.g.,
`semiconductor manufacturing technology, compiler technology, object oriented technology,
`basic operating system technology, data and voice networking technology, and the like); or (ii)
`the implementation of other published standards developed elsewhere and merely referred to in
`the body of the Guidelines, or (iii) any Licensed Product and any combinations thereof the
`purpose or function of which is not required for compliance with the Guidelines. For purposes of
`this definition, the Guidelines shall be deemed to include only architectural and interconnection
`requirements essential for interoperability and shall not include any implementation examples
`unless such implementation examples are expressly identified as being required for compliance
`with the Guidelines.
`
`1.4 “Guidelines” mean the Guidelines For Handling Image Metadata Version 1.0.
`
`
`
`
`
`__________________________________________________________________________
`
`www.metadataworkinggroup.org
`
`Page 2
`
`
`
`
`
`Petitioner Apple Inc. - Ex. 1038, p. 2
`
`

`

`Metadata Working Group
`Guidelines For Handling Image Metadata
`__________________________________________________________________________
`
`
`2. License
`
`2.1 Copyright: Licensee must include the following on ALL copies of the Guidelines, or portions
`thereof, that Licensee makes:
`
`2.1.1. A link or URL to the Guidelines at this location: http://www.metadataworkinggroup.org
`
`2.1.2. The copyright notice as shown in the Guidelines.
`
`2.2 Patent: The Authors each will grant Licensee a royalty-free license under reasonable, non-
`discriminatory terms and conditions to their Necessary Claims to make, have made, use,
`reproduce market, import, offer to sell and sell, and to otherwise distribute Licensed Products.
`Licensee agrees to grant Authors and their affiliates a royalty-free license under reasonable,
`non-discriminatory terms and conditions to its Necessary Claims to make, have made, use,
`reproduce market, import, offer to sell and sell, and to otherwise distribute Licensed Products.
`Nothing herein shall prevent the Authors from charging a reasonable royalty for such Necessary
`Claims to any party who is offering their Necessary Claims on royalty bearing terms.
`
`3. Limitations
`
`3.1 No Warranty: THE “GUIDELINES FOR HANDLING IMAGE METADATA VERSION 1.0”
`GUIDELINES IS PROVIDED "AS IS," AND THE AUTHORS MAKE NO REPRESENTATIONS
`OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
`WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-
`INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE GUIDELINES ARE SUITABLE
`FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT
`INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER
`RIGHTS.
`
`3.2 No Liability: THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL,
`INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY
`USE OR DISTRIBUTION OF THE GUIDELINES.
`
`3.3 Trademark: The name and trademarks of the Authors may NOT be used in any manner,
`including advertising or publicity pertaining to the Guidelines or its contents without specific,
`written prior permission. Title to copyright in the Guidelines will at all times remain with the
`Authors.
`
`3.4 No Other Rights: No other rights are granted by implication, estoppel or otherwise.
`
`Normative Sections
`
`This document attempts to conform to the keyword usage practices defined in RFC 2119. This RFC
`defines the use and strength of the capitalized terms MUST, MUST NOT, SHOULD, SHOULD NOT
`and MAY. All sections and appendixes, except the first chapter “Introduction”, are normative, unless
`they are explicitly indicated to be informative.
`
`These imperatives are used to highlight those requirements that are required to insure interoperability
`and drive compatibility.
`
`__________________________________________________________________________
`
`www.metadataworkinggroup.org
`
`Page 3
`
`
`
`
`
`Petitioner Apple Inc. - Ex. 1038, p. 3
`
`

`

`Metadata Working Group
`Guidelines For Handling Image Metadata
`__________________________________________________________________________
`
`
`References
`
`This document includes the following references to third party documents:
`
`Metadata Specifications
`Exif 2.21/DCF 2.0
` Official Exif specifications are available in paper form and can be ordered on the JEITA website.
`IPTC-IIM 4.1
`
` http://www.iptc.org/std/IIM/4.1/specification/IIMV4.1.pdf
`IPTC Core 1.0
` http://www.iptc.org/std/Iptc4xmpCore/1.0/specification/Iptc4xmpCore_1.0-spec-XMPSchema_8.pdf
`IPTC Core 1.1 & IPTC Extension 1.0
` http://www.iptc.org/std/photometadata/2008/specification/IPTC-PhotoMetadata-2008_1.pdf
`XMP
`
` http://www.adobe.com/devnet/xmp/pdfs/xmp_specification.pdf
`
`File Format Specifications
`
`JPEG
` http://www.jpeg.org/jpeg/index.html
`TIFF
`
` http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf
`PSD/PSIRs
`
` http://www.adobe.com/go/psir
`
`Miscellaneous
`
`RDF
` http://www.w3.org/TR/rdf-schema
`Dublin Core
`
` http://dublincore.org/documents/dces
`RFC2119
`
` http://www.ietf.org/rfc/rfc2119.txt
`Date and Time (W3C)
` http://www.w3.org/TR/NOTE-datetime
`
`__________________________________________________________________________
`
`www.metadataworkinggroup.org
`
`Page 4
`
`
`
`
`
`Petitioner Apple Inc. - Ex. 1038, p. 4
`
`

`

`Metadata Working Group
`Guidelines For Handling Image Metadata
`__________________________________________________________________________
`
`
`TABLE OF CONTENTS
`
`
`1. Introduction....................................................................................................................................... 6

`1.1 Introducing the Metadata Working Group......................................................................................... 9

`1.2 Scoping the work .............................................................................................................................. 9

`1.3 Digital imaging metadata initiative .................................................................................................. 10

`1.4 Relationship to standards organizations......................................................................................... 10

`1.5 Definition of terms........................................................................................................................... 11

`2. Usage and Data Model ................................................................................................................... 12

`2.1 Actor definition ................................................................................................................................ 12

`2.1.1 Creator ..................................................................................................................................... 12

`2.1.2 Changer ................................................................................................................................... 13

`2.1.3 Consumer................................................................................................................................. 13

`3. Metadata Management ................................................................................................................... 14

`3.1 Existing metadata standards .......................................................................................................... 14

`3.2 Important metadata for the consumer............................................................................................. 16

`3.3 Metadata formats within image files ............................................................................................... 18

`3.3.1 Handling a single metadata format .......................................................................................... 18

`3.3.2 Handling multiple metadata formats......................................................................................... 18

`3.3.2.1 Exif and IPTC-IIM in the context of XMP ........................................................................... 20

`3.3.3 Metadata reconciliation guidance............................................................................................. 21

`3.3.3.1 Handling Exif and XMP...................................................................................................... 21

`3.3.3.2 Handling IPTC-IIM and XMP ............................................................................................. 24

`3.3.3.3 Handling Exif/TIFF, IPTC-IIM and XMP metadata............................................................. 27

`3.3.3.4 More complex reconciliation in popular image formats ..................................................... 28

`3.4 Specific core vocabulary and data issues....................................................................................... 32

`3.4.1 Keywords ................................................................................................................................. 32

`3.4.2 Description ............................................................................................................................... 33

`3.4.3 Date / Time............................................................................................................................... 34

`3.4.4 Orientation................................................................................................................................ 35

`3.4.5 Rating....................................................................................................................................... 36

`3.4.6 Copyright.................................................................................................................................. 36

`3.4.7 Creator ..................................................................................................................................... 37

`3.4.8 Location (Created) ................................................................................................................... 38

`3.4.9 Location (Shown) ..................................................................................................................... 39

`4. Appendix ......................................................................................................................................... 41

`4.1 References ..................................................................................................................................... 41

`
`
`__________________________________________________________________________
`
`www.metadataworkinggroup.org
`
`
`
`
`
`Page 5
`
`Petitioner Apple Inc. - Ex. 1038, p. 5
`
`

`

`Metadata Working Group
`Guidelines For Handling Image Metadata
`__________________________________________________________________________
`
`
`1. INTRODUCTION
`
`Metadata, often referred to as “data about data,” provides interesting information that supplements the
`primary content of digital documents. Metadata has become a powerful tool to organize and search
`through the growing libraries of image, audio and video content that users are producing and
`consuming. This is especially important in the area of digital photography where, despite the increased
`quality and quantity of sensor elements, it is not currently practical to organize and query images
`based only on the millions of image pixels. Instead, it is best to use metadata properties that describe
`what the photo represents and where, when and how the image was taken.
`
`Metadata is now critical in workflows ranging from consumer sharing experiences to professional-level
`asset management. That said, there are several complications which result from structural hierarchies
`required to store metadata within images:
`
`Digital images are stored in a variety of common file formats such as TIFF, JPEG and PSD as well as
`proprietary formats such as RAW. Each file format has unique rules regarding how metadata formats
`must be stored within the file.
`
`
`Within image file formats, metadata can be stored within a variety of common metadata container
`formats such as Exif/TIFF IFDs, Adobe XMP, Photoshop Image Resources (PSIR) and IPTC-IIM.
`Each metadata container format has unique rules regarding how metadata properties must be stored,
`ordered and encoded within the container.
`
`
`Within metadata container formats, metadata can be stored within a variety of semantic groupings.
`Examples of these groupings are Exif's GPS, XMP's Dublin Core, and IPTC-IIM's Application Record.
`
`__________________________________________________________________________
`
`www.metadataworkinggroup.org
`
`Page 6
`
`
`
`
`
`Petitioner Apple Inc. - Ex. 1038, p. 6
`
`

`

`Metadata Working Group
`Guidelines For Handling Image Metadata
`__________________________________________________________________________
`
`
`
`Some metadata semantic groupings, such as IPTC's, are targeted for specific user workflows. Some
`metadata semantic groupings, such as Exif's, can be stored within multiple metadata containers.
`
`
`Within metadata semantic groupings, there can be dozens of individual metadata properties. Each
`metadata property can require data of specific types such as strings, numbers or arrays. Some
`metadata properties are conventionally read-only while other can be user modified. Some metadata
`properties are typically objective while others are subjective. Some useful properties, such as user
`ratings, have no commonly used standard storage container while others, such as copyright string,
`can be stored within many containers with similar but subtly distinct semantics.
`
`
`__________________________________________________________________________
`
`www.metadataworkinggroup.org
`
`Page 7
`
`
`
`
`
`Petitioner Apple Inc. - Ex. 1038, p. 7
`
`

`

`Metadata Working Group
`Guidelines For Handling Image Metadata
`__________________________________________________________________________
`
`
`The above structural complexities have traditionally caused further complications which challenge the
`effective use of metadata in workflows:
`
`
` Different applications and devices have chosen different policies in cases where
`standard metadata specifications were weakly or ambiguously defined.
`
` Different applications and devices have chosen different policies in cases where
`metadata can be stored in more than one standard location.
`
` An application or device often stores proprietary metadata, such as maker notes,
`within a metadata container. This practice is fragile because such private data can
`easily be lost when a different application modifies a file.
`
` Some applications and devices usurp a general purpose metadata property to
`address a specific need. This can cause compatibility problems for applications
`that correctly use the property in accordance with the generally accepted
`specification,
`
` Some applications avoid the complexities of storing metadata within image files
`altogether and opt instead to store it in a separate file or database. This practice
`can easily result in the loss of metadata when a file is used across several
`applications.
`
`All of these problems have lead to significant frustration to users who want consistent metadata
`interoperability across digital imaging products and services. Manufacturers of digital imaging
`hardware, software and services spend substantial development resources dealing with these
`problems. Until practical guidance to resolve these complexities exists, these problems will
`continue to cost both users and industry time and resources.
`
`__________________________________________________________________________
`
`www.metadataworkinggroup.org
`
`Page 8
`
`
`
`
`
`Petitioner Apple Inc. - Ex. 1038, p. 8
`
`

`

`Metadata Working Group
`Guidelines For Handling Image Metadata
`__________________________________________________________________________
`
`
`1.1 Introducing the Metadata Working Group
`
`Based on a 2006 proposal by Microsoft, the Metadata Working Group (MWG) organization was
`created in 2007 by 5 founding members: Apple, Adobe, Canon, Microsoft and Nokia. Sony joined this
`initiative in 2008.
`
`The goals are:
`
` Preservation and seamless interoperability of digital image metadata.
`
`
`
`Interoperability and availability to all applications, devices, and services.
`
`The organization is based on a formal legal framework and royalty free intellectual property policy that
`allows member companies and other industry leaders to collaborate on a solution to the above
`problems. The efforts of the MWG are organized into initiatives. The first initiative (embodied in this
`document) addresses digital imaging metadata for typical consumers. Future initiatives might include
`metadata for professional photography, audio and video metadata, etc.
`
`1.2 Scoping the work
`
`Consumer sharing of still images has exploded with the maturing of Internet services for the storage,
`manipulation and sharing of pictures. However, the majority of standards related to still images are
`oriented toward the documentation of the creation of an image or towards professional (e.g. print
`media) usage and management of images. There are no “advocates” in the ecosystem for the
`consumer who simply wants to share with friends, manage her snapshots, or deal with photos in
`unique, personal ways. The intent of this document is to use the existing standards to address the key
`organizational metadata questions that most consumers have:
`
` Who is involved with this image (who took it, who owns it, who’s in it)?
`
` What is interesting about this image?
`
` Where is this image from?
`
` When was this image created or modified?
`
`The goal of this document is to provide best practices specifically for these critical data, with the intent
`of solving interoperability issues in the consumer space.
`
`When we look at the “4W’s” (who, what, where, when), it is clear that this data can range from highly
`precise (e.g. a GPS latitude/longitude) to extremely vague or context dependant (e.g. “In my
`backyard”). It is not the intent of this document to solve the difficult semantic issues around this
`problem, but rather to help ensure that semantically equal metadata is identified across standards,
`and where it exists, semantically well-defined properties are chosen as best practice containers for the
`data. The two key notions of “reconciliation” and “rationalization” for the consumer space, defines the
`scope of this initial work.
`
`__________________________________________________________________________
`
`www.metadataworkinggroup.org
`
`Page 9
`
`
`
`
`
`Petitioner Apple Inc. - Ex. 1038, p. 9
`
`

`

`Metadata Working Group
`Guidelines For Handling Image Metadata
`__________________________________________________________________________
`
`
`1.3 Digital imaging metadata initiative
`
`The scope of this initial effort is targeting still-imaging metadata, with a focus on consumer workflows
`(i.e., at this time it does not specifically address professional scenarios). The effort has been highly
`focused on solving a specific set of problems, outlined below. Future releases of this initiative will both
`refine and expand the effort.
`
`Specific issues addressed in this document
`
`
`
`Interoperability and preservation of metadata between processes (devices,
`applications, platforms and services), file formats and metadata standards.
`
` Overlapping fields between existing standards and schemas.
`
`These issues have been addressed by the creation of:
`
` A usage and data model based on common consumer use cases.
`
` Actor definitions of the roles each device or application play when interacting with
`metadata.
`
` Best practices for how, when and where metadata should be changed in popular
`consumer still image file formats using existing industry metadata standards.
`
` Rationalization of common and important consumer metadata fields between existing
`standards.
`
`Specific non-goals for this document
`
` To define new metadata structures, storage formats, or standards where ones exist
`today.
`
`1.4 Relationship to standards organizations
`
`There are a number of established standards, such as Exif and IPTC-IIM, widely used by the digital
`photography industry. This effort is not intended to replace existing industry standards, but rather to
`build on them by providing resources to improve interoperability and metadata preservation between
`them. This is based on significant understanding of the industry (customers, scenarios, technologies)
`and experience in building the products that capture, process, store, share and transmit digital
`photographs.
`
`This document, “Guidelines For Handling Image Metadata”, is designed to help guide developers by
`providing best practices on how to create, read and modify metadata within digital images. It’s also
`designed to motivate the owners of metadata standards and formats to think about preservation,
`interoperability, and compatibility in general terms.
`
`__________________________________________________________________________
`
`www.metadataworkinggroup.org
`
`Page 10
`
`
`
`
`
`Petitioner Apple Inc. - Ex. 1038, p. 10
`
`

`

`Metadata Working Group
`Guidelines For Handling Image Metadata
`__________________________________________________________________________
`
`
`1.5 Definition of terms
`
`Digest
`
`A checksum value to help identify changes between the metadata formats
`
`Dublin Core
`
`The Dublin Core is a metadata element set. It includes all DCMI terms
`(that is, refinements, encoding schemes, and controlled vocabulary terms)
`intended to facilitate discovery of resources.
`
`Exif
`
`IPTC
`
`“Exchangeable image file format” – standard for image file formats
`introduced by Japan Electronics and Information Technology industries
`Association (JEITA)
`
`“International Press Telecommunications Council” – creator and maintainer
`of metadata standards
`
`IPTC-IIM
`
`“Information Interchange Model” – IPTC multimedia metadata standard
`
`IPTC Core
`
`“IPTC Core” – IPTC photo metadata standard based on XMP
`
`IPTC Extension
`
`“IPTC Extension” – IPTC photo metadata standard based on XMP
`
`JPEG
`
`MWG
`
`PSD
`
`RDF
`
`TIFF
`
`Unicode
`
`UTF-8
`
`XMP
`
`The JPEG file format, widely used in image and photography workflows
`
`“Metadata Working Group” – Industry consortium responsible for this
`document
`
`The native Adobe Photoshop file format
`
`The “Resource Description Framework (RDF)”, described by the W3C as a
`“framework for representing information in the Web”, has become a
`general model for representing metadata
`
`The “Tagged Image File Format (TIFF)” is a file format to store images as
`well as photography.
`
`Unicode is an industry standard to consistently represent characters and
`text within modern software and hardware systems
`
`UTF-8 is a byte-oriented encoding form of Unicode
`
`“Extensible Metadata Platform” – multimedia metadata standard
`introduced by Adobe
`
`__________________________________________________________________________
`
`www.metadataworkinggroup.org
`
`Page 11
`
`
`
`
`
`Petitioner Apple Inc. - Ex. 1038, p. 11
`
`

`

`Metadata Working Group
`Guidelines For Handling Image Metadata
`__________________________________________________________________________
`
`
`2. USAGE AND DATA MODEL
`
`For a better understanding of the proposed guidance in this document this chapter introduces the
`notion of different actors that play specific roles in metadata processing. These definitions will be used
`throughout the document to discuss the rules on how to handle metadata across the different formats.
`
`2.1 Actor definition
`
`In the actor model, the flow of an image file is represented as a series of phases between multiple
`applications (actors). It starts from the Creator actor, going through Changer actors and ending at the
`Consumer actor. In this model, all actors are essentially black boxes where processing actions,
`specific to the actor, are not known nor considered important from the model’s point of view. However,
`the state of the metadata in the image file is communicated between each phase.
`
`Figure 1 - Actor state diagram
`
`
`
`An application is defined to be compliant if it reads and writes metadata in accordance to this
`document. There may also be non-compliant applications modifying metadata between two actors. It
`is not always possible to detect such a modification, so any compliant application must also accept
`non-compliant metadata.
`
`This document presents the rules on how to handle a small set of selected metadata fields in a
`compliant manner. Roles defined in this document have two important functions: first they attempt to
`clarify the purpose of the selected fields, and secondly how to apply similar metadata handling to fields
`not covered here. An application can function in different roles at different times but every time it
`touches metadata, it does so only in one of these roles.
`
`2.1.1 Creator
`
`A Creator application creates the first instances of metadata into the (image) file. It is usually (though
`not necessarily) the same application that creates the image data, e.g. an image processing
`application, a digital camera or a cell phone. The typical aspect of a Creator application is that there is
`no old metadata to preserve. Alternately, an image editing application might behave as a creator even
`though it produces a new file from an existing file.
`
`A Creator must fulfill these criteria:
`
`
`
`It MUST have full knowledge of all metadata it is creating.
`
`__________________________________________________________________________
`
`www.metadataworkinggroup.org
`
`Page 12
`
`
`
`
`
`Petitioner Apple Inc. - Ex. 1038, p. 12
`
`

`

`Metadata Working Group
`Guidelines For Handling Image Metadata
`__________________________________________________________________________
`
`
`
`
`
`It MUST always create standard compliant metadata at least in one form as specified
`in this document.
`
`In summary, the Creator understands all metadata it is writing and has exclusive access to the image
`content. There’s no existing data the Creator needs to worry about. Most of the metadata is being
`determined while creating the content.
`
`2.1.2 Changer
`
`A Changer application first reads metadata from the image file and then writes new or modified
`metadata back to the same file.
`
`The rules for an application in Changer role are:
`
`
`
`
`
`
`
`It MUST NOT delete metadata unintentionally.
`
`It SHOULD obey rules for Consumer applications when reading metadata.
`
`It SHOULD keep all forms of metadata it modifies in sync with each other.
`
`The first rule implies that if the image file contains metadata fields that the application does not
`understand, it must preserve them when writing new or updated fields back to the file. The second rule
`comes from the fact that, almost always, the Changer application is also a Consumer application so it
`must also observe all Consumer application rules. The third rule states, that whenever, the Changer
`application writes new metadata fields to the file, it must keep different forms exiting in the file, e.g.
`Exif, IPTC-IIM and XMP, in sync. This could also mean to remove a particular metadata
`representation while writing another preferred one.
`
`2.1.3 Consumer
`
`A Consumer application only reads metadata from the image file. It may use metadata for display
`purposes, searching, content organization, etc. but it never modifies the metadata in the file itself.
`
`General rules for Consumer application are:
`
`
`
`
`
`It MUST reconcile between different forms of metadata in the image.
`
`It MUST use metadata according to the semantics defined for each field.
`
`The first rule says that a Consumer application must process metadata according to policies defined
`in this document and then only the reconciled data is used further before it is presented to the end-
`user. This may involve, for example resolving possibly conflicting information between Exif, IPTC-IIM
`and XMP versions of a metadata field existing in the image file. The second rule says that applications
`must understand the semantics of desired metadata fields and use them appropriately. For example,
`in order to reconcile different forms of metadata, the application must know the semantics of the
`metadata in question. In summary, the Consumer application treats image files as read-only so the
`state of the metadata remains unchanged.
`
`Tools designed to display technical details about the format and content of the file’s metadata, but not
`intended to primarily express metadata semantic meaning, are not required to be compliant
`Consumer applications.
`__________________________________________________________________________
`
`www.metadataworkinggroup.org
`
`Page 13
`
`
`
`
`
`Petitioner Apple Inc. - Ex. 1038, p. 13
`
`

`

`Metadata Working Group
`Guidelines For Handling Image Metadata
`__________________________________________________________________________
`
`
`3. METADATA MANAGEMENT
`
`Metadata is an essential part of image and photography based workflows. Cameras capture device
`metadata while taking pictures. Operating systems and other software subsequently read metadata to
`build up catalogs and offer effective search capabilities. In addition, the user is able to enhance this
`workflow with it’s own metadata that will be stored either inside the file or within caching or database
`systems.
`
`In the context of consumer image-based workflows, the existence of different metadata standards
`leads to interoperability issues when using various devices, operating systems and software tools.
`Although the majority of metadata properties are unique there are a number of properties that overlap
`across several metadata standards and thus lead to interoperability issues.
`
`The goal of this section is to identify those overlapping properties and provide guidance on how to
`handle them correctly across the different metadata formats.
`
`After a brief overview of existing metadata standards, this chapter introduces the most common
`metadata properties in the context of consumer workflows. To ensure best interoperability across
`software and hardware systems a general reconciliation mechanism will be discussed