Quantity "tables"
Ed Shaya
Edward.J.Shaya.1 at gsfc.nasa.gov
Fri Jan 23 13:33:26 PST 2004
Tony Linde wrote:
>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.
>
>
Software would see from Ed.xsd that ed:distance_Cepheid extends (or
restricts) VO:Quantity and hence should be treated and constructed as a
Quantity. It knows from Ed.xsd how it is restricted and how it differs
from VO:distance_Cepheid. It does not use it exactly as
VO:distance_Cepheid, but it may know where to find
edsOWL#distance_Cepheid and from there, it knows things like how to
convert to a VO:distance_Cepheid or to a distance_modulus.
We can get the same effect from <Quantity type="ed:distance_Cepheid"
../> except now it does not look into Ed.xsd for structural
information. It is constructed as free form as any Quantity.
>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