ISSUE-183 draft response

Hi all,

Here's a draft response to Michael on [ISSUE-183], let me know what you 
think. Note *this is just a draft, not the actual response* -- I'll wait 
for feedback from the WG before replying formally to
to Michael. (Michael: if you're lurking on this list feel free to post 
your thoughts at any time.)


Dear Michael,

Thank you for your comments [1]:

3. Class-Topic relationships

This issue seems to cause some general problems for using SKOS as a
general tool to model classification systems, since the fundamental
entity in a classification system is not the concept but the class, or,
more precisely, the distinction between classes and their subjects.
There are numerous examples of problems that arise by the difficulty of
expressing in SKOS the interplay between a class and the subjects that
form that class on the basis of at least one common characteristic.

The inability to model other than concept-concept relationships with
SKOS sometimes leads to inconsistencies as subjects/topics are
frequently in the domain or range of common classification

In the DDC, this can manifest itself in classes being connected by both
hierarchical and non-hierarchical relationships if modeled with current

<A> skos:narrower <B> .
<B> skos:related <A> .

This arises because what is expressed here isn't really a relationship
between classes, but between topics and classes:

<A> ddc:narrower <B> .
<Topic_in_B> ddc:related <A> .

This pattern can also lead to circular hierarchical relationships:

<A> ddc:narrower <Topic_in_B> .
<B> ddc:narrower <Topic_in_A> .

At the moment in SKOS, this has to be coded at class level:

<A> skos:narrower <B> .
<B> skos:narrower <A> .

which produces inconsistencies. A possible solution would be to
introduce/define ddc:related (or similar relationships) as a new element
without extending SKOS semantic relationships, even if this would mean
lowering the utility of classification systems in SKOS applications.


Honnestly, I found this comment hard to understand, as it touches 
aspects that were left untouched until now.

My reaction would be that first relations between classes as relation 
between skos:Concepts standing for these classes. Your solution is on 
this point completely appropriate.

But then I'm not sure I get what "subjects/topics" are, if these are 
different from classes. If they are concepts of their own right, why not 
model them as instances of skos:Concept as well?
If you want, you can have the class-concepts in one concept scheme 
(corresponding to the "core" classification scheme) and subject-concepts 
in another concept scheme.
Nothing in SKOS prevents entities from two different schemes to be 
linked by semantic relations such as skos:broader, so this is an option. 
That would allow to consider the subject/topics as specializations of 
classes, in a way similar to what is presented in the "concept scheme 
extension" described in the (current) section 3.1 of the SKOS Primer [1].

This way you wouldn't have to represent links between subject/topics and 
classes or links between subject/topics themselves at the level of 
classes only. Which would avoid the circular hierarchical relationships 
you mention.

We hope that the current SKOS model, as used in this solution, fit your 

Note that would rather not change the current SKOS specification to fit 
your case further. We had indeed not identified that kind of situation 
in our Use Cases and Requirements document [3], even for the 
classification case we had at hand (which was UDC [4]).

We actually would welcome your opinion, whether this is a big 
shortcoming or not. In fact if you believe this situation is more common 
than what we currently think, we'd also encourage you to publish a brief 
best practice note and inform the SKOS community via the mailing list. 
We'd also be more than happy to set up a "SKOS community best practices" 
wiki page to collect links to such statements! Note that in your 
specific case, all the elements that you have brought in [1] could be a 
useful addition to the practices presented in [5]...

Best regards,



Received on Friday, 17 October 2008 09:03:50 UTC