FW: Quantity "tables"
Tony Linde
ael at star.le.ac.uk
Fri Jan 23 10:46:48 PST 2004
Try again, original bounced...
-----Original Message-----
From: Tony Linde [mailto:ael at star.le.ac.uk]
Sent: 23 January 2004 17:32
To: 'Ed Shaya'
Cc: dm at ivoa.net
Subject: RE: Quantity "tables"
Hi Ed,
You cannot use <Quantity type="Galactic_long" ..../> if the type is
enumerated and if it isn't then how does anyone know what to do with the
values.
Actually specifying the elements (or enumerating them in attributes) means
that any software which understands the schema knows what to do with the
element, ie what a Galactic_long is and how to handle it.
Anyone who wants to create a new element can do so in a separate schema. The
software knows that there is somethin new that it cannot handle when it sees
an element belonging to a different namespace.
Cheers,
Tony.
> -----Original Message-----
> From: Ed Shaya [mailto:Edward.J.Shaya.1 at gsfc.nasa.gov]
> Sent: 23 January 2004 16:07
> To: Tony Linde
> Cc: dm at ivoa.net
> Subject: Re: Quantity "tables"
>
>
> Tony,
> <Quantity type="Galactic_long" ..../> is the same concept as
> <Galactic_long .../>, but the difference is,
> the first one you can use as soon as we have a Quantity.xsd
> and before
> it is extended for this particular concept. It is not mechanically
> restricted to only have what we agree upon for Galactic_long.xsd.
>
> Ed
>
>
>
> Tony Linde wrote:
>
> >Quick question, Ed: why is everything a <Quantity ... />
> element? Why
> >not a <Galactic_long ... />, <Galactic_lat ... /> etc? Isn't
> it harder
> >to use the metadata if you've got to work with types of
> Quantity rather
> >than specific elements?
> >
> >Thanks,
> >Tony.
> >
> >
> >
> >>-----Original Message-----
> >>From: owner-dm at eso.org [mailto:owner-dm at eso.org] On Behalf
> Of Ed Shaya
> >>Sent: 22 January 2004 15:56
> >>To: dm at ivoa.net
> >>Subject: Quantity "tables"
> >>
> >>
> >>This is a cross-post with VOTable.
> >>
> >>Simply put XML is hierarchical and a table is not. Hence, there is
> >>this misfit between XML tools (XQuery, XPath, XSLT,
> >>WebServices) and our XML/Table efforts (Astrores, VOTable,
> >>XDF, Dataset, etc). XML's hierarchies make it more suitable
> >>for describing an object's structure. Tables are compact and
> >>human-friendly, especially when one gets to large (but not too
> >>large) amounts of info. We want it all, but we are
> >>struggling to make tables fit beautifully into XML, and
> >>falling into circles of inconsistencies.
> >>
> >>In true XML, tables are something to convert to or from. XHTML has
> >>tables explicitly described, but XHTML is a display language. One
> >>transforms from your true XML into XHTML only at display time.
> >>
> >>XML is meant to interchange with relational databases.
> Using a schema
> >>based on true XML, one creates a database configuration and
> flattens
> >>the documents into one or several tables. The tables are
> now strictly
> >>speaking outside of the XML realm but an XML front end
> allows one to
> >>address the data as if it were still in true XML.
> Although, it should
> >>be noted that native XML databases are getting pretty mature and
> >>maybe we won't be doing this much longer.
> >>
> >>I conclude that we should start off with a true XML description of
> >>data (ie, not tabular) and then after that matures, rethink tabular
> >>formats, but as either a compressed transmission mode or as a
> >>display mode or as the internals of an object-relational database.
> >>That way, all tools interface with the data in true XML fashions.
> >>If I am right, then it would follow that even our image/table
> >>display tools like Alladin and Mirage would benefit from a
> >>hierarchical view of data.
> >>
> >>Just to make clear what I mean by a "hierarchical view of data",
> >>below is an example of the "non-tabular way". This is just one
> >>galaxy and one must imagine that there are many in this object
> >>oriented database. It would be easy now to extend this to include
> >>additional metadata about each measurement, who observed it, when,
> >>with which instrument, etc. It would also be interested to create a
> >>little schema for each Quantity/@type. A B_T_Quantity.xsd which
> >>extends Quantity could substitute for the <Quantity type="B_T"/> and
> >>provide suitable extensions and restrictions on both metadata
> >>and datatypes.
> >>
> >>OK. Now the crux of this all is that the Tabular form of this is
> >>done by a auto-flattener that simply turns this into a series of
> >>tables exactly as an XML to DB converter does. Now you have a
> >>compact form to transfer and one that can go right into your
> >>local/private DB. If it is an object relational DB you should be
> >>able to access the data with the original true XML schema and XPATH
> >>or XQuery.
> >>
> >>======================================================
> >><AstroObject type="galaxy" name="NGC 300">
> >> <Quantity type="altname" name="PGC
> >>Num"><value>3238</value><units><unitless/></units></Quantity>
> >> <Group name="position">
> >> <Quantity type="RA
> >>
> >>
> >>J2000"><value>00:54:52.6</value><units><unit>xs:time</unit></u
> >>nits></Quantity>
> >> <Quantity type="DE
> >>J2000"><value>-37:40:57</value><units><unit>sexigesimal</unit>
> >></units></Quantity>
> >> </Group>
> >> <Quantity type="Galactic_long"
> >>name="l"><value>299.2306</value><units><unit>degree</unit></un
> >>its></Quantity>
> >> <Quantity type="Galactic_lat"
> >>name="b"><value>-79.4210</value><units><unit>degree</unit></un
> >>its></Quantity>
> >> <Quantity
> >>type="SGL"><value>259.8113</value><units><unit>degree</unit></
> >>units></Quantity>
> >> <Quantity
> >>type="SGB"><value>-9.4984</value><units><unit>degree</unit></u
> >>nits></Quantity>
> >> <Quantity type="brightness absolute B total"
> >>name="B_T"><value>8.95</value><units><unit>magnitude</unit></u
> >>nits></Quantity>
> >> <Quantity type="extinction I-band"
> >>name="A_I"><value>0.02</value><units><unit>magnitude</unit></u
> >>nits></Quantity>
> >> <Quantity type="extinction B-band"
> >>name="A_B"><value>0.055</value><units><unit>magnitude</unit></
> >>units></Quantity>
> >> <Quantity type="axis ratio b/a" shape
> >>name="b/a"><value>0.73</value><unitless/></Quantity>
> >> <Quantity type="morphology type T"
> >>name="Ttype"><value>7</value><unitless/></Quantity>
> >> <Quantity type="morphology type M"
> >>name="Mtype"><value>SA(s)d</value><unitless/></Quantity>
> >> <Group type="velocity radial">
> >> <Quantity type="geocentric" name="V_gsr">
> >> <value errorValue="4." >101.</value>
> >> <units><unit>km</unit><unit power="-1">s</unit></units>
> >> </Quantity>
> >> <Quantity type="heliocentric" name="V_helio">
> >> <value errorValue="4.">144.</value>
> >> <units><unit>km</unit><unit power="-1">s</unit></units>
> >> </Quantity>
> >> </Group>
> >> <Quantity type="linewidth 21cm @20percentOfPeak" name="W20">
> >> <value ErrorValue="7.">166.</value>
> >> <units><unit>km</unit><unit power="-1">s</unit></units>
> >> </Quantity>
> >> <Quantity type="distance Cepheid" name="Cepheid dist"><value
> >>errorVAlue="2.3"
> >>
> >>
> >>>26.66</value><units><unit>Mpc</unit></units></Quantity>
> >>>
> >>>
> >> <Quantity type="distance TRGB" name="TRGB
> >>dist"><value>UNKNOWN</value><units><unit>Mpc</unit></units><
> /Quantity>
> >> <Quantity type="distance PNLF" name="PNLF
> >>dist"><value>26.9</value><units><unit>Mpc</unit></units></Quantity>
> >> <Quantity type="distance SBF" name="SBF
> >>dist"><value>UNKNOWN</value><units><unit>Mpc</unit></units><
> /Quantity>
> >> <Quantity type="distance TF" name="Tully-Fisher
> >>dist"><value>UNKNOWN</value><units><unit>Mpc</unit></units><
> /Quantity>
> >> <Quantity type="axes"><valueList>21.9
> >>15.5</valueList><units><unit>arcmin</unit></units></Quantity>
> >> <photometry>
> >> <region>
> >> <fitsFile href="HSTDA/retrieve/n300.u65w0201r.fits">
> >> <instrument>WFPC2</instrument>
> >> <observationDate>2001:05:06</observationDate>
> >>
> >><rightAscension>1.372291666667E+01</rightAscension>
> >> <declination>-3.768333333333E+01</declination>
> >> <rotation>168.502</rotation>
> >> <filters>F814W</filters>
> >> <exposureTime units="second">40.</exposureTime>
> >> <proposalId>8599</proposalId>
> >> <observer>Boeker</observer>
> >> <history>
> >> <date>2001:08:24</date>
> >> <creator>Felicia Tam</creator>
> >> <item>mosaic of all 4 ccds</item>
> >> </history>
> >> </fitsFile>
> >> <fitsFile href="HSTDA/retrieve/n300.u65w0202r.fits">
> >> <telescope>HST</telescope>
> >> <instrument>WFPC2</instrument>
> >> <observationDate>2001:05:06</observationDate>
> >>
> >><rightAscension>1.372291666667E+01</rightAscension>
> >> <declination>-3.768333333333E+01</declination>
> >> <rotation>168.502</rotation>
> >> <filters>F814W</filters>
> >> <exposureTime units="second">300.</exposureTime>
> >> <proposalId>8599</proposalId>
> >> <observer>Boeker</observer>
> >> <history>
> >> <date>2001:08:24</date>
> >> <creator>Felicia Tam</creator>
> >> <item>mosaic of all 4 ccds</item>
> >> </history>
> >> </fitsFile>
> >> <fitsFile href="HSTDA/retrieve/n300.u65w0203r.fits">
> >> <telescope>HST</telescope>
> >> <instrument>WFPC2</instrument>
> >> <observationDate>2001:05:06</observationDate>
> >>
> >><rightAscension>1.372291666667E+01</rightAscension>
> >> <declination>-3.768333333333E+01</declination>
> >> <rotation>168.502</rotation>
> >> <filters>F814W</filters>
> >> <exposureTime units="second">300.</exposureTime>
> >> <proposalId>8599</proposalId>
> >> <observer>Boeker</observer>
> >> <history>
> >> <date>2001:08:24</date>
> >> <creator>Felicia Tam</creator>
> >> <item>mosaic of all 4 ccds</item>
> >> </history>
> >> </fitsFile>
> >> </region>
> >> <region>
> >> <fitsFile href="shoko/n300.fits">
> >> <telescope>HST</telescope>
> >> <instrument>WFPC2</instrument>
> >> <observationDate>2001:07:02</observationDate>
> >>
> >><rightAscension>1.375416666667E+01</rightAscension>
> >> <declination>-3.758000000000E+01</declination>
> >> <rotation>-154.402</rotation>
> >> <filters>F814W</filters>
> >> <exposureTime units="second">600.</exposureTime>
> >> <proposalId>9162</proposalId>
> >> <observer>Tully</observer>
> >> <history>
> >> <date>2001:07:09</date>
> >> <creator>Shoko Sakai</creator>
> >> <item>mosaic of all 4 ccds</item>
> >> <item>cosmic ray cleaned and summed</item>
> >> </history>
> >> </fitsFile>
> >> <psFile name="NGC 300 Color-Magnitude Diagram"
> >>href="shoko/n300cmd.ps"/>
> >> </region>
> >> </photometry>
> >> <kinematics>
> >> <reference>
> >> <title>H I studies of the Sculptor group
> >>galaxies. VI - NGC
> >>300</title>
> >>
> >><author><initial>D</initial><lastName>Puche</lastName></author>
> >>
> >> <author><initial>C</initial><lastName>Carignan</lastName></author>
> >>
> >><author><initial>A</initial><lastName>Bosma</lastName></author>
> >> <abstract>A study of the kinematics of the
> Sculptor group
> >>galaxy NGC 300 is presented. VLA observations of the H I
> line show a
> >>dramatically warped H I disk just outside the optical disk. A
> >>two-component mass model, fitted to the data, gives a total mass of
> >>2.4E10 solar masses at the last observed point of the
> rotation curve.
> >>This value implies an (M/L_B)global about 11 solar masses/solar
> >>luminosity for the galaxy which is compared with the total dynamical
> >>(M/L_B)dyn of the group. This comparison suggests that dark
> >>matter is probably more concentrated around the galaxies of
> >>the group than uniformly distributed in the intergalactic medium.
> >> </abstract>
> >> <bibcode>1990AJ....100.1468P</bibcode>
> >> </reference>
> >> </kinematics>
> >></galaxy>
> >>
> >>
> >>Ed
> >>
> >>
> >>
> >>
> >
> >
> >
>
>
More information about the dm
mailing list