comments on BLD draft part I

[I will send editorial comments in a separate message]

0) Side remark: it seems to me that if we were to adopt the abstract
EBNF syntax (section 2.1.1.2.2), then we no longer need the presentation
syntax; this abstract EBNF syntax could be used wherever presentation
syntax is currently used.

1) General: I agree with Stella that there should be one definition of
semantic structures for the condition language.
I also think that for the BLD document, the semantics of conditions can
be presented together with the semantics of rules.

2) General: I think we should somehow mark in the document which parts
will go to the framework documents and which will go to the BLD document.

3- section 2.1.1: I do not understand why there is still a "formal
syntax"; the presentation syntax is used throughout the document for the
definition of syntax and semantics; the "formal syntax" is only used in
section 2.1.1. I suppose this is an error, and the "formal syntax"
should be removed?
4- section 2.1.1: it seems odd to me to associate signatures with
variable symbols, because occurrences of the same variable symbol under
the scope of different occurrences of quantification symbols are
interpreted differently.  So, I think that either all variable symbols
need to have the same signature, or the signature is specified together
with the quantifier.
In any case, I expect that the BLD document (as opposed to the framework
documents) will not define signatures for variable symbols.
[in fact, I don't think we need signature expressions at all in BLD]

5- section 2.1.1.1, signatures:
  a- I think we should use URIs for the basic signature expressions i
and bool, as well as the other names used in the definition of signature
expressions (SigNames).
  b- I did not understand why signatures have a name.  Can't we just use
sets of signature expressions? I think the signature name provides an
unnecessary indirection in the definitions.
  c- Why are i{} and bool{} used to represent the context of individual
objects and atomic formulas?  It seems to me that basic signature
expressions i and bool should be used, rather than signature names; a
constant symbol c would then have the signature {i}.
  d- There do not appear to be abstract and presentation syntaxes for
signatures.
  e- The names i and bool are not in line with Sandro's proposed naming
convention.

6- rif:iri and rif:local need to be renamed to conform with the naming
convention, if adopted; they should probably be called rif:IRI and
rif:LocalSymbol.

7- section 2.1.1.2.1: CONSTNAME, TYPENAME and VARNAME are not defined
8- section 2.1.1.2.2: Const, CONSTNAME, TYPENAME and VARNAME are not defined
9- section 2.1.1.3: CONSTNAME, TYPENAME and VARNAME are not defined
10- section 2.1.1.3: the definition of the presentation syntax should
include the requirement that every Uniterm and every constant is a
well-formed term and every item is a well-formed atomic formula
11- section 2.1.1.3: it is unclear what abs2con4g is doing here.
Firstly, the abstract EBNF syntax seems redundant with the presentation
syntax; second, such a mapping, if deemed important, should be moved to
an appendix.
12- section 2.1.2: the definition of constant symbols is a somewhat
unclear, because it is only (and only partially) defined through the
presentation syntax. Furthermore, I do not like the term "lexical form"
to refer to literal; I would expect that term to refer to the lexical
representation of the entire symbol. I propose to rename it to "lexical
part".

I propose to define a constant symbol as a pair (literal, label), where
literal is a sequence of Unicode characters and label is a URI
identifying a symbol space. The Unicode string literal is called the
*lexical part* of of the symbol.  We write a constant symbol (literal,
label) in the presentation syntax as:
"literal"^^label

13- section 2.1.2: it is not entirely clear what is meant with
"semantics of a symbol space".  It's also not clear what is meant with
"value space is fixed". If the semantics of a symbol space defines the
value space, then how can the value space not be "fixed"? Furthermore, I
do not see the use of associating a value space with a symbol space.
I propose to amend the definitions as follows:
The symbol space consists of a lexical space and one (or possibly more)
URI(s) which identify it (as it is currently defined).  A datatype is a
symbol space which additionally includes a value space and a lexical to
value mapping (where the value space and lexical to value mapping are as
currently defined).
Additionally, I propose to include a little bit of explanation about
symbol spaces and data types here.

14- section 2.1.2: it is unclear to me why we would need a notion of
"primitive datatypes"; we can simply use the notion of a "datatype"
15- section 2.1.2: I think we decided a long time ago to support the
xsd:integer datatype; yet, it is not mentioned in this section
16- section 2.1.2: the lexical spaces of the XML schema datatypes used
in RIF do not all needs to be defined here; a simple mechanism for using
XML schema datatypes in RIF is sufficient.  For example:
RIF supports the use of the following XML schema datatypes: string,
integer, ...., where each datatype is identified by the XML Schema
canonical URI reference for the datatype,
http://www.w3.org/2001/XMLSchema#name, where name is the local name of
the datatype, and the lexical space, value space and lexical to value
mapping are as defined in [XML schema datatypes].

Similar for the RDF XML datatype, which is, by the way, he used for
representing XML content, rather than XML documents.

The only two symbol spaces which are really defined by RIF are rif:iri
and rif:local.

17- section 2.1.2: it is unclear to me why the list of datatypes is
fixed. By fixing this list, every implementation needs to support all
mentioned data types, and no other data types can be used in
meaning-preserving fashion. I propose to make a list of datatypes which
need to be supported by every RIF implementation (e.g. xsd:string,
xsd:integer), and a list of additional data types which are recommended
for use with RIF (e.g. xsd:gYearMonth)


More to come

-- 
Jos de Bruijn            debruijn@inf.unibz.it
+390471016224         http://www.debruijn.net/
----------------------------------------------
The third-rate mind is only happy when it is
thinking with the majority. The second-rate
mind is only happy when it is thinking with
the minority. The first-rate mind is only
happy when it is thinking.
  - AA Milne