UML Associations in ODM

One of the major differences between the Ontology Definition Metamodel (ODM) and my UML profile for OWL is how associations are modeled. ODM treats the name of an association and its reading-order arrow as a property rather than the association ends. I find this rather odd. Not only are such models unusual, the UML specification itself uses no association names in its diagrams, except for the examples of that notation.

The way I have been modeling things at the business level for many years does not use the association name at all; it uses the association end names. These association ends are properties in the UML metamodel, so why shouldn't they represent properties in an ontology? One might argue that in UML, classes own their properties and in an ontology, properties are global, not owned by anything. I've made one simple change in interpretation of the UML specification to make this work: ownership does not convey into OWL. A property's domain corresponds to its owning class, and its range corresponds to its its type. Because the unspecified domain and range of a property is interpreted as having Thing as the domain and range, and because, practically speaking, every class in an ontology is a specialization of Thing, this interpretation works for all properties. When the association is bidirectional, the other end is an inverse in OWL, which is very convenient. Therefore, I can model in my usual way, sprinkle on a few stereotypes, and generate OWL.

There are three ways to name association ends. Many metamodelers from the OMG prefer noun phrases. Ontologists prefer verb phrases. Data modelers prefer prepositional phrases. Transforming these styles into an ontology is a matter of prepending the word "has" for noun phrases, leaving verb phrases alone, or prepending the word "is" to prepositional phrases.

Here is an example of an association with its ends named as verb phrases:

Here is an example of an association with its ends named as noun phrases:

Here is an example of an association with its ends named as prepositional phrases:

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.

Ontology Definition Redux

I just had a debate with an ontologist friend about whether or not an ontology is a kind of a taxonomy and a taxonomy is a kind of controlled vocabulary.

I believe what is true in Formal Concept Analysis should be true in every ontology: every generalization must have fewer attributes than its specializations, and every specialization must have more attributes than its generalizations.

If we were to create an ontology about controlled vocabularies, taxonomies, and ontologies, we would say that a controlled vocabulary is a set of words; a taxonomy is a set of terms with hypernym, hyponym, and synonym relations between the terms; and an ontology is a set of terms with hypernym, hyponym, and synonym relations between the terms, with additional relations and perhaps axioms. Therefore, I think an ontology is a kind of a taxonomy and a taxonomy is a kind of controlled vocabulary.

What do you think?

Here is more supporting evidence I've dug up:

• CLARITY IN THE USAGE OF THE TERMS ONTOLOGY, TAXONOMY AND CLASSIFICATION: "A very simple ontology could perhaps better be named 'taxonomy'"
  
• What are the differences between a vocabulary, a taxonomy, a thesaurus, an ontology, and a meta-model?:
• "A controlled vocabulary is a list of terms that have been enumerated explicitly. This list is controlled by and is available from a controlled vocabulary registration authority. All terms in a controlled vocabulary should have an unambiguous, non-redundant definition."
• "A taxonomy is a collection of controlled vocabulary terms organized into a hierarchical structure."
• "A formal ontology is a controlled vocabulary expressed in an ontology representation language."
• "The word 'ontology' has been used to refer to all of the above things."
• Ontology Development 101: A Guide to Creating Your First Ontology:
  
• "The ontologies on the Web range from large taxonomies categorizing Web sites (such as on Yahoo!) to categorizations of products for sale and their features (such as on Amazon.com)."
• Organizing Knowledge with Ontologies and Taxonomies:
• "The concepts are defined in an ontology that maps the main ideas and their relationships. It also include the creation of a set of terms that defines how to label items according to the concepts described in the conceptual map. This structured set of terms is a taxonomy."
• "Taxonomies are the classification scheme used to categorize a set of information items. They represent an agreed vocabulary of topics arranged around a particular theme."
• Building and Using Ontologies
• "An ontology may take a variety of forms, but necessarily it will include a vocabulary of terms, and some specification of their meaning."
  

UML Profile for OWL, Part 2: RDF Resource

In my previous posting (Part 1), I introduced UML profiles to prepare for this posting. In this posting (Part 2), I will describe the top of the UML stereotype specialization hierarchy for defining an OWL ontology. In subsequent postings I plan to descend the specialization hierarchy and describe each specialization in detail.

The top of the specialization hierarchy is the «RDF Resource» stereotype. One of the ambiguities in RDF and RDFS is the capitalization of the word "resource". In RDF, "resource" is a thing with a URI and possibly a namespace prefix; whereas in RDF-S, "Resource" is the class of all RDF resources. I capitalize the first letter of the words in both stereotypes and qualify them with RDF or RDFS because classes and metaclasses always have the first letter of every word capitalized (in every convention I've ever seen except for one, and you know who you are :-) ), and stereotypes are virtual specializations of UML metaclasses.

The «RDF Resource» stereotype tells the transformation software to transform a UML metaclass into an rdf:resource. Although I haven't thought of a reason why this would be a useful thing to do yet, mainly because the specializations I'll be introducing in subsequent postings are so much more useful, I don't want to disallow its use because everything identifiable by a URI is an rdf:resource. (Please feel free to leave a comment if you have an opinion!)

As with rdf:resource, the «RDF Resource» stereotype has a URI and may have a namespace prefix. The URI is a String that can either be a fragment (e.g., "Person") or a full URI (e.g., "http://somewhere.com/myOntology.owl"). In this profile the URI is optional because the transformation software can often derive it from the UML metaclass' name and owning element's URI. For example, a UML Package stereotyped as an «RDF Resource» might represent an ontology file's URI. The transformation software can then automatically determine the URI fragment of a UML Class based on that Class' name. (More about this in a subsequent posting on the «Ontology» stereotype.)

The namespace prefix is a String that represents the URI with a much shorter name (e.g., the first three characters in "rdf:resource"). Whatever UML metaclass stereotyped as «RDF Resource» that has both a URI and a namespace prefix defines their equivalence for use in other places. For example, when you want to re-use a property in another namespace, you can set that property's namespace prefix to it's real owner. Normally, when you don't specify a property's namespace prefix or URI, the transformation software derives it from the owning UML Class' Package, which must be stereotyped as an «Ontology». I'll explain more about this as I descend the stereotype hierarchy.

I get the feeling I'm being too abstract in this posting, but at this level in the hierarchy, I'm having trouble coming up with a good example. I plan to give better examples as I work down the stereotype hierarchy and can show some actual UML diagrams. (Gentle feedback is welcome!)

Related articles by Zemanta

• Linked Data and the Semantic Web: What Are They and Should I Care? (slideshare.net)
• Introduction To RDF and RDFS (slideshare.net)

UML Profile for OWL, Part 1: UML Profiles

As I mentioned previously, this is the first part of a multi-part description of an OWL profile for UML that I have developed. In contrast to the Ontology Definition Metamodel (ODM), which requires an ontologist to model in an unusual way, this profile allows an ontologist to mark up a normal UML model with stereotypes. This profile is not  standardized, although I hope to get it standardized through the OMG, and it is nonetheless useful in the meantime.

First I should introduce UML profiles. A UML profile is a way of extending metaclasses in the UML metamodel with virtual specialization hierarchies, semantics, constraints, and graphic images. (for hard-core UML metamodel geeks, the reason I use the word virtual is because a stereotype does not technically have a generalization relationship with a UML metaclass, it has a special association with it, called an Extension.) A stereotype can have any number of pseudo meta-properties, called tagged values. Modern UML tools allow a modeler to add values to a stereotyped meta-class instance, such as a UML Class. For example, I can create a stereotype that extends a UML Class, called Resource, that has a URI. Indeed, this is what I've done in the OWL profile.

A UML stereotype can further specialize another UML stereotype, thus adding to the virtual specialization hierarchy of a UML metaclass. For example, I can define a Property stereotype that specializes Resource, and I can further define a Transitive Property stereotype that specializes Property. I can then apply the Transitive Property to a UML Association End, which tells the transformation software how to generate the intended OWL statements and makes it possible to define transitive properties in UML.

In the next posting (Part 2) I will describe the top of my OWL stereotype specialization hierarchy. In subsequent postings I will descend the specialization hierarchy and describe each specialization in detail.

Related articles by Zemanta

• Glossary of UML terms (modeling-languages.com)

UML--It's Not Just for OO Software Design Anymore!

Image via Wikipedia

As I mentioned previously, UML 2, with a simple profile, can represent what an OWL 1 ontology can represent.

There is a heavier-weight profile called the Ontology Definition Metamodel (ODM), but it requires me to model concepts in a different way. I prefer starting with standard UML, then augmenting that with additional semantics in the form of stereotypes.

UML is a more expressive language than OWL, and because it is a graphical language, it is quicker to manipulate in a modern UML tool. For example, OWL does not have association classes, nor does it have a direct way to sort relations. One can build something equivalent in OWL, but I think that undesirably replaces an abstraction with an implementation detail, much like a loop in a high-level language turns into lots of machine code. Therefore, in MDA terms, a UML model is more of a PIM and an OWL model is more of a PSM.

I can sit in a room of business subject matter experts (SMEs) and capture a draft ontology in real time, as I project my progress on a wall, for all to see. The SMEs don't know they're learning UML as I build up a model in their own words. At the end of the session I publish what I captured for all to validate, not only as diagrams, but also as structured English! The ontology I capture is not limited to classes and associations--I also capture processes as activity diagrams and business-level SoaML service architectures. (The semantics for class and activity diagrams are defined in Common Logic in the upcoming fUML specification from the OMG.)

Part of the value in capturing a business ontology in UML is what I can do with it afterwards. I can transform it into OWL to immediately start creating and querying instances. I can augment the business ontology with a logical system architecture to generate detailed requirements for a vendor to build a service or to generate XSD, WSDL, DDL, and Java using a high-level MDA tool such as ModelPro. I think that's pretty powerful.

In future blog postings I will introduce the lightweight OWL 1 profile I've developed for UML 2.

Related articles by Zemanta

• Simplifying the UML - the Request for Proposals is out (modeling-languages.com)
• UML is a notation not a develoment method (modeling-languages.com)
• OWL 2 is a Proposed Recommendation (w3.org)

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)

Modeling States for Business People

In a model intended for business people I prefer to model states as subclasses. Some say this is not a good idea, but I'm going to give you what I think are some pretty compelling reasons for why it is.

Modeling states as an enumeration is pretty standard, so I don't think I need to go into the details here. What I do want to go into is how subclasses are very similar, yet have more benefits.

UML 1.x generalizations used to have a "discriminator", which was a value (string, integer, enumeration, or whatever) to represent each subclass. Every subclass had its own discriminator value, which made the discriminator look an awful lot like an enumeration. (Discriminators have now morphed into a similar but more complex notion of "powertypes" in UML 2.)

A subclass per state specifies the equivalent of enumeration literals while also specifying which states should have additional properties and constraints. There are many cases where a thing in a state has different properties than that thing in a different state. For example, an Unfilled Customer Order should not have a shipment tracking number, but a Filled Customer Order should have one. Reifying these states as sub-classifications allows us to capture this business rule.

Without subclasses, all we could capture is two unrelated facts, as an enumeration (filled and unfilled) and an optional shipment tracking number. Business people naturally understand the sub-classification in a concept model without explanation because it is how they think. (We could also use OCL, but it is just not natural for them.)

It's not necessary for every one of these subclasses to have different properties, which means we can generalize and say that states can be represented as subclasses.

UML allows a lot more flexibility with generalization sets than most programming languages and databases naturally support, so many technical people react with "you can't do that!" Well, the business people naturally understand such high-level models without explanation, especially when I run the model through my über glossary generator that describes the generalization sets in plain, structured English.

Why can't business people have the classifications they envision directly in their models? One should be able to transform a model for business people (without technology limitations) into a target technology (perhaps with technology limitations). In fact, I can use the MDS ModelPro tool (also part of NoMagic's Cameo SOA+ plugin) to transform these models into Java, XSD, and DDL. These models work well for both business people and computers.

So, the reasons for using subclasses to represent states are that you can tie together unrelated facts with business rules, present models to business people that reflect how they think, and still be able to transform these models into technology artifacts.

Welcome to Onto Goo!

This is a blog for people in the disparate information management community to come to terms and unify. I think it may be a long road, but over time it is achievable.

I am very pragmatic and technology neutral because I grew into a role where I model, on the clock, the world as business subject matter experts see it. I embrace the OMG's Model Driven Architecture idea of separating concepts from the technologies that implement them. I am a primary contributor to the OMG's Information Management Metamodel (IMM), responsible for a core ontology of information that provides a theory of how information technologies correspond to one another.

What is the information management community you ask? This is a community that spans multiple entrenched camps. The camps that come to mind usually center around particular technologies, such as object oriented (OO) languages, relational database management systems (DBMSs), XML schema, and OWL. For example, people who model in an ER tool are very likely to have grown up on relational databases. People who model in a UML tool are very likely to have grown up on OO languages. People who model in a tool such as XML Spy or Oxygen are very likely to have grown up on XML. People who model in Protege, TopBraid, or Knoodl are very likely to have grown up on RDF Schema and OWL. These camps generally see the world differently from other camps and think the others are wrong.

As I mentioned, I am technology neutral; however, one technology that I find is a superset of these other modeling languages and technologies is UML. "What?!" I hear you say? Yes, I assert that UML 2, with a couple of lightweight profiles, is a superset of all of these technologies and languages.