This is the first of two posts that discuss how to define synonyms and related entities in the Web Ontology Language (OWL) and the Simple Knowledge Organization System (SKOS). This post will focus on the basics in OWL. The next post will focus on the Simple Knowledge Organization System (SKOS) vocabulary that provides more sophisticated ways to show entities are similar or related without necessarily being exact synonyms. I've created a small example ontology called SKOSExamples to illustrate some of the concepts described in this and the next post. All of the Protégé screen snapshots in this and the next post are from this ontology.
Make sure you understand the difference between an IRI and a label property before reading further. If you don't understand this difference I recommend reading this previous post. Also, recall that in OWL terminology an entity is any OWL object: a Class, Property, or Individual.
There are two ways that entities in OWL can be defined to be synonyms:
Different IRIs. It is possible to have two different IRIs that represent the same concept.
Same IRI, different labels. The other way to indicate that an IRI can have multiple names but still represents the same concept is to have different labels. A label is an annotation property so it can be asserted on any OWL entity.
Assume I'm creating a geographic ontology and I want to define a class called Nation. However, I may also want to allow for the fact that both people and other systems may want to call this class Country as well. I often see people defining two classes and then using OWL to tell the reasoner they are both the same class (more on that below). However, I think the better solution is usually to use skos:altLabel (note: I cover the right way to add IRIs for specific entities such as skos:altLabel to your ontology in a previous post). The convention for labels is to use the rdfs:label property. SKOS adds three sub-properties to rdfs:label shown below. The skos:altLabel property is usually the lowest priority to display an entity. It is used when none of the other label properties have a value. The skos:prefLabel property has the highest priority. The skos:hiddenLabel is for literals that are used to find an entity but not to display it, e.g., for common misspellings. In this example we would use the literal "Nation" for skos:prefLabel and "Country" for skos:altLabel. We might also add "Nations" and other variants for skos:hiddenLabel.
That's the most straight forward example, and in most of the cases where you have more than one name for an entity I think this is the best way to handle it. Creating two entities and then telling the reasoner that they are the same works but it is usually overkill. Mostly all you care about is documenting that different labels may apply to the same entity and skos:altLabel works just fine for that and doesn't add extra entities or extra work for the reasoner. I've seen ontologies that seem rather complex at first, only to realize that many of the entities are the same as other entities. This is bad because it takes up extra memory without a justification but as in most cases, what matters the most to me is how easy it is to understand and maintain a model and adding lot of synonym entities can make an ontology more difficult to understand.
So, unless you have a good reason to use different entities, I would recommend using skos:altLabel and skos:prefLabel. Protégé and Web Protégé can utilize these additional labels. However, you need to configure your preferences to take advantage of this. In Protégé, go to File>Preferences>Renderer. In Entity Rendering click on Render by annotation property. Then click on the Configure button just below the rendering options. You will see a dialog where you can add/delete label properties (the first two squares with a + and - above them) and you can set the preferences for which properties are the best to use using the up and down arrow icons. In the screen capture below, I've set Protégé to first use skos:prefLabel, then if there is no value for that to use rdf:label and finally if neither of those exist to use skos:altLabel. You can do the same with Web Protégé using the Project>Settings>Display Name Settings option.
So much for labels. What are the good reasons to create multiple entities rather than just add additional labels? There are two use cases that immediately come to mind:
You are working with multiple ontologies and one of them already has an entity with a different name.
You want to refer to the entity in OWL axioms (e.g., class restrictions) and want to use more than one name depending on the axiom.
The first example is when you inherit an ontology that has an entity that is identical to an entity you want in your ontology but uses a different name. The first thing I would consider in such a case is to just use the existing entity from the other ontology and add a new skos:altLabel for that entity in your ontology.
However, there can be good reasons for not taking that approach. E.g., suppose you work for a software product company like SAP that also has its own consulting services group for installing, customizing, and extending the product. In the main company data model you would probably have a Customer class for the Customers that buy your software. The consulting group on the other hand might have the class Client rather than Customer. This could be a good reason to have a class called Client and to indicate that it was the same entity as the class called Customer. For example, it could be that for the domain experts defining the ontology for the consulting group it is more natural to think and define axioms in terms of clients. In this case you want to define Client to be Equivalent To Customer as shown above. Then as in the following two screen snapshots below you can write axioms using Customer or Client depending on which one is more intuitive to your domain experts.
The most common use for Equivalent To is to define the necessary and sufficient axioms for a defined class. However, you can also simply put the name of another class or property in that field and that will indicate that they are really the same class or property. Note: you can only make classes Equivalent To other classes and properties Equivalent To other properties.
If you have two synonymous Individuals then you also use the Description view. In the Description view for each Individual there are 3 fields: Type, Same Individual As, Different Individuals. If individuals Foo and Bar are really the same, you can enter Bar in the Same Individual As field for Foo. The reasoner will know that Foo and Bar are the same individual and a change to one will be reflected in the other. A classic example of this comes from the Philosophy of Language literature.
We might have an astronomy ontology with three individuals: Venus, TheMorningStar, and TheEveningStar. We could indicate that these three individuals are the same by adding TheMorningStar and TheEveningStar to the Same Individual As field for Venus. If we did that, the OWL reasoner would know that each IRI represents the same object.
Note that unlike most programming and database languages, OWL doesn't assume that two entities are different just because they have different identifiers (IRIs). It is possible for the reasoner to determine that two entities are the same or different without declaring them to be so. Also, it is possible to tell the reasoner to make all your individuals different. This can be useful for axioms and for SWRL rules. To achieve this you can use the Protégé command: Edit>Make all individuals different. If you do this, you will see that each individual has a copy of all the other individuals in the ontology in its Different Individuals field.
Those are the basics. What if you have two entities that are mostly similar but not identical? Or what if you want to represent that one concept is more or less general than another? That is where SKOS comes in and will be covered in the next post.
Comments