W3C home > Mailing lists > Public > www-rdf-rules@w3.org > November 2003

Re: SeRQL an RDF rule language: scoping Rules vs Query in W3C work

From: Damian Steer <pldms@mac.com>
Date: Mon, 03 Nov 2003 22:05:28 +0000
To: Dan Brickley <danbri@w3.org>
Cc: www-rdf-rules@w3.org
Message-ID: <m2ism185w7.fsf@evila.danbri.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dan Brickley <danbri@w3.org> writes:

> Hi
>
> Within W3C, we're looking into phase 2 of the Semantic Web activity.
>
> In terms of possible new technology areas, 'Rules' and 'Query' 
> are two topics for recommendation-track work.
>
> So I'm looking at 
> http://sesame.aidministrator.nl/publications/users/ch05s06.html with 
> some interest. The CONSTRUCT mechanism appears to provide a bridge 
> between the world of RDF query systems and RDF-based rule systems.
>
> 	CONSTRUCT
>     	{Artist} <rdf:type> {<art:Painter>};
>                  <art:hasPainted> {Painting}
> 	 FROM
> 	     {Artist} <rdf:type> {<art:Artist>};
> 	     <art:hasCreated> {Painting} <rdf:type>
> 	     {<art:Painting>}
>
>
> In this light, do folks on these lists think it is sustainable to 
> maintain that there's an interesting distinction still to be made 
> between work on RDF 'query' languages vs 'rules' languages.
>
> Can folks here imagine a workable W3C RDF Query WG constrained not to 
> get into Rules WG territory, but to maximise compatibility with a 
> (future? parallel) Working Group on Rule languages for RDF? Or are the
> two technology areas too close?
>
> (I invite continuation of this thread on www-rdf-rules, am sending this 
> to Sesame list too initially)
>
> thanks for your thoughts on this,
>
> Dan

Well here are my unordered, ill-considered, thoughts. You did ask :-)

There is clearly a difference - queries are questions, rules are
statements which (with the addition of a single inference rule: modus
ponens) allow us to infer more triples.

But as for your actual question - difference in the work involved - I
suspect not. However I'm also not sure the work involved would be
significantly different from RDF 2, the successor to RDF.

Let me explain that. Here's a very abbreviated query:

foo:parentOf ?x ?y
foo:parentOf ?y ?z

You could also express that as the question:

data |= exists ?x, ?y, ?z (?x foo:parentOf ?y & ?y foo:parentOf ?z) ?

A query is simple checking whether the data entails that conclusion,
and (the useful bit) giving you all the ?x ?y ?z bindings where the
antecendent holds.

Here's a rule:

foo:grandparentOf ?x ?z := foo:parentOf ?x ?y & foo:parentOf ?y ?z

Which can be expressed as the statement (call it R):

forall ?x, ?y, ?z ((?x foo:parentOf ?y & ?y foo:parentOf ?z) -> 
                                    ?x foo:grandparentOf ?z)

It's easy to show that this holds:

R, _:a foo:parentOf _:b, _:b foo:parentOf _:c |= 
                                    _:a foo:grandparentOf _:c [*]

What I want to suggest is that AIUI this proposed work is related, and
also that it seems to amount to  adding variables, quantifiers, and the
connective material implication ( -> ) to RDF [**]. Although only cwm
(as far as I'm aware) explicitly mentions these additions, all of the
work in this field that I've seen has this at its core.

If we add in the usefully brief syntax rule and query languages have
it looks to me like RDF core pt II work :-)

Less flippantly it isn't simply a question about query vs rules
independence, but query vs rules vs RDF++.

Damian

[*] And you might add OWL to the antecedent, as in
<http://www.cs.man.ac.uk/~horrocks/DAML/Rules/>.

[**] I should add literals as subjects to that list, as seen in
restrictions like ?a =~ "^foo*", and perhaps the disjunction connective.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQE/ptEnAyLCB+mTtykRApZAAKCuozVcFwgTeLqSpCT/8eWJiKcc2QCg2WB1
BP7dW0aeP/r5jUykNDcC66E=
=tM2Y
-----END PGP SIGNATURE-----
Received on Monday, 3 November 2003 17:05:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:46:16 UTC