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

Re: data interchange format

From: Felix Sasaki <fsasaki@w3.org>
Date: Thu, 15 Jan 2009 18:35:17 +0900
Message-ID: <496F0355.9060808@w3.org>
To: Pierre-Antoine Champin <pchampin@liris.cnrs.fr>
CC: Joakim Söderberg <joakim.soderberg@ericsson.com>, public-media-annotation@w3.org

Pierre-Antoine Champin さんは書きました:
> 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.

You are absolutly right, my bad. Sorry for writing without thinking.

> 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
>   -> [ "2008-01-13", "creationDate" ]
>   -> [["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 ?

Makes all sense. To implement this I would replace "property=dateGeneral" in


with one of the function calls you describe above. From an 
implementation point of view the above and the function call are the 
same effort. What is more convinient from a users point of view, or for 
specific use cases?


>   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 Thursday, 15 January 2009 09:36:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:32 UTC