Re: SKOS comment: Grouping Concept Schemes

Hi Jakob,
>
>> 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)
>
> So is Collection for "structuring" and CS to "define vocabularies"? 
> Isn't "defining a vocabulary" always a way of "structuring"? 

Sorry I was unclear. I added "the content of a vocabulary" to precise 
that collections were aimed at structuring concepts *inside* a concept 
scheme.

> My first motivation was to create an easy way to group concept schemes 
> and so I came to the question what skos:member and skos:inScheme mean. 
> There are four cases to be covered by SKOS:
>
> 1. the membership of a concept to a concept scheme (inScheme?)
> 2. the membership of a concept to a collection (member?)
> 3. the membership of a concept scheme to a concept scheme (?)
> 4. the membership of a collection to a collection (member?)

skos:member covers 4 for the moment, as you hypothesize (since current 
specification already allows for nested collections)
>
> Point 3 is not defined yet. Furthermore the semantics have to be 
> clarified: 

Yes, even for more fundamental points (see below)
> which membership is transitive? which membership implies another 
> membership relation?
>
>> 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
>
> Well, I am not sure why you need "if a concept C1 is a member of CS1 
> which is a member of CS2 then C1 is a member of CS2". 

Now it's my turn to be confused: if you refuse this, why then nest 
concept schemes inside each other? I don't see why an encompassing 
concept scheme would not include the concepts of its "sub" concept 
schemes...

> We should better define what "beeing a member of a Collection" means 
> compared to "beeing in a scheme".

Well I guess the semantics of the membership relation is quite the same 
(we've got to kinds of sets of concepts). Only the range of the 
membership differs. On the one hand we've got sets with a "meaningful" 
collection criterion, that is, concepts make a coherent whole (usually 
there is a semantic axis) while on the other hand we've got sets that 
are motivated by an application which require a vocabulary. Most of the 
time it will be practice alone (e.g. description/indexing) that 
motivates a concept being a member of a scheme, I guess.

Cheers,

Antoine

Received on Tuesday, 5 February 2008 08:53:11 UTC