reifying variables

From: Sandro Hawke (
Date: 02/10/04

  • Next message: "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
    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:body rdf:parseType="Collection">
            <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:bound vars> 
           <drs:Var_bag rdf:parseType="Collection">
             <swrl:Variable ID="v1" name="x"/> 
             <swrl:Variable ID="v2" name="y"/>
           </drs:bound vars> 
      	     <rdf:predicate resource=""/> 
      	     <rdf:subject resource="#v1"/> 
      	     <rdf:object resource="#v2"/> 
        [ 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=""/> 
      	     <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:
                     <denotation rdf:resource=""/> 
               <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
                  <Variable rdf:about="#v2"/ name="x">
    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
       <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
         -- sandro

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