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

Why should LDP be concerned with any specific serialization?

On Sun, 22 Oct 2017 at 20.44, Gregg Kellogg <gregg@greggkellogg.net> wrote:

> On Oct 21, 2017, at 8:49 PM, Christopher Johnson <chjohnson39@gmail.com>
> wrote:
>
> 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.
>
>
> It is HTTP, but should be HTTPS, I’ll update the .htaccess file that sets
> this. However, it should redirect and work anyway.
>
> 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/json-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.
>
>
> By “URI base issues”, I mean the resolution of non-absolute
> document-relative IRIs; but, this is a common issue among any format that
> uses relative IRIs where the document is used outside of a scheme that can
> be used to determine the base IRI (URL). Implementations may provide a
> means of setting this through options. If the `@context` uses a relative
> IRI, it will have the same issue.
>
> However, the spec mostly is concerned with JSON(-LD) documents served over
> HTTP(S); certainly when the Link header is involved.
>
> 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.
>
>
> You can also specify the context through the API (both for expansion and
> compaction). Same with the frame.
>
> If dependencies are provided outside the document envelope (Link header or
> API option), you can certainly do this. If inside the document, then you
> need to deserialize to find the references (consider an @context embedded
> within some object).
>
> 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) …
>
>
> There isn’t a way to represent a context in RDF, per-se, other than when
> serialized as JSON-LD which includes a top-level @context.
>
> These seem like reasonable concerns, however, but perhaps they should be
> considered in LDP. At most, I could see the API including some form of
> @context lookup hash that would allow an implementation to look for context
> references that are in this hash and use them rather than perform a
> dereference.
>
> 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.
>
>
> If the server maintains such a cache, then presumably it could be included
> in a JSON-LD serialization when serialized. It’s similar to prefix
> management for Turtle, where the service may have a configured set of
> prefixes it uses when serializing resources.
>
> There is also an open-issue to allow the client to request (#491) [1],
> which could also be used for specifying a context the service should use
> when serializing compacted/framed JSON-LD (presumably, subject to
> white/black listing on the server side).
>
> 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.
>
>
> The JSON-LD spec was originally written from the perspective that a client
> may apply algorithms to the received JSON-LD to put it in the most
> convenient form for local processing, but I think that, in actuality, it’s
> more common for clients to work with the results the server sends directly,
> thus the need for additional request profile information (tying us further
> to HTTP(S)).
>
> This is a complicated enough issue that we might consider creating an
> ad-hoc conference call to discuss in more detail, or perhaps piggy-back on
> some existing LDP call (if such exists).
>
> Gregg
>
> [1] https://github.com/json-ld/json-ld.org/issues/491
>
> 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-profile-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>
>>
>>
>>
>>
>>
>>
>
>