Re: Proposal for ontology and api structure

Hi Felix,

comments inline....

Felix Sasaki schrieb:
> 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
>
In order to produce a scalable mapping approach we should imho come up
with something like a core vocabulary to which other vocabularies can be
mapped to. If we do not find anything intermediate to which all can be
mapped to we have to define something new. If we do not have a common
core, the number of mappings will become soon very large if you want to
match each possible vocabulary with each other.

But if I understood one of your comments below correctly. Our "core"
should be XMP.

>
>> 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).
If we define properties only as labels this seperation would probably
not be necessary. Agree.
>
> 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
>
The createDate for example would be a typical attribute as it will have
most probably an xsd:date - value
For all others this could depend on our model; for example if the rights
attribute refers to a cocept defined in a rights ontology then this
would be a relation. <Video1> dc:rights <Rights2>.
>
>> 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
>
Agree again. The methodology depends on what outcome we want to achieve
and which expressivity our ontology should have.
>
>> 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.
Yes. In the deliverable we should however clearly state the restrictions
of the scope of our ontology,  such as that we do not define a rights
vocabulary but rather refer to others, etc.
>
>>  (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
>
I guess it would be great if you could come up with a diagram (Entity
Relationship for example) that captures our domain aind that shows the
main concepts in our ontology and relations. To build this diagram could
be one task for the F2F meeting in Ghent. If we only stay at the level
of labels we would however end up with more relations than entities.
>
>> (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.
Yes. This serves as a good evaluation I guess.
>
>> (4) Documentation
>>   
>
> I hope that the W3C Recommendation we are developing will serve this
> purpose.
Think so, too.
>
> 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.
I also think that a very lightweight approach is appropriate if we stay
at the levels of labels as we then won't have any taxonomic relations or
even axioms. So we stay on the lower expressiveness spectrum with our
ontology (see cf. [5]).

[5] http://ksl.stanford.edu/people/dlm/etai/lassila-mcguinness-fbr-sw.html

Talk to you later,

Best

Tobias
>
> 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
>>>
>>>
>>>       
>>
>>   
>
>

-- 
_________________________________________________
Dipl.-Inf. Univ. Tobias Bürger

STI Innsbruck
University of Innsbruck, Austria
http://www.sti-innsbruck.at/

tobias.buerger@sti2.at
__________________________________________________

Received on Tuesday, 18 November 2008 10:30:55 UTC