new take on resource registration best practice

[Ray Plante]

Hi Pierre,

On Wed, 23 Oct 2013, Pierre Le Sidaner wrote:
> To register services do we agree that we want to register one end point TAP
> service (one vodataservice) and multiple collections ?

No, not quite.  This proposal specifically says that each catalog is
represented by its own DataCollection record which will include a
capabilitiy describing the TAP service that can access it.  This is
*even if* there is only one TAP service that can access multiple
catalogs; the same capability element is replicated across all of
them.  If you do have one TAP service accessing many catalogs, you
may *in addition* register that TAP service separately.

> I just want us to separate two point :
> The way we want the services and collection to be registered by the users.
> (example for registering one tap with multiple collections)
> The way we want to ingest them in the registry. (or the way we would like to
> retrieve informations)

This is a good point, and it's subtle enough that I really had to 
think carefully about the answer.  

I framed this discussion in terms of how the convention affects 
(specifically, improves) searching for resources, suggesting I'm 
talking about how users retrieve the information.  However,
traditionally, registry implementations present resources in search
results much as they were ingested from the originating registry,
suggesting that it matters what the resources look like when
ingested.  We have, though, discussed how this correspondence need not
be strictly the case.

For example, we've talked about how a registry might augment a
service's metadata by, say, accessing its VOSI getTables method during
ingest.  Thus, resources that a user searches against need not be
exactly what was harvested.  You give another example:

> In the implementation of REST registry done by Jonathan we will consider one
> collection as one resource and we will add them the associate capabilities
> (the one associated to the related service) and it will transparent for the
> user.
> he will ask give me tap services dealing with infrared or with this word. And
> answer will come directly

So I think what you are saying is that on ingest, when you encouter a 
case where the collection and associate TAP service are separate 
resources, you will (in effect) "copy" the TAP capibility over to the 
collection resource.  That is, you will attempt to make the collection 
conform to the new proposed convention.  Yes?

Of course, you will have to assume some other convention is in
use--i.e. there are relationships declared to connect the separate
resources.  This will certainly be an important feature, since even if
we promote the new proposed convention, there will remain some
"legacy" resources that do not get updated.  

There is a question, though, as to whether this kind of smarts needs
to be widely applied across all searchable registries or let this just
be a custom, value-added feature a registry might implement.
Ultimately, we need to be able to give people (like Mark Taylor) 
specific, sure-fire queries that, when applied to a standard search
interface, return the desired results; thus, such queries probably
should not rely on a "custom" registry feature.  

So, while a registry may apply some smarts either upon ingest or 
during searching, I think it is important to consider the case of 
an implementation where the resources returned upon searching are 
those that were ingested (via OAI) verbatim.  That is, in answer to 
your original question, this discussion pertains to how resources are 
registered as well.  This discussion asks, then, what is the best way 
to register resources to make the standard search interfaces most 
successful.  

> As I consider that VO organisation is not the problem of the user, we should
> not change the way resources are designed just because we have change
> interface to TAP.  

(Is the "user" here the searcher or the publisher or both?)

If a TAP-based search interface is to be successful, simple, common 
questions should be simple to express.  So, it's important that we 
don't promote registration practices that undermine a user's ability 
to create simple queries to find the resources.  (At the same time, 
obviously, we want to avoid drastic, disruptive changes.) 

I specifically talked about the context of TAP, but I think there is 
an extension to the RESTful "text-optimized" search interface as well.  
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?

cheers,
Ray