[ome-devel] on the use PIDs and OMERO

[Johan Henriksson]

(snip)

>
> This seems like the most immediate win, but I'm not sure that it requires
> a new DB field. Using a clear namespace ("csl-json", etc) you could attach
> this information today with annotations.
>
> The key criterion which is one that we have one our plate for 2014 anyway
> is that when the image is exported and then re-imported that this
> information
> is collated and clearly provenanced.
>
> That would certainly be a workflow that it would be good to have you
> validate.
>

Hi Josh,

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


> > * Add FILEID support to scifio/bio-formats, or right next to the omero
> > importer if you want to skip one dependency (the library also has
> > command-line utility for making FILEIDs)
>
> Are you thinking of this as a separate file format or as an extension of
> each file format? If that latter, that's fairly invasive from an
> architecture
> point of view. From our point-of-view with the workflow above, embedding
> the FILEID info directly in the TIFF comment would be the fastest way to
> get started with a prototype.
>

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


The next major version of OMERO (5.0) is slotted to come out very, very
> (, very) soon. So if you're interested in making this work in the short
> term, we'd need to find a way to interoperate without DB changes.
>

The annotation seems to be the way forward here. We'll keep in touch!

Thanks,
/Johan


-- 
-- 
-----------------------------------------------------------
Johan Henriksson, PhD
Karolinska Institutet
Ecobima AB - Custom solutions for life sciences
http://www.ecobima.com  http://mahogny.areta.org  http://www.endrov.net

<http://www.endrov.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20140212/375e1694/attachment.html>