Warning:
This wiki has been archived and is now read-only.
Sub Types
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".