Task #8511: Figshare: Develop or Implement MN Software - Member Nodes - DataONE Tasks

Task #8511

MNDeployment #5451: Cary Institute (via Figshare)

Story #8509: Figshare: Development & Testing

Figshare: Develop or Implement MN Software

Added by Amy Forrester about 6 years ago. Updated over 5 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Monica Ihli

Target version:

Start date:

2018-03-20

Due date:

% Done:

100%

Story Points:

Sprint:

Description

Change node's primary MNDeployment ticket status to Testing.
Identity Management:
- Confirm what nodeID will be used.
- Register NCEAS LDAP (https://identity.nceas.ucsb.edu/) because cert download auth is maintained by separate system.
- Use Use cilogon to generate a DataONE LDAP account by logging into DataONE test env. (Sign-in link at https://search-stage.test.dataone.org)
DataONE Certificate:
- Request in #CI for a sandbox or stage D1 certificate generated available to NCEAS uid.
- Cert/key downloaded by node operator.

For a custom implementation of DataONE APIs as new service:

MN implements full scope of Member Node APIs.
API methods systematically verified by D1 tech lead.
Passes web tester checks (http://mncheck.test.dataone.org:8080)

For a DataONE Software Stack

Install software, SSL cert, and DataONE cert per installation instructions.
If using LE cert, schedule cron for renewal.
Configure software as appropriate (baseURL, Node Contact Subject, replication, etc).

For a SlenderNode:

Develop adapter.
Fully test movement of data from source system to target MN software.
Install on MN web server and schedule cron job. Verify cron is running as expected.

For both:
* Verify system metadata of test records. Ensure correct node URI value in auth/orig MN.
* Verify node description document. Ensure that Contact Subject is set to the DataONE LDAP identity string.

History

#1 Updated by Monica Ihli about 6 years ago

Figshare confirms that identifier handling can vary from source to source. Will ensure that identifier handling is individually mediated within adapter code.

#2 Updated by Amy Forrester almost 6 years ago

6/13/18: from Tudor Panescu tudor@figshare.com

As the Cary Institute has just recently moved to production, I wanted to be sure to share this update with you, but also to provide you with this information, which I believe you'll find helpful as we finalize everything: https://api.figshare.com/v2/oai?verb=ListRecords&metadataPrefix=oai_dc&set=portal_376.

#3 Updated by Monica Ihli over 5 years ago

Finalizing Figshare Identifier handling:

“no matter how many versions a figshare items has, in OAI-PMH you will always see one record (with a persistent OAI identifier). What changes between versions is the value of, for example, dc:identifier field, which will reflect the latest DOI that was minted for that specific item.”
Minor changes may not be reflected in version number (dc: identifier) change.
However, even minor changes WILL appear in OAI harvest, regardless of whether or not identifier changes, because date modified will change.
So our question: Do we want to enforce versioning via checksum or can we just allow the MN to decide what versions they want to enforce.
ANSWER: We will FOR NOW use contents of OAI-PMH identifier (system identifier) for SID dc:identifier (doi) as the PID for now, understanding that some minor revisions will not be captured. However, will explore future solutions for improving upon this.
Will look at adding a log entry to keep track of how often a record appears with new modified date but without a change to dc:identifier field