Re: mapping table 2.0

Reading this discussion about abstraction layers, I think we should not 
say we allow or disallow "layers", but restrict ourselves to properties 
directly used in existing metadata. Hence, FRBR is out of scope, since 
it is not used directly for the media we are interested in. Hence, 
keeping the ontology open or not is also not a question: if we have 
properties which are actually used, we integrate them in the ontology, 
otherwise not. What people do "in private" with the ontology is out of 
scope for us.

That approach also answers the questions from Dave about mappings for ID3
http://lists.w3.org/Archives/Public/public-media-annotation/2009Feb/0087.html
taking Tobias contribution into account
http://lists.w3.org/Archives/Public/public-media-annotation/2009Feb/0088.html
but without introducing FRBR. Instead, we refer to the existing 
properties xmpDM:artist for 1), dc:creator for 2), and dc:creator for 3).

Felix

Pierre-Antoine Champin さんは書きました:
> 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:29:20 UTC