- From: Yves Raimond <yves.raimond@bbc.co.uk>
- Date: Fri, 6 Feb 2009 17:30:08 +0000
- 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 UTC