Re: [FLD] Comments on draft dated April 7

Christina,
Here are some answers to the rest of your concerns.
I put in almost all of your comments, so I will not reply to those items.

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

I think the above is vague and confusing, not the other way around (sorry,
could not resist :-).

XML syntax is NOT a common serialization for many rule languages out there.
It is an interchange format for them. If you want (I do) precise
definitions then they have to talk about a concrete language (the FLD
presentation syntax) and its serialization.

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

The above has no meaning - really. In what sense does this framework
introduce general principles for serializing concrete languages? Which
languages? In what way?  The only concrete language that the framework
deals with is the FLD presentation syntax. Your reference to "concrete
languages" is anything but concrete.

> - In section 1, the introduction of name argument terms ...
> Btw, why must argnames be disjoint from both const and var (sect 2.2)?

For Const, it is not essential, but you do not want to write named arg
terms as 
person("name"^^xsd:string -> "csma"^^xsd:string "address"^^xsd:string -> "...")

Vars are excluded because then our claim that terms with named arguments
easily map to positional terms would not be true. We will not be able to
claim that arguments do not repeat and, worse, unification of such terms
would be worst-case exponential.

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

No, symspace ids cannot be constants or else the definition will have
unfounded recursion. I added a comment to make it clear.

> - 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];

It is prominently explained in at least two places (Sec 2.1 and 2.7) that
RIF dialects can limit the classes of terms and formulas they
support. Signatures only affect the context, so having a signature for
something (like # or ##) does not mean those terms are necessarily
included.

It might be possible to phrase this definition better, but I do not see an
obvious candidate (which does not introduce worse problems).
I think this is explained adequately.

> - 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 do not see how you got to this conclusion. Dialects (e.g., BLD) do not
limit the lists of symspaces and builtin schemas, which they allow.


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

How did you get to conclude that metadata cannot be attached to a
single rule?

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

Not sure.  BNF symbols with capitalized (as opposed to all-uppercase) serve
as XML tags. So, from the grammar point of view they are not needed, but
they are useful for establishing a direct correspondence with the XML
syntax.


	--michael

Received on Tuesday, 15 April 2008 16:04:54 UTC