Formats' file extensions vs synonyms

[matuskalas]

This issue is about both improving the user experience, and steamlining the development|maintenance work (& cleaning + clearing up) with respect to file extensions. Points to keep in mind or consider:

• file_extension in EDAM is always lower case and should stay like that (just repeating the fact)
• synonyms are searchable in ontology browsers
• we may consider making file_extension a sub-property of hasExactSynonym, but that would disable the possibility of same file extension for multiple formats. Unless we revise the synonyms uniqueness rule (in such case consider also related_term to be non-unique)
• double-check that ontology-browser searches are case-insensitive
• maybe we want to avoid copying file_extension to hasExactSynonym(with capitals there). Or have at least very clear rules when to do that and when not.

[joncison]

Thanks for this.

I'm not keen on making file_extension a sub-property of hasExactSynonym - these attributes are fundamentally different types, and it would be confusing / overly complicated to model them like that.

Better (as an EDAM design pattern) to clone all file extensions into hasExactSynonym - thus making them searchable - then have a QA/QC rule/check to enforce that.

I think the capitalisation thing comes in only (and really only) when there is a "canonical" upper-case file extension - there are some of these I think. And for those the key thing is whether the browsers are capitalisation-insensitive, as you say (I suspect they are and thus its a non-issue)

[joncison]

@matuskalas this boils down to two checks for edamverify - once those checks are implemented we can close this issue.