W3C home > Mailing lists > Public > www-rdf-rules@w3.org > September 2001

Re: Making Rules Out of RDF-Graphs (Re: What is an RDF Query?)

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Mon, 17 Sep 2001 17:28:55 -0500
Message-Id: <p05101010b7cc281e1fab@[]>
To: Sandro Hawke <sandro@w3.org>
Cc: www-rdf-rules@w3.org
>  > >I think we ought to seriously explore the possibility of using an RDF
>>  >graph not only as the assertion language, but also as the query, rule-
>>  >premise, and rule-conclusion languages.
>>  That idea has already been explored by Stefan Decker. He and some
>>  colleagues demonstrated a working system at the DAML PI meeting
>>  (which I think you were also at, Sandro, no?)
>Sorry, I didn't mean to say it hadn't been done, just that it should
>be discussed on this list.
>>  >
>>  >Style 2:
>>  >
>>  >    We say that any variables in the second formula which are not also
>>  >    in the first formula remain as local existential variables.
>>  >
>>  >      (1) EXISTS g1,g3 Grandparent(g1,g3)
>>  >      (2) EXISTS g1,g2,g3 Parent(g1,g2) AND Parent(g2,g3)
>>  >
>>  >    would become a rule like this:
>>  >
>>  >      FORALL g1,g3
>>  >         Grandparent(g1,g3)
>>  >	=>
>>  >         EXISTS g2 Parent(g1,g2) AND Parent(g2,g3)
>>  >
>>  >       (This rule basically says that if two things have a grandparent
>>  >       relationship, there is a third thing and they have a transitive
>>  >       parent relationship through that third thing.)
>>  Why not go to the usual normal form and say that this is two rules,
>>  since its conclusion is a conjunction. If you skolemize, the skolem
>>  function will keep track of the connections for you:
>>  Forall g1, g3 (grandparent(g1,g3) => Parent(g1, GPSkolem(g1,g3)) )
>>  Forall g1, g3 (grandparent(g1,g3) => Parent(GPSkolem(g1,g3), g3) )
>You might well Skolemize it like that internally (you'd have to if you
>were giving it to a Horn logic engine), but if you require users to do
>it, then the rule-conclusion language needs to have functions in it.
>I'm suggesting that we try making RDF rules out of less-expressive
>stuff (to use the technical term) than that.

Why? (Not that there might not be valid reasons, but I wonder what yours are.)

I think there has been too much emphasis on sticking to very 
inexpressive languages. More expressive languages are often *easier* 
for users (though admittedly not for inference engines; but I really 
do not think that the kinds of ontologies we are going to see on the 
semantic web in the near future are going to tax the resources of a 
modern inference engine for full FOL, to be honest.)

>>  >    This may well not be full Horn logic, but I believe it's more
>>  >    expressive than Style 1,
>>  Yes, it is, since it has existentials inside the scope of universals,
>>  which isn't expressible in RDF.  But we could still use RDF as a
>>  language for specifying the 'patterns' to be matched, but allow a
>>  somewhat larger collection of bindings to the variables than just
>>  ground URIs and literals. Think of a skolem function as a kind of
>>  link to a place in the rules where a query engine has a licence to
>>  conclude that something exists which satisfies some RDF, but it has
>>  to use a special name format to keep track of the mutual dependencies
>>  of that thing on other things.
>>  (Hmm, I wonder, could a nested function  term be encoded as a URI? If
>>  so, this *would* be RDF.)
>Yeah, but if we're going to go that route, ...   well it just seems
>like we might as well add nestable function terms throughout RDF.   I
>guess both paths seem worth exploring.

Well, RDF is too fixed to alter in this way now, but RDF+ could allow 
this extension with really minimal change either to the syntax or the 
inference engines that are being built. Once you have a run-time 
variable binder and some kind of search engine that can switch 
bindings between paths, adding functional terms is just a matter of 
extending the binding code to be recursive. Prolog hackers have some 
blindingly fast unifiers which do this very effectively.

>  > Pat Hayes
>-- sandro

IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Monday, 17 September 2001 18:28:52 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:13 UTC