Re: FRBR WEMI and identifiers

From: Jon Phipps <jonphipps_at_nyob>
Date: Thu, 12 Nov 2009 17:27:00 -0500
To: NGC4LIB_at_LISTSERV.ND.EDU
Karen,

I think that lcsh has a particular problem in that the data was starting to
become widely used, as linked data, when the original site was abruptly shut
down. See the comments:
http://lcsh.info/comments1.html

The current id.loc.gov site took quite a while to bring up and in the
interim a tremendous amount of credibility was lost, particularly
internationally. People who had started using the data were left in the
cold, and I for one would be very reluctant to trust any aspect of my system
to that particular dependency again.

Even if the data was 'out there', if it's not reliable, it's just a toy.

As for some of the things we're doing with the RDA vocabularies, it's not
really 'in spite of' RDA. RDA's simultaneous backward-looking,
forward-looking viewpoint provides an opportunity for us to explore the
opportunities presented by that orientation, and maybe provide some guidance
to folks looking to integrate closed-world library data silos with the
open-world, on both sides of that fence.

--Jon

On Thu, Nov 12, 2009 at 5:10 PM, Karen Coyle <lists_at_kcoyle.net> wrote:

> I think that among other things we're struggling with some terminology
> issues... "linked data" is a bit of a misnomer -- it doesn't mean that the
> data *is* linked, it means it is in a format that could be used for semantic
> web linking. More correctly it could be called "linkable data", but then
> what would we call it when it actually linked?
>
> Jim is really arguing my point, which is that the problem isn't with what I
> guess we could call the data format, but with the content of our data. LCSH
> at id.loc.gov is perfectly good, semantic-webbed, URI-identified,
> linked-data compatible data. Is it being used as such in the linked data
> cloud? No, not really. Why not? I think for the reasons that Jim states:
> that the pre-coordinated forms just aren't useful to anyone who isn't
> assigning standard LCSH headings. As Ross seems to be pointing out, this
> seems to be proof that "just putting our data out there" may not be good
> enough. It's a first step, we should encourage LC to get the other authority
> data out there ASAP (and I think names may turn out to be more useful
> generally than LCSH), but we also need to know this is just a first step.
>
> This is been a huge issue in the RDA registry project. You *can* register
> RDA data elements in a semantic web-compatible format, but they remain
> semantically library cataloging data. As I pointed out in my talk at
> Code4Lib (2008?), the use of transcribed values, such as the name of the
> publisher as it appears on the title page, is of great interest to (some?)
> catalogers, but no other community appears to be interested in capturing
> that particular bit of data. What other communities probably would be
> interested in would be a linkable data element for the corporate entity that
> is the publisher. The library cataloging data does not include an element
> for that. Ditto, I think, our compound headings, such as the uniform title
> heading that was discussed earlier in this thread. Others may well want a
> linkable data element with the original title. The uniform title heading,
> however, doesn't give us this because it includes things like language and
> date of the edition being described.
>
> As a result of this conversation, which has been long, varied, sometimes
> unfocused, but essentially very useful, I am more than ever convinced that
> we have to do more than "link-ify" our current data elements and data
> values. Note that the RDA registry project has taken some steps to create
> data elements that can be used "in spite of" RDA. We're working on an
> article to explain that, and I hope it will be out by Midwinter.
>
> kc
>
>
> Quoting Ross Singer <rossfsinger_at_GMAIL.COM>:
>
>
>> You're still missing the point.  id.loc.gov has nothing to do with
>> _pages_.  It has to do with _data_.  It's purpose isn't to add as a
>> link to your webpage, it's to add a link to your 600 field so we're
>> not doing weak text string queries across systems.
>>
>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
>
Received on Thu Nov 12 2009 - 17:29:01 EST