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.
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.
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.