View source

From Media Annotations Working Group Wiki

You do not have permission to do that, for the following reasons:

• The action you have requested is limited to users in the group user.
• You must confirm your e-mail address before editing pages. Please set and validate your e-mail address through your user preferences.

You can view and copy the source of this page:

== Background == === Purpose === Analyzing the usage in certain metadata formats of more than one description level for representing a resource (e.g. work-expression-instance-item in FRBR [2]). In the scope of this document we call these characteristic “multi-level description”. === Reference Material === [1] [http://dublincore.org/documents/dces/ Dublin Core Metadata Element Set, Version 1.1] [2] [http://www.ifla.org/VII/s13/frbr/frbr_current1.htm IFLA’s Functional Requirements for Bibliographic Records FRBR] [3] [http://www.adobe.com/devnet/xmp/pdfs/XMPSpecificationPart2.pdf XMP Specification Part 2] [4] [http://www.vraweb.org/projects/vracore4/VRA_Core4_Intro.pdf VRA Core 4.0] [5] [http://dmag.ac.upc.edu/ontologies/ Media Value Chain Ontology (MVCO)] (informal introduction) === Introduction === There are different aspects and functionalities which can derive into a multi-level description: * (1) Representing different abstract views of a resource or a group of resources (e.g. one record from class ''Work'' in FRBR about the Pink Floyd’s rock opera “The Wall” is related to several records from class ''Instance'', like the one about "The Wall", the album published by Columbia Records or the one about "The Wall", the album published by Harvest Records). * (2) Representing different stages and states of the media value chain related to Intellectual Property (creation, publishing, etc.). And example is the ''Adaptation'' class in MVCO, which serves to represent works derived from original works). * (3) Representing different stages of the media processing workflow, even if they do not derive intellectual property rights (e.g. differentiating the features of a photo from the features of the digital image which has been obtained from it through scanning) * (4) Handling collections and membership (e.g. ''Collection'' structure in VRA) * (5) Whole/part relationships (regions, tracks, etc.) (e.g. ''SegmentDecomposition'' in MPEG-7) A multi-level description can be present in ''structured'' metadata formats (e.g. MPEG-7) but also in ''flat'' metadata formats (e.g. Dublin Core v1.1 [1]). === Pros and cons of multilevel description === Pros: * Avoid redundancy of data records which share certain properties (literal values and relationships). For instance the name of the author in all the records related to different exemplars of a video will be the same. ** (little) Benefits in terms of efficiency ** Benefits in terms of consistency (e.g. avoid two exemplars of the video using slightly different names for the author) * Allow the definition of more precise relationships and more expressive models. Cons: * Complexity * Long metadata paths to literal values (e.g. Item/Manifestation/Expression/Work/Title) Graphical example of bibliographic records in a multi-level description format: <center>[[Image:MultimediaPresentationUC_examplemultilevel.jpg]]</center> Graphical example of bibliographic records in a single-level description format: <center>[[Image:MultimediaPresentationUC_examplesinglelevel.jpg]]</center> == Metadata formats == === Dublin Core Metadata Element Set, Version 1.1 && Adobe’s XMP Dublin Core Schema=== ''Reviewer: Ruben * CASE: Flat multi-level description *Defines the properties: **''dc:relation'', "A related resource." **''dc:source'', "A related resource from which the described resource is derived." **''dc:creator'', "An entity primarily responsible for making the resource". **''dc:publisher'', "An entity responsible for making the resource available." **''dc:contributor'', "An entity responsible for making contributions to the resource". ''Comments * ''Flat (only one structure for any kind of resource) * ''Does not allow representing different abstract views of a resource * ''dc:source allows representing different stages of the media processing workflow * ''ambiguous meaning of dc:relation * ''Allows representing some stages and states of the media value chain related to Intellectual Property through the "dc:creator", "dc:publisher", "dc:contributor" and "dc:rights" properties. === Adobe’s XMP Media Management Schema === ''Reviewer: Ruben * CASE: Flat multi-level description * In XMP a resource may be: ** A file. This includes simple files such as JPEG images, or more complex files such as entire PDF documents. ** A meaningful portion of a file, as determined by the file structure and the applications that process it. * XMP defines properties to represent two different abstractions of a resource: ** ''Document'': The file in general, as a persistent container whose content can change ** ''Instance'': A specific state of the file as it exists at a point in time. * Properties: **''xmpMM:DocumentID'', a common identifier for all versions and renditions of a resource. **''xmpMM:DerivedFrom'', which points to another resource, from which the current one is derived. **''xmpMM:History'', an ordered array of high-level user actions that resulted in this resource. **''xmpMM:Ingredients'', an unordered array of references to resources that were incorporated, by inclusion or reference, into the resource **''xmpMM:InstanceID'', an identifier for a specific incarnation of a document, updated each time a file is saved. ''Comments * ''Allow representing (two) different abstract views of a resource: document and instance. * ''Allows representing different stages of the media processing workflow through the xmpMM:DerivedFrom, xmpMM:Ingredients and the xmpMM:History properties. xmpMM:DerivedFrom seems to be overlapped with dc:source. === IFLA’s Functional Requirements for Bibliographic Records FRBR === ''Reviewer: Ruben * CASE: Structured multi-level description In 1997 the Standing Committee of the IFLA Section on Cataloguing approved the FRBR model (Functional Requirements for Bibliographic Records). The purpose of FRBR is a re-examination of bibliographic records cataloguing theory and practice. The entities (in the first group) of FRBR (as depicted in the figure) represent the different aspects of user interests in the products of intellectual or artistic endeavor: [[Image:MultimediaPresentationUC_frbr.jpg|center|600px|FRBR]] * Each class reflects a different way of grouping physical items which share certain information. From more abstract or general (work) to more precise (a physical item). * Reflect different user scopes which are useful for Search&Retrieval '''Work''': “a distinct intellectual or artistic creation” * An imprecise abstract entity which encompasses a common idea about a set of expressions. * Example 1: “The Wall”, Pink Floyd’s rock opera; “The Wall”, Alan Parker’s movie. * Example 2: “The Lord of the Rings”, the book; “The Lord of the Rings Strategy Battle Game”; “The Lord of the Rings” the film trilogy by Peter Jackson * A work is realized through one or more expressions (e.g the double album of “The Wall”, the Second Edition of “The Lord of the Rings”, the book, in English). * When the modification of a work involves a significant degree of independent intellectual or artistic effort, the result is viewed as a new work: Rewritings, parodies, musical variations on a theme, adaptations of a work from one literary or art form to another (e.g., dramatizations), adaptations from one medium of the graphic arts to another, etc.), abstracts, digests and summaries. (e.g “The Wall”, Alan Parker’s movie). '''Expression''': “the intellectual or artistic realization of a work in the form of alpha-numeric, musical, or choreographic notation, sound, image, object, movement, etc., or any combination of such forms” * A more refined view of a work but also an abstract entity which encompasses an imprecise idea about a set of different physical manifestations. * Example 1: “The Wall” the double album. * Example 2: The Second Edition of “The Lord of the Rings” in English * Variants of a expression incorporating revisions or updates are viewed simply as expressions of the same work (i.e., the variants are not viewed as separate works): Abridgements or enlargements, addition of parts or an accompaniment to a musical composition, translations from one language to another, musical transcriptions and arrangements, and dubbed or subtitled versions of a film. * The process of obtaining an expression from another expression (e.g. the photo of a painting is not modeled in FRBR) '''Manifestation''': “the physical embodiment of an expression of a work” * Precise entity which refers to a set of physical copies or items. * Example 1: “The Wall” the double album originally released on Columbia Records in the U.S, “The Wall” the release on Harvest Records in the UK, “The Wall” a digitally remastered CD in 1994 in the UK on EMI. * Example 2: The Spanish translation of the Second Edition of the “Lord of The Rings” published by Minotauro in 1980 in Barcelona ISBN 8445070320 '''Item''': “A single exemplar of a manifestation” * Example: An exemplar of “The Lord of the Rings” on my shelves ''Comments * ''CONS: Fuzzy difference between Work and Manifestation. Maybe just one level of abstraction is necessary. * ''CONS: Long metadata paths can be a burden * ''PROS: Separating a general "title" from a specific "title" (e.g. Special Edition..) seems useful * ''PROS: Allows representing different stages of the media processing workflow. * ''Maybe we can avoid such a complex structure, but we should address the problem of consistency of literal fields (enforcing exactly same author names, titles, etc.) * ''The "derivedFrom" relationship can be obtained using a field (like "source" in Dublin Core). === VRA (Visual Resources Association) === ''Reviewer: Ruben * CASE: Structured multi-level description The VRA Core is a data standard for the cultural heritage community. It consists of a metadata element set (units of information such as title, location, date, etc.), as well as an initial blueprint for how those elements can be hierarchically structured. The element set provides a categorical organization for the description of works of visual culture as well as the images that document them. <center>[[Image:MultimediaPresentationUC_vra.jpg|300px]]</center> * A work is a unique entity such as an object or event. Examples include a painting, sculpture, or photograph; a building or other construction in the built environment; an object of material culture, or a performance. Works may be simple or complex. Works may have component parts that are cataloged as works themselves but related to the larger work in a whole/part or hierarchical fashion via the RELATION element. * An image is a visual representation of a work in either whole or part. The representation serves to provide access to the work when the work itself cannot be experienced firsthand. In image collections, such representations typically are found in the form of slides, photographs, and/or digital files. * Two levels + “collection” * Allows relationships: 1) work to work, 2) image to work, 3) image or work to collection * The distinction between work and image is misleading (according to the definition a photo is both) ''Comments * ''CONS: Fuzzy difference between Work and Image. A photo seems to be both according to the definition. * ''PROS: Allows representing different stages of the media processing workflow. === MPEG-21 MVCO (Media Value Chain Ontology) === ''Reviewer: VictorRodriguez * CASE: Structured multi-level description This ontology [4] describes the Intellectual Property along the Value Chain. Besides transforming the resource itself, the cathegory of the Intellectual Property Entity may be transformed, implying a different chain of agent's rights (Author, Translator, Publisher etc.). The next image shows one record with the author´s work and other with the Spanish translation. Both agents (author and translator) hold rights over the translation. <center>[[Image:mvcofig1.png]]</center> The other main non-abstract IP Entities are Manifestation (the author´s expression of the Work), the Instance (an interpretation of the Work by other artist) and the Copy (a reproduction). <center>[[Image:mvcofig2-rev2.png]]</center> ''Pros: * ''The chain of agents that gave rise to a annotated resource and that hold some rights over it is kept. * ''Better description of what can and cannot (legally) be done over a resource. ''Cons: * ''To make precise linkings, annotations would require the use of URIs. == Conclusions == <CENTER> <TABLE border=1 width="75%"> <TR> <TD></TD> <TD align="center">'''DC & XMP-DC'''</TD> <TD align="center">'''XMP-M'''</TD> <TD align="center">'''FRBR'''</TD> <TD align="center">'''VRA'''</TD> <TD align="center">'''MVCO'''</TD> <TD align="center">action</TD> </TR> <TR> <TD align="left">''multiple abstractions''</TD> <TD align="left">NO</TD> <TD align="left">document-instance and versioning</TD> <TD align="left">work-expression-manifestation-item</TD> <TD align="left">work-image</TD> <TD align="left">work-manifestation-instance-copy</TD> <TD align="left">WE SHOULD INCLUDE PROPERTIES LINKING RELATED RESOURCES (DIFFERENT ENCODINGS OF THE SAME CONTENTS, COPIES, UPDATED VERSIONS, ETC.)</TD> </TR> <TR> <TD align="left">''derived from''</TD> <TD align="left">dc:source</TD> <TD align="left">xmpMM:DerivedFrom xmpMM:Ingredients</TD> <TD align="left">YES</TD> <TD align="left">PARTIAL (one step, work-image)</TD> <TD align="left">PARTIAL (related to IP)</TD> <TD align="left">SEEMS TO BE RELEVANT, MAYBE SHOULD BE INCORPORATED</TD> </TR> <TR> <TD align="left">''whole/part''</TD> <TD align="left">MAYBE (dc:relation)</TD> <TD align="left">YES</TD> <TD align="left">YES</TD> <TD align="left">?</TD> <TD align="left">YES</TD> <TD align="left">?</TD> </TR> <TR> <TD align="left">''collections''</TD> <TD align="left">MAYBE (dc:relation)</TD> <TD align="left">YES</TD> <TD align="left">?</TD> <TD align="left">?</TD> <TD align="left">?</TD> <TD align="left">?</TD> </TR> </TABLE> </CENTER> [[MetadataDictionary]]

Return to MultilevelDescriptionReview.