update of uCD list following SSAP UCD check

[loumir]

while checking SSAP UCD words , we propose to fix some UCD terms in the list

• meta.curation change flag to S

• phys.size change definition

[loumir]

SSAP UCD are also proposed for revision . see table attached
SSAP_appendixD_UCDCheckmL+Seb.pdf

[mbtaylor]

Are these supposed to be compatible with UCDList 1.4? Several entries contain meta.curation in the secondary position, but meta.curation is marked P in UCDList 1.4.

[loumir]

No, meta.curation flag update can be planned for EN UCDList1.5.
The suggestions for SSAP updates in the document, imply that meta.curation becomes a more general term than identity of publisher.
so be changed to S or Q .
Q;Q terms have no logic to be combined so S would be more convenient.

[msdemlei]

On Thu, Sep 09, 2021 at 10:17:47AM -0700, Mireille LOUYS wrote: No, meta.curation flag update can be planned for EN UCDList1.5. The suggestions for SSAP updates in the document, imply that _meta.curation_ becomes a more general term than identity of publisher. so be changed to S or Q . Q;Q terms have no logic to be combined so S would be more convenient.

As a general principle, I'd be very wary of transitions from P to S, as that will make *any* previous use of the atom invalid, which is a bad thing in almost all cases (essentially, unless the previous meaning was really broken beyond repair). Also, semantically, a generalisation of a concept cannot make it flip from P to S, as that would necessarily mean certain parts of the previous extension were be dropped (a generalisation only enlarges the extension). I mention in passing that making meta.curation S will again break existing SSAP, as its utype ssa:Curation.Publisher is currently associated with the UCD "meta.curation". As to avoiding Q-Q because there's no implied order, I'd say that's not really something to worry about. Basically, making an atom Q means "it can work *both* as a main descriptor *and* as a qualifier". Writing definitions such that that works is tricky but not impossible. Of course, "meta.ref.ivoid;meta.curation" then really means something else than "meta.curation;meta.ref.ivoid". The question is: what? My UCD explainer produces for the first: Identity of man/organization responsible for the data related to an identifier as recommended in the IVOA (dereferenceable) So... with my current code this comes out as the folks that maintain an an identifier. Ahem. I'd suggest that's a bug, as it should arguably by "identifier of the folks how do the curation". Patches to http://svn.ari.uni-heidelberg.de/svn/gavo/hdinputs/ucds/res/ucdexplainer.py are welcome. For the second UCD, it's Related to an identifier as recommended in the ivoa (dereferenceable) identity of man/organization responsible for the data That that sentence is broken indicates my code fails with meta.ref.ivoid on a wider scale. What I'd say the explanation ought to work out to is what the explainer put out as first thing: it's infos on the curation of IVOA identifiers. Whether that's a thing commonly used in tables I doubt, but, really, the extension of that compound concept pretty plainly is what in Registry we call an Authority, and I don't see anything wrong in admitting such a concept in UCDs. In closing: Can we change the "man" in the meta.curation definition to "person"?

[loumir]

version UCDList1.5 solves this issue
it states a position Q for meta.curation and recommends meta.id;meta.curation for identifying a person or an organization responsible for curation.