new take on resource registration best practice

[Markus Demleitner]

On Thu, Oct 24, 2013 at 01:41:59PM -0500, Ray Plante wrote:
> On Thu, 24 Oct 2013, Markus Demleitner wrote:
> > [Ray said:]
> > > Will we need to *require* a registry to implement the ingestion
> > > behavior you described?  Is it better to get the original resource
> > > record in a optimal state to begin with?
> > 
> > Since the effects of whether or not that  happens are visible to the
> > registry client, I am completely convinced that yes, this must be
> > mandated.  Maybe not in a REC initially, but clients must be able to

> I think it is better not to mandate this but leave it as a value-added 
> feature.  (Of course, I was never bothered by the different answers 
> issue, but I admit that people complained loudly about it.)
> 
> To explore this choice, we might consider what the world would 
> subsequently look like.  We have a user that is looking for a catalog 
> related to some science topic and servced by a TAP service.  

> She goes to the VAO Registry to submit the query.  This registry 
> follows the DataCollection2 best practice for its own resources, but 

> Savvy or not, she tries now going to the VO-Paris registry and submits 
> her simple query again.  This time she gets more resources back 
> including those that followed the DataCollection2 best practice *and* 
> those that didn't.  At this point says:

With the current RI1 infrastructure, the problem typically has been
somewhat different -- people haven't been idly trying out different
registries, but they fell back to another registry when their
"usual" one was down.  Then they were X annyoed when they saw
additional services (X=mildly) or didn't see the services they were
normally using (X=severely).

I'm claming that this sort of failover will continue to be the
typical scenario for people switching registries, and that's why I
believe consistent responses are really, really desirable.

This whole argument might be invalidated if we said the best practice
for a registry client was to join results from three or more
registries as long as they are up; that might mitigate the problem a
bit.  But I think it doesn't take too much empathy to predict the
registry client implementors will not like such a proposal.

Cheers,

        Markus