use standard for profile identification

[dret]

for the new dcat-ucr draft, maybe using an existing standard for identifying and signaling profiles would be useful? if so, https://tools.ietf.org/html/rfc6906 could be interesting.

[RubenVerborgh]

We will definitely consider existing standards; an overview of pros and cons we have identified can be seen here: https://www.slideshare.net/larsgsvensson/an-http-header-for-metadata-schema-negotiation/9

[dret]

On 2017-12-12 18:17, Ruben Verborgh wrote: We will definitely consider existing standards; an overview of pros and cons we have identified can be seen here: https://www.slideshare.net/larsgsvensson/an-http-header-for-metadata-schema-negotiation/9

nice presentation! seems like you have all the context you need... [[ detour: the presentation made me wonder: should RFC 6906 be updated to also register a preference per RFC 7240? i like the idea! it means media types do not have to support a profile media type parameter, and thus it better decouples profiles from media types. //cc @jasnell ]]

[larsgsvensson]

OK, here is a straw-man proposal for some text to refer to existing standards for identifying and signalling profiles in HTTP. @dret does this address your issue?

Existing standards for transporting profile information in HTTP headers

Using Accept/Content Type together with the profile parameter

The HTTP Accept and Content-Type header fields RFC 7231 allow a client to specify acceptable media types (Accept) and a server to indicate the media type of the payload (Content-Type). A media type registration can also specify an optional list of media type parameters. Some media type registrations (e. g. application/ld+json) have specified the use of a media type parameter named “profile” that could be used to signal the profile the payload of the message conforms to. Example:

GET /some/resource HTTP/1.1
Accept: text/turtle;q=0.9;profile="urn:example:profile-1",
		text/turtle;q=0.7;profile="urn:example:profile-2";

HTTP/1.1 200 OK
Content-Type: text/turtle;profile=<urn:example:profile-2>

During TPAC 2018 in Lyon, the DXWG had a longer discussion with the JSON-LD WG 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 the JSON-LD profiles "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 Content-Profile are to be used.

Using a Link-header with rel=”profile” (RFC 6906)

The HTTP Link header field RFC 8288 relates a web resource (Link Context) to a target resource (Link Target) by specifying the relation between the two resources. One of the relation types is “profile” as defined in RFC 6906. RFC 6906 defines a profile as “additional semantics that can be used to process a resource representation […] that do not alter the basic media type semantics,” and specifically states that “creators and users of profiles MAY define and manage them in a way that allows them to be used across media types,” so that the “profile” relation seems like a suitable way to transport information about acceptable profiles (request) and payload profile (response). Example:

HEAD /some/other/resource HTTP/1.1
Accept: text/turtle;q=0.9,application/rdf+xml;q=0.5
Link: <http://example.com/profile-1>; rel="profile"

HTTP/1.1 200 OK
Content-type: text/turtle
Link: <http://example.com/profile-1>; rel="profile"

There is, however, no possibility to convey quality information (q-values) using the “profile” relation.

Using the Prefer/Preference-Applied header fields (RFC 7240)

The http Prefer and Preference-Applied header fields RFC 7240 can be used to convey information about profile preferences. A client could use the Prefer header to tell the server about its preference for a payload conforming to a specific profile. If the server sends a Preference-Applied header field in the response, the client will know that the preference was honoured. Example:

GET /some/resource HTTP/1.1
Accept: text/turtle
Prefer: profile=<urn:example:schema>

HTTP/1.1 200 OK
Content-Type: text/turtle
Preference-Applied: profile=<urn:example:schema>

This approach has two disadvantages. The first is - as with the "Link" header, that there is no possibility to work with q-values. The second one is that the only way for a server to state that it ignored the preference stated by the client is to omit sending a "Preference-Applied" header. For the client - however - it is not clear if the "Preference-Applied" header is absent because the server did not honour the preference, or if it is because the server did not understand the "Prefer" header in the first place. This could be solved by making it mandatory to send a "Link: rel=profile" header when answering to a request with a "Prefer: profile=''" header in it. That solution requires that a client evaluates two different headers in order to find a response to its request for a specific profile, which would make client implementation more complicated.

If the text is OK, we also need to decide which document it goes into. It could either go into dc-prof-conneg (possibly in "related work") or into the IETF document. @RubenVerborgh what do you think?

[dret]

On 2019-02-28 16:59, Lars G. Svensson wrote: OK, here is a straw-man proposal for some text to refer to existing standards for identifying and signalling profiles in HTTP. @dret <https://github.com/dret> does this address your issue?

that reads nice and balanced. thanks for the proposal!