update eumetsat-seviri.json example with the latest standard developm…

[gaubert]

Hi @tomkralidis @amilan17 @jsieland @Amienshxq @solson-nws @josusky,

I have updated the EUMETSAT example prior to create a new one for another EUMETSAT product, I will wait to finalise this one as I have the following comment/questions:

1. temporal information/extent.
I have created the temporal information at the root level using the example from @jsieland (Thanks a lot for the work done btw) https://github.com/wmo-im/wcmp2/blob/main/examples/wcmp2_de.dwd.icon-eps.ALL.json and I have a suggestion. I see some examples provided bluntly without any explanation regarding how to encode the time information. It took me a lot of time to understand how @jsieland had described the temporal information and I only understood it from the description provided in the metadata. It is a particular way of describing the temporal information because it is a forecast with two time dimensions (the model run time and the forecast time). The same forecast time/model run time information could be defined differently. Could we have some information in the example provided in the standard and recommend for all forecast data to define the time information in a similar way ? Otherwise it will be very difficult to take advantage in a portal of the information.

2. Can I get rid of the following information ?
I don't know why it is there anymore. I think that I kept it for being compliant with the WIS but I can't remember why.

{
                "concepts": [
                    "EDHA",
                    "EDHI",
                    "EDHK",
                    "EDJA",
                    "EDMO",
                    "EDOP",
                    "EDTD",
                    "EDTL",
                    "EDTY",
                    "EDVE",
                    "EDXW",
                    "EDZO"
                ],
                "scheme": "https://wis.wmo.int/2012/codelists/WMOCodeLists.xml#WMO_CategoryCode#MD_KeywordTypeCode_place"
            },

and

{
        "concepts": [
            "GlobalExchange"
        ],
        "scheme": "https://wis.wmo.int/2012/codelists/WMOCodeLists.xml#WMO_CategoryCode#MD_KeywordTypeCode_dataCentre"
}

Can I get rid of them ?

3.Format in mime types always ?

I've seen that @jsieland has defined the format without using the corresponding mime type. Should we recommend to always use a mime type ?

        "formats": [ 
            "GRIB2"                                                                         
        ] 

should it be defined using the mime type instead ?

        "formats": [ 
            "application/wmo-grib"                                                                         
        ] 

This is also as we have defined our formats including proprietary formats: (x-eum-msg-native)

"formats": [
            "application/x-geotiff",
            "application/x-jpeg",
            "application/x-png",
            "application/zip",
            "application/x-eum-msg-native",
            "application/x-eum-hrit",
            "application/netcdf",
            "application/x-hdf"
        ],

Thanks once this solve it can be merged in the main branch

[jsieland]

Hi @gaubert,

thanks for the update, I think your questions highlight some aspects we should consider further.

regarding 1.

Good point! We have Rec 5 (/rec/core/extent_temporal) which states to provide a "valid ISO 8601 duration" for time.resolution but we do not indicate anything for date / timestamp / interval. I agree that we should provide more information here.

regarding 2.

This might be from an old METAR example... I would be fine to remove it. Regarding themes/concepts in general I think we'll have some discussion next meeting due to #78 and so this part likely will need adjustement anyway.

regarding 3.

More some additional thoughts than a definitive opinion: As format isn't specified in the spec it falls under 7.1.18. Additional Properties and I wonder if we should add specific recommendations for information about format (then maybe it's worth adding in the spec?) or if we give broad recommendations like "if possible use codelist, standards etc." with corresponding examples like format with mime type (and then we could just add more examples if needed)?

[tomkralidis]

1. Agree to add more descriptive text. @jsieland can you take a first pass?
2. can be removed
3. MIME types should be tied to infrastructure (i.e. links). OGC API - Records defines properties.formats as: "A list of available distributions for the resource.". The question for WCMP2 is whether we want to a. "promote" properties.formats, or b. is this bound to distribution links? What value would a. provide?

[jsieland]

1. Agree to add more descriptive text. @jsieland can you take a first pass?

@tomkralidis yes, I can do that (but not sure if I'll have a draft ready for our meeting tomorrow).

[tomkralidis]

@jsieland no problem RE: timing, thanks!

[gaubert]

I have updated the example file and it can be merged.
Regarding the last question from @tomkralidis and the format property. If we want to build relevant discovery services users will look for the format information so that information is going to be indexed and probably facets or another discovery feature will be used to allow users to select datasets depending on the format. Also if the way to describe the formats is "standardised" this will help creating consistent discovery services otherwise you will x ways to spell the different formats, etc and it will be complicated to build relevant discovery services. We can discuss it during the meeting.

[tomkralidis]

@gaubert RE: formats: see the related TT-WISMD 2023-06-09 discussion.

[tomkralidis]

@gaubert given some time has passed, I will close this PR and await a new one. Note that per #134, your metadata is now in examples/failing/int-eumetsat.seviri.json. So I am looking forward to a PR with the various fixes to pass ETS.