Re: mapping table 2.0

Joakim Söderberg a écrit :
> For me it doesn't matter if the Ontology is complex or not as long as
> the API is simple. But it is of course an advantage if the Ontology
> is also light weight as long as it can cope with requirement r07:
> "Introducing several abstraction levels in the ontology".

My concern is less about keeping the ontology simple than keeping it
*open*. Committing to a particular abstraction hierarchy may make it
(and hence the API) not suitable for some applications...

> Maybe "dc:source" is enough!

That is my first intuition, although exploring ID3 gave me some concern.

I alrdeady pointed out that ID3 implicitly defines some abstraction
layers above the digital media object, through, e.g. the different dates
(Tagged, Digitised, Release, Recording, Original Release). I intepret
that as distinguishing at least 3 levels:

A the digital media object
B the audio content
C the original audio content

(actually, in my toy implementation, I also decided to distinguish the
"recording" from the "performance"... but let's ignore that for the moment)

the relation between A and B is, I think, very different from the
relation between B and C. It seems reasonable for A to inherits
properties from B -- e.g. A.getCreator() not only returns the person who
encoded the file, but also the composer or lyricist (which are really
properties of B). The same does not between B and C. The performer of C
may not be the same as the performer of B. Here, property *changes*
through inheritence: C's TPE1 becomes B's TOPE (*original* performer).

I think the difference comes from the fact that A and B are instances of
different abstraction "levels"; their intrinsic properties are not the
same (A has an encoder but no composer, contrary to B). They ultimately
refer to the same "Work" (as defined by FRBR). On the other hand, B and
C are instances of the same abstraction "levels", but refer to
different, though related, "Works".

So may be we will have to define two different relations between related
resources ("vertical" vs. "transversal" ??), should it be only to
specify clearly when the API should provide inheritance, and when it
should not...

  pa


> 
> /joakim
> 
> 
> -----Original Message-----
> From: Eric Carlson [mailto:eric.carlson@apple.com] 
> Sent: den 23 februari 2009 16:38
> To: Pierre-Antoine Champin; Joakim Söderberg
> Cc: public-media-annotation@w3.org
> Subject: Re: mapping table 2.0
> 
> 
> On Feb 23, 2009, at 4:50 AM, Pierre-Antoine Champin wrote:
> 
>> I'm not sure designing "yet another" ontology of abstraction levels  
>> is a
>> good idea. Felix already pointed out that FRBR, for example, was not
>> entirely satisfactory to the BBC, and that they had to design their  
>> own
>> abstraction hierarchy.
>>
>> I would favor a minimalistic approach with a single and very general
>> property. For that matter, it seems to me that dc:source [1] is a good
>> candidate, and this is what I used in my toy implementation.
>>
>> More refined abstraction hierarchies could be defined by specializing
>> this property and introducing new classes, like the ones in FRBR or in
>> the BBC ontology, but I think committing to one or the other would  
>> only
>> limit the scope of our work.
>>
>    I agree whole-heartedly - the first version of this spec should  
> take as minimalistic an approach as possible.
> 
>    I believe a single abstraction layer will be quite powerful, and  
> additional complexity can be built on top of this in the next version  
> of the spec *if* it proves to be necessary as people use the first  
> version of the API.
> 
> Eric Carlson
> Rich Media Systems - Apple, Inc.
>

Received on Tuesday, 24 February 2009 11:09:36 UTC