Re: [UNITS] FAQ : Constraints on data values range

>I have not noticed any activity under [UNITS] so 
>far ... this is a first bait :))
>A FAQ in Protégé-OWL list, I'll give here the 
>latest variant sent yesterday (summed up)
>"I have defined a class 'Wheel'
>and a DatatypeProperty 'diameterValue'
>on Domain 'Wheel'
>and Range 'Integer'
>I want to create a class 'BigWheel' with a restriction on the property
>'diameterValue', for instance 'diameterValue => 10'.
>How do I do that in OWL?"

You mean in OWL-DL, right? You can't.  There are 
lots of workarounds you can use, but the short 
answer is that you can't say what you want to 
say. In OWL-Full this is a two-step restriction 
(assuming you have some property corresponding to 
'=>' available:)

BigWheel onProperty diameterValue .
BigWheel allValuesFrom _:x .
_;x onProperty greaterThan .
_:x hasValue "9"^^xsd:integer .

>I had answered that basically you can't express 
>that kind of 'quantitative restriction' in
>OWL, although there are workarounds, like using 
>a 'minDiameterValue' property and so on.
>I guess every other user wanting to include 
>units in one's ontology will hit that kind of


>It figures we should come out with clear explanations why OWL does not support
>quantitative restrictions on DatatypeProperty 
>with numerical Range, and more generally
>restrictions linked to the very nature of data 
>themselves, like defining the class
>'WellDescribedThing' by restriction on a 
>'description' value to 'over 1000 words'.


IMO, this kind of example illustrates exactly why 
OWL-full (or even better, RDF + the OWL 
vocabulary) is more use than OWL-DL as a web 
ontology language. Rather than imposing a uniform 
blanket restriction on all ontology 
expressiveness, what we should be doing is 
letting people say what they mean. Then other 
people will build reasoners that do something 
useful with it. This will create a kind of 
ontology-expressiveness marketplace between 
ontology/markup writers and processing-engine 
implementers, where it might be worth an 
engine-implementer's effort to appropriately 
support some feature if enough people want to use 
it. Instead we have created a DL-reasoning-engine 
monopoly. We are telling the entire planet to 
twist itself into knots just to ensure that the 
DL reasoners are never offended by the sight of a 
class containing a class or a restriction on a 
datatype value, both of which are perfectly 
clear, meaningful notions with a rigorously 
defined semantics.

<comment on rant>
I don't mean to re-start an old argument. We all 
know the various positions we hold on this issue. 
But I feel that the OWL documentation has been 
allowed to contain some rather extreme negative 
comments about OWL-Full, and that an occasional 
comment in the other direction may be informative 
to those whose minds are still open.
</comment on rant>

>[Seems to me that there are many ways to work 
>around declaration of those kinds of
>restrictions, but that OWL internally makes no 
>provision to check their consistency, but
>can be used to pass them as black boxes to 
>external applications that can make sense of
>them. IOW, I can declare an instance of 
>'BigWheel' with 'diameterValue' set to 9.7, no
>inconsistency will be detected by pure logical 
>tools with 'minDiameterValue = 10', but
>external applications able to deal with quantities will make sense of it.]

Guus' proposal to use complex datatypes has the 
same features: it hands consistency issues over 
to the datatype.  I think this kind of thing is 
going to happen a lot.

Maybe we should explain the issues that arise in 
this kind of an external opaque trick, and let 
people choose. Can we give good advice on how to 
at least document such a trick so as to let folk 
know what they are, and more particularly are 
not, getting when they use it?


>Bernard Vatant
>Senior Consultant
>Knowledge Engineering
>Mondeca -

IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell

Received on Friday, 16 April 2004 15:27:04 UTC