Open mbjones opened 1 year ago
Thanks for the summary @mbjones. I see the same thing you do.
I like the updatePath
method idea but we could also probably modify setValue
such that if the targetPath
is manipulated the relationships are updated. I like the way the function call would look for updatePath
, but I'm not convinced we need a new method.
We should stop using insertRelationship
I think - it is too likely to end up inserting a bogus relationship that makes the resource map invalid or otherwise non-sensical.
And I do think that it should error if the entity is not in the package - I saw an example of that yesterday, and it fails sort of silently (bagit doesn't download correctly, but package otherwise looks fine).
The use of
prov:atLocation
in packages as implemented in #76 makes use of atargetPath
slot on eachDataObject
. When an DataObject withtargetPath
set is added to a package withaddMember()
, the function knows to add aprov:atLocation
relationship to the graph for that object. However, if thetargetPath
of the DO is later updated, the relationships in the package remain untouched, resulting in a conflicting state. Here's some example code showing howtargetPath
and the relationships table can be out of sync:The fix to this might be to synchronize targetPath and relationships, such that a change to one results in an update in state on the other. For example, if a
prov:atLocation
relationship is added viainsertRelationship()
(or removed), then the appropriate targetPath should be updated (assuming it can be found -- would it be an error if that entity is not in the package?). And, if targetPath is updated usingsetValue()
then the relationships should be updated. The challenge lies in consistently determining when one or the other has been updated, especially if they get changed through other methods than those two, or if the slots are manipulated directly.An alternate solution might be adding an
updatePath(pkg, id, path)
, and use that in preference to the other methods discussed above. cc @jeanetteclark