codemeta: Codemeta content negotiation is not correct

BTW, in RO-Crate call today we agreed to add the additional codemeta terms to our context, so we’ll use the newer w3id namespace for now in anticipation of this issue (as I would be reluctant to add a github.io namespace)

Considering #321 I would propose https://w3id.org/codemeta# as namespace in agreement with @dgarijo. As this is a v3.0 (major change in https://semver.org/) and only affect a couple of additional terms like softwareSuggestions (not the majority which remain in http://schema.org) v3 would be the right time to do it.

Vocabulary namespace should not be versioned, so that their semantic meaning can stay the same over time, although the exact interpretation/definition may change slightly as the vocabulary evolves. In this case we only have a textual representation of the vocabulary anyway (no stringent OWL file etc) so it shouldn’t matter.

It may be tricky to add <tr id="contIntegration"> anchors without redoing the knitr magic of terms.Rmd.

Shouldn’t be an issue, we rewrote other parts of the .Rmd-based website generation to Python and Hugo templates in recent months.

Thanks. I prefer hash + changelog + obsolete terms, but if we follow schema.org style, slash is preferred.

The best practices you linked is the document I always recommend.

El vie., 6 oct. 2023 12:46 p. m., Stian Soiland-Reyes < @.***> escribió:

I’ll try to clarify the proposal:

• https://w3id.org/codemeta#contIntegration etc. redirect to https://codemeta.github.io/terms/#contIntegration if asking for text/html
• https://w3id.org/codemeta#contIntegration etc. redirect to https://codemeta.github.io/terms/3.0/codemeta.jsonld if asking for application/ld+json
  • (currently versioned https://raw.githubusercontent.com/codemeta/codemeta/3.0/codemeta.jsonld which do not define the terms beyond mapping them into the context)
  • The JSON-LD context file to be extended to also include basic rdfs declarations of the new terms.
• https://w3id.org/codemeta/3.0 redirect to https://codemeta.github.io/terms/3.0/ if asking for text/html
  • (currently unversioned https://codemeta.github.io/terms/) – this would have to become a static copy of terms.html on release)
• https://w3id.org/codemeta/3.0 redirect to https://codemeta.github.io/terms/3.0/codemeta.jsonld if asking for application/ld+json
  • (currently versioned https://raw.githubusercontent.com/codemeta/codemeta/3.0/codemeta.jsonld which has wrong `Content-Type: text/plain)

One problem with # is what to do about terms that are now (or in the future) in schema.org – like maintainer – if they are removed from the page then we can’t redirect to an earlier version as the term is after the #anchor. An easy solution is to have a section for “Obsolete terms” which would also be beneficial for users. The more detailed version is to use https://w3id.org/codemeta/maintainer etc. “slash-style” namespaces which generically could redirect to the HTML section but could be overridden for each deprecated term.

These considerations are explained in https://www.w3.org/TR/swbp-vocab-pub/ – perhaps @dgarijo https://github.com/dgarijo have some more modern sources.

— Reply to this email directly, view it on GitHub https://github.com/codemeta/codemeta/issues/216#issuecomment-1750395484, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALTIGUI6Q3JL5Q4HAAN4V3X57OP7AVCNFSM4H4JMFSKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZVGAZTSNJUHA2A . You are receiving this because you were mentioned.Message ID: @.***>