- From: Felix Sasaki <fsasaki@w3.org>
- Date: Sat, 20 Dec 2008 01:51:46 +0900
- 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 UTC