Re: [FLD] Comments on draft dated April 7

Hi Christian,
thank you very much for the comments on FLD.

FLD can be extended to support production rules and more. Including the
semantics (at least, the part of the semantics, which you outlined in PRD).
We could perhaps discuss this at the next F2F, but I will not have the time
to write this up (most likely). I could explain it at the f2f.
But clearly, this is for Ph2.

Regarding interoperability with other dialects, this is something to think
about. It is closely related to the issue of modules, which was discussed
on the list.

Finally, regarding the preeminence of the presentation syntax, you should
understand that the syntax and its semantics must be defined precisely
before it is cast in XML. I do not see any other way how to bridge from the
formal part to XML.  Clearly, using XML to define the formal stuff is
untenable.


	cheers
	  --michael  

> Michael,
> 
> 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 
> document.
> 
> 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 
> normative.
> 
> 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...
> 
> Cheers,
> 
> Christian
> 
> [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:38:13 UTC