You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I wanted to discuss here the integration of the concept of namespace for key-value pairs. This is a feature I planned to implement in the OMERO-BIOP extension, but I found more useful to do it there, as this extension is on the way to replace ours.
A namespace is like a category inside which you can group multiple annotations (mostly KVPs and attachments). This concept is very nice and useful to sort the different annotations and classify them on OMERO.
Currently, both OMERO extensions simply import from OMERO all KVPs, whatever the namespace. I recently noticed that it can lead to some issues if certain KVPs, under a particular namespace, contain keys identical to those of the KVPs under another namespace. Due to the restriction we did to force not having duplicate keys, KVPs cannot be imported into QuPath. But in practice, only KVPs under a certain namespace need to be imported into QuPath.
To solve that, I was thinking of giving the choice of the KVP namespace at the import, with a drop-down menu or textField. On QuPath side, I don't expect to add the namespace info somewhere ; KVPs will be stored as they are currently stored.
By default, if no namespace are set by the user or if KVPs are, at some, automatically imported, only KVPs from the default qupath namespace are imported.
When send qpmetadata to OMERO, then I'm thinking of having a different GUI where it will be possible to select individually which metadata the users want to send (a bit like the run for project GUI does with selecting images) and to select in which namespace to send them.
Doing like this, I think it could work ok to deal with duplicated keys in different namespaces. Of course, within a particular namespace, the duplication key restriction will still be applied.
As this is a completly new feature, I'll be happy to help you devlopping it and to read what you think about it
Rémy.
The text was updated successfully, but these errors were encountered:
I wanted to discuss here the integration of the concept of namespace for key-value pairs. This is a feature I planned to implement in the OMERO-BIOP extension, but I found more useful to do it there, as this extension is on the way to replace ours.
A namespace is like a category inside which you can group multiple annotations (mostly KVPs and attachments). This concept is very nice and useful to sort the different annotations and classify them on OMERO.
Currently, both OMERO extensions simply import from OMERO all KVPs, whatever the namespace. I recently noticed that it can lead to some issues if certain KVPs, under a particular namespace, contain keys identical to those of the KVPs under another namespace. Due to the restriction we did to force not having duplicate keys, KVPs cannot be imported into QuPath. But in practice, only KVPs under a certain namespace need to be imported into QuPath.
To solve that, I was thinking of giving the choice of the KVP namespace at the import, with a drop-down menu or textField. On QuPath side, I don't expect to add the namespace info somewhere ; KVPs will be stored as they are currently stored.
By default, if no namespace are set by the user or if KVPs are, at some, automatically imported, only KVPs from the default
qupath
namespace are imported.When send qpmetadata to OMERO, then I'm thinking of having a different GUI where it will be possible to select individually which metadata the users want to send (a bit like the
run for project
GUI does with selecting images) and to select in which namespace to send them.Doing like this, I think it could work ok to deal with duplicated keys in different namespaces. Of course, within a particular namespace, the duplication key restriction will still be applied.
As this is a completly new feature, I'll be happy to help you devlopping it and to read what you think about it
Rémy.
The text was updated successfully, but these errors were encountered: