Update UCDlist.tex

[BaptisteCecconi]

First attempt to solve #35

[msdemlei]

You have my blessing for the changes (including when you back out my changes...)

[BaptisteCecconi]

This PR describes the ucd-list.txt and ucd-list-deprecated.txt.
I'm not sure the way the ucd-list-deprecated.txt is defined is fully functional. So we should discuss this a bit more.

My current concern is, for instance, with the pos.resolution term, which has been first introduced in V1.01, then deprecated in v1.10, with a proposed replacement, but has been reintroduced (with another definition) in v1.4.

So currently, the term pos.resolution is both valid (as of v1.4) and deprecated (for previous versions).

On way to solve this would be to add 2 columns to the ucd-list-deprecated.txt: the UCD list version when it has been deprecated, and a date of deprecation. Then it might be possible for validators to compare dates of resources with date of deprecation.

[msdemlei]

On Tue, May 03, 2022 at 05:19:42AM -0700, Baptiste Cecconi wrote: My current concern is, for instance, with the `pos.resolution` term, which has been first introduced in V1.01, then deprecated in v1.10, with a proposed replacement, but has been reintroduced (with another definition) in v1.4. How shall we manage this ?

I think that's rather clear from an operational perspective: If it's not deprecated right now, it must not be in the deprecated list right now, or clients using that list will get it wrong. Or am I missing something?

[BaptisteCecconi]

yes, agreed from an operational point of view, that would be simpler. Older resources using pos.resolution (before it was deprecated, i.e., >=v1.01 and <v1.10) were using a different definition than that currently in place (>=v1.4). But that's not an operational issue, that's a resource maintenance issue.

[BaptisteCecconi]

I have fixed ucd-list.txt (removed meta.ref.ivorn) and ucd-list-deprecated.txt (removed pos.resolution).

[BaptisteCecconi]

NB: also solving #31

[loumir]

good for cleaning meta.ref.ivorn out of ucd-list.txt.
the replacement rule is in the ucd-list-deprecated.txt.

my suggestion when we redefine the meaning of a former deprecated term:
It would be useful to have a #redefined status like :
#redefined : term new definition
pos.resolution '+' new definition
here
pos.resolution '+' Q | pos.resolution | Spatial linear resolution (not angular)
For those terms, the data providers need to check that they map the column to the most recent UCD definition, expressed here in the redefined list as a reminder .

drawback : the #redefined line should be exactly the same as in ucd-list.txt...
but this situation does not happen too often

[loumir]

Ok with the useful description of the two lists added .

[msdemlei]

On Tue, May 03, 2022 at 07:20:04AM -0700, Mireille LOUYS wrote: drawback : the #redefined line should be exactly the same as in ucd-list.txt... but this situation does not happen too often

Hm -- what would clients do with this information? Me, I'd say the two text files are machine-readable resources and hence should only contain what machines actually want to read. Telling them that the thing once meant something different, I think, won't help them accomplish anything they could reasonably accomplish; figuring out what a UCD means *in context* would require that they know when a UCD was created and when we changed the meaning, both of which they can't figure out at the moment. So: My vote is to warn humans about this in the document but don't bother the machines with it.

[BaptisteCecconi]

I agree with @msdemlei, the relevant information is available in the document humans. The plain text lists are for machines.