Allow adding standard annotations #114

New issue

Open

opened 2025-05-19 11:17:24 +00:00 by jsheunis · 1 comment

jsheunis commented

2025-05-19 11:17:24 +00:00

(Migrated from github.com)

Origin: inm7/annotate.inm7.de-simplesubmit#25

Right now, annotations can be added via an "all fields" visible selector. However, for a few common annotations, it would make sense to simplify that. Examples:
Request record deletion (add annotation with a justification string)
Certify validity of a record (record who is claiming to have checked the record and when)
Report error (Like deletion, but capture explanation of the error. This is needed when it is known that something is wrong, but the reporter does not know how to fix it directly).

Origin: https://hub.psychoinformatics.de/inm7/annotate.inm7.de-simplesubmit/issues/25 > Right now, annotations can be added via an "all fields" visible selector. However, for a few common annotations, it would make sense to simplify that. Examples: > > Request record deletion (add annotation with a justification string) > Certify validity of a record (record who is claiming to have checked the record and when) > Report error (Like deletion, but capture explanation of the error. This is needed when it is known that something is wrong, but the reporter does not know how to fix it directly). Related: - https://hub.trr379.de/q04/annotate.trr379.de-demo/issues/42 - https://hub.psychoinformatics.de/inm7/annotate.inm7.de-users/issues/8

jsheunis commented

2026-01-12 11:08:52 +00:00

(Migrated from github.com)

I'm thinking it would be good to approach this in a general way via config. The general functionality is: add some annotation with extra message/content.

The current data model / app UI have the ability to add Annotations to a Thing, specifically by selecting an existing standard annotation_tag, e.g. "To be deleted", and adding an annotation_value, e.g. a string containing an explanation as to why the Thing should be deleted.

Generally, a specific button on a record could be attached to a specific annotation tag (which has a PID, and can therefore be specified via config), so pressing the button could internally create and link that annotation, and then require the annotation_value to be input manually. This suggests that the Annotation form can be used for this, i.e. it would be opened directly from the button press, with the annotation tag prefilled.

One uncertainty that remains is the nature of the annotation_value. It seems it would often be a string, which fits the model of an Annotation. But looking at the use case:

Certify validity of a record (record who is claiming to have checked the record and when)

The who and when would not best be described via strings, rather some Thing. In such cases, would the annotation itself have to be linked to a new Statement, as the subject, with the object then being the who or when?

Getting back to the config, we could e.g. have an option record_actions that ties a specific button functionality to a specific record type to be created and associated slots to be prefilled:

{
    "record_actions": {
        "delete": {
            "class": "dlthings:Annotation",
            "slots": {
                "dlthings:pid": "<pid-template-if-not-autogenerated>",
                "dlthings:annotation_tag": "<pid-of-action-specific-annotation-tag>",
            }
        }
    }
}

In this way, these record actions could also be used in other contexts outside of this specific "button-adds-annotation" use case.

Regarding pre-populating the Annotation form (with the tag, in the use case above), this could also be seen as a general functionality. After pressing the button, the rest would pretty much follow the same approach as when editing a record (as opposed to creating a new record). This suggests that it can be achieved by creating the record first (and linking the tag) when the user hits the button, and then open the form as an edit process.

This functionality, i.e. creating a record and adding links, would be very similar to what is needed to support (in part) the feature of record cloning: https://github.com/psychoinformatics-de/shacl-vue/issues/117

I'm thinking it would be good to approach this in a general way via config. The general functionality is: add some annotation with extra message/content. The current data model / app UI have the ability to add `Annotation`s to a `Thing`, specifically by selecting an existing standard `annotation_tag`, e.g. "To be deleted", and adding an `annotation_value`, e.g. a string containing an explanation as to why the `Thing` should be deleted. Generally, a specific button on a record could be attached to a specific annotation tag (which has a PID, and can therefore be specified via config), so pressing the button could internally create and link that annotation, and then require the `annotation_value` to be input manually. This suggests that the `Annotation` form can be used for this, i.e. it would be opened directly from the button press, with the annotation tag prefilled. One uncertainty that remains is the nature of the `annotation_value`. It seems it would often be a string, which fits the model of an `Annotation`. But looking at the use case: > Certify validity of a record (record who is claiming to have checked the record and when) The who and when would not best be described via strings, rather some `Thing`. In such cases, would the annotation itself have to be linked to a new `Statement`, as the subject, with the object then being the who or when? Getting back to the config, we could e.g. have an option `record_actions` that ties a specific button functionality to a specific record type to be created and associated slots to be prefilled: ```json { "record_actions": { "delete": { "class": "dlthings:Annotation", "slots": { "dlthings:pid": "<pid-template-if-not-autogenerated>", "dlthings:annotation_tag": "<pid-of-action-specific-annotation-tag>", } } } } ``` In this way, these record actions could also be used in other contexts outside of this specific "button-adds-annotation" use case. --- Regarding pre-populating the `Annotation` form (with the tag, in the use case above), this could also be seen as a general functionality. After pressing the button, the rest would pretty much follow the same approach as when editing a record (as opposed to creating a new record). This suggests that it can be achieved by creating the record first (and linking the tag) when the user hits the button, and then open the form as an edit process. This functionality, i.e. creating a record and adding links, would be very similar to what is needed to support (in part) the feature of record cloning: https://github.com/psychoinformatics-de/shacl-vue/issues/117