W3C home > Mailing lists > Public > public-rif-wg@w3.org > April 2008

[FLD] Comments on draft dated April 7

From: Christian de Sainte Marie <csma@ilog.fr>
Date: Mon, 14 Apr 2008 20:20:14 +0200
Message-ID: <4803A05E.6040506@ilog.fr>
To: Michael Kifer <kifer@cs.sunysb.edu>, RIF WG <public-rif-wg@w3.org>


Here a couple comments on RIF-FLD. I started annotating the April 7 
draft on April 9, and did not care to move to the new snapshots, so, 
some of the comments may be out of date.

In my opinion, this is a very good and very useful document. My only 
regrets are that:
1. it covers only the logic side of RIF; and
2. it does not address the issue of dialects inter-operability.

If the document could be extended to cover these two topics, it would 
essentailly serve the purpose we had in mind for the Architecture 
document (ARCH [1]).

Re 1., the syntactic framework would need only little changes to cover 
RIF dialects concerned with more procedural rule languages, but the 
semantic part would need to be rewritten extensively to cover non model 
theoretic semantics. Not for FLD WD1, obviously :-)

As long as the document covers "only" logic dialects, we should be 
careful and replace "RIF dialect" (resp. "dialect of RIF" etc) by "RIF 
logic dialect" (resp. "logic dialect of RIF" etc) everywhere in the 

There are also references to "RIF formulas", "RIF group formula" etc, 
where RIF should probably be qualified as well (e.g. in section 3.7 - 
Logical entailment").

Another general concern about the document is the proeminence it gives 
to the presentation syntax: in several places, it implies that every RIF 
(logic) dialect must have a presentation syntax (e.g. section 1: "for 
each dialect, its concrete XML syntax is a derivative of the dialect's 
presentation syntax)"; section 4: "RIF requires that the presentation 
syntax of any logic-based RIF dialect must be a specialisation of the 
presentation syntax of RIF-FLD").

I understand that a presentation syntax may be useful and desireable in 
some, and maybe in most, cases, but I see no reason why RIF should make 
it mandatory, especially since only the XML-based interchange format is 

In the same way, introducing the XML serialisation framework as 
"[defining] the general principles for serializing the various parts of 
the presentation syntax of RIF-FLD" is slightly confusing: the XML 
syntax of a RIF dialect is a common serialisation for the many different 
syntaxes of the (concrete) rule languages covered by that dialect; and, 
thus, RIF-FLD XML serialisation framework should, in my opinion, rather 
be presented as defining the general principles for specifying such a 
common serialisation (for the logic rule languages covered by a RIF 
dialect that specialises FLD).

One way to avoid the confusion could be, in section 1, when the 3 main 
components of RIF-FLD are first introduced, to start with the XML 
serialisation framework, defined as above (that is: "the general 
principles for specifying such a common XML serialisation for the 
concrete logic rule languages covered by a RIF dialect that specialises 
FLD"); and to introduce the syntactic framework (and the prez syntax) 
and the semantic frameworks as the means to achieve that goal.

More specific comments follow:

- In section 1, the introduction of frames says that "there are certain 
syntactic similarities [...] quite different". I would remove that 
sentence, or, at the very least remove the words 'certain' at the 
beginning and 'quite' at the end;

- In section 1, the introduction of name argument terms equates them ro 
"rows in relational tables", whereas, in section 2.4, the argnames in a 
term are said to be "not necessarily distinct" symbols: a clarification 
(e.g. about this being shorthand to denote several rows in a single 
term) might help avoid some confusion. Btw, why must argnames be 
disjoint from both const and var (sect 2.2)?

- the use of the term "symbol space" is sometimes a bit confusing 
(because of it is sometimes used to denote a symbol space, and sometimes 
the identifier of a symbol space, I guess). E.g. in section 1, it is 
written that "symbol spaces can be used to identify any object" and that 
they "syntactically look like IRIs";

- Re symbol spaces again, in section 2.1, "the symbol spaces determine 
the syntax of the symbols that are allowed in the dialect": shouldn't 
that be "the syntax of the constant symbols"? If not, how symbol spaces 
determine the syntax of variable symbols and argument names should be 
mad emore explicit;

- More about symbol spaces: in sect. 2.3, it is written that "each 
symbol in const belongs to exactly one symbol space" and, later, it is 
implied that "the set of all symbol spaces [partitions] const": how is 
this compatible with symbol spaces that include other symbol spaces 
(e.g. data types that are sub-types of other data types)?

- a question, more than a comment, re symbol spaces identifiers: do they 
belong to const? If so, can the classification terms be used to assert 
that a constant belongs to a symbol space? Or that a variable binds to 
values of a given data type?

- All RIF dialect that specialise FLD must include a # and a ## 
signature: does that imply that all logic dialect (including RIF Core) 
will have to support classification terms? If yes, this is an open issue 
(issue-48 [2];

- FLD does not make a difference between a dialect and an application of 
a dialect. E.g. section 2.7 implies that adding external schemas amounts 
to specify a new language/RIF dialect (whereas it might just define a 
new application, just like new predicate names). This confusion is a 
minor annoyance, but still an annoyance...

- I did not catch up with the discussion on meta-data yet, but I am 
suprised that, according to the Group construct, meta-data are allowed 
at the rule set level only: what about meta-data attached to single 
rules (e.g. rule names etc)?

- A (maybe) minor detail: in the EBNF, what is the purpose of the "Atom" 
production? That is, why isn't "Atom" removed and replaced directly with 
UNITERM in the ATOMIC production?

That's about all...



[1] http://www.w3.org/2005/rules/wg/wiki/Arch

[2] http://www.w3.org/2005/rules/wg/track/issues/48
Received on Monday, 14 April 2008 18:20:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:50 UTC