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

Hi Andy, Christophe,

[First, a disclaimer: I was involved in the "private discussion", and strongly pushing solution B :-)]

To me solution C is not really practical, as it more-or-less implies that there is a shared vocabulaires of facets somewhere. We could say that MARC defines that, but I find it difficult to determine how actually MARC was indeed influenced by the LCSH situation. So having the "sub-concepts-types" or "sub-concept-schemes" or whatever in the lcsh: namespace is clearly ok.

Solution D is technically very similar to solution B. Only, it has the drawback of using skos:Collection, which I find not appropriate: collections will usually be much finer-grained. Is it useful defining a collection which includes more than half of a concept scheme?


Now, my 2 cents: note first that this topic was once approached on the SKOS list, when people discussed about things like "micro-thesauri" [1]. They (Johan) seem to naturally think of them as sub-concept-schemes, rather than some completely new entity. Note than in [1] Johan was actually more thinking of the micro-thesaurus to be concept-schemes, and less the all-encompassign vocabulary/domain.

But writing that I start to realize that the LCSH "beasts" at hand may not be fully similar to microthesauri, since they really have a strong facet flavor. So in the end the perfect solution would be to have a common pattern for facets, which we don't have. But would the facet specialists on the list opt for pattern A over pattern B, given that no entirely appropriate solution can be found for now?

Best,

Antoine

[1] http://lists.w3.org/Archives/Public/public-esw-thes/2008Dec/0021.html

> There is probably another approach, Solution C, that you could use which would be to create a controlled vocabulary of aspects (facets?) in SKOS, e.g., topical, geographic, chronological, personal names, corporate names, etc. and then use skos:broadMatch to link to them from lcsh, lcshac, naf, lctgm, gmgpc, etc. and would also allow other vocabulary maintainers to assert that their concepts are part of a broader scope.
> 
> The downside to making lcsh:genreConceptScheme is that its in the lcsh namespace.  So would you be proposing the same solution for naf, lctgm, gmgpc, etc., e.g., lctgm:genreConceptScheme and gmgpc:genreConceptScheme?  These aspects (facets?) don't seem like concept schemes, e.g., versions or editions of the vocabulary. 
> 
> Solution B seems to me to be better modeled than Solution A, but you could also achieve the same thing without subclassing skos:Concept and use dc:type with a controlled list of names, e.g., genre, personal name, topical, etc. which again could be used by other vocabulary maintainers, but this mimics Solution C without anybody being able to assert that their concepts are part of a broader scope.
> 
> Yet another approach, Solution D, would be to use collections and assert that a concept is in a particular collection, e.g., topical, geographic, chronological, etc.  From the SKOS reference: "Collections are useful where a group of concepts shares something in common, and it is convenient to group them under a common label, or where some concepts can be placed in a meaningful order."  Seems to me that the 1XX tags in MARC-21 fit the definition of collections.
> 
> Just my 2 cents, Andy.
> 
>> -----Original Message-----
>> From: public-swd-wg-request@w3.org [mailto:public-swd-wg-
>> request@w3.org] On Behalf Of Ed Summers
>> Sent: Thursday, January 29, 2009 11:44 AM
>> To: SWD Working Group; public-esw-thes@w3.org
>> Cc: Barbara B Tillett; Clay Redding
>> Subject: use of skos:inScheme and rdf:type in SKOS modeling
>>
>>
>> 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 09:52:22 UTC