Code4Lib Keynote 2011


Published on

Slides and notes from keynote for Code4Lib 2011, Bloomington, IN, Feb. 8, 2011.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • I began working in libraries in 1969 got an MLS in 1976I learned to type catalog cards on manual typewriters with card platens! Learned the indentation rules and the filing rules!I never had a cataloging course in library school, but during the massive retraining of catalogers for the implementation of AACR2 (1979/80), I finally had some formal training
  • Although I was a pretty good cataloger, I never got hooked on the details (I liked exploring ‘funny formats’)Instead I used my knowledge of library data to work in the geekier data areas of the library, including:LMS migrations for CornellMapping odd data files into MARC for importTesting data loads and managing import/export duties for the library’s MARC database
  • I started working on computers in 1973. I’ve witnessed (and participated in) most of the changes in libraries since thenAs a former cataloger who has worked successfully with programmers, I want to see more of that cross-cultural collaboration to make change happenAs a sometime educator of new librarians and [new and old] catalogers, I see increasing eagerness to learn how to operate outside the library siloSo what do I have to say to you, the most technically adept people on Planet Library?
  • At the Library Linked Data meeting at Midwinter, there was a discussion about how librarians (maybe even catalogers) ought to be working closely with programmersThis is a recurring theme—this month on RDA-L there was yet another discussion where catalogers/programmers talked past one anotherWhy does that keep happening? How can we change the conversation? How can we help catalogers and programmers to find (and respect) one another, and work together to make important innovation happen?
  • First, let’s look at the cultural divideWhat can we do to change that?
  • They often don’t know much about the technology underlying their tools, but they know their dataIn libraries catalogers (and metadata librarians) are physically and administratively separate from programmers and IT staffCatalogers and metadata librarians get their continuing ed at ALA, not in venues where there are many programmersThey’re used to looking towards the ‘big players’ for leadership and solutions
  • They know a lot about tools, but sometimes they have funny ideas about library dataThey speak some language that nobody else understands (especially catalogers)They like to ‘roll their own’ solutions and not operate within the often overloaded (and too often dysfunctional) library decision-making structuresThey like working below the radar
  • Karen Coyle and I have been doing a lot of training with catalogers one thing we’ve noticed is that catalogers get frustrated talking about the ‘issues’—they want to go directly to the concrete—to see what will ‘look’ differently for them in the RDA worldAs I lurk on Code4Lib and other discussions, I note some of the same irritationMaybe we have more in common than we think?
  • We tend to think that we can make things happen without working together, but I don’t think we can ...First we need to know what we don’t know (all of us), and figure out how to ‘Tear down that wall!’ (Reagan said that)We need to look around at the opportunities we have to make change happen (who said ‘never let a crisis go to waste’?)We need to look for intra-institutional ideas to replicate as well as ideas to share across LibraryLandBottom up rather than top down is more likely to get us where we need to be (if you don’t believe me, look at what’s happening at the top)
  • It’s important to talk about and create change first within our own institutions. The new sort of conversations need to start on a personal levelConsider that your institution will be making choices about technology, resource allocation, hiring, etc., within the next few years that will affect you …You need allies, not enemies
  • In the interests of cultural understanding …But the point is that you’re looking for COLLABORATORS … and perhaps growing your own
  • Catalogers who ‘don’t fit’ into traditional cataloging environments tend to gravitate towards the geek side of the business
  • We’ve always relied on institutions and professional organizations to teach us what we need to knowWhy not teach ourselves? We can think about organized classes or mixed, self-organized study groupsProgrammerscan teach about XML, RDF, etc.Catalogers can teach about vocabulary development, descriptive standards, etc.Regular group meetings to give everyone opportunities to present about (and discuss) projects, conferences attended, etc., build common understanding and improve communicationDepending on geography and budget, these opportunities can extend beyond one institution or one library ( These strategies are all about building common knowledge and personal relationships
  • Changing the conversation in one institution is only the startSome levels of learning through innovation are possible within the institution, others require a larger canvasThe important thing is that we not approach these opportunities as catalogers of programmers, but with both groups represented.
  • A common goal: better data to allow for provision of better services But we will still need to work with current software for N years? If we stop thinking of MARC as the basis for our work, but instead consider it a lossy exchange format, that should help? We have legacy data we need to move along with us We need to start as soon as possible to be able to create ‘native’ RDA dataThese two tasks can/should be done in parallel—This transition will last a LONG TIME
  • Libraries have only recently appeared on this diagramServices outside libraries (publishers, Amazon, the NYTimes, etc.) are creating and sharing useful data that we haven’t figured out how to use, partially because we’re still trying to cram it into MARCMost of our efforts in using data outside libraries has been with ONIX, publisher dataWe need to learn to use data that hasn’t been vetted by catalogers, and improve it in aggregate
  • We’re at a point where we need revolutionary change, not evolutionary change, and we should take advantage of the current tumultuous environment to start shaking things upA crisis is a terrible thing to wasteWe need to look to the potential represented by linked data and Semantic Web technologies to move aheadWe become increasingly marginalized if we keep waiting for everything to be ‘finished’, ‘ready’, complete, etc.
  • I’ve been ranting and raving about this for some time, it’s one of those ‘Emperor Has No Clothes’ momentsThose who don’t want change have been reassured that RDA can work within the MARC recordThose who do want change now think that RDA does not represent ENOUGH change to be worth the investment. If all you’re looking at is the guidance instruction, it’s difficult to see the real potential, and the possibility for real change
  • We need to recognize that the 800 lb. gorillas of our world have a vested interest in keeping things the way they are—their investment in MARC is considerable—they are probably incapable of leading us into our future (mostly, they’re holding us back)Their innovation is around the edges, and they’ve not confronted the age and infirmity of their business modelsLMS vendors are waiting to see which way the wind blows, most have no idea about RDA, only that it’s very similar to MARC (!)If anything is going to change, we have to do it ourselves
  • Many traditional catalogers are still grieving for a simpler world, where there was one ‘format’ and we were the expertsThere hasn’t been enough attention paid to RDA as the starting point for a replacement for MARC (though I’ve heard a rumor that LC might be thinking along those lines, finally)Catalogers actually like MARC, so we know why they want to keep itBut what’s the reason that techies have been so detached from this development? Because, in the end, if not RDA, then what?
  • The slow uptake of the RDA Vocabularies holds us all backCatalogers have a difficult time understanding the new concepts we are trying to get acrossWe have little that is concrete enough to show (catalogers tend to become impatient with the abstract parts)They tell us that they need to see a clearer demonstration to understand what we’re telling themWe need help with this!
  • Example: Karen Coyle has been looking for ways to build the parallel SKOS/RDFS expression of MARC And we’d both like to be able ‘fill in the gaps’ to be able to demonstrate better how RDA might be mappedExample: The DCMI/RDA TG will be moving ahead on Application Profiles for RDA—we could use some help to make progress on thisThe Open Metadata Registry will (we hope) be available to help us build the APs and maps, but we’ll need more techie smarts to work through the issues and build some demos
  • Libraries in Europe have already moved ahead (ask them to tell you what they think about ‘RDA Testing Theater’)Take a look at the DNB efforts should have closure on the RDA Vocabularies work by ALA Annual—we need people to experiment with it!IFLA’s work on the ‘FR Family’ is moving in interesting directions, likely to result in usable mappings very soon
  • We need ways to collaborate across institutional and cultural boundaries to make change happenCode4Lib is a great model, but can it be re-used? (Jen Eustis, blogging as Celeripedean, asks why there isn’t a Metadata4Lib) How do we get the catalogers who gather at ALA to talk to the techies at Code4Lib?Is there any interest in more formal structures, or is informal the best option? Can we talk about that here?
  • Code4Lib Keynote 2011

    1. 1. Code4Lib 2011, February 8<br />Critical Collaborations<br />Programmers and catalogers? Really?<br />
    2. 2. Old Familiar Cataloger Tools<br />
    3. 3. Obviously not<br /> a real cataloger<br />
    4. 4. WHYME?<br />I’ve been working with <br />computers in libraries <br />since 1973 …<br />But is that enough?<br />P.S.: I don’t write code …<br />
    5. 5. I<br />Programmers<br />
    6. 6. I<br />Programmers<br />Naomi Dushay<br />
    7. 7. I<br />Programmers<br />Naomi Dushay<br />George Kozak<br />
    8. 8. I<br />Programmers<br />Naomi Dushay<br />George Kozak<br />Pete Hoyt<br />
    9. 9. I<br />Programmers<br />Naomi Dushay<br />George Kozak<br />Pete Hoyt<br />Jon Phipps<br />
    10. 10. So … Why Am I Here?<br />Catalogers and programmers have a history of talking past one another<br />How can we change that?<br />I have ideas!<br />XML<br />OY<br />SPARQL<br />MARC<br />RDF<br />
    11. 11. Separate Tables<br />What do we need to do to start sitting together?<br />
    12. 12. Only some of the stereotypes you’ve <br />heard about catalogers are true<br />Like in most professional groups,<br />there are important variations<br />
    13. 13. On the other hand, maybe all the<br />stereotypes about programmers<br />are true?<br />But I’m sure I’ve talked about the<br />weather with programmers!<br />
    14. 14. Quiz: Which group is more likely to want to go to the <br />‘nitty gritty’ first (whether or not they’ve had a chance<br />to agree on the basics)?<br />▢<br />Catalogers<br />▢<br />Programmers<br />▢<br />All of the above<br />
    15. 15. Are We Getting Anywhere?<br />
    16. 16. Small Starts/Big Goals<br />Starting to talk about change within your institution<br />What are our priorities? Do we have common priorities? <br />
    17. 17. Inside the Cataloger Brain<br />Real catalogers think (and talk) in MARC tags. <br />Their job is to fit the thing in their hands into the panoply of other cataloged items<br />The happiest catalogers are those who are at one with their rules and practices<br />Ergo, look for competent, but frustrated catalogers<br />
    18. 18. Finding Frustrated Catalogers<br />Clue: May be a catalog maintenance or authorities librarian<br />Clue: May have had some experience with data that isn’t MARC<br />Clue: May have done some crosswalking and mapping<br />
    19. 19. Are we waiting for some 800 lb. Gorilla to teach us what we need to learn?<br />Or can we learn from one another what we need to know?<br />One model:<br />
    20. 20. Setting Priorities<br />Changing the conversation<br />Building new tools<br />Doing it together<br />
    21. 21. Better Data = Better Services for Users<br />Legacy<br />Data<br />Prospective<br />Data<br />POINTS OF TENSION<br />Current OPAC users (internal and external)<br />
    22. 22. Libraries<br />Linking Open Data cloud diagram, by Richard Cyganiak and AnjaJentzsch.<br />What about all this other stuff?<br />
    23. 23. Where we are now?<br />What are we doing about it?<br />
    24. 24. RDA Testing Theater<br />What we tested: whether the RDA rules could be crammed into MARC<br />What we should have tested: whether we can meet the needs of our users better with a different approach to data<br />Result: The cataloging world outside the US thinks we’re nuts<br />
    25. 25. Waiting for the Gurus to speak<br />Libraries currently live in a top down world—how well is that working for us today?<br />If we want a bottom-up world, we need to build it ourselves<br />Consider the RDA Vocabularies--built by a small group, with the potential to change how we work<br />
    26. 26. ReadMe<br />
    27. 27.
    28. 28. Where Are The Tools?<br />
    29. 29. RDA/IFLA/other properties (minimal linkage)<br />format<br />Extent<br />has extent<br />Extent (/S)<br />has extent of the carrier<br />has extent (R/)<br />Extent of text<br />Extent (M/)<br />has extent of the carrier (M/)<br />Extent of text (M/)<br />SameAs<br />Subproperty<br />numPages (D/l)<br />numVolumes (C/l)<br />Note: Document sub-class-of Resource<br />Label (Domain/Range)<br />RDA<br />FRBR<br />ISBD<br />DCT<br />BIBO<br />Classes: Manifestation, Resource, Collection, Document, SizeOrDuration, literal<br />FRBR lite<br />ISBD lite<br />DC<br />
    30. 30. New World Data<br />Reusing legacy data in a different environment will require significant investments in data improvement, and systems that will provide support for that transition<br />XC has started, but others need to work in this area <br />We need to look at the issues of prospective data creation and reuse of legacy data in parallel<br />Our new world is more distributed, more diverse, offering us data that hasn’t been vetted by catalogers<br />The only rational way to deal with that data is at the statement level, not the record level<br />
    31. 31. Our Challenges<br />Managing statements, not records<br />Integrating data from a multitude of providers, including users<br />Developing new models of distribution and data sharing, less centralized<br />This includes identifying and sharing more granular WEMI info, with relationships!<br />Demonstrate that the costs of NO CHANGE are significantly more than the costs of CHANGE<br />
    32. 32. Can We Get More Comfortable With One Another?<br />
    33. 33. Can We Do More Than Get Along?<br />Thanks for your attention!<br />Email:<br />Blog: Metadata Matters<br />Thanks to Gordon Dunsire for the ‘FR’ slide, and to Flickr members clover_1 and annagoben (among others) for the photos. Thanks to the Virtual Museum of Cataloging and Acquisitions Artifacts and the RDA Happy Fun Time Companion.<br />