VOResource 1.1 RFC

[Markus Demleitner]

Dear Registry,

In the story with the symmetrisation of identifiers-like information
on the various VOResource person-like element, there's good and bad
news.  Let's start with the good news.

On Thu, Jun 08, 2017 at 12:02:07PM +0200, Markus Demleitner wrote:
> On Thu, Jun 08, 2017 at 10:32:55AM +0200, Baptiste Cecconi wrote:
> > 
> > Indeed ORCID could do it for persons.  I will try to use use the
> > existing altIdentifier attribute to refer to orc-id and spase-id.
> > I would need it for all elements that could be a person/party, so
> > having it back on contributor would be needed.
> 
> Ok -- so, I'll add altIdentifier to vr:Contact; that seems reasonable
> based on symmetry with vr:Creator.  In consequence, the draft RegTAP
> 1.1 schema will grow a role column, presumably reflecting the element
> name of altIdentifier's parent.

That's done now.

> > However, when the contact/contributor/creator is a team or an
> > organizing, we should use the ivo-id.  I'll see on real-life
> > examples and come back to you.
> 
> So, we won't deprecate ivo-id where it already sits (i.e., publisher
> and contributor).  I'm not sure if I'm too enthusiastic about
> organisations as creators, but for contacts they clearly make sense.
> For symmetry, I'd say both should grow an @ivo-id attribute with a
> verbal constraint that only vr:Organisation-typed records should be
> referenced.

That's done, too.  The schema file on volute 
http://volute.g-vo.org/svn/trunk/projects/registry/VOResource/VOResource-v1.1.xsd
should reflect this, and if anyone has a chance to try it out with
creators or contacts with ivo-ids or with contacts with ORCIDs, you'd
be most welcome (please leave a note on the RFC wiki page).  Also,
the documentation should contain some appropriate language (in case
you want to see it formatted: http://docs.g-vo.org/VOResource.pdf).

Now for the bad news:

> Publisher and contributor are a different matter, though.  They
> currently are a vr:ResourceName-s.  In the parallel thread started by
> Sarah, we're investigating whether they will get a
> relatedAltIdentifier, too; but there are fairly hairly issues with
> this (essentially: a sane relationship is a *pair*, not an n-tuple
> for n>2). Do you forsee critical use cases that could need
> altIdentifiers for publishers and contributors?

It's worse than that.  I'd just have put in ResourceNameWithAliases
types or something; I'd appreciate more symmetry between the
person-like elements in VOResource anyway.  But there's a fairly
fundamental modelling difference between contact and creator on the
one side and contributor and publisher on the other: The first have
name children, the others don't. 

Hence, contributor and publisher have character data children:

  <publisher ivo-id="ivo://org.gavo.dc/org">GAVO DC</publisher>

Were we to add altIdentifier as for contact and contributor, it
would look like this:

  <publisher ivo-id="ivo://org.gavo.dc/org">
    <altIdentifier>orcid:lugb-urz0</altIdentifier>
    GAVO DC
  </publisher>

-- we'd suddenly have what, in XML circles, is known and widely
despised as mixed content, i.e., an element has both text children
and element children.  This comes with a lot of ugly technicalities,
not to mention I'd have to study XML schema documentation.  It'd also
be a first for this kind of thing in VOResource, and I'd hate to be
the one that spoiled the, well, beauty.

So... I'd say this is out.  What are the alternatives?

(a) Forget about altIdentifiers for publishers and contributor.  That'd
be my default until someone produces a compelling use case.

(b) Change publisher and contributor to a more creator-like content
model, i.e., with a proper name element.  That's VOResource 2.0 right
there.  I'd like to avoid that as long as possible.  Doing this step
would require a *really* compelling use case.

(c) Make altIdentifier an attribute rather than a child element.  I
don't much like that for two reasons: 

  (c.1) it's different from what altIdentifier is in Resource and
    Creator (where it's an element), which is always bad when you're
    modelling the same thing, and

  (c.2) it's an element on Resource and Creator for a good reason, in
    that a given thing can have multiple altIdentifiers (e.g., a
    bibcode and an ISBN for a book; not that we'll have that in the
    Registry, but the concept is the same).

Opinions?  Ideas for a (d)?

      -- Markus