new take on resource registration best practice

[Gretchen Greene]

Hi Ray, 

I'm trying to follow the logic and i missed the interop discussion so i may have some incorrrect understanding.

The terminology for DataCollection2:  Does this mean a modified version of the standard,  OR a different organization within the relational registry,  i.e. the referred best practice registration with single collection and multiple capabilities.

One example i'm familiar with.  If users are searching for the Hubble data,  although this may be a single observatory and hence a *collection*,  the users typically are searching for Hubble Instruments/wavelengths/filters more so than just give me the Hubble collection.  So i'm not clear yet on WHICH CONTRAINTS are being used to define the best practice resource collection *Grouping* and then related  how the services are benefiting the user discovery or client discovery.  Perhaps what this allows is more summary level information,  then clients will be required to drill down.  

I'm interested in seeing the definition for the RULES which define the collections to evaluate more clearly (A) how the parsing will be done on the client side and (B) how the user will see the results.

The question of making this mandatory or not,  I feel strongly that we need to have as much consistency in the registries,  and users should have similar results for the same structured regTAP queries yet the text based queries WILL have variability due to the underlying indexing of the individual registries  databases.  I don't see how the later could be forced to return identical results with underlying differences.

-Gretchen



________________________________________
From: registry-bounces at ivoa.net [registry-bounces at ivoa.net] on behalf of Markus Demleitner [msdemlei at ari.uni-heidelberg.de]
Sent: Friday, October 25, 2013 3:10 AM
To: registry at ivoa.net
Subject: Re: new take on resource registration best practice

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