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

2009/11/20 Evain, Jean-Pierre <evain@ebu.ch>

> It looks like what I suggested during the F2F.  So a priori yes for me.
>

For me too.

Best,

Felix


>
> JP
>
> ________________________________________
> De : Pierre-Antoine [pierre-antoine.champin@liris.cnrs.fr]
> Date d'envoi : vendredi, 20. novembre 2009 14:11
> À : Evain, Jean-Pierre
> Cc : public-media-annotation@w3.org
> Objet : RE : [mawg] RE: [q] MAWG: Definition of subproperties
>
> 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 recisely, 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/
>