- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Fri, 17 Oct 2008 11:03:16 +0200
- To: SWD WG <public-swd-wg@w3.org>
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.) 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. ------------------------------------------------------------------- ------------------------------------------------------------------- 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 needs. 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, Antoine [1] http://lists.w3.org/Archives/Public/public-swd-wg/2008Oct/0061.html [2] http://www.w3.org/TR/2008/WD-skos-primer-20080829/#secextension [3] http://www.w3.org/2006/07/SKOS/UCR.html [4] http://www.w3.org/2006/07/SWD/wiki/EucUDC [5] http://esw.w3.org/topic/SkosDev/ClassificationPubGuide?rev=12
Received on Friday, 17 October 2008 09:03:50 UTC