Handling schema.org HTTP/HTTPS mismatches

[pbuttigieg]

schema.org allows both HTTP and HTTPS, however this is very unusual behaviour and generates two different namespaces.

In ODIS we convert everything to HTTPS for operations, but in our release graphs we show what the partners share. We strongly recommend that all nodes use the HTTPS protocol and thus https://schema... prefixes

@fils to document this process and status

@jmckenna to create warning dashboard icon/status on nodes that are sharing HTTP. @fils to generate back-end push/messages/validation for dashboard to react to

[smrgeoinfo]

see https://github.com/ESIPFed/science-on-schema.org/blob/master/guides/GETTING-STARTED.md#specifying-the-context. Note that that context document identified by "@context": "https://schema.org/" specifies "@vocab": "http://schema.org/" and the schema: prefix "schema": "http://schema.org/". Check it out at https://schema.org/docs/jsonldcontext.json

on the https://schema.org/docs/developers.html page, under the "Machine Readable Term Definitions" heading it says:

The JSON-LD context is available from https://schema.org/docs/jsonldcontext.json. Schema.org is typically deployed in JSON-LD 1.0, but the location of our context file is exposed via JSON-LD 1.1 conventions, as an HTTP link header (the commandline tool 'curl' can be useful, e.g. used with -I -i arguments). We serve the same context description regardless of whether the context is retrieved with http or https.

[smrgeoinfo]

as a simple example this JSON-LD

{
    "@context": "https://schema.org/",
    "@type": "Thing",
    "@id": "igsn:metadata",
    "name": "rock sample"    
}

generates these triples using the JSON-LD playground (bogus prefixes to keep it short)

**** "rock sample" . **** . note that the schema.org namespace is http:

[pbuttigieg]

@fils which side of the road are we driving on?