On Profiles

now that The profile Link Relation Type has been published as RFC 6906 (and is properly registered in IANA's link relation registry), this is a good moment to explain what profiles can be used for, how they should be used (and shouldn't be used), and which kinds of scenarios might be most interesting to look at for using the mechanism.

Bundling Functionality

one way of describing profiles is to look at them as capability bundles (i am just making this term up here), which are supposed to identify a specific way in which an extensible and open data format is used to accomplish a more specialized goal. specifically, the idea of a profile is not to just identify a single extension element or attribute.

instead, consider podcasts used as one example in the RFC. or, you could also think of OPDS, another feed-based content distribution architecture. in both cases, the specifications are using feeds as their foundation, i.e. you can read podcasts and OPDS feeds with a generic feed reader. this satisfies one of the requirements for scenarios that are a good fit for profiles: it should be possible to have meaningful applications using the services without knowing/using the profile. specifically, for this reason it would not be a proper use of profiles to say that podcasts or OPDS are profiles of RDF or XML, because you cannot meaningfully consume podcasts or OPDS just based on on parsing RDF or XML. you need knowledge of the concept of feeds to have something that minimally works (but of course a generic feed reader will not support any of the features that are specific to podcasts or OPDS).

the second requirement for using profiles in a useful way is that profiles should identify meaningful and self-contained capability bundles. both is true for podcasts and OPDS, which start from plain feeds and then add features and capabilities to them in order to address a specific set of use cases. don't give in to the temptation to make things too fine-granular and turn every single property/feature into a profile. this would lead to an inflation of profiles, and make working with them awkward and unnecessarily complicated.

The OO View

apart from the capability bundles concept, another useful way of thinking of them is in terms of the OO concept of a subclass. instances of subclasses can be handled in exactly the same way as instances of their superclass, but they have additional constraints, and/or have additional behavior. the same can be said of resources using profiles: they can be used according to their profile (i.e., as an instance of the subclass), or they can be used according to their media type (i.e., as an instance of their superclass), ignoring the fact that they follow a profile.

taking this view even further, you could say that in that OO view each superclass can have multiple subclasses (i.e., it is possible for a resource to specify more than one profile), but subclasses only have one superclass (because there onle is one media type in which a profile is used).

however, since the notion of a profile is fairly open, there is nothing that keeps profile designers from saying that their profile can be used with different media types. one obvious example could be RDF, which is an abstract model, and has a number of possible serializations (all identified by different media types). a profile could be based on RDF's abstract model, i.e. not be specific for any specific serialization, and then could be identified in different RDF media types through the same profile URI, making sure that the profile can be recognized in a way that is indepedent from the specific serialization.

Profile URIs

as defined by the RFC, profile URIs are purely identifiers: clients are expected to recognize them when they are used with profile-typed links or as profile media type parameters, and then deduce from that that a resource follows a certain profile. this means that profile URIs never have to be dereferenced, and thus could also use non-referencable URI schemes such as URNs.

however, as with other identifier-style URIs (XML namespace URIs come to mind), it is a good idea to use referencable HTTP URIs, and provide some documentation (or other helpful resources) at that URI. also, when choosing the profile URI, it might be a good idea to stick to the naming advice from the XML Namespaces section on Comparing URI References: Because of the risk of confusion between URIs that would be equivalent if dereferenced, the use of %-escaped characters in [...] names is strongly discouraged.

providing documentation at a profile URI is a good idea, but there is no standard what to provide there. it probably makes sense to follow the pattern of XML namespace URI pages such as the XSLT namespace, which links to a variety of helpful resources, so that developers accessing the URI (hopefully) find what they are looking for.

What Now?

now that profiles can officially be used in both content and HTTP, it would be great to see services taking advantage of them. media types are not such a great design for what we're doing on the web today and one day could be redesigned to better fit today's needs. but they are one of the most fundamental aspects of not only the web, but many other internet technologies (such as email) as well, so it's unlikely that they will change radically anytime soon.

the idea of profiles is simple and fits into the architecture and limitations of today's standards and tooling. the hope is that by using profiles, resources on the web will become a little more self-describing, and it will be easier to properly design scenarios where services are extending others, but still want to maintain a working relationship with the service ecosystem they are building on.

personally, adding profile support to atom is the next step in the grand plan, but other than that, hopefully other representations and media types will start supporting profiles as well. it's very simple: mint a URI, ideally provide helpful information at that URI, and then start using this profile URI in your representations and maybe in media types as well. if you have any questions about how to best do this for a specific representation and/or media type, please feel free to comment or send me an email.