This may be an Omeka-S site design question, or the answer may lie in a CSV Import tip that someone may have. My problem is that I am trying to use the Omeka-s CSV Import Module to build a simple network of linked items.
Most of the items in our collection represent documents. Each document is associated with a Street Address, or Building. I would like to use Omeka-s to represent Buildings as a class of item. Building items would have a location that is recognized and managed with the Mapping Module. Building items would be referenced by document items.
I know the relation of Documents with Addresses in advance, It would be nice if the CSV Import tool would allow me to include a reference to a building item in the metadata for a document item using an intentionally-assigned property such as a (unique) DublinCore Identifier, which had been assigned to a Building Item in another (previous) CSV Import operation.
I see that the CSV Import module will let me reference an Item Set, but this is not my dream scenario because item-sets do not interoperate with the Mapping Module; The awkward assignment of thumbnails to item-sets is another strike against representing buildings as item sets. It seems to me that in a linked-data architecture, I would want Buildings to be first-class items.
The CSV Plugin will let me include a reference to a Resource ID of another item, which is almost what I need, But the problem with this is that this resource ID is not predictable (to my knopwkedge) and therefore impossible to code into the CSV import script for document Items. I guess that one could modify the CSV Import module to define a new data-type associated with an object-ID lookup …once I learn how to modify Omeka modules.
It occurs to me that the old Archive Repertory module for Omeka Classic would be useful in this case, since the URI for Building Items could be foretold in advance so that the building identifiers could be created in one import and then referenced by documents created by successive import operations. Would it make sense to try to migrate the Archive Reperatory plugin to Omeka-s to enable the sort of functions I need? I could imagine that this might create problems for example if the URIs end up changing due to some sort of migration scenario.
OR it may be that I am overlooking an obvious solution to this problem! Or trying to force Omeka-s to do something that is outside of its scope. Can anyone out there see whether my conception of linked document items and building items makes sense? Or whether there is a more effective way of expressing these relationships using the existing capabilities of Omeka-s and the CSV Import module.
In any case, thanks for reading this and for any comments, advice, or encouragement that you might have.
Cambridge Massachusetts Historical Commission, Digital Architectural Survey