Constraints on the title of a collection

[havardf]

Typical use-case: Client populates a selection menu with title of collections.

Some potential rules:

• Mininum and maxium number of characters.
• No acronyms.
• How to handle multiple languages? Should we handle multiple languages?

[havardf]

What about these rules for starters:

• Must be in english.
• No longer than 50 characters.
• Normal casing of characters.
• Only widely understood acronyms and abbreviations.

We can then add these to the profile now, and update later as needed. It would anyway be good to add something quickly, so it is easier for everyone later to contribute.

[mrauhala]

We should handle multiple languages. I think best way to do that is to have parameter such as lang=fi and then responses would be in that language. CoverageJSON does have something for the i18n, but that does not solve the whole problem.

Default would be English, which must always be available.

[mrauhala]

Title is now missing from many of the services. Should we say that it is mandatory, otherwise clients will default to collection id, which is maybe not optimal for user interfaces and leads to not optimal lists for the user.

[havardf]

I say definately yes. Maybe like this:

Mandatory and with the following rules:

• max 50 characters
• english text
• Describe the collection topicly and geographically. As in, "Surface observations in Europe" for E-SOH, not just "Observations".

[mrauhala]

There have been a lot of discussion internally in FMI about naming conventions, it is not easy, but one thing we observed was that names should have the most "important" bit first / near beginning of the string so if UI needs to truncate title, relevant part is not dropped. Your example follows this "Surface observations in Europe"

[geira]

Prohibiting acronyms could cause problems when they are often more recognizable than what they originally stand for, e.g.

• TAF/METAR
• CBRN
• MEPS
• NOAA
• ECMWF

[tomkralidis]

A title of "surface weather observations from NOAA" is not helpful to the actual content. Here, "NOAA" is a property of the entire record, as the organization.

[geira]

I actually had a specific example in mind:

https://labs.metoffice.gov.uk/edr/collections?f=html

[tomkralidis]

Which collection? I am guessing the collections with "UK" as part of the title (perhaps "Airfields in the United Kingdom" would work better here?).

[geira]

Ignoring "UK" and "EDR", the following collections have titles with acronyms which would exceed the 50 char limit if expanded:

• Met Office (UKV) station level
• Met Office (UKV) Soil Temperatures
• Met Office (UKV) data at standard heights
• Met Office (UKV) data at standard pressure levels
• Met Office (UKV) whole atmosphere
• ECMWF (Global) station level ensemble medium-range forecasts
• ECMWF (Global) isobaric levels ensemble medium-range forecasts
• ECMWF AIFS Machine Learning surface data
• ECMWF AIFS Machine Learning isobaric data
• NOAA Graphcast station level data
• NOAA Graphcast isobaric data

[tomkralidis]

What value does "NOAA" have in an actual title? Can a user not derive this from the collection metadata itself?

[geira]

Well, the only other relevant metadata field available under /edr/collections is description, which is not always displayed unless reading the JSON manually (e.g. you can't see it when using Swagger UI).

I feel this is more of an issue for forecast data than for observations. When quering simulation data it is essential to know which model you are using, and these are more often than not named using acronyms (MEPS, AROME, ECMWF Hi-Res, UKMO, GFS, HRRR et al).

[tomkralidis]

Is Swagger UI a requirement then? Note that there needs to be some provision around description for fulsome, descriptive metadata.