Added scientific extension for STAC catalogs

[m-mohr]

Originally defined by the dataset group during the STAC sprint 3. Added in advance of the dataset spec as I think this can already be useful and tested before-hand for catalogs and later be adopted by/to the dataset spec.

Includes README, JSON schema and an example.

[matthewhanson]

spelling: citation

[m-mohr]

Fixed, thanks!

[matthewhanson]

You say that the DOI should not be a link, but should the DOI and Publication DOI be included in the links section? I would think so, and if so then some guidance should be given, such as what should be the rel type, and add links to the examples.

Also, it seems possible to me that a dataset might have multiple Publications that describe the dataset, do you think that's reasonable? A data provider might have a document that describes the dataset and use (i.e. a user manual), but another more technical doc that describes the processing. Many datasets I've seen have several relevant user documents.

@m-mohr

[m-mohr]

Thanks for the comments, @matthewhanson.

DOI in links: That's an interesting idea and makes much sense. I added that.

Multiple publications: Usually there is one main document that initially published the dataset. That publication is to be added. Additional information such as a user documentation, technical documentation etc. would belong in the links, I think. But I am open to change the publication fields to sci:publications, which is an array of objects with a doi and a citation:

"sci:publications": [
  {"doi": "10.1000/xyz.2018.1", "citation": "Mustermann, M (2018): An example"},
  {"doi": "10.1000/xyz.2019.2", "citation": "Mustermann, M (2019): Another example"}
]

What do you and others think?

[matthewhanson]

We've been avoiding objects in properties, mainly for searching purposes. But in the case of this extension I think it's fine because I don't see users needing or wanting to search on DOI or citation.

[m-mohr]

And I don't see this as an extension for Items, but only for catalogs/datasets. So there is no real problem to use objects.

@edzer You are probably the best expert for this topic. What do you think about this proposal in general? Anything missing? Is it common to have multiple publications for a dataset or is it usually just one that is introducing a new dataset?

[edzer]

Thanks for pinging me! I think it is quite common, and in general a positive sign, to have more than one publication describing a dataset.

[m-mohr]

Thanks, @edzer. Updated the profile to allow a list of publications. If there are no other comments, this would be my final draft for this extension.

[matthewhanson]

+1

[cholmes]

I think we should consider making an 'extensions' folder in the 'dataset-spec' folder (or whatever we call that folder), where we put extensions that only apply to datasets. I think we might even consider doing an eo specific extension in dataset - it should align field names with the item level eo: spec, but should define what they mean at the dataset level.

[m-mohr]

Hmm, any chance there are extensions that share definitions between entities? I think so (EO/SAR/... for sure, Storage and Scientific could be) and I personally prefer to have one place for extensions. The extension can easily sort out to what entity they apply (i.e. catalogs, items, datasets or any subset of them). We could even make an overview table of extensions and their scope in the README of the extension folder. That makes it easier for users to explore them. We can also reference the extensions from each spec. I just don't like replicating things as this is prone to errors, e.g. fixes in shared fields are screwed up.

[cholmes]

Looks good. I'll merge it in.

[cholmes]

Oh, and on extensions - yeah, I guess I'm cool with extensions sharing one place.