VOResource 1.1: Mirrors?

[Markus Demleitner]

Dear Registry,

Pierre said on how mirrors are described in GLU:

On Thu, Jun 02, 2016 at 11:39:33AM +0200, Pierre Fernique wrote:
> *0) First of all, a GLU record is basically just a couple (ID,URL)
> [...]
> *1) Or mirror can be defined by a n-uplet (ID, id1,id2,id3...) and the URL
> associated to the ID can be one of the URLs associated to id1, id2,...) =>
> Mirror definition by indirection*
> [...]
> *2) or a couple (ID, URL_template_containing_GLUids) => The final URL is

I'm trying to figure out what we can learn from that for how we'd
model mirrors in VOResource -- I'm clearly not very keen of
introducing too much referencing and templating into the Registry.
How much of this is indispensible for operation, and what is just
convenient (and how)?

And then, Arnold said:

On Thu, Jun 02, 2016 at 09:58:45AM -0400, Arnold Rots wrote:
> Proper mirror identification is crucial, but it requires its own metadata:
> 
> - What kind of mirror?
> Identical data and identical user interface
> Identical data with different interface
> Subset of the data
> Derived data products

My take is that if it's not "identical data and identical user
interface", it's a separate resource and thus has a separate resource
record.  The mirror-of relationship would, I'd argue, work good
enough for these.  Refined semantics could go in when clients
actually do something with that information.

Hence, I'd strongly argue we're only dealing with case 1 here (i.e.
the proposed mirrorURL element).

> - Original data source/publisher
> Name the source
> Provide a link to the source
> Provide acknowledgment and citation information

Since CDS has, I think, the richest experience here: do you see a
need for additional metadata on the hosting institution?  One *could*
imagine a <hostedBy ivo-id="">foo-bar</a> element in mirrorURL, but
really, that's definitely something I'd like to hear substantial
clamor for before committing to it.

The remaining metadata, I'd argue, has to be identical for something
to qualify as a mirror (in particular, it must be "in effect" managed
by the "main" institution, where the hosting institution only
provides the hardware).

> - The most recent sync date and time
> This is an issue for mirrors of evolving repositories

...and all of them are.  But I don't think this can reasonably be
managed through the Registry -- it would have to re-harvest all
service records each time a sync is made, and that would completely
change the whole architecture of the thing.

Cheers,

          Markus