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

Hello!

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

Yves

>  pa
>
>

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