Export/import value annotations

Hi,

Value annotation is a wonderful feature. More and more projects are taking advantage of it.

However it is not possible (to my knowledge) to easily export or import annotation values. You have to mess directly with the mysql database to do so. omeka-s-csv.py script does not include value annotation in the exportation, the same for bulkexport.

Importation-wise, CSVImport (or BulkImport) does not support value annotation.

So this is a feature request to add the support for exporting and importing value annotation. Reified statements are very important and they contain in most case scientific information (and not internal note) that should be handle in a same way than metadata value. I understand it is complicated and time consuming to implement this.

3 Likes

The annotations are present in the JSON output from the API, so saving them in that format is a possible option.

The trick with omeka-s-csv.py and the importers is more one of figuring out what would be a possible format for flattening those annotations to represent them in a CSV, or read them from a CSV. Every value can have arbitrarily many annotations of varying properties; with “main” properties already columns, how do you handle that? I haven’t thought of a format that can represent that in a reasonable way. Maybe resorting to JSON within a cell?

The best “flat” structure that I can think of would look like this: every main property has its own column (as it is currently), then there’s an additional column for every unique annotation property used by the values of that main property. Each one would have to follow the same multi-value structure as the main column, i.e., a “date” annotation on the second “contributor” value alone would have to look something like

dcterms:contributor dcterms:contributor_annotation_dcterms:date
Contributor 1;Contributor 2 ;2024

This obviously could lead to a whole bunch of columns in the output depending on how consistent and limited (or not) the site is in terms of how many annotations it uses and on which base properties, but I can’t immediately think of a better solution.

2 Likes

Thanks John for considering this.

Your solution is quite elegant in my opinion.

This is most likely the way to go. Here are two other ways for representing value annotations in a flat structure I can think of just to give grist to the mill.

  1. Using only one column. It is more readable if you have multiple values for the same term but makes things harder if you need to manipulate the data (and prevents the use of the bracket in the data)
dcterms:contributor
Contributor 1;Contributor 2[dcterms:date 2024]
  1. Consider reified statements has a third resource type in Omeka S (alongside media and item) a use a dedicated stylesheet to export/import them.

item or media stylesheet:

dcterms:contributor value_annotation_id
Contributor 1;Contributor 2 ZZZ

value annotations stylesheet:

value_annotation_id resource_id value_annotation_term value_annotation
ZZZ XXX dcterms:date 2024

ZZZ being a increasing number. XXX being the resource_id for value “Contributor 1” of “dcterms:contributor” for item YYY

This representation would be probably useful if you want to refine value annotation in the future (for example, by allowing to import an owner for a reified statement or by allowing reified statement about a reified statement (an annotation on a value annotation).

This solution implies to know the resource_id of the value annotated, so to implement some way to see/retrieve this information.