ISSUE-129 draft response

Hi all,

Here's a draft response to Lourens on [ISSUE-129], 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
Lourens. (Lourens if you're lurking on this list feel free to post your
thoughts at any time.)


Dear Lourens

Thank you for your comments [1]:

A comment on
"S9 skos:ConceptScheme is disjoint with skos:Concept "

I have considered modelling complex thesauri containing sub thesauri
describing different aspects of objects (persons,subjects,..) as
a general concept scheme having sub thesauri as top concepts.
(often the pre-skos version is organized as a tree with top level
children nodes that are the aspects themselves).

ct:complex_thesaurus rdf:type skos:ConceptScheme
ct:complex_thesaurus skos:hasTopConcept ct:subjects
ct:complex_thesaurus skos:hasTopConcept ct:persons
ct:complex_thesaurus skos:hasTopConcept ...


ct:subjects rdf:type skos:Concept,

but I would also like
ct:subjects" rdf:type skos:ConceptScheme

I would put all ct:complex_thesaurus concepts skos:inScheme  

ct:subject1 rdf:type skos:Concept
ct:subject1 skos:broader ct:subjects
ct:subject1 skos:inScheme ct:subjects
ct:subject1 skos:inScheme ct:complex_thesaurus

Then, ct:complex_thesaurus would be a proper conceptscheme with tree
but its subtree ct:subjects would also be a proper conceptscheme.

Why? Because I would dislike having to define two distinct URIs for
the subject that is a topconcept of ct:complex_thesaurus and
the subject that is a Conceptscheme that defines all subjects  
concepts that are
descendants of the ct:subjects concept. I would then need to define  
some ad hoc
property linking both subject uris.

Requires discussion.


If I understand your use case correctly, you would like to define a  
composite thesaurus where the composition of the thesaurus is  
essentially represented using the hasTopConcept relation between the  
"super"-thesaurus and its constituent parts (treating each  
constituent thesaurus as a subject for this purpose). Speaking  
personally, I would be a little concerned at the use of the SKOS  
relations for this purpose as you are in some ways overloading the  
interpretation of the relationships. It may be better to approach  
this using existing mechanisms for modularity (such as owl:imports).

As you discuss, in the SKOS data model, a concept scheme is viewed as  
an aggregation of a number of Concepts and we have chosen to make  
Concept and ConceptScheme disjoint. This does then require the  
introduction of additional URLs to identify the scheme and the  
concepts but we believe that maintaining a separation between the two  
notions aids clarity.

I hope this helps and that you are able to live with the current  


	Sean Bechhofer
	Alistair Miles


Sean Bechhofer
School of Computer Science
University of Manchester

Received on Monday, 6 October 2008 12:23:37 UTC