W3C home > Mailing lists > Public > public-esw-thes@w3.org > January 2008

Re: SKOS comment: Grouping Concept Schemes

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Thu, 31 Jan 2008 12:14:43 +0100
Message-ID: <47A1ADA3.2020806@few.vu.nl>
To: Jakob Voss <jakob.voss@gbv.de>
CC: public-swd-wg@w3.org, public-esw-thes@w3.org

Hi Jakob,

Your comments make much sense to me but : (of course there are BUTs ;-)

I have indeed nothing against introducing a superclass 
(ConceptGrouping?) of ConceptScheme and Collection that would be the 
domain of "member" (or the range of a renamed "inscheme"). I am however 
unconfortable with declaring one as the subclass of the other, since 
their logics seems slightly different (CS group concepts to define 
vocabularies, Collection group concepts for structuring the content of a 
vocabulary)

The problem is also that for the moment inScheme and member have 
restriction on their domain and range that may make the thing more 
difficult to implement.
E.g. inScheme  is applied to concepts, and member can target collections 
(when you have nested collections) while collections and concepts are 
disjoint. So the range of the new "member" would be the union of Concept 
and ConceptGrouping.

There might be also consequences for ISSUE-83 [4], if you allow for 
nested concept schemes (which I think can occur in the context you 
introduce in [2])
If you allow for nested concept schemes, then "member" should be 
transitive (if a concept C1 is a member of CS1 which is a member of CS2 
then C1 is a member of CS2). But this doesn't work for nested 
collection, as you rightly put it in [3]: if C1 is a member of Coll1 
which is a member of Coll2 then C1 is not a member of Coll2

Cheers,

Antoine

[1] http://www.w3.org/2006/07/SWD/track/issues/83
[2] http://lists.w3.org/Archives/Public/public-esw-thes/2008Jan/0089.html
[3] http://lists.w3.org/Archives/Public/public-swd-wg/2008Jan/0208.html
[4] http://www.w3.org/2006/07/SWD/track/issues/83
>
> Hi,
>
> Grouping Concept Schemes via making skos:ConceptScheme a subclass of 
> skos:Collection does imply or allow some more changes that you may be 
> interested in: We could rename skos:inScheme to skos:memberIn and make 
> it the reverse to skos:member? What's the semantic difference between
>
> <C> skos:inScheme <S>
>
> and
>
> <S> skos:member <C>
>
> In practise I think it's the same, so why not combining it? I think it 
> makes SKOS simpler to put this things (skos:ConceptScheme and 
> skos:Collection, skos:inScheme and skos:member) together.
>
>
> Alistair Miles wrote:
>
>> We ask at this stage feedback and reviews on this draft specification.
>> All comments are welcome and may be sent to public-swd-wg@w3.org;
>> please include the text "SKOS comment" in the subject line. Note
>> especially that there are a number of open issues, which are indicated
>> in the document.
>
> As explained in http://arxiv.org/abs/0801.3908 there is a need to 
> hierarchically group Concept Schemes (a Concept Scheme may contain 
> other Concept Schemes). To solve this, change the current draft in the 
> following way:
>
> Make skos:ConceptScheme a subclass of skos:Collection. The draft says:
>
> In 4.1. "A SKOS concept scheme can be viewed as an aggregation of one 
> or more conceptual resources. "
>
> In 9.1. "SKOS concept collections are labeled and/or ordered groups of 
> conceptual resources."
>
> An "aggregation of one or more conceptual resources" is obviously a 
> special kind of a "labeled and/or ordered groups of conceptual 
> resources". By making skos:ConceptScheme a subclass of skos:Collection 
> you can group concept schemes this way:
>
> <A> rdf:type skos:ConceptScheme .
> <B> rdf:type skos:ConceptScheme .
>
> <A> skos:member <B> .
>
> You have to change S40 in 9.4. Integrity Conditions to
> "skos:Collection is disjoint with skos:Concept and skos:LabelRelation."
>
>
> You could also think about making skos:hasTopConcept a sub-property of 
> skos:member, thus
>
> <MyScheme> skos:hasTopConcept <MyConcept>
>
> implies
>
> <MyScheme> skos:member <MyConcept>
>
> But I am not sure whether a top concept must also be a member of its 
> concept scheme. Same aplies to skos:inScheme: You could specify
>
> <MyConcept> skos:inScheme <MyScheme>
>
> implies
>
> <MyScheme> skos:member <MyConcept>
>
> Maybe you better rename 'skos:inScheme' to 'skos:memberIn'?
>
>
> I have not found any other problems with this solution so far.
>
> The solution should also be noted in
> 10.6.6. Links Between and Within Concept Schemes
>
>
> Greetings,
> Jakob
>
Received on Thursday, 31 January 2008 11:15:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:38:59 GMT