RE: What is an RDF Query?

> >Yes, but in a relational/deductive database one typically
> >considers the intensional knowledge, i.e. the rules/views to
> >be quite stable once defined (or "asserted", if you wish), and
> >the extensional knowledge, i.e. the set of facts that may be
> >asserted, as subject to frequent changes.

> Ah, that is a very controversial view, and we could argue about it at 
> length. But in any case, I don't see anywhere in any semantic theory 
> where this kind of distinction can be expressed, so it seems 
> irrelevant to the discussion.

It's a pragmatic distinction between frequently changed facts in
a fact base (or XML page) and rarely changed rules (possibly in a 
separate rule base or XML page) implying that what you typically 
assert/retract are facts, and therefore you want to have a separate 
language for them defining their admissible form wrt allowed 
connectives (e.g., may a conjunction or a disjunction or a negation 
be asserted?). This may be called an assertion or input language,
as opposed to the more expressive query language (which is typically
a superset). I don't think that pragmatic distinctions need a semantic 
theory to be relevant.

> >Obviously, any practical KR system, such as Prolog, relational
> >databases, or RDF, has an assertion (or input) language defining
> >the admissible (logical) expressions that may be asserted/inserted
> >into a KB, and it has a query language defining the admissible
> >expressions for querying/retrieving knowledge.
> 
> Sorry, but I don't find  that at all obvious, particularly if it is 
> supposed to imply that these must be different languages.  

The assertion/input language typically is a subset of the query 
language with respect to admissible connectives/operators. This 
holds for SQL and Prolog, and I guess, it will hold for an 
RDF-based KR system (where a knowledge base consists of a 
number of XML pages with RDF content) as well. For instance,
you cannot assert/represent a disjunctive statement, such as
"the author of this document is Pat Hayes or Gerd Wagner"
in RDF, right? But it should be possible to pose this statement 
as an RDF query.

> >Both with respect to bottom-up and to top-down evaluation
> 
> These terms 'bottom-up' and 'top-down' are meaningless to me, I'm 
> afraid. 

They are standard terms in deductive databases and logic programming
(corresponding to forward and backward chaining).

> ... This allows assertion to be a rule with an empty body. A query 
> could be a rule with an empty head, 

Normally, a rule with an empty head is interpreted as a denial
(since implying the falsum amounts to negation), used in the
logic programming literature to express certain forms of integrity 
constaints (namely something that must not be the case).

Anyway, I think it is much more natural to consider the languages
for facts and that for rules separately and not impose such an
artifically appearing syntax requiring to express an assertion as 
a rule with an empty body. Since we have assertions and queries
already in a system without rules, why should we change their
syntax when we add rules to the system? Of course, we may then
make the observation that an assertion formula "A" corresponds to a 
rule "-> A" with empty body but that doesn't force us to express
assertions in this way.

> <speech>
> My basic point is that the functional roles of expressions and parts 
> of expressions in an inference or rule-manipulating system should not 
> be identified with their syntactic or logical descriptions, since the 
> same structure, with the same logical meaning, can often be used for 
> different functional purposes in different contexts. 
> ...
> </speech>
 
That's certainly true. But still, we may make the useful observation
that those formulas that may be posed as a query to an RDF knowledge 
base can also be used as an antecedent of a rule that is evaluated on
the basis of the RDF KB, and those that may be used as an assertion 
(that can be added to the RDF KB) can also be used as a consequent 
of a rule, right? Typically, the former may contain disjunction and
negation while the latter cannot.

-Gerd

--------------------------------------------
Gerd Wagner        Email: G.Wagner@tm.tue.nl
http://tmitwww.tm.tue.nl/staff/gwagner

Eindhoven University of Technology
Faculty of Technology Management
Department of Information & Technology 
P.O. Box 513       
5600 MB Eindhoven    Tel: (+31 40) 247 26 17
The Netherlands      Fax: (+31 40) 243 26 12

Received on Thursday, 20 September 2001 08:23:26 UTC