Ramblings on Librarianship, Technology, and Academia

I never metadiscourse I didn't like

2/21/08 09:14 am - libraries 2.0 and 1.0 play awfully nice together

This wonderful. The Nebraska Library commission has been making archived copies of Creative Commons published works and cataloging them into their OPAC. They aren't doing this indiscriminately; they are only grabbing works which are in line with their collection development policy. They are also making spiral-bound printed copies of those works for which the license allows it, and shelving them in the physical collection.

What a fabulous, fabulous mashup of old and new.

(And does it say something about my reading habits that I got this link from lisnews and not from boingboing?)

1/26/07 11:14 am - LibraryThing and FRBR

I got to thinking today (during Julie Allinson's presentation on using FRBR to model e-scholarship) about LibraryThing and FRBR. Unusually for me, before I braindumped here, I looked around to see what others have said about this. And I found that of course of course, Tim is not unaware of how the LT works system overlaps with some of the goals of FRBR.
Cut for lengthy meanderings )

9/13/06 11:11 am - No wetware in the stacks! (Cataloguing and the virtual environment)

In my day job, in the local "metadata expert" -- or so they keep calling me, although I will continue to point out that they have a cataloging department, and just because it's got a fancy new computer-based word doesn't mean the catalogers are there we'll metadata experts. But my job entails constantly thinking how users find information. What metadata fields will end-users want, or be able to use? What metadata fields are important only for technical services? What metadata is used technologically to control rights or object manipulation? Under what circumstances is it appropriate to ignore metadata altogether and just do fulltext keyword searches?

Now I'm volunteering at the Second Life Library. (Or I will be, once I get back in; I've been locked out since the security incident this weekend and I can't get anyone from tech support to call me back. Not a great sign, but I suppose they were hacked, and so they're probably overloaded.)

At the Second Life Library, the virtual space is arranged something like a real library. As avatars move around the space, they may see a shelf of science fiction books in the science-fiction room, of reference books in the reference section, or of Gutenberg Project classics arranged in no particular order. Some of these books are portals which will open up a page on your web browser, outside of Second Life. Others will hand you a set of note cards you can read in-world which contain the text of the book, and still others (more clever, but extremely clunky and difficult to use) appear as enormous larger-than-avatar books an avatar can actually read in-world. And how do the users find these books? Well, they wander around and browse, or ask a librarian.

In other words, a collection of electronic texts is made available through one portal (the library building), and in order to find them, the patron wanders around a virtual space, browsing. (In the long run, I think it would be a good idea for the library to provide a list at the front door of all of the electronic texts made available at the library, with either hyperlinks or teleports directly on the list. And now that I'm thinking about it, it would be truly awesome if that list in-world appeared to be an old-fashioned card catalog -- with direct keyword searching, of course, but still looking like a card catalog.)

Do you see what I'm getting at? The idea is that the traditional experience of walking around the library building -- even for those users who were so much into computer worlds that they spend their days in a virtual environment and would rather go to the Second Life Library than to their local library -- is in some cases preferable to be much simpler and faster direct access search. In some ways, the look of the virtual space is the metadata: science-fiction books are behind that display of planets; reference materials are on the shelf by the reference desk.

All of us involved with the Second Life Library really hope it works out. But I will be really curious to see whether this model is currently only appealing because of its novelty. Maybe the experience of browsing through a physical space, looking for displays and book covers that catch the eye, is one that people really genuinely want.

Welcome to the William Gibson world.

7/20/06 03:13 pm - specialized reference sources

There's this interesting argument about roses going on at the GardenWeb forum. The original poster, via Google, was given in inaccurate name for a rose variety she liked, and when she ordered the rose, she received a different rose with the name she found commonly on Google. When the other posters pointed out that the vendor was not responsible for her not correctly researching the name, she continually used the presence of the inaccurate name on Google as an argument for the vendor giving her the benefit of the doubt: "It's just funny to me that the vast majority of people 100% list the Coral Carpet Rose that I wanted on the Google search That doesn't persuade some of you know it alls that maybe I had a right to expect that rose to come?"

Various posters disagree with her, many of them pointing her to a rose specific reference. But the poster I found most fascinating told her "Google is too vast and non specific to catalog all roses with the same name by their hybridizer or year of introduction."

Google as cataloger. I don't know why that surprises me, to see that phrasing, because at some level plenty of people think of Google as a catalog of information. But once the verb "to catalog" is invoked, somehow the difference between cataloging and fulltext indexing is made far more apparent to me. Helpmefind, the flower specific reference other posters are mentioning, actually does have a catalog. But Google?

Now I'm thoughtful.

12/18/04 03:33 am - xmlmarc ranting

Dorothea wrote a scathing piece on some of the problems in electronic cataloguing that I was going to respond to, but I realised my response was more of a spinoff than a reply, so it'll be here instead.

Caveat: I've been absorbed in schoolwork. I have not been following the myriad projects combining technology and cataloging. It's entirely possible that the rant I'm about to make is Old News, years old. I know there are other DTDs out there I haven't investigated.

Note for the non-librarians: MARC -- Machine Readable Cataloguing -- is a 30-year-old format which encodes bibliographic information in a way that's can be read by computer. The step inevolution before MARC was the card catalogue, so at the time it was a massive advance. But it can get a little fuggly

When I took my Cataloging class, I decided to do my term project on MARCXML. MARC, in my techie's opinion, was a cute work-around from less technological days, but clearly outdated in this day and age. I was jazzed by the notion of using the powers of XML to do an intelligent and flexible encoding of cataloging data. I imagined something like this:

MARCXML of my dreams )
That would break up each element into a completely machine parseable entity, ready for display in MARC format. Perfect! Handy, useful, easy to convert existing MARC records into XML and XML records back into MARC or any other format. Instead, here's what the Library of Congress schema actually calls for:

MARCXML of sad reality )
What's wrong with this encoding? Let me count the ways. Firstly, the fact that MARC, while machine-readable, is not particularly human readable, is a side effect of technological limitations which are no longer in place. Once upon a time it made sense to name your machine-readable fields "100" with single-letter subfield codes. Now is not that time. For goodness' sake, it's a positive abuse of XML to have a number of data fields (all named"datafield") tagged with the MARC number. And you kept the meaningful spacing and punctuation. By the ghost of S. R. Ranganathan, people, this is not Fortran.
  • Give each field type (authority, title, etc) its own field, to start. It's readable, it's portable, and there's no reason not to.
  • Name the fields. Please. Please. Don't name your field "245". Name it "Title". Readable code is everything.
  • Under no circumstances should the meaningful spacing and punctuation exist. What on earth is the point of converting to XML if you're not going to take advantage of its power? A field for title and one for subtitle; a field for birth date and for death date. Use the tool you're in. You like the way MARC looks? Fine, write an XML to MARC converter and you can view the MARC to your heart's delight. But store your data in the extensible, human-readable, portable database. Please.

Ach, this project made me cry.

12/8/04 12:12 am - Welcome to my semi-public life

As I approach the end of library school, I am overwhelmed with the projects I don't have time to even investigate.

  • Boatloads of open-source cataloguing projects
  • Metadata initiatives out the wazoo
  • Open Access initiatives

All important, exciting, an extremely interesting to me. Not to mention that I don't have time to look into all the personal projects that led to work on: bar-code scanning and cataloging my own book collection; writing the database to catalog our music collection so we can easily write tools to generate playlists and archive mixes we've made (even if we still only own analog copies of the songs); creating a comprehensive database of reference sources with annotations which can be used to generate bookmark files or pathfinders.

With luck, having this space to talk about these issues will help me find focus.
Powered by LiveJournal.com