joshmoore
commented
8 years ago With other graph actions (e.g. Chgrp), there are some objects which are deleted to unlink, e.g., Datasets from Images. A data structure (map annotation?) which could record such actions could be re-used and optionally checked to re-attach objects at least when re-imported to the same server.
mtbc
One may conceive of being able to import and export sets of OME top-level objects (especially project, dataset, folder, experiment, instrument, image, screen, plate, annotation, ROI) together with their lower-level subgraphs quite apart from an image-centric view. For instance, https://trello.com/c/QIOQSgRU/13-export-downloads-data-out describes an existing client that can do things like "export the OME-XML representation of every ROI of a plate" and https://trello.com/c/22XfjucX/7-export-re-import describes an attendant import issue: in the schema the link between images and ROIs is part of the image (
ROIRef), not the ROI, so,The same kind of asymmetrical representational issue is true of datasets and images: it is the datasets that bear the
ImageRef.With the above background context, this issue asks the question: Moving beyond image-centricity, if we were to generalize OMERO.server to export and import any top-level schema object separately from other top-level ones, what workflows do we want to support, and how? Export-only would already be useful for IDR (metadata could be processed by remote users) and significantly advanced by https://trello.com/c/FjKjbzio/18-generate-omerometadata but where do we have interest in importing objects back into OMERO and, especially, such that they "merge" or relink, as if restoring part of the database from backup, rather than simply duplicate and orphan?