Review of the SKOS Primer

Antoine, Ed,

I found the SKOS primer [1] rather interesting and I will organise my
review in 2 sections. On the one hand, I will give general comments
about the document. On the other hand, I will go in more details for
certain section. I would like to apologise for the length of the review.

General comments
================
I think that a clear mapping between the formal semantic available in
the SKOS reference [2] with the different classes and properties in the
SKOS primer [1] should be made throughout the document. This could be
achieved by having a link to the reference [2]. 

I think it would be easier if we were using a concrete example
throughout the document rather than different example depending on the
property or class. The document is meant to show to use the SKOS
vocabulary and as such using a use case would allow the user to fully
understand how to create a KOS with SKOS. Furthermore, I think that in
some cases the use of a graph or picture would facilitate the
understanding of the property similar to the one available in SKOS Core
[3]. This is particularly useful for representing inverse relation
between skos:broader and skos:narrower and to display collections.

Once the acronym KOS has been defined, I think it should be used
throughout the document instead of "knowledge organisation systems".

Specific comments
=================
Abstract:
- I would move "meaningfully" before "on the World Wide Web".
- I use "character string" or simply "string" rather than "lexical
strings" in the third paragraph.
- In the last paragraph, I would refer to "concept labels" rather than
"labels of concepts".


Introduction:
- I would use "machine-readable" rather than "machine-processable".
- I would combine the last sentence from the second paragraph with the
third paragraph as they seem to be related.

About this Primer:
- "publish their concept schemes in SKOS" rather than "as SKOS" as we
are defining SKOS as a vocabulary.
- I would use "formal semantic" rather than "reference semantic".

SKOS Essential:
- I would modify the ordering of this section as follow:
2.1 Concepts
2.2 Labels
2.3 Document Notes
2.4 Semantic Relationships
2.5 Concept Schemes
This ordering first describes the main component of SKOS and describes
the different properties relevant to it before introducing the
organisation (i.e. skos:ConceptSchemes). Furthermore, it might be useful
to introduce numbering to the different sub section (e.g. 2.1.1
skos:prefLabel) to facilitate access from the content list.

Labels: 
- I would move the paragraph in the introduction for the section rather
than in hidden labels.
"As specified in Section 5 of the SKOS Reference, the properties
skos:prefLabel, skos:altLabel and skos:hiddenLabel are all
sub-properties of rdfs:label. It is important to note that they are
pairwise disjoint. A concept cannot have a same literal both as
preferred label and alternative one at the same time, for instance."
- In the "Use of Labels Outside SKOS", I would use a OWL example
describing what problem would be solved by using SKOS. 
"Human-readable annotations on classes, properties and individuals in
OWL
ontologies are normally expressed using the rdfs:label and rdfs:comment
properties. Consider the following triples that describe animals:

ex:animal rdf:type owl:Class;
  rdfs:labels "animal"@en;
  rdfs:labels "creatures"@en.

An application would have difficulties to display the right label to the
user as they both have the same weight. SKOS labels allow the
implementer to explicitly define the labels for a given resource."

Semantic Relationships:
- I find it confusing to use "the one between one whole and its parts"
as part of the definition of broader and narrower. These relationships
are used to represent hierarchies and allowing composition to be similar
to subsumption which might be correct in some KOS but would be totally
wrong in other cases. I think that this COULD cause problems when
integrating different concept schemes using different aspect (see ISSUES
44 [4] and 56 [5]). I think I would rather have certain sub-properties,
as proposed in [6] and [7], to be added in the SKOS vocabulary to ensure
interoperability.
- The last paragraph of this section refers to a graph but no graph is
present in the document. If referring to the RDF graph instead, it would
be useful to make it explicit.
- Finally, I would agree with Margherita [8] to use skos:hasBroader and
skos:hasNarrower to remove any confusion about the intended meaning of
the property.

Concept Schemes:
- As far as I know, there is no restriction on the number of top
concepts a given concept scheme can have and I think it would be
important to reiterate this point as part of this section.

Re-using and Extending Concept Schemes:
- "This does not however replace the skos:inScheme statements between
the imported concepts and the importing scheme. Using owl:imports
indicates that all statements from ex1:referenceAnimalScheme are
imported into ex2:thePlatypusScheme, but the original information source
did not define its concepts as belonging to the new scheme."
I'm not sure if you mean that ex2:thePlatypusScheme is not included in
the imported concept scheme or if you need to explicitly define  

ex2:nicePlatypus skos:inScheme ex1:referenceAnimalScheme. 

Subject Indexing in SKOS:
- From a reuse perspective, I think it would better to use dc:subject
rather than create a new property within SKOS.

SKOS Collections and semantic relations:
- I understand the idea behind the addition of skos:Collection to the
vocabulary, i.e. to represent arrays, etc. However, the current semantic
make it redundant especially when using semantic relationships as
collections can't be used as part of the BT, NT, RT triple. 

Relationships between Labels:
- I might totally misunderstand the reason for this issue. I would have
thought that the following could have solved the problem easily.

ex:acronym rdfs:subPropertyOf skos:altLabel 

This would be associated to a concept and therefore easily retrievable
by an application,

On Specializing the SKOS Model:
- I think that this section advocates for a SKOS extension to be created
as per [7].
    
Quentin

[1] http://www.w3.org/2006/07/SWD/wiki/SKOS/DraftPrimer
[2] http://www.w3.org/2006/07/SWD/SKOS/reference/20071223
[3] http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20051102/
[4] http://www.w3.org/2006/07/SWD/track/issues/44
[5] http://www.w3.org/2006/07/SWD/track/issues/56
[6]
http://www.w3.org/2001/sw/Europe/reports/thes/1.0/guide/20040504/#3.9
[7] http://www.w3.org/2004/02/skos/extensions/spec/
[8] http://lists.w3.org/Archives/Public/public-swd-wg/2008Jan/0075.html

******************************************
* Quentin H. Reul                        *
* PhD Research Student                   *
* Department of Computing Science        *
* University of Aberdeen, King's College *
* Room 238 in the Meston Building        *
* ABERDEEN AB24 3UE                      *
* Phone: +44 (0)1224 27 4485             *
* http://www.csd.abdn.ac.uk/~qreul       *
******************************************

Received on Tuesday, 15 January 2008 12:51:16 UTC