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: public-lld-requ...@w3.org [mailto:public-lld-requ...@w3.org] On Behalf Of Owen Stephens Sent: Thursday, April 07, 2011 08:11 To: Thomas Meehan Cc: Code for Libraries; public-lld; f.zabl...@open.ac.uk 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: o...@ostephens.com <mailto:o...@ostephens.com> -- Thomas Meehan Head of Current Cataloguing Library Services University College London Gower Street London WC1E 6BT t.mee...@ucl.ac.uk -- Owen Stephens Owen Stephens Consulting Web: http://www.ostephens.com Email: o...@ostephens.com
