Semantics and Ontology

Zen mind

by

Part 1 & Part 2

We just conducted a weeklong training session on OWL/DL and Ontology Engineering.  Several of the participants will be attending the Semantic Technology Conference, and felt they will be getting a lot more out of the conference, because of the training.  On drilling down a bit further, we found that the main benefit in this regard was breaking down their pre-conceived ideas of what semantics is.  They were several days into the training before they were deprogrammed enough to completely follow what was going on.

In this blog, and perhaps the next couple, I want to summarize some of these preconceptions, and some ideas that will at least make you aware of them, and may help you get more out of the conference, or any other studying you may be doing in the area.  We call this “Zen Mind” from the Zen masters belief that to really learn you have to get as many of your preconceived ideas out of your head long enough to establish some new patterns.  I believe the Zen Masters called it “beginners mind” (perhaps they thought Zen Mind was too promotional).

In that spirit, let us offer up some preconceived ideas and the “koans” that seem to best address them.

Preconceived idea #1: Properties belong to Classes

People from a relational background make the partially correct analogy between relational attributes and semantic datatype properties and between foreign key relationships in relational and object properties in semantics.  However, this analogy will bite you.  Repeatedly, as our students demonstrated.

They had a tough time remembering that the same property can be associated with many different classes.  They were so used to each property being unique, that when they did associate the same property with more than one class, they gave it different names (locatedIn, became locatedInState, locatedInCountry etc).

The koans we decided were most useful in this case were two:

• Classes are really “sets” (to help get past the idea that classes are some sort of template, as they are in relational and Object Oriented technologies.  This seems to help overcome the temptation to believe that the property belongs to the class)

• Properties own classes (when you define a restriction class in OWL/DL, what you have really done is use a pre-existing property to create a set of instances that have “someValues” from that property.  It is the property that gives rise to the class, and therefore is more useful to think of the properties owning the classes – at least compared to the classes owning the properties)

So, if you find yourself relapsing into relational thinking, just repeat the two koans until the symptoms disappear.

Multiple Inheritance v. Multiple Classification

Koan: MI is almost always Intersection

Koan: MI makes sets smaller, does not make capabilities larger

Preconceived Idea # 2: Multiple Inheritance

If you come from an Object Oriented background, in particular one that supports multiple inheritance, you might find an apparent similarity between multiple inheritance in OO and having a class be subsumed by two others.  However, if you try this out, you’ll realize you’re not getting what your expecting.  This is because the semantics are different.  In OO there are really two things going on at the same time: subtyping and inheritance.  The inheritance piece is giving you properties from both of your parents. If one parent had the “foo()” method and the other parent had the “bar()” method, the child now has both.  The child has all of the attributes, and all of the behaviors of both parents.  The child is essentially the union of the behaviors of the two parents.  Semantics is not dealing with behavior, it’s dealing with typing, membership and classification.

So, take a couple of koans and call me in the morning:

Subclassing from two classes makes you the intersection, not the union of the two If a class A is a subclass of class B and class C, all members must be members of both parents.  This is the intersection of the two parents, not the union.  It is really a subclass of the intersection, but we’ll do that on another post.

Multiply classify an instance – The power in semantics lies in the ability to classify an instance multiple ways.  This gets at what most OO people want to do with MI, and it’s far more flexible.

Dublin Core and Owl

by

Why isn’t there an OWL version of Dublin Core?

We’ve known about the Dublin Core (http://www.dublincore.org/) pretty much forever. We know it has a following in Library Science and content management systems, and Adobe uses their tags as the basis for the XMP (www.adobe.com/products/xmp/). And we knew that at least one of the original architects for the Dublin Core, Eric Miller (www.w3.org/People/EM/) is now deeply invested in the Semantic Web. So, we knew it was just a matter of time until we came to a client who was implementing a content management system, using the Dublin Core tags and who wanted to integrate that with their Enterprise Ontology. We assumed there was a Dublin Core OWL implementation just for this purpose. If there is, it’s pretty well hidden. (One of my motivations in this writing is to see if this brings it out of the woodwork). The obvious one (the one that comes up first in a Google search) is from Stanford (protege.stanford.edu/plugins/owl/dc/protege-dc.owl).

On closer inspection, the only OWL property used in this ontology is the owl:annotationProperty (comment). The rest of it is really just naming the tags and providing the human readable definitions. But this really isn’t helpful for integration. It turns out there are several other problems with the Dublin Core for this type of usage. For instance, the preferred usage of the “creator” tag is a LastName, FirstName literal. LastName, FirstName is pretty ambiguous.

There are a lot of “Smith, John”s in most corporate databases, and in many cases we know much more precisely (to the urn: level) which John Smith we’re dealing with when we capture the document. We have built an OWL version of the Dublin Core suitable for integration with Enterprise Ontologies. We ended up, I’m sure, re-inventing the wheel. I’m on the road again starting tomorrow, but within a week or two we expect to have it vetted and out in a suitable public place. In the next installment I’ll go over some of the design tradeoffs we made along the way. By the way, what suitable public places are people going to for their ontologies these days?

White Paper: Categories and Classes

by

Getting the categories and classes distinction right is one of the key drivers of the cost of traditional systems.

We’ve been working with two clients lately, both of whom are using an ontology as a basis for their SOA messages as well as the design of their future systems. As we’ve been building an ontology for this purpose we became aware of a distinction that we think is quite important, we wanted to formalize it and share it here. In an ontology there is no real distinction that I know of between a class and a category. That is: classes are used for categorizing, and you categorize things into classes. If you wanted to make a distinction, it might be that category is used more in the verb form as something you do, and the class is the noun form.

Categories and Classes in Traditional Apps

But back in the world of traditional applications there is a quite significant difference (although again I don’t believe this difference has ever been elaborated). In a traditional (relational or object oriented) application if you just wanted to categorize something, (say by gender: male and female) you would create a gender attribute and depending on how much control you wanted to put on its content you
would either create an enum, a lookup table or just allow anything. On the other hand if you wanted behavioral or structural differences between the categories (let’s say you wanted to distinguish sub
contractors from employees) you would set up separate classes or tables for them, potentially with different attributes and relationships. We’ve been studying lately what drives the cost of traditional systems,
and getting this category/class distinction right is one of the key drivers. Here’s why: in a traditional system, every time you add a new class you have increased the cost and complexity of the system. If you
reverse engineer the function point methodology, you’ll see that the introduction of a new “entity” (class) is the single biggest cost driver for an estimate. So every distinction that might have been a class, that
gets converted to a category, provides a big economic payoff. It’s possible to overdo this. If you make something a category that should have been a class, you end up pushing behavior into the application code, which generally is even less tractable than the schema. So we were interested in coming up with some guidelines for when to make a distinction a category and when to make it a class.

Categories and Classes in gist

As it turns out, we had foreshadowed this distinction, although not for this reason, in gist, our upper ontology. Gist has a class called “category” whose intent is to carry categorical distinctions (from one lower level ontology to another) without necessarily carrying their definitions. For instance when we worked with a State Department of Transportation, we had a class in their enterprise ontology called “Roadside Feature.” A Roadside Feature has properties such as location and when by what process it was recorded. Several of their applications had specific roadside features, for instance “fire hydrants.” In the application fire hydrant is a class, and therefore is one in the application ontology. But in the enterprise ontology “fire hydrant” is an instance of the category class. Instances of fire hydrant are members of the roadside feature class at the enterprise ontology level, and associated with the category “fire hydrant” via a property “categorizedBy.” A fire hydrant can therefore be created in an application and communicated to another application that doesn’t know the definition of fire hydrant, with almost no loss of information. The only thing that is lost on the receiving end is the definition of fire hydrant, not any of the properties that had been acquired by this fire hydrant.

Download the White-paper to read more.

Written by Dave McComb

Building Ontologies Visually Using OWL

by

Faced with the challenges of UML and other modeling notations, we developed our own Visio-based ontology authoring tool. We’ve been building large enterprise ontologies for our clients using the W3C web ontology language OWL. If you’re not familiar with OWL, think of it as a data modeling language on steroids. It also has the fascinating property of being machine interpretable.

You can read the model with the aid of an inference engine, which not only tells you if all the assertions you have made are consistent, but also can infer additional parts of the model which logically follow from those assertions. So far the available tools for developing OWL ontologies, like Top Braid Composer and Protégé, look and feel like programming development environments. Some visualization tools are available but there is no graphical authoring tool, like Erwin or ER Studio, that data modelers have become used to.

The larger your ontology gets, the harder it is to understand and navigate using the current tools, and enterprise models push the boundaries of size and complexity for OWL ontologies. Another problem is that, because of OWL’s expressiveness, the UML diagramming conventions can result in a very complex-looking diagram even for simple ontologies.

This makes it hard to review models with subject matter experts (SMEs), who typically have about 15 minutes’ worth of tolerance for training in complex modeling notations. Faced with these problems, we developed our own Visio-based ontology authoring tool. It uses a more compact, more intuitive diagramming convention that is easier for SMEs to grasp.

From the diagram you can generate compliant OWL in XML format that can be read by any of the standard editors or processed by an OWL inference engine. The tool, which we call e6tOWL, is built as an add-in to Visio 2007 which provides the diagramming platform. In addition to the Visio template containing the diagramming shapes and the OWL generation function, the tool provides a lot of layout and management functionality to help deal with the challenges of maintaining large and complex diagrams.

So far the results have been good. We find it faster, easier and more fun to create ontologies graphically, and SMEs seem able to understand the diagramming conventions and provide meaningful feedback on the models. We are still using Composer and Protégé for running inference and debugging, but all our authoring is now done in Visio. We currently maintain the tool for our own use and provide it to our clients for free to help with the ongoing development and maintenance of ontologies.

Follow us on LinkedIn for more!

White Paper: The Seven Faces of Dr. “Class”

by

The Seven Faces of Dr. “Class”: Part 1

“Class” is a heavily overloaded term in computer science. Many technologies have implemented the concept slightly differently. In this paper we look at the sum total of concepts that might be implemented under the banner of “class” and then later we’ll look at how different technologies have implemented subsets.

The seven facets are:

  • Template
  • Set
  • Query
  • Type
  • Constraint
  • Inclusion
  • Elaboration

Template

One aspect of a class is to act as a “template” or “cookie cutter” for creating new instances. This is also called a “frame” based system, where the template sets up the frame in which the slots (properties) are defined. In the simplest case, say in relational where we define a table with DDL (Data Definition Language) we are essentially saying ahead of time what attributes a new instance (tuple) of this class (table) can have. Object Oriented has this same concept, each instance of a class can have the attributes as defined in the class and its superclasses.

Set

A class can be seen as a collection of all the instances that belong to the set. Membership could be extensional (that is instances are just asserted to be members of the class) or intensional (see below under the discussion about the inclusional aspect). In the template aspect, it’s almost like a caste system, instances are born into their class and stay there for their lifetime. With set-like classes an instance can be simultaneously members of many sets. One of the things that is interesting is what we don’t say about class membership. With sets, we have the possibility that an instance is either provably in the set, provably not in the set, or satisfiably either.

Query

Classes create an implied query mechanism. When we create instances of the Person class, it is our expectation that we can later query this class and get a list of the currently know members of the class. In Cyc classes are called “collections” which reflect this idea that a class is, among other things, a collection of its members. A system would be pretty useless if we couldn’t query the members of a class. We separate the query facet out here to shine a light on the case where we want to execute the query without previously having defined the class. For instance if we tag photos in Flickr with a folksonmy, and someone later wants to find a photo that had a combination of tags, a class, in the traditional sense was not created, unless you consider that the act of writing the query is the act of creating the class, and in which case that is the type of class we’re talking about here. This is primarily the way concept like taxonomies such as SKOS operate: tags are proxies for future classes.

Type

Classes are often described as being types. But the concept of “type” despite being bandied about a lot is rarely well defined. The distinction we’re going to use here is one of behavior. That is, it is the type aspect that sets up the allowable behavior. This is a little clearer in implementations that have type and little else, like xsd. It is the xsd type “date” that sets up the behavior for evaluating before or after or concurrent. And it is the polymorphism of types in object oriented that sets up the various behaviors (methods) that an object can respond to. It is the “typeness” of a geographicalRegion instance that allows us to calculate things like its centroid and where the overlap or boundary is with another geographicalRegion. We rarely refer to the class of all items that have xsd:date as if it were a collection, but we do expect them to all behave the same.

Constraint

Constraints are generally implemented as “guards” and prevent noncompliant instances from being persisted. There is no reason that the constraints need to be associated with the classes, they could easily be written separately and applied to instances, but many implementations do package constraints with the class definition, for two reasons: one the constraints are naturally written in and lexically tied to the cl ass definition and the other is just for packaging around the concept of cohesion. The constraint can be a separate language (as with OCL the Object Constraint Language) or may be an extension to the class definition (as ranges and foreign key constraints are in relational).

Inclusion

That is, inclusion criteria. This is for classes that support inference, and are the rules that determine whether an instance is a member of the class, or whether all members of a class are necessarily members of another class. It also includes exclusion criteria, as they are just inferred membership in the complement. While it is conceivable to think of the “open world” without inclusion criteria, it really comes to the fore when we consider inclusion criteria. Once we have rules of inclusion and exclusion from a set, we have set up the likelihood that we will have many instances that are neither provably members or provably not members, hence “satisfiability.”

Elaboration

Elaboration is what else can be known about an item once one knows its class membership. In Object Oriented you may know things about an instance because of the superclasses it is also a member of, but this is a very limited case: all of this elaboration was known at the time the instance was created. With more flexible systems, as an instance creates new membership, we know more about it. For instance, let’s say we use a passport number as evidence of inclusion in the class of Citizens, and therefore the class of People, we can know via elaboration that the passport holder has a birthday (without knowing what their birthday is). To the best of our knowledge, there is no well supported language and or environment that supports all these facets well. As a practical consequence designers select a language implement the aspects that are native and figure out other strategies for the remaining facets. In the next installment of this series, we will examine how popular environments satisfy these aspects, and what we need to do to shore up each.

Click here to read part 2. 

Written by Dave McComb

FOIS Keynote: Ontology-Driven Information Systems

by

Orginally published in October 2008

The following paper was given as a keynote address at the 5th International Conference on Formal Ontology in Information Systems held in Saarbrücken, Germany in October 2008.

Title: Ontology-Driven Information Systems: Past, Present and Future Author: Michael Uschold Abstract : We trace the roots of ontology-drive information systems (ODIS) back to early work in artificial intelligence and software engineering. We examine the lofty goals of the Knowledge-Based Software Assistant project from the 80s, and pose some questions. Why didn’t it work? What do we have today instead? What is on the horizon? We examine two critical ideas in software engineering: raising the level of abstraction, and the use of formal methods. We examine several other key technologies and show how they paved the way for today’s ODIS. We identify two companies with surprising capabilities that are on the bleeding edge of today’s ODIS, and are pointing the way to a bright future. In that future, application development will be opened up to the masses, who will require no computer science background. People will create models in visual environments and the models will be the applications, self-documenting and executing as they are being built. Neither humans nor computers will be writing application code. Most functionality will be created by reusing and combining pre-coded functionality. All application software will be ontology-driven.

Web 3.0

by

I’m weighing in in favor of Web 3.0 as an alias for the Semantic Web.

I’m weighing in in favor of Web 3.0 as an alias for the Semantic Web. I know there are a lot of people who will roll their eyes and initiate some anti hype exorcism, but let’s have a sober look at the pluses and minuses here. Web 3.0 is not without its problems. The first problem with Web 3.0 is that everyone is defining it to their own ends. As Montoya Herald summed it up at http://www.christianmontoya.com/2007/10/08/web-30-i-about-money/, Web 3.0 is essentially whatever each of the companies that used the term are working on next. The second problem is that it does pander to the hypemeisters. But the very people who decry hype the loudest are often those who benefit from it the most. (Who can argue that the hype of the Web and Web 2.0 didn’t advance the careers and opportunities of the very people who now think Web 3.0 is hype?) A lot of people seem to be comfortable with Web 2.0 now, despite the fact that it has no real unifying principle. Web 2.0 is blogs and wikis and Facebook and MySpace (user generated content) and AJAX and Rich Internet Applications for a richer user experience in a browser, but really there isn’t anything holding it together or giving it a defined shape. Maybe we don’t need to call the Semantic Web: Web 3.0. But if we don’t some other marginal improvement in an existing technology will claim the moniker. In other words, there will be a Web 3.0 and we will find ourselves explaining to people: “well yes, but that is just a part of the vision…” Isn’t the term “Semantic Web” good enough? It’s good for the population that is already “in the tent” but it suffers from being the next big thing for too long for many others. Many people have discounted what they believe the Semantic Web to be(often by making up things that it isn’t and then objecting to that straw man). Web services suffered from a similar fate, for a long time, as thought leaders confused it with services delivered over the web (Software as a Service for instance) which it has some things in common with, but the two aren’t the same. For some, calling the Semantic Web: Web 3.0 gives an opportunity to take another look. So, I’m coming down in favor of “Web 3.0 = Semantic Web.” What do you think?

 

Silos of Babel

by

Semantic technology can be a ‘lingua franca’ to connect disparate information silos.

Several speakers and writers have referred to the problem of systems integration as being one of getting systems written in different languages to communicate. Whenever I’ve heard or seen this, the speaker/writer goes on toIf you wanted to make a case that the semantic differences in languages made integration difficult, this would be the place to make it. say that the difficulty is that getting COBOL to speak to Java is like translating Spanish to Chinese. (Each speaker puts different languages in there.) I like an analogy as much as the next person, but this one strains it a bit too much.

Semantically, COBOL and Java (or any two procedural languages) aren’t that different. If you look in their BNF (Backus Naur Form – a standard way of expressing the grammar of a programming language) you’ll find only a few dozen key words in each language. Yes, there are grammatical differences and some things are harder to express in some languages than others.

But this isn’t where the problems come from. More modern languages (C++, Java, C# and the like) have very large frameworks and libraries, each consisting of tens of thousands of methods. If you wanted to make a case that the semantic differences in languages made integration difficult, this would be the place to make it.

Certainly it is these libraries that make learning a new language environment difficult, and it is these libraries that provide most of the behavior of a system, and therefore most of its semantics. This is what makes systems conversion difficult, for in converting a system to an equivalent in another environment, all the behavior must be reimplemented in an equivalent way in the new environment, and depending on how much of the environment was used this can be a large task. But this still isn’t where the integration problem lies.

Most integration is performed at the data level, either through extract files or some sort of messages. What makes integration difficult is each system to be interfaced has developed its own language about what each data attribute “means.” This is obvious with custom systems: analysts interview users, get their requirements and turn them into data designs. Each table and attribute means something, and this meaning is conveyed partially in the name of the item and partially in its documentation. Developers develop the system, procedure writers develop flow and procedures, and end users develop conventions.

Eventually each item means something, often close to what was intended, but rarely exactly the same. The same thing happens more subtly with packaged software. First, most packages have far more complex schemas than would be developed in a comparable custom system (the package vendors have to accommodate all possible uses of their package). Second, package vendors have tended to make their field definitions and validation more generic, as this is the low road to flexibility.

The process of implementing a package is really one of finalizing the definition of many of the attributes, some of which is done through parameters and some of which is procedural and convention. The net result is that a large organization will have many applications (classically each in its own “silo” or vertical slice of the organization) each of which has its data encoded in its own schema, essentially its own language. I sometimes call these their own idiolects (a dialect for one).

In my opinion it is these “silos of Babel” that create most of the difficulty, cost and expense in integrating. Luckily we have a solution to this the application of semantic technology as an intermediary, a lingua franca if you will, not of computer languages or libraries, but of meta data.

Written by Dave McComb

Contact Us

Semantic Arts, Inc.
123 N College Avenue
Suite 218
Fort Collins, CO 80524

Email:
[email protected]

Phone:
(970) 490-2224

Learn More

Data-Centric
Services
Expertise
Resources
gist
About Us
Privacy Policy