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

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. 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 15:57:33 UTC