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

[Zachary Pincus]

Aah, I see. Yes, versioned archiving is a much better solution than 
retracting pervious transactions. Especially in the medical domain.

I had figured that you guys (in your usual fastidious nature) would 
have come up with the "right" solution to this issue, so thanks for 
expounding upon it.

Zach


On Sep 24, 2004, at 9:44 AM, Ilya Goldberg wrote:

>
> 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
>