Closed ksonda closed 4 years ago
Spent a little time with hydrologic units containedCatchment and containingCatchment relations just now.
It looks like 1:many relationships are going to be a non-starter with our current pyGeoAPI-based landing content -- ouch. Simple Features are really not supposed to have array attributes. GeoJSON does support it but other formats in our infrastructure don't.
Lots of good stuff to do with some simple 1:1 relations but it's going to be a major limitation.
So I think the list of potentials are the within / contains relations and point relations to other geometries. Yeah, we can pull our spatial predicates from geosparql.
Re: inverse relations -- we need a lot more sophistication to get there. IMHO there are three levels of sophistication we might consider.
I think 3 is what we want to pursue and is the most work. Maybe there's a happy medium? Something to think about.
For the bit without addressing inferencing, should we explore pyLDAPI as an alternative and/or complement?
The concept that simple features aren't supposed to have arrays is...a challenge. another option would be to use the links section of the response, though this would not be built into the existing pygeoAPI space.
Im no expert, but if you just specify multiple properties as a given predicate, I think it works... Below, I've set both GNIS_ID and SOURCEFEATUREID to https://schema.org/subjectOf
Copying to JSON-LD playground:
This could mean at least limited 1:m relationships are possible.
clsoing since it seems like this will require either a completely different approach or significant modifications to pyGeoAPI.
It is maybe worthwhile to encode links representing the network topology of HUCs, reaches, and cataloging units.
If so:
Where to start?
Which ontology/ context to use for the relationships? GeoSPARQL?
Should all inverse relationships be manifested as links directly?