LISTSERV mailing list manager LISTSERV 16.0

Help for ID Archives


ID Archives

ID Archives


[email protected]


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

ID Home

ID Home

ID  May 2009

ID May 2009

Subject:

Re: dashes

From:

Karen Coyle <[log in to unmask]>

Reply-To:

Authorities and Vocabularies Service Discussion List <[log in to unmask]>

Date:

Wed, 20 May 2009 12:49:52 -0700

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (134 lines)

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

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

February 2024
January 2024
March 2023
January 2023
July 2022
June 2022
May 2022
April 2022
February 2022
November 2021
September 2021
August 2021
July 2021
June 2021
May 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
March 2020
February 2020
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
April 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2017
July 2016
February 2016
January 2016
December 2015
November 2015
September 2015
August 2015
June 2015
March 2015
February 2015
October 2014
August 2014
July 2014
June 2014
March 2014
January 2014
November 2013
September 2013
August 2013
June 2013
May 2013
April 2013
March 2013
December 2012
November 2012
October 2012
September 2012
August 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
April 2011
March 2011
February 2011
January 2011
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
November 2009
June 2009
May 2009

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager