Warning: Can't synchronize with repository "(default)" (/home/git/ome.git does not appear to be a Git repository.). Look in the Trac log for more information.
Notice: In order to edit this ticket you need to be either: a Product Owner, The owner or the reporter of the ticket, or, in case of a Task not yet assigned, a team_member"

User Story #1650 (new)

Opened 15 years ago

Last modified 8 years ago

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

Reported by: jamoore Owned by: jamoore
Priority: critical Milestone: GatherReqs
Component: Model Keywords: ImageImageLink, Annotations, schema, dbmodelcompare, hold
Cc: jburel, wmoore Story Points: n.a.
Sprint: n.a. Importance: n.a.
Total Remaining Time: n.a. Estimated Remaining Time: n.a.

Description (last modified by wmoore)

Linking Objects

There is a requirement from the users that there should be a mechanism to link images to other images, roi to roi and roi to images. This mechanism should also allow some logic to be placed on the link describing the relationship between objects. The relationship should have a qualifier defining what created that relationship.

As a first draft the relationships will be defined by a predicate, a list of the initial predicates are:

  • Associate
  • Aggregate
  • Compose
  • Derive

The link should also have a namespace associated with it, describing the operation creating the relationship.

For instance an image that was created using delta vision deconvolution algorithm should look like:


This will require the creation of 3 tables: imageImageLink roiImageLink roiRoiLink

Additional examples of RDF-type relationships between "images" (3D volumes or EM maps) http://www.ebi.ac.uk/~best/emdb/341/rich_submission_schema.html, including transformation matrices as link attributes for mapping one image/map onto another.

Another use case of Image - Image (or Image - ROI links) for correlative EM - EM Figure from this Article


  • namespace on the link
  • unidirectional

Change History (18)

comment:1 Changed 14 years ago by jmoore

  • Description modified (diff)
  • Summary changed from (Re)add RoiRoiLink or similar mechanism to (Re)add RoiRoiLink or similar mechanism (also ImageImageLink)

comment:2 Changed 14 years ago by jburel

  • Cc jburel wmoore added
  • Description modified (diff)
  • Keywords ImageImageLink Annotations added

comment:3 Changed 14 years ago by wmoore

  • Description modified (diff)

comment:4 Changed 14 years ago by 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?

comment:5 Changed 14 years ago by 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.

comment:6 Changed 14 years ago by 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.

comment:7 Changed 14 years ago by 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?

comment:8 Changed 14 years ago by 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.

comment:9 Changed 14 years ago by wmoore

  • Description modified (diff)

comment:10 Changed 14 years ago by ajpatterson

XML work in #1863

comment:11 Changed 14 years ago by jmoore

  • Milestone changed from OMERO-Beta4.2 to Unscheduled

comment:12 Changed 12 years ago by jburel

Following February dev meeting, good to review the notes of the ticket.

comment:13 Changed 11 years ago by ajpatterson

  • Keywords schema added

comment:14 Changed 11 years ago by ajpatterson

  • Cc dzmacdonald removed

comment:15 Changed 11 years ago by ajpatterson

  • Keywords hold added

Hold, solution currently to use alternative storage (Tables)

comment:16 Changed 11 years ago by ajpatterson

  • Keywords dbmodelcompare added

comment:17 Changed 11 years ago by ajpatterson

  • Milestone changed from Unscheduled to Future

comment:18 Changed 8 years ago by jamoore

  • Milestone changed from Future to GatherReqs
Note: See TracTickets for help on using tickets. You may also have a look at Agilo extensions to the ticket.

1.3.13-PRO © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.80505 sec.)

We're Hiring!