Yeah, that's a really good point, makes sense.

But if we don't have any accessible means of mapping from LCC to LCSH... 
   then it's not an option. So do nothing, or do something else?

Hmm, what if you displayed the LCC headings in the shelf browse, _and_ 
included them in the index as searchable, to meet the "if you display 
it, the user should be able to search it" rule.  But of course you don't 
stop indexing LCSH either -- LCC is a bad 'entry vocabulary', we don't 
expect anyone to use it 'naturally' -- but if they see it on the shelf 
browse and then want to use it to perform searches, at least they can.

It would certainly be better if we had one vocabulary we could use for 
all things that serves all purposes, but it's just not the current 
environment. Even if you did have an accessible means of mapping from 
LCC to LCSH (I don't think anyone other than maybe OCLC does; and I am 
not sure if even OCLC shares it with members in a flexible machine 
readable way, unless maybe the Terminologies Service does), even if you 
did have that... I wonder, if LCC works better hieararchically for a 
shelf browse label, if you might still want to show both LCC and LCSH as 
labels in a shelf browse.

> Quoting Jonathan Rochkind <[log in to unmask]>:
>
>> Ah, but we're not talking about "entry vocabulary", we're talking 
>> about labelling shelf ranges.
>
> At my job at UC we had a rule: if you display it, the user should be 
> able to search it and get those same results. If you display one set 
> of strings as a shelf label, and a different set of strings are 
> required for retrieval, that's going to be confusing. Ideally users 
> should be able to search within the classification scheme, or to 
> navigate around, but we don't have that ability. The point of my blog 
> post is that we have separate systems and it can't be clear to users 
> how they interact. (I'm not even sure they do interact cleanly.) The 
> only way users can make sense of things is by extrapolating from what 
> we display to them. I worry that seeing inside LCC, while being given 
> only LCSH to search on, isn't going to be clear. While LCSH loses a 
> lot of the structure of LCC, at least users are seeing what they would 
> need to search on in the catalog to get those same results.
>
> kc
>
>>
>> But I agree that the headings for LCC will be less user friendly than 
>> LCSH.  If there was a way to get LCC-to-LCSH mappings in an easily 
>> usable way without paying tens of thousands of dollars, that would be 
>> clever. (I'm not sure there's a way to get them even if you DO pay 
>> millions of dollars).
>>
>> So I was suggesting using the LCC headings themselves as a more 
>> feasible alternate plan, is all. I agree it would be insufficient if 
>> we needed an "entry vocabulary".  But just for labelling shelf ranges 
>> on display, I think it's probably not worse than nothing.
>>
>> Of course, that's up to the implementer, what's better than nothing.
>>
>>> Quoting Jonathan Rochkind <[log in to unmask]>:
>>>
>>>
>>>> For #2, you can provide a useful topical/subject type heading via 
>>>> much simpler and more feasible solutions than mapping to LCSH.  For 
>>>> #2, you don't need a map to LCSH, you need the LCC schedules with 
>>>> descriptions of what each range of LCC call numbers is for, in 
>>>> machine-readable form.
>>>
>>> I would give the opposite advice. LCC will have fewer pre-composed 
>>> headings than LCSH at id.loc.gov, and the terminology associated 
>>> with the numbers in digital LCC will be less user-centric than the 
>>> LCSH subject headings. cf my most recent blog post:
>>>
>>>   http://kcoyle.blogspot.com/2011/10/relativ-index.html
>>>
>>> There isn't any entry vocabulary for users other than LCSH -- which 
>>> isn't really entry vocabulary to LCC and is definitely NOT entry 
>>> vocabulary to DDC.
>>>
>>> kc
>>>
>>>>
>>>>> Thanks everybody!
>>>>>
>>>>> this is useful for a couple of purposes
>>>>> 1) sometimes we have records that have call numbers, but no 
>>>>> subject headings.
>>>>> this would be useful to provide those.
>>>>> 2) i'm thinking of providing a 'subject heading' label to our 
>>>>> shelf browser --
>>>>> so users see, in addition to the callnumber -- what the call 
>>>>> number means.
>>>>>
>>>>> thanks again!
>>>>> rick
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Oct 18, 2011 at 2:33 PM, Jonathan 
>>>>> Rochkind<[log in to unmask]>  wrote:
>>>>>> Anyone know if the OCLC Terminology Service provides such a 
>>>>>> mapping? The
>>>>>> Terminology Service may be free if you are already an OCLC 
>>>>>> cataloging
>>>>>> member.
>>>>>>
>>>>>> At one point I think I saw an absolutely free open access machine 
>>>>>> readable
>>>>>> mapping somewhere, that was made at some point in the past and no 
>>>>>> longer
>>>>>> updated... but I cant' remember where I saw that even.
>>>>>>
>>>>>>> LC's Classification Web provides a mapping from LC 
>>>>>>> classifications to
>>>>>>> LC subject headings.  There is a manual web interface, used 
>>>>>>> mainly by
>>>>>>> catalogers, which requires a subscription:
>>>>>>>    http://classificationweb.net/
>>>>>>>
>>>>>>> I don't know if it has any kind of API.
>>>>>>>
>>>>>>> Keith
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Oct 18, 2011 at 2:11 PM, Enrico Silterra<[log in to unmask]>
>>>>>>> wrote:
>>>>>>>> is there any way to go from a LC call number,
>>>>>>>> like DF853  to http://id.loc.gov/authorities/subjects/sh85057107
>>>>>>>> via some sort of api? opensearch?
>>>>>>>> thanks,
>>>>>>>> rick
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Enrico Silterra Software Engineer
>>>>>>>> 501 Olin Library Cornell University Ithaca NY 14853
>>>>>>>> Voice: 607-255-6851 Fax:     607-255-6110 E-mail: 
>>>>>>>> [log in to unmask]
>>>>>>>> http://www.library.cornell.edu/dlit
>>>>>>>> "Out of the crooked timber of humanity no straight thing was 
>>>>>>>> ever made"
>>>>>>>> CONFIDENTIALITY NOTE
>>>>>>>> The information transmitted, including attachments, is intended 
>>>>>>>> only
>>>>>>>> for the person or entity to which it is addressed and may contain
>>>>>>>> confidential and/or privileged material. Any review, 
>>>>>>>> retransmission,
>>>>>>>> dissemination or other use of, or taking of any action in reliance
>>>>>>>> upon, this information by persons or entities other than the 
>>>>>>>> intended
>>>>>>>> recipient is prohibited. If you received this in error, please 
>>>>>>>> contact
>>>>>>>> the sender and destroy any copies of this document.
>>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>