- 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