Scholars' Lab

This issue came up for a friend of the Scholars’ Lab today on Twitter, but it’s hard to answer in 140 characters. It’s a question about allowing for larger file sizes in Omeka and there are a few ways to handle this. (Because we want our new blog to be a combination of thoughtful essays on digital scholarship and quick answers to real-world technical problems, I thought I’d post here.)

Since Omeka runs on PHP, this is actually a PHP configuration issue and not something you can currently tweak in Omeka. Basically, you just need to tell PHP to allow larger files sizes that are larger than the default. A very easy way to do this is to edit the .htaccess file that Omeka ships with along the following lines:

php_value upload_max_filesize 20971520
php_value post_max_size 20971520

I’ll note here that doing things this way only affects your Omeka project. Another way to go about this is to add the above to the Apache configuration that defines from where Omeka should be served. For example:

<VirtualHost *:80>

ServerName www.coolomeka.org
DocumentRoot /var/www/omeka

<Directory "/var/www/omeka">
    Options FollwSymLinks
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>

    ErrorLog logs/omeka_error_log
    TransferLog logs/omeka_transfer_log

    php_value upload_max_filesize 20M
    php_value post_max_size 20M
</VirtualHost>

Lastly, you can edit the php.ini file (usually in /etc/php.ini or /etc/php5/apache2/php.ini). Just do a search in the file and change the following settings:

  memory_limit = 32M
  post_max_size = 20M
  upload_max_size = 20M

You typically don’t need to reload Apache (as long as you did not edit the Apache configuration file) to get these settings to work.

For more info on this, check out these resources

• Description of core php.ini directives
• PHP Upload Configuration
• PHP Directives Related to (Large) File Upload

I’ve called Neatline, the Digital Humanities Start-Up project Adam Soroka and I began developing in September, a “contribution to interpretive humanities scholarship in the visual vernacular.”

Huh?

This project will allow scholars (and other stewards of cultural heritage) to create Web-based geospatial and temporal visualizations that build on the rich EAD metadata libraries produce in describing their archival collections and making them more discoverable — but the crucial twist is that we didn’t want to think of our Neatline visualizations as products of the metadata. They’re not brain-dead algorithmic output or some kind of thoughtless expression of the archivist’s (nuanced, but necessarily broad) stance toward historical or literary documents of interest. (Yes, I’m asking for it; bring it on!) In other words, Neatline isn’t about the parsing of placenames and automated population of timelines with data. Rather, we’ve conceived this tool (really, as development proceeds, this approach, because Neatline is emerging as an arrangement of instruments and an attitude toward their use) as a kind of playspace for the scholarly interpretative act. In future posts, we’ll describe our development effort and I’ll delve a little into the conceptual background for Neatline in the Temporal Modelling project I undertook several years ago with Johanna Drucker.

In the meantime, you can read about how we’re employing the Omeka plugin framework as a way to handle GIS services for scanned historical maps on the ScholarsLab.org project pages for Neatline-in-progress and our larger Omeka plugin work, or you can check out our dedicated project blog.

Among my regular tasks in the Scholars’ Lab Research and Development department, I have been developing applications to enable users to easily edit XML metadata within web forms.  As those familiar with metadata creation workflows will know, methods for creating XML documents were prone to human error and required some level of technical knowledge.  With XForms, a W3C standard for creating dynamic web forms, the technical barriers for creating robust metadata can finally be removed.

I began working with XForms (and the enterprise application, Orbeon, for rendering the forms and managing data interactions) in July as I improved Numishare, the open source application developed to deliver the University of Virginia Art Museum Numismatic Collection.  The UVA coin collection, described in Encoded Archival Description (EAD) is a visual site with no administrative back end.  In order to provide tools to entice users to try the new software, I had to develop a method that curators could use to quickly and easily manage artifactual information–standard creating, updating, and deleting commands.  I was able to accomplish this entirely with Orbeon and XForms.  The application is sophisticated enough to allow auto-suggest capabilities for controlled vocabulary (based on TermsComponent in Solr 1.4), as well as post directly to the Solr search index when the user saves or deletes a record.

Most recently, I have been developing an XForms application that can generally be applied to the creation and management of EAD finding aid collections.  The project, titled EADitor, has been met with interest from the archival and library coding communities.  While there is much work left to do, the application has definite potential.  It is possible to interact with EAD data that resides in the institutional repository, simplifying the process by which the guides are edited and saved back in the repo.

Other institutions have developed forms for other metadata standards common to libraries, so my colleague in the Scholars’ Lab, Adam Soroka, and I have started a listserv in order to facilitate better discussion and collaboration between units working on similar projects.  Hopefully, the library community will eventually use XForms applications that streamline the metadata creation process for all XML standards that are commonly used.