Closed Bcadej closed 1 week ago
@Bcadej What you are seeing is the difference between the URL of a page on the Schema.org website (https based), and the the (http based) unique identifier (URI) for the structured data vocabulary term that the page describes.
Those http based identifiers have been associated with their terms since the start of Schema.org in 2012. Those values will be found in datasets, queries, and code far and wide across the web. Therefore just changing them to new https based identifiers is not as simple as it sounds. The ramifications could be significant for established processes.
This issue was discussed in detail in issue #2018, in reference to the term canonical value displayed on each page (under the [more...] tab). Check this out for more information.
@RichardWallis actually we could update most of the examples. The use of specific URIs in our data dumps and schemas is, as you say, a more complicated business. But we have long had consensus that people can use https: in their markup (see FAQ, https://schema.org/docs/faq.html#19 ).
or adding owl:sameAS between the 2 URI so people can effectively use them both
@RichardWallis I no longer see the [more...] tab that shows the HTTP Canonical URI (as well as Leave public feedback and Check for open issues). Is this a different issue or by design? This is what we used to see:
See issue #2610 for fix to [more...] issue.
The ESIP science-on-schema.org group is in the process of providing implementation guidance for adoption of the https://schema.org/
prefix for term definitions in JSON-LD markup for schema.org. This requires a mechanism to reliably dereference the context document for http
vs. https
based term definitions.
What are the plans with respect to dereferencing the context for schema.org markup in JSON-LD? Can we assume a http
request (http://schema.org/
with Accept: application/ld+json
) will return a context with http
schema.org term definitions, and similarly, a https
request will return a context file with https
term definitions?
See also https://github.com/RDFLib/rdflib/issues/1120#issuecomment-668536109 for discussion on canonicalizing from http to https URIs in Python rdflib
One approach being evaluated for handling potentially mixed schema.org namespaces is normalization to https
on load using the JSON-LD API expand and compact methods. The workflow is basically: expand the source graph to remove context, compact with a known context, then switch the namespace in the context of compacted graph.
A worked example is available at https://github.com/ESIPFed/science-on-schema.org/blob/develop/examples/SO_normalize_javascript.ipynb
This seems to work OK (so far) for web page scale content. I'm interested to hear of other approaches for working with this challenge.
This issue is being tagged as Stale due to inactivity.
On website https://schema.org every example is writen without s -> http://schema.org
Fix all documentation to https://schema.org