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

Re: [FLD] Comments on draft dated April 7

From: Christian de Sainte Marie <csma@ilog.fr>
Date: Tue, 15 Apr 2008 14:13:56 +0200
Message-ID: <48049C04.4050009@ilog.fr>
To: Michael Kifer <kifer@cs.sunysb.edu>
CC: RIF WG <public-rif-wg@w3.org>

Michael Kifer wrote:
> FLD can be extended to support production rules and more [...]  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.

Agree completely.

> 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.

I am not completely up-to-speed wrt the mailing list yet :-)

But I also had things like Sandro's fallbacks in mind; or forbiding that 
two dialects use the same construct with different semantics or define 
different constructs for the same semantics; things like that...

> 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.

Absolutely, esp. for FLD. My point was more about how things are 
presented: it is different to say that the prez syntax is shorthand for 
the XML, in order to make the formal definitioni easier (as I would 
prefer) or that the XML syntax is derived from the prez syntax (as it is 
introduced in the current draft).

Or maybe it is only me :-)

What about my other comments and questions?
>>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?


Received on Tuesday, 15 April 2008 12:14:49 UTC

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