W3C home > Mailing lists > Public > public-esw-thes@w3.org > February 2009

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

From: Alistair Miles <alistair.miles@zoo.ox.ac.uk>
Date: Mon, 2 Feb 2009 08:53:04 +0000
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>
Message-ID: <20090202085304.GB8750@skiathos>

Hi Ed,

If you use solution A (skos:inScheme) I would anticipate that a
generic SKOS browser would recognise that there are a number of
different schemes described in the data, and allow you to browse,
search and do lint-like sanity checking on each independently.

If you use solution B (rdf:type) then you have classes declared which
can be used in property axioms, e.g. domain or range assertions or
other restrictions. This might be useful where you want to document
usage and/or semantics for a set of metadata elements.

Not knowing the requirements in detail, I think I would do both A + B,
with your additional workaround for B to avoid inferencing (adding the
triple X rdf:type skos:Concept). This should give you a platform to
explore the options.

For practical purposes this probably won't help, but you could also
make an assertion that formalises the fact that both A and B are
different ways of saying the same thing, e.g....

lcsh:TopicalConcept rdf:type owl:Class ;
  rdfs:subClassOf skos:Concept ;
  rdfs:subClassOf [
    rdf:type owl:Restriction ;
    owl:onProperty skos:inScheme ;
    owl:hasValue lcsh:topicConceptScheme ;
  ] ;
.

...which supports an inference from B to A. 

Actually, thinking about that again, if they really are different ways
to say exactly the same thing, you'd probably want to assert...

lcsh:TopicalConcept rdf:type owl:Class ;
  owl:intersectionOf (
    skos:Concept ,
    [ 
      rdf:type owl:Restriction ; 
      owl:onProperty skos:inScheme ;
      owl:hasValue lcsh:topicConceptScheme ;
    ]
  ) ;
.

...which I think supports an inference from B to A and from A to B,
although you might want to double-check my OWL.

Cheers,

Al


On Thu, Jan 29, 2009 at 11:43:31AM -0500, Ed Summers wrote:
> 
> 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/
> 

-- 
Alistair Miles
Senior Computing Officer
Image Bioinformatics Research Group
Department of Zoology
The Tinbergen Building
University of Oxford
South Parks Road
Oxford
OX1 3PS
United Kingdom
Web: http://purl.org/net/aliman
Email: alistair.miles@zoo.ox.ac.uk
Tel: +44 (0)1865 281993
Received on Monday, 2 February 2009 08:53:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:39:03 GMT