Re: comments on BLD draft part I

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

This is not very relevant right now. We are talking about the 2nd
draft. After that it the document will be split. It is a waste of time to
merge these sections now and to discard these changes a few days later.

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

Again, we are talking about the 2nd draft right now.

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

The formal syntax is used in the semantics, not the presentation syntax.
Well, the two are almost the same, but the presentation syntax is still too
inconvenient for formal development. Maybe we should align them better
so that presentation syntax will be an extension of the formal syntax
(filling in the details that are not needed for the formal stuff).

There is value in having a presentation syntax, since it provides common
grounds for people to write examples. Giving a second thought to what we
discussed today, you are basically suggesting to use the presentation
syntax in the examples but not give it a BNF. Not clear what is the benefit
of it. (But I agree that we should think whether we need all these
syntaxes.)

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

And it is not weird to associate signatures with quantifiers?
Open any textbook and you will see that in defining sorted logics people
always associate sorts with variables, not quantifiers. This is also the
best way to go for a practical textual language.

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

This is precisely what the document says!!

It is in anticipation of the comments like the above that I proposed to
split the document in two: In any concrete dialect much of the complexity
of the overall framework is not needed.


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

Not clear why this is necessary. Certainly it is not necessary for the BLD,
since all signatures are implied. Let's not do things that are clearly not
necessary and which we might regret later.

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

So you will write expressions like this (just as an example)?

    {
       {i*i->i, i*i*i->i} -> bool,
       {bool*i->bool, i*bool->i}-> {i*i->i, i*i*i->i}
    }

instead of

    sig1{i*i->i, i*i*i->i}
    sig2{bool*i->bool, i*bool->i}
    sig3{sig1->bool, sig2->sig1}

Which one is easier to write and understand? The first one eliminates one
term, signature name, but I think the price is heavy.
On the other hand, this price is paid only in the examples in the
"frameworks" document. On yet another hand, signatures are likely to be
used almost exclusively in the frameworks document. So?...

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

*Signatures* are associated with symbols, not signature expressions.
As Chris mentioned, in the polymorphic case these are not the same.

>   d- There do not appear to be abstract and presentation syntaxes for
> signatures.

It is not needed. The XML syntax should also be removed. It is premature
and probably best be done if and when we encounter a dialect where
signatures would need to be user-defined as opposed to being implied.

>   e- The names i and bool are not in line with Sandro's proposed naming
> convention.

They do not have to be. So far they are not going to be visible in a dialect.
If and when we run across a dialect where this is going to be necessary
then we can consider what the appropriate names should be.


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

sure. not in this draft though.


> 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

Sure. But we did not want to go into this low level of detail in this draft.

> 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

No, this is not needed. The section "Specifying Signatures in RIF Dialects"
takes care of that. I added a sentence there to clarify that.

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

The abstract syntax is not redundant. It is very convenient, since both the
presentation and the XML syntaxes can be derived from it in a
straightforward manner.

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

Why partially? It is defined partially only in the sense that there is a
possibility of adding more types of symbols.

Symbols are defined in formal preliminaries in a very abstract form and
then made concrete in the presentation syntax. You are right in that they
should also be defined in the abstract 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".

done.


> 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

This is appropriate for the abstract syntax. Other than that, this is
equivalent to what we have now. 


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

Some of these are good suggestions, and I already put them in. I also
tightened the language. But I am not sure that the change about the value
space is a good one. I find it convenient to be able to talk about the
value space in all cases.

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

The notion of a data type raises false expectations that these types can be
"complex" as in XML or object-oriented DBs.

> 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

I believe we decided to support xsd:long.

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

I do not see harm in spelling these out.


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

The list of data types is not fixed. It is in flux.
It is a minor issue, but I am not against recommended data types.
Or, maybe, we could use a more general mechanism.
We need to think what does it mean for an exchange language to "support" a
data type. Is it a matter of issuing an error when the lexical space is
violated? To support certain inferences? If the latter, then I fail to see
what does it mean to be a type "recommended" for use with RIF.




	--michael

Received on Wednesday, 26 September 2007 01:59:57 UTC