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

Re: What is an RDF Query?

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Tue, 11 Sep 2001 23:27:42 -0400
To: sandro@w3.org
Cc: phayes@ai.uwf.edu, www-rdf-rules@w3.org
Message-Id: <20010911232742R.pfps@research.bell-labs.com>
From: Sandro Hawke <sandro@w3.org>
Subject: Re: What is an RDF Query? 
Date: Tue, 11 Sep 2001 16:04:09 -0400

> > > I
> > > suggest we ignore the syntax and simply say we're using an RDF
> > > assertional graph (knowledge base) to convey the query (and its response).
> > 
> > Now I have a real problem.  Saying that we are using an RDF assertional
> > graph carries along with it a lot of baggage, at least for human readers.
> > Why not just say that we want to convey a query and a response, and try to
> > figure out what sorts of queries and responses we want to query?
>                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^
> I can't quite parse that, sorry.

Sorry, I meant

	... responses we want to represent?

> > Yes, I know that syntax issues can cause lots of problems.  Yes, I know
> > that it is possible to get into troubles by ignoring syntax issues.
> > However, I think that it is much more likely to have lots of problems by
> > considering meaning secondary to syntax than by considering syntax
> > secondary to meaning.
> I think understand.
> We need something like four languages, right?
>    1) language for asserting facts in a knowledge base
>    2) language for adding inference rules to a knowledge
>       base which allow it to infer new facts
>    3) language for expressing a query of a knowledge base
>    4) language in which the knowledge base replies to 
>       a query.

I'm not, necessarily, arguing for a split, at least not yet.  I'm also not
arguing about any operational aspects of a system, at least not yet.

> I think I could come up with reasonably clear candidates for these
> based on SQL, n3, prolog, some ascii versions of FOL, XML, etc.  But
> the interesting part is that all four languages would have a lot in
> common.   They'd all be something like
>    1)  tell-fact(Expression facts)
>    2)  tell-rule(Expression premise, Expression conclusion)
>    3)  ask(Expression pattern)
>    4)  binding map and/or Expression matched_pattern
> with perhaps a few more details.  So the question is: what do we use as
> the Expression language?
> I lean towards RDF graphs as the expression language.  If we need a
> character-based language, maybe N-Triples would be the clearest.

Why should there be any relationship between the argument of #1, the
arguments of #2, and the argument #3?   Perhaps, there are very different
needs for the language of queries, such as aggregation, grouping, etc.

Consider the case of relational data bases.  The (declarative) query
language (e.g., the declarative portion of SQL)  is very different from the
(declarative) assertion language.  The `rule'' language of some relational
data bases is yet different again, often talking about ``before'' and
``after'' states, etc., etc.

> Then we have the question of what language & protocol we embed the
> expression in -- this is where we say "tell-fact", "tell-rule", etc.
> I suppose we might use SOAP for that, or a C-language API.   Or reify
> the expression and use RDF again, but I'm sensing some resistance to
> that.  :-)

The operational component of a representation system can be very different
from the assertional component.  Consider KQML, which includes, more or
less, facilities for operating on knowledge bases.  It is a very different
language from KIF, which is, more or less, a language for expressing
knowledge bases, and has been used as a ``payload'' language for KQML.  As
you indicate, I don't see much benefit in encoding a KB operational
language (like KQML) in an assertional language (like KIF or RDF).

>      -- sandro

Peter F. Patel-Schneider
Bell Labs Research
Received on Tuesday, 11 September 2001 23:29:42 UTC

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