W3C home > Mailing lists > Public > public-owl-dev@w3.org > July to September 2007

RE: Property Value Ranges

From: Ibach, Brandon L <brandon.l.ibach@lmco.com>
Date: Wed, 22 Aug 2007 22:17:40 -0400
To: John McClure <jmcclure@hypergrove.com>, Owl Dev <public-owl-dev@w3.org>
Message-id: <0D237077B37CD943A64396032B6569270352A355@EMSS04M23.us.lmco.com>

	I'm not sure why you're uncomfortable with expressing
constraints on an individual's property value using class-based
mechanisms.  When you get right down to it, OWL only allows you to say
what classes an individual belongs to and what values it *does* have for
properties.  Anything more complicated than that, such as what values it
*doesn't* have or which values it *could* have, are handled by defining
class and property expressions, then relating the individual to these
expressions with <rdf:type>.
	A significant amount of the OWL language is, technically, syntax
shortcuts that could be rewritten into other forms, all built on a
handful of "primitive" constructs.  If your concern is simply that the
new version of OWL won't have shortcuts for things you want to be able
to model easily, you should certainly provide that feedback.  Of course,
since you obviously have some experience in defining some syntax of your
own, you might also consider using an extended version of OWL with
special syntax that better meets your needs, so long as that syntax can
be readily translated (using XSLT, for instance) into standard OWL that
can then be fed to a reasoner or other processing tools.
	All that said, I think your example could be expressed with
something like the following, which (disclaimer!) I have not tested with
any tools.  Hopefully, any errors on my part will be corrected in short
order by those on the list more experienced than I. :)  Several
variations on the means to define the allowed values are possible, if
you don't care for the use of <owl11:pattern>, which I chose simply
because it is the most compact (and because I'm a regexp junkie).

<owl:Thing rdf:about="#a">
      <owl:onProperty rdf:resource="#P"/>

	If you find this somewhat verbose expression as part of the
definition of an individual to be distasteful, I'd ask what it is about
this one individual that motivates this restriction upon its value for
this property.  My inclination is to say that this motivation is
probably some aspect of this individual and that this aspect should be
named and defined as a class in your ontology, in which case the
declaration that this individual has that aspect would be a simple
assignment of the individual as a member of the class and your property
value restriction would be accomplished, neat and clean.

-Brandon :)

-----Original Message-----
From: public-owl-dev-request@w3.org
[mailto:public-owl-dev-request@w3.org] On Behalf Of John McClure
Sent: Wednesday, August 22, 2007 2:57 PM
To: Owl Dev
Subject: Property Value Ranges

I'm uncomfortable with the answer given for axioms about instance
values -- the answer used a <Restriction> element which is mechanism for
definitions. I'm concerned about the impact of this approach on
user-queries of
a knowledge-base and also on its maintenance by developers

Let's consider for a moment that one wants to say an instance 'a' has a
'P' that has an exclusive range of values a-z, with the exception of
value 'm'
(and, being exclusive, of the endpoints). To me, that is a simple matter

<owl:Thing rdf:about="#a">
     <P verb='has'>
	<Minimum verb='has' rdf:value='a'/>
	<Maximum verb='has' rdf:value='z'/>
	<Value verb='hasNot' rdf:value='a'/>
	<Value verb='hasNot' rdf:value='z'/>
	<Value verb='hasNot' rdf:value='m'/>

Would someone provide the OWL 1.1 equivalent coding (in XML)? I'm
wondering if
the values for P are spread across <rdf:type> and <P> element structures
than packaged in a single element as shown above.

Though feasible, using <rdf:type> elements to specify property values
that an
instance *does or doesn't have* seems strange from the perspective that
hard to understand the actual significance of the extent of a class so

John McClure
Received on Thursday, 23 August 2007 02:17:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:58:15 UTC