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

Hi,

Thanks for the reply.  jsonld-java does not execute the remote-doc tests,
yet.  Interesting thing about the 0009 test is that the Link references a
non-HTTP document.  Processing Link headers is not that easy, but I would
assume that the test client should also try to dereference the Link Header
using an HTTP client.  I will check how jsonld.js does this.

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


​By "URI base issues", I assume that you mean when @context is referenced
with an IRI in a document.  Perhaps, this form and also the JSON-LD
profiles that do not include context (i.e. http://www.w3.org/ns/jso
n-ld#expanded) should be mentioned in the spec as exclusions to the
#context constraint if these are intended to also be served as
application/ld+json.

The concern that I would like to address relates primarily with the "HTTP
context" dependency that you indicate.  If a client depends on an processed
document format (e.g. framed or compacted) and the @context or frame is
only served by HTTP, then any client-side JSON-LD processing (required when
a document is served in a non-expected format like RDF or JSON-LD expanded)
requires some hypermedia mechanism whereby these dependencies can be
dereferenced and validated *before* deserialization.

An undefined point is how an LDP server can persist @context in RDF for a
particular document graph or document collection.  This seems to be related
to a the client expectation of a particular document format that can only
be provided by an remote reference (z.B. the "HTTP context").  A client
could issue some form of negotiated "Accept-Processing-Document" request,
and the server could respond with an "processing document" IRI, (but only
if it had persisted it) ...

Furthermore, it seems then that an "HTTP context" is a actually a
dependency for client-side processing of the document , and could be
serviced similarly to other compile time package dependency managers (e.g.
Maven Central, npm, etc.).  This frees the producer from having to provide
custom headers for every possible document processing relation.  When
deserializing from JSON-LD, the producer could persist a context hash with
the graph that pointed to a package, and let the client do the rest.  For
LDP implementations, where the data can be serialized dynamically from RDF,
the client does have the potential to declare profile preferences, though I
am not sure why it would if it were doing the processing.  The protocol
regarding negotiation of JSON-LD processing options is undefined at the
moment, though this is yet another "feature" that could be considered for
server-side negotiated processing.

It seems a gray area as to where the JSON-LD processing *should* occur.  In
writing this, I have convinced myself that a clean solution is to have the
producer provide expanded or RDF with some externally defined reference to
processing options and context dependencies and let the client do the
processing into its desired format.  No need for negotiation of
preferences!  However, "tailored JSON serialization" is generally what some
clients expect, though this level of service certainly has a cost in
complexity for the producer.

Christopher Johnson
Scientific Associate
Universitätsbibliothek Leipzig

On 19 October 2017 at 19:03, Gregg Kellogg <gregg@greggkellogg.net> wrote:

> 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" 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 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 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.
>
> 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-profi
> le-parameter-for-json-ld-requests
> [2] https://json-ld.org/spec/latest/json-ld/#interpreting-json-as-json-ld
> [3] 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>
>
>
>
>
>
>