Content negotiation for JSON-LD (or TTL) representation

[dgarijo]

Hello, I have noticed that http://schema.org does not resolve to a machine-readable format:

curl -H "Accept:application/ld+json" -L http://schema.org/

Returns HTML. (Also tried with application/json, and text/turtle and got the same result). I wonder if there is a reason for not supporting content negotiation on the vocabulary?

Also, the data releases snapshots in the README lead to a 404: https://schema.org/version/

I have searched, and I have found some related issues (#3378, #2841), but I have not found anything about content negotiation.
Thanks!

[gkellogg]

It turned out that traditional content-negotiation is difficult for some static sites. Instead, schema.org relies on using a link header with rel=alternate:

$ curl -I -L http://schema.org/

...
link: </docs/jsonldcontext.jsonld>; rel="alternate"; type="application/ld+json"

This is provided for in JSON-LD 1.1 Alternate Document Location.

[dgarijo]

@gkellogg thanks for your answer.

Can you please provide a little bit more information on the difficulty for static sites, or where can I read more about this issue? As in, why are static sites trying to resolve schema.org and how is content negotiation problematic? (as opposed as the rel="alternate" approach)

I find that this solution does not currently address:

• Resolving Schema.org elements does not return the rel="alternate" document, e.g., curl -I -L http://schema.org/Person
• The README states that the main schema is in .ttl, but I see no way to get to it with content negotiation. I tried curl -IH "accept:text/turtle" -L http://schema.org/ and I only get the redirection to the /docs/jsonldcontext.jsonld file.

Thanks in advance!

[gkellogg]

Some of your questions pertain to the schema.org setup, and what they are expected to return when resolving identifiers such as Person. They do have a Turtle version of their schema at https://github.com/schemaorg/schemaorg/blob/main/data/schema.ttl, but it is not returned as part of any content-negotiation.

The rel="alternate" returned from the main schema.org page is to resolve a request for a JSON-LD context, not for an alternate representation of some specific vocabulary item. As with many such sites, schema.org runs as a static site, for handling an Accept header for content negotiation is difficult, so they use the rel=alternate mechanism which is easier to configure.

When other software tries to extract JSON-LD from an HTML page and that JSON contains "@context": "https://schema.org" (or similar) a JSON-LD processor will attempt to retrieve that context (although it really should be cached) and the rel=alternate is a way for a conforming JSON-LD processor to redirect to the actual location of the context. This allows the embedded JSON-LD to be manipulated using standard algorithms,, including transforming it to RDF, which may then be serialized using Turtle, for example. AFAIK, schema.org does not, itself, depend on this for retrieving a context.

[dgarijo]

Thanks again for your answer.
I will leave the issue open in case the maintainers consider useful adding some sort of content negotiation. Please feel free to close it if this is out of the question.

[pietercolpaert]

Related to this: the content-type header of https://schema.org/docs/jsonldcontext.json returns application/json instead of application/ld+json.

If I understand the JSON-LD spec correctly, that must trigger a JSON-LD compliant parser to look for a Link header towards a context to interpret that file as a JSON-LD file. If the link header is not provided, the parser must return an error.

Can the content-type of this page be changed to application/ld+json?

[pietercolpaert]

Solving my own comment: it appears https://schema.org/docs/jsonldcontext.jsonld does have application/ld+json as a content-type and I was testing the wrong URL.