- From: Pierre-Antoine Champin <pchampin@liris.cnrs.fr>
- Date: Wed, 14 Jan 2009 12:19:51 +0000
- To: Felix Sasaki <fsasaki@w3.org>
- CC: Joakim Söderberg <joakim.soderberg@ericsson.com>, public-media-annotation@w3.org
Felix Sasaki a écrit : > I like the levels of granularity you describe DC > EXIF > XMP, but I'm > not sure if you need a specific format to achieve that. The granularity > description itself is enough to achieve the effect you want, see above > implementation. And a format would create the burden that it must be > implemented by tools who normally don't process Jason, e.g. browsers. Just a precision: JSON is a subset of javascript, to it is "naturally" understood by browsers, that is what makes it so popular. Now, it seems to me that the discussion is becoming: should we have a fine grain API returning only simple types (e.g. getDateGeneral vs. getPubDate), or a coarser grain API returning more complex data (as proposed by Joachim). An alterenative method would be to have an optional flags in each method to explicitly require structure data / specific data. E.g. getDate() -> "2008-01-13" // creationDate by default getDate(QUALIFIERS) -> [ "2008-01-13", "creationDate" ] getDate(QUALIFIERS|MULTIPLE)t -> [["2008-01-13","creationDate"],["2008-01-14", "publishDate"] ] getDate("publishDate") -> "2008-01-14" This is just an example, the actual parameters / result could be different, of course. That being said, does that example make sense ? pa > > Felix > > Joakim Söderberg さんは書きました: >> Hello, >> The way I see it, is that the definition of the data interchange >> format [1] is part of the API and therefore important. >> If we define a flexible format (like JSON) we could define type-value >> pairs or an array thereof which defines what you get (preferably in a >> simple way). It could solve the granularity problem i.e. "dc:rights >> vs. xmpDM:copyright" by informing what attribute is referred e.g. >> [Disney,dc:rights] [Walt Disney Company ,xmpDM:copyright]. >> We could define what a valid array should look like: >> [(value, attribute), (value, attribute),..., (value, attribute)] >> >> - and valid values for "value" and "attribute" in BNF for example. >> >> The ontology could then perhaps define the levels of granularity e.g. >> (from top to bottom) DC -> EXIF -> XMP being the order of the elements >> in the array, similar to the schema of preference defined by the >> Metadata Working Group. >> >> Just some thoughts to get the discussion going... >> /Joakim >> >> >> [1] http://www.w3.org/2008/WebVideo/Annotations/wiki/Dataformat >> >> >> > > >
Received on Wednesday, 14 January 2009 12:20:36 UTC