W3C home > Mailing lists > Public > public-swd-wg@w3.org > January 2009

Re: use of skos:inScheme and rdf:type in SKOS modeling

From: Christophe Dupriez <christophe.dupriez@destin.be>
Date: Fri, 30 Jan 2009 09:08:02 +0100
Message-ID: <4982B562.1010106@destin.be>
To: Ed Summers <ehs@pobox.com>
CC: SWD Working Group <public-swd-wg@w3.org>, "public-esw-thes@w3.org" <public-esw-thes@w3.org>, Barbara B Tillett <btil@loc.gov>, Clay Redding <cred@loc.gov>
Rethinking to this:
* Collections are a good way to group unorganized, disperse individual 
concepts.
* Schemes and Hierarchies are providing a structure: if an attribute can 
be mainly deducted by the structure, it should be.

So, here, if concepts are inheriting their type from their broader 
(topics, geographics, time periods, corporations), may be the best is to 
put each types in different schemes (broader/narrower/related relations 
within one scheme and broadMatch/narrowMatch/relatedMatch between 
concepts in different schemes).

Have a nice day!

Christophe

Ed Summers a écrit :
> Hi All,
>
> I am trying to solicit some responses to a particular SKOS modeling
> question I have. I apologize in advance if similar questions have come
> up and been answered before.
>
> Some initial work [1] has been done to examine how the Library of
> Congress Subject Headings [2] can be represented as SKOS. Since the
> Répertoire d'autorité-matière encyclopédique et alphabétique
> unifiéshares (RAMEAU) [3] shares some lineage with LCSH, it is hoped
> that this effort could also inform a SKOS representation of RAMEAU as
> well.
>
> The LCSH vocabulary has different types of concepts within it:
> topical, geographic, chronological, personal names, corporate names
> ... to name a few. It is anticipated that use cases within the library
> community will require applications to be able to distinguish between
> the types of concepts. There's been some private discussion about the
> best way to use SKOS to achieve this granularity. The thought was that
> perhaps it would be better to have that discussion in the open.
>
> Solution A is to group them into sub concept schemes using
> skos:inScheme, while also keeping the concepts part of the larger LCSH
> concept scheme:
>
>  lcsh:sh85124200 a skos:Concept ;
>    skos:prefLabel "Sociology"@en ;
>    skos:inScheme lcsh:topicConceptScheme ;
>    skos:inScheme lcsh:conceptScheme .
>
>  lcsh:sh85056381 a skos:Concept ;
>    skos:prefLabel "Grand Canyon (Ariz.)" ;
>    skos:inScheme lcsh:geographicConceptScheme ;
>    skos:inScheme lcsh:conceptScheme .
>
> Solution B is to create extensions of skos:Concept such that:
>
>  lcsh:TopicalConcept rdfs:subClassOf skos:Concept .
>  lcsh:GeographicConcept rdfs:subClassOf skos:Concept .
>
>  lcsh:sh85124200 a lcsh:TopicalConcept ;
>    skos:prefLabel "Sociology"@en ;
>    skos:inScheme lcsh:conceptScheme .
>
>  lcsh:sh85056381 a lcsh:GeographicConcept ;
>    skos:prefLabel "Grand Canyon (Ariz.)" ;
>    skos:inScheme lcsh:conceptScheme .
>
> The discussion so far has centered around two issues.
>
> 1. A may result in better tool support since it does not require inferencing
> 2. B uses rdfs:type instead of skos:inScheme to indicate the type of a
> concept...which fits in better with RDF as it is deployed on the web.
>
> Perhaps there are more arguments in favor or against? One counter
> argument to 1 is that serializations of B could include asserted
> triples for tool convenience.
>
>  lcsh:sh85056381 a lcsh:GeographicConcept, skos:Concept ;
>    skos:prefLabel "Grand Canyon (Ariz.)" ;
>    skos:inScheme lcsh:conceptScheme .
>
> If you have a particular opinion about this your feedback would be most welcome.
>
> //Ed
>
> [1] http://dcpapers.dublincore.org/ojs/pubs/article/view/916
> [2] http://www.loc.gov/aba/cataloging/subject/
> [3] http://rameau.bnf.fr/
>
>
>
>   


Received on Friday, 30 January 2009 08:05:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 30 January 2009 08:05:55 GMT