-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to handle HTTPS for schema.org? #118
Comments
Correct. It was the change in latest RDFLib v6.1.1 that causes this. Interesting back story, RDFLib changed to HTTPS version of Schema.org two years ago in the 5.0.0 development cycle but it somehow got changed back to HTTP in the codebase before release. This has recently been fixed (in v6.1) but it didn't affect many people until a different change in 6.1.1 came in effect. There is new behaviour in v6.1.1 to pre-register all known common built-in namespace prefixes into the graph Namespaces dict when a new graph is parsed. That is why the "schema" prefix is now taken up, and your non-HTTPS namespace is added as "schema1". One thing you could try. After creating the
No, and they're trying to work through that issue over in RDFLib. I don't know how the people at rdflib.js javascript library handle it, it would be good to touch base with them.
I would. |
Thanks a lot for your response and the hint to override the default namespace. All clear now :-) |
Since I've updated |
Hi there
Using
pyshacl
for my schema.org resources, I recently encountered a change in the reported errors. Instead ofschema
I now seeschema1
as a prefix. Because I experienced the same behaviour when building the docs from my SHACL shapes using https://github.com/lambdamusic/Ontospy I thought this could be related to https://github.com/RDFLib. This turned out to be the reason since they recently switched from http://schema.org/ to https://schema.org/ (TLS).schema
now seems to refer to https://schema.org/ andschema1
to the non TLS version of it.I am aware that this is not a
pyshacl
issue. However, I wonder whether http://schema.org/Thing is different from https://schema.org/Thing. In a technical sense it's clearly two different things but I think everyone would agree that they refer to the same concept, as stated here.Are there any best practices to handle this? Should one switch to HTTPs for schema.org asap?
The text was updated successfully, but these errors were encountered: