The ORM Foundation

It is my understanding that a binary can only be objectified if it has a uniqueness constraint that spans both roles or if each role has a uniqueness constraint. I don't understand this limitation. Suppose I am modeling the process of assigning work to someone else. Here are the relevant facts:

• TaskRequest(id) is sent by [1] Person
• TaskRequest(id) is request to [1] Person
• TaskRequest(id) includes [1] WorkDescription
• TaskRequest(id) received response on [0 or 1] DateTime

Now with regard to last predicate, suppose a TaskRequest can only receive a single response. So there is a unique constraint on the TaskRequest role but NO unique constraint on the DateTime role. It seems natural to objectify that predicate as a "Response". And then I'll have some other predicates like:

• Response included [1] Note
• Response was of [1] ResponseType(code) 'yes' or 'no'.

Why isn't it legal to objectify the binary this way?

There are other ways to model this that seems less natural and more cumbersome. For example, I can create a subtype of TaskRequest called TaskRequestWithResponse, where TaskRequestWithResponse is a TaskRequest that received response on some DateTime. And then I can attach the response roles to that sub-type. Another alternative is to attach the response predicates to the TaskRequest directly, like TaskRequest received response of ResponseType, but then I need to add a lot of complex subset constraints to indicate that all the response facts only apply if the TaskRequest received response on some DateTime.

I'd also be happy to add a new fact TaskRequest(id) received [0 or 1] Response, in which each role has a uniqueness constraint. And then I can attach the response roles to the Response object. But I'm not sure how to specify the reference mode of the Response. If anything, the reference mode on the Response should be the same as the reference mode on the Request. In other words, a TaskRequest with identity 3 would only have a Response with identity 3; the Response would not have an identity outside of the TaskRequest it is associated with. Is this approach legal ORM?

jmagaram:

It is my understanding that a binary can only be objectified if it has a uniqueness constraint that spans both roles or if each role has a uniqueness constraint.

I don't believe this is true. I do this in situations where it make sense, for example the Driving object type in my Insurance model: http://dataconstellation.com/ActiveFacts/examples/index.shtml. See the VehicleIncident diagram.

jmagaram:

There are other ways to model this that seems less natural and more cumbersome.

Yet another way to model it is to objectify the unary "TaskRequest received response" and add the response date on that. This implies that it's useful/meaningful to know whether a request has had a response, without needing to know what or when the response was given.

jmagaram:

I'm not sure how to specify the reference mode of the Response.

You can identify the Response by its relationship to the TaskRequest object. You have a non-mandatory one-to-one between them; select the UC on the TaskRequest side and make it preferred.

This is assuming you're using NORMA; more restrictive rules applied to VSEA and I can't advise you on the details.

Now I see where my confusion came from. In the first ORM book, nested objects could only be made from spanning or 1-1 uniqueness constraints. The new book says "The second generation ORM...allows any fact type to be objectified...Although allowed for pragmatic reasons, such exceptions violate elementarity and require special treatment when mapped..." So if I'm understanding this correctly it isn't recommended because the identifier of such nested objects has nothing to do with the roles that are not spanned by the uniqueness constraint. In my example, if I nest "TaskRequest received response on Date" as "Response", the identifier of Response really only has to do with the TaskRequest and is independent of the Date. I think the best solution for me is to have a predicate TaskRequest has [0 or 1] Response and set the uniqueness on the TaskRequest side as the preferred identifier for the Response. The objectified unary could work but it is a bit artificial since I'm going to have a mandatory "Response received on [1] Date" anyway.

jmagaram:

I think the best solution for me is to have a predicate TaskRequest has [0 or 1] Response and set the uniqueness on the TaskRequest side as the preferred identifier for the Response.

You'll see that's what I did with 'Claim concerns Incident", which is not mandatory (because Incident details may not be known yet).

Any time you have a ternary with no spanning UC, you can factor it to a binary and an external role (same for higher-arity FTs) - but sometimes it doesn't verbalise as well. It's always worth considering however. I view the situation of an objectified binary with no spanning UC as the same. You'll see that the verbalisations around Driving could possibly be clearer, but I had didactic reasons for doing it this way. :]