Imagine you are setting up a book shop. You will primarily sell a selection of books, but to diversify your revenue streams you will also sell board games, coffee and greeting cards. How should you organise your store so that your customers can find your products?
One section of the shop could be dedicated to books, with different shelves for different types of books (fiction, non-fiction, new arrivals, local history etc). Another section of the shop would be dedicated to board-games, while some racks near the door would hold the different types of greeting cards: birthday, mother’s day, father’s day etc. Upstairs is the coffee bar, selling different types of coffee.
What is going on here, from a modelling and ontology perspective?
When we supply the description above to finchbot.net (and with a little prodding) it produces the Concerto model below:

Not a bad start for this domain model, but it doesn’t really address the organisation question we have in mind.
In our example, we’ve dedicated sections of the shop to different types of concepts, but then also used attributes of the concepts to further organise them. In fact, we’d even go as far perhaps as to order the books within a section by author name or (horror!) by colour.
Let’s examine that in terms of the levels of our ontology:
Level 0 (instances):
A Book
- Title: My Brilliant Friend
- Author: Elena Ferrante
- Genre: Fiction
Level 1 (model):
Concept: Book
Level 2 (meta-model):
Type: Concept Declaration
Summary
We can think of the organisation as an exercise in populating shelves, using queries.
For example, the query that populates the shelves for fictional books, might look like:
Select all Books where genre is “Fiction”, ordered by author
The query is using both Level 0 (All Books) and Level 1 information (genre and author). One might even image using Level 2 information in other scenarios, for example to collect all enumerations (Level 2), ordering them by enumeration name (Level 1).
Around about this point the astute amongst you start to question, “What is data and what is metadata?” That is purely a matter of perspective! One person’s metadata is another person’s data: the customer considers the author name to be metadata about the book, and the text of the book is the “data”, while the system that pays author royalties would almost certainly consider the author name to be data, and might consider the text of the book to be metadata.
We can also move data/metadata between the levels of our model. For example, instead of creating a Book concept and a BoardGame concept we could have a generic Product concept and an enumeration of ProductType – this would effectively push the distinction between Books and Board Games into level 0, rather than capturing it at level 1.
Please bear in mind these principles as your think about how best to display, sort, and organise the concepts and instances of your domain models.
Leave a comment