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/
>>
>>   
>