Grab a bucket! It's raining data!
5 likes4,688 views
This document is a transcript of a talk given by Dorothea Salo titled "Grab a bucket! It's raining data!". In the talk, Salo discusses several key points about research data: - There is a huge volume of research data being created, but it is diverse in nature and technical environments. Data needs to be interacted with and used, not just stored. - Much existing data is already "out there" and was created without long-term preservation in mind. Libraries will need to actively preserve this data. - Data comes in many formats, including analog materials like lab notebooks that should be digitized. Data is also often created for specific projects using various tools.
Grab a bucket! It's raining data!
- 1. Grab a bucket! It’s raining data! Photo: http://www.flickr.com/photos/peasap/655111542/ Dorothea Salo University of Wisconsin Access 2009 Hi there. Thanks very much to Mark Leggott for inviting me here, and to all of you for lending me your ears for a time. Youʼll have noticed that the title of this talk in the program notes is very formal and buttoned-down. ʻRepresenting and managing the data deluge.ʼ Well, okay. I am not a formal and buttoned-down person, but when Mark approached me to speak here, I was actually scared to death to accept, and so I wrote this really terribly boring title -- so like Peter, I just up and changed it. The REAL title is ʻGrab a bucket -- itʼs raining data!” To hear some folks tell it, itʼs a golden age to be a digital librarian. Here we have an entire new form of scholarly publication -- digital research data -- and itʼs ours for the asking! In times when weʼre all worried about the future of libraries (and, letʼs face it, librarians), this feels heaven-sent. Grab a bucket, itʼs raining data, hallelujah!
- 2. the... Painting: “Cassandra,” Evelyn de Morgan Photo: http://commons.wikimedia.org/wiki/File:Cassandra1.jpeg of Open Access In some quarters, I am now styled the “Cassandra of Open Access.” Cassandra, for those not up on their Greek myth, was a Trojan prophetess who was cursed such that nobody believed what she said until it was too late. Being from Troy, which was of course completely doomed, most of her prophecies were fairly dire, too. “Hey, the Greeks are about to wheel a big wooden horse into your city so they can burn it down and kill everybody!” Not happy-making stuff weʼre talking about.
- 3. I’ve got nothing against but the reality was... Photo: http://www.flickr.com/photos/y2bk/528300692/ Some people have mistaken my Cassandra-nature for an onus against open access generally and institutional repositories in particular. Iʼve never had it in for open access! Who doesnʼt like open access! Itʼs similar to what Cory said yesterday, itʼs hard to be against an unambiguous good like open access without sounding like a total jerk... which hasnʼt stopped some publishers, of course. (*CLICK*) But Iʼve been running institutional repositories for close to five years now and the on-the- ground reality has been quite a bit...
- 4. ... blurrier. goals? means? something for nothing? fit between content and container? fit between user needs and system? and so now, I may be becoming Photo: http://www.flickr.com/photos/jennsstuff/2965783700/ ... blurrier. Conflicting, contradictory, and in some cases flatly impossible goals. Minimal means, because of people who seem to have been reading the mythical “Frommerʼs Institutional Repositories on $5 A Day.” Asking for time, effort, and data from faculty without giving them any real service or any return on their time investment that made sense to them. We crammed things into IRs that just didnʼt fit with the very limited IR view of the digital universe, just because we hadnʼt anywhere else to put them: our content didnʼt fit in the container we had. And we completely ignored faculty needs and desires. Iʼm seeing some of the same thought and design processes happening now with regard to e- science, e-research, cyberinfrastructure, data curation, whatever you want to call it. And this troubles me. So I canʼt help but wonder if Iʼm becoming...
- 5. the... of Data Curation? But, optimistically, itʼs early days yet. Thereʼs no reason we have to make the same mistakes with data that we made with IRs. So, I donʼt want anyone to think that Iʼm raising the problems Iʼm going to raise in this talk because Iʼm somehow AGAINST research data curation, or I think libraries shouldnʼt get involved with it. I am all for research-data curation, and I believe very strongly that libraries need to get involved. I just think we should know what weʼre getting ourselves into, and if that means Iʼm a little Cassandraic, okay, so be it.
- 6. goals? means? something for nothing? fit between content and container? fit between user needs and system? I could spend hours talking about all these things, but I guarantee that nobody here wants to listen to me for hours. So Iʼm going to focus this talk on the fit between content and container, though I may touch on other things. Iʼm going to examine some of the qualities of typical research data, then talk about digital libraries and IRs, looking hard at some of the impedance mismatches weʼre liable to run into, and maybe strategize a little bit about how to make ourselves and our systems better now, before we run headlong into another mess. And the lens Iʼm going to be looking through is a human lens, not so much a technological lens. THIS IS NOT JUST A TECHNOLOGY PROBLEM, I canʼt say that loudly enough.
- 7. What do we know about data? Photo: http://www.flickr.com/photos/kentbye/2053916246/ So what do we know about research data, speaking very broadly and generally?
- 8. There’s a lot of data. Photo: http://www.flickr.com/photos/noelzialee/2126153623/ Richard talked about this yesterday, but Iʼll just reiterate: Even if we admit that the Large Hadron Collider types are probably going to take care of themselves -- and this isnʼt something I necessarily admit; I know huge, well-funded projects that are making huge messes with their data -- even if we admit that, weʼre still looking at an incredible flood of stuff. Have we got big enough buckets? I dunno. At this juncture I feel it incumbent upon me to say the word “cloud.” Cloud. There. I have said it. I now feel no need at all to say it again. Look, I understand that storage and networking are problems that have to be solved before we can do anything else. I get that. Just -- to me, itʼs necessary but not sufficient, even though it seems to be getting all the attention right now. So Iʼm going to move on to characteristics of research data that Iʼm more interested in.
- 9. Photo: http://www.flickr.com/photos/jonevans/1032687817/ Data are there to be interacted with. One thing I think we need to keep in mind about data is that they are not an end in themselves. We donʼt keep data just to keep data; we do it because researchers can pick up shovels and dig around in the sands and build knowledge like sand castles! Data are there to do things with. To be examined, cleaned up, verified, refuted, corrected, number- crunched, mashed up with other data, graphed, charted, visualized... and if we treat them as though they were unchangeable museum objects -- look but donʼt touch, like books chained to a medieval lectern -- we are actually getting in the way of making new knowledge. If nobody can do things with data, there is no point in keeping them! Thatʼs what CC0 is about, as Richard mentioned in his Q&A session yesterday: removing legal barriers to messing about with data. We, we librarians, need to remove TECHNICAL barriers to messing about with data. Whatʼs more, different kinds of data have different affordances. You donʼt use a plastic sand-shovel to dig a rock quarry, just the way you donʼt use a backhoe to build a sand castle. The way a sociologist interacts with census data is just wildly different from the way a medical researcher interacts with MRI data. The data buckets we build will have to internalize and respect those affordances, or at the VERY least allow RESEARCHERS to build tools on top that respect those affordances.
- 10. Data are wildly diverse in nature... ... as are their technical environments. Photo: http://www.flickr.com/photos/28481088@N00/670258156/ In other words, data are diverse, so the buckets we put them in will need to be different shapes and colors in order to respect that diversity. Now, differences in data can sometimes be skin-deep. The difference between a digital image of a sculpture and a digital image of a physics field station in Antarctica is in some ways not much for our purposes, however different our researchers may think they are. But sometimes the differences really do matter. You canʼt treat a book in TEI markup the same as a book of page-scanned images; you will be doing violence to readers of one or the other. A microscopy researcher on my campus does cell sections digitally; you can train a microscope to focus from the top of the cell all the way through and down, and then you can create a 3D cell image to play with. Itʼs really cool! But a system that treats each section image as a wholly separate and unrelated thing (*cough*DSpace*cough*), is making it impossible to get any knowledge out of those data. Think for a moment about a single bucket that works for the TEI book, the book of page scans, the images of the Antarctic field station, and the microscopy data, and youʼre starting to realize the scope of the data-diversity problem. Again, we donʼt control the technical environments our researchers are using to generate data. Some of those environments are proprietary, and Mike Rylander talked yesterday about why thatʼs a dangerous, dangerous problem. But even leaving that aside, if weʼre really, really lucky, we might have a chance to make recommendations to researchers about their data. For the most part, though, WE are the ones who will have to adapt to whatever theyʼre doing.
- 11. Data are already out there. Photo: NASA (via http://nasaimages.org/), “Multiwavelength M81” Why is that? Weʼre not creating all the digital research data out there; the researchers are. And theyʼve created it in huge volumes already. So Iʼm really interested when Dan Chudnov says that the Library of Congress is working to capture data at world-scale and web-scale, because I want them to teach ME how to do that. So, researchers. Theyʼre not thinking long-term about the data theyʼve created. Theyʼre not thinking past the expiration of their next grant! That means we have to. Weʼre the only people with a long- term time horizon. Furthermore, theyʼre not gonna come to us; for the most part they canʼt even imagine that we can help. The inescapable corollary here is that we canʼt just sit back and wait for data to come to us -- a lot of it weʼre going to have to go out there and rescue! And I may be airing some library dirty laundry here, in which case, forgive me, but itʼs not just them -- itʼs us. WE have plenty of unsustainable digital projects sitting around our libraries. Just think for a second: how many different digital-library, repository, and storage platforms are running inside your library? I wonʼt even answer for mine; itʼs a scary large number. The stuff in those platforms is in danger. We made this mess, we librarians; we have to clean it up. As Richard said yesterday, we have to set an example with our own data! How are we going to establish ourselves as authorities in describing and organizing data if our own datastores are not in order?
- 12. A lot of data are analog... ... but really want to be digital. Photo: http://www.flickr.com/photos/mrbill/3452943573/ So, right, back to research data. (read slide titles) For example, scientists still use paper lab notebooks. I wish they didnʼt too! The university archivist on my campus really wishes they didnʼt, because they keep trying to give him hundreds of boxes of lab notebooks that he canʼt possibly find space to store! And thatʼs just one example. Linguistic field notes, on paper. For one of the linguists Iʼve talked to, her notes are some of the only attestations of the language we have! Slides are a bugaboo in visual arts communities. Faculty have a tremendous volume of analog materials that would be much, much greater use if they were digital. Can we scale up to that? Again, I donʼt know, and Iʼm not going to talk about this problem again. Itʼs there, we probably need to solve it, end of story.
- 13. Data are project-based. http://www.exploringthehyper.net/ Aha. Now we get interesting. This is a dissertation; you can look at it at ʻexploring the hyper dot netʼ. It includes the underlying data (read “Explore” text). As you may be able to see at bottom right there, itʼs built on the blogging tool WordPress and the Center for History and New Mediaʼs exhibit-builder tool called Omeka. These are great tools! I love them both. But what are we librarians going to do as our dissertators pile random webtools on top of each other to build their dissertations? Thatʼs what project-based thinking gets you: total technological randomness. But our researchers think in terms of projects. The latest grant. The latest collaboration. And when it comes to technology, theyʼre not above doing something different and sui generis for every single one.
- 14. Data are sloppy. Photo: http://www.flickr.com/photos/midorisyu/2622024163/ By the same token, faculty are not librarians. They are messy, messy people, a lot of them. Many more of them leave petty chores like, I donʼt know, organizing research materials and results -- they leave that to their grad students. This means that our data buckets are not going to fill up with nice neat orderly well-described, data-dictionaried columns of numbers. Honestly, what weʼre doing is catching sloppy leaks, and we can expect to be for a long, long time. And when our systems, library systems, only accept data thatʼs clean and pretty, we have a problem. In a word...
- 15. Data aren’t standardized. Photo: http://www.flickr.com/photos/mikewade/3463334719/ ... data are not standardized, most of them. Thatʼs not even seen as a desideratum by data creators yet. I know most of us know this, but in the print world, the journal-article-and-book world, we have publishers to impose some kind of uniformity. Data doesnʼt live in that kind of world. We may yet get there, but honestly? I donʼt expect it in the length of my career. Thatʼs our trawl through some basic characteristics of research data. What do we have in libraries to throw at this problem?
- 16. Our Big Bucket: the digital library People think that primary-source data, even big data is a new thing to libraries. Itʼs not. We were doing big digital data before the researchers were, in the form of the digital library! What did I hear yesterday, ten terabytes of TIFFs from a single digitization project? So itʼs possible to think hey, weʼve got this solved! We just apply our existing digital-library infrastructure, human and technological, to this new problem.
- 17. Our other Big Bucket: the institutional repository If thatʼs not enough, at the same time, weʼve been building another kind of digital bucket; weʼve called it the institutional repository. And again, some people think that IRs just solve the data problem. Magic IR pixie dust! Or something...
- 18. Photo: http://www.flickr.com/photos/peasap/655111542/ Impedance mismatches Well, it wonʼt surprise anyone that I donʼt think thatʼs true. There is no magic pixie dust for research data curation, not in digital libraries and not in IRs. What weʼve done with digital libraries and IRs gives us a lot of the skill and knowledge we need to work with research data; I firmly believe that, though itʼs hard to find researchers who do. But weʼre going to have to do a lot of rethinking and reworking the way we do things. Otherwise, weʼll just trip all over ourselves and the impedance mismatches between the characteristics of research data and the characteristics of digital libraries and IRs. So letʼs take this a piece at a time.
- 19. What do we know about these? Photo: http://www.flickr.com/photos/schex/193912573/ Digital libraries. You know, I love this picture, because theyʼre so proud of being digital. National DIGITAL Library. Where I am, weʼre trying to rebrand our digital collections, because we donʼt think “digital” should be what linguists call a ʻmarkedʼ state any more. Digital is ordinary, or it should be. Digital is normal. So given that, how DO you brand digital collections? --If you have an idea, see me after, okay? Anyway, what are digital libraries like? And how is that going to work with research data?
- 20. Carefully built and tended http://www.collectionscanada.gc.ca/naskapi/index-e.html Just like our print libraries, weʼve built our digital libraries carefully, out of the best materials. Weʼre not making digital libraries out of any old thing; we SELECT what weʼre prepared to lavish effort on. And we do lavish effort! Look at this site! Itʼs a lexicon of a First Nations language, itʼs been translated INTO that language, including the fonts to represent that language -- I love this site! Itʼs beautiful!
- 21. Data are already out there. Photo: NASA (via http://nasaimages.org/), “Multiwavelength M81” How are our thoughtful, careful collection-development policies going to cope with whatʼs already out there? How will we decide what we pick up and what we leave behind? I already see troubling signs that in the absence of better policy, cyberinfrastructure shops are deciding to help whoever has money. I donʼt like that trend and hope we in libraries challenge it. When I go to data curation workshops, most people think of data curation as “the new special collections” or “the new archives.” Understanding that we canʼt keep everything, theyʼve come up with elaborate decision mechanisms for figuring out what to keep and what to toss. Well, I think thereʼs a problem with that. Itʼs a human problem. Itʼs the faculty member who, when told youʼre not going to curate his lousy badly-designed badly-described dataset, turns around and never darkens your door again -- even when heʼs got a dataset that will revolutionize his field. How do we harmonize the need to provide good service with the need not to swamp ourselves with garbage? I donʼt know, and I suspect answers will differ, but I do know we need to figure that one out.
- 22. Data are sloppy. Photo: http://www.flickr.com/photos/midorisyu/2622024163/ How are we going to rescue data when, by our standards, a lot of it is sloppy? Are we prepared for the work involved in rescuing other peopleʼs sloppy data? Are we prepared to let other peopleʼs sloppy data in alongside our nice clean pretty data?
- 23. Data are project-based. http://www.exploringthehyper.net/ Are we going to pick and choose among projects? Based on their software platforms? Can we? What about dissertations, which are institutional records no matter HOW theyʼre created?
- 24. Carefully built and tended So weʼre going to have to rethink how much and what kind of care we can and should give our data libraries. Like it or not, they canʼt all look as beautiful as this; volume and condition forbid.
- 25. Production is a Taylorist’s dream. Photo: http://www.flickr.com/photos/villeneuve53/1808995620/ Where Iʼm from, and perhaps where youʼre from too, we like our production of digital objects, mostly but not entirely through digitization, to run like a well-oiled machine. Just like the factory floor Peter talked about. Itʼs generally more cost-effective to do things in large volumes and in systematic ways. In the States, we call this a Taylorist way of going about things -- for those who donʼt read management literature, Frederick Taylor was the guy who taught Henry Ford how to run auto production. Taylor measured how long it took people to do things, and made it so people had to make the fewest and smallest motions possible to get the work done. What Taylorist production methods mean in a digitization context, of course, is that you tend to limit the type of work that you do to what you can easily automate and train for, which in practice means only a few kinds of data per library. We do our image collections or our newspapers or our finding aids or our text collections -- we in essence specialize ourselves by data type, again for efficiencyʼs sake.
- 26. Data are wildly diverse in nature... ... as are their technical environments. Photo: http://www.flickr.com/photos/28481088@N00/670258156/ How well is that going to serve us when weʼre not in control of the data-creation process? When the data donʼt fit into the buckets weʼve designed for our own particular digital-data specialties? If weʼre going to come to grips with data on an institutional basis, we wonʼt have the luxury of specializing any more. How are we going to cope?
- 27. Data aren’t standardized. Photo: http://www.flickr.com/photos/mikewade/3463334719/ How can we be Taylorist about gathering and describing data when the data just arenʼt standardized? And if we canʼt be Taylorist about it, how do we keep up with the flood?
- 28. Data are project-based. http://www.exploringthehyper.net/ How are we going to manage when thereʼs a technical-infrastructure mismatch between their project silos and our Taylorist, tailored environments? We have some choices, but none of them are particularly good. Do we pull the data out and start over, ignoring the effort put in on the original interface? If itʼs on the web, do we take a static snapshot of the original? That feels a bit to me like pinning a gorgeous butterfly through the head, killing it, to display it in a glass case, though I have to admit that I do it because I donʼt necessary have a better option. Do we recreate the original interface, and take on the work of maintaining and improving it? Those donʼt sound like Taylorist processes to me! Iʼm frightened -- honestly scared to death -- at how many librarians do not realize that this is a problem. They really seem to think that you wave a magic wand over somebodyʼs random dataset and it miraculously shows up in a repository! It does not work that way! For every new input, somebody has to figure out whatʼs in there, how best to represent whatʼs in there on the repository technology platform (whatever that is), and how to move the old representation into the new one. That... looks suspiciously like work. No, look, I do it -- trust me, itʼs work.
- 29. Production is a Taylorist’s dream. Photo: http://www.flickr.com/photos/peasap/655111542/ Where I work weʼre starting to think and talk very seriously about this, because our digital-library processes are very Taylorist, and weʼre realizing that thatʼs not serving us well as smaller and more specialized projects come our way. Everything right down to how we BUDGET PROJECTS is going to have to change. Honestly, weʼre finding this a struggle -- but a necessary one, and one that I am proud to say that weʼre confronting head-on.
- 30. when it isn’t a Taylorist’s nightmare. Photo: http://www.flickr.com/photos/elsie/97542274/ Some of you are looking at me right now with utter bemusement. Your digital-library production isnʼt Taylorist at all! You only WISH it were. What it is, is completely ad-hoc. Something interesting comes in, you build a way to deal with it, you slap it up on the Web somehow or other, problem solved.
- 31. Many digital libraries are project silos. http://www.brown.edu/Departments/Italian_Studies/dweb/dweb.shtml And thus are born project silos, both inside and outside libraries! One of the problems with project silos is that they arenʼt replicable across libraries and institutions... and the last thing any of us need is to reinvent the wheel! If youʼve never looked at Decameron Web, I love it, check it out -- thereʼs some nice TEI-based UI in there. (Google for it; the URL is really long.) But I canʼt build DanteWeb or CervantesWeb based on DecameronWeb; the innards of DecameronWeb are opaque to me. It should be easier. And another problem: project silos arenʼt part of the web. (Hi, Dan Chudnov.) Itʼs what I saw called a “cabinet of curiosities” in an article I was reading. Nice to look at; impossible to really work with. Now, this isnʼt entirely the fault of library technology. Itʼs partly the fault of librarians who natter on about “context” as though it were the be-all and end-all. My belief is that context is fluid, not fixed; itʼs constantly being built and rebuilt, rather than something trapped like a fly in amber. We have to expose our digital objects so that they can appear in entirely NEW contexts. Thatʼs not decontextualization! Itʼs RE-contextualization, and cabinets of curiosities donʼt allow it.
- 32. Many are content-specialized. Presentation is content-specific. For each project silo, its own user interface. Books browse differently from maps, which browse differently from finding aids. Right? I wonder. How can we maintain all this UI code? Now, Iʼm the last person to tell you to build The One User Interface To Rule Them All. Not possible! As I said earlier, data have affordances, ways they want to be interacted with, and we absolutely need to respect that. However, itʼs possible to go too far in the other direction, building interfaces so content-specific that the content winds up in a cage of jargon and non-interoperability. Thatʼs where I think we are in digital libraries, and itʼs a problem.
- 33. Data are project-based. http://www.exploringthehyper.net/ These practices have a lot in common with what our researchers do! Everything is its own project with its own technology stack and its own silo. Well, this isnʼt workable. Itʼs wasteful duplication of technical effort, for one thing; why build -- oh, a tagging infrastructure -- more than once? It also creates huge headaches for discovery processes and especially for digital preservation. The more interaction you have to preserve, and the more different ways itʼs coded, the more lines of code weʼre all maintaining, and who needs more lines of code to maintain? But itʼs happening anyway, and if weʼre serious about data weʼre going to have to deal with the result.
- 34. when it isn’t a Taylorist’s nightmare. Photo: http://www.flickr.com/photos/elsie/97542274/ Now Iʼm going to go a little Cassandra on you -- we have already lost a lot of digital projects to the project-silo problem, particularly in the digital humanities. Some of those projects were ours: developed in libraries, but not sustainably. I predict with absolute confidence we will lose more such projects. There is a crying need for academic librarianship to develop a coordinated, collaborative rescue effort for early digital projects, if only to stem the bleeding. On a happier note, if we DO take the trouble to rescue our own projects, we will learn a LOT about rescuing other peopleʼs. I think that that learning process all by itself should be incentive for forward- thinking academic libraries and librarians to start undertaking rescue efforts. So thatʼs where we are with digital libraries, and where I think our practices are going to come up short in the new data world.
- 35. What do we know about these? What about institutional repositories?
- 36. We’re caged up inside our institutions. Photo: http://www.flickr.com/photos/annia316/115439737/ Well, first you need to understand what Stevan Harnadʼs cat was hunting. No, okay, seriously. (*CLICK*) The word “institutional” is becoming a serious problem. I would argue it always was. In my worklife, if I run into digital objects needing archival, I cannot go anywhere near them until I prove a link to one or more faculty members in my home institutions, and the weaker that link is, the more red tape and bureaucracy I have to go through to get permission to help with the project -- no matter how important I think that project may be.
- 37. Data are already out there. Photo: NASA (via http://nasaimages.org/), “Multiwavelength M81” The problem is most acute for already-existing data. For example, think about what happens when a researcher leaves your institution for a different one. Their institutional web presence tends to remain behind. There may be valuable data there. But can the IR get involved, if the researcher doesnʼt have a connection to the institution any more? And, of course, it means that data at institutions without IRs just fall between the cracks. Definitely not ideal, not what we want.
- 38. Data are sloppy. This is another aspect of data sloppiness. A lot of them donʼt clearly belong to one institution, or indeed to ANY one institution! Consider something like a disciplinary data or e-print repository. One of those just came up for rescue, the anthropology repository known as Manaʼo. Would I, as an IR manager, like to rescue it? Sure! Do I have the technical capacity to do it? Mmmmostly; I could at least take a stab at it. Can I do the rescue? Oh, heck no. Not in my remit. Iʼm not allowed. Itʼs not institutional data, so I canʼt touch it. So it follows, at least to me, that if weʼre going to grapple with data in our institutions, we will have to give up on the purely inward-looking focus that IRs have had. Maybe different institutions will choose disciplinary specialties to focus on. Maybe weʼll just drop the idea that data have to originate within our institution before the institution is interested in them. I donʼt know. But if IRs are going to play in the data space, something in the policy environment has to give.
- 39. We’re caged up inside our institutions. This restriction, this institutional cage, is an artifact of the scholarly publishers; itʼs not something libraries invented. Some publishers allow self-archiving only in “institutional” web presences. If an IR opens itself to a lot of stuff that doesnʼt have strong and obvious ties to the institution, it is opening its institution to a very real legal risk, a risk that some publishers will sue the institution, making the argument that itʼs not an “institutional” repository any more because it contains non-institutional content. But the reality is that research does not stop at institutional borders. And the more that IRs cling to that institutional cage, the less we can actually DO to salvage and protect research data.
- 40. Photo: http://commons.wikimedia.org/wiki/File:Black_Ford_Model_T_in_HK.JPG Any color you want... Unlike digital libraries, at least in theory, IRs were supposed to accept any kind of digital content or data at all! But the snag there is that theyʼre not really designed for it; theyʼre optimized for research papers. So in practice, you get the famous Henry Ford statement about Model T cars: you can have any color you want, as long as itʼs black! Iʼll show you what I mean.
- 41. Bring it on; we’ll take anything! ... as long as it’s static and final. Photo: http://www.flickr.com/photos/orblivio/146691405/ The “weʼll take anything” promise is broken and has always been broken. Weʼd take anything IMMUTABLE. I use this photo advisedly, because for a lot of faculty, once something they produce is static and final and immutable, itʼs junk! Itʼs out of their sight and they donʼt care about it any more. So it never gets deposited in the IR to begin with, which means nobodyʼs taking care of it. The researcher sure isnʼt; itʼs old news.
- 42. Photo: http://www.flickr.com/photos/jonevans/1032687817/ It’s there to be interacted with. The ʻstatic and finalʼ model is absolute garbage for interactive data. Itʼs especially garbage if interacting with the data is one of the ways that the data are made more reliable! Maybe the first reduction of the data is wrong. If we then canʼt change it because our repository only handles whatʼs final and static... we are not serving the need here.
- 43. Data are already out there. Photo: NASA (via http://nasaimages.org/), “Multiwavelength M81” Itʼs also not ideal for whatʼs already out there. We *know* a lot of that stuff is in bad shape. But if we wait to ingest it until we can clean it up into an acceptable final form -- we may lose it altogether.
- 44. Data are wildly diverse in nature... ... as are their technical environments. Photo: http://www.flickr.com/photos/28481088@N00/670258156/ IRs are LOUSY at dealing with the diversity of data. Iʼll have a few more words about this later, but for now Iʼll just state the obvious: putting research data into a user-interface optimized for research PAPERS is a total loser. Papers have built up a lot of uniformity over the centuries weʼve had journals. Data are a whole different story.
- 45. Bring it on; we’ll take anything! ... as long as it’s static and final. Photo: http://www.flickr.com/photos/peasap/655111542/ Again, all this is a profoundly HUMAN problem, and another place where the technology we created has an impedance mismatch with the way researchers actually work and think. Richardʼs Q&A session yesterday brought up a key problem with the static-and-final idea: sometimes you THINK something is static and final when itʼs really, really not. And some things are just not even MEANT to be static and final! DSpace, for example, assumes the static-and-final, so much so that it makes correction of an item already ingested into DSpace difficult and perhaps impossible unless youʼre the systems administrator. How much time I have wasted swapping out files for people, you really donʼt want to know. Fedora users, donʼt get smug here, because Fedora has similar problems. We canʼt DO that with data. Humans are imperfect. The artifacts that we produce are imperfect and incomplete. Our systems need to accept and work with that imperfection, allowing us to work TOWARD perfection, conscious that weʼll never quite get there. Librarians tend to HATE this point of view. Weʼre all about the static and final and authoritative. I am here to say we have to get over our bad selves. HAVE to, if weʼre going to do justice to research data.
- 46. Right, anything you’ve got! ... one file at a time. Photo: http://www.flickr.com/photos/jetalone/39990302/ So, IRs promise to take anything youʼve got, anything at all -- but you have to put it in one file at a time, like coins into a glass piggy bank.
- 47. There’s a lot of data. Photo: http://www.flickr.com/photos/noelzialee/2126153623/ Putting data into repositories one file at a time, MANUALLY, is like emptying the ocean into a bucket with an eyedropper. Not gonna fly.
- 48. Data are already out there. Photo: NASA (via http://nasaimages.org/), “Multiwavelength M81” And since data are already out there, we have to make it easy to dump in large quantity into our buckets. That means more APIs and protocols. SWORD is good, I like SWORD, I love what I heard about BagIt yesterday -- but honestly, itʼs got to be even easier than that. I want researchers to be able to push the “Archive It!” button and have it just silently, seamlessly, WORK.
- 49. Any look and feel... And IRs promise that you can customize the look and feel, but in practice, itʼs too hard. How many people in here can tell a DSpace from an EPrints install just by looking at the front page of the site? I sure can. And anyway, what you get even when you customize is this very sterile, boring, libraryish look and behavior; itʼs not appealing to the researchers whose hearts and minds we need to capture. Look, I did this redesign for MINDS@UW, I am hoisting myself on my own petard -- but gosh, we need to do better than this!
- 50. Data are project-based. http://www.exploringthehyper.net/ Look at this gorgeous little site! Isnʼt it appealing? If I promise the researcher here that Iʼll take care of her data forever and ever at the cost of it losing all its visual appeal and its individualized usability, is she going to take me up on that? I wouldnʼt take me up on that! So this becomes a content-recruitment problem; researchers see IRsʼ ugly, pathetic little one-horse interfaces and interaction patterns and they run screaming in the opposite direction.
- 51. Data are wildly diverse in nature... ... as are their technical environments. Photo: http://www.flickr.com/photos/28481088@N00/670258156/ I know I keep coming back to this data-diversity issue like a bad record, but so much of our infrastructure just fails when confronted with it. One interface does NOT fit all.
- 52. Any look and feel... There is some experimentation happening in IR space. Manakin for DSpace making collection- based theming possible was definitely a step forward, though perhaps not enough of one; too much of the page-construction logic still lives in Java. The KULTUR project in the UK is adapting ePrints to be appealing to visual and performing artists. All of this is good and we need more of it, but I think we have to confront a wider issue: building our platforms with enough flexibility to be easy to customize for as much variation as we can manage. We also need to make it easy for people to construct their own look and feel on top of our stuff, or just with our stuff in it where that makes sense. Our silos really get in the way of that now, and itʼs a problem.
- 53. Any metadata you want! ... as long as it’s key-value pairs. Photo: http://www.flickr.com/photos/rattodisabina/2460905893/ I hate this. It drives me insane. All the marvelous work being done with linked data, XML, semantic webby sorts of things, and all I can have in my IR is key-value pairs? What is up with that?
- 54. Data are wildly diverse in nature... ... as are their technical environments. Photo: http://www.flickr.com/photos/28481088@N00/670258156/ The diversity of data environments includes diversity in metadata; Iʼm sure thatʼs a surprise to no one. It also means a diversity of metadata content models, well beyond key-value pairs.
- 55. Data are already out there. Photo: NASA (via http://nasaimages.org/), “Multiwavelength M81” Imagine the ideal data project. Itʼs already well-described in an elaborate schema and well- organized. Are we seriously going to tell the provider that they have to dumb it down to key-value pairs before we can take it? Seriously? Gosh, I hope not.
- 56. Any metadata you want! ... as long as it’s key-value pairs. Reality check: anybody developing a metadata standard these days expresses it in XML or RDF or both. Key-value pairs donʼt cut it, and arguably never did.
- 57. Do anything you want... ... as long as it’s “download.” Photo: http://www.flickr.com/photos/procsilas/306417902/ IRs can take in digital files and they can give them back. Honestly, thatʼs pretty much all they can do.
- 58. Photo: http://www.flickr.com/photos/jonevans/1032687817/ Data are there to be interacted with. This just KILLS us with interaction. It kills us! A lot of these data need APIs. If weʼre not providing them, honestly, we might as well not bother. Interact with data? In an institutional repository? Mash it up with something else? Heavens forfend -- that would imply that digital objects are somehow related to each other, and thatʼs just crazy talk. So we have a lot of interface and API work to do. A lot of it!
- 59. Content models Enough said. Hereʼs a real-world example of the difficulty. A project Iʼm helping with for the UW-Madison Zoology Museum involves a teaching collection of animal skeletons that students measure and do comparisons on. Weʼre photographing those and whomping up an interface that lets students do that measurement work digitally. Saves wear and tear on fragile realia, allows distance students to participate fully, and, we hope, creates an archive thatʼs useful outside our campus borders. Weʼre using Fedora for this, and the content modeling gets complicated. We have a specimen -- say, a squirrel -- which has any number of actual bones, and each bone may have several photos in various views, and this matters as far as “where do we hang which metadata” and “what do you want people to find in a search?” and “how do you display on a specimen page all of its component bones and views?” So, those have been a lot of entertaining (and sometimes macabre) conversations. Imagine for a moment that this had been a DSpace project. *CLICK* Here is the content model for DSpace. The ONLY content model. Community is not even relevant here; collection kinda-sorta fits but not really, so weʼre left with items, bundles (whatever the heck they are), and bitstreams. And only items can have metadata! (*CLICK*) I donʼt need to say any more. DSpace, which is running the lionʼs share of institutional repositories in the United States, is completely functionally inadequate as a serious data bucket! So much for the IR.
- 60. So where does all that leave us? Photo: http://www.flickr.com/photos/library_of_congress/2162653769/ Hopefully not with a trainwreck!
- 61. Photo: http://www.flickr.com/photos/jonevans/1032687817/ We need bigger, better buckets. I love the idea of just grabbing a bucket and going after data. I admit itʼs probably an 80/20 thing; thereʼs 20% of the problem-space weʼre looking at that we cannot realistically solve. But I know -- I KNOW -- we havenʼt served 80% of our users or 80% of our potential content. We can do better, and we need to.
- 62. Silos are both necessary and unacceptable. Photo: http://www.flickr.com/photos/jojakeman/2818910104/ At some level data are all bits -- and at that level, silos tend to be counterproductive and stupid. We shouldnʼt have to build a checksum engine for sixteen different silos! Where I am, weʼre working toward combining our digital library and our institutional repository on a single technical infrastructure, because it just makes sense to do that. But because data come in thirty-six flavors and then some, once you get above the pure-bits level itʼs unrealistic to think that we can design one silo that will work equally well for everything. Our infrastructure has to be flexible, it has to have APIs that other people can build on as well as ourselves, and it should make the most of the commonalities we *do* find in wildly diverse and heterogeneous data. Homogeneity whenever possible, flexibility where necessary: that needs to be our motto as we build these systems.
- 63. We have a lot of modeling to do. And meta-modeling. Photo: http://www.flickr.com/photos/crobj/727348790/ Again, because of data diversity, the content-modeling exercise I talked about with the zoology skeletons will have to be replicated, over and over and over again, as new kinds of data come our way. I donʼt know if this scares you -- it sure scares me. Add standardization processes on top of this, because we can expect some kinds of research data to develop standards, and it gets even scarier. Fundamentally, we need more efficient ways to do this work -- a sort of meta-model for content modeling, if you will. I donʼt know how that can work; I just know it has to.
- 64. We have a lot of code to write. Photo: http://www.flickr.com/photos/fienna/170559081/ Should be uncontroversial. I know a lot of you are already writing this code! Thank you. Now share it with the rest of us, please, because...
- 65. We can’t code or model in isolation. Photo: http://www.flickr.com/photos/naus3a01/240614578/ ... here is another Cassandraic dire warning. We cannot possibly *hope* to keep up with the data flood if weʼre all making our own little content models and coding up discovery and dissemination frameworks in isolation. Why should anyone out there have to decide how to represent skeletons and bones? At Wisconsin weʼve done that for you! “We love open source; no, you canʼt have our code” is not gonna fly any longer, folks. We have no choice but to figure out how to share code better. Whatʼs more, we have to figure out how to share code with people no more technically inclined than I am, and perhaps less. Now, just a little bit about me: I hate Java. I am violently allergic to Tomcat. I donʼt even like man pages! Can you build a system for me? Now think about the vast DSpace installbase out there. Think about how many of those installs happened because DSpace was supposed to be an out-of-the-box solution. Now think about how weʼre going to migrate these people to something more flexible. Scared yet? I am! Brian Owen talked yesterday about how HARD it is to solve these collaboration problems. I agree with him! Itʼs hard. Itʼs a human problem, and human problems are hard. The problem is, all the ALTERNATIVES to solving this problem are even harder. Weʼve GOT to fix library-technology collaboration.
- 66. Fedora is the new world. But Fedora must change. Photo: http://www.flickr.com/photos/mythwhisper/3361907495/ Of the digital-library and institutional-repository platforms out there today, I think Fedora is the horse to bet on. Itʼs the only one that comes close to the storage and presentation flexibility needed for a big data bucket, and I think the data buckets such as RepoMMan that have already been built atop it are all by themselves a pretty good indicator that it is the future. But Fedora needs to make some changes -- some technical, some social. Content models, service definitions, and their associated code need to be pluggable, to avoid the wheel-reinvention Iʼve said we canʼt afford. I donʼt entirely know how this needs to work, though the plugin and mod structures for projects like Drupal and WordPress may be models. I do know that it does need to work, or weʼre all going to drown in our buckets. And then we have to build the social scaffolding to actually share these pieces of code, which may turn out to be harder than the actual technology! Fedora also made the same mistake DSpace did with regard to the editability and replaceability of objects. Getting stuff into Fedora you can do with what Fedora hands you. Removing stuff, you can do. Editing stuff? No, unless you want to edit XML as text in an incredibly clunky and ugly Java app. Replacing an object with a better object? No. This is not gonna fly, Fedora. It needs to be fixed as soon as possible. We also have to put easier tools on top of Fedora, both on the data-producing and data-consuming ends. Thatʼs being worked on: Islandora, Omeka-over-Fedora, lots of things, and that is all to the good. Fundamentally, we have to figure out ingest straight from whatever unholy mess a researcher has, and we have to be able to translate the affordances of a particular dataset easily into our systems. I donʼt think either of those solved yet, though RepoMMan comes close; even the SWORD
- 67. Photo: http://www.flickr.com/photos/werwin15/3554539197/ Focus on the start... ... not so much the finished product. ... you canʼt curate what you donʼt HAVE. Fundamental truth that the IR experience should have taught us. If our systems donʼt invite deposits -- even sloppy ones, even unfinished ones, even bad ones by any measurement -- and if they donʼt do it as early as possible in the research process, so that researchers donʼt get fixated on some other software system, thereʼs no point to having research-data repositories at all. I know this goes against the grain, hundreds of years of library perfectionism, but Iʼm afraid thatʼs just too bad! If weʼre playing in this space, we have to be ready to make some mud pies. Iʼve always, always loved the RepoMMan project for this reason -- if youʼre googling for it, it has two “m”s -- and I also really like what the California Digital Library is building. Theyʼre starting with the good old filesystem, which we all know and more or less love, and theyʼre enhancing it into a curation system. Itʼs an approach I think will bear fruit, and thatʼs because theyʼre starting from the right place: where people actually do their work.
- 68. Solr brings it all together Photo: http://www.flickr.com/photos/chantrybee/2911840052/ Now, to end on a positive note, I love the Solr app, and I think itʼs a marvelous example of the kind of lightweight tool that does really heavyweight things. The beauty of Solr is that once Iʼve solved the intellectual problem of “what metadata do I want to expose for search and browse?” Solr makes expressing that in a crosswalk just stunningly, beautifully trivial -- and then I never have to worry about it again for that flavor of metadata. There is complexity under the hood, but our experience at Wisconsin has so far been that you donʼt encounter that complexity until you actually need it, which is just perfect.
- 69. ... the Vermeer: the Muse Clio, from “The Allegory of Painting” of Data Curation. So thatʼs what I have to tell you. If Iʼve helped you see some of these problems in a new way, if Iʼve expressed them usefully, such that they get solved, perhaps Iʼll get to stop being Cassandra -- and instead become the Clio of data curation. Hereʼs hoping.
- 70. Thank you! This presentation is available under a Creative Commons Attribution 3.0 United States license.