W3C home > Mailing lists > Public > www-rdf-interest@w3.org > October 2003

A couple of problems with using OWL (or DAML+OIL)

From: Matt <matt.halstead@auckland.ac.nz>
Date: Mon, 06 Oct 2003 18:53:54 +1300
Message-ID: <3F810372.2080304@auckland.ac.nz>
To: www-rdf-interest@w3.org

Two problems I am having with the use of OWL.

1. Representing closed restrictions on properties of concepts. I find 
interpreting the OKBC implementation that native protégé uses quite 
simple in this context, i.e. one may form restrictions on properties in 
subclasses, and these restrictions, plus any inherited properties that 
aren’t restricted further form a specific template for gathering data to 
instantiate these.

Consider for example the following in OWL or DAML+OIL

Class A : primitve
Class B : primitve
Class C : primitve
Class D : primitve

Property hasA
Property hasB
Property hasC
Property hasD

hasC SubProperty A
hasD SubProperty A

Class E : primitive
hasA A 1*
hasB B 1*

Class F : defined
SubclassOf E
hasC 1*
hasD 1=

Given this, an individual of F needs to have all the necessary and 
sufficient conditions of F and satisfy the necessary conditions of E, 
which as I see it, means it needs to satisfy hasC, hasD and hasB as a 
minimum. There is nothing stopping an instance of Class F also defining 
other values for property hasA that are not instances of hasC or hasD 
relations. If I wanted to follow the OKBC style more closely, it would 
seem I should define a new concept that contains the properties hasC and 
hasD as defined in F and use this as a value restriction on the property 
hasA in F. That would at least narrow the interpretation to only 
allowing values of hasC and hasD and not others of hasA being defined in 
instances of F. But that feels like a hack in that we start creating 
intermediate classes that aggregate those subProperties we whish to 
restrict a particular property of a superclasss to in a particular 
class. Perhaps that is the correct way.

2. The blurry line between metadata and data. One way to describe this 
is from the perspective of adding metadata to data resources. We have an 
XML based data representation language for biological modelling. We 
currently use RDF to provide metadata descriptions of the data 
structures. The line between metadata and the data structures seems to 
blur quite quickly. It’s obvious that our XML representation language 
itself is simply a particular legal abbreviated form of writing out the 
RDF/XML representation of instances of OWL, or RDF-S constructs. So what 
should it actually be – instances of an ontology, or instances of a 
particular XML Schema or DTD(i.e. custom language specification)? One 
driving force in answering this seems to be the difficulty of 
interpreting OWL, or RDF-S constructs into the well defined objects the 
representation language represents. E.g. if I defined a particular 
element in our representation language as an OWL concept, and 
interpreted a particular instance of this, then it 1) isn’t very easy to 
check against a schema to see if it conforms to a correct XML structure, 
since quite a few different XML representations would be equally valid 
representations of instances of the OWL concept and 2) it isn’t very 
easy to write XSLT transforms for instances, since again, they could be 
represented in different ways. Note : both of these uses are 
interpretations at the XML data level in terms of structure and content, 
not validation or inference using the semantics.

Overall, both 1) and 2) above suggest to me to not use the OWL language 
to represent constructs that are to be used as templates for data 
structures in OOP or as defined XML structures intended for XML 
transforms, unless structural and/or OOP concepts are also defined 
within the ontology so that such unambiguous interpretations can be made.

Or I have this completely wrong and need to read more – in which case 
pointers to particular articles would be appreciated.

If you have made it to here, I really appreciate your help.

Received on Monday, 6 October 2003 01:54:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:44 UTC