W3C home > Mailing lists > Public > public-owl-wg@w3.org > May 2008

RE: Question about problems with top/bottom property

From: Michael Schneider <schneid@fzi.de>
Date: Thu, 29 May 2008 23:31:07 +0200
Message-ID: <0EF30CAA69519C4CB91D01481AEA06A096AF41@judith.fzi.de>
To: "Boris Motik" <boris.motik@comlab.ox.ac.uk>
Cc: <public-owl-wg@w3.org>
Hi Boris!

Many thanks for this clear explanation. I think I now understand what your
concerns are.

To point 2: What I at least can imagine is that adding U to OWL R Full would
result in a mess. So let's better not have it in this particular profile.

To point 1: I was surprised that the encoding of U was so simple (I myself
only found a complicated encoding based on sub property chains a few months
ago). And I can see that it is even simpler, because the reflexivity axiom
(2) is redundant: For each x in owl:Thing we have U(x,ni) by axiom (1). So
we have U(ni,x) by symmetry (3). And then U(x,x) follows from transitivity
(4). This means that the top property can already be expressed in OWL 1.


>-----Original Message-----
>From: Boris Motik [mailto:boris.motik@comlab.ox.ac.uk]
>Sent: Thursday, May 29, 2008 1:52 PM
>To: Michael Schneider
>Cc: public-owl-wg@w3.org
>Subject: RE: Question about problems with top/bottom property
>Here is the executive summary of this rather long e-mail:
>1. The universal property can already be expressed in OWL 2 in a
>straightforward way.
>2. This straightforward encoding (suggested in most papers), however, is
>quite inefficient in practice.
>3. It might be possible to come up with a more efficient implementation
>technique. This technique, however, would not be completely
>4. It is currently unclear how any of these techniques would fare in
>5. It is currently unclear that the potential "dangers" outweigh the
>benefits of adding the universal property.
>6. Therefore, we might want to wait before we add this feature to OWL 2.
>And now for the details.
>Point 1.
>You can use existing OWL 2 axioms to encode universal role. The
>following axioms make U universal (ni is a new individual -- that
>is, an individual that does not occur elsewhere in your ontology):
>(1)  SubClassOf( owl:Thing hasValue( U ni ) )
>(2)  ReflexiveProperty( U )
>(3)  SymmetricProperty( U )
>(4)  TransitiveProperty( U )
>Axiom (1) makes every individual in the interpretation domain connected
>through U to ni, and axioms (2), (3), and (4) then ensure
>that you have a connection between all possible individuals. This is the
>encoding suggested as an encoding in most papers: one
>simply adds these axioms to an ontology and treats U as an ordinary
>object property.
>Point 2.
>The problem with this encoding is that axioms (1)--(4) connect
>everything with everything. Consider what would happen if you added
>(1)--(4) to an ontology containing a large number of assertions. Then,
>your reasoner would have to deal with the extension of U
>which is at least quadratic in the number of individuals occurring in
>the ontology. This is likely to cause problems for indexing
>and memory storage management in general.
>Point 3.
>I had a quick chat with Ian, and we noticed that there might be a way to
>implement the universal property more efficiently, without
>the explicit maintenance of the extension of U. Here is a very rough
>sketch how this might work.
>The only way that U does something from a logical point of view is
>through universals, and in such cases, U is connected to
>everything; hence, you might find a suitable reformulation of
>AllValuesFrom( U CE ) and simulate it though axioms of the form
>SubClassOf( owl:Thing CE ). In fact, the two constructs are "quite
>close" semantically.
>The complication here is with the role hierarchy: one would have to
>ensure that the used encoding does not mess up some interaction
>w.r.t. complex role inclusions.
>Thus, there is some conceptual work to be done, albeit this work is
>probably not hard and/or interesting from a purely theoretical
>point of view.
>Point 4.
>We should be careful when extending OWL 2 with new features that have
>not been extensively tested in practice.
>If we don't have the universal property in OWL 2, then it is user's
>fault if he adds the axioms (1)--(4) to an ontology and
>everything suddenly runs slowly. In fact, if a user complains that my
>reasoner is running slowly on his ontology, I can tell him
>"it's your fault because you are using an ontology which is hard".
>If we allow for the universal property, then users will use it (even
>though they might not really need it). But then, if my
>implementation technique for an official feature of OWL 2 is flaky (and,
>in particular, if this flakiness occurs in even rather
>simple cases), the user has every right to complain.
>Point 5.
>On the one hand, I see that the universal property might be intuitively
>appealing: it would allow make the language symmetric when
>compared with classes (which have owl:Thing), and it would allow us to
>"hang" the property hierarchy off of the universal role.
>On the other hand, I don't see what expressivity benefits we gain by
>adding the construct to the language. As I already mentioned,
>AllValuesFrom( U CE ) and SubClassOf( owl:Thing CE ) are "very close"
>Thus, the added expressivity of the universal property does not seem to
>outweigh the potential risks identified in Point 4.
>Point 6.
>My preferred course of action would be to let someone demonstrate
>(either by using the simple encoding (1)--(4) or by developing a
>more efficient implementation approach) that adding universal property
>does not really cause problems in practice. Assuming this is
>done, adding the feature to the language should not be contentious.
>	Boris
>> -----Original Message-----
>> From: public-owl-wg-request@w3.org [mailto:public-owl-wg-
>request@w3.org] On Behalf Of Michael
>> Schneider
>> Sent: 29 May 2008 09:32
>> To: Boris Motik
>> Cc: public-owl-wg@w3.org
>> Subject: Question about problems with top/bottom property
>> Hi Boris!
>> In yesterday's telco you expressed some concerns about the
>introduction of
>> the top/bottom properties into OWL. But I did not understand what the
>> problem was. Can you please elaborate on this topic.
>> Thanks,
>> Michael

Received on Thursday, 29 May 2008 21:31:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:04 UTC