Bug #4724


Mark data package as changed when Annotation is edited

Added by ben leinfelder about 14 years ago. Updated over 10 years ago.

Morpho Plugin
Target version:
Start date:
Due date:
% Done:


Estimated time:


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
-if you use the File
>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 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.

Related issues

Blocks Semtools - Bug #4738: Discard Annotation changes when datapackage window is closedResolvedben leinfelder02/04/2010

Blocked by Semtools - Bug #4853: Save as Duplicate... should copy the Annotation tooResolvedben leinfelder03/01/2010

Actions #1

Updated by Margaret O'Brien about 14 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.

Actions #2

Updated by Matt Jones about 14 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.

Actions #3

Updated by ben leinfelder about 14 years ago

adding a dependency for the annotations being discarded when the window closes. I'm not sure what should rely on what, but they are related issues. If we discard annotations w/o alerting someone, that's bad. we'll figure out something.

Actions #4

Updated by ben leinfelder almost 13 years ago

Annotation should be saved if it has changed - the application should indicate that there are unsaved changes (either/both with EML and annotation) and it should save whatever artifact needs to be saved when that action is invoked.

Actions #5

Updated by Redmine Admin almost 11 years ago

Original Bugzilla ID was 4724

Actions #6

Updated by ben leinfelder over 10 years ago

  • Target version changed from Unspecified to morpho-plugin-0.9.0

Also available in: Atom PDF