W3C home > Mailing lists > Public > public-swbp-wg@w3.org > January to March 2004

RE: [ALL] Human-friendly syntax for communicating OWL fragments

From: Uschold, Michael F <michael.f.uschold@boeing.com>
Date: Tue, 30 Mar 2004 20:09:28 -0800
Message-ID: <823043AB1B52784D97754D186877B6CF04894ECC@xch-nw-12.nw.nos.boeing.com>
To: <public-swbp-wg@w3.org>

I propose that by convention all OWL fragments are given using the reader-friendly abstract syntax, rather than the parser-friendly XML syntax.  Personaly, I cannot read OWL fragments well enough to be motivated to ever understand the details, so I tend to skip over them.  Even when I can get motivated, it takes way too much time.

I would argue very strongly that any public documents published by this WG  do use the more readable syntax. Why not get used to it when we communicate with each other? It will also make it easier to grab things from discussions in the archive and plunk them into documents, instead of having to translate into the abstract syntax suitable for the public.

Of course, if the discussion is about parsing, or about the syntax of the language, then it is better to use the parser-friendly syntax, both for internal discussions and for publised documents.

What do people think about this suggestion?

If the overwhelming majority of this WG actually PREFER to read the parser-friendly syntax, then perhaps I'd best get used to it, but it there are many like me, it makes sense to use a more reader-friendly syntax.

Mike


 -----Original Message-----
From: 	public-swbp-wg-request@w3.org [mailto:public-swbp-wg-request@w3.org]  On Behalf Of Guus Schreiber
Sent:	Friday, March 26, 2004 9:00 AM
To:	public-swbp-wg@w3.org
Cc:	Natasha Noy; Bernard Vatant
Subject:	RE: [OPEN] and/or [PORT] : a practical question


> From: Natasha Noy <noy@SMI.Stanford.EDU>
> Date: Wed, 24 Mar 2004 10:26:00 -0800
> To: "Bernard Vatant" <bernard.vatant@mondeca.com>
> Cc: SWBPD <public-swbp-wg@w3.org>
> 
> 
>>Are there other concrete experience on that, not only theoretical 
>>considerations? Seems
>>like there are not so many people exploring the terminology-ontology 
>>interoperability. Or
>>are they?
> 
> I am not sure if Bernard's concern is only about subject hierarchies 
> or about mixing ontologies and terminologies in general. If it is the 
> former, than the message below is not very relevant. For the latter, 
> here are a few words from the experience in a number of 
> medical-informatics projects in our lab. In our experience, the issue 
> of linking ontologies and terminologies comes up often. There is no 
> lack of (often reasonably well-structured) controlled terminologies 
> in medical informatics, using them makes sense both from reusability 
> and interoperability perspectives. However, in our projects and their 
> ontologies, it inevitably led to mixing classes and instances, and we 
> really didn't find any practical workarounds (although admittedly we 
> were not wedded to DLs, so didn't look too hard).
> 
> Consider for example clinical guidelines (again, this is a practical 
> example from a couple of kb-based systems here). A specific clinical 
> guideline (an instance of a class Clinical Guideline) represents the 
> tests, decisions, etc. in diagnosing and treating a particular 
> ailment. One of the reference terminologies used here is that of 
> drugs. (cf Chris's message later: a drug hierarchy is not a 
> partonomy, it is indeed a subclass hieararchy. You have 
> beta-clockers, and specific types of beta-blockers as subclasses, 
> etc.). So, a specific instance of a clinical guideline must refer to 
> classes of drugs to be prescribed. Again, at a particular step in a 
> guideline you want to prescribe a specific beta-blocker. But you want 
> this guideline to be retrieved when looking for all guidelines using 
> beta-blockers. Note, the guideline really refers to a class of drugs 
> and not a specific bottle with pills.

We have had exactly the same experience in using thesauri for annotating 
art  collections. For example, the value for the "style" property of a 
painting is taken by us from the AAT (Art and Architecture Thesaurus) 
hierarchy of styles and periods. Even for seemingly simple attributes 
like "color" we have found this feature: we cannot treat the color value 
as a simple instance from a flat value space, as color subtleties can be 
key issues in art objects (e.g. porcelain) and the thesauri, like AAT, 
thus contain elaborate color hierarchies (e.g. vivid-pink subClassOf pink).

[Note: some parts of the style/period hierarchy are in fact based on 
parts (periods). An important practical point however is: these thesauri 
are out there and they represent community consensus. Are we going to 
discard them because they model the world in the "wrong" way?]

Interestingly enough, we have also encountered some problems with 
putting classes as values for Dublin Core elements. The maim problem is: 
how do you define the value type for the Dublin Core slot. Our tool uses 
this to present the annotator with the right subtrees in the thesauri to 
choose a value for this slot. One way to do this is to define for every 
slot a metaclass that has the top nodes of the subtrees as its 
instances. But that does not lead to the intended semantic 
interpretation which is: all classes in the subtrees are valid slot 
fillers. In other words, there seems to be no way to express in OWL the 
Protege notion of "AllowedClasses", in which you define the value type 
of a slot through a set of classes, with the intended interpretation 
that all subclasses of these classes are legal slot values.

The approach we have recently been using actually avoids the use 
classes-as-instances. Take this example:

   <rdf:Property rdf:ID="style/period">
     <rdfs:subPropertyOf rdf:resource="&dc;coverage"/>
     <rdfs:subPropertyOf rdf:resource="&dc;subject"/>
     <rdfs:domain rdf:resource="#VisualResource"/>
     <rdfs:range>
       <owl:Class>
         <owl:unionOf rdf:parseType="Collection">
           <rdfs:Class rdf:resource="&aat;50111078"/>
           <rdfs:Class rdf:resource="&aat;50111079"/>
         </owl:unionOf>
       </owl:Class>
     </rdfs:range>
   </rdf:Property>

This is a piece of our OWL ontology for VRA [1].

[NOTE: VRA is a specialization of Dublin Core for visual resources [2]. 
The VRA spec defines the VRA elements as specialization's of DC 
elements. This is reflected in the OWL ontology through subproperties, 
thus allowing for DC's dumb-down principle. Note that if the DC elements 
have been defined as OWL annotation properties, this piece of OWL is 
actually not OWL DL but OWL Full.]

The value type of "style/period" (see the union) is specified here 
through the two top nodes of the relevant subtrees in the AAT hierarchy 
(&aat;50111078 and  &aat;50111079). Assume we have a painting for which 
we want to define the style/period value of "Cubism". Cubism is a class 
in one of the subtrees, so it would not be a legal value. Instead, we 
store an anonymous instance of "cubism". In fact, there is something to 
be said for this solution: the style of a painting is not cubism but 
some expression of cubism. Likewise, a painting is not "blue" but some 
expression of blue.

Sorry if this is confusing. We have had many long internal discussions 
about this, and it is difficult to summarize. Some of these 
considerations you can also find in our KCAP'01 paper "From thesaurus to 
ontology" [3]. For examples of the annotation tool see [4].

Guus

[1] http://www.cs.vu.nl/~guus/public/vra.owl
[2] http://www.vraweb.org/vracore3.htm
[3] http://www.cs.vu.nl/~guus/papers/Wielinga01a.pdf
[4] http://www.cs.vu.nl/~guus/papers/Hollink03b.pdf


> 
> I could find more examples,
> 
> Hope this helps.
> 
> Natasha

-- 
Free University Amsterdam, Computer Science
De Boelelaan 1081a, 1081 HV Amsterdam, The Netherlands
Tel: +31 20 444 7739/7718
E-mail: schreiber@cs.vu.nl
Home page: http://www.cs.vu.nl/~guus/
Received on Tuesday, 30 March 2004 23:12:00 EST

This archive was generated by hypermail pre-2.1.9 : Tuesday, 30 March 2004 23:12:10 EST