could a profile also be an object?

[christopher-johnson]

In relation specifically to JSON-LD, I wonder about the possibility of defining an HTTP mechanism for a client to inject a context or frame (as a String or Object) into the server response serialization process. Jena JsonLDWriteContext does not (yet) use a remote document loader, so any server implementation depending on it could not use an IRI profile.

It does however allow Strings or Objects. This mechanism may have some overlap with Accept-Patch.

It would also be helpful to have a specification that defined an HTTP method for a client to specify JSON-LD processor options.

[larsgsvensson]

I wonder about the possibility of defining an HTTP mechanism for a client to inject a context or frame (as a String or Object) into the server response serialization process

Wouldn't that be a pretty huge security threat? If any client can inject their preferred JSON-LD context into the reply they can change the intended semantics of the response payload at their liberty.

[christopher-johnson]

It is a risk that could be handled by the server implementation with ACL/whitelisting.

For reference, this mechanism is being discussed relation to Trellis LDP and https://github.com/json-ld/json-ld.org/issues/491.

The object size for a profile would be constrained by a LimitRequestFieldSize directive (in Apache), though even for larger @context a normal default of 8K, could work. The efficiency of such a mechanism is probably greater for a producer than having to dereference an profile IRI before serialization.

[larsgsvensson]

But couldn't all of this be done client-side, too? When the client receives the stream, it can substitute the server-provided context with its own context without having to send the client context to the server in the first place (or do I misunderstand something?).

The efficiency of such a mechanism is probably greater for a producer than having to dereference an profile IRI before serialization.

If it's a profile that is often referred to, I would suggest that the client caches the profile. Then it won't have to dereference every time.

[christopher-johnson]

true. However, the prevailing trend for consumers of JSON-LD is to expect "tailored JSON" serializations directly. Ideally, "smart clients" (i.e. ones that are equipped with a JSON-LD processor) are definitely more sustainable and reduce the complexity of server-side implementations. Though these clients are more rare than common, at least for my use case, where they do not exist at all.

[ericprud]

[I'm not sure I understand this proposal so this may be a bit afield.] As I understand Accept-profile, a client is selecting amongst a variety of available (semantically equivalent) representations. If I were to pass an @context as a profile, I'd either be assuming that the server would recognize and be able to emit data which exactly conforms with that context or that the server would blindly serve it's usual contents but stick the passed context at the top. I believe the former use case is more easily met by having an identifier for the profile (rather than it's structure) and the latter doesn't interact with Accept-profile because it's not advising the server about the desired vocabulary or schema.

[RubenVerborgh]

I'd be inclined to say that it should always be an IRI. Then that IRI can be dereferenced, and result in different kinds of profile representations. Seems to me that Jena should adjust :wink:

[christopher-johnson]

OK. It is certainly easier to use an IRI. For reference, @acoburn has developed a method for a Jena IO impl to fetch @context profile (as IRI) from a whitelisted cache using an Accept header and then set JsonLdWriteContext before writing the JsonLD.

A similar IRI fetching mechanism could be used for JSON-LD framing, but unlike @context stable frame IRIs are less common. Framing is a use case for Accept-Schema where I see profile object injection as perhaps useful, since a frame allows "tailored serialization" based on a spec that may be divergent from a de facto schema (i.e. an IRI @context) for a document representation. Allowing arbitrary object frames, however, could just be an unnecessary server implementation headache... as a smart client could just as readily apply the frame itself.

Thank you for the feedback. I close the issue as "Resolved".