reifying variables

From: Sandro Hawke ([email protected])
Date: 02/10/04

  • Next message: [email protected]: "Hello" 
    This came up at the end of the call, and Benjamin asked if I could be
more clear about it in e-mail.  I'll try.  The issue is about handling
variables in in RDF syntaxes.

SWRL 0.5, at the start of section 6 says:

   "In this section we present an RDF concrete syntax for the
   rules. It is straightforward to provide such an RDF concrete syntax
   for rules, but the presence of variables in rules goes beyond the
   RDF Semantics. We do not yet know if the intended semantics of the
   resultant RDF graphs can be described as a semantic extension of
   RDF." 

So SWRL makes no claim to get it right, which is okay, but of course
this means it's not really an "RDF Concrete Syntax", it's an "RDF-Like
Concrete Syntax."   Not so good.

The example is:

  <swrl:Variable rdf:ID="x1"/>
  <swrl:Variable rdf:ID="x2"/>
  <swrl:Variable rdf:ID="x3"/>
  <ruleml:Imp> 
    <ruleml:body rdf:parseType="Collection">
      <swrl:individualPropertyAtom> 
        <swrl:propertyPredicate rdf:resource="&eg;hasParent"/> 
        <swrl:argument1 rdf:resource="#x1" />
        <swrl:argument2 rdf:resource="#x2" />
   ...

DRS says:

     Variables in this system are treated as belonging to the class
     Variable from SWRL, the OWL rules language. Variables (may) have
     names, which link them back to their source form. They also have
     rdf:IDs that distinguish different variables with the same name.

The example is:

   <drs:Forall> 
     <drs:bound vars> 
       <drs:Var_bag rdf:parseType="Collection">
         <swrl:Variable ID="v1" name="x"/> 
         <swrl:Variable ID="v2" name="y"/>
       </drs:Var_bag> 
       </drs:bound vars> 
       <drs:body> 
         <drs:Implies>
  	 <drs:antecedent> 
  	   <drs:Atomic_formula> 
  	     <rdf:predicate resource="http://human.rels.org/term#loves"/> 
  	     <rdf:subject resource="#v1"/> 
  	     <rdf:object resource="#v2"/> 
  	   </drs:Atomic_formula>
  	   ...
  
    [ actually, the Var_bag shouldnt be there -- parseType=Collection
    forces it to be an rdf:List -- but I get the idea ]

The problem may be obvious looking at:

 	     <rdf:predicate resource="http://human.rels.org/term#loves"/> 
  	     <rdf:subject resource="#v1"/> 

if you think about the triple 

     <#v1> rdf:type swrl:Variable

appearing or disappearing (let alone being inferred, negated, etc).
That other triple -- which could even come from some other document --
changes whether a term in this one is treated as a variable or a
constant.  Seems like a bad idea.  (I'm willing to try to construct a
proof that this is incompatible with the RDF semantics if necessary,
but for now I'll assume it's understood.)

I think a solution is to reify all the way down, so it's like:

           <predicateTerm>
              <Constant>
                 <denotation rdf:resource="http://human.rels.org/term#loves"/> 
              </Constant>
           </predicateTerm>
           <objectTerm rdf:resource="#v2"/>

That object term, #v2, is of course a variable.  We could include that
information here if we wanted, and maybe a name, making it look like

           <objectTerm>
              <Variable rdf:about="#v2"/ name="x">
           </objectTerm>

But we probably want to declare our variables and maybe even our
constants at the beginning, just for human readers.
 
Note that the terms used in the Atomic_formula are given as "Term" objects;
subclasses of Term include "Constant" and "Variable".   To connect
them back to RDF, Constants can have a "denotation" which is an RDF
term.    (The word "denotation" isn't quite right here; I want some
way to say "equals" which stretches between two logics.)

In this formulation, if you don't know whether a Term is a Variable or
a Constant (or whatever), you can't use the formula.  If you learn
it's both, you have an ill-formed formula.   The system is monotonic
and compatible with RDF.

Incidentally, I concur with Drew's observation that one could just
write 
   <logic>(or (loves she me) (not (she loves me)))</logic>
except that we still need a way tie in URIs and generally map to RDF
(in terms of n-ary predicates, function terms, etc).   (So, yes, 
equivalent compact syntaxes are a good thing.)   We may encounter this
problem in other places as we try to import/export between RDF and
the same-expressive-power bits of other languages which just aren't
webized and perhaps have transformable differences like n-ary
predicates.

     -- sandro

    This archive was generated by hypermail 2.1.4 : 02/11/04 EST