Supercession questions

[ksonda]

Given the supeceding framework you're laying out, should the mainstem id be based on the levelpathid from nhdpv2 or something more arbitrary?

In the "first case", will headwater and outlet references be added to the json-ld? As in there will be multiple headwater comid and outlet comid associated with the updated mainstem? Seems reasonable if the pairings can be maintained in the ontological relationships. You probably dont want just grab-bags of m:m matches between headwater and outlet comids though.

In the "second case", what will the new identifier be if not the levelpathid?

I could be misunderstanding something, so a concrete example of each case that has been implemented in this latest version would help.

for reference, the framework we've built with @fils
for the KG is that every time we re-harvest the pid registry, an object store full of individual harvested json-ld documents is populated. a re-harvested pid's json-ld is replaced in this object store. The object store is the source of truth for the triple store. So previous/ superceded relationships need to persist in the web resources one way or another if you want them remaining in the KG, unless they are errors presumably. I think this may have implications for how you want to think about superceding.

[dblodgett-usgs]

Given the supeceding framework you're laying out, should the mainstem id be based on the levelpathid from nhdpv2 or something more arbitrary?

That ship sailed. I used levelpathid from the version of hydrography I was looking at for no reason other than not overthinking it.

[dblodgett-usgs]

In the "first case", will headwater and outlet references be added to the json-ld?

This is something to work out. So far, I've only really thought about this in terms of the registry its self. How the information is materialized in structured data is separate. In concept, I figured we would have a list of preceded head water and outlet representations. Note that that will only happen when the preceded ones are similar enough that their meaning has not changed. In almost all cases this will be because a new set of features has become available and the mainstem representation has been improved with those new features.

[dblodgett-usgs]

In the "second case", what will the new identifier be if not the levelpathid?

I need to figure this out -- at this point, it will just be a unique integer that is not already in the registry. Exactly what it is isn't important. In hindsight, I should not have used the levelpath from the initializing dataset as it's introduced more confusion than it was worth. I was being overly incremental, to the point of cutting corners. But as I commented seperately, that ship sailed an now we are in a position of using unique alphanumeric strings for new mainstems.

[dblodgett-usgs]

So previous/ superceded relationships need to persist in the web resources one way or another if you want them remaining in the KG, unless they are errors presumably.

Yes. So in case 1, there is no change in the KG other than additional known headwater / outlet representations. In case 1, the mainstem ID is not superseded and it's semantic meaning is maintained.

In case 2, the relationship to superseded mainstems will need to be expressed such that the relations can be tracked back to mainstems that were found to be problematic, and were superseded as a result.