# Re: Expressiveness of RDF as Rule Conclusion Language (was Re: W hat is an RDF Query? )

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Wed, 10 Oct 2001 16:07:25 -0500
Message-Id: <p0510104bb7ea65d1c347@[205.160.76.193]>
To: Drew McDermott <drew.mcdermott@yale.edu>

```>    [me]
>    >I can think of two
>    >responses:
>    >
>    >a) Don't require it to be a legal RDF graph.  Make it an "RDF graph
>    >schema," that is, something containing variables that becomes an RDF
>    >graph when nodes are substituted for the variables.
>
>    [Pat Hayes]
>    That *is* a legal RDF graph. RDF graphs have blank nodes which have
>    exactly the semantics of existential variables.
>
>    [me]
>    [This idea] leave[s] the variables without explicit scope, as in
>    >Prolog.  If you want explicit scope, things get more interesting.
>
>    True; the implied scope is the graph. This makes things much easier.
>
>Okay, if you change Sandro's "document scope" to "graph scope," you're
>right.  But then a rule like
>
>  (R1 ?x ?y) |-   (R2 ?y ?x)
>
>becomes unstatable, because the ?x and ?y in the graph on the left are
>different variables from the ?x and ?y in the graph on the right.
>
>Unless I'm missing something.

No, that is perfectly correct. I was thinking of the idea that RDF
needed to be extended in some way to provide a notation for making
*queries*.

But it wouldnt be much of a stretch, then, to let the variable scopes
extend across the entire rule. The point being that this shouldnt be
interpreted as a universally quantified implication (which would be a
big stretch from RDF) but only as a way to specify how to derive one
RDF graph from some others, by manipulating them in a graph-oriented
way (adding and deleting triples, merging nodes, moving labels
around). The rule then is a kind of recipe which licences an
inference of graph from graphs, and all the actual graphs that
interact with such a rule - the query that matches the rule
consequent, and the assertions whose subgraphs match the rule
antecedents - are legal RDF 1.0, with no need to change anything.

What this cannot do is have the rules generate new labels (no skolem
functions). That would be a major extension, I'd suggest for phase 2.

Of course it is a simple further extension - really only an
efficiency hack, in a sense - to allow rules to be strung together
into larger rules, and the same processes of matching apply (this is
a trivial consequence of the most general unifier property.)

BTW, this is all just a restatement of Stefan Decker's proposal. He
calls it logic programming, but that's just a red herring; Stefan
calls anything that involves matching 'logic programming' :-)

Pat Hayes
--
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu
http://www.coginst.uwf.edu/~phayes
```
Received on Wednesday, 10 October 2001 17:07:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:53:09 GMT