Change node's primary MNDeployment ticket status to Testing.
- 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.
* 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.
#2 Updated by Amy Forrester over 4 years ago
6/13/18: from Tudor Panescu email@example.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 4 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