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: Mon, 23 Nov 2009 09:40:05 +0100
Message-ID: <4B0A4A65.6060001@sti2.at>
To: Pierre-Antoine <pierre-antoine.champin@liris.cnrs.fr>
CC: "Evain, Jean-Pierre" <evain@ebu.ch>, "public-media-annotation@w3.org" <public-media-annotation@w3.org>
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 Monday, 23 November 2009 08:41:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 November 2009 08:41:51 GMT