Differentiate profile parameter and Accept-Profile header

[nicholascar]

From Gregg Kellogg via the W3C JSON-LD CG:

There certainly is a conversation on the difference between the profile parameter, and Accept-Profile header, which looks like a good direction for you, IMHO. It would be useful to be able to content-negotiate over this; an opaque frame URL is not helpful, as it would be challenging to know what it meant if it wasn’t registered. We came down on the use of the profile parameter to specify registered profiles, that may imply specific contexts or frames to be used as part of the profile specification. Of course, the profile URI could, itself, be used to returned the context or frame.

[larsgsvensson]

Do we need a separate issue for this or can it all be handled in #663?

[nicholascar]

Could do, let's decide that at this week's meeting! I just erred on the side of over-creating Issues so nothing from reviewers was lost.

[aisaac]

I would say this is a slightly different issue from #663 as it includes elements from the discussion we had with the JSON-LD group during the F2F in Lyon (https://www.w3.org/2018/10/26-dxwg-minutes#x06) during which we've tried to separate "mediatype-profiles" from "DXWG-profiles". (#261 )

[nicholascar]

Decided in today's Conneg subgroup meeting that this and #663 are separate concerns and thus they will remain as separate Issues.

[nicholascar]

Subgroup meeting 2019-02-14 noted that it looks like there's no crossover between JSON-LD (syntax) profiles & Profile Neg profiles therefore likely to resolve this with a note in the doc about difference.

[larsgsvensson]

What I took home from the meeting in Lyon was that the profile parameter used with the Accept header is used for profiles (or profile URIs) that are tied to specific media types, such as "flattened" (http://www.w3.org/ns/json-ld#flattened) or "compacted" (http://www.w3.org/ns/json-ld#compacted) in JSON-LD. Accept-Profile and Content-Profile are used when the profile is media-type independent, e. g. application profiles defining which RDFS classes and properties are used in a document that can be returned in Turtle, N-Triples or JSON-LD.
This way an http request can contain both a profile parameter in the Accept header and an Accept-Profile header field specifying the application profile of the payload:

GET /a/resource HTTP/1.1
Accept: application/ld+json;profile="http://www.w3.org/ns/json-ld#compacted"
Accept-Profile: urn:example:profile1

---------------------
HTTP/1.1 200 OK
Content-Type: application/ld+json;profile="http://www.w3.org/ns/json-ld#compacted"
Content-Profile: urn:example:1

{
    "@context" : "https://example.org/context" ,
    {
        "title" : "A document"
    }
}

@gkellogg scripsit:

Of course, the profile URI could, itself, be used to returned the context or frame.

Yes, in an ideal DXWG world, the profile URI (the one used in Accept-Profile/Content-Profile) is an http URI that resolves to a profile description using content-negotiation to serve html, RDF etc., where the RDF representation uses the profile ontology ^H^H vocabulary and all the best practices from the profile guidance document.

Does this address your feedback, @gkellogg?

[gkellogg]

Yes, looks good!

[larsgsvensson]

OK, thanks @gkellogg. I wrote some text in #45 that is now part of a PR.

[larsgsvensson]

The text I wrote about this in #45 has now been merged so I think we can close this issue

[larsgsvensson]

Closed in cneg meeting 2019-03-13