[SKOS] Re: Review of the SKOS Primer

Dear Quentin,

First: thanks for the impressive reviewing work! The length of the 
review if of course a very positive point, to answer your concern ;-)

Please find below my answers to these comments. These can be either 
actions on the document or further questions...
A new draft is available at 
http://www.w3.org/2006/07/SWD/wiki/SKOS/DraftPrimer that hopefully 
solves some of the issues.

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

Do you mean, for each property and class, having a link to the 
Reference? Or just mentioning it more often in the Primer?
We thought citing it in the introduction (twice, as a reference to the 
reader for complete info on SKOS) would be enough.
Also, we cited it each time we felt it was explicitly needed. But it can 
of course be improved. In the latest version, there are 8 citations 
throughout the document.
To make the link between the Primer and the Reference clearer, I have 
added in the abstract
[[
This document is a companion to the SKOS Reference, which gives the 
normative reference on SKOS
]]

Also, in the introduction,
[[
the reader should consult the SKOS Reference [SKOS-REFERENCE]
]]
has been replaced by
[[
the reader should consult the normative SKOS Reference [SKOS-REFERENCE]
]]

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

If everyone agrees, I will try to create a version with graphs. But that 
requires time, and, and, also, a decision whether the current examples 
are good.
Now, to answer your first comment, apart from the section on documentary 
notes, there are 5 clearly distinct examples (animals, rocks, FAO, 
TimBL, milk) 3 of them are I think unavoidable (animals, FAO, TimBL).
Of course the sitation could be enhanced in documentary notes section, 
but generally I find it is difficult to find or create a single use case 
that features all the elements that are needed.
Further, I would say that to me the variety of examples is also a hint 
to the fact that SKOS can be applied to different situations. Do you 
really think such a stance really harms the Primer?

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

I've changed this, but am not convinced of the elegance of sentences 
like "Representing a KOS with SKOS". The price to pay for using 
abbreviations, maybe. Your comment made of course sense.

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

Here I'll be a bit blunt: I do not see the differences in many of your 
above suggestions, as I am not a native. And Ed had fixed a lot of 
sentences before we released the draft you've read.
Now, this is surely not a reason for us to ignore your comments. Just to 
point out that Ed had not time to review these before I send out this 
mail, and I therefore would like to postpone a bit our answering them
I trust you to remind us that this point is still a @@TODO!

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

I propose to replace "in SKOS" by "as SKOS data" and "reference 
semantics" by "reference formal semantics".

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

I have followed here what seemed to me the order of importance for 
characterizing a concept, semantic relationships come clearly before the 
documentation (and after labelling).
I agree that this is not the order in the reference. @@TODO If people 
really think my argument does not make sense I will change the order...

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

I have done it, and this seems indeed to be a useful addition (as long 
as it does not double the length of 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."

The introducing paragraphs of section 2 now read
[[
The first characterization of concepts are the expressions that are used 
to refer to them in natural language—their labels. SKOS provides three 
properties to attach labels to conceptual resources: skos:prefLabel, 
skos:altLabel and skos:hiddenLabel. Each property implies a specific 
status for the label it introduces, ranging from a strong, univocal 
denotation relationship, to a string to aid in lookup. These properties 
are pairwise disjoint. A concept cannot have a same literal both as 
preferred label and alternative one at the same time, for instance.

As specified in Section 5 of the SKOS Reference, the properties 
skos:prefLabel, skos:altLabel and skos:hiddenLabel are considered as 
simple labelling means. As a result, they are all sub-properties of 
rdfs:label. Also, from a syntactic perspective, all these three 
properties have RDF plain literals as a range [RDF-CONCEPTS]. In other 
words they link a skos:Concept to a character string, not to another 
full-fledged RDF resource identified with a URI.
]]
but I really don't like the result. Would you think it is also OK to 
keep the paragraph where it was, but to create an appropriate subsection 
for the issues of labelling semantics?

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

I would propose to add your idea but also to keep the the previous example
[[
While it is somewhat outside the scope of this Primer, it is possible to 
use SKOS labelling properties to label resources that are not of type 
skos:Concept. Consider these triples that describe Tim Berners-Lee:
<http://www.w3.org/People/Berners-Lee/card#i> a foaf:Person;
foaf:name "Timothy Berners-Lee";
foaf:nick "timbl";
rdfs:label "Tim Berners-Lee";
skos:prefLabel "Tim Berners-Lee"@en.
An application that wishes to display a label for this resource is able 
to identify "Tim Berners-Lee" as the preferred label instead of having 
to choose between the equally compatible labels rdfs:label "Tim 
Berners-Lee" or the foaf:name "Timothy Berners-Lee". These labels are 
compatible because foaf:name is a sub-property of rdfs:label.

Another example are human-readable labels on classes, properties and 
individuals in OWL ontologies, which are normally expressed using 
rdfs:label alone. Consider the following triples that describe humans:
ex:Human rdf:type owl:Class;
rdfs:label "human"@en;
rdfs:label "man"@en.
An application would have difficulties to display the right label to the 
user as they both have the same weight. The semantics of skos:prefLabel 
allow implementors to explicitly define the label for a given resource. 
In general the ability to mix-in vocabulary elements from SKOS and other 
RDF vocabularies at will like this is what gives RDF much of its 
expressive power.
]]

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

This issue has and will be extensively discussed elsewhere.
For the moment I propose to add a sentence that acknowledge the problem 
and points to the possible specializations of Section 4.8:
[[
Finally, an aspect left untouched here is the way one can distinguish 
the situations that hierarchical relations cover. As said in the 
preamble for this section, these can range from instance-class 
relationhips to part-whole ones. The interested reader is referred to 
Section 4.8, which presents a way to create specializations of semantic 
relations so as to deal with this issue.
]]
I would like to insist on the fact that it is however not possible to 
generally discourage the use of skos:broader to represent part-whole 
relationship, as it is very common in the KOS practice to use the 
generic BT link for this as well

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

I have added "RDF" as you suggest

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

I'll do the same answer as I did for Margherita. As soon as there is a 
resolution on http://www.w3.org/2006/07/SWD/track/issues/82 we'll update 
the Primer accordingly!

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

I propose to replace in this section 2.5
[[
This property allows to link a concept scheme to the most general concepts
]]
by
[[
This property allows to link a concept scheme to the (possibly many) 
most general concepts
]]

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

This is indeed not 100% clear to the reader.
I propose to add
[[
One has therefore to assert the ex1:platypus skos:inScheme 
ex2:thePlatypusScheme statement emphasized above.
]]

> 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.
I hope the discussion on ISSUE-48 will soon provide more insight on this 
issue. Notice that your comment is per se very valueable, and rewards 
well my letting this TODO in the draft ;-)

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

I think we can do nothing with this comment, it is not really the Primer 
to solve this :-( Perhaps you can raise this as a problem in a different 
mail about collections in general. We'll of course change the Primer if 
there is a problem.

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

I would say that if you do this, you loose the information that "FAO" is 
*the* acronym of the label "Food and Agriculture Organization". If the 
link is between the concept and the label, it is just *one* acronym for 
the concept.

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

Well, this is not our work to as editors to solve this, I think. Hence the
[[
@@TODO: check this section, according to resolutions on ISSUE-56@@
]]
that is in this section, showing that we do not consider that it is stable.

Thanks again for these very helpful comments. I hope you will not mind 
answering the questions that I have asked on some of them...

Best,

Antoine

> 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 Friday, 25 January 2008 11:24:38 UTC