change flag + definition meta.curation meta.email

[loumir]

meta.curation had P flag but SSA or Obscore implementations already use it in various combinations ( 22 occurrences in Gavo Registry).
Moving it to S for secondary word seems the least changes impacting running services.
meta.id;meta.curation is the replacement for current usage of meta.curation (12 occurrences in GAVO Registry ) to represent the name or id of curator/organisation
meta.email 's description, previously mentioning curation , is now defined more generally as 'Contact email'

[mbtaylor]

Is it wise to change from P to S? That means that if anybody was using it as Primary before, in accordance with the published standard, their usage will now be illegal. I suggest changing it to Q instead so that both old and new usages are legal.

[msdemlei]

On Fri, Aug 27, 2021 at 05:25:18AM -0700, Mark Taylor wrote: Is it wise to change from P to S? That means that if anybody was using it as Primary before, in accordance with the published standard, their usage will now be illegal. I suggest changing it to Q instead so that both old and new usages are legal.

I fully agree -- if we touch it, it needs to become Q, or we need to at least get all the services that have UCDs with meta.curation in the first position (currently, these exist from www.plate-archive.org, nasa.heasarc, and cds.vizier) to update their descriptions. I don't think their UCDs are wrong, though. On the other hand, obscore 1.1's meta.ref.url;meta.curation seems reasonable, too. So, it'll have to be Q. We ought to work on clear, testable rules for when an atom needs to be P, S, or Q.

[loumir]

Hi,
having Q for meta.curation make assigning tools fail when they have to decide how to combine
Q meta.mail
Q meta.curation
then which is first , which is second ?
the former use of meta.curation used as P , should be instead meta.id;meta.curation .
this is then not ambiguous anymore.
Vizier can update the former usage using a script .
May be the same could be done for other services .

[msdemlei]

On Wed, Sep 01, 2021 at 08:27:56AM -0700, Mireille LOUYS wrote: having Q for meta.curation make assigning tools fail when they have to decide how to combine Q meta.mail Q meta.curation then which is first , which is second ?

While this may be a first step towards my goal of having testable criteria for S, P, or Q, I'm sure you'll find any number of combinations of two Q atoms already, so avoiding Q;Q UCDs hardly is a strong criterion against making something Q. Be that as it may, since there are are only 30 tables from four providers with meta.curation in the P position, I'm not strongly against making it S *if* we tell the concerned persons. Mireille, could you do that? You can use a query like ``` select ivoid, table_name, name, ucd, role_name, email from rr.table_column natural join rr.res_table natural join rr.res_role where ucd like 'meta.curation;%' and base_role='contact' ``` on the TAP service http://dc.g-vo.org/tap to see who's affected and have e-mail addresses; making suggestions how to fix things would be certainly welcome, in particular for where there's only meta.curation at the moment. Once these are gone from the registry, I'd sanction the merge. For the future, I'd suggest "doesn't break any registered service" ought to be a condition for merging incompatible changes (as this one). Convincing data providers to change their UCDs is a nice way to review such changes...