{"id":52,"date":"2011-09-08T09:30:40","date_gmt":"2011-09-08T14:30:40","guid":{"rendered":"http:\/\/managemetadata.org\/blog\/2011\/09\/08\/fine-wine-and-old-fish\/"},"modified":"2011-09-08T09:30:40","modified_gmt":"2011-09-08T14:30:40","slug":"fine-wine-and-old-fish","status":"publish","type":"post","link":"https:\/\/managemetadata.com\/blog\/2011\/09\/08\/fine-wine-and-old-fish\/","title":{"rendered":"Fine Wine and Old Fish"},"content":{"rendered":"<p>Recently I retweeted the following:<br \/>\n\u201cnice quote &#8220;your data ages like fine wine, whereas your software applications age like fish&#8221; in @mattwall&#8217;s http:\/\/j.mp\/o8zsQG (via @edsu)\u201d<\/p>\n<p>Since then I\u2019ve been thinking about the important lesson encapsulated in those less-than-140 characters, and how we\u2019ve not really internalized this lesson in LibraryLand, no matter how many times we\u2019ve migrated data.  I remember many years ago, when I was working in the Cornell Law Library in the catalog card era, we were told by a university official that in case of fire, everyone should grab a shelf list drawer or two and head out the door.  We were pretty stunned by this instruction, but they\u2019d worked it all out\u2014that catalog was the biggest investment the library had, and the only way to re-create it after a fire (if for nothing else than to determine the insurance to be paid for all those lost books), was via that shelf list.<\/p>\n<p>Although a lot has changed since then, and most of those catalog cards were long ago recycled as scrap paper, the data they contained is (are?) still around, and still powering the online catalogs at Cornell. The catalog card drawers themselves were part of an ancient (and esthetically pleasing) piece of furniture, rescued from Boardman Hall, which was torn down in the 1950s to make way for Olin Library, a move many believe was a terrible mistake (Olin is the only modern building on Cornell\u2019s Arts Quad).  But I digress.<\/p>\n<p>Like most libraries Cornell used OCLC\u2019s services to create catalog cards, not paying much attention to the data being created as part of that process until well down the road.  Also like many, Cornell actually had a clutch of \u2018holding libraries,\u2019 physical spaces associated with particular schools and programs, each creating what was effectively it\u2019s own database via OCLC.  But unlike most, Cornell bit that multiple-records bullet early and when the data was loaded into NOTIS, there was only one iteration of a bibliographic record, with all the local \u2018holding libraries\u2019 attached to it. A mini-version of OCLC\u2019s \u2018master record\u2019, is one way to look at it, I suppose.  It was a sensible, if not particularly popular move, and we all had occasion later to thank our lucky stars we had crossed that bridge as a group, rather than as individuals, when we saw the headaches our comrades were coping with. <\/p>\n<p>My last data migration for Cornell was the one that moved data from the old NOTIS system to Voyager, and it was a year-long project that, if nothing else, reaffirmed my biases towards standard data.  Although, like everyone else, we had some standard data (MARC bibs and authorities) and a lot of non-standard data (acquisitions and circulation), the bibliographic portion was, we agreed, the most important part, because everything else \u2018hung off\u2019 that bib record. Clearly, the data remained where our investment lay\u2014by the end we weren\u2019t even installing new versions of NOTIS in all the modules we used (and the ones we did install turned out to be mistakes).  NOTIS was very old fish indeed by the time we moved to Voyager, and Voyager now, like most of the so-called \u2018new generation\u2019 of integrated library systems based on relational databases, is fast becoming a pungent geriatric fish as well.<\/p>\n<p>Enough of looking back (interesting as that can be).  The questions now revolve around how different we think our future will look.  Will we continue to use\/reuse our considerable legacy of data to build the services we want moving forward?  If so, what are the steps we need to take, to transform our legacy data to RDA or any other more modern packaging for our data?  We have a large number of value vocabularies as well as the MARC 21 schema we still rely on, which we will need to consider part of that plan for re-use. <\/p>\n<p>I\u2019ve seen a lot of \u2018new rules for data\u2019, but these are mine:<br \/>\n\t&#8211;Data should be able to be encoded in a variety of ways, to suit a variety of functions, uses, and systems<br \/>\n\t&#8211;Data should be managed at a granular, statement level, but also be available in a variety of record \u2018formats\u2019 (with records being understood as primarily an on-the-fly method of aggregating data for a variety of downstream users)<br \/>\n\t&#8211;Although current data is expressed mostly as text strings, data improvement strategies will be designed to change most of them to URIs as soon as practicable.<br \/>\n\t\u2014Data definitions and specifications will be easily available on the web, allowing mapping to be simpler and easier to tweak<\/p>\n<p>And the most important rule:<br \/>\n\t\u2014Never, never make data decisions to fit the system flavor of the month, and \u2018out\u2019 any system that degrades our data as the price of functionality<\/p>\n<p>This is not to say that the transition of our old data to what we need for a newer environment is going to be seamless, lossless or even easy.  It will be none of those things. But I would contend that it\u2019s not rocket science either, and we\u2019d be well advised not to indulge in needless hand-wringing until we\u2019ve explored the issues more fully.  Stay tuned &#8230;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Recently I retweeted the following: \u201cnice quote &#8220;your data ages like fine wine, whereas your software applications age like fish&#8221; in @mattwall&#8217;s http:\/\/j.mp\/o8zsQG (via @edsu)\u201d Since then I\u2019ve been thinking about the important lesson encapsulated in those less-than-140 characters, and how we\u2019ve not really internalized this lesson in LibraryLand, no matter how many times we\u2019ve [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[],"class_list":["post-52","post","type-post","status-publish","format-standard","hentry","category-futures"],"_links":{"self":[{"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/posts\/52","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/comments?post=52"}],"version-history":[{"count":0,"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/posts\/52\/revisions"}],"wp:attachment":[{"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/media?parent=52"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/categories?post=52"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/managemetadata.com\/blog\/wp-json\/wp\/v2\/tags?post=52"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}