• Added release artifact in loading specification

From your comments, we can specify the following:
A deposit containing release metadata (softwareVersion, `releaseNoteè) is a release software artifact.
The metadata that arrives with a deposit MUST use CodeMeta vocabulary (this should be reviewed following T1345).

In https://gitlab.inria.fr/gt-sw-citation/artifact-archival-swh

After the discussion on extrinsic_metadata this morning with @zack, @vlorentz, @olasd and @douardda, here is a quick recap of the discussion,
feel free to add, comment and rewrite...

References to investigate:

• Zotero and the following issues:
  • https://github.com/citation-style-language/zotero-bits/issues/69
  • https://github.com/zotero/zotero/issues/1438
  • https://github.com/zotero/translators/pull/1578
  • https://github.com/zotero/translators/pull/1552
  • https://github.com/zotero/bib-web/issues/106
• https://code4ref.github.io/pure.html

I created a seperate branch moranegg on which I'm working and to which I'm pushing.
You can have a look, but I will ask for a merge only next week.
Seems I can't push to master, but it's better this way :-)

Sorry, I was in the midst of just adding quotes for readability and left it open.

I'm for the hashed origin only if we make it available as an identifier under our PID schema:

I have talked to Bruno about it for deposits on HAL.
It can't be implemented on HAL's form without an "high level" decision.
I think this will be the same for the actors roles.

I think that we should fetch all metadata found in its raw form (keep in xml if xml, etc.)
Apply translation techniques with CodeMeta to while identifying relevant metadata we want to keep in a translated format.
so no need to discriminate and choose what to fetch.

Not needed, Claude will deposit a new deposit called Scilab instead of renaming Scilab 1.1 to Scilab-> which will fix the issue

This is not possible, HAL doesn't send the metadata releaseNote even when existing!

All comments are open for discussion and IMHO are not subject to accepting this diff.
On the other hand, I didn't notice that the table is mixed up between name and type and should be changed before push.

I really like it!
Good job!

Also adding this example:
https://github.com/etalab/data-codes-sources-fr

Resolved locally by adding 'decorator' from swh-core to the requirements.

Looks great!
small language changes to clarify..

In T1683#31104, @zack wrote:

That was my point about "swh-docs as a fallback".

@zack Thanks for the answer.
It's not a blocker per se but I prefer to have a long term decision before moving the specs from different spaces, so for me it's a high priority.
It wasn't clear to me that it should be in the docs and that this is the long term decision.

I need this decision for different specs, for example:

• Legacy software deposit
• Sparse / Metadata deposit (now in docs)
• Metadata workflow- How do we dill with software metadata (T1344)

Resolved with last deployment on HAL

Thank you both for dealing with this bug quickly!

After pairing with Ardumont, the updates are validated!

Validating this but we have some changes to do on the added test to follow a more restrictive grammar.

Blocked because I thought I can call swh-deposit like old times:-)
Now it is good for me (saw the slug changes live).

I'm going to try and run it, but am a bit blocked with swh-deposit command................
Maybe @douardda could validate he can do a deposit?

Seems great!
tox passes locally.
I would add/change the date formats in tests (because we can recieve dates in different styles)
and/or test only the _parse_date and compute_date functions.
Here some examples: