Archive for the ‘dspace’ Category
I posted the following today on the DSpace wiki as a proof of concept for using the HTML 5 video tag within DSpace using Manakin. The original post can be found here.
- [manakin-source]/themes/[theme-dir]/template.xsl (The theme’s stylesheet)
- [manakin-source]/themes/dri2xhtml/DIM-Handler.xsl (The theme’s stylesheet)
- 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.
- Add the OGV to the metadata registry using the instructions found here —> Add a new format to the bitstream registry
- Create an OGV video. If you have Firefox, you can use Firefogg to do it.
- Upload your video to your DSpace install.
- If you haven’t already, you need to Create a new theme (or don’t, if you don’t want to).
- 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.
- 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>
- Of course, stop and start DSpace for good measure.
- 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.
Recently, I had reason to install xpdf on RHEL 5 for use with DSpace. I had already installed freetype, but for some reason, the xpdf configure file was not able to find the freetype2.
I finally got this configured after running the following
This gave the output of -I/usr/include/freetype2
Next, I used that path with the configure command as follows:
After that, it configured perfectly.
I’ve been working with DSpace recently, and I am amazed with the power of this wonderful repository system. It is an incredible platform for long term preservation, access, and dissemination of content. It has incredible OAI and indexing abilities. It is well developed, well funded, and well … well, let’s just say I can’t heap enough praise on it. I think it’s the best repository system available, bar none.
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.
- 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.
- Make the media stuff seamless. — It is a YouTube/Flickr/Amazoogle world. Embed or you’re dead. ‘Nuff said.
- 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.
- 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).
- 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.
- 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.
- 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.
- 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.
- 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.