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

Hi. Pierre-Antoine.

Thanks for good proposal.
I think it's good approach. :)

Best regards,
Wonsuk

> -----Original Message-----
> From: public-media-annotation-request@w3.org [mailto:public-media-
> annotation-request@w3.org] On Behalf Of Pierre-Antoine
> Sent: Monday, November 23, 2009 9:29 PM
> 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 Tuesday, 24 November 2009 07:41:21 UTC