More flexible annotation setup #183

New issue

Open

opened 2025-12-18 08:29:23 +00:00 by mih · 1 comment

mih commented

2025-12-18 08:29:23 +00:00

(Migrated from github.com)

It is my understanding that, at present, the annotation tags for recording the submitter and the submission time stamp are hard-coded.

It would be good to have them be configurable, such that a user/admin can decide what vocabulary terms is appropriate in a given content.

Right now, the assumption dumpthings is making is that people run things/v1, and that the annotation_value is a string with no further constraints. It would be good to decouple dumpthings from the specifics of things/v1 in this regard.

I only see the slot name annotation_value being used in the tests right now (cool!). A future things release may get rid of this dedicated slot, and switch to the generic description slot instead. If the name of the annotation_value equivalent slot is important, it should become a configurable parameter.

Moreover, it would also be good to support simple templating of the annotation value.

Use case: Rather than having two annotations for submission time and submitter separately, one might want to have a single "dumpthings submission tag", and maybe have that formatted as a string following particular conventions. This could be achieved by allowing for a Python template string to be configurable, and provide a small catalog of values (timestamp in different formats, submitter ID, maybe incoming IP, maybe certain HTTP header values, ...) that could also be extended as needed in future releases.

It is my understanding that, at present, the annotation tags for recording the submitter and the submission time stamp are hard-coded. It would be good to have them be configurable, such that a user/admin can decide what vocabulary terms is appropriate in a given content. Right now, the assumption dumpthings is making is that people run `things/v1`, and that the `annotation_value` is a string with no further constraints. It would be good to decouple `dumpthings` from the specifics of `things/v1` in this regard. I only see the slot name `annotation_value` being used in the tests right now (cool!). A future `things` release may get rid of this dedicated slot, and switch to the generic `description` slot instead. If the name of the `annotation_value` equivalent slot is important, it should become a configurable parameter. Moreover, it would also be good to support simple templating of the annotation value. Use case: Rather than having two annotations for submission time and submitter separately, one might want to have a single "dumpthings submission tag", and maybe have that formatted as a string following particular conventions. This could be achieved by allowing for a Python template string to be configurable, and provide a small catalog of values (timestamp in different formats, submitter ID, maybe incoming IP, maybe certain HTTP header values, ...) that could also be extended as needed in future releases.

christian-monch commented

2026-01-14 14:18:57 +00:00

(Migrated from github.com)

Annotation tag classes were made configurable in PR #145. The admin can define the vocabulary terms in the configuration keys:

collections.<collection_name>.submission_tags.submitter_id_tag, and
collections.<collection_name>.submission_tags.submission_time_tag

Currently, both values are always added to an annotation.

Annotation tag classes were made configurable in PR #145. The admin can define the vocabulary terms in the configuration keys: - `collections.<collection_name>.submission_tags.submitter_id_tag`, and - `collections.<collection_name>.submission_tags.submission_time_tag` Currently, both values are always added to an annotation.