More generic DAP such that specific parameters define ObsDAP analogous to ObsTAP?

[trjaffe]

The draft says:

These choices are not suitable for all domains; the values are chosen to enable the query resource to be used to search for most standard observational astronomy data. If they are not suitable for a specific domain of interest (e.g. planetary science) then it is feasible to write a very short standard that re-uses the DAP query capability but redefines the hard-coded systems and units. This new standard would have a new standardID to distinguish services that implement it from those that implement the capability defined here.

As TAP defines a generic interface and ObsTAP is how we refer to a TAP service that serves a database in the ObsCore data model, should this also be more generic? The doc says that you'd need a separate standard to define the equivalent for planetary. But in the TAP case, we already have a document describing each data model, and a document describing the TAP protocol, so there's no need for an additional document describing ObsTAP. Should we set this up similarly such that only one new standard is needed, clarifying how any generic data model is used in the simple, parametrized, generic Data Access Protocol? Otherwise this needs to be renamed to indicate its dependency on ObsCore, because it is not generic.

(Though since "ObsDAP" sounds a lot like "ObsTAP" when spoken, that would argue for calling this generic protocol something else, maybe with a "Simple" in the name or a "Parametrized".)

[pdowler]

In the TAP world, you have ObsCore + TAP + ADQL which together enable usersto query. Or you have RegTAP instead of ObsCore...

There is a little confusion because we sometimes say ObsCore (DM) and sometimes ObsTAP. ObsCore is really just the relational mapping (suitable for TAP) and not, I would claim, a complete standalone data model. That was originally on purpose, because it was intended to be something people could implement as a view on their own bespoke/internal/archive database.

SIAv2 re-used ObsCore as the "output model" and defines parameters to query that model, so most of what's in SIAv2 (and here in DAP) is really replacing ADQL with a parameterized query language (in the style of other DAL S??? services). So, TAP + ADQL for fully general query capability (any DM) and ObsCore + params for "simple" query capability.

There was an acronym PQL that circulated for quite some time in the past, but it turns out to be hard to specify it and decouple it from the model.... and it's relatively easy to specify with respect to a specific model (like ObsCore). But then yes: you need to do that again (a little bit differently) for EPN.