The whole problem with this question is that there is no
single answer. Metadata varies from the crucial (magnification,
dwell time) all the way to the trivial (user annotations). If
it were not possible for the microscope to 'get it wrong' one
might draw a line in the sand and set a level beyond which one
could not edit. But unfortunately on the majority of systems
out there such critical items as magnification can easily be
stored wrongly. So to my mind everything should be editable,
so that at least one can get it right. And given the time pressure
on using advanced equipment, a lot of users will want to sort out
their annotations at leisure. Not to mention adding things such as
2-photon laser parameters which many systems do not record, but which
Omero presumably has space for.
The idea of having some levels which are editable only by the 'lab
manager' is not realistic. In a large core facility like ours, who
other than the user can possibly know if the metadata is correct or
not?
The question of an audit trail is a bit of a red herring. I assume
everyone is going to keep the original image in the equipment maker's
format, so any changes from that are going to have to be justifiable on
the basis of the records in the lab book. I can't see any lab giving
up the paper trail any day soon.
Guy
Optical Imaging Techniques in Cell Biology
by Guy Cox CRC Press / Taylor & Francis
http://www.guycox.com/optical.htm
______________________________________________
Associate Professor Guy Cox, MA, DPhil(Oxon)
Electron Microscope Unit, Madsen Building F09,
University of Sydney, NSW 2006
______________________________________________
Phone +61 2 9351 3176 Fax +61 2 9351 7682
Mobile 0413 281 861
______________________________________________
http://www.guycox.net
-----Original Message-----
From: Confocal Microscopy List [mailto:[log in to unmask]] On Behalf Of Dan White
Sent: Monday, 2 February 2009 10:15 PM
To: [log in to unmask]
Subject: editable metadata
Hi Jason,
I think your idea of at least logging the changes is sensible.
One should be able to edit ANY metadata.
Systems are often set up incorrectly with false metadata.
Its up to the user to make sure its right.
OMERO cant be expected to police the quality of the meta data, only try its best to archive / store it in a version controlled manner.
by 2 cents
Dan White
Date: Sun, 1 Feb 2009 20:09:54 +0000
From: Jason Swedlow <[log in to unmask]>
Subject: Metadata editability
--00151749bffe789c870461e105bf
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Dear All-
Apologies-- this is not a direct confocal question, but it does affect use and analysis of confocal data. If you don't care about image metadata, then just ignore and delete.
As the OME project moves towards release of OMERO-Beta4 ( http://trac.openmicroscopy.org.uk/omero/roadmap), we have a number of issues coming up we'd like feedback on.
The first is metadata editability. In Beta4, we've gone for something we call "metadata completion". This means that, for a given image file format, we capture and find a home for all of the metadata in that format which fits into OMERO. For some formats, that's easy, because there is so little metadata. But many are quite rich, and this project has been a huge effort by the Bio-Formats (Melissa Linkert) and OMERO (Brian Loranger, Chris Allan, Jean-Marie Burel) teams.
The result is that we will support 5 rich file formats in Beta4 "completely". Note that we have to make decision about what each piece of metadata means-- we certify that it has been imported into OMERO, although there are a few edge cases where we've had to make decisions about where each piece of metadata goes.
This raises a critical question, that we have debated within OME for years,
namely:
What image metadata should be editable? Imagine that some value was either unset or wrongly set on the microscope, a user may want to correct the situation after import. Then, if we allow editing, how much info about that editing should we track?
Some technical points:
-- in OMERO, we store every write to the DB as an Event. So we know every change, who did it and when.
-- we really do NOT want to store every metadata change made. Doing this properly means making multiple copies of every database entry every time one thing changes-- so things get bloated very rapidly.
A compromise we are considering seriously-- keep only the last metadata value, but log all the changes. If a user has changed any metadata that came with an image fille, we can add functionality to the client applications to let the user find this out. You'll know that the data has changed, by whom, and when, you just wont know what the previous data was.
If necessary, we could implement an audit database, which stores previous metadata versions, or maybe just the first version-- the one that was acquired with the original . This would be optional-- if needed it could be turned on. We won't get that done for the first Beta4.0 release, but if it's a priority, it could come later this year.
Thanks for your ideas and comments.
Cheers,
Jason
Dr. Daniel James White BSc. (Hons.) PhD
Senior Microscopist / Image Processing and Analysis Light Microscopy Facility Max Planck Institute of Molecular Cell Biology and Genetics Pfotenhauerstrasse 108
01307 DRESDEN
Germany
New Mobile Number!!!
+49 (0)15114966933 (German Mobile)
+49 (0)351 210 2627 (Work phone at MPI-CBG)
+49 (0)351 210 1078 (Fax MPI-CBG LMF)
http://www.bioimagexd.net
http://www.chalkie.org.uk
[log in to unmask]
( [log in to unmask] )
No virus found in this incoming message.
Checked by AVG.
Version: 7.5.552 / Virus Database: 270.10.16/1929 - Release Date: 1/02/2009 6:02 PM
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.552 / Virus Database: 270.10.16/1929 - Release Date: 1/02/2009 6:02 PM
|
