CaseTalk - Examples

These articles will show usage of CaseTalk, demonstrating how to refactor your model, or model very specific facts. If you have questions which remain unanswered please ask us. Your question may lead to an article on our website for the benefit of you and others.

From a 1995 case study to a well-formed information model — with an agent at the keyboard

Why EU-Rent

EU-Rent is the fruit fly of business rules. A fictitious car rental company with branches in several countries, it was written by Model Systems Ltd. in the UK, published in 1995 as the case study of the GUIDE Business Rules Project, adopted by the Business Rules Group, and later became the worked example annexed to the OMG's SBVR specification. Anyone who has read about business vocabularies and rules has met it. It has been drawn in ER, in ORM, in UML, in SBVR Structured English — but, as far as we know, never as a fully populated FCO-IM model with its provenance attached to every element.

And almost every data model of one is a faithful model of a single country

There is a particular kind of confidence that appears when addresses come up in a design session. Someone says it's a solved problem. Someone else suggests four columns. A third person, the cautious one, proposes six. The meeting moves on in under ten minutes, because everybody in the room has an address, has always had one, and has never once found it difficult.

That confidence is real, and it is earned. It is just earned in one country.

An address model is one of the few artefacts in enterprise data where personal experience feels like domain expertise. Nobody walks into a session on derivative settlement or clinical coding assuming their private life qualifies them. But everyone has filled in an address form. Everyone has received post. The subject appears fully known, and the model that results is genuinely excellent — at representing addresses in the place where its authors learned what an address is.

Then the company opens in a second country, and the excellent model starts lying.

In our often used example about blood pressure, we wanted to add a fact for the appointments our patients need to make beforehand.

The fact expressions are pretty straightforward and the rules are similarly simple. The fact "Patient 564432 has an appointment for a checkup on 2010/10/13" contains a structure similarly straight forward:

Appointment

On many conferences where AI, ML or data science is mentioned, a simple dataset is used to underpin the storyline of the sessions. The Titanic dataset is such a relatively small and simple example. Until now a Fact Oriented Model was absent. So, let's see how we can build one out of the dataset by verbalizing it.

Modeling the communication about the data as expressed by domain experts can clash with technical oriented viewpoints. For instance the world of reference data and catalogs which might use codes, versus the actual values that bear meaning to the business. This article explores how an example case of preferred pronouns can unite people with different viewpoints.