Summary of HDWG and St Johns TC
Coming out of the Australia meeting, the project plan was starting to come together and needed to be vetted and solidified with people at the St. John's TC. Much of the work that tool place at the TC was conversation, socializing the ideas that had emerged in Australia. A summary of what seems to have emerged as concensus is below.
The demonstration of the IE will be a collection of IE participant contributed visualizations. Each visualization will address a specific use case that is both relevant to a given participant's organization and possible given existing data. Participants are not expected to provide linked open data or data services to be used in the use cases. Rather, participants are expected to contribute data and content that can be inserted into ttl/rdf/json-ld/html templates. The templates will be created as resources to be re-used, as possible, in similar use cases implemented using multiple contributor's data.
The technical solution being introduced by ELFIE is largely inspired by the Linked Data API's concept of linked data "viewers". In this context, a view can be thought of as a specific constrained and fully dereferenced/resolved view of a linked data graph encoded as a single resource (file) that is to be returned as the response to an HTTP request. The approach will allow creation of valuable general purpose resouces that are built as views of an actual live linked open data graph or as stand alone documents generated to document a single data provider or linked data hub's holdings. This approach should provide the useability and adoptibility of common REST/JSON API patterns while leveraging the rigor and power of linked open data. It also provides a path for organizations without the resources or capacity to implement a full linked open data capacity to publish useful, simple to generate, resources that express the critical details of their feature data holdings. These views will have a core set of predicates and are intended to be extended with conceptually consistant application-specific predicates. This should provide a core set of generally useful content to any client application while allowing domain or use-case specific systems to add their own content without hampering basic interoperability.
This view is intended to provide a useful preview of a feature. For any feature, it should provide information such as a geometric preview, a label, a description, and ownership information. For monitoring features, it should also include a basic summary of the monitoring activities associated with the feature. Commonality between what is required to satisfy use cases will be used to guide what is eventually included in the ELFIE reccomended set for basic interoperability. A given system would be expected to user predicates in the ELFIE recommended set first but would be free to add more specific predicates in addition to basic ones. A given system could also implement additional predicates that are unrelated to the ELFIE recommended ones understanding that general client implementations should feel free to ignore un-recognized content.
This view is intended to provide links to features connected to eachother through general spatial or temporal topology as well as through monitoring and hydrology domain topologies. This view would allow cross domain clients to understand spatio-temporal relationships such as in, contains, intersects, before, after, near, etc. Hydrology domain features could include hydraulic connectivity, associations with more general features like catchments, and groundwater surfacewater relationships. Other domain or application specific topology could be added in addition to the general set recommended basic interoperability understanding that only the core set are expected to be implemented in a general client.
It's becoming generally accepted that open data on the internet will follow an architecture based losely on data providers and data hubs. Data owners are expected to be providers, responsible for maintenance and provision of their basic data. "Hub" organizations pull information from numerous data providers creating indexes, caches, and enriched data holdings. While there may be some overlap between these two types of organization, the distinction is useful in devising a generalized information architecture. In terms of ELFIE views, data providers could publish a preview of all their features as well as the part of the network view they are aware of. For river monitoring, this would mean a data producer would publish monitoring site locations and what is monitored at the sites in preview views and the rivers the sites monitor as a network view. A hub might maintain an index of monitoring sites from multiple organizations, providing network navigation search and filtering based on what is observed. The hub could harvest information from the data provider using ELFIE views and return search results using the ELFIE view predicates. While there are other open data internet architectures, this example illustrates how ELFIE views could be used and is a likely future for the internet of open data.
The project is being tracked through the GitHub project here. Planned tasks and ongoing work will be tracked there. Below is a set of tasks coming out of the TC week and a longer term set of actions that all contributors will have to take.
- Get domain feature model predicates that we plan on using established and recorded in a common place. I hope this can be done soon and “recorded” can be a lightweight easy mechanism like checking a file into GitHub.
- Finish the ELFIE data submission strategy and templates that have been started this week. This will provide a target for people to use in submitting datasets to the ELFIE.
- Get use case diagrams for existing use case patterns finished up to go along with the data submission process.
- Track requirements for the OGC-NA infrastructure for tracking “test coverage” and “sandbox” type functionality to support IEs.
- Contribute a use case in the brief format recorded here or open an issue illustrating the use case idea and we can work it forward in the issue comments.
- Stay tuned and/or contribute to this and future pull requests working on the template for data contribution.
- Keep track of the status of the above work items on the ELFIE project and contribute to them as you can. Long term…
- Contribute small datasets (a handful of features that can illustrate the linkages we want to establish).
- Contribute your unique associations (in addition to the core set) and linked data encoding for your use case data.
- Contribute a script or simple program that interprets the contributed and encoded and generates a compelling user-oriented visualization.
SHACL: For specifying and testing graph shapes of views. Mustache templates: For templating multiple encodings of views. GeoJSON: for submission of geometry data to the IE and simple visualization in QGIS and/or github. Others?
The notes below are largely Dave Blodgett's running notes that were pulled from running note taking and/or recorded in retrospect. Please add additional material if there are relevant items that were missed.
Mostly was a work week with many sidfe conversations.
See "data" folder in repository for draft data contribution template.
See tasks in project
See discussion of alternates / multiple representation issue.
Rob commited to making HY_Features shapechange ontology and get it hosted on OGC-NA staging server.
Byron drafted diagrams documenting use cases and relationships we will be tracking for them. Will be checked in soon.
The plan for implementation of ELFIE has become more concrete -- summary above...?
An ontology has been developed (WMO hydrologic ontology) http://hiscentral.ddns.net/hisarctic/startree.aspx
Potential GWML2 Feature types for ELFIE: GW_MonitoringSite, GW_Well, GW_Aquifer, GW_Spring, ...
How much of GWML2 will be implemented for Canada pilot?
- Aquifer
- Water Well and Level
- ...?
Non-information resource discussion.
When dereferenced, 303 see other.
Either conneg with the 303 or 303 to a different url that has conneg. The latter works well with federated systems. The solution Eric presented is in line with the alternates view.
One Geology is driving linked data encodings of GWML2. Some of it is coming along from GeosciML. There is an expectation that ShapeChange will be used to create an OWL/RDF schema.
MonitoringSite is a well with other monitoring stuff.
INSPIRE has an environmental monitoring facility — that encompasses a number of monitoring site types.
How do we bridge this? Is there a way to show how we can give multiple representations of the same thing in ELFIE to bridge this issue a bit?
ELFIE use case on environmental monitoring of air for a city? US-EU-NZ.
Nice slide showing how GW data is linked together!!
Geological observations -> Borehole -> Env. Monitoring Facility -> observation -> featureOfInterest -> Geological observations
Lots of good stuff in the recording.
Documented the top level use case and a list of datasets that are of interest.
See wiki page on use cases.
Use cases need to go in GitHub
- Event with related data (see last slide of flood cast)
- Texas DOT (see slides from Maidment)
Five dimension slide is really good.
Flood event -> extent data -> assets -> monitoring + modeling
"Water integrates -- soils is where the integration actually happens!"
EODP as a base line reference in ELFIE? It’s in GitHUB.
SoilIE architecture is pretty ideal — grab slide for use in ELFIE.
We can abstract away the service calls by embedding them in linked data. -> Turn service requests into resources with linked data
Observations: We don’t have to implement a bunch of new stuff… we just need to stitch things that exist together!
LAWA timeline slide!!! AM I RIGHT?
What about ELFIE content as a micro format in HTML?
“Metadata is a lovenote to the future”
There is definitely an ELFIE use case to be addressed related to the IWN catalog.
Could we do an example of how to extend the ELFIE core with some SOSA sensor data quality information? https://www.w3.org/TR/2017/WD-vocab-ssn-20170504/
Look at a headwaters area or area of concern in the GoldKing mine area. Start at a HUC12 or a catchment. Show linked WQP samples and real time sensor data sources. Grab WQP data as well as sensor data from NWIS, states, and tribes. (in use case wiki page)
Similarly, look at EPA data in the Champlain Richelieu. HUC12 as the index drinking water compliance information, impaired waters information, state revolving fund investments, monitoring data (WQP).
FloodCast for DOT flood preparedness — in the information standards phase of the project.
Noted that we are really using OGC information models along with W3C best practices.
Boyan isn’t too worried about ontology work for domain features. We can handle some subset of them.
Boyan asked about feature resolution and how this applies to it.
Boyan asks how this fits into the linked data world? A lot of discussion, linked data will likely (definitely) underpin what we are doing.
Conversation covered most of the bases in: https://github.com/opengeospatial/ELFIE/wiki/Summary-of-Australia-Face-to-Face
Really highlighted how we need to separate issues of feature id minting, url resolving, and what the default response ought to be.
Starting the second session — let’s talk about criteria for “success” here. Root these things in particular use cases. What are the things we want to be able to accomplish using these linked-data documents.
Question about whether content negotiation on application profile is in or out of scope? Out of scope. We need to point to what appears to be the future solution but move on for now.
First set of criteria, Dave: We think we can come up with a document that can allow a data provider to encode a relationship between their monitoring feature and the domain feature they are attached to as well as what the schema and mime type of what I will get back.
We think we can express that rivers and watersheds have spatial relationships with aquifers, wells, and groundwater monitoring features.
For a flood inundation event feature, we think we can create a catalog of affected features (critical assets, monitoring sites, NWM flows) for that flood event. Do we expect to be able to express the type of the things attached to the flood inundation feature?
Sylvain pointed out that the feature preview: featurePreview : "gml standard object property + some specific elements”
Discussion of events and time… probably not going to solve anything related to events in this, but some of our use cases are going to point to events as some kind of temporality of the properties.
If we use events to link to features, then we don’t have to deal with time explicitly. “Events”, “incidents”, and affected features is a good set of information.
The flood impacts use case needs the concept of event for sure.
Discussion of an “event” as a feature. What does that mean in the “feature preview” context? We would have a feature preview of the event its self.
Our flooding use case should for sure have an entry point that is an “event”. Our expectation here is that we can provide a document that describes.
This expands scope to include “event” features. Sylvain's edit : the INSPIRE theme on Natural Risk Zones (NZ) modelled 2 Features related to this (AbstractObservedEvent and ObservedEvent)
For monitoring features, we expect to be able to express basic O&M properties and a basic feature preview.
For the domain feature it basic type, name etc. as well as a basic preview.