Elements to add to TabularSkyService

[Tony Linde]

I've been tied up this week so haven't been following the threads that've
developed.

We agreed in Boston the schema for Jan 2005. Anything under discussion now
WILL NOT affect that. 

The table and column descriptions in TabularSkyService are simply there to
facilitate the creation of a simple query at this stage. In the future we
will likely adapt all the resource descriptions to use the data model but we
don't have that yet (although I understood someone was going to supply a
trial catalog data model a while back). In the meantime it is best to keep
it simple.

TabularSkyService is not a replacement for VOTable nor will it ever be.
Likewise VOTable is not in a form that could describe registry information
in any usable fashion. Let's not try to confuse the two.

We have a workable schema in TabularSkyService. Work is needed on the
description of applications however and that is an area that AstroGrid can
extend and develop over the coming months with a view to presenting options
for future releases of the schema.

We have decided on the schema to be used for Jan 2005. I suggest we
concentrate on building interoperable services based on that and solving
real problems based on those attempts. Both AstroGrid and NVO have committed
to building interoperable registries and services for Jan 2005 - AstroGrid
will not implement anything that defeats that goal or makes it difficult to
achieve.

(Now for the other threads - after all what are weekends for...)

Cheers,
Tony. 

> -----Original Message-----
> From: owner-registry at eso.org [mailto:owner-registry at eso.org] 
> On Behalf Of Martin Hill
> Sent: 01 July 2004 20:46
> To: registry at ivoa.net
> Subject: Re: Elements to add to TabularSkyService
> 
> Gretchen Greene wrote:
> 
> > Martin,
> > 
> > I wouldn't rule-out NVO using TabularSkyService at all.  We 
> are in the 
> > process of populating and testing new schemas just the same.  Our 
> > prototypes were based on much earlier concepts and then 
> yes...we have 
> > advanced services which have their own similar set of 
> 'elements' such 
> > as skynodes.  This doesn't mean we are not interested in 
> using these 
> > newer schema elements,  it is simply a process of 
> development that we 
> > are exploring.
> 
> OK dok... however it sounds like you're some way away from 
> using this document-based way of describing metadata 
> (skynodes do their own thing with calls to methods that 
> return lists of tables, lists of columns etc). So I was 
> really wondering if we/Astrogrid can 'take ownership' of it 
> for a while (viz ADQL by NVO) to develop it into a real-world 
> usable document, and then present the results to the registry 
> group for discussion/dismemberment/etc.  Rather than going 
> through the rigmarole of discussing each small change!
> 
> However I think Ray has suggested a way of doing this but 
> using a completely different extension, which will save us 
> from interfering with each other.
> 
> > With all the discussion on the theoretical aspects of the 
> schema dev,  
> > I encourage you to share some instance examples.  It really helps 
> > clarify how the schemas apply.  Project drivers always 
> differ yet real 
> > examples go a long way.  Throw some out there!
> 
> Yers - the examples I have now are only from discussion with 
> a couple of innocent data providers who are about to be VO'd 
> (poor things :-).  I'll definitely put up some real examples 
> when I have some.  I suspect before then there will be lots 
> of questions from me and them about other aspects of VOResource!
> 
> Is this the right forum to use to ask questions about 
> ambiguous/undocumented elements in the VOResource document?  
> Perhaps with a special subject marker [SupportRequest] ?
> 
> Cheers!
> 
> MC
> 
> 
> --
> Martin Hill
> www.mchill.net
> 07901 55 24 66
> 0131 668 8100 (ROE)
>