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: Pierre-Antoine Champin <pchampin@liris.cnrs.fr>
Date: Fri, 06 Feb 2009 14:54:00 +0000
Message-ID: <498C4F08.2040009@liris.cnrs.fr>
To: Yves Raimond <Yves.Raimond@bbc.co.uk>
CC: public-media-annotation@w3.org, public-media-fragment@w3.org

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).

Received on Friday, 6 February 2009 14:55:00 UTC

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