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.
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.
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.
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]
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.