Single or collection resources

[Guy Rixon]

Hi Markus (and DAL-WG),

I'm working on the upgrade to the AstroGrid DSA/catalogue product to
make it into a TAP implementation. What I've been doing the last few
days bears on the single/multiple-registration issue.

We support (in the forth-coming minor release) separate registration
of each catalogue and also registration of all catalogues as one
resource. Separation makes it simpler to use one catalogue;
combination allows more joins. (In a DSA installation, all catalogues
are within one RDBMS, so cross-catalogue joins are possible if the
service knows to do them.)

These separate registrations are on different IVORNs. If you have
a base service A containing catalogues x, y and z, you can register
all of these:

ivo://whatever/A
ivo://whatever/A/x
ivo://whatever/A/y
ivo://whatever/A/z

Each of those resources is a service registration. We don't use
data-collection resources because we need to provide the table metadata
with the service and with the service registration.

Considering the base service A and catalogue x from the example above,
we have these endpoints

http://whatever/A/TAP/sync
http://whatever/A/TAP/async
http://whatever/A/VOSI/capabilities
http://whatever/A/VOSI/tables
http://whatever/A/VOSI/availability
http://whatever/A/VOSI/capabilities?COLLECTION=x
http://whatever/A/VOSI/tables?COLLECTION=x

i.e. the VOSI resources are parameterized by the catalogue/data- 
collection name
but the TAP resources are not. Downloading the parameterized VOSI  
resource
gets you the relevant sub-set of the metadata.

The TAP-mandated VOSI endpoints are redirected internally to the ones  
above e.g.:

http://whatever/A/TAP/sync?REQUEST=getCpabilities -> http://whatever/A/VOSI/capabilities


Cheers,
Guy

On 6 Aug 2009, at 13:58, Markus Demleitner wrote:

> Dear DAL folks,
>
> On Thu, Aug 06, 2009 at 06:28:44AM -0500, Ray Plante wrote:
>> collection separate from the services that access it.  In VOResource
>> speak, the former is a resource of type DataCollection, the latter  
>> would
>> be a CatalogService with an SIA capability.  The DataCollection  
>> resource
>> can reference the service as a "related resource" (of the type
>> "served-by").  This allows for N DataCollections being registered,  
>> but
> Yes, that's nifty, and I'd probably like to go this way.  Except:
>
>> One barrier to this approach is the extent to which registries  
>> support
>> it.  That is, your registry will need to let you (easily) set the  
>> related
> ...and in particular, what VOExplorer does with it.  I always find
> that people are much more impressed when their data turns up in a
> "real" program as opposed to "just another website".  So -- I'd be
> really grateful if someone from from the VOExplorer team could
> comment what would work best for them.  In particular, do you even
> look at DataCollections?  Will you show your nice service icons for
> served-by?
>
>> In closing, I'll note that the DAL services aren't currently good for
>> finding data based on the science subject matter that the datasets
>> address.  If we consider our goals of re-purpose data, then perhaps  
>> they
>> shouldn't; science happens arguably at a higher level.  The only  
>> other
>> service for doing discovery by subject matter is the registry.  We  
>> could
> Right -- that is exactly why I'm worrying about individual registry
> entries and why the being able to show the service icon behind some
> entry in VOExplorer is a bit more than just a means for seducing
> potential data providers.
>
> Cheers,
>
>         Markus