Re: LCSH and Linked Data

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: owen@ostephens.com <mailto:owen@ostephens.com>
>>
>
> --
> Thomas Meehan
> Head of Current Cataloguing
> Library Services
> University College London
> Gower Street
> London
> WC1E 6BT
>
> t.meehan@ucl.ac.uk
>
>


-- 
Owen Stephens
Owen Stephens Consulting
Web: http://www.ostephens.com
Email: owen@ostephens.com