Mike continues his series of blog posts that talks about the distinction between ABoxes (the assertions box; the data instances box) and TBoxes (the terminologies box; the data schemas box). Mike suggests to people to make a distinction between the data instances (individuals) that belongs to the ABox, and the vocabularies (schemas, ontologies; whatever how you call these formal specifications of conceptualizations) that belongs to the TBox.
I wanted to hammer an important point that emerged in our recent discussions about these specific questions: the TBox defines the language used to describe different kind of things and the ABox is the actual description of these things. However, there is an important distinction to make here: there is a difference between using some properties to describe a thing and understanding the meaning of the use of these properties to describe these things.
Let’s take the use-case of two systems that exchange data. The data instances that will be transmitted between the two systems will be exactly the same: their ABox description will be the same; they will use the same properties and the same values to describe the same things. However, nothing tells us how each of these properties will be processed, understood and managed by these two systems. Each system has its own Worldview. This mean that their TBox (the meaning of classes and properties used to describe data instances) will probably be different, and so, interpreted and handled differently.
I think the fact that two systems may process the same information differently is the lesser evil. This is no different than how humans communicate. Different people have different Worldviews that will dictate how they will see and reason over things. One person can see a book and think at it as a piece of art where another person can say: “Great! I finally have something to start that damned fire!”. The description of the thing (the book) didn’t change; but its meaning changed from one person to another. Exactly the same thing applies to systems that are exchanging data instances.
This is really important since considerations of the TBox (how data instances are interpreted) shouldn’t be bound to the considerations of the ABox (the actual data instances that are transmitted). Otherwise no systems will ever be able to exchange data considering that they will most than likely always share different Worldviews for the same data (they will handle and reason over data instances differently).
I think this is a really important thing to keep in mind going forward because there won’t ever be a single set of ontologies to describe everything on the semantic web. There will be multiple ontologies that will describe the same things, and there will be an endless number of versions of these ontologies (there are already many). And finally, the cherry on the cake, how these ontologies are handled and implemented in systems is different!
But take care here; this doesn’t mean that we can’t exchange meaningful data between different systems. This only means that different Worldviews exist, which means that care should also be given to not mix data with the interpretation of concepts. This is yet another reason why we have to split apart concerns between the ABoxes and the TBoxes.
2 thoughts on “Different World Views (TBox) for the same Structs (ABox)”
Really enjoyed reading this post – but still think you made a crucial mistake: you equalize the TBox with ‘how […] properties will be processed, understood and managed’. But if you look at today’s implementations of Semantic Technologies – how much of their behavior is really determined by the TBox? In the end – how much can you learn about Google’s Social Graph implementation from the FOAF ontology?
Even more – if you argue that the common case will be that applications exchanging data do not commit to the same ontology and will interpret relations and properties differently – why then bother with ontologies at all?
Well, first the TBox defines the classes and properties (in RDF parlance) and their descriptions and relationships. So, the TBox is defined by these classes and properties descriptions. But As Mike put it: there is a problem with the semweb’s “ontology” term since many people will describe everything in an “ontology”: classes, properties, and instances of classes.
So, I do think the classes and properties belongs to the TBox and the instances of classes belongs to the ABox.
One of the point of this blog post is that we have to separate concerns between ABox and TBox. We do care about the ontologies at the level of the TBox. However we don’t have to care about how the other system will think (tbox) about the data that is being exchanged (abox). So, sure that we care about the ontologies (at least I do) so that we can make some sense of data 🙂
Does this help?