Skip to toolbar

Community & Business Groups

SKOS and OWL for Interoperabilty Community Group

Based on our #SDSVoc bar camp session we would like to discuss best practices for using SKOS and OWL for interoperability

Note: Community Groups are proposed and run by the community. Although W3C hosts these conversations, the groups do not necessarily represent the views of the W3C Membership or staff.

No Reports Yet Published

Learn more about publishing.

Chairs, when logged in, may publish draft and final reports. Please see report requirements.

This group does not have a Chair and thus cannot publish new reports. Learn how to choose a Chair.

opening this group

Dear all,

Thank you for your interest in this community group. The topic for this group is: SKOS and OWL for interoperability. This topic was discussed during the #SDSVoc bar camp in Amsterdam last December, and we felt that we needed more time and more opinions to come up with best practices and design patterns for using SKOS versus OWL.

Some background: in the wild there are many examples of SKOS implementations. People seem to find it a useful, easy standard to “capture things”. On the other hand, people are very creative in extending the basic SKOS scheme, and by doing so move towards a more OWLy version of the original SKOS scheme. (Some examples here.)

Statement: To support interoperability we should agree on using standard design patterns and move away from the tempation to make the perfect semantic model.

This would perhaps imply that it is best to use the SKOS scheme in a clean way and not play with it too much, otherwise the user of your data has to “do something extra”, such as run a reasoner before (s)he can use. And if you want to add complexity, maybe just create an OWL class, and not subclass from skos:Concept.

What is your opinion?


SKOS in the wild

Some examples of how people use SKOS,  beyond just filling in the scheme:

A . subclass skos:Concept with a class that means the same, but has its name in the national language.

The use case for this is merely that one wants to provide the user with a model that is in the national language.

B: to subclass skos:Concept with a number of classes that describe the body of knowledge.

The idea behind this is that the developer wants to use the skos semantic relation properties to build a simple hierarchy.

C: to subclass skos:Concept with a number of classes with OWL restrictions that describe the body of knowledge.

The idea behind this is that the developer wants to use the skos properties to build a simple hierarchy, AND use the restrictions to further describe the Vehicle set.

E. To extend SKOS with capabilities that are (more or less) available in OWL: