Re: New use case ISO 3166 and its issues

Jakob Voss wrote:
> GROUPING OF CONCEPT SCHEMES (ISSUE-??): ISO 3166 consists of different
> parts that build opon another. ISSUE-33 solved encoding of concept
> hierarchies with skos:Collection and skos:member - but what about
> nesting Concept Schemes? Several schemes contain parts that can also
> be used independently. The best solution I could found so far is to make
> skos:ConceptScheme a subclass of skos:Collection so you can say:
>
> iso3166-1: a skos:ConceptScheme .
> iso3166-2: a skos:ConceptScheme .
>
> iso3166: a skos:ConceptScheme ;
>   skos:member iso3166-1: ;
>   skos:member iso3166-2: .
>   
If I understand Jakob Voss correctly, we also could use some SKOS based 
solution for grouping of ConceptSchemes too:
 
We have been working on a vocabulary service based on SKOS. Because 
often within one "file" or contribution,
or vocabulary, a set of related ConceptSchemes is described, we needed 
some grouping of Conceptschemes into
groups. Especially when a repository starts to contain lots of 
vocabularies some subgrouping
of ConceptSchemes is needed (:for retrieval. Of course a partially 
satisfying solution for us would be to say that a ConceptScheme is a 
"document" and therefore we could make the ConceptSchemes accessible 
through SKOS annotation using skos:subject of some SKOS hierarchy of 
ConceptSchemes. ).

A specific SKOS standard solution could be useful.

But Jakobs proposal seems to suggest that the group of ConceptSchemes is 
yet another ConceptScheme (iso-3166),
itself containing  no skos:Concepts, i.e. not exists X: X skos:inScheme 
iso-3166.

Lourens van der Meij
lourens@cs.vu.nl
http://stitch.cs.vu.nl

Received on Tuesday, 29 January 2008 18:25:24 UTC