Describing Resources, the Web Way

there has been a long and often very passionate discussion around the question of how the linked data community can distinguish between identifiers that are referring to non-information resources, and those that refer to information resources. this distinction in itself is something created by the linked data community, and is a direct result of the design goal to be able to serve descriptions at the very same URIs that identify the described things. this design approach (trying to associate two different things with the same URI) has caused quite a bit of pain, and this resulted in a variety of attempts to handle it in a well-defined way, the last being the famed httpRange-14 resolution based on HTTP.

my biggest issues with both the (older) hash URI convention and the 303 redirect convention is that they unnecessarily interfere with rather basic fundamentals of web architecture, instead of simply using the mechanism that any other web-based application establishing associations between resources is using: establishing links. if there are two different things that need to be associated (the described resource and the description resource), then why not just link them, allowing clients to simply discover those links, and then act accordingly. if these are proper links, then there are three different ways how they can be used:

1. the links can be embedded in representations that support embedded links, and thus clients consuming those representations can find links from a described resource to a description and back (if both support embedded links).
2. if representations do not support embedded links, but the association is known to and/or managed by the server responding to the request, an HTTP Link header field can be used to convey the association. this is particularly convenient for representations not supporting embedded links, such as image formats.
3. since associations can also be treated as first-class citizens, it is possible to have a third-party service that associates described resources and description resources. this means of course that there also can be alternative/competing and even conflicting services claiming to provide those links, but that's just how the web is: decentralized and possibly containing conflicting information.

while there is a describedby link relation type that has been registered in the IANA link relation type registry by POWDER for quite a while, this was not even considered as a possible way to handle the linked data problem. so maybe the lack of the inverse described was the problem, because it certainly would be more useful to be able to represent both directions of the same association? for this reason, there now is an I-D for registering The 'describes' Link Relation Type. here's the abstract:

This specification defines the 'describes' link relation type that allows resource representations to indicate that they are describing another resource. In contexts where applications want to associate described resources and description resources, and want to build services based on these associations, the 'describes' link relation type provides the opposite direction of the 'describedby' link relation type, which already is a registered link relation type.

apart from the fact that this approach is more in line with existing web architecture, simply registering a new link relation, an added benefit is that it allows to layer descriptions, so that descriptions can in turn be described by other resources.

any feedback about this new link relation type is greatly appreciated, in particular any feedback about which linked data scenarios may not be appropriately supported by such an approach.