1 Terry Halpin Neumont University © 2006, T. A. Halpin ORM2 Perspectives: Objectification, Modality, and Tooling

2 Contents  Objectification –Objectification in ORM, UML, and ER –Two Kinds of Nominalization –Objectification and Composite Reference Schemes –Objectification of Unary Facts –Objectification of Fact Types with Non-spanning UCs –Propositional Nominalization and Communication Acts  Business Rule Modality –Introduction –Modal Operators and Rule verbalization –Embedded, Static Rules –Dynamic Rules  NORMA Tool Demo/Discussion

3 Objectification in ORM, UML, and ER Roughly speaking, objectification (a.k.a. nesting), treats a relationship instance as an object in its own right, so it may be talked about like any other object. ORM example (ORM 2 notation):

4 UML usually calls this reification, allowing association instances to be objectified as instances of an association class. Unfortunately the name of the association class must match the name of the association (whether displayed or not). UML example, augmented by non-standard notation for preferred identification scheme “{P}” :

5 Industrial Entity Relationship Modeling (ER) (e.g. IE, IDEF1X, Barker ER) does not support objectification at all. Some academic versions of ER do support objectification, typically with restrictions (e.g. objectified relationships may have attributes but not play in other relationships) Example in Elmasri-Navathe ER notation (unable to specify attribute optionality):

6 Two Kinds of Nominalization Nominalization replaces a declarative sentence by a noun phrase, enabling the nominalized object to be referenced like any other object. Two basic kinds of nominalization may be distinguished: Situational -- nominalized object is a state of affairs/event/activity Propositional -- nominalized object is a proposition Elvis sang the song ‘Hound Dog’. -- original proposition Elvis’s singing of the song ‘Hound Dog’ is popular. -- actual state of affairs That Elvis sang the song ‘Hound Dog’ is well known. -- true proposition That Elvis sang the song ‘Hound Dog’ is debatable. -- false proposition

7 It’s snowing outside. -- original proposition It’s true that it’s snowing outside. -- proposition That snowing is beautiful. -- state of affairs In ordinary speech, “fact” (i.e. fact instance) often means “true proposition”. ORM uses “fact” in the weaker sense of “proposition taken to be true” (epistemic commitment by users in the business being modeled)

8 Consider an object instance resulting from the objectification to Playing, e.g. Australia’s playing of cricket. Is this object a state of affairs/event/activity or is it a proposition? Australia’s playing of cricket is at rank 1. Makes sense if playing is an activity, but not if it’s a proposition. Australia’s playing of cricket is true.-- Nonsense.

9 This is typical of objectification examples in information models. “Objectified relationships” are typically states of affairs in 1:1 correspondence with the relationships (facts in the ORM sense) that they objectify, but are not identical with those facts. So we reject this aspect of the UML metamodel, where AssociationClass is a subclass of Association and Class.

10 Objectification and Composite Reference Schemes To facilitate conceptual declaration of business rules (constraints or derivation rules) and queries on information models ORM includes (implicitly or explicitly) link fact types to support navigation between the objectification result and the objects in the fact being objectified.

11 Default readings are assigned for link predicates, e.g. The modeler may assign better readings, e.g.

12 ORM 2 supports multiple predicate readings and role names whose screen or print display may be suppressed individually. ORM 2 allows rules and navigation paths to be declared in relational style -- using predicate names attribute style -- using role names mixed style -- using both

13 ORM 2 allows objectification to be displayed in this way but interprets this as shorthand for: Asserting the equality constraint is the critical step in treating this as objectification.

14 ORM 2 allows role sequences participating in constraints to be disambiguated by role sequence numbers whose display may be toggled on/off.

15 This model may be arrived at in different ways, e.g. (1) Start with the fact type Country plays Sport, then objectify it as Playing. (2) Start with the fact types Playing is by Country and Playing is of Sport, then define Country plays Sport as fully derived from them. (3) Start with the 3 fact types Country plays Sport, Playing is by Country, and Playing is of Sport, then assert the equality constraint.

16 These 3 ways may be formalized as equivalences thus: E1:  x [Playing x   y:Country  z:Sport (x is by y & x is of z & y plays z)] E2:  x:Country  y:Sport [x plays y   z:Playing (z is by x & z is of y)] E3:  x:Country  y:Sport  z:Playing [x plays y  (z is by x & z is of y)] Regardless of which way is used to arrive at the model, the same basic structure is used to capture the model in the metamodel, and the same basic mapping procedures are used to transform it to implementation targets (e.g. Rmap, Omap, Xmap) -- under development ORM 2 includes a formal, high level textual language for all its graphical rules as well as additional business rules e.g. the derivation rule E2 may be rendered as: Country plays Sport iff some Playing is by Country and is of Sport.

17 Objectification of Unary Facts ORM previously forbad objectification of unary facts. For ORM 2, we removed this restriction, by extending the previous analysis to objectified types with simple reference schemes. Consider the unary fact: The President named ‘Abraham Lincoln’ died. We may objectify this event using the nominalization “that death”, and declare the following additional fact: That death occurred in the Country with country code ‘US’.

18 The schema is interpreted as shorthand for:

19 The earlier analysis for objectification may now be generalized by allowing the arity to be unrestricted (1 or more) and the reference scheme to be simple or composite. The result of objectifying a relationship type may be viewed as an entity type that has a reference scheme whose reference projection bears an equality constraint to the fact type being objectified.

20 FCO-IM also supports objectification of unaries, but in a very different way and for a different purpose. FCO-IM uses defines non-lexical objects as objectifications of roles played by lexical objects, e.g. While this approach is interesting, and is supported by two Dutch tools (CaseTalk and Infagon), this seems to conflate reference with referent, and to make it awkward to deal with multiple inheritance, context-dependent reference, and changes to reference schemes.

21 Objectification of Fact Types with Non-spanning UCs Previously, ORM allowed an association to be objectified only if either it has just one uniqueness constraint, and this spans all its roles, or it is a binary 1:1 association. This restriction forbids objectification of 2 kinds of associations: An n:1 (or 1:n) binary association; A ternary or longer association whose longest uniqueness constraint spans exactly n – 1 roles. The above cases are allowed in UML, and those academic versions of ER that support objectification. ORM 2 allows these cases, subject to modeling guidelines.

22 Usually, objectifying an n:1 association is just bad modeling, e.g. consider this Elmasri-Navathe ER example 1 : It’s simpler to remodel the departure time as an attribute of just LegInstance. 1 Example from Elmasri, R. & Navathe, S. 1989, Fundamentals of Database Systems, Benjamin/Cummings Publishing, Figure 3.18, p. 63.

23 To support this kind of example in ORM 2 (whether or not it is the best way to model) we interpret the schema thus: The 1:1 nature of the left-hand link fact type avoids denormalization on Rmapping.

24 For objectification, mandatory constraints are needed on all link roles of the objectified type. e.g. if we remove a mandatory role constraint as shown below, Birth is no longer an objectification of GovtHead was born in Country.

25 The main case where it makes sense to objectify associations with non-spanning uniqueness constraints, is when the UC(s) may evolve over time (e.g. from non-spanning to spanning) and we wish to minimize the impact of such changes to the model. A set of modeling guidelines, which also covers other cases is presented on the next slide.

26 Modeling heuristic. 1 A fact type may be objectified only if: (a) it has only a spanning uniqueness constraint; or (b) its uniqueness constraint pattern is likely to evolve over time, e.g. from n:1 to m:n, or m:n:1 to m:n:p; or (c) it has at least two uniqueness constraints spanning n-1 roles (n > 1), and there is no obvious choice as to which of the n-1 role uniqueness constraints is the best basis for a smaller objectification based on a spanning uniqueness constraint; or (d) the objectification significantly improves the display of semantic affinity between fact types attached to the objectified type. 1 For further discussion, see Halpin, T. 2003, ’Uniqueness Constraints on Objectified Associations’, Journal of Conceptual Modeling, October Online at:

27 Propositional Nominalization and Communication Acts The Business Rules Team submission to the OMG RFP on Business Semantics for Business Rules includes business rules that may be treated directly as cases of propositional nominalization, e.g. If a waiter earns an amount of money as a tip from serving a meal, the waiter must report that fact. Rather than introducing a second kind of objectification into ORM 2 to deal directly with propositional nominalization, we recommend recasting such cases in terms of situational nominalization (e.g. as shown on the next slide).

28 If a waiter earns an amount of money as a tip from serving a meal, the waiter must report that fact.

29 As regards modeling of communication acts, when it is of interest to model these acts, they are best modeled directly like any other business domain objects. e.g. in a genealogy model we might be interested in not just descriptions of states of affairs, but assertion acts made by researchers about states of affairs. Such a model might include fact types such as: AssertionAct reported Proposition; AssertionAct was made by Researcher with ConfidenceLevel; etc. These comments relate to the information model only. For modeling communication processes, the information model should be supplemented by other kinds of model (e.g. interaction or workflow models) that provide a more intuitive and direct way of understanding essential business processes/services.

30 For information modeling, objectification may be restricted to situational nominalization, where the nominalized object is a state of affairs (event, activity …) rather than a proposition. Objectification of facts (unary, binary, or longer) may then be interpreted in terms of entities whose reference schemes are constrained by equality constraints involving reference projections from linking predicates. Objectification of facts with non-spanning uniqueness constraints should be permitted, but subject to proposed modeling guidelines. Communication acts may be included as domain entities in information models, but some communication aspects are best specified with other kinds of model (e.g. interaction or workflow diagrams). Summary

31  Introduction  Modal Operators and Rule Verbalization  Embedded, Static Rules  Dynamic Rules Business Rule Modality

32 Introduction Business Rules determine what states and state transitions are possible or permitted for a given business domain, and may be of alethic or deontic modalities. Alethic rules impose necessities (e.g. implied by physical laws) cannot be violated, even in principle e.g.Each Person was born on at most one Date. No Component includes itself. Deontic rules impose obligations ought to be obeyed, but may be violated e.g. It is obligatory that each Person is husband of at most one Person. It is forbidden that any Person smokes in any Office.

33 Information modeling approaches such as ER, UML and ORM typically restrict their coverage of rules to alethic rules. In practice, many business rules are deontic, and it is often important to know when they are violated so that actions can be taken to discourage future violations (whether or not support for this is automated). In recognition of this need as well as for rule exchange etc., the OMG is finalizing the SBVR 1 (Semantics of Business Vocabulary and Rules) proposal to specify a business semantics layer on top of its software-oriented layers. 1 Interim SBVR specification URL:

34 This presentation is based on the author’s logical formalization work for SBVR, and work on NORMA 1 an open-source tool for ORM 2 (2 nd generation ORM) which supports deontic and alethic rules. The ideas discussed could be adapted for other approaches such as ER and UML. In fact, the NORMA tool is currently being extended to to support ER and UML notations as views of the underlying ORM model. 1

35 Modal Operators and Rule Verbalization AlethicDeontic ReadingSymbolReadingSymbol It is necessary that  It is obligatory thatO It is possible that  It is permitted thatP It is impossible that ~~ It is forbidden thatF Modal negation rules~  p   ~p ~Op  P~p ~  p   ~p ~Pp  O~p  Fp ~Fp  Pp  = true in all possible worlds  = true in some possible world For static constraints, a possible world is a state of the business domain.

36 NORMA displays alethic constraints in violet and verbalizes constraints in positive and negative forms. The mandatory and uniqueness constraints in positive, combined form: Each Person was born in exactly one Country. (2 constraints: exactly one = some, and at most one). This is read as a necessity. As an option, this may be made explicit: It is necessary that each Person was born in exactly one Country.

37 In positive form, NORMA also verbalizes the lack of a uniqueness constraint on the right-hand role: It is possible that more than one Person was born in the same Country. Satisfying populations help illustrate constraints.

38 The mandatory and uniqueness constraints verbalized separately in negative form: For each Person, it is impossible that that Person was born in more than one Country. It is impossible that any Person was born in no Country. NORMA is being extended to support counterexamples to illustrate constraint violation and generate test cases.

39 Alethic +ve: [It is necessary that] For each Room and HourSlot, that Room at that HourSlot is booked for at most one Activity. Alethic –ve: It is impossible that the same Room at the same HourSlot is booked for more than one Activity. The uniqueness constraint might be alethic (shown above) or deontic.

40 Deontic modality : +ve: It is obligatory that for each Room and HourSlot, that Room at that HourSlot is booked for at most one Activity. -ve: It is forbidden that the same Room at the same HourSlot is booked for more than one Activity. NORMA display deontic rules in blue, typically with an “o” for “obligatory”.

41 NORMA screenshot

42 NORMA currently allows modal operators only as the main operator of the rule expression. Some allowed SBVR formulations that violate this restriction may be transformed into an equivalent NORMA expression by applying modal negation rules and the Barcan formulae and their converses, i.e.  x  Fx    x Fx  x  Fx   x Fx e.g. For each Person, it is necessary that that Person was born in at most one Country. transforms to It is necessary that each Person was born in at most one Country.

43  x O Fx  O  x Fx We also accept the following deontic variant of the Barcan formulae, allowing  and O to commute. This allows the following rule For each Person, it is obligatory that that Person is a husband of at most one Person. to be transformed to It is obligatory that each Person is a husband of at most one Person.

44 By normalizing rules to restrict modal operators to the main operator, the only impact on tagging a rule as a necessity or obligation is on rule enforcement. For static rules, no commitment to a specific modal logic is required. Enforcement of a necessity rule never allows violations. Enforcement of an obligation rule allows violations, but takes some remedial action (e.g. display a message to a relevant authority indicating violation of the rule including verbalization of the rule).

45 Embedded, Static Rules SBVR allows modal operators to be embedded anywhere in rule expressions. In rare cases, these rules cannot be transformed into rules where the only modal operator is the main operator. To support such cases, we have two alternatives adopt a specific modal logic 1 replace the embedded modal operators by domain-level predicates For the first alternative, we prefer S4 2. For the second alternative, we proceed as for embedded deontics (see later). 1 There are many normal modal logics (e.g. K, K4, KB, K5, DT, DB, D4, D5, T, Br, S4, S5) as well as non-normal modal logics (e.g. C2, ED2, E2, S0.5, S2, S3). 2 Schema evolution may seem to violate S4 (its accessibility relationship between possible worlds in transitive), but we resolve this by treating such evolution at the metametalevel.

46 Formally, we treat a model as an interpretation where each non-deontic formula evaluates to true. A model is a permitted model if the p in each deontic formula of the form Op evaluates to true otherwise it is a forbidden model (though still a model). This approach avoids the need to assign a truth value to expressions of the form Op.

47 Various metarules apply between alethic and deontic rules, e.g. the argument (role set) of a deontic uniqueness constraint must be a proper subset of the argument of an alethic uniqueness constraint. This example satisfies this metarule: However, if the marriage predicate were alethically 1:1, then no deontic uniqueness constraint may be added (if something is already necessary, it makes no sense to declare it obligatory).

48 Some SBVR formulae (e.g. OPp) are illegal in some deontic logics, and deontic logic itself is rife with controversies. If a deontic model operator is embedded, we first try to normalize the formula using transformation rules such as p  Oq. . O(p  q) 1 or deontic counterparts to the Barcan formulae. In rare cases, embedded deontics cannot be so normalized. Rather than choosing a specific modal logic (a risky option), where possible we transform such cases into first-order formulae with no modalities by replacing the modal operators by predicates at the business domain level. Such predicates (e.g. “is forbidden”, “is permitted”) are reserved and given additional semantics (e.g. exclusion constraints between forbidden/permitted predicates). 1 In contrast to our approach, some versions of deontic logic reject this equivalence on the basis that agent control is restricted to the scope of modal operators.

49 As a simple example, consider the following SBVR rule. Car rentals ought not be issued to people who are barred drivers at the time the rental was issued. This deontic rule may be captured by the following ORM derivation rule for the partly derived domain fact type CarRental is forbidden: CarRental is forbidden if CarRental was issued at Time and CarRental was issued to Person and Person is a barred driver at Time. The following slide shows the full ORM diagram for this case.

50

51 SBVR allows rules that embed possibly non-factual propositions. However, there does not appear to be any simple solution to providing explicit, formal semantics for such rules. As a nasty example, consider the following business rule: It is not permitted that some department adopts a rule that says it is obligatory that each employee of that department is male. This example includes the mention (rather than use) of an open proposition in the scope of an embedded deontic operator. One possible, though weak, solution is to rely on reserved domain predicates to carry much of the semantics implicitly, as shown in the following ORM schema.

52 Some support for reification in the sense of propositional nominalization is being added by Pat Hayes and Chris Menzel to the IKL language, while retaining first-order. When available, this may offer other options for dealing with such cases.

53 Dynamic Rules Dynamic rules restrict the possible transitions between business states. The rule may simply compare one state to the next (e.g. Salaries should never decrease) or the rule may compare states separated by a given period (e.g. Invoices ought to be paid within 30 days of being issued). The invoice rule might be formally expressed thus, assuming the relevant fact types exist in the conceptual schema: For each Invoice, if that Invoice was issued on Date 1 then it is obligatory that that Invoice is paid on Date 2 where Date 2 <= Date days.

54 This rule might now be normalized to the following formulation, moving the deontic operator to the front: It is obligatory that each Invoice that was issued on Date 1 is paid on Date 2 where Date 2 <= Date days. This transformation requires an equivalence rule such as p  Oq. . O(p  q). While this formula is actually illegal in some deontic logics, it does seem intuitively acceptable. In principle, such formal transformation issues might be ignored, so long as the domain expert confirms that the normalized formulation agrees with his/her intended semantics.

55 While it is obvious how to implement this rule in a database system, capturing the formal semantics in an appropriate logic (e.g. a temporal or dynamic logic) is a harder task. One possibility is to provide a temporal package that may be imported into a domain model, in order to provide a first-order logic solution. Another possibility is to adopt a temporal modal logic (e.g. treat a possible world as a sequence of accessible states). We prefer a first-order solution where possible.

56 Summary Many business rules are deontic rather than alethic. This presentation discussed one way of modeling and verbalizing such rules in ORM 2, as supported by the open-source NORMA tool. NORMA currently supports static rules where the only modal operator is the main operator. Rules that cannot be transformed into such cases are challenging to adequately formalize and support, especially those involving embedded deontics or dynamic rules. Some approaches were suggested to deal with such cases, but further research is needed to adequately address these complexities.

57 NORMA Tool Demo/Discussion