- From: Pat Hayes <phayes@ai.uwf.edu>
- Date: Mon, 17 Sep 2001 17:28:55 -0500
- 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 phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes
Received on Monday, 17 September 2001 18:28:52 UTC