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

Interpreting OWL property restrictions

From: Matt <matt.halstead@auckland.ac.nz>
Date: Wed, 08 Oct 2003 09:02:10 +1300
To: www-rdf-logic@w3.org
Message-id: <007601c38d0d$e4e6ad40$ea50fea9@o0z6n4>

Two problems I am having

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 : primitive
  Class B : primitive
  Class C : primitive
  Class D : primitive

  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.

Thank you for any help you can provide,

Received on Tuesday, 7 October 2003 16:02:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:40 UTC