After having done numerous matching and mapping projects, there are some issues that you will face with your strategy, assuming I understand it correctly. Trying to match a heading starting at the left most subfield and working forward will not necessarily produce correct results when matching against the LCSH authority file. Using your example:
650 _0 $a Education $z England $x Finance
is a good example of why processing the heading starting at the left will not necessarily produce the correct results. Assuming I understand your proposal you would first search for:
150 __ $a Education
and find the heading with LCCN sh85040989. Next you would look for:
181 __ $z England
and you would NOT find this heading in LCSH. This is issue one. Unfortunately, LC does not create 181 in LCSH (actually I think there are some, but not if it’s a name), instead they create a 781 in the name authority record. So to find the corresponding $z England we need to go to the name authority record 150 England with LCCN n82068148. Currently under id.loc.gov you will not find name authority records, but you can find them at viaf.org. The second issue using your example is that you want to find the “longest” matching heading. While the pieces parts are there, so is the enumerated authority heading:
150 __ $a Education $z England
as LCCN sh2008102746. So your heading is actually composed of the enumerated headings:
sh2008102746 150 __ $a Education $z England
sh2002007885 180 __ $x Finance
and not the separate headings:
sh85040989 150 __ $a Education
n82068148 150 __ $a England
sh2002007885 180 __ $x Finance
Although one could argue that either analysis is correct depending upon what you are trying to accomplish.
The matching algorithm I have used in the past contains two routines. The first f(a) will accept a heading as a parameter, scrub the heading, e.g., remove unnecessary subfield like $0, $3, $6, $8, etc. and do any other pre-processing necessary on the heading, then call the second function f(b). The f(b) function accepts a heading as a parameter and recursively calls itself until it builds up the list LCCNs that comprise the heading. It first looks for the given heading when it doesn’t find it, it removes the *last* subfield and recursively calls itself, otherwise it appends the found LCCN to the returned list and exits. This strategy will find the longest match. The headings are search against an augmented LCSH database where the 781 name authority records have been transformed into 181 records keeping the LCCN of the name authority record. Not ideal, but it generally works well. Adjust algorithm per need.
Hope this helps, Andy.
From: [log in to unmask] [mailto:[log in to unmask]] On Behalf Of Owen Stephens
Sent: Thursday, April 07, 2011 08:11
To: Thomas Meehan
Cc: Code for Libraries; public-lld; [log in to unmask]
Subject: Re: LCSH and Linked Data
Importance: Low
Thanks Tom - very helpful
Perhaps this suggests that rather using an order we should check combinations while preserving the order of the original 650 field (I assume this should in theory be correct always - or at least done to the best of the cataloguers knowledge)?
So for:
650 _0 $$a Education $$z England $$x Finance.
check:
Education
England (subdiv)
Finance (subdiv)
Education--England
Education--Finance
Education--England--Finance
While for 650 _0 $$a Education $$x Economic aspects $$z England we check
Education
Economic aspects (subdiv)
England (subdiv)
Education--Economic aspects
Education--England
Education--Economic aspects--England
- It is possible for other orders in special circumstances, e.g. with language dictionaries which can go something like:
650 _0 $$a English language $$v Dictionaries $$x Albanian.
This possiblity would also covered by preserving the order - check:
English Language
Dictionaries (subdiv)
Albanian (subdiv)
English Language--Dictionaries
English Language--Albanian
English Language--Dictionaries-Albanian
Creating possibly invalid headings isn't necessarily a problem - as we won't get a match on id.loc.gov anyway. (Instinctively English Language--Albanian doesn't feel right)
- Some of these are repeatable, so you can have too $$vs following each other (e.g. Biography--Dictionaries); two $$zs (very common), as in Education--England--London; two $xs (e.g. Biography--History and criticism).
OK - that's fine, we can use each individually and in combination for any repeated headings I think
- I'm not I've ever come across a lot of $$bs in 650s. Do you have a lot of them in the database?
Hadn't checked until you asked! We have 1 in the dataset in question (c.30k records) :)
I'm not sure how possible it would be to come up with a definitive list of (reasonable) possible combinations.
You are probably right - but I'm not too bothered about aiming at 'definitive' at this stage anyway - but I do want to get something relatively functional/useful
Tom
Thomas Meehan
Head of Current Cataloguing
University College London Library Services
Owen Stephens wrote:
We are working on converting some MARC library records to RDF, and looking at how we handle links to LCSH (id.loc.gov <http://id.loc.gov>) - and I'm looking for feedback on how we are proposing to do this...
I'm not 100% confident about the approach, and to some extent I'm trying to work around the nature of how LCSH interacts with RDF at the moment I guess... but here goes - I would very much appreciate feedback/criticism/being told why what I'm proposing is wrong:
I guess what I want to do is preserve aspects of the faceted nature of LCSH in a useful way, give useful links back to id.loc.gov <http://id.loc.gov> where possible, and give access to a wide range of facets on which the data set could be queried. Because of this I'm proposing not just expressing the whole of the 650 field as a LCSH and checking for it's existence on id.loc.gov <http://id.loc.gov>, but also checking for various combinations of topical term and subdivisions from the 650 field. So for any 650 field I'm proposing we should check on id.loc.gov <http://id.loc.gov> for labels matching:
check(650$$a) --> topical term
check(650$$b) --> topical term
check(650$$v) --> Form subdivision
check(650$$x) --> General subdivision
check(650$$y) --> Chronological subdivision
check(650$$z) --> Geographic subdivision
Then using whichever elements exist (all as topical terms):
Check(650$$a--650$$b)
Check(650$$a--650$$v)
Check(650$$a--650$$x)
Check(650$$a--650$$y)
Check(650$$a--650$$z)
Check(650$$a--650$$b--650$$v)
Check(650$$a--650$$b--650$$x)
Check(650$$a--650$$b--650$$y)
Check(650$$a--650$$b--650$$z)
Check(650$$a--650$$b--650$$x--650$$v)
Check(650$$a--650$$b--650$$x--650$$y)
Check(650$$a--650$$b--650$$x--650$$z)
Check(650$$a--650$$b--650$$x--650$$z--650$$v)
Check(650$$a--650$$b--650$$x--650$$z--650$$y)
Check(650$$a--650$$b--650$$x--650$$z--650$$y--650$$v)
As an example given:
650 00 $$aPopular music$$xHistory$$y20th century
We would be checking id.loc.gov <http://id.loc.gov> for
'Popular music' as a topical term (http://id.loc.gov/authorities/sh85088865)
'History' as a general subdivision (http://id.loc.gov/authorities/sh99005024)
'20th century' as a chronological subdivision ( http://id.loc.gov/authorities/sh2002012476)
'Popular music--History and criticism' as a topical term (http://id.loc.gov/authorities/sh2008109787)
'Popular music--20th century' as a topical term (not authorised)
'Popular music--History and criticism--20th century' as a topical term (not authorised)
And expressing all matches in our RDF.
My understanding of LCSH isn't what it might be - but the ordering of terms in the combined string checking is based on what I understand to be the usual order - is this correct, and should we be checking for alternative orderings?
Thanks
Owen
--
Owen Stephens
Owen Stephens Consulting
Web: http://www.ostephens.com
Email: [log in to unmask] <mailto:[log in to unmask]>
--
Thomas Meehan
Head of Current Cataloguing
Library Services
University College London
Gower Street
London
WC1E 6BT
[log in to unmask]
--
Owen Stephens
Owen Stephens Consulting
Web: http://www.ostephens.com
Email: [log in to unmask]
|
