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

[Zachary Pincus]

Ilya,

Thanks for your reply. Again, this clears up some questions; however, 
it (as usual) has lead me to another question.

Basically, one of the lessons the medical image processing people have 
learned over the last few years is that if you want something done 
right (as opposed to just done fast), you shouldn't let a computer do 
all of it, and instead you should have a more open-loop system where 
some image processing algorithm makes a first stab, and then a human 
refines it. (Or an even tighter interactive human-computer interaction 
model.)

However, this requires a computer making retractable guesses, which the 
human then OKs, fixes, or deletes. One could pretty easily conjure a 
biological imaging system where a user would like to check in a bunch 
of images to a database, perform some operation on those images, and 
then manually refine the results of that operation. (I'm in fact 
working on a tool that would work thusly...) 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.

I understand the null MEX trick to create mutable attributes, but (a) I 
also understand that this is discouraged, and (b) in the situation 
above, it is pretty necessary that the attributes have a MEX 
associated, so you can tell which tool was used to create the initial 
guesses, etc.

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? Am I looking at the problem wrong -- is 
there a better way to support this sort of behavior than by changing 
attribute values?

Zach



On Sep 23, 2004, at 8:07 AM, Ilya Goldberg wrote:

>
> On Sep 23, 2004, at 4:05 AM, Zachary Pincus wrote:
>
>> Thanks for the discussion of the type model -- this actually clears 
>> up some other questions I've had. As to my original questions, I 
>> think I may have proposed a bad example to illustrate them. So let me 
>> try to re-phrase them with a sensical example:
>>
>> Say we've pulled a DTO over the network representing Feature 78, 
>> which belongs to image 1. We realize on further processing that it is 
>> actually a sub-blob within a larger blob, and thus the parent feature 
>> should not be null, but should be feature 64, which is another blob 
>> in image 1. Presumably this is a sensical operation? (If not, just 
>> treat this as a straw man. This is meant to be a generic question 
>> about the update machinery of the remote API.)
>
> Changing the container the feature belongs to - a feature in this 
> case, is the same as changing the image a feature belongs to, but I 
> see your point about changing references (STs can have references to 
> other STs).
>
>> Several questions:
>> (1) Why are there two possible methods to do this (via the fields 
>> "parent_feature" or "parent_feature_id")? Is there a reason to prefer 
>> one over the other in certain cases?
>
> I think this is done for convenience.  The Perl API is set up this way 
> because sometimes you've got the object already, or you want to just 
> chain the references together (i.e. object->reference()->something()). 
>  Other times you just have the id and don't want to bother loading the 
> object it refers to.  The DTO setup closely mirrors the perl API, so 
> its present there as well.
>
>> (2) If we want to have the DTO refer to a new parent feature, we can 
>> make it look like so:
>> {
>>   'image': 'REF:Image:1',
>>   'parent_feature': 'NEW:1',
>>   'tag': 'GOLGI',
>>   'id': 78
>> }
>> and call updateObjects with a list which contains the new parent 
>> feature first, and then this DTO. Now my question is whether this 
>> would work if we set 'parent_feature_id' to 'NEW:1' rather than 
>> setting 'parent_feature' to that value.
>> (3) In option (a) above, we need to set the 'image' and 
>> 'parent_feature' fields to 'REF:Image:1' and 'REF:Feature:64' 
>> respectively -- why not 'REF:1' and 'REF:64'? The fields are 
>> strongly-typed, after all: OME should know which kinds of objects 
>> each field/column refers to, right? In fact, if we set 
>> 'parent_feature' to 'REF:Image:64' or even 'REF:foobar:64' instead of 
>> 'REF:Feature:64' it works just the same way, with no errors -- that 
>> is, no type checking seems to be performed on the middle type value. 
>> Is there any reason for this?
>
> That I don't know.  Maybe DOug can shed some light.
> -Ilya
>
>
>>
>> Thanks,
>>
>> Zach Pincus
>>
>> Department of Biochemistry and Program in Biomedical Informatics
>> Stanford University School of Medicine
>>
>>
>>
>> On Sep 22, 2004, at 9:14 PM, Ilya Goldberg wrote:
>>
>>> Hi Zach
>>> On Sep 22, 2004, at 5:53 PM, Zachary Pincus wrote:
>>>
>>>> Hello,
>>>>
>>>> I've got a few minor questions about how updating objects with the 
>>>> remote framework works.
>>>>
>>>> Specifically, when you pack up a DTO for update over the wire, 
>>>> there appear to be two ways to specify objects to which that DTO 
>>>> refers.
>>>>
>>>> Say we've got pulled a DTO from over the network for a Feature that 
>>>> looks like so:
>>>>
>>>> {
>>>>   'image': {'id': 2},
>>>>   'tag': 'CELL',
>>>>   'id': 78
>>>> }
>>>>
>>>> Now say we want to change the image to which feature 78 refers to 
>>>> image 1.
>>>
>>> Can't really do that.
>>> There are two object hierarchies in play here.  One is the "core" 
>>> hierarchy of Project->Dataset->Image->Feature, the other is the 
>>> vagaries of STs.  Im including STs as an object hierarchy because 
>>> much to our surprise (!) they seem to support a fairly complete 
>>> inheritance model (though some might argue), and we're working on 
>>> the syntactic sugar to make it palpable.  A very important aspect of 
>>> the STs is where they belong in this core hierarchy.  None of the 
>>> objects in the core hierarchy are STs, they can only act as 
>>> containers for STs.  Perhaps its a weakness of the datamodel, but 
>>> that's how it is for now.  In the future, its possible to think of a 
>>> scenario where the "core" hierarchy is represented as STs as well, 
>>> but that's not how things are now.  There are numerous complications 
>>> that arise from this, as you can probably imagine.
>>>
>>> An ST (by its declaration) can belong to a Dataset, Image or 
>>> Feature, or it can be Global - that's the granularity of the ST.  
>>> You can't switch the container that the ST instance belongs to, nor 
>>> can you switch its granularity.  Basically once you have an instance 
>>> of an ST, you are locked into its container instance.  You can 
>>> change its contents only as long as it has no assigned MEX.  Once it 
>>> has a MEX its immutable.  This is why we refer to instances of an ST 
>>> as attributes - they are attributes of the container they belong to. 
>>>  Some containers, like features, are described only by their 
>>> attributes - they are abstract.  It is sometimes useful to also 
>>> think of features as image attributes, because unlike the other 
>>> levels of the core hierarchy, images and features are limited to a 
>>> one-to-many relationship.  This is the same pattern as the 
>>> container-attribute relationship - one to many.
>>>
>>> Some of this is hard to enforce in OO-space, and there has been some 
>>> thought to enforcing it at the DB layer (with triggers, for 
>>> example).  So far we've counted on "good behavior" in applications 
>>> to keep this aspect of the datamodel consistent.
>>>
>>> If you think about what you're proposing actually means physically, 
>>> its an impossibility.  You're saying I found this blob in Image 1, 
>>> and it has all these attributes.  Now, I'm going to take this very 
>>> same blob along with all of its attributes and assign it to Image 2. 
>>>  It just doesn't make sense in terms of the physical reality this 
>>> represents.
>>>
>>> Unless of course, I completely missed your point.
>>>
>>> -Ilya
>>>
>>>
>>>
>>>
>>>>
>>>> We could do this two ways:
>>>> (a) Change the DTO to look like so:
>>>> {
>>>>   'image': 'REF:Image:1',
>>>>   'tag': 'CELL',
>>>>   'id': 78
>>>> }
>>>> and call updateObject on that DTO, or
>>>>
>>>> (b) Change the DTO to look like so:
>>>> {
>>>>   'image_id': 2,
>>>>   'tag': 'CELL',
>>>>   'id': 78
>>>> }
>>>> and call updateObject.
>>>>
>>>> Several questions:
>>>> (1) Why are there two possible methods?
>>>> (2) If we want to have the DTO refer to a new image, we can make it 
>>>> look like so:
>>>> {
>>>>   'image': 'NEW:1',
>>>>   'tag': 'CELL',
>>>>   'id': 78
>>>> }
>>>> and call updateObjects with a list which contains the new image 
>>>> first, and then this DTO.
>>>> The question is whether this method would work if we set 'image_id' 
>>>> to 'NEW:1' rather than setting 'image'.
>>>> (3) In option (a) above, we need to set the 'image' field to 
>>>> 'REF:Image:1' -- why not 'REF:1'? The fields are strongly-typed, 
>>>> after all. OME knows that it must be a reference to an Image. In 
>>>> fact, if we set 'image' to 'REF:Feature:1' or even 'REF:foobar:1' 
>>>> it works just the same way, with no errors. Is there any reason for 
>>>> this?
>>>>
>>>> Thanks,
>>>>
>>>> Zach Pincus
>>>>
>>>> Department of Biochemistry and Program in Biomedical Informatics
>>>> Stanford University School of Medicine
>>>>
>>>> _______________________________________________
>>>> ome-devel mailing list
>>>> ome-devel at lists.openmicroscopy.org.uk
>>>> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
>>>>
>>>
>>
>