Skip to content

Data Model

Jump to bottom Edit New page
Joachim Neubert edited this page Oct 11, 2019 · 26 revisions

This page documents the RDF constructs, including but not limited to SKOS, that Skosmos supports. In general, Skosmos should work with any well-formed SKOS Core vocabularies. Skosmos is not limited to SKOS Core: there is support for many Dublin Core properties, some extensions from ISO 25964 and also support for custom classes and properties.

It is recommended use Skosify to pre-process your SKOS vocabulary and fix potential problems before publishing it in Skosmos.

Concepts

All instances of skos:Concept are displayed as concepts in Skosmos. Each concept will have its own page and concepts can be searched for (via their labels).

Labels

Skosmos supports the following label properties:

  • skos:prefLabel is used as preferred label, usually set in bold
  • skos:altLabel: can be found in search, usually set in italic
  • skos:hiddenLabel: can be found in search, but not displayed

Make sure that you have proper language tags for all labels.

Semantic relationships

  • skos:broader and skos:narrower are used for e.g. the hierarchy display
  • skos:related is displayed as links between concepts

Mapping relationships

Skosmos recognizes all SKOS mapping relationships and will show them in a separate section on the concept page.

  • skos:exactMatch
  • skos:closeMatch
  • skos:broadMatch
  • skos:narrowMatch
  • skos:relatedMatch
  • owl:sameAs
  • rdfs:seeAlso

The target of the mapping relationship is typically an external URI, i.e. it is a concept from outside the current vocabulary. For display purposes, Skosmos will attempt to find a label for the concept from the following sources:

  1. If the target URI matches the URI namespace of a configured vocabulary, look up the label in that vocabulary. This works well when you have several interlinked vocabularies in the same instance of Skosmos.
  2. Perform a HTTP request on the external URI, asking for RDF data (Linked Data). The response is cached using APC user cache, if the APC PHP module is enabled. This can sometimes be slow; external HTTP requests can be disabled using the skosmos:loadExternalResources setting (see Vocabularies).
  3. If the above methods fail to produce label, just display the URI itself without a label.

Documentary notes

  • skos:note
  • skos:scopeNote
  • skos:definition
  • skos:example
  • skos:historyNote
  • skos:editorialNote
  • skos:changeNote

Dublin Core properties

Both the old DC 1.1 (namespace prefix dc11) and the newer DC Terms (prefix dc) namespaces are supported.

  • dc:title and dc11:title
  • dc:subject
  • dc:description and dc11:description
  • dc:creator and dc11:creator
  • dc:contributor and dc11:contributor
  • dc:rights and dc11:rights
  • dc:license and dc11:license
  • dc:publisher and dc11:publisher
  • dc:source and dc11:source
  • dc:date
  • dc:created
  • dc:issued
  • dc:modified
  • dc:relation and dc11:relation
  • dc:replaces
  • dc:isReplacedBy

Notations

Notations (skos:notation) are displayed as part of the headline on concept pages and in search result lists. By definition "a notation, also known as classification code, is a string of characters such as "T58.5" or "303.4833" used to uniquely identify a concept within the scope of a given concept scheme". By convention, "(skos:notation) is used with a typed literal in the object position of the triple".

Other properties

  • rdfs:label
  • rdfs:comment
  • owl:versionInfo
  • foaf:homepage
  • skosext:partOf

Additional custom properties

Furthermore, Skosmos can display arbitrary properties, if the endpoint (graph) provides an rdfs:label for the property.

Types of concepts

You can define custom types of concepts, i.e. subclasses of skos:Concept, in your RDF data. The type will be displayed by Skosmos and you can also restrict searches by type.

Make sure to also set a label for each type. Also make sure that instances of those subclasses are also typed as skos:Concept, as Skosmos by itself will not perform any inference (Skosify with the --infer option can be used for this).

Example:

ex:Place a owl:Class ;
  rdfs:subClassOf skos:Concept ;
  rdfs:label "Place"@en .

ex:new_york a ex:Place, skos:Concept ;
  skos:prefLabel "New York"@en .

ex:paris a ex:Place, skos:Concept ;
  skos:prefLabel "Paris"@en .

Deprecated concepts

Deprecated concepts are concepts that are no longer valid but are kept in the vocabulary for backward compatibility. Skosmos can detect that a concept has been deprecated if the concept data includes:

  • owl:deprecated true metadata
  • optionally, dcterms:isReplacedBy relationships pointing to the concepts (one or multiple) that replace this one

Example:

ex:old a skos:Concept ;
  owl:deprecated true ;
  skos:prefLabel "Old concept that has been replaced by a new concept"@en ;
  dct:isReplacedBy ex:new .

Deprecated concepts will not be visible in the alphabetical listing, in the hierarchical view, and cannot be found with the search, unless the option skosmos:showDeprecated is set to true in the vocabularies configuration file. However, deprecated concepts can still be accessed through their URI in both the web user interface and the API.

The concept page of a deprecated concept includes a notification element that informs the user that the concept has been deprecated, and if possible links to the concept that should be used instead (The following link illustrates how Skosmos visualizes deprecated concepts: http://finto.fi/yso/en/page/p3410).

Concept schemes

Basic metadata (Dublin Core and other properties) for concept schemes are shown in a similar way as for concepts.

In addition, skos:hasTopConcept and skos:topConceptOf relationships are used to list the top level concepts in the hierarchy, if the configuration setting skosmos:showTopConcepts is enabled. See Vocabularies for details. Make sure to define both skos:hasTopConcept and skos:topConceptOf (Skosify will do this automatically).

If your vocabulary contains multiple skos:ConceptScheme instances, you should set the skosmos:mainConceptScheme option to choose the most important one to show on the vocabulary home page.

Collections, Arrays and Groups

Collections, arrays and groups enable grouping multiple concepts under a common label, which can be useful when a group of concepts shares something in common. The web user interface has an optional sidebar view that enables browsing these groups included in a vocabulary.

For groups Skosmos supports the properties skos:Collection and isothes:ConceptGroup. The appropriate type should be configured per vocabulary using the skosmos:groupClass option of the vocabularies.ttl file. See the vocabularies wikipage for more detailed instructions on how to enable the group view for your vocabulary.

Example

ex:animals a skos:Collection ;
  skos:prefLabel "Animals"@en ;
  skos:member ex:cat, ex:dog .

ex:cat a skos:Concept ;
  skos:prefLabel "Cat"@en .

ex:dog a skos:Concept ;
  skos:prefLabel "Dog"@en .
Add a custom footer
Clone this wiki locally