Re: [Fwd: Re: [Mediann] Ad. "Return Type / String vs Uri" - Issue]

Hello Werner,

Bailer, Werner さんは書きました:
> Dear Felix, all, 
>
>   
>> two points: first, Jason is just one serialization - as is 
>> XML, RDF or anything else. 
>> [...]
>>     
>
> Yes, in our case the serialization question is related to the API design. One question is whether we support more than one representation in the model and the other is how the API can be used to access this value.
>   

Exactly. I think we should discuss first discuss whether we want to 
support more than one representation, and later details how the API 
should implement the outcome of the discussion.

>  
>   
>> My second point is that this discussion is "top down", that is: we 
>> discuss whether we want a feature or not without looking into the 
>> behavior of existing implementations of metamodels for 
>> metadata (using the terminology from Chris here), and without looking into 
>> what existing formats do.
>>     
>
> The formats typically specify the data model and a serialization, but there could still be several ways of implementing access to these properties. For example, MPEG-7 ControlledTermUseType allows to put a string in the content of an XML element and a URI into an attribute of the element. Using XML-related ways to access the data (e.g. XPath, DOM) one would either access the content or the attribute of that element. However, an OO API might define an object that contains the string and the URI as return type, or two methods getXXXAsString and getXXXAsURI. In my opinion this is really a design decision for the API and not really related to the underlying data model.
>   

I'm sorry, but I'm still missing an example of a metamodel for metadata: 
could you or somebody else give me an (API implementation and underlying 
model) example which works *across* (that is, not within MPEG-7) format 
a, b, c and provides different return types?

>   
>> For mappinges: The page
>> http://www.w3.org/2008/WebVideo/Annotations/wiki/Format_mapping
>> is still empty. One approach to continue this discussion 
>> which I propose 
>> is to do it "bottom up" by filling the page and describe what 
>> existing 
>> formats do about types of properties. 
>>     
>
> In that case we would also need to collect the different datatypes supported for a property in the different formats. 

Yes, we have to do that. See e.g. the very detailed discussion on time 
zone handling (p. 31).



> However, I expect that in those cases where there are different types it will often be string and URI or string and some numeric type. 

See the above for a counter example.


> It will be helpful for defining and implementing the mappings, but I'm not sure that it will help us in the return type question for the API.
>   

My point is that our main work item is to define the mappings - and I'm 
trying to find a way which allows us to start work on that (which we 
need to do rather sooner than later IMO), and having also a means to 
evaluate the importance of the "return type" discussion based on 
existing implementations.

Felix

> Best regards,
> Werner
>
>
>
>   
>> --------------------------------------------------------------
>> ----------
>>     
>>> Subject:
>>> Re: [Mediann] Ad. "Return Type / String vs Uri" - Issue
>>> From:
>>> Tobias Bürger <tobias.buerger@sti2.at>
>>> Date:
>>> Tue, 23 Dec 2008 12:45:30 +0100
>>> To:
>>> Joakim Söderberg <joakim.soderberg@ericsson.com>
>>>
>>> To:
>>> Joakim Söderberg <joakim.soderberg@ericsson.com>
>>>
>>>
>>> Hi Joakim,
>>>
>>> thanks for the assembling of the page!
>>> Comments below
>>>
>>> Joakim Söderberg schrieb:
>>>   
>>>       
>>>> Hi all,
>>>> In order to facilitate the discussion on data interchange 
>>>>         
>> format, I have assembled the options on a wiki page:
>>     
>>>> http://www.w3.org/2008/WebVideo/Annotations/wiki/Dataformat
>>>>
>>>> Personally I like the idea of JSONs collection of name/value pairs.
>>>> Some thoughts are:
>>>> 1) Can we have two levels of complexity e.g. simple 
>>>>         
>> (string) and complex (e.g. collection of name/Value pairs) 
>> depending on property or application?
>>     
>>>>   
>>>>     
>>>>         
>>> If we want to have it we can implement it I guess. Please 
>>>       
>> have a look at
>>     
>>> how RDF can be represented using JSON [1]:
>>>
>>>  "http://example.org/about" : {
>>>         "http://purl.org/dc/elements/1.1/creator" : [ { 
>>>       
>> "value" : "Anna
>>     
>>> Wilder", "type" : "literal" } ],
>>>         "http://purl.org/dc/elements/1.1/title"   : [ { "value" :
>>> "Anna's Homepage", "type" : "literal", "lang" : "en" } ] ,
>>>         "http://xmlns.com/foaf/0.1/maker"         : [ { "value" :
>>> "_:person", "type" : "bnode" } ]
>>>     } ,
>>>
>>> "_:person" : {
>>>         "http://xmlns.com/foaf/0.1/homepage"      : [ { "value" :
>>> "http://example.org/about", "type" : "uri" } ] ,
>>>         "http://xmlns.com/foaf/0.1/made"          : [ { "value" :
>>> "http://example.org/about", "type" : "uri" } ] ,
>>>         "http://xmlns.com/foaf/0.1/name"          : [ { 
>>>       
>> "value" : "Anna
>>     
>>> Wilder", "type" : "literal" } ] ,
>>>         "http://xmlns.com/foaf/0.1/firstName"     : [ { "value" :
>>> "Anna", "type" : "literal" } ] ,
>>>         "http://xmlns.com/foaf/0.1/surname"       : [ { "value" :
>>> "Wilder", "type" : "literal" } ] ,
>>>         "http://xmlns.com/foaf/0.1/depiction"     : [ { "value" :
>>> "http://example.org/pic.jpg", "type" : "uri" } ] ,
>>>         "http://xmlns.com/foaf/0.1/nick"          : [
>>>                                                       { "type" :
>>> "literal", "value" : "wildling"} ,
>>>                                                       { "type" :
>>> "literal", "value" : "wilda" }
>>>                                                     ] ,
>>>         "http://xmlns.com/foaf/0.1/mbox_sha1sum"  : [ {  "value" :
>>> "69e31bbcf58d432950127593e292a55975bc66fd", "type" : "literal" } ]
>>>     }
>>>
>>>
>>> Here a resource @ http://example.org/about is described. 
>>>       
>> For the creator
>>     
>>> they return a literal and for the maker a person object with more
>>> properties attached (so a complex object so to speak). So 
>>>       
>> this is a way
>>     
>>> we could implement it.
>>>
>>> If we want to have a property which has two different 
>>>       
>> return types than
>>     
>>> we could subclass this property, e.g. hasMetadataValue is the
>>> SuperProperty (with no specified range) with two sub-properties
>>> hasMetadataValueLiteral (range: Literal) and hasMetadataValueComplex
>>> (range: class representing some "complex" objects).
>>>
>>> This approach is valid in RDF(S), OWL Lite and OWL DL.
>>>
>>>   
>>>       
>>>> 2) How does the application know what is returned?
>>>>   
>>>>     
>>>>         
>>> The application would have to see for which sub property a value is
>>> returned to determine if she gets a literal or a complex object.
>>>
>>> Just one idea....
>>>
>>> Best,
>>>
>>> Tobias
>>>   
>>>       
>>>> /J
>>>>
>>>>   
>>>>     
>>>>         
>>> [1] http://n2.talis.com/wiki/RDF_JSON_Specification
>>>
>>>   
>>>       
>>
>>
>>     

Received on Tuesday, 23 December 2008 12:58:34 UTC