externalInfo display

[will-moore]

Since we are starting to use externalInfo in IDR and possibly for other users - see https://github.com/ome/omero-cli-zarr/pull/167/files, it may be useful to display this in web. Glencoe already use this.

Updated description based on discussions below:

• We aim to load externalInfo along with the original objects (instead of an extra lazy loading call)
• getObject() and getExternalInfo() load externalInfo omero-py#453 updates getObject() etc to include externalInfo
• We use that PR and display in the right panel (nothing is shown if externalInfo is not found)
• NB: if the omero-py PR is missing, then this will fail silently since obj.getExternalInfo will not be found. No need for this PR to depend on getObject() and getExternalInfo() load externalInfo omero-py#453

cc @knabar @dominikl

[sbesson]

@will-moore thanks for starting this conversation. As noted above, Glencoe is using ExternalInfo quite extensively so we are interested in ways to expose this metadata via the OMERO.web API and/or UI.

Starting with with your last question, my immediate feeling is that it would be most beneficial to include this functionality in the OMERO.web JSON API. A few reasons for that:

• as explained in https://omero.readthedocs.io/en/stable/developers/Web.html, the /webclient component should be considered as internal only. If the intent is to expose this metadata as JSON for consumption (both internal and external), api/ is the location of choice
• omero-marshal already has support for ExternalInfo encoding/decoding so there is no complex cross-component work
• the usage of ExternalInfo is not limited to Image and can be applied to any object. Glencoe uses this on Mask objects to represent labels for instance. Having api/v0/<images,rois,...>/<id> loading and exposing the external info in a unified manner would be consistent.

On the query itself, my impression is that externalInfo should be treated the same way as other details. I don't expect the additional join to be expensive in terms of query time given these are relatively shallow objects with only a few attributes but that should certainly be reviewed as par of the functional testing.

The UI questions is probably the one where I am the less opinionated and I have a suspicion the answer might be "it depends". For Zarr data, we have used ExternalInfo as an mechanism to store the location of the data. The closest equivalent would be the legacy OMERO pyramids which are not exposed in the UI. The most relevant existing icon would be the ../../. in the right-hand panel which lists the Fileset entries.
However other ExternalInfo objects might be more naturally suited either as Image details or as additional attributes

[knabar]

Agree with @sbesson; I would probably not create a separate view for retrieving externalInfo, but get it with the other object details on an existing call. Any performance hit should be minimal compared to having a whole separate call.

[will-moore]

@sbesson This is now deployed on idr-testing. e.g. https://idr-testing.openmicroscopy.org/webclient/?show=image-15160031

[joshmoore]

As a quick sidenote before I disappear for a week, I'd be more than happy if we hide the acronym "LSID" from users.

[dominikl]

👍 Looks good to me. What does LSID actually stand for, and what is the ExternalInfo actually used for generally @joshmoore ?

[joshmoore]

LSID stands for "Life Science Identifier". https://www.lsid.info/ et al. https://zenodo.org/records/46804 is a pretty good read.

The ExternalInfo object wasn't used a lot previously but was intended to hold info of the objects that felt "too detailed" to expose in the main object. It also helps that if you have an opaque identifier that you don't have to check every table to find the object but you can look in the one external info table.

[will-moore]

https://en.wikipedia.org/wiki/LSID.
@joshmoore "Hide LSID from users" - what about CLI users? - in ome/omero-cli-zarr#167 we have --lsid and in general we try to make the UI reflect the data model.

Do we use another term or just e.g.

http://path/to/my/image.zarr
entityType: com.glencoesoftware.ngff.multiscales
entityId: 3

[joshmoore]

in general we try to make the UI reflect the data model.

"Attribues"? "Attachments"? 😄

what about CLI users?

I certainly worry about CLI users less.

But if we need to keep it, that's fine, just more than the other terms, "LSID" was a mistake.

[will-moore]

As discussed in web meeting, we probably don't want ExternalInfo to be so much "in your face" since it's not of interest to most users.
Could look at hiding it under ../../ or elsewhere.

[will-moore]

Deployed latest changes to idr-testing and updated screenshot above.

[will-moore]

To help testing, you can now set ExternalInfo via the CLI - see ome/omero-py#453