SKOS RDF Schema
This page is about the SKOS RDF Schema
A draft schema  is available. The schema is intended to provide a machine readable version of the referencee , encoding information in triples where possible. The draft makes a number of decisions w.r.t to namespaces, expressivity and deprecation of vocabulary
The schema is OWL full. This is due to a number of factors. Properties are defined as owl:ObjectProperty and then used with data values, which violates the OWL namespace separation. Properties are also defined as owl:ObjectProperty and then used to assert information about instances of owl:Class. Again, this is not allowed in OWL DL ontologies.
A number of people have expressed a desire to have the schema as an OWL DL ontology. A version of the schema could be produced without the offending triples (largely by removing the documentation from the schema). Usage of the SKOS schema could still easily result in OWL Full ontologies, however, if the documentation properties were to be used in particular ways.
If we do publish an OWL DL schema, how would this be done?
- As the "canonical" schema?
- As a separate document? And if so, at which namespace would this be published?
It is likely that the changes introduced in OWL 2  will support the kinds of modelling used in the SKOS schema — in fact the SKOS WG may be able to use the schema as a use case and input for the OWL WG. In this event, an OWL 2 version of the schema could be published without impacting on the intended semantics.
In  there are three alternative proposals for handling deprecated vocabulary
A: Keep old namespace, don't include deprecated vocab.
B: Keep old namespace, include deprecated vocab (and mark as such)
C: Define new namespace, with only new vocab.
with C as the preferred option. The only explicit response to this was , which stated a strong preference for C. We discussed this at our 6 May 2008 face-to-face and resolved to choose C.
A comment regarding the namespace change has been posted to the list . A draft response is below.
Dear Bernard and Thomas, Thank you for your comments regarding the SKOS Reference and namespace. The Working Group spent some time discussing the question of the SKOS namespace, and whether to adopt a new namespace for the SKOS Recommendation. For example, see discussion threads: http://lists.w3.org/Archives/Public/public-swd-wg/2008Apr/0032.html SWD Telecon meeting minutes: http://www.w3.org/2008/04/08-swd-minutes.html#item03 http://www.w3.org/2008/05/06-swd-minutes.html#skosnamespace SKOS Issues: http://www.w3.org/2006/07/SWD/track/issues/117 For the sake of brevity, in the following discussion, I'll refer to the http://www.w3.org/2004/02/skos namespace as the "2004 namespace" and http://www.w3.org/2008/05/skos as the "2008 namespace". The WG considered the following choices: 1/ Redefine the properties in the existing 2004 namespace or 2/ Provide a new namespace This was not a simple or easy choice -- there are tradeoffs that we need to consider for both solutions. As you point out in your comment, even though SKOS is not as yet, a Recommendation, there are already a number of vocabularies and applications that are using the 2004 namespace. A change of namespace could then require change to those vocabularies and applications. A key issue here, however, was the fact that the proposed semantics for the SKOS vocabulary (in particular the skos:broader and skos:narrower properties) differ from the semantics in the 2004 SKOS vocabulary as currently published at: http://www.w3.org/2004/02/skos/core.rdf By continuing to use the 2004 namespace and changing the semantics, we run the risk of inconsistent interpretations of existing vocabularies that make assumptions based on the original specification. The WG decided that there were sufficient changes in the vocabulary (and semantics) to warrant the introduction of a new namespace. The existing 2004 namespace can still be used, and the machine-readable specification will also still be available.
The following text is intended to represent our requirements for either property punning or rich annotations in OWL 2.
The SKOS vocabulary is intended for the representation of simple knowledge organisation schemes such as thesauri, term lists and controlled vocabularies. SKOS is designed to fit into existing Semantic Web standards, and to achieve this, an RDF Schema which defines the SKOS vocabulary has been produced. The development of this schema has highlighted issues relating to OWL species which are relevant to current work on OWL 2. In particular, the current schema is in OWL Full. It would be desirable if the SKOS vocabulary could be represented in OWL DL (or the equivalent of OWL DL in the OWL 2 space). Concepts in a SKOS vocabulary are defined as instances of the owl:Class skos:Concept. They may be related to other skos:Concepts using object properties such as skos:broader, skos:narrower and skos:related -- known as SKOS semantic relations. SKOS also provides a set of lexical labelling properties, such as skos:prefLabel and skos:altLabel. These are datatype properties, with RDF plain literals as values. Documentation properties including skos:note, skos:changeNote, skos:definition are also provided, allowing the decoration of concepts with additional information. In some circumstances, the expected value of a documentation property is a literal value (e.g. a simple textual note). In other circumstances, the value may be an object, for example the value of skos:changeNote may be a structured object containing information about a change along with provenance or date information. Documentation properties are defined as subproperties of skos:note. An additional use case for SKOS is as an annotation vocabulary for OWL ontologies. For example the SKOS vocabulary itself uses skos:changeNote and skos:definition to attach provenance and documentation information to the SKOS vocabulary terms. This then pushes the ontology out of OWL DL as object properties are being applied to classes. We envisage that SKOS properties will also be used to attach lexical information to OWL ontologies (for example, providing alternate names or labels for classes). Again, with the current situation, this results in OWL Full ontologies. One solution to this would be the provision of rich annotations. The SKOS documentation properties are essentially annotations and would ideally be represented as such, but with the addition of subproperty relationships between the properties (i.e, skos:note as a superproperty). The lexical labelling properties could also be considered as annotation properties. SKOS is intended to be extensible, however, so again allowing the possibility of providing subproperties of the lexical labelling properties is desirable. Support for punning, both in terms of class/instance and data/object property would also provide solutions to some of these issues. Rich annotations would, however, be our preference.