This use case is meant to demonstrate the use of HY_Features to link a catchment (12 digit hydrologic unit code (HUC12) watershed in this case) to the data representing it as well as the monitoring network associated with it. It serves as a general demonstration that could be used for a wide array of linked watershed information use cases.
The demo is available as an interactive map.
A water quality analyst needs to find hydrographic data and all stream flow and water quality data that is available for the waterhsed they are evaluating so they can develop a model of water quality for the watershed.
This demonstration is a basic test of linking a watershed to its realizations and monitoring locations in the watershed. In this case, monitoring locations are linked to the watershed as a monitoring network realization of the watershed rather than linking them to a hydrologic location at the outlet of the watershed or linked to the waterbodies in the watershed.
The HUC12 Oservations demo is a simple interactive leaflet map of watershed hydrography and linked observational data locations.
The data index for the huc12obs demo can be seen in github here.
The primary entry point to the data is the non-spatial catchment that can be seen in this json-ld document.
The catchment is linked to three features, a flowline network, and a boundary polygon, and a hydrometric network.
Navigate to the use case data home on github and go to the
usgs_wqp_huc12obs.tsv
.tsv
or .json files to see the data
that is in the demo ELFIE json-ld documents such as this one.
Other tsv and json files in the use case home were used to construct the linked data documents.
This collection of files is accessed with R code that builds the map in the data visualization that can be seen here.
This demonstration showed that the linked data graph views defined for ELFIE will satisfy technical requirements of the use cases. Parsing and working with the content was straight forward and building a simple interactive geospatial visual that satisfied the use case was not challenging. From a pragmatic point of view, this approach is satisfactory, however, significant work remains to enable general implementation on the internet between multiple data providers. The major gap (which was known and out of scope for ELFIE) was the lack of published feature identifiers and a linked-data baseline to build on. On this front, a clear next step is for data providers to establish URIs for features and to choose the default behavior of a linked-data URI broker.
HY_Features feature types and relations encoded in JSON-LD were used successfully and showed promise for use in the way the schema.org and other linked data types and relations are used. Similar to feature URIs, canonical feature type and relation URIs and best practices for dereferencing bahavior for them is needed in order to move forward using HY_Features (an other domain feature models) in this way. Apart from HY_features, even when published, the response from a given relation or feature URI is rarely consistant.
For example:
curl https://schema.org/GeoCoordinates
Accept
headers curl --header "Accept: application/ld+json" -L https://schema.org/GeoCoordinates
curl https://schema.org/GeoCoordinates.jsonld
curl http://www.w3.org/2004/02/skos/core#related
Accept
headers curl --header "Accept: application/rdf+xml" -L http://www.w3.org/2004/02/skos/core#related
curl --header "Accept: application/ld+json" -L http://www.w3.org/2004/02/skos/core#related
While the list above is not at all exhaustive, it demonstrates the diversity in completion and diversity of core domain-agnostic resources that are required to satisfy use cases like the one illustrated here.