Here is the command:

For the code itself, we need to transition either way, as the interface changed. So changing the terminology in the code is free.

thanks ! for the feedback..

You correctly mention uniformity as a positive thing to have.
But term correctness is also a positive value, in my opinion.

In T2381#43854, @vlorentz wrote:

swh-loader-tar (used in the revision creation with a field called extrinsic with two properties provide and tool)

I don't think we should change this right now, but convert them when we have a proper storage for extrinsic revision metadata

swh-loader-tar (used in the revision creation with a field called extrinsic with two properties provide and tool)

Changing provider in title to authority for terminology consistency.

I suggest the following changes:

I think you'll probably need the user's input command as well to investigate
this. The deposit client can generate a uuid to use as external identifier (if none
is provided).

In T2369#43635, @moranegg wrote:

The choice for IPOL is between:
[1] https://www.ipol.im/pub/art/2018/236/ -> link to metadata record containing article, code and demo
[2] https://www.ipol.im/pub/art/2018/236/mlheIPOL.tgz -> direct link to tar.gz
[3] https://doi.org/10.5201/ipol.2018.236 -> which is a PID recognized in the academic ecosystem

One difference between HAL and IPOL is the item identified with the identifier:

• In HAL, the HAL-ID is given to the software artifact alone and if you want to deposit the main software article it will have a another identifier.
• In IPOL, the DOI identifies the metadata record of both the published article and the published code

Also the IPOL article and code are peer reviewed which results with a publication with an IPOL DOI.

In T2369#43616, @zack wrote:

If we go for the DOI, shouldn't we converge on it also for other similarly archives, for the sake of uniformity? HAL comes to mind, of course.
(To be clear: I'm not proposing to uniform past deposits, but to change this for the future.)

If we go for the DOI, shouldn't we converge on it also for other similarly archives, for the sake of uniformity? HAL comes to mind, of course.
(To be clear: I'm not proposing to uniform past deposits, but to change this for the future.)

The origin
For IPOL, we could use indifferently the DOI: https://doi.org/10.5201/ipol.2018.236 or the URL: https://www.ipol.im/pub/art/2018/236/, as it is trivial to convert the one into the other.

From the article web page:

published
    2018-12-07 
reference
    Jose-Luis Lisani, An Analysis and Implementation of the Shape Preserving Local Histogram Modification Algorithm, Image Processing On Line, 8 (2018), pp. 408–434. https://doi.org/10.5201/ipol.2018.236

Here is the link to the open issue on the CodeMeta repository:
https://github.com/codemeta/codemeta/issues/240

Our proposal to extend the CodeMeta vocabulary is based on the following nine roles identified in https://hal.archives-ouvertes.fr/hal-02135891v2/document :

they don't have to be single words. I'd say:

In T2329#43073, @moranegg wrote:

I've seen the new example, is this the right transformation?

I've seen the new example, is this the right transformation?

I just realized I didn't follow schema.org's roleName examples when writing this example. Could you copy-paste the new example from the pad, which uses "designer", "coder", and "documenter"?

If you agree with this proposal with @vlorentz's example, I can submit the issue tomorrow.

see mandatory fields for citation

Now it does

I do like the idea of adding a role to author, but the way schema.org is organized, is by adding properties with specific roles

I just discovered that there is a pending term maintaineron schema.org, thanks @vlorentz
for pointing this out.
https://schema.org/maintainer

Encoding the roles into existing property of CodeMeta or schema.org is a possibility.
The other, that I prefer, is to associate a "role" property to authors/contributors: indeed, an author/contributor may have multiple roles, just like multiple affiliations.

Taxon map:

Here is a sample request provided by the ScanR developers to get all the metadata entries that can be found about software in ScanR

I barely started writing it, so no

@vlorentz can we say that your new validator resolves this?

Thanks @olasd for the accurate and detailed summary !

Thanks a lot for this summary of a recurrent discussion we've had over the past few years now.

After discussion with @rdicosmo, GitHub is the best place for the community that wants to use the CodeMeta Generator.

example: https://archive.softwareheritage.org/swh:1:cnt:a6463d2ce390990c31c2f2fa8019606721f0ca13;origin=http://git.savannah.gnu.org/git/gnugo.git/

I think it qualifies, yes

@vlorentz I'm not sure it is an easy hack, could you review the task and decide?

publiccode.yml : https://docs.italia.it/italia/developers-italia/publiccodeyml-en/en/master/index.html

https://github.com/fnielsen/scholia