RIF and QL

[summary: SPARQL queries and queries in other query languages in RIF rules.]

Dear RIFers,

During yesterday's (24 Jan.) telecon, the issue has been raised
whether SPARQL queries, or queries expressed other query languages,
could appear in bodies (= condition parts) or heads (= consequence
parts) of RIF rules.

It has been noticed that this approach would have the advantage of
elegantly ensuring the compatibility of RIF with SPARQL and the other
query languages considered.

It has also been noticed that this approach would have the drawback
of making RIF an extension of one, or worth: several, query languages,
what would make RIF hardly definable within the time given (1 to 2 years).

I would like to submit the following views concerning the declarative
fragment of RIF (ie the following is not about updates, actions,
(re)active rules, etc. that RIF might have to offer):


1. RIF should be a "lingua franca" (literally "French speech", meaning a
language used as common or commercial tongue among peoples of diverse
speech).


2. The RIF lingua franca should abstract out "the diverse speech" by
dis-considering (a) idiosyncracies, (b) computational choices, as well
as (c) some semantic choices of query languages and rule
languages/engines. These three points is motivated below.

First, let draw a line between "rule format" and "rule language", both
being formal languages (ie something else than human/natural
languages):

- A rule format has a (unambigous) syntax and a declarative semantics
(preferably in the form of a model theory) but does not necessarily
have a computational semantics.

- A rule language also has a (unambiguous) syntax and a declarative 
semantics
but also a computational semantics (and preferably a prototype implementing
this computational semantics).

Second, let recall the difference between declarative and
computational semantics. The difference is that the former might
ignore computational aspects such as an evaluation order for
conjunctions and disjunctions, ensuring termination through memoing,
and optimizations.

Third, let discuss the three points (a), (b), and (c):

(a) Idiosyncracies (like writing "\+" instead of "not" in Prolog) should
obviously be dis-considered for otherwise we shall end up with a
dictionary of notations. Such a dictionary might be useful but should
not be an objective of the RIF WG.

(b) Computational choices must dis-considered for otherwise we shall
end up with defining a rule language, not only a rule format, and
furthermore a rule language extending several other rule languages. It
is doubtful whether this is at all possible. It is undoubtedly
impossible within the time scale the RIF WG has.

(c) More subtile is that some (not all!) semantic choices of query
languages and rule languages/engines should be dis-considered. Let us
consider three examples.

First, consider a rule with fuzzy truth values like:

R1 = if a:0.3 and b:0.2 then c:0.25

Obviously, how the fuzzy truth values are combined is an important
part of the rule's semantics. As it is well-known, how fuzzy truth
values are combined is one of the essential aspects that distinguish
fuzzy rule languages. Therefore, it is desirable that RIF gives a way
to express that rule R1 has been specified after fuzzy truth
combination C.

However, rule R1 can also be used after the following (weaker) meaning:

R1' = if a is possible and b is possible then c is possible.

Arguably, RIF is needed precisely for conveying R1 making it possible for
the recipient to interprete it a R1'.

Second, consider the following rules with non-monotonic negation:

R2 = if not a then b
R3 = if not b then a

The ruleset {R2, R3} might have been specified in a context where it is
used under the well-founded semantics. Under the well-founded semantics,
in the absence of other a- and b-headed rules, {R2, R3} means that a and
b are unknown.

However, the ruleset {R2, R3} can also be used after the stable model
semantics where it means a or b is true.

Third, consider a rulle stating that a computer science student not 
attending the lecture on RIF must attend the lecture on Prolog.

This rule can be used for making a list of those student who should 
attend the Prolog lecture. In this case, the rule negation is 
non-monotonic negation.

This rule can also be used  in determining consequences of the 
regulationwithout considering students and student registrations to 
lectures.
In this case, the rule negation is monotonic negation.


These example show that there might be cases where a Web actor need the
one semantics, another another semantics of non-monotonic negation. This
would be the case if the first actor, using the well-founded semantics,
is interested in derivable facts (ie investigates only necessities), while
the other actor is also interested in derivable disjunctions (eg for
investigating possibilities).

Of course, RIF cannot be free of declarative semantics. A RIF "and"
must mean a logical "and", a RIF fuzzy truth value must have a meaning
and a RIF "non-monotonic not" must mean a "non-monotonic not". But
these meanings must leave ways open to re-interpretations --
admittedly within a yet to define reasonable scope.


3. The RIF lingua franca should offer a way to procedurally attach
SPARQL queries, and queries expressed in other query languages, in rule
bodies.

RIF could support such procedural attachments under the following
assumptions:

- Expressions in a query language may appear in rule bodies
(= condition parts) with an interface stating sets of bindings they
provide for logical variables (occurring elsewhere in the rule).

- It is the responsibility of the query language
designers/implementers to provide with such an interface.

- It is the responsibility of the RIF designer to specify the format
of the interface.

- It is the responsibility of users of RIF, ie RIF programmers, to
ensure that the procedurally attached queries make sense. Especially,
RIF does not have to provide with a declarative semantics
considering/encompassing that of query languages.


Greetings

Francois

Received on Wednesday, 25 January 2006 12:43:19 UTC