You’ve seen them in libraries, and you may have even helped build one. Christmas trees made of books are all the rage among bibliophiles. At the James P. Boyce Centennial Library, we’ve built one too. It looks like this.

This year, though, our staff decided to take the holiday decorations up a notch. They demonstrated their mad book sculpting skills by creating Frosty the Bookman.

Frosty is constructed entirely of library materials. His body is made of books turned spine in with a piece of white paper from the recycling bin on top. His eyes are made of old library stamps. His nose is a rolled up New York Times Magazine with carrots on the cover. His arms are newspaper displayer sticks, and his scarf is a blanket one of our librarians uses to keep warm in her office on chilly winter days.

Here’s wishing you a Merry Christmas and a blessed holiday season from the Frosty the Bookman!

The user group asked that I discuss why we decided to use Archon and how we use it. Below are my ever-so-brief notes on the topic.

Why we selected Archon

1. It had a really nice web interface (both public and administrative)
2. Chris Prom’s user interactions articles in American Archivist gave me hope for the project at its earliest stages
3. It was easy to train student workers to use (contextual DACS help)
4. It runs on LAMP stack (No Java, XSLT)
5. It makes the migration of the types of legacy data we had relatively easy (MARC, EAD, CSV)
6. It is fast (my initial tests with Archivists’ Toolkit reports were somewhat slow)
7. It is free (no cost, license allows for adaptation )

How we use Archon

1. We provide web access to finding aids for collection
2. We keep track of accessions
3. We process collections (We feel that it facilitates MPLP and processing large collections)
4. It allows us to describe yet hide closed collections (visible to us, not the world)
5. It provides us with smart searching (records are returned in a hierarchical context, so it’s not just Google style searching)
6. It allows us to supply virtual arrangement
7. We use it to keep track of our offsite collections  (user defined field mapped to EAD UnitID)
8. We use it to export to our online catalog (MARC, EAD)
9. We use the digital library for some digital objects

Downsides

1. It has no real reporting suite
2. Accessioning seems more robust in Archivists’ Toolkit
3. It does not support OAI
4. It does not support Premis
5. It does not support a multi-site or collaborative setup (in the way I would envision it)
6. I am unsure of what the final ArchivesSpace product will be like
7. The user community does not seem as active as some OSS projects

All that to say, if you would like to win a copy of Wills’ superb institutional history, stop by Trevin’s blog and register to win.

Files:

• [manakin-source]/themes/[theme-dir]/template.xsl (The theme’s stylesheet)

• [manakin-source]/themes/dri2xhtml/DIM-Handler.xsl (The theme’s stylesheet)

[edit] Instructions:

• Caution: This is really just a proof of concept for adding support for the HTML5 video tag to xmlui. It’s based on the Classic XMLUI theme, so some things may be different for your application.

1. Add the OGV to the metadata registry using the instructions found here —> Add a new format to the bitstream registry
2. Create an OGV video. If you have Firefox, you can use Firefogg to do it.
3. Upload your video to your DSpace install.
4. If you haven’t already, you need to Create a new theme (or don’t, if you don’t want to).
5. To modify the header, locate the section of DIM-Handler.xsl that begins with <xsl:template match="dim:dim" mode="itemSummaryView-DIM">

. Copy this section into your theme’s local template.xsl and modify the XSLT as noted below.

1. Immediately following the line that reads <table> add the following code:

            <xsl:choose>
                <xsl:when test="ancestor::mets:METS/mets:fileSec/mets:fileGrp[@USE='CONTENT']/mets:file[@MIMETYPE='video/ogg']">
                        <tr class="ds-table-row odd">
                                <td><span class="bold"><i18n:text>xmlui.dri2xhtml.METS-1.0.item-preview</i18n:text>:</span></td>
                                <td>
                                        <xsl:attribute name="href"><xsl:value-of select="@OBJID"/></xsl:attribute>
                                        <video>
                                                <xsl:attribute name="src">
                                                        <xsl:value-of select="ancestor::mets:METS/mets:fileSec/mets:fileGrp[@USE='CONTENT']/mets:file/mets:FLocat[@LOCTYPE='URL']/@xlink:href"/>
                                                </xsl:attribute>
                                                <xsl:attribute name="width">
                                                        <xsl:value-of select="320" />
                                                </xsl:attribute>
                                                <xsl:attribute name="height">
                                                        <xsl:value-of select="240" />
                                                </xsl:attribute>
                                                <xsl:attribute name="controls" />
                                                <xsl:attribute name="autobuffer" />
                                        </video>
                                </td>
                        </tr>
                        </xsl:when>
                        <xsl:otherwise>
                        </xsl:otherwise>
                    </xsl:choose>

1. Of course, stop and start DSpace for good measure.
2. Visit the Item Summary View for the item you uploaded with a Firefox 3.5 or greater browser, and you should have pseudo-streaming enabled.

I finally got this configured after running the following

freetype-config --cflags

This gave the output of -I/usr/include/freetype2

Next, I used that path with the configure command as follows:

./configure --with-freetype2-includes=/usr/include/freetype2/

After that, it configured perfectly.

I can think of strengths that could be gained from this integration. A GUI could be a nice addition. The folder view in Archivists’ Toolkit is nice as well. I also hope that these development efforts will also lead to a new platform that supports union catalogs from the outset.

There are dangers in the combined efforts as well, in my opinion. I  hope that the nice, clean PHP code used in Archon doesn’t get mucked up with some sort of integration with Java, which I hate with a passion. I think using a great deal of Java would slow development and reduce the ability of many to do customization. Did I mention that I hate Java? I also hope that development isn’t stymied due to a lack of competition. Competition is always good, even when it’s between open source products. I also hope that Chris Prom’s influence on the project is undiminished. Chris’ two American Archivist articles on the EAD Cookbook and user interactions with finding aids set up a solid research foundation for the entire Archon project. Without his research, the project would not have been as good as what it is.

Still, this project holds promise, and I think the outcome will probably be good for archivists.

Handbrake has been around for quite some time. It is a free and open source video conversion tool that is available for Windows, Apple, and Linux. In previous releases, Handbrake was merely a DVD ripper that many people used to convert DVDs for use on their iPods, PSPs, or cell phones.

I have used it before, but I never really considered it a good candidate for use in an archives because it just converted DVDs. However, the latest version (0.9.3) of the software makes it an ideal solution for using in an archives, because it now supports video format conversion. In other words, Handbrake will allow you to convert videos between formats. Their developers state on the wiki that “HandBrake can accept almost any sort of video file you can throw at it, although with exotic fare, things can sometimes be a little rough around the edges.” It is able to encode videos as MP4, MKV, M4V, OGM, and AVI.

Handbrake also includes a nice set of presets for encoding to devices like iPhones, iPods, and gaming consoles. Do you want to add an iPod friendly copy of some historical video you’ve converted to DVD to your institutional repository? You don’t want to take the time to learn what all of the different audio and video encoding options are? That’s not a problem, because Handbrake has them baked right in.

One other nice feature Handbrake offers is a command-line interface. What this effectively means is that with just a little bit of script-fu and a spare workstation, you can convert a whole mess of video files. Of course, you could also do this the easy way, because the graphical interface has a nice queue available as well.

Now, today’s outage appears to be caused by a denial-of-service attack, so data loss will probably be minimal. But other types of digital catastrophes can cause data loss, and the data lost may be culturally and sociologically significant.

By the way, if anyone needs ideas for what to do while Twitter is down, here’s a few suggestions. They beat working on a Twitter archiving app right now. Can’t connect to the API.

• Over 43 percent of the respondents attempt some self archiving of their blogs
• Nearly 71 percent of the respondents believed that their blogs should be archived
• Nearly 50 percent of respondents believed that preserving the audio and video embedded in a blog was important
• Over 30 percent of respondents believed that archives and libraries had an obligation to preserve blogs in general

Quere from Glen’s Creek. Is it right for Baptists to join in an assembly at Barbecues on the 4th of July? Answered No.

I may have some repenting to do

This is the list of things they fill compelled to do at Darien. Are there things that you, personally, would add or eliminate from the list?

They be like Geese Lice, but somewhat bigger, they will breed most about the ears, neck, and tail, and over all the body. THe comve of poverty, and the Horse will be alwayes rubbing, and scratching, and will eat his meat, and not prosper withal, and with rubbing he will break all his mane and tail. The cure, according to Martin, is thus; Anoint the place with Sope and Quicksilver, well mingled together, and to a pound of Sope, put half an ounce of Quicksilver.

That’s right folks. There’s no cure for lice like a mixture of soap and mercury.

The version of DSpace with which I’ve been working is 1.5. Version 2.0 is currently in development. I don’t know what chanes are in order for this next major release, but I know that it needs a good dose of web 2.0 in version 2.0. What do I mean? I mean that DSpace should become more user-centric. So, here’s my top 10 list of things that I think DSpace developers need to do in version 2.

1. Make the easy stuff easy. – It’s easier to explain this by example. A few days ago, I was working on making a minor change to the user interface that would allow for streaming media. To make it work, I needed to be able to generate the URL for the primary bitstream. In short, there was no way to do this. Even though the URL is present in the default interface, there is no method for calling the URL on its own. At times, DSpace is SO object oriented, that it prevents system administrators from making minor tweaks such as this one. Giant blocks of code may be easier to maintain (I really don’t think they are), but they circumvent customization. Take a page from the scripting language developers: make the easy stuff easy.
2. Make the media stuff seamless. — It is a YouTube/Flickr/Amazoogle world. Embed or you’re dead. ‘Nuff said.
3. Make the waiting stuff apparent. — No one enjoys load screens and status bars, but everyone hates the alternative: not knowing whether the application is doing anything. A nice little status bar would ease users’ minds.
4. Make the U the basis for the UI. — This goes along with the previous two points, and the next point. Some aspects of the UIs for DSpace are just clunky and ugly. Whether I’m using the administrative interfaces, or the regular user interfaces, I find my eyes jumping all over the place to find stuff. The interface may be well-ordered, but it doesn’t feel like it is. Tasks could often be bundled in a way that would reduce the number of clicks for users (especially in the approval process under JSPUI). In some ways, the XMLUI setup is better with some themes, but there’s still much to be desired (like having a common administrative interface for XMLUI, instead of the Drupal-like changing of administrative UIs). Perhaps developers could take a page from Automattic’s recent development of the WordPress Administrative UI. They used Ball State’s Center for Media Design to drastically change the interface, and, well…it just works. UIUC’s Archon is another project that recently saw a beautiful interface redesign (public, not administrative).
5. Make the UI AJAXy. — Not for the cool effects, but to increase speed and usability for the short head of users that wrestle with the DSpace UIs on a daily basis. Yes, make provisions to increase accessibility for all. Yes, have alternatives for users who cannot use javascript effects. But please, please, please give users the same type of experience that they are used to with nearly every other website now. There are tons of javascript frameworks that make this sort of thing easy to implement. Might I suggest Scriptaculous?
6. Make the themes more available. — Someone should establish an XMLUI theme library. Perhaps there is one, but if so, I am not aware of it. Anyone could establish such a library, but I really think it would help those less fortunate potential adopters that don’t have entire teams of web designers and Java gurus.
7. Make the XML-based stuff database driven. — A couple examples are in order. First, the controlled vocabulary functionality should be in a database. IMO, there should be a way within DSpace to edit and add to controlled vocabularies. There’s not. One has to maintain a controlled vocabulary within a separate system, and then store the CV as XML.Second, the welcome message (I’m thinking of XMLUI here, but it may also be the case in JSPUI) should be in a database. In my opinion, if it’s content that can be changed by the user and is not binary data, it should be stored in a database. Items like welcome messages, sidebar content, and controlled vocabularies are all good candidates for treating in this way. I long for the day when XML will be treated merely as a transport format or medium for structural layout, rather than a storage format.
8. Make the batch process streamlined. — Anyone who has used the batch process knows what I’m talking about. It’s easier to rope goats than it is to use the DSpace batch uploader. The software should have a utility that allows a user to select a whole bunch of files which are automatically uploaded. The utility could also extract metadata from the files (Exif, IPTC, or whatever) to write to the database as the file’s descriptive or structural metadata. At present, one either has to manually package the files appropriately and write Dublin Core for each file to be batch uploaded, or create some sort of program that will package the files and write the Dublin Core. I know, it’s  a difficult thing to do. Still, if Flickr can do it  for Exif data, then it can be done.
9. Make the documentation readable. — I’ve seen worse, but I’ve seen much, much better as well. It would be nice if the documentation had a “How to do simple stuff” section that covered a lot of the really simple things one finds in the DSpace wiki — things like making adjustments to headers and footers. I believe that a lot of the questions that get asked repeatedly on the listserv would stop being asked if the official documentation addressed them clearly.
10. Make the mental switch to Rails. — DSpace has a certain musty, 1.0 kind of odor about it. As soon as you unzip it, this smell, tantamount to descending into your grandmother’s basement, wafts up from your computer. As you look around at it, you realize that it’s been around for a while. It’s reliable — like the old pedal driven Singer sewing machine in the corner of your grandmother’s basement — but it also feels a little antiquated. More and more, users are accustomed to web apps that have a 2.0 feel. We’re used to sites developed in things like PHP and Rails. We’re used to sites that give us a good user experience. DSpace needs to become that. It needs to transition. It needs to be more “Rails-ish.” I realize that the developers are probably not going to scrap the whole codebase and start over with a new framework and language. But Java can look like Rails, feel like Rails, and have a certain Rails kind of quality to it. However, it takes developers thinking like Rails guys (and gals). I hope this happens. If so, version 2.0 of DSpace could very well look and feel 2.0.

Here’s a link to the Endnote add-on download page.

Here’s the hack instructions that I used.

Happy hacking. And researching. And writing.