RE: Property Value Ranges

John,
	Hmmm...  While I agree that this is more concise, and
potentially more maintainable, I strongly disagree with the "clearer"
part.  How am I to know what this means, when I see it?  The first
problem I see is that the OWL semantics would infer an assertion that
#blny is an rdfs:Literal, since that (or a subclass of it) is the range
of all datatype properties.  Since you've also asserted that #blny is a
DataRange, there is a conflict.  OWL DL will flag it as an error and OWL
1.1, with punning, will consider the two assertions to be talking about
different entities, one a literal and the other a data range, with the
two having nothing to do with each other.  Neither case will accomplish
what you desire, here.
	Setting that aside, for the moment, it is not entirely clear
what the relationship between the individual and the data range is,
anyway.  To illustrate my point, I wasn't quite sure exactly what
semantics you were trying to express with the original example, based on
your English-language description.  You may have meant that #a does,
indeed, have a value for the #P property and that the value is some
string matching the regexp "[b-ln-y]", but you aren't saying
specifically what that string is.  An alternative interpretation, and
the one that I actually modeled, is that if #a has any value for #P (and
you aren't saying how many it has or even that it has any at all), that
value is a string matching the regexp.  OWL has the ability to model
either of these cases as well as numerous other variations.  However,
your syntax doesn't make it at all clear which of these cases applies.
The OWL specs could simply dictate the interpretation that a reasoner
should use if it sees something like this, but then the flexibility to
model other cases is lost and this new syntax is only of limited value.
	Now, you've shown a syntax that can provide some disambiguation
of this sort of thing, using the "verb" attribute.  However, given that
OWL is committed to remaining compatible with RDF, including being
expressible using triples, this approach is problematic.  As I
mentioned, it may be feasible as a private syntax extension, *if you can
reliably map it to standard OWL syntax/semantics*, but I think it's
quite doubtful that something like this would be able to gain much
traction for inclusion in the standard.
	I don't want to discourage your participation in the discussion,
here, but I urge you to consider the often complex relationships and
interdependencies among the OWL model/semantics, the RDF/RDFS
model/semantics, and the various syntaxes supported (or proposed) for
each.

-Brandon :)

-----Original Message-----
From: John McClure [mailto:jmcclure@hypergrove.com] 
Sent: Thursday, August 23, 2007 2:39 PM
To: Ibach, Brandon L; Owl Dev
Subject: RE: Property Value Ranges

Brandon,
I agree about using patterns in this instance... 
But my point is that it seems clearer to say:

<owl:DataRange rdf:about='#blny'>
    <owl11:onDataRange rdf:resource="&string;"/>
    <owl11:pattern rdf:datatype="&string;">[b-ln-y]</owl11:pattern>
</owl:DataRange>

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

No rdf:typing is necessary and I think query & maintenance is alot
easier.

Thanks,
John

>-----Original Message-----
>From: Ibach, Brandon L [mailto:brandon.l.ibach@lmco.com]
>Sent: Wednesday, August 22, 2007 7:18 PM
>To: John McClure; Owl Dev
>Subject: RE: Property Value Ranges
>
>
>John,
>	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">
>  <rdf:type>
>    <owl:Restriction>
>      <owl:onProperty rdf:resource="#P"/>
>      <owl:allValuesFrom>
>        <owl:DataRange>
>          <owl11:onDataRange
>rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
>          <owl11:pattern
>rdf:datatype="http://www.w3.org/2001/XMLSchema#string">[b-ln-y]</owl11:
p
>attern>
>        </owl:DataRange>
>      </owl:allValuesFrom>
>    </owl:Restriction>
>  </rdf:type>
></owl:Thing>
>
>	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
>property
>values -- the answer used a <Restriction> element which is mechanism
for
>class
>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
>property
>'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
>of
>
><owl:Thing rdf:about="#a">
>     <P verb='has'>
>          <Range>
>	<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'/>
>          </Range>
>     </P>
></owl:Thing>
>
>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
>rather
>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
>it's
>hard to understand the actual significance of the extent of a class so
>obviously
>artificial.
>
>Thanks,
>John McClure
>
>

Received on Thursday, 23 August 2007 19:36:13 UTC