Library Journal Mobile
Log In  |  Register          Free Newsletter Subscription
Subscribe to LJ Magazine
Email
Learn RSS

Tennant: Digital Libraries   



Link This | Email this | Blog This | Comments (4)


"Quick Fixes" Are Often Neither

June 29, 2009 I've been inspired to write this post based on a discussion on the Code4Lib list about embedding HTML in MARC records. Even worse, perhaps, it turns out that the actual use case was to embed an image of a line of text that would be used in a catalog display. I'm telling you, I can't make this stuff up.

I'll get to the reasons why this is wrong, but first I'd like to acknowledge the motivations behind this "fix". A fix like this often comes from a library's inability to control the end-user display like they wish to. The vendor may not provide enough flexibility to do this, and/or the library may not possess the technical knowledge required to accomplish it in a different way than embedding HTML in a MARC record. Frustrated, they turn to a "solution" that is ill-advised but is seen as a "quick fix".

As someone who has at times been on the downstream end of such "quick fixes" I can tell you that you could easily be creating a world of hurt. MARC already includes much more "display" markup than it should, which is why we often end up standing on our heads to repurpose the metadata for needs other than a card catalog-like display, for which it was intended. International Standard Bibliographic Description (ISBD) punctuation may have been necessary in the paper card era to allow someone to "visually parse" the metadata, but in the computer era it is almost certainly indefensible to a computer scientist. We should not compound our early error by adding display markup to what should simply be a structured metadata container.

There are other things I would try before being pushed to this extreme:
  • Reconsider whether you really need to do this. If no one else is doing it, and the vendor is less than willing to allow you to do it, shouldn't this tell you something? How important is it to the end user?
  • Reconsider whether this is the only way to do it. Carefully consider all the various options for achieving your goal. Try to pick the least invasive method.
  • Consider a Javascript framework like Juice (suggested by Tim Hodson on the list) to insert elements into a page based on what is on the page.
  • Marshall your forces. If this is really important to end user services and you can see no other better way to achieve it, work with the other customers of your ILS to see if they will support your request to make a change that will allow you to achieve your goal without inserting HTML in the records.
If you really see absolutely no other way to do this:
  • Keep it as simple as possible.
  • Create a valid string of HTML. Do not leave any open tags, for example.
  • If you must make a change to the markup, change it in all of the records. Do not vary practice over time. Every entry must be consistent to allow for global changes (or removal) down the road.
  • Understand that you must remove this if/when you ever share these records. This includes when you offer records for metadata harvesting via OAI-PMH.
  • Know (and test) your exit strategy. You (or your successor) will likely need to remove this at some point in the future, so know how you will do this and try it out first. I suggest using Terry Reese's excellent MarcEdit to try a batch process cleanup.
By now I hope it's clear that this should not be taken lightly. Mixing metadata with display elements flies in the face of common wisdom that the separation of the data from the instructions for its depiction allows the greatest flexibility -- both now and in the future. Before throwing this away be very sure it is required and that there is no better way to accomplish it.

Posted by Roy Tennant on June 29, 2009 | Comments (4)


Industries: News & Features
Email
Learn RSS

June 30, 2009
In response to: "Quick Fixes" Are Often Neither
Lukas Koster (Library of th eUniversity commented:

Couldn't agree more!




June 30, 2009
In response to: "Quick Fixes" Are Often Neither
Jennifer Parsons commented:

Just so you know, this article has been posted by Lukas to Twine (my link was vetoed by LJ; otherwise I'd post it.)

An excerpt from my comment there: "Please, catalogers and metadata librarians: the glories of "universal access" upon which librarians build their dreams begin with you and your work. Attempting to clumsily embed markup in a much older format does not make you more relevant."




July 2, 2009
In response to: "Quick Fixes" Are Often Neither
Edward M. Corrado commented:

I agree that if there are other ways to do this, it is better to go that route, but I think you dismiss some very creative uses of MARC records inside proprietary, inflexible systems by labeling them quick fixes. For example, I know of a library that has been able to provide access to digital collections for over 10 years by including HTML in the MARC record - long before commercial digital library systems were available (let alone affordable).

The point is librarians need to do the best they can to provide meaningful access to their resources and if doing something slightly non-standard is the way to do it - they should do it instead of waiting years for a solution to the problem.

What I do agree with you, and mentioned on the code4lib list, is the exit strategy. Of course, in this day in age, any technical decision and/or purchase should come with a exit strategy.




July 2, 2009
In response to: "Quick Fixes" Are Often Neither
Roy Tennant commented:

Good points, Ed, and I guess that's why I included strategies to do quick fixes right if you feel compelled to do them -- sometimes it's important and there really isn't another way. I just want people to make sure there aren't alternatives before going down this path.





POST A COMMENT
Display Name or Registered Users Login Here.
Please restrict submissions to less than 7,000 characters (including any HTML formatting).

Change Image
Before submitting this form, please type the characters displayed above.
Note the letters are NOT case sensitive.

Advertisement
Advertisements

©2009 Reed Business Information, a division of Reed Elsevier Inc. All rights reserved.
Use of this Web site is subject to its Terms of Use | Privacy Policy
Please visit these other Reed Business sites