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:

@zack this was open last year but we never got to that.
Is this still our goal?

I think we can close this one :-)

I started reviewing but the question is more complex than I first stated
I asked HAL to fix dateCreated to their real metadata 'date de création/écriture'
and to add datePublished as the deposit date
While dateCreated isn't mandatory on HAL, datePublished is implicitly mandatory
And the date of arrival to SWH isn't the same of datePublished, because of the moderation process on HAL side
It can differ by hours, days or even weeks

And add datePublished for the deposit date

Here is the approved property on Wikidata:
https://www.wikidata.org/wiki/Property:P6138

This will also be useful for:

• ASCL
• swMath
• OpenAire

Where would you put this type of specs?

I think that @douardda's comments should be resolved in a specs document and not in the current docs.
So I'm opening a task about that, referring to the discussion here [T1344]

I'm not sure why the build is failing.
Can I relaunch a build as a reviewer, or only by changing the diff will the build be relaunched?

Here is the property proposal under discussion: https://www.wikidata.org/wiki/Wikidata:Property_proposal/SWH_Release_ID

Questions and Answers with the WikiDigi WG (from Toto256):

1. Even thought we identified the release ID to be the most appropriate ID to use in Wikidata, should the property specify it is a release instead of being a generic SWH ID?

As we discussed, it's easier to have a limited scope for a property : it allows for defining constraints, building bots and explaining the purpose.
This doesn't mean we can later add other properties for others ids.

Accepting because I accepted D620

Accepting because I accepted D620

There is no test a case of a revision with multiple 'metadata files' which is an intriguing case - this should be tested before accepting this diff.

Add README or CITATION to data directory with the following:
Matthew B. Jones, Carl Boettiger, Abby Cabunoc Mayes, Arfon Smith, Peter Slaughter, Kyle Niemeyer, Yolanda Gil, Martin Fenner, Krzysztof Nowak, Mark Hahnel, Luke Coy, Alice Allen, Mercè Crosas, Ashley Sands, Neil Chue Hong, Patricia Cruse, Daniel S. Katz, Carole Goble. 2017. CodeMeta: an exchange schema for software metadata. Version 2.0. KNB Data Repository. doi:10.5063/schema/codemeta-2.0
swh:1:dir:39c509fd2002f9e531fb4b3a321ceb5e6994e54a;origin=https://github.com/codemeta/codemeta

When using the save code now feature with https://github.com/codemeta/codemeta.git the origin created was exactly as requested.
Now there are 2 different origins:

• https://github.com/codemeta/codemeta.git
• https://github.com/codemeta/codemeta

Noted Invalid because D591 by @vlorentz uses the most up-to-date mappings with the CodeMeta crosswalk table.

I'm accepting this diff- it looks great.
Nevertheless, I think there should be at least one test for CodeMeta (even without the json-ld resolution)
and I added a comment about the tool version.

I think that an alert would work in this case, just need to see when it appears.
This is also to prevent re-submission by mistake.

This test doesn"t pass but it's normal.
We should see how do we want to address this.
The CodeMeta file is a json-ld file and contains keys that are not detailed in the codemeta.csv table.

I need some more time to play with this diff before accepting it

Now that D558 and D557 have landed this error is no longer happening