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

Hi list,

Following up on this:
In a discussion regarding JSON-LD processing documents in relation to an
implementation of LDP, a few specification points have been addressed:

1. Since JSON-LD processing documents cannot be deserialized to RDF (and
are therefore not JSON-LD documents), they *MUST* be served with a
Content-Type application/json.
2. As application/json Content-Type, JSON-LD processing documents can
only be persisted in LDP as rdf:type http://www.w3.org/ns/ldp#NonRDFSource
..
3. A (recommended) HTTP header for clients who need to identify a
processing document to a specification compliant LDP implementation *MAY* be
Accept: application/ld+json; profile="http://example.org/context.json
<http://www.google.com/url?q=http%3A%2F%2Fexample.org%2Fcontext.json&sa=D&sntz=1&usg=AFQjCNGVZtpiz4NkamqiB3uatpw9ZmXeyw>
"

Christopher Johnson
Scientific Associate
Universitätsbibliothek Leipzig

On 23 October 2017 at 00:59, Gregg Kellogg <gregg@greggkellogg.net> wrote:

> On Oct 22, 2017, at 11:58 AM, Martynas Jusevičius <martynas@atomgraph.com>
> wrote:
>
> Why should LDP be concerned with any specific serialization?
>
>
> I think the concern is likely captured in issue #491. A context cache
> isn’t really something the spec needs to handle explicitly, as it already
> provides the means to specify an alternative document loader, with which a
> client could implement a context cache.
>
> Gregg
>
> 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>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>