Project

General

Profile

Task #8511

MNDeployment #5451: Cary Institute (via Figshare)

Story #8509: Figshare: Development & Testing

Figshare: Develop or Implement MN Software

Added by Amy Forrester over 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
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:

  • 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:

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 over 4 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 over 4 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 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

#4 Updated by Monica Ihli about 4 years ago

  • % Done changed from 0 to 100
  • Assignee set to Monica Ihli
  • Status changed from New to Closed

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 14.8 MB)