Codemeta content negotiation is not correct #216
Comments
|
@dgarijo you make a good point. We published the 2.0 version using the doi https://doi.org/10.5063/schema/codemeta-2.0, and our intention was that would be the context for the terms. So this resolves properly: curl -sH "accept:application/json+ld" -L https://doi.org/10.5063/schema/codemeta-2.0 We meant to switch the namespace to that, but it seems we didn't and we are now going to have the github.io URL as the context URI, which could cause issues in the long run for us. So, @cboettig, what do you think of a new release using the doi as the context? Alternatively, we live with it at the current github.io URL, and accept that we can't redirect it to the schema, and that we may not be able to maintain it over the long term depending on what happens with github.io. Other options? |
|
Some suggestions based on my experience. Maybe they will help: I think that a raw.githubusercontent URL may not be the best for production. It would be better to give it a more stable URI, even if you use a github page. Or even better, you tag a release and have the json representation there, so you have a permanent link such as https://github.com/codemeta/codemeta/archive/2.0.jsonld Do you have control on the content negotiation for https://doi.org/10.5063/schema/codemeta-2.0? If so, in the htaccess you may add a 303 redirect to the github.io html documentation or the jsonld file depending on the header request. Right now doing: curl -sH "accept:text/html" -L https://doi.org/10.5063/schema/codemeta-2.0 also returns the json ld file, instead of https://codemeta.github.io/terms/ If you decide to move towards the DOI as a namespace, then it would be nice to design a vocabulary URI independent from the version. Something like https://doi.org/10.5063/schema/codemeta#. Having a github namespace usually doesn't work, because you don't have control on the redirections. |
|
Thanks @dgarijo Personally I much prefer to keep the version in the namespace, as it makes it much clearer which version of a vocabulary people are using in particular instance documents. But I agree we have some namespace cleanup to do here. This partly depends on the recent changes at DataCite on how much control we have over content negotiation for the json-ld document -- I need to look into that further. |
|
All right, please keep me posted :) |
|
That's a very good point about the property rename. For other vocabularies that we manage like ECSO, the new versions only contain new terms -- once minted, old term URIs never change, whereas new terms would have the new namespace version. I'm not so sure that applies here, and all may be moot if our push to get all of these terms into schema.org directly is successful. |
|
Now that a v3 is on the discussion, maybe it's a good time to bring back this issue @mbjones ? |
|
DataCite removed native custom content negotiation for DOIs, so there is not an easy way to have both the html and json ld on the same DOI. I'm not sure that we need both formats in the same url. If we do, content negotiation would have to happen on a separate service, which brings up sustainability issues. |
|
Having content negotiation is desirable, but not a requirement. You are right that external services bring sustainability issues, although there are permanent url services (purl.org, w3id.org) that may help. Of course, this would mean changing the github URI to something like purl.org/codemeta or w3id.org/codemeta, which is a huge change. I think the main issue right now is that if you translate the JSON-LD to other serializations, the context is lost and may not resolve. For example, take the following codemeta file https://tinyurl.com/yevqrs2s and translate it to n-quads in the application. You will see that schema.org terms will resolve, but things like |
|
This issue will be open for discussion until March 15th and we will start a vote from March 15th until March 25th 2023 This is an urgent matter which should be a candidate for the v3.0. An option would be to use a SWHID for the json-ld file: Some more information about SWHIDs can be find here: |
|
Thanks, @moranegg. I think this would solve the versioning aspect, but not the main identity problem with the vocabulary. Plus, the ids are too long to use in a vocabulary directly. Let me elaborate below. Codemeta namespace URI is: When I resolve this, I don't get a machine-readable representation of the vocabulary. I get HTML. So I cannot use it in my apps. Since a lot of time has passed, I would like to propose the following for version 3: Create a w3id for codemeta. Something like https://w3id.org/codemeta, which always resolves to the latest version of the vocabulary. This can be a DOI, a SWHID, or other. The HTML version would not change, as https://w3id.org/codemeta would redirect to This approach supports direct versioning, as we can declare version IRIs like Note: This would be a MAJOR change, as it would mean moving the ID of codemeta from |
|
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 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. |
|
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 |
Codemeta Namespace boldly assumed to be w3id-based rather than github.io see codemeta/codemeta#216 Added Biochemas namespace comment, see BioSchemas/specifications#653
|
I'm inclined to drop the What would be the best approach here in term of replacement? This discussion will be open until October 15th. |
|
I'll try to clarify the proposal:
One problem with These considerations are explained in https://www.w3.org/TR/swbp-vocab-pub/ -- perhaps @dgarijo have some more modern sources. |
|
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
<#216 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALTIGUI6Q3JL5Q4HAAN4V3X57OP7AVCNFSM4H4JMFSKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZVGAZTSNJUHA2A>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
It may be tricky to add https://github.com/yihui/knitr/blob/v1.44/R/table.R#L370 do not have any way to add anchor attributes (beyond Perhaps these terms should be loaded from elsewhere than the crossmap? Also I wonder why they have the type |
Shouldn't be an issue, we rewrote other parts of the |
What does? |
From crosswalk.csv as read by terms.Rmd: |
Can try to help on this, I have done a couple of Hugo templates for my own website. In this way the term listing could also include sufficient RDFa description of the new terms. |
That looks like a mistake
Thanks! |
|
Hello, Would it be possible to change this id the context file too so we can resolve terms live |
|
@dgarijo I don't see any issues with making the full term URIs resolve without a breaking change -- we just need |
|
switching from |
progval
added
enhancement
discussion
|
Exactly, the problem is what @progval states. We would need to open a community consultation and take a decision on this. @mbjones we already control |
I don't understand this. What should property URIs resolve to? schema.org's property URIs also don't resolve to anything: in the first message of this thread, you mentioned you wanted I am also not convinced it is that useful to make a namespace redirect to the context (which is not schema, btw) because it has no meaning in and of itself. Wikidata's namespace also resolves only to an HTML page (and it's a 404): |
|
Schema.org supports content negotiation on a special way, and not for terms, that's true (schemaorg/schemaorg#3500). I would like the vocabulary URI (and the respective terms) to resolve to the specification following w3c best practices. We only have the context right now, so that would ok. Ideally we should return the new codemeta properties in a graph stating the At the moment |
|
I see. Any chance we could somehow serve the machine-readable data within the HTML, ie. as microdata? |
|
Ah that's interesting. We could embed it in a JSON-LD snippet in the html doc, I had not considered that option. Still, this would not support content negotiation and you would need a specific extractor to get the snippet... I'd still prefer going for a URI rename because w3ids allow for more control, but I would be keen to see what the rest of the community thinks about it. The solution above would be a compromise (unless github decides that github.io needs a URI change in the future and we need the rename anyways) |
|
I see where my confusion came from -- I wrongly assumed we were already using the w3id in the context file. I thought that was the whole point of the switch away from a DOI, to provide long term continuity and to enable redirects to work properly. So, currently, where the context file has: "@context": {
"type": "@type",
"id": "@id",
"schema":"http://schema.org/",
"codemeta": "https://codemeta.github.io/terms/",
...If we were to change this to: "@context": {
"type": "@type",
"id": "@id",
"schema":"http://schema.org/",
"codemeta": "https://w3id.org/codemeta/",
...then I think we would be well served. That URI space could 1) provide redirects to the context file for requests for JSON-LD, 2) provide redirects to human readable docs for the context and terms overall, and 3) provide redirects to HTML for individual terms at term anchors in the html. Honestly, I thought we had done this before, which is why I thought 3.0 was a breaking change. I think this is still an important change, even if it is breaking again. Once we make this change, the website at codemeta.gitub.io could get moved/renamed with impunity because the redirects can be updated. So I support that the new official term URIs for codemeta would have the form that @dgarijo proposed -- https://w3id.org/codemeta/contIntegration. |
indeed, we are using w3id as the URL for the context file, but not as the URI namespace inside the context file. It's the properties that are still on the codemeta.github.io domain.
It was a breaking change because we renamed some properties within the namespace, though we kept the same namespace. (see the change log) |
|
Good to know. So, are you supportive of changing the properties to use the form |
|
I don't know, there is merit to both. (and if we do, probably |
|
The w3id config is an apache rewrite config, so it is very flexible and could handle those regexes, but I agree it might make sense to keep the parallel URL structure in the new namespace. I like that |
|
I am happy to mimic the current structure and use the This discussion is a little buried in the issue stack. If you think we should prioritize it, we can make a concrete proposal with how the new w3id/redirections would be and clearly state what would be the changes. Then we can open it up to the rest of the community to be incorporated in the next release? |
|
In the SciCodes consortium, we have decided to open this as a discussion to get a community vote. |
|
Now in #360 |
Hello,
I want to use Codemeta on our next version of OntoSoft. However, the content negotiation of the schema is not correct. When I do
curl -sH "accept:application/json+ld" -L https://codemeta.github.io/terms/I am expected to obtain https://raw.githubusercontent.com/codemeta/codemeta/1.0/codemeta.jsonld, i.e., a machine readable description of the schema. Instead, I am redirected to the human-readable html page.
I don't think you can enable content negotiation on GitHub pages, but maybe having a w3id would be desirable.
The text was updated successfully, but these errors were encountered: