We introduce the tool suite SKOS-Utils for the development and quality assessment of SKOS vocabularies (Simple Knowledge Organisation System). SKOS is a wide-spread standard for organizing hierarchical knowledge structures, that uses RDF as basic data model. SKOS-Utils provides converters for spreadsheets and mindmaps in order to facilitate the bottom-up development of SKOS vocabularies. A suite of quality checks is used for testing the created vocabularies.
BSCHm skos:hasTopConcept
Bike skos:narrower skos:broader skos:narrower skos:broader skos:Concept
Frame skos:prefLabel “Frame”@en, “Rahmen”@de skos:hiddenLabel “FR_owe_jb” Wheel
skosxl:prefLabel
skosxl:prefLabel
skosxl:literalForm
are expanded so that concepts can point to first class instances of lexical entities [
Concepts are grouped in a skos:ConceptScheme by using the skos:inScheme property. The entry into a concept scheme is represented by using the property skos:hasTopConcept, which points to the topmost concepts of this scheme. See the ConceptScheme instance BSCHm in Figure 1. Please note, that there is no constraint, that only one top concept must exist.
When not directly maintained in a SKOS data model but in a proprietary system, the data is often converted to SKOS representation for interchange in the IT landscape. For instance, master data located originally in an ERP system is exported as SKOS data for the interchange with a knowledge graph application. But also for the creation of new structures the SKOS standard has shown to be beneficial. Here, the concepts of the structure are defined in standard applications like mindmapping tools or even spreadsheet editors. After the initial creation phase, these structures are later transferred to a graph database or ERP system. With these use cases we experienced, that SKOS data is often defined without tools checking for validity or general quality.
This paper introduces the modular open-source tool suite SKOS-Utils. The suite provides a collection of Python scripts that help during the development of SKOS vocabularies and the continuous quality assessment of the resulting knowledge graphs.
There exist various applications tailored to the development of SKOS vocabularies. While these tools ofer a wide range of functionalities and benefits for professional authors, the tools lack intuitivity needed for the first steps of developing a new vocabulary, especially for domain specialists not familiar with the engineering of ontologies. We experienced the use of already known tools more accessible for domain specialists, e.g., using spreadsheet editors and mindmapping tools. That way, we claim that it is more productive to start with such simple applications for the initial structure before switching to tailored tools for supporting the life cycle of the created vocabulary.
Quality Assessment As a primary document besides the W3C standards, Baker et al. [
Development Busse [
The suite SKOS-Utils ofers a collection of scripts for developing and checking SKOS data. Due to the intrinsic nature of incompleteness1, the suite is designed to be easily extended. We distinguish the parts development and checking, whereas each part ofers a variety of (extensible) modules for the specific task.
An extensive discussion of methods for checking vocabularies can be found in [
The development part provides the standardized SKOS RDF data model as recommended by the
W3C [
SKOS2GRAPHVIZ
SXKLOSS22SXKLOSS
SKOS2ASCII XSMKiOnSd22SXKMOinSd
… … Mindmaps In Figure 3 we see an example XMind structure of an exemplary bike definition. Basically, mindmaps allow for the definition of nodes and their hierarchical relationship (general parent-children). This relation is mapped to the skos:broader and skos:narrower properties, respectively. Further common relations in SKOS are represented by using the ’note’ attribute of nodes. When one wants to define preferred labels ( skos:prefLabel) or alternative labels (skos:altLabel), these are written into the note. By convention, the user defines those properties in separate lines, where each line needs to start with a @ character. All lines not starting with a @ are handled as standard comments and are transferred into a skos:note property. In the example in Figure 3 we see the note window for the node Rear brakes.
When we apply the script XMind2SKOS of SKOS-Utils a SKOS representation in RDF is generated. The following RDF in Listing 1 is an excerpt for the node Rear brakes (here in turtle syntax). Please note, that unique URIs are generated for each concept since we cannot rely on the unique names in the mindmap. The inverse script SKOS2Xmind converts RDF data to an XMind data format.
Listing 1: Sample output of a SKOS concept. ex : C_5b3154 a skos : Concept ; skos : prefLabel " Hinterradbremse " @de ,
" Rear brake " @en ; skos : broader ex : C_02b4cc ; skos : inScheme ex : Functions ; skos : note " @order : 10" , " @uuid : C_5b3154 ", " @xmind_name : \" Rear brakes \"" , " The correct function of a rear brake is important for save driving !" ; rdfs : label " Brake " @en ; skos : altLabel " Rear wheel brake " @en .
Graphviz SKOS-Utils provides a converter to the dot format of Graphviz. By default, the converter prints the SKOS concepts as nodes. The node label is defined by the preferred label of a specified language. Furthermore, the class type and the preferred labels can be printed in the node. Also, you can define which properties should be drawn in the graph, additionally. Graphviz provides diferent layout strategies and output formats, such as PDF, PNG, and SVG. Figure 4 depicts the example vocabulary rendered by Graphviz.
Spreadsheets The bridge modules SKOS2XLS and XLS2SKOS of SKOS-Utils transfer SKOS RDF to and from MS-Excel spreadsheets. In the spreadsheet representation, each SKOS concept is located in a separate row, whereas the SKOS properties are represented by the respective columns. Additional properties denoted by @ are exported as single columns. In Figure 5, a MS-Excel sheet is depicted, which was generated from the RDF file and the XMind structure in Figure 3, respectively. The hierarchy is represented in level notation, i.e., column Level denotes the hierarchical position of the SKOS concept. A concept with a level describes the child of a concept − 1 when the parent − 1 occurs immediately before concept . For example, Figure 5 shows the levels in Column A, where concepts Frame and Wheel are children of Bike. This kind of hierarchy level definition is common for exports/imports into ERP systems such as SAP.
Functions (en) skos:ConceptScheme
Bike (en) skos:Concept
skos:hasTopConcept skos:narrower skos:narrower
For the quality assessment a suite of configurable checks is executed as a pipeline. The results
for each check are collected and reported after finishing the entire pipeline. We provide two
alternative interfaces for the implementation of checks, i.e., as SPARQL queries [
Check Definition The current state of SKOS-Utils brings a number of checks, that are usable for the quality assessment of SKOS data. The extension of the suite is under development.
We provide two interfaces to implement project specific checks: 1) New checks basically defined by a SPARQL query are implemented by extending the python class StructureTestInterfaceSPARQL. 2) Checks navigating the graph object structure are implemented by extending the python class StructureTestInterfaceNavigate.
Listing 2 shows an example of the SPARQL approach and implements the check SinglePrefLabelCheckerSPARQL. It looks for deficient SKOS concepts that have more than one preferred label for the same language. For the sake of simplicity we omitted the query for retrieving SKOS-XL prefLabel occurrences, that is also part of the actual implementation.
Listing 2: Check definition SinglePrefLabelChecker implemented as SPARQL query. class SinglePrefLabelCheckerSPARQL ( StructureTestInterfaceSPARQL ): """ Check whether every concept has at most one prefLabel for each language . Considers prefLabels defined in standard SKOS . """ @property def status ( self ):
return " Error " def message ( self , result_df ):
... @property def query ( self ): return """
SELECT DISTINCT ? concept WHERE { { ? concept skos : prefLabel ? label1 , ? label2 . }
FILTER ( lang (? label1 ) = lang (? label2 ) &&
? label1 != ? label2 ) } GROUP BY ? concept """ A check is basically defined by overwriting three methods: The method status signifies the escalation level in the case of a found deficiency. The levels info, warning, and error are possible. The method message defines the information given to the user in case of found deficiencies. The actual logic for finding deficiencies is specified in the method query. Here, a SPARQL query for finding the wanted deficiencies needs to be given. In the standard case, the check does not report an error/warning, when the query returns no results. All results returned by the query, in turn, are interpreted as deficiencies.
Listing 3 shows the same method as native implementation. Native implementations navigate over the graph data model and try to find the deficiencies programmatically. By interfacing the class StructureTestInterfaceNavigate we usually only need to implement the method find_concepts() with the logic for finding the corresponding deficient concepts. Listing 3: Check definition SinglePrefLabelChecker implemented by navigating the graph object model. class SinglePrefLabelChecker ( StructureTestInterfaceNavigate ): @property def status ( self ):
... def message ( self , result ):
... def find_concepts ( self , graph ): bad_concepts_list = [] for concept , p , o in graph . triples (( None , RDF . type , SKOS .
Concept )): labels = self . all_pref_labels ( concept , graph ) if self . duplicate_labels ( labels ):
bad_concepts_list . append ( concept ) return bad_concepts_list Implementation note: Checks defined by SPARQL queries come with the advantage of easy definition. Additionally, SPARQL is a well-accepted W3C standard that is widely used. That way, SPARQL allows for a quick and declarative addition of new checks. However, the disadvantage of that approach is that the execution performance of SPARQL queries is significantly worse than an implementation working directly on the graph object model.
Pipeline Definition The quality assessment of SKOS data is performed by defining a pipeline of quality checks. A configuration file defines the pipeline in YAML syntax. The pipeline execution script SKOSQualityChecker performs the actual assessment of the SKOS data using this configuration file. Listing 4 shows an exemplary configuration for the quality assessment:
Listing 4: Sample definition of a check pipeline configuration. input : tests / Testdata / testfile . rdf output : test_results add_datetime_to_output : True write_results_to_excel : True tests : - LooseConceptIdentifier - SchemeCoherenceChecker - SinglePrefLabelChecker - ...
The YAML configuration describes the SKOS RDF file under analysis ( input), the name of the results file ( output). In the section (tests) the actual pipeline of tests is defined. Further, we can toggle whether we want to write a result output and whether we want to log the date/times of the tests.
That way, quality assessments are easily executable the headless way, for example, as part of a nightly continuous integration step. The results of an assessment step can be persisted into an Excel file for subsequent analysis.
SKOS-Utils is implemented as a Python script collection. For the access to RDF vocabularies we use the popular library rdflib 5. For the access to Excel files we use the pandas framework 6.
In the following we report the experiences we made during the use of the development scripts in an industrial project. We further demonstrate the implementation of the quality assessment part by reporting the runtime and findings for a collection of known SKOS vocabularies.
In the context of a customer project we started the development of a functional structure of machines in 2022. The functional structure was created on the green field initialized by a number of workshops with domain specialists from diferent areas, e.g., engineering, safety, and after sales.
Due to the collaborative set-up of the workshop the use of a mindmapping improved the intuitive creation and change of the structure. We used the bridge to the spreadsheet application for subsequent and iterative analyses by the domain specialists in their own areas. These analyses mainly covered the alignment of existing structures to the newly developed structure. Here, a spreadsheet efectively helped the alignment process. The development of the functional structure is still in progress.
Data Sets We selected a collection of popular SKOS vocabularies in order to demonstrate
the performance and usability of the developed SKOS-Utils. The DemoBike vocabulary is a
selfcreated SKOS structure describing an exemplary bicycle configuration. Here, example defects are
included to test the functionality of the SKOS-Utils implementation. The EuroVoc7 vocabulary
is a multi-lingual thesaurus created and managed by the European Union publications ofice
and describes terms in languages of EU countries and EU-candidate countries. The AGROVOC
vocabulary is developed and coordinated by the Food and Agriculture Organization (FAO) of
the United Nations [
Results We used the introduced data sets with the check implementations of SKOS-Utils. The aim of this experiments was to measure the application runtime and the general functionality of the implementation. For the experiments we used a Macbook Pro M1 Max with 32GB RAM (Python 3.11). Table 2 shows runtime numbers performing the particular checks. For each check the runtime of the navigate implementation is shown and the corresponding SPARQL 5rdflib: https://rdflib.readthedocs.io 6pandas: https://pandas.pydata.org 7EuroVoc: https://op.europa.eu/s/yTkE 8AGROVOC: https://www.fao.org/agrovoc/ 9UNESCO THES: http://vocabularies.unesco.org/thesaurus implementation, when available ("-" otherwise). The runtime numbers in Table 2 are formatted as sec:ms, whereas sec is omitted, when the check only had a milliseconds runtime. After the runtimes the count of found anomalies is given.
We see that accessing the SKOS graph by using SPARQL is significantly larger than accessing the graph via the navigation features of the library. This observation is also made for other programming libraries and therefore not surprising.
When looking at the findings in the table, the BikeDemo vocabulary shows findings for all checks. This ist not surprising, since the knowledge base is used as test for all checks, The vocabulary AGROVOC has a high number of incomplete language coverage: The vocabulary defines in total 58 languages but mostly uses for the single concepts only about 20 languages. For the UNESCO thesaurus 35 concepts with incomplete language coverage are detected, e.g., not all concepts define preferred labels for Russian language.
We introduced the tool suite SKOS-Utils as a collection of useful Python scripts for the development and quality assessment of SKOS vocabularies. SKOS became one industrial standard for creating and interchanging knowledge organization structures. Due to the heterogenous infrastructures of existing IT landscapes in industries, a flexible and open tool suite is necessary to interweave SKOS vocabularies into existing applications.
The described SKOS-Utils is at the beginning of its implementation. While the available scripts have proven to be useful in daily development and testing of knowledge bases, there are limitations so far that are tasks for future work. For the development part, only the most important SKOS properties are converted between the applications and RDF. For the quality assessment we need to develop more checks to be included in the suite. Also, there is a strong limitation in the reasoning support of SKOS-Utils. The underlying Python library rdflib does not support reasoning of RDF ontologies. For example, instances of SKOS concepts need to be defined explicitly ( ex:A rdf:type skos:Concept) and not as instances of sub-classes of SKOS concepts. This also holds for other SKOS properties and classes. That way, it is required that instances under investigation need to be explicitly defined as SKOS elements. In the future, we are planning to include reasoning support for SKOS-Utils to remove this requirement.
Parts of this work were funded by German Federal Ministry for Economic Afairs and Climate Action under the ZIM program, AiF grant KK5394901GR1 (ISCO project).
SKOS-Utils is still under development and we invite collaborators to join the development team. The sources are available via GitHub: https://github.com/denkbares/SKOS-Utils