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

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 12:49:55 UTC