Response to Review of Deliberation RuleML 1.02

From RuleML Wiki
Jump to: navigation, search

The comments below, in boxes, were received in regard to the Deliberation RuleML 1.02 Review. Immediately after each boxed comment, there is an enumerated RuleML response addressing it, with corresonding numbers.

Three new issues were submitted to the RuleML Wiki Issue Tracker due to comments made during the Review:

increasing the number of open enhancement requests, to be addressed in Deliberation RuleML 1.03 or later (see Category:Enhancements of Deliberation RuleML 1.02). There is one open Erratum of Deliberation RuleML 1.02 at this time (see Category:Errata of Deliberation RuleML 1.02).

All comments received during the (extended and now closed) Review comment period for Deliberation RuleML 1.02 have been addressed in the responses below.

1 Alexandre Riazanov

  1. Provide a link/reference for "Relax NG" when you first mention it.
  2. The terms "anchor schema/language", "content model", "transformer" are not universally understood.
  3. "polyadic" is much less popular than "n-ary".
  4. is not properly rendered in a browser.
  5. I don't understand the need for relaxed versions of the XML-based syntaxes, and any other syntactic sugar, so some motivation would be beneficial, IMO.
  6. does not resolve to a specific gloss.
  7. The Glossary would benefit a lot from more examples. In particular, they would clarify some places that are quite suspicious. For example, the gloss includes See <act> <arg> <declare> <degree> <formula> <if> <left> <meta> <oid> <op> <repo> <resl> <right> <strong> <then> <torso> <weak>, but it's unclear how all these things are related to <role>. What is a <role>, BTW?
  8. Section 9 looks like a stub.
  9. Section 14.1. The example is really minimal. More examples are necessary, illustrating all language features.
  1. Done
  2. Definitions or links to definitions have been added.
  3. Done: It should be noted that the key aspect is the varying number n≥0 of arguments, so we now refer to "variably polyadic" functions and relations for emphasis. The term "variadic" is sometimes used for variably polyadic functions, possibly originating as an abbreviation of "variably polyadic", so we mention that briefly, but we now use the unabbreviated (but clearer) term in all cases.
  4. The RuleML server is set to serve these examples as XML files, so they can be used as input to web applications such as Since there is no specified stylesheet, the display is not consistent across browsers. An alternative would have been to display the direct IRI for the example, but actually link to validome, e.g., which, however, would have made us dependent on that web app. We have added an initial paragraph at the end of the Examples section with "advice to readers" about viewing the examples in the exa directory, e.g. viewing the source code in various browsers.
  5. The relaxed serialization is a direct consequence of following the Robustness Principle. Applications that accept instances in the relaxed serialization are liberal in what they accept from others. Applications that generate instances in the normalized or compact serializations are conservative in what they produce. The choice between normalized or compact serializations depends on the needs of the particular case. The normalized serialization emphasizes explicit representation of all roles (as edge elements), while the compact serialization emphasizes eliminating redundancy.
  6. The broken link in Section 3 has been fixed.
  7. There is no <role> element. Roles are the denotations of edge elements (e.g. <act>, <arg>, ...), and are binary relations. See the third response to Frank Olken for a related issue.
  8. This section is shared (by MediaWiki transclusion) with Reaction RuleML. We are working on improving it in response to feedback from the Reaction RuleML review, so the edit will be delayed slightly.
  9. The example in Section 14.1 is aimed at end users, i.e. authors. Implementers need different kinds of examples, as in the test and, to some extent, exa directories. This need was raised previously in the review of Consumer RuleML 1.02 (see There is also a suite of use cases maintained in the Rulebase Competition 2014 subdirectory (see For these, a template was developed for a design pattern of assertion, query and expected result. The example in Section 14.1 is now prefixed with some of these points.

2 Bob Kirby

  1. Copyrights typically have, and may need for validity, a year, a list of years, range of years, or some combination of these.
  2. The upcoming Specification of RuleML 1.02 depicts and mentions a derivational subset of Deliberation RuleML and of HOL and FOL. The Deliberation RuleML Spec should too.
  3. While visiting Stanford, PD Dr. Christoph Benzmüller showed me TPTP (Thousands of Problems for Theorem Provers), which includes at least two different syntaxes for specifying higher-order logic. This could be referenced.
  4. John Sowa enspouses the ISO/IEC 24707 standard for Common Logic, which includes a grammar for the Conceptual Graph Interchange Format (CGIF). These standards may be capable of representing higher-order logic but through mechanisms beyond the quantification of predicates. However, it's unclear if Deliberation RuleML can readily mirror such representations, which include descriptions as arguments to predicates.
  5. Perhaps the glossary should have references to the formats it uses including the basics of XML like syntax and terminology.
  6. Perhaps I don't understand the glossary schema documentation for components such as ruleml:And, but the "instance" section appears to contain regular expressions for optional parts such as ruleml:degree with a quantifier between its tags of "{1,1} rather than a quantifier outside, just before the tag <ruleml:degree ...> of "{0,1}".
  7. Is there a distinction between axioms, rules, and facts as in SUMO? Such distinctions may be outside of the scope of Deliberation RuleML.
  8. In 2. Examples "datalog_style.ruleml" links to, which produces an error with Firefox 16.0.2.
  1. We are currently reviewing how to best reference, which is explained in The RuleML Specification License.
  2. Done: The chain Deliberation -> HOL -> FOL -> Derivation is now mentioned in the fourth lead paragraph of
  3. There is a translator from FOL RuleML to TPTP. Once appropriate higher-order TPTP and RuleML syntaxes are aligned, this translator can be correspondingly extended, and a future Deliberation RuleML Specification (see Higher_Order_TPTP-RuleML_Translator) can include and reference these joint efforts.
  4. Mirroring CGIF-like higher-order mechanisms could be attempted in a future Deliberation RuleML subfamily (see CGIF-RuleML_Translator) building on, e.g., an exemplary alignment between first-order CGIF and RuleML, RuleML's higher-order relations and functions, Grailog's labelnodes, XCLX and XCL2, as well as the efforts listed under 3.
  5. This has been done in the main spec page: See Antonis Bikakis, item 2.
  6. There is a problem with the Schemadocs generated by Oxygen, and it has been only partially fixed in the latest (17.1) version.
  7. Deliberation RuleML permits to Assert axioms, which can be rules (tagged with Implies) or facts (tagged with Atom).
  8. Fixed.

3 Zainab Hamzah Almugbel

  1. This and the following comments are regarding the Attribute Mapping section: Some of the attributes (on the grey boxes) are not linked to the glossary.
  2. The naming convention reflects attribute 'mapping' through XML trees, where there are many cases for such mapping.
    1. Simple case, one map attribute is used on the outer node. In general,...
    2. Conflict case, whenever a map attribute on a Node is in conflict with ..... Hence, the extreme case of corresponding attributes present on all child Node elements. For example,...
    3. Multi-attributes case, when the node includes one or more semantic variant attributes ..... For example,
      <Implies closure="universal" material="no" style="ex:classical">

      The explicit semantic attribute specifies that the implication is not material takes precedence over a user-defined style, ex:classical. In case the explicit @material attribute is absent, the material implication is assumed.

      1. Semantic attributes vs. Style attribute

        In Semantic attributes, when there is an explicit semantic override for the outer node, the values of the inner semantic variant attributes are not inherited. This is the principle difference between semantic variant attributes and the style attribute. For example ........ attribute on its Rulebase ancestor. The same precedence applies to every semantic variant attribute.
      2. The closure attribute

        The closure attribute is not a semantic ....... the quantified formula:
  3. you may want to remove the --> at the end of the section.
  1. The grey boxes now link to the Glossary, but in some cases there is an inaccuracy in following the deep link. This is a Mediawiki bug: See Antonis Bikakis, item 3.
  2. The suggested modifications have been considered.
    1. Done, with minor modifications.
    2. Done, with minor modifications.
    3. The syntax has been changed somewhat so that the style attribute is only now allowed on a root element. The interaction of semantic variant attributes with semantics styles is discussed in the section Specification_of_Deliberation_RuleML_1.02#Semantic_Variant_Attributes, but this section contains no example. A related example has been added to Specification_of_Deliberation_RuleML_1.02#Semantic_Variant_Attributes.
  3. Done

4 Antonis Bikakis

  1. There is an overlap between the Quick links and Version history menus when they are both expanded in Chrome and Safari - there is no such problem in Firefox.
  2. Provide either short descriptions or appropriate references for languages that are not widespread known (Relax NG, SWSL).
  3. Some external anchor links (e.g. do not point to the exact point of the anchor in Chrome - they work fine in Safari and Firefox.
  4. Section 5.1 (example) : (the compact version of the Datalog+ example) are normalized to the expanded version -> is normalized to the expanded version.
  1. Optimizing the layout of the specification page in various browser has indeed not been investigated up to this point - the target has been Firefox. A Wiki issue has been created for this task (see Optimize_Specification_Page_Layout_for_Multiple_Browsers) and it will be resolved in a later version.
  2. References have been added, in the lead paragraphs of Specification_of_Deliberation_RuleML_1.02, for XML, Relax NG, SWSL, DTD, XSD, XSLT, IRI, CURIE, RDF.
  3. This is a known bug in MediaWiki (see although this bug report mentions only Firefox, not the other browsers. We have confirmed that the problem goes away if the Version History and Quick Links tables are not collapsed by default. The only workaround we have found at this point is if one clicks into the address bar and then presses enter, the page focus will move to the correct position (tested for Firefox and Chrome only).
  4. Done.

5 Leora Morgenstern

  1. Consider the organization. At a minimum, you want to set out your general goals for RuleML and your goals for this document. You want to explain how this document relates to the goals of RuleML as a whole, and its connection to the other specifications that you reference, such as Consumer RuleML. (I have not yet read Consumer RuleML, but even if there is a whole lot of explanation, structure, and motivation there, it's not in this document.)
  2. What do you mean by Deliberation? How is Deliberation RuleML different from other versions of RuleML? What is in scope? What is out of scope? Examples would help greatly. You have links to a few examples, but the links are nearly dead; that is, they link to a page that does not show up as XML for me and does not illuminate the subject. In any case, the specification needs to be self-contained; examples must be in the text. There is one very short example at the end of the document, and that is too simple. You need a suite of examples, going from simple to complex. You need to point out what you cannot express (or claim that you can express everything).
  3. You cannot assume that the typical reader of this specification is an expert in XML. (Indeed, the people who make decisions as to whether to adopt RuleML will typically not be experts, even if those who implement it are.) So you must explain the terminology (e.g., Relax NG schemas, XSLT). You must also explain it. For example, you might want to explain that XSLT is important because you are expecting conversion of different XML docs, and you want to facilitate that. You should spell out abbreviations, such as RNC. (In this election year, it took me a moment to realize you meant Relax NG compact style! In general it is good form to spell out abbreviations the first time they are used.)
  4. I was confused by Section 3, XML Serialization Technology. Which parts are specific to Deliberation RuleML?
  5. Section 5 is sorely lacking semantics. Implies and Forall and other operators have meanings, not just syntax.
  1. Done. See the first two lead paragraphs.
  2. Deliberation RuleML is now characterized in the first lead paragraph, also w.r.t. where it differs from Reaction RuleML. What is in scope and out of scope is now highlighted in later lead paragraphs. For a discussion of examples, see Alexandre Riazanov, item 9. For a discussion of XML rendering, see Alexandre Riazanov, item 4. An item about what cannot be expressed (in the current version) was added to what is out of scope.
  3. The third lead paragraph now links to XML technologies for schemas and instances (see and to foundational and extended RuleML technology. These also explain needed terminology, including a bit of XSLT. Yet, an introduction to those parts of XML relevant to RuleML, in the style of an executive summary, would still be beneficial for a future edition (see new wiki issue Write_Summary_of_XML_for_Specification). Abbreviations have been spelled out in the main spec page: See Antonis Bikakis, item 2.
  4. The title of the section has been changed to RuleML/XML Serialization Technology and a lead sentence has been added for clarification Specification_of_Deliberation_RuleML_1.02#RuleML.2FXML_Serialization_Technology.
  5. Please see the second bullet in the "Out of Scope" portion of the lead section. It is new in RuleML 1.02 (all families) that we do not distinguish a default semantics (see Semantic_Styles_of_RuleML_1.02). If a particular semantics is intended, then it must be specified using an @style (Glossary_of_Deliberation_RuleML_1.02#.40style) attribute (available in all families) or with a <Profile> element (available in Reaction RuleML only). If the intended semantics is not specified, the semantics is considered to be "under-specified". This is an important feature for some users, e.g. LegalRuleML. Regarding the logical connectives you mention, there is not one universally accepted semantics for these connectives across all logics. For example, the semantics of Forall is different in free logic than it is in classical logic. Implies also has different semantics in different logics, including various LP semantics. This is why we do not specify a particular semantics in the Deliberation RuleML 1.02 spec, but instead we explain how to specify the semantics using @style (see Glossary_of_Deliberation_RuleML_1.02#.40style), as well as indicate which of the existing predefined styles are appropriate for Deliberation RuleML (see Specification_of_Deliberation_RuleML_1.02#Predefined_Semantic_Styles). Since this semantics approach is adopted at the System level, for all families, it will be the primary focus of the review at the System level Specification_of_RuleML_1.02 (starting soon), in addition to the predefined profiles (see Predefined_Semantic_Styles_of_RuleML_1.02) which can be referenced in the @style attribute. Suggestions on how we can better convey this new semantics approach to readers of the Deliberation RuleML specification would be welcome.

6 Frank Olken

  1. The document structure makes it challenging to read. No definitions occur in the body of the specification document, and examples are all in the Appendices. Suggestions:
    1. write a tutorial
    2. define terms in the body
    3. put small examples in the body
    4. define non-self-explanatory, crucial tags like <Ind> in the body
  2. There are four types of text: normative, definitions, examples, and explicative (explanatory notes) which could be indicated e.g. by font or background color.
  3. Mention that Node/edge were called Type/role earlier.
  4. Encourage the use of bug trackers, e.g. Bugzilla, Jira, so there can be many specialized issues.
  5. The "own" example was illuminating.
  6. A deeper Table of Contents would be helpful.
  7. In the 1.01 spec, point already to 1.02 as "under development".
  8. I would also suggest adding horizontal margins (perhaps 3 cm).
  1. Readability is being improved on a continuing basis
    1. There is a tutorial-style Primer
    2. We use multiple levels of definitions:
      1. Tool tips (hovering over underlined acronyms shows their definitions "on the fly")
      2. We define the syntax components and categories in the Glossary with one-click references from the body
      3. Many other terms are already defined in the body (e.g. formatting transformation in XSLT-Based_Formatters), but more are in the making
    3. We have started to put more small examples in the body, e.g. Semantic_Variant_Attributes
    4. Non-self-explanatory, crucial tags like <Expr>, <Plex>, and <Naf> are linked in the body (XSLT-Based_Normalizer section)
  2. We should study the pros and cons of indicating types of text by color in future releases, considering questions such as the following:
    1. Should color be served by RuleML or become a client-side option (color interpretation being rather culture-specific and subjective)?
    2. What would be good examples of (primary) color use in comparable specifications (rather than secondary use for illustration)?
    3. Will "normative", "definitions", "examples", and "explicative" (or "informative") stay the only types that we need or will there be further ones such as "observations" (or "lemmas/theorems", with "proofs") and "counter-examples"?
    4. Could color (not accessible to color-blind readers) become the primary type indicator or would we need another primary type indicator such as font type (although already partly used for other purposes) or explicit indication in English?
    5. Since we rely on MediaWiki (see item 8), would there be a (safe and light-weight) MW way to implement and maintain font or background color?
  3. There is a new (in 1.02) relationship between the terms "Node" and "type", and a similar relationship between "edge" and "role", which is explained in the Glossary entries for Node and edge. However, the Glossary is not the logical place for historical discussions about terminology in previous versions. An item has been added to Deliberation_RuleML_Changelog_1.02, which is transcluded into the Deliberation Specification as Appendix 7.
  4. Evaluating bug trackers for managing specialized issues in future releases should be helpful even if only to improve the current tracking of implementation-oriented problems in GitHub as well as the current use of MediaWiki pages for higher-level issues and errata.
  5. (No response required.)
  6. We rely on MediaWiki (see item 8) to create the Table of Contents for all header levels, from whose sub...subsections the further structures such as bulleted lists can be navigated
  7. Done. All deliberation specs on the wiki (starting with 1.0) now contain a link to the latest development version. Also the development version contains a notice, similar in appearance to the already existing obsolescence notice) to indicate that it is in draft form.
  8. We are not sure if the suggestion is in regard to margins in the printable version, online version or both. When the specs moved from HTML to MediaWiki several years ago, we knew that MediaWiki has its own rendering philosophy not optimized for all purposes. For instance, in the left sidebar, under "Tools", there is "Printable version", but the formatting this generates could be improved by the MediaWiki developers, e.g. to allow flexible margins.