The ORM Foundation

Dear John,

Thanks for your clear description of semantic and speech communities in SBVR and the relationship to UoD.

I would propose we extend it a bit by the following:

SBVR distinguishes three levels:

a. Ground facts

b. Domain specific conceptual schema

c. Generic conceptual schema

In SBVR the union of b+c is called Conceptual schema.

In SBVR the union of a+b+c is called Fact model.

In AI a is called the aBox (assertion)

In AI b+c is called the tBox (type).

This can much better be represented in a diagram. Part of such a diagram can be found in my articles on www.brcommunity.com., in particular the October 2007 issue.

Kind regards

Sjir 

Dear Terry,

In your previous contribution you mention a few aspects that deserve further discussion one of which is atomicity of fact types. All three approaches SBVR, ORM and CogNIAM have atomic fact types in the classical definition. Practice has shown that there is more that can be offered to a mature business modeling community.

I believe it is good to consider to specify the semantics of atomicity in more than one way and let people decide what they want to adopt, hence select a certain business practice. Atomicity could also be loosely defined as convenient in practice. Of course we need to define this further and precisely as can be done in an SBVR concept definition. Let us illustrate this right away with an example and see whether there is sufficient interest to follow up on this practice. Suppose we deal with the fact type

SBVR expert <SBVR expert> lives in the country <country> since date <start date> until end date <end date>.

There are several ways of modeling this.

One way is to keep in mind that you want to have the structural rule (SBVR) or constraint (CogNIAM, ORM) that periodes per person cannot overlap. In that case it is convenient  to have a convenient atomic fact as specified above. This would also have the consequence that the role end date is optional. In the CogNIAM business practice we recommend to use the fact type forms in such a convenient fact type with the classical meaning of atomic fact types including an objectification.

Hence the proposal is to include more aspects than the classical elementary considerations and this makes more fact types conveniently atomic. In any practical project one then can decide which kinds of atomicity to use.

Regards  

Sjir

Dear Sjir

Your example is an interesting one, and does illustrate a difference between ORM and CogNIAM. In CogNIAM, I take it that you treat a fact type such as

 Person lived in Country from Date to Date

as an asserted fact type, allowing that the end date is optional, which means that you allow nulls in asserted fact instances. For example, assuming for simplicity that we can identify people by their first given name, and that countries are identifed by 2-letter ISO country codes and that dates are identified by year-month-date strings, we might populate the fact type with the following fact instance:

The Person with first givenname 'Terry' lived in the Country with the countrycode 'US' from the Date with ymd datestring '2000-02-15' to the Date NULL.

To save writing, let's leave the reference schemes implicit, and now represent the fact instance by the tuple

'Terry', 'US', '2000-02-15', NULL

This approach is of course convenient for storing facts in relational tables, since the relation scheme for this case (allowing that a person may have multiple habitations in the same country) may be specified as

Habitation ( personName, countryCode, startDate, [endDate] )

with additional constraints such as uniqueness over (personName, countryCode, endDate) and other constraints to ensure endDate >= startDate for the same habitation and that habitation periods for the same person don't overlap. We can now conveniently populate this table with many rows, e.g.

 Habitation ( personName, countryCode, startDate, [endDate] )

'Sjir', 'NL', '1950-01-22', '1982-02-03'

'Sjir', 'AU', '1982-02-04', '1986-12-31'

'Sjir', 'NL', '1987-01-01', NULL

''Terry', 'US', '2000-02-15', NULL

In ORM, we do not allow nulls in asserted facts, so if presented with this population in a report to verbalize, we would proceed differently. In looking at the last row, we see simpy the fact that Terry began a habitation in the US on 2000-02-15, which we may treat as an instance of the fact type

Person began a habitation in Country on Date.

We do not attempt here to verbalize something like "until NULL", as the NULL simply indicates the absence of a fact. Looking at the first row, we might have first verbalized it as a quaternary indicating Sjir lived the The Netherlands from 1950-01-22 to 1982-02-03. However, now that we know the end date might not always be known (e.g. rows 3 and 4), we rephrase row 1 by stating the smaller ternary fact about the habitation start (Sjir began a habitation in The Netherlands on 1950-01-2), and then attach the end fact to that (That Habitation ended on 1982-02-03), making the end fact type optional in the schema. This leads to the following nested formualtion for the schema:

Person began a habitation in Country on Date: objectify as "Habitation";

That Habitation ended on Date (optional)

Uniqueness constraints are added (internal and external uniqueness), and other temporal constraints as discussed before. In the second edition of Information Modeling and Relational Databases (p. 422, Figure 10.25) I discuss a similar example, and also show various alternative ways to model the situation (e.g. introduce a simple identifer for the habitation).

In ORM, you may still use the quaternary formulation if you like, but as a derived fact type (defined in terms of the nested formulation). ORM allows nulls only in derived facts, and regards relation schemes as simply derived fact types (typically compound). In ORM, it is not uncommon in Step 1 of the CSDP to initially verbalize in a way that is later reformulated, with the option of retaining the initial verbalization as a derived fact.

As another issue, note that if we had COMPLETE knowledge of habitation facts, we could model the situation with yet another alternative, where we have two ternary fact types "Person began a habitation in Country on Date" and "Person ended a habitation in Country on Date", with a pair-subset constraint from the Person-Country role pair of the end fact type to the Person-Country role pair in the start fact type. This flattened approach fails however if we have incomplete knowledge. For example, w.r.t. rows 1 and 2 of the above sample population suppose we know only that Sjir started a habitation in NL on 1950-01-22 and ended a habitation in NL on 1986-12-31: from this it would be incorrect to deduce that Sjir lived in NL from 1950-01-22 to 1986-12-31.

As yet another solution to the habitation example, we could use the quaternary "Person lived in Country from Date to Date" for cases where the end date is known, and run a subset constraint from the sequence of its first three roles to the ternary "Person began a habitation in Country on Date". This would allow you to verbalize rows 1 and 2 of the sample report population without nesting, and verbalize rows 3 and 4 as before.

While this verbalization may well be the most natural of the alternatives discussed, currently the NORMA tool will generate two relational tables for the flattened schema, instead of the more efficient single table solution (resulting from the nested schema). We should probably add an option in NORMA to allow the single table result as a relational mapping option if the user still prefers the flattened solution at the conceptual level. 

However, if we wish to add more fact types about habitations (e.g. Habitation was enjoyable) the nested solution becomes more preferable at the conceptual level. This fits in naturally with the notion of objectification (if you want to talk about something, you effectively make an object of it).

Dear Sjir and Terry,

I agree on Terry that the sentence ‘Sjir lived in NL from 1987-01-01 to NULL’ isn’t very convenient.

One of the solutions Terry suggested is:

As yet another solution to the habitation example, we could use the quaternary "Person lived in Country from Date to Date" for cases where the end date is known, and run a subset constraint from the sequence of its first three roles to the ternary "Person began a habitation in Country on Date". This would allow you to verbalize rows 1 and 2 of the sample report population without nesting, and verbalize rows 3 and 4 as before.

In my opinion these two sentence patterns are both used in business practice, depending on the situation that exists:

1: person <personName> lived in <countryCode> from <startDate> to <endDate>

2: person <personName> began a habitation in <countryCode> on <startDate>

Use sentence pattern 1 only if you know the enddate. If enddate is unknow, then sentence pattern 2 is used.

So, group the two facttypes to one facttype and use both sentence patterns with this resulting facttype:

Habitation ( personName, countryCode, startDate, [endDate] )

1: person <personName> lived in <countryCode> from <startDate> to <endDate>

2: person <personName> began a habitation in <countryCode> on <startDate>

And agree on the following rules:

• You may use sentencepattern 1 for rows with a known endDate

• You may not use sentencepattern 1 for rows with a unknown endDate

• You may use sentencepattern 2 for all rows

This removes the drawback for the use of a sentence with NULL for enddate.

Well folks, here is my contribution.

As far as I can see there are two quite distinct elementary facts that (in my opinion) have nothing to do with each other.

Fact 1: Person began residence in Country on Date
Fact 2: Person ended residence in Country on Date

I have uploaded a file to the library that shows:

1: The object-role model
2: The two tables generated in the logical model 
3: The three code snippets that enforce the constraint that you cannot end a residence before you have started it.
4: The details of the two facts

Ken

Hi Ken

Thanks for your model, which does correctly identify two ternaries that are derivable from the original example. However, your model has some problems. As a trivial error, the subset constraint in your model is wrong (it should go between the person-country role-pairs).  But the main problem is that it assumes COMPLETE knowledge, as discussed in my earlier post. We want to know for what periods each person was continuously resident in a country, but this cannot be determined from your model if we have incomplete knowledge (as might often be the case). Here I repeat the counterexample to this approach that I gave in an earlier post that concern's Sjir's multiple habitations in The Netherlands, where we know the first start date and last end date only (not the first end date and not the last start date):

 <<This flattened approach fails however if we have incomplete knowledge. For example, w.r.t. rows 1 and 2 of the above sample population suppose we know only that Sjir started a habitation in NL on 1950-01-22 and ended a habitation in NL on 1986-12-31: from this it would be incorrect to deduce that Sjir lived in NL from 1950-01-22 to 1986-12-31.>>

Cheers

Terry, Lex and Ken,

First and for all thanks for your contributions to this thread.

What would the conceptual world be without real examples?

I said in the start of this discussion just to consider some other forms of atomicity. 

Well here is my preferred model:

ft1: SBVR expert <SBVR expert> started habitation on date <start date> in country <country>

A primary key over the combination of role 1 and 2 

ft2: The habitation of SBVR expert <SBVR expert> started on date <start date> ended on date <end date> and was, as can be derived, in country <country>

A primary key over the combination of role 1 and 2; an alternate mandatory key over the combination of role 1 and 3; role 4 is derived from ft1; no overlap between the first three roles; the ordered set <role1, role2> of ft2 is a subset of the ordered set <role1, role2> of ft1

ft3: The habitation of SBVR expert <SBVR expert> started on <start date> was <enjoyable indeed not> enjoyable and ended, as can be derived, on date <end date>

Primary key over the combination of role 1 and 2; alternate mandatory key over the the combination of role 1 and 3; the ordered set <role1, role2> of ft3 is a subset of the ordered set <role1, role2> of ft2

I leave it up to each contributor, including this one, to remove unnecessary or wrong constraints.

Kind regards

Sjir

Hi Terry,

Thanks for pointing out my "oops!" I have corrected the file in the library to prevent others from being misled.

Interesting isn't it that there is such hidden complexity in seemingly simple facts!
One way of avoiding the "NULL" problem is to populate the second fact with today's date.
(OK, yesterday's date because I still might choose to end my habitation "later today".)

Then, we always do have what you call "perfect knowledge" in that if you have not been to the authorities and de-registered, then you are still resident in the country. And if you have de-registered, then you are free to start another period of habitaion at a later date.

But maybe you see things differently?

Ken

This is a response to both Ken and Sjir's previous responses.

First, Ken, your new model now has the subset constraint on the correct arguments but it is pointed in the wrong direction (assuming we agree that a habitation may have a start date without necessarily having an end date).

Second, Ken's model includes a uniqueness constraint that allows a given person to reside in a given country only once (i.e. for only one continuous period). This is counter to my sample population, where I had Sjir living in The Netherlands for two disjoint periods. From my reading of Sjir's posts, I believe he agrees with me in rejecting this constraint.

Third, both Ken and Sjir included uniqueness constraints requiring a given person on a given date to start residing in at most one country. Although this might well be true for some UoDs, I did excluded this constraint because I wanted to allow borderline cases such as somebody starting to reside in The Netherlands one morning but for some reason ending that residence on the same day and starting residence in Belgium, say, later that same day. This was also partly influenced by my prior experience with modeling country visits, which certainly do not have that uniqueness constraint. If you say that such a uniqueness constraint must be applied, then we should later also consider cases like country visits where no such constraint applies.

Fourth, as noted before, while I'm happy to allow derived facts to be compound or have null components, I think it facilitates communication with domain experts and also simplfies the underlying theory to restrict asserted facts to have no null components, and for me it then seems simpler to take the same position with respect to fact types. 

Terry,

Start date without end date>
My domain model says that "There is always an end date" in that if someone takes up residence then they are resident from the day they register to either yesterday or the day on which they chose to discontinue residence.
This allows easy reporting for "How many resident-days have we had between date x and date y.
Tax collectors like this one!

Reside only once   
Yes, this needs to be changed to allow multiple sequences of residence.

Reside in two countries on the same day.
From my periods of residence in Holland and Belgium, I infer that this is not legally feasible.
The forms you have to fill in allow you to enter "Date on which Residence begins" or words to that effect.
The forms don't have an option to specify  "Time of day on which your residence began"
Of course, you can "visit" multiple countries in one day but you I don't think that you can "reside" in more than one country on the same day.

Nulls not allowed
I absolutely agree with you here. No Nulls! 
After all - What are elementary facts for?

Ken

Ken,

Would it be an idea that we start to develop the conceptual schema of this website in both CogNIAM, ORM and SBVR?

It  could be a good example of a very practical and relevant application. 

Kind regards 

Sjir

Hi Sjir,

That's an interesting idea but it sounds like quite a big project (probably several weeks if not months work)
Right now I'm finding it hard to spare time for manageing the website so I'm sorry but I could not committ to such a project.
And anyway, I don't see what benefit I might get from doing such a project.

You may care to note that the website uses about 100 tables with an average number of columns per table of about 7 - in other words, there would be 500+ objects (in ORM) and probably at least as many facts.

Ken

 Hello, Sjir,

The idea of modeling the OF website has both positive, and negative aspects.  I saw Ken's reply - and his remarks are understandable.  I started an ORM model for a website of my own, and there are some daunting aspects.  If you intend to create a complete model (one that covers all the aspects of a website, down to the level of the actual code for the web server), that would be a huge undertaking.  Still, as it's a conceptual model, you can choose the level of abstraction.  I think it would be a good exercise; and it would be open to review and comment from the members here.  You can, model the site from the user's perspective.  You shouldn't need any expert knowledge beyond what you can discover as a user.  You can model the site as you see it work.  What goes on behind the seens need not be part of the model (and that may be both a good idea as far as security is concerned, as well as a relief to Ken).  Not requiring the model to delve into the mechanics of the Community Server application that hosts this site will make it much easier to create; and make it a much better learning tool - as we can all comprehend the parts of the site that are available to us as visitor/members.  Perhaps that's the sort of thing you had in mind?

If a high level model is what you are suggesting, by all means take a shot at it.  I'll be interested to see what entities you choose as core components.  I'll try to scare up the partial model I was working on, so we can compare notes.   My familiarity is with ORM; so seeing the model in the other forms would be interesting as well.  Given that the model will reflect aspects common to nearly all websites, that should provide a good basis for comparing the methods.

BRN.. 

Dear Brian,

The first priority is to develop a conceptual schema in SBVR, CogNIAM and ORM that contains

a. a complete list of concept definitions

b. a complete list of associated fact types

c. a complete list of associated fact type forms

d. a complete list of the asociated rules 

to understand the communication from a user point of view.

If you are willing to contribute I would be very grateful.

Kind regards

Sjir