@anlambert thanks for the detailed explanation !

@vlorentz I think we can resolve this due to D1614?

At the moment the loader-tar is not adapted to receiving release objects.
@ardumont, Should we wait the refactoring of the loader-tar to successfully implement this feature for deposits?

• Fix typo

• Update specs: status image and other modifications

thanks !

Can you link to the list of metadata fields that resolves this ?

Here is the list of metadata we worked on for HAL specifications:
https://forge.softwareheritage.org/P183

• Update specs: ammend occurrences into branches

thanks @twitu for finding this location, if you see any other places dates are documented, feel free to comment here.

We have http://status.softwareheritage.org/ for this, but we are not using it.
I suggest we start using it and make it a habit of doing so, developing the needed integrations.

• Update specs with date mapping

@zack: Good idea to have only one glossary.

This is resolved with the following decision as I understand it:
specifications of a component should be in swh-<component>/docs/specs/.
specifications of a a transversal functionality should be in swh-docs/specs/.

Other comment, specs folder might be a better place to hold the file. we might have other specs in swh-docs:-)

Very nice output !

• Update specs and test scenarios in docs with D1617 comments

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

Draft is done and was sent to Inria GT for feedback.

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!