- From: Axel Polleres <axel.polleres@deri.org>
- Date: Sat, 12 Apr 2008 11:49:35 +0100
- To: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
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 10:50:16 UTC