VOResource 1.1: Mirrors?

[Markus Demleitner]

Hi,

On Tue, May 31, 2016 at 02:21:26PM -0400, Accomazzi, Alberto wrote:
> projects chime in.  IMHO it would not be terrible to let the end user
> choose, rather than trying to complicate the protocol and infrastructure,

"Let the end user choose" would probably mean that clients have to
offer them that choice, which would mean that they'd have to have
some standard way to figure out the mirror locations.  Which would
make it a VO/Registry problem.  Except that you are right that there
are at least two fairly distinct cases:

> as an astronomer will probably know whether NRAO is better than ESO or NAOJ
> as the source of ALMA data depending on her location.  Individual projects
> such as Vizier have their own way to provide load-balancing via redirection
> when geolocation features are enabled, so maybe it's not really a VO
> problem unless there is an upswell of demand with concrete use cases to
> back it up.

I'd sketch these as "big data, few mirrors" (e.g., ALMA) vs. "medium data,
many mirrors" (e.g., VizieR).  I'd argue that for the few mirrors
case it may make complete sense to have separate resource records for
their services (perhaps linked through a mirror-of relationship), and
VOResource doesn't need to do much in addition to what it already
does.

It's the many mirrors case that I was talking about in the original
mail -- I'm very sure we don't even want to suggest that VizieR has
separate resource records for each of their mirrors, at least not for
their SCS services and tables.  And I think what I'm soliciting at
this point are the concrete use cases backing up the need to handle
that on a VO level.

> The second thought follows from the first one, and relates to the ability
> to identify mirror services.  We are already seeing the replication of
> services through data hosting, which may not produce exact clones but which
> nonetheless often creates sites with semantically equivalent data and

Yes -- I'd say that, in principle, VOResource's relationship concepts
(in this case, mirror-of) might *almost* be enough.  As you say,
however...

> services.  Right now as far as I can tell there is no way to tell whether
> the instances of the SDSS DR8 listed in the registry differ from each
> other, and what the provenance of each one is.  Since these correspond to

...mirroring is not a terribly clear concept in reality.  And even if
we made a strict delineation to derived-from (that's also present
already in VOResource 1.0), I'd give you that the plain information
that there is *some* derivation going on is probably insufficient to
really act upon.

However, it is not clear to me which concepts a machine readable
representation of mirroring or derivation would contain,  and what
clients would be supposed to do with it.

Unless someone volunteers to do some deep thinking in that direction,
I'd be tempted to just wait and see what other communities work out
in that direction (RDA? DataCite? -- btw., DataCite right now
essentially does what we do).  Does anyone have leads?

> data.  Somebody (sorry forgot who -- maybe Dave Morris?) mentioned the
> difficulty in having a VO application which uses the registry discover the
> presence of a local data service (presumably something running on a local
> port) if the application is written do "do the right thing" and look things
> up in the registry.  Is this a use case which should be considered as part
> of this conversation?

That's definitely within the Registry's remit -- but fortunately,
VOResource is modular, and I'd say this is a case for what's been
under discussion as a "VOApplication" registry extension now and
then.  Which means: I'd rather keep it out of VOResoruce 1.1
discussions.

Cheers,

        Markus