Error column in VOResource

[Tony Linde]

> An important question is, do you see "ErrorColumn" being 
> useful for choosing/locating a resource?  (as opposed to 
> querying the table itself.)

Can we really say of any metadata that no-one will want to use that piece of
structure of metadata to locate the resource? I suspect not. VOResource
should include all metadata as part of its specification and a registry must
be able to return all the metadata within the VOResource structure but any
particular instance of a registry may be implemented so that it caches all
such metadata or not - that is an implementation decision - but the registry
is the interface whereby all the metadata is returned - an application
should not have to have the responsibility of querying resources for their
metadata - the registry is a one stop shop for all metadata.

T.

> -----Original Message-----
> From: owner-registry at eso.org [mailto:owner-registry at eso.org] 
> On Behalf Of Ray Plante
> Sent: 18 May 2004 15:30
> To: Martin Hill
> Cc: registry at ivoa.net
> Subject: Re: Error column in VOResource
> 
> On Tue, 18 May 2004, Martin Hill wrote:
> > Would it be a good idea to include a reference to the 
> associated error 
> > column in a column's description?  eg:
> > 
> > <Column>
> >       <vr:Name>FREQ</vr:Name>
> >       <vr:Description>Frequency at center of the image 
> > wavehand</vr:Description>
> >       <DataType>float</DataType>
> >       <Unit>Hz</Unit>
> >       <ErrorColumn>FREQ_ERR</ErrorColumn>
> > </Column>
> 
> There is a caution to be made about metadata creep.  The more 
> we put in, the more that doesn't get used, the heavier and 
> more complicated to schema to understand.  
> 
> An important question is, do you see "ErrorColumn" being 
> useful for choosing/locating a resource?  (as opposed to 
> querying the table itself.)
> 
> Cone Search and SIA both define a metadata query that returns 
> a VOTable header.  This would presumably contain this 
> information if it exists anywhere.  SkyNode is working on an 
> analagous operation to get this information.  
> 
> I'm also concerned about our re-inventing the metadata that 
> comes with a VOTable.  In previous versions of the schemas, I 
> suggested importing parts of the VOTable schema to describe 
> tables within a VOResource; that way you get all this 
> richness for free.  Plus, we don't have 2 different ways of 
> expressing the same thing.  The only reason I can think of 
> for not doing this is that VOTable is somehow not general enough.  
> 
> > Also, a rather naive question: I had originally thought that column 
> > descriptions were part of the VOResource document, but they 
> don't seem 
> > to be there - they seem to be in a VODataService schema.  
> Have I got 
> > that right?
> 
> Yes, since this applies only to tabular data and data 
> services, VODataService seems the most appropriate place to 
> put it.  More importantly, table descriptions lie at the more 
> unstable end of our schema development (as illustrated by 
> this email ;-) so it's best not to have it in the core.  
> 
> > If so, could we add this to the VOResource page at 
> > http://www.ivoa.net/xml/VOResource/ ?
> 
> Exactly what do you wish to see on this page?  
> 
> Note that all schemas are listed at http://www.ivoa.net/xml/. 
>  Also note that http://www.ivoa.net/xml/ is not maintained by 
> the Registry working group but by the document coordinator.  
> Because of the chore of maintaining the documents themselves, 
> the presentation is kept pretty plain to all automated maintanence.  
> 
> cheers,
> Ray
> 
>