I spent some time researching this issue in the context of some other projects I've been following or involved in (OWS context Standards Working Group, energy industry ISO19115 metadata profile, and USGS CGI Web Application Integration Framework group). I would like to see this considered in a larger context to come up with a solution that can be used in these various contexts, because it's essentially the same problem.
Here' s the gist of the proposal for link attributes outlined in the attached doc:
href -- the link URL
type -- MIME type of response. Specifies encoding and optionally the native software application environment. We're sort of stuck with this because of existing usage. One big question is how much of serviceType, puprpose, and outputScheme it makes sense to conflate in the MIME type. I favor keeping the MIME type limited to low-level file formatting--to answer the question 'what software can read this file in a useful way' Understanding the content and intention of a document or the interface to a service should be specified by separate properties.
Here are a few screenshots to give a taste of what it is like to use our new Django app to manage a set of URI redirections:
For any URI-Scheme: Basically, the Django app allows you to control a listing of MIME Media Types, and Rewrite rules.
USGIN URI-Scheme: The same basic structure, but the USGIN-specific app allows you to control a listing of Name Authorities and Resource Types, as described in this post.
Listing of Rewrite Rules: A nice overview of what rewrite rules you have in place, and a mechanism for searching for the one you might need to adjust.
Creation of a Rewrite Rule:
A common problem we run into is the unique identification of resources. This is a very broad statement because it represents a very broad problem. We have identification schemes for all kinds of things: people have names, web pages have URLs, books have ISBN numbers, etc. For the USGIN system to work smoothly, we need an identification scheme for resources that are part of the network. In USGIN we use Universal Resource Identifiers (URIs) which follow a specific format. For more information about the format, and for more background, see this post on lab.usgin.org.
Once we have this identification scheme built, it is important that the URIs can be dereferenced, or in other words that they are resolvable. We would like a user to be able to put the URI of a particular feature into the address bar of their web browser, push enter, and be presented with some sort of representation of their resource of interest. This is the niche that our Django-based redirection engine it trying to fill.