W3C home > Mailing lists > Public > public-media-annotation@w3.org > November 2009

Re: RE : [mawg] RE: [q] MAWG: Definition of subproperties

From: Tobias Bürger <tobias.buerger@sti2.at>
Date: Tue, 24 Nov 2009 07:02:59 +0100
Message-ID: <4B0B7713.3000409@sti2.at>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 24 November 2009 06:04:50 GMT