New Mexico Wells

[ksonda]

New Mexico wells may be a good demonstration. @jirhiker this will be of interest eventually. @dblodgett-usgs the use case is pretty similar to the SELFIE CERDI use case. There are at least five data systems representing wells in NM, all of which have partial overlap with each other with different ID schemes and landing content

1. NWIS
2. NWGMN
3. NM Environment Department (NMED) (quality) (no current landing content)
4. NM Office of the State Engineer (NMOSE) (rights, borehole profile, levels)

• Non-semantic LC, e.g http://nmwrrs.ose.state.nm.us/ReportDispatcher?type=WR&name=WaterRightSummary.jrxml&basin=RG&nbr=55032&suffix=

5. NM Bureau of Geology and Mineral Resources (NMBGMR) (levels, quality)

• Different, non-semantic LC for each parameter, eg Levels, Quality

There is also the New Mexico Water Data Initiative (NMWDI), which, in ambition, will either via ETL or API alias/proxy serve out all well data via SensorThings API. Demo App and SensorThings endpoint.

SO, there need to be:

• reference wells at ref/wells with info.geoconnex.us LC, with subjectOf to all NMBGMR, NMED, NMOSE, and USGS existing LC or PIDs about the same well.

• In the short term, can mint NMBGMR organizational pids at /nmbgmr/wells that redirect to one of the LC pages, although not all wells have all parameters so that gets weird. May be better to set up a pygeoapi to try it out.

• Can create a /nmwdi/wells namespace with pygeoapi LC that are subjectOf the SensorThings/Locations, and sameAs the ref/wells?

Questions: Which LC should subjectOf vs. sameAs to which urls/ PIDs?

[dblodgett-usgs]

This is a great example to aspire to.

At the least, I'd like to get a solid reference wells set so we have something to build on.

Then we can get organizational PIDs and have the landing pages point to the reference gages.

Longer term, building out landing content that documents how these all relate will be in scope.

We should think about how we will sequence this stuff though -- it's all a bit too much to try and take on all at once.

[ksonda]

NM wants to host their own OGC-API with their own versions of HUC, counties, places, etc. Tell them to use our reference features instead? or have them do their own, and sameAs them to /ref/ features?

[dblodgett-usgs]

They should use reference URIs at the least. If they want to have application resources that that have geospatial services for their purposes, that would be all good but we want to make sure they are using the URIs to harvest into a knowledge network down the road.

[ksonda]

OK. Here's the scenario.

Statewide, multi-agency monitoring data is being aggregated and then published via SensorThings.

They're building a rough demonstration client application that they want to allow you to do various spatial queries by HUC, county, etc. They want these spatial queries to be driven by fairly high-resolution versions of WBD, counties, places, congressional districts, etc. They like to experiment and work fast, so they already are using the geoconnex counties as a sort of toggleable reference layer. They also want to show their data "integrates" with federal data sources in general, so are intrigued by the whole geoconnex idea and will pretty much do whatever I say or let me stand things up and transfer to them.

Currently no landing content for monitoring locations other than the sensorthings/Locations(id) calls that return json or geojson,

I can propose to them the following:

1. st_intersect the monitoring locations with preferred boundary geospatial files of choice

2. Make pygeoapi for monitoring locations.

   • Mint geoconnex PIDs.
   • Add some kind of link to the relevant sensorthings call for them. https://schema.org/distribution ?
   • Add link to the upstream (in a data, not hydrologic sense--usually bulk/aggregated/not-site-specific) source for them.
   • Add schema:geoWithin links to the /ref/ entities corresponding to the boundaries used in Step 1

3. Make pygeoapi for boundary files used in Step 1 and that will be used in anger in client applications. geoconnex PIDs and semantic content for these may not be necessary. Use case is more WFS 1.0.

4. Use the boundaries in Step 3. in your client applications if you want to do on-the-fly geospatial queries for now

Any suggestions?

[dblodgett-usgs]

For linked data, relying on the SELFIE contexts for guidance on association selection would be good. https://opengeospatial.github.io/ELFIE/contexts/elfie-2/

While not perfect, I think using "sosa:isFeatureOfInterestOf" from https://www.w3.org/ns/sosa/ to link to the sensorthings call to get data. To be super proper we would do something like:

{
  "@id": "https://the_well",
  "@type": [
    "https://www.w3.org/ns/sosa/FeatureOfInterest",
    "http://gwml2.org/def/gwml2#GW_Well"
  ],
  "https://www.w3.org/ns/sosa/sosa:isFeatureOfInterestOf": {
    "@type": "https://www.w3.org/ns/sosa/Observation",
    "https://www.w3.org/ns/sosa/hasResult": {
      "https://schema.org/url": "https://sta_call"
    }
  }
}

[ksonda]

I guess I was wringing my hands over sosa/ssn:ObservationCollection not being a thing (yet) or is it? I can't tell https://github.com/w3c/sdw/blob/gh-pages/ssn-extensions/rdf/ssn-ext.ttl

Its not the worst thing in the world to do hasResult to the most recent result though.

[dblodgett-usgs]

Some discussion of that over here: https://github.com/opengeospatial/SELFIE/issues/99

https://www.w3.org/ns/ssn/ext/ declares sosa:ObservationCollection in the @prefix sosa: <http://www.w3.org/ns/sosa/>

In the above -- I am always thinking in terms of a continuous observation where the result is ongoing rather than an observation collection of discrete observations. If the results are from multiple observations, then it would be a link to an observationCollection rather than an Observation. IMHO, if we can avoid the complexity of observationCollections and treat the sensorThings result as an ongoing result from a single Observation we should.

[ksonda]

closing for the time being. WIll proceed with more incremental issues as NM moves forward