From: Sandro Hawke (sandro@w3.org)
Date: 02/10/04
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="⪚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