- From: Pierre-Antoine Champin <pchampin@liris.cnrs.fr>
- Date: Mon, 23 Feb 2009 12:07:44 +0000
- 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 UTC