Skip to content

Xalgo Expression & the RASE Method

Jump to bottom
Joseph Potvin edited this page Jul 28, 2017 · 1 revision

Xalgo "Expression" (or perhaps better referred to as a "high-level language", an "instruction set", or a "protocol') involves two kinds of primary tables:

  • Data Reference Tables (e.g. the UBL schema; ISO 1366; UNSPSC; UN ISIC codes);
  • Algorithm Reference Tables (e.g. to express a rule, such as a tax, a tariff, a subscription, etc.).

In practice there are also Joined Tables (tables joined for a particular case) that are stored for re-use, and Temporary Tables that are auto-generated and transient during processing.

Xalgo Logic Tables have the following general layout (using tab delimiters), where "state" is synonymous with "condition": logic table layout

Note that each individual rule is expressed as a single row using three symbols:

  • 1≡ confirmed as "present"
  • 0≡ confirmed as "not present"
  • -≡ confirmed as "don't care"

Actions are inferred from conditions, and the condition columns are the table key. And while data may contain nulls, if a state rule cell containing a 1 or 0 is met with a null, this returns an error.

A rule efficiency objective in all cases is to minimize the number of conditions which must be considered in order to infer a particular action. In practice, IF two rules agree in all conditions but one AND differing entries are "1" and "0"; AND actions for the two rules are identical; THEN both rules may be consolidated into a single rule by replacing the differing entries by a "don't-care" symbol (-).

For example:

  • a≡ UNSPSC|50405500|peanuts
  • b≡ HS|2008112000 1|roasted & salted peanuts
  • i≡ price*vat1
  • j≡ price*vat2

We are currently thinking through the best way to adopt into this structure the RASE (Requirement, Applies, Selection and Exceptions) semantic­ mark­up methodology developed by Eilif Hjelseth (Hjelseth 2015) and others. RASE is a data structure optimized for documenting all the functional elements contained in natural language texts of laws and regulations, applying a meta-data mark-up based on four operators: Requirement (R), Applicabilities (A), Selection (S) and Exceptions (E). A RASE table expresses the results with attributes and values that should provide the complete expression of each rule in an efficient machine-readable form. For example:

  • R: A transaction tax rule would specify that Price is multiplied by 0.5.
  • A: This tax rule applies uniformly for all UNSPSC product and service categories.
  • S: This tax rule applies differently to the following UNSPSC codes.
  • E: This tax rules does not appluy to the following UNSPSC codes

The RASE methodology serves the dual purpose of providing a simple requirements record for each rule, while at the same time expressing the rule in a directly executable form. A template RASE table contains the following columns:

  • Mark-up metric phrase
  • Operator (R, A, S or E)
  • Object type
  • Data schema
  • Property
  • Comparison
  • Metric
  • Unit

Xalgorithms' Lichen and the generic Internet of Rules context avoids the need to transcribe each rule from tabular form to script (such as Kasim et.al. 2013, p.18), but Xalgo Form presents no obstables to conversion to scripts suited to specific computing solutions.

Tala Kasim et.al. illustrate a sample set of logical relationships amongst rows of a RASE table for the expression of a rule, in the illustration below. A diagram of RASE data relationships

Not all semantically useful information in the natural language expression of a law or regulation can be categorized under the four RASE operators. Therefore Hjelseth provides the Tx3 methodology for classifying rules to express the degree of computability of the law or regulation (Transcribe, Transform, Transfer).

  • Transcribe refers the translation of a natural language statement directly into a RASE table.
  • Transform involves rewriting or restructuring the natural language statement so that it can be expressed in a RASE table.
  • Transfer applies to the natural language statements which cannot be expressed in a RASE table, such as when the requirements are imprecise, or when goals (Property column) are not matched with simple indicators (Metric column).

To facilitate the computability of qualitative indicators in the Metric column, Hjelseth describes "Test Indicator Objectives" (TIO) as an ontology­-based methodology for transforming qualitative requirements into quantitative values. A TIO table for documenting transformed qualitative goals as quantitative metrics has the following columns:

  • Clause
  • Shall/Should
  • Qualitative expression of goal text of statement
  • Test Indicator Objectives (TIO)
  • Quantitative metric =, <, >

References

Beach, T. H., Rezgui, Y., Li, H., & Kasim, T. (2015). A rule-based semantic approach for automated regulatory compliance in the construction sector. Expert Systems with Applications, 42(12), 5219–5231. https://pdfs.semanticscholar.org/fef3/25421c92121579f5583226d6882da78b9a11.pdf

Hjelseth, E. (2015). Foundations for BIM-based model checking systems: Transforming regulations into computable rules in BIM-based model checking systems (Doctoral dissertation). Norwegian University of Life Sciences, Norway. Retrieved from http://ibim.no/Eilif_Hjelseth_PhD_Foundations_for_BIM-based_model_checking_systems_2015-11-06.pdf

Kasim, T., Li, H., Rezgui, Y., & Beach, T. (2013). Automated sustainability compliance checking process: Proof of concept. In 13th Int. Conf. on Construction Applications of Virtual Reality, Teesside Univ., Tees Valley, UK (pp. 11–21). Retrieved from http://itc.scix.net/data/works/att/convr-2013-1.pdf

Clone this wiki locally