[ome-devel] Re: need to retract/modify attribute assignment

[Ilya Goldberg]

On Sep 24, 2004, at 4:36 AM, Zachary Pincus wrote:

> Ilya,

Hi Zach
>
>  However, if attribute creation and container assignment is truly 
> non-retractable in OME -- for example, if a particular algorithm has 
> labeled a spot as a cell, the user can't delete it, or relabel it as a 
> vacuole within some other cell (etc.) -- then OME seems to be of very 
> limited utility for interactive image analysis.

> So, I guess the big question is: Is there any way to support iterative 
> refinement of image annotation/attribute attachment (etc.) in OME, 
> where several users, tools, or users and tools, can change and update 
> errors in previous annotations?

We haven't overlooked this at all.  Here's a question to consider.  
When a user slides a slider or types in new parameters or whatever in a 
regular interactive application, does the application save every 
movement of the slider to disk?  Why would it save it to a DB?
Think of saving an interactive tool's settings in OME as if it were a 
"Save" button.

Here's something you can do with OME that you don't normally see.  When 
you hit "Save" in a regular application, it over-writes what you saved 
last time - right?  At least usually.  What if you could roll back the 
various times you hit "Save" back to the beginning?  With OME, that 
kind of functionality comes for free.

This would seem to complicate matters a great deal.  Now, there are a 
zillion versions of the same data, so which do you get when you search, 
etc?  The fact is that the exact same simplicity that you would have 
with an application that over-writes can be achieved with an 
application that has a versioned archive.  If you want to keep it 
simple, just use the "latest" set of data.  The difference here is that 
this allows you to do something more - rewind and review.

There is a function in OME commander (only in CVS HEAD for now) that 
lets you do an actual deletion because mistakes are inevitable - 
especially during development.  It would be possible in principle to 
"prune" the version history of what was done keeping only the "latest" 
data.

However, you bring up medical applications.  Would such an action even 
be legal in all circumstances?  Not legally as in violating a datamodel 
or whatever, but as a matter of actual law.  There has been some talk 
about getting pretty hard-core about provenance - especially about 
medical and scientific data.  Our datamodel is built around the 
provenance concept.  Every piece of information in the OME database can 
be traced backwards through all analyses that were performed, to the 
instrument the data was acquired on, the lightpath through the 
instrument, the CCD detector the photons landed on (all with serial 
numbers for all the physical components).  If you start changing the 
data in there willy-nilly, you can no longer guarantee this provenance. 
  That's why in this system you're not allowed to do that.  It isn't 
perfect in terms of its protections, because they really all need to be 
at the DB layer as well as any protections you have in the various 
APIs, but this is really the goal here.

And speaking of medical applications, you'll be pleased to know that we 
have some support for DICOM import in CVS HEAD, which will most likely 
be in the next release - 2.2.2

>
> Zach

Ilya