I have just returned from the Open Repositories 2016 conference in Dublin where I did a demo in the Developer Track, curated by my colleagues Claire Knowles and Adam Field. The demo went OK, despite being interrupted by a fire alarm.
Here's my abstract:
Presented by Peter Sefton, University of Technology, Sydney firstname.lastname@example.org
In this session I'd like to show off the technical side of the open source platform, Ozmeka (based on Omeka) which was presented at OR2015.
In the demo I will:
Spin up a fresh instance of a repository using a vagrant script my team prepared earlier.
Show how to populate the repository via a CSV file, complete with multiple different item types (people, creative works, that sort of thing) with relations between them.
Demonstrate that this is a Linked-data-ish system, with relations between items in the repo, and external authorities and talk about why this is better than using string-based metadata which is still the default in most repository systems.
Talk about why it is worth considering Omeka/Ozmeka for small-to-medium repository and website development.
To which I added:
Demo loading the same data into a Fedora 4 repository.
The spreadsheet format I demoed is still a work in progress, which I will document on github project; I think it shows promise as a way of creating simple websites from data, including multiple types of object, and nested collections. I took the first fleet maps data, munged it a little to create a linked-data set for this demo. As downloaded, the data is a list of map images. I added a couple of extra rows:
- Two collections, one for the maps and one for people
- Entries for the people mentioned in the metadata the creators of the maps
And extra columns for relationships:
- Collection membership via a
REL:dc:creatorfor the dublin core creator relationship.
What is this?
I presented a paper last year co-authored with Sharyn Wise about an Omeka-based project we did at UTS, building a cross-disciplinary research repository, Dharmae. This time I just wanted to do a quick demo for the developer track showing out how easy it is to get started with a dev version of Omeka, and also show some early work on an Python API for Fedora 4.
This is for developers who can run Python and understand virtual environments. NOTE: These instructions have not been independently tested; you will probably need to do some problem solving to get this to run, including, but not limited to running both python 3 and python 2.
Get the dependencies up and running
- Get & run Omeka via this vagrant script, put together by Thom McIntyre.
Get an API Key via
Install the item relations plugin (it's there, you just need to activate it via the install button)
- Get the One-click-run Fedora Application from the Fedora downloads page.
Import some data into Ozmeka
Assuming Omeka is running, as per the instructions above.
NOTE: This is a Python 2 script.
Check out the Ozmeka Python Utils.
Follow the instructions on how to upload some sample data to Omeka from a CSV file.
Remember your API key, and to install the Item Relations plugin.
Import the same data into Fedora 4
NOTE: this is a Python 3 Script.
Also, note that Fedora 4 doesn't come with a web interface - you'll just be putting data into it in a raw form like this:
- Start Fedora by running the Jar file (try double-clicking it).
- Select port 8081
- Click Start
- Install our experimental Fedora api client for Python 3.
- Follow the instructions to import csv data into Fedora.
Thanks to Mike Lynch for the Fedora API code.
Commentscomments powered by Disqus