I've been trying to find some information on what kind of workflows are out there for metadata creation. Let me tell you, it is harder than you think. But I did stumble across a new piece of software that will hopefully be coming out soon: Rutger Libraries' Workflow Management System (inventive title, no?). Code4Lib did an article about it awhile ago, so it's not like super-new news, but I've noticed that not everyone and their mom reads Code4Lib. No offense to the C4L guys--you all seem quite awesome.
Anyway Grace Agnew and Yang Yu wrote an article about it, and it's pretty interesting stuff. WMS is really just like Archon or Archivists Toolkit, except that it's for anyone that's creating metadata, not just archives. I like that aspect very much, since here at our instiution, most of the digitization projects are actually hybrid projects that use staff from archives, the library, and the digital people. I imagine it's probably at least a little more user-friendly than the archives software, mostly because of who created it. Archivists can be....not so user-centered sometimes. Again, no offense (I'm offending lots of people today!).
Tuesday, March 11, 2008
Thursday, March 06, 2008
GLIMIR
The Interwebs is already starting to seeth with mentions of GLIMIR.
But first, you may ask, what is GLIMIR? Well, as I read it, it's a terribly horrible acronym for Global Library Manifestation Identifier (yeah, I don't know where that other I and the R come from, either....maybe we could throw some stuff in?....Global Library Irate Manifestation Identifier Roadshow?)
Basically, it takes the problem of manifestations (FRBR alert!), and addresses the issue that ISBNs are not manifestation identifiers. A good example of what that means was given by Mr. Stuart Weibel--there are lots of records in OCLC that have the same ISBN. But many of those records are not duplicate, redundant records. They're foreign language records for a work in English. So....in this case we're talking about the same work, but a different manifestation of that work (I may be using "work" in an improper form. Sorry in advance). I guess that in the beginning, a lot of people thought that ISBN would be a manifestation-identifier. Which would be very nice and comforting, since it helps to ground FRBR-thinking into current-cataloger-thinking, but it's not a 1-to-1.
So OCLC (in all their infinite wisdom), has graciously decided to solve this problem for us. Whether or not these GLIMIRs will be "business-neutral" is still up for debate. Honestly, I don't see why they wouldn't be....OCLC numbers (and ISBNs) are "free"--once one catalog outside OCLC has one in their record, you're perfectly welcome to use that number for whatever you like.
So, with that (really, really bad) introduction to GLIMIR, I give you a link list:
Stuart Weibel's GLIMIR Of the Future (good stuff, read the comments, too!)
The FRBR blog's Open Library developers’ meeting (just a mention)
FRBR definitions (why not? Manifestation!)
That's all I have for now....OCLC is not yet admitting publicly that it's launching a pilot project. But I do think it's fascinating that FRBR is basically infiltrating our organizational lives already--RDA is not more than a mere glimmer in our eyes (pun!), yet we're already ramping up for a FRBR-based approach to cataloging. In fact, it's kind of like the current recycling theory: it's easier to recycle when you don't have to think about it. It's easier to FRBR when you don't have to catalog it.
But first, you may ask, what is GLIMIR? Well, as I read it, it's a terribly horrible acronym for Global Library Manifestation Identifier (yeah, I don't know where that other I and the R come from, either....maybe we could throw some stuff in?....Global Library Irate Manifestation Identifier Roadshow?)
Basically, it takes the problem of manifestations (FRBR alert!), and addresses the issue that ISBNs are not manifestation identifiers. A good example of what that means was given by Mr. Stuart Weibel--there are lots of records in OCLC that have the same ISBN. But many of those records are not duplicate, redundant records. They're foreign language records for a work in English. So....in this case we're talking about the same work, but a different manifestation of that work (I may be using "work" in an improper form. Sorry in advance). I guess that in the beginning, a lot of people thought that ISBN would be a manifestation-identifier. Which would be very nice and comforting, since it helps to ground FRBR-thinking into current-cataloger-thinking, but it's not a 1-to-1.
So OCLC (in all their infinite wisdom), has graciously decided to solve this problem for us. Whether or not these GLIMIRs will be "business-neutral" is still up for debate. Honestly, I don't see why they wouldn't be....OCLC numbers (and ISBNs) are "free"--once one catalog outside OCLC has one in their record, you're perfectly welcome to use that number for whatever you like.
So, with that (really, really bad) introduction to GLIMIR, I give you a link list:
Stuart Weibel's GLIMIR Of the Future (good stuff, read the comments, too!)
The FRBR blog's Open Library developers’ meeting (just a mention)
FRBR definitions (why not? Manifestation!)
That's all I have for now....OCLC is not yet admitting publicly that it's launching a pilot project. But I do think it's fascinating that FRBR is basically infiltrating our organizational lives already--RDA is not more than a mere glimmer in our eyes (pun!), yet we're already ramping up for a FRBR-based approach to cataloging. In fact, it's kind of like the current recycling theory: it's easier to recycle when you don't have to think about it. It's easier to FRBR when you don't have to catalog it.
Wednesday, March 05, 2008
LCSH v. techies
There's a big digital project in the works here at The New Job. They're digitizing something like 400 works or pieces, and then some of us in the cataloging department are charged with creating the metadata. Not from scratch or anything, of course--the works are originally out of the archives here, so there's some basic metadata available. I've been meeting with people about this project a lot in the past few days, since I am the Metadata Librarian.
And I finally think I have a grasp on what it means to the be the Metadata Librarian. My job is to make sure that the catalogers don't feel like they're selling their souls, and that the digital people don't feel like they're being nickel and dimed by the catalogers. Case in point: LCSH.
This new digital project is going to be pretty cool--two institutions working together to create a federated search portal that other libraries/archives will be able to use, as well, in the future, all under one umbrella. It's not the most groundbreaking piece of technology I've seen, but still. It's neat that they're doing it.
They did a pilot metadata creation thing a few weeks back, as I understand it. One cataloger told me that they were given 6 days (really four, since two of the days were a weekend) to create metadata on 35 records. No big deal, right? Wrong. Apparently the metadata includes LCSH. And let's not forget, all the catalogers here have their "real" jobs, where they do all the other cataloging that needs to be done.
So the catalogers are all in a tizzy because they think (perhaps rightly) that the digitization people just don't get how long it takes to do subject analysis, not to mention filling in the other blanks in the metadata record. Oh, and did I mention that the catalogers didn't have anything to look at while they cataloged? The digitization people didn't think that the catalogers needed to see any of the pieces in order to catalog. How does subject analysis get done when all you have is a title?
Now, on the other side of this, the digitization people (this includes the project manager), think that the catalogers are exaggerating how long it takes to do things, and that their time table is going to get screwed up if the catalogers keep insisting on needing more things and more time. I think that the digitization folks believed that the metadata and digitization would be done concurrently, or even that the metadata could be done BEFORE the items were digitized. This is of course possible...but only if, as one cataloger said to me "we go upstairs with a notepad and catalog it by hand in front of the original."
I've already come up with several solutions in my head for this, and I think this is why they hired me. I like creating compromise. But that's not the "biggest" problem.
The biggest problem is that the digitization folks have now started messing with the LCSH field. They have started asking for non-LCSH terms to be used in that field. The catalogers are horrified, of course. I'm kind of horrified, too, but not because LCSH is so inviolate. More because the non-LCSH term they want is not a "subject" at all. It's a type of material. But I think I have an answer for that, too, if I can phrase it correctly. Then everybody wins. We have a meeting today; we'll see how it goes. Considering that I'm totally new, they might not even want me to speak at all. :)
And I finally think I have a grasp on what it means to the be the Metadata Librarian. My job is to make sure that the catalogers don't feel like they're selling their souls, and that the digital people don't feel like they're being nickel and dimed by the catalogers. Case in point: LCSH.
This new digital project is going to be pretty cool--two institutions working together to create a federated search portal that other libraries/archives will be able to use, as well, in the future, all under one umbrella. It's not the most groundbreaking piece of technology I've seen, but still. It's neat that they're doing it.
They did a pilot metadata creation thing a few weeks back, as I understand it. One cataloger told me that they were given 6 days (really four, since two of the days were a weekend) to create metadata on 35 records. No big deal, right? Wrong. Apparently the metadata includes LCSH. And let's not forget, all the catalogers here have their "real" jobs, where they do all the other cataloging that needs to be done.
So the catalogers are all in a tizzy because they think (perhaps rightly) that the digitization people just don't get how long it takes to do subject analysis, not to mention filling in the other blanks in the metadata record. Oh, and did I mention that the catalogers didn't have anything to look at while they cataloged? The digitization people didn't think that the catalogers needed to see any of the pieces in order to catalog. How does subject analysis get done when all you have is a title?
Now, on the other side of this, the digitization people (this includes the project manager), think that the catalogers are exaggerating how long it takes to do things, and that their time table is going to get screwed up if the catalogers keep insisting on needing more things and more time. I think that the digitization folks believed that the metadata and digitization would be done concurrently, or even that the metadata could be done BEFORE the items were digitized. This is of course possible...but only if, as one cataloger said to me "we go upstairs with a notepad and catalog it by hand in front of the original."
I've already come up with several solutions in my head for this, and I think this is why they hired me. I like creating compromise. But that's not the "biggest" problem.
The biggest problem is that the digitization folks have now started messing with the LCSH field. They have started asking for non-LCSH terms to be used in that field. The catalogers are horrified, of course. I'm kind of horrified, too, but not because LCSH is so inviolate. More because the non-LCSH term they want is not a "subject" at all. It's a type of material. But I think I have an answer for that, too, if I can phrase it correctly. Then everybody wins. We have a meeting today; we'll see how it goes. Considering that I'm totally new, they might not even want me to speak at all. :)
Monday, March 03, 2008
There Ain't No School Like the Old School
So I've started using old-school Unicorn (ie, Workflows). I mentioned before that it feels outdated. It's really easy to use, once someone has explained how to use it and what the words mean. It's kind of Windows-based...it reminds me of databases that we used in junior high, which makes sense, since Unicorn is a pretty old system. I'm currently learning how they copy catalog here, so the work is not terribly challenging (although it does give me a good chance to relearn my leader/directory/008 fields). Their system here is so streamlined...the vendor has a relationship with OCLC, so the copy catalogers' job is really to just check the cataloging that's already in the Sirsi system--there's no uploading by our library, unless OCLC has a poor record or no record to use at all.
So I've been spending time today using a light wand (I know!), and using the "public access" part of Unicorn, which is laughably old. The face that actual users today see is fine--it looks like any regular ILS front end. But the public access module in Workflows that the librarians use has those picture buttons, like an Athena system or something. The "reserve desk" has a picture of an apple, "search catalog" has a picture of a girl in 1993-era clothing studiously looking at books in a library. "Browsing" has a pair of binoculars floating free above the Earth (I assume that these are some kind of super spy satellite binoculars). For some reason, the "subject" search has a picture of the Space Shuttle launching. Don't ask, because I don't know. I could go on, but you get the idea.
Workflows is fairly customizable, even though I would never have imagined that to be the case when I first saw it. You can put in whatever menus you want. I also learned today that if you want to do an import, though, Workflows go really, really 1993 on you. The first step is to tell it you want to import a certain file, and then you have to schedule the upload. I imagine that back in the day this was necessary so you could upload everything at 3am when no one was using the system. Of course now it's just silly, and makes the catalogers sigh.
I'm looking forward to using Java Workflows a little more...just to see what kind of changes they made to the system. It has to be better than old Workflows, if even just in the feel of it.
So I've been spending time today using a light wand (I know!), and using the "public access" part of Unicorn, which is laughably old. The face that actual users today see is fine--it looks like any regular ILS front end. But the public access module in Workflows that the librarians use has those picture buttons, like an Athena system or something. The "reserve desk" has a picture of an apple, "search catalog" has a picture of a girl in 1993-era clothing studiously looking at books in a library. "Browsing" has a pair of binoculars floating free above the Earth (I assume that these are some kind of super spy satellite binoculars). For some reason, the "subject" search has a picture of the Space Shuttle launching. Don't ask, because I don't know. I could go on, but you get the idea.
Workflows is fairly customizable, even though I would never have imagined that to be the case when I first saw it. You can put in whatever menus you want. I also learned today that if you want to do an import, though, Workflows go really, really 1993 on you. The first step is to tell it you want to import a certain file, and then you have to schedule the upload. I imagine that back in the day this was necessary so you could upload everything at 3am when no one was using the system. Of course now it's just silly, and makes the catalogers sigh.
I'm looking forward to using Java Workflows a little more...just to see what kind of changes they made to the system. It has to be better than old Workflows, if even just in the feel of it.
Subscribe to:
Posts (Atom)