VOResource 1.2 WD

[Markus Demleitner]

Dear Registry community,

You may remember that to properly describe how the UAT is intended to
be used in the VO Registry we planned a quick new REC of VOResource
((<http://mail.ivoa.net/pipermail/registry/2022-August/005499.html>
and followups).

Well... as always there was a bit of a feature creep.  There is now
the first Working Draft for VOResource 1.2:
http://ivoa.net/documents/VOResource/20230105/

I would appreciate feedback in particular on the various changes:

(1) The UAT thing (roughly, "Keywords look like uat-label"), sect.
    3.1.3, Element subject

(2) People should now use SPDX URIs if they give rightsURIs, sect.
    3.2.2

(3) You can now set content/source/@format to "doi" and then have
    a doi instead of a bibcode as the paper people should cite, sect.
    3.2.2, the vr:Source type

(4) We now force referenceURL to start with http or https, sect.
    3.1.3, the vr:Content type

(5) vr:ResourceName has a new altIdentifier attribute, affecting 
    curation/contributor, curation/contact/name,
    curation/creator/name, curation/publisher, and
    relationship/relatedResource, as well as facility and instrument from
    VODataService, and managingOrg from Registry Interfaces.  In
    connection with this, created the sect. 2.2.5 with general rules
    for non-ivo identifiers that have before been with the
    altIdentifier elements in VOResource 1.1


It is (5) that we perhaps should stop and think about for a second.
The immediate reason for the change was that VizieR would like to
express relationships to other resources (e.g., the Gaia archive)
that have a DOI which would be interesting to keep, in particular
when you turn VOResource into DataCite records (that use DOIs as
their native identifier scheme).

This could be done by creating a new type for
relationship/relatedResource, and perhaps that is what we should do
rather than change vr:ResourceName (its current type), because as the
list above suggests, that type is used in many places.

On the other hand, it stands to reason that people who want, say,
curation/contributor might be grateful if they can use ORCIDs in
there, and in curation/creator/name we have actually added an
altIdentifier child in VOResource 1.1.  To me, this suggests that
ResourceName's nature ("human-readable name with a machine-readable
identifier") makes it reasonable to just allow non-ivo identifier
schemes throughout.

But exactly the 1.1 addition is what gives me the worst headache
here.  With the present change, you could assign alternate
identifiers to creators *both* in a child element and in an
altIdentifier attribute on the name child.  This clearly is... not
pretty.

So far, I'm trying to weasel out of this by forbidding the use of the
attributes when the children are there:

  Since VOResource version 1.2, the name children of these role-like
  elements also have an altIdentifier attribute since they are
  vr:ResourceName-s. Do not use these attributes for creators and
  contacts; their alternate identifiers, if any, must be given in
  their direct altIdentifier children.

That's still a nasty trap.

The alternative would be to deprecate the altIdentifier children we
have introduced in 1.1 (the altIdentifier on the record itself would
of course remain).  That would not hurt anyone, since nobody has in
fact added ORCIDs to creators or contacts --

  select * from rr.alt_identifier where alt_identifier like 'orcid:%';

-- except for my one test case.

Against the current state, this would remove the capability of having
multiple alternate identifiers for creators (e.g., an ORCID and a GND
id).  *I* don't think that's an actual loss (especially given that
people haven't even bothered to add ORCIDs in the give years since
VOResource 1.1 PR).

Do you have thoughts on this?  Me, I'm starting to lean towards
deprecating the child elements...

Anyway: please have a look.  I think it would be nice if we could get
this to RFC after the Bologna interop, which means we ought to aim
for PR by March...

Thanks,

            Markus