W3C home > Mailing lists > Public > public-media-fragment@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:30:08 +0000
Message-ID: <82593ac00902060930u3686e9d9je78737428c904e9c@mail.gmail.com>
To: Felix Sasaki <fsasaki@w3.org>
Cc: Pierre-Antoine Champin <pchampin@liris.cnrs.fr>, public-media-annotation@w3.org, public-media-fragment@w3.org

On Fri, Feb 6, 2009 at 3:56 PM, Felix Sasaki <fsasaki@w3.org> wrote:
>
> Pierre-Antoine Champin さんは書きました:
>>
>> 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 think Yves made the point that FRBR does pose problems for videos, and he
> told me offline (I hope no secret) that the BCC is not using it, but their
> own abstraction scheme.

which is really, really, similar to FRBR Items and Manifestations (a
rdfs:subClassOf should happen, at some point). The only tricky thing
in a *video* context is the work and the expression, IMHO.

> So they sticking to FRBR for video? Of course, we
> can say we "promote" some aspects of FRBR also for video, but that is
> different than trying to accomodate the whole model.
>
> Felix
>
>
>
Received on Friday, 6 February 2009 17:30:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:32 GMT