Elements to add to TabularSkyService

Martin Hill mchill at dial.pipex.com
Thu Jul 1 10:42:23 PDT 2004


Ray Plante wrote:

>><ErrorColumn> - an optional element with a value of the column name, 
>>that holds the error for the values in this column.
> 
> I'm concerned that, given our past discussions (on this and other lists)
> that this one is not sufficiently well defined to be added to the schema
> now.  This discussion came up wrt VOTable, and it was recognized as one of 
> a general problem of associating columns.  Column groups were the answer.

Ahem, well actually this particular one is very well defined for *most* cases :-)

Yes we can discuss the wider general problem that we can sort out later; what 
I'm really after just now is a way of making this particular association.

> We 
> could add it now as a "simple but useful" solution with the possibility of 
> having to yank it out later.  (I'm less worried about this kind of 
> volatility in VODataService.)

That's exactly what I would like to see.  As we actually publish real data we'll 
see how these fields get filled in, and no doubt there will be more changes to 
follow.  Who knows, it might turn out looking just like VOTable headers :-)

> Regardless, I encourage you to post your update to VOResourceV010Disc
> (perhaps just include the new definition of the Param type);  it's a lot
> easier to discuss when we have something concrete down.

All I want to add (for now!) is the optional elements:

    <xs:element name="ErrorColumn" type="xs:string"/>

and

    <xs:element name="UcdPlus" type="xs:string"/>

to

    <xs:complexType name="ParamType">

so that both can be filled in as we deploy datacenters *now*; we can always 
transform the metadata documents later if we change our minds. However if I'm 
going to have to persuade data owners to go through a few hundred columns I'd 
like to fill out the metadata fields as completely as possible, rather than 
leaving some bits out and having to go over the whole laborious process again 
later when we finally get around to agreeing a set of comprehensive tags.

Perhaps the best thing to do is for Astrogrid to develop the TabularSkyService 
type, since it appears that noone else is going to use it anyway?  As I 
understand it, the only other people developing SkyNodes are NVO, and they are 
not going to provide this metadata as a document.  We can make sure the relevent 
elements are compatible with VOTables!

Cheers,

MC


-- 
Martin Hill
www.mchill.net
+44 7901 55 24 66




More information about the registry mailing list