RFC 6906 defines the profile relation (rel="profile"). (This document) defines the keyword profile so that we can write Link: rel="self"; profile="<urn:example:something>". There are some examples of that in the examples section. Obviously we need some more text to get this sorted out and I expected that to be part of the W3C rec we're to write, but probably we need some more text in the RFC, too.

I'm not convinced about the necessity of such a new keyword instead of a relationship. Also see #11.

My point is that with the "profile" keyword we can supply more metadata about alternate resources, e. g.

Link: rel="self";type="text/turtle";profile="<urn:example:profile-1">,
    <http://example.org/something-1.rdf>; rel="alternate"; type="application/rdf+xml"; profile="<urn:example:profile-1>",
    <http://example.org/something-2.rdf>; rel="alternate"; type="application/rdf+xml"; profile="<urn:example:profile-2>",
    <http://example.org/something-2.ttl"; rel="alternate"; type="text/turtle"; profile="<urn:example:profile-2>

I don't know how to do that with RFC 6906

With RFC6906:

Link: <urn:example:profile-1>; rel=profile; type="type="text/turtle",
      <http://example.org/something-1.rdf>; rel="alternate"; type="application/rdf+xml",
      <http://example.org/something-2.rdf>; rel="alternate"; type="application/rdf+xml",
      <http://example.org/something-2.ttl"; rel="alternate"; type="text/turtle",
      <urn:example:profile-1>; rel=profile; anchor=<http://example.org/something-1.rdf>,
      <urn:example:profile-2>; rel=profile; anchor=<http://example.org/something-2.rdf>,
      <urn:example:profile-2>; rel=profile; anchor=<http://example.org/something-2.ttl>

OK, thanks. Not as straightforward but reuses existing solutions. Do you have a feeling which solution is easier to implement (for the consuming application)?

The custom ;profile= seems easier of course, but the question is whether the difference is worthwhile breaking with the rel= paradigm. (The good news is that RFC 5988 Web Linking allows such extensions.) Quick analysis below.

Reusing rel=profile

Pro

• reuse of RFC6906, so existing clients remain compatible
• works like regular rel=… things

Con

• specifying both media type and profile on an alternate representation requires an extra Link

Creating profile=

Pro

• single Link to specify both media type and profile on alternate representations

Con

• not reusing RFC6906

(Incomplete, but this already shows things depend on usage of RFC6906.)

Yes, very good questions and good perspectives. A conference call to collect the different views, pros and cons would a good path forward.

Having revisited this thread I'm still not sure how to proceed. I know, though, that we've got a spec to write and even if DXWG is working on a six month extension we need to solve this issue since we point implementers to the Link header as one possibility to tell clients which profiles a server can serve
Looking at Ruben's proposal with RFC 6906 I note a further con: it's much more verbose (31% more characters compared to the profile parameter. Don't know if that's an issue...
Mark Nottingham's "Link hint" has been bumped to -01 but I'm not sure how we could use that to implement profiles.
My vote is to define the profile parameter in our RFC. @RubenVerborgh , @hvdsomp what do you say?

I am really not in favor of the "profile" approach despite the advantages mentioned above. As @RubenVerborgh has shown, everything can be expressed without needing additional functionality; it can be done with Links and rels. I am very much in favor of sticking to that approach; it requires no additional intelligence by agents that consume links.

I'm, not sure that the RFC 6906 can be made to work if URIs support content negotiation - they only seem to work if the explicit resource referenced is unique for a mime type

so what is the "anchor" - its not the profile in that example, because its not the alternate view of the profile we are trying to advertise - and the actual profile being offered isnt given, If it is the ID of the profile the example is wrong - its not the profile that has the alternate - its the original resource, but the line:

http://example.org/something-1.rdf; rel="alternate"; type="application/rdf+xml",

doesnt seem to read that way - and doesnt use a profile ID - it seesm to be referencing the resource that conforms to a profile without ever saying what profile it is...

Interesting point. And apologies in advance, this response became longer than I thought it would ;-)

I do think the approach can be made to work when URIs support content negotiation. But content for different profiles needs to be made available at different URIs.

Consider this variation on @RubenVerborgh's example that does not have explicit file type extensions:

Assume that http://example.org/something-1 is the resource that provides the below Link header in response to HEAD/GET and that it responds in text/turtle:

Content-Type: text/turtle
Link: <urn:example:profile-1>; rel=profile; type="type="text/turtle",
      <http://example.org/something-1>; rel="alternate"; type="application/rdf+xml",
      <http://example.org/something-2>; rel="alternate"; type="application/rdf+xml",
      <http://example.org/something-2"; rel="alternate"; type="text/turtle",
      <urn:example:profile-1>; rel=profile; anchor=<http://example.org/something-1>,
      <urn:example:profile-2>; rel=profile; anchor=<http://example.org/something-2>

Let's break it down:

=> <urn:example:profile-1>; rel=profile; type="type="text/turtle"

says that http://example.org/something-1 (link context is implicit) adheres to profile-1. It also says that profile-1 is expressed as text/turtle. I am not sure that was @RubenVerborgh's intention. Attributes (e.g. type) pertain to link targets and in this case profile-1 is the link target. Maybe the intention was just <urn:example:profile-1>; rel=profile.

=> <http://example.org/something-1>; rel="alternate"; type="application/rdf+xml" and <urn:example:profile-1>; rel=profile; anchor=<http://example.org/something-1>

says that there's an alternate representation of http://example.org/something-1 (link context is implicit) at http://example.org/something-1 and that alternate is in application/rdf+xml. This info can be used to do content negotiation with http://example.org/something-1 to get the application/rdf+xml version. It also says that http://example.org/something-1 adheres to profile-1. That is actually redundant; we knew that already from the first entry in the Link header.

=> <http://example.org/something-2>; rel="alternate"; type="application/rdf+xml" and <urn:example:profile-2>; rel=profile; anchor=<http://example.org/something-2>

says that there's an alternate representation of http://example.org/something-1 (link context is implicit) at http://example.org/something-2 and that alternate is in application/rdf+xml. This info can be used to do content negotiation with http://example.org/something-2 to get the application/rdf+xml version. It also says that http://example.org/something-2 adheres to profile-2.

=> <http://example.org/something-2>; rel="alternate"; type="text/turtle" and <urn:example:profile-2>; rel=profile; anchor=<http://example.org/something-2>

says that there's an alternate representation of http://example.org/something-1 (link context is implicit) at http://example.org/something-2 and that alternate is in text/turtle. This info can be used to do content negotiation with http://example.org/something-2 to get the text/turtle version. It also says that http://example.org/something-2 adheres to profile-2.

Given, the above, the Link header can be simplified to:

Content-Type: text/turtle
Link: <urn:example:profile-1>; rel=profile,
      <http://example.org/something-1>; rel="alternate"; type="application/rdf+xml",
      <http://example.org/something-2>; rel="alternate"; type="application/rdf+xml",
      <http://example.org/something-2"; rel="alternate"; type="text/turtle",
      <urn:example:profile-2>; rel=profile; anchor=<http://example.org/something-2>

As long as all serializations for a given profile are made available at a dedicated URI (i.e. everything for profile-1 at something-1 ; everything for profile-2 at something-2), an agent can unambiguously figure out which profile/serialization combinations are available and how to get them through content negotiation.

If we were to serve everything at the same URI, we would get something like:

Content-Type: text/turtle
Link: <urn:example:profile-1>; rel=profile,
      <urn:example:profile-2>; rel=profile,
      <http://example.org/something-1>; rel="alternate"; type="application/rdf+xml",
      <http://example.org/something-1>"; rel="alternate"; type="text/turtle"

This says that there are two profiles and two serializations available via http://example.org/something-1. What an agent can't figure out from this info is which serializations are available for which profile. It does give the agent enough info to try content and profile negotiation. However, the agent does not know in advance whether each combination will yield the intended response.

I don't have a strong opinion either way. I think there's benefit to reusing RFC6906, I prefer the already extensible rel mechanism as opposed to a new mechanism, but I'm not opposed.

It also says that profile-1 is expressed as text/turtle. I am not sure that was @RubenVerborgh's intention.

It was not indeed.

i think my other comment was wrong - because i didnt interpret the new "anchor" rel...

however: "I do think the approach can be made to work when URIs support content negotiation. But content for different profiles needs to be made available at different URIs." - the whole point of negotatition by profile is that we dont need to have multiple URIs in the wild to support a range of alternative views on the same "thing" - so its not something we can ignore.

so - Herbert's last example is pertinent - as is the comment "What an agent can't figure out from this info is which serializations are available for which profile"

at this stage we still seem to need the "profile" attribute which carries the same semantics as a rel=profile - the rel=profile talks about the current representation, the attribute talks about linked representations.

at this stage we still seem to need the "profile" attribute which carries the same semantics as a rel=profile - the rel=profile talks about the current representation, the attribute talks about linked representations.

Good argument indeed. I'm now inclined to support profile=.

Three comments on the reactions to my posting above:

1. The question that arises from the discussion is whether the list of profile/serialization combinations has to be complete/unambiguous or whether good enough hints will do. If the former, then a profile attribute is most likely essential.
2. If the choice is for a profile attribute, then I feel rather strongly that it has to be defined generically, i.e. not only in the context of this work. Hence, I re-up my suggestion to see whether an attribute of this nature could be made part of the initial registry for @mnot's Link Hints.
3. Note that it is not uncommon in content negotiation to serve variants at different URIs. That's 302-style content negotiation. So, I'm not too worried about @rob-metalinkage's comment with that regard.