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

>    [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 UTC