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

> Direct Specification" of BLD still often refers to the FLD document and
> is not entirely self-contained.

This is treated *more than adequately*. The document clearly identifies the
sections that must be moved to DTB and the references that will be changed.
It is a waste of time to make such gratuitous changes in a draft, and then
revert to a previous wording just couple of weeks after that.

Regarding symbol spaces, they should be in DTB. Perhaps DTB could be
appropriately renamed to accommodate that, but I think it is fine as is.

Regarding other comments:

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

This is not a problem with the document, but with the group's decision to
restrict BLD like that. This will make BLD less useful for merging
rulesets.  Fortunately, we now have a framework, and it is easy to define
BLD+ with all kinds of extensions. Could even add it to the appendix along
with the core and stuff like that.

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

Whatever it is, this must be dialect-independent, so Rule and Ruleset
are unacceptable. Do you also have a problem with the term "block" in
programming languages even though a block may contain only one statement?

> refer to sections rather by their number than by their name

HTML and wiki are not LaTeX. You cannot do that. At this stage, hard-coded
references to section numbers would be acceptable only if you promise to
maintain those references is good order 24/7  :-)



	--michael  



> 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 19:17:43 UTC