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

Re: data interchange format

From: Pierre-Antoine Champin <pchampin@liris.cnrs.fr>
Date: Thu, 15 Jan 2009 12:03:32 +0000
Message-ID: <496F2614.5060104@liris.cnrs.fr>
To: Felix Sasaki <fsasaki@w3.org>
CC: public-media-annotation@w3.org

Felix Sasaki a écrit :
>> 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.

It happens even to the best ones :)

>> 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" ]
>>   -> [["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
> inputURI=http%3A%2F%2Fgdata.youtube.com%2Ffeeds%2Fbase%2Fvideos%2F-%2FExperte%3Fclient%3Dytapi-youtube-browse%26v%3D2&property=dateGeneral
> 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?

I was more thinking in a "programming language" style, than in a "HTTP"
style... If I was to translate my ideas to "HTTP" style, I would say
that I would replace

  property=dateGeneral / property=pubDate


  property=date / property=date&subproperty=pubDate

* the legal values for "property" would be properties from our ontology
* the legal values for "subproperty" would be open for extensibility,
  (while retaining the core semantics of the "property" used)
  (of course, the REC could define/recommand a set of core
   subproperties, especially for interoperability with existing

More systematically, I would propose the following equivalences

<=> (some_url)...&property=date
  -> "2008-01-13" // creationDate by default

<=> (some_url)...&property=date&structured=yes
  -> [ "2008-01-13", "creationDate" ]

<=> (some_url)...&property=date&structured=yes&subproperty=ALL
  -> [["2008-01-13","creationDate"],["2008-01-14", "publishDate"] ]

<=> (some_url)...&property=date&subproperty=publishDate
  -> "2008-01-14"

Open question:
with such an API, should
be accepted as a shortcut to

(this would require the service to recognize that publishDate is a
subproperty of "date", so this would only be possible -- or at least
practical -- for standard subproperties)

Received on Thursday, 15 January 2009 12:04:15 UTC

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