I have followed with interest the discussion and I have to admin that,
while I agree a little on what Francois and Patricio have said, I also
know that we cannot try to look at the problem as if it's a totally
brand new one. Kmart might not have what we need by any means, but
perhaps there are solutions out there that are flexible enough to be
"adapted" for our purposes.
I think that among the directions we decide are "best", we need to include those that are indeed feasable given our requirements and our timescale regardless if they are employed by Microsoft, Walmart or Kmart.
Another $0.02...
Alberto
-- Dr Alberto Conti Space Telescope Science Institute 3700 San Martin Drive Baltimore, MD 21218 USA Tel: +1 (410) 338 4534 Fax: +1 (410) 338 4767 -----Original Message----- From: owner-votable-at-eso.org [mailto:owner-votable-at-eso.org]On Behalf Of Patricio F. Ortiz Sent: Tuesday, January 20, 2004 5:08 PM To: Francois Ochsenbein Cc: Tamas Budavari; votable-at-ivoa.net Subject: Re: Microsoft's "Dataset.xml" On Tue, 20 Jan 2004, Francois Ochsenbein wrote:Received on 2004-01-20Z23:27:04
>
> I got your example, Tamas, which contains:
>
> <?xml version="1.0" encoding="utf-8"?>
> <DataSet xmlns="http://skyservice.pha.jhu.edu">
> <xs:schema id="CasResult" xmlns=""
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
> <xs:element name="CasResult" msdata:IsDataSet="true">
> <xs:complexType>
> <xs:choice maxOccurs="unbounded">
> <xs:element name="Table">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="objid" type="xs:long"
minOccurs="0" />
> <xs:element name="ra" type="xs:double" minOccurs="0"
/>
> <xs:element name="dec" type="xs:double"
minOccurs="0" />
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> </xs:choice>
> </xs:complexType>
> </xs:element>
> </xs:schema>
> <diffgr:diffgram
xmlns:msdata="urn:schemas-microsoft-com:xml-msdata" xmlns:diffgr="urn:schemas-microsoft-com:xml-diffgram-v1">
> <CasResult xmlns="">
> <Table diffgr:id="Table1" msdata:rowOrder="0">
> <objid>582100152821940758</objid>
> <ra>259.717782786004</ra>
> <dec>25.6622296171871</dec>
> </Table>
> <Table diffgr:id="Table2" msdata:rowOrder="1">
> <objid>582100152821940993</objid>
> <ra>259.741105598172</ra>
> <dec>25.6757329621483</dec>
> </Table>
> </CasResult>
> </diffgr:diffgram>
> </DataSet>
>
> As a computer scientist, you may be happy with the result, but as an
> astronomer I feel frustrated by this schema: there is absolutely NO
> metadata which would enable a usage in an astronomical context: no
> definition of the parameters, and no semantic content at all!
> The VOTable schema is exactly trying to avoid this jungle where
> each dataset is written with is own definitions -- generating
> some kind of Babel tower, instead of interoperable datasets...
I fully agree with you Francois in this one. The description may make a lot of sense for an XML document, but I feel like in "back in time" or "deja vu" (sp?) as this scheme is not much different (although lots of times more verbose) than the case of tables in the literature we had a few years ago. I thought we've learned that column names can not describe quantities properly in a very heterogeneous environment, perhaps they're fine for Kmart where things are well defined and a lot of closed commercial environments, but propagate it to science and the number of ambiguities which a scheme like this will generate will prevent any type of interoperability. As an "astro", I feel that we should look for solutions suitable to our discipline, take what's good from the commercial world but not get blinded by fashionable trends, as they may take away our freedom to advance in the directions we decide are best. Just my two cents, Patricio --- Patricio F. Ortiz pfo-at-star.le.ac.uk AstroGrid project Department of Physics and Astronomy University of Leicester Tel: +44 (0)116 252 2015 LE1 7RH, UK