LISTSERV mailing list manager LISTSERV 16.0

Help for ID Archives


ID Archives

ID Archives


ID@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Monospaced Font

LISTSERV Archives

LISTSERV Archives

ID Home

ID Home

ID  November 2011

ID November 2011

Subject:

Re: Linking LCSH

From:

Owen Stephens <[log in to unmask]>

Reply-To:

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

Date:

Thu, 10 Nov 2011 11:32:21 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (210 lines)

Thanks for this answer Kevin

The examples you give of using MADS here are, as you note, not too far away from what I was asking for - and so look good to me. I think some documentation and 'best practice' suggesting this, or giving the outline as suggested here, would be a really useful resource for those working with LCSH in a linked data context.

Thanks again for this full and useful answer

Best wishes,

Owen

Owen Stephens
Owen Stephens Consulting
Web: http://www.ostephens.com
Email: [log in to unmask]
Telephone: 0121 288 6936

On 9 Nov 2011, at 22:55, Ford, Kevin wrote:

> Dear Owen,
>
> Thanks for writing.
>
>> As it has been added to the catalogue, I assume it is a valid heading,
>> so we check for a URI for this heading from id.loc.gov - but there
>> isn't one, because although it may be valid, it isn't authorised, and
>> so doesn't fall into the scope of the data published on id.loc.gov
> -- And there's the rub. ID provides identifiers for LCSH headings (single or pre-coordinated) for which there is a MARC record. It is basically possible to create an infinite number of perfectly-valid, pre-coordinated LC subject headings. I've started down this road- there are roughly 6.2 unique subject headings in the LC bibliographic dataset - but I don't know how it ends. It is a good thing to highlight, however, because it is a something that many do not necessarily consider when starting out with ID.LOC.GOV.
>
>> There are some parts of what we did that I suspect are open to
>> discussion as to their validity - for example, is it valid to apply the
>> URI http://id.loc.gov/authorities/sh85118587#concept (=Science--Study
>> and Teaching) when the original heading was Science--Study and
>> Teaching--Research.
> -- Yea, we had this debate too. Decided, in the end, to do identify each component separately.
>
>> I can see that MADS might offer this type of approach - but this seems
>> overly complex for what I'm looking to achieve - I don't need to
>> express an authority file, but rather relationships to existing
>> resources.
> -- Yes and no. Certainly no more difficult if you are already considering creating a local URI for a pre-coordinated LCSH that you can't match at ID. And, if you are already using ID URIs, there's been at least a tacit acceptance of the additonal data (whether in SKOS or MADS/RDF) since most of the resources at ID contain substantial information. In reality, however, very little is needed to express a pre-coordinated heading in MADS/RDF: a label and componentList are sufficient to capture your intent and meet your need. Using you local URI example:
>
> @prefix madsrdf: <http://www.loc.gov/mads/rdf/v1#>.
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
>
> <http://data.open.ac.uk/topic/library/science--study_and_teaching--research> madsrdf:authoritativeLabel "Science--Study and teaching--Research";
> madsrdf:componentList (<http://id.loc.gov/authorities/subjects/sh85118553> <http://id.loc.gov/authorities/subjects/sh2001008697> <http://id.loc.gov/authorities/subjects/sh2002006576>);
> a madsrdf:ComplexSubject.
>
> Currently the madsrdf:componentList property has a range of rdf:List. In a future update I anticipate the range of madsrdf:componentList will be an rdf:List OR rdf:Seq. This will simplify querying, but it does not significantly alter the construction (I've provided an RDF/XML serialization of the above example and the following example at the end of this email):
>
> <http://data.open.ac.uk/topic/library/science--study_and_teaching--research> madsrdf:authoritativeLabel "Science--Study and teaching--Research";
> madsrdf:componentList _:bnode1302373376;
> a madsrdf:ComplexSubject.
>
> _:bnode1302373376 rdf:_1 <http://id.loc.gov/authorities/subjects/sh85118553>;
> rdf:_2 <http://id.loc.gov/authorities/subjects/sh2001008697>;
> rdf:_3 <http://id.loc.gov/authorities/subjects/sh2002006576>;
> a rdf:Seq.
>
> For your troubles, you get the pre-formatted label *and* the component resources of the label. Naturally, it is possible to construct a label without representing it natively in the data, but it may be of benefit with regard to indexing and supplying the label reduces the need to perform look-ups. After all, when you query the resource of a single term heading, you're looking for its label. It seems logical to extend the same principle to pre-coordinated ones.
>
>> Hopefully I'm not saying anything very stupid ... thoughts/comments
>> welcome
> -- Absolutely and categorically, no. It's really very helpful for us to hear about *how* the data is being used and what challenges users face using the data. I've said it before on this list and I'll say it again: hearing these accounts, receiving questions, and getting feedback inform our priorities and service enhancements. Your account is very much welcome. Thanks again.
>
> Warmly,
>
> Kevin
>
>
> *Using an rdf:List*
> <rdf:RDF
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
> xmlns:madsrdf="http://www.loc.gov/mads/rdf/v1#">
>
> <madsrdf:ComplexSubject rdf:about="http://data.open.ac.uk/topic/library/science--study_and_teaching--research">
> <madsrdf:authoritativeLabel>Science--Study and teaching--Research</madsrdf:authoritativeLabel>
> <madsrdf:componentList rdf:parseType="Collection">
> <madsrdf:Topic rdf:about="http://id.loc.gov/authorities/subjects/sh85118553"/>
> <madsrdf:Topic rdf:about="http://id.loc.gov/authorities/subjects/sh2001008697"/>
> <madsrdf:Topic rdf:about="http://id.loc.gov/authorities/subjects/sh2002006576"/>
> </madsrdf:componentList>
> </madsrdf:ComplexSubject>
>
> </rdf:RDF>
>
> *Using an rdf:Seq*
> <rdf:RDF
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
> xmlns:madsrdf="http://www.loc.gov/mads/rdf/v1#">
>
> <madsrdf:ComplexSubject rdf:about="http://data.open.ac.uk/topic/library/science--study_and_teaching--research">
> <madsrdf:authoritativeLabel>Science--Study and teaching--Research</madsrdf:authoritativeLabel>
> <madsrdf:componentList>
> <rdf:Seq>
> <rdf:li rdf:resource="http://id.loc.gov/authorities/subjects/sh85118553"/>
> <rdf:li rdf:resource="http://id.loc.gov/authorities/subjects/sh2001008697"/>
> <rdf:li rdf:resource="http://id.loc.gov/authorities/subjects/sh2002006576"/>
> </rdf:Seq>
> </madsrdf:componentList>
> </madsrdf:ComplexSubject>
>
> </rdf:RDF>
>
>
>
>> -----Original Message-----
>> From: Ford, Kevin
>> Sent: Wednesday, November 09, 2011 4:50 PM
>> To: Ford, Kevin
>> Subject: RE: [ID.LOC.GOV] Linking LCSH
>>
>>
>>
>> From: Authorities and Vocabularies Service Discussion List
>> [mailto:[log in to unmask]] On Behalf Of Owen Stephens
>> Sent: Tuesday, November 08, 2011 2:37 PM
>> To: [log in to unmask]
>> Subject: [ID.LOC.GOV] Linking LCSH
>>
>> Earlier this year I worked on a project[1] to create Linked Data
>> representation of a small set of library resources at The Open
>> University in the UK. I've been meaning to write up some thoughts on
>> the issues we encountered in linking to the LCSH representations on
>> id.loc.gov, and have finally got round to it, and would be interested
>> in feedback from others on our experience and my thoughts/reflections -
>> and of course if I'm making any obvious mistakes in my interpretation.
>>
>> I presented some of these thoughts at a Linked Data and Libraries event
>> earlier this year - my slides and notes are
>> at http://www.slideshare.net/ostephens/linking-lcsh-and-other-
>> stuff from page 7 onwards.
>>
>> We were working from MARC21 records, and focussing on the 'topical'
>> subject headings. So, typically our starting data might look something
>> like:
>> 650 #0 $aScience$xStudy and Teaching$xResearch OR Science--Study and
>> Teaching--Research
>>
>> As it has been added to the catalogue, I assume it is a valid heading,
>> so we check for a URI for this heading from id.loc.gov - but there
>> isn't one, because although it may be valid, it isn't authorised, and
>> so doesn't fall into the scope of the data published on id.loc.gov
>>
>> We could at this point just stop, and not provide an external link -
>> but this seemed like a wasted opportunity - we wanted to provide
>> external links where possible, and in this case there are actually URIs
>> on id.loc.gov for parts of the subject heading, just not the whole
>> thing. So checking we can find URIs for the following:
>>
>> Science--Study and Teaching
>> = http://id.loc.gov/authorities/sh85118587#concept
>> Science (as Topical Term)
>> = http://id.loc.gov/authorities/sh85118553#concept ** Study and
>> Teaching (as a general subdivision)
>> = http://id.loc.gov/authorities/sh2001008697#concept
>> Research (as a general subdivision)
>> = http://id.loc.gov/authorities/sh2002006576#concept **
>>
>> We have all the components we need to build the equivalent of the
>> original 650 field but using URIs instead of textual strings - and it
>> seems a shame not to use these.
>>
>> In our project we decided to just allocate as many relevant URIs as we
>> could - and in order to preserve the full, but not authorised, LCSH we
>> also coined a local URI for this - you can see the results
>> at http://data.open.ac.uk/page/library/289148
>>
>> There are some parts of what we did that I suspect are open to
>> discussion as to their validity - for example, is it valid to apply the
>> URI http://id.loc.gov/authorities/sh85118587#concept (=Science--Study
>> and Teaching) when the original heading was Science--Study and
>> Teaching--Research. However, what I think is missing is a better way of
>> using the LCSH component parts to express the LCSH as linked data. My
>> first thoughts are that it might be possible to use a mechanism like
>> the Bibliographic Ontology BibO uses for lists of authors, which is to
>> have an 'authorList' as well as individual authors[2], which allows you
>> to specify and ordered list alongside its component parts.
>>
>> In this case you could do something like:
>> lcsh:headingList
>> ( <http://id.loc.gov/authorities/sh85118553#concept> <http://id.loc.gov
>> /authorities/sh2001008697#concept> <http://id.loc.gov/authorities/sh200
>> 2006576#concept>)
>>
>> This would allow full use of the URIs already published on id.loc.gov,
>> and offer more links from library data.
>>
>> I can see that MADS might offer this type of approach - but this seems
>> overly complex for what I'm looking to achieve - I don't need to
>> express an authority file, but rather relationships to existing
>> resources.
>>
>> Hopefully I'm not saying anything very stupid ... thoughts/comments
>> welcome
>>
>> 1. http://lucero-project.info/lb
>> 2. http://bibliontology.com/content/article
>> ** An aside - it isn't (or at least, wasn't) possible to search for
>> 'topical terms' separate to 'general subdivisions' so for headings like
>> 'Science' or 'Research' this creates a problem - it would be really
>> useful to be able to search for topical terms separate to general
>> subdivisions in order to identfy the correct URI
>>
>> Owen Stephens
>> Owen Stephens Consulting
>> Web: http://www.ostephens.com
>> Email: [log in to unmask]
>> Telephone: 0121 288 6936

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

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