RIF BLD comments

Dear all,

find attached some BLD comments of mine. I did the moffline in the 
plane, so apologies, if I mention some things which others already remarked.

I split the comments in purely editorial and non-purely-editorial ones...

Axel
-- 
Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/

Editiorial Comments:


These comments are based on
http://www.w3.org/2005/rules/wg/bld/draft-2007-09-24.html

and might be subsumed by others comments already, apologies if so.


1) Use "data type" or "datatype" consistently

2) "RIF supports XML Schema"
->
 "RIF supports XML Schema Simple Datatypes [add reference to XML Schema Spec]" (check terminollogy with XML Schema Doc)

3) 
"follows the standard textbook conventions for logical syntax"
-->
"follows the standard textbook conventions for logical syntaxes"

4) Change order of itemlist where syntaxes are mentioned:

- Formal Syntax
- Presentation Syntax
- Abstract Syntax
- XML Syntax

-->

- Formal Syntax
- Abstract Syntax
- Presentation Syntax
- XML Syntax

(the abstract syntax is always explained before the Presentation syntax in the text)

5) Use consistent either
"base signature expression"
or 
"basic signature expression"

6) in the examples for well-formed terms there are sometimes greek and sometimes 
latin letters (K) used as signature names (\rho)... I would stick with one consistently.

7) There is a font problem in the examples for 
"h_2{i (i i)=>bool" with the first i

8) "Signatures in the Basic Condition Lagnauge"
-->
 "Signatures in the RIF Basic Logic Dialect Condition Lagnauge" 

9) Correct me if I am wrong: I see no way to distinguish between c and c() in the asn06 nor EBNF.

10)  in the abstract EBNF: what is the rationale of having a slotted attributes for op, arg, side, but not for the (const)name?
There is no production for Const (but should, since op requires a Const and not a TERM)

11) "where TERM* is used as TERM* :== | TERM TERM*"
Do we need to state that, I think this is self-explanatory enough and we can drop that.

12) Whenever a Section is cross-references e.g. "given in Section Primitive Data Types"
we should reference also the Section number, ie. "given in 2.1.2. Symbol Spaces and Primitive Data Types". This occurs several times, but I guess will be  a final edition step.


13) "their free variables carry answer bindings back to the caller"
I suggest to weaken this:
 "their free variables can carry answer bindings back to the caller"

14)  Suggest to replace  "^^label" and "^^TYPENAME" in the EBNF 
by "^^CIRIorIRI" and define "CIRIorIRI", ie. allow either angle bracketted IRIs or 
CIRIs here.

15) "that symbol spaces in RIF include spaces, such as[...]"
-->
"that RIF includes symbol spaces such as[...]"

16) "is not the same as the value space of the XML primitive type anyURI."
"is not the same as the value space of the XML Schema primitive type xsd:anyURI."

17) I don't like the example "abc"^^ade, can't we make "abc"^^ex:ade from it, or do we allow local constants as type labels?

18) in the explanation of s##c
"Informally, this formula states that class s is a member of class c"
--> 
"Informally, this formula states that each member of class s is a member of class c"
or 
"Informally, this formula states that class s is a subclass of class c 
(Note that this doesn't imply OWL or RDFS or other subclass relationships 
in particular related formalisms)."

19) Section 2.2.2

Either replace '/\' by the unicode symbols or use the representation syntax in the example

20) In the Definition of I_Truth for slots, there is some subscripting formatting error with the closing bracket.

21) As for the Bags (multisets) used in the Definition of I_SR, I suggest to use
{{ }}
instead of single curly brackets, to denote multisets.

22) I find it awkward to use xsd:string in the asn. Are primitive XSD types in asn? (Sorry, no network, cannot check.

23) "The mapping to RDF lists is even more direct thant in OWL 1.1[...]"
OWL 1.1 is work in progress, or, respectively not a standard, but a WG just started to work on it. I wouldn't make this statement other than in an editorial note.

Non-editorial comments, clarifying questions and issues:

These comments are based on
http://www.w3.org/2005/rules/wg/bld/draft-2007-09-24.html

and might be subsumed by others comments already, apologies if so.


1) At the end of section 1, an overview paragraph sketching the structure of 
the document would be helpful.

2) We need a subsection/paragraph introducing the useed namespace-prefixes  
and corresponding uris in the beginning of the doc  (rdf:, xsd:, ...) 

3) We might, instead of RDFing the XML syntax think about adding, except

- Formal Syntax
- Presentation Syntax
- Abstract Syntax
- XML Syntax

add a new item: RDF Serialization of Rulesets (kept *independent* of the XML syntax)

4) How are signatures defined in RIF documents? How are sginatures merged 
(this is already mentioned in a note... I think this should go to Arch, probably
in the nect iteration, but we probably want to keep the signature discussion 
still in for the time being, in order to solicit feedback)

5) Just to be sure again:  A signature ()=>i  is not the same as i, yes, ie 
  constant/propositional atom  c
is not the same as
  term/atom  c()
AND we want to allow BOTH in BLD, yes?

6) In the next version, we might want to put examples directly after definitions, 
instead of the  examples for signatures all in one place. Anyway, as signature 
in RIF BLD are implicit anyway, we might move the whole signature discussion 
out of BLD anyway.

7) In the signature example, what exactly is meant by 
"(polymorphic) signature" ?
that there might be a problem for arbitrary polymorphism.
I am unsure about the semantics definitions, in case there are different 
signatures with the same arity for one and the same term, e.g.
p(a b)

sig1{ (i i) => sig2 (i i) => sig2 } how is that covered in the current semantics?
Will return again to that  later on...

8) In the section about symbol spaces we use rdf:XMLLiteral without having explained
CIRIs or our use of namespace prefixes at all. I think we should do that in the 
very beginning.

9) "the set const of all constant symbols has subsets [....]"
Do we want to say:
    "the set const of all constant symbols has disjoint subsets [....]"
?

10) Also, here we mention a particular set of primitive datatypes/symbol spaces:
"The following primitive datatypes are supported:[...]"
 Is this RIF BLD here or RIF what we are speaking about?
Whereas we make this distinction clear in the discussion on signatures, this 
is not the case for Symbol spaces. 

So, we should have paragraphs:

 Well-formed terms
 Signatures
 Signatures in the RIF Basic Logic Dialect Condition Lagnauge
 Symbol Spaces
 Symbol Spaces in the RIF Basic Logic Dialect Condition Lagnauge

11) I have a general problem with the basic signature name "bool"
 it should be renamed "tv" or "truth" to reflect the generic semantics 
definition which speaks about truth value orders rather than boolean 
logic only.

12) In the Section " Signatures in the RIF Basic Condition Lagnauge" as for variables, 
I would add for explanatory purposes:

"All variables are associated with the signature i{}, so they can range only over individuals [(add:) and not appear in predicate or term constructor position]."

13) The terms striped, stripe-skipped, unstriped should be referenced/explained 
before used in the beginning of section 2.1.1.2, (yes, this is already marked TODO) 
maybe by adding a glossary. For the first version of the BLD we could maybe 
just avoid these terms for the moment, and replace

"i.e. in a fully striped manner"
-->
"i.e. all properties and classes are made explicit in the syntax"

(and leaving an editors note to introduce the terms striped, stripe-skipped, unstriped l8er on)

Also in Section 2.1.1.2.2 "striped normal form" --> "fully explicit syntax"?

14) In the asn for conditions, it appears that the difference between ordered 
and unordered lists cannot be made explicit in asn06, see example

 declare (which should be unordered)
 arg (which should be ordered)

Also, and again referring to comment 5)... we allow empty arg lists... yes?
Correct me if I am wrong: I see no way to distinguish between c and c() in the asn06 nor EBNF, however, we have different dignatures for those: 
 i 
as opposed to 
 ()=>i

15) As for the 'ordered' constraint, I guess we'd in the end just be better off in the metamodel to reference the parameter position in the meta-model.
 I had proposed that a while ago in the RIFRAF ontology, where I suggested named and positioned parameters for terms (that way, you could even have ordered named parameters, which I wouldn't know how to produce in the current meta-model):
http://www.w3.org/mid/45B55A11.9000402@urjc.es

16) For variables, to be compliant with SPARQL, we should allow both, the '?' and the '$' versions for denoting variable names.  I would suggest to copy their grammar for variables.

17) I would rather remove the abs2con4g part in the published WD.

18) "All variables introduced by quantification must also occur in the quantified formula"
Why, I see no reason for this restriction?

19) In the condition example, remove the second part with the RIF Horn Rule, and rename RIF condition to "RIF BLD condition". The Horn Rule example should go to Section 3.1 Horn Rules

20) "An absolute IRI that identifies the symbol space" 
Why absolute?

21) As for the symbol spaces, should we declare rif:local the default, or do we want the user to always have to make the type explicit for ANY literal?

22) As for the "TODO: define CURIs":
a) this should be done earlier in the document
b) I'd call it CIRIs and not CURIs

23) Can be any set and no apriori equalities among the members of the type rif:iri are assumed.  a) Add reference to IRI normalization RFC here. b) to make things clear, why not go the way SPARQL did:

"Relative IRIs are combined with base IRIs as per Uniform Resource Identifier (URI): Generic Syntax [RFC3986] using only the basic algorithm in Section 5.2 . Neither Syntax-Based Normalization nor Scheme-Based Normalization (described in sections 6.2.2 and 6.2.3 of RFC3986) is performed."

I think I remember there was some complaint that this is verbose, but I find it 
much clearer that way.

24) "Symbols with ill-formed lexical part. RIF constant symbols that belong to one of the RIF-supported symbol spaces must be well-formed, i.e., their lexical form must belong to the lexical space associated with the symbol space. For instance, "123"^^xsd:long has a correct lexical form, since 123 belongs to the lexical space of the data type xsd:long. In contrast, "abc"^^xsd:long is ill-formed, as it does not have a correct lexical form. A compliant RIF interpreter must reject such symbols."

A warning here. I would handle this statement with care.
This might hamper later on adding/handling built-ins which produce 
(possibly ill-typed) literals...  well, would probably be fine, if we include error handling f or built-ins similar to SPARQL Filter built-ins which use a three valued logic (that we should check whether it fits with our generic definition of truth values.)

25) Section 2.1.3.1:
 I agree with Dave's comment that the XML syntax for signatures is, in this form not to be included in the WD, since it wasn't really discussed, unless we find agreement in the F2F on it. BTW, I want to stress comment 11) in that context again, the name "bool" is inadequate for the generic semantic model of truth values we have.

Also, I find the whitespace separated
 s1 s2 s3
in the proposed XML syntax not optimal, labels for (arg) can be used.

26) 
I_C vs. I_F : again issues 5)+14) cont'd, we semantically treat c, c() differently, but syntactically, I don't see at the moment, how we can syntactically express this.

27) As for I_F, I have a question how this connects to signatures.
I.e. if there are two signatures for the same arity for f, e.g. f has signature
sigf{ (i i)=>sig1 (i i)=>sig2}
then, there are also two I_F associated?
(This question doesn't arise for BLD, so we can leave it aside for the moment, 
but I think we shall keep it in mind and ask ourselves about what same 
arity/different arrow signature expressions imply. At least to me, it is unclear)

28) "slotted arrow expression":
  I am not sure what thew y_i's are: should they be signatures indeed, or not rather constants? We want here to be able to define the type for a named parameters, how do I do that, if y_i is a signature?   

29) Section 2.2.1.2.1, asn06 version:
 This adds constructs such as 
 list TERM TERM
and
 TYPENAME?
ie. modifies asn on the fly as needed. 
it is also explained in the paragraph afterwards. I assume this is more for discussion in the WG and not for the published workingdraft, I would either like to stick to a stable version of ASN, or leave asn aside for the published working draft.

30) similarly as to issue 17), I suggest to rather remove the abs2con4g part in the published WD, same later on for the Rules EBNF-2-EBNF mapping.