ivoa-std / DAP

Dataset Access Procotol (name TBD)
Creative Commons Attribution Share Alike 4.0 International
1 stars 3 forks source link

review of OpenDAP interface/capabilities #4

Open BaptisteCecconi opened 1 year ago

BaptisteCecconi commented 1 year ago

Anyone in the authors have looked into OPeNDAP? (documentation is here)

Of course this is not IVOA, not FITS. It is Earth observation and NetCDF (mostly). But it contains a lot of capabilities and features that I would be very happy to see implemented.

Beware that this ecosystem also has an interface called DAP (Data Access Protocol).

pdowler commented 1 year ago

We are open to alternate names if we can can come up with something that improves. There is always the question of whether P(rotocol) needs to be in the name - it is is SIAP-1.x and TAP-1.x and not in SIA-2.0

I had kind of favoured Simple Data Access (SDA-2.1 as the successor to SIA-2.0), where Simple nominally means "query parameters" rather than "query language" and there is a fixed data model (ObsCore).

Probably since the model used to be referred to in the protocol spec, this could refer to ObsCore... Simple ObsCore Access (SOA)? Simple ObsCore Query (SOQ) since access is really covered by DataLink and SODA?

soooo many possibilities... :-)

molinaro-m commented 1 year ago

If you like going for abused and conflicting ones there's

Parametric Observational Dataset Search

that embeds parameters query, meant for observations, related to datasets in general and has the search like in Cone

BaptisteCecconi commented 1 year ago

My initial comment included the issue on the name, but I’m serious about the study of that other DAP interface. For once, it may be an occasion to build up interoperability with a wider community.

molinaro-m commented 1 year ago

From a quick skim through the OPenDAP documents, it seems to me that it spans more than the purpose of the IVOA DAP, going from discovery of services to filtering on them, including specific access based on the abstract representation on datasets (including basic datatypes mappings and others), so it goes from something like Registry up to DataLink/SODA, via models and annotations and ReST resource specific syntax (reminds me of HAPI for time series in a sense).

What might be looked after is the way request/response are built, since I feel we always struggle a bit about how to build and alert about query parameters. I only wonder how to cope with SIA/SODA idea of having the same parameter calls if we change that way (need not loose the existing solutions).