International Virtual Observatory Alliance

Difference: Obscore-1_1-Next (1 vs. 2)

Revision 22024-04-15 - MarkusDemleitner

META TOPICPARENT	name="IvoaDataModel"

This page collects proposals for modifications to ObsCore 1.1, leading up to 1.2

Proposed new Features

Changed:

<
<

None yet

>
>

Define a way to discover s_region usability

Added:

>
>

A major pain when doing "blind" obscore queries is that it would be nice to query against s_region (because it is so much more flexible and reliable than s_ra, s_dec, and s_fov), but support for s_region is not universal.

Probably the easiest way to fix this would be to say "if you give s_ra and s_dec, you MUST give s_region". That would be my preferred solution, actually.

Alternatively, there should be a way for data providers to say "you will not get extra false negatives if you use s_region over s_ra and s_dec on this table". Ideally, this would not require Registry interaction; and actually, the Registry does not have an out-of-the-box mechanism for something like this either. We would have to define an Obscore registry extension for such a flag, and that seems overkill to me at this point.

I wonder if we should'nt just have a hack and say "if your s_region column is fine, add the literal string 'safe-for-queries' to s_region's description". Yes, this may seem to radiate a bit of bad karma, but it works nicely with both TAP_SCHEMA and VOSI, which is nice and seems hard to attain with just about anything else.

Another alternative that has this property would be to change the s_region's UCD or utype for query-safe (or non-query-safe?) s_region columns... hm.

Proposed modifications

Improve Sample Queries

The example queries in the appendix should not show people

Changed:

<
<

split-coordinate spatial constraints (s_dec<20 and friends) and rather

>
>

split-coordinate spatial constraints (s_dec<20 and friends) and rather

use proper geometry constraints (circles or polygons). Coordinate queries are often not covered by indexes and are rarely a good idea physically.

Also, it would be good if we could include at least one or two examples which show how to just retrieve a subset of columns; "select *" may be appropriate for certain use cases, but just pulling the data one needs for a certain use case is better use of resources. This may in general not be dramatic in your average obscore query, but when people to statistics on millions of matches, it does matter.

-- MarkusDemleitner 2023-01-16

<-- 
 
 
 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Revision 12023-01-16 - MarkusDemleitner

META TOPICPARENT	name="IvoaDataModel"