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

I can see how to do this extracting the appropriate information from xml schema structured data like TVA, EBUCore and IPTC but this will demand quite some work and logic at the API level.

Jean-pierre

-----Original Message-----
From: Pierre-Antoine [mailto:pierre-antoine.champin@liris.cnrs.fr] 
Sent: lundi, 23. novembre 2009 13:29
To: Tobias Bürger
Cc: Evain, Jean-Pierre; public-media-annotation@w3.org
Subject: Re: RE : [mawg] RE: [q] MAWG: Definition of subproperties

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/

>>
>>   
>

Received on Monday, 23 November 2009 13:00:05 UTC