Re: Review of 'Use Cases and Requirements for Ontology and API for Media Object 1.0', Working Draft 19 January 2009

Hello Michael,

many thanks for the follow up! Some replies below.

Michael Hausenblas wrote:
> Felix,
>
> Most of the stuff seems sorted, thanks. Remaining points inline:
>
>   
>> I think that the paragraph
>> "An important aspect of the above figure is that everything visualized
>> above the API is left to applications, like: languages for simple or
>> complex queries, analysis of user preferences (like "preferring movies
>> with actor X and suitable for children"), or other mechanisms for
>> accessing metadata. The ontology and the API provide merely a basic,
>> simple means of interoperability for such applications."
>> Tries to answer some of your questions.
>>     
>
> Some, yes ;)
>
> Seriously, I *think* it would be good to have the ontology as the primary
> model and derive the API from it (automagically?) if possible. I must admit
> that I still didn't entirely grok how these two things play together. Assume
> for a second that I'm a total noob - how'd you explain that in some simple
> language?
>   

The ontology describes relations between properties in existing formats.
As an example of the relation description see the table at
http://dev.w3.org/cvsweb/~checkout~/2008/video/mediaann/mediaont-1.0/mapping_table_common.xls?rev=1.3&content-type=text/plain
This table (and our working group) has put XMP into the focus, see
leftmost column. That means that all other formats are related to XMP as
much as possible.

The ontology which we will produce may be
1) just this table, in a more readable and verified version, "verified"
meaning: checking with users and implementers of the format and XMP
specialists whether our description of the relations is appropriate
2) an ontology using a formal language like RDF, or an RDF-based
vocabulary (like SKOS), an XML-based format with an addition formal
semantics, some other language etc.

Currently we have no consensus in the Working Group whether we should do
only 1), only 2), both 1) and 2) and make 2) the normative version, both
1) and 2) and make 1) the normative version, etc. This is especially my
fault ;) , since I have the use case of a client-side API, e.g.
JavaScript in a browser, in mind, which implements the mappings between
formats. Such an API can be built easily *by hand*, that is by reading
the prose in the table from 1), but IMO it cannot be expected that such
an API would process RDF or another formal language. Or to put it
differently: we have different user communities with different usage
scenarios for the ontology in mind, and it is hard to find a middle
ground. The automatic derivation of the API sounds interesting in
theory, but I have a hard to imagine it in practice.

>   
>>> + Regarding '6.7 Requirement r07: Introducing several abstraction levels in
>>> the ontology' I'd say this is an absolute must.
>>>       
>> Do you have any existing implemention we could look at to be able to
>> judge the efforts of this?
>>     
>
> Well, yes, I guess so, see [1] and [2]; its from the audio domain and the
> chap behind it, Yves Raimond, is lurking here around as well, so he may be
> able to chip in ;)
>   

It would be great to get more information about this. I have a hard time
to grasp the abstraction layers, and to understand how one can make use
of them in [2]. Some explanation would be really helpful.

> Mostly I'd recommend to focus on FRBR [3], but I guess the real expert is
> actually Yves. Ah, I'll CC him and see what happens ...
>  
>   
>>> + the TOC is not well-formatted, although pubrule-checker [2] seems not to
>>> complain - rather use use <ol> and <li>
>>>   
>>>       
>> mm ... I checked
>> http://validator.w3.org/check?uri=http://www.w3.org/TR/2009/WD-media-annot-req
>> s-20090119/
>> and did not see any problems. Could you point me to the markup part
>> which you think has a problem?
>>     
>
> Well, true. As I said. It's perfectly *valid*, it's about the markup you are
> using (list rather <p> + <br/>) ...
>   

ah, now I understand. Many thanks for checking, we will fix that for the
next publication.

>   
>> I did not see any comments on the requirements which I think are the
>> most important "message" of the WD. Do you think these need a revision
>> or are stable? 
>>     
>
> Seems pretty stable, beside my comments ;)
>   

Thanks. So let me phrase this as a question: except that you regard r07
as important ("several abstraction layers"), do you or somebody else
from the Media Fragments Working Group think there are other
requirements we should take into account? Could you reply with "no" on
behalf of your Working Group?

It would also be great to get feedback from you about our conversation:

[
> If you can't talk about the
> different abstraction layers, I guess the effort is pretty worthless.
>
At the TPAC meeting in October we had a presentation from a video search
engine with not more than *five*, "flat" properties, see
http://www.w3.org/2008/10/24-mediaann-minutes.html#item01
I think we saw a metadata mapping which was very useful and worth it, so
I would disagree with your statement above.
]

that is, your feedback about the example of a simple approach I
mentioned. Although you stated that without different abstraction layers
you regard the effort as worthless, there seem to be even rather large
applications which work without abstraction layers.

Regards,

Felix

> Cheers,
>       Michael
>
> [1] 
> http://wiki.musicontology.com/index.php/Structural_annotations_of_%22Can%27t
> _buy_me_love%22_by_the_Beatles
> [2] http://dbtune.org/henry/
> [3] http://www.loc.gov/cds/downloads/FRBR.PDF
>
>

Received on Thursday, 5 February 2009 01:43:43 UTC