SKOS Reference review

Alistair, Sean,

Attached is my review. Sorry for the delay.

I like the document a lot. I think we will still be able to take a 
decision on Tuesday, if you can manage a response before that time. In 
responding just comment on the non-editorial comments. The editorials 
ones I leave to your discretion.

Guus



Review SKOS Reference
Version: http://www.w3.org/2006/07/SWD/SKOS/reference/20080730/


This document is in good shape. I have no objections to publishing, 
provide the comments below are taken into account. Most comments are 
editorial.


GENERAL EDITING

- Please change "foo/bar" examples.
- "Integrity constraints/conditions": use one of these forms  consistently
- "data" variably used as singular or plural, e.g.
   "SKOS data are"  but also "some given data conforms to "

SYNOPSIS

"documented with various types of note"
note => notes

STATUS

The 2nd "feature at risk" is unclear. We have to state the options and 
how the current choice might change (e.g. adding property-chaining axioms).


SEC. 1

Consider to add a note about the overall design rationale behind SKOS, 
roughly covering the following issues:
- wide coverage of KOSs required
- therefore danger of SKOS schema overcommitment
- WG rationale: if in doubt, don't include a formal constraint (least 
commitment strategy), but suggest usage convention or specialization 
instead => see Primer

1.2: suggest to change section title to "SKOS Overview"

1.3

" ...I.e. SKOS is itself an OWL Full ontology."
delete this part of the sentence as it is more or less a repetition of 
the earlier part.

[[
   I.e. it is appropriate (if one has the time, effort and need) to 
manually re-engineer a thesaurus or classification scheme as a formal 
OWL ontology, using the "concepts" of the thesaurus as a starting point 
for creating classes, properties and individuals in the ontology, and 
using the informal hierarchies and association networks of the thesaurus 
as a starting point for creating the axioms and facts of the ontology. 
However, OWL is a formal ontology language, and it does not by itself 
provide a natural or suitable data model for expressing a thesaurus or 
classification scheme. I.e. it is not appropriate to express the 
"concepts" of a thesaurus or classification scheme directly as classes 
of an ontology, nor to express the informal (broader/narrower) hierarchy 
of a thesaurus directly as a set of class subsumption axioms. The reason 
for this is that, because a thesaurus or classification scheme has not 
been developed with formal semantics in mind, but rather as an informal 
or semi-formal aid to navigation and information retrieval, expressing a 
thesaurus hierarchy directly as a set of ontology classes with 
subsumption axioms typically leads to a number of inappropriate or 
nonsensical conclusions.
]]

I suggest to delete this paragraph. I think the issue is made clear 
enough in the rest of the text (also in 1.4), and this paragraph might 
be perceived as too opinionated.

1.4

Should we label this section explicitly as "Informative"?

1.5

[[
   These statements are not integrity conditions. I.e. the graph below 
is perfectly consistent with the SKOS data model, despite the fact that 
<A> and <B> have not been explicitly declared as instances of skos:Concept.
]]

I find this unclear, in particular the "despite" part. I would reverse 
the argument: OWL Full does not require that <A> and <B> are explicitly 
defined as concepts, so the model is consistent. You could also argue 
that it is till an integrity constraint, as it disallows, for example, 
<A> to be a concept scheme. This is the only point in my review where I 
would appreciate some discussion.

1.7

"an RDF graph" => "a RDF graph"


SEC. 2:

I suggest to make the table ordering more logical:

    skos:Concept   skos:ConceptScheme   skos:inScheme 
skos:hasTopConcept   skos:topConceptInScheme

   skos:altLabel
   skos:hiddenLabel
   skos:prefLabel

   skos:note
   skos:notation
   skos:changeNote
   skos:definition
   skos:editorialNote
   skos:example
   skos:historyNote
   skos:scopeNote

   skos:semanticRelation
   skos:broaderTransitive
   skos:broader
   skos:narrowerTransitive
   skos:narrower
   skos:related

   skos:Collection
   skos:OrderedCollection
   skos:member
   skos:memberList 	

   skos:mappingRelation
   skos:closeMatch 	
   skos:exactMatch 	
   skos:broadMatch
   skos:narrowMatch
   skos:relatedMatch


SEC. 4

Example 5:

[[
   <MyConcept> skos:topConceptInScheme <MyScheme> .
]]

This statement could have been derived from the inverse semantics. 
Either remove or explicate in the text.

I find the name "skos:topConceptInScheme" too contrived. I prefer the 
natural inverse of "skos:hasTopConcept", namely "skos:topConceptOf". 
This is probably also eaier to understand and remember.


4.6.3 named RDF graphs

Explain (or refer to Primer) the issue of schema containment and 
potential use of SPARQL + named graphs

SEC. 5

5.6.2

[[
   For an application that needs to identify labels using URIs, consider 
using the SKOS eXtension for Labels defined in Appendix A.
]]

Instead of this single sentence I suggest to make a separate note about 
XL (e.g. "5.6.3 Defining label relations"), explicating in a few 
sentences why this is needed, just to point readers in the right direction.

5.6.4

This note feels a bit redundant as the point about language tags is 
already made at the end of 5.4


SEC. 7

"7" => "seven"

Example 25: I suggest to refrain from using the construct "rdf:value" as 
it is so rarely used. If you really need it, you have to add an 
explanatory note + RDF ref.

SEC. 8

[[
   S26: skos:related is disjoint with the property skos:broaderTransitive.
]]

Is skos:related also disjoint with skos:narrowerTransitive?

8.6.4.

Explain briefly rationale why skos:related is not transitive.

8.6.6

"(e.g. simple query expansion algorithms)": delete "simple"

8.6.10

First par:
".. distinct in nature, and that therefore a ..."
=>
".. distinct in nature. Therefore a ..."


SEC 9

9.6

Suggest to explain briefly the use of "( .. )" notation in Turtle.


SEC 10

S46: should skos:exactMatch not also be disjoint with skos:narrowMatch?

10.6.7:

"link to individuals"
to => two

[[
   Generally speaking, using owl:sameAs in this way will lead to 
inappropriate inferences, which may sometimes (but not always) be 
detectable by checking consistency with the SKOS data model.
]]

Obscure sentence. The point was already made above, suggest to delete 
this sentence.

APPENDIX

"A property xl:labelRelation is defined. "
=>
"The SKOS data model also defines the property xl:labelRelation."

A1

I suggest to use "skos-xl:" in the examples instead of "xl". In this 
document it is not ambiguous, but in actual usage it might lead to 
reduced clarity. People will use the reference as a model.


A2.1

"an RDF plain literal": an => a

A2.2

Shouldn't there be a definition c.q. semantic condition to define the 
cardinality of precisely 1 for xl:literalForm? BTW this would make the 
FuctionalProperty definition superfluous.

A2.4.1

"As stated above ...": this has actually not been stated yet, see 
previous comment.

[[
   Second, the function is not surjective. In other words, there may be 
no instances of xl:Label with a literal form corresponding to a given 
plain literal.
]]

I cannot parse this sentence (in particular the last part); please 
reformulate.

A3.4.2

"Note the two integrity conditions on the SKOS labeling properties 
defined in Section 5."
=>
""In Section 5 two integrity conditions were defined on the basic SKOS 
labeling properties."