Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[protege-owl] SWRL extension for Disjunction and Negation

Martin O'Connor martin.oconnor at stanford.edu
Wed Oct 31 11:53:00 PDT 2007


>Howver, AFAIK the SWRL specification 
>requires that SWRL rules are interpreted as first-order (horn logic) 
>sentences (and full SWRL is undecidable anyway).
>
Yes - and unrestricted SWRL rules are definitely undecidable. A lot of 
recent effort has concentrated on so-called DL-safe SWRL, which is 
decidable. Two OWL reasoners that I am aware of that support SWRL 
(Pellet and KAON2) both implement DL-safe SWRL. (FYI, there is a brief 
description of DL safe rules in my SWRL language FAQ [1] and Bijan 
Parisa has a recent series of blog posts on this topic [2].)

>Thus, you should also be able to conclude from 
>
>i : not human 
>
>and 
>
>person(?x) -> human(?x) 
>
>that 
>
>i : not person 
>
>holds, etc. Can this conclusion be reached with any SWRL engine 
>currently available? 
>
 I am not sure if the current Pellet or KAON2 implementations support 
contraposition. This topic was brought up recently on the Pellet mailing 
list in a discussion of DL-safe rules. Posting this question there might 
be a good idea.

The Pellet people are gradually expanding their support of SWRL in their 
reasoner. This support is at the native level, which is nice because 
SWRL rules can be considered as just another sort of OWL axiom. I think 
KAON2 is being turned into a commercial project.

>I also don't know what happens with the SWRL 
>built-ins, e.g. can you deduce from 
>
>i : (not adult) 
>(i,age-of-i) : age   (so "i" has some unspecified age, "age-of-i")  
>
>and the rule 
>
>age(?x,?age) & swrl:GreaterOrEqualThan(?age,18) -> adult(?x)
>
>that "swrl:LessThan(age-of-i,18)" must hold? It is important to get 
>this inference since other rules may have this atom in their 
>preconditions. I am wondering what kind of semantics the SWRL 
>specification has given to built-ins; in general, some kind of 
>concrete domain reasoning is required here, am I right? 
>
The SWRL Submission says very little about the semantics of built-ins, 
despite having quite a large section devoted to defining a core library 
[3]. It is very easy to see that built-ins could cause all sorts of 
interesting problems, particularly if they can bind their arguments. For 
example, the rule

Driver(?d) ^ hasAge(?d, ?age) ^ swrlb:add(?newage, ?age, 1) -> 
hasAge(?d, ?newage)

will never terminate.

>Thus, IMHO, 
>nasty (theoretical) problems already appear with built-ins and the 
>first-order semantics left alone (even if you don't have NAF negation 
>etc.) and I think that the only "escape" from them is to assign a 
>non-first order semantics to (SWRL) rules, but I may be wrong. I am 
>curious to learn how these situations are addressed in other 
>available SWRL engines. 
>  
>
My understanding is that Pellet, for example, does not support arbitrary 
built-ins and that the goal is to develop a formal semantics for the 
built-ins that they implement to ensure sound reasoning. Again, it might 
be good to ask this question on the Pellet list.

The SWRLTab Jess implementation of SWRL inference is currently very much 
an ad hoc solution. When I developed it (in late 2005), there were no 
usable SWRL implementations. Many OWL axioms are ignored when an OWL 
ontology containing SWRL rules is mapped to Jess for inference [4]. 
However, even this limited form of reasoning has proved quite useful.

My goal is to use the current release of Pellet as an additional 
inferencing back end for the SWRLTab in the next month or so. However, 
the Jess back end is not going away. I plan to extend it so 
progressively consider additional OWL axioms, perhaps with user 
configuration of the desired 'axiom support level'. My intuition is that 
a full implementation of SWRL inference is going to have scalability 
issues in the short term. Built-ins are also going to be problematic in 
reasoners too. Pellet, for example, is probably going to be very 
conservative in its support for built-ins.

>Thus, as long as the rule application strategy is under control of the 
>application and termination is granted I think it doesn't harm the  
>situation to add additional expressive means to such rules in order 
>to enhance their applicability to real world problems (since from a  
>logical perspective, things are already  complicated due to the 
>presence of built-ins and contra-positions left alone etc.). Just my 
>two cents. 
>
I agree. We have been using SWRL in several biomedical applications over 
the past two years and have run into many expressivity problems with 
SWRL. From the mailing list and many discussions I have had with SWRL 
users it is clear that expressivity is a challenge. Most of the work I 
have done in the past year has been to extend that expressivity. These 
extensions have concentrated on the development of built-in libraries 
[5] and a SWRL-based query language called SQWRL [6]. The TBox built-in 
library, for example, allows direct querying of an ontology's TBox, 
something that is not possible in SWRL; other libraries allow 
interoperation with XML documents, and the use of complex mathematical 
expression in rules. There is also an API that allows user to develop 
their own built-in libraries [7]. The SQWRL query language supports a 
lot of features that are not possible in SWRL: counting is currently 
supported and soon forms of disjunction and negation as failure will be 
available. Querying, of course, presents far fewer theoretical issues 
than inference.

One of the very nice features of SWRL is its formal underpinning: 
conclusions reached using SWRL rules have the same formal guarantees as 
conclusions reached using standard OWL axioms. This is a non-trivial 
benefit. Arbitrary extensions, if not done carefully, could destroy this 
benefit. SPARQL is already a semantic disaster - another one would not 
be a good idea. However, a formally sound language that is not 
practically useful is not helpful either.

Martin

[1] http://protege.cim3.net/cgi-bin/wiki.pl?SWRLLanguageFAQ#nid9VC
[2] 
http://clarkparsia.com/weblog/2007/09/13/understanding-swrl-part-3-some-tricky-bits/
[3] http://www.daml.org/2004/04/swrl/builtins
[4] http://protege.cim3.net/cgi-bin/wiki.pl?SWRLRuleEngineBridgeFAQ#nid6QL
[5] http://protege.cim3.net/cgi-bin/wiki.pl?SWRLTabBuiltInLibraries
[6] http://protege.cim3.net/cgi-bin/wiki.pl?SQWRL
[7] http://protege.cim3.net/cgi-bin/wiki.pl?SWRLBuiltInBridge



More information about the protege-owl mailing list