Considerations for seamlessly add services or data within QGIS workflows #2
Description
My approach to the problem has been thinking about this from the point of view of a metadata record.
In ISO 19115, a resource (dataset in this case) may be accessible through a variety of distributions (e.g. click on the [third entry here](http://search.usgin.org/#Geology United States); in the metadata this becomes a set of CI_Online resource elements
In an Atom feed the same thing would be represented as a collection of atom:links (e.g. see ESIP-discovery DCP-8
There's plenty of other situations where this issue arises. Its essentially the problem that must be addressed to implement HATEOS in REST. The software client needs to be able to inspect a bunch of links and determine which one to use and get the necessary information to formulate a valid request.
In order to do this, there are varying amounts of information that must be conveyed to the client depending on the nature of the link. For a URL that gets a web page, its simple. For services piggybacked on http (like OGC services), you need to know the service protocol (i.e. the ISO19119 ServiceType; specifies the syntax for requests), and typically something about the encoding of message content in service requests and responses. This encoding will involve some kind of syntax (e.g. JSON, XML, NetCDF...), and more than likely some kind of profile on that syntax (INSPIRE ISO 19139 XML, CSDGM biology XML, GeoSciML v3, WaterML v2), in some cases some specific parameters need to be known to get the request correct, e.g. the layer name in a WMS, a FeatureType in a WFS, or some subsetting query string for OpenDAP. This can't be done with just one property associated with the link. I think its worth separating these various facets into separate link properties. This is the motivation for my Content model for hypermedia affordances proposal. Please have a read.