Epn spatial frame type

[BaptisteCecconi]

No description provided.

[BaptisteCecconi]

This is a proposal for including epn-spatial-frame-type vocabulary, as defined in EPNTAP 2.0 specification.

[msdemlei]

On Wed, Jul 09, 2025 at 09:37:19AM -0700, Baptiste Cecconi wrote: BaptisteCecconi left a comment (ivoa-std/Vocabularies#41) This is a proposal for including `epn-spatial-frame-type` vocabulary, as defined in EPNTAP 2.0 specification.

First, the name really shouldn't contain "epn"; vocabularies should not appear to be tied to a particular standard (the vocabularies with "voresource" or "datalink" in their URIs were an early mistake). Then, I was worried that this might somehow interfere with our existing refframe vocabulary. Fortunately, it doesn't; this is what the old STC called "coordinate flavour"; this is a notion that is distinct from the frame, and you could indeed use, say, the ICRS refrence frame not only with #spherical coordinates but, if you wanted to, also with, say, #cartesian. So, it's a different universe of discourse. Whether the flexibility of a vocabulary is a good thing for something as fundamental (it would seem to me that programs will always need new code when a term is being added here, and I don't think there is much potential to exploit hierarchies here) is another matter. But if you think it helps, I'll not stand in the way. It is certainly a good complement to refframe and refposition and might one day come in useful in VOTable's COOSYS, too. I'm not sure I am too fond of the name "spatial frame type", because it's too close to refframe for my taste. Perhaps coosys-type would be a more unique designation? "flavor" was the language that STC 1.03 used, which I never liked too much either. Perhaps it's time to consult a math textbook... Aw, not yet :-) In the vocabulary description, I'd again like to tone the reference to EPN-TAP down. I'd rather say "This vocabulary enumerates types of spatial coordinate systems, i.e., sets of axes. To give concrete coordinates a meaning, one will almost always also have to define the reference frame (see the refframe vocabulary) and often the reference position (see the refpossition vocabulary). This vocabulary is used in EPN-TAP's spatial_frame_type column." or so. I am fairly severely opposed to #none. I'm not sure why EPN-TAP 2.0 had this custom NULL value, but they are almost invariably a mispattern. Or is there actually a semantic difference between spatial_frame_type is null and spatial_frame_type='none'? Technically, this vocabulary could be reviewed with EPN-TAP 2.1 -- is that your plan, too?

[BaptisteCecconi]

On Wed, Jul 09, 2025 at 09:37:19AM -0700, Baptiste Cecconi wrote: BaptisteCecconi left a comment (ivoa-std/Vocabularies#41) This is a proposal for including epn-spatial-frame-type vocabulary, as defined in EPNTAP 2.0 specification.
First, the name really shouldn't contain "epn"; vocabularies should not appear to be tied to a particular standard (the vocabularies with "voresource" or "datalink" in their URIs were an early mistake).

ok, that's easy to fix. No problem.

Then, I was worried that this might somehow interfere with our existing refframe vocabulary. Fortunately, it doesn't; this is what the old STC called "coordinate flavour"; this is a notion that is distinct from the frame, and you could indeed use, say, the ICRS refrence frame not only with #spherical coordinates but, if you wanted to, also with, say, #cartesian. So, it's a different universe of discourse. Whether the flexibility of a vocabulary is a good thing for something as fundamental (it would seem to me that programs will always need new code when a term is being added here, and I don't think there is much potential to exploit hierarchies here) is another matter. But if you think it helps, I'll not stand in the way. It is certainly a good complement to refframe and refposition and might one day come in useful in VOTable's COOSYS, too. I'm not sure I am too fond of the name "spatial frame type", because it's too close to refframe for my taste. Perhaps coosys-type would be a more unique designation? "flavor" was the language that STC 1.03 used, which I never liked too much either. Perhaps it's time to consult a math textbook... Aw, not yet :-)

No problem to adopt to the STC nomenclature. I can switch to coosys-flavour, but I'll ask Stéphane too.

In the vocabulary description, I'd again like to tone the reference to EPN-TAP down. I'd rather say "This vocabulary enumerates types of spatial coordinate systems, i.e., sets of axes. To give concrete coordinates a meaning, one will almost always also have to define the reference frame (see the refframe vocabulary) and often the reference position (see the refpossition vocabulary). This vocabulary is used in EPN-TAP's spatial_frame_type column." or so.

Ah yes, I updated the term descriptions, but I copied the vocabulary description from the EPNTAP 2.0 document. Let me update this too.

I am fairly severely opposed to #none. I'm not sure why EPN-TAP 2.0 had this custom NULL value, but they are almost invariably a mispattern. Or is there actually a semantic difference between spatial_frame_type is null and spatial_frame_type='none'? Technically, this vocabulary could be reviewed with EPN-TAP 2.1 -- is that your plan, too?

If I remember well, the reason why we need a term for the "no frame applicable" concept was that this column must be set (mandatory column). In earlier version of EPNTAP, we didn't have this special term, and as a validation point of view, it was not possible to tell if an empty value was a missing value (which should fixed) or a valid "no frame applicable" situation.

[msdemlei]

On Thu, Jul 10, 2025 at 12:40:22AM -0700, Baptiste Cecconi wrote: If I remember well, the reason why we need a term for the "no frame applicable" concept was that this column must be set (mandatory column). In earlier version of EPNTAP, we didn't have this special term, and as a validation point of view, it was not possible to tell if an empty value was a missing value (which should fixed) or a valid "no frame applicable" situation.

Hm. I don't find that reasoning particularly convincing. For background, let me point you to <https://blog.g-vo.org/requirements-and-validators.html>. What this boils down to is: "If whatever you do works when the coosys type is NULL, you shouldn't make it mandatory". If, on the other hand, you must have it *in certain situations* (c1min/max non-NULL, say) only, then the validator needs to diagnose these situations and only then make sure the coosys type is non-NULL. But in that case, having an extra term to express NULL does not help either; on the contrary, it pulls in extra code. Let's not do it. By the way, I acknowledge that there sometimes *are* reasons to have different sorts of NULL values; "it should be non-null, but the data is lost" would be one case. But at least that case certainly does not seem to apply here. As soon as I write coordinates, I know their type (or flavour, if you will, but I've never really liked that term much TBH; I'd still prefer coosys-type or perhaps coordinate-system-type).