The ORM Foundation

Supposing I have a Blog model where Author writes Post, and Author commented on Post. Now I want to calculate the average number of Comments per Post. That sounds to me very like I need a derived value of some (new?) value type, which seems unnatural in ORM. I can model it as a unary fact type on a value type; perhaps a VT having a cardinality constraint of one. The use of a fact type means I can add a derivation for this fact type (and it also makes sense in a relational mapping)... but it seems wrong when it's the value instance itself that's derived, not a fact relating to a value type.

SBVR provides for such calculated values

What's the ORM way to define them?

Hi Clifford,

Interesting example, but I'd say you were on the right track with your unary fact type but were somewhat misled by thinking the cardinality constraint (of #1)applied to the "value" type. Actually, there is a cardinality constraint, but not on the value type so much as on the role.

For example, if I had the unary fact type "Date is today", obviously only one Date should be playing that role at any particular time; so there should be a "role cardinality" constraint on that. (This is an example that I recall discussing with Terry.)

However, though your unary fact type (Quantity is the average number of comments per post) has such a cardinality constraint on the role, that constraint is actually derivable itself, from the derivation rule on the unary. So there's no need to enforce it separately.

Cheers,

Andy

I think the best approach here is to objectify a derived unary. In this case, the cardinality of one is implied by the derivation rule, and the identifier for the objectifying entity is the value.

So, you have a generic 'Count' value type with a unary fact type 'is average post comment' with an aggregate derivation rule. The objectification of this fact type gives you an entity identified by the count. The question then becomes whether the entity type is OK. Certainly for the time case (I don't consider Today to be a value, but it is definitely an abstract notion that can be identified by a value) the entity is fine. A similar argument can be made for the average (I can conceptually talk about the average number of comments without knowing the value for it, so I don't see a problem making it an entity type).

The basic approach here (objectified unary) is likely also acceptable to the FCO-IM community, but they wouldn't enforce that the objectifying object type be an entity type as ORM currently does.

-Matt

Matthew Curland:

The basic approach here (objectified unary) is likely also acceptable to the FCO-IM community, but they wouldn't enforce that the objectifying object type be an entity type as ORM currently does.

I was going to object, but it seems that in this situation where a cardinality of one applies, I should be able to use the value which identifies the objectified unary "Average Comment Ratio". In CQL:

Comment Count is written as Integer;
Comment Ratio is written as Real;

// Derive the Comment Count for a Post:
Post has Comment Count where
    Comment Count is count of Comment in Post has Comment;

// Derive the overall average Comment Ratio as a unary:
Comment Ratio is average where
    Comment Count is count of Comment in Post has Comment,
    Post Count is count of Post in Author wrote Post,
    Comment Ratio = Comment Count / Post Count;

// Derive the average Comment Ratio for each Author:
Author receives Comment Ratio where
    Author wrote Post that has Comment,
    Comment Count is count of Comment in Post has Comment,
    Post Count is count of Post in Author wrote Post,
    Comment Ratio = Comment Count / Post Count;
 
// Derive the final unary:
Author is controversial where
    Author receives Comment Ratio(1) > Comment Ratio(2) that is average;

That all works nicely, and doesn't have issues with the verbalisation regarding the unary (I hadn't found this rather nice way of expressing it before). CQL could (but doesn't) figure out that the inequality means there are two Comment Ratios at play here, so should allow dropping the subscripts. Anyhow...

However, if I objectify "Comment Ratio that is average", I can use the value of the objectification. Here's an alternate definition of "Author is controversial:

// Objectify "Comment Ratio is average":
Average Comment Ratio is where
    Comment Ratio is average;

Author is controversial where
    Author receives Comment Ratio > 2*Average Comment Ratio;

In the final comparison, the value of (the value which identifies) Average Comment Ratio is used. Note that multiplying by 2 would have been uglier without the objectification:

Author is controversial where
    Author receives Comment Ratio(1) > 2*Comment Ratio(2) and Comment Ratio(2) is average;

I guess that seems to work ok, in any case. The verbalisations aren't that bad.