# Invenio - SWH

###### tags: `software preservation` `software identification` `SWHID` `DOI`
[TOC]

## Introduction

- CodeMeta vocabulary (https://codemeta.github.io/)
- CodeMeta generator form (https://codemeta.github.io/codemeta-generator/)
- The SWHID- an intrinsic persistent identifier (https://docs.softwareheritage.org/devel/swh-model/persistent-identifiers.html)
- SWH deposit client (https://docs.softwareheritage.org/devel/swh-deposit/getting-started.html)
- SWH deposit spec (https://docs.softwareheritage.org/devel/swh-deposit/spec-api.html)
- SWH deposit metadata (https://docs.softwareheritage.org/devel/swh-deposit/metadata.html#deposit-metadata)
- SWORD3 specification  (https://swordapp.github.io/swordv3/swordv3.html#21.3)

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

- Deposit to SWH content + metadata:
- Getting started with [swh-deposit client](https://docs.softwareheritage.org/devel/swh-deposit/getting-started.html)
- API for the [SWH SWORD 2.0 server](https://docs.softwareheritage.org/devel/swh-deposit/spec-api.html)

#### 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

3. 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)