Clarify http/https vocabulary differences with JSON-LD

[stain]

https://schema.org/docs/developers.html seems to indicate that developers should prefer https version of the vocabulary definitions.

However the JSON-LD context (even with @context: https://schema.org/) maps to the http namespace which has been consistent since the beginning of schema.org (I do not suggest changing this!) - try for instance in https://json-ld.org/playground/

I think it's good the JSON-LD is consistent for both @context examples.

However RDFa examples like https://schema.org/CreativeWork use vocab="https://schema.org/" as namespace declaration.

I think developers.html should acknowledge this difference so that developers are aware of both variants, and highlight that the JSON-LD context will map to http. It depends on where the data comes from which variant developers will want.

Something like:

For consistency with structured data already deployed with JSON-LD, the @context resolved for both http://schema.org/ and https://schema.org/ will continue to be mapped to terms in the http namespace.

BTW: developers.html page could also benefit with a link to the JSON-LD context https://schema.org/docs/jsonldcontext.json as I struggled to find it!

[danbri]

You are right - we've also apparently lost navigability to the FAQ document.

The https thing is tricky, and needs documenting somewhere. I'll tag this issue for the next release - thanks

[github-actions]

This issue is being nudged due to inactivity.

[mdw00d]

Changing the namespace is problematic for existing applications. Obviously if a program was written referencing e.g., schema:Action and the definition of schema: has changed from http://schema.org/ to https://schema.org/, then this adds unnecessary complexity for programs that now have to know that those two predicates are the same. SPARQL queries have to handle either form, etc.

Namespaces really should not change unless there's a fundamentally new version.

[nicholascar]

rdflib will stick to HTTPS for schema.org. We had some confusion with an accidental reversion to HTTP recently but we are now HTTPS and will stay there.

[github-actions]

This issue is being nudged due to inactivity.

[rlzijdeman]

In #3270 @RichardWallis writes:

@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.

So 1. does not seem to be an option, but today's course of not acting on 2. has ramifications of its own. In my country two major national research infrastructures are now split over the http:// - https:// issue (see codemeta/codemeta#373), but also the many references above.

To sum up:

• the preferred URI for schema terms is https:// as mentioned here and acknowledged here and here
• the schema documentation provides both a https:// and http:// json-ld version, the https:// being the default select option. See: [docs/developers]https://schema.org/docs/developers.html
• however, this machine readable file refers to the deprecated URI http:// , which is used as argument to stick to http:// when using JSON-LD
 see here and leads to various issues (e.g. here).

I would therefore, like many above, reiterate the request to -take action- on this matter. Note, that this is perhaps more about social engineering than about technical engineering. Schema.org now deprecating the http:// URI, but leaving ample room for discussion in the FAQ and the machine readable file, creates unclarity.

A solution as with Python migrating from 2 to 3 seems a good option, using a clear announcement of the https:// being -also in JSON-LD- the official URI say per Jan 1st 2027, with support being dropped by say Jan 1st 2028, gives: (1) clarity on the future direction of Schema, (2) ample time for people to adjust to the idea and make decisions on URI use in current and future projects, (3) brings the community 1 step closer to aligned vocabulary use.