UML Profile for OWL, Part 3: Ontology

Image by dullhunk via Flickr

This is Part 3 of a multi-part series describing my profile for OWL. In this part I start to descend the stereotype hierarchy. This part of the descent is about the «Ontology» stereotype.

Generally, an OWL ontology is a web accessible resource with a URL that is similar to a Web page. Sometimes a Web server builds this resource from statements in a triple store so you can retrieve it. Sometimes the ontology lives on your computer's disk and the URL will start with "file://". In any case, it behaves like a Web resource. So, for the purposes of this posting I will describe it as such.

An OWL ontology generally uses "hash URIs" (e.g., "#Person"). These hash URIs are a shortcut for prepending the URI of the ontology. This causes a problem when an ontology is stored in several different locations and someone wants to refer to something in it. My understanding of the way to resolve this problem is to declare a "default namespace" for the ontology. This causes the hash URIs to be relative to the default namespace rather than the current location of the ontology. (Please correct my understanding in a comment if I'm wrong.)

The «Ontology» stereotype has several tagged values. Because the «Ontology» stereotype is a specialization of the the «RDF Resource» stereotype, it inherits URI and namespace prefix, which were explained in Part 2. In addition to these inherited tagged values, the «Ontology» stereotype adds a default namespace.

Although I haven't constrained what you can apply the «Ontology» stereotype to, it makes sense to apply it to a UML Package. The UML elements in that package will all be in their owning package's default namespace, unless an element has a stereotype that says otherwise.

The namespace prefix is still useful in UML land. Rather than having every ontology responsible for defining a different namespace for every ontology it references, in this profile every ontology has its own namespace prefix, which helps keep things consistent across ontologies. (Although this approach will eventually give me trouble going from OWL to UML, I haven't yet run into a case where the prefix is inconsistent. I think all I would have to do it increase the maximum cardinality of the namespace prefix to deal with this. I'll deal with that later.)

In UML it is convenient to have multiple packages stereotyped as «Ontology» to take advantage of UML namespaces. Most UML tools allow you to show the owner of a class on a diagram, making it unnecessary to clutter the diagram with stereotypes and tagged values when you use a class from another ontology on a diagram. You simply create a package for the borrowed classes and apply the «Ontology» stereotype to those packages.

Related articles by Zemanta

• Introduction to the Semantic Web (slideshare.net)
• Introduction To RDF and RDFS (slideshare.net)

Class Name Capitalization?

In another posting I mentioned the convention for capitalizing class names. I've been looking into this more deeply today, and I'm even more puzzled about how we got to where we are than I was when I started!

The convention I've seen the most is UpperCamelCase, which I've seen in object-oriented programming languages, OWL, RDFS, and XML. Where did this convention come from, especially the distinction between UpperCamelCase for class names and lowerCamelCase for properties?

When I model for an audience of business people, I make the names non-technical because they seem to find anything that smells of technology offensive. To make the names non-technical, I use spaces between the words, title case for the words themselves, and I spell out acronyms that would be unfamiliar to a layman. I rely on transformations to convert those names into CamelCase for technical language parsers.

Still, why do people expect to see UpperCamelCase in computer languages or Title Case in normal English for concepts? One answer I can conjure is that it is useful in English sentences. It signals to the reader that I'm being specific when I capitalize Association End, for example, because it makes it clear that I'm talking about the UML meta-class called AssociationEnd rather than the more general idea of the end of an association, which might include a name, multiplicity, stereotype, and a constraint.

Why are the capitalization rules for conceptual models different from an encyclopedia such as Wikipedia or Encyclopedia Britannica? Wikipedia naming conventions are more or less sentence case, although Wikipedia acknowledges that "Outside of Wikipedia, and within certain specific fields (such as medicine), the usage of all-capital terms may be a proper way to feature new or important items." The Encyclopedia Britannica convention seems to only capitalize proper nouns, as in the example computer programming language. If we were to follow these encyclopedia capitalization rules, proper nouns would only apply to instances (except for cases where a class name contains a proper noun, as in "Epstein-Barr virus"). Do we have the capitalization conventions backwards for classes and instances in an ontology / conceptual model?

One reason may be what the Wikipedia article on capitalization says: "Common nouns may be capitalized when used as names for the entire class of such things, e.g. what a piece of work is Man." This makes me think maybe we're on the right track. However, The Open Biomedical Ontologies Foundry naming wiki page disagrees! It recommends: "Don’t enforce dogmatically, but prefer lower case beginnings for class and property names. Capture names just as they would appear in normal English written text, i.e. where acronyms and proper nouns cannot be avoided in names they should be capitalized." For example, they say to "Use ‘microarray’, ‘DNA microarray’, ‘pH value’, ‘Golgi apparatus’."

So, what is the right way to capitalize concept names in an ontology / conceptual model? In the world of RDFS and OWL, the convention seems to be that the first letter is always capitalized. I think what is important is consistency, but I do question the convention.

Can anyone shed some light on this?

Enterprise Ontology

I just found a great blog entry about Modeling an Organization Using Enterprise Ontology. It was an enlightening read about something I thought to be true but have never seen expressed. Highly recommended for all enterprise architecture practitioners.

What is an Ontology?

Image via Wikipedia

In this post I ponder the definition of an ontology using the Semiotic Triangle as a guide. (Note that because business people do not understand what an ontology is, I prefer to call it a concept model.) I purposely gloss over the nitty gritty of taxonomy, generalization, specialization, dynamic classification, and so on, to focus on defining an ontology by what it provides to its consumers.

Before I talk about what it provides, I'd like to explain what goes into an ontology. An ontologist works with subject matter experts to develop and validate a conceptualization of the real world within a particular domain, such as finance, weather, or even music theory. The ontologist develops this conceptualization either by reusing existing concepts that other ontologists have defined, or by defining new concepts. The ontologist can generate structured English sentences to make it easier for the SMEs to understand and validate the ontology. Some examples of concepts might be Invoice, has line item, Wind, has speed, Chord, and has pitch. Regardless of who defines the concepts, the ontologist defines every concept using a predefined vocabulary of symbols, which is built on set theory and predicate calculus. These concepts are generally classes and properties, but can also included axioms expressed in a logic language.

So, why would an ontologist put that much effort into creating a conceptualization of the real world? There is a spectrum of reasons, ranging from the low end to the hard core. Here are some examples, ranked from the low end to the high end:

• A database for a business to track real-world things needs to reflect the real world as much as possible to reduce rework in the database and the programs that manipulate it.
• An enterprise architecture is a kind of an ontology about information, processes, roles, collaborations, and rules that allows business people to improve their business.
• IT systems with different databases and interfaces need a Rosetta Stone to communicate. This is called semantic interoperability.
  
• An expert system aids in the decision making of human professionals, such as doctors or pharmacists.
• An artificial intelligence learns by itself, simulates human reasoning, and answers questions.
  

All of these things require some kind of an ontology. My experiential sweet spot is in enterprise architecture and semantic interoperability, so I'll expound on them a bit more.

Many ontology consumers use an ontology about the enterprise to reason about their business so they can bring more value to their customers than their competitors. Being able to see how the business works in terms of a controlled vocabulary allows business people to optimize how they meet the needs of their customers.

Other ontology consumers augment the ontology about the enterprise with a Rosetta Stone for aligning disparate systems. How does that work? An ontology allows its consumer to understand the ontologist's conceptualization of the real world, link a data element in a system to an ontology concept to declare its real-world meaning, and follow a link from a data element to an ontology concept to determine its real-world meaning. Having this Rosetta Stone allows computers to automatically map information elements between systems, and it provides a well-thought-out, overarching structure for all information in an enterprise or a community.

Related articles by Zemanta

• Artificial Intelligence 2.0 (technotations.wordpress.com)
• Intelligence, algorithms, and anthropomorphism (tor.com)
• An Intelligent System Helps Elderly Or Memory-impaired To Remember Everyday Tasks (innovationtoronto.com)
• Does the Semantic Web Need Ontologies? (groups.csail.mit.edu)
• Science goes back to basics on AI (news.bbc.co.uk)