Thanks to Jon Phipps for translating my attempts to communicate into
SemWebGeek, a language I read but, alas, do not speak fluently.
I must say that I am taking a new and more open look at FAST, which now
seems to provide some solutions to the problems that LCSH poses.
kc
Jon Phipps wrote:
> On Wed, May 20, 2009 at 9:31 AM, Ed Summers <[log in to unmask]> wrote:
>
>> ... the software developer in me would like to see the id.loc.gov effort stay focused on how to enable the use of LCSH outside the bounds of the service itself--rather than listening to the siren song of building a pristine model of LCSH. As Simon has described, LCSH itself is far from perfect [2].
>>
>>
>
> I don't disagree with Ed at all, but I think that there's some
> potential to dramatically increase the utility of the LCSH RDF, and
> that at least some of it seems to me (perhaps naively) to be
> relatively low-hanging fruit. That said, It seems to me that there are
> several memes at play in this conversation (excerpted from a blog post
> I'm putting up in a few minutes):
>
> LCSH and SKOS
> As both Karen and Ed have pointed out, LCSH is more than just a simple
> thesaurus. It's also a set of instructions for building structured
> strings in a way that's highly meaningful for ordering physical cards
> in a physical catalog. In addition, each string component has specific
> semantics related to its position in the string, so it's possible, if
> everyone knows and agrees on the rules, to parse the string and derive
> the semantics of each individual component. The result is a
> pre-coordinated index string. [1]
>
> These stand-alone pre-coordinated strings are perhaps much less
> meaningful in the context of LOD, but this certainly doesn't apply to
> the components. I think what Karen is pointing out is that, while it's
> wonderful to have a subset of all of the components that can be used
> to construct LC Subject Headings published as LOD, and it's fine to
> have the precoordinated subject headings, there's enough missing
> information from the description of those headings to significantly
> reduce the overall value.
>
> As I read it, she's wishing for the missing semantics to be published
> as part of the LCSH linked data, and hoping that LC doesn't rest on
> its well-earned laurels and call it a day. What's needed is a way to
> say "Here's a pre-coordinated string expressed as a skos:prefLabel, it
> has an identity, and here are its semantic components."
>
> So...
>
> "Italy--History--1492-1559--Fiction"
>
> ...is currently expressed in
> http://id.loc.gov/authorities/sh2008115565#concept as...
>
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix skos: <http://www.w3.org/2004/02/skos/core#> .
> @prefix terms: <http://purl.org/dc/terms/> .
> @prefix owl: <http://www.w3.org/2002/07/owl#> .
>
> <http://id.loc.gov/authorities/sh2008115565#concept>
> skos:prefLabel "Italy--History--1492-1559--Fiction"@en ;
> rdf:type ns0:Concept ;
> terms:modified
> "2008-03-15T08:10:27-04:00"^^<http://www.w3.org/2001/XMLSchema#dateTime>
> ;
> terms:created
> "2008-03-14T00:00:00-04:00"^^<http://www.w3.org/2001/XMLSchema#dateTime>
> ;
> owl:sameAs <info:lc/authorities/sh2008115565> ;
> skos:inScheme
> <http://id.loc.gov/authorities#geographicNames> ,
> <http://id.loc.gov/authorities#conceptScheme> ;
> terms:source "Work cat.: The family, 2001"@en .
>
> ...and has a 151 field expressed in the authority file [4] as...
>
> 151 __* |a *Italy* |x *History* |y *1492-1559* |v *Fiction
>
> ...which would allow the inclusion of the _additional_ minimal semantics of...
> (note the use of a fictional 'loc_id' vocabulary)
>
> <http://id.loc.gov/authorities/sh2008115565#concept>
> loc_id:geographicName "Italy"
> loc_id:type "Geographic Name" #note that this is also expressed as
> a skos:inScheme property
> loc_id:topicalDivision "History"
> loc_id:chronologicalSubdivision "1492-1559"
> loc_id:formSubdivision "Fiction"
>
> ...and this might also be expressed as...
>
> <http://id.loc.gov/authorities/sh2008115565#concept>
> loc_id:geographicName http://id.loc.gov/authorities/n79021783
> loc_id:type http://id.loc.gov/authorities/sh2002011429
> loc_id:topicalDivision http://id.loc.gov/authorities/sh85061212
> loc_id:formSubdivision http://id.loc.gov/authorities/sh85048050
> dcterms:temporal "1492-1559"
> dcterms:spatial http://sws.geonames.org/3175395/
> dcterms:spatial http://id.loc.gov/authorities/n79021783
>
> Making sure that those strings in the first example are expressed as
> resource identifiers as they are in the second example is also
> something that I think Karen is asking for. (BTW, The ability to
> lookup a specific label by URL at id.loc.gov/authorities is really
> useful)
>
> I should point out that Ed, Antoine, Clay, and Dan's DC2008 paper [5]
> detailing the conversion of LCSH to SKOS goes into some detail (see
> section 2.7) about the LCSH to SKOS mapping, but doesn't seem to
> directly address the issue that Karen is raising about mapping the
> explicit semantics of the subfields.
>
> Best,
> —Jon Phipps
>
> [1] http://www.willpowerinfo.co.uk/glossary.htm
> [2] http://dublincore.org/documents/abstract-model/
> [3] http://aa.usno.navy.mil/data/docs/JulianDate.php
> [4] http://bit.ly/lc_auth
> [5] http://arxiv.org/pdf/0805.2855v3
>
>
>
--
-----------------------------------
Karen Coyle / Digital Library Consultant
[log in to unmask] http://www.kcoyle.net
ph.: 510-540-7596 skype: kcoylenet
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------
|