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.
Examples
- 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.
- 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.
- 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
- "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. - 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.