Enable the ability to negotiate the data profile via http, similar to the negotiation of data formats today. [ID30] (5.30)

[nicholascar]

Entered from Google Doc

[aisaac]

Oct 24 2018: changed metadata to data

[nicholascar]

I think this is more a Profile Guidance issue than it is a Profile Conneg one. At the conneg level, there's no distinction (for clients and servers) between data & metadata profiling but there certainly is/will be in Guidance.

[kcoyle]

@nicholascar I read this as the basic use case for content negotiation - negotiate (via http) based on profile, and I assumed that "data formats" = mime types.

[aisaac]

I think I would second @kcoyle 's reading. In the original use case (Standard APIs for metadata profile negotiation [ID30]) the idea is that (DCAT-level) metadata about datasets can be obtained in different profiles. Which sounds like the basic motivation for negotiation by profile.

[nicholascar]

OK, accepting the 'base case', do we need to do anything here then just yet? Do we perhaps indicate that this is a requirement on Profile Guidance and that Profile Guidance delegates the details to the Profile Conneg doc?

[aisaac]

@nicholascar this sounds like a good approach. In general I like the idea of the Profile Guidance serving as entry points to the other Profiles documents.

[nicholascar]

De-tagging as profile-negotiation as dealt with by its point of view

[nicholascar]

Re-tagged with profile-negotiation so the issue can still be found in relation to Conneg in perpetuity

[nicholascar]

Closing after listing in plenary 2019-09-03 + 3-day wait period.

[kcoyle]

@nicholascar how was it dealt with in conneg? You need to record that in the closing comment.

[nicholascar]

@kcoyle and for all other readers:

The "ability to negotiate the data profile via http" of internet resources is the core concern of Content Negotiation by Profile. The approach is "similar to the negotiation of data formats today" in that where a content request by format (Media Type) is implemented with the requester including the HTTP header Accept in an HTTP request, a request for content via its profile conformance is implemented with clients supplying an Accept-Profile header. The response will try to honour that and indicate any profiles the response's resource representation conform to with a Content-Profile header, just as an Accept header would receive a Content-Type response.

This mechanism is detailed in the Content Negotiation by Profile Editors Draft and the Second Public Working Draft and is essentially unchanged between the two, although examples and other supporting information have been added.

Note that the Content Negotiation by Profile documents also describe another approach to negotiate for resources by data profile other than via HTTP: via Query String Arguments.