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

From: Michael Kifer <kifer@cs.sunysb.edu>
Date: Sat, 12 Apr 2008 15:16:53 -0400
To: "Axel Polleres" <axel.polleres@deri.org>
Cc: "Boley, Harold" <Harold.Boley@nrc-cnrc.gc.ca>, "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
Message-ID: <29531.1208027813@cs.sunysb.edu>


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

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:50 UTC