We're creating a database of eighteenth century clubs, recording overlaps in membership, venues, events etc.I'm hoping that we can gather our data in an ms access database, which will allow us to take advantage of the relational capacity easily. We have tables for clubs, individuals, events, and venues, and transaction tables for membership records, event descriptions, event attendance etc. We also have lookup tables for regions, club types etc to make data entry easier.
Our ultimate plan A is to try to publish this data using omeka, using various plug ins to record relations.
However, we are a little fuzzy on the details... One thing I am particularly wondering about is whether you can manipulate relations between items directly in the MySQL backed using phpmyadmin and also if you can import tables to the MySQL db rather than using the csvimport plug in?
The other plan ( plan b!) would be to abandon the ms access part of the process and gather data directly into omeka.
What do you think about our plans, and can you advise me about how to best use omeka either to gather the data or to represent the data we gather and import from ms access.
Any and all advice / thoughts greatly appreciated.
In a lot of ways, what you describe actually sounds more like a Drupal site than an Omeka site, at least out-of-the-box. Drupal's real strength is the ability to create those relations between different types of content. House Divided is a good example that seems similar to what you are describing.
On the other hand, getting all that set up in Drupal would be a much more complicated task, though once it is set up it would do some nice things for you automatically.
In Omeka, there is the ItemRelations plugin, which would let you build relations in a similar way. There would still be some setup to do there, but I think it would be quicker and easier than building a Drupal site.
Neither Drupal nor Omeka would let you directly import tables -- to either CMS, the new tables would be completely foreign, and the system wouldn't know what to do with them.
So, here's roughly what I see, at least in Omeka. It's a bit of a hybrid of your plans A and B. For the different types of content (clubs, people, events, etc.), create a new Item Type in Omeka with whatever additional metadata fields you need for it beyond Dublin Core. Then, use the CSV import plugin to import the data for each of those types separately. That would not, however, capture the relations, so the next step would be to use the ItemRelations plugin to manually build the relations between the items -- with the batch feature, coming out soon! :)
Depending on how much data you already have in access, you might want to import soon and switch over to doing it all in Omeka (or Drupal, if you go that route).
Hope that helps
Thanks for your helpful response.
I know what you mean about Drupal. I've been playing around with it but I don't really get it and I've found it difficult to set up relations, exactly what you said: it seems much more complicated or steep a learning curve, though I can see in many ways it might be worth it in the long term.
Thanks for clarifying about the import tables thing.
Your description of the 'hybrid plan' is extremely helpful and reassures me we might be able to use omeka. I need to think about whether I would make the entities on the transaction tables 'bridge' item types, as the information they contain is important too -i.e. they don't just link a club to a person, but record the date of that link and the source of that link. So I suppose I could have the true item types and the transaction item types and relate them all using the item relations plug in. So for instance you'd have clubs, people, but also membership records, as item types. If you think that would be problematic, please let me know! This is where I guess Drupal is inherently more suitable.
If we do go with omeka, the batch feature is going to be crucial, I suspect. I'm still thinking access will be the tool for collecting the data just because I think it might be easier from a data entry point of view...I might be wrong though, and the possibility of a problem with importing the data to omeka at a later stage would be worrying. I suppose the thing to do would be to test the import and check it works before going too much further or deciding either way.
Thank you very much for your thoughts.
Ah! I like that structure of having the membership record there. It complicates things, but is great data to have! What you describe sounds like the way to go with it. The Item Relations plugin will let you build the relations you need. Out of the box it has a variety of relations to choose from. If none of those quite fit, I'm pretty sure a plugin can add new relations. The biggest complication I imagine is some theme hacking to display the relations as you want.
Yes, I'd definitely test the import process early to make sure it works out okay, but there will always be a slight risk.
Hi Tara and Patrick,
I was wondering whether the project described by Tara was finally built on Omeka or on Drupal? I am working on a similar situation which requires the creation of custom relations between items and would like to use Omeka.
Patrick, it appears the ItemRelations plug-in does not work under Omeka 2.0 ?
Yes, ItemRelations has not yet been upgraded for Omeka 2.0. It's a fairly complex one, requiring lots of changes to work with 2.0. We'll have it updated as soon as possible, but I can't give an ETA as yet.