Support rendering record back links

jsheunis commented

2026-01-19 14:55:08 +00:00

Owner

The current record viewer in shacl-vue shows a record and all of its related information. On the graph level it means rendering a named node and all the quads where that named node is the subject. There is no current functionality to render all quads where that same named node is the object.

This occurs e.g. when a class has a slot to link to a parent record, but that parent record has no inverse slot to list all of its children. A use case: if a Distribution is a distribution_of a Document, and there is no slot on a Document that lists all of its distributions, there is no way currently to view a Document and immediately be able to link to a related Distribution. But this would be useful from a user's perspective: click on a Document and be able to download it (i.e. the Distribution) immediately.

Technically this is not difficult, the N3 query already happens but the node argument now just has to go into the object position rather than the current subject position. What needs to be figured out is how the specification/configuration can support this.

The current record viewer in `shacl-vue` shows a record and all of its related information. On the graph level it means rendering a named node and all the quads where that named node is the subject. There is no current functionality to render all quads where that same named node is the _object_. This occurs e.g. when a class has a slot to link to a parent record, but that parent record has no inverse slot to list all of its children. A use case: if a `Distribution` is a `distribution_of` a `Document`, and there is no slot on a `Document` that lists all of its distributions, there is no way currently to view a `Document` and immediately be able to link to a related `Distribution`. But this would be useful from a user's perspective: click on a `Document` and be able to download it (i.e. the `Distribution`) immediately. Technically this is not difficult, the N3 query already happens but the node argument now just has to go into the `object` position rather than the current `subject` position. What needs to be figured out is how the specification/configuration can support this.

mih commented

2026-02-11 06:33:44 +00:00

Owner

The number of use cases for this is accumulating. It may also be an interesting approach for investigating the usage of (custom) properties (e.g., https://pool.v0.trr379.de/ui/?sh%3ANodeShape=dlthings%3AProperty). What is being "credited", etc.

mih commented

2026-02-11 07:30:51 +00:00

Owner

Another major use case would be "what is being influenced by particular objectives?" What other objectives are considered part_of another?

Another major use case would be "what is being influenced by particular objectives?" What other objectives are considered `part_of` another?

jsheunis commented

2026-02-17 08:23:30 +00:00

Author

Owner

@cmo @mih I thought about this again. In shacl-vue this wouldn't be difficult to achieve. The in-app graph store uses N3 which makes it easy to find quads with any specification (with subject X or predicate Y or object Z). However, that query is constrained to known quads in the store, thus the challenge is getting all relevant quads into the app from the backend. AFAICT, the best way to achieve this with the current dumpthings API is to do a constrained search with the relevant PID, and with the class being Thing. I am assuming that the string matching search in dumpthings will check the whole record?

E.g. if we want to show "what is being influenced by particular objectives?", we would do a search for all Things with the matching string being the PID of a particular objective.

The only alternative I can think of would be to implement a new API endpoint that explicitly searches for related PIDs on specific slots.

@cmo @mih I thought about this again. In `shacl-vue` this wouldn't be difficult to achieve. The in-app graph store uses `N3` which makes it easy to find quads with any specification (with subject X or predicate Y or object Z). However, that query is constrained to known quads in the store, thus the challenge is getting all relevant quads into the app from the backend. AFAICT, the best way to achieve this with the current dumpthings API is to do a constrained search with the relevant PID, and with the class being `Thing`. I am assuming that the string matching search in dumpthings will check the whole record? E.g. if we want to show "what is being influenced by particular objectives?", we would do a search for all `Thing`s with the matching string being the PID of a particular objective. The only alternative I can think of would be to implement a new API endpoint that explicitly searches for related PIDs on specific slots.

mih commented

2026-02-19 14:22:16 +00:00

Owner

This is also my understanding. Without knowing the details of the implementation in dumpthing, this should also not be faster than a dedicated endpoint. The PID should (be definition) be fairly unique and no further type-constraint would be available.

jsheunis referenced this issue

2026-02-25 10:00:52 +00:00

Introduce BackLinkViewer component and associated config #342

jsheunis closed this issue

2026-02-25 10:14:49 +00:00

Rows
Columns

Support rendering record back links #303