Deal with `InstancesUploadEditor` templating shortcomings #312

New issue

Open

opened 2026-01-24 21:23:34 +00:00 by jsheunis · 0 comments

jsheunis commented

2026-01-24 21:23:34 +00:00

Owner

https://github.com/psychoinformatics-de/datalad-concepts/pull/503 triggered this challenge.

The added annotation also required a different TTL template because here we are allowing upload on a slot with range XYZDistribution, where previously the upload is on a slot with range XYZDocument.

The context is a two-way linkage between a document and distribution. Up until now for a file upload, the DocumentUploadTemplate ttl file specified the creation of both a new XYZDocument record and a new XYZDistribution record, and for linking them correctly. Since both of them were created in-place by the code that assesses the template, their PIDs are available in place and the two way linkage is straightforward.

Now, for a file upload on the distributions slot of an XYZDocument, the new template should only specify the creation of a XYZDistribution record (because the XYZDocument already exists, or was just created, and is being edited) and the two-way linkage should still be done. The link from XYZDocument to XYZDistribution via distributions follows the normal process of form editing, nothing to update here. But the opposite link from XYZDistribution to XYZDocument (via distribution_of) needs to be part of the TTL template step, which happens on successful file upload. There is no problem with also passing the XYZDocument PID to the templating process, so that that link can be set on the XYZDistribution record when it is created from the template. The problem is that that might be an internal/temporary PID: internal if the open form is for a new XYZDocument that was just created, or temporary in case the user decides to change the PID of the XYZDocument. This means that, specifically upon form save, there would need to be an extra check for the correctness of the PID of the distribution_of slot of the created Distribution.

shacl-vue already has a mechanism for registering onSave, onCancel, and similar handlers for a form from any component. The challenge is that these handlers, for the InstancesUploadEditor, would need to be conditional on the type of TTL template being used and the existence or not of two-way linking slots.

So this would have to somehow also come from config, otherwise some complicated interpreting logic needs to be added to the component itself. Perhaps that might be necessary either way...

I core part of why this is a challenge is that the InstancesUploadEditor creates the graph data (via the templating mechanism) on successful upload, as opposed to on form save. That is why it needs (currently and perhaps inadequately) accurate data inside the template.

https://github.com/psychoinformatics-de/datalad-concepts/pull/503 triggered this challenge. The added annotation also required a different TTL template because here we are allowing upload on a slot with range `XYZDistribution`, where previously the upload is on a slot with range `XYZDocument`. The context is a two-way linkage between a document and distribution. Up until now for a file upload, the `DocumentUploadTemplate` ttl file specified the creation of both a new `XYZDocument` record and a new `XYZDistribution` record, and for linking them correctly. Since both of them were created in-place by the code that assesses the template, their PIDs are available in place and the two way linkage is straightforward. Now, for a file upload on the `distributions` slot of an `XYZDocument`, the new template should only specify the creation of a `XYZDistribution` record (because the `XYZDocument` already exists, or was just created, and is being edited) and the two-way linkage should still be done. The link from `XYZDocument` to `XYZDistribution` via `distributions` follows the normal process of form editing, nothing to update here. But the opposite link from `XYZDistribution` to `XYZDocument` (via `distribution_of`) needs to be part of the TTL template step, which happens on successful file upload. There is no problem with also passing the `XYZDocument` PID to the templating process, so that that link can be set on the `XYZDistribution` record when it is created from the template. The problem is that that might be an internal/temporary PID: internal if the open form is for a new `XYZDocument` that was just created, or temporary in case the user decides to change the PID of the `XYZDocument`. This means that, specifically upon form save, there would need to be an extra check for the correctness of the PID of the `distribution_of` slot of the created `Distribution`. `shacl-vue` already has a mechanism for registering `onSave`, `onCancel`, and similar handlers for a form from any component. The challenge is that these handlers, for the `InstancesUploadEditor`, would need to be conditional on the type of TTL template being used and the existence or not of two-way linking slots. So this would have to somehow also come from config, otherwise some complicated interpreting logic needs to be added to the component itself. Perhaps that might be necessary either way... I core part of why this is a challenge is that the `InstancesUploadEditor` creates the graph data (via the templating mechanism) on successful upload, as opposed to on form save. That is why it needs (currently and perhaps inadequately) accurate data inside the template.