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

ISSUE-183 new draft response

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Wed, 22 Oct 2008 11:30:04 +0200
Message-ID: <48FEF29C.7020002@few.vu.nl>
To: SWD WG <public-swd-wg@w3.org>


Hi all,

Here's a new draft response to Michael on [ISSUE-183]. Please let me 
know what you think, especialy wrt. formality level!

Antoine

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

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

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

As a matter of fact, SKOS does not offer by default a solution that 
would fit exactly your problem. Our concern with your comment is however 
that its scope might be limited, considering the whole context of KOS 
practice. We have indeed not identified that kind of situation in our 
Use Cases and Requirements document [2], even for the classification 
case we had at hand, which was UDC [3].

Further, your problem is quite difficult to get. I assume that 
"subject/topics", even if they are different classes, are "units of 
thoughts" which also play a structuring role in your KOS, to paraphrase 
the SKOS Primer [4]. And that they can therefore be modelled as 
instances of skos:Concept in their own right.
Consequently, you could model aqll your semantic relations as standard 
paradigmatic SKOS relations at the level of topic/subjects or between 
classes and subjects/topics, without having to code this at the class 
level. And thus avoid the cycles you mention.

In the light of the assumed relative rarity of your case and existence 
of a solution for it, we propose to *close* ISSUE-183 [ISSUE-183], 
making no change to the existing SKOS documents. We hope that you are 
able to live with this.


Please note that it is still possible to coin a practice giving a finer 
solution to your problem, using existing properties from SKOS.
Namely, 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. 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 section 3.1 of the SKOS Primer [5].

We actually would welcome your opinion on such a practice. And if you 
believe this situation is more common than what we currently think, we 
would 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 [6]...

Best regards,

Antoine

[ISSUE-183] http://www.w3.org/2006/07/SWD/track/issues/183
[1] http://lists.w3.org/Archives/Public/public-swd-wg/2008Oct/0061.html
[2] http://www.w3.org/2006/07/SKOS/UCR.html
[3] http://www.w3.org/2006/07/SWD/wiki/EucUDC
[4] http://www.w3.org/TR/2008/WD-skos-primer-20080829/#secconcept
[5] http://www.w3.org/TR/2008/WD-skos-primer-20080829/#secextension
[6] http://esw.w3.org/topic/SkosDev/ClassificationPubGuide?rev=12
Received on Wednesday, 22 October 2008 09:30:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 22 October 2008 09:30:33 GMT