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

Hi Christophe,

> 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).

As these relations between different parts of the vocabularies are defined just the same way as the intra-scheme ones, I think using the standard relations is just as good. And do not forget that in all case there is an overarching LCSH concept scheme, so you can say that the concepts are in the same scheme, even though they are in different sub-schemes.

Cheers,

Antoine

> 
> 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 09:59:35 UTC