Re: Proposal for ontology and api structure

Hi Tobias,

many thanks for these comments!

Tobias Bürger さんは書きました:
> Dear Felix,
>
> thanks for the intial draft!
>
> I have some comments, questions, and pointers...
>
> From the abstract one could infer that the ontology is only a
> description of relations. 

That's currently the case, yes.

> I thought that the ontology should reflect a
> core vocabulary which then is mapped to existing formats, or am I wrong?
>   

I think that is the case, but with a semantically very "thin" core 
vocabulary, focusing on interoperability between existing vocabularies, 
see below.

> I am however fine with the statement that we will only refer to existing
> properties instead of creation new ones.
>   

This is indeed a crucial point: should we define new properties or focus 
on interoperabilty between existing ones? I am (currently) very biased 
by the metadata WG deliverable, which aims at the latter target. In such 
a scenario, a property is just a name (a "label") with an informal 
description. Like at
http://dev.w3.org/2008/video/mediaann/mediaont-api-1.0/mediaont-api-1.0.html#property-createDate

> For section 2.1: Perhaps we could seperate properties into relations and
> attributes. Relations reflect properties which refer to other resources,
> attributes to a datatype value.
>   

If we define properties only as names ("labels"), such a separation 
would probably not be necessary - what do you think?. That's a choice we 
have to make, related to the outcome we want to achieve and the 
methodology (see below).

Could you give an example on how such a separation would look like for 
the existing properties at
http://dev.w3.org/2008/video/mediaann/mediaont-api-1.0/mediaont-api-1.0.html#property-definition

> Regarding the general structure of the ontology deliverable and how we
> want to build the ontology: I wonder if we want to adopt one of the
> existing ontology engineering methodologies?
>   

Many thanks for the pointers! I have used [2] for teaching and ontology 
development myself a few years ago. I did not use it here on purpose, 
since again I am biased by the metadata WG approach of a simply listing 
of properties. Again I think the choice of our methodology depends on 
what outcome we want to achieve, and for which community it should be 
useful. This relates also to the issue "annotation structured or 
simple", see http://www.w3.org/Bugs/Public/show_bug.cgi?id=6169
and to the "URIs as values" thread, I think.
http://lists.w3.org/Archives/Public/public-media-annotation/2008Nov/0057.html

> There is plenty of material available on this:
>
> One of the basic methdologies is presented in [1]
>
> The methodology consists of: (1) Identify purpose and scope

With the decision to have XMP as a starting point I think we could say 
"this is done". The purpose would be to go through XMP, see what 
properties are important to be used as simple properties "labels", and 
then describe the interoperabilty to similar properties in other formats.

>  (2) Build
> the ontology (Domain capture, coding, integrate existing ontologies),
>   

I was trying "build the ontology" with
http://dev.w3.org/2008/video/mediaann/mediaont-api-1.0/mediaont-api-1.0.html#property-definition
and the relation to existing formats with mappings like at
http://dev.w3.org/2008/video/mediaann/mediaont-api-1.0/mediaont-api-1.0.html#property-createDate

> (3) Evaluation, 

Our charter says that we should create a "Collection of a corpus of 
metadata to demonstrate the mapping and translation.". I think that 
could serve the evalutation purpose.

> (4) Documentation
>   

I hope that the W3C Recommendation we are developing will serve this 
purpose.

This are just my thoughts, as I said biased on the metadata WG approach. 
Also I am focused on the scenario which Philippe presented briefly at 
the TPAC meeting: a JavaScript implementation with methods like 
"getCreateDate". For this use case the current, deliberately very light 
wheight knowledge engineering approach seems sufficient to me. But I am 
looking forward for your comments.

Felix

> Another one which is often used and simple is presented in [2].
>
> More detailed methodologies include METHONTOLOGY, DILIGENT and others.
> Most methodologies are listed in [3].
>
> Regarding how to document our ontology: I found the presentation of the
> enterprise ontology in [4] very good but this could also be too detailed
> for our case.
>
> Just some pointers from the ontology engineering community. Perhaps some
> are useful.
>
> Talk to you later!
>
> Best regards,
>
> Tobias
>
> [1] Mike Uschold, Mike Uschold, Michael Gruninger, Michael
> Gruninger``Mike Uschold, Mike Uschold, Michael Gruninger, Michael
> Gruninger'' Knowledge Engineering Review Vol 11. p. 93---136 (1996)
> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.5917
>
> [2] Natalya F. Noy  and  Deborah L. McGuinness. ``Ontology Development
> 101: A Guide to Creating Your First Ontology''. Stanford Knowledge
> Systems Laboratory Technical Report KSL-01-05 and Stanford Medical
> Informatics Technical Report SMI-2001-0880, March 2001.
> http://ksl.stanford.edu/people/dlm/papers/ontology101/ontology101-noy-mcguinness.html
>
> [3] http://semanticweb.org/wiki/Ontology_Engineering
>
> [4] Mike Uschold, Martin King, Stuart Moralee and Yannis Zorgios (1998)
> The Enterprise Ontology The Knowledge Engineering Review , Vol. 13,
> Special Issue on Putting Ontologies to Use. Available online:
> http://www.aiai.ed.ac.uk/project/pub/documents/1998/98-ker-ent-ontology.ps
>
>
>
> Felix Sasaki schrieb:
>   
>> Hi all,
>>
>> I have created a proposal for the structure of the ontology and the API. See
>> http://dev.w3.org/cvsweb/~checkout~/2008/video/mediaann/mediaont-api-1.0/mediaont-api-1.0.html?rev=1.9
>>
>> It would be great to get your feedback on these via mail and / or during
>> the next call (agenda to be provided). Some notes before:
>>
>> - This is only a proposal for the general structure of ontologoy and the
>> API, nothing put in stone, and not a lot of material.
>>
>> - Ontology and API are currently in one draft. The reason is that I
>> think we have agreement that there should be a close alignment between
>> the two, and having one document was an easy way to achieve this.
>>
>> - For the timeline, I mainly would like to discuss this before and at
>> the f2f in Belgium, especially since Raphael is on holiday until then
>> and I know that he already has worked on an ontology, which I think we
>> definitely should take into account.
>>
>> - You might be surprised that the above draft does not contain any
>> formal definition in RDF or a different format. That is on purpose: from
>> the viewpoint of the API, it is sufficient to have for each property a
>> name, an informal description of mappings to existing formats, and the
>> related API methods. The draft contains an example for the createDate
>> property. For other use cases than the API, we might need a more formal
>> description, but I have put the informal one in the center here to see
>> if in that way we can gather the attention of the browser vendor community.
>>
>> - While writing this draft I have not taken the discussion off XMP,
>> transmission.cc or comments on the use cases & requirements document
>> into account. Again this is on purpose, to be able to focus on the API
>> use case - for the time being.
>>
>> Looking forward for your feedback.
>>
>> Regards, Felix
>>
>>
>>   
>>     
>
>

Received on Tuesday, 18 November 2008 06:57:20 UTC