An Approach that Uses ODM

Wow, it's been a long time since I had time to write anything here. I need to get back into the habit.

Today I found a really good approach that I think I will adopt for my own OWL profile for UML. Rather than transforming directly into and out of OWL, this approach is a model-to-model transformation from UML to the OWL metamodel of the ontology definition metamodel (ODM). This is a way that plays nice with ODM rather than ignoring it or sidestepping it. Also, having all the OWL metaclasses in one place makes it easier to determine if I have 100% coverage of the OWL concepts.

The other thing I like is that the author(s) of this approach understand how to use UML association ends as OWL properties. After all, the UML 2.x specification defines association ends as specializations of properties, so why use the entire association as the property? The only complaint I have about their example diagram is that the hasArtist property should have hasSculptor and hasPainter as sub-properties, and the creates property should have sculpts and paints as sub-properties. This is easy to do in UML with the subsets meta-association between the association ends, which appears as a constraint on the diagram. (It is also possible to use association generalization, but that can sometimes have issues I won't cover here.)

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)