How to (properly) publish a vocabulary or ontology in the web (part 6 of 6)

And we finally arrive to the last part of the tutorial, which is a set of guidelines on how to reuse other vocabularies (i.e., how your vocabulary should link to other vocabularies). Reuse is not only related to publication, but also to the design of your own vocabulary. As a researcher, everyone knows that it is better not to reinvent the wheel. If an existent vocabulary covers with its terms part of what you want to cover in your competency questions (or system requirements), why should you redefine the same terms again and again?

In order to avoid this issue, you can either import that vocabulary into yours, which will bring the whole imported vocabulary as part of your ontology (like a module), or you could either extend only those properties and classes that you are going to reuse, without adding all the terms of the reused vocabulary as part of your ontology.

Which way is better? It depends: on one hand, I personally like to extend the vocabularies that I reuse when the terms being expanded are not many. Importing a vocabulary often makes it more difficult to present, and for someone loading the ontology, it could be very confusing to browse across many terms not being used in my domain.

Reusing concepts from other ontologies simplifies your domain model, as you import just those being extended.

On the other hand, if you plan to reuse most of the vocabulary being imported, for example by creating a profile of a vocabulary for a specific domain, the import option is the way to go.

Importing an ontology makes it on one hand easy to reuse, but on the other (in some cases) it makes your ontology more difficult to understand.

Another advice is to be careful with the semantics. I personally don’t like to mess up with the concepts defined by other people. If you need to add your own properties taking as domain or ranges classes defined by other people, you should specialize those classes in your ontology. Imagine an example where I want to reuse the generic concept from the PROV ontology prov:Entity for refering to the provenance of digital entities (which is my sample domain). If I want to add a property that has domain digital entity (like hasSize), then I should specialize the term prov:Entity with a subclass for my domain (in this case digitalEntity subClassOf Entity). If I just assert properties on the general term (prov:Entity) then I may be overextending my property to other domains than those I may have thought, and what is worse: I may be modifying a model which I haven’t defined originally.

But where to start looking if you want to reuse a vocabulary? There are several options:

• Linked Open Vocabularies (LOV ): A set of common vocabularies that are distributed and organized in different categories. Different metrics for each vocabulary are displayed regarding its metadata and reuse, which will help you to determine whether it is still in unse or not.
• The W3C standards: When building a vocabulary it is allways good to look up if a standard on that domain already exists!
• Swoogle and Watson will allow you to search for terms on your domain and suggest you existent approaches.

With this post the tutorial ends. I hope it served to clarify at least a couple of things regarding vocabulary/ontology publication in the web. If you have any questions please leave them on the comments and I’ll be happy to help you.

Do you want more information regarding ontology importing and reuse? Check out these papers (thanks Maria and Melanie for the pointers):

• The Landscape of Ontology Reuse in Linked Data: Analysis of 196 ontologies belonging to LOV and how they are related to each other.
• MIREOT: the Minimum Information to Reference an External Ontology Term : A short guideline on reusing and importing ontologies in the biomedical domain (OBO, OBI).
• Ontofox: a tool for extracting all the knowledge of single concepts of ontologies.

This is part of a tutorial divided in 7 parts:

1. Overview of the tutorial.
2. (Reqs addressed A1(partially), A2, A3, A4, P1) Publishing your vocabulary at a stable URI using RDFS/OWL.
3. (Reqs addressed P2, P3). How to design a human readable documentation.
4. Extra: A tool for creating html readable documentation
5. (Reqs addressed P4). Derreferencing your vocabulary
6. (Reqs addressed A1 (partially)). Dealing with the license
7. (Reqs addressed A5, P5). Reusing other vocabularies. (This post)

• Linked Data