Best Practices for Implementing FAIR Vocabularies and Ontologies on the Web
aa r X i v : . [ c s . D L ] M a r Best Practices for Implementing FAIRVocabularies and Ontologies on the Web
Daniel Garijo r ´ ´ ´ s andMar´ıa Poveda-Villal´on r ´ ´ ´ s Information Sciences Institute, University of Southern California [email protected] Ontology Engineering Group, Universidad Polit´ecnica de Madrid [email protected]
Abstract.
With the adoption of Semantic Web technologies, an increas-ing number of vocabularies and ontologies have been developed in differ-ent domains, ranging from Biology to Agronomy or Geosciences. How-ever, many of these ontologies are still difficult to find, access and un-derstand by researchers due to a lack of documentation, URI resolvingissues, versioning problems, etc. In this chapter we describe guidelinesand best practices for creating accessible, understandable and reusableontologies on the Web, using standard practices and pointing to exist-ing tools and frameworks developed by the Semantic Web community.We illustrate our guidelines with concrete examples, in order to helpresearchers implement these practices in their future vocabularies.
Keywords:
Ontology metadata · Ontology publication · Ontology ac-cess · FAIR principles · Linked Data principles.
In the last decade, a series of initiatives for open data, transparency and openscience have led to the development of a myriad of datasets and linked Knowl-edge Graphs on the Web. Ontologies and vocabularies have been developedaccordingly to represent the contents of these datasets and Knowledge Graphsand help in their integration and linking. However, while significant effort hasbeen spent on making data Findable, Accessible, Interoperable and Reusable(FAIR) [18], ontologies and vocabularies are often difficult to access, understandand reuse. This may be due to several reasons, including a lack of definitionsof ontology classes and properties; deprecated or unavailable imported ontolo-gies, non-resolvable ontology URIs, lack of examples and diagrams in the docu-mentation, or having scientific publications describing an ontology without anyreference to its implementation.The scientific community has started to acknowledge the need for ontologiesto be properly documented, versioned, published and maintained following the https://lod-cloud.net/ Garijo and Poveda-Villal´on
Linked Data Principles [6] and adapting the FAIR principles for data [8]. Butthese recommendations do not include guidelines on how to implement them for atarget vocabulary. In this chapter we address this issue by describing how to makean ontology or vocabulary comply with the FAIR principles, including examplessummarizing best practices from the community and our own experience; andpointing to popular existing tools and frameworks.Our guidelines are aimed at ontology engineers, and therefore the paper isstructured according to their ontology development processes: Section 2 describesseveral design decisions for an ontology URI (naming conventions, versioning,permanent URIs); Section 3 describes how to create a documentation that is easyto 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 ontologypublication process; and Section 6 concludes our paper. We consider the designand development of an ontology out of the scope of this paper, as it has beencovered by methodologies for ontology development (e.g., LOT or NeOn [14]). Ontologies are digital artifacts, and therefore their URIs should follow the LinkedData Principles, and use a URI namespace under the developer’s control. Therationale is simple: only in a domain under our control we will be able to servethe right serialization of the ontology.When creating an ontology, it is also important to think carefully about itsname, prefix and URI design. Well engineered ontologies are costly to produce,and therefore they should be accessible to other potential users (e.g., by avoidingcomplex URIs) and easy to differentiate from existing vocabularies.In this section we describe our proposed best practices for designing URIs forontologies to make them unique, easy to remember, and easy to maintain. Weacknowledge that naming conventions may be subjective, but these practicesreflect our experience in ontology development over a wide range of domains(smart cities, open science, meteorology, neuroscience, etc.) and therefore providea good starting point. We divide our guidelines over four main key points foraccessible 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 opaqueURIs (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 throughoutthis paper, with the following URI: https://w3id.org/example . The name and prefix of an ontology are in most cases related to its applicationdomain.
Short and simple names will help others remember your ontology https://lot.linkeddata.es/ est Practices for FAIR Vocabularies 3 easily. An extended practice is to use acronyms to abbreviate the title oflonger ontologies, as in “The Data Catalog Ontology” (with prefix dcat ) or the“Friend of a Friend Ontology” (with prefix foaf ).Another aspect to consider when designing the name of your ontology isto avoid overlapping with other existing vocabularies. While it is possible tooverload existing prefixes by assigning them a different URI, this often confusespotential re-users that are already familiar with the state of the art. A goodstrategy to prevent this problem is to look for existing prefixes in common vo-cabulary registries such as prefix.cc, Linked Open Vocabularies (LOV) [15] orBioportal [17]. In our example ontology, by doing a quick search LOV and Bio-portal, we can see that our example ontology URI has not been defined. However,the prefix “example” has already been registered to refer to “example.org”, anamespace defined to create sample URIs. Therefore we decide on exo (derivedfrom example ontology ) as our namespace prefix.
When designing the URI of an ontology, it is important to determine whetherthe trailing element will be a hash ( as the client looking at the URI stripsonly the part of the URI before the hash symbol. Everything after the hashsymbol is interpreted as a fragment identifier , and may be ignored or used bybrowsers 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 ourexample as well.On the other hand, using a slash allows treating each element of the ontologyas a separate entity that may be described in an independent manner. This can beuseful for organizational purposes when the ontology is big (thousands of classes)and returning a full serialization or rendering a single HTML documentationmay be deemed too slow, showing instead each class and property separately.The Open Biomedical Ontology network is an example of this convention. Opaque URIs obfuscate the name of classes and properties that are part of yourontology. For instance, let us assume we have an “ExampleClassA” in our exam-ple ontology. In order to use opaque URIs, instead of using “ExampleClassA” wewould associate the class with an identifier such as “EXO C0001”, and use it aspart of its URI. This has two main advantages: First, if we decide to change thename of the class in the future, the URI of the class would not be affected by it. http://xmlns.com/foaf/spec/ http://prefix.cc Garijo and Poveda-Villal´on
Second, identifiers are language agnostic. For instance, someone using anotheralphabet (e.g., chinese, cyrillic, etc.) would be able to refer to the same URI withthe corresponding label. Examples of ontologies that follow this convention canbe found in the Open Biomedical Ontologies, but it is also followed by commonlyused knowledge graphs such as Wikidata [16].The main drawback of using opaque URIs is the difficulty of interpretingproperly classes and properties, which usually requires additional tooling fordisplaying the right labels. For this reason, we will not use them in our example.
Ontologies often have multiple versions, and these should be appropriately anno-tated as part of the ontology metadata (e.g., with the property owl:versionIRI and owl:versionInfo ).We recommend using semantic versioning as a guide-line for identifying the different versions of an ontology, as it has become acommon practice in software engineering. In semantic versioning, each versionid 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 repre-sents a minor version (e.g., adding a single property or class), and Z representspatches or quick bug fixes (updating a label, adding examples, etc.). In ourexample ontology, the first version is (first major release), with the IRI“ https://w3id.org/example/1.0.0 ”, which we would represent in the ontol-ogy as follows: If we now released another version of the ontology (1.0.1), all the URIs ofExampleClassA would change (highlighted in blue below): @prefix exo2: By following this convention, we can continue doing ontology releases withappropriate versioning, while keeping the classes and properties consistent interms of their URI. When publishing an ontology on the Web, it is recommended to think aboutits 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 afterseveral 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, whatwill happen if the server name changes; or if the person in charge of maintaingit needs to move the ontology hosting to another institution?Permanent URIs services are community driven initiatives designed to ad-dress these issues. The idea behind them is simple: instead of minting a URI fora resource, users may use these services to create a proxy URI which can then beredirected to wherever the target resource is stored at any point in time. Thatway, if the target resource is moved, developers just have to update its locationwithout changing its permanent URL. There are several open, free services tocreate permanent URLs on the Web, among which purl.org (now hosted bythe Internet Archive) and w3id (created by the W3C Permanent IdentifierCommunity Group and supported by several companies) are perhaps the mostcommonly used. We recommend using permanent URIs in ontologies in order tosupport their long term sustainability. In fact, our example ontology uses a w3id: https://w3id.org/example . Creating a w3id is as simple as forking a GitHubrepository and following the instructions in the readme file. An advantage ofw3id versus purl.org is that you have control on how to redirect the ontology toits different serializations (a full example is available in Section 4). We refer to “ontology documentation” as the collection of documents and ex-planatory comments generated during the entire ontology building process [14]. https://archive.org/services/purl/ https://w3id.org/ https://github.com/perma-id/w3id.org Garijo and Poveda-Villal´on These documents are critical for helping others understand an ontology: docu-mentation provides context, accurate definitions and examples of the differentconcepts that are included. In fact, an important part of the documentationis usually provided within the ontology itself through ontology metadata andnatural language annotations. However, some of the documents may be exter-nal to the ontology, such as the ontology requirements document, other sourcesused during the knowledge acquisition phase, the conceptualization diagrams,examples of use, etc.In this section we describe our recommended best practices to generate on-tology metadata and human oriented documentation, including diagrammingguidelines to show the relationships between classes in a visual manner. When creating an ontology, it is crucial to describe it with appropriate meta-data for others to understand it correctly. For example, if some of the classesare ambiguously defined, other researchers may misinterpret their meaning whenincorporating them into their work. We distinguish two main categories of meta-data in an ontology: the metadata associated with the ontology itself and themetadata associated with its elements (classes, object properties, datatype prop-erties and individuals).The metadata associated to the ontology itself is important to provide anoverview and identify an ontology, understand its usage conditions and under-stand its provenance. Table 1 shows our recommended and optional annotationproperties for describing ontologies, along with candidate properties that can bereused from existing vocabularies and standards. The recommended propertiesare license (critical for others to know how the ontology may be used; we recom-mend 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 andhow to properly refer to it. Finally, a citation is recommended for letting otherusers know how to attribute the authors of the ontology. For the rest of thesection, we will be using the following namespaces: Other vocabularies (e.g., https://schema.org ) are alternatives to the ones pro-posed. See https://w3id.org/widoco/bestPractices for additional suggestions. For reference, the TTL version of our example ontology is available at https://dgarijo.github.io/example/release/1.0.1/ontology.ttl est Practices for FAIR Vocabularies 7 Table 1. Recommended and optional metadata for describing ontologies Property name Annotation Property Rationale Guideline License dcterms:license Usage conditions RecommendedCreator dcterms:creator Provenance and attribution RecommendedContributor dcterms:contributor Provenance and attribution RecommendedCreation date dcterms:created Provenance RecommendedPrevious version owl:priorVersion Provenance and comparison RecommendedNamespace URI vann:preferredNamespaceUri Identifying the ontology RecommendedVersion IRI owl:versionIRI Versioning RecommendedPrefix vann:preferredNamespacePrefix Identifying the ontology RecommendedTitle dcterms:title Understanding RecommendedDescription dcterms:description Understanding RecommendedCitation dcterms:bibliographicCitation Credit RecommendedAbstract dcterms:abstract Additional information OptionalSee also rdfs:seeAlso Additional information OptionalStatus sw:status Maturity information OptionalBackward compatibility owl:backwardCompatibility Version compatibility OptionalIncompatibility owl:incompatibleWith Version compatibility OptionalModification Date dcterms:modified Provenance and timeliness OptionalIssued date dcterms:issued Provenance and timeliness OptionalSource dcterms:source Provenance OptionalPublisher dcterms:published Provenance OptionalDOI bibo:doi Bibliographic information OptionalLogo foaf:logo Identifying the ontology OptionalDiagram foaf:depiction Visual documentation Optional The optional properties included in Table 1 are not critical to identify orreuse a target ontology, but provide additional insight and ease its understand-ing. These properties include having an abstract and see also with an additionaloverview of the ontology and links to related resources; a status to describe itsmaturity (first draft, specification, etc.); information about the backward compat-ibility or other incompatible versions of the ontology; the modification and issue dates; the original source that led to the definition of the ontology (requirementdocument, use cases, etc.); information about the publisher organization sup-porting 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 aidfor the ontology.Table 2 shows the recommended and optional metadata properties for classes,properties, data properties and individuals. Recommended metadata propertiesinclude a human-readable label to identify the term (using as many languages asneeded); and a definition for the ontology term that is as accurate as possible.Definitions should be clear and illustrative, as classes and property names mayhave different meanings to different researchers.The rest of the properties in Table 2 are nice to have to improve the under-standing of ontology terms. These include examples that illustrate how to usea term; its status (e.g., deprecated, under discussion, etc.); the rationale for in-cluding a term in the ontology (which may reflect consensus from a discussion);and the source material that motivated the inclusion of the term. Garijo and Poveda-Villal´on Table 2. Recommended and optional properties for describing ontology terms Property name Annotation Property Rationale Guideline Label rdfs:label Readibility RecommendedDefinition rdfs:comment Understanding RecommendedExample vann:example Understanding OptionalStatus sw:term status Understanding OptionalRationale vaem:rationale Understanding OptionalSource dcterms:source Provenance Optional Ontologies are usually designed in editors and then exported in formats (Tur-tle, RDF/XML, JSON-LD, etc.) that are difficult to navigate by humans. Re-searchers often address this issue by pointing to an associated paper or report,but these usually describe a scientific contribution rather than the definitions ofeach ontology concept in detail. A better solution is to create a documentationfor all the terms in the ontology. Since this can be a time-consuming task, theSemantic Web community has developed tools to help ontology documentation.Given an OWL file as input, these tools generate an HTML documentation fromthe metadata included in the ontology itself (by retrieving the annotation prop-erties recommended in Section 3.1), creating sections for all classes, properties,data properties and named individuals. Popular tools for ontology documen-tation include WIDOCO [3] (an evolution of the Live OWL DocumentationEnvironment [12] that includes automated visualization diagrams through theWebVowl tool [9]), Parrot [2] or OwlDoc (integrated with the Prot´eg´e Ontologyeditor [11]).We recommend creating an HTML documentation for ontologies, as it makesthem easier for others to understand and navigate on the Web. The tools intro-duced above are a good starting point for documentation generation, but werecommend expanding their results with additional motivation and context forthe target ontology, pointers to the requirements and rationale; and custom di-agrams with examples that illustrate how to use ontologies in practice. Graphical representations of ontologies help users understand their structure,relationships and usage. Since there is no standard convention for ontology dia-grams, developers have adopted several approaches, such as UML-alike diagramsin the SAREF ontologies; semantic network oriented diagrams in the SSN On-tology; or custom diagrams as in the Provenance Ontology. https://protegewiki.stanford.edu/wiki/OWLDoc See the SAREF4AGRI extension https://w3id.org/def/saref4agri Semantic Sensor Network Ontology PROV-O: The PROV Ontology est Practices for FAIR Vocabularies 9 Class11.a) Named class Class1Class2 Class1Class2 < Class1 Class21.c) Intersection of classesClass1 Class2 < Class1 Class2 1.b) Class restrictions or anonymous class Class1 Class2 Class1 Class2 < Fig. 1. Recommended notation for classes. In the last years, conventions for ontology diagrams have been proposed (e.g.,VOWL [10] and Graffoo ) but none have been standardized yet. In this sectionwe suggest guidelines for generating ontology diagrams based on the UML Ontprofile proposed at [4]. The rationale for our recommendation is that UML iscommonly used in software engineering, and it is familiar to software developers.Figure 1 depicts our proposed graphical representations for classes, class re-strictions and class axioms. Named classes are represented by labelled boxes(1.a); while class restrictions or anonymous classes are represented byempty boxes (1.b). Intersection class descriptions are represented either byusing an empty circle with the < Equivalent (2.d) and inverse object properties (2.e) can be rep-resented by using a bidirectional arrow with the < Equiv-alent datatype properties may be represented by a UML dependency bidi-rectional arrow with the < Functional datatypeproperties may be represented by adding “(F)” to the datatype property label(3.e.i) or by a labelled diamond including the < Individuals or instances may be represented by labelled boxes with underlinednames or identifiers (4.a). Class membership may be represented with labelled est Practices for FAIR Vocabularies 11 objectProperty1< Class1 Class2 < Fig. 2. Recommended notation for object properties. boxes containing the individual name followed by the character “:” and the classname, all underlined (4.b.i); by a linking the individual box with the class us-ing a unidirectional UML dependency arrow with the stereotype < Once an ontology is fully implemented and documented, it is time to make itaccessible and findable in the Web. In this section we briefly describe the best < Class1 datatypeProperty1 (F): xsd:datatype 3.e.i 3.e.ii < Class1 datatypeProperty1 :: xsd:datatype 3.c.i3.c.iidatatypeProperty1 Class1 3.e) Functional datatype property Fig. 3. Recommended notation for datatype properties. Individual14.a) Individual Individual1:Class1 Class1Individual1 Fig. 4. Recommended notation for individuals. practices to perform content negotiation to serve a target ontology in multipleformats (Section 4.1) and registries for describing new ontologies (Section 4.2). Ontologies should be made available in both human and machine readable man-ner using a single identifier: the ontology URI. This way we can make any ontol-ogy 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 ontologyeditor. In order to distinguish the target resource to serve (HTML or RDF se-rialization), we must implement a 303 See Other redirect , a common practicein the Semantic Web community for doing content negotiaiton over URIs. This https://tools.ietf.org/html/rfc7231 est Practices for FAIR Vocabularies 13 type of redirect indicates the location of a target resource in the server basedon the received request, but has to be appropriately configured on the serverwhere we are hosting the ontology. Fortunately, there are W3C best practices(recipes) on how to configure an Apache HTTP server -a commonly used typeof server for serving files- for hash ended and slash ended ontologies. Herewe expand these practices with our example ontology to illustrate: 1) How tosupport multiple serializations of an ontology (HTML and Turtle); 2) how tosupport version redirection, as we would like all the versions of the ontologyto be appropriately available, not only the latest; 3) How to specify if a serial-ization is not supported (for example, requests for JSON-LD will return a 406non-acceptable code, rather than an RDF/XML serialization); and 4) how toimplement a default response in case the user agent doing the request does notspecify a target in the request (by default we return Turtle). The htaccess fileto be placed in the server (in an “/example” folder) would look as follows: In order to test the redirection, the easiest way is just to paste the URI ofthe ontology in Prot´eg´e or in your browser and check that both load the right serialization. Another possibility is to use a curl command, e.g., to retrieve theTurtle serialization: curl -sH "Accept: text/turtle" -L https://w3id.org/example If interested in a particular version, we can use its version IRI. For example, forthe documentation of version 1.0.0: curl -sH "Accept: text/html" -L https://w3id.org/example/1.0.0 Once an ontology is published in the Web, the next step is to ensure it can beeasily found by others. There are three main activities that can help the visibilityof an ontology:1. Register the namespace prefix : prefix.cc, is a crowdsourced registrywhere users can vote the most popular URL for a given prefix.2. Register the ontology : There are a number of existing metadata registriesthat can be used for browsing existing ontologies [15][17]. Our recommenda-tion is to look first for domain-specific registries (e.g., Bioportal [17] in thebiomedical domain, Agroportal [7] in Agronomy, etc.) commonly used by thetarget 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 processto ensure that minimum metadata is provided) or FAIRsharing. In-document annotations to help crawlers understand the metadata ofthe ontology when publishing it on the Web. For instance, annotations canbe added in your HTML documentation through JSON-LD snippets: https://curl.haxx.se/ http://prefix.cc https://fairsharing.org/standards/ est Practices for FAIR Vocabularies 15 Semantic Web researchers and practitioners have developed methods and toolsfor easing ontology engineering, development, publication and exploitation. Anumber these tools have already been mentioned in the corresponding sectionsof this chapter, however, they are not always integrated as part of an end-to-endframework, and researchers have to use them separately.More recently, frameworks inspired in the software continuous integrationpractices have arisen to support ontology engineering activities in collaborativeenvironments. These frameworks offer end-to-end solutions that support ontol-ogy engineers documenting, visualizing, testing and publishing their ontologies;and we recommend them as an entry point to adopt some of the practices de-scribed in this chapter. One example is OnToology [1], a web application thatorchestrates ontology documentation, evaluation and publication on the Webwith permanent URLs. Another similar approach is VoCol [5], which providesontology developers with feedback on syntax and other errors and gives accessto a human-readable presentation of a target ontology. Finally, PoolParty [13]is a commercial solution that also includes publication of thesauri, taxonomiesand ontology management among other features. In this chapter we have described implementation guidelines and recommen-dations for making ontologies findable (through metadata registries and anno-tations); accessible (through good practices in URI design and content nego-tiation), interoperable (showing how to serve ontologies in different standardserializations) and reusable (by describing the metadata and diagram guidelinesneeded for proper understanding) on the Web while following the Linked Dataprinciples. A distinct feature of our guidelines is that we have illustrated howto carry out our recommendations with an example ontology and pointers tousable tools developed by the Semantic Web community in the last decade. Ourrecommendations reflect years of experience on ontology engineering and alsosummarize community discussions for ontology design and publication. Hence,we believe these guidelines are a comprehensive starting point for ontology de-velopers who aim to make their ontologies FAIR and available on the Web. References 1. Alobaid, A., Garijo, D., Poveda-Villal´on, M., Santana-Perez, I., Fern´andez-Izquierdo, A., Corcho, O.: Automating ontology engineering support activities withOnToology. Journal of Web Semantics (2018)2. Alonso, C.T., Berrueta, D., Polo, L., Fernndez, S.: Current practices and perspec-tives for metadata on web ontologies and rules. International Journal of Metadata,Semantics and Ontologies (2), 93 (2012) http://ontoology.linkeddata.es/ (3), 173–176 (2014)7. Jonquet, C., Toulet, A., Arnaud, E., Aubin, S., Yeumo, E.D., Emonet, V., Gray-beal, J., Laporte, M.A., Musen, M.A., Pesce, V., Larmande, P.: Agroportal: Avocabulary and ontology repository for agronomy. Computers and Electronics inAgriculture , 126 – 143 (2018)8. Le Franc, Y., Parland-von Essen, J., Bonino, L., Lehvslaiho, H., Coen,G., Staiger, C.: D2.2 fair semantics: First recommendations (Mar 2020), https://doi.org/10.5281/zenodo.3707985 9. Lohmann, S., Link, V., Marbach, E., Negru, S.: WebVOWL: Web-based visualiza-tion of ontologies. In: Proceedings of EKAW 2014 Satellite Events. LNAI, vol. 8982,pp. 154–158. Springer (2015)10. Lohmann, S., Negru, S., Haag, F., Ertl, T.: VOWL 2: User-oriented visualizationof ontologies. In: Proceedings of the 19th International Conference on KnowledgeEngineering and Knowledge Management (EKAW ’14). LNAI, vol. 8876, pp. 266–281. Springer (2014)11. Musen, M.A.: The Prot´eg´e project: a look back and a look forward. AI Matters (4), 4–12 (Jun 2015)12. Peroni, S., Shotton, D., Vitali, F.: The Live OWL Documentation Environment:A Tool for the Automatic Generation of Ontology Documentation. In: KnowledgeEngineering and Knowledge Management, vol. 7603, pp. 398–412. Springer BerlinHeidelberg, Berlin, Heidelberg (2012)13. Schandl, T., Blumauer, A.: Poolparty: Skos thesaurus management utilizing linkeddata. In: Extended Semantic Web Conference. pp. 421–425. Springer (2010)14. Surez-Figueroa, M.C.: NeOn Methodology for building ontology networks: specifi-cation, scheduling and reuse. Ph.D. thesis, Facultad de Informatica, UniversidadPolitcnica de Madrid (2010)15. Vandenbussche, P.Y., Atemezing, G.A., Poveda-Villaln, M., Vatant, B.: LinkedOpen Vocabularies (LOV): A gateway to reusable semantic vocabularies on theWeb. Semantic Web (3), 437–452 (Jan 2017)16. Vrandei, D., Krtzsch, M.: Wikidata: a free collaborative knowledgebase. Commu-nications of the ACM (10), 78–85 (Sep 2014)17. Whetzel, P.L., Noy, N.F., Shah, N.H., Alexander, P.R., Nyulas, C., Tudorache, T.,Musen, M.A.: BioPortal: enhanced functionality via new Web services from theNational Center for Biomedical Ontology to access and use ontologies in softwareapplications. Nucleic Acids Research (suppl), W541–W545 (Jul 2011)18. Wilkinson, M.D., Dumontier, M., Aalbersberg, I.J., Appleton, G., Axton, M.,Baak, A., Blomberg, N., et.al.: The FAIR Guiding Principles for scientific datamanagement and stewardship. Scientific Data3