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

A context document without any graph is absolutely valid JSON-LD and thus
can be served with the JSON-LD media type. You process it and get zero
triples, but it's still a valid serialization of the empty graph.

In terms of LDP, if you want to manage the context as a separate *document*
then yes, you need to manage it as a LDP-NR.

Rob


On Thu, Oct 26, 2017 at 11:14 AM, Christopher Johnson <chjohnson39@gmail.com
> wrote:

> By "processing document", I mean only an @context or frame that is served
> without a graph body via HTTP.  i.e. analogous to  "schema".
>
> The server-side processing from and to RDF is facilitated by "localized"
> persistence of schema as LDP-NRs, so that it does not have to depend on an
> HTTP client to dereference potentially unknown/threatening entities
> remotely.  Of course, a client can opt to process the document itself if it
> does not issue the Accept header and just fetches the graph as RDF.
> However, as mentioned, the prevailing trend seems to be have the server do
> the processing to simply the client interaction model.
>
> Christopher Johnson
> Scientific Associate
> Universitätsbibliothek Leipzig
>
> On 26 October 2017 at 19:31, Gregg Kellogg <gregg@greggkellogg.net> wrote:
>
>> On Oct 26, 2017, at 1:04 PM, Christopher Johnson <chjohnson39@gmail.com>
>> wrote:
>>
>> 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.
>>
>>
>> Can you clarify this? If the JSON-LD processing document is JSON-LD, it
>> would include an @context, which would allow it to be interpreted as RDF,
>> no? application/json can serve a JSON document that can be interpreted as
>> JSON-LD by linking to a context, or it can return a JSON-LD document
>> containing @context (or both). Am I missing something?
>>
>> No clear what a “processing document” is in relation to LDP.
>>
>> 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  .
>>
>>
>> This wouldn’t seem to restrict a client’s ability to process it as
>> JSON-LD, though, would it?
>>
>> Gregg
>>
>> 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.json
>>>>> ld
>>>>> 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
>>>>> <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/tes
>>>>> t-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-a
>>>>> s-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>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Rob Sanderson
Semantic Architect
The Getty Trust
Los Angeles, CA 90049