# InvenioRDM - SWH: launch meeting

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

## Introduction

:::info
**Useful Links:**
- 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)
- user manual (https://docs.softwareheritage.org/devel/swh-deposit/user-manual.html)
- deposit repository (https://forge.softwareheritage.org/source/swh-deposit/)
:::
## 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)

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

* Introductions
* development
* docker: can help development for the invenio team (https://forge.softwareheritage.org/source/swh-environment/browse/master/docker/docker-compose.yml$244-268)

* Staging area and credentials
* environment
webapp: https://webapp.staging.swh.network
deposit: https://deposit.staging.swh.network

* account setup as a usage requisite (in parenthesis, a proposal):
**user**: authenticated user and owner of the collection (e.g invenio)
**collection name**: deposit software collection (e.g
invenio).
**provider_url**: It's a fallback url used as origin url when
the user does not provide one alongside its deposit (e.g FIXME!
https://www.openinventionnetwork.com).
**domain**: the main domain the software is coming from (e.g FIXME!
www.openinventionnetwork.com)

* Deposit protocol updates:
* See the [current specification](https://docs.softwareheritage.org/devel/swh-deposit/spec-api.html)
* https://docs.softwareheritage.org/devel/swh-deposit/specs/protocol-reference.html
* now need additional data in Atom doc:
* URL for repository
* deposit examples in the archive: [IPOL](https://archive.softwareheritage.org/browse/search/?q=https%3A%2F%2Fdoi.org%2F10.5201%2F&with_visit=true&with_content=true), [HAL](https://archive.softwareheritage.org/browse/search/?q=https%3A%2F%2Fhal.archives-ouvertes.fr%2F&with_visit=true&with_content=true)
* CodeMeta taskforce
*
* Cottage Labs update
* https://github.com/inveniosoftware/invenio-swh/issues
* https://inveniordm.web.cern.ch/uploads/new
* https://github.com/inveniosoftware/invenio-rdm-records/blob/master/tests/records/full-record.json

* InvenioRDM deployment
* https://github.com/inveniosoftware/invenio-swh/pull/10/files