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

Re: mapping table 2.0

From: Pierre-Antoine Champin <pchampin@liris.cnrs.fr>
Date: Mon, 23 Feb 2009 12:07:44 +0000
Message-ID: <49A29190.5080507@liris.cnrs.fr>
To: Tobias Bürger <tobias.buerger@sti2.at>
CC: Joakim Söderberg <joakim.soderberg@ericsson.com>, David Singer <singer@apple.com>, public-media-annotation@w3.org
Tobias Bürger a écrit :
> Would be good to get feedback from Pierra-Antoine. Perhaps he can answer
> to the mail I sent in reply to David this morning?

sorry about my late answer, I was in vacation.

Disclaimer: I volunteered to have a close look at ID3, mainly because I
had to do it anyway when writing a toy implementation. However, I do not
consider myself as an ID3 expert... I just read the spec as carefully as
I could...

>> 1) Should xmpDM:artist (and QuickTime İart) map to ID3 TPE2?
>>
>>         4.2.1   TPE2    [#TPE2 Band/orchestra/accompaniment]

I'd say so, the term "artist" in XMP seems to map fairly to the notion
of "performer" in ID3 (as opposed, in both specs, to "composer", for
example).

>> 2) Should dc:creator (QuickTime İaut) map to TEXT?
>>
>>      4.2.1   TEXT    [#TEXT Lyricist/Text writer]

Seems good to me. The dublin core defines a creators as an entities
"primarily responsible for making the resource" [1], while XMP define
them as the "authors of the resource" [2].

>> 3) Are we missing a line for ID3 TENC (and matching QT Tag İenc)?
>>
>>         4.2.1   TENC    [#TENC Encoded by]

"Encoded by" in ID3 is intended for "the person or organisation that
encoded the audio file" [3], so it seems like a creator as well.

A problem here is that this ID3 frame may also contain a copyright
message... (applying to the file, not the content). So the mapping here
involves some processing of the *value* of the frame, which is not
trivial...

>> 4) Does dc:date (İday) map to TDAT or TDRL?
>>
>>         4.2.1   TDAT    [#TDAT Date]
>>
>>         4.2.5   TDRL Release time (note that this is version 2.4)

both.
According to the dublin core specs, dc:date is "a point or period of
time associated with an event in the lifecycle of the resource." [1]
According to XMP, "date(s) that something interesting happened to the
resource.".


As pointed out by Tobias, we face the problem of levels of abstraction
here. Many metadata schemes *implicitly* define several levels of
abstraction. Take the example of ID3 v2.4, and consider the different
dates that it defines:

  TDTG Tagging time
  TDEN Encoding time
  TDRL Release time
  TDRC Recording time
  TDOR Original release time

The first two are about the digital audio file, the next two are about
the audio content.

The last one is very interesting: it is about *another* audio content,
from which the audio content at hand is supposed to be derived,
typically as a cover. The fact that it may have a different lyricist
(there is an "original lyricist" frame) but the same composer (there is
no "original composer" frame) dictates the kind of "derivation" that are
relevant here, but only implicitly.


This shows, in my (biased ;) opinion, that even "flat looking" metadata
scheme involve several layers of abstraction, and so that our ontology
must take this into account, preferably in an explicit way.

  pa


[1] http://dublincore.org/documents/dcmi-terms/
[2] http://www.adobe.com/devnet/xmp/pdfs/XMPSpecificationPart2.pdf
[3] http://www.id3.org/id3v2.4.0-frames
Received on Monday, 23 February 2009 12:08:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 February 2009 12:08:33 GMT