[codemeta-pmc] The CodeMeta vocabulary identifier Was: v2.1 of CodeMeta has been released 🎉🚀

[Morane GRUENPETER]

Hello again,

I'm using this thread that was initially launched with the v2.1 release to discuss and vote the v3.0 identifier.

As Matt wrote in the exchange below: 

Ideally we should: 

1) when requesting JSON-LD, get the context file directly; 

2) when requesting HTML, get the documentation page for the terms, and 

3) have individual term identifiers resolve to anchored term definitions when HTML is requested.

The options suggested and provided in the email exchange:

A. https://w3id.org/codemeta (Thanks Daniel!):

From the conversation:

- curl -sH "Accept:application/ld+json" -L https://w3id.org/codemeta/ will get you the JSON. 

- If you resolve https://w3id.org/codemeta/ in your browser, it will take you to https://codemeta.github.io/terms/

- Version ids are supported: 

https://w3id.org/codemeta/{version}. 

- For example https://w3id.org/codemeta/1.0. I redirected the HTML of the versions to https://codemeta.github.io/terms/ because as far as I know there is no versions on the HTML.

- It's open: https://github.com/perma-id/w3id.org/tree/master/codemeta

B. https://purl.archive.org/purl/codemeta/2.0 (Thanks Carl!)

- widely used in other vocabularies

-  the ids are not open, i.e., you can't have several maintainers on an id

- limited content negociation capabilities in purl.org. For example, it does not support content negotiation on content type (JSON-LD vs HTML)

C. new DOI

- I won't list advantages and drawbacks because it seems clear that this is not what we need for using the vocabulary.

With this discussion I will also approach a few experts in the semantic artifacts domain to see what are the requirement of the vocabulary identifier.

If you feel that this discussion should be open to the full CodeMeta community, please let me know by answering this email with `open discussion to the community` before September 4th.

After this date, I'll open a vote (here or on the discussion board) on the different identifiers options that we are considering.

Kind regards,

--
Morane Ottilia GRUENPETER
Software engineer and project manager
Software Heritage http://www.softwareheritage.org
@INRIA Paris
personal website: http://moranegg.github.io/

On Thu, Apr 27, 2023 at 7:14 PM Daniel Garijo <dgar...@gmail.com> wrote:

Thanks Carl!

I will leave it up to the PMC to decide what to do with the old purl, but at least we have everything in a consistent manner now :)

Best,

Daniel

El jue, 27 abr 2023 a las 18:55, Carl Boettiger (<cboe...@berkeley.edu>) escribió:

Thanks Daniel!  Yup this is a good illustration of the advantages of the W3id system.  I've pointed https://purl.org/codemeta at your w3id now.  I didn't change the https://purl.org/codemeta/2.0 id yet.  I'm not sure anyone uses these purl URLs anyway (except maybe me in some long-ago code).  

I'd also be happy to transfer these purl ids to someone, though it's not obvious if/how to do so in the interface, or delete them if that would be best. I appreciate your guidance on this stuff!

---
http://carlboettiger.info

On Thu, Apr 27, 2023 at 9:23 AM Daniel Garijo <dgar...@gmail.com> wrote:

Hi Carl,

that's a relief! If you redirect the purl to the w3id I created, then content negotiation will work on both and every time we change one, the other one will be consistent.

But you'd have to create a different purl per version I am afraid.

Best,

Daniel

El jue, 27 abr 2023 a las 18:17, Carl Boettiger (<cboe...@berkeley.edu>) escribió:

Hi Daniel,

Thanks for the explanation, sounds great!  

yup, I believe I 'own' the https://purl.archive.org/purl/codemeta/2.0

- Carl

---
http://carlboettiger.info

On Thu, Apr 27, 2023 at 9:13 AM Daniel Garijo <dgar...@gmail.com> wrote:

Hello,

purl is another option. I used to use it quite a bit before purl was dropped from oclc and then rescued by the Internet archive.

But the content negotiation capabilities are more limited in purl.org. For example, it does not support content negotiation on content type (JSON-LD vs HTML) like I have done in w3id.

Plus, the ids are not open, i.e., you can't have several maintainers on an id. In fact, I have done a search for codemeta and I found https://purl.archive.org/purl/codemeta/2.0 (only works for JSON-LD)

Does anyone own it already? Who knows.

Best,

Daniel

El jue, 27 abr 2023 a las 18:02, Carl Boettiger (<cboe...@berkeley.edu>) escribió:

Thanks, this change sounds good to me.  I think it's okay that this isn't a DOI; even when it was working, the content negotiation mechanism on datacite wasn't particularly robust, and I think our use of a DOI for the purpose might have been a bit conceptually confusing to many researchers.  

https://w3id.org looks cool and a good choice, that one is new to me!  Not to propose a change, but curious what folks think about https://purl.org  iirc it was (is?) pretty widely used in other vocabularies?

- Carl

---
http://carlboettiger.info

On Thu, Apr 27, 2023 at 8:01 AM Daniel Garijo <dgar...@gmail.com> wrote:

Hello,

all right, I have created: https://w3id.org/codemeta

curl -sH "Accept:application/ld+json" -L https://w3id.org/codemeta/ will get you the JSON. If you resolve https://w3id.org/codemeta/ in your browser, it will take you to https://codemeta.github.io/terms/

Version ids are supported: 

https://w3id.org/codemeta/{version}. For example https://w3id.org/codemeta/1.0. I redirected the HTML of the versions to https://codemeta.github.io/terms/ because as far as I know there is no versions on the HTML.

This is not my identifier. It's open: https://github.com/perma-id/w3id.org/tree/master/codemeta

I listed several of us in the PMC as maintainers of this identifier. Changes done to the .htaccess file are automatically made live.

For example, I did not add support for JSON, only JSON-LD. We can easily add that. By opening a pull request.

When we get v3, we can do another pull request.

This is an initiative that span several years ago from a community group in the W3C. It now has hundreds of identifiers, and it's backed by several companies. So it's unlikely to go.

I hope this helps (at least it solves the problem, or part of it).

The only disadvantage that I see is that it's not a DOI. But it gives the Codemeta PMC full access to the redirection.

Best,

Daniel

El mié, 26 abr 2023 a las 19:22, Matt Jones (<jo...@nceas.ucsb.edu>) escribió:

When we originally minted the DOI for the schema, we did so using DataCite's then-current support for content negotiation, and the context resolved fine. After we issued that, their service changed and the redirect stopped working, much to our disappointment. I fully support using a new mechanism to publish the namespace and its associated identifier so that redirection works seamlessly. Ideally we should: 1) when requesting JSON-LD, get the context file directly; 2) when requesting HTML, get the documentation page for the terms, and 3) have individual term identifiers resolve to anchored term definitions when HTML is requested.

Matt

Matthew B. Jones

ORCID: 0000-0003-0077-4738

Director of Informatics R&D, National Center for Ecological Analysis and Synthesis

PI, NSF Arctic Data Center

Director, DataONE program

University of California Santa Barbara

On Wed, Apr 26, 2023 at 2:02 AM Daniel Garijo <dgar...@gmail.com> wrote:

Thank you Moranne, congrats on the milestone!

Now that we are preparing for 3.0 and a new identifier needs to be minted, would it be possible to at least generate content negotiation on it?

I can easily generate a w3id with content negotiation which at least solves part of the problem (something like https://w3id.org/codemeta/{VERSION})

This does not solve the main issue of using https://codemeta.github.io/terms/ as a namespace, but it solves part of the problem (i.e., getting redirected to the documentation

vs the JSON-LD file or any other serialization)

Citation proposal looks good to me.

Thanks,

Daniel

El lun, 24 abr 2023 a las 16:57, Morane GRUENPETER (<mora...@gmail.com>) escribió:

Dear PMC,

As promised, Valentin and myself have reviewed and merged all pending PRs for v2.1, which as crosswalk table PR, with 0 modifications of the vocabulary.

Here is the direct link to v2.1 🎉🚀:

https://github.com/codemeta/codemeta/releases/tag/2.1

👉 please schedule some time before May 25th to review the v3.0 PR candidates (comment / accept / request modifications).

https://github.com/codemeta/codemeta/milestone/9

🗓 May 25th we will review and merge PRs for the V3.0 

* the procedure will be, if there is no comments we will decide if we merge or postpone to v4.0

🚩Also we have decided to have a v3.1 during the summer to add crosswalks that were blocked at v2.1 and other potential candidates.

For the v3.0 we need to update the authors:

- Current citation: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

- V3.0 citation proposal:
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, Morane Gruenpeter, Valentin Lorentz, Thomas Morrell, Daniel Garijo, Bryce Mecum . 2023. CodeMeta: an exchange schema for software metadata. Version 3.0.

In yellow the new PMC members who weren't authors of v2.0.

In turquoise a contributor who acted directly on the jsonld file  who weren't authors of v2.0.

👉 Let me know if you identified other individuals that should be credited in the v3.0 on the citation. All contributions to the v3.0 will be listed in this file under a new v3.0 section:

https://github.com/codemeta/codemeta/blob/master/CONTRIBUTORS.MD

🗓 Please do so before May 25th

I'm so happy to see the CodeMeta community moving forward.

Thank you again for your engagement!

Note: I am off on vacation until May 5th and will be answering with some delay upon my return.

Kind regards,

--
Morane Ottilia GRUENPETER
Software engineer and project manager
Software Heritage http://www.softwareheritage.org
@INRIA Paris
personal website: http://moranegg.github.io/

--
You received this message because you are subscribed to the Google Groups "codemeta-pmc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codemeta-pmc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/codemeta-pmc/CAL8iZAxDHRpk_6UXOBodZ%2B9LzYZLHq3vCy-eJFcHE_hi12Uxkw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "codemeta-pmc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codemeta-pmc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/codemeta-pmc/CAExK0DexWMC05rWbOo9n1VPWgf-GPKr0kbCRda%2B68QjEiEZtaA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "codemeta-pmc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codemeta-pmc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/codemeta-pmc/CAExK0DfXb_UaiNC_tr6Qrc2uVK8%3DCULm9y6oPT5u5SgLOutCTQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Matt Jones]

Thanks, Morane, great summary.

Based on the summary, it seems to me like the advantages of w3id come through strongly, and there's little to argue in favor of the other alternatives. So, we could probably just move forward with that, unless there are other candidates we haven't considered. If we want to solicit other potential ideas, we could just summarize our current consensus in an issue and ask for feedback from the broader community. Or, if we're comfortable with the existing proposed paths and settling on w3id, we could decide internally. I guess I would probably prefer the synopsis in an issue and public call for comments before we vote. It is an important infrastructure decision that will affect how CodeMeta is used.

Matt

Matthew B. Jones

ORCID: 0000-0003-0077-4738

Director of Informatics R&D, National Center for Ecological Analysis and Synthesis

PI, NSF Arctic Data Center

Director, DataONE program

University of California Santa Barbara

To view this discussion on the web visit https://groups.google.com/d/msgid/codemeta-pmc/CAL8iZAzj8OYPWdB%3D-RyR9L6PJeYbgBn0FE6nTyz%2BnMGLdprSXA%40mail.gmail.com.

[Daniel Garijo]

Hello,

I would move forward with the w3id, as I would prefer the community discussions to focus on the new terms. But I don't oppose to having the discussion public.

By the way, for v3 (and next versions), I would have a "frozen" HTML version as well, not only the JSON-LD file.

This would only require:

• Having a separate html with the definitions for a given version.
• State which version is the one shown in the latest HTML.

That way we can navigate through the different versions also in the HTML. The structure may be /terms/{version}.html as shown above.

I can handle the redirections for the w3id too.

Best,

Daniel

To view this discussion on the web visit https://groups.google.com/d/msgid/codemeta-pmc/CAFSW8xnmKWEN_zq%3D0QEsOMwW8zfMqBq5oQqWJgROOrxG98FubA%40mail.gmail.com.

[Morane GRUENPETER]

Dear all,

I have just added a new issue calling for feedback until September 6th:

https://github.com/codemeta/codemeta/issues/321

We will move forward with w3id if no new information is submitted on the issue.

Have a good weekend!

Cheers,

--
Morane