Use `Accept-Profile` header instead of `JsonLdContext` ?

[srosset81]

I came accross this article from Ruben Verborgh: https://ruben.verborgh.org/articles/fine-grained-content-negotiation/

It advocates for a new Accept-Profile header, which could be the reverse solution of the existing MIME-type/profile combination used in the ActivityStreams spec: https://rubenverborgh.github.io/SDSVoc-2016/#activity-streams

Because Activity Streams 2.0 can be considered a restricted profile of JSON-LD, Implementations should consider the application/ld+json; profile="https://www.w3.org/ns/activitystreams" media type as being equivalent to application/activity+json. https://www.w3.org/TR/activitystreams-core/#media-type

There is a whole WG working on this notion of profile: https://www.w3.org/TR/dx-prof-conneg/

This is distinct from negotiating by Media Type or Language: a profile may specify the content of information returned, which may be a subset of the information the responding server has about the requested resource, and may be structured in a specific way to meet interoperability requirements of a community of practice.

The last part of the sentence is close to what would be required for JSON-LD context.

But I still struggle to understand what they mean by profile. I'm especially wondering if it could fit with custom contexts. The current JsonLdContext header accept JSON-stringified arrays or objects.

[srosset81]

https://datatracker.ietf.org/doc/html/rfc6906#section-3

[Laurin-W]

From reading the spec https://www.w3.org/TR/dx-prof-conneg/ (I didn't quite step through the vocabulary linked from there) , there does not seem to be a way to ask for json-ld to be framed in a specific way (which seems a bit surprising to me), is there? From a brief overview I only saw that the vocabulary is to support references to e.g. shex or shacl validators.

For our use-cases right now, something like a special profile URI type might be helpful, since the notion of profile is rather vague anyways?

GET /path/to/resource HTTP/2
Host: example.org
Accept: application/ld+json;profile="urn:json-ld-frame:path-to-ld-frame"

Or in analogy to activity streams, we might even just try to use the profile URI as the frame object? That's probably the most compatible way right now and similar to the way we do it already (unless the https://www.w3.org/ns/activitystreams.jsonld does not suffice to frame an activitystreams object correctly?).

To me, it looks like the spec might be promising at some point but if it is only about requesting data to be framed correctly, this might be like using a sledgehammer to crack a nut.

[Laurin-W]

Reading:

During 2018, DXWG members had a longer discussion with the JSON-LD WG at the annual forum TPAC in Lyon, France and it was concluded that the "profile” parameter in the Accept and Content-Type headers should be seen to convey profiles that are specific to the Media Type, such as JSON-LD's "expanded" (http://www.w3.org/ns/json-ld#expanded) or "flattened" (http://www.w3.org/ns/json-ld#flattened). In order to signal the use of Media Type-independent profiles, the http header fields Accept-Profile and Link: <...>; rel="profile" are to be used.

, the Accept-Profile header seems to be not what we are looking for, since the JsonLdContext is content-type specific.

[srosset81]

Thanks for the research. Looks like the Accept-Profile header is not appropriate indeed. Since no standard seem to exist (yet), it's maybe better to keep our implementation of JsonLdContext header for the moment...