Drop SkyService?

[Tony Linde]

I should have known it would not be that easy :)

How about we keep my idea for services which simply front a data collection
- simple query services - and use the SkyService for those which offer
services that cannot be described by the data collection behind them (as
well as those which collect data from several areas or which have no
registered data collection behind them)?

Cheers,
Tony. 

> -----Original Message-----
> From: owner-registry at eso.org [mailto:owner-registry at eso.org] 
> On Behalf Of Thomas McGlynn
> Sent: 26 September 2003 20:25
> To: registry at ivoa.net
> Subject: Re: Drop SkyService?
> 
> 
> While I like the idea of having a DataCollection object
> with coverage elements, I don't think its quite enough...
> 
> E.g., suppose we register the ROSAT data collection at
> the HEASARC, with nice numbers for spatial, spectral, and 
> temporal resolution appropriate to the collection. Now 
> someone else builds a service, say an object detection 
> algorithm, which can use our collection.  Now if the service 
> simply inherits the characteristics of the linked to 
> collections, it may indicate that this service is capable of 
> temporal reolution of 1 ms -- since that's what ROSAT data 
> could be analyzed at in some contexts.  However, that's 
> almost certainly wrong. The service very likely combines 
> entire ROSAT observations and then looks at data, so if we 
> were to give it a temporal resolution it might be 10 Ksec.
> 
> Of course a service specifically designed to look for short 
> term temporal variability in X-ray data would split up the 
> obsevation.  Perhaps it could be characterized as having 10 
> second resolution... Where do I put in the metadata this 
> service allows one to look for variability on a given timescale.
> 
> Similarly, there may be some change in the characteristics of 
> the data midway duing the mission.  The entire mission 
> lifetime is given as the temporal coverage of the dataset.  
> However some service might work only with data early in the 
> mission, e.g., before the particle background got too high.  
> So the temporal coverage for the service is different from 
> the temporal coverage of the dataset.
> 
> Or again there might be gamma ray source detection algorithm 
> that works nicely outside the galactic plane but doesn't work 
> well in that high background region.
> 
> So services can have coverage limits that are independent of 
> the datasets they use. It may be that providing this is just 
> not feasible in general, and for the very simple services we 
> are looking at right now -- which deliver existing datasets 
> with little or no processing -- this problem may not be significant.
> 
> I guess I don't have any problem with the suggestion for 
> right now, but I'd hope that approach taken wouldn't 
> foreclose on services having coverage data eventually.
> 
> 
> 	Regards,
> 	Tom
>