Quantity "tables"
Tony Linde
ael at star.le.ac.uk
Fri Jan 23 10:22:45 PST 2004
Hi Ed,
I don't think it is an issue so much of optional vs mandatory as of
recognised and unrecognised.
If an element is defined in a schema, <Galactic_lat ... /> in AstroData.xsd
then any data document, galaxy.xml, which namespaces AstroData and includes
the Galactic_lat element can be used by software which understands what to
do with AstroData type data.
Now, if your data document includes an element <distance_Cepheid ... />
which belongs to a separate namespace (referencing Ed.xsd, say) then the
software knows to ignore that element.
However, if every element is called Quantity (namespaced as AstroAll.xsd)
with a type attribute which is not enumerated then how does the software
know whether it can handle the contents of the document. It recognises the
namespace AstroAll and the Quantity element but does not know what to do
with the type="distance_Cepheid" attribute. The software should know what it
can do and cannot from the namespacing, not from the contents of attributes.
Or that is my understanding of xml, at least.
Cheers,
Tony.
> -----Original Message-----
> From: Ed Shaya [mailto:Edward.J.Shaya.1 at gsfc.nasa.gov]
> Sent: 23 January 2004 17:57
> To: Tony Linde
> Cc: dm at ivoa.net
> Subject: Re: Quantity "tables"
>
>
> Tony,
> Another thought on this. We should have all sorts of
> metadata type
> quantities available (observer, filter, date, telescope, observatory,
> project, etc). But, I do not think that the Galactic_lat.xsd would
> require any of this. Data providers should put in whatever Metadata
> Quantities they have on each Quantity, but maybe they don't
> have much. Maybe a date should be required, but even that
> does seem required for
> say a galaxy at high red shifts and the value is averaged over many
> measurements over many years. So, I don't think we can make many
> useful restrictions beyond the general Quantity for many of our
> concepts. About the only sure restriction is that the units must of
> 'dimension' angle.
>
> 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