RE: [BLD] review of snapshot version http://www.w3.org/2005/rules/wg/draft/ED-rif-bld-20080410/

Axel,

Thanks for pointing us to all of these possible improvements.

> General:
> a lot of the (C) comments refer to that the "Direct Specification" of 
> BLD still often refers to the FLD document and is not entirely 
> self-contained.

At least in the current round, we could accommodate this
through rewordings like these:


"1 Overview":

RIF-BLD is defined in two different ways -- both normative:

* Independently of the RIF framework, for the benefit of those who
desire a quicker path to RIF-BLD and are not interested in the
extensibility issues.
-->
* Mostly independent of the RIF framework, for the benefit of those who
desire a quicker path to RIF-BLD and are not interested in the
extensibility issues.


"2 Direct Specification of RIF-BLD Syntax":

This normative section specifies the syntax of RIF-BLD directly, without
relying on RIF-FLD. 
-->
This normative section specifies the syntax of RIF-BLD directly, relying
only on
sections "Symbol Spaces" and "Schemas for Externally Defined Terms" of
the "RIF-FLD document".


"3 Direct Specification of RIF-BLD Semantics":

This normative section specifies the semantics of RIF-BLD directly,
without relying on RIF-FLD.
-->
This normative section specifies the semantics of RIF-BLD directly,
relying only on the
section "Primitive Data Types" of the "RIF-FLD document".


Rather than splitting off sections such as "Symbol Spaces" of the 
RIF-FLD document into yet other documents or (shared?) appendixes,
I think we should allow for such clearly delineated dependencies.

Please find more remarks about some of your review points below.

Harold



(E) Mathematical English -> mathematical English

I modeled the name on Controlled English
(names are often uppercased in this way).


(C)
"The presentation syntax is not intended to be a concrete syntax for 
RIF-BLD."
-->
"The presentation syntax is currentlty not intended to be a concrete 
syntax for RIF-BLD. This may evolve in future versions of this
document."

currentlty
-->
currently

This may evolve in future versions of this document
-?->
An abridged presentation syntax may be added as a shorthand in the
next version of this document.


(C)
"Note: I think we have some problem here: Since we do not specify 
signature definitions or signatures as part of the rule set definitions,

but only say predicate and function symbols are defined by their 
syntactical context, what happens on merging rulesets one of which uses 
p as a function symbol and one of which uses p as a predicate symbol?
Even if two rulesets are separately well-formed, the union of their 
rules might not."

We didn't begin to deal with merging rulesets in any of the documents.
So this is (N) next iteration (not to be considered in current version):
On a merge, non-well-formedness of p as a function symbol vs. p as a
predicate symbol can be detected via signature inference, as mentioned
in FLD.


(Q)
"I am not entirely happy with the term "Group" since it is very 
unspecific. I think, in the end, I'd like ruleset better, but I don't 
have the ultimate suggestion, to be honest."

Excactly: unspecific. You should think of <Group> as just a neutral
bracketing ("grouping") construct, which allows <meta> annotation.


(E)
"Section Syntax of a RIF Dialect as a Specialization of the RIF 
Framework in that document lists the parameters of the syntactic 
framework, which we will now specialize for RIF-BLD."
--> refer to sections rather by their number than by their name.

Because of the hyperlink underlining of the name, it can act as
the reference, at least until all other things (including section
numbers) have settled in a future WD.


-----Original Message-----
From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org]
On Behalf Of Axel Polleres
Sent: April 12, 2008 7:50 AM
To: Public-Rif-Wg (E-mail)
Subject: [BLD] review of snapshot version
http://www.w3.org/2005/rules/wg/draft/ED-rif-bld-20080410/


review RIF BLD 20080411:

on version:
http://www.w3.org/2005/rules/wg/draft/ED-rif-bld-20080410/

I categorize my comments in:

(N) next iteration (not necessarily to be considered in current version)

(C) critical

(E) editorial

(Q) question for clarification

General:
a lot of the (C) comments refer to that the "Direct Specification" of 
BLD still often refers to the FLD document and is not entirely 
self-contained.
--------------------------------------------

(E)
"This document is being published as one of a set of 3 documents:"
->
"This document is being published as one part of a set of 3 documents:"


(E)
"This document develops RIF-BLD"
->
"This document describes RIF-BLD"

(E)
"Syntactically, RIF-BLD has a number of extensions to support features 
such as objects and frames as in F-logic [KLW95], internationalized 
resource identifiers (or IRIs, defined by [RFC-3987]) as identifiers for

concepts, and XML Schema data types."
->
"Syntactically, RIF-BLD has a number of extensions to support features 
such as objects and frames as in F-logic [KLW95], internationalized 
resource identifiers (or IRIs, defined by [RFC-3987]) as identifiers 
(for concepts, constants, functions and predicates), XML Schema data 
types, and a basic set of built-in functions and predicates (based on a 
subset of the XPath/Xquery functions and operators)."

(E)
"In particular, it can be used as queries, constraints, and in the 
conditional part of production rules (see RIF-PRD) and reactive rules."
->
"In particular, it can be used to express queries, constraints, and in 
the conditional part of production rules (see RIF-PRD) and reactive
rules."


(E) Mathematical English -> mathematical English

(C)
"The presentation syntax is not intended to be a concrete syntax for 
RIF-BLD."
-->
"The presentation syntax is currentlty not intended to be a concrete 
syntax for RIF-BLD. This may evolve in future versions of this
document."

(Q)
"a countably infinite set of argument names, ArgNames (disjoint from 
Const and Var)"

Why need ArgNames be different from Const?
For not having confusion with equality? If so, a remark might be in
order.


(C)

"Constants are written as "literal"^^symspace, where literal is a 
sequence of Unicode characters and symspace is an identifier for a 
symbol space. Symbol spaces are defined in Section Symbol Spaces of the 
RIF-FLD document."

If in the "direct specification" we still reference backwards to FLD, 
the dscription is not self-contained.

(N)
""Constants are written as "literal"^^symspace, where literal is a 
sequence of Unicode characters and symspace is an identifier for a 
symbol space. Symbol spaces are defined in Section Symbol Spaces of the 
RIF-FLD document."

This is the point where we should define shortcut notations for  <IRI> 
instead of "IRI"^^rif:iri, and a definition for namespace prefixes in 
the next version.
Also for the External( ... ) notion a shortcut would be desirable.


2.4 Formulas

(C)

"Any term (positional or with named arguments) of the form p(...) (or 
External(p(...)), where p is a predicate symbol, is also an atomic
formula"
->
"Any term (positional or with named arguments) of the form p(...) (or 
External(p(...)), where p is a predicate symbol, is also called atomic 
formula"

I miss a condition here that no predicate symbols may appear in nested 
in atomic formulas.

(C)
Note: I think we have some problem here: Since we do not specify 
signature definitions or signatures as part of the rule set definitions,

but only say predicate and function symbols are defined by their 
syntactical context, what happens on merging rulesets one of which uses 
p as a function symbol and one of which uses p as a predicate symbol?
Even if two rulesets are separately well-formed, the union of their 
rules might not.

(Q)
I am not entirely happy with the term "Group" since it is very 
unspecific. I think, in the end, I'd like ruleset better, but I don't 
have the ultimate suggestion, to be honest.

2.5 EBNF Grammar for the Presentation Syntax of RIF-BLD

(E)
"This is done on intentionally,"
->
"This is done intentionally,"

(C)
"It is not intended as a concrete syntax for a rule language. "
->
"It is not intended as a concrete syntax for a rule language. This may 
evolve in future versions of this document."


(C)

Name           ::= UNICODESTRING
Var            ::= '?' UNICODESTRING

a) Why do we need "Name" as a non-terminal?
b) I think we get some ambiguity here, it should rather be

Name           ::= UNICODESTRINGNOTSTARTINGWITHQUESTIONMARK
Var            ::= '?' UNICODESTRINGNOTSTARTINGWITHQUESTIONMARK
UNICODESTRINGNOTSTARTINGWITHQUESTIONMARK ::= {UNICODECHAR\'?'}
UNICODECHAR*


(E)

Example 1:

Change font from fixed with to arial in the parts which are NOT part of 
the RIF presentation syntax:

"Compact URI prefixes:"
"expands into "
"Positional terms:"
"Terms with named arguments:"
"Frames:"

Similarly for Example 2 and 3.


2.5.2 EBNF for the RIF-BLD Rule Language

(C)/(Q)

why IRIMETA? I find the nonterminal IRIMETA not very helpful, the syntax

doesn't say anything here that it needs to be an IRI, any frames seem to

be allowed.

Since the discussion is still not settled, I think I'd rather opt for 
postponing the metadata mechanism to the next version.

"For convenient reference, we reproduce the condition language part of 
the EBNF below.[...]"
  I find this repitition unnecessary.




3 Direct Specification of RIF-BLD Semantics


(C)
" 3.1 Truth Values

The set TV of truth values in RIF-BLD consists of just two values, t and
f."

No separate section necessary here. Include this in the section on 
semantic structures, i.e. change:

"TV denotes the set of truth values that the semantic structure uses"
-->
TV denotes the set {t,f} of truth values, true and false"

(C)
"DTS is the set of primitive data types used in I (please refer to 
Section Primitive Data Types of RIF-FLD for the semantics of data
types)."

again this is not self-contained.

"IF maps D to functions D*ind -> D (here D*ind is a set of all sequences

of any finite length over the domain Dind) "
->
"IF maps D_func to functions D*ind -> D_ind (here D*ind is a set of all 
sequences of any finite length over the domain Dind) "

not sure whether really D we meant here and also in several other
places.

(Q)
Why do 8.-11. refer to D and not directly to TV?

(E)
"I(External(t)) = I_externsl(\sigma)"
->
"I(External(t)) = I_external(\sigma)"

(C)
"Note that, by definition, External(t) is well formed only if t is an 
instance of an external schema. Furthermore, by the definition of 
coherent sets of external schemas, t can be an instance of at most one 
such schema, so I(External(t)) is well-defined."

this is again an link to FLD,  which makes the definition of BLD 
non-self-contained.

(E)

"For each constant "lit"^^dt \in LSdt, IC("lit"^^dt) = Ldt(lit)."

would look more readable to me, if dt and lit were in italic font.

(E)
section 3.3, item 7.

"by substitution ?X1/s1 ... ?Xn/s1."
->
"by substitution ?X1/s1 ... ?Xn/sn."

(C)
"Furthermore, by the definition of coherent sets of external schemas, t 
can be an instance of at most one such schema, so I(External(t)) is 
well-defined."

this is again an link to FLD,  which makes the definition of BLD 
non-self-contained.


Section 5.1

(E)
"The syntax of the RIF Basic Logic Dialect is defined by specialization 
from the syntax of the RIF Syntactic Framework for Logic Dialects."

->

"The syntax of the RIF Basic Logic Dialect is defined by specialization 
of the syntax of the RIF Syntactic Framework for Logic Dialects."

(E)
"Section Syntax of a RIF Dialect as a Specialization of the RIF 
Framework in that document lists the parameters of the syntactic 
framework, which we will now specialize for RIF-BLD."
--> refer to sections rather by their number than by their name.


(E)
"6. For every set of symbols s1,...,sk \in SigNames, there are 
signatures fs1...sk{(s1->individual ... sk->individual) => individual} 
and ps1...sk{(s1->individual ... sk->individual) => atomic}"

is it poossibly to subscript indexes 1-k in s1,...sk?

(Q)
"g. The constant symbols that belong to the supported RIF data types 
(XML Schema data types, rdf:XMLLiteral, rif:text) all have the signature

individual in RIF-BLD."

Shall we also place the dummy comment referring to DTB for the next 
version here?
"The definition of supported RIF data types will eventually be also 
given in the document Data Types and Builtins."

(Q)
"j. [...] This means that equality can compare only those terms whose 
signature is individual; it cannot compare predicate names or function 
symbols. "

Where are "function symbols" and "predicate symbols" defined to be 
disjoint from individuals?



(E)

"
5. Supported types of terms.
     * RIF-BLD supports all the term types defined by the syntactic 
framework (see Well-formed Terms and Formulas):
          a. constants
          b. variables
          c. positional
          d. with named arguments
          e. equality
          f. frame
          g. membership
          h. subclass
          i. external
"
->
     * RIF-BLD supports all the term types defined by the syntactic 
framework (see Well-formed Terms and Formulas):
          a. constants
          b. variables
          c. positional terms
          d. terms with named arguments
          e. equality
          f. frames
          g. membership terms
          h. subclass terms
          i. externally defined terms
"

Received on Saturday, 12 April 2008 16:14:36 UTC