W3C home > Mailing lists > Public > public-owl-wg@w3.org > April 2009

RE: Negative Property Assertions (NPAs) in RL

From: Michael Schneider <schneid@fzi.de>
Date: Thu, 16 Apr 2009 11:57:26 +0200
Message-ID: <0EF30CAA69519C4CB91D01481AEA06A00125F9E5@judith.fzi.de>
To: "Bijan Parsia" <bparsia@cs.man.ac.uk>
Cc: "OWL 2" <public-owl-wg@w3.org>
>-----Original Message-----
>From: public-owl-wg-request@w3.org [mailto:public-owl-wg-request@w3.org]
>On Behalf Of Bijan Parsia
>Sent: Wednesday, April 15, 2009 10:43 PM
>To: OWL 2
>Subject: Negative Property Assertions (NPAs) in RL
>There was some clear and present confusion in today's telecon.  I
>want to point out a few things, and I wanted to record (now) my
>thoughts so that if Aberdeen does file a formal objection, I don't
>have to recreate them later :)

I would also like to add a few words, specifically concerning the
implementation of NPAs in the OWL 2 RL/RDF ruleset. My argument is that this
is a very weak and IMO harmless implementation, and really not an AtRisk
candidate (although I was indifferent about this point at yesterday's TC and
therefore voted "0"). 

In general, I think it is important to stress that the semantic expressivity
of NPAs in OWL 2 RL/rules is very limited compared to the complete treatment
of NPAs in the Direct Semantics and the RDF-Based Semantics. There are many
things that can happen based on NPAs under these more expressive semantics,
which are simply not possible in RL/rules. A few points to be considered:

(1) The only NPAs that can ever occur in the RL ruleset are those that are
explicitly defined within a given ontology (modulo simple inferred variants, 
e.g. by owl:sameAs-based substitution). There is no rule that has an NPA 
(or a fraction of the NPA encoding) in its consequent, so NPAs can never be 
inferred, unless there are already NPAs defined in the ontology. In 
comparison, a lot of NPAs can be entailed under the Direct/RDF-Based 
semantics, even if there is not a single NPA explicitly stated in an 
ontology (see the example in (2)).
(2) The only interesting semantic effect of an NPA(s p o) under the 
OWL 2 RL ruleset is that it leads to immediate inconsistency of an ontology, 
when the triple "s p o" can be inferred from the ontology. If "s p o" 
cannot be derived, the NPA keeps semantically silent. This kind of 
"sleeping killer watchdog" behavior of an NPA in RL/rules is pretty clear 
and should rarely lead to confusion. In comparison, under the 
Direct/RDF-Based semantics a lot of other, more subtle things can 
happen due to NPAs; in particular, the outcome won't always be an 
inconsistent ontology. 

For example, the following ontology O

  O := {
      :fp rdf:type owl:FunctionalProperty
      :y owl:differentFrom :z
      :x :fp :y

is obviously OWL 2 DL/Full satisfiable, and it OWL 2 DL/Full entails

  |= NPA(:x :fp :z) .

However, this outcome is NOT an outcome from the RL/rules, although 
the RL ruleset covers all the features used in the ontology O 
(functional properties, different individuals, and property assertions). 

(3) The two NPA rules in RL closely resemble the rule "eq-diff1", which

  "s owl:sameAs o, s differentFrom o --> false", 

but AFAIR no one has ever considered this rule harmful.


>	1) It was asserted that NPAs increase the expressivity of RL [1],
>and that that was a reason to resist them (since they would increase
>the implementation burden).
>	NPAs are sugar as was pointed out last week:
>	Achille's encoding:
>		 DisjointClasses(ObjectSomeValueFrom(R, ObjectOneOf(b)),
>	There are a slew of other ones.
>	All the encodings are linear (obviously).
>	2) It was asserted that NPAs are difficult for RDF APIs [2], and
>that that was a reason to resist them.
>	NPAs do not require any change to any RDF API. At all. Nada.
>Furthermore, this fact does not require any special RDF or RDF
>toolkit expertise to verify (although, I believe I have that
>expertise and I do verify it). If we look at the mapping to RDF:
>    NegativeObjectPropertyAssertion( OPE a1 a2 )
>Gets mapped to:
>    _:x rdf:type owl:NegativePropertyAssertion .
>    _:x owl:sourceIndividual T(a1) .
>    _:x owl:assertionProperty T(OPE) .
>    _:x owl:targetIndividual T(a2) .
>All the latter are standard RDF triples in good standing. Thus, there
>is no change needed to any RDF API to support NPAs. The rules need to
>reason with them them can be standard RDFy rules (and Ivan has
>verified this with an implementation). All the alternative encodings
>require *more* triples. But they are all triples. There's *no*
>difference between the various encodings from the RDF point of view
>except number of triples and the predicates used. None. Nada. Zip.
>In fact, this encoding is *better* than the other ones as it's A)
>shorter, and 2) more intention revealing.
>I would expect users to like this and want NPAs. The general rule is
>that users like features, esp. if there's no extra cost and, you
>know, people *do* complain that you can't negate property assertions.
>Given how easy the alternative encodings are *and* that we have the
>"direct" encoding in the complete language, we run a rather serious
>risk of people settling on an alternative encoding. That's *bad*
>because it introduces nominals even when nominals weren't otherwise
>used. That means that such OWL RL ontologies can do *arbitrarily
>worse* on reasoners with general nominal support. That means a
>heavier implementation burden or worse interop.
>If we have means in the complete language to directly say what can be
>implicitly said in a profile, we should enlarge that profile to be
>able to directly say it. To do otherwise is to *confuse* people about
>the expressive capabilities of the profile. This was (as Uli pointed)
>one of the deep problems with OWL Lite. We should not repeat that
>mistake...and we aren't!
>I went back and looked at Jeremy's comment and not that he raises no
>technical issue with them. He says that they will cause some
>unidentified user problem and that "RDF systems are simply not geared
>up to support negative triples as well as positive ones". But of
>course, we do not introduce "negative triples". We encode, in
>triples, negative property assertions. Given the proven harm of not
>providing sensible direct means of expressing things over an
>inchoate, incoherent worry about a possible harm...well...I chose to
>avoid the former.
>[1] Boris clearly had a thinko. But since Jeff was tasked with
>thinking about whether this caused any problems, I'm unclear why he
>didn't catch the thinko instead of acting like it supported his pov.
>     http://www.w3.org/2009/04/15-owl-irc#T17-36-58
>     17:36:38 [msmith]
>      bmotik: jjc is wrong, there is no problem with the RDF. we
>either have it in the language or not.
>     17:36:58 [msmith]
>       ... in RL it is *not* syntactic sugar, they can't be expressed
>in other ways
>     17:37:58 [msmith]
>     jeffp: bmotik's point that it is not syntactic sugar in RL is
>It's especially weird given Jeff's earlier comment:
>     17:33:56 [msmith]
>      jeffp: last telecon we discussed n.p.a.'s in RL. I did some
>investigation and I think it boils down to syntactic sugar.
>Which is itself weird given that no investigation was required to
>determine that it was syntactic sugar as Achille demonstrated this in
>the prior telecon.
>It would have been *much better* to have discussed this in email.
>Much less chance of confusion and going off into the weeds.
>[2] http://www.w3.org/2009/04/15-owl-irc#T17-50-39

Dipl.-Inform. Michael Schneider
Research Scientist, Dept. Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: michael.schneider@fzi.de
WWW  : http://www.fzi.de/michael.schneider
FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts, Az 14-0563.1, RP Karlsruhe
Vorstand: Prof. Dr.-Ing. Rüdiger Dillmann, Dipl. Wi.-Ing. Michael Flor,
Prof. Dr. Dr. h.c. Wolffried Stucky, Prof. Dr. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus

Received on Thursday, 16 April 2009 09:59:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:41:58 UTC