[jgonggrijp]

Since I'll be away for two weeks, this draft PR serves to document what I've been working on. My plan is to address #301 by combining a (small) datamodel change and a UI change.

In the datamodel, I want to allow the oa:hasBody of an edit annotation to be a nested resource that can have roughly the same properties as an edpoprec:Field or edpoprec:DigitizationField, except for using rdf:value instead of edpoprec:originalText and edpoprec:summaryText. The use of rdf:value for the "main" content of the edit follows the convention of oa:TextualBody (though without requiring that the resource actually has oa:TextualBody as its rdf:type). This also avoids the confusion that might arise from an edit containing an override value in a property named edpoprec:originalText. Existing edits with just a string as body will continue to work and will be considered equivalent to the rdf:value of a nested body.

In the UI, I want to turn the field editor into an input group with a dropdown button on the left. The dropdown lets you pick which subproperty of the annotation body you're editing. All fields have a "text" and a "link" option, with the "text" option being selected by default and letting you set the rdf:value. This is equivalent to the existing functionality. Picking the "link" option, however, makes it possible to set the edpoprec:authorityRecord and thus create a link. For the digitization field, I want to also add "IIIF", "image" and "thumbnail" options, which let the user set the edpoprec:iiifManifest, edpoprec:url and edpoprec:previewURL, respectively.

Executing this plan involves the following layers:

• backend SPARQL Updates for updating and deleting annotations
• backend POST and PUT handlers for /api/annotations/
• frontend Annotation model
• frontend presentableContents
• new frontend model to represent an edit with nested properties
• frontend AnnotationEditView