Trial 0.8.4

[Tony Linde]

Hi Ray,

> By analogy for ADQL, we would describe the columns as part of the 
> description of the service (e.g. SkyNode) that accepts ADQL 
> (under the 
> Capability element).  

You've lost me. Where would you put columns in Capability?

> For the purpose of our next round of demos, it is NVO's 
> thinking that we 
> do not plan to support locating tables based on UCDs; so, for 
> the moment, 
> we're not planning to capture this info in our registries.  

Is there a description of what NVO plans to do with the registries
somewhere?

Cheers,
Tony. 

> -----Original Message-----
> From: Ray Plante [mailto:rplante at poplar.ncsa.uiuc.edu] 
> Sent: 10 October 2003 18:58
> To: Tony Linde
> Cc: registry at ivoa.net
> Subject: RE: Trial 0.8.4
> 
> 
> On Fri, 10 Oct 2003, Tony Linde wrote:
> > > saying all resources are curatable.  I'm okay with making Curation
> > 
> > I think if we're going to extend the resource schema into projects, 
> > organisations (and, possibly, people) then they certainly aren't 
> > curatable - an organisation does not have a curator (unless you put 
> > the janitor down :)
> > ) so which person associated with an organisation do you put as the
> > 'publisher'?
> 
> See posted example 
> http://www.ivoa.net/internal/IVOA/IVOARegWp03/adil-v0.8.3.xml.
>   In this 
> example, I chose to say that the RAI group is 
> "self-publishing"; however, 
> I could go give NCSA as the "Publisher/Title".
> 
> The key thing is the definition of "Publisher"--it's who is 
> responsible.  
> That applies perfectly well to an Organization.  
> 
> > > Alternatively, if
> > > you (Astrogrid) define a new, say, TabularDataCollection 
> > > resource class in 
> > > a separate extension schema, you can use it on your end and 
> > > we (NVO) can 
> > > ignore it on ours.
> > 
> > The key reason for including table data is to accommodate ADQL, not 
> > AstroGrid. To use ADQL we need to know what tables and 
> columns are in 
> > a data collection (or the accompanying SkyService). How can you 
> > construct a query if you don't know table names and column names / 
> > UCDs?
> 
> For the purpose of our next round of demos, it is NVO's 
> thinking that we 
> do not plan to support locating tables based on UCDs; so, for 
> the moment, 
> we're not planning to capture this info in our registries.  
> That said, the 
> VOTableColumn element in the ConeSearch schemas can 
> capture UCDs.  In other words, we will expose the individual 
> tables by 
> registering the ConeSearch service that accesses them.
> 
> By analogy for ADQL, we would describe the columns as part of the 
> description of the service (e.g. SkyNode) that accepts ADQL 
> (under the 
> Capability element).  
> 
> > > My VOTableColumns element required no changes to the VOTable
> > > schema.  Note 
> > 
> > I see what you mean - but this doesn't allow UCDs to be 
> associated at 
> > the table and collection level, which I understand they can be.
> 
> Yes, at that level it may not make sense to draw on the 
> VOTable schema.  
> This is independent of whether you choose to use FIELD at the 
> level of 
> column descriptions.  
> 
> cheers,
> Ray
> 
>