Re: SWRL expression in a property instance?

From: Peter F. Patel-Schneider (pfps@research.bell-labs.com)
Date: 02/12/05

  • Next message: Benjamin Grosof: "Re: SWRL expression in a property instance?"
    [Speaking for myself, but with some pretensions to know something about the
    topic. :-) ] 
    
    From: David Martin <martin@AI.SRI.COM>
    Subject: SWRL expression in a property instance?
    Date: Fri, 11 Feb 2005 18:10:45 -0800
    
    > Greetings Mike and all joint committee folks -
    > 
    > Lest you guys get bored, a bunch of us are grappling with the question 
    > of how to use a SWRL expression as the value of a property instance, and 
    > I'd very much appreciate your views on this.
    
    You asked, so don't get mad at the answer.  :-)
    
    > For example, in OWL-S an AtomicProcess has a precondition, which we want
    > to express in SWRL.  Here's a simplistic example of the kind of thing we
    > might like to do:
    > 
    > <AtomicProcess>
    >    <hasPrecondition>
    >      <ruleml:Imp>
    >        <ruleml:body>
    >          <!-- empty body -->
    >        </ruleml:body>
    >        <ruleml:head>
    >         <swrl:IndividualPropertyAtom>
    >           <swrl:propertyPredicate
    >             rdf:resource="&eg;hasCreditCardOfType"/>
    >           <swrl:argument1 rdf:resource="#user" />
    >           <swrl:argument2 rdf:resource="#VISA" />
    >         </swrl:IndividualPropertyAtom>
    >        </ruleml:head>
    >      </ruleml:Imp>
    >    </hasPrecondition>
    >    ....
    > </AtomicProcess>
    > 
    > This says that the precondition for the atomic process is that the user 
    > must have a VISA card (user is a variable that will get bound to some 
    > kind of user ID, when the process runs).
    > 
    > So here are my questions:
    > 
    > (1) Is this legal to use an Imp instance in this way, as the value of a 
    > property instance?
    
    Your question is not specific enough.  Let me provide answers to several
    more specific questions.
    
    (11) Is the above syntactically-valid RDFS?
         
         No, because it is missing rdf:parseType="Collection" in two places.
    
    (12) Ignoring that, is the above syntactically-valid RDFS?
    
         I think so.  (Checking RDF by hand is beyond my capabilities.)
    
    (13) Is the above (modified) semantically-valid RDFS, i.e., non contradictory?
    
         Yes, of course, as it is very hard to make contradictions in RDFS.
    
    (14) Is the above (modified) syntactically-valid OWL?
    
         Yes, although only OWL Full, as it uses collections outside of the DL
         syntax.
    
    (15) Is the above (modified) semantically-valid OWL Full?
    
         Yes, as there is no use of interesting OWL stuff here.
    
    (16) Is the above (modified) syntactically-valid SWRL.
    
         Yes, it appears to be, although the precise characteristics of the RDF
         syntax for SWRL are not very well specified.
    
    (17) Is the above (modified) semantically-valid SWRL.
    
         Hmm.  That depends.  The RDF syntax for SWRL is not fully mixable
         with other RDF.  This goes to the heart of the problem with RDF.
         (More below on this.) 
    
    > (1a) In general, can SWRL classes like Imp and IndividualPropertyAtom be 
    > instantiated and used in all the same ways that ordinary OWL classes can 
    > be used in OWL-DL?  (Is it even right to think of these as OWL classes?)
    
    Good question.  
    
    The answer to all of these is "NO!", or, at least "DON'T DO IT!".  You are,
    in essence, mixing together facts and code without being able to determine
    which is which.  In particular, as far as SWRL is concerned you have a
    top-level rule there - not a precondition.  Any SWRL processor would be
    correct in trying to determine the consequences of this rule, which is
    certainly not what you want.
    
    However, if you don't care about SWRL processing, then go right ahead.  But
    then why worry about the RDF form of the rule - why not just include the
    abstract syntax in a string?
    
    > (2) If the above example is legit, how about if we omit the Imp and body 
    > and head elements, and just nest the IndividualPropertyAtom directly 
    > inside the hasPrecondition tag?
    
    If the above considerations didn't matter, then there would be no problem.
    Just think of it as any other data.  Again, however, why not just use
    strings to carry the SWRL rules?
    
    > (3) If the answer to (1) or (2) is "no" - is it any different for SWRL-FOL?
    
    No.  There is no reason that the answer would be less restrictive for
    SWRL-FOL.  There is no RDF syntax for SWRL FOL, nor will there ever be if I
    have anything to say about it.
    
    [In fact, it is demonstrably impossible to have a viable same-syntax
    extension of RDF to unary/binary predicate calculus with equality.]
    
    > (4) If the above example is legit, and *if* we forget about RDF 
    > semantics, will a SWRL reasoner treat the Imp as if it were a non-nested 
    > assertion, and try to reason with it?  Or will it simply record that 
    > there's an Imp instance related to an AtomicProcess instance?
    
    Hmm.  A SWRL reasoner probably woudn't work very well at all on a document
    of this form.  The RDF syntax for SWRL rules isn't really RDF - it is just
    a way to get RDF parsers to not choke on SWRL rules.  (Why do this?  I
    plead the fifth!)
    
    If you want to write SWRL then you should have separate documents for OWL
    information and SWRL rules.  
    
    If you want to embed SWRL in something else, then you should probably not
    use the RDF syntax.
    
    > Thanks!
    > 
    > - David Martin
    > (on behalf of various people working on OWL-S and Protege-based OWL editors)
    
    Peter F. Patel-Schneider
    Bell Labs Research
    
    
    PS: I'm not particularly satisfied with the way this answer turned out.  In
    particular, there are ways around your problem - but you probably won't
    like the answer.  This topic really requires an interactive session to give
    it full justice.
    


    This archive was generated by hypermail 2.1.4 : 02/12/05 EST