jacobvos: he object type 'Rental' with as subtypes
I believe this is an incorrect use of subtypes. Every instance of a subtype must be capable of playing every role of the supertype (without that role having a different meaning from the same role when applied to the supertype without reference to its subtype). In a system that models activities and lifecycles, this principle extends to requiring that every instance of a subtype must be capable of the same actions as its supertypes, and each action would have the same meaning as that action applied to an instance of the supertype (without reference to it as an instance of the subtype). These are basic requirements for Substitutivity of Individuals from the theory of types.
Accordingly, if subtypes are to be used, the basic Rental type needs to have a subtype "Promised Rental" (which contains the link to the person who made the booking, the anticipated start date/time, etc), a separate subtype StartedRental (which contains the actual start date, the nominated drivers, etc), and so on. A StartedRental is not a subtype of PromisedRental, since a Promised Rental can be started, which a StartedRental cannot. This would be a type conflict. The Rental remains a PromisedRental even after it was started (it is still the case that the Rental was once promised), so now the instance is of two subtypes as well as the supertype. This allows reference back to the nature of the promise that was made, even as that promise is being fulfilled.
However, it's not necessary to create all these subtypes. Unary (or other) roles can indicate states, and the population of other roles can be required or prevented by use of subset constraints. See the following diagram to follow this:
The unary fact types here are not derived, rather other roles are required or prevented by them. There is one important missing subset constraint which requires NORMA Pro, and doesn't fully display in ORM, which is one that requires that before a rental can be ended after the car has been picked up, the car must first be returned. This constraint requires a disjunction "either car is not picked up or car has been returned".
When I coined the term "readiness fact type", I refer to a derived unary which indicates whether all pre-conditions have been met for the object to be considered as "ready" for some other activity or roles, representing possibly a new phase of life (e.g. started, picked up, returned, etc). This is a third alternate way of working, and the one I prefer where possible (including for my original question in this thread). This is the way of working which Matt also suggested.
Note that the non-ORM shorthand shown by Jan in the objectification of a single role of the nominated-driver fact type, while I understand the intention and the meaning, is unnecessary and masks a modelling error. It is possible for any Person (whether a Driver in a Rental or not) to have a driving license. The license is not subordinate to this instance of them being nominated as a Driver in this rental situation; nor do they necessarily have another license when they are nominated in another Rental. When a person rents again, it is necessary again to check the validity of their licence, and perhaps to add new license details (since those may have changed) but the old licence is still relevant. Both old and new licences are independent of their application to a given rental. Note that in the above diagram, I have corrected this mistake with an explicit Driver subtype; though not with a fleshed-out model for licence validity over time. I've also allowed the Rental to nominate more than one driver, while still requiring that a Rental must nominate at least one driver before being started (these are both subtle changes in the business rules, which would need to ba validated with domain experts).
So to summarise, I've made a rebuttal of Jan's "way of working" from both a theoretical and practical correctness point of view, a way of correcting it (still using subtypes), and two alternative ways of working using unary fact types with subset constraints, in increasing order of preference (for this situation; I do use subtypes for such as Person/Driver, but not for phase-of-life factors as in this case).