Opening an edit form injects additional redundant blank nodes

jsheunis commented

2025-02-08 22:12:48 +00:00

(Migrated from hub.datalad.org)

This is a person record upon first view:

Then I click the edit button and the form shows an extra blank node for identifiers:

Then I click cancel and the extra blank node is in the summary:

This must be happening as a result of one of the service calls when either the form renders or when the instanceselecteditor renders.

This is a person record upon first view: ![Screenshot 2025-02-08 at 23.06.54.png](/attachments/75e86102-38d1-4fd6-a162-a9ef87f188ee) Then I click the edit button and the form shows an extra blank node for identifiers: ![Screenshot 2025-02-08 at 23.07.06.png](/attachments/4be34323-0077-4781-a2d0-7b21df12862d) Then I click cancel and the extra blank node is in the summary: ![Screenshot 2025-02-08 at 23.07.14.png](/attachments/6b337987-283a-4568-a5ac-453d7151905f) This must be happening as a result of one of the service calls when either the form renders or when the instanceselecteditor renders.

jsheunis commented

2025-02-12 21:57:54 +00:00

(Migrated from hub.datalad.org)

I've been stuck on this for too long. The core of it is to try and prevent the creation of duplicate blank nodes that have exactly the same triples under a different blank node value. This duplication happens when data is read in from the dump-things-service into the shacl-vue graph store. It will be something like:

<https://trr379.de/instruments/fra-cobic-mri-prisma-3t> <https://concepts.datalad.org/s/things/v1/characterized_by> b705
<https://trr379.de/instruments/fra-cobic-mri-prisma-3t> <https://concepts.datalad.org/s/things/v1/characterized_by> b707

where both b705 and b707 have exactly the same predicates and objects in separate triples. I can't pin the source of the issue down yet.

This issue became more noticeable when I solved a previous issue of a record display not updating upon saving a form.

I've been stuck on this for too long. The core of it is to try and prevent the creation of duplicate blank nodes that have exactly the same triples under a different blank node value. This duplication happens when data is read in from the `dump-things-service` into the `shacl-vue` graph store. It will be something like: ``` <https://trr379.de/instruments/fra-cobic-mri-prisma-3t> <https://concepts.datalad.org/s/things/v1/characterized_by> b705 <https://trr379.de/instruments/fra-cobic-mri-prisma-3t> <https://concepts.datalad.org/s/things/v1/characterized_by> b707 ``` where both `b705` and `b707` have exactly the same predicates and objects in separate triples. I can't pin the source of the issue down yet. This issue became more noticeable when I solved a previous issue of a record display not updating upon saving a form.

jsheunis commented

2025-02-12 22:10:05 +00:00

(Migrated from hub.datalad.org)

Ok I think I know the source. shacl-vue is in fact fetching the same record twice, the first time via the "records" endpoint records/{name}?format=ttl (multiple) when a specific class is selected, and the second time via the "record" endpoint record?id={curie}&format=ttl (singular) when the user clicks the edit button on a specific record. When the GET request interaction with the service was first introduced into shacl-vue, I implemented a layman's request caching approach where a "set" is maintained of all previous request URLs, and a second request won't be made to a URL already in a set. This was actually to prevent unnecessary requests, but the prevention of the current issue actually seems like an even more valid reason.

I can currently think of different approaches to solve this.

The first is a quick and dirty approach, which is to disable the singular record GET request, because given the current workflow of the application it can safely be assumed that the "multiple records by class" request would already have been made before a singular record request is tried. UPDATE: this works!

However, this should not be the correct or long term solution. For that scenario we can take two approaches: either by developing a smarter caching mechanism, or by updating the shacl-vue graph store to prevent "duplicate" blank node creation.

Ok I think I know the source. `shacl-vue` is in fact fetching the same record twice, the first time via the "records" endpoint `records/{name}?format=ttl` (multiple) when a specific class is selected, and the second time via the "record" endpoint `record?id={curie}&format=ttl` (singular) when the user clicks the edit button on a specific record. When the GET request interaction with the service was first introduced into `shacl-vue`, I implemented a layman's request caching approach where a "set" is maintained of all previous request URLs, and a second request won't be made to a URL already in a set. This was actually to prevent unnecessary requests, but the prevention of the current issue actually seems like an even more valid reason. I can currently think of different approaches to solve this. The first is a quick and dirty approach, which is to disable the singular record GET request, because given the current workflow of the application it can safely be assumed that the "multiple records by class" request would already have been made before a singular record request is tried. _UPDATE: this works!_ However, this should not be the correct or long term solution. For that scenario we can take two approaches: either by developing a smarter caching mechanism, or by updating the `shacl-vue` graph store to prevent "duplicate" blank node creation.

Rows
Columns

Opening an edit form injects additional redundant blank nodes #32