In the previous post, I described ways to indicate that two OWL entities represent the same Concept. In this post I'm going to introduce the Simple Knowledge Organization System (SKOS) vocabulary and how to define mappings between OWL entities and entities in formalisms other than OWL. The advantage of SKOS is that unlike OWL, there are more gradations than just defining two entities to be the same. SKOS can define that two entities are related to each other but not exactly the same. Or that one entity is more or less general than another.
Before discussing SKOS, I need to define some terminology. One often hears the term "taxonomy" and "ontology" and it isn't always clear what the difference is. People use "taxonomy" in at least two ways:
Any tree structured classification scheme within an ontology. E.g., a class hierarchy in OWL can be described as a taxonomy as can a hierarchy of individuals where lower level nodes in the taxonomy are sub-parts of higher level nodes.
A hierarchical system of classification that uses two or more formalisms. E.g., some links in the graph represent subclass, sub-part, and other relations.
In this post, whenever I use the term taxonomy it will mean the second definition of taxonomy: a tree diagram that may use 2 or more different semantics for a link.in the tree. For more detail on the difference between taxonomies and ontologies I recommend the following article from SciBite: SKOS in CENtree.
SKOS was designed to formalize such taxonomies. Since a link in a taxonomy can have at least two different meanings (sub-class or sub-part), SKOS doesn't provide ways to define sub-class or part-of relations. Rather it uses terms like skos:broader and skos:narrower. These are both object properties defined in OWL. For our purpose the only SKOS classes we need are Concept and Concept_Scheme. The Concept class is the domain and range for all the semantic relation properties discussed below. A Concept_Scheme is the SKOS term for an ontology or taxonomy.
The skos:broader and skos:narrower properties are embedded in a hierarchy of sub and super properties shown below. In the following diagram, I'm utilizing the labels for each SKOS property rather than their IRI names because the labels make the direction of the property clearer:
The properties are organized by the immediate sub-properties of is_in_semantic_relation_with:
has_broader_transitive
has_narrower_transitive
has_related
is_in_mapping_relation_with
Note that some of the properties have multiple super-properties. E.g., has_broader_match is a sub-property of has_broader and is_in_mapping_relation_with. Any property that ends with "match" is meant to be a mapping between entities in two different concept schemes. All of these match properties are grouped under the fourth super-property: is_in_mapping_relation_with.
The properties has_broader_transitive and has_narrower_transitive are inverses as are their sub-properties. E.g., if Foo has_broader Bar then Bar has_narrower Foo. The has_broader property holds between any two nodes where the object is higher in some concept scheme than the subject. E.g., Dog has_broader Mammal and Mammal has_broader Animal. In that example has_broader represents a super-class relation. However, another use for has_broader would be MotherBoard has_broader Computer and CPU has_broader MotherBoard. In this case the relation is a super-part relation. In manufacturing this is known as a Bill of Materials, a hierarchal structure showing a manufactured product and the various component parts it has as well as the components of the components, etc.
The fourth sub-property: is_in_mapping_relation_with, groups together all the properties that map across different concept schemes rather than within the same concept scheme. For example, defining mappings between the National Institute of Health's MeSH Taxonomy and the Bioportal Human Disease Ontology would all be done with sub-properties of is_in_mapping_relation_with. For example, both MeSH and the Disease Ontology have a class called Anatomy. However, they aren't exact matches due to the different use cases that the two models are designed for. MeSH is oriented toward indexing PubMed documents and the Disease Ontology toward providing a logically rigorous definition of Anatomy within the larger OBO framework. The appropriate SKOS property to map these two concepts would be has_close_match. This tells search engines and reasoners that the two concepts are similar, close to but not quite exact synonyms. In the SKOSExamples ontology there is a class called skos:Concept. That Concept has_exact_match with the skos:Concept defined at http://www.w3.org/TR/skos-reference/skos.rdf
The first thing that is probably apparent is to use SKOS with OWL classes you will need to use punning. The SKOS documentation is actually a bit out of date. In the section on SKOS Concepts and OWL classes it says: "to be used together with SKOS. OWL Full users will be... treating instances of SKOS concepts explicitly as classes...at the time of writing,... OWL Working Group [has] been chartered to handle... metamodeling within a description-logic framework".
OWL Full mentioned in the SKOS documentation, is an example of an OWL profile. There are various profiles for OWL that add or remove features in order to improve performance with fewer features or improve expressiveness of the language with poorer performance. The standard profile that most people use is OWL DL. Another profile that is often used is OWL RL which is a subset of OWL DL and designed to support fast rule-based inferencing by the reasoner. The OWL RL profile is often used for very large ontologies that want to support reasoning in tractable time and are willing to give up a few OWL features for better performance. OWL Full is a profile that should usually be avoided at all costs because no reasoner can support it. OWL Full means that anything goes. Recall that underneath OWL are RDF triples. In order to use the reasoner, it is necessary to restrict some of the possible RDF triples one can utilize. Specifically, one can't type an OWL Class as also being an instance of other classes such as skos:Concept. In the SKOS documentation this is the only way described to utilize OWL classes and SKOS. Doing this puts you into OWL Full.
The good news is the committee described in the SKOS documentation completed their work and added the punning feature to OWL 2. Punning allows you to create an Individual with the same name as a class. In the examples above to use SKOS with OWL you would create individuals with names such as Dog, Animal, Mammal, Computer, MotherBoard, and CPU. I.e., create an individual (a pun) with the same name as each class you want to use SKOS for. When you do this, OWL and Protégé recognize that it is a pun and when you click on the individual you will also see the class. Note that semantically a punned individual is not an instance of the class it is a pun for. E.g., the pun Animal is not an instance of Animal, it represents the class Animal not an actual Animal. When I use puns, I typically create a class called MetaClass or PunnedClass. In the future I may start to just use the skos:Concept class as the class for all punned classes and properties. Doing this enables you to assert axioms such as Dog has_broader Mammal and CPU has_broader MotherBoard.
Using SKOS concepts within an OWL ontology isn't all that useful because the has_broader properties have more rigorous definitions in OWL anyway. One use case would be if your ontology was going to be processed by a search engine that utilized SKOS properties to improve searches. However, for the most part SKOS would be used to map one concept scheme (e.g. an ontology) to another concept scheme (e.g., a taxonomy).
You might be wondering why not just make properties like has_broader annotation properties rather than object properties? Annotation properties are designed to be meta-data and meta-data needs to be defined for all OWL entities not just individuals. That's why annotation properties like skos:altLabel can be directly defined on classes without punning. I think the reason is that the designers of SKOS wanted to take advantage of the reasoning that is only available on object properties. Specifically inverses, transitive, and sub-properties. Some examples of this are:
The has_broader property has an inverse has_narrower. When you assert that Dog has_broader Mammal, the reasoner infers that Mammal has_narrower Dog.
The has_broader property is a sub-property of has_broader_transitive (which is defined to be transitive). When you assert that Dog has_broader Mammal and Mammal has_broader Animal, the reasoner infers that Dog has_broader_transitive Animal.
Another important SKOS property is has_related. In OWL this could indicate a relation between two individuals represented by some object property that connects the two. One way to use SKOS is with semantic search engines. Properties such as has_broader and has_related can tell search engines to retrieve certain entities that are related in some way to the main entity that is the best match for the search. For example, if Michael and Fido are instances of Person and Dog respectively, and Michael hasPet Fido, then Michael has_related Fido. Since has_related is a symmetric property, the reasoner will infer that Fido has_related Michael.
All of the examples used in this and the previous post are defined in a small ontology I created called SKOSExamples. This ontology has examples of using Equivalent To to indicate two OWL classes are the same using the Client = Customer example in the previous post. It also shows an example using Same Individual As for three individuals (Venus, TheMorningStar, TheEveningStar). It has various examples of punning classes and then utilizing SKOS to show broader and narrower relations between them. The ontology also provides a simple example of how the reasoner can help to automate inferences about SKOS properties. I defined a simple SWRL rule: hasComponent(?c1, ?c2) -> skos:narrower(?c1, ?c2). I.e., if some individual X hasComponent Y then X has_narrower Y. Once this ordering relation is defined, the reasoner can assert many additional properties such as skos:broader and skos:narrowerTransitive based on the various definitions of the properties (e.g., sub-properties, transitive properties, etc.).