Re: Interpreting JSON as JSON-LD / Content-Type header spec. requirements

> On Oct 17, 2017, at 8:29 PM, Christopher Johnson <chjohnson39@gmail.com> wrote:
> 
> Hi list,
> 
> In am writing tests and possibly a​n async document loader implementation for jsonld-java that could check Content-Type and Link headers before fetching.  The current one does not.

There are tests for this in the JSON-LD test suite, specifically remote-doc-0009-0011.

> curl -I https://json-ld.org/test-suite/tests/remote-doc-0009-in.jsonld
HTTP/1.1 200 OK
Accept-Ranges: bytes
Access-Control-Allow-Origin: *
Content-Length: 77
Content-Type: application/ld+json
Date: Thu, 19 Oct 2017 16:54:08 GMT
Etag: "20d78-4d-4e582e01c8079"
Last-Modified: Tue, 03 Sep 2013 23:16:15 GMT
Link: <remote-doc-0009-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"
Server: Apache/2.2.22 (Ubuntu)
Vary: Accept-Encoding

>  I would like ​to ​research and find actual examples where the JSON-LD specification about the Interpretation requirement has been observed.  Anyone know a site that serve​s​ Content-Type application/json with a Link header that provides a "http://www.w3.org/ns/json-ld#context <http://www.w3.org/ns/json-ld#context>" relation?
> 
> Also could some​one please explain why application/ld+json is forbidden to provide an #context relation with a Link Header?

The rational is buried in the GitHub issue tracker, but as I recall, application/ld+json is intended to represent a JSON-LD document that can be fully interpreted based on its content, rather than rely on out-of-band information. This allows the document to be used outside of it’s HTTP context (URI base issues aside).

> Is an #context relation (if served as application/ld+json) allowed to specify a  http://www.w3.org/ns/json-ld <http://www.w3.org/ns/json-ld> profile?

I think there’s a test for this, where it is specifically ignored (0009).

> Or could a non http://www.w3.org/ns/json-ld <http://www.w3.org/ns/json-ld> Content-Type profile be served as application/json and provide a secondary #context relation if it were itself an #context ?

Need a more specific example of this.

> Should the document loader check (and ​subsequently dereference the relations) if "second-step" remote documents provide Link and/or Content-Type profile?  Should there be a processing "order of precedence”?

The remote-doc test manifests  does have some redirect logic, but you’d need to look more specifically to see if it addresses what you’re concerned about; we can always add more tests. https://json-ld.org/test-suite/tests/remote-doc-manifest.jsonld <https://json-ld.org/test-suite/tests/remote-doc-manifest.jsonld>.

> Just trying to understand required hypermedia options and possible use cases.

Happy to help, also you can chat on Giiter or IRC.

Gregg

> Thanks,
> Christopher Johnson
> Scientific Associate
> Universitätsbibliothek Leipzig
> 
> [1] https://stackoverflow.com/questions/39551829/usage-for-profile-parameter-for-json-ld-requests <https://stackoverflow.com/questions/39551829/usage-for-profile-parameter-for-json-ld-requests>
> [2] https://json-ld.org/spec/latest/json-ld/#interpreting-json-as-json-ld <https://json-ld.org/spec/latest/json-ld/#interpreting-json-as-json-ld>
> [3] https://github.com/IIIF/api/issues/1066 <https://github.com/IIIF/api/issues/1066>
> ​[4] https://github.com/ProfileNegotiation/I-D-Accept--Schema​ <https://github.com/ProfileNegotiation/I-D-Accept--Schema%E2%80%8B>
> 
> 
>