Adding a tag field to handle OMERO tags

[Rdornier]

Feature request

Issue
Metadata fields are perfectly suitable for OMERO Key-value pairs but there is no way to propertly handle OMERO tags in QuPath.

Description of the solution
As tags are very useful in OMERO to search for images, it could be great to also have a tag field in QuPath.

Tag field attributes

• value (unique => no duplicate possible)
• used to sort the images within the project
• maybe other attributes mirorred from the Metadata field object that I'm not aware of.

[petebankhead]

Can you explain in more detail what would need to change to support this?

I don't have much experience of OMERO tags, but it sounds like what you're suggesting could either be handled entirely in the OMERO extension already (using QuPath's existing metadata support for project entries), or else could risk projects becoming more OMERO-specific (which I'd like to avoid).

[Rdornier]

Actually, tags are one key-word annotation.
Currently, the metadata field works as a dictionnary. My suggestion is to add a one-keyword metadata field

it sounds like what you're suggesting could either be handled entirely in the OMERO extension already

Maybe... I don't think it is optimal nut having the same value as the key could work, using existing QuPath's metadata

[petebankhead]

Actually, tags are one key-word annotation.

Ah... makes sense.

My suggestion is to add a one-keyword metadata field

Sounds sensible, but I wonder is it possible that people will then want tags with different interpretations?

The alternative I'm thinking is to simply have a dictionary entry

{
   "omeroTags": "tag1, tag2, tag3"
}

but I don't know whether it's safe to use a comma (or anything else) as a delimiter.

Otherwise, I guess there could be a general tags list in a QuPath project entry.

Do you think either option is strongly preferable to the other?

[Rdornier]

but I wonder is it possible that people will then want tags with different interpretations?

Yes, this is also true.

The alternative I'm thinking is to simply have a dictionary entry
{
"omeroTags": "tag1, tag2, tag3"
}

but I don't know whether it's safe to use a comma (or anything else) as a delimiter.

Actually, I already thought of the solution but our final goal would be to sort the images within the current project according to one or more tags.

Otherwise, I guess there could be a general tags list in a QuPath project entry.

I would rather go for this solution as I think it is the best way to make them independant and searchable.

[petebankhead]

How would the sorting look? Would there need to be multi-level sorting?

QuPath's current sorting logic based upon the 'metadata' dictionary is... not great. I don't think it can really increase in complexity without breaking, so my feeling is we should also think broadly about how projects are displayed, sorted, and incorporate both metadata and tags.

[Rdornier]

Well, with the current way of sorting, I wasn't expect more than one-level sorting (i.e. sort by tag1, or tag2).
Ideally, it would be great to sort by more than one tag (i.e. sort by tag1 and tag2, like the way it is done in OMERO => multiple levels). This logic could also be mimic for metadata by having multiple nested expend trees

I think both metadata and tag could follow the same sorting logic. The key(s) / tag(s) used to sort the images could be written in the project tab, like in this example.

Also, having a default option to sort by image name would be nice :)