It’s worth noting at the outset that I don’t know anything about generating ContentDM export files (partially because even the ContentDM documentation is proprietary, or at least hidden behind a login). But I do know that every time someone has sent me a cDM export file, it is in tab-delimited format (UPDATE: here is the Tab-delimited export documentation), which is basically a plain text spreadsheet. I gather these spreadsheets can be produced pretty easily so I think we can start by assuming you already have the spreadsheet and need to prep it for import into Omeka, which will be done in this tutorial using the CSV Import plugin. If you are not already familiar with how that plugin works, check out the documentation page at Omeka.org before continuing.

You probably need to use Excel

First, open the tab-delimited spreadsheet in Microsoft Excel. You will later save this file in CSV format. If you prefer using non-MS spreadsheet software, you are probably out of luck. As far as I know, neither OpenOffice/LibreOffice nor Apple’s Numbers have an equivalent ‘Text-to-Columns…’ functionality, which will be used in this process.

Remove unwanted and problematic rows/columns, Rename column headers

Once you have your spreadsheet open in Excel, go ahead and remove any ContentDM-specific administrative metadata, or anything else you don’t wish to carry over to Omeka during the migration. At this point, you should probably rename the column headings to something meaningful. This will help with the crosswalk step later.

Breaking out semicolon-delimited values

Next, you will want to check for columns having multiple entries within a single cell. At the very least, this will probably include the Subjects column (because archivists/librarians are never satisfied with assigning just one subject term… subject classification being the Lay’s potato chip of librarianship). By default, these multiple subjects will be separated by a semicolon (e.g. “Librarianship — Potato Chip Analogies; Librarianship — Puns; Librarianship — Personality Disorders;” ). Instead of copying each one of these entries into a new Subjects column, you can just use the “Data > Text to Columns…” feature in Excel. I recommend using a separate worksheet for this step as the new columns will overwrite your existing ones if you are not careful.

Getting the File Path URLs

So you’ve shaped up all the metadata on the spreadsheet. Now you need to define the path to the item file in ContentDM. This is probably the trickiest part to come up with on your own, especially if you are not so familiar with ContentDM. Basically, our starting point will be the cDM “Reference URL.” Those look something like this: http://images.ulib.csuohio.edu/u?/press,59. Assuming you have a whole column of Reference URLs, you need to run a Find and Replace to create your file path (again, I recommend doing this in a separate worksheet so you don’t accidentally overwrite important data). Let’s begin.

UPDATE: in ContentDM version 6+, ShowFile is replaced by GetFile. Adjust the following instructions as needed (i.e. in the first Find and Replace, swap out showfile.exe with getfile.exe).

Start with something like:
http://images.ulib.csuohio.edu/u?/press,59

FIND this:
u?/
… and REPLACE with this:
cgi-bin/showfile.exe?CISOROOT=/

Next, FIND this:
,
…and REPLACE with:
&CISOPTR=

So now we have something that looks like:
http://images.ulib.csuohio.edu/cgi-bin/showfile.exe?CISOROOT=/press&CISOPTR=59

This is a working file path that can be used by the CSV Import plugin to ingest the item file along with the metadata record.

In some instances, you might need to tweak this process. For example, if your ContentDM installation includes JP2 or TIF files (or some other unfriendly image format) but you don’t want the hassle of building a custom display wrapper into your Omeka theme, you can append some additional query string parameters to your file URL.

So if you want ContentDM to serve up a JPG instead of a JP2 (or other…) file, add this to your file column
&DMSCALE=100.00000&DMWIDTH=1600&DMHEIGHT=1600&DMX=0&DMY=0&DMTEXT=&REC=1&DMTHUMB=0&DMROTATE=0
…using this Excel function (where A2 is the first column/cell in need of appending):
=CONCATENATE(A2,"&DMSCALE=100.00000&DMWIDTH=1600&DMHEIGHT=1600&DMX=0&DMY=0&DMTEXT=&REC=1&DMTHUMB=0&DMROTATE=0")

Finally, you need to swap showfile with getimage in the file URL above by running one more find and replace in Excel.

So now, your file path looks like:
http://images.ulib.csuohio.edu/cgi-bin/getimage.exe?CISOROOT=/press&CISOPTR=59&DMSCALE=100.00000&DMWIDTH=1600&DMHEIGHT=1600&DMX=0&DMY=0&DMTEXT=&REC=1&DMTHUMB=0&DMROTATE=0

This will return a JPG file, which is pretty handy. These additional parameters will vary by installation and file type. I don’t know what all of the parameters are or even what each one does; only that this usually works. Again, this is a case where actual ContentDM documentation would be really handy. UPDATE: Keep in mind that this only works with image file types. For more details, check out the GetImage documentation.

Metadata Crosswalk

It’s usually a good idea to plan out your metadata crosswalk in advance, especially if you have multiple export files (and you should if your collection is bigger than a few hundred items; more on that later). Remember that Omeka – out of the box – only uses the first 15 Dublin Core elements. You may need to add a new Item Type or install Dublin Core Extended in order to find/create an appropriate home for your legacy/custom metadata in Omeka.

Batching

To avoid server timeouts, you should consider breaking your spreadsheets into manageable batches. I try not to import more than a few hundred items at a time, and even then one of the two servers involved is likely to timeout or throw an error or something. Keeping the batches small makes it easier to isolate problems, avoid import errors, and undo problematic imports.

Using the CSV Import Plugin

From here, just follow the standard instructions for using the CSV Import plugin.

Bugs, Known Issues, and Limitations

As of version 1.3, there are still some quirks. For example, your file path – that hideous long URL you worked so hard to create – will become the actual name of your imported/migrated file. In some instances, your files may be ingested sans file extension (e.g. .pdf, .jpg, .mp3), which can cause various headaches (though it’s worth noting that these files will generally display inline on your site, due to the way most Omeka themes handle media files, and will only break down when someone tries to download the file, in which case they would need to manually add the file extension). From time to time, you could have an import that hangs indefinitely, never finishing and never failing — and thus not easily “undo-able” (at least, the “Undo Import” button will not be visible). In such a case, you can manually create that button by entering the following URL pattern into your address bar:

http://[PATH TO YOUR OMEKA INSTALLATION]/admin/csv-import/index/undo-import/id/[IMPORT ID]

– this is on the plugin documentation page by the way, as are several other points in this tutorial.

One of the biggest limitations of the CSV import strategy is that you will probably have issues migrating compound objects and other multi-file items, primarily because of the way ContentDM formats the export file and serves compound objects online and partially due to limitations in the way the plugin works with Omeka. Basically, you need all the files for an item to be in the same row as all of the other item-level metadata (e.g. in columns like “File 1,” “File 2,” “File 3,” etc). And there is currently no way to use the CSV Import plugin to assign file-level metadata. For example, if you had a postcard in your ContentDM collection and it had distinct metadata for each side (say, for front.jpg and verso.jpg), along with general metadata for the object as whole, something is going to be lost in the migration without some serious elbow grease.

The Omeka Dev forums are the best place to report bugs, inquire about error messages, discuss workarounds, and submit patches. The general Omeka Forums are also great for more basic questions; happily, most questions get answered in fairly short order. Please do not post support questions here. Please do, however, feel free to leave general comments, suggestions for improvement, requests for clarification, etc.

IMAGE NOTE: poorly Photoshopped post image contains assets by multiple artists and designers, including the amazing “Bob” sketch from Matt Haley’s unreleased but totally awesome sounding Twin Peaks: Season 3 graphic novel.

Though we know information work is highly technical, it seems most library and information science programs are not — even when the faculty are involved in cutting edge technical research.  The programs are relatively short, culminating after just 1-2 years — not much time, especially considering that, unlike most other graduate programs, LIS students are generally starting from scratch with degrees in unrelated fields.  As such, the curriculum is broad but mostly shallow, save for some specialized tracks and doctoral programs. The following is my shortlist of abbreviations and acronyms that I’ve come to view as important to my work in public/digital history, digital humanities, and educational technology.  I don’t work in a library exactly, but I know firsthand that many of these are also important in that setting as well.

API
Application Programming Interface
APIs connect different platforms and programs, most often via established functions and methods.  Twitter, Facebook, Flickr, Google and many other web services provide open APIs that allow you to embed, feed, and connect with their services on your own site or application.  Operating systems, content management systems (WordPress, Drupal, dSpace, etc.), game engines, and programming languages (Ruby on Rails, jQuery, etc.) all have APIs that allow programmers to tap into, customize and extend functionality.

• API @ Wikipedia

XML
eXtensible Markup Language
XML is the core of several languages, tool, and protocols used in digital archives, digital humanities, and general web development.  In my experience, it is kind of a bear to work with, but is nonetheless worth investigating as it is the basis of RSS, EAD, and TEI, among others familiar to M.L.I.S.s.

• XML @ Wikipedia
• XSLT @ Wikipedia
• TEI @ Wikipedia
• EAD @ Wikipedia
• RSS @ Wikipedia

JSON
JavaScript Object Notation
JSON is a lightweight, language-independent data interchange format, billed as “The Fat Free Alternative to XML.” I’ve never worked with it, but probably will at some point.

• JSON @ Wikipedia

OOP
Object Oriented Programming
Okay, well, I’m listing OOP here as a placeholder for various programming languages, some of which are not, strictly speaking, object-oriented by definition. The point is that, while I was introduced to HTML and CSS for the first time in an elective grad school workshop, there’s really not that much you can do with those tools alone. Static webpages have limited use these days. Most libraries, archives, and digital humanities projects need someone who understands – or better, can do – programming/scripting on some level. The languages listed below are probably the most commonly used in the field, though as more projects start to involve mobile app development, Objective-C (iPhone) and Java (Android) will also be in demand.

• OOP @ Wikipedia
• PHP @ Wikipedia
• Javascript @ Wikipedia
• Ruby on Rails @ Wikipedia
• Python @ Wikipedia

LAMP
Linux Apache MySQL Perl/PHP/Python
Basically, a LAMP server is composed of several open source components, including MySQL for database service, Apache as the HTTP server, and pre-installed “P” programming languages (Perl/PHP/Python) running on some variety of Linux operating system. This LAMP “stack” is the basis of most sites on the web today.

• LAMP @ Wikipedia

SQL
Structured Query Language
SQL, and particularly MySQL, is one of the most common relational database platforms in use on the web today. As part of the open source LAMP stack, it is available on nearly all web servers by default and forms the underlying data structure for most open source content management systems.  In recent years, a variety of alternative platforms have emerged under the banner of NoSQL, sparking some amusing yet mostly incomprehensible (to me) debate.

• SQL @ Wikipedia
• MySQL @ Wikipedia
• PostgreSQL @ Wikipedia
• NoSQL @ Wikipedia

DCMI
Dublin Core Metadata Initiative
A metadata schema for describing “physical resources such as books, digital materials such as video, sound, image, or text files, and composite media like web pages.” It is often said that Dublin Core is “capable of describing anything, though not particularly well.” Still, a good place to start.  Like the two metadata standards that follow, it is often used in conjunction with some type of XML. I’m listing just a few here but there are many others one might add to this list.

• DCMI @ Wikipedia

METS
Metadata Encoding and Transmission Standard
Another metadata standard “for encoding descriptive, administrative, and structural metadata regarding objects within a digital library” using XML.

• METS @ Wikipedia

DACS
Describing Archives: A Content Standards
And another metadata standard “for describing archives, personal papers, and manuscript collections.”

• DACS @ Wikipedia

DMCA
Digital Millennium Copyright Act
Understanding copyright legislation is essential for many projects in libraries, archives, education and digital publishing.  I name DMCA here mainly because it’s an abbreviation and thus fits into the scope of this post. It is difficult to imagine a web consisting only of the publisher’s own original content. Today we share, link, quote, and remix content created by others as part of our daily routines. Scholars post research material for students; archivists post manuscripts for researchers; librarians share book reviews; students and other user communities contribute to projects by uploading content. While most institutions have a copyright policy, it’s important that it be kept up to date, both for the organization’s protection, but also for the protection of our collective legal rights. If we take a casual view of copyright, we risk legal action on one end and the forfeiture of our power on the other. A large part of DMCA applies specifically to Digital Rights Management software (DRM) and the legality of circumventing it. Archivists of film, videogames, music and other commonly DRM’ed material obviously have something at stake here.

• DMCA @ Wikipedia
• Copyright @ ALA
• DMCA @ EFF

General Resources

• W3 Schools
• Mozilla School of Web Craft @ P2PU

This list may seem overwhelming.  I wrote it and it overwhelms me, even two years out of grad school. And it’s not even comprehensive. But you have to start somewhere.

My progression from HTML newb only a couple years ago to, well, a newb of several additional, more difficult things, came by way of hacking WordPress.  I’m sure this is quite common. There are plenty of other ways to learn a programming language, but from what I can tell the key factors are always going to be necessity and specificity. If your motivation is to complete a specific project (regardless of languages involved), you will be far more likely to succeed and learn something than if you are simply trying to grasp the language itself in an abstract, academic way. I have a book on Objective C sitting on my shelf, but until I need to complete a real life project with Objective C, I probably won’t get much further than “Hello World!.” Find an actual need to develop these skills and you will probably make some progress. If nothing else, you will discover along the way all the things you don’t know, which is also helpful.

Another important thing to remember is that you will almost never be working from scratch. When you plan out a project, find something to serve as a solid foundation.  It may be a document to use as an example, a description of an existing project, an open source code base, or  some other fundamental element that almost fits your needs perfectly, and then figure out what needs to change to make it your own. As you go deeper and begin to produce your own content, this will seem less like copying and more like learning from and contributing to a community of practice.

Just to be clear, I want to close in defense of my education and alma mater (to which I will always be true or whatever). I was taught of these things (well, some of them), but not in any great detail; something that would be near impossible in the context of a broad-based 1-2 year LIS program.  It’s worth noting that I was in a generic public library track and may have learned more about these issues in a more specialized setting.  I also should clarify that I’m hardly an expert in most if any of these topics and languages; there may be some better resources and explanations out there so please share in the comments and/or via twitter.

What was/has been your experience with your MLIS program?  Did/do you feel prepared for a professional position coming out of grad school?  What would you add to this list?

I recently picked up a copy of Walter Benjamin’s Illuminations. I was completely struck by the first essay, “Unpacking My Library”, where Benjamin discusses book collecting. And while I myself take pride in my ever growing personal library, I almost immediately began to translate all his references to books as pertaining to record collecting. Not only this, but Benjamin’s words somehow summed up, far more eloquently than my own I might add, why, despite my professional stance that everything should be digitized and widely disseminated, I don’t and never will own an ipod. It made me rethink a few ideas I’ve become accustomed to, things like ownership and physicality, that have become essential to my work as a Digital Humanist. So, I thought I’d share…

Let me start by quoting part of Benjamin’s conclusion,

“…ownership is the most intimate relationship that one can have to objects”.

While this statement would possibly seem insignificant enough to your average person, “ownership” is an extremely weighted word for the Digital Humanist. Putting it simply, Digital Humanists hate ownership. Often, this disdain is directed towards corporations and their claims to proprietary software. This is easy enough, especially with the aggressive (unethical?) business practices of companies like Blackboard. The music industry, with its severely outdated business model, is another common target.  Many Digital Humanists go further though. They challenge their colleagues and institutions, especially universities and museums, to give up traditional rights to scholarship, educational content and primary sources.

However, we can think of ownership from another side. What about an individual’s ownership of something? Now, as I’m pretty sure not all Digital Humanists are total Communists (just kind of), I think most are comfortable with the idea of an individual owning possessions like a house, car, whatever. Its more intellectual property rights, especially of digitized intellectual property, that irk us. Because Digital Humanists have created this distinction, most of us can live in relative peace with the belief that its okay for us to own all sorts of things, but Microsoft needs to stop charging people for software. It works for me at least.

There are some cases, however, where this distinction begins to blur, and I think music is an excellent example. I’m not necessarily talking about the consumption of music here, but the collecting of music. Lets return to Benjamin’s idea of ownership. I’ll throw another quote at you because I genuinely like how he writes:

“Even though public collections may be less objectionable socially and more useful academically than private collections [as the Digital Humanist knows very well] … the phenomenon of collecting loses its meaning as it looses is personal owner”

Think about that for a second and let me pose a question: do you own the songs on your ipod? I mean, not legally, that all depends on how you acquired them. But, do you feel ownership of them? Is that Vampire Weekend (or whatever the kids are into these days) mp3 yours? Speaking strictly for myself, I don’t really feel like a song on a copied CD is mine, let alone an mp3 file. Even if some feel that they do in fact own their mp3 files, looking deeper into Benjamin’s essay, I think I can demonstrate why this definition of ownership is inadequate or at least very distinct from the ownership I am trying to describe. Let me explain.

The Thrill of the Hunt

I really miss hunting for records. Don’t get me wrong, I still go to the record store to look for things, but its just not the same when what I’m looking for could just as easily be bought online while I’m watching TV. Especially for the collector of underground music, the joy of finding something you’ve sought for literally years is pretty hard to describe. However, guess who describes it perfectly?

“I am not exaggerating when I say that to a true collector the acquisition of an old birth is its rebirth”

In explanation of this rather odd statement, Benjamin explains how, for the collector, the acquisition of an item quite literally fulfills that item’s destiny, which is of course, to become part of your collection. All of that item’s history, from its production, to its past owners, real or imagined, becomes an additional property of the item (think of it like invisible metadata that exists in the collector’s head). Honestly, it sounds dumb, but I have to admit that I’ve shared this extraordinary feeling. Putting all real probabilities aside, it truly seems like destiny when you uncover that record that you’ve been searching for, perhaps for years, in the used bin at some crappy record store you dragged your girlfriend to on vacation. Every crease on the album sleeve, every marking, all the writing, it all stays with you, forever becoming part of a collection that includes but is not limited to the music itself. Basically, it all adds up to much more than the music itself.

Physicality, Ownership and the Digital World

The point of all this nonsense, besides that record collecting is cool, is that while the digital world has not necessarily changed music itself, it has certainly qualitatively changed the collecting of music. Physicality is one aspect of this, as the physical marks on something like a used record can perhaps be used to conjure up a richer history of that item, which, as Benjamin suggests, adds to the many joyful histories contained within in a collection, inseparable but distinct from the music itself. However, I would argue that physicality, while perhaps the most obvious, is not the most important factor. For instance, back in the days of peer to peer file sharing, I certainly felt Benjamin’s “thrill of acquisition” when finding an album after countless unsuccessful searches. I believe the more essential element is that “ownership”, in the Benjamin sense, is directly dependent on a meaningful acquisition. One that produces “profound enchantment” and a literal sense of destiny.

Its interesting for myself, as a Digital Humanist, to consider that part of Benjamin’s “ownership” as defined in his quotation, cites public ownership in direct opposition to this personal ownership that makes collecting so desirable in the first place.  Its easy to see why this is so, if only because widespread availability would necessarily lesson the difficulties and joys of acquisition. Thus, some of my most cherished goals of dissemination and the eradication of the ownership of digital “property” also contribute to the deterioration of a different kind of “ownership”, that of an individual to that personal, intangible, yet very real aspect of his or her collection. In this case, its music. But perhaps the example can be applied elsewhere. When I reflect on all of this, I realize that receiving information of any kind, academic for instance, is not necessarily so different from listening to a record. Its certainly more than just memorization, critical thinking, or other mental processes normally associated with learning. In fact, my “collection” of academic knowledge has been dramatically enriched by everything else that took place while in school, at conferences, or in the archive. From the thrill of putting on those white gloves the first time I handled historic photographs to the memories of my music professor’s leather pants and rants about punk music (“Roots of Rock and Soul”, a legendary class). Of course, I’m not saying Digital Humanists should abandon our, in my view, very essential goals. Its just that, thinking of Walter Benjamin’s library and my record collection, I think its also important to remember the central importance of the process of acquisition, not simply the content acquired.

As the dialogue on the emergent (yet increasingly passe?) edupunk movement has begun to penetrate the mainstream press, I’ve been thinking a lot about what the term might mean to my present occupation, and also about what punk rock has meant to me historically (both in terms of my personal history and also my views on History with a capital H). I’ll spare you the many cliched “life experiences” I’ve enjoyed as a result of my involvement in punk culture, and focus here on how it has impacted my views on art, literature, politics, society, technology and education (i.e. the (digital) humanities).

My friend Joe, a newspaper editor, once said something to the effect of “It’s kind of crazy how all the punks end up doing such interesting and serious work outside of punk when they ‘grow up.’” Okay, he probably said something a lot better and more impactful than that because I remember the gist of it years later. For some reason this brief conversation has stuck with me. As I moved through undergrad and grad school and into the professional world, I have consistently noticed the phenomenon in action. The best students, the best teachers, the best writers, and the best researchers all seem to have this common background. I have seen it and confirmed it in many of my (more interesting) colleagues and it shows in the work of many others whom I’ve never met. It’s a certain flair for innovation, improvisation, and investigation; a proclivity for self-education and DIY solutions; a disdain for convention and privilege; and an eye for finding humor and absurdity in unexpected places.

3 Chords is All You Need (… at Least to Start)

Yep. The Ramones first album proved among other things that you only need to know three guitar chords to make great music. But like many other punk bands, the music matured over time, becoming more complex as the artists began to hone their skills and increase their repertoire. Sometimes the music got better, sometimes it got worse as a result. Even though I never was able to master even the requisite three chords to start my own band, the “anyone can do this” attitude that punk embodied has carried over into everything I do. Most everything one might pursue has those metaphorical three chords — the trick, as with the guitar, is figuring out what they are.

In digital humanities, those three chords might be HTML, CSS, and PHP. (Maybe others have a different idea. I’m focusing here on the digital part because the humanities part – the content – is understood. Afterall, if you don’t have something to say, you shouldn’t be starting a “band.”) The degree to which you need these “chords” will vary depending on what you are trying to accomplish, as well as on the tools you use and the people you work with. But generally speaking, these three will set you up to start web publishing, and also give you a solid base for understanding other more complex programming languages and projects.

So you find the chords, you master them. Then on to the next challenge… and the next. Before you know it, you’ll be soloing on your hand-built keytar as your self-produced album rockets to the top of the prog rock charts. Or not. Maybe you’ll just keep pounding away at those same chords and finding new ways to use them. But the point is that it’s alright to start small (and/or stay small).

DIY or Die!

It’s not just that you can do it yourself but that you should. To me, there is no such thing as a major label punk rock band (at least not after about 1980). Being punk has always been about doing it yourself – sometimes out of necessity, sometimes by preference, and occasionally as an anti-capitalist or anti-authoritarian gesture. If you do it yourself, you are free to do it however you want.

Thus far, a lot of the digital humanities projects I’ve seen are tied to institutional funding and labor, proprietary content and technology, and bound by copyright and contractual obligations. It’s not that these projects are bad. Many are great. And they often benefit especially from connections gained through these affiliations. They also employ people, which is good. It’s just that they can also become organizationally bloated, unwieldy, and tenuous as a result. This doesn’t mean you have to run your semantic search think tank from your mom’s garage (though, hell, why not?), it just means keeping hierarchies in check and making sure you don’t lose control of your project, or lose sight of your goals. It also means learning as you go; tinkering, experimenting, and failing are all important.

No Rights Reserved

DIY is not about individualism, it can also be about leaning on (and contributing to) like-minded communities. Open source technologies and Creative Commons licenses are totally punk rock. Open platforms (like WordPress, Drupal, Omeka, etc.) and software packages (Gimp, OpenOffice, FireFox) share their code, encourage non-proprietary standards, and are often developed and maintained by a community of users/contributors. If you want to use them, you can do so for free. If you want to study them, make them better or bend them to your own needs, you can usually do that too. Most open source projects operate under some kind of Creative Commons license.

But open content is also important. Humanities research requires the use of all kinds of content. Running up against unnecessary copyright restrictions can be not only frustrating but can actually bring projects to a halt – especially digital archival projects operating under the aegis of larger institutions; institutions that are understandably (though sometimes paranoically) wary of litigation. There are two (or maybe three) significant archival repositories in my neighborhood. One opens its content to all comers because they have defined themselves as an institution committed to education and community. They allow hands-on access, digitization, and non-profit use of nearly everything in their collections. At the other end of the spectrum is the more hallowed institution. They believe that their collections are sacrosanct and that their artifacts exist to be preserved. They do not make anything available online and they forbid reproduction of any type (unless you pay a ridiculous fee) for fear that everyone is out to steal their content. They really believe that if they increase access, they will lose their standing. Direct quote: “These items are all we have! We can’t just let people download them! Then how will we make money or get funding?” As if they are bringing in a lot of money in their current state: offline, behind lock and key, and crippled by the analog DRM called fear of obsolecense. The people who will pay (i.e. commercial projects like documentaries), will pay anyway. If they can find your content. Overprotection creates a situation where the “wondrous” artifacts they preserve may as well have burned in Alexandria. It’s pretty annoying to know that the perfect set of historic image sits just across town, waiting to help you complete your groundbreaking, non-profit, community-based public history project, but it will cost you $1000 (or the equivalent in months of grovelling) to use it.

So why add to this problem with your own unnecessary copyright barriers? Open it up, and let people benefit from and build on your work. They’ll do it anyway, so what do you have to lose? (see also Stuart Geiger’s post on the topic). The point of your work is to make an impact (on communities, people, scholarship, your reputation, etc.). While nothing is more punk rock than throwing the ole’ “No Rights Reserved” on your blood, sweat and tears creation, CreativeCommons allows you to choose the degree of openness that suits your project, so no pressure… you poser.

Death to Posers and EduJocks

Punks hate nothing more than posers and jocks (and maybe Ronald Reagan). They are antithetical to all the punk believes in. Posers are an affront to the punk rocker’s unending need to measure and display authenticity. In edupunk and in the digital humanities (interesting how these seem to be tied together), there are also what might be called posers. We will call them EduJocks (I sure hope you heard it here first, but I doubt it). EduJocks adopt the outward persona of the digital humanist/edupunk, but lack the internalized commitment and understanding of the bigger picture. If you hear someone saying, “Well, BlackBoard is good for some things…” or “Too bad there’s no alternative to Microsoft Office/ContentDM/Adobe…”, cut them off and walk away immediately. You are in the presence of an EduJock. This could be like a Jeff Foxworthy bit. You know you’re an EduJock if… [ahem - this is what blog comments are for].

That’s it for Part 1. I’m getting tired of this right now, but I have plenty more to say. Stay tuned for Part 2, wherein I will blow your mind with another ludicrous application of the time-honored punk rock tradition of making everything you like be about punk rock.

Yes, this post ends abruptly. That’s because it’s punk rock. I’m exploring the form.

Here are some teaser topics for the next installation:

Framing: The Decline of Western Civilization

Liner Notes: The Original People’s University or Citation City

Lies My Teacher Professor Told Me

Judging an Album by it’s Cover (and/or the Record Label) or Style is Substance (the Medium is the Message)

Nihilism as a Valid Academic Perspective

Technology of Resistance?

So, I really like the looks of this nifty little flowchart, though I’m not sure it’s logically consistent.  In fact, it kind of reminds me of the inscrutable maintenance manual that came with my Taiwanese scooter.   I’m feeling compelled to take it down and make some revisions, but I think it best to just move on to writing my little article about the challenges inherent in digital history at the institutional level.  So here it is…

Introduction

After reading through the latest issue of Perspectives on History (May 2009),  I’m thinking a lot about what exactly is meant by terms like “digital history” and “digital humanities.”  On the surface these seem like pretty intuitive ideas.  You can slap a “digital” in front of just about anything and the meaning conveyed is more or less “on the web.”  In general, the actual practice of digital history bears this out.  Every history professor has a blog, every city has its own digital archive (in Ohio, they seem to all be named “[yourCityOrState] Memory”), and every modern historical event has a commemorative website or two.  Increasingly, discreet areas of historical inquiry are also well-represented online.  Each of these has a value.  Some are well executed and well used.  Others are well meaning and… well… ignored.  The best projects engage both teachers and learners, as well as the general public, with tightly focused, organized and comprehensive research and presentations.  Many others struggle in ways that are predictable (notably aesthetic design, usability and information architecture, and an apparent failure to comprehend the strengths, weaknesses, and demands of the media they are working in).

Nevertheless, we want and need more of whatever digital history is or is going to be.  My impression is that many would-be digital historians jump into new and exciting projects without fully understanding what they are getting into and what it takes to realize their vision.  Most projects seem simple at the outset, but, as you can see from my totally mad flowchart, even projects with modest goals can be jarringly complicated.

Before I get into the nitty gritty I should point out here that I am not an educator — though I do plenty of staff training and instructional sessions.  Nor am I an academic in the conventional sense.  I have an undergraduate degree in History and a graduate degree in Library and Information Science, as well as a few years under my belt managing various oral, public and digital history projects, including some on-the-job training in website development.  My professional expertise in not in content creation, nor in technology, but rather in conceptualizing practical ways to bring the two together in an educational context.  With these qualifications and caveats in mind, I will attempt to describe what I see as the barriers to operationalizing digital history at the institutional level.

Note: I am operating on a university model in which professors set project goals, providing direction and instruction, and using class time, staff and/or student labor resources, as well as university or grant funding to achieve completion.  The end result being an online resource of some type.

Core Competencies for Teaching, Learning, and Doing Digital History

Content:  You need to know your stuff.  If you are creating a digital history exhibit about Content X, then all participants (those who conceptualize the project and those who populate it with content) must have a reasonably advanced understanding of Content X as well as an ability to communicate that knowledge.  The final content must be of publishable quality since it is more or less being published.

Technology:  Although it is often assumed that the current generation of students is more technically competent than their instructors, this is often not the case.  Just because a student brings a laptop to class and uses email and social networking sites does not mean he or she understand how to use complex software and publishing platforms.  Assuming that students will “pick it up as they go” misses the reality that technical learning requires the building of experience through use and training, along with ample time to explore, experiment and fail.

In most scenarios, students are the technological proletarians of the project, contributing the bulk of the content and spending the most time using the technology.  Thus, they need to know how to use the tools at their disposal.  Professors and other supervisors have the luxury of guiding outcomes and watching content amass, but also bear the burden of bigger picture and behind the scenes technological matters such as data security, workflow management, server and site administration, and perhaps even a healthy dose of coding, designing, and debugging.

Law and Ethics:  Digital history, like “regular” history, often involves collecting and analyzing primary and secondary sources.  Traditional history is typically filtered through rounds of vetting and editing before it reaches the public.  Digital history can be “published” without such constraints.  Professors and other supervisors are not always able to comb through all the content that students collect in the course of their research.  As a result, there is often a risk of unwittingly publishing someone else’s work.  Leaving the issue of blatant plagiarism aside, what students deem fair use and what actually is fair use can differ greatly.

In my experience I have seen many images taken from commercial websites (some with giant watermarks and embedded logos!) and embedded or reposted without attribution or permission.  Students must understand that they have a responsibility to not only respect relevant laws, but also to not do things that make the primary investigator look like a total jerk.  There are appropriate and inappropriate sources, and there are sources for which appropriate use depends entirely on the way and the context in which they are being used.  These issues are not self-evident and must be explored and codified at the outset.

Likewise, there are often ethical questions that should be fully addressed.  Consider the use of digital oral history files.  Due to their length, file size, and meandering nature; we often edit them down to excerpts or reframe them in new contexts such as film or video.  We do this for any number of reasons: to tell stories, to increase use and access, to accommodate bandwidth restrictions, etc.  But with each modification and recontextualization, we run the risk of betraying not only the historical integrity of the item, but also the trust of our subjects.  The mere act of cataloging an oral history in the library takes a new meaning in the digital age, when recorded political beliefs and entire life stories (sometimes in full text or streaming audio) are only a name search away.  The potential for harm cannot be ignored.

Organization of Information:  Surely one of the least discussed aspects of digital history.  Supposing your team has a strong understanding of content, is attentive to legal and ethical responsibilities, and is reasonably skilled at using technology;  a final gauntlet awaits.  Yes, I speak of the soul crushing demands of metadata and information architecture.

Historians, like others in the Humanities, pride themselves on weaving complex and idiosyncratic narratives, employing deep analysis and rich vocabularies in the process.  Librarians in contrast use plain and objective language to create clean, accessible resources that are predictably organized and easy to understand.   This famously boring approach to information is actually one of the most useful tools that libraries employ to create usable collections and resources.  Digital history projects are likely to involve any number of cataloging and metadata standards, which must be implemented consistently with the help of considerable documentation and training.

Information architecture is also important.  Just as metadata needs to be consistent, so too does the organization of websites and other interactive resources.  Navigation must be clear and intuitive, but defined according to project-specific needs and amenable to many different use scenarios.  Most of this is laid out in the planning and design stages, but must be continually monitored lest the system break down.  As a resource loses organization, it also loses value.

The Primary Challenges

Training:  Each of these core competencies requires some degree of training.  A common critique of digital humanities education has been its rotation between conventional history training (content mastery, research, writing, et al.) and “digital” training (technology, metadata, information theory, etc.).  This will be a necessary reality into the foreseeable future.  Thus, digital historians should expect pushback at the institutional level from those concerned with maintaining tradition in history education.  Furthermore, some history students will ruffle at the idea of being graded on such non-history competencies as the use of software, HTML, and Dublin Core.

Time:  Training takes time, as does the required planning and management.  Instructors need time to teach all that needs to be taught and have limited classroom time to do so.  Personal time is likely to become a consideration as well; as projects evolve, they can become unwieldy and demanding.  Other professional expectations (i.e. traditional publication activities) are often set aside, to the chagrin of tenure review boards. Students also have limited time in their day.  Most students today work at least part-time and also have family and social lives to maintain.  At my place of employment, the majority of students commute to and from full-time commitments at both work and school.  Unless a project has a regular paid support staff, time is certainly a major barrier.

Money:  Costs can add up.  Server space, domain names, web design, hardware and software, as well as administrative and other staff all cost money.  Though it is often possible to find alternate sources of finance (grants, fellowships, etc.), most funding is likely to originate at the institution.

Of course, it need not be this way.  At the risk of devaluing my own position as a facilitator, I suggest that most digital history projects could be accomplished cheaply and effectively by a small team of informed and devoted volunteers working outside of the institution.  Students often devise ambitious projects, but never follow through for lack of financial or intellectual support, time, and know-how.  A recent post by Dave Lester suggests the possible emergence of “digital history street teams.”  I really like this idea, which reflects a rising interest in DIY approaches to education and scholarship (the kids are calling it “edupunk” these days, and I heartily approve).   So while the barriers I outlined above are very real and require some serious thought, there are also alternatives for creative and motivated individuals and groups – both inside and outside the Ivory Tower.