[ome-devel] More details on "Locked" attribute please?

[Curtis Rueden]

Hi Isaak,

> What about the case of multiple file distribution (at least for OME-TIFF, I
> can't remember if OME-XML talks about this)?
> What if several files reference the same dataset, (or even the same pixel
> set), but later (whether a few hours, or a few days, or years) after they
> are generated, another user opens only one or some of them, and sets the
> locked attribute.
> Say this file gets submitted to a database with Locked = TRUE before the
> other files of the same dataset (in separate actions) with Locked = FALSE?
> Is there any rule or tool or convention or general practice to prevent that
> situation, or to deal with it when it arises?

For OME-XML, each entity is in one master file. As far as I know there
is no facility to split the document across multiple files.

In the case of a collection of OME-TIFF files describing a single
OME-XML entity, it is the responsibility of the application to keep
the files' OME-XML blocks synchronized with one another. If they get
skewed in any way (other than differing TiffData elements to indicate
which IFDs corresponding to which image planes), the behavior of
OME-TIFF readers is undefined. In that case, my suggestion would be to
use whatever is present in the "first" -- lowest numbered,
lexicographically first, etc. -- TIFF, and ignore the rest.

-Curtis

On 12/4/06, Isaak Berg <isaak at cimaging.net> wrote:
>
> >> Could someone please provide a use-case scenario of how the "Locked"
> attribute is intended to be used?
>
> >Locked simply means that the Dataset's collection of images can no longer
> be altered.  This is the case when Dataset-granularity
> > attributes are generated for the dataset.  For example, one could perform
> a calculation over all of the images in a dataset (average
> > signal intensity, say).  If the set of images comprising the dataset is
> subsequently altered, then the computed signal intensity
> > would no longer be valid.  So the Locked attribute is used to signify that
> there exists a piece of information pertaining to the dataset as a
> > whole.
>
> Then it seems to apply mostly in the context of the semantic types version
> of OME-XML obtained from the ome.xsd style XML via XSLT? Is this the schema
> by which most OME- files are expected to be found floating around
> cyberspace?
>
> Is there any assumption or design idea favoring the base ome.xsd style or
> the STD.xsd style OME-XML/TIFF data as the preferred format for general
> interchange, or should readers be expected to read either?
>
> This clearly makes sense within files or a database where exclusively one
> OME-aware application has access, but I am struggling with this concept a
> bit because for example I don't know how it will or even ought be treated if
> say an OME user creates or retrieves from some database some OME files and
> then e-mails them to say, some other OME user on the other side of the
> Atlantic Ocean.  It doesn't seem secure or general enough to justify
> full-blown prevention of writing over the data merely because the locked
> attribute had been set some time in the past by some application or some
> database, but could certainly justify not allowing overwriting the pixel
> data without generating a new Pixels ID.
>
> What about the case of multiple file distribution (at least for OME-TIFF, I
> can't remember if OME-XML talks about this)?
> What if several files reference the same dataset, (or even the same pixel
> set), but later (whether a few hours, or a few days, or years) after they
> are generated, another user opens only one or some of them, and sets the
> locked attribute.
> Say this file gets submitted to a database with Locked = TRUE before the
> other files of the same dataset (in separate actions) with Locked = FALSE?
> Is there any rule or tool or convention or general practice to prevent that
> situation, or to deal with it when it arises?
>
> Are there any further details on who or what application is responsible for
> setting the locked attribute? Should proprietary software designed to import
> from and export to OME-TIFF format give special treatment of Locked = true?
> Either way, more details please. Surely this attribute must solve someone's
> problem(s).  but whose and what problem(s)? Even understanding that, would
> help greatly in deciding how to treat this attribute.
> This sort of seems like really an internal value that should really be
> handled differently (whether that means removal or set to true or whatever)
> when sending data cross-application? If so, wouldn't it be better to have
> some consensus before dozens of different OME-capable applications get
> compiled and distributed, each with a possibly different rule about this
> attribute?
>
>
>
> _______________________________________________
> ome-devel mailing list
> ome-devel at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
>