Page Comparison

...

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/).
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.

...

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.

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. 
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?)

...