Open smrgeoinfo opened 10 years ago
rsignell-usgs
commented
10 years ago @smrazgs, I read the proposal. I learned a lot, and also learned I have a lot to learn. ;-) Can all this "extra" stuff just be tacked onto the end of the URNs of the type that Tom listed here? https://github.com/OSGeo/Cat-Interop/blob/master/link_types.csv In other words, can we just go ahead with that list (or a URL version) as a first step?
smrgeoinfo
commented
10 years ago It really depends on what you're trying to do. One route is certainly to create long service type URIs (or MIME types?) that convey service protocol, message encoding, and interchange format/profile, but I prefer the idea of keeping the semantics clear by using explicit key value pairs.
/*openDap endpoint
<dct:references>{"link":"http://test.opendap.org:80/opendap/data/nc/ber-2002-10-01.nc.nc",
"rel":"download",
"title":"example NetCDF file retrieval via OpenDAP",
"type":"application/x-netcdf",
"overlayAPI":"OpenDAP",
"profile":"http://test.opendap.org:80/opendap/data/nc/ber-2002-10-01.nc.dds"}
</dct:references>
/* wfs capabilities
<dct:references>{"link":"http://kgs.uky.edu/arcgis/services/aasggeothermal/ARSeismicHypocenters/MapServer/WFSServer?request=GetCapabilities",
"rel":"documentation",
"title":"Get the capabilities document for seismic event hypocenter WFS service",
"type":"application/xml",
"overlayAPI":"OGC:WFS"}
</dct:references>
tomkralidis
commented
10 years ago @smrazgs good points, given your comments at https://github.com/geopython/pycsw/wiki/Geonode-notes#wiki-alternate-proposal.
Having said this, the above works! Comments:
dct:references/@scheme as a given link type and go with JSON as the element content? This will help decipher things via @scheme before committing to processing the element content JSON. Thoughts?Updated example:
<dct:references scheme="http://www.osgeo.org/vocab/service/wfs/1.1.0">
{
"href":"http://kgs.uky.edu/arcgis/services/aasggeothermal/ARSeismicHypocenters/MapServer/WFSServer",
"title":"Get the capabilities document for seismic event hypocenter WFS service",
"type":"simple",
}
</dct:references>Then again, how would (could?) we encode, say, a WMS layer here? Where could we put the layer name, as a means to bind this without the Capabilities roundtrip (like https://github.com/geopython/pycsw/wiki/Geonode-notes#wiki-proposal).
The two main issues I see are:
@scheme to provide the link type. I strongly propose to useCI_OnlineResource modelsmrgeoinfo
commented
10 years ago I think it would scale better to allow other approaches to the content encoding inside the dct:references if the @scheme attribute is about the element content scheme, and all the information about the reference (link) is in the content of the element.
Xlink only provides a type property, the 'metadata as hypermediaApp' doc I've pointed to discusses why this is insufficient (your question about WMS layers is an example). Also in that doc is a mapping between the link attribute scheme I've proposed and xlink and CI_online resource, as well as various other approaches I could find. I've tried to preserve the property name and semantics where it works (e.g. title, type). What to name the key for the actual URL value is up in the air--href? link? linkage? .... All have been used. I've added some JSON examples of various kinds of real service links in the link property proposal
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.