Work with Omeka soldiers on. As I write more PHP to handle the relational metadata on display for the site, I continue to notice some of constraints of my present setup:
- The code specifying the functionality for recognition and categorization of relationship metadata (‘Is Part Of’, ‘Has Part’, ‘Connections’ and now ‘Sister Part’) is inside the custom theme. This is breaking the principle of content and display as separate operations that can mix and match. Thus if you take away the custom theme, none of the relationship functionality is present. This was not a strict division in the first place, but that’s even less so now.
- Omeka does not provide a way to formally link objects together beyond grouping them into collections. While the Extended Dublin Core plugin provides useful dcterms like ‘hasPart’ and ‘isPartOf’, and while they can be expressed in RDF/XML, the Omeka system itself does not provide a way to hinge functionality upon such relationships. In fact the only way an item’s associated components are displayed is through some string manipulation of the item’s ‘isPartOf’ or ‘hasPart’ values. I cannot just ask Omeka for the related items.
Despite these constraints, I am not disappointed with the setup. I think Omeka’s presentation strength is perfectly suited to this work and to my timeframe. This particular project is about presenting a model that can be critiqued and shared. To that effect, the Turing test can (more or less) work here: if it operates now as fully functional, and appears semantic and scalable, then it has achieved the purpose. We don’t ask, “Is it extensible, interoperable, and semantic?” We just ask, “Does it work that way? Would such a system be worthwhile?” There is nothing on display now (on the local machine, that is) which could not be easily done elsewhere in a more robust, scalable way if it were deemed important enough to do it. I am thinking particularly of the Fedora repository, which I have worked with at the Goodwill Computer Museum, as well-suited to the sort of lateral, semantic relationships this model would provide.
Matt noted this sort of modeling as potentially useful for platform studies, and I imagine an entire linked database of such modeling, where one could index any number of machines by any number of properties and components, would help digital humanists examine machines or platforms across an array of creators and timespans, and would facilitate some easier groupings and associations.
In any case – going back, the first constraint is a matter of abstracting the code enough so that it can function as a plugin. Such an effort is considerable because the plugin would need to achieve the logical linking of items that the present implementation does not. My first instinct would be to directly manipulate the MySQL Omeka database, and insert foreign keys and such. And while doing this, one would want to keep the configurations flexible enough so that the plugin is of use to other Omeka users who need to define relationships in an entirely different way. It’s an interesting project, but also beyond the scope of this one I think.
Moving on, this week I’ve added a ‘Sister Parts’ display which shows components that are part of the current item’s container. The upside is more information on display, and faster browsing. The downside is more information on display (read: clutter!).
Beyond this, we are presently working on getting an instance on a live server for some broader access and viewing. Keep your fingers crossed.