Re: data interchange format

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
> 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 ?
>   

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?

Felix

>   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