Next release?

[cboettig]

Are we ready for a new release of the the codemeta.jsonld context file? Do we do a major or a minor release? (migrated from #235 (comment))

[cboettig]

• Guess we need a changelog summary of the changes since https://doi.org/10.5063/schema/codemeta-2.0.

To me, this v2.1 or v3.0 might pivot on if we re-define the codemeta context as inclusive of all schema.org vocabulary (e.g. codemeta is an extension of schema.org, as it would be if our terms are ever rolled in). I don't think we've ever formally decided on that (#161). Have we made any other edits that would seem like breaking changes?

Relatedly, our DOI corresponds directly to the codemeta.jsonld file alone, we don't have a 'published' release of the rest of the material in this repo (specifically the crosswalks). (Related to #186). Thoughts on that?

[mbjones]

Yeah, I was examining our CodeMeta files in the Google structured data testing tool, and it didn't recognize it as schema.org because wrap the SO terms. So I think we should reconsider that, although I don't seem to be able to replicate it atm.

We also need to ensure that our namespace ends with a /, as it currently means our terms append onto the namespace without a separator.

I do like an identifier that resolves to exactly the bytes of our context file, as it makes it self-referential. That said, if you'd prefer, we can use a namespace that uses a regular https address and redirect from there, which is what we do with our other schemas. It certainly wasn't easy to get the DOI redirect to work right with the DOI redirection service.

[moranegg]

open issues that might be suited for V3 evolution

• add review or reviewedBy : Including metadata on reviews/reviewers #177
• API entry point: Entry points (or API endpoints) extension for codemeta? #183
• mailing list or contactPoint :Should CodeMeta include the concept of "mailing list" / "discussion forum" in next release #166
• link fromSoftwareApplication to SSC with hasSourceCode: linking between SoftwareSourceCode and SoftwareApplication? #198
• input/output formats: [proposal] Specifying input/output formats and (natural) languages #188
• add roles to authors: Proposal for author roles in CodeMeta v3 #240
• add roles to contributors : Proposal for author roles in CodeMeta v3 #240
• change contIntegration to continuousIntegration: Link to continuous integration service #243

[moranegg]

When we are ready to move to the CodeMeta v3 or v2.1 we need to add a crosswalk between v2 -> v3, like the already existing crosswalk from v1 -> v2

[mbjones]

@cboettig @moranegg I think at this point many of the changes proposed warrant a v3.0 designation, including the most recent proposal to change the https namespace for schema.org in PR #248. So, I created a new v3.0 milestone for us to use to identify issues and PRs that will be part of the next release. Please review and nominate issues to be included, keeping in mind that issues for which no PR exists might considerably delay release (but still might be warranted). The schema.org task force from Force11 has proposed a number of changes, some of which have been implemented or discussed, and it seems like we should harmonize these and come to agreement on a new release. I will also note that the Science on Schema.org (SOSO) release milestone v.1.2 is coming up, and that covers a number of issues that will apply to CodeMeta as well, particularly their proposal on provenance relationships between software and data objects for describing workflows.

So, everyone please nominate issues to include in the release by adding them to the milestone, and let's discuss what the release timing for that might look like. Thanks.

[moranegg]

Hi @mbjones I'm very excited about the v3.0.
I will review the open issues and try to propose PRs during this month (October 2020).

Very interesting links on SOSO and the relations between research outputs, thanks.

Concerning the release timing, I believe that a release before the end of 2020 is reasonable.
What did you have in mind?

[chrishalbert]

Hi! I know this has gone stale a little, but I wanted to know if v3 is simply awaiting pull requests? I have an interest in this particular request: #166, but would be willing to contribute elsewhere too if that's all that is needed.

Thank you for your hardwork!

[mbjones]

Hi @chrishalbert -- yes, it's just awaiting community work on the release. There are a lot of outstanding pull requests from the CodeMeta task force and others, which need to be reviewed and merged. I haven't had time to maintain this myself, but my impression was that @moranegg and others from the task force were going to handle that. In looking now, I see that somehow they don't have write access to the repository, so that is likely the problem. Let's discuss admin additions with @moranegg and the CodeMeta task force. Maybe @tmorrell has some thoughts to move forward as well.

[chrishalbert]

Thanks for the response @mbjones. I may free up at the end of this week. If so, I can spend some time on code reviews and/or pull requests.

[tmorrell]

I'd be happy to help move a release forward. What's the process for moving through the backlog of PRs?

[mbjones]

@tmorrell In the past, @cboettig and I have done due diligence to ensure there is community support for a change, and that it doesn't cause compatibility issues, and that the crosswalks and transformations all continue to work with the change via tests. I think some of that review can now happen through community reviews of PRs, and then a final check and merge by a maintainer. We've taken a fairly conservative stance on breaking changes, but if the group decides breaking changes are needed, I think it should be confined to a single release, and then build incrementally from there. I can make you a maintainer on the repo if @cboettig and others support that. It would be good to define who can serve as maintainer from the CodeMeta task force and elsewhere -- you and @moranegg come to mind as having engaged in the CodeMeta task force a lot, but open to other suggestions.

[mbjones]

Also, once all proposed changes are in develop, then a final release tag and merge to the main branch would need to be done, along with issuing a new DOI for the new versioned release -- I've been issuing those DOIs from our KNB Data Repository DOI prefix.

One other note -- there is some tooling out there that works with the current release -- e.g., codemetar and codemeta-generator. I think we should try to keep those functional, and ensure they continue to work with new releases of the schema.

[kequach]

• Guess we need a changelog summary of the changes since https://doi.org/10.5063/schema/codemeta-2.0.

To me, this v2.1 or v3.0 might pivot on if we re-define the codemeta context as inclusive of all schema.org vocabulary (e.g. codemeta is an extension of schema.org, as it would be if our terms are ever rolled in). I don't think we've ever formally decided on that (#161). Have we made any other edits that would seem like breaking changes?

Relatedly, our DOI corresponds directly to the codemeta.jsonld file alone, we don't have a 'published' release of the rest of the material in this repo (specifically the crosswalks). (Related to #186). Thoughts on that?

Hello, I wanted to ask about issue #186 (responding here since the issue hasn't been active for a while). I am writing my master thesis on the topic of FAIR research software and am looking to properly cite the CodeMeta project. Considering that you already had this discussion I'd like to push this issue.

[proycon]

One other note -- there is some tooling out there that works with the current release -- e.g., codemetar and codemeta-generator. I think we should try to keep those functional, and ensure they continue to work with new releases of the schema.

I agree and think that this a very important point, having good software that complies to the latest codemeta standard can make or break it. I'll do the same for the tools I developed (codemetapy, and by extension the new codemeta-harvester and codemeta-server).

[moranegg]

We will be closing this task with the V3.0 release.
If you find that some subjects weren't addressed in the upcoming v3.0, please open new tickets.

Cheers and good weekend!

[stain]

Will the v3.0 be fully released or is it a release candidate? Several things seem still to be undecided

3.0 is not listed in

• https://codemeta.github.io/jsonld/
• https://github.com/codemeta/codemeta/#codemeta-schema
• https://github.com/codemeta/codemeta/blob/master/codemeta.json Update codemeta.json for v3 release #299

Several issues "tagged for 3.0" were not included:

• maintainer switch to schema.org Switch maintainer to schema.org version #250 Write proposal for the schema.org adoption of the CodeMeta terms #232 (comment)
• funding switch to schema.org Switch funding to schema.org  #274
• The namespace of https://raw.githubusercontent.com/codemeta/codemeta/3.0/codemeta.jsonld defines terms such as https://codemeta.github.io/terms/readme which is 404 -- these should not use github.io and should resolve as PIDs. Codemeta content negotiation is not correct #216
• The PID for is not shown on https://codemeta.github.io/terms/ and neither is the version Choose identifier for the CodeMeta schema #321

3.0 is not yet used by https://codemeta.github.io/codemeta-generator/ -- perhaps waiting for that PID issue.

I'm happy to help but at the moment I am quite confused because "3.0" seems to be in a beta or release candidate stage -- perhaps as 3.0 is not known outside GitHub releases, this gives us a change to fix this and call it 3.1?

[progval]

Will the v3.0 be fully released or is it a release candidate? Several things seem still to be undecided

3.0 is not listed in

• https://codemeta.github.io/jsonld/

• https://github.com/codemeta/codemeta/#codemeta-schema

• https://github.com/codemeta/codemeta/blob/master/codemeta.json Update codemeta.json for v3 release #299

This is still a work in progress

Several issues "tagged for 3.0" were not included:

• maintainer switch to schema.org Switch maintainer to schema.org version #250 Write proposal for the schema.org adoption of the CodeMeta terms #232 (comment)

It's scheduled for 4.0.

• funding switch to schema.org Switch funding to schema.org #274

Oversight, sorry.

• The namespace of https://raw.githubusercontent.com/codemeta/codemeta/3.0/codemeta.jsonld defines terms such as https://codemeta.github.io/terms/readme which is 404 -- these should not use github.io and should resolve as PIDs. Codemeta content negotiation is not correct #216

The 404 is fine, there is no requirement that IRIs resolve to anything.

Using the github.io domain is unfortunate, but that's what we are stuck with.

• The PID for is not shown on https://codemeta.github.io/terms/ and neither is the version Choose identifier for the CodeMeta schema #321

Could you open a PR to https://github.com/codemeta/codemeta.github.io/ ?

3.0 is not yet used by https://codemeta.github.io/codemeta-generator/ -- perhaps waiting for that PID issue.

I'm happy to help but at the moment I am quite confused because "3.0" seems to be in a beta or release candidate stage -- perhaps as 3.0 is not known outside GitHub releases, this gives us a change to fix this and call it 3.1?

We are still working on announcing it and updating the website

[moranegg]

Emphasizing @progval that it is still work in progress.

Since the v3.0 is not yet in use (because it's not identifiable yet).
It is in Beta/ release candidate because it can't be used in production.
We have opened the ID discussion on this issue #321 and it seems that we haven't resolved it yet...

I'm inclined to resolve some of the items in @stain 's comment, if possible in a reasonable time.

PRs are always welcome and we are all struggling with time ;-)

My "personal" deadline for this is mid November, because it is needed for the a beta release of other components that are using metadata.

[moranegg]

I'm actually going to close this long thread.
If you found missing items in issues or in the next v4.0, please open new issues.