2018-06-25 Note: for the current version of this white paper,  see http://usgin.github.io/usginspecs/ContentModelForLinks.htm

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.

rel -- URI from IANA rel vocabulary for consistency with IETF5988. This one is already embedded and is used in a WIDE variety of ways - 69 values from existing specs or proposals  (IANA, ESIP, ISO, RDFa, DataCite, DCT) are in Table 4 in the word doc; after AGU last week I could probably add 20 or 30 more. My opinion is that at this point this attribute is not very useful for interoperability except for the very general values suggested in the original Atom (RFC-4287) or WebLinking (RFC 5988) specs.

title -- free text to label link in GUI

protocol -- ftp, http, other. Default is http if attribute not specified (ietf registry at http://www.rfc-editor.org/rfcxx00.html). Equivalent to property in 19115 CI_OnlineResource/protocol. Because RPC-3986 mandates that “each URI begins with a scheme name”, this is probably unnecessary. Explicit inclusion might make some filter queries simpler ("link/@protocol='doi'" instead of "link/href like 'doi:*'").

serviceType -- URI that identifies a service protocol and version (one attribute or two?). ISO19119 property, needs registry of URIs for service specifications that is community agrees to use.

purpose -- analogous to ISO19115 CI_OnlineResource//function, specified by CI_OnlineFunctionCode (but need a better vocabulary, see attached doc)

outputscheme -- profile for content of message retrieved by href URL; may be WFS feature name, URI for xml schema or JSON scheme, other description of data structure and content? Need conventions, clear definition.

The word doc referenced in the text (link below) is a concept development document. The first three sections could be the basis for a DCP-3 to supersede DCP-2 (and incorporate DCP-1). The rest is supplemental information and background.

Files: 

Machine Actionable Links on the web 20111212