Best Practices for Implementing FAIR Vocabularies and Ontologies on the Web

Best Practices for Implementing FAIR Vocabularies and Ontologies on the Web


With the adoption of Semantic Web technologies, an increasing number of vocabularies and ontologies have been developed in different domains, ranging from Biology to Agronomy or Geosciences. However, many of these ontologies are still difficult to find, access and understand by researchers due to a lack of documentation, URI resolving issues, versioning problems, etc. In this chapter we describe guidelines and best practices for creating accessible, understandable and reusable ontologies on the Web, using standard practices and pointing to existing tools and frameworks developed by the Semantic Web community. We illustrate our guidelines with concrete examples, in order to help researchers implement these practices in their future vocabularies.

Ontology metadata Ontology publication Ontology access FAIR principles Linked Data principles.

1 Introduction

In the last decade, a series of initiatives for open data, transparency and open science have led to the development of a myriad of datasets and linked Knowledge Graphs on the Web.1 Ontologies and vocabularies have been developed accordingly to represent the contents of these datasets and Knowledge Graphs and help in their integration and linking. However, while significant effort has been spent on making data Findable, Accessible, Interoperable and Reusable (FAIR) [18], ontologies and vocabularies are often difficult to access, understand and reuse. This may be due to several reasons, including a lack of definitions of ontology classes and properties; deprecated or unavailable imported ontologies, non-resolvable ontology URIs, lack of examples and diagrams in the documentation, or having scientific publications describing an ontology without any reference to its implementation.

The scientific community has started to acknowledge the need for ontologies to be properly documented, versioned, published and maintained following the Linked Data Principles [6] and adapting the FAIR principles for data [8]. But these recommendations do not include guidelines on how to implement them for a target vocabulary. In this chapter we address this issue by describing how to make an ontology or vocabulary comply with the FAIR principles, including examples summarizing best practices from the community and our own experience; and pointing to popular existing tools and frameworks.

Our guidelines are aimed at ontology engineers, and therefore the paper is structured according to their ontology development processes: Section 2 describes several design decisions for an ontology URI (naming conventions, versioning, permanent URIs); Section 3 describes how to create a documentation that is easy to reuse and understand by others (minimum metadata, diagrams to include); Section 4 illustrates how to make an ontology accessible and findable in the Web; Section 5 points to existing end-to-end frameworks that support the ontology publication process; and Section 6 concludes our paper. We consider the design and development of an ontology out of the scope of this paper, as it has been covered by methodologies for ontology development (e.g., LOT2 or NeOn [14]).

2 Accessible Ontology URI Design

Ontologies are digital artifacts, and therefore their URIs should follow the Linked Data Principles,3 and use a URI namespace under the developer’s control. The rationale is simple: only in a domain under our control we will be able to serve the right serialization of the ontology.

When creating an ontology, it is also important to think carefully about its name, prefix and URI design. Well engineered ontologies are costly to produce, and therefore they should be accessible to other potential users (e.g., by avoiding complex URIs) and easy to differentiate from existing vocabularies.

In this section we describe our proposed best practices for designing URIs for ontologies to make them unique, easy to remember, and easy to maintain. We acknowledge that naming conventions may be subjective, but these practices reflect our experience in ontology development over a wide range of domains (smart cities, open science, meteorology, neuroscience, etc.) and therefore provide a good starting point. We divide our guidelines over four main key points for accessible ontology URI design: how to select a name and prefix (Section 2.1), whether to use hash or slash namespaces (Section 2.2), whether to use opaque URIs (Section 2.3), how to incorporate semantic versioning in your ontology URI (Section 2.4) and how to make your ontology URI permanent (Section 2.5).

For illustrating purposes, we will be using an example ontology throughout this paper, with the following URI:

2.1 Ontology name and prefix

The name and prefix of an ontology are in most cases related to its application domain. Short and simple names will help others remember your ontology easily. An extended practice is to use acronyms to abbreviate the title of longer ontologies, as in “The Data Catalog Ontology”4 (with prefix dcat) or the “Friend of a Friend Ontology”5 (with prefix foaf).

Another aspect to consider when designing the name of your ontology is to avoid overlapping with other existing vocabularies. While it is possible to overload existing prefixes by assigning them a different URI, this often confuses potential re-users that are already familiar with the state of the art. A good strategy to prevent this problem is to look for existing prefixes in common vocabulary registries such as,6 Linked Open Vocabularies (LOV) [15] or Bioportal [17]. In our example ontology, by doing a quick search LOV and Bioportal, we can see that our example ontology URI has not been defined. However, the prefix “example” has already been registered to refer to “”, a namespace defined to create sample URIs. Therefore we decide on exo (derived from example ontology) as our namespace prefix.

2.2 Hash versus slash URIs

When designing the URI of an ontology, it is important to determine whether the trailing element will be a hash (“#”) or a slash (“/”). On the one hand, using a hash makes serving the ontology easier,7 as the client looking at the URI strips only the part of the URI before the hash symbol. Everything after the hash symbol is interpreted as a fragment identifier, and may be ignored or used by browsers to refer to the right section of the HTML documentation (if available). W3C standards usually follow the hash convention, and we will follow it in our example as well.

On the other hand, using a slash allows treating each element of the ontology as a separate entity that may be described in an independent manner. This can be useful for organizational purposes when the ontology is big (thousands of classes) and returning a full serialization or rendering a single HTML documentation may be deemed too slow, showing instead each class and property separately. The Open Biomedical Ontology network8 is an example of this convention.

2.3 Opaque URIs for classes and properties

Opaque URIs obfuscate the name of classes and properties that are part of your ontology. For instance, let us assume we have an “ExampleClassA” in our example ontology. In order to use opaque URIs, instead of using “ExampleClassA” we would associate the class with an identifier such as “EXO_C0001”, and use it as part of its URI. This has two main advantages: First, if we decide to change the name of the class in the future, the URI of the class would not be affected by it. Second, identifiers are language agnostic. For instance, someone using another alphabet (e.g., chinese, cyrillic, etc.) would be able to refer to the same URI with the corresponding label. Examples of ontologies that follow this convention can be found in the Open Biomedical Ontologies, but it is also followed by commonly used knowledge graphs such as Wikidata [16].

The main drawback of using opaque URIs is the difficulty of interpreting properly classes and properties, which usually requires additional tooling for displaying the right labels. For this reason, we will not use them in our example.

2.4 Ontology versioning

Ontologies often have multiple versions, and these should be appropriately annotated as part of the ontology metadata (e.g., with the property owl:versionIRI and owl:versionInfo).We recommend using semantic versioning9 as a guideline for identifying the different versions of an ontology, as it has become a common practice in software engineering. In semantic versioning, each version id should follow the format X.Y.Z, where X represents a major version (e.g., defining a set of classes and properties to support new use cases), Y represents a minor version (e.g., adding a single property or class), and Z represents patches or quick bug fixes (updating a label, adding examples, etc.). In our example ontology, the first version is 1.0.0 (first major release), with the IRI “”, which we would represent in the ontology as follows:


[frame=single,fontsize=] ¡¿ rdf:type owl:Ontology ; owl:versionIRI ¡¿ ; owl:versionInfo ”1.0.0”@en .

As shown in the example, the version IRI is independent from the URI of the ontology (“”). It is discouraged to include version numbers as part of the ontology URI, as it would deeply affect interoperability of its instances. For example, consider we had used “” as the ontology URI, and we had populated a Knowledge Graph with two instances of “ExampleClassA”:


[frame=single,fontsize=] @prefix exo: ¡¿ . @prefix ex-inst: ¡¿ . ex-inst:instance1 a exo:ExampleClassA . ex-inst:instance2 a exo:ExampleClassA .

If we now released another version of the ontology (1.0.1), all the URIs of ExampleClassA would change (highlighted in blue below):


{},fontsize=] @prefix exo2: ¡¿ . @prefix ex-inst: ¡¿ . ex-inst:instance1 a exo2:ExampleClassA . ex-inst:instance2 a exo2:ExampleClassA .

This is an undesired behavior, because it makes ex-inst:instance1 and ex-inst:instance2 instances of two different classes (exo:ExampleClassA and exo2:exampleClassA) instead of a single one. Instead, we want all the instances of a class to be compatible across different ontology versions:


[frame=single,fontsize=] @prefix exo: ¡¿ . @prefix ex-inst: ¡¿ . ex-inst:instance1 a exo:ExampleClassA . ex-inst:instance2 a exo:ExampleClassA .

By following this convention, we can continue doing ontology releases with appropriate versioning, while keeping the classes and properties consistent in terms of their URI.

2.5 Using permanent URIs

When publishing an ontology on the Web, it is recommended to think about its long term sustainability, specifically if it gets widely adopted. For example, what will happen to the domain used for the namespace URI of an ontology after several years? (i.e., when the funding for the related research project is over). Likewise, if the ontology is hosted on a server in a university or company, what will happen if the server name changes; or if the person in charge of maintaing it needs to move the ontology hosting to another institution?

Permanent URIs services are community driven initiatives designed to address these issues. The idea behind them is simple: instead of minting a URI for a resource, users may use these services to create a proxy URI which can then be redirected to wherever the target resource is stored at any point in time. That way, if the target resource is moved, developers just have to update its location without changing its permanent URL. There are several open, free services to create permanent URLs on the Web, among which purl.org10 (now hosted by the Internet Archive) and w3id11 (created by the W3C Permanent Identifier Community Group and supported by several companies) are perhaps the most commonly used. We recommend using permanent URIs in ontologies in order to support their long term sustainability. In fact, our example ontology uses a w3id: Creating a w3id is as simple as forking a GitHub repository and following the instructions in the readme file.12 An advantage of w3id versus is that you have control on how to redirect the ontology to its different serializations (a full example is available in Section 4).

3 Generating Reusable Ontology Documentation

We refer to “ontology documentation” as the collection of documents and explanatory comments generated during the entire ontology building process [14]. These documents are critical for helping others understand an ontology: documentation provides context, accurate definitions and examples of the different concepts that are included. In fact, an important part of the documentation is usually provided within the ontology itself through ontology metadata and natural language annotations. However, some of the documents may be external to the ontology, such as the ontology requirements document, other sources used during the knowledge acquisition phase, the conceptualization diagrams, examples of use, etc.

In this section we describe our recommended best practices to generate ontology metadata and human oriented documentation, including diagramming guidelines to show the relationships between classes in a visual manner.

3.1 Ontology Metadata

When creating an ontology, it is crucial to describe it with appropriate metadata for others to understand it correctly. For example, if some of the classes are ambiguously defined, other researchers may misinterpret their meaning when incorporating them into their work. We distinguish two main categories of metadata in an ontology: the metadata associated with the ontology itself and the metadata associated with its elements (classes, object properties, datatype properties and individuals).

The metadata associated to the ontology itself is important to provide an overview and identify an ontology, understand its usage conditions and understand its provenance. Table 1 shows our recommended and optional annotation properties for describing ontologies, along with candidate properties that can be reused from existing vocabularies and standards.13 The recommended properties are license (critical for others to know how the ontology may be used; we recommend a CC-BY license); creator, contributor, creation date and previous version to track the provenance of the ontology and compare against earlier versions; namespace URI and version IRI to properly identify the ontology; and prefix, title and description to provide a quick overview on what the ontology does and how to properly refer to it. Finally, a citation is recommended for letting other users know how to attribute the authors of the ontology. For the rest of the section, we will be using the following namespaces:14


The optional properties included in Table 1 are not critical to identify or reuse a target ontology, but provide additional insight and ease its understanding. These properties include having an abstract and see also with an additional overview of the ontology and links to related resources; a status to describe its maturity (first draft, specification, etc.); information about the backward compatibility or other incompatible versions of the ontology; the modification and issue dates; the original source that led to the definition of the ontology (requirement document, use cases, etc.); information about the publisher organization supporting the ontology; the DOI to accessed to a publication about the ontology; and information about the logo and diagrams that can be used as a visual aid for the ontology.

Property name Annotation Property Rationale Guideline
License dcterms:license Usage conditions Recommended
Creator dcterms:creator Provenance and attribution Recommended
Contributor dcterms:contributor Provenance and attribution Recommended
Creation date dcterms:created Provenance Recommended
Previous version owl:priorVersion Provenance and comparison Recommended
Namespace URI vann:preferredNamespaceUri Identifying the ontology Recommended
Version IRI owl:versionIRI Versioning Recommended
Prefix vann:preferredNamespacePrefix Identifying the ontology Recommended
Title dcterms:title Understanding Recommended
Description dcterms:description Understanding Recommended
Citation dcterms:bibliographicCitation Credit Recommended
Abstract dcterms:abstract Additional information Optional
See also rdfs:seeAlso Additional information Optional
Status sw:status Maturity information Optional
Backward compatibility owl:backwardCompatibility Version compatibility Optional
Incompatibility owl:incompatibleWith Version compatibility Optional
Modification Date dcterms:modified Provenance and timeliness Optional
Issued date dcterms:issued Provenance and timeliness Optional
Source dcterms:source Provenance Optional
Publisher dcterms:published Provenance Optional
DOI bibo:doi Bibliographic information Optional
Logo foaf:logo Identifying the ontology Optional
Diagram foaf:depiction Visual documentation Optional
Table 1: Recommended and optional metadata for describing ontologies

Table 2 shows the recommended and optional metadata properties for classes, properties, data properties and individuals. Recommended metadata properties include a human-readable label to identify the term (using as many languages as needed); and a definition for the ontology term that is as accurate as possible. Definitions should be clear and illustrative, as classes and property names may have different meanings to different researchers.

The rest of the properties in Table 2 are nice to have to improve the understanding of ontology terms. These include examples that illustrate how to use a term; its status (e.g., deprecated, under discussion, etc.); the rationale for including a term in the ontology (which may reflect consensus from a discussion); and the source material that motivated the inclusion of the term.

3.2 Creating a Human-Readable Documentation

Property name Annotation Property Rationale Guideline
Label rdfs:label Readibility Recommended
Definition rdfs:comment Understanding Recommended
Example vann:example Understanding Optional
Status sw:term_status Understanding Optional
Rationale vaem:rationale Understanding Optional
Source dcterms:source Provenance Optional
Table 2: Recommended and optional properties for describing ontology terms

Ontologies are usually designed in editors and then exported in formats (Turtle, RDF/XML, JSON-LD, etc.) that are difficult to navigate by humans. Researchers often address this issue by pointing to an associated paper or report, but these usually describe a scientific contribution rather than the definitions of each ontology concept in detail. A better solution is to create a documentation for all the terms in the ontology. Since this can be a time-consuming task, the Semantic Web community has developed tools to help ontology documentation. Given an OWL file as input, these tools generate an HTML documentation from the metadata included in the ontology itself (by retrieving the annotation properties recommended in Section 3.1), creating sections for all classes, properties, data properties and named individuals. Popular tools for ontology documentation include WIDOCO [3] (an evolution of the Live OWL Documentation Environment [12] that includes automated visualization diagrams through the WebVowl tool [9]), Parrot [2] or OwlDoc15 (integrated with the Protégé Ontology editor [11]).

We recommend creating an HTML documentation for ontologies, as it makes them easier for others to understand and navigate on the Web. The tools introduced above are a good starting point for documentation generation, but we recommend expanding their results with additional motivation and context for the target ontology, pointers to the requirements and rationale; and custom diagrams with examples that illustrate how to use ontologies in practice.

3.3 Ontology visualization

Graphical representations of ontologies help users understand their structure, relationships and usage. Since there is no standard convention for ontology diagrams, developers have adopted several approaches, such as UML-alike diagrams in the SAREF ontologies;16 semantic network oriented diagrams in the SSN Ontology;17 or custom diagrams as in the Provenance Ontology.18

In the last years, conventions for ontology diagrams have been proposed (e.g., VOWL [10] and Graffoo19) but none have been standardized yet. In this section we suggest guidelines for generating ontology diagrams based on the UML_Ont profile proposed at [4].20 The rationale for our recommendation is that UML is commonly used in software engineering, and it is familiar to software developers.

Figure 1 depicts our proposed graphical representations for classes, class restrictions and class axioms. Named classes are represented by labelled boxes (1.a); while class restrictions or anonymous classes are represented by empty boxes (1.b). Intersection class descriptions are represented either by using an empty circle with the <<owl:intersectionOf>> stereotype (1.c.i); or an icon including the symbol “” (1.c.ii). Similarly, union class descriptions may use an empty circle with the <<owl:unionOf>> stereotype (1.d.i); or an icon including the symbol “”(1.d.ii).

Figure 1: Recommended notation for classes.

Subclasses are represented using the generalization arrow used in UML (1.e.i) or with a dependency arrow with the <<rdfs:subClassOf>> stereotype (1.e.ii); and equivalent classes are represented with double-sided UML dependency arrows with the <<owl:equivalentClass>> (1.f.i) stereotype or by a circle including the symbol “” (1.f.ii). Lastly, disjoint classes may be represented with double-sided UML dependency arrows, using the <<owl:disjointWith>> stereotype (1.g.i) or with a circle including the symbol “” (1.g.ii).

Figure 2 illustrates guidelines on how to represent object properties. When the domain or range are not known (2.a), properties can be represented with dotted arrows (2.a.i); or with a diamond with the <<owl:ObjectProperty>> stereotype (2.a.ii). Subproperties may be represented with the UML dependency arrow with the <<owl:subPropertyOf>> stereotype linking the arrows that represent the involved object properties (2.b.i) or with an UML dependency unidirectional arrow with the <<owl:subPropertyOf>> stereotype linking the diamonds that represent the involved object properties (2.b.ii). When domain and range are known, properties can be represented with a solid line between source and target classes (2.c.i) or with a labelled diamond accompanied by dotted arrows labelled with <<rdfs:domain>> and <<rdfs:range>> respectively (2.c.ii). Equivalent (2.d) and inverse object properties (2.e) can be represented by using a bidirectional arrow with the <<owl:equivalentProperty>> and <<owl:inverseOf>> stereotypes between the lines (2.d.i and 2.e.i) or using diamond shapes (2.d.ii and 2.e.ii). Lastly, functional (2.f), transitive (2.g) and symmetric (2.h) object properties can be represented using a shared notation: either by adding the first initial of the property type (F, T or S) to the object property label attached to the arrow that represents the object property; or by a labelled diamond, which represents the object property itself, including the corresponding stereotype (e.g., <<owl:FunctionalProperty>>).

Figure 2: Recommended notation for object properties.

Figure 3 shows how to represent datatype properties. When the domain or range are not known (3.a) datatype properties may be represented as labelled dashed boxes attached to boxes representing classes (3.a.i); or as a diamond with <<owl:DatatypeProperty>>. Subproperties for datatypes may be represented with a UML dependency arrow with the <<owl:subPropertyOf>> stereotype linking the diamonds that represent the involved datatype properties (3.b). When the domain and/or range are known, the box representing the datatype property may be depicted with a solid line indicating that the domain of the datatype property is the attached class and the range may be included following the characters “::” after the datatype label (3.c.i). Alternatively, a labelled diamond may be used accompanied by dotted arrows labelled with the <<rdfs:domain>> and <<rdfs:range>> stereotypes respectively (3.c.ii). Equivalent datatype properties may be represented by a UML dependency bidirectional arrow with the <<owl:EquivalentProperty>> stereotype linking the diamonds that represent the datatype properties (3.d). Functional datatype properties may be represented by adding “(F)” to the datatype property label (3.e.i) or by a labelled diamond including the <<owl:FunctionalProperty>> stereotype (3.e.ii).

Figure 3: Recommended notation for datatype properties.

Finally, Figure 4 proposes how to represent individuals and class membership. Individuals or instances may be represented by labelled boxes with underlined names or identifiers (4.a). Class membership may be represented with labelled boxes containing the individual name followed by the character “:” and the class name, all underlined (4.b.i); by a linking the individual box with the class using a unidirectional UML dependency arrow with the stereotype <<rdf:type>> (4.b.ii) or with a underlined labelled box for the individual attached to the class.

Figure 4: Recommended notation for individuals.

4 Ontology Publication on the Web

Once an ontology is fully implemented and documented, it is time to make it accessible and findable in the Web. In this section we briefly describe the best practices to perform content negotiation to serve a target ontology in multiple formats (Section 4.1) and registries for describing new ontologies (Section 4.2).

4.1 Ontology Accessibility in Multiple Interoperable Formats

Ontologies should be made available in both human and machine readable manner using a single identifier: the ontology URI. This way we can make any ontology resolve to its HTML documentation when accessed by a user in a browser; and resolve to a standard RDF serialization when importing it in an ontology editor. In order to distinguish the target resource to serve (HTML or RDF serialization), we must implement a 303 See Other redirect,21 a common practice in the Semantic Web community for doing content negotiaiton over URIs. This type of redirect indicates the location of a target resource in the server based on the received request, but has to be appropriately configured on the server where we are hosting the ontology. Fortunately, there are W3C best practices (recipes) on how to configure an Apache HTTP server -a commonly used type of server for serving files- for hash ended and slash ended ontologies.22 Here we expand these practices with our example ontology to illustrate: 1) How to support multiple serializations of an ontology (HTML and Turtle); 2) how to support version redirection, as we would like all the versions of the ontology to be appropriately available, not only the latest; 3) How to specify if a serialization is not supported (for example, requests for JSON-LD will return a 406 non-acceptable code, rather than an RDF/XML serialization); and 4) how to implement a default response in case the user agent doing the request does not specify a target in the request (by default we return Turtle). The htaccess file to be placed in the server (in an “/example” folder) would look as follows:


[frame=single, fontsize=] # Turn off MultiViews (Apache-specific command) Options -MultiViews

# Directive to specify supported types besides html and xml # Standard RDF serialization formats include Turtle, RDF/XML, N-Triples and JSON-LD AddType text/turtle .ttl RewriteEngine on

# Rewrite rule for accessing the latest version. RewriteCond RewriteCond RewriteCond RewriteCond RewriteRule ^\([R=303,L]\par #% RewriteruletoservetheTurtleserializationfromthevocabularyURI(latestversion)RewriteCondRewriteCondRewriteCondRewriteRule\) [R=303,L]

# Rewrite rules for retrieving a particular version. RewriteCond RewriteCond RewriteCond RewriteCond RewriteRule(.+)\(\)1/index-en.html [R=303,L]

# Rewrite rule to serve Turtle serialization of a particular version RewriteCond RewriteCond RewriteCond RewriteRule(.+)\(\)1/ontology.ttl [R=303,L]

# Rewrite rule for other non accepted formats RewriteCond RewriteRule(.*)\([R=406,L]\par #RewriteruletoservetheTurtlecontentfromthevocabularyURIbydefaultRewriteRule\) [R=303,L]

In order to test the redirection, the easiest way is just to paste the URI of the ontology in Protégé or in your browser and check that both load the right serialization. Another possibility is to use a curl command,23 e.g., to retrieve the Turtle serialization:

curl -sH "Accept: text/turtle" -L

If interested in a particular version, we can use its version IRI. For example, for the documentation of version 1.0.0:

curl -sH "Accept: text/html" -L

4.2 Making an Ontology Findable on the Web

Once an ontology is published in the Web, the next step is to ensure it can be easily found by others. There are three main activities that can help the visibility of an ontology:

  1. Register the namespace prefix:,24 is a crowdsourced registry where users can vote the most popular URL for a given prefix.

  2. Register the ontology: There are a number of existing metadata registries that can be used for browsing existing ontologies [15][17]. Our recommendation is to look first for domain-specific registries (e.g., Bioportal [17] in the biomedical domain, Agroportal [7] in Agronomy, etc.) commonly used by the target community of interest. When domain-specific registries do not exist, we suggest registering the ontology in a domain-generic metadata registry, such as Linked Open Vocabularies [15] (which has a manual curation process to ensure that minimum metadata is provided) or FAIRsharing.25

  3. In-document annotations to help crawlers understand the metadata of the ontology when publishing it on the Web. For instance, annotations can be added in your HTML documentation through JSON-LD snippets:26


[frame=single, fontsize=] ¡!– Annotations for the example ontology –¿ ¡script type=”application/ld+json”¿ ”@context”:””, ”@type”:”WebPage”, ”url”:””, ”name”:”The example ontology”, ”datePublished”:”4-2-2020”, ”version”:”1.0.1”, ”license”:””, ”author”:[”@type”:”Person”,”name”:”Daniel Garijo”, ”@type”:”Person”,”name”:”Maria Poveda”], ¡/script¿

5 Ontology Documentation and Publication Frameworks

Semantic Web researchers and practitioners have developed methods and tools for easing ontology engineering, development, publication and exploitation. A number these tools have already been mentioned in the corresponding sections of this chapter, however, they are not always integrated as part of an end-to-end framework, and researchers have to use them separately.

More recently, frameworks inspired in the software continuous integration practices have arisen to support ontology engineering activities in collaborative environments. These frameworks offer end-to-end solutions that support ontology engineers documenting, visualizing, testing and publishing their ontologies; and we recommend them as an entry point to adopt some of the practices described in this chapter. One example is OnToology [1], a web application27 that orchestrates ontology documentation, evaluation and publication on the Web with permanent URLs. Another similar approach is VoCol [5], which provides ontology developers with feedback on syntax and other errors and gives access to a human-readable presentation of a target ontology. Finally, PoolParty [13] is a commercial solution that also includes publication of thesauri, taxonomies and ontology management among other features.

6 Conclusions

In this chapter we have described implementation guidelines and recommendations for making ontologies findable (through metadata registries and annotations); accessible (through good practices in URI design and content negotiation), interoperable (showing how to serve ontologies in different standard serializations) and reusable (by describing the metadata and diagram guidelines needed for proper understanding) on the Web while following the Linked Data principles. A distinct feature of our guidelines is that we have illustrated how to carry out our recommendations with an example ontology and pointers to usable tools developed by the Semantic Web community in the last decade. Our recommendations reflect years of experience on ontology engineering and also summarize community discussions for ontology design and publication. Hence, we believe these guidelines are a comprehensive starting point for ontology developers who aim to make their ontologies FAIR and available on the Web.


  13. Other vocabularies (e.g., are alternatives to the ones proposed. See for additional suggestions.
  14. For reference, the TTL version of our example ontology is available at
  16. See the SAREF4AGRI extension
  17. Semantic Sensor Network Ontology
  18. PROV-O: The PROV Ontology
  19. Specification available at
  20. The original UML_Ont profile uses custom labels and dependencies to cover OWL 1 constructs. Here labels are mapped to the OWL and RDF(S) constructs.


  1. A. Alobaid, D. Garijo, M. Poveda-Villalón, I. Santana-Perez, A. Fernández-Izquierdo and O. Corcho (2018) Automating ontology engineering support activities with OnToology. Journal of Web Semantics. Cited by: §5.
  2. C. T. Alonso, D. Berrueta, L. Polo and S. Fernández (2012) Current practices and perspectives for metadata on web ontologies and rules. International Journal of Metadata, Semantics and Ontologies 7 (2), pp. 93 (en). External Links: ISSN 1744-2621, 1744-263X Cited by: §3.2.
  3. D. Garijo (2017) WIDOCO: A Wizard for Documenting Ontologies. In The Semantic Web – ISWC 2017, Vol. 10588, pp. 94–102. Cited by: §3.2.
  4. P. Haase, S. Brockmans, R. Palma, J. Euzenat and M. d’Aquin (2009) D1.1.2 updated version of the networked ontology model. Technical report Universität Karlsruhe. Note: NeOn Project. http://www. neon-project. org Cited by: §3.3.
  5. L. Halilaj, N. Petersen, I. Grangel-González, C. Lange, S. Auer, G. Coskun and S. Lohmann (2016) VoCol: an integrated environment to support version-controlled vocabulary development. In 20th International Conference on Knowledge Engineering and Knowledge Management - EKAW 2016, Bologna, Italy, Lecture Notes in Computer Science, Vol. 10024, pp. 303–319. Cited by: §5.
  6. K. Janowicz, P. Hitzler, B. Adams, D. Kolas and C. Vardeman II (2014) Five stars of Linked Data vocabulary use. Semantic Web 5 (3), pp. 173–176. External Links: ISSN 15700844 Cited by: §1.
  7. C. Jonquet, A. Toulet, E. Arnaud, S. Aubin, E. D. Yeumo, V. Emonet, J. Graybeal, M. Laporte, M. A. Musen, V. Pesce and P. Larmande (2018) AgroPortal: a vocabulary and ontology repository for agronomy. Computers and Electronics in Agriculture 144, pp. 126 – 143. External Links: ISSN 0168-1699 Cited by: item 2.
  8. Y. Le Franc, J. Parland-von Essen, L. Bonino, H. Lehväslaiho, G. Coen and C. Staiger (2020-03) D2.2 fair semantics: first recommendations. FAIRsFAIR. External Links: Link Cited by: §1.
  9. S. Lohmann, V. Link, E. Marbach and S. Negru (2015) WebVOWL: web-based visualization of ontologies. In Proceedings of EKAW 2014 Satellite Events, LNAI, Vol. 8982, pp. 154–158. Cited by: §3.2.
  10. S. Lohmann, S. Negru, F. Haag and T. Ertl (2014) VOWL 2: user-oriented visualization of ontologies. In Proceedings of the 19th International Conference on Knowledge Engineering and Knowledge Management (EKAW ’14), LNAI, Vol. 8876, pp. 266–281. Cited by: §3.3.
  11. M. A. Musen (2015-06) The Protégé project: a look back and a look forward. AI Matters 1 (4), pp. 4–12 (en). External Links: ISSN 23723483 Cited by: §3.2.
  12. S. Peroni, D. Shotton and F. Vitali (2012) The Live OWL Documentation Environment: A Tool for the Automatic Generation of Ontology Documentation. In Knowledge Engineering and Knowledge Management, Vol. 7603, pp. 398–412. External Links: ISBN 978-3-642-33875-5 978-3-642-33876-2 Cited by: §3.2.
  13. T. Schandl and A. Blumauer (2010) PoolParty: skos thesaurus management utilizing linked data. In Extended Semantic Web Conference, pp. 421–425. Cited by: §5.
  14. M. C. Suárez-Figueroa (2010) NeOn Methodology for building ontology networks: specification, scheduling and reuse. Ph.D. Thesis, Facultad de Informatica, Universidad Politécnica de Madrid. Cited by: §1, §3.
  15. P. Vandenbussche, G. A. Atemezing, M. Poveda-Villalón and B. Vatant (2017-01) Linked Open Vocabularies (LOV): A gateway to reusable semantic vocabularies on the Web. Semantic Web 8 (3), pp. 437–452. External Links: ISSN 22104968, 15700844 Cited by: §2.1, item 2.
  16. D. Vrandečić and M. Krötzsch (2014-09) Wikidata: a free collaborative knowledgebase. Communications of the ACM 57 (10), pp. 78–85 (en). External Links: ISSN 00010782 Cited by: §2.3.
  17. P. L. Whetzel, N. F. Noy, N. H. Shah, P. R. Alexander, C. Nyulas, T. Tudorache and M. A. Musen (2011-07) BioPortal: enhanced functionality via new Web services from the National Center for Biomedical Ontology to access and use ontologies in software applications. Nucleic Acids Research 39 (suppl), pp. W541–W545 (en). External Links: ISSN 0305-1048, 1362-4962 Cited by: §2.1, item 2.
  18. M. D. Wilkinson, M. Dumontier, I. J. Aalbersberg, G. Appleton, M. Axton, A. Baak, N. Blomberg and (2016-03) The FAIR Guiding Principles for scientific data management and stewardship. Scientific Data 3, pp. 160018. External Links: ISSN 2052-4463 Cited by: §1.
Comments 0
Request Comment
You are adding the first comment!
How to quickly get a good reply:
  • Give credit where it’s due by listing out the positive aspects of a paper before getting into which changes should be made.
  • Be specific in your critique, and provide supporting evidence with appropriate references to substantiate general statements.
  • Your comment should inspire ideas to flow and help the author improves the paper.

The better we are at sharing our knowledge with each other, the faster we move forward.
The feedback must be of minimum 40 characters and the title a minimum of 5 characters
Add comment
Loading ...
This is a comment super asjknd jkasnjk adsnkj
The feedback must be of minumum 40 characters
The feedback must be of minumum 40 characters

You are asking your first question!
How to quickly get a good answer:
  • Keep your question short and to the point
  • Check for grammar or spelling errors.
  • Phrase it like a question
Test description