Different World Views (TBox) for the same Structs (ABox)

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.

Structured Dynamics for the New Year

 

For this New Year, Mike and I wanted to introduce our new venture: Structured Dynamics LLC.

Structured Dynamics is dedicated to assist enterprises and non-profit organizations and projects to adopt Web-accessible and interoperable data.  The basic premise is that the data itself becomes the application:  by virtue of its structure, information can be combined, inferred, analyzed, filtered by tag or facet, queried, searched, reported, templated or visualized.  A suite of Web services provides these capabilities, generalized to be driven by the structure of the input data itself.

Structured Dynamics supports both open and proprietary data, including the extraction of structure from fully structured data (RDF), from conventional structured data (such as relational databases), from unstructured (text) data, and from semi-structured (metadata, tags and mark-up) sources.  SD’s professional services include:

  • Linked data training and education
  • Project evaluation and planning
  • Legacy data conversions
  • Vocabulary (ontology) development and mapping
  • Named entity (instance) dictionary creation
  • Information extraction, and
  • Architectural design, development and deployment assistance.

 Structured Dynamics is platform- and language-neutral, though all of our services are based on open source software.  Mike and I have been advocates of linked data done right as our frequent and oft-cited blog posts attest.

You can read the whole story here and here.

Structured Dynamics and Zitgist

For the past 2 years and a half I put all my time, energy, efforts and knowledge in developing Zitgist LLC‘s products and services. During all that time I had to opportunity to work with a great company (OpenLink Software Inc.); with Kingsley and its dedicated team; and with the best database management system that I had the chance to use (a Swiss knife that let you do anything with any kind of data): Virtuoso.

However life is full of events. It is these events that forge someone’s life. The creation of Structured Dynamics is one of these events; just like Zitgist was.

I am really grateful to OpenLink and Kingsley.