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

[Tony Linde]

> There's a few things getting mixed here I think...

That's why I want this exercise to take place. We're all talking about
interfaces, tables, databases, datasets, services etc. The modeling exercise
should determine what entities we do want to handle and how we want them
represented (as two separate parts of the exercise).

Let's step back from deciding how things will be represented until we have a
better idea what the 'things' are.

T.

> -----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)
>