[ome-devel] Housekeeping..

[Josiah Johnston]

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