from geekandpoke

I’m just in the midst of reading this ITHAKA S+R report on the sustainability of digital “projects.” It’s one of those reports where the basic ideas are so simple, but you didn’t realize that you knew them until you read it. Among the things that they suggest are vital to sustainability of projects:

• Dedicated and entrepreneurial leadership (this could also be ongoing leadership: how many digitization projects do you know of that fell apart or became static after the project manager left)?
• A clear value proposition (as in clear evidence of the value of the project)
• Minimizing direct costs (hello appropriate outsourcing!)
• Developing diverse revenue sources (of course that’s a dirty word in some parts of the academy)
• Clear accountability and metrics for success

The question I am increasingly coming to grips with is: In an era of “Do More with Less” what priority does digitization take in the grand scheme of library work? Especially since a lot of us are still out there at the grass roots level trying to raise support. We know that there is a future for this material, but in some cases our faculty don’t yet fully realize what they can do with it (Digital Humanists aside). They may be pleased to be able to replicate as much of their traditional research paradigm online as they can, but it’s hard to argue that we need twice as many resources so we can provide redundant online and in-house services. The small but growing field of Digital Humanities can be effective partners, but they are just one group. Even our own fellow librarians may not be able to grasp how it is more than “putting pictures online”.

In the face of possibly taking another 10% budget cut here that will reduce the staff even further, is digitization the priority? If we do have to cut back, what do we deem the essential activities:

• Digitization, but less robust metadata
• Digitization and metadata but little to no preservation activity
• Very limited further development of repository tools (this includes both public and administrative tools)

Obviously, a lot of work done by the digital curation communities (DigCCurr, DCC, and ICPSR being among the most prominent) can be a guide, but studies of sustainability seem to reinforce the idea that we can’t cut back, that the only way to ensure that these materials meet their potential is to continue to invest resources into maintaining them, and even to increase those resources into the future. So instead of cutting back as above, should I as project manager begin looking into more diverse and creative ways to find funding outside of my organization’s budget? Is it time to create the “digital swear jar” that Ann and I used to joke about (in which we would put an online donation link in the repository and ask people to donate a dollar every time they swore)?

By Flickr user cdw9

I had the distinct pleasure of attending three RDA webinars in the last month and found them alternately informative, entertaining and frustrating. Here’s the lowdown:

Informative: The quality and knowledge of the speakers was great. Having a basic understanding of all of the concepts, I was not overwhelmed but got a greater view into some specifics of RDA that I was lacking. There has obviously been a lot of attention to RDA in the Tech Services world, but not as much in Digital Collections-y worlds, I guess because we probably don’t always deal as directly with the big thugs like MARC and AACR2. However, I’ve been wondering for a while now why more digital libraries (especially open-source and homegrown ones like ours) are doing more experiments with RDA, RDF, and especially linked data. Here at ECU we grab a lot of records from the catalog and cataloguers create the metadata in our MODS/METS records, so we are not immune to this change. I am really anxious for us to do something in this vein. The possibilities for broadening the use of our repository and for enriching it are just too good to ignore.

Entertaining: Again while the presenters were great, the entertaining part was to be found in the simultaneous chat. Now I don’t want to be uncharitable towards my colleagues, but there were comments there that were so clichéd and clueless I thought it had to be sarcasm. I’m not trying to stifle debate or legitimate dissent, but arguing that maybe libraries purposely SHOULDN’T keep up with the times to preserve our “ambience” and saying in one breath that cataloguers were too busy to learn new things and in the next that they were afraid they were no longer needed (but of course the idea of learning to skills to remain viable in a new information environment was out of the question), was astonishing to me. However, the entertainment soon led to…

Frustrating: I’m not the only one in library-land to have ended up slightly bewildered by the reaction at this webinar. My own frustration had a few different sources:

1. It was unfortunate that many of the participants did not have a firm grasp of concepts like FRBR, the difference between data standards (XML, RDF) and content standards (RDA, AACR2), and individual metadata standards (Dublin Core). The webinar introduced concepts but didn’t cover them in depth and the resulting confusion led to a lot of misinterpretation.
2. I wished that there were separate webinars for those with differing levels of expertise, and with different job functions. I’m all for cataloguers having a basic understanding of data formats and system designers understanding content standards, but perhaps addressing the needs of each separately would have been more productive.
3. On the other hand, it’s not like RDA was dreamed up yesterday. If you are a professional in this field and you don’t get it by now, it’s not like there haven’t been plenty of opportunities.
4. Finally, I think some of the examples of this great new information environment do more harm than good. The attendees get too stuck on individual examples of what could be done, pick apart it’s flaws, and perceive it as a threat to “THE CATALOG.” Meanwhile, the point is to make the catalog BETTER. There were multiple comments on data deluge and the importance of catalogs due to some of the examples used (mashups of data from multiple sources), demonstrating that participants were so caught on that they missed the central message…that the changes will make catalogs easier to use, for both librarian and user.

Of course there is plenty of frustration on the side of the debate, obvious to anyone familiar with the petition against the RDA test which grew out of OCLC-CAT discussions. *sigh…

Be sure to checkout the Continuing the Conversation posts about the webinars at the ALA Techsource blog.

Please consider taking a few minutes to answer a 9-question survey.  Feel free to share this survey through your social networks.

The survey closes at 5pm on Friday, November 5.

http://www.surveymonkey.com/s/ncgovwebdesign

Thank you for your time.

He’s written a series of tutorials on using the new Google Maps API, which he’s expanded into the recently published book: Beginning Google Maps API 3. All of the code demonstrated in the book is available for free download. I wish I’d had this book when I’d started the project – it would have saved a great deal of trial and error on my part. The author says that even those without much web development experience should be able to get a Google Map up and running. While I don’t disagree with this, the author introduces some advanced JavaScript fairly early in the book. Library staff members can follow the tried and true, copy and paste method, but some of the concepts, like anonymous and self-executing functions, might leave them scratching their heads a bit.

The author begins with a brief history of the Google Maps API and then takes a detour into upgrading from Version 2 of the API to Version 3, which the author recommends skipping if you don’t have any legacy applications to upgrade. However, I found it a useful general overview of the concepts discussed later in the book.

The rest of the book starts with the development of a very simple map. Then each chapter builds on the previous chapter in terms of map features and complexity; including such common mapping tasks as creating clickable markers that open information bubbles and creating polylines and polygons, used to create such things as driving directions, or to highlight specific geographical areas. The author follows the pattern of introducing a chapter’s main concepts and then working through them bit by bit, ending each chapter with the completed code for that chapter. I found this practice quite helpful as I didn’t have to flip back and forth as I have in other technical books to figure out the totality of what was going on.

The author also discusses several other often used features such as using Google’s
Geocoding service to find a user’s location as well as how to create custom markers. One particularly useful feature the author discusses deals with maps with large number of markers, anything above 1000, at which point a map’s performance starts to seriously degrade, particularly in Internet Explorer. This was something I ran up against very early in the development process. The author discusses the pro and cons of the various methods to deal with this problem, enabling a developer to easily choose the one that’s right for his or her particular application without having to code up each option and see what happens.

The book concludes with a very helpful overview of the API features discussed in the book, going over exactly how to use each class and method.

One concept I wish had been discussed in the book was dynamic sidebars, where a user can click a sidebar link to open the info window for a particular point. I found this one of the trickiest parts of developing our application.

All in all, I’d highly recommend Beginning Google Maps API 3 to those looking to develop Google Maps applications with the new API. It’s clearly written with lots of examples and pictures of exactly what the code’s output looks like. If you’re merely looking to embed the location of your library/institution in a Google Map this book is definitely overkill. However, if you plan on working on anything beyond the very basics this book is a definite plus. It will be particularly helpful to those with some previous JavaScript experience.

Image courtesy of Flickr user marttj

Image courtesy of Flickr user law_kevin

Question: Will the way volumes are digitized today change the way that work is done in the future: less close reading more broad reading/more data mining and deduction across corpora. Are the traditional monograph-driven disciplines a strong enough force against the tides of Google-ization (i.e. the “close enough” answer is the good enough answer)?
These questions are being explored by author David Weinberger in an upcoming book he’s working on called Too Big To Know and he gives some insight into his writing process and the arguments he is pulling together for his book on his Joho the Blog. It’s interesting both from the perspective of getting an inside look at an author’s process and for the sake of the arguments themselves. Check it out.

This report describes blight in Hamlet, NC.

This is the collection I hinted at way back in March (and yes, I’m as enthusiastic about these reports today as I was then).  I haven’t come up with any secrets regarding how to quickly and efficiently draw people to what’s inside; most of my ideas involve a lot of loving description, as I speculated months back. For now, I’m relying on a relatively straightforward web site and word of mouth.

We’re still in the process of scanning and uploading materials, but there’s plenty for people to explore at this point. We won’t get through scanning all of the printed reports as a part of this grant project, but should end up with at least 200-250 in the collection.

I’ve listed some complementary North Carolina collections and resources on the “More Resources” page, but if you know of and can recommend any others send them my way and I’ll make sure they get on the site.  As always, we’d love any feedback you might have.

We are exploring lots of options for digital asset management systems – right now, we are experimenting with a home-grown system, and while the backend seems ok so far, the interface needs major work. It’s clunky. The system also lacks capabilities for global find-and-replace, implementing controlled vocabularies, and easy data import/export. Also, folks with levels of expertise ranging from super-duper advanced to novice will be working on our projects, so we want to ensure some ease of use.

We’ve also been playing around with ContentDM, Omeka, and Fedora. There are aspects of all three that I really like and things that cause me some concern. (We’re excluding DSpace from the mix simply because it seems much more suitable for IRs and the like, but please feel free to correct me if I’m wrong about that and you love using DSpace for image-based collections.)

So I come to you, my digital library pals – I’m sure you have strong opinions on these products. Do you have songs of praise to sing about any of them? Any huge warnings about what NOT to go with? We want to make sure we get as many perspectives as we can so we choose the right system for our needs.

Here’s where we need your help (and I was able to work in reference to the term “crowdsourcing”).

We need a name that makes it clear that we aren’t NC ECHO, the Digital Heritage Center, or NC State (all of which either are in some way related to the State Library or State Archives or have the words “North Carolina” and “State”  in their name). The name should (a) make reference to the Archives & Library or (b) be completely neutral (and I think that we prefer a “neutral”  name as it allows our partnerships to grow, potentially).  We’ll be providing access to the historic and contemporary records and publications of state government (as we do now), and the name needs to reflect that (probably).  These materials can be as diverse as the Library’s 2003 document about prosecuting computer crimes from the Department of Crime Control and Public Safety to the Archives’s Black Mountain College publications and promotional photographs from the Department of Tourism. And, we’re both divisions within the Department of Cultural Resources, so there is some question as to whether we need to work a reference to that in?

Now, I realize that a name containing all of this information would be ridiculous, but I’m providing this information to give you some background.

OK. Let the crowdsourcing begin…

For those of you who are using social media to promote your digital collections (and I assume that’s most of you at this point), is it working? What do your web stats tell you — do you notice a bump in traffic after a well-timed post or tweet? Do you hear from people who find your stuff via Facebook who might not have run across it otherwise? I don’t know that anybody has questioned the rush to interactive tools by libraries, and I’m certainly not now, but I know that we all have to budget our time carefully and maintaining an active online presence does require time. Now that we’re a few years into it and have enough experience to step back and take a good look, what do you think: is it worth it?

On the one hand, this is good. We’ve completed a number of larger projects this year and our student workers can really focus on projects involving similar formats and workflows, increasing efficiency. However, now the tide has turned and several members of the Special Collections department are asking to have the pdfs “attached” to the finding aid (which, to us means, deposit it in the repository, create metadata, store for the long-term with the best methods possible…because the whole point is to organize all this digital ephemera not just have it “attached” to the finding aid).

So now I have the proverbial Angel on one shoulder and Devil on the other:

Angel: Access to something is better than nothing!
Devil: But pdfs of photographs and manuscripts? Ew.
A: They are perfectly readable online, i.e. access ready
D: But we don’t have a built in pdf viewer…yet…
A: We have asked, and gotten, identifiers, titles, and descriptions which is all we ask for to begin a digitization request anyway
D: But should we spend so much time on improving the metadata (which we will eventually do, if we follow the current workflow) of pdfs?
A: They are already just sitting around on servers, why not use them?
D: But if we deposit them, think of all the overhead involved? Would we be committing to digital preservation?
A: Aren’t you just being a snob?
D: No, I’m being a good steward of resources!

So I leave it to you, collaborators, what would you do?