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

Re: New use case ISO 3166 and its issues

From: Lourens van der Meij <lourens@cs.vu.nl>
Date: Tue, 29 Jan 2008 19:27:59 +0000
Message-ID: <479F7E3F.7090308@cs.vu.nl>
To: SKOS <public-esw-thes@w3.org>

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 

Lourens van der Meij
Received on Tuesday, 29 January 2008 18:25:24 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 13:32:09 UTC