Research changes in H2 for GIS deposit

[edsu]

@kimdurante has a user who would like to deposit GIS items potentially via H2. This ticket is to research what changes would be needed to allow an item deposited via H2 to be accessioned using gisAssemblyWF. Some things to consider include:

• how would the user indicate their data is GIS data?
• how would users need to structure their data for it to be processed by GIS related workflows?
• how would users get feedback when their data is not structured properly?
• are there additional steps that are needed in GIS SDR workflows to ensure the data is processed correctly?
• can users associate their data with a DOI if desired?

[amyehodge]

@edsu

• how would we collect the geospatial specific metadata? My understanding is that these objects would need at least bounding box information. There is currently no place for that in H2. What other metadata/vocabularies/etc might be needed, e.g. geoNames?
• will this need its own special version of the deposit form?
• do any of the H2 file upload options work for how the GIS data needs to be structured?
• can users submit other files along with the gis files? how do we either make sure that they don't submit other files (if we can't allow this) or be sure that we understand which files are for earthworks and which aren't?
• where/how can we link from the PURL that will be created to the EarthWorks record?
• if a DOI is made, should it point to the PURL or the EW record?

[kimdurante]

Geospatial specific metadata (bounding boxes, projections, geometry types, and file formats) can be extracted from the data directly. One thing we would need to account for is the creation of ArcGIS/ISO metadata, but we could probably create that as well.
Something else we would have to consider is that, currently, GIS data are structured as: 1 layer = 1 druid, so the deposit process would have to allow for that.

[amyehodge]

@kimdurante We should consider where/when that extraction would occur. The H2 database is the version of record for all items deposited via H2 (except in a few cases, but then depositors can never use H2 again to update those items). If the extraction occurs after H2 deposit ("outside" of H2), this would make these items another exception to the rule that staff then need to maintain for depositors. If it happens "inside" H2, then we need to be able to store that metadata in H2. Just something I want to be sure people are thinking about. I'm generally opposed, as I think is @andrewjbtw, to anything that creates more exceptions to the rule that users can maintain or themselves.

Edit: I'm thinking about this again and realizing that if the extraction happens "outside" H2 but every time, this may be fine? Basically, I just want to make sure these workflows are carefully considered so we don't end up with more exceptions to the rule or objects that have a tendency to get stuck when versioned etc.