- From: Tobias Bürger <tobias.buerger@sti2.at>
- Date: Tue, 24 Nov 2009 07:02:59 +0100
- To: Pierre-Antoine <pierre-antoine.champin@liris.cnrs.fr>
- CC: "public-media-annotation@w3.org" <public-media-annotation@w3.org>
Thanks, PA for the explanation. Yes this now makes sense to me. Best regards, Tobias Pierre-Antoine wrote: > Tobias, > > conceptually, I am considering subproperties in the sense of RDF(S), > i.e. composer (e.g. in the sense of ID3) is a subproperty of ma:contributor. > > syntactically, I suggest indeed to attach this information to the return > value, so that users are free to use it or not. So > > md.getValues("contributor") > > would return like > > [ { "value": "John Doe", "subproperty": "id3:composer" }, > { "value": "Jane Doe", "subproperty": "id3:lyricist" }; > ] > > > In a sense, this amounts to use the following SPARQL query (on some > conceptual RDF graph, which may not be the way it is actually > implemented, don't get me wrong!) : > > SELECT ?value, ?subprop > WHERE { > the:media ?subprop ?value . > ?subprop rdfs:subPropertyOf ma:contributor . > } > > > I do not envision that the argument of our unique method could/should > accept a subproperty, e.g. > > md.getValues("id3:composer") > > because I think this would be make immplementation quite harder (maybe > too RDFish). I would prefer something like > > md.getValuesFilterSubproperty("composer", "id3:composer") > > But I'm ready to discuss the alternatives. > > pa > > > > Le 23/11/2009 09:40, Tobias Bürger a écrit : > >> Hi PA, all >> >> apologies for stepping in late in the discussion. >> >> If I understand your proposal correctly then you suggest not to define >> subproperties in the sense of RDF(S) which allow subclass-relationships >> among properties, but you suggest to define attributes for something >> which is in the range of a property such as a contributor. >> Do I understand this correctly? >> If yes, then we are not discussing subproperties but structured return >> values here (as we did in the early days of the working group). >> >> Thanks in advance for clarification. >> >> Best regards, >> >> Tobias >> >> Pierre-Antoine wrote: >> >>> Le 20/11/2009 10:16, Evain, Jean-Pierre a écrit : >>> >>> >>>> PA, >>>> >>>> do you mean a property/sub-property like title / (title) type? >>>> or contributor / role? without specifying what the type or role >>>> is but allow mapping to what is available from other descriptions. >>>> >>>> >>> Basically, yes, this is what I mean. >>> More precisely, I suggest that, e.g. >>> >>> md.get("contributor") >>> >>> would return a set of values. Those values would basically be text, >>> but would have an optional attribute (call it "role" or >>> "subproperty"...) indicating more precisely the kind of contributor >>> represented by the text. >>> >>> This optional attribute would represent additional semantics (w.r.t. the >>> general semantics of ma:contributor), provided by the underlying format. >>> At first, we can leave this field completely unspecified and let >>> implementators do whatever they see fit to fill it. Later on, we could >>> identify a set of standard values for these fields, to reflect notions >>> that are considered relevant enough, and present in one or several >>> underlying format. >>> >>> Again, try out to my implementation [1] (quite outdated regarding our >>> drafts, but this is not the point here) for an example of this idea. For >>> the moment, my implementation only provide the additional information if >>> you explicitly ask for "structured" value. The sub-property is carried >>> by the "property" field (quite ill-name, I agree ;)... >>> >>> My point is : we should decide now how to make this information >>> available in the interface (the "structured" flag is not necessarily the >>> good way to do it). This is a little extra work, granted, but it paves >>> the way for extensibility (even if we chose not to standardize this >>> extensibility -- de facto standard could as well emerge from this >>> feature). >>> >>> pa >>> >>> [1] http://champin.net/wsgi/mawg/ >>> >>> >>> > > > -- _________________________________________________ Dr. Tobias Bürger STI Innsbruck University of Innsbruck, Austria http://www.sti-innsbruck.at/ tobias.buerger@sti2.at __________________________________________________
Received on Tuesday, 24 November 2009 06:04:50 UTC