Profile negotiaton: profile token in Accept-Profile header

[steve-chavez]

In https://www.w3.org/TR/dx-prof-conneg/#profileid it's mentioned that:

A client requesting the representation of a resource conforming to a data profile MUST identify the resource by a Uniform Resource Identifier (URI) [RFC3986] and MUST identify the profile either by a URI or a token.

There is an example in https://www.w3.org/TR/dx-prof-conneg/#getresourcebyprofile on how to make a request with a token profile in the UR(with the _profile query param):

GET http://example.com/path/to/resource/a?_profile=prof-01&_mediatype=text/turtle.

But there isn't an example with a profile token in an Accept-Profile header.

Would a request like the following be valid for profile negotiation?

# A request for resource a according to Profile x is made
GET /resource/a HTTP/1.1
Accept-Profile: x

(Granted that token mappings are provided as specified in https://www.w3.org/TR/dx-prof-conneg/#http-tokens)

I'm trying to implement content negotiation by profile on postgrest.org.

Would appreciate any clarification/guidance on this. Thank you.

[rob-metalinkage]

The expectation was that canonical URIs were preferred, but realistically URL encoding URIs as query string arguments is ugly and counter to typical practice for systems that already have some equivalent concept of alternative profiles that can be chosen.

There are two things we need to consider: 1 - whether we should allow tokens in Accept-Profile values 2 - how to make the spec clearer whichever option we choose.

Lets hears pros and cons from people about allowing tokens in the Accept header.

(PS its no great drama for me in the implementation to allow it - so I'm agnostic, other than I feel there must be URIs for profiles accessible otherwise there is no interoperability benefit at the data level - and we are a Data Exchange WG :-) )

[nicholascar]

Hi @steve-chavez & @rob-metalinkage the Dataset Exchange WG has just split repositories for DCAT, ConnegP and so on so I've transferred this issue to the ConnegP repo from the DCAT one. Please continue all ConnegP work here!

[steve-chavez]

@nicholascar Cool. Thank you.

@rob-metalinkage I would be in favor of allowing the token in the header. It makes the header easier to type and thus makes APIs easier to explore.

In the document it's mentioned that one of the reasons of qsa-uri is to allow human-actionable content negotiation. I'd like to add that API explorer tools(such as Postman, Insomnia, etc.), make modifying headers human-actionable as well. Setting headers is something that Open Data users and developers are used to when exploring APIs.

Regarding interoperability, I agree, I also intend to provide the token mappings.

[larsgsvensson]

(also pinging @RubenVerborgh and @hvdsomp as co-authors of the IETF draft)

But there isn't an example with a profile token in an Accept-Profile header.

When writing the current IETF draft specification of the headers Accept-Profile and Content-Profile my co-authors and I have attempted to minimise the coupling of URIs with other mechanisms of profile identification (cf. also the discussion on the use of "token" attributes in the Link header). I personally am not very inclined to allow for profile tokens in the http headers. IMO that will be a source of confusion since different services might map the same profile URI to different tokens.