Sub Types

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

Proposition for a rationale for selecting sub-properties for the MAWG core properties: a starting point for selecting relevant sub-properties could be to look at the mapping tables provided by Jean-Pierre Evain (http://www.ebu.ch/metadata/), and check out in his tables which sub-properties apply to at least 3 metadata schemas; this would constitute the first list from which we would select a subset by voting, as for the core properties set. Note: the reference to the schema (name of the schema/standard) which the sub-property belongs to should be kept.

A specific set of sub-properties is the one suggested by the PLING W3C group, dealing with right management issues on the Web: ma:policy (former ma:license) should have the following set of 3 sub-properties: ma:license, ma:access, ma:privacy With this set, we would provide a complete set of possible right-related information contained in resources metadata.

Preliminary work by Joakim gathering possibly relevant sub-properties, collected form different existing formats:

ma:identifier UMID, EASN


ma:title Album Title, Song Title

ma:location Recording Location, Depicted Location

ma:Date Create Date, Publishing Date

ma:rating Review Rating, MPAA, Personal Rating, Review Context

ma:collection Album, Personal, My Favorites

ma:fragments

ma:targetAudience Age group, Geographical

ma:contributor and ma:creator

Normative role types:

editor (EBU 11.1)
actor (EBU 25.9)
composer
featured_in
cinematographer
director
musicproducer
producer
screenplayer
writer
distributor (company)
production company

All role types; EBURoleCode, Version Date: 01.05.2009 http://www.ebu.ch/metadata/cs/web/ebu_RoleCodeCS_p.xml.htm

relation types (NA)

ma:relation

version of
reference  (literature, book, web site)
sound tracks
influenced by
re-edit
adapted_work
translated
interpretation
followed by
similar theme
similar touch
is similar to
nominated award
origin country


About the Role types: The creator of a collection can indeed be mapped to ma:creator, with a property specifying that the meaning or scope of "collection author" is narrower than the one of ma:creator

Good approach. For the API, I think keeping the number of methods small (e.g. one property = one method) would be good too. To capture the differences you mention one could create different signatures, e.g. getCreator(mediaResourceURI) getCreator(mediaResourceURI,COLLECTIONCREATOR) with COLLECTIONCREATOR being a constant for the roles. In that way, the user of the API has both options: getting just all creator information (first method call) or only a specific one (second call).


A possible name for the role could be "curator". In a museum a curator is someone who is responsible for an exhibition and who is in charge of a certain collection of artworks. Or to put it simple the name of the role could just be "collection creator".