6.0.0

[ppouchin]

Ok. I think I'm nearly done with the 6.0 version (mentioned in #31 and #41), although I'm still wondering if going the "getChildren/getParents" route would have been better: the constant method name is cleaner, but even if I split the HCS and containers hierarchies (getContainerParents/getHCSParents), I'm not sure where plate acquisitions would fit for example, although I could ignore them and just have two hierarchies: Screen/Plate/Well/Image and Project/Dataset/Image...
Also, images do not have children and screens/projects do not have parents, so some kind of RuntimeException would have to be thrown I guess.

Also, it's more of a detail, but I wonder if Project::addDataset, Dataset::addImages and import functions should always reload the parent object. It's helpful in case we forget, but sometimes, it can be a wasteful request to the server. Maybe I'll duplicate the method and overload it so a version exists without the reloading.

I only added ImageLinked, ContainerLinked and HCSLinked one commit ago (on the "6" branch: 5033811) and the names are not very satisfying: it might still go if a standard hierarchy works better. Or I could do both.

A preview of the (possible) API update is available here: https://api.igred.fr/simple-omero-client/6.0.0-SNAPSHOT/
And a "snapshot" is usable from there: https://artifacts.igred.fr/snapshots/fr/igred/simple-omero-client/6.0.0-SNAPSHOT
Everything breaks as I introduced (non-generic) interfaces and repackaged the classes. Removing "Wrapper" from the class names except for constructors should do the trick in many cases.
@Rdornier I kept the "core" package as I didn't know if I should make "image" plural (as "containers") or singular (as "screen") and thought it was easier to globally mirror the OME model.

In any case, I'd like to release it by the end of next week if possible.

[Rdornier]

In any case, I'd like to release it by the end of next week if possible.

Cool !

although I'm still wondering if going the "getChildren/getParents" route

"getChildren/getParents" is more user-friendly beacuse we don't have to test if the image is part of a dataset or plate. But it also means that, if the image is coming from a plate, image.getParent() = wellSample and not just well. Or, if we want to keep the straightforward image->well->Plate->screen, documentation is needed about the implementation of getParent/getChildren and getPlateAcquisition/getWellSample methods have to be separately implemented.

I'm not sure where plate acquisitions would fit for example

In that case, I would put it in getHCSParents because it is only part of HCS data.

I could ignore them and just have two hierarchies: Screen/Plate/Well/Image and Project/Dataset/Image...

This is also an option. I like the straight way image->well->plate->screen and I personally do not use the plate acquisitions. But I think it might be useful to still have access to all HCS hierarchy (PlateAcquisition and WellSample) and adding getters to on of the well or plate layer.

Maybe I'll duplicate the method and overload it so a version exists without the reloading.

This is a good idea to not overload network

@Rdornier I kept the "core" package as I didn't know if I should make "image" plural (as "containers") or singular (as "screen") and thought it was easier to globally mirror the OME model.

Ok

[ppouchin]

Ok. I could try to do both: get objects directly or get them through getParents/getChildren.

I could add getParents/getChildren methods to RepositoryObject and make HCS/Container/Folder inherit from it.

HOWEVER, to prevent code duplication, I put protected import methods in RepositoryObjectWrapper and made it extend AnnotatableWrapper, but Well Samples are not Annotatable (they're the only ones in fact, although the attachAnnotation does attach annotations to the underlying image) and thus only extend ObjectWrapper.

If I make repository objects not annotatable, I have to duplicate the import code to screens and datasets or move the protected methods up, otherwise they can't extend AnnotatableWrapper as well.
Edit: Nevermind that. I should actually just make a superclass specific to Datasets and Screens, like "ImportWrapper" or whatever.

Moreover, I'm a bit lost when it comes to HCS data (as we don't use it here):

• Screens contain plates.
• Plates contain wells.
• Wells contain multiple well samples that can be acquired with different "plate acquisitions" (I need to fix my code BTW).
• Well samples just wrap images and only add the position.

With a getParents/getChildren (or even getHCSParents/getHCSChildren) structure, I'm not sure how to go with that, as wells and plate acquisitions are independent from each other.
Should Plate::getChildren return wells or plate acquisitions?

[Rdornier]

Should Plate::getChildren return wells or plate acquisitions?

To my mind, it should return wells (it's the more intuitive). I didn't really catch the purpose of introducing a plateAcquisition object. As far as understand, it is not possible to get wells from plateAcquisitionData object. Also, I'm confused about the difference between plateAcquisition and the so-called Run that appears in the tree on OMERO.web (they look like the same object).

Here is my understanding of the hierarchy and how I would implement it. PlateAcqusition objects are just a field of Plate object and do not interact with getParent/getChildren

[ppouchin]

Indeed, "plate acquisitions" do represent different runs for the same plate/wells and are linked to different "well samples": https://docs.openmicroscopy.org/ome-model/5.6.2/developers/screen-plate-well.html#plateacquisition

But that only means that these runs can be used to differentiate well samples inside wells, the main tree is "screen/plate/well/well samples".

Currently the "repository objects" only share the "getName/getDescription" methods (that Well Samples cannot have), which is not very useful.
I can add getParents/getChildren to this interface instead, but these methods will only return a List<RepositoryObject>... which can only provide children or parents. The type of objects will not be determined, and these lists will need to be filtered and cast to retrieve a specific type (like Plate or Dataset).

[Rdornier]

I could try to do both: get objects directly or get them through getParents/getChildren.

I can add getParents/getChildren to this interface instead, but these methods will only return a List... which can only provide children or parents. The type of objects will not be determined, and these lists will need to be filtered and cast to retrieve a specific type (like Plate or Dataset).

This is a suggestion, but what about having getParents/getChildren in the interface and object getters in the wrapper ? In that case, if we work with generic object, we can call for getParent and in case we work with defined object like datasets, it is possible to directly call getProject.

[ppouchin]

I was going to have both interfaces anyway: RepositoryObject for parents/children, and HCSLinked/ContainerLinked for direct access.
Although "Well Samples" are a bit annoying: if we skip them, then RepositoryObject can be Annotatable and have a name.

Also, I'm wondering if making Annotation and "containers" ContainerLinked is good or not.

[Rdornier]

I was going to have both interfaces anyway: RepositoryObject for parents/children, and HCSLinked/ContainerLinked for direct access.

Ok

Also, I'm wondering if making Annotation and "containers" ContainerLinked is good or not.

For Annotation, I think it can be ok because all kind of annotations are related to a container or an HCS container ( Annotation have to be ContainerLinked and HCSLinked as well).
For "containers", it's a bit more difficult to say. You need to handle the result of project.getProject() (same with dataset). I would rather not make them ContainerLinked and just add simple methods getDatasets for Project and getProjects for Datasets. But I understand the use of the interface here to make the code more generic and it make also sense to keep it.

[ppouchin]

Ok. I'm really too slow.
I've fixed the relationship between Well Samples and Plate Acquisitions, and added getParents/getChildren:
https://api.igred.fr/simple-omero-client/6.0.0-SNAPSHOT-2/
I've also removed ServerException.

I'm checking a few things, adding back the "*Linked" interfaces (not sure) and it should be good.

Edit: I'm also going to add checks for "tag sets".

[ppouchin]

I'm still integrating things I developed in 2023 on the main branch, but I'm not yet on "Repository Objects" and such.

However, I'm trying to simplify TableBuilder and ROI conversion. I'm thinking of removing the liberty to choose the property where ROI indices/IDs are stored, to only use ROI/ROI_ID/ROI_NAME for ROIs, as I only use "SHAPE_ID" for shapes and "IMAGE_ID" for images.

Removing it would somewhat reduce code complexity (checks and such), and it would probably help to recognize "ROI" columns if there are several of them in a table.

I wonder if this functionality is used though (meaning no more roi.toImageJ("MY_PROPERTY").

[Rdornier]

I wonder if this functionality is used though (meaning no more roi.toImageJ("MY_PROPERTY").

I didn't use it so far. So, I think you can go like this 👍