More separation - mirrors, copies, tight vs slack queries...

[Tony Linde]

> interfaces.  Each of these requires a different entry in the 
> Registry, but they are all just different interfaces to the same data.

I don't see why separate interfaces to the same service would need separate
registry entries. They aren't separate resources. The service is one
resource with multiple interfaces, so should be one registry entry with
repeating interface descriptions.

> have two different installations of SSA/USNO-B/2MASS.

I assume there is some difference between them else why would they be
provided. So you have one service accessing two datasets. If they *are* the
same then it is just one dataset and which one you acccess is an
implementation matter and has no affect whatever on the registry.

Mirrors, copies etc are another matter which I hope this modeling exercise
will tease out.

> runs on one specified table or 'any available table' merely 
> describes how tight the search constraints are. And just to 

I'm not sure that 'tables' are relevant here. If one dataset has its data
stored in several tables then, again, that is an implementation issue with
no affect on the registry. If the tables represent fundamentally different
data which the astronomer would be interested in then they would need to be
registered as separate datasets.

Cheers,
Tony. 

> -----Original Message-----
> From: owner-registry at eso.org [mailto:owner-registry at eso.org] 
> On Behalf Of Martin Hill
> Sent: 09 December 2004 17:34
> To: Roy Williams
> Cc: registry at ivoa.net
> Subject: Re: More separation - mirrors, copies, tight vs 
> slack queries...
> 
> There's a few things getting mixed here I think...
> 
> We can supply multiple interfaces to the same *instance* of a 
> dataset, which is where Guy's proposed service-neutral 
> description of the dataset is useful.  For example, the PAL 
> library comes with amongst others, Cone Search, SkyNode (sort 
> of :-), 'Full-Featured' SOAP, CEA, SIAP and soon SSAP 
> interfaces.  Each of these requires a different entry in the 
> Registry, but they are all just different interfaces to the same data.
> 
> There are also 'true' mirrors, where the data on a different 
> bit of hardware is kept synchronised with the original one, 
> and so we *could* have another deployed datacenter that might 
> share the same table description. For example, at the ROE we 
> have two different installations of SSA/USNO-B/2MASS.
> 
> 'Copies' - where someone has taken a copy of the data and 
> published it elsewhere - will need separate metadata 
> documents because as additions or adjustments are made, the 
> datasets will diverge slightly.  For example, the 2MASS at 
> Edinburgh is not a mirror of that on the OpenSkyNode portal.
> 
> The issue of whether a cone search (or any other search!) 
> runs on one specified table or 'any available table' merely 
> describes how tight the search constraints are. And just to 
> be argumentative (heh heh) I certainly don't see that as an 
> astronomer vs developer difference - anyway from a developers 
> point of view it's much easier when astronomers are explicit 
> about what they want :-)
> 
> Cheers
> 
> Martin
> (no, no storm please, not now)
> 
> Roy Williams wrote:
> 
> > From: "Tony Linde"
> > 
> >>  The same applies to data services: one service might 
> provide access 
> >> to multiple data collections and one collection might be 
> served up by 
> >> more than one service.
> > 
> > 
> > As soon as the first cone-searches were built in 2002, we had URLs 
> > that look like:
> > http://blahblah.org/cgi-bin/cone?Catalog=Messier&RA=200&Dec=20&SR=10
> > 
> > Dissecting this URL, we can see two different semantically-distinct
> > entities:
> > 
> > (1) http://blahblah.org/cgi-bin/cone?Catalog=Messier
> > This is an instance of a conesearch which queries a specific data 
> > resource (the Messier catalog). It represents the point of 
> view of an 
> > astronomer-client.
> > 
> > (2) http://blahblah.org/cgi-bin/cone?
> > This is a sort of "meta-conesearch", that can act as a 
> consearch for a 
> > number of data resources. It represents the point of view of a 
> > software developer.
> > 
> > 
> 
> 
> --
> Martin Hill
> www.mchill.net
> 07901 55 24 66
> 0131 668 8100 (ROE)
>