I'm working on it. blog post soon. but it's not easy. - kc
Lundgren,Jimmie Harrell wrote:
> Hi Karen,
> Maybe it would be helpful to elaborate a little on what you perceive that we need. Who is we? Catalogers or users or both? Constructing a subject string, (which in my mind is not multiple concepts but a single concept that takes multiple words to express), is different from using it to bring together like works in a catalog. What context are you addressing here? I'd like to try to understand this better. I know I haven't carefully studied every posting, but neither have many of the other readers and it is all to often that we make assumptions about what someone means that are a bit off. I know that you really care about users and access so you're on my side on that issue 100%. I also feel you have a vision about how things can be more helpful that is reflected in your impatience with various imperfections of the way things are now. I'd like to encourage you to reveal more of that vision to us, please.
>
> Thanks and have a great day,
> Jimmie
>
> -----Original Message-----
> From: Next generation catalogs for libraries [mailto:NGC4LIB_at_LISTSERV.ND.EDU] On Behalf Of Karen Coyle
> Sent: Tuesday, May 19, 2009 9:40 AM
> To: NGC4LIB_at_LISTSERV.ND.EDU
> Subject: Re: [NGC4LIB] Discussion of id.loc.gov
>
> Ross, there's another problem. Many of the subheadings are themselves
> members of controlled lists. Alternate terms for those subheadings are
> given where the controlled list is defined. Without a separation into
> the logical parts, there isn't a linked data way to associate the term
> as used in the subject heading with the list from which it came.
>
> I'll give some examples soon, but quite honestly I don't think that
> treating the main heading and subheadings as an undifferentiated string
> is going to give us what we need. Well, not what I think we need.
>
> kc
>
> Ross Singer wrote:
>
>> On Mon, May 18, 2009 at 5:40 PM, Weinheimer Jim <j.weinheimer_at_aur.edu> wrote:
>>
>>
>>
>>> Agreed. But the SKOS headings put out in id.loc.gov lack this subfield information, and is exactly the point that I (and I think Karen) were trying to make. If the subfields were in there, we would have no problem at all, but as it is, while we might be able to break the strings at the hyphens, we could not recreate the semantics, i.e. the subfields v,w,x,z. At least, not without a lot of work.
>>>
>>>
>>>
>> But the SKOS has not replaced the MARC. The prefLabel is just that, a
>> human readable label. Our machines should not be trying to bust it
>> apart and infer meaning in it, since that's the whole point of the
>> URI.
>>
>> You would instead be adding other assertions to the URI (probably
>> through a secondary vocabulary, I suppose, since SKOS can only deal
>> with NT/BT/RT) to which you can layer in the complexities of LCSH.
>>
>> This way, anybody (library and, more importantly, non-library
>> applications) can use the URIs. People who don't understand or care
>> about the stuff we apparently can't figure out very well /ourselves/,
>> will have SKOS and a pretty simple thesaurus of related concepts.
>>
>> Libraries, armed with knowledge of this other, LCSH-specific
>> vocabulary (I don't know of any other data-structures that mimic LCSH)
>> will have the URIs, the SKOS for the obvious relationships and the
>> LCSH thing for the less so (although, possibly more machine usable
>> than they /ever/ have been).
>>
>> Everybody wins.
>>
>> -Ross.
>>
>>
>>
>>
>
>
>
--
-----------------------------------
Karen Coyle / Digital Library Consultant
kcoyle@kcoyle.net http://www.kcoyle.net
ph.: 510-540-7596 skype: kcoylenet
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------
Received on Tue May 19 2009 - 10:38:54 EDT