Michael Uschold started his course on “Designing and Building Enterprise Ontologies” as the last presenter on Tuesday, with parts 2 and 3 to take place in the next couple of days.

Part 1

Michael motivated his course with some challenges in enterprises: professionals spending time “searching” for information, inability to evolve legacy systems, staggering cost of system integration. The root of the problem is that people are not “on the same page” (lack a unified view of the enterprise), which leads to applications not being “on the same page”. An Enterprise Ontology (EO) is a solution for this problem.

An EO defines the core terms of the enterprise using an agreed set of terms. It should also be done with automation in mind. The scope should be all concepts in the enterprise that are both essential, stable and substantially different from one another. From his experience, EOs are quite small (between 1 and 2 thousand concepts)

He then made the case for reusing upper ontologies (UOs): build faster and harness the experience of others (logicians that have more experience on the foundational stuff than you do). Using UOs also help improving clarity (force you to explain your concepts based on the UO’s concepts) and therefore accuracy, plus reduces complexity.

The question then is: how to choose an UO to use? It has to be easy to learn, understand and use: manageable scope (a few hundred concepts, not like CYC), well-structured with visualization aids and unambiguous definitions. It has to support the inferences required by the applications of the enterprise. You have to agree and commit to what the ontology says (this one is domain-specific!). It should be mature, stable, still evolving and with support.

It’s better if it has business roots (instead of academic background) — academia has emphasis on expressive power and not inference, whereas industry usually focus on understandability and usability. It should have a user base and community supporting it. It may help if it’s mapped to other ontologies (although this one is not as important). Finally, for industry it’s important that it’s standards-based.

There are many resources available: linguistic resources (e.g., WordNet), foundational ontologies (e.g., DOLCE, BFO, CYC, SUMO, gist), small narrow-scoped ontologies (e.g., vCard, FOAF, SKOS, SIOC, Dublin Core, etc.), datasets (e.g., Geonames), etc. He spent some time presenting some details about some of these resources, with special attention to Schema.org (which may become the de facto commercial UO).

Finally, he motivated the use of gist, which is his proposal for an upper enterprise ontology. Gist has the right balance for industry, considering all the criteria he presented earlier. Details on it will follow in the next days. At the end of the day, three things are important in this context: to understand, to agree, and to be able to use.

Part 2

In this part of the course, Michael presented a tutorial on gist, the upper enterprise ontology developed in his company.

gist has a core component which is ready for use and other parts which are called subgists which are still being worked on. It aims to be small and to make it easy for users to find where they should place their domain-specific concepts. Another design decision was to prefer object properties instead of datatypes so you have the freedom to further describe the property if you want.

Michael presented the common patterns (visual and not) used when presenting concepts of the ontology. He then went through the major families of classes in gist: Time, Place, Landmark, Person, Organization, Stuff, Documents, Agreement, Events and Intention, all of which use the general “class packages” UnitOfMeasure, Magnitude and Other (Collections, Concept, Language).

He talked about two scenarios for using gist: direct extension — gist as a foundational upper ontology, imported by the enterprise and new specific concepts added — or mapping — gist as a semantic aid, which makes sense in the case you don’t control the other ontology (although it can be used when you do too).

He ended the tutorial with some comments on gist’s ongoing development and how users could do change management when new versions come along.

Part 3

In the third part of the course, Michael focused on the process of building an enterprise ontology. It basically follows a cycle of Discover & Build -> Evaluate & Debug -> Refactor -> start over. He illustrated the process with an actual case study inside a U.S. company called Sentara Healthcare.

The first phase of the cycle — Discover — comprises activities such as: identify scope; gather information; ask probing questions; take plenty of notes; got o build. On Build, then, we have: identify core classes and properties; align to gist; extend and elaborate; model in OWL; go to evaluate & debug. Michael talked a bit about each of the steps, conducting some exercises along the way.

One interesting information is that they use a proprietary tool (a Microsoft Visio plug-in) for modeling the ontology in a graphical way and the tool exports everything to OWL. They plan to release the tool to the public next year.

The second phase of the cycle — Evaluate/Debug — consists of: check correctness; check completeness; create visualization aids; socialize with client; make changes and repeat until satisfied; go to refactor.

Correctness is checked using inference and manual inspection and by creating exemplars. Completeness is checked by comparing against scopes and notes. There’s also a Q/A session to evaluate correctness/completeness, with tools such as adding instances to check for errors, using SPARQL queries, using OOPS!, etc. Communication with the client is also very important in this step, so Michael mentioned some guidelines on how to make good visualizations for the clients.

Finally, Michael went very quickly through the third cycle — Refactor. Too quickly to take any notes. 🙂

Part 4

In the fourth and final part of the course, Michael went through a fictitious scenario of a company — Mega Corp — which had problems with their information systems’ complexity (actually, it was based on a real company they worked with). He talked about different ways of structuring the information for this enterprise like a case study.