CSV Import: Referencing Linked Resources?

Omeka S Modules
1

Hi,

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.

Paul Cote,
Cambridge Massachusetts Historical Commission, Digital Architectural Survey

2

One workflow is to make the Buildings and Documents into separate CSV sheets. Import the buildings first. Once you have the buildings created as items in Omeka S, you can apply their ID numbers to the Documents csv (I usually do this in a new column next to the one holding the original reference data).

3

Thank you Meghan,

That is a promising idea. In my case I have thousands of buildings. Too many to do a manual lookup and transcription of the OmekaIDs so I guess I would use a workflow like this:

  1. Create building items with Building_Import.csv which includes a Unique DC Identifier that is constructed from the Building Address.
  2. Create a lookup table with an SQL query that extracts the OmekaID for each building item along with the address of the building.
  3. Construct a Document_Import.CSV that gets the OmekaID for buildings by looking up the address in our lookup table.

Is this the way that you do it? If so, I would greatly appreciate an SQL snippet or any hints about the tables involved.

I noticed that the advanced options in the CSV Import module allow you to use any item property to identify items for for updating and deleting. In the case of multiples, the latest one is used as the target. Maybe this same logic could be re-used be to use any item property (preferably unique) to link a new item to an existing resource without having to know the Omeka_ID. Under the covers, this may be functionally similar to the workflow described above, but without the wrangling of tables and joins on the side.

But, until I learn some Zend, the approach that you suggest will get me where I want to go!

Thank you very much and have a great day!

–pbc

4

Funnily enough we were just discussing this today in a slightly different context. You’re correct that the “lookup” functionality is already there for use to link media to parent items and items to item sets, but just not for “link” property values.

The only barrier here is just figuring how we’d go about integrating it into the interface. The importer’s interface is a pretty complicated beast already (as I’m sure you’ve noticed) so this isn’t necessarily a trivial consideration. I think it might make sense as a further “option” you can select after marking a column as being “resource” values: select what property to look up to make the link, internal ID (as now), or a selection of properties.

This is the same UI used for doing the other kinds of this linking we already support, just moved.

5

Hi,

Maybe the “Link Item” interface could be nearly a clone of the “Link Item Set” widget? Or maybe a set of radio buttons on this panel would let you select Item or Item Set, before choosing a Target Identifier column in the pull-down.

…Screenshot Below from the Import CSV Module Documentation …

image
image.png788×320 26.7 KB

…