Member Nodes

The server VMC is using is managed by the institution's central IT department. As of now, GMN has successfully been installed on CentOS 7: https://dataone.uvm.edu/mn/v2. This is presently a standalone installation, and will remain so until the adapter integration between their repository and GMN has been fully developed and tested.

Jim provided this status update 22 June:

I just wanted to provide a status update to the whole group. Mike and Monica have been making headway on the URL endpoints and setting up our adapter, and will be having another round of work very soon. I don’t think we need to set up call immediately, I am hopeful that we will have something workable to show before the July 4 holiday, after which it would be great to talk again.

There was a bit of a problem getting access to the FEMC endpoints earlier in the month, but Monica and Mike/Jim were able to sort this out.

ABOUT RESTFUL ENDPOINTS
This operates in two parts. First there is an endpoint which presents the identifiers which have changed since a point in time. Then these identifiers are fed into a 2nd endpoint which can be used to retrieve the metadata object for that specific set of identifiers.

The first endpoint for records changed is of the following format:

https://www.uvm.edu/femc/dataone/changedDatasets/changedSince//X-API-KEY/

For example:

https://www.uvm.edu/femc/dataone/changedDatasets/changedSince/1502668800/X-API-KEY/gumboandcrawfish

will return values such as:

12345
67890


12345
09876

Which may then be used in the following way as:

/femc/dataone/datasetEML/projectID//datasetID//X-API-KEY/

Such as for the above example:

/femc/dataone/datasetEML/projectID/1065/datasetID/2294/X-API-KEY/gumboandcrawfish

The result of the specific record request will be a science metadata xml file returned.

The build of metadata records from data in the native system was using an outdated algorithm which, among other issues, prefixed the eml namespace to all elements. This invalidated the xml document. An updated script for generating eml documents has been applied. There may still be a few invalid documents to look out for here or there to look out for with small errors.

Additional Requirement:

FEMC system permits researchers to temporarily set an existing data set to be private. They are concerned as to how this will be handled in DataONE. They don't want to archive it yet because something can't be unarchived once that is done.

Proposed solution:

Use .update() to remove public access rule from system metadata to create outcome of privacy. Add a status to the FEMC endpoint which lists altered records to identify appropriate action. This could also provide a tidy way of identifying if a record has been deleted /archived in your system so that DataONE knows to archive it on our copy as well. For example:

@

20
229
ACTIVE


20
229
HIDDEN


20
229
DELETED

@

An important consideration is to ensure that, if a metadata record changes between the time it is set to private through removal of access rules and the time the author wants it to go public again, we must make sure to execute an update() instead of just .updateSystemMetadata()

• FEMC has acquired their Stage DataONE test certificate/key.
• New certificate are installed and CRUD tests done.
• Adapter has been developed ( https://github.com/DataONEorg/SlenderNodes/tree/master/femc)
• Adapter is installed on FEMC MN server and cron setup for 3 hour intervals. Testing is in progress. The node operator will wait for initial load to complete and then will manipulate some test records so we can confirm updates are cascading to GMN.
• Will convene with Mike in 1-2 days to check progress and testing. If all looks good will complete registration at that time.

Jim has completed updates to metadata generation script and new metadata record versions have been harvested. No failures observed in the CN logs.

Working with Jim to get a service agreement signed by our two institutions...DataONE doesn't have such a doc...Jim sending us one to sign.

8/27/19: sent Jim reminder email