Define usage of Shape Path for Data Grant with InheritInstances scope

[elf-pavlik]

#130 uses viaPredicate to express predicate which directly relates parent to a child, we use it for inherited access.
I will link this issue inline in the primer to track changing it to st:viaShapePath.

Currently to find all Data Instances of child resources, we do following:

0. Each Data Grant is associated with specific ShapeTree (eg. Project, Task etc.)
1. Starting from child Data Grant with InheritInstances scope (eg. Tasks), follow interop:inheritsFromGrant Optimize referenced data grants and referenced access needs #124
2. We get parent Data Grant with scope AllInsances or SelectedInstances (eg. Projects)
3. For each instance of parent (eg. Project)
4. Find and fetch ReferencesList for children matching ShapeTree of child Data Grant (there will be separate ReferencesList for each referenced child ShapeTree in parent ShapeTree).
5. In the ReferencesList find references to all child Data Instances

I think in 3.1 we should be able to do it purely based on child ShapeTree if we include that information in ReferencesList description (partially embedded in each parent Data Instance). In 3.2 we would need to use Shape Path to get references of children. We would also need to consider how based on that Shape Path relevant statements get added to ReferencesList.

@ericprud @justinwb

[ericprud]

I accidentally made 137 link to this. I deleted that, but it still shows up as related above.

[elf-pavlik]

Some notes we were taking with @ericprud during one of TS implementation meetings https://hackmd.io/fTfCEE0XR4WVGHZIK5v5yQ

[TallTed]

@elf-pavlik -- hackmd.io pages are generally editable. I strongly advise making the reference above target a static page (I wasn't able to quickly find one, but perhaps there's a way to link to a specific version of a hackmd.io page, as with most wikis?), or moving the relevant content here.

[elf-pavlik]

@ericprud I implemented creating and deleting child data instances. It requires adding and removing accordingly relation statements from the parent data instance. In my case with simple direct relation just add / remove quad matching ?parent ?predicate ?child where I found a hackish way of picking predicate from shape path using schemaNodes[0].predicate
https://github.com/janeirodigital/sai-js/blob/main/packages/utils/src/shape-path.ts#L23

Your example uses shape path @<AppointmentLocation>~fhir:link I don't think sai-js would be able create all the statements and for such cases applications would need to be responsible for updating the parent first before we PUT the child. sai-js would still create draft data instance with correct IRI which app could use when updating the parent.

It might still be worth for shape tree to just define st:viaPredicate for simple cases where libraries can manage the relation statements while also supporting use of st:viaShapePath but here applications would need to take responsibility for managing statements describing relation.

In many (most?) cases simple st:viaPredicate will suffice and app developers will appreciate that library can take care for them to add / remove statement describing the binary parent-child relation.