Michael Uschold on Semantic Technology
I attended a presentation by Michael Uschold of Boeing corporation Phantom Works. He talked about ontologies and semantic applications and the pressing need for them in today's software industry. I thought it was a great presentation. The following is a summary of his ideas from what I gathered while listening:
Dr. Uschold explained that when one is talking to someone about semantics one needs to sell its value. One should provide answers to the following questions: how will semantics help? Why is it better? What is the cost / benefits? Where will it fit in the architecture?
For example: there was a task at Boeing that required someone to write a report every three months. Writing the report involved the guy formulating a bunch of database queries, loading the results into Excel, messing around with the data a bit to shape it into the required form, and then writing the report. Altogether this was a 20-hour task. Doing the same task with ontology would be much quicker and produce a more accurate and more complete result. This is because ontologies uses the same schema (or language) for everything in the workflow. There is no need to convert between different data representations.
So, the value of ontologies for IT systems is that they allow systems to be more tightly coupled. In a traditional system the semantics are implicit. That is, they are hard wired into the system. You can't see them, you can't change them and you can't maintain them. So, more often than not, the system's requirements are out of sync with the applications'. For example: suppose someone creates a model (in UML) and write the code according to that model (in Java), then the requirements changes and the code is updated to match the new requirements, but no one ever updates the model. Over time the model and the code grow further and further apart until the model is all but useless. With an ontology the model is directly used to drive the system. Any change to the requirements requires a change to the ontology model and that, in turn, results in a change to the system. The result: everything is up-to-date all the time. This is the holy grail of semantic systems: a model driven architecture (remember that buzz word!).
The benefit of semantics is that they allow common access to information. Ontologies have unambiguous formal semantics. So, for example: in a semantic data warehouse, the ontology can provide a common schema for querying multiple databases; when doing system integration, the ontology allows for enterprise wide interoperability; and when capturing organizational knowledge, the ontology allows this knowledge to be stored, queried and accessed throughout the organization.
Speaking of querying: semantics enable better search. Semantic search goes a step beyond basic keyword-based search. It allows for detailed and very specific question answering and document retrieval.
Semantics offer many benefits in knowledge management. They allow organization to retain knowledge (e.g. when people retire), share knowledge and enable communities of practice (by e.g. informing people throughout the organization about who knows what). Semantics enable secure knowledge authoring and storage, since a rich ontology- or rule-based specification can accurately and reliably control everything that anyone is allowed to see and/or change. Semantic knowledge management would be especially useful for compliance with the Sarbanes-Oxly business process act (which all large organization are severely struggling to comply with, because it is so ridiculously complicated).
Semantic technology allows for lean and agile application development. With a database you are stuck with a given schema that was designed according to a specific problem scenario. Want to ask a different question? Then you would better get ready to spend at least two days rewriting all your SQL, or watch your performance go down the drain like nobody's business. The ontology allows for improved reliability, consistency and reusability. People still don't know how to reuse code. An ontology, however, is built for re-use.
So, in short, the benefits of semantic technology are: flexibility, flexibility, flexibility!
Ontologies do have some limitations, however. They can't do everything.
For one, scaling is a big issue. Reasoners currently have difficulty providing efficient a-box reasoning (answering questions about a large number of individuals/instances), as well as dealing with very large ontologies. Then there also is not much in the way of commercial application support for ontologies. The triple stores on the market are, for the most part, really, really dumb. They just store triples. If you want any reasoning support at all, you need to do it yourself.
Then there is workflow control. There needs to be more support for collaborative ontology development and change management. Large groups need to be able to concurrently build ontologies.
Another major issue that is limiting the adoption of semantic technology is that it is pretty much impossible for a normal person to understand. Take OWL restrictions, for example (please!). To describe a "big red ball", one needs to write: "class: ball, that has an anonymous superclass of which some values from are restricted over the property "hasSize" with the filler of the class of "Big" and some values from are restricted over the property of "hasColor" with the filler of the class of "Red". How bizarre is that?! The non-logician/non-geek just wanted to describe a ball, not get into the details of hopelessly complicated formal logic (and that was an easy example!). The complicated stuff really needs to happen behind the scenes.
Finally: we still need code. Ontology models can't yet drive the whole system. They are just a small part of a very big picture.
Questions that need answering
There are a few common questions that people in industry need to have answered before they will adopt semantic technologies. These include: how do I use my ontology in my architecture? How do I integrate this into my Eclipse framework? How does it link into my middleware? Which API(s) should i use? Will I have to roll-my-own all the time, or can I use some kind of IDE for ontologies?
So, what we really need is a book that covers: semantic middleware and semantic programming (i.e. telling the reading: "this is Jena and this is what it does", "this is Jess and this is what is does", etc.). That, coupled with an ontology programming interface that abstracts some of the APIs and programming tasks needed for ontology development, would go a long way towards enabling the adoption of semantic technologies in real-world applications.