![](https://secure.gravatar.com/avatar/327b654b20b643aee9aba05af863dc66.jpg?s=120&d=mm&r=g)
Hi Everyone,
As mentioned in a previous thread I said I would build a justification for not having cardinality in the Tonto shared ontology.
In order to do this I will differentiate between:
* Semantics: Shared meaning * Application Logic: Statements necessary to do useful things with data within a particular context.
Clearly there are semantics in Application Logic. There is meaning in almost anything that isn't purely random but I believe the distinction is important and will be come clear as we go along.
Cardinality = "The number of instances of entity B that can (or must) be associated with each instance of entity A."
Notation I'll use is:
* 0 = none allowed * 1 = one and only one * n...n' = somewhere between n and n' allowed (inclusive). e.g. 0...1 or 1..2 or 1...* (where * is infinite)
Take an example: The Person class has the property hasMother that allows instances of Person to have a link to another Person as their mother. The principle of motherhood is a very strong semantic and easy to agree on.
Now lets introduce cardinality.
Everyone has a mother so the cardinality of hasMother should be 1 - correct?
If this is so then systems will say that person objects that don't have a hasMother link to another person are invalid and should be rejected. It is therefore impossible to communicate between systems using the Person class if you don't know who everyones mother is - you can't even use it to ask who their mother is so we have a catch 22. That mother resolver service will have to create it's own semantics. It also rules out use of the Person class in applications that don't care about motherhood - the local pizza delivery shop should not have to have a reference to your mother in order to sell you pizza!
So the cardinality of hasMother should be 0...1 - correct?
We are now saying that a Person can have 0 or 1 mothers. This isn't semantically correct. Everyone has to have at least 1 mother don't they! It is only instances of the Person *class *that have 0...1 mothers. This is Application Logic not semantics. We are confusing the meaning of the hasMother link with what we want to do with software artifacts.
What about an upper bound on this cardinality? Does everyone really have 1 mother? Well if you are adopted you have a birth mother and an adoptive mother. If you have been fostered as well you may have a birth, foster and adoptive mothers. Thanks to IVF you could have separate genetic and birth mothers. So the upper bound of 1 is a little application specific. It doesn't fit if you are running a social services department or IVF clinic but the notion of hasMother does work. You could always communicate with other systems in terms of this person hasMother and simply not express the different mothers roles. In fact the other systems probably wouldn't understand them.
So my conclusion from this is that cardinality of properties of objects is application specific and not a matter of shared semantics. Do away with cardinality and we can capture a great deal of useful semantics and communicate using them.
Practically is you are running an IVF clinic or orphanage you will have to extend the shared semantic ontology for your particular purposes. Most technologies allow you to do this.
I'd be interested in your thoughts on this.
All the best,
Roger (As we are doing motherhood in this example I promise to try and get Apple Pie into another example)
participants (1)
-
Roger Hyam