- From: Felix Sasaki <fsasaki@w3.org>
- Date: Mon, 9 Feb 2009 11:53:23 +0900 (JST)
- To: "Yves Raimond" <yves.raimond@bbc.co.uk>
- 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). I think I said it before, and the charter of this working group http://www.w3.org/2008/01/media-annotations-wg.html says it too: our goal is to develop a simple lingua franca for existing formats. If we want to take FRBR as an input format into account, IMO there has to be existing applications which output FRBR. Otherwise we will end up in feature creep and a lot of "wouldn't it be nice?" discussions. Felix 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 Monday, 9 February 2009 02:54:01 UTC