W3C home > Mailing lists > Public > public-swd-wg@w3.org > January 2008

RE: [SKOS] Re: Review of the SKOS Primer

From: Reul, Q. H. <q.reul@abdn.ac.uk>
Date: Fri, 25 Jan 2008 13:30:01 -0000
Message-ID: <2AD2401FC36E784094D0B3375FDA6CE802C2BA9C@VMAIL2.uoa.abdn.ac.uk>
To: "Antoine Isaac" <aisaac@few.vu.nl>
Cc: <public-swd-wg@w3.org>

Dear Antoine,

Dear Antoine,

I can find below my answer to most of your comments that I needed to
reply to. Let me know if you have anymore questions. 



- Although it is mentioned in the Primer [1] is that it a companion to
the SKOS Reference [2], I sometimes had to go through the whole document
to find a link to the reference. Would it not be possible to make the
title of the section as a direct link to the appropriate section in the
Reference? Obviously, the link doesn't need to be explicitly stated
throughout the document. You could revise the introduction to make it
This document is a companion to the SKOS Reference, which gives the 
normative reference on SKOS. The reader is able to consult the SKOS
Reference [SKOS-REFERENCE] by clicking on the property (e.g.

- The examples in the Primer [1] are similar to the example found in the
original SKOS Core document [3]. Would it not be possible to re-use
those examples to save you the time to have to create them? 

- I just thought that a single example would have tied up the different
construct better as we could have added a link to the generated SKOS
file for the user to have a look @ it, but I totally understand your

- Sorry about the grammar/vocabulary documents, my supervisor tends to
argue a lot about these things. The only I feel strongly about is to use
"machine-readable" instead of "machine-processable", as the former is
commonly used in the field.

- Your suggestion sounds appropriate to me.
> but I really don't like the result. Would you think it is also OK to
> the paragraph where it was, but to create an appropriate subsection
> the issues of labelling semantics?

- "Use of Labels Outside SKOS": I think the addition of the new
paragraph with the OWL example better show the full power of combining
SKOS with other knowledge representation.

- Semantic Relationships: I totally understand that we won't be able to
stop to use skos:broader to represent part-whole relationship, but as I
said before certain type of KOS would need this difference to be made
specific. The addition of the new paragraph is useful to refer people to
the right section in the Primer [1].

- I agree
> 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
> to link a concept scheme to the (possibly many) most general concepts

[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/

-----Original Message-----
From: Antoine Isaac [mailto:aisaac@few.vu.nl] 
Sent: 25 January 2008 11:24
To: Reul, Q. H.
Cc: public-swd-wg@w3.org
Subject: [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
> 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
> 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
> [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
> ontologies are normally expressed using the rdfs:label and
> 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
> 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
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
> 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
> 44 [4] and 56 [5]). I think I would rather have certain
> as proposed in [6] and [7], to be added in the SKOS vocabulary to
> 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
> be useful to make it explicit.

I have added "RDF" as you suggest

> - Finally, I would agree with Margherita [8] to use skos:hasBroader
> 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
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
> 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
> 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
> 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
> as per [7].

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

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



> 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]
> ******************************************
> * Quentin H. Reul *
> * PhD Research Student *
> * Department of Computing Science *
> * University of Aberdeen, King's College *
> * Room 238 in the Meston Building *
> * Phone: +44 (0)1224 27 4485 *
> * http://www.csd.abdn.ac.uk/~qreul *
> ******************************************
Received on Friday, 25 January 2008 13:30:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:31:47 UTC