search

ceos-org / ceos-ard

Repository for CEOS Analysis Ready Data (CEOS-ARD), including Product Family Specifications (PFSs)
9 stars 1 forks source link

Single DOI landing page #21

Open m-mohr opened 6 months ago

m-mohr commented 6 months ago

In the PFSes there's often this terminology

Information on X should be available in the metadata as a single DOI landing page

A couple of questions:

Let's looks at an example: The ESA Sentinel-2 L2A data was peer-reviewed to be CEOS ARD compliant.

It seems to have a single DOI landing page in the metadata - i.e. https://doi.org/10.5270/S2_-znk9xsj - in the XML PRODUCT_DOI tag. That I find this DOI landing page there, how do I know this as a user?

As a user that is looking to find the e.g. the information about water vapour (req. 3.5), I have to assume I find that under this page. If there would be two DOI pages in the metadata, it seems I'd need to look at both at there's no necessarily a need to document what the individual DOI pages are meant to provide information about.

As I have only one DOI this time, I'm looking at https://doi.org/10.5270/S2_-znk9xsj . The page says that water vapour maps are included, but doesn't give details about the algorithm as required by 3.5. It generally says "Algorithm used: Sen2Cor – Version 2.10". That's rather uninformative with regards to the requirements, it doesn't list a citable paper without googline Sen2Cor – Version 2.10.

Are people expected to read self-assessments and randomly walk around DOI landing pages? I feel this is not solving what it was meant to solve.

strobpr commented 6 months ago

Hi Matthias, thanks for your questions! Regarding the need for a DOI: It should be the provider of the information (in this case ESA) who creates the DOI, not the one assembling a STAC catalogue. More tricky is the question on the amount of DOI's to be created. We will first need to specify more uniquely what we mean by 'product' which is the entity we ultimately award the 'CEOS-ARD' label. Next we would need to talk about about whether to harmonise the metadata labels (irrespective of their format) where PFS relevant info is associated to. To my knowledge this is not the case in any PFS so far. Then comes the metadata content and whether this has to comply with certain standards. For many fields this is not the case (yet). Ultimately, and that's one of the most challenging issues, we need to define some hierarchy and relations (a sort of ontology) in metadata as otherwiose we'll never finish discussing what needs to be provided where in what detail. That's certainly something I want to raise when meetiong in Delft for the OGCISO ARD SWG where this will be crucial (in my opinion).

m-mohr commented 6 months ago

Regarding the need for a DOI: It should be the provider of the information (in this case ESA) who creates the DOI, not the one assembling a STAC catalogue.

So I can't create a CEOS ARD compliant STAC catalog for Sentinel-3 for example if ESA doesn't provide me with a DOI?

strobpr commented 6 months ago

Well my take would be that it is a product which is certified as 'CEOS-ARD'. While we still need to better define what a 'product' exactly is, it will definitely be more than a catalogue or just metadata. So, you can create a STAC catalogue by harvesting all or parts of the Sentinel-3 archive, but that catalogue is not what qualifies the S3 product to be 'CEOS-ARD'.

If a provider chooses not to fulfill certain threshold criteria by withholding information, his product is not 'CEOS-ARD' regardless on how the metadata are presented. If you as an interim entity undertake to fill this gap and meet all threshold requirements (by e.g. creating missing metadata or setting up a DOI) you become the provider and it is 'your' (derived) product that might be granted 'CEOS-ARD' status, if you file an application.

mattsymbios commented 2 months ago

Just flagging that this DOI requirement is also being question in the Ocean Reflectance PFS development.