[ome-devel] analysis model import

[Ilya Goldberg]

This is just a warning.  Maybe we should preface this message with  
"Warning: " to make it more clear/less scary?

LSIDs are a very important chaos abatement measure, and the warning  
is there to remind us that all is not necessarily well with the world.

LSIDs are globally-unique identifiers.  The reason for the warning is  
that in an LSID-compliant world, it would cause data corruption and  
loss if you allowed different objects to have the same LSID world- 
wide.  Since we can't resolve remote LSIDs, that's something we just  
can't verify yet, so we issue a warning instead.  Your module's LSID  
authority is "openmicroscopy.org", which is the right thing to use if  
you intend to make this module part of the standard distribution.   
The server actually goes as far as realizing its never seen this LSID  
before and that a remote LSID authority issued it, so it tries to  
contact the remote authority to verify the object's identity.  The  
last step isn't implemented, and hence the warning.

We can verify LSIDs locally though (and we do), and this is why you  
can't re-import "modified" XML without changing the LSIDs.  If you  
import that file again, the LSID will now resolve locally and you  
won't have the warning, and no duplicate module either, even if you  
import it again from a completely different document.  If you export  
this module to XML, then OME will re-use the same LSID as before, and  
issue new LSIDs (using the local authority specified during  
installation) for any new objects it generates (like analysis  
results, for example).

Globally unique identifiers are cool, and OME supports and uses LSIDs  
fairly well - except of course the remote resolution bit.  IBM has  
open-source implementations of the client and server parts of an LSID  
resolution service in at least a couple languages, so if we ever find  
a compelling use-case for remote LSID resolution, this will be cake.

-Ilya



On Mar 23, 2006, at 9:25 AM, Harry Hochheiser wrote:

> Bernd:
>
> A quick look at the code reveals that the getRemoteObject procedure  
> in the LSIDManager is not quite implemented:
>
> sub getRemoteObject ($) {
> 	carp ("OME::Tasks::LSIDManager::getRemoteObject() is not  
> implemented.");
> 	....
>
> Thus,  it does nothing other than generate an warning now.
>
> if we look at the calling code in ModuleImport.pm, it looks like  
> the call to getRemoteObject() is designed to check to see if the  
> module already exists in the DB. If it does, it is not processed  
> any further.
>
> Josiah knows this code much better than I do, but I don't think  
> this is going to cause you any problems as is.  Ideally,  
> getRemoteObject would be fleshed out to make this check meaningful,  
> but I don't even know where to start with that.
>
> Josiah, what do you think?
>
> harry
>
>
> On Mar 23, 2006, at 8:40 AM, Bernd Jagla wrote:
>
>> I wanted to import an analysis module (see attachment) to describe  
>> the process of importing plate definitions for compound plates.
>>
>>
>>
>> I now have a module called Ai compound importer, so I believe that  
>> everything is OK, but
>>
>>
>>
>> I get the following message but can’t really interpret it.
>>
>>
>>
>> Why is it complaining that getRemoteObject is not implemented????
>>
>>
>>
>> Importing files
>>
>>          1/4: [IN PROGRESS] Starting import
>>
>>          3/4: [IN PROGRESS] Importing
>>
>> OME::Tasks::LSIDManager::getRemoteObject() is not implemented. at / 
>> home/bernd/ome_cvs/OME/src/perl2//OME/ImportExport/ModuleImport.pm  
>> line 183
>>
>>          4/4: [FINISHED] Imported 0 images from 0 files. 1  
>> scanned. 0 unknown format, 0 duplicates, 0 errors.
>>
>> OME::Session __destroySession: $self->__destroySession();
>>
>>  at /home/bernd/ome_cvs/OME/src/perl2//OME/Util/Commands.pm line 269
>>
>> Exiting...
>>
>>          4/4: [FINISHED] Imported 0 images from 0 files. 1  
>> scanned. 0 unknown format, 0 duplicates, 0 errors.
>>
>> Exiting...
>>
>>
>>
>>
>>
>> Thanks for explaining this to me.
>>
>>
>>
>> Bernd
>>
>> Bernd Jagla, PhD
>> Associate Research Scientist
>> Columbia University
>> 1150 St. Nicholas Avenue
>> Russ Berrie Medical Pavilion, Room 520
>> New York, NY 10032
>> Tel: 212 - 851 5560 x16
>> Fax: 212 - 851 5570
>> e-mail: baj2107 at columbia.edu
>>
>>
>>
>>
>> <Ai_compound_import.ome>
>> _______________________________________________
>> ome-devel mailing list
>> ome-devel at lists.openmicroscopy.org.uk
>> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
>
> _______________________________________________
> ome-devel mailing list
> ome-devel at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel