W3C home > Mailing lists > Public > public-media-annotation@w3.org > June 2009

RE: Comparison of TT and MAWG Metadata Properties

From: Bailer, Werner <werner.bailer@joanneum.at>
Date: Tue, 30 Jun 2009 13:17:43 +0200
To: Glenn Adams <gadams@xfsi.com>
CC: "public-tt@w3.org" <public-tt@w3.org>, "public-media-annotation@w3.org" <public-media-annotation@w3.org>
Message-ID: <CD9846F872C7874BB4E0FDF2A61EF09F18DAF33D9C@RZJC1EX.jr1.local>
Dear Glenn, 

> You might find it interesting 
> to review Table K-1 [1] to see the source derivation of the 
> ttm:* element vocabulary. As you can see, it is based in part 
> on SVG (by direct reuse) and MPEG-7 (by conceptual reuse). 

Thanks for this hint. Looking a the table it states that ttm:actor is derived from mpeg7:Creator and ttm:agent from mpeg7:Agent. mpeg7:Agent is quite generic and used in different contexts. If I understand this correctly, ttm:actor[@type='character'] maps to mpeg7:Creator/Character, and  ttm:actor[@type!='character'] maps to mpeg7:Creator/Agent. In addition we know that if an Agent is referenced by a Character, mpeg7:Creator/Role is "actor".

What was the reason for not including an attribute/element for specifying other roles than actor, e.g. director, composer, ... ?

> We 
> have previously had comments about the abbreviation of 
> ttm:desc. I personally don't have a strong feeling either 
> way.

I also do not consider this a major issue, as long as the mapping is clear.

Best regards,
> On Tue, Jun 30, 2009 at 4:29 PM, Bailer, Werner 
> <werner.bailer@joanneum.at> wrote:
> 	Dear all,
> 	I have done a review of the metadata elements you 
> propose in the DFXP draft to see how this fits together with 
> our work in the media annotations group (MAWG). MAWG has 
> defined a set of core properties in a recent working draft 
> (http://www.w3.org/TR/2009/WD-mediaont-10-20090618/#core-prope
rty-lists). Data types are not yet defined in this draft, this > is currently ongoing work.
> 	Here is an attempt to map the elements between the 
> ttm:* and ma:* elements:
> 	- ttm:title: maps to a ma:title instance, it is more 
> general as ma:title can also have qualifiers that specify the 
> type of title (main, secondary, original, ...)
> 	- ttm:desc: 1:1 mapping to ma:description
> 	- ttm:copyright: 1:1 mapping to ma:copyright
> 	- ttm:agent: maps to ma:creator or ma:contributor, 
> ttm:agent has qualifiers (person, character, group, 
> organization, other) that specify the type of agent rather 
> than the role in the creation process (as for ma:creator and 
> ma:contributor)
> 	-- ttm:name: maps to the content of 
> ma:creator/ma:contributor; there are qualifiers for specific 
> name parts or for an unstructured string, similar to the 
> structured/unstructured return values drafted for the MAWG 
> API [note that there is not yet a public WD of the API]
> 	-- ttm:actor: links a character to a real-world agent
> 	To conclude: Most of the ttm elements are covered in 
> the MAWG draft and mapping seems to be feasible. You might 
> want to consider renaming "desc" to "description", as (i) it 
> is the only abbreviated name and (ii) then all elements that 
> map nicely to ma elements would have the same names in both 
> vocabularies.
> 	The only element that is different is the agent 
> element, which not only includes creators and contributors, 
> but also fictional characters. While ttm lacks a way to 
> express the role in contribution, ma lacks a way to express 
> the character impersonated by an actor. Attempting to 
> harmonize this could improve both vocabularies.
> 	Best regards,
> 	Werner
> --------------------------------------------------------------------
> 	 Werner Bailer
> 	 Institute of Information Systems & Information Management
> 	 JOANNEUM RESEARCH Forschungsgesellschaft mbH
> 	 Steyrergasse 17, A-8010 Graz, AUSTRIA
> 	 phone:  +43-316-876-1218               mobile: 
> +43-699-1876-1218
> 	 web:    http://iis.joanneum.at            fax: +43-316-876-1191
> 	 e-mail: mailto:werner.bailer@joanneum.at
> --------------------------------------------------------------------
Received on Tuesday, 30 June 2009 11:19:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:24:36 UTC