Response to Review of Deliberation RuleML 1.02
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
- Definitions or links to definitions have been added.
- 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.
- The RuleML server is set to serve these examples as XML files, so they can be used as input to web applications such as http://www.validome.org/. 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. http://deliberation.ruleml.org/1.02/exa/Datalog/datalog_style.ruleml, 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.
- 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.
- The broken link in Section 3 has been fixed.
- There is no <role> element. Roles are the denotations of edge elements (e.g.
<arg>, ...), and are binary relations. See the third response to Frank Olken for a related issue.
- 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.
- 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 http://wiki.ruleml.org/index.php/Test_Cases_for_Implementers). There is also a suite of use cases maintained in the Rulebase Competition 2014 subdirectory (see http://deliberation.ruleml.org/1.02/exa/RulebaseCompetition2014/). 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
- We are currently reviewing how to best reference http://ruleml.org/licensing/RSL1.0-RuleML, which is explained in The RuleML Specification License.
- Done: The chain Deliberation -> HOL -> FOL -> Derivation is now mentioned in the fourth lead paragraph of http://wiki.ruleml.org/index.php/Specification_of_Deliberation_RuleML_1.02.
- 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.
- 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.
- This has been done in the main spec page: See Antonis Bikakis, item 2.
- There is a problem with the Schemadocs generated by Oxygen, and it has been only partially fixed in the latest (17.1) version.
- Deliberation RuleML permits to Assert axioms, which can be rules (tagged with Implies) or facts (tagged with Atom).
3 Zainab Hamzah Almugbel
- 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.
- The suggested modifications have been considered.
- Done, with minor modifications.
- Done, with minor modifications.
- 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.
4 Antonis Bikakis
- 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.
- 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.
- This is a known bug in MediaWiki (see https://phabricator.wikimedia.org/T67468) 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).
5 Leora Morgenstern
- Done. See the first two lead paragraphs.
- 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.
- The third lead paragraph now links to XML technologies for schemas and instances (see https://www.w3.org/standards/xml/) 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.
- 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.
- 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
- Readability is being improved on a continuing basis
- There is a tutorial-style Primer
- We use multiple levels of definitions:
- Tool tips (hovering over underlined acronyms shows their definitions "on the fly")
- We define the syntax components and categories in the Glossary with one-click references from the body
- Many other terms are already defined in the body (e.g. formatting transformation in XSLT-Based_Formatters), but more are in the making
- We have started to put more small examples in the body, e.g. Semantic_Variant_Attributes
- Non-self-explanatory, crucial tags like <Expr>, <Plex>, and <Naf> are linked in the body (XSLT-Based_Normalizer section)
- We should study the pros and cons of indicating types of text by color in future releases, considering questions such as the following:
- Should color be served by RuleML or become a client-side option (color interpretation being rather culture-specific and subjective)?
- What would be good examples of (primary) color use in comparable specifications (rather than secondary use for illustration)?
- 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"?
- 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?
- 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?
- 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.
- 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.
- (No response required.)
- 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
- 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.
- 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.