How to use this Page

Mild post updates:

First, if you are attending Midwinter and want to see the LITA Trendsters in action, it’s Sunday, January 13, 2008, 8-10 a.m., LOEWS Congress B. The session will be recorded, but we’re so much more fun f2f.

Second, under interoperability/open data I’d add NISO’s ballot item to establish a working group on serial knowledge bases. Kudos also to NISO for being so open about its documents and processes.

————————————————————

I had to miss LITA’s Top Tech Trends panel at Annual 2007, so it has been a full year since I have really engaged those rusty parts in my brain. And what a year it has been!

Hardware is becoming smaller, larger, and wider. TVs, laptops, and iPhones are now designed around 16 x 9 — a display shift gently pushing its way through our culture. Meanwhile, the cell phone is that “ubicomp” (ubiquitous computing) device talked about twenty years ago, while HDTVs keep getting bigger and cheaper; the 32″ we bought last year looks positively petite. (Thanks to Richard Madaus, the Boss of Bosses at My PLace Of Work, for pointing out the 16×9 phenom.)

The path to interoperability

For the I-Heart-Standards crowd, we had several interesting pops that point to a possible trend. It only took two years for SUSHI to debut, which is like a nanosecond in the standards community. Also, the NCIP discussions may or may not lead to fruition, but I like how they are trying to build in flexibility.

A very smart co-worker has been observing for a while that LibraryLand needs an “ISWN” — an ISBN that colocates items at the work level. Apparently great minds think in parallel: by mid-2008 several large publishers are planning to implement ISTC — the International Standard Text Code — which is an ISBN-like number that collocates items at the expression level.

This NISO-approved standard does what xISBN attempts to do but much more cleanly: as it says on Laura Dawson’s wiki, ISTC “identifies the intellectual property that could be manifested in any number of ISBNs. For example, the book ‘Moby Dick, Or the Whale’ would be identified with an ISTC; the Bantam edition, the Barnes & Noble edition, the Signet edition, the Norton Critical edition would each be assigned a different ISBN.”

Not only that, but as Dawson explains, the ISTC goes even farther: “ISTCs are not limited to books. They can be assigned to poems, articles, essays, short stories – any written work. So an ISTC can identify the poem ‘Lady Lazarus’ by Sylvia Plath, and another ISTC can identify the collection ‘Ariel’ in which it appears. A third ISTC can identify the unedited ‘Ariel’ collection that includes poems the original publication did not.”

This has so many possibly wonderful implications my head is exploding — the smallest of which is that finally, I could add single essays and short stories to LibraryThing. In any event, it’s interesting that such a key standard has bubbled up so quietly and yet in parallel with the ideas brewing in the brains of other smart people.

Open the door, see all the data

Design concepts such as open source and service-oriented architecture continue to mature, and these ideas percolate in new and interesting ways, such as:

• Evergreen’s success in Georgia and continued growth
• Continued success for Koha
• WoGroFuBiCo’s recommendation to put authorities on the Web

In winning its first public-access mandate, SPARC made AAP throw a clot, and I admit enjoying the spectacle. Who will win in the short run may not matter as much as who wins in the long run — and the the open-access crowd (largely) seems to grasp that right now it’s about hearts and minds. I warn the open access crowd to walk lightly in this area and be respectful of disciplines where mandating open access would be counterproductive. “‘Shoot if you must this old gray head, but I get paid for my work,’ she said.”

To open source and access you can add, “open data.” Profession-wide, we’re asking the right questions — are we best served by a model where our de facto network catalog data is proprietary? — and the conversations about open data knowledge bases are also heartening. Even more interesting is that discussions that would have been pooh-poohed a decade ago now have serious traction.

Some LibraryLand types actually understand the phrase “service oriented architecture.” For those who don’t, Eric Schnell spelled it out for us in a fabulous five-part series. Go Er-ic! Go Er-ic!

One interesting phenom, first observed with Endeca’s penetration of the library market, is that librarians appear more open to non-library software. Two non-library software products, Jive and LivePerson, have passed the selection process for large virtual reference networks, and AskOntario will debut its LivePerson-based VR service on January 15. Jive is based on Jabber, an open source product, demonstrating that all roads lead to London.

Overall librarians appear somewhat savvier about software selection. Maybe it’s just who I speak with, but increasingly I engage with colleagues who are familiar with terms such as as “deliverable,” “critical path,” “stage-gate,” and “project management.” Awareness of user needs is also on the rise.

Blogging is mainstream. People understand the implications of maintaining a blog, and the field is shifting to a focus on either the well-written niche blog with something new to say and specific audiences to serve, or the group blog. On LITAblog, Eric Lease Morgan talked about the “abandoned” blogs, but I’d focus on the blogs that have become very big.

The LibraryThing for Libraries service points to a growing awareness that population density is key for social networking, that simply adding a tagging function to OPACs is not adequate, and that libraries are small and the Web is large, which is a strategically healthy point of view. This ties into experiments such as WorldCat Local, which is designed around luring library users from the wild and placing library services squarely in the user’s web workflow.

Ships That Sailed By

I noted in July that not one but two libraries in Arizona had implemented BISAC identifiers (the subjects established by the Book Industry Standards Group), one for their physical organization and the other for their OPAC’s facets. Some folks really got their shorts in a bunch over this, and the PUBLIB discussion list appears to harbor quite a few Dewey fundamentalists (leading to my other conclusion, which is that the old-style massive discussion list may be on the way out).

One boat we have pretty much missed as a profession is mobile device compatibility. By the time most of us catch up with it, it won’t be needed any more. Can’t win ‘em all.

Bookmark to:

Over on TechEssence, Roy Tennant has posted a manifesto about library software.

The part of the manifesto that hit me most was the list of consumer responsibilities… and though the manifesto is good and deserves discussion on its own point, I’m going to drift in another direction.

I just spent two days among very smart, dedicated people who for five years or more have been struggling with a standard that like the ball of yeast dough in one of Leo Rosten’s stories has been bulging out of its container in a most scary way. NCIP started as a “circulation” protocol, but as happens with most library standards, it has been larded up with additional stuff to the point where it’s almost unrecognizable (and it’s going to be tough to fit the dough into a pan to go in the oven). This good group of folks has been kneading this ball of dough… with excellent effect… but they’ve inherited an old-school standards process that is shoving them around the kitchen in a most frustrating way.

I only have 20 minutes to blurb this out before a very crazy day begins, so here goes.

• Standards should never get in the way of interoperability… nor should they be confused with interoperability. A lot of times librarians think they want a product that is X-compliant, where X is a standard. But the standard is a means to an end; you really want interoperability and a bit of insurance against future change. We should know enough about standards to realize what we’re really asking for.
• Standards can’t take five years to come out of the oven. It is better to have a leaner standard that gets everyone moving (q.v. SUSHI) than a “perfect” standard that is irrelevant because everyone has already left the restaurant.
• For another thing, there is no oven. Trying to keep standards in sync with technology is like changing a tire on a moving vehicle. It’s a given that standards development has some lag time, and a reality check has to be built into the process. Standards have to be flexible enough to be extended as needed, or they are useless. (NCIP’s new proposed “any” tag is a huge step forward in that direction.)
• Some of our standards impose near-ridiculous  requirements. Look at SRU and CQL: achtung, the target must conform to the source! Come on, who’s zooming who? (Look at Z39.50. Look at MARC. I know, I’m making your eyes hurt.)
• We can’t keep designing standards around long, long lists of possible scenarios.
• We need to decide when a standard absolutely must be available — e.g. we need it in a year — and let that be a primary requirements restraint.
• We can’t keep insisting standards comply with one-offs. If you have the most amazingly unique circulation system in the world, then don’t lobby for that scenario in the standard; instead, lobby for a flexible standard that allows your chefs to whip up extensions. Eyes on the prize.
• Uncooked thought: we need to rethink the balloting process.
• De facto standards (such as Coins, and don’t make me spell out those stupid Studley Caps) need more study to see where and how they have been successful, so their practices can inform the standards process. What helps? Transparency? Broader discussion within librarianship? Iterative design? Put a standard in a Google Doc and let smart people whale away at it for a while to see what happens?
• Standards avoidance needs more study to see why this happens. When someone says to me that they are told to wait two years for a standard to address what seems like a central problem and they can handle the issue with web services, SOAP, and a REST-ful approach, we need to ask if they are just doing the responsible thing — taking a unique situation and addressing it locally — or if they are forced to avoid the standard to fulfill a crucial task (or avoid a fatal weakness).
• Vendors aren’t evil. Librarians aren’t saintly. Finger-pointing is pointless.  The user comes first.
• Plain English is a blessing.

Bookmark to: