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

Hi Joachim,

I think I buy your cent :-) This sounds a good practice: extending the SKOS model when there is a specific type of KOS to manage properly (and thus a finer representation model is required), and not changing it when it's rather a matter of data. 

We indeed have keep in mind the following:
- solution A amounts to creating an extension to SKOS (to use more frightening words, an ontology ;-) for each vocabulary with sub-vocabularies/facets.
- solution B just re-uses the existing SKOS ontology, and represents the different facets at the data level, not the schema/ontology level.

As you say, both can be used orthogonally. But keeping in mind their respective modelling levels: I can for instance extend the skos vocabulary with a mySkos:Facet class (as a subclass of skos:ConceptScheme, or not) but the different facets vocabulaires are then introduced at the instance level. 

Of course one can still use solution A. But it ought to be pursued only if there was some more representational features added to the new types of concepts. For instance, if a "birth date note" property was allowed to describe only person-concepts. Which is a significant shift compared to trying to use SKOS as it is...

Cheers,

Antoine


> Sometimes you may even need both solutions, for different purposes: In my case, the descriptors of the thesaurus at hand (STW) are organized within a taxonomy. Using stw:Descriptor and stw:Thsys as subclasses of skos:Concept (solution B) seemed to be quite natural, and allowes to check for additional constraints (eg. each Thsys must have a notation, no Thys may be narrower to a Descriptor, etc.).
> 
> Some day, when a differentiation in geographical, topical etc. facets may be required, I would gladly use solution A additionally (and orthogonally). I think, this wouldn't work the other way arround. (just another cent ...)
> 
> Cheers, Joachim
> 
>> -----Ursprüngliche Nachricht-----
>> Von: public-esw-thes-request@w3.org 
>> [mailto:public-esw-thes-request@w3.org] Im Auftrag von Antoine Isaac
>> Gesendet: Freitag, 30. Januar 2009 10:52
>> An: Houghton,Andrew
>> Cc: Ed Summers; SWD Working Group; public-esw-thes@w3.org; 
>> Barbara B Tillett; Clay Redding
>> Betreff: 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 13:12:05 UTC