Using the HTTPS context applies HTTP properties and classes

[wouterbeek]

Observation

In line with the HTTPS/HTTP FAQ Triply prefers the HTTPS variant of the Schema.org vocabulary over the HTTP variant (although both are fine and supported).

However, if we reference the Schema.org remote context we can only use the HTTP variant, and not the HTTPS variant. Specifically:

{
  "@context": "https://schema.org/",
  "@id": "https://triplydb.com/DBpedia-association/dbpedia",
  "@type": "Dataset"
}

results in:

<https://triplydb.com/DBpedia-association/dbpedia> a <http://schema.org/Dataset>.

^ Notice that the HTTP variant of the class is applied, not the HTTPS variant.

Live run in the JSON-LD Playground

Expected

Specifying the HTTPS remote context to result in applying the HTTPS variants of the properties and classes.

[danbri]

There is no https variant, partly because the site is statically served. Conidering rdfa and microdata are also out there in both variants, some post-processing is always needed

On Wed, 22 Feb 2023 at 20:16, Wouter Beek @.***> wrote:

Observation

In line with the HTTPS/HTTP FAQ https://schema.org/docs/faq.html#19 Triply prefers the HTTPS variant of the Schema.org vocabulary over the HTTP variant (although both are fine and supported).

However, if we reference the Schema.org remote context we can only use the HTTP variant, and not the HTTPS variant. Specifically:

{ @.": "https://schema.org/", @.": "https://triplydb.com/DBpedia-association/dbpedia", @.***": "Dataset" }

results in:

https://triplydb.com/DBpedia-association/dbpedia a http://schema.org/Dataset.

^ Notice that the HTTP variant of the class is applied, not the HTTPS variant.

Live run in the JSON-LD Playground https://tinyurl.com/2s3def43 Expected

Specifying the HTTPS remote context to result in applying the HTTPS variants of the properties and classes.

— Reply to this email directly, view it on GitHub https://github.com/schemaorg/schemaorg/issues/3270, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABJSGLXQX4A2XEVMBFLQK3WYZX27ANCNFSM6AAAAAAVEY66RY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[mightymax]

There is no https variant, partly because the site is statically served. Conidering rdfa and microdata are also out there in both variants, some post-processing is always needed …

The issue is that the website uses the preferred form in all examples to start with https:// over http:// where the JSON-LD context itself which still uses http:// over https:// (look for the "@vocab": "http://schema.org/" entry). This will block many users from moving to the preferred https:// IMHO.

[mightymax]

Also note that in the codebase there is already some work done to switch to https, see this diff.

[danbri]

Everything is migrated except the ns of the triples emitted by json-ld parsers.

@RichardWallis are there any options for serving a different variant of the context when it is fetched by https?

[RichardWallis]

@danbri There is no in-built configuration in our cloud hosted site to serve a different static file dependant on the protocol (http / https) used for a request.

This leaves two options:

1. Implement live logic to inspect incoming requests and return protocol specific context files. However, this would expose us to the type of DoS attacks that caused us to move to a static site.
2. Change the current context file to be https based which would satisfy the desires expressed here. However, the knock-on ramifications of such a move for those currently expecting and/or depending upon http based code could be significant.

[KalleOlaviNiemitalo]

I hit this issue while trying to check the sanity of the JSON-LD that was generated by my application. On the JSON-LD playground, the "Compact" feature fails due to the URI scheme mismatch. Consider the JSON-LD input:

{
  "@context": "https://schema.org/",
  "@type": "https://schema.org/WebPage"
}

Now if you try to compact that using the context shown, then the result is:

{
  "@context": "https://schema.org/",
  "type": "https://schema.org/WebPage"
}

i.e. https://schema.org/WebPage did not compact to WebPage.

I hope a note about this can be added to the FAQ where it says either scheme can be used.

A hack that comes to mind is just put the https-based context at a different path, i.e. require authors to use "@context": "https://schema.org/https.jsonld" if they want to expand IRIs to HTTPS URIs. That would not be a problem for the cloud hosting, I hope.

[KalleOlaviNiemitalo]

Related issues https://github.com/schemaorg/schemaorg/issues/2853 and https://github.com/schemaorg/schemaorg/issues/2886.

[github-actions[bot]]

This issue is being nudged due to inactivity.

[kathrinrin]

I would like to upvote this issue.