[ome-devel] Housekeeping..

[Josiah Johnston]

The proposal outlined has been implemented. Also, the OME file  
generated by Imaris now imports successfully. See  
http://bugs.openmicroscopy.org.uk/show_bug.cgi?id=191 for more info.

-josiah

On Jul 21, 2004, at 2:57 PM, Josiah Johnston wrote:

>> Apropos OME format, I tried an ome file as generated by Imaris  
>> (4.0.5) and this
>> was a failure. Later in this message, the extract of error_log,  
>> regarding this
>> import operation.
>>
>> Any idea?  Bitplane? OME Team?
>
> Without seeing the file, I can't be sure, but I suspect the  
> ExperimenterRef tag under Image is absent (as the schema allows). The  
> back-end Image class requires an Experimenter field. The way we handle  
> this with other image formats is assume the image belongs to the user  
> that is importing it.
> If this is really the problem, my short answer is: It's our fault. We  
> [the OME team] need to solve it with a minor bit of code and adding a  
> rule to the schema to prevent data inconsistencies.
>
>
> The long answer (& proposal))
> ---------------------------------
>
> An obvious solution is to adopt the usual strategy for image in the  
> OME format that don't say who they belong to.
> A problem arises with Image in OME files that have qualified LSIDs.  
> (1) If such an image is imported into two separate OME installations  
> by two people, then the experimenter in the images will differ. This  
> introduces data inconsistencies: the two installations will return  
> contradictory objects for the same LSID.
> My proposed solution is to
> 	require an ExperimenterRef for Images with qualified LSIDs, and
> 	populate the Image's ExperimenterRef with the currently logged in  
> User for Images that lack an LSID and lack an ExperimenterRef
> This would be very easy to implement.
>
>
> The rejected solutions:
> ---------------------------------
>
> Make ExperimenterRef required in the schema.
> 	This disallows direct translation from an existing file that lacks an  
> Experimenter description to an OME file.
> Drop the Experimenter requirement in the back-end Image class
> 	The experimenter is a very important bit of information. If we did  
> drop this requirement, we could still reconstruct who imported the  
> image. However, the person who imports an Image could easily be  
> different from the person that took the image. It's excedingly useful  
> to guarantee a recording of who took the image (or minimally, knows  
> where it came from). One could claim the person who imports an image  
> should not be assumed to be the experimenter, but they most often will  
> be. *shrug* This solution has many more implications.
>
>
> Notes
> ---------------------------------
>
> (1) An LSID is a Globally Unique Identifier that can (in principle) be  
> resolved to an object by whoever issued it. Folks that want to write  
> OME files but don't want to bother with guaranteeing LSID resolution  
> will use typical xml ids instead.
>
>
> -josiah
>
>
>>
>> Regards, Claude
>>
>>
>> 04/07/21 15:54:10 serve.pl[3987]: OME::Tasks::OMEImport->importFile:  
>> imported
>> bla77_MLE.ome
>> 04/07/21 15:54:10 serve.pl[3987]:  
>> OME::ImportExport::HierarchyImport->new
>> called with parameters:
>>         session=>OME::Session=HASH(0x94f664c)
>>         semanticTypes=>
>>         semanticColumns=>
>>         _parser=>XML::LibXML=HASH(0x918ef8c)
>> 04/07/21 15:54:10 serve.pl[3987]:  
>> OME::ImportExport::HierarchyImport->new
>> returning successfully
>> 04/07/21 15:54:10 serve.pl[3987]:
>> OME::ImportExport::HierarchyImport->processDOM: Processing Projects
>> 04/07/21 15:54:10 serve.pl[3987]:
>> OME::ImportExport::HierarchyImport->processDOM: Processing Datasets
>> 04/07/21 15:54:10 serve.pl[3987]:
>> OME::ImportExport::HierarchyImport->processDOM: Processing Images
>> 04/07/21 15:54:10 serve.pl[3987]:
>> OME::ImportExport::HierarchyImport->importObject: Importing node  
>> Image type 1
>> [Wed Jul 21 15:54:10 2004] -e: DBD::Pg::st execute failed: ERROR:   
>> ExecInsert:
>> Fail to add null value in not null attribute experimenter_id at /usr
>> /lib/perl5/site_perl/5.8.0/OME/DBObject.pm line 2329.
>> 04/07/21 15:54:10 serve.pl[3987]: Error DBD::Pg::st execute failed:  
>> ERROR:
>>  ExecInsert: Fail to add null value in not null attribute  
>> experimenter_i
>> d at /usr/lib/perl5/site_perl/5.8.0/OME/DBObject.pm line 2329.
>>          
>> OME::Factory::newObject('OME::Factory=HASH(0x90f2c2c)','OME:: 
>> Image','HASH(0x8a29c24)')
>> called at /usr/lib/perl5/site_perl/5.8.0/OME/ImportE
>> xport/HierarchyImport.pm line 442
>> [SNIP]
>
> _______________________________________________
> ome-devel mailing list
> ome-devel at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
>