In this section, we provide a step-by-step example of converting a SKOS file to an OWL or RDF-S ontology using SKOS2OWL.

To start the tool, click on SKOS2OWL Online Tool in the navigation row above.

Step 1: Select the SKOS source file

You can either upload a local file or point SKOS2OWL to a file that is available on the Web. Note that we kindly ask for your permission to store and analyze your uploaded files in order to improve SKOS2OWL continuously.

Figure 1: Selecting the SKOS source file

Step 2: Loading and parsing

As a next step, SKOS2OWL loads and parses your file and shows some statistics.

Figure 2: SKOS2OWL shows some statistics.

Step 3: User Input

Now, the user has to select a Base URI for the ontology to be generated. By default, SKOS2OWL suggests one in its own namespace. However, since we cannot host your ontology, you should rather use a URI in your own domain space. This decision can be changed later by simply editing the ontology file.

Then, an appropriate label and description (comment) of the target ontology must be specified. These will be included in the ontology header.

As a last step, you can specify your name and e-mail address. Both will also be included in the ontology header.

Figure 3: User Input

Step 4: Modeling Choices

In the next step, you have to make certain important modeling choices. First, you have to decide whether you want to create an ontology in either OWL or RDF-S. This mainly affects whether the ontology classes will be RDF-S classes or OWL classes. If you want to use an OWL DL reasoner, OWL is the better choice.

Second, you have to describe the context of the original hierarchy - what does it mean to be an object in a category in all of the contexts of usage of the original hierarchy. If unsure, you can use the default text.

Now it is getting tricky: You have to describe the intended Master Concept.

Usually, you should have a clear understanding of what it means to be an instance of the classes in the resulting ontologies. For example, when reusing a classification of electronic equipment, you may want to derive either an ontology of actual pieces of electronic equipment or, alternatively, an ontology of media resources related to different types of electronic equipment. The Master Concept specifies the parent class of all derived ontology classes.

Examples for master concepts:

• Media Resource: Everything that is a media resource
• Product: Everything that is an actual product
• Employee: A staff member

The master concept chosen is used for narrowing down the meaning of the input labels. For example, the label "TV Set" from an input categorization schema, may be narrowed down to

• TV Set [Media Resource]: A Media resource related to TV sets
• TV Set [Product]: An actual TV set
• TV Set [Employee]: A staff member with expertise in TV sets

For more details on Master Concepts, see also the GenTax section on this Web site.

Figure 4: Choosing the Master Concept and other modeling aspects.

Step 5: Diagnosis

In this step, we check whether the conversion as configured will produce a consistent ontology.
For that, we check for three potential causes of problems.

Figure 5: Check for proper modeling.

Local labels

Often, the intended meaning of a concept in a SKOS vocabulary is not what the pure label stands for, but instead what this label means as a child node of its superordinate nodes.

Example: The concept "2006" in a hierarchy of concepts of the form
Pictures <--- Italy <--- 2006
may mean all pictures that were taken in Italy in 2006, instead of everything that can be subsumed under the label "2006".

A simple cure to this problem is to add the labels of all superior concepts to the name of the concepts, e.g.
Pictures <--- Pictures.Italy <--- Pictures.Italy.2006

The default is no.

If you are not sure whether this hold for your SKOS vocabulary, you can use the respective online check for this property.

Is the original hierarchy a valid subsumption hierarchy in the context of the original usage?

Before we can reuse the original hierarchy in SKOS as a subsumption hierarchy of the generated ontology, we must make sure that this hierarchy is actually equivalent to rdfs:subClassOf, since the "broader than / narrower than" relationship in SKOS vocabularies is often used for less precise semantic relationships between concepts.

Example: In a SKOS concept hierarchy, "ice cubes" may be a child node to "beverages", because it is somehow related to beverages. If we interprete the concepts in a broad sense of "anything than can in any reasonable context be classified under this label", it holds that an instance of "ice cubes" is also an instance of "beverage".
If unsure, you can assume that this is the case.

The default is yes.

If you are not sure whether this hold for your SKOS vocabulary, you can use the respective online check for this property.

Is the original hierarchy also a valid subsumption hierarchy in the target context?

In some lucky cases, we can also reuse the original hierarchy in SKOS as a subsumption hierarchy between the more specific concepts in the target context. In particular for SKOS vocabularies that follow good conceptual modeling practices, this may hold. However, usually we cannot safely assume that the original "narrower than/broader than" relationships are also always valid rdfs:subClassOf relations for the more specific target concepts. Keep in mind that this decision depends on the choice of the Master Concept in step 3 (User Input).

Example: In a SKOS concept hierarchy, "ice cubes" may be a child node to "beverages", because it is somehow related to beverages, but it does not hold that an instance of "ice cubes" is also an instance of "beverage" if the Master Concept is "Actual Product or Service", whereas it may hold if the Master Concept was "An invoice over goods of the respective type", since in most businesses, expenses related to ice cubes are also expenses related to beverages.

The default is no.

If you are not sure whether this hold for your SKOS vocabulary, you can use the respective online check for this property.

Online Checks

For the three modeling choices in this step, SKOS2OWL can present to you a representative random sample from the ontology to be created. You have to judge whether the selected modeling decision is appropriate a few times. If your choice is correct for all of the presented samples, then you can assume it is also appropriate for the overall ontology.

In the first step, you have to choose the sample size (Figure 6). You must select at least four leave classes and we recommend 10% of all leaves. The more leaves you look at, the more confident can you be that the resulting ontology is consistent.

Figure 6: Selecting the sample size.

Then, the tool shows you all super-concepts of the randomly chosen leave and asks you to check whether the modeling is correct (Figure 7). If the modeling is correct, the tool takes you to the next element in the sample. If not, the tool will stop and suggest the default modeling choice. If you do not report any problem in the presented samples, then the tool assumes your choice is correct.

Figure 7: SKOS2OWL asks you to check your modeling choice for a random sample.

Step 6: Generating Ontology

On the last screen, SKOS2OWL shows the first 100 lines of the resulting ontology and provides a link to the full ontology. You can either download the RDF/XML file or a compressed version as a ZIP file by clicking on the symbol right to the filename.

Important: The links are only temporary - please download your ontology and save / publish on your own.

Figure 8: SKOS2OWL Output