- From: Christophe Dupriez <christophe.dupriez@destin.be>
- Date: Fri, 30 Jan 2009 00:12:07 +0100
- To: "Houghton,Andrew" <houghtoa@oclc.org>
- CC: Ed Summers <ehs@pobox.com>, SWD Working Group <public-swd-wg@w3.org>, public-esw-thes@w3.org, Barbara B Tillett <btil@loc.gov>, Clay Redding <cred@loc.gov>
- Message-ID: <498237C7.2070100@destin.be>
We are here facing an usual problems: are we modeling something a pure abstraction or are we modeling for a given usage, for existing tools... Personaly, I think the need fits the notion of collection but I would change my minds depending of existing data, ergonomy of UI and tools capabilities. I would like to propose a similar (?) problem to the community. I have an authority list of authors, each one born in a country. For me, there is a scheme of countries (possibly in a hierarchy of political organisations and continents) and a scheme of authors. How are they linked? Collections of authors by countries? broadMatch between an author and its country? Additional RDFS attribute (born in)? I develop the tool (so I can do what I want but I am lazy/busy). The final goal is to add the countries to the author search indexes (so you can ask for a book written by Victor Hugo or ask for a book written somebody born in France). My feeling is that I should implement "broadMatch/narrowerMatch": * no "extension" to SKOS * no need to keep a coherence between countries concepts and collections of authors from these countries * broadMatch indicates that two different schemes are involved (broader does not) * BUT this may not be the intended use of broadMatch Thanks for any suggestions! Christophe Houghton,Andrew a écrit : > 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 Thursday, 29 January 2009 23:10:01 UTC