Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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. 

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. 

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 W3C or similar status from some other organization. 
  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

 

  • No labels