W3C home > Mailing lists > Public > public-media-annotation@w3.org > February 2009

Re: Review of 'Use Cases and Requirements for Ontology and API for Media Object 1.0', Working Draft 19 January 2009

From: Yves Raimond <yves.raimond@bbc.co.uk>
Date: Fri, 6 Feb 2009 17:31:49 +0000
Message-ID: <82593ac00902060931y5a7744f7icd9a8c71a7992d87@mail.gmail.com>
To: Pierre-Antoine Champin <pchampin@liris.cnrs.fr>
Cc: public-media-annotation@w3.org, public-media-fragment@w3.org


On Fri, Feb 6, 2009 at 2:54 PM, Pierre-Antoine Champin
<pchampin@liris.cnrs.fr> wrote:
> Yves Raimond wrote :
>> Hello!
>>> Felix Sasaki wrote :
>>>> b) with several abtraction layers we face the challenge of loosing
>>>> simplicity for people who want to implement simple applications (...)
>>> It seems to me that a mean of hiding this complexity for people not
>>> interested in it would be that every *specific* object (e.g. frbr:Item
>>> or bbc:Broadcast) inherits, in the API, the properties of the more
>>> abstracts elements (resp. frbr:Manifestation, bbc:Episode).
>>> So I can ask for the ISBN of an book Item (though this is strictly
>>> speaking a property of the Manifestation), or to which Series a
>>> Broadcast belongs (though this is actually the Episode that belongs to a
>>> Series).
>>> Yves, does that make sense? Do the implementation you are aware of
>>> provide this kind of inheriance/proxy mechanism?
>> Hmm. I never saw that done anywhere. I think one of the reason may be
>> that the relationships between different abstraction layers can be
>> something else than a strict hierarchy. For example, a Manifestation (a
>> recording) can come from several Expressions (several performances),
>> etc. So such an inheritance rule is actually quite hard to define.
> That's a good one.
> I don't think we had mentionned that case yet :)
>> Also, it tends to be quite unclean. Properties of a performance (date,
>> place, performers, instruments, etc.) are not properties of an mp3 file.
> I agree.
> Add to this that if a property is declared inverse-functional, i.e. an
> *identifying* property, inheriting it could raise some problem.
> E.g.: ISBN is identifying the Manifestation, not the Item.
>> I think it is highly desirable to have a schema as normalised as
>> possible in your backend, and maybe collapse it in the UI side if it
>> does bring benefit to the end-user.
> May be I wasn't clear enough: a normalised schema was indeed what I had
> in mind. My suggestion was only regarding (some level of) the API, so
> that developers do not need to understand all the subtleties of the
> ontology to use the API.
> Anyway, we will have to do this at some point, because legacy metadata
> have the bad habit of flattening those abstraction levels. So it might
> appear that all we have is a set of properties attached to the Item,
> some of them applying in fact to the Manifestation or Expression, but
> without any mean to know exactly which (think of dcterms:Contributor).

I completely agree :-) Flat schemas are harmful, as they lead to
information loss (admitting you have more detailed information in the
first place, of course :-) ).


>  pa
Received on Friday, 6 February 2009 17:32:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:33 UTC