Skip to main content Link Search Menu Expand Document (external link)

SKOS Support

Support for SKOS vocabularies in OntoPortal OntoPortal serves as a web-based portal designed for the access and exchange of . The platform is capable of receiving submissions in OWL and OBO formats, as well as SKOS vocabularies containing specific constructs. This guide outlines the essential set of SKOS constructs required in a vocabulary for proper acceptance and handling within OntoPortal. It is important to emphasise that the described SKOS constructs are specifically processed for vocabularies identified as SKOS during their submission to OntoPortal.

Required SKOS constructs skos:Concept. Concepts are the fundamental elements of SKOS vocabularies and are asserted using the skos:Concept class, e.g.: http://www.example.com/animals rdf:type skos:Concept In SKOS vocabularies, OntoPortal only treats the SKOS concept assertions as concepts to be displayed. If the vocabulary contains other assertions about other types of concepts, OntoPortal will not treat these as concepts in any of its displays or features. See the W3C’s SKOS System Primer and SKOS Reference for concept documentation and examples.

Note: Some OWL ontologies declare the SKOS namespace to facilitate minimal use of SKOS constructs for things like labels (e.g., skos:prefLabel, skos:altLabel) or mappings (e.g., skos:exactMatch, skos:broaderMatch). In these cases, the proper format for new ontology submissions is OWL, not SKOS. skos:ConceptScheme and skos:hasTopConcept. For every ontology entry in OntoPortal, the application provides a tabbed interface with various views of the ontology data, e.g., a “Classes” tab with a tree structure to graphically depict the hierarchical collection of ontology classes. In the case of SKOS vocabularies, OntoPortal determines which concepts to display as roots in the concept tree by querying vocabulary content for occurrences of skos:hasTopConcept property assertions. Top concepts are the most general concepts contained in SKOS concept schemes (an aggregation of one or more SKOS concepts). The following example, taken from the SKOS System Primer, shows how to define a concept scheme and link it to the most general concepts it contains:

@prefix skos: <http://www.w3.org/2004/02/skos/core#> 
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> 
@prefix ex: <http://www.example.com/>

ex:animalThesaurus rdf:type skos:ConceptScheme
skos:hasTopConcept ex:mammals
skos:hasTopConcept ex:fish

SKOS vocabularies submitted to OntoPortal must contain a minimum of one concept scheme and top concept assertion. See the SKOS System Primer and SKOS Reference for more documentation of concept schemes and top concepts. If your vocabulary declares more than one concept scheme, all of the top concepts will be aggregated and displayed as root level concepts. The OntoPortal user interface offers functionality to group these top-level concepts based on their respective concept schemes, accessible through the implemented filters.

Hierarchy in SKOS vocabularies

The only semantic relationship in SKOS vocabularies that OntoPortal uses to construct and display concept hierarchies is the skos:broader property.

ex:mammals rdf:type skos:Concept;
skos:inScheme :myScheme;
skos:narrower ex:cat;
skos:prefLabel "mammals"@en;
skos:broader ex:animals.

Other properties used to denote hierarchical relationships like skos:narrower, skos:broaderTransitive, and skos:narrowerTranstive, are ignored.

Metrics data for SKOS vocabularies OntoPortal employs the OWL API to parse all ontology and vocabulary submissions, including the computation of metric data. The OWL API interprets SKOS vocabularies as RDF files that encompass classes and instances. Following the SKOS Reference, concepts are identified as instances of owl:Class, consequently, they are counted as instances, also referred to as “individuals.” When examining metric tables within the OntoPortal user interface, the “Number Of Individuals” value aligns with the count of concepts within a given SKOS vocabulary. Example of valid SKOS This example provides a simple illustration of the composition of a SKOS file that complies with the above constraints.

  • Example header. The provided header establishes several common namespaces that could prove valuable. The final namespace is the one responsible for defining the specific SKOS vocabulary in question. Ideally, the IRI associated with the “myskosid” namespace should be a resolvable location pointing to the SKOS ontology.
     <xml version="1.0" encoding="UTF-8"?>
     <rdf:RDF
       xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
       xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
       xmlns:skos="http://www.w3.org/2004/02/skos/core#"
       xmlns:dct="http://purl.org/dc/terms/"
       xmlns:myskosid="https://example.org/ontologies/myskosontology/" >
    
  • Example ontology description. In the rdf:type item, this namespace is declared as the ConceptScheme. It’s important to note that the ConceptScheme doesn’t necessarily have to match the ontology’s namespace. Additional metadata examples are given as good practices in ontology metadata. While dct:creator doesn’t necessarily need to be an ORCID ID, having a unique identifier is recommended for identifying the creator, whether an individual or organisation. This ontology comprises only two concepts (to be defined later), resulting in only two skos:hasTopConcept declarations.
      <rdf:Description rdf:about="https://example.org/ontologies/myskosontology/">
      <rdfs:label xml:lang="en">Example SKOS ontology for OntoPortal</rdfs:label>
      <rdf:type rdf:resource="http://www.w3.org/2004/02/skos/core#ConceptScheme"/>
      <rdfs:comment xml:lang="en">Example created to simplify understanding and creation of a SKOS  vocab for OntoPortal</rdfs:comment>
      <dct:created rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2024-02-02</dct:created>
      <dct:modified rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2024-02-02</dct:modified>
      <dct:license rdf:resource="https://creativecommons.org/licenses/by/4.0/"/>
      <dct:creator rdf:resource="https://orcid.org/0000-0001-6875-5360"/>
      <skos:hasTopConcept df:resource="https://example.org/ontologies/myskosontology/fragmentid001"/>
      <skos:hasTopConcept rdf:resource="https://example.org/ontologies/myskosontology/fragmentid002"/>
      </rdf:Description>
    
  • Example term definitions. This section shows the two concepts and a few typical annotations about those concepts. The first rdf:Description line of each group names the concept that is being defined in the indented lines that follows. The rdf:Type and skos:prefLabel are required annotation content for OntoPortal to work effectively. Other items are optional. The skos:topConceptOf is not strictly required for OntoPortal SKOS ontologies, but provides useful contextualization if there is more than one topConcept.
      <rdf:Description rdf:about="https://example.org/ontologies/myskosontology/fragmentid001"">
      <rdf:type rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/>
      <skos:prefLabel xml:lang="en">First concept</skos:prefLabel>
      <skos:definition xml:lang="en">The very first example provided as part of this ontology.</skos:definition>
      <skos:topConceptOf rdf:resource="https://example.org/ontologies/myskosontology/"/>
      </rdf:Description>
      <rdf:Description rdf:about="https://example.org/ontologies/myskosontology/fragmentid002"">
      <rdf:type rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/>
      <skos:prefLabel xml:lang="en">Second concept</skos:prefLabel>
      <skos:definition xml:lang="en">The very first example provided as part of this ontology.</skos:definition>
      <skos:topConceptOf rdf:resource="https://example.org/ontologies/myskosontology/"/>
      </rdf:Description>
    
  • Closing XML. Needed for a complete, parseable RDF file! </rdf:RDF>