owned this note   changed 4 years ago  
Linked with GitHub

InvenioRDM - SWH: launch meeting

tags: software preservation software identification SWHID DOI

Introduction

Useful Links:

Scenario 1 : New content deposit (using tar.gz, .zip, etc.)

Limitations

  • Only open access content (not including Embargoed,Restricted, Closed)
  • Only Software type

Sequence diagram


User->Invenio: upload files and metadata
Invenio->User: publish deposit with DOI
Invenio-> SWH: push deposit
SWH->SWH: check deposit
Invenio-> SWH: retrieve status 
SWH->Invenio: status
Note right of SWH: loader \n ingest \n deposit
Invenio-> SWH: retrieve status 
SWH->Invenio: status & SWHID
Invenio->User: publish deposit with DOI and SWHID

Scenario 2 : Invenio - GitHub integration

  • Automatic integration of deposits for each release
  • Automatic metadata creation (that can be updated)

Zenodo automatically extracts metadata about your repository from GitHub APIs. For example, the authors are determined from the repository's contributor statistics. The automatic extraction is solely a best guess. Add a .zenodo.json file the root of your repository to explicit define the metadata. The format of file is the same as for our REST API (use e.g. below JSON to get started).

Limitations

  • [don't apply] Only open access content (not including Embargoed,Restricted, Closed)
  • [don't apply] Only Software type

Sequence diagram

User->GitHub: create repository on GitHub
User->Invenio: links account with GitHub & flip switch for repository
User->GitHub: create release 
GitHub->Invenio: new release
Invenio-->GitHub: GET: fetch release
Note right of Invenio: metadata \n automatic \n extraction
Invenio-->User: publish deposit with DOI
Invenio->Invenio: calculate SWHID
Note left of SWH: SWHID zip \n SWHID release \n metadata \n original url \n DOI url
Invenio-> SWH: push deposit
SWH-->Invenio: deposit_id
SWH->SWH: links
Invenio-> SWH: call "save code now"
SWH->SWH: check deposit
Invenio-> SWH: retrieve status 
SWH->Invenio: status
Note right of SWH: loader \n ingest \n deposit
Invenio-> SWH: retrieve status 
SWH->Invenio: status & SWHID
Invenio->User: publish deposit with DOI and SWHID

Remarks

  1. The SWHID that is returned is for the zip (swh:1:dir:aaaa…) with the context, using the anchor qualifier with the release identifier (swh:1:rel:bbbb…) if save code now succeeds

  2. Save code now is called by the client on the repository's url (without .git) to ensure all development history of the artifact is preserved

Scenario 3: Push/Update metadata linked to a deposit/SWHID

The user can update and modify the metadata of a deposit in both cases (simple deposit or GitHub integration deposit).
We need to provide a mechanism to capture the updated metadata, without reloading the content.

Sequence diagram


User->Invenio: update metadata
Invenio->User: publish new metadata 
Invenio-> SWH: add metadata to SWHID with context
SWH->Invenio: deposit_id
SWH->SWH: check metadata
Invenio-> SWH: retrieve status 
SWH->Invenio: status
Note right of SWH: fetcher \n ingest \n metadata
Invenio-> SWH: retrieve status 
SWH->Invenio: status & SWHID
Invenio->User: publish deposit with DOI and SWHID

SWH ingestion of content

If the deposit contains content it is the loader that comes into play:

  1. creates origin with DOI
  2. creates snapshot for the deposit 'visit' with the push date
  3. creates synthetic revision to link between versions
    • since the DOI (not like the HAL-ID) is independent from versioning, how should we proceed?
      • use concept DOI for origin?
      • use version DOI and have the concept DOI in metadata
      • can revisions be linked if coming from different deposits?

SWH ingestion of metadata

If the deposit contains only metadata it is the fetcher that comes into play:

  1. associates the metadata with the artifact it describes:
    • origin
    • snapshot
    • release
    • revision
    • directory
    • content
  2. with the date of the metadata receival (a.k.a the date when the deposit arrived)
  3. with the context qualifiers of the SWHID (if possible)

Stages of Development (from the InvenioRDM proposal)

Stage 1: Core Development

  1. Upgrade the SWORDv2 Python client to Python 3.
  2. Implement a Software type in InvenioRDM which is compatible with and as extensive as defined by Code Meta.
  3. Implement an export package format that is compatible with Software Heritage.

Stage 2: InvenioRDM to Software Heritage base integration

  1. Implement a general asynchronous worker for SWORD deposits
  2. Implement new deposit workflow
  3. Implement updated metadata workflow
  4. Record and display suitable minimal information on deposit state

Stage 3: GitHub Integration

Questions

Q:

Meetings

14 December 2020 on https://meet.jit.si/InvenioRDM-SWH

Select a repo