Hi everyone!
I have a couple questions about the use of uppercase in Rubin table names, columns and TAP services. I noticed that the documentation (https://sdm-schemas.lsst.io/) describes many fields having uppercase (e.g. dp1 → Object table → coord_decErr). The same convention is exposed by the TAP service when looking at the available tables.
The tutorial notebooks (e.g. dp1 102_*) show examples where the queries are done respecting those exact names (something like “SELECT TOP 10 coord_ra, coord_dec, g_cModelMag FROM dp1.Object”) , although I tried with “SELECT TOP 10 coord_ra, coord_dec, g_cmodelmag FROM dp1.Object” and it also works. The column names on each query result match the respective queried column names.
When looking at other TAP services around the world, the column names are always (as far as I’ve seen) in lowercase. Why did Rubin decided to use mixed-casing? It’s something like snake_case + camelCase.
I’m developing some services for users in the ALeRCE broker and I’d like to keep the same naming convention as Rubin, but at the same it behaves differently to other astronomical services. When querying “select top 10 ObS_Id, S_ra, s_dEc from ivoa_des_dr2.obscore” from https://datalab.noirlab.edu/tap, it works but i get the answer in lowercase. This is fine because SQL is supposed to be case-insensitive and the reported column names by their TAP service (as it’s the case for any other TAP service) is in lowercase.
I have a couple design alternatives from the ALeRCE side, like enforcing the use of the exact Rubin names, but that will require annoying stuff like forcing our users (which are Rubin users) to use quotes around the fields they want to retrieve. Another way to go is the standard behavior where the user can write the query in any casing, but the names are shown by our service metadata in lowercase, as well as the names of the fields in the answer we provide.
It would be great to understand the reason behind the choice of this naming style in Rubin to help guide our decision, and also if it required some special considerations from your teams behind RSP, qserv and other services. I’m also interested to know what behavior would users prefer.
Cheers,
Ignacio Reyes Jainaga
The ALeRCE broker