Re: high-level explanation of profile-based content negotiation

This all seems very sensible to me. +1 for the general mechanism.

Got a couple of queries...

1) With polymorphism of profiles (profiles may be deeply hierarchical, and
multiple profiles may be supported) the client may not be able to enumerate
all profiles it supports - will there be support for wildcards and
superclasses, or other ideas for handling this?
2) There are many forms of content - for example map projection for spatial
data, and certainly the level of detail in geometric properties, which will
have the same role and data-type. Is the content negotiation going to be
extensible across aspects, and are those aspects defined by an authority
register? (and by extension will existing dimensions of conneg - mime type
and language be also supported in equilvalent form by a more general
mechanism)
3) is there a means to discover supported profiles (e.g. http HEAD
accepting  *)
4)  Can URL parameters be allowed to override the header (agent)
negotiation - as per language negotiation practices?

Cheers
Rob

On 19 Jun 2017 1:56 PM, "Ruben Verborgh" <Ruben.Verborgh@ugent.be> wrote:

> Dear all,
>
> Given the other discussions on profiles,
> it might be good to explain on a high level how
> Lars, Herbert and myself see the IETF RFC
> regarding profile negotiation we are editing.
>
>
> SCOPE
> For the RFC, a profile is a set of structural and/or
> semantic constraints that can be imposed on a document.
> It provides extra assumptions/interpretations
> that a recipient is allowed to make.
> A document can conform to one or multiple profiles.
>
>
> IDENTIFICATION
> A profile will be identified by an IRI.
> This IRI can be dereferenceable,
> so something meaningful is returned
> when clients follow that IRI.
> We do not specify what is returned in general,
> but can do so for specific cases within this working group.
>
>
> NEGOTIATION
> On a high level, negotiation works as follows:
> – A client indicates the profiles it is compatible with
>    by using their IRIs.
> – A server aims to return a response
>    that maximally uses these preferences,
>    indicating which profiles the response conforms to.
>
>
> As you can see, this mechanism is very generic.
> This also means it is compatible with any more specific profile,
> for instance, such as a DCAT application profile
> (whatever this might become).
>
> However, at the same time, we see no reason
> to tie profile negotiation specifically to DCAT.
> In fact, tying it to DCAT would reduce
> the number of applicable use cases
> and hence the possible uptake.
>
> Best,
>
> Ruben
>