Re: [FLD] Comments on draft dated April 7

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


This is not my department :-)


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

Yes, the presentation syntax is NOT a shorthand for XML. RIF-FLD and
RIF-BLD are *defined* using that syntax. It cannot be any other way unless
XML is used in all the definitions. Since it is not (by obvious reasons),
XML must be derived from the presentation syntax. Otherwise, there would be
a disconnect between the definitions and the language (XML).

> Or maybe it is only me :-)

Maybe :-)

> What about my other comments and questions?

I believe Harold and I took care of them all.


	--michael  


> >>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?
> 
> Cheers,
> 
> Christian
> 
> 
>

Received on Wednesday, 16 April 2008 12:37:56 UTC