JSON-LD 1.1 Feature Request : define how to specify the json-ld profile in a request to a server and include framing as an option

[lisp]

the current descriptions provide means to specify encoding and framing options through a programmatic api. these include the context to apply, whether to frame the result.
they also provide means in http headers to specify the variant which applies to the given document in terms of a link to a context and/or a media type profile.

the 1.0 descriptions do not appear to provide a way to specify that same information to a json-ld source as part of an http request.
is this now included somewhere in 1.1 document?
are there plans to provide for this?

[gkellogg]

You can see the current Editor's Drafts of the specs here (note, RDF API is archaic).

The IANA Considerations describe values for a profile parameter, but do not provide a mechanism to provide a context to use for compacting. There is a mechanism for providing a context to use when expanding, but only if the content type is not application/ld+json (see Interpreting JSON as JSON-LD), and that is for a reply, not a GET.

Framing was not part of 1.0, so was not included as a possible profile; expect it to be included for 1.1.

I don't recall any discussions we may have had about providing such information for retrieving JSON-LD documents, but there may be something buried in the closed issues. Is this what you're referring too?

[lisp]

I don't recall any discussions we may have had about providing such information for retrieving JSON-LD documents, but there may be something buried in the closed issues. Is this what you're referring too?

yes, the issue is, how to specify in an http request to a sparql endpoint everything which is required in order to effect and control framing.
i found no mention in any issue - open or closed.

as an interim measure, we have been using the same mechanism as served to report the state of the response, but that has no actual basis in the recommendations.

[gkellogg]

It seems to me that there are three ways in which a request might include the location of a context to use for compacting or frame to use for framing:

• Include as a URI query parameter in a GET request. This could be advisory only.
• Add another parameter(s) to the content-type registration for context and frame in addition to profile. (I believe these parameter names are specific to the content-type so don't require independent registration).
• Add Link Relations definitions with a LINK header in the request defining URIs to describe the target as a Context for doing compaction or Frame for framing.

Of these, I think an informative description of doing this in a query parameter is probably safest, and allows it to be specified using CURL or WGET more easily. But, this is an area the spec cannot normatively address.

The second possibility seems consistent with the use of a profile parameter, but I recall that the discussions around this were complicated, it it may be more challenging than we thing. Also, considering that a service actually needs to dereference the URIs and use them in server-side processing, there are greater security implications. Perhaps @msporny @dlongley @lanthaler or @niklasl have better recollection about these discussions for 1.0.

The last option of using a Link relation seems inconsistent with normal REST principles, so I would not recommend that.

@lisp please share your experience doing this with Dydra, the specifics of your "interim measure" and what your experience with that has been.

[lisp]

the last option, the link header, is what we actually implemented, but upon consultation with the customer who uses this the most, i was informed that, absent a "standard" mechanism, they reframe everything in the client. that is, we frame it once - without a context and they frame it again to effect the name substitutions, on their end. seems very wasteful.

we did not put it in the url as a query argument, as the context is not a semantic component of the addressed resource.
we did not add a media type parameter, but would not be averse to that approach, as the context is an elaboration of the media type designation.

[Conal-Tuohy]

@lisp do you allow clients to request any frame at all? i.e. are the acceptable values of the header constrained, e.g. with a "same domain" policy?

[lisp]

we see that as on the same order as a service location: if the host requires authorization, it's just another external resource. Am 27.05.2017 6:20 vorm. schrieb "Conal Tuohy" <notifications@github.com>:

…

@lisp <https://github.com/lisp> do you allow clients to request any context at all? i.e. are the acceptable values of the header constrained, e.g. with a "same domain" policy? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#491 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALs7vJOMJBeCA88PuCYxcDFbVxMzgDzks5r95q0gaJpZM4NdglK> .

[Conal-Tuohy]

My question is really this: if I were to send a request to your JSON-LD server asking for a response to be framed using a resource http://example.com/some-arbitrary-frame-which-might-be-multiple-gigabytes-in-size, would your current implementation attempt to use that frame, or would you (for instance) reject it because it was not in a white-list of acceptable frames?

[lisp]

indirectly, yes, it could be rejected, but not because there is a white list of frames.
a service which enforces access authorization can signal an error if the respective repository's account does not have read access for the remote resource.
that is, in the sense of the question, resources are "white-listed".

whether the size matter is another issue.
unless we arrive at a point where particular aspects of query processing are metered, we could limit the size of a context, but that would not really matter.
if the context were "too large", the respective query processor would exhaust its memory and exit.
this is no different than the consequences of a service request response of excessive size or a cross-join of a single-subject repository.
that request fails and the next proceeds with a new process.

[mongoponzo]

if I were to send a request to your JSON-LD server asking for a response to be framed using a resource http://example.com/some-arbitrary-frame-which-might-be-multiple-gigabytes-in-size

My understanding is that you do not pass a URL to the frame, but instead you pass the frame itself. So this issue should already be handled by the webserver (or any proxy before it).

[lisp]

the question does not concern the programmatic api.
it relates to a json-ld stage which is integrated into a sparql processor, which means the question is exactly how that sparql server handles the protocol-level issue.

[Conal-Tuohy]

Yes the HTTP interface is exactly what I'm interested in; whether that's for a SPARQL query processor or indeed for any kind of "linked data" server, such as an LDP server. I am curious about current implementations of this (currently unspecified) part of the protocol, which is really a particular kind of HTTP Content Negotiation. It had struck me that allowing a client to specify a frame by URI reference would present a new DoS attack surface, so my curiosity was about whether implementers had made any attempts to mitigate that risk.

NB SPARQL query processors will often provide an analogous system for XML-based serializations of RDF, in which they will accept a URI parameter from the client which refers to an XSLT stylesheet to be used for re-writing the result (and which is roughly equivalent to JSON-LD framing), but such XSLT processing is always done client-side; the server simply returns a result with an embedded XML processing instruction which refers to the XSLT. Doing the XSLT processing server side would impose a DoS risk on the server.

[lisp]

so, i tried to make it clear in my answer that each and every sparql request is in and of itself a dos vector.
does the context url add something new to that risk?
nb. we support also server-side xslt processing.