Item Hierarcy & Inheritance

Omeka S Development
1

Greetings,
I’ve implemented an Omeka-S schema to organize Documents that are related to Places. We currently have about 14,000 places and 75,000 documents. This hierarchy has advantages, since the map interface only has to have one marker for each place. Clicking on a Place marker populates a panel showing the properties of the Place and a listing the documents related to that place. To see this in action, see cdash.cambridgema.gov

Our semi-automated workflow for sorting, digesting and bulk uploading items assigns a marker location to each document that corresponds with the location of the parent place. Documents have other properties that are place-dependent: Document titles incorporate the Name of the parent place and the Type of the document; Documents also are tagged by neighborhood and a have a StreetSort key that allows items to be sorted by the street address of the parent place ordered by StreetName, then HouseNumber)

So far, so good! Now an opportunity / challenge arises as we transition from the automated bulk loading process to ad-hoc corrections and item creation. When it becomes necessary to adjust the marker location for a place. I’ve created a somewhat hackish procedure that syncs the place marker locations of documents using a PHP script that uses SQL to updates the Mapping_Marker table for all documents, syncing them with their places. I realize that it is probably not a great practice to hack the MySQL schema in this way, but it is fairly simple owing to the one-to-one relationship of items to markers.

Now, I am looking at ways of updating other properties of documents – like the Titles, Neighborhood and StreetSort key. I gather from the architecture of Omeka-S that the right way to do this would be to create a new module that uses Doctrine ORM to create a extended Item class for Places which would have have Document children. Updates to a place properties would propagate to the child Documents. Hopefully there would also be a behavior so that creating a new Document item and linking it to a place, would also trigger automatic population of properties that are dependent on the Place.

I currently have simulated this inheritance behavior by hacking item show pages, but it does not deal with the street-sort key and the changes have no effect on our street sort function or on search filters. This cosmetic approach would also be problematic if we ever wanted to bulk-export Documents with their place-dependent properties.

I would be interested in advice from folks who have thought about this sort of data model, which could have other applications for ontologies such as biographical information. Is anyone aware of similar modules that create new item classes with relations and triggers like this? Or maybe I am on the wrong track and missing something simple. Doctrine is completely new to me, but I am pretty handy with SQL. Would it be OK, to approach this with a module that adds SQL triggers to the MySQL database instead?

Thanks

2

Hi, I just suggested the database trigger solution on this topic :wink:

Unfortunately, I am not yet familiar enough with Omeka’s architecture to know if it embeds a Drupal-like “hook” system, which would provide a perfect base for custom code triggering on specific events at different steps of the processing.

1 Like
3

I think in general our recommendation would be to as great a degree as is feasible to not duplicate data between the linked resources, the places and the documents here, and just let the linkage handle that either by having visitors follow the link, or pulling in metadata from the linked place with a custom theme or resource page block. So the documents would have only the link to the place, and the place alone would have the mapping marker, the address, etc. But there are things like titles, if they’re intended to be based on the “parent” place, where that would be tricky to accomplish and so some duplication could be the right move.

So, moving on to doing that duplication and keeping things in sync. In terms of hooks/events/etc., Omeka S has events that trigger when operations are performed that you can listen to to perform other actions; there’s a list in the developer docs. The “api” and “entity” events are probably the most interesting if you’re looking to trigger an action when things are added or updated. Triggers on the database level isn’t a strategy we use in Omeka itself, but it’s not necessarily a problem to use them for a specific project where they would make sense, and maybe this is the case here.

Sticking with more “Omeka-native” solutions, I could imagine a module that is listening to, for example, the update event for items, and when a Place item is updated, it iterates over the linked Documents and updates them to recalculate and replace the title, or whatever other metadata. I could also imagine a workflow that works outside the system somewhat like your location update solution; using the Omeka S REST API to edit the “parent” and then loop through and update the children; doing it directly in SQL is also a possibility.

1 Like
4

Thank you for taking the time to understand the problems so thoroughly and for the alternative approaches. I am clearly at a stage for digging in to laminas, doctrine and Omeka-S modules!

I agree about duplicating data, I have been thinking over the past couple of days, that many of my problems could be solved if I could trick search and view-property functions follow joins. For example, for sorting lists of Documents on the value of StreetSort that is associated with the Place. Much of the desire to duplicate Place data on Documents is oriented toward avoiding more numerous modifications to the basic Omeka-S search and show behavior.

You have given me a lot of good direction here. I’m especially happy that you did not rule out usning good old-fasioned SQL! I may post an update on this thread later.