Mark data package as changed when Annotation is edited
Currently you can make as many changes as you want to an Annotation without ever changing the EML data package that it is referring to. This means:
you can close the data package without being prompted to save the annotation>Save... menu you will not be able to save the the location you are currently working from ("local" will be greyed out in the most typical case).
-if you use the File
If we mark the EML package as dirty, then we will always save both EML and Annotations when the save is invoked.
Unfortunately this will inflate the EML revision number and also makes it look like Annotating is an act of "editing" the EML.
At this point there is a separate "Save Annotations" option in the Annotation menu bar but it has rightly been deemed confusing.
#1 Updated by Margaret O'Brien over 9 years ago
This is part of a bigger issue - how to balance the user's need to have all the underlying structure hidden with the same user's need to know what is going on - like the difference between metadata and annotation. So far, we have been talking about annotating datasets as a two step process, and so the second "Save" makes some sense. Some aspects of the process need to be made clearer, though - that these are two activities, that a dataset is complete on its own, that annotation depends on attributes being complete, and that not all attributes need to be annotated.
One general comment: there are some tasks that users will balk at or will find confusing - mainly that you first define an attribute (EML) and then add very similar information in a second place (the annotation). So the more that the two activities are split apart, the better -- or conversely, link them together by completing part of the annotation along with the attribute definition.
#2 Updated by Matt Jones over 9 years ago
I've been thinking that the annotation will eventually supplement or supplant the current EML attribute description page. As we wrap our minds around annotation, it seems like it could potentially eliminate some of the choices that the user needs to make in the attribute screen for EML. Units in particular are a point of overlap to be resolved. Also, by choosing Entity and Characteristics first, we can probably massively simplify the rest of the UI -- for example, if the Characteristic measured is Diameter, there's no need to display any units other than Length-derived units. Exploiting the ontologies to simplify the UI for markup would always be a good thing. There will probably be some things that remain from EML. Maybe we should talk through the Morpho attribute screen and discuss what overlaps with the oboe annotation process, and what could be eliminated.