<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>(snip) <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<br>
</div>This seems like the most immediate win, but I'm not sure that it requires<br>
a new DB field. Using a clear namespace ("csl-json", etc) you could attach<br>
this information today with annotations.<br>
<br>
The key criterion which is one that we have one our plate for 2014 anyway<br>
is that when the image is exported and then re-imported that this information<br>
is collated and clearly provenanced.<br>
<br>
That would certainly be a workflow that it would be good to have you validate.<br></blockquote><div><br></div><div>Hi Josh,<br><br></div><div>that sounds like an even better solution! I had forgotten about the annotations. I realized today that in addition there might in addition be a need for a quick indexing solution to find a certain dataset, given PIDs. But actually this is not 100% certain, as if you publish the records on an external PID resolver, it can give back an omero imageset ID and take care of the problem. Worst case an O(n) solution would be sufficient to get going<br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div class="">
> * Add FILEID support to scifio/bio-formats, or right next to the omero<br>
> importer if you want to skip one dependency (the library also has<br>
> command-line utility for making FILEIDs)<br>
<br>
</div>Are you thinking of this as a separate file format or as an extension of<br>
each file format? If that latter, that's fairly invasive from an architecture<br>
point of view. From our point-of-view with the workflow above, embedding<br>
the FILEID info directly in the TIFF comment would be the fastest way to<br>
get started with a prototype.<br></blockquote><div><br></div><div>Indeed, the idea is to make FILEID a separate file to avoid the need to change existing file formats. Otherwise there is no way it would gain wide adoption! If a file format already has e.g. an LSID then we can pull it out and replicate it in the FILEID, which is easier for other (dumb) programs to parse than 100 specialized formats<br>
</div><div class=""> <br>
<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The next major version of OMERO (5.0) is slotted to come out very, very<br>
(, very) soon. So if you're interested in making this work in the short<br>
term, we'd need to find a way to interoperate without DB changes.<br></blockquote><div><br></div><div>The annotation seems to be the way forward here. We'll keep in touch!<br><br>Thanks,<br></div><div>/Johan<br></div>
</div><br clear="all"><br>-- <br>-- <br>-----------------------------------------------------------<br>Johan Henriksson, PhD<br>Karolinska Institutet<br>
Ecobima AB - Custom solutions for life sciences<br><a href="http://www.ecobima.com" target="_blank">http://www.ecobima.com</a> <a href="http://mahogny.areta.org" target="_blank">http://mahogny.areta.org</a> <a href="http://www.endrov.net" target="_blank">http://www.endrov.net</a><br>
<br><a href="http://www.endrov.net" target="_blank"></a>
</div></div>