W3C home > Mailing lists > Public > public-media-annotation@w3.org > November 2008

Re: my token about the "3 or more layer" structure for the ontology

From: Pierre-Antoine Champin <swlists-040405@champin.net>
Date: Tue, 25 Nov 2008 10:49:28 +0000
Message-ID: <492BD838.3050508@champin.net>
To: Felix Sasaki <fsasaki@w3.org>, public-media-annotation@w3.org

Felix Sasaki a écrit :
> Hi Pierre-Antoine again (btw. ,do you mind to forward this to the
> mailing list?),

absolutely not! I just missed the "reply all" button in my last reply :-(
Sorry everybody... However, the last exchange with Felix in enclosed below.

> I think we don't disagree - we just stress different points.

It is also my opinion :)
And by the way, I am perfectly ok with the bottom-up approach, having
the conceptual model emerge from use cases, which is indeed a good way
of keeping it (the conceptual model) simple enough.

Thinking about it, I realized that external metadata is indeed an
important feature for me, hence my bias in favor of a specific format
for our ontology.

External metadata allows people to exchange it separately from the
(potentially copyrighted) video. It is indeed a key feature of the
Advene application (on which I am working), as well as popular social
applications focused on video (like youtube).

Wouldn't that deserve a use-case, by the way?

  pa

> 
> Pierre-Antoine Champin さんは書きました:
>> Felix,
>>
>> Felix Sasaki a écrit :
>>  
>>> Pierre-Antoine Champin さんは書きました:
>>>    
>>>> Hi Felix, thank you for your feedback.
>>>>
>>>> First, the term "data structure" was a bad choice. I should have
>>>> written
>>>> "conceptual model", which describes better what I am interested in. I
>>>> think once we agree on a conceptual model, we can chose the best syntax
>>>> to represent it -- if we want to...
>>>>
>>>> As a matter of fact, I took for granted that we would have to define
>>>> our
>>>> own format. But once again, the most important thing is the conceptual
>>>> model.
>>>>         
>>> I'm sorry, I have to disagree again. Take again a statement like
>>> "Mapping for getDate" from
>>> http://dev.w3.org/2008/video/mediaann/mediaont-api-1.0/mediaont-api-1.0.html#property-createDate
>>>
>>>
>>> "exif:DateTimeDigitized (based on [MWG Guidelines Image]). This is taken
>>> only into account if both xmp:createDate and exif:DateTimeOriginal are
>>> missing."
>>> I think this fulfils our task without a conceptual model: to provide
>>> interoperability between heterogenous metadata formats for video.
>>>     
>>
>> how do you (or the MWG Guidelines) end up with such a recommendation, if
>> not by building (even if only mentally) a conceptual model of the
>> metadata, beyond a simple attribute-value model?
>>   
> 
> You hit the point with "even mentally". I'm fine with a conceptual
> model. However, I am worried that we spend too much time thinking about
> a conceptual, without working on our main task of describing
> interoperability between properties of existing formats. IMO a
> conceptual model, more ore less explicit, will come naturally along if
> we concentrate on that task.
> 
> If we concentrate on the model we might end up with lots of abstraction
> layers, which are good for some use cases, but bad for others: I see us
> as a competitor to approaches like Blinx, see
> http://www.w3.org/2008/10/24-mediaann-minutes.html#item01
> who have just 5 categories for searching across *a lot* of videos.
> 
>> Take the rationale about dates, in the MWG Guidlines (p.16). It
>> introduces different *processes* in the lifetime of a digital image,
>> such as *photo taken*, *image digitized* and *file modified*. Only after
>> that can you discuss about the various date and argument that "date/time
>> original" should be prefered over the other ones.
>>   
> 
> A good example: the description is very specific to metadata fields
> specific to date / time, and does not argue with an overall conceptual
> model. I think you can end up with a section like that by looking into
> existing formats and their fields related to date / time, and
> classifying these fields. Again: I don't think we disagree, but put a
> different focus.
> 
> 
>> My point is that, since this effort is necessary, it is better to make
>> it explicit 
> 
> Agree if we make it explicit *after* analyzing properties, or if we at
> least start with the analysis, and not with thinking about the model.
> 
> 
>> -- even if only as prose, rather than emerging only through
>> its consequences in each property mapping.
> 
> I see "only throughits consequences in each property mapping" as a
> benefit. AFAIK the metadata WG deliverable was also written in such a
> "bottom-up" approach, and the conceptul model you see is a result or
> something emerging "on the way", and not the start of that work.
> 
>>  I see the following
>> advantages to this:
>>
>> - making the ontology/API easier to understand
>> - enabling implementors of the API to extend it in a consisten way
>>   - to properties that we would have considered out of scope
>>   - to format that we would not have considered
>>   
> 
> I agree with all these advantages.
> 
>>  
>>>> [example of "album title", "original album title"]
>>>>       
>>> Good example. My opinion is exaclty that mapping these properties to
>>> Dublin Core *does not* require finding these equivalences. From our
>>> charter:
>>> http://www.w3.org/2008/01/media-annotations-wg.html
>>> Success criteria: "Abilitity to convert core metadata information from
>>> one metadata standard to an other". This does not talk about
>>> roundtripping, so information loss  is OK.
>>> Out of scope: "Full coverage of all metadata elements in EXIF, IPTC,
>>> XMP, MPEG-7, and similar broad vocabularies, is out of scope".
>>> I interpret this as "it's OK to loose the structure of ID3 tags is lost
>>> in the mapping to ID3.".
>>>     
>>
>> Information loss is OK indeed, but we should be aware of the information
>> we are losing.
>>   
> 
> I agree.
> 
> Felix
> 
Received on Tuesday, 25 November 2008 10:50:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 25 November 2008 10:50:20 GMT