-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Schema.org moving from HTTP Content Negotiation to JSON-LD 1.1 "Link:" header for context file #85
Comments
The main Schema.org site should have the headers discussed now, i.e.
|
@hsolbrig can you suggest a workaround, at least for short term use? Can we pass in the context when invoking parser (by URL or by content?) /cc @Gnomus042 |
Is there no way to do this without requiring a custom HTTP header? Why is that part of the data specified out-of-band from the rest of the document? (edit) Static files (with no HTTP server configuration dependency) are most scalable and archivable. |
@rob-metalinkage, is this going to cause problems for JSON- > JSON-LD expansion due to the separate Context? |
@danbri, @westurner, @hsolbrig RDFlib maintainers are assembling volunteers to complete this tools' JSON-LD 1.1 implementation and then to merge it into RDFlib core. That should make it easier for all to just "do" JSON-LD with RDFlib. |
@nicholascar I dont think it causes any extra problems, as using just a model namespace to perform JSON->JSON-LD expansion is unsafe anyway. The patterns appearing to be in the wild seems to be: Data model = X i.e. there is no way to discover for a model X the relevant context file. Or the requirement to perform content negotation is based on a model Datamodel = X this is being taken off the table as a bad idea according to this issue, but it has a deeper issue IMHO that if your data model is described in OWL , then ld+json should be the data model serialised as JSON-LD, not necessarily a JSON-LD context for the model. The options for canonical mechanisms to discover the actual URL for a context seems to be: if dx-prof-conneg supports the same Link syntax and if a resource chooses to embed the Link headers for all the available profiles and serialisations from the "alt" view by default the two approaches are consistent I think. I'd always choose the latter, as JSON context is not the only resource I'd want to be able to discover about a model. JSON-schema is also valuable, and SHACL and HTML and maybe other forms. |
Maybe I'm misunderstanding? From https://www.w3.org/TR/json-ld11/#the-context ::
|
@westurner you are right it doesnt need necessarily need a custom header, but there are a couple of things that need care here:
we can say its all client code to tell RDF lib exactly what to include and maybe not think about this - but this issue is about other approaches such as trying to resolve namespaces such as schema.org and getting a context.
|
I think the following code (failing to load the schema.org context) is linked to the present problem, but doesn't understand the workaround jsonldSample = """ g = Graph().parse(data=jsonldSample, format='json-ld') |
Updated schema.org context document address in the light of RDFLib/rdflib-jsonld#85
This happened faster than planned due to a DOS attack this week, details in schemaorg/schemaorg#2578 (comment)
Schema.org no longer publishes a JSON-LD context file using HTTP content negotiation. Our homepage URL always returns HTML. This affects the parsing of all JSON-LD that expects to get a context definition from URLs "http://schema.org", "https://schema.org", "http://schema.org/", "https://schema.org/".
The URL of our context file is https://schema.org/docs/jsonldcontext.jsonld
We will shortly update the site to declare this URL via a Link header (see above issue for details).
I am filing this issue
The text was updated successfully, but these errors were encountered: