Bug #4769

Save annotations to network

Added by ben leinfelder over 10 years ago. Updated over 6 years ago.

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


Estimated time:


Currently only supporting saving Annotations to local store
This has implications for loading Annotations as well since that currently happens when the Annotation Plugin loads at start up.


#1 Updated by ben leinfelder about 10 years ago

now responding to the save event (on a data package) and saving to the same location as the eml package.
The "Save Annotations" command, however, only saves to the local store.
I think this is okay for right now because the ultimate goal is to make the eml/annotation distinction as opaque as possible.

#2 Updated by ben leinfelder about 10 years ago

Resolved a few outstanding issues:
-ID conflict resolution: revision is automatically incremented until conflict does not exist. this is different than how id conflict is handled for EML where the user is given an option to use a new id or to increment the revision. I decided it should be as transparent as possible for annotations.
-Revision is only incremented when save to disk/network. I had been incrementing the revision for any change to the annotation (in memory) but I believe that is unnecessary.
-annotations will be loaded from the source that their DP is loaded from - the default is local, as these are loaded when morpho first starts up.

Still need to make the Annotation->Save Annotations menu item save to the network.

#3 Updated by ben leinfelder about 10 years ago

Now saving to the same location that the EML data package is using:
If the EML has current unsaved changes, the location is not known and I default to save locally. If/When you finally do save the EML, the Annotation will also be saved to that location.

#4 Updated by ben leinfelder about 10 years ago

A potential problem I see cropping up is when we have local and network copies of annotations and the IDs differ (either a simple case of revisions being off, or a bigger issue of userA annotating a DP and userB annotating the same package).
We can "handle" multiple annotations per DP, but it's a crap shoot which one we'll be viewing/editing in the GUI right now (see related bug on this cardinality issue).

#5 Updated by ben leinfelder about 10 years ago

I've set up a test Metacat instance for us to use with the semtools-Morpho installers:

I've got one EML package and one annotation on it so far:

Of course you can't really see the annotation on the metacat side of things.

#6 Updated by Margaret O'Brien about 10 years ago

I successfully saved and reopened these 2 datasets and their annotations: (data package) (annotation)
This group seems to be OK, I was able to edit the annotation and save it to the network again. (data package) (annotation)
this group has a problem - when I reopen the data package a second time (without editing), it seems to be no longer attached to its annotation, although the ids match if you look at the annotation xml.

These are not synchronized with the local copies. both are publicly viewable.

#7 Updated by Margaret O'Brien about 10 years ago

This morning (from morpho installed on a different computer) I was able to view, edit and save the annotation for (annotation: mobrien.38.19).

#8 Updated by ben leinfelder about 10 years ago

I found an issue where network annotations made by other people were not being loaded. Fixed that.
But i'd like to figure out what your first issue was with reopening mobrien.47

#9 Updated by ben leinfelder about 10 years ago

Now responding to synchronization events fired by Morpho:
1. local -> network: the local annotation[s] are saved to metacat
2. network -> local: the annotation[s] stored in metacat are saved locally

We may find quirks in this behavior the more complex the docid conflict resolution gets. I tested with a scenario in which a new docid was generated before synching to metacat - both the network and the local "copies" of this DP showed the correct annotation for the given docid (and location).
I'm still not exactly sure how much more useful the synchronization feature is vs. regular old 'save' - time will tell.

#10 Updated by Redmine Admin over 7 years ago

Original Bugzilla ID was 4769

#11 Updated by ben leinfelder over 6 years ago

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

Also available in: Atom PDF