Ambiguous and not so optimal resolvers

[skybristol]

I like the idea behind the registry quite a bit and would like to contribute. It would be great to get some of the stuff around feature registries we've been talking about forever into an operational state. One of the major use cases we are dealing with brings in "environmental features of interest" that don't really have an established resolvable identity for a registered geoconnex.us URI to dereference to. Having a system like this that we can build linked data on top of would be great, but I don't know how the current model you are pursuing here fits cases like these.

A couple cases in point that have long been problematic are some established methods of describing explicit ecosystem unit boundaries based on mapping of ecosystem characteristics. Two big sources still in wide use for biodiversity assessment and many other purposes are Bailey's and Omernik's ecoregion interpretations. Online availability for these is essentially in the form of spatial data downloads from USFS and EPA, respectively. There are GIS web services available for these as boundaries, contextual identifiers, and a few properties from quite a number of different sources but certainly none that would be considered authoritative or necessarily stable. I also don't know of anyone who has stood up something like a landing page construct where structured metadata could instantiated to rally around. There are lots of other things like this, including Large Marine Ecosystems and Ecologically and Biologically Significant Areas. Some of these are really interesting from a linked data perspective in that there could be all kinds of interesting stuff linked to them if a reliable persistent identifier system existed. Roger Sayre's alternative approaches (Ecological Land Units, Ecological Marine Units, Ecological Coastal Units) for this kind of ecosystem mapping also don't yet quite have an instantiation that supports linked open data.

One approach for this type of use case would be for different organizations to take logical ownership to stab up some sort of code-driven data system that reads best available source data in whatever form and instantiates a "back-end" resource of identifiers, landing pages, JSON-LD metadata, etc. and then registers those via geoconnex.us, advertises and starts using those identifiers. Geoconnex.us provides a nice layer of abstraction in case someone else wants to take ownership of the back end asset pool eventually (e.g., like the actual owner of the data). We might even do something in the registry metadata that indicates where this third party, hopefully not permanent stewardship condition exists. That would keep the architecture clean, but it does create a number of dependencies in motion to be managed.

I'd be really interested in thoughts on dealing with this kind of dynamic. What are some other use cases like this, and how are folks thinking about dealing with them?

[dblodgett-usgs]

Hey @skybristol -- Thanks for your thoughts here and interest in taking part!

Your thinking re: "logical ownership" is exactly what I'm imagining will be the path of least resistance. I'm increasingly realizing we need to create "community reference locations" and "cataloging units" as described in the wiki I started over here..

I like this idea of creating "thematic" name spaces where there's some group of motivated people who create a reproducible workflow to mash up a bunch of data sources and generate landing-content. Deployment of that content (html and json-ld) can and should be uber cheap. Then if some more authoritative organization wants to come along and host the landing content -- great! We just change the PIDs.

Re: getting involved, I'm starting to assemble a plan for a "barn raising" of sorts over here.. Been talking with Daniel about dams and waterfalls that we could include in a couple places there. Maybe we would want to add some of the obvious eco-region sets in the list? Your references above provide a solid starting point for what would be "in-scope".

In ELFIE/SELFIE and the CHyLD project, I wrote a bunch of R-code that can template out json-ld and html to create basic landing pages -- I've been thinking about scaling that stuff up in service of this barn raising ... maybe we could pursue a little hacking in that space between all the teams.

The question is just -- who wants to own the web-server to put the stuff out? I'm not in a position to do it right now. I wouldn't want to saddle @ksonda with too much unless he's game to take it on. Maybe there are some other options in the USGS CSS world? I could ask around in Water too -- the labs.waterdata.usgs.gov space may be an option.

Dave

[ksonda]

Regarding hosting thematic/community/ownerless landing content, I think institutionally Internet of Water makes sense as a neutral hosting entity. @dblodgett-usgs and I have batted around the idea of an info.geoconnex.us that would serve new landing content to which geoconnex.us redirects.

[skybristol]

From the USGS perspective, one option is to leverage the data.usgs.gov domain. I'd set that up a long time ago along with maps.usgs.gov and some others back when I was in a role with a different focus for the enterprise. We still own it, and I've been pushing some more stuff toward it lately in terms of code-driven data backed APIs. If my lab took this on as a temporary-till-someone-better-comes-along owner, we'd probably spin stuff up there to help place it and ensure some hope for longevity.

For the Ecoregion sources I mentioned, I can make a logical case for USGS and my group, in particular, to take some ownership in the near term. We already have our own stuff spun up for Omernik Ecoregions in our work and need to modernize that anyway. For LMEs, EBSAs and a bunch of other marine features, I might have a reasonable chance of enticing the folks from VLIZ in Belgium who run https://www.marineregions.org/ to get involved, perhaps tying it to a UNESCO global infrastructure project I'm involved in. The PHP app they are using to run their gazetteer has a reasonable semblance of a landing page that is workable enough. In my mind, it should be pretty simple and cheap to structure out JSON-LD with that stuff, following the science-on-schema.org work, decorate pages via their existing web app, and set up a registry/maintenance mechanism with geoconnex.us. Of course, I always think things like that should be cheap.

I also really like the idea from @ksonda of some kind of neutral territory for some other community-led efforts. A case in point that's also in the marine world where we really need a "Switzerland" (ch.geoconnex.us?) is with the Exclusive Economic Zones. These are always in debate and litigation around the world with a bunch of diplomatic concerns in putting them online. MarineRegions does it...sort of, but they are always really careful and somewhat deliberately ambiguous about how they are represented and what happens with the data. But they are also really important when it comes to doing things like developing metrics and indicators relevant to management policy and developing trends analyses on things like conservation status. Having some neutral group come together and develop a process for processing some slate of reasonably trusted sources, standing up a code-driven info source, and registering through this system could be really appealing.

If I can make time, I'll happily come to your barn raising, though I'll probably contribute Python. R makes my head hurt too much.

[dblodgett-usgs]

OK -- So @ksonda and I have been scheming over in the ESIP slack. I'm going to do some investigation of how to use pyGeoAPI for a really simple info.geoconnex.us and see what we see.

There are some others we might be able to tap to help here too.

All code is welcome as long as it's reproducible. :)

[skybristol]

I've reached out to Pieter Provoost with the OBIS and IODE efforts in Belgium who will chat with some colleagues involved in the MarineRegions work about mapping and exposing linked data from their gazetteer. We'll see if we can get them involved and on track for the June-ish barn raising.

[dblodgett-usgs]

Sky -- I'll leave this issue open for further discussion. Maybe once we've agreed to a few items to add to the barn raising scope we close it?

[dblodgett-usgs]

@skybristol -- Looking back through old issues and realizing we never followed up.

Do you think we are in a place where we could ad a few reference layers per discussion above?