ECCO records

Blech. They have no subject analysis whatsoever. Nothing. Just description. This is the kind of record we could have had years ago. After the mess with the Serial Set records... which have their own (incompatible with LCSH) subject scheme, this makes me wonder if we ought not be more clear about what we expect from the MARC records we are paying for when we acquire new digital services. Or at the least, let them know our disappointment.

Transaction file issues again

Time of last Legato backup: Dec 2 12:25

Well, the Legato backup completed or it re-released or something happened, as you can tell. I got a call from Greg at the H-L Circ desk at 1:45 reporting checkout problems, which turned out to be the transaction file not processing. Called III and they said control wasn't down, and after I had explained what had happened earlier today, and the backup problem from last night, their answer was: well, the transaction file just needs to be restarted every now and then, when it stops like this. Duh. I said forcefully that I am able to predict when this is going to happen, and if I can do that, the system should be able to as well. I asked that a call remain open to investigate the root causes of this, and to determine what can be done to make sure it doesn't happen in the future... perhaps there is a Legato configuration or a bug/enhancement fix that III could make to fix this. Grrr. On a side note, I have a cold. Cough.

Again with the backup not happening

Time of last Legato backup: Dec 1 02:31

I had a suspicion... I have no idea why, but I just thought I'd check, since we had a problem last week too (Nov. 27)... anyway, this time the transaction file was not processing. The way I know this is to get into my test record - Mudlumps - and make an edit, then close out and try to get back into the record. So I fired off an e-mail to Tim and Chris, and called III. The III guy was extremely helpful. Had it fixed in under a minute, and I didn't have to do any explaining, nor did he question my diagnosis - which does happen every now and then. So, I'll be on the lookout tomorrow AM too.

Phebe backup didn't happen last night

So, my power is out at home - went out early this morning. So after swiffering and sweeping (instead of vacuuming) I walked into H-L (I'd called first and found out that H-L had power, but not some dorms apparently). Fired up putty and saw that the legato backup had not happened in the wee hours, as it should have. Sent an e-mail to Chris and Tim to alert them, as I imagine we're not the only share/server that didn't get backed up. One thing to clarify next week is what level of emergency this is. Should we call IT about this? If so, whom should I call? There used to be a pager number, but I think that system is out of date.

As it is, we likely won't lose any data - the only way that could happen is if the system were to crash and burn and have to be restored from legato. In that case, we'd have lost all of Friday's work and anything done up til the time of the crash, most likely. The real inconvenience for me is that our transaction file is at 73 % full. I've been doing some massive global updates to eebo records to fix the one last error that resulted from my problematic load table. I'm just lucky I was conservative yesterday and didn't do more. If I'd pushed it over 90 percent, it's likely that our transaction file would have filled up and we'd be in a control down situation.

I called III and spoke to Remy, and discussed the possibility of increasing the allotment for the transaction file. He suggested that it could be done on the fly, but he'd prefer to consult with database specialists before doing this as he wasn't sure of what the consequences could be for the system. He said that the size of the transaction file is set at the time the Millennium system is installed, and is gauged to database usage metrics. He suggested that if there had been significant changes in usage, that it's possible that our allocation should be adjusted. I'm going to follow up on this on Monday. For the time being we're doing nothing, but will monitor the transaction file, and if it reaches 93 percent, I will call III and see if there can be a temporary adjustment made safely.

Just another Saturday...

Ordered DRAM records from OCLC

Filled out the form to get the records from OCLC's WorldCat Collection Sets for DRAM. Amazingly, the options for customizing the URL did not include the most common option... insert proxy prefix... no, they'll let you delete the entire contents of all 856s (why you would want to do this I have no idea), use only the first listed 856 (again, I see no point in this), and tweak the |z public note... which I did. So, I'll need to use MarcEdit to insert our prefix or create another custom load table. That may be the best route since we'll be getting monthly updates.

HoudahSpot on MacZot

My review of HoudahSpot as seen on MacZOT.com

-- Wow, I found a duplicate Documents directory that was buried deep in a folder that I didn't even know existed and was able to remove about half a gig of duplicate files (Sweet!) --

NOTE: If you're seeing this on June 16, 2006 head over to MacZOT, you might be able to get a Free copy of HoudahSpot

Search easily in Tiger, Mac OS X, with HoudahSpot

Another BlogZot

MacZOT.com Fans want Pzizz because 'According to the National Sleep Foundation, sleep deprivation and its effect on work performance may be costing U.S. employers some $18 billion each year in lost productivity. Another study pushes this cost to over $100 billion.' - link to full article

about your URL

Interesting service http://www.abouturl.com that brings together in one convenient page, all the various "web page" checkers... from load time to validity checkers... neat.

read more | digg story

Guy proposes marriage on Apple time lapse coverage of 5th Avenue store

If you watch the time lapse footage at 5AM on Apple's site for their new Manhattan store you'll see an innovative young man holding up a sign with the following message. "Uschi Lang" "Will you marry me".

read more | digg story

Global Update not so global

According to the help desk:

"I write you about the call where you asked:
'if there is a way to increase the limit of 25,000 records
when he does an index search for global update.'

This limit was added with Rls. 2005 because of problems sites
were encountering when trying to work with very large review
files. The new limit is hard-coded.
Any change to this limit would be considered as an enhancement
request. You can submit an enhancement through the Innovative
User Group enhancement process.
You can also submit you suggestion directly to Innovative by
emailing it to enhance@iii.com

So, this applies to index find and replace as well as review files. Hope we don't have to make any changes to variable fields of large sets of records. It could be, ahem, difficult to do.

Notes regarding Millennium Product Suites

After speaking with Barbara H. this morning, I know this: If we order ANY of the suites (complete suites) we may be able to 'tack on' additional software and receive the same discount and maintenenace discount. We'd need to order by June 30, but wouldn't have to pay until the software is installed. I've requested price quotes for all of the suites, though I think that the most likely ones we'll be interested in are the first (WebPac Pro), and the third (Acquisitions Workflow).



More to come...

Planning for Phebe migration

Continuing to work with Randy, III and others to get the hardware ordered and the migration scheduled. Still not sure if the blade server concept has been approved.

White smoke above the halls of Augusta

The InnReach is Dead! Long live the InnReach! Maine libraries have overwhelmingly (83%) chosen MaineCat as the new name of the statewide resource sharing InnReach system known as Maine Info Net. I therefore proclaim:

110 2- MaineCat
410 2- MeCat
410 2- The Application Formerly Known as Maine Info Net
410 2- TAFKAMIN
510 2- Maine Info Net

Huzzah! BTW, it was thought that there might be some confusion between the new MaineCat and the old MaineCat (the CD-ROM statewide union catalog). I doubt it! As a friend of mine says, "Old ideas die, when those who hold them die."... Well maybe that's a little too naturalistic. Still.

Nexpress Catalogers conference call

Participated in the second of the Nexpress cataloger conference calls. Sherrie had asked if I should be doing this or perhaps Mary. I think Mary should start to be involved in this. I'm going to talk to her about participating in the next meeting. Mostly we've been discussing the various issues relating to the way records from our local catalogs have or have not merged in Nexpress. Basically, Williams is getting a LOT of non-returnables requests because the records they have for e-journals have the print ISSN in them, which is what the A&I vendors use to pass OpenURL requests in most cases. Williams had specified getting the print records as first choice from SerSol, whereas Bates, Bowdoin and Wellesley (maybe Colby too) specified electronic records. The result has been that Williams records in Nexpress are more likely to match holdings in the Non-returnables module.

The other issue is that our records are not merging because some of us who get electronic records as a priority from SerSol, are getting the print ISSN in a |y of the 022. The |a has the e-issn. Because Williams and Wellesley didn't have load table training at the time of their load, they had to use the basic m2btab.b loader, and had to ask SerSol to prepend a 1 to the 001 SSJ number, so that it would be recognized by the load table as a valid 001. Why they couldn't have III change the m2btab.b table to accept alpha characters, I don't know, though it may have to do with possible "random" overlaying of non-matching records that happened to have the same 001 even though they came from different sources, OCLC and SerSol for example.

Confused yet? Well the way the matching algorithm works in InnReach is that it looks to match on the 001 and if it finds a match, it merges. If it doesn't find a match, then it checks the 020 field |a (ISBN), and failing a match there, it checks the 022 field |a. So as a consequence you can see that we have three different records for some electronic resources: search American Economic Review (Online), and you'll see what's at issue. One record with Williams and Wellesely, one with CBB, and one for Northeastern (who uses TDnet).

We are looking into various ways to fix this, including:

-- doing the changes ourselves via global update [con: we'd have to do this every month]
-- asking SerSol to strip all ISSN's from the Conser MARC records we receive and load new ISSN data from their database (print to be mapped to |a [my choice, since we're paying them, but we'd likely have to reload a LOT of records, but they would change this in our profile and we'd never have to deal with it after this fix, "famous last words"]
-- waiting til the format-neutral ISSN is developed by the ISSN agency... [Chris (Will) and Sandy (Well) will report back from NASIG on this... it turns out it's not coming til the Fall of 2007 at the earliest]

To see an example of the fix we're proposing search for 19th Century Music and select the first record (the one that says it's print format)... Don't worry about why the electronic links aren't showing up from our record; it's been reported to III. If you select MARC display, you'll see that our SerialsSolutions records did merge with this, once we manually changed the records. Indeed, the SerialsSolutions electronic record went away totally, and because of the print ISSN, the holdings merged with the actual print periodical record. This would mean that we'd have a one-record approach in Nexpress, but not in our own catalogs. And not in Maine Info Net. At any rate, we have to be mindful of how any changes will affect our users. This record will be ONE LONG RECORD! Click back in a week or so to see if III has fixed the electronic link display issue. You'll see what I mean.

Seems like I'm the right person to be thinking about this for the Library, since I'm doing the loading of the records, and likely to continue doing that for a while. We've not even begun to discuss the EEBO mess (more non-matching records...) ... next conference call is Tuesday.

Tape drive waiver

Communicating with Randy and Tad about the tape drive waiver and it looks like we'll go ahead and send the acknowledgment in to III which will allow us to have the waiver. Specifically we're acknowledging the following:

"we're aware of the special circumstances when a tape drive is useful, as described below, and are willing to forego those capabilities:

- Backup during implementation, if there is a delay at the sites end in including the server in Legato scheme [Shouldn't be a problem, as we currently have many blades in the legato backup setup already ]
- Occasional "push" backups of data by Innovative techs for special circumstances [to our knowledge III has never done this with us, at least since Randy and I've been here]
- Software distribution for secure sites [I believe a secure site is one without FTP/Internet access possibilities]"

Spoke to Randy P. about this and we both agree that we haven't used the tape drive in a long while (at least over a year), and that the above is simply III legalese. I'll chat with Judy about sending in an acknowledgement of this.

Mulling MULS

I contacted Sharon Quinn at Orono to find out what's happening with MULS. Will update this post as I know more. This was prompted by an email from Sara and follow up by Guy and Carr. According to Sharon, Marilyn Lutz and Barbara McDade are the ones to speak to. And something is definitely coming that will replace MULS. It looks like it will happen soon. I got a second email from Sharon regarding this and she mentions that she's had a phone call from Marilyn indicating that the new MULS release is imminent.

Cataloging update

50 percent done with the non-Asian monographs, 33 percent done with the CD-Roms. 100 percent done with Spanish movie soundtracks.

verdammt Eszett!

Couldn't figure out why OCLC Connexion wouldn't let me validate a record with an Eszett, that I had entered using the Connexion ALA Character set Diacritics and Special Characters box. It's there, but as I found out after searching the OCLC Cataloging listserv, it's not kosher til version 1.60 comes out, and maybe not even then... seems that LC has a rule interpretation that does not permit the use of this character. Sigh. This is cataloging.

CentralSearch Demo

In attendance, Judy, Sara, Carr, Karl, Richard, Mary, Sue, Ginny, Mike, Rebecca, Ruth, Jennifer

Up and running in 6-8 weeks. Could have up and running by fall semester easily.

Did 18 software upgrades over 2005, which was the release year of the product.

-- subject categories (clusters defined by us)
-- dynamic resource display -- ability to watch results come in in real time
-- advanced filtering (peer-review, full-text, etc)
-- de-duplication of results set (with links to all the access to that citation)

Can we place search boxes on other webpages? (JRM) - yes, but he's not sure about blackboard.

Next development. Vivisimo clustering
clustering vs visualization

CentralSearch sort of assumes that the user of their product is going to be a novice user, less advanced researchers. I'm not so sure that this is true. I think the librarians might disagree.

If you do a one word search, with clustering, it will attempt to guide the user, to present them with options to help them make more intelligent use of the search. - cluster by subject class, journal title, date, author. Will be released in the third quarter of 2006. (by the end of September)

They're moving back to product support specialists (application specific), so there would be a CentralSearch specialist who would deal with us.

Not sure we got any idea how easy/quick it would be to add a typical database to a list.

Search stalling in the demo. This is reminiscent of the last demo we had from SerialsSolutions on CentralSearch. He switched browsers and it started working.

Saw the clustering demo and we can cluster by topic, date, author or journal title.

Spreadsheet collaboration

Well, I've been working with Cathy D. and Rachel this morning, helping them design a way to have both of them doing data input for an excel spreadsheet of unplaced orders that Sherrie wants. I thought about an Access database, but that seemed like overkill (though with such a limited amount of data - title, author, requestor, dept, cost - it would have been easy to set up), so in the end they are working on separate spreadsheets, and we'll merge the data into one workbook at the end.

Woah Nellie! That paragraph above... that was BEFORE I searched Excel/Office Help. Where I discovered that we can:

Share a workbook

1. Create a workbook you want to make available for multiuser editing, and enter any data you want to provide.
2. If you want to include any of the following features, add them now: merged cells, conditional formats, data validation, charts, pictures, objects including drawing objects, hyperlinks, scenarios, outlines, subtotals, data tables, PivotTable reports, workbook and worksheet protection, and macros. You can't make changes to these features after you share the workbook.
3. On the Tools menu, click Share Workbook, and then click the Editing tab.
4. Select the Allow changes by more than one user at the same time check box, and then click OK.
5. When prompted, save the workbook.
6. On the File menu, click Save As, and then save the workbook on a network location accessible to the intended users. Use a shared network folder, not a Web server.
7. Check any links to other workbooks or documents, and fix any that are broken.

Notes

All users with access to the network share have full access to the shared workbook (shared workbook: A workbook set up to allow multiple users on a network to view and make changes at the same time. Each user who saves the workbook sees the changes made by other users.), unless you use the Protect Sheet command (Tools menu, Protection submenu) to restrict access.

The users who will edit the shared workbook need Microsoft Excel 97 or later (Microsoft Windows) or Excel 98 or later (Macintosh).


Well that's pretty cool. Cathy and I tested it out (we're both on Office 2003). Rachel will have a go later this morning (she's on Office 2000).

Cataloging cleanup in Karl's office

I've sorted through all of the remaining library materials in process in my office and am working to have them completely catalogued by the end of May. Clean slate. The tally so far:

• 3 cdroms
• 6 videorecordings
• 9 sound recordings
• 25 non-asian language books
• 10 asian language books

Note that the Asian language materials does not include the materials in the basement. That's another large "to do" item.

Docushare at Rochester

Judy sent me a link to the information about the Mellon grant that U. Rochester has gotten for its eXtensible Catalog (XC) project... which has been talked up a lot in the circuit. I started googling for more info about the project, but got distracted by a shiny thing... take a look at the Univ. of Rochester libraries' staff pages. It's a pretty neat content management system... or at least this implementation is... it's from Xerox. For more bling, click on Presentations and Publications... now that is cool. CBB could use something like this. Basecamp is useful, but I don't think it's intuitive in navigation. Yes, it does different things. Still.

Off topic: neat interview with Xerox's current CEO available in transcript form here, or as an audio stream here. She talks a lot about what it took to bring Xerox back to life.

Phebe and 13-digit ISBN

The 024's with the 13 digit ISBN's are being downloaded correctly from OCLC and are indexed. This isn't anything special we did with our load table. We just happened to have already been accepting 024's (other publisher numbers) and indexing them in the I index. Good for us. This means we should be "ready" to accept/deliver EDIFACT orders from our vendors (both accepting and delivering these orders from phebe will require additional III software, I think). If you'd like to see an example of a 13-digit ISBN in the catalog, the record for The Cambridge economic history of Latin America, will show you both that the ISBN indexes, as well as the 10 digit ISBN, and how it displays to the public. Eventually all 13 digit ISBN's will be in the 020 field in OCLC (and in Phebe). For now, they are displaying to the public incorrectly with the UPC/recrd# label. Nothing to be done about that for now.

Note to self 13 digit ISBN

Inform yourself! There appears to be no information on the IUG list about this ongoing transition. For more information from the horse's mouth, go to the FAQ on the ISBN.org website. It's even got a nifty 10->13 ISBN converter for "retailers" ... I guess libraries qualify!

Did find an informative FAQ on CSDirect. The basics are that we need to review our load tables. Probably should have done this earlier. But as long as we can make sure that we are downloading the 13 digit ISBN's from OCLC, and indexing them I guess, we should be ok to do the EDIFACT ordering with Yankee and other vendors.

From CSDirect:

"Your library must consider the following changes:

• Many vendors are outputting 13 digit ISBNs in advance of the 2007 implementation deadline. For example, as an interim solution, OCLC will output 13 digit ISBNs into a MARC 024 tag with a first indicator of 3. If your organization plans to load these 024 fields, you should view the load tables used in Management Information to verify whether 024s are currently loaded. You need to determine whether you want to index the 024 if it is not already in your index rules. Once OCLC changes to loading 13 digit ISBNs into the 020, you need to decide whether to retain any changes made to the load table previously. You should check with your data providers to find how the providers plan to proceed with implementing the addition of the 13 digit ISBN to data.

• If your library uses BISAC ordering, you must move to EDIFACT. There have been no changes to the BISAC standard, and no changes are anticipated. BISAC uses only ten digits of the ISBN. After the implementation of the 13 digit ISBN, few (if any) vendors will be prepared to accept BISAC orders.

  If you have questions about moving to EDIFACT, please contact your customer sales representative. You should check with your vendors if you or your staff are not sure whether a given vendor supports EDIFACT."

Maine Info Net software on phebe

Received a call from Kevin Mitchell from III's Union Database division and he called to let me know that he's going to need to compile some software on our system to recognize the new Agency Model for the Maine Info Net system... which I guess is going to have a new name too. He mentioned that there will be no downtime and we shouldn't notice it even. I've asked to be notified when the compiling is done.

Phebe migration plans

Been working with IT and III on the choice of a platform for our new server - more on that in upcoming posts. We are planning on migrating to the new hardware in July. Ideally we'd be able to be running the new hardware for a couple of weeks before we upgrade to 2006... though that's partly mitigated since we're currently running the beta 2006 Web OPAC. No word yet on when III will release 2006.

Wow! MacZOT! does it again

Well you remember the success they had with another piece of great Mac software. The folks at MacZOT! are at it again. Basically, MacZOT and TheCodingMonkeys will award $105,000 in Mac software based on blog citation analysis. An infotech librarian's dream. And on top of it all they are featuring the wonderful SubEthaEdit from CodingMonkeys, a great collaborative editing solution for folks who didn't already know. Why not check it out at BLOGZOT 2.0 on MacZOT.com? You won't regret it. Great deals on software that is excellent. Highly recommended. I can only say that I have the highest respect for the folksat CodingMonkeys. They have designed a solution to a problem that's more than a software problem, but a human interaction problem. Getting people to collaborate without thinking about the mechanics. Cheers.

UPDATE: I got my free SubEthaEdit! Thanks MacZOT!

2006LE - preparation

Called III around 11:00 AM to make sure that there would be someone at III to do the step-around of the backup/restore tape step, since we do Legato backup to disk and don't need the tape backup. Ken was supposed to take care of it .c899359, but it hadn't been done by the time I got over to the machine room in Hubbard. Grr. Called III and talked to my favorite helpdesker (Glenn) and he got us stepped around. Details of the preparation phase:

2:57 PM... loading main software
3:00 PM... installling - loading additional software upgrade
3:06 PM... installing - loading software utilities
3:09 PM... installing - loading new system files
3:18 PM... installing new system files
3:20 PM... building library routines - 0%
3:28 PM... building library routines - 25%
3:34 PM... building library routines - 50%
3:45 PM... building library routines - 75%
3:50 PM... build completed
3:50 PM... phase 1 finished

In 30 minutes, I'll go and finish the job, Pardner. Swagger... swagger... stumble?

Release 2006LE upgrade

Confirmed with Randy and Sara that I will do this on Monday, 3/13 - notice sent to libstaf and faculty-staff digest. Gonna try to do this upgrade in two parts. The preparation phase in the early afternoon, and the commit phase later the same day, after the library is closed. First time trying this. Release 2006LE features list available on CSDirect.

Frist

Thanks to Sara, I've now got this up and running.