Collection vx ConceptScheme Re: SKOS comment: Grouping Concept Schemes

Hi all

Late answer, just read this thread, in the framework of a discussion we 
have with Jérôme in cc about the best expression of "end-user navigation 
taxonomies".
We've used so far ConceptScheme to define those taxonomies, and used 
Collections in the concept hierarchy, as was allowed by SKOS Core 1.0, 
but actually sounded like a kind of hacking. But this is no more 
conformant to the current draft, as I discovered only yesterday. :-(  
Which is too bad, because we had a whole chain of production using this ...
See e.g http://recherches.nievre-tourisme.com/.

So, reading and thinking more about it, I figure that our "navigation 
taxonomies" are grouping of concepts for application purpose (end user 
navigation/filtering), and should be better represented as Collections, 
using as needed nested collections. In the example quoted above, the 
"Label" and "Langue parlée" would correspond to nested collections. And 
we gain the ordering capacity.

But it raises some issues vs ConceptScheme.
 
1. Does a Concept have to belong to a ConceptScheme to be included in a 
Collection? Or may one define a Collection from scratch, without notion 
of ConceptScheme?
I ask because of the remark by Isaac, below, that "collections are aimed 
at structuring concepts *inside* a concept scheme".
2. Is it OK to have broader-narrower relationships declared inside a 
Collection? It seems OK vs conformance to the current draft, but is it a 
good pratice?
3. If a Collection is declared independently of any ConceptScheme, we 
have no way to declare the "top concepts" of a Collection.

Regarding 3, what about extending the "hasTopConcept" domain to 
"Collection"?

Bernard

Antoine Isaac a écrit :
>
> 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
>
>
>
>

-- 

*Bernard Vatant
*Knowledge Engineering
----------------------------------------------------
*Mondeca**
*3, cité Nollez 75018 Paris France
Web:    www.mondeca.com <http://www.mondeca.com>
----------------------------------------------------
Tel:       +33 (0) 871 488 459
Mail:     bernard.vatant@mondeca.com <mailto:bernard.vatant@mondeca.com>
Blog:    Leçons de Choses <http://mondeca.wordpress.com/>

Received on Tuesday, 26 February 2008 11:35:57 UTC