search

ivoa-std / ObsCoreExtensionForRadioData

ObsCore model extension for radio data
Creative Commons Attribution Share Alike 4.0 International
0 stars 6 forks source link

Specify operations and discovery #43

Closed msdemlei closed 2 months ago

msdemlei commented 6 months ago

This replaces the implementation section with one that discusses ivoa.obs_radio, the way to join it with obscore, and then a section on registration and discovery.

kettenis commented 6 months ago

Using a NATURAL JOIN seems a good compromise between ease of use and having the flexibility to provide extension information for a subset of ObsCore records. I think that makes sense since there are discussions about future ObsCore extensions for high-energy observations and time-domain observations. It is entirely plausible that radio observatories would have archives that contain both visibility data products described by this radio extension but also Pulsar/FRB observations described by a time-domain extension.

That said, should the ivoa.obs_radio schema include a mandatory obs_publisher_did column (and maybe also obs_id) to make sure there is at least something to join on?

msdemlei commented 6 months ago

On Wed, Dec 13, 2023 at 03:08:27AM -0800, kettenis wrote:

That said, should the ivoa.obs_radio schema include a mandatory obs_publisher_did column (and maybe also obs_id) to make sure there is at least something to join on?

At first I thought I'd like the idea, but it has the big disadvantage that without a lot of magic, this means SQL engines will join on at least obs_publisher_did no matter what.

That is probably acceptable if we all agree that obs_publisher_did is part of a primary key for both obs_radio and obscore (individual providers can always have other primary keys that are computationally cheaper and hence would probably be preferred by the query planner). But I'm not sure everyone agrees on that.

Also, the case that there's nothing to join on at all is already ruled out by "will yield per-dataset rows of obscore and radio extension metadata" (or so I hope). Still, having some reliable, stand-alone id column in obs_radio sounds like a reasonable thing to want.

Perhaps we should have an issue on this and revisit it once there are other implementations? For the record, for DaCHS it would be trivial, because it will always join on obs_publisher_did (only).

BaptisteCecconi commented 3 months ago

It seems that my recent comment on #49 is related to the changes proposed here.

msdemlei commented 3 months ago

So, I've rebased on the current main branch, which was nasty because of the whitespace changes. If you don't merge is soon-ish, please at least cherry-pick the whitespace commit, or following changes in main will keep being painful.

But, really, my preferred way of continuing would be that you just apply whatever changes you see fit to this PR (you can push into this branch) and then merge. I'll complain if I see something I don't like...