Error column in VOResource

[Martin Hill]

Ray Plante wrote:

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

No I see it useful (in fact, necessary?) for building queries rather 
than discovery, but this still puts it in the metadata.  I appreciate 
putting too much in can make things harder to implement, but can we 
actually manage without it?  It seems a minor addition...

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

Only if the columns are actually in the table.  Why are we defining a 
seperate metadata query for SkyNode that returns a VOTable?  What will 
be in a VOTable that cannot go into VOResource/VODataService?  This 
rather implies data implementors are going to have to make two sets of 
metadata; and while the VOTable header can describe an associated table, 
it's not really suitable for describing a complete relational dataset 
including images.

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

Yes I agree.  Going the *other* way around would give us a lot more; ie 
replacing VOTable header with VOResource (or a subset of it) in VOTable 
would give us a complete way of describing a table properly.

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

But it *is* included in the VOResource schema?  So isn't it part of the 
core anyway?  Not sure how this stuff is organised...

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

Just that as that page is the bit that links to VOResource, it might be 
useful to have links to any other schemas related to VOResource. If it's 
a pain as you say below then ok I'll use personal bookmarks to remind me 
where to find the appropriate ones.

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


-- 
Martin Hill
www.mchill.net
07901 55 24 66