/
FIBO Rules Language Consideratons

FIBO Rules Language Consideratons

Owned by Dean Allemang
Last updated: Nov 28, 2016

NOTE This page is Public, reviewable by everyone in the world (not just FIBO team members)

 

I have created this page as a sort of clearinghouse for considerations for a Rules language for FIBO.  

I've started with four sections - examples from FIBO of things that go beyond the expressivity of OWL, the DL particulars that these relate to, requirements (this is intended to include functional and non-functional requirements) and candidates.  Once we settle on the requirements and candidates, we can do a matrix of requirements vs. candidates as we make a decision. 

I take it that for situations in which a rule can be expressed in OWL, that we will prefer to do so (e.g., the property chains that define the relationship of the lattice to the corresponding unreified property can be expressed in OWL).  

Examples

  1. Ownership And Control.   We have a property that says A owns B, and another one that says A controls B.  It is desirable to have a property that says A ownANDcontrols B, which holds exactly if both of the former hold.  
  2. Mixed Currency Swap. A swap has two legs. Each leg is traded in some currency.  If the currency of one leg is different from the currency of the other, then we say that this is a mixed currency swap. 
  3. The rules for affiliation are complex, but they include a consideration that if A owns B or B owns A then A is affiliated with B, except that A is not an affiliate of itself.
  4. In order to support various kinds of analysis of financial instruments (calculated valuations, behaviors over time, risk oriented analysis, determination of an organization's exposure to either another counterparty or one or more instruments), the ability to calculate is needed (i.e., do math), on equations expressed in rules, whose parametric elements (values, variables) come from individuals that are represented using the FIBO ontologies.  We can represent the parameters themselves, but not the numeric functions per se, such as has been done in RIF (see http://www.w3.org/TR/2013/REC-rif-dtb-20130205/).  This includes aggregate operations (e.g., the sum of x such that p(x)), averages, counts, and so forth.
  5. Also in order to understand behaviors, some ability to understand states and state change is required.  An ontology representing states will be submitted with IND (or another downstream specification) to support representation of state and changes in states, but the ability to interpret the state of something at a point in time (situational analysis) and to "do something" based on that state, such as execute an analysis, is also needed.  RIF includes a declarative way to describe events, conditions, and actions that could be used to represent these sorts of things, although a mapping to an operational language (e.g., IBM's ILOG language, Oracle, TIBCO Business Events) would be needed to actually interpret and validate such rules. This case may be more operational, rather than declarative, which would be part of an application that you build around the logic, but you might want to at least represent the rules, if they are sufficiently common.

Issues with DL

There are a handful of well-known limitations of DL expression. I'll list some here

  1. "friendly fire".  Class definitions in which membership in the class is based on items that have the same value for two properties.  The name comes from the military situation in which a unit fires on another unit of the same affiliation.  OWL enthusiasts point out that this situation can be resolved in DL, if you know the list of all possible affiliations; it is possible to define a class called "RedTeamFriendlyFire" in which the value of the firing and fired-upon units are both Red, and the class "BlueTeamFriendlyFire" as the class of fire situations in which the value of the firing and fired-upon units are both Blue.  Then FriendlyFire is the UNION of RedTeamFriendlyFire and BlueTeamFriendlyFire.   Logically, this is sound as long as there are only two affiliations, Red and Blue.  If the set of possible affiliations is volatile, then the definition of FriendlyFire has to be updated whenever a new affiliation is defined. 
    This situation is exactly parallel to the "Mixed Currency Swap" situation above, only instead of two affiliations (Red and Blue) we have hundreds of currencies.  I take it as obvious that this is not the sort of maintenance we want to do each time an update is made to ISO 4217. 
  2. Role intersection.  In DL, a "role" corresponds to a property in RDF, and is mathematically defined as a set of ordered pairs of (subject,object) for which the property holds.  The intersection of these sets is the set of (subject,object) pairs for which both properties hold.   So property :r is the intersection of properties p and q means that if A p B and A q B, then A r B. 
    The definition of role intersections is not possible in DL. 
    This is  parallel to the OwnershipAndControl situation above.  It is a bit more complex, but affiliation can also be reduced to role intersection.
  3.  The ability to represent equations / analysis, and rules that state what should be done under certain circumstances (declaratively, not to actually perform the execution of those rules), is needed to support 4 and 5, above.
  4. The ability to support negation as failure – DL reasoning is open world and does not support this but for affilliate analysis, counterparty risk-based analysis, and others, we will need to provide support for closed world reasoning in rule-based execution environments, including support for negation as failure.
  5. There are many examples of limitations of DL, by design, that extensions or alternative representations can assist in addressing.

Requirements

I'm using the word "must" here a lot, since these are requirements.  I don't expect that we'll be able to satisfy them all at once. 

  1. We need a normative way to express rules in FIBO that make definitions for FIBO concepts that go beyond what we can do in OWL. 
  2. The rule language we use for normative expression must be able to refer to the OWL constructs that define FIBO already. 
  3. The rule language must be a standard, e.g., a Recommendation from the OMG, W3C, ISO community, OASIS, or similar status from some other organization, free and open source to the degree possible.
  4. The rule language must be translateable into something actionable for unit tests on the FIBO ontologies. 
  5. It must be possible to edit / view the rules in some human readable way (what exactly does this mean?)

 

Candidates

  1. FIBO/RIF work done by Dean about a year ago.  It is a proper subset of RIF, and hence conforms to a W3C standard, and can be converted into SPIN and MarkLogic rules.  There is no easy way to edit/view rules in RIF.  It's connection to OWL is defined in the RIF standard. 
  2. SPIN from TopQuadrant etc. Based on SPARQL, a W3C Recommendation, but the SPIN extension is just a working note. Runs on any SPARQL-enabled triple store (that's all of the ones that are actually compliant), can be edited/viewed using TopBraid Composer.  Connection to RDF/OWL is part of the spec.  No translations available, but there is a command-line version that can be used for unit tests. 
  3. SWRL available in Protege for ages.  It is not a W3C standard, can be edited and viewed in Protege.  Connection to OWL is part of the spec.   Unit tests can be performed in Protege
  4. Decision Model and Notation (DMN) an OMG standard http://omg.org/spec/DMN/ that uses Decision Tables and an expression language (FEEL). It's being directly supported by the major rules engine vendors such as IBM (ILog/JRules), Oracle and TIBCO.
  5. Other candidates might include Flora-2, which is what the Sunflower implementation by SRI/Quarule uses, and is also used by Benjamin Grosof's implementation.  It has higher expressivity than RIF/BLD (see http://www.w3.org/TR/2013/REC-rif-bld-20130205/), and is open source, though not a standard per se.  A starting point write-up on the mapping from RIF to Rulelog is available at http://ruleml.org/rif/rulelog/rif/RIF-Rulelog.html. The Sunflower implementation supports validation, has a rule editor, imports OWL as the basis for rule development, etc., and I believe the same is true / planned for the Coherent-based implementation.  Both use Flora-2, by Michael Kifer, described at http://flora.sourceforge.net/.  Flora-2 is "in the same spirit" as RIF, since Michael worked on both and continues to support it, but there may not be a direct mapping document available at present.  SRI might be willing to make Sunflower available for unit test support (stay tuned).
  6. There are other implementations of RuleML, such as prova, which is Adrian Paschke's implementation, which provides Reactive RuleML support – see https://prova.ws/. This work includes a prova syntax, with mappings from various flavors of RuleML, including ECA RuleML (event-condition-action). http://wiki.ruleml.org/index.php/RuleML_Home
  7. Yet another candidate might include the Hets system, which is related to the DOL/OntoIOp effort.  The focus there is on CL and declarative monotonic logics, so this may or may not work for us.  See http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/index_e.htm for more on this.