Documentation Needed for Relating Organizational Features to Reference Feature Collections

[webb-ben]

Description: We need to create documentation outlining the best practices for relating organizational features to each reference feature collection in our service. The goal is to establish a consistent and understandable way to relate these collections to each other using appropriate standards and vocabularies. It seems gsp:stWithin could be a simple fallback if there are no vocabulary specific predicates. The goal of this issue is to come to consensus before developing documentation on the standard the relationships between the reference feature collections and organizationally contributed features. For the current collections (predicates open to change)

Name	SPARQL Predicate	Description
HU02	hyf:containingCatchment	Two-digit Hydrologic Regions from USGS NHDPlus High Resolution
HU04	hyf:containingCatchment	Four-digit Hydrologic Subregion from USGS NHDPlus High Resolution
HU06	hyf:containingCatchment	Six-digit Hydrologic Basins from USGS NHDPlus High Resolution
HU08	hyf:containingCatchment	Eight-digit Hydrologic Subbasins from USGS NHDPlus High Resolution
HU10	hyf:containingCatchment	Ten-digit Watersheds from USGS NHDPlus High Resolution
USGS National Aquifers		National Aquifers of the United States from USGS National Water Information System National Aquifer code list
USGS Principal Aquifers		Principal Aquifers of the United States from 2003 USGS data release
USGS Secondary Hydrogeologic Regions		Secondary Hydrogeologic Regions of the Conterminous United States from 2018 USGS data release
Reference Gages		United States community contributed reference Stream Gage Monitoring Locations
Reference Mainstems	hyf:referencedPosition/hyf:HY_IndirectPosition/hyf:linearElement	United States community contributed reference Mainstem Rivers
Reference Dams		United States Community Contributed Reference Dams
Public Water Systems		Public Water Systems from United States EPA Safe Drinking Water Information System
States	schema:State	States from United States Census Bureau Cartographic Boundaries
Counties		Counties from United States Census Bureau Cartographic Boundaries
AIANNH		Federally recognized American Indian/Alaska Native Areas/Hawaiian Home Lands (AIANNH)
CBSA		United States Metropolitan and Micropolitan Statistical Areas
Urban Areas		United States Urbanized Areas and Urban Clusters from the 2010 Census
Places		United States legally incorporated and Census designated places

[ksonda]

I think there are a few types of relationships we may want people to assert:

1. I have a surface water monitoring location

• I am the same as this reference gage (optional) (schema:sameAs)
• I am on this ref/mainstem or usgs/mainstem (hyf:referencedPosition/hyf:HY_IndirectPosition/hyf:linearElement)
• I have X gsp geometry OR gsp:sfWithin (HUC/county/state)

2. have a groundwater monitoring location

• I am the same as this reference well (need to make that still)
• I monitor this aquifer (sosa:featureOfInterest)
• I have X gsp geometry OR gsp:sfWithin (HUC/county/state)

4. I have a administrative boundary/HUC

• I am the same as this county/state/HUC

5. I have a delineated catchment/watershed

• I am within hyf:containingCatchment comid/HUC/other id
• I have X gsp geometry OR gsp:sfWithin (array of HUCs)

5. I have data about an arbitrary linear or area feature

• I have X gsp geometry OR gsp:sfIntersects (HUC/county/state)

[webb-ben]

It might have been wiser to rename the middle column to SPARQL Predicates because a subject can have 1..n types of relationships (predicates) with an object

[ksonda]

It's more that this is either a matrix (different types of things haver different predicates for different ref features) or is better communicated in a more broken out way than table

[webb-ben]

Probably many ways to represent it. I think there are certainly better ways to frame the output documentation than the table I included at the head of this issue. Your framing addresses someone that who is readily able to adapt their infrastructure to relate to features of upmost hydrologic importance to the data.

I do think we should consider multiple representations of how to map - mine was built off the use case of adding WQP stations to geoconnex. The table I created had two principle questions I was trying to answer:

1. Given an extant API with constraints on associated information, how do I map all existing fields to geoconnex reference features?

{
  "@iot.id": "0800852-MB1",
  "name": "MysteryBridge",
  "description": "MysteryBridge",
  "properties": {
    "OrganizationFormalName": "Mystery Bridge Road - US Highway 20",
    "county": "https://geoconnex.us/ref/counties/56025",
    "hu08": "https://geoconnex.us/ref/hu08/10180007",
    "mainstem": "https://geoconnex.us/ref/mainstems/486655",
    "monitoringLocationType": "CERCLA Superfund Site",
    "provider": "STORET",
    "state": "https://geoconnex.us/ref/states/56",
    "station_url": "https://www.waterqualitydata.us/provider/STORET/0800852/0800852-MB1/",
    "uri": "https://geoconnex.us/iow/wqp/0800852-MB1"
  }
}

2. Given (1), what is at least one SPARQL predicate I can use for each reference feature collection?

[webb-ben]

I think there are a few types of relationships we may want people to assert:

Re-reading this I entirely agree. I guess this is an outstanding question - Is your scenario imagining a world where there is geospatial inferences? If the answer is yes, then I think each still merits a mapping of how you could relate to all reference features. Could be a two step process where you select the type of information you would want to associate and it would then show a corresponding map to reference features

[ksonda]

I think we can imagine geospatial inferencing one way or another. But agreed we can describe all relationships that would end up inthe graph, and indicate which need to be explicit to show up.