RFC 6906 defining "The 'profile' Link Relation Type" has been published a little while ago and I discussed it briefly when it was published. It has been picked up in a variety of places, and seeing where it is being used and how, it occurred to me that maybe some clarifications and explanations are in order. Like most link relation types, the type is defined in relatively fuzzy terms, in an attempt to make it generic enough to be reusable, but still specific enough so that there is some commonality in what it is used for.
The idea of profiles originates in the idea for safely evolving formats and services, as explained in more detail in "Patterns for Robust Extensibility". The assumption is to start from a meaningful core model, which is an extensible format or service. A profile then identifies one specific way of extending it, in the sense that the profile-identified extension still adheres to the core semantics, but adds constraints and/or extensions that go beyond it. One important aspect of profiles is that they must always be permissible to ignore the profile and just use the core semantics, and still something useful can happen.
One example used in RFC 6906 are podcasts, i.e. feeds for multimedia content. While you can look at these in a regular (i.e., non-podcast-aware) feed reader and get useful information out of them, a podcast-aware client can be more helpful and for example display available media metadata such as media running time.
An argument can be made (and has been made in a variety of ways) that because a podcast is a feed, no profile identification is necessary. Instead, if a client supports podcasts, then it can simply look at a feed and figure out whether it satisfies all the additional podcast constraints, and if it does, then it can be treated as a podcast, without being labeled as one. This is what in programming is called duck typing: If it walks like a duck and quacks like a duck, then in all likelihood it is a duck.
The duck typing argument can be applied to profiles: If a feed can be extended to carry all podcast-specific data, and still be treated as a regular feed, then why go through the additional effort of calling it a "podcast" and making it identifiable?
There is nothing inherently wrong with that argument, because in a well-designed ecosystem of a meaningful and extensible core format, and existing extensions to it, the evolution of producers and consumers is loosely coupled (that is the purpose of the whole enterprise after all), and everything can be treated at runtime as it is encountered.
So what are the arguments for going beyond that and to use profiles and related mechanisms? There are two main reasons:
- If applications encounter extensions, then how do they find out what those mean, if they do not have built-in knowledge of them? One approach to do this is by using a registry, where extensions can be registered along with some metadata. At the minimum (and often as the only thing), that metadata links to available documentation, so that any extension that is encountered can be traced back to the place where it is defined and explained. This usually is not done at runtime, but is a robust mechanism to be able to track the ongoing evolution of the extension ecosystem, and update applications as required.
- Going one step further: If you define a coherent and meaningful set of extensions, then you might want to give this set a name and thus make it identifiable. The reason for this is quite simple: If you want to have meaningful conversations about what to produce or consume, then you must be able to identify it. By creating a "property bag" and calling it "podcast" (and let's say also make it self-describing via a profile URI), you can talk about feeds being podcasts, for example in conversations where you can then say "I can deal with a variety of media feed formats, but prefer to use the podcast variety".
Essentially, only when you are able to call a duck a "duck" can you ask somebody to please hand you a duck. This might or might not be something that matters in your service scenario. But if it does, then going beyond the duck typing approach and create a self-describing label for a "duck" may be useful. And in that case, profiles as defined in RFC 6906 might be a useful way of doing this instead of having to reinvent that particular wheel.