W3C home > Mailing lists > Public > public-media-annotation@w3.org > December 2008

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

From: Felix Sasaki <fsasaki@w3.org>
Date: Sat, 20 Dec 2008 01:51:46 +0900
Message-ID: <494BD122.6010802@w3.org>
To: "Ruben Tous (UPC)" <rtous@ac.upc.edu>
CC: public-media-annotation@w3.org

Hi Ruben, all,

Is there any existing implementation which gets information from various 
metadata formats, and which uses such an OO-like approach? The 
implementations we looked at during the f2f (Chris from IBBT and Tobias) 
only returned one type. And XMP specifies only only one type for each 
property. Also, I have problems to understand how to implement the use 
case "web developer"
http://dev.w3.org/2008/video/mediaann/mediaont-req/mediaont-req.html#uc-access-via-web-client
with this level of complexity.

Felix

Ruben Tous (UPC) さんは書きました:
>
> Hi Pierre-Antoine, all,
>
> I adhere to this OO-like approach you propose. Using objects we could 
> wrap all the elements of our particular "value description model". 
> This way the one who calls the API function does not need to deal with 
> an extra grammar (e.g. DC-TEXT, DC-RDF, etc.).
>
> I specially like the "value description model" of Dublin Core (from 
> the DCAM's Description Set Model):
>
> (from http://dublincore.org/documents/dc-text/)
>
> (the return of our function will be the "value surrogate")
>
> "[...]
> - a value surrogate is either a literal value surrogate or a 
> non-literal value surrogate
>  - a literal value surrogate is made up of
>    - exactly one value string
>  - a non-literal value surrogate is made up of
>    - zero or one value URIs
>    - zero or one vocabulary encoding scheme URIs
>    - zero or more value strings
> - a value string is either a plain value string or a typed value string
>  - a plain value string may be associated with a value string language
>  - a typed value string is associated with a syntax encoding scheme URI
> - a non-literal value may be described by another description
> "
>
> If we were using Java it would be something like this:
>
> //abstract class Value
>
> //Class LiteralValue inherits from class Value
>  ValueString literalValueString
>
> //Class NonLiteralValue  inherits from class Value
>  String nonLiteralValueURI
>  String nonLiteralValueVocabularyEncodingSchemeURI
>  ValueString valueStrings [N]
>
> //Class ValueString
>  String string
>  String stringLanguage
>  String syntaxEncodingSchemeURI
>
> Best regards,
>
> Ruben
>
> ----- Original Message ----- From: "Pierre-Antoine Champin" 
> <pchampin@liris.cnrs.fr>
> To: "Felix Sasaki" <fsasaki@w3.org>
> Cc: "Tobias Bürger" <tobias.buerger@sti2.at>; 
> <public-media-annotation@w3.org>
> Sent: Friday, December 19, 2008 1:44 PM
> Subject: Re: [Mediann] Ad. "Return Type / String vs Uri" - Issue
>
>
>
> Felix Sasaki a écrit :
>>
>> Hi Tobias,
>>
>> I think this is a very good example on how to make a distinction between
>> "only string value" and "URI value" on the metadata level, and it would
>> be great to have it in a wiki page. However, IMO we are going to provide
>> an API which should provide access on a metamodel metadata level. Or to
>> put this into a question: If we have a method getSubject, should it 
>> return
>> 1) the complete DC-TEXT presentation
>> 2) the completet RDF/XML representation
>> 3) If the input is example 1: the URI. If yes, how does the API "know"
>> that it needs to do that?
>> 4) If the input is example 2: the string value. If yes, how does the API
>> "know" that it needs to do that?
>>
>> I think you are aiming for 3) and 4), but I'm not sure.
>
> a 5th option would be, as suggested at the last telecon, to return a
> JSON object with two attributes "uri" and "text". The burden on the
> developer would be low (append ".uri" or ".text" after the returned
> value), and the API would not have to "know" what is required.
>
>  pa
>
Received on Friday, 19 December 2008 16:52:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 19 December 2008 16:52:28 GMT