> - VOTable has managed to (neraly) fully describe astronomical data by the
> inclusion of meta-data within the same document, a fact that not even
> FITS had fully achieved. Metadata being a key ingredient for VO.
Absolutely, meta-data is the key thing. If the data isn't self describing then you need a human to make guesses about it before its useable. This isn't really desirable.
> - In its current format, VOTable is human understandable and the metadata
> can be easily followed.
While some people will disagree, I think this is very important, and no, this doesn't contradict the point I just made above!
> - If one sticks to human readable form, (<TD></TD>), the overhead is
> considerable, eg, a 48K+ rows QSO catalogue uses 14.6 Mb while its TSV
> version occupies 5.1Mb.
For larger tables some form of binary representation is obviously going to be necessary. Personally I'm in favour of the URI point to a FITS file option for large data chunks, that way if the meta-data is all you were concerned about you don't actually have to transmit the actual data at all. You pull the actual data on demand, in binary, this makes alot more sense than embedding a couple of hundred megabytes of data in base64 inline in the XML document!
> - I've been working with web services, (clients and servers), and one sees
> the difference. Another point is that because VOTable is an XML document,
> seems that when one embeds it into a SOAP envelope (XML), some XML
> parsers may interpret the VOTable content. Curiously enough, if I
> uuencode the VOT previous to be send, interpretation time goes down, even
> when the volume increases slightly.
Yes, if you embed a pure XML document into a SOAP envelope many SOAP servers will parse the VOTable. Personally I get round this by shoving the VOTable through as a parameter encoded as base64. There are other ways around it of course, and a Web Service returning a VOTable in a document literal mode isn't going to have this problem.
> - I would propose to add an alternative binary representation to the
> current row-wise write/read mode. In a number of cases, the software
> producing a VOT is aware of the resulting number of rows, enabling
> the writing of the data column-wise, ie, all-of-column1, followed by
> all-of-column2 and so on. Data volumne is not affected by this new
> scheme, but reading efficiency increases.
More features? We already have lots of features that aren't getting used in the wild. What's the justification behind this one?
> Finally, a points that worries me regarding meta-data is the representation
> of the equinox for equatorial coordinates. There are some solutions, but
> there is no standard (as far as I know). Data federation tools (like cross
> matchers) do need this meta-information to be represented in a standard
> way, without having to tune the software to how things are done in
> different data-centers.
Yes, as I've mentioned before (and been shouted down) the meta-data representing the co-ordinate frame of the RA & Dec coordinates is crucial if the data is going to be scientifically valid. You need to provide the epoch, equinox and system of the RA & Dec values you're shipping, if you don't then they're pretty much meaningless... and yes, I'm just as big an offender as anyone else here, alot of my stuff doesn't do it properly either.
Al.
-- Dr. A. Allan, School of Physics, University of ExeterReceived on 2004-01-19Z15:22:50