Terry
Thanks for your reply and insights.
I think I was a little unclear about my tentative "(or not)" proposal -- my idea was that the "(or not)" qualifier would only be added in the fact type verbalisation (or, equivalently, would be removed in the fact instance verbalisation. That would avoid the grossly tautological fact instance verbalisation -- but you are right that it would be inconsistent with the way that other fact types are verbalised, which is a good reason to reject it.
I think the problem I've found with business user acceptance may be due to the way that I've been presenting the more common binary (and higher arity) fact types. Because these fact types almost always have some constraints (mandatory, uniqueness) I've often verbalised the fact type just using the constraint verbalisation
e.g.
> Each Person was born in exactly one Country
rather than first "defining" the fact type using the unconstrained verbalisation, and then qualifying it
> "Person was born in Country"
> :--- Each Person was born in exactly one Country
(And even where there are no constraints, we can verbalise the lack of constraints as "has zero or more ...").
Of course, unaries don't often have such constraints, so their verbalisation is just the fact type verbalisation, which then "feels" different. Taking the latter (define then constrain) approach for the more common binaries would highlight the similarity in form with the unaries, and should reduce confusion.
Thinking further, the idea of providing negative readings (we could use the existing / notation, since unaries do not need "reverse order" reading) would be essentially a short-hand for the re-factoring of a single unary into two mandatory disjunctive mutually-exclusive unaries. If that was done, then the constraint-readings would be available, allowing the fact types to be implied from the constraint readings.
> Each Person is a smoker or is a non-smoker but not both.
I'm particularly interested in the use of OWA and OWN in ORM -- for binary and higher facts as well as unaries. I have an application in mind that must deal with missing information (information that should in principle be available but in practice isn't because data becomes available at different times -- alethically OWN but deontically CWA, you might say).
The "negative unary reading" idea, and its equivalence to a mutually-exclude two-unary model, might help with modelling OWN too (since the CWA two-unary model is easily translated to the OWN equivalent by removing the disjunctive mandatory constraint, and perhaps automatically adding an "It is known that ..." prefix to the fact type and instance verbalisations).
Thanks again for helping me to think through these issues.
Misha