Auto-config options for CSV Upload

Omeka S Development
1

I’m scoping out an some planned work related to the CSV Upload module, and I was hoping I could solicit some advice. Described here: Feature Suggestion: Config Persistence · Issue #218 · omeka-s-modules/CSVImport · GitHub, I would like for users to have the option to retrieve the CSV Import options they made from a previous upload, or to upload a config file along with their data. This would populate mapping and options settings for properties as well as basic settings and advanced settings.

Questions:

  1. Is this the kind of feature you would support/entertain a pull request?
  2. My first thought was to model the implementation for basic and advanced settings after other auto-filled values for fields in those areas (e.g., getDefaultSiteIds()) and to manage the field configuration after the auto-mapping feature. Do you see anything wrong with that approach?
2

So, if you look around you’ll find a few other threads discussing this.

My plan/vision for this feature has been to save settings that would get applied with Javascript: i.e., you’d save your settings, then when doing a later import you’d have an option to apply them, which would just go set all the the forms up as if you’d manually entered the same settings. Then you could modify them from there if you needed to. These saved settings would probably just be JSON stored in the database, in a user setting maybe.

My general sense is that approaching this client-side would work out better than trying to set it all up on page load as we do now with some saved settings. But I’ve also conceived of this happening in tandem with some cleaning up of the JS that currently runs the mapping UI: for example to break things out into functions and then use the same functions for doing a user’s live changes through the UI and for applying saved settings.

I’m not currently working on this at the moment. Certainly there’s lots of interest. We’ve seen some other people take approaches like saving the JSON that comes out at the end, the job arguments, and “replays” them: I’m more likely to accept (or implement) something along the lines of what I described above than that approach.

1 Like
3

Thanks, John! Glad to hear that you would support the client side approach. The refactoring you suggest makes sense to me. I’ll start working along those lines and draft a pull request.

4

Note that such a feature in server side exists with module Bulk Import (Daniel-KM / Omeka-S-module-BulkImport · GitLab). For spreadsheet, as long as you have headers formatted as property @language ^^datatype §visibility, for example dcterms:title @fr §private or dcterms:date ^^numeric:timestamp, the full mapping will be done automatically.

1 Like