(Re)add RoiRoiLink or similar mechanism (also ImageImageLink)

[jmoore]

What are the current options for the representation of the predicates? I imagine:

• link inheritance: a ComposeImageImageLink, AggregateImageImageLink, ... If it weren't for the need for separate ImageImageLink, RoiRoiLink, etc. this wouldn't be such a problem.
• enum: another table which defines these values (eventually, these would be code-generated static values, not a table)
• a string: should this then be encoded in the NS?
• ...

Another issue: unidirectionality (which in practice may or may not be a blocker)

• Should we use something other than the standard links (DB)?
• Would that be a top-level object?
• Is there a way to encode the roi/roi and image/image links all in one structure? E.g. an image-image link with optional rois on each side. (Too complicated? Definitely not RDF.)

Also, what are the use cases for the RoiImageLink?

[jmoore]

A few more comments:

• I realized that RoiImageLinks are most likely for top-level (unattached), template rois.
• There are cases where a predicate may be multi-valued. Aggregate, for example, is actually a collection of several images. We discussed walking the links to build the complete graph, but would a (possibly ordered) collection be more useful? Then, predicates would become another container type (similar to dataset) and the links from the container to the images could still have namespaces (and possibly other information like how to perform the aggregation).
• finally, the DB representation of RoiImageLink and RoiRoiLink are both dependent on the outcome of WorkPlan/RoiStorage.

[wmoore]

Use case for RoiImageLink : E.g. Single-particle work-flow (EM). Start with large image 4k X 4k or bigger, pick particles (ROIs) from the image, create new images from these regions, process these further (CTF correction etc), classify these and make an average of each class, use these projections for 3D reconstruction.

In this work-flow, you need to know which ROIs the single-particle images came from. All the rest of the work-flow can be described with ImageImageLinks.

[jmoore]

Will, if that's the case, would a special kind of ImageImageLink with an added ROI field work? This would then even allow using template ROIs (which don't have an Image). In terms of the predicates, this could be something like a "Subsection" or "Zoom". In a way, it's the reverse of "Aggregate", right?

[jmoore]

.#2 Modelling TS 15:51 ([[OmeWork#195]])

 - Links
  -- Predicates: "aggregate", "compose",...
  -- Similarity of ns & predicate
  -- Predicates as types
  -- Chris: seems like a lot of complexity
  -- stitching implies an order, need x/y
  -- Donald: square peg in a round hole
  -- Will: immediate requirement?
   --- Jean-Marie
    ---- ImageImage: import of LIF file (another container)
    ---- LSM has MDB. People aren't happy when they come to OMERO.
    ---- Projection/Deconvolution
    ---- Currently using wiki links (slowly abandoning it)
  -- Josh: XmlAnnotation?
   --- throwing it in an RDF store with an interface
   --- the UI would have to take it and do more work with it
   --- Chris: a bit storage is an academic exercise
  -- Will: EM 1000s of links for one workflow
  -- (Probably Holding off on ROIs)
  -- Donald: Multiple solution for this problem
   --- image container, have seen that # of datasets doesn't scale
   --- Jason: mostly the 2.3 version (PE)
   --- Chris: counts are less expensive (views)
   --- Jason: you can always get yourself into trouble
  -- Josh: generic containers?
   --- getting us towards a "desktop" container
   --- SPW, PDI, FS, EM, ...
   --- Chris: all becomes "folder", NS on the folder.
   --- "Project","Dataset","Screen", ("Plate","Well",...)
   --- Jean-Marie: reluctant for plate and well
   --- "why can't I put these 6 plates and 50 images in same dataset?"
   --- Jean-Marie: flexibility being solved by FS/data-dupe work.
    ---- trying to decide how to represent containers that don't support
    ---- ImageImageLink was trying to improve our acceptance
    ---- Chris: enough to relax the hierarchy (N-depth)
   --- Donald: will we run into the issues of tag/tagsets
    ---- running into NS issues
    ---- calls are tricky, flattened the hierarchy
   --- Jean-Marie: only a display issue?
    ---- grouping them for a smart dataset
    ---- Chris: essentially adding a third layer (4th with ROI)
    ---- Chris: just make it N-layer to prevent pain layer
    ---- Donald: N-layer hierarchy is what I'd like, not in DB.
   --- Josh: primary user experience would become folder-based
   --- Donald: are we building our own CMS
    ---- Chris: "Why can't I attach anything anywhere?"
   --- Will: Image/Image links
    ---- go to the container, and then see all the images
   --- Josh: gets us toward OME 5.0
  -- Jean-Marie
   --- only using the description in wiki/rdf
   --- user notices the link and creates a smart browser
   --- Chris: burden of complexity on client? (put it in IContainer)
   --- Donald: won't scale beyond the leica stuff
   --- folks in Portugal don't like it today. quicker solution.
   --- Chris: advocate using an annotation to be easier to upgrade.
   --- Josh
    ---- IContainer.parseFormat()
    ---- requires python upgrade
    ---- ann with NS +1
    ---- on container +1
   --- Andrew
    ---- What are we solving? LSM
    ---- Tiling, projections, ...
    ---- We're defining an OME extension in OME-XML
    ---- Donald: objects
    ---- Jason: x-start/y-start proposal on image (width? height?)
  -- leaving early.

[ajpatterson]

XML work in #1863