The Semantic Web and Ontological Technologies Continue to Expand

Ontologies and Ontological management have become more popular as enterprise architecture has gained ground among organizations. As tool support has become more available and the concepts of semantics and ontologies are being understood, there are more players that have come to the table with contributions. The AKSW group recently released their Triplify product to provide "a building block for the 'semantification' of the web." The UMBEL backbone project has started up to provide a lightweight subject structure for the Web. Dan McCreary talked about some of the main pitfalls in developing and maintaining enterprise ontologies.

The Agile Knowledge and Semantic Web research group (AKSW) has recently released the newest version of their Triplify product. Triplify is a small plugin for Web applications, which reveals the semantic structures encoded in relational databases by making database content available as RDF, JSON or Linked Data. By using the plugin and ordering the columns in the application queries, Triplify can analyze the data returned by the applications queries and make them available in the previously mentioned formats. This makes it easier for small to medium web applications to participate in the semantic web without a very large effort to create and maintain large semantic definition efforts. This is the end goal of the Triplify approach - "exploiting structured relational representations behind Web applications for creating a critical mass of semantic representations on the Web."

The Upper Mapping and Bind Exchange Layer (UMBEL) project billed itself as "a lightweight ontology for relating Web data and datasets to one another via a standard set of subject concepts." UMBEL defines "subject concepts" as:

a distinct subset of the more broadly understood concept such as used in the SKOS RDFS controlled vocabulary or formal concept analysis or the very general concepts common to some upper ontologies. Subject concepts are a special kind of concept: ones that are concrete, subject-related and non-abstract. We further contrast these with named entities, which are the real things or instances in the world that are members of these subject concept classes.

The main thrust of the project is to help provide "meta-maps" of the relationships between the immense number of fine-grainied, local ontological and concept maps. Michael K. Bergman provided a look at what the web's subject backbone might look like as well as a slideshow describing the UMBEL online demos and the project's first 11 semantic web services.

Lastly, Dan McCreary discussed some of the things to watch out for in defining enterprise ontologies. When asked about some of the main stumbling blocks to getting an organization involved in defining their ontologies, Dan replied that the word "ontology" itself was a big hurdle:

It is too intimidating. It puts too many people off. They think they are paying for AI research. Sometime we just have to pick a more friendly name. Just call it a metadata registry and you my get better adoption. Many people that work with database developers just end up calling it a logical data model or and enterprise data dictionary. XML types like to call it an XML Schema type library. Whatever the audience...pick a term that makes them feel comfortable and then focus on the pain points of the organzation. I only tell about 25% of my customers I am building ontologies.

Once an organization gets started on defining and maintaining their ontologies, it needs to be managed and run across the enterprise. Dan said that it is not just a high-level effort but that it needs to extend all the way through the organization.

An upper ontology is pretty much useless by itself. They solve no real business problems by themselves. It is only when you get to the leaf level elements that you can start mapping to columns in databases. That is where the rubber meets the road.

Once adoption of ontologies has begun in an organization, McCreary's list of ten pitfalls should be heeded:

1. Use tools made for designing ontologies
2. Avoid duplication of data elements
3. Do not confuse roles with objects within the ontology
4. Separate processes for defining semantics from those defining constraints
5. Test upper ontologies thoroughly
6. Create unambiguous definitions for data elements
7. Avoid mixing definitions of elements with the descriptions of them
8. Create searchable structures that allow complex full-text searches
9. Adopt a practice of versioning and traceability for the definitions
10. Define the semantics for enterprise code/identifier objects as well.

McCreary also stressed the importance of having individuals or teams within the organization that own the ontologies and are responsible for semantic precision. For enterprises that are serious about the value of their ontologies, these individuals should play key leadership roles.