Over the course of the next month or so, we’ll be developing an Omeka S site to host translations of medieval documents — which means we need to know how Omeka S works. Today (and over the course of the next week or so) I’m taking a dive into Omeka S’s documentation in order to prep. The documentation is available here, in case you were curious.
I won’t rehash it, because explaining a lot of the technical stuff will get boring fast, but the main takeaways of the beginning are much more geared towards questions of design and planning than specific fiddly technical bits. So that’s what I’ve been thinking about in the context of our project. They’re good questions to ask of any project, but I’m going to answer them here specifically for what we’re doing, because… yeah.
Who is our audience? Primary, or secondary? Our primary audience will be historians who want to reference medieval documents; our secondary audience, if we decide to make this part of the project, might be translators looking to share their work. That’ll need to be another conversation.
What do we want people to be able to do on our site? The site’s primary concept is as a searchable repository: we want people to be able to locate useful documents based on the metadata associated with them. That means we don’t need many pages of context, beyond perhaps a description of the project; the scholarship being done is in the presence of the content. The open-ended issue here relates to the first question: do we want translators to be able to share their work? That’s functionality we can add… but is it functionality we need?
How are we thinking about what’s on our site? Omeka S operates using items, which have properties (metadata…ish?) associated with them; the items can be grouped into item sets, which also have properties. Items, item sets, and media can be used as properties for other items and item sets.
This is probably the blurriest part right now. Each translation will almost definitely be its own item, but what will the core theme of each item set be – if we even have item sets? Will we end up making other features of the translations items, in order to create a better network through properties? (IE, if we have multiple translations from the same author, should we make the author also an item, so that we can navigate from the translation to the author to other translations?)
This would be a question to answer before we get started, since it would inform everything about how we enter the data. It’s not a bad idea, but scope creep is… not something to take lightly, and we need to do some time estimations.
Goals for planning, then:
- Plan out our rough stages (given what we need the site to do, what do we build first? When/how do we add the translations, and how do we store them?)
- Ballpark the amount of time each stage might take
- Figure out who should be doing what, depending on the amount of time we have, what our deadlines are, and who’s busy when
- And of course, keep reading the documentation
Leave a Reply