From andrea.preitemartinez at rm.iasf.cnr.it Sun May 1 22:15:45 2005 From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez) Date: Mon, 2 May 2005 07:15:45 +0200 Subject: New list of words Message-ID: <20050502071545.o2qry3nmgtcgok8s@webmail.sic.rm.cnr.it> Dear member of the UCD_wg, since last Friday (20050429) an updated list of UCD words is available at: http://vizier.u-strasbg.fr/UCD/ucd1p-words.txt at the UCD page: http://vizier.u-strasbg.fr/UCD/ The new list of words has been edited according to the very valuable comments coming from the community and also thanks to the (almost!) every day use of them made by Sebastien and myself. The most important differences with the previous version (20040823) concern - distances and sizes (linear/angular) - the introduction of a rectangular/cartesian reference frame - the phot.color section, much simplified - spelling, abbreviations, syntax ... At the UCD page you can also find un updated version of the UCD_tree browser(s) and a new tool, the ucd_builder: http://vizier.u-strasbg.fr/UCD/cgi-bin/descr2ucd that uses a description in "natural" language to find the relevant ucd_words, and then tries to build a valid ucd out of them. In these two weeks before Kyoto please explore the list, use the tools and send back comments. A more "formal" comment page is available to suggest changes in the list of words at: http://vizier.u-strasbg.fr/UCD/cgi-bin/comment/ucdComments Have fun. Andrea ============================================================================== Andrea Preite Martinez andrea at rm.iasf.cnr.it Istituto di Astrofisica Spaziale Tel.:+39.06.4993.4641 Area di Ricerca di Tor Vergata Fax.:+39.06.2066.0188 Via del Fosso del Cavaliere 100 Cell:+39.339.3817355 00133 Roma ============================================================================== From Alberto.Micol at eso.org Mon May 2 03:25:47 2005 From: Alberto.Micol at eso.org (Alberto Micol) Date: Mon, 2 May 2005 12:25:47 +0200 Subject: New list of words In-Reply-To: <20050502071545.o2qry3nmgtcgok8s@webmail.sic.rm.cnr.it> References: <20050502071545.o2qry3nmgtcgok8s@webmail.sic.rm.cnr.it> Message-ID: Dear Andrea, Thanks a lot for the new list! A couple of comments/suggestions: Versioning: the ucd1p-words.txt file does not contain any version one could refer to. On this topic, the UCD page (http://vizier.u-strasbg.fr/UCD/) provides a link to "ucd1p-words.txt" and a link to "ucd1p-words-20050429.txt" and it is not clear whether one is a link to the other (I would prefer to always see the version in the file name). Also, beware that the document pointed to in the UCD page ("Explanations on the vocabulary are available in IVOA WD-UCDlist-20050429.pdf") is not found on the ivoa web site. Then, looking at the list with biased eyes given that these days I'm working on the Characterisation DM, I have a remark on some asymmetry within the list. For example let's take the Resolution concept for which I can find: Q|instr.angRes |Angular resolution Q|instr.spect.resolution |Spectral (or velocity) resolution Q|time.resolution |Time resolution The problems I see with this are: 1.- the resolution (think of an image from the ground) is not only a instrumental effect (unless one thinks of the atmosphere as part of the instrument) 2.- In the charcterisation DM, resolution on the various axes is treated symmetrically Hence, my preference would go for something along these lines: Q|pos.resolution |Angular resolution Q|spect.resolution |Spectral (or velocity) resolution Q|time.resolution |Time resolution What do you think? Ciao, Alberto PS: Just another little question on: S|instr.pixel |Pixel what is that for? In which case is it used? Thanks. On May 2, 2005, at 07:15, Andrea Preite Martinez wrote: > Dear member of the UCD_wg, > > since last Friday (20050429) an updated list of UCD words is available > at: > > http://vizier.u-strasbg.fr/UCD/ucd1p-words.txt > > at the UCD page: > > http://vizier.u-strasbg.fr/UCD/ > ... From andrea.preitemartinez at rm.iasf.cnr.it Mon May 2 04:56:47 2005 From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez) Date: Mon, 2 May 2005 13:56:47 +0200 Subject: New list of words In-Reply-To: References: <20050502071545.o2qry3nmgtcgok8s@webmail.sic.rm.cnr.it> Message-ID: <20050502135647.sugef32llp0gkk4g@webmail.sic.rm.cnr.it> Dear Alberto > > beware that the document pointed to in the UCD page > ("Explanations on the vocabulary are available in IVOA > WD-UCDlist-20050429.pdf") is not found on the ivoa web site. sorry, still editing a section... > I have a remark on some asymmetry within the list. For example > let's take the Resolution ... > ... my preference would go for something along these lines: > > Q|pos.resolution |Angular resolution > Q|spect.resolution |Spectral (or velocity) > resolution > Q|time.resolution |Time resolution > > What do you think? I like your proposal. I'm sure you'll have other before Kyoto! > PS: Just another little question on: > S|instr.pixel |Pixel > what is that for? In which case is it used? Try "pixel size" on the builder. Andrea From Hessman at Astro.physik.Uni-Goettingen.DE Mon May 2 05:58:37 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Mon, 2 May 2005 14:58:37 +0200 Subject: New UCDs for VOEvent please In-Reply-To: <4272824B.7010900@gsfc.nasa.gov> References: <32fd4a5efbfd9d3afbbae300411c0379@Astro.physik.Uni-Goettingen.DE> <426FBAC9.2050600@cacr.caltech.edu> <4272824B.7010900@gsfc.nasa.gov> Message-ID: <71e0852515f7c6122fe60632c6efb16d@Astro.physik.Uni-Goettingen.DE> On 29 Apr 2005, at 8:51 pm, Ed Shaya wrote: > But we can also be keeping another eye on the longer time scale where > we want to be able to put data in machine understandable terms so that > applications can do the most possible on our behalf. This requires > something a bit more sophisticated than just a simple class hierarchy > of terms. An ontology would be more complete but probably not even an > order of magnitude (factor 10) more than the UCD is now. In fact, > given the requests and requirements to augment UCDs, with time, the > UCD will probably grow to the size of an ontology anyway. So, it is > probably wise to start doing some thinking in terms of the formal OWL > standard now. What we do with the ontology can vary greatly. > 1. Use it as a string identifier, exactly as UCDs are. The advantage > is that one can read the Ontology at that point to get more context > for the meaning of the term. > 2. Use it as one more model builder for developing schemas. This is > like UML but more in tune with knowledge/information structures. I > think this is what Mathew had in mind. > 3. Use it to test completeness and consistency of terms. This would > not be on the fly, but rather as one adds new terms one can see > whether it is clashing with other terms and Venn diagrams let you see > something about completeness. This then makes it more acceptable for > groups to be adding terms into their namespace without going to the VO > heads or the IAU. > 4. One can use it as the defining structure of all information being > exchanged. Sounds daring but in fact several other related science > fields are preparing to do just that, including space physics. > 5. One can use it to reason out pathways to converting, pipelining, > and analysing data. It should be possible to automatically find the > transformation and queries needed to satisfy an arbitrary stated goal > or request. Our group at UMD has an NASA/AISRP grant to figure out > the basics of how this might be done using OWL. Ummm.... maybe my googling didn't go quite as far or I'm missing something: the "ontology" I found was a "low-level" (no - that sounds too negative - let's say "very fundamental") means of describing scientific quantities - nothing particularly "astronomical" about it. If this is as far as anyone has gotten, then I vote for a mid-term temporary solution - what I've called "VOThings" - which someone else can turn into a full astronomical ontology in the future. Thus, - Small, multiple, overlapping, incompatible lists within different schemata will be an unnecessary pain, so we need a minimal common-ground list. - A formal development of a real astronomical ontology will take many years and we can't wait that long. - We should resist the temptation to make VOThings "complete" since it won't ever be such and we'd waste time in trying. Maybe having such a terrible name will be a good thing - let's get it over quickly knowing that some day somebody else will get it right. Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From Alberto.Micol at eso.org Tue May 3 01:54:53 2005 From: Alberto.Micol at eso.org (Alberto Micol) Date: Tue, 3 May 2005 10:54:53 +0200 Subject: New list of words In-Reply-To: <20050502135647.sugef32llp0gkk4g@webmail.sic.rm.cnr.it> References: <20050502071545.o2qry3nmgtcgok8s@webmail.sic.rm.cnr.it> <20050502135647.sugef32llp0gkk4g@webmail.sic.rm.cnr.it> Message-ID: Dear Andrea, > I'm sure you'll have other before Kyoto! I'm taking it seriously :-) Here some other comments, in no particular order: 1. pos.frame exists, can we also add the spect.frame and time.frame? 2. instr.spec: probably not needed because otherwise we would also need instr.imager, and similarly for other kinds of instruments. Also, instr.spect.dispersion could simply be instr.dispersion instr.spect.order " " " instr.order (in fact there is no need to say instr.imager.scale, instr.scale is enough). 3. Transmission (an old friend of mine): some time ago Sebastien and I exchanged some emails and, if I remember correctly, we agreed that there should be a phys.transmission which could be attached to any of: instr.det, instr.filter, instr to distinguish between the transmission/sensitivity of the various components (detector, filter, optical elements) and the overall transmission (filter * detector * optical elements) including even the atmosphere if necessary. 4. instr.sensitivity; Its description reads: Instrument sensitivity, detection threshold I would say that sensitivity and detection threshold, while linked, are two different concepts, and would be better to split that one into 2 different UCDs 5. Descriptions: sometimes the description of a ucd is ambiguous, e.g.: a. instr.tel.focus (Q): Telescope focus b. instr.bandpass (Q): Bandpass of instrument c. instr.pixel (S): Pixel a. Is instr.tel.focus the "name" of the telescope focus (eg nasmith), or the focal length of the telescope? b. instr.bandpass How many services will make use of this ucd to describe a table column that contains the numeric transmission at a given wavelength of a given filter? Some other service will use this ucd to describe the name of the bandpass (or the filter name). Which one of the two is legitimate, both? (see (3) above). c. Another, though different, example is the instr.pixel I can think of a catalog associated with an image, where X and Y indicate at which detector coordinates the source was found (pos;instr.pixel). But it can be used to indicate the pixel scale of the detector (phys.angSize;instr.pixel) The fact is that instr.pixel is a Secondary word, hence its meaning could be broader. For that reason probably both above mentioned cases are legitimate: instr.pixel is only an attribute (an adjective in a grammar-speak). I think it is very important to be clear, especially on those words that could be Primary, because otherwise people might misuse UCDs and that would make the entire concept collapse. 6. Abbreviations: Why temperature is some times abbreviated and some other times not? (e.g., instr.skyTemp, phot.antennaTemp, phys.temperature) Wouldn't be better to be consistent? 7. wcs information pos.wcs.ctype: How would the software recognise ctype1 from ctype2 ? Would it be possible to say: pos.wcs.ctype;arith.first and pos.wcs.ctype;arith.second? Or maybe (see cdmatrix below): arith.1 and arith.2 The same for pos.wcs.crpix, crval and naxis pos.wcs.cdmatrix: how to distinguish the various matrix elements? what about accompaining the cdmatrix with a arith.1_1, arith.1_2, etc.? That arith.1, etc. could be useful to rank things. 8. question regarding files meta.file exists; how can I describe the size (eg in bytes) of a file? and its CRC? Probably enough for this morning... ;-) And, beware, I might come back with more DM issues. :-) Ciao, Alberto From norman at astro.gla.ac.uk Tue May 3 07:18:22 2005 From: norman at astro.gla.ac.uk (Norman Gray) Date: Tue, 3 May 2005 15:18:22 +0100 Subject: UCD name documentation Message-ID: <1eff2d5b2ed291becf05825cb37fd8e6@astro.gla.ac.uk> Greetings, I've just been involved in a discussion in another forum about UCDs, and their general desirability as metadata keywords (in fact it was in the context of the keywords to be extracted by a putative FITS plugin for MacOS X 10.4's Spotlight -- extremely nice). I was trying to discourage folk from using FITS keywords as general metadata, and encourage them to use UCDs instead. As part of this, I produced a set of UCD equivalents for a candidate list of FITS keywords. There were some gaps, however, and I wasn't sure how to go about filling them. Is there a better way than looking through the one-line descriptions in the current list at ? There are two UCD tree browsers on the UCD page, of course, but they're really just a more attractive presentation of the text list and don't, for example, have more discursive documentation. The other UCD tools didn't produce any useful suggestions for `BITPIX' or `number of axes' What would be _really_ nice, of course, is a tool which allowed you to enter one of a subset of FITS keywords and produced one of a few possible UCDs to use instead. So my question is, am I missing something (much more likely than I wish it were)? Such a thing would require an injection of Copious Free Time, of course, but I found myself in a rather awkward place, recommending UCDs over FITS keywords, to an audience which is familiar with FITS, but for whom the UCD list is opaque and rather thinly documented. All the best, Norman -- ---------------------------------------------------------------------- Norman Gray : Physics & Astronomy, Glasgow University, UK http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk From andrea.preitemartinez at rm.iasf.cnr.it Tue May 3 07:41:14 2005 From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez) Date: Tue, 3 May 2005 16:41:14 +0200 Subject: UCD name documentation In-Reply-To: <1eff2d5b2ed291becf05825cb37fd8e6@astro.gla.ac.uk> References: <1eff2d5b2ed291becf05825cb37fd8e6@astro.gla.ac.uk> Message-ID: <20050503164114.gxpb53ye89ygogo4@webmail.sic.rm.cnr.it> Dear Norman, > As part of this, I produced a set of UCD equivalents for a candidate > list of FITS keywords. I did the same exactly a year ago. UCDs have evolved since then, and the list I'm appending was not revised according to the new list now on-line. The list was generated merging the headers produced by 7 observatories/data_producers (with data in all ranges of wl). > There were some gaps, however, and I wasn't > sure how to go about filling them. Is there a better way than looking > through the one-line descriptions in the current list at > ? There are two UCD > tree browsers on the UCD page, of course, but they're really just a > more attractive presentation of the text list and don't, for example, > have more discursive documentation. The other UCD tools didn't produce > any useful suggestions for `BITPIX' or `number of axes' I agree, even the "builder" will not be of great help with BITPIX! > What would be _really_ nice, of course, is a tool which allowed you to > enter one of a subset of FITS keywords and produced one of a few > possible UCDs to use instead. If you think that the appended list (better, an updated version of it) could be the base for such a tool, I'll do it (the tool, I mean) All the best, Andrea -------------- next part -------------- #FITS Keyword | Description | Proposed UCD1+ #Andrea, 10/10/2003 | Rev.17/05/2004 | # | | AIRMASS | air mass | obs.air.mass AIRT_EOS | air temperature at End of Scan | phys.temperature;obs.air AIRT_SOS | air temperature at Start of Scan | phys.temperature;obs.air AMASS_FC | approximate air mass at image center | obs.air.mass AM_EOS | air mass at End of Scan | obs.air.mass AM_SOS | air mass at Start of Scan | obs.air.mass APERTURE | name of field of view aperture | meta.id;instr.fov ARCFILE | archive file name | meta.id;meta.file ARYT_EOS | array temperature at End of Scan | phys.temperature;instr AUTHOR | author of the data | meta.bib.author BANDPASS | GSSS bandpass code | instr.bandpass BANDW | total bandwidth of observation | instr.bandwidth BAR_EOS | barometric pressure at End of Scan | phys.pressure;obs.air BAR_SOS | barometric pressure at Start of Scan | phys.pressure;obs.air BASE | pixel dwell time | time;instr.pixel BITPIX | bits per data value | meta.fits.bitpix BLANK | value used for undefined array elements | meta.code;meta.table BLOCKED | is physical blocksize a multiple of 2880? | meta.code;meta.fits BSCALE | linear factor in scaling equation | arith.factor BUNIT | physical units of the array values | meta.unit BZERO | zero point in scaling equation | arith.zp CALID | calibration identifiers for image | meta.id;phot.calib CDELTia | coordinate increment along axis ia | pos.wcs CDi_ja | linear transformation matrix (with scale) | pos.wcs CHECKSUM | checksum for the current HDU | meta.fits.software CHECKVER | version of checksum algorithm | meta.fits.software COMMENT | descriptive comment | meta.note CONFIGUR | s/w configuration used to process the data | meta.fits.software CONTINUE | denotes the CONTINUE long string keyword convention | meta.note CREATOR | name of software task that created the file | meta.id;meta.fits.software CROTAn | coordinate system rotation angle | pos.wcs CRPIXja | pixel coordinate of the reference point | pos.wcs CRVALia | coordinate system value at reference point | pos.wcs CTYPEa | axis type | pos.wcs CUNITia | units of CRVALia and CDELTia | pos.wcs DATAMAX | maximum data value | stat.max DATAMEAN | mean data value | stat.mean DATAMED | median data value | stat.median DATAMIN | minimum data value | stat.min DATAMODE | pre-processor dat mode | meta.fits.software DATARMS | RMS of data values | stat.stdev DATASUM | checksum of the dat records | meta.fits.software DATE | date of file creation | time.epoch;meta.fits DATE-END | date of the end of observation | time.end DATE-OBS | date of the observation | time.epoch DATE_EOS | U.T. date at End of Scan | time.end DATE_SOS | U.T. date at Start of Scan | time.start DAYNUM | sequential survey day number | time.epoch DEC | declination of the observed object | pos.eq.dec DEC_EOS | scan reference declination J2000 | pos.eq.dec DEC_NOM | nominal declination of the observation | pos.eq.dec DEC_OBJ | declination of the observed object | pos.eq.dec DEC_PNT | dec of the pointed direction of the instrument | pos.eq.dec DEC_SCX | declination of the X spacecraft axis | pos.eq.dec;instr DEC_SCY | declination of the Y spacecraft axis | pos.eq.dec;instr DEC_SCZ | declination of the Z spacecraft axis | pos.eq.dec;instr DEC_SOS | scan reference declination J2000 | pos.eq.dec DETNAM | name of detector used to make the observation | meta.id;instr.det DXFS | cross-scan frame step for image | # DYFS | in-scan frame step for image | # ELAPTIME | elapsed time of the observation | time.expo END | marks the end of the header keywords | meta.note EPOCH | equinox of celestial coordinate system | time.equinox EQUINOX | equinox of celestial coordinate system | time.equinox EXPOSURE | exposure time | time.expo EXPTIME | exposure time | time.expo EXTEND | may the FITS file contain extensions? | meta.code EXTLEVEL | hierarchical level of the extension | meta.code EXTNAME | name of the extension | meta.id;meta.code EXTVER | version of the extension | meta.id;meta.code FILENAME | name of the file | meta.id;meta.file FILETYPE | type of file | meta.code;meta.file FILTER | name of filter used during the observation | meta.id;instr.filter FILTERn | name of filters used during the observation | meta.id;instr.filter FLXSCALE | relative flux scale | arith.factor;phot.flux FN_PRNX | observatory filename prefix | meta.id;meta.file FOCUS | telescope focus setting | meta.code;instr.tel.focus FREQ0 | rest frequency | em.freq FREQR | reference frequency | em.freq GCOUNT | group count | meta.number;meta.fits GRATING | name of the grating used during observation | meta.id;instr.grating GRATINGn | name of the grating used during observation | meta.id;instr.grating GROUPS | indicates random groups structure | meta.note HA_EOS | hour angle at End of Scan | pos.az.ha HA_SOS | hour angle at Start of Scan | pos.az.ha HDUCLASS | general identifier for the classification of the data | meta.fits.hdu HDUCLASn | hierarchical classification of the data | meta.fits.hdu HDUDOC | reference to document describing the data format | meta.fits.hdu HDULEVEL | hierarchical level of the HDU | meta.fits.hdu HDUNAME | descriptive name of the HDU | meta.fits.hdu HDUVER | version number of the HDU | meta.fits.hdu HDUVERS | specific version of the document referenced by "HDUDOC" | meta.fits.hdu HIERARCH | denotes the HIERARCH keyword convention at ESO | meta.fits.eso HISTORY | processing history of the data | meta.note;meta.fits ICSVERSN | "ics" script version | meta.fits.software INHERIT | denotes the INHERIT keyword convention | meta.note;meta.fits INSTRUME | name of instrument | meta.id;instr IS_OFF1 | in-scan offset - SOS to frame 1 | # IS_OFF2 | in-scan offset - SOS to end frame | # JD-END | Julian Day at end | time.end JD-START | Julian Day at start | time.start JDAY | Julian Day of observation | time.epoch LATITUDE | geographic latitude of the observation | pos.earth.lat LIVETIME | exposure time after deadtime correction | time.expo MAGZP | calibrated zero point for image (magnitudes) | arith.zp;phot.calib MAPLAB | label of the map | meta.id;obs.field MISSION | mission name | meta.id;instr.obsty MJD-OBS | modified Julian Day at start | time.start MJDREF | modified Julian Day zero point for times | time.epoch MOONANGL | angle between the observation and the moon | pos.posAng NAXIS | number of axes | phys.dimens;meta.table NAXISn | size of the axis n | phys.size;meta.table.axis NEXTEND | Number of standard extensions | meta.number NOISE | noise value in map | instr.det.noise NORM | normalization factor in "fast fourier transform" | arith.factor;stat.Fourier NUMFRMS | number of frames in scan | meta.number OBJECT | name of observed object | meta.id;src OBJNAME | IAU name of observed object | meta.id;src OBSERVER | observer who acquired the data | obs.observer OBS_ID | unique observation ID | meta.id;obs OBS_MODE | instrumental mode of the observation | meta.code;instr.setup ONTIME | integration time during the observation | time.expo ORDATE | observation reference date | time.epoch ORIENTAT | position angle of image y axis (deg. E of N) | pos.posAng ORIGFILE | original file name | meta.id;meta.file ORIGIN | organization responsible for the data | meta.id;instr.obsty PA_PNT | position angle of the pointing | pos.posAng PCDEC | pointing center declination | pos.eq.dec;obs PCOUNT | parameter count | meta.number PCRA | pointing center R.A. | pos.eq.ra;obs PCi_ja | linear transformation matrix | pos.wcs PIXNAM | "pixphot" processing namelist configuration id | meta.fits.software PLATEID | GSSS plate id | meta.id;instr.plate PLTDECD | Dec (degrees) of plate center | pos.eq.dec.degrees;instr.plate PLTDECM | Dec (arcmin) of plate center | pos.eq.dec.arcmin;instr.plate PLTDECS | Dec (arcsec) of plate center | pos.eq.dec.arcsec;instr.plate PLTDECSN | Dec (sign) of plate center | pos.eq.dec.sign;instr.plate PLTGRADE | plate quality grade | meta.code;instr.plate PLTLABEL | observatory plate label | meta.id;instr.plate PLTRAH | R.A. (hours) of plate center | pos.eq.ra.hours;instr.plate PLTRAM | R.A. (minutes) of plate center | pos.eq.ra.minutes;instr.plate PLTRAS | R.A. (seconds) of plate center | pos.eq.ra.seconds;instr.plate PLTSCALE | plate scale (arcsec per mm) | instr.scale POSITNID | observatory scan position identifier | meta.id;pos,obs.field PROGRAM | the name of the s/w task that created the file | meta.id;meta.fits.software PSCALn | parameter scaling factor axis n | arith.factor PSi_ma | coordinate parameter m (char) | pos.wcs PTYPEn | name of random groups parameter | #meta.id PVi_ma | coordinate parameter m (float) | pos.wcs PZEROn | parameter scaling zero point | arith.zp RA | R.A. of the observation | pos.eq.ra;obs RADECSYS | coordinate reference frame | pos.frame RA_EOS | scan reference R.A. J2000 | pos.eq.ra;obs RA_NOM | nominal R.A. of the observation | pos.eq.ra;obs RA_OBJ | R.A. of the observed object | pos.eq.ra RA_PNT | R.A. of the pointed direction of the instrument | pos.eq.ra;instr RA_SCX | R.A. of the X spacecraft axis | pos.eq.ra;instr RA_SCY | R.A. of the Y spacecraft axis | pos.eq.ra;instr RA_SCZ | R.A. of the Z spacecraft axis | pos.eq.ra;instr RA_SOS | scan reference R.A. J2000 | pos.eq.ra;obs REFERENC | bibliographic reference | meta.bib REGION | GSSS region name | meta.id;instr.plate ROOTNAME | rootname of the file | meta.id;meta.file SATURATE | Data value at which saturation occurs | # SCANDIR | scan direction | # SCANIMG | name of original scan | meta.id;obs SCANNO | nightly scan number | meta.number;obs SCANNUM | identifies scan of the plate | meta.id;instr.plate SCHEDVER | scan scheduled version | meta.code;obs SCRPTFN | script template file name | meta.fits.software SCRPTVER | script template version | meta.fits.software SEESH | seeing shape parameter for image | instr.obsty.site.seeing SEE_EOS | seeing at End of Scan | instr.obsty.site.seeing SEE_SOS | seeing at Start of Scan | instr.obsty.site.seeing SIMPLE | does file conform to the Standard? | meta.code;meta.fits SITELAT | latitude of observatory | pos.earth.lat SITELONG | longitude of observatory | pos.earth.lon SKIPRDOS | number of frames skipped at start of scan | meta.number SKYSIG | point source filtered noise estimate for image | instr.det.noise SKYVAL | modal sky estimate for image | instr.det.noise STRIP_ID | 2MASS tile number | meta.id;obs.field ST_EOS | sidereal time at End of Scan | time.end ST_SOS | sidereal time at Start of Scan | time.start SUNANGLE | angle between the observation and the sun | pos.posAng TBCOLn | beginning column number | meta.id;meta.table.column TDBINn | default histogram bin size for the column | # TDIMn | dimensionality of the array | phys.dimens;meta.table.column TDISPn | display format | meta.code;meta.fits TDMAXn | maximum physical value in the column | stat.max TDMINn | minimum physical value in the column | stat.min TELAPSE | elapsed time of the observation | time.expo TELESCOP | name of telescope | meta.id;instr.tel TELNAME | telescope location (name of site) | instr.obsty.site TELT_EOS | telescope temperature at End of Scan | phys.temperature;instr.tel TELT_SOS | telescope temperature at Start of Scan | phys.temperature;instr.tel TFIELDS | number of columns in the table | meta.number;meta.table.column TFORMn | column data format | meta.code;meta.table.column THEAP | offset to starting data heap address | arith.diff;phys.size;meta.fits TIME-END | time at the end of the observation | time.end TIME-OBS | time at the start of the observation | time.start TIMEDEL | time resolution of data | time.resolution TIMER0 | read1 time | time;instr.setup TIMER1 | read2-read1 time | time;instr.setup TIMER2 | secondary settling time | time;instr.setup TIMEREF | time reference (barycenter/local) | meta.ref;time TIMESYS | time system | meta.ref;time TIMEUNIT | time unit | meta.unit;time TIMEZERO | clock correction | arith.factor;time TIMVERSN | timing system definition | meta.ref;time TITLE | title for the observation or data | meta.id;obs TLMAXn | maximum legal value in the column | stat.max TLMINn | minimum legal value in the column | stat.min TNULLn | value used to indicate undefined table element | meta.code;meta.table TOT-EXPT | total cumulative exposure time | time.expo TOT-IMAG | total number of images | meta.number;obs.image TSCALn | linear data scaling factor | arith.factor TSORTKEY | defines the sort order of a table | # TSTART | start time of observation | time.start TSTOP | end time of observation | time.end TTYPEn | column name | meta.id;meta.table.column TUNITn | column units | meta.unit;meta.table.column TYPE | scan type | meta.code;obs TYPEn | name of random groups parameter | # TZEROn | column scaling zero point | arith.zp;meta.table.column USXREF | 2MASS U-scan X coordinate at image center | # USYREF | 2MASS U-scan Y coordinate at image center | # UT | U.T. time at start | time.start UT_DATE | U.T. date of scan | time.epoch UT_EOS | U.T. at End of Scan | time.end UT_OFF1 | U.T. offset - Start Of Scan to frame 1 | arith.diff;time.start UT_SOS | U.T. at Start of Scan | time.start VEL | center velocity | src.veloc VELCODE | code for center velocity | meta.code;src.veloc VELR | reference velocity | src.veloc WAVEF_P | secondary waveform data file | meta.id;meta.file WCSAXESa | number of axes in WCS description | pos.wcs WDIR_EOS | wind direction at End of Scan | obs.air.wind WDIR_SOS | wind direction at Start of Scan | obs.air.wind WSPD_EOS | wind speed at End of Scan | obs.air.wind WSPD_SOS | wind speed at Start of Scan | obs.air.wind XPIXELSZ | x pixel size | phys.size;instr.pixel XS_OFF1 | x-scan offet - SOS to frame 1 | # XS_OFF2 | x-scan offet - SOS to end frame | # XTENSION | marks beginning of new HDU | meta.note;meta.fits.hdu YPIXELSZ | y pixel size | phys.size;instr.pixel ZD_EOS | zenith distance at End of Scan | pos.az.zd ZD_SOS | zenith distance at Start of Scan | pos.az.zd ZP | zero point calibration | arith.zp;phot.calib ZP_ERR | error in zero point | stat.error;arith.zp;phot.calib From norman at astro.gla.ac.uk Tue May 3 09:21:39 2005 From: norman at astro.gla.ac.uk (Norman Gray) Date: Tue, 3 May 2005 17:21:39 +0100 Subject: UCD name documentation In-Reply-To: <20050503164114.gxpb53ye89ygogo4@webmail.sic.rm.cnr.it> References: <1eff2d5b2ed291becf05825cb37fd8e6@astro.gla.ac.uk> <20050503164114.gxpb53ye89ygogo4@webmail.sic.rm.cnr.it> Message-ID: Andrea, On 2005 May 3 , at 15.41, Andrea Preite Martinez wrote: > If you think that the appended list (better, an updated version of it) > could be the base for such a tool, I'll do it (the tool, I mean) Thanks -- that's just the thing I was looking for. Will this appear on the UCD pages at some point? If anyone's interested, this came up on a `osxastro' list (OS X for astronomy applications). The thread is `Tiger's Spotlight & FITS files' at . All the best, Norman -- ---------------------------------------------------------------------- Norman Gray : Physics & Astronomy, Glasgow University, UK http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk From edward.j.shaya.1 at gsfc.nasa.gov Tue May 3 14:09:31 2005 From: edward.j.shaya.1 at gsfc.nasa.gov (Ed Shaya) Date: Tue, 03 May 2005 17:09:31 -0400 Subject: New UCDs for VOEvent please In-Reply-To: <71e0852515f7c6122fe60632c6efb16d@Astro.physik.Uni-Goettingen.DE> References: <32fd4a5efbfd9d3afbbae300411c0379@Astro.physik.Uni-Goettingen.DE> <426FBAC9.2050600@cacr.caltech.edu> <4272824B.7010900@gsfc.nasa.gov> <71e0852515f7c6122fe60632c6efb16d@Astro.physik.Uni-Goettingen.DE> Message-ID: <4277E88B.7030305@gsfc.nasa.gov> Fred, Actually, I've been slaving away at an ontology for several months. It is still quite broad and far from complete. But if you are interested and have the facility to examine OWL, then have a look. I am open to any and all comments.: http://archive.astro.umd.edu/ont/ (an svn archive) Ed Frederic V. "Rick" Hessman wrote: > > On 29 Apr 2005, at 8:51 pm, Ed Shaya wrote: > >> But we can also be keeping another eye on the longer time scale >> where we want to be able to put data in machine understandable terms >> so that applications can do the most possible on our behalf. This >> requires something a bit more sophisticated than just a simple class >> hierarchy of terms. An ontology would be more complete but probably >> not even an order of magnitude (factor 10) more than the UCD is >> now. In fact, given the requests and requirements to augment UCDs, >> with time, the UCD will probably grow to the size of an ontology >> anyway. So, it is probably wise to start doing some thinking in >> terms of the formal OWL standard now. What we do with the ontology >> can vary greatly. >> 1. Use it as a string identifier, exactly as UCDs are. The >> advantage is that one can read the Ontology at that point to get >> more context for the meaning of the term. >> 2. Use it as one more model builder for developing schemas. This >> is like UML but more in tune with knowledge/information structures. >> I think this is what Mathew had in mind. >> 3. Use it to test completeness and consistency of terms. This would >> not be on the fly, but rather as one adds new terms one can see >> whether it is clashing with other terms and Venn diagrams let you >> see something about completeness. This then makes it more >> acceptable for groups to be adding terms into their namespace >> without going to the VO heads or the IAU. >> 4. One can use it as the defining structure of all information being >> exchanged. Sounds daring but in fact several other related science >> fields are preparing to do just that, including space physics. >> 5. One can use it to reason out pathways to converting, pipelining, >> and analysing data. It should be possible to automatically find the >> transformation and queries needed to satisfy an arbitrary stated >> goal or request. Our group at UMD has an NASA/AISRP grant to >> figure out the basics of how this might be done using OWL. > > > Ummm.... maybe my googling didn't go quite as far or I'm missing > something: the "ontology" I found was a "low-level" (no - that sounds > too negative - let's say "very fundamental") means of describing > scientific quantities - nothing particularly "astronomical" about > it. If this is as far as anyone has gotten, then I vote for a > mid-term temporary solution - what I've called "VOThings" - which > someone else can turn into a full astronomical ontology in the > future. Thus, > > - Small, multiple, overlapping, incompatible lists within > different schemata will be an unnecessary pain, so we need a minimal > common-ground list. > > - A formal development of a real astronomical ontology will take > many years and we can't wait that long. > > - We should resist the temptation to make VOThings "complete" > since it won't ever be such and we'd waste time in trying. Maybe > having such a terrible name will be a good thing - let's get it over > quickly knowing that some day somebody else will get it right. > > Rick > > ------------------------------------------------------------------------ > ------------------------ > Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE > Universitaets-Sternwarte Tel. +49-551-39-5052 > Geismarlandstr. 11 Fax +49-551-39-5043 > 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman > ------------------------------------------------------------------------ > ------------------------- > MONET: a MOnitoring NEtwork of Telescopes > http://monet.uni-goettingen.de > ------------------------------------------------------------------------ > ------------------------- > > From Hessman at Astro.physik.Uni-Goettingen.DE Fri May 6 03:17:02 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Fri, 6 May 2005 12:17:02 +0200 Subject: [Voevent-core] Draft v0.6, VOThings & UCD usage In-Reply-To: <011EA67F-8093-408A-A5C5-AF6BC33A70A3@noao.edu> References: <427A7DAB.3010102@cacr.caltech.edu> <011EA67F-8093-408A-A5C5-AF6BC33A70A3@noao.edu> Message-ID: <4cd59db0ee26584cabeaaece611a1fcd@Astro.physik.Uni-Goettingen.DE> > - It seems to me that VOThing is unlikely to be embraced as a name. > Suggestions? Perhaps this facility should exist underneath VOEvent > itself in some fashion. Other VO projects needing access would then > simply reference us in return. Remember: I purposefully used this terrible name to emphasize the need for a VO-wide solution. How about "VOConcept"? It seems that the UCD community will also have to address the usefuless of the present UCD usage: one requires a separate parser to disentagle what "em.X-ray;phot.count;obs.image" is supposed to mean, whereas parsing something like em.X-rayphot.countobs.image would fall out of the normal processing of the XML document with no real additional effort. This is why I've been playing with UCDType and VOThingType in the experimental VOEvent schema (http://monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/ SchemaTableOfContents). This is a good chance to force our VO colleagues to think a bit more about how different VO projects can be made more compatible (at least) and more useful (we hope) in the near future. I'd like to see VOEvent's and turn into something like ("concept" <--> "VOConcept" = "VOThing") em.opt process.burst phot.flux em.opt.R supernova.Type_Ia NGC 1234 galaxies The whole point of XML, after all, is to do as much as possible in XML, othewise one can stick to old ASCII formats. > - There appears to be no purpose for the "type" attribute of the > VOEvent element. This functionality is encapsulated under the > citations. Comments on section 3.2 would be quite welcome. I think it's a bit tricky that the ultimate purpose of the document is hidden in the cite attributes in a lower-level element. Yes, we can agree what everything is supposed to mean, but you certainly can't call it elegant. And no, I don't really have a better suggestion..... > - Timestamp? I vote for subelement of Curation, not attribute of > VOEvent. Unless I get some immediate support for my suggestion, I assume we keep the original syntax. > - There is no error attribute for a VOTable Param, so there should be > none for VOEvent. I FIRMLY disagree with this. With VOTable, the syntax is designed to describe rows and columns in a table and errors are often kept in separate entries. VOEvent needs to be able to describe a measurement, and I've always told my students that a measurement without an error and some units isn't a measurement. It's artificially cumbersome to force people to use s in order to attach an error by adding another element which is identical with the partner element except for the ".error" appendix on the ucd. > - I think all elements of a packet should be optional. A completely > empty VOEvent should be acceptable, for instance, for testing. It is > not our job to try to limit usage only to sensible packets. The first > thing any subscribing client will do is to perform a reality check on > the semantics of the message *from the point of view of the needs of > the client itself*. If a client driving a robotic telescope receives > a discovery packet with no WhereWhen, it will be a simple matter to > reject it. It would, on the other hand, be a hellaciously complicated > job to try to construct a protocol/language in which no nonsense could > be spoken. (See the Sunday morning talk shows for examples.) I started to say that a packet without a is anonymous, but that's not entirely true: if the packet HAS to have a unique ivo: ID, then there's at least somebody who knows where the message came from. Is this enough? What if your system gets a message with the id "ivo://other/message12345678"? Do you assume that somebody within the IVOA was wise in letting somebody who knows what s/he's doing insert a nearly blank message claiming to have found a optical transient? > - We are relying on STC and RTML (and other stuff like UCD). How > should we mandate (or not) what versions of each standard are > acceptable for a packet conforming to VOEvent vM.n? Should we > constrain the usage to the latest stable version of each dependency at > the time of our own releases? Surely the VO must have run into this > before? When STC and RTML is inserted in the schema, one is forced to specify a particular version. As the schema is updated, the appended schemata can also be updated. A performance issue is implicit here: if extremely fast processing times are required, either your system will have to forget about formal schema-based parsing or probably should force the parser to use local copies of the schemata (e.g. updated regularly from the IVOA). > - I think How should continue to live at the top level (not underneath > Curation). It should, however, typically only correspond to a pointer > to an RMTL document or earlier VOEvent packet. (This is the > equivalent of the familiar "N more" syntax for commanding additional > exposures under a variety of data acquisition systems.) In many > cases, How will be omitted entirely. Hear! Hear! If somethings comes from Raptor or a similarly trustworthy source, for instance, we won't need to have the grimy details in the message. Good practice should dictate, however, that there really should be a useful link (a , for example) which permits one to take a look if needed. Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From pfo at star.le.ac.uk Fri May 6 03:37:07 2005 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Fri, 6 May 2005 11:37:07 +0100 (BST) Subject: [Voevent-core] Draft v0.6, VOThings & UCD usage In-Reply-To: <4cd59db0ee26584cabeaaece611a1fcd@Astro.physik.Uni-Goettingen.DE> Message-ID: Hi Frederick, On Fri, 6 May 2005, Frederic V. "Rick" Hessman wrote: > > - It seems to me that VOThing is unlikely to be embraced as a name. > > Suggestions? Perhaps this facility should exist underneath VOEvent > > itself in some fashion. Other VO projects needing access would then > > simply reference us in return. > > Remember: I purposefully used this terrible name to emphasize the need > for a VO-wide solution. How about "VOConcept"? > > It seems that the UCD community will also have to address the usefuless > of the present UCD usage: one requires a separate parser to disentagle > what "em.X-ray;phot.count;obs.image" is supposed to mean, whereas > parsing something like > > em.X-rayphot.countobs.image ucd> > > would fall out of the normal processing of the XML document with no > real additional effort. Possibly, but that makes UCDs tied to a particular representation (XML), which I don't believe should be the way to go. If UCDs are to be used widely, they should remain as independent of the "way to write them" as possible. Some people (include me) would like to use UCDs in a non XML context, and build our own tools. Furthermore, which usages do you have in mind where a piece of software would be required to "understand" the meaning of a UCD? (other than just compare with other UCDs, either completely or partially) Cheers, Patricio --- Patricio F. Ortiz pfo at star.le.ac.uk Department of Physics & Astronomy Phone: +44 (0)116 252 2015 University of Leicester Leicester, LE1 7RH, UK From Hessman at Astro.physik.Uni-Goettingen.DE Fri May 6 03:59:11 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Fri, 6 May 2005 12:59:11 +0200 Subject: [Voevent-core] Draft v0.6, VOThings & UCD usage In-Reply-To: References: Message-ID: On 6 May 2005, at 12:37 pm, Patricio F. Ortiz wrote: >>> - It seems to me that VOThing is unlikely to be embraced as a name. >>> Suggestions? Perhaps this facility should exist underneath VOEvent >>> itself in some fashion. Other VO projects needing access would then >>> simply reference us in return. >> >> Remember: I purposefully used this terrible name to emphasize the need >> for a VO-wide solution. How about "VOConcept"? >> >> It seems that the UCD community will also have to address the >> usefuless >> of the present UCD usage: one requires a separate parser to disentagle >> what "em.X-ray;phot.count;obs.image" is supposed to mean, whereas >> parsing something like >> >> em.X-rayphot.countobs.image> ucd> >> >> would fall out of the normal processing of the XML document with no >> real additional effort. > > Possibly, but that makes UCDs tied to a particular representation > (XML), > which I don't believe should be the way to go. If UCDs are to be used > widely, they should remain as independent of the "way to write them" > as possible. Some people (include me) would like to use UCDs in a non > XML context, and build our own tools. Furthermore, which usages do you > have in mind where a piece of software would be required to > "understand" > the meaning of a UCD? (other than just compare with other UCDs, either > completely or partially) I don't see any problem: in produing the UCDType (not to be confused with VOTable's "ucdType", which just says what a ucd should look like lexographically), I simply took the official list and put it in a schema enumeration so that it could be checked syntactically. This certainly doesn't preclude someone else using the list for totally different purposes. The whole point of UCD's was, at least as I understood it, that one could use an official label for a concept which a computer could then process. The UCD tags aren't for people - they're for computers. By making the UCD list available within a schema, we can make the list simpler for computers to process. Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From pfo at star.le.ac.uk Fri May 6 04:13:46 2005 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Fri, 6 May 2005 12:13:46 +0100 (BST) Subject: [Voevent-core] Draft v0.6, VOThings & UCD usage In-Reply-To: Message-ID: On Fri, 6 May 2005, Frederic V.Rick Hessman wrote: > On 6 May 2005, at 12:37 pm, Patricio F. Ortiz wrote: > > >>> - It seems to me that VOThing is unlikely to be embraced as a name. > >>> Suggestions? Perhaps this facility should exist underneath VOEvent > >>> itself in some fashion. Other VO projects needing access would then > >>> simply reference us in return. > >> > >> Remember: I purposefully used this terrible name to emphasize the need > >> for a VO-wide solution. How about "VOConcept"? > >> > >> It seems that the UCD community will also have to address the > >> usefuless > >> of the present UCD usage: one requires a separate parser to disentagle > >> what "em.X-ray;phot.count;obs.image" is supposed to mean, whereas > >> parsing something like > >> > >> em.X-rayphot.countobs.image >> ucd> > >> > >> would fall out of the normal processing of the XML document with no > >> real additional effort. > > > > Possibly, but that makes UCDs tied to a particular representation > > (XML), > > which I don't believe should be the way to go. If UCDs are to be used > > widely, they should remain as independent of the "way to write them" > > as possible. Some people (include me) would like to use UCDs in a non > > XML context, and build our own tools. Furthermore, which usages do you > > have in mind where a piece of software would be required to > > "understand" > > the meaning of a UCD? (other than just compare with other UCDs, either > > completely or partially) > > I don't see any problem: in produing the UCDType (not to be confused > with VOTable's "ucdType", which just says what a ucd should look like > lexographically), I simply took the official list and put it in a > schema enumeration so that it could be checked syntactically. This > certainly doesn't preclude someone else using the list for totally > different purposes. Perhaps, I can see it from your point of view. That means that anyone getting an XML document adopting that convention and wanting to use "total" UCDs needs to append these elements into a new element which will look like the original. Non-XML representations will remain as originally proposed, right? > The whole point of UCD's was, at least as I understood it, that one > could use an official label for a concept which a computer could then > process. The UCD tags aren't for people - they're for computers. By > making the UCD list available within a schema, we can make the list > simpler for computers to process. In an ideal world, yes, UCDs should be for computers, but in a few cases the information for a given column is so "cryptic" that a human would get more information from the UCD than from an explanation/column-name combination. Besides, I can think of cases in which users are faced with a choice between a number of "things" (to use that term :-) :-) in which the UCD will play an important role to understand what they are dealing with. Searches launched by users will not always return "precise answers", (eg, a registry query) so one of the discriminating elements may well be the UCD. > Rick Cheers, Patricio --- Patricio F. Ortiz pfo at star.le.ac.uk Department of Physics & Astronomy Phone: +44 (0)116 252 2015 University of Leicester Leicester, LE1 7RH, UK From Hessman at Astro.physik.Uni-Goettingen.DE Fri May 6 08:06:54 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Fri, 6 May 2005 17:06:54 +0200 Subject: [Voevent-core] Draft v0.6, VOThings & UCD usage In-Reply-To: References: Message-ID: <09edf63bac6eaf3722da225c046d3a4f@Astro.physik.Uni-Goettingen.DE> >>>>> - It seems to me that VOThing is unlikely to be embraced as a name. >>>>> Suggestions? Perhaps this facility should exist underneath VOEvent >>>>> itself in some fashion. Other VO projects needing access would >>>>> then >>>>> simply reference us in return. >>>> >>>> Remember: I purposefully used this terrible name to emphasize the >>>> need >>>> for a VO-wide solution. How about "VOConcept"? >>>> >>>> It seems that the UCD community will also have to address the >>>> usefuless >>>> of the present UCD usage: one requires a separate parser to >>>> disentagle >>>> what "em.X-ray;phot.count;obs.image" is supposed to mean, whereas >>>> parsing something like >>>> >>>> em.X-rayphot.countobs.image>>> ucd> >>>> >>>> would fall out of the normal processing of the XML document with no >>>> real additional effort. >>> >>> Possibly, but that makes UCDs tied to a particular representation >>> (XML), >>> which I don't believe should be the way to go. If UCDs are to be used >>> widely, they should remain as independent of the "way to write them" >>> as possible. Some people (include me) would like to use UCDs in a non >>> XML context, and build our own tools. Furthermore, which usages do >>> you >>> have in mind where a piece of software would be required to >>> "understand" >>> the meaning of a UCD? (other than just compare with other UCDs, >>> either >>> completely or partially) >> >> I don't see any problem: in produing the UCDType (not to be confused >> with VOTable's "ucdType", which just says what a ucd should look like >> lexographically), I simply took the official list and put it in a >> schema enumeration so that it could be checked syntactically. This >> certainly doesn't preclude someone else using the list for totally >> different purposes. > > Perhaps, I can see it from your point of view. That means that anyone > getting an XML document adopting that convention and wanting to use > "total" UCDs needs to append these elements into a new element which > will look like the original. I'm not sure what you mean by "total" - "original"? UCD information which gets passed via its XML representation can be turned into any format you want: e.g. em.opt.Rphot.flux... is the same as in a VOTable, and we hope the human at the end only sees "R-band optical flux of 1.234e-4 W/m^2" (or something similarly intelligent) and neither of the above computer representations! > Non-XML representations will remain as originally proposed, right? My point is that UCDs will have a life of their own as an official representation of astronomical quantities and concepts - to be used for whatever purposes people find them useful for - but that their use as a means of communication between computers and between people and computers will be much simpler if there is an official XML representation. The current model of simple string concatenation is a cumbersome one for computers given that everything else is cast in XML. Thus, the creation of an official UCD standard list should be accompanied (not replaced!) by an attempt to make the list XML-enabled. My suggestion of using concatenated elements instead of concatenated UCD content is just one obivous way to achieve this functionality. >> The whole point of UCD's was, at least as I understood it, that one >> could use an official label for a concept which a computer could then >> process. The UCD tags aren't for people - they're for computers. By >> making the UCD list available within a schema, we can make the list >> simpler for computers to process. > > In an ideal world, yes, UCDs should be for computers, but in a few > cases > the information for a given column is so "cryptic" that a human would > get > more information from the UCD than from an explanation/column-name > combination. Besides, I can think of cases in which users are faced > with > a choice between a number of "things" (to use that term :-) :-) in > which > the UCD will play an important role to understand what they are dealing > with. Searches launched by users will not always return "precise > answers", (eg, a registry query) so one of the discriminating elements > may > well be the UCD. Absolutely - the UCD can be the syntactical glue by which the human users are finally able to communicate with the external VO world. All the more reasons to invest (1) in a more useful parallel version of the UCD list (XML) and (2) in extensions to the now still VOTable-ish UCD list (a la but not necessarily exactly like VOThing). Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From jcm at head.cfa.harvard.edu Sun May 8 23:04:47 2005 From: jcm at head.cfa.harvard.edu (Jonathan McDowell) Date: Mon, 9 May 2005 02:04:47 -0400 (EDT) Subject: New UCD list Message-ID: <200505090604.j4964lFb012041@urania.cfa.harvard.edu> Dear Andrea, I've been looking at the new UCD list. I have a question, some comments and a concern. question: I assume that the suggestion I made in Aug 2004 for "phot.flux.beam" should now be handled by "phot.flux;instr.beam" using the new "instr.beam" UCD? comment: I applaud the simplification of phot.color. How are you handling this in the Vizier tables with more than one color? Adding secondary pairs of "em.*" UCDs? comment: The UCD desc for 'phot.count' still includes the comment "count (/s)" even though on Oct 19 you agreed on the feedback form that we drop the "/s". comment: I second Alberto's suggestions on homogenization of things like resolution. comment: However, On attempting to map the WCS keywords with things like arith.1_1, I think this is trying to take UCDs beyond where they should go (something I've been accused of myself!). That's what a UTYPE is for, to map it to a data model. All the components of cdmatrix are the same kind of thing and should have the same ucd. concern: On the comments page I also asked in August-Sept. 2004 for feedback on the following proposed UCDs: em.veloc.radio meta.curation phys.energy-density src.net I'm a bit disappointed that many months later a new list has emerged without none of these being addressed, even with a "well, I don't think this is sensible for a UCD". These were proposed not just for fun, but as things needed for the spectral data model document. I also still think that it would be a good idea if new UCDs were circulated for comment to the UCD WG "board" before the web page was updated, the process still seems a bit opaque and over-centralized. (by the way, the automated emails we get with "A suggestion has been made for a new UCD" would I think be much more useful if the text of the suggestion was included, removing one step in the process, since I have the impression few WG members have been responding to them). Best wishes, Jonathan McDowell From norman at astro.gla.ac.uk Mon May 9 06:45:02 2005 From: norman at astro.gla.ac.uk (Norman Gray) Date: Mon, 9 May 2005 14:45:02 +0100 Subject: New UCD list In-Reply-To: <200505090604.j4964lFb012041@urania.cfa.harvard.edu> References: <200505090604.j4964lFb012041@urania.cfa.harvard.edu> Message-ID: Greetings, On 2005 May 9 , at 07.04, Jonathan McDowell wrote: > (by the way, the automated emails we get with "A suggestion has been > made for > a new UCD" would I think be much more useful if the text of the > suggestion > was included, removing one step in the process, since I have the > impression > few WG members have been responding to them). Who is the `we', here? Is this the CDS panel for discussing new UCDs, or the list of folk on the WG, which I take to be approximately coextensive with the list of authors of the UCD1+ proposal? I understood I was still on the WG, though I don't recall any such automated emails. Norman -- ---------------------------------------------------------------------- Norman Gray : Physics & Astronomy, Glasgow University, UK http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk From andrea.preitemartinez at rm.iasf.cnr.it Mon May 9 08:06:49 2005 From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez) Date: Mon, 9 May 2005 17:06:49 +0200 Subject: New UCD list Message-ID: <20050509170649.srzz6v0z3gkgossw@webmail.sic.rm.cnr.it> Dear Jonathan, > question: I assume that the suggestion I made in Aug 2004 for "phot.flux.beam" > should now be handled by "phot.flux;instr.beam" using the new "instr.beam" > UCD? You're right, that was the idea. > comment: I applaud the simplification of phot.color. How are you handling > this in the Vizier tables with more than one color? Adding secondary pairs of > "em.*" UCDs? Yes, if U-B and V-K are present, we would simply have phot.color;em.opt.U;em.opt.B phot.color;em.opt.V;em.IR.K > comment: The UCD desc for 'phot.count' still includes the comment "count (/s)" > even though on Oct 19 you agreed on the feedback form that we drop the "/s". Thanks, this will be fixed in version 1.01 of the list. > comment: I second Alberto's suggestions on homogenization of things like > resolution. Yes, I agree. Anyone opposing the following changes ? instr.angRes -> pos.resolution (angular resolution) instr.spect.resolution -> spect.resolution (spectral resolution) > comment: However, On attempting to map the WCS keywords with things like > arith.1_1, I think this is trying to take UCDs beyond where they should > go (something I've been accused of myself!). That's what a UTYPE is for, > to map it to a data model. All the components of cdmatrix are the same > kind of thing and should have the same ucd. I also agree with you. > concern: > > On the comments page I also asked in August-Sept. 2004 for feedback on the > following proposed UCDs: > em.veloc.radio There are several things at stake with this one. You can now describe velocities with the following combinations: For radial velocities derived from a spectrum: spect.veloc -- which can be followed by a word em.* : spect.veloc;em.opt or spect.veloc;em.radio or spect.veloc;em.line.HI ... For other velocities : src.veloc (by the way, the definition is wrong in the list! It should not read "radial velocity", but simply "Velocity"). You first suggested em.veloc.radio to account for the 2 conventions to derive velocities from spectra (optical and radio conventions). If nobody ever applies the optical convention to a radio spectrum (or vice versa), then we can live with spect.veloc;em.opt and spect.veloc;em.radio What do you think? > meta.curation What about having a few specific words to describe the elements of VOResource metadata: meta.entity (or meta.identity and meta.organization) meta.version ... > phys.energy-density Yes, but spelled phys.energyDensity ? > src.net You suggested three words to distinguish total source flux, background flux, and net source flux. I don't feel comfortable with src.net, because net values should be the default... The background could be described by a qualifier, e.g. renaming instr.background to stat.background. "Total" is too general a word. Can you suggest a more specific word to describe source+background? Would this be the same as aperture photometry in the optical (i.e. total flux measured within some radius). > I also still > think that it would be a good idea if new UCDs were circulated for > comment to the UCD WG "board" before the web page was updated, the > process still seems a bit opaque and over-centralized. I think the role of the Kyoto session will also be to formalize the existence of the board. Emails like yours contribute to make the process less opaque! > (by the way, the automated emails we get with "A suggestion has been made for > a new UCD" would I think be much more useful if the text of the suggestion > was included, removing one step in the process, since I have the impression > few WG members have been responding to them). Okay, it can be done! Andrea. ============================================================================== Andrea Preite Martinez andrea at rm.iasf.cnr.it Istituto di Astrofisica Spaziale Tel.:+39.06.4993.4641 Area di Ricerca di Tor Vergata Fax.:+39.06.2066.0188 Via del Fosso del Cavaliere 100 Cell:+39.339.3817355 00133 Roma ============================================================================== From arots at head.cfa.harvard.edu Mon May 9 08:38:24 2005 From: arots at head.cfa.harvard.edu (Arnold Rots) Date: Mon, 9 May 2005 11:38:24 -0400 (EDT) Subject: New UCD list In-Reply-To: <20050509170649.srzz6v0z3gkgossw@webmail.sic.rm.cnr.it> Message-ID: <200505091538.j49FcOfq024961@xebec.cfa.harvard.edu> Andrea Preite Martinez wrote: > ... > You first suggested em.veloc.radio to account for the 2 conventions to > derive velocities from spectra (optical and radio conventions). If > nobody > ever applies the optical convention to a radio spectrum (or vice versa), > then we can live with spect.veloc;em.opt and spect.veloc;em.radio > What do you think? > O yes! The optical definition needs to be (and is) used for plenty of radio observations. Do you distinguish between LSR, geocenter, barycenter, topocenter, Galactic center (to name the most popular ones)? > ... -------------------------------------------------------------------------- Arnold H. Rots Chandra X-ray Science Center Smithsonian Astrophysical Observatory tel: +1 617 496 7701 60 Garden Street, MS 67 fax: +1 617 495 7356 Cambridge, MA 02138 arots at head.cfa.harvard.edu USA http://hea-www.harvard.edu/~arots/ -------------------------------------------------------------------------- From debray at obs-besancon.fr Mon May 9 11:40:48 2005 From: debray at obs-besancon.fr (Bernard Debray) Date: Mon, 09 May 2005 20:40:48 +0200 Subject: UCDs and optical and near-infrared bandpasses References: <20050502071545.o2qry3nmgtcgok8s@webmail.sic.rm.cnr.it> Message-ID: <427FAEB0.1040507@obs-besancon.fr> Dear UCD list members, I apologize if the subject of the remarks below has already been addressed or this turns out eventually to be outside the scope of the UCD field. This is both a remark on the UCD electromagnetic spectrum scheme and a question about the use of UCDs. I have browsed the archive of the UCD mailing list and found only one message, by Patricio Ortiz, already a long time ago (October 2003, http://www.ivoa.net/forum/ucd/0310/0067.htm) that fits this topic and looked quite sound to me. One of the claimed aims of UCDs is interoperability. Therefore, they should serve, for instance, the purpose of comparing magnitudes from different catalogues in given filters. Therefore, one should be able to identify unambiguously through which filter, photometric system, ... a magnitude is supplied in a catalogue or by a simulation tool. In the division of the electromagnetic spectrum in the UCD document, optical and near-infrared subparts of the spectrum where given names which are the ones of filters in the Johnson, ... photometric system, whereas they designate contiguous portions of the electromagnetic spectrum. While Johnson filters do fit in the subparts so defined, this is not always the case for filters from other photometric systems. For instance, the g filter of the SDSS photometric system has an effective wavelength of 482.5 nm but the flux in this band encompasses widely both the em.opt.B and em.opt.V domains. On the other hand, there seems to be,as far as I can see, no UCD which refers to the specification of a photometric system which could complement the UCD for the description of the electromagnetic spectrum subpart. Alternatively, the UCDs for specific filters such as those of SDSS' system, which could become more widespread that Johnson's in the future, could be handed over to particular namespaces. But it then still seems to me that, in order to release ambiguity in the meaning of optical and near-infrared parts of the spectrum, the corresponding UCDs should be named slightly differently, not simply U, B, V, ... Finally, if the desired achievement of identifications of data columns in the purpose of comparaison is beyond the scope of UCDs, should the cross-comparaison process be handed over to VO tools at more sophisticated levels ? Thanks in advance for your remarks and comments. Best regards, Bernard Debray Bernard Debray bernard.debray at obs-besancon.fr Observatoire de Besan?on http://www.obs-besancon.fr/ BP 1615 25010 Besan?on Cedex France Andrea Preite Martinez wrote: >Dear member of the UCD_wg, > >since last Friday (20050429) an updated list of UCD words is available at: > >http://vizier.u-strasbg.fr/UCD/ucd1p-words.txt > >at the UCD page: > >http://vizier.u-strasbg.fr/UCD/ > >The new list of words has been edited according to the very valuable >comments coming from the community and also thanks to the (almost!) every >day use of them made by Sebastien and myself. > >The most important differences with the previous version (20040823) concern > >- distances and sizes (linear/angular) >- the introduction of a rectangular/cartesian reference frame >- the phot.color section, much simplified >- spelling, abbreviations, syntax ... > > >At the UCD page you can also find un updated version of the UCD_tree >browser(s) >and a new tool, the ucd_builder: > >http://vizier.u-strasbg.fr/UCD/cgi-bin/descr2ucd > >that uses a description in "natural" language to find the relevant >ucd_words, and then tries to build a valid ucd out of them. > >In these two weeks before Kyoto please explore the list, use the tools and >send back comments. >A more "formal" comment page is available to suggest changes in the list of >words at: >http://vizier.u-strasbg.fr/UCD/cgi-bin/comment/ucdComments > >Have fun. >Andrea > > From pfo at star.le.ac.uk Mon May 9 13:29:14 2005 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Mon, 9 May 2005 21:29:14 +0100 (BST) Subject: UCDs and optical and near-infrared bandpasses In-Reply-To: <427FAEB0.1040507@obs-besancon.fr> Message-ID: Hi Andrea, Bernard, et al, I've been sitting on my hands to see if there was any reaction to the way UCDs are heading, but as I was mentioned in the last post, I feel I can free my hands and re-phrase my concerns again. I fully agree with Bernard's position, which something isn't quite right with the way UCD1+ are heading, particularly in the photometry section, which comprises and will comprise the bulk of the data in astronomy. We should ask ourselves why we want to attach a UCD to a column's metadata, and how we intend to use it. To the first question, the initial answer (pre-historic UCDs :-) was that we wanted to be able to recognize the content of any given column in as accurate a way as possible in order to compare it with others (we had datamining in mind); we wished not to mix apples, pears, oranges or lemmons, so, there would be different UCDs for apples, lemmons and oranges (to follow Roy's way of exemplifying things) :-) Now, we have reached a point in which we're lucky to have one ucd for apples and pears and one for lemmons and oranges (citrics). Perhaps we only have one UCD for fruits.which.grow.on.trees.of.more.than.two.metres.high :-) Which leads us to the second question... How do we intend to use them? Do we want to find "things" using ucds? Sure, 1- I(*) want to find all catalogues containing observations with the gunn g filter (enough of fruits, we're astronomers :-). Perhaps I'd like to compare observations done by different observers? (*) replace I by "user" or "users". 2- Another possibility is that I want to find observations in the optical blue section of the em-spectrum? Fine, I may be just interested in discovering resources rather than comparing on a very accurate level. 3- I want to discover which objects have been observed in the radio regime of the CO emission at 3.whatever mm [go back to normal use of 'I'] As far as I can see, ucd1+ allows us to answer [2] accurately and possibly completely, while [1] and [3] will give us a lot of answers with a low S/N, ie, correct answers combined with irrelevant information (to the person questioning). One of the initial ideas of UCDs (mine at least) was to tag columns accurately (including filter/photometric systems), but having "virtual UCDs", ie, UCDs which will be accessible to those querying, but never (or rarely) attached to columns. Translation tables would take care of interpreting that if I asked for "blue magnitude" I would get Johnsons' B, Stroemgrem, gunn, washington, HST, Sloan, etc, etc. However accurate querying was possible. The problem of UCD1+ is that if I want HST Blue observations I have to weed through all the other systems which were put in the same box!! Somehow I feel as if I went to a supermarket to buy AAA alkaline batteries and I'm told "Ah! batteries, they are all in this box (AAA, AA, C, D, N, etc., alkaline, zn, li, new-tech, etc.), here, help yourself" I don't think I'll go back to buy batteries there again! OK, so what can be done? I'm not just complaining here! :-) UCD1+ have already the broad classification, *I* think we need to add the fine structure, so no information is lost and needs to be re-discovered time after time For instance, S|em.opt.B should be left for a magnitude for which we have no idea how it was measured (old catalogues), while a Johnson's B should be something like S|em.opt.B:phot.jhn.B Yes, the ucd tree will grow again (or we'll have to handle this with UTYPE or some other meta-data element), but the example just given gives an accurate description of the quantity, yet can be used in fuzzy searches. Alternatively, we could have phot.jhn.B by itself as the UCD, but have something like S|em.opt.B -> (S|em.opt.B, phot.jhn.B, phot.HST.B, ....... ) That means that in the context of a query, whenever a tool finds the left term it should look for columns which contain a UCD listed in the right hand side. If no list is associated with a "virtual UCD", exact matches should be performed (which should not prevent us from searching for 'phot.HST' regarding of the filter observed! I've implemented tools like this, that's why I'm voicing this proposition. To finish, I just took a quick look at the 'em.line' section... well, absorption and emission lines exist across the spectrum: Ly-alpha, CIV (QSOs), molecular lines, (CO, H20) in Radio, FeXIV in X, etc. By not leaving room for accurate description with UCDs we are making UCDs less useful as accurate descriptors and discovery tools. I feel more threatened by a lack of accuracy in the description of a column than for a largish set of terms (which only reflects our trade). Cheers, Patricio On Mon, 9 May 2005, Bernard Debray wrote: > Dear UCD list members, > > I apologize if the subject of the remarks below has already been > addressed or this turns out eventually to be outside the scope of the > UCD field. This is both a remark on the UCD electromagnetic spectrum > scheme and a question about the use of UCDs. > > I have browsed the archive of the UCD mailing list and found only one > message, by Patricio Ortiz, already a long time ago (October 2003, > http://www.ivoa.net/forum/ucd/0310/0067.htm) that fits this topic and > looked quite sound to me. > > One of the claimed aims of UCDs is interoperability. Therefore, they > should serve, for instance, the purpose of comparing magnitudes from > different catalogues in given filters. Therefore, one should be able to > identify unambiguously through which filter, photometric system, ... a > magnitude is supplied in a catalogue or by a simulation tool. > > In the division of the electromagnetic spectrum in the UCD document, > optical and near-infrared subparts of the spectrum where given names > which are the ones of filters in the Johnson, ... photometric system, > whereas they designate contiguous portions of the electromagnetic spectrum. > > While Johnson filters do fit in the subparts so defined, this is not > always the case for filters from other photometric systems. For > instance, the g filter of the SDSS photometric system has an effective > wavelength of 482.5 nm but the flux in this band encompasses widely both > the em.opt.B and em.opt.V domains. > On the other hand, there seems to be,as far as I can see, no UCD which > refers to the specification of a photometric system which could > complement the UCD for the description of the electromagnetic spectrum > subpart. > > Alternatively, the UCDs for specific filters such as those of SDSS' > system, which could become more widespread that Johnson's in the future, > could be handed over to particular namespaces. But it then still seems > to me that, in order to release ambiguity in the meaning of optical and > near-infrared parts of the spectrum, the corresponding UCDs should be > named slightly differently, not simply U, B, V, ... > > Finally, if the desired achievement of identifications of data columns > in the purpose of comparaison is beyond the scope of UCDs, should the > cross-comparaison process be handed over to VO tools at more > sophisticated levels ? > > Thanks in advance for your remarks and comments. > > Best regards, > Bernard Debray > > Bernard Debray bernard.debray at obs-besancon.fr > Observatoire de Besan?on http://www.obs-besancon.fr/ > BP 1615 > 25010 Besan?on Cedex > France > > > Andrea Preite Martinez wrote: > > >Dear member of the UCD_wg, > > > >since last Friday (20050429) an updated list of UCD words is available at: > > > >http://vizier.u-strasbg.fr/UCD/ucd1p-words.txt > > > >at the UCD page: > > > >http://vizier.u-strasbg.fr/UCD/ > > > >The new list of words has been edited according to the very valuable > >comments coming from the community and also thanks to the (almost!) every > >day use of them made by Sebastien and myself. > > > >The most important differences with the previous version (20040823) concern > > > >- distances and sizes (linear/angular) > >- the introduction of a rectangular/cartesian reference frame > >- the phot.color section, much simplified > >- spelling, abbreviations, syntax ... > > > > > >At the UCD page you can also find un updated version of the UCD_tree > >browser(s) > >and a new tool, the ucd_builder: > > > >http://vizier.u-strasbg.fr/UCD/cgi-bin/descr2ucd > > > >that uses a description in "natural" language to find the relevant > >ucd_words, and then tries to build a valid ucd out of them. > > > >In these two weeks before Kyoto please explore the list, use the tools and > >send back comments. > >A more "formal" comment page is available to suggest changes in the list of > >words at: > >http://vizier.u-strasbg.fr/UCD/cgi-bin/comment/ucdComments > > > >Have fun. > >Andrea > > > > > > --- Patricio F. Ortiz pfo at star.le.ac.uk Department of Physics & Astronomy Phone: +44 (0)116 252 2015 University of Leicester Leicester, LE1 7RH, UK From francois at vizir.u-strasbg.fr Tue May 10 00:52:39 2005 From: francois at vizir.u-strasbg.fr (Francois Ochsenbein) Date: Tue, 10 May 2005 09:52:39 +0200 Subject: No subject Message-ID: <200505100752.j4A7qdE20199@vizir.u-strasbg.fr> Hi Patricio, et al., This question of accurate/inaccurate description was discussed many times --- and one of the results was the definition of 2 different entities : -- the UCDs which have the role of broad classification -- the "utype" was introduced to fulfil the role of the accurate description -- the "utype" being in principle connected to a data model which gives the necessary level of detail. In the photometric domain, each of the two entities has its role: -- from a ucd: 2 quantities showing the same UCD can be compared at least in a statistical way; -- from a utype: the accurate specification of each filter must be accessible; quantities can then be combined. In practice however the required level of details is frequently not fully known. There is exactly the same problem in the astrometric domain: while UCDs can be used to define the RA and Dec, an accurate definition of these values requires a lot of extra parameters -- have a look at Arnold's Space-Time model and be sure you have specified everything if you want to be accurate... In many practical cases -- e.g. for statistical cross-matching -- a full description is not required, and then the UCDs have their place. --francois ================================================================================ Francois Ochsenbein ------ Observatoire Astronomique de Strasbourg 11, rue de l'Universite F-67000 STRASBOURG Phone: +33-(0)390 24 24 29 Email: francois at astro.u-strasbg.fr (France) Fax: +33-(0)390 24 24 17 ================================================================================ From jcm at head.cfa.harvard.edu Tue May 10 05:06:07 2005 From: jcm at head.cfa.harvard.edu (Jonathan McDowell) Date: Tue, 10 May 2005 08:06:07 -0400 (EDT) Subject: How precise should UCDs be? Message-ID: <200505101206.j4AC67oh015174@urania.cfa.harvard.edu> Francois wrote: > This question of accurate/inaccurate description was discussed > many times --- and one of the results was the definition of 2 > different entities : > -- the UCDs which have the role of broad classification > -- the "utype" was introduced to fulfil the role of the accurate > description -- the "utype" being in principle connected to a > data model which gives the necessary level of detail. My own thoughts on the relation between UCD and utype/DM have evolved a little (although it comes to essentially the same answer as Francois). I believe that the UCD should have a precise and accurate definition, but that when you need metadata, or parameters, i.e. you need to refer to other UCDs, the utype/DM is needed. It's not a question of level of detail or "accurate", it's a question of "complete" - do you need more than one number of value to describe the idea? Thus, flux.photDens.sb and flux.photDens;instr.beam are different physical concepts - subtly different, and we are going to a high level of detail, but it's necessary to do so. But RA2000 and RA1950 are the same basic concept differing only by a parameter. The concept 'RA' and the concept 'equinox' are the two different concepts here: pos.eq.ra (value = 12:26:03.4) and time.equinox (value = 2000.0) and these are related to each other in the context of a coordinate frame (e.g. STC) data model. RA1950 and RA2000 are really the same physical concept simply with different metadata. pos.eq.ra is PRECISELY defined, it's just not COMPLETELY defined without tying it to the STC metadata. In contrast, you can't really say that about "surface brightness" and "flux density per beam", there's no associated metadata to distinguish them. (I guess you could use instr.scale or instr.pixel and tie it to the spatially variable beam size in the second case but I think implicitly using an algorithm to connect two concepts is cheating.) Of course for pragmatic reasons we do break this paradigm for the "phot.*;em.*" UCDs where the "em.IR" is really metadata for the "phot.*" concept. But in general I think this is a good rule of thumb for deciding whether you need a new UCD, or whether you need to relate two different UCDs via a data model. > while UCDs can be used to define the RA and Dec, an accurate > definition of these values requires a lot of extra parameters > -- have a look at Arnold's Space-Time model and be sure you > have specified everything if you want to be accurate... > In many practical cases -- e.g. for statistical cross-matching -- > a full description is not required, and then the UCDs have their > place. The key phrase here is "requires a lot of extra parameters". In some other practical cases, a full description *is* required: so you need the parameters and a data model to relate them to each other. But if the data model is very generic you still need the UCDs to describe precisely what the individual parameters are. This is of course fuzzy, since sometimes - as in parts of STC - the utype implies what the UCD must be. But sometimes the utype describes only the precise relationship between two concepts, and the UCDs describe the precise identity of the concepts - both precise, but doing different jobs. Thus you might use utypes to link a velocity and its standard of rest, but you still need to use UCDs to explain that this is the escape velocity from the star (src.veloc.escape) and not the expansion velocity of the wind (src.veloc.expansion) that you're talking about. If you look at the src.veloc tree I see three different kinds of UCD: Group 1 - different kinds of velocity src.veloc src.veloc.ang (src.veloc means radial velocity, we're missing a way to say "(norm of) 3D space velocity", I suggest src.veloc.space or src.veloc.total) Group 2 - the velocity of what? (distinguishing different physics concepts): src.veloc.dispersion src.veloc.escape src.veloc.expansion src.veloc.microTurb src.veloc.pulsat src.veloc.rotat Group 3 - shortcuts for giving parameter values of the STC frames: src.veloc.cmb src.veloc.lg src.veloc.lsr Do other people see the same distinction I'm seeing here? I suggest that instead of Group 3 we should have pos.frame.cmb, pos.frame.lg, pos.frame.lsr, pos.frame.src and allow combinations like src.veloc;pos.frame.lsr src.veloc.space;pos.frame.lsr to make more clear that the concept that's changing is the frame, not the velocity. - Jonathan From Alberto.Micol at eso.org Tue May 10 05:59:29 2005 From: Alberto.Micol at eso.org (Alberto Micol) Date: Tue, 10 May 2005 14:59:29 +0200 Subject: How precise should UCDs be? In-Reply-To: <200505101206.j4AC67oh015174@urania.cfa.harvard.edu> References: <200505101206.j4AC67oh015174@urania.cfa.harvard.edu> Message-ID: <536c867aa5ebeae2ff9af6b55dc312a5@eso.org> On May 10, 2005, at 14:06, Jonathan McDowell wrote: > > The key phrase here is "requires a lot of extra parameters". In some > other practical cases, a full description *is* required: so you need > the > parameters and a data model to relate them to each other. But if the > data model is very generic you still need the UCDs to describe > precisely > what the individual parameters are. > > This is of course fuzzy, since sometimes - as in parts of STC - the > utype implies what the UCD must be. But sometimes the utype describes > only the precise relationship between two concepts, and the UCDs > describe the precise identity of the concepts - both precise, but > doing different jobs. Thus you might use utypes to > link a velocity and its standard of rest, but you still need to > use UCDs to explain that this is the escape velocity from the > star (src.veloc.escape) and not the expansion velocity of the > wind (src.veloc.expansion) that you're talking about. > [...] > Group 2 > - the velocity of what? (distinguishing different physics concepts): > src.veloc.dispersion > src.veloc.escape > src.veloc.expansion > src.veloc.microTurb > src.veloc.pulsat > src.veloc.rotat > Devil's advocate point of view It looks to me as if you are trying to model a generic astronomical source by using UCDs. Wouldn't that be the role of a "Generic Astronomical Source Data Model" instead? That is, the UCD could be src.veloc leaving to the utype of the GAS-DM to tell which part of the source is being described. Drawing a line between UCDs and UTYPEs is something we have not achieved yet. The fact is that we have never really tried. I have never seen a VOTABLE using both UCDs and UTYPEs; until we see one and we experiment with it I fear we could philosophically talk about it for ages. We need real examples (self-criticism: hence we need some DM :-) ). In my view, precise UCDs means: a pragmatic, though incomplete, approach; an approach that is useful to fill a gap: the absence of a DM. To counter-balance such sentence I can certainly add that on the other hand, we will never have all the DMs we would need. Help! :-) Alberto From derriere at newb6.u-strasbg.fr Tue May 10 06:10:55 2005 From: derriere at newb6.u-strasbg.fr (Sebastien Derriere) Date: Tue, 10 May 2005 15:10:55 +0200 Subject: New UCD list References: <200505090604.j4964lFb012041@urania.cfa.harvard.edu> Message-ID: <4280B2DF.400C25E2@astro.u-strasbg.fr> Norman Gray wrote: > > > Who is the `we', here? Is this the CDS panel for discussing new UCDs, > or the list of folk on the WG, which I take to be approximately > coextensive with the list of authors of the UCD1+ proposal? I > understood I was still on the WG, though I don't recall any such > automated emails. Hi Norman, You are still on the WG. People who receive these emails are those who explicitly asked to receive automated notifications for additions made on the following page: http://vizier.u-strasbg.fr/UCD/cgi-bin/comment/ucdComments Currently, this means: Sebastien Derriere, Bob Mann, Anita Richards, Jonathan McDowell, Pedro Osuna, Andrea Preite-Martinez, and Nausicaa Delmotte. I can add you if you want. From now on, automated messages should include the explanation of the suggested change (previously you had to check details on the web page). Sebastien. -- _______ / ~ /, Sebastien Derriere mailto:derriere at astro.u-strasbg.fr / ~~~~ // Observatoire de Strasbourg Phone +33 (0) 390 242 444 /______// 11, rue de l'universite Telefax +33 (0) 390 242 417 (______(/ F-67000 Strasbourg France From pfo at star.le.ac.uk Tue May 10 06:16:19 2005 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Tue, 10 May 2005 14:16:19 +0100 (BST) Subject: How precise should UCDs be? In-Reply-To: <536c867aa5ebeae2ff9af6b55dc312a5@eso.org> Message-ID: On Tue, 10 May 2005, Alberto Micol wrote: > On May 10, 2005, at 14:06, Jonathan McDowell wrote: > > The key phrase here is "requires a lot of extra parameters". In some > > other practical cases, a full description *is* required: so you need > > the > > parameters and a data model to relate them to each other. But if the > > data model is very generic you still need the UCDs to describe > > precisely > > what the individual parameters are. > > > > This is of course fuzzy, since sometimes - as in parts of STC - the > > utype implies what the UCD must be. But sometimes the utype describes > > only the precise relationship between two concepts, and the UCDs > > describe the precise identity of the concepts - both precise, but > > doing different jobs. Thus you might use utypes to > > link a velocity and its standard of rest, but you still need to > > use UCDs to explain that this is the escape velocity from the > > star (src.veloc.escape) and not the expansion velocity of the > > wind (src.veloc.expansion) that you're talking about. > > [...] > > Group 2 > > - the velocity of what? (distinguishing different physics concepts): > > src.veloc.dispersion > > src.veloc.escape > > src.veloc.expansion > > src.veloc.microTurb > > src.veloc.pulsat > > src.veloc.rotat > > > > Devil's advocate point of view > > It looks to me as if you are trying to model a generic astronomical > source > by using UCDs. Wouldn't that be the role of a "Generic Astronomical > Source Data Model" > instead? > That is, the UCD could be src.veloc leaving to the utype of the GAS-DM > to tell which part of the source is being described. > > Drawing a line between UCDs and UTYPEs is something we have not > achieved yet. > > The fact is that we have never really tried. I have never seen a VOTABLE > using both UCDs and UTYPEs; until we see one and we experiment with it > I fear we could philosophically talk about it for ages. > We need real examples (self-criticism: hence we need some DM :-) ). > > In my view, precise UCDs means: a pragmatic, though incomplete, > approach; > an approach that is useful to fill a gap: the absence of a DM. > > To counter-balance such sentence I can certainly add that > on the other hand, we will never have all the DMs we would need. > > Help! > :-) > > Alberto Alberto, that's exactly my problem! I've never seen any VOT with both ucds and utype that would allow me to think how to identify quantities which are "kind of equivalent" or "equivalent enough" so the user has a short list to pick what is of his/her interest. Whether that line exists, or how it will be defined is quite important. We have already a number of people (astronomers and non-astronomers) wondering why we bother with UCDs (let alone utype!). I second your position that we need practical examples, not just philosophical discussions on how we should write this or that. In my case, the clash with reality comes when consulting a registry (or the META tables in vizier) trying to retrieve resources of a particular type. Personally if I want to get catalogues with HST blue data, I'd like to get back a list with as little overhead as possible, not five times larger, poluted by all other observations in the blue bands which fall into the same box... again, I haven't seen utype widely used yet. If I could narrow down the search using utype + ucd or utype alone, fine, we can always write a piece of software to perform this task. My complaints last night had to do with the fact that up to this point in time, using only ucd1+ our searches would bring back too much overhead. Cheers, Patricio --- Patricio F. Ortiz pfo at star.le.ac.uk Department of Physics & Astronomy Phone: +44 (0)116 252 2015 University of Leicester Leicester, LE1 7RH, UK From Markus.Dolensky at eso.org Tue May 10 06:21:08 2005 From: Markus.Dolensky at eso.org (Markus Dolensky) Date: Tue, 10 May 2005 15:21:08 +0200 Subject: How precise should UCDs be? In-Reply-To: <536c867aa5ebeae2ff9af6b55dc312a5@eso.org> References: <200505101206.j4AC67oh015174@urania.cfa.harvard.edu> <536c867aa5ebeae2ff9af6b55dc312a5@eso.org> Message-ID: <4280B544.2010503@eso.org> Alberto Micol wrote: > I have never seen a VOTABLE using both UCDs and UTYPEs; Alberto, Here you are: http://www.ivoa.net/internal/IVOA/IvoaDAL/ssample20041021.xml The lack of examples is due to the fact that the utype attribute is new to version 1.1 of VOTable, but more importantly that we are just starting to write services that produce data model compliant data (chicken & egg thing). BEWARE: Above example is obsolete as far as the used data model is concerned, but it should be a valid VOTabled doc nonetheless. - Markus From debray at obs-besancon.fr Tue May 10 11:56:43 2005 From: debray at obs-besancon.fr (Bernard Debray) Date: Tue, 10 May 2005 20:56:43 +0200 Subject: How precise should UCDs be? References: <200505101206.j4AC67oh015174@urania.cfa.harvard.edu> Message-ID: <428103EB.5030205@obs-besancon.fr> Dear all, Jonathan McDowell wrote: >Francois Ochsenbein wrote: > >>This question of accurate/inaccurate description was discussed >>many times --- and one of the results was the definition of 2 >>different entities : >>-- the UCDs which have the role of broad classification >>-- the "utype" was introduced to fulfil the role of the accurate >> description -- the "utype" being in principle connected to a >> data model which gives the necessary level of detail. >> >>In the photometric domain, each of the two entities has its role: >>-- from a ucd: 2 quantities showing the same UCD can be compared >> at least in a statistical way; >>-- from a utype: the accurate specification of each filter must be >> accessible; quantities can then be combined. >> In practice however the required level of details is frequently >> not fully known. >> >>There is exactly the same problem in the astrometric domain: >>while UCDs can be used to define the RA and Dec, an accurate >>definition of these values requires a lot of extra parameters >>-- have a look at Arnold's Space-Time model and be sure you >>have specified everything if you want to be accurate... >>In many practical cases -- e.g. for statistical cross-matching -- >>a full description is not required, and then the UCDs have their >>place. >> >>--francois > >My own thoughts on the relation between UCD and utype/DM have evolved a >little (although it comes to essentially the same answer as Francois). I >believe that the UCD should have a precise and accurate definition, but >that when you need metadata, or parameters, i.e. you need to refer to >other UCDs, the utype/DM is needed. It's not a question of level of >detail or "accurate", it's a question of "complete" - do you need >more than one number of value to describe the idea? > >... >But > RA2000 and RA1950 are the same basic concept differing only by a parameter. > The concept 'RA' and the concept 'equinox' are the two different concepts > here: > pos.eq.ra (value = 12:26:03.4) and > time.equinox (value = 2000.0) > >and these are related to each other in the context of a coordinate frame >(e.g. STC) data model. RA1950 and RA2000 are really the same physical >concept simply with different metadata. pos.eq.ra is PRECISELY defined, >it's just not COMPLETELY defined without tying it to the STC metadata. > >... > >Of course for pragmatic reasons we do break this paradigm for >the "phot.*;em.*" UCDs where the "em.IR" is really metadata for the >"phot.*" concept. But in general I think this is a good rule of thumb >for deciding whether you need a new UCD, or whether you need to >relate two different UCDs via a data model. > >>while UCDs can be used to define the RA and Dec, an accurate >>definition of these values requires a lot of extra parameters >>-- have a look at Arnold's Space-Time model and be sure you >>have specified everything if you want to be accurate... >>In many practical cases -- e.g. for statistical cross-matching -- >>a full description is not required, and then the UCDs have their >>place. >> >> >The key phrase here is "requires a lot of extra parameters". In some >other practical cases, a full description *is* required: so you need the >parameters and a data model to relate them to each other. But if the >data model is very generic you still need the UCDs to describe precisely >what the individual parameters are. > >... > - Jonathan > Yes, definitely. If I go back to my particular initial concern about photometric bandpasses, I pointed that the definition of the UCDs for electromagnetic spectrum in the document NoteEMSpectrum-2004052-3.pdf which is still referred in the last version of the UCD1+ Working Draft Document (2005-04-29) is somewhat ambiguous for the optical and near-infrared parts. For example, the note in the table for em.opt.U says "B band" which, I think, for the average astronomer is Johnson B filter bandpass. On the other hand, there is no ucd to define a photometric system. Therefore in this case, the definition is not "precise" in the sense that it can be confusing. On the other hand, I would tend to think that in order to be used in registries, UCDs should allow a more complete description than for being used in statistical cross-matching (e.g. "I need a resource which has g magnitude in the SDSS photometric system for a given part of the sky"). Does that mean this should be envisaged through data modelling as well ? Bernard Debray bernard.debray at obs-besancon.fr Observatoire de Besan?on http://www.obs-besancon.fr/ BP 1615 25010 Besan?on Cedex France From jcm at head.cfa.harvard.edu Tue May 10 15:21:37 2005 From: jcm at head.cfa.harvard.edu (Jonathan McDowell) Date: Tue, 10 May 2005 18:21:37 -0400 (EDT) Subject: New UCD list Message-ID: <200505102221.j4AMLb3d015644@urania.cfa.harvard.edu> Andrea, Just a couple of followups to your reply to me on Monday: - I agree with your spelling change: phys.energyDensity - spec.veloc; em.opt: I agree if the implication of this is agreed to be "optical method for determining velocity" rather than "velocity measured from the optical spectrum". (Following Arnold's point that yes, alas, all methods are used for all kinds of data) - meta.entity etc as "a few specific words to describe VOResource" Yes... although we should be careful to define them in a general way. I'll try and propose some specifics at Kyoto. - I'm not sure "stat.background" is quite right - to me, background is an astronomical/physical rather than statistical concept. Let me be clear about my proposal: the src.* would be secondary words, so you'd write phot.flux;em.IR;src.total I agree src.net should be the default, but maybe it's helpful for clarity in some cases. instr.background seems not right, because the background can be of cosmic rather than instrumental origin. Thanks, Jonathan From derriere at newb6.u-strasbg.fr Wed May 11 06:37:36 2005 From: derriere at newb6.u-strasbg.fr (Sebastien Derriere) Date: Wed, 11 May 2005 15:37:36 +0200 Subject: UCD simple tools Message-ID: <42820AA0.A5821669@astro.u-strasbg.fr> Hello, I just released a series of basic tools to ease manipulation of the UCD1+. They are described here, with simple CGI forms: http://cdsweb.u-strasbg.fr/UCD/tools.htx A Web Service access is also available, and documented here: http://cdsweb.u-strasbg.fr/cdsws/ucdClient.gml These tools allow: translate: convert UCD1 into default corresponding UCD1+ explain: get the description of a UCD1+ word/combination validate: check whether a UCD1+ is well-formed upgrade: convert deprecated UCD1+ to a valid expression assign: attempt to find the best UCD1+ corresponding to a plain text description They will be presented to those of you attending the meeting in Kyoto, during the UCD session! Sebastien. -- _______ / ~ /, Sebastien Derriere mailto:derriere at astro.u-strasbg.fr / ~~~~ // Observatoire de Strasbourg Phone +33 (0) 390 242 444 /______// 11, rue de l'universite Telefax +33 (0) 390 242 417 (______(/ F-67000 Strasbourg France From derriere at newb6.u-strasbg.fr Thu May 12 12:08:01 2005 From: derriere at newb6.u-strasbg.fr (Sebastien Derriere) Date: Thu, 12 May 2005 21:08:01 +0200 Subject: New UCD list References: <200505091538.j49FcOfq024961@xebec.cfa.harvard.edu> Message-ID: <4283A991.2A3EED5F@astro.u-strasbg.fr> Arnold Rots wrote: > > Andrea Preite Martinez wrote: > > ... > > You first suggested em.veloc.radio to account for the 2 conventions to > > derive velocities from spectra (optical and radio conventions). If > > nobody > > ever applies the optical convention to a radio spectrum (or vice versa), > > then we can live with spect.veloc;em.opt and spect.veloc;em.radio > > What do you think? > > > > O yes! The optical definition needs to be (and is) used for plenty of > radio observations. Hi, In order to find the relevant UCD, we need an accurate description/ explanation of the quantity we want to describe. My understanding is the following: there are 3 kinds of velocities 1. physical velocities (ratio of a distance and a time) 2. radio "velocity" representing a frequency shift 3. optical "velocity" representing a wavelength shift 2 and 3 have no physical meaning, they only correspond to a physical radial velocity for motions << c (speed of light). The difference is that (2) depends on the rest frequency, while (3) depends on the observing frequency. But (2) seems to be deprecated by the IAU. In the UCD, you have the word "src.veloc" for case (1). - Again, the description of this word should read simply "Velocity", not "Radial velocity" sorry for the confusion. There is also a word "spect.veloc" for so-called velocities derived from a spectrum. We had in mind that it could be complemented by a word indicating what kind of spectra was used, e.g : spect.veloc;em.opt -> radial "velocity" derived from optical spectrum spect.veloc;em.line.HI -> radial "velocity" derived from a shift of the HI line With your input, I understand that we should have two words, for cases (2) and (3), for example: spect.opticalVeloc and spect.radioVeloc , and we could say: "spect.opticalVeloc;em.radio" for a measurement-of-a-frequency-shift-in a-radio-spectrum-expressed-as-a-velocity-with-the-optical-convention ?! My concern with this is that if someone asks the proper UCD for a "radio velocity", the answer could be "spect.opticalVeloc;em.radio" or "spect.radioVeloc", because the description given by the user is ambiguous. > Do you distinguish between LSR, geocenter, barycenter, topocenter, > Galactic center (to name the most popular ones)? There are a few UCD words which describe some reference frames: pos.geocentric pos.heliocentric pos.galactocentric You are allowed to append them to indicate in which frame the velocity was measured: src.veloc;pos.geocentric src.veloc;pos.cartesian.y;pos.galactocentric (to indicate one component of the velocity) In 3 cases where the frame was only used for velocities, some specific words exist, as noted by Jonathan: src.veloc.cmb src.veloc.lsr src.veloc.lg Sebastien. -- _______ / ~ /, Sebastien Derriere mailto:derriere at astro.u-strasbg.fr / ~~~~ // Observatoire de Strasbourg Phone +33 (0) 390 242 444 /______// 11, rue de l'universite Telefax +33 (0) 390 242 417 (______(/ F-67000 Strasbourg France From arots at head.cfa.harvard.edu Thu May 12 12:43:14 2005 From: arots at head.cfa.harvard.edu (Arnold Rots) Date: Thu, 12 May 2005 15:43:14 -0400 (EDT) Subject: New UCD list In-Reply-To: <4283A991.2A3EED5F@astro.u-strasbg.fr> Message-ID: <200505121943.j4CJhEkY024567@xebec.cfa.harvard.edu> You may want to look the gory detail up in the STC document. I'd much rather tie "radial velocities" to redshift and, yes, they are basically just formalisms, not physical velocities; but your description is not entirely accurate. - Arnold Sebastien Derriere wrote: > Arnold Rots wrote: > > > > Andrea Preite Martinez wrote: > > > ... > > > You first suggested em.veloc.radio to account for the 2 conventions to > > > derive velocities from spectra (optical and radio conventions). If > > > nobody > > > ever applies the optical convention to a radio spectrum (or vice versa), > > > then we can live with spect.veloc;em.opt and spect.veloc;em.radio > > > What do you think? > > > > > > > O yes! The optical definition needs to be (and is) used for plenty of > > radio observations. > > Hi, > > In order to find the relevant UCD, we need an accurate description/ > explanation of the quantity we want to describe. > My understanding is the following: there are 3 kinds of velocities > 1. physical velocities (ratio of a distance and a time) > 2. radio "velocity" representing a frequency shift > 3. optical "velocity" representing a wavelength shift > > 2 and 3 have no physical meaning, they only correspond to a physical > radial > velocity for motions << c (speed of light). The difference is that (2) > depends > on the rest frequency, while (3) depends on the observing frequency. But > (2) > seems to be deprecated by the IAU. > > In the UCD, you have the word "src.veloc" for case (1). - Again, the > description of this word should read simply "Velocity", not "Radial > velocity" > sorry for the confusion. > > There is also a word "spect.veloc" for so-called velocities derived > from a spectrum. We had in mind that it could be complemented by a word > indicating what kind of spectra was used, e.g : > spect.veloc;em.opt -> radial "velocity" derived from optical > spectrum > spect.veloc;em.line.HI -> radial "velocity" derived from a shift of the > HI line > > With your input, I understand that we should have two words, for cases > (2) > and (3), for example: spect.opticalVeloc and spect.radioVeloc , and we > could > say: "spect.opticalVeloc;em.radio" for a > measurement-of-a-frequency-shift-in > a-radio-spectrum-expressed-as-a-velocity-with-the-optical-convention ?! > My concern with this is that if someone asks the proper UCD for a > "radio velocity", > the answer could be "spect.opticalVeloc;em.radio" or "spect.radioVeloc", > because > the description given by the user is ambiguous. > > > > Do you distinguish between LSR, geocenter, barycenter, topocenter, > > Galactic center (to name the most popular ones)? > > There are a few UCD words which describe some reference frames: > pos.geocentric > pos.heliocentric > pos.galactocentric > > You are allowed to append them to indicate in which frame the velocity > was measured: > src.veloc;pos.geocentric > src.veloc;pos.cartesian.y;pos.galactocentric (to indicate one > component of the velocity) > > In 3 cases where the frame was only used for velocities, some specific > words exist, as noted by Jonathan: > src.veloc.cmb > src.veloc.lsr > src.veloc.lg > > Sebastien. > -- > _______ > / ~ /, Sebastien Derriere mailto:derriere at astro.u-strasbg.fr > / ~~~~ // Observatoire de Strasbourg Phone +33 (0) 390 242 444 > /______// 11, rue de l'universite Telefax +33 (0) 390 242 417 > (______(/ F-67000 Strasbourg France > -------------------------------------------------------------------------- Arnold H. Rots Chandra X-ray Science Center Smithsonian Astrophysical Observatory tel: +1 617 496 7701 60 Garden Street, MS 67 fax: +1 617 495 7356 Cambridge, MA 02138 arots at head.cfa.harvard.edu USA http://hea-www.harvard.edu/~arots/ -------------------------------------------------------------------------- From derriere at newb6.u-strasbg.fr Fri May 13 07:32:41 2005 From: derriere at newb6.u-strasbg.fr (Sebastien Derriere) Date: Fri, 13 May 2005 16:32:41 +0200 Subject: New UCD list References: <200505121943.j4CJhEkY024567@xebec.cfa.harvard.edu> Message-ID: <4284BA89.EAC5A4EB@astro.u-strasbg.fr> Arnold Rots wrote: > > You may want to look the gory detail up in the STC document. > I'd much rather tie "radial velocities" to redshift and, yes, they are > basically just formalisms, not physical velocities; but your > description is not entirely accurate. Hi, I had looked at the FITS spectral coordinates paper, as this is what Jonathan originally referenced to in his suggestion. See http://pan-starrs.ifa.hawaii.edu/ project/IPP/wcs_paper3_20050126.pdf I read there that there are 4 different quantities: 1. apparent radial velocity 2. "radio" velocity 3. "optical" velocity 4. redshift My last mail was just to suggest that we could have 2 ucd words for quantities 2 and 3 (I suggest spect.radioVeloc and spect.opticalVeloc), instead of the single spect.veloc existing now, which is not accurate enough for some people. I don't pretend we can/need be as accurate as STC with a few UCD words - leave this to specific stc:utypes. At least we must try to describe the basic existing quantities with UCD. Sebastien. -- _______ / ~ /, Sebastien Derriere mailto:derriere at astro.u-strasbg.fr / ~~~~ // Observatoire de Strasbourg Phone +33 (0) 390 242 444 /______// 11, rue de l'universite Telefax +33 (0) 390 242 417 (______(/ F-67000 Strasbourg France From Hessman at Astro.physik.Uni-Goettingen.DE Mon May 30 04:06:23 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Mon, 30 May 2005 13:06:23 +0200 Subject: T0 : extensions to em, obs, spect, instr Message-ID: 1. I suggest we rename em from "electromagnetic spectrum" to "emission" and add em.grav-wave (gravitational wave) em.neutrino (neutrino) Alternatively, add phys.grav-wave (gravitational wave) phys.particle (particle emission) phys.particle.cosmic-ray phys.particle.neutrino ...? 2. I suggest we add UCD's for describing calibration observations. Presently, they are few mentions of calibrations at all in the official list: instr.calib (calibration parameter) phot.calib (photometric calibration) and they are sorely needed for things like VOEvent and RTML. It's trivial to say that there's a big different between calibrations (see above) and calibration observations, so new UCD's are needed and it seems the likely candidates would be: obs.calib (calibration observation) obs.calib.dome-flat (dome-flat observation) obs.calib.flux (flux calibration observation) obs.calib.freq (frequency calibration observation) obs.calib.guide-star (guide-star observation, e.g. for intial setup) obs.calib.phot (photometric calibration observation) obs.calib.pos (astrometric calibration observation obs.calib.sky-flat (sky-flat observation) obs.calib.slit-mask (slit-mask calibration observation) obs.calib.spect (spectral type calibration observation) obs.calib.veloc (radial velocity calibration observation, e.g. standard star) obs.calib.wl (wavelength calibration observation) For completeness, one should then also add phot.calib.flux (photometric flux calibration) phot.calib.mag (photometric magnitude calibration) pos.calib (astrometric calibration) spect.calib (spectroscopic calibration) spect.calib.wl (" " in wavelength) spect.calib.freq (" " in frequency) 3. Suggested addition to spect (Spectroscopy) spect.cont (spectral continuum) We already have spect.line. Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From Hessman at Astro.physik.Uni-Goettingen.DE Mon May 30 04:23:44 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Mon, 30 May 2005 13:23:44 +0200 Subject: Txx Message-ID: <84bb0f6cc51a46b0499a99dc75f16b0a@Astro.physik.Uni-Goettingen.DE> Again, because of VOEvent and RTML, I'd like to suggest we include at least event (physical or observational event) event.burst ("sudden" observed change in state) event.chirp (continuous change in frequency) event.discovery (discovery of previously unknown object) event.eclipse (intrinsic eclipse of physically related objects) event.eruption ("sudden" physical change in state resulting in more/less observed emission) event.explosion (physical explosion) event.glitch (discontinuous change in frequency) event.occulation (extrinsic occulation of physically unrelated objects) event.variation (variation in some observable property) event.variation.phot (photometric variation) event.variation.pos (astrometric shift in position) event.variation.spect (spectroscopic variation) If we're going to have solar system UCD's, then it's only fair to have stellar and extragalactic ones: I suggest looking at http://monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/ UnifiedContentDescriptors were there are unit UCD's like "stars", "ism", "galaxy" (as in milky way), "galaxies", and "cosmology". Yes, we don't have to adopt ALL of them, but it would help to have the basic ones. Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From pdidelon at cea.fr Tue May 31 06:09:03 2005 From: pdidelon at cea.fr (Pierre Didelon) Date: Tue, 31 May 2005 15:09:03 +0200 Subject: T0 : extensions to em, obs, spect, instr In-Reply-To: References: Message-ID: <429C61EF.4020300@cea.fr> Hi, Frederic V. "Rick" Hessman wrote: > 1. I suggest we rename em from "electromagnetic spectrum" to "emission" electromagnetic spectrum can concern absorption! > and add > > em.grav-wave (gravitational wave) > em.neutrino (neutrino) > > Alternatively, add > > phys.grav-wave (gravitational wave) > phys.particle (particle emission) > phys.particle.cosmic-ray > phys.particle.neutrino why not electron, proton, neutron.... UCD must define preferentially concept I suppose, isn't it? Enumerated lists must be handle with other mechanisms! Keyword (<=>UCD) and the corresponding values...Y/N? > ...? > > 2. I suggest we add UCD's for describing calibration observations. > Presently, they are > few mentions of calibrations at all in the official list: > > instr.calib (calibration parameter) > phot.calib (photometric calibration) > > and they are sorely needed for things like VOEvent and RTML. > > It's trivial to say that there's a big different between > calibrations (see above) and calibration > observations, so new UCD's are needed and it seems the likely > candidates would be: > > obs.calib (calibration observation) > obs.calib.dome-flat (dome-flat observation) > obs.calib.flux (flux calibration observation) > obs.calib.freq (frequency calibration observation) > obs.calib.guide-star (guide-star observation, e.g. for > intial setup) > obs.calib.phot (photometric calibration observation) > obs.calib.pos (astrometric calibration observation > obs.calib.sky-flat (sky-flat observation) > obs.calib.slit-mask (slit-mask calibration observation) > obs.calib.spect (spectral type calibration observation) > obs.calib.veloc (radial velocity calibration > observation, e.g. standard star) > obs.calib.wl (wavelength calibration observation) Looks like you are trying to define a data model for observation and data reduction with UCD... which is perhaps not the best way to go? > > For completeness, one should then also add > > phot.calib.flux (photometric flux calibration) > phot.calib.mag (photometric magnitude calibration) > pos.calib (astrometric calibration) > spect.calib (spectroscopic calibration) > spect.calib.wl (" " in wavelength) > spect.calib.freq (" " in frequency) > > 3. Suggested addition to spect (Spectroscopy) > > spect.cont (spectral continuum) I like it (personnaly), but why not then spect.background.... > > We already have spect.line. > > > Rick > > ------------------------------------------------------------------------ > ------------------------ > Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE > Universitaets-Sternwarte Tel. +49-551-39-5052 > Geismarlandstr. 11 Fax +49-551-39-5043 > 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman > ------------------------------------------------------------------------ > ------------------------- > MONET: a MOnitoring NEtwork of Telescopes > http://monet.uni-goettingen.de > ------------------------------------------------------------------------ > ------------------------- > -- Pierre ------------------------------------------------------------------ DIDELON :@: pdidelon_at_cea.fr Phone : 33 (0)1 69 08 58 89 CEA SACLAY - Service d'Astrophysique 91191 Gif-Sur-Yvette Cedex ------------------------------------------------------------------ Aidez les enfants Tib?tains : http://www.a-e-t.org/jcparrain.htm ou d'autres : http://www.sosesf.org/ ------------------------------------------------------------------ Seule compte la d?marche. Car c'est elle qui dure et non le but qui n'est qu'illusion du voyageur... Saint Exupery - Citadelle ------------------------------------------------------------------ From Hessman at Astro.physik.Uni-Goettingen.DE Tue May 31 08:06:22 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Tue, 31 May 2005 17:06:22 +0200 Subject: T0 : extensions to em, obs, spect, instr In-Reply-To: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> Message-ID: <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE> On 31 May 2005, at 3:09 pm, Pierre Didelon wrote: > Frederic V. "Rick" Hessman wrote: > >> 1. I suggest we rename em from "electromagnetic spectrum" to >> "emission" and add >> em.grav-wave (gravitational wave) >> em.neutrino (neutrino) > electromagnetic spectrum can concern absorption! Yes, but if you see anything at all, it's ultimately emission (even if attenuated). Admittedly, the better solution is... >> Alternatively, add >> phys.grav-wave (gravitational wave) >> phys.particle (particle emission) >> phys.particle.cosmic-ray >> phys.particle.neutrino > why not electron, proton, neutron.... If people are detecting them, why not? The whole point of em is to describe by what means we observe something, and photons are only one of many ways. I'm sure my LIGO colleagues would be happy with phys.grav-wave and my HESS/MAGIC friends phys.particle.neutrino. The present UCD isn't complete and we probably won't need phys.particle.axion for a long while, so the (other) missing entries aren't a problem, but right now there are some glaring holes..... > UCD must define preferentially concept I suppose, isn't it? > Enumerated lists must be handle with other mechanisms! > Keyword (<=>UCD) and the corresponding values...Y/N? I'm not sure what you mean.... >> ...? >> 2. I suggest we add UCD's for describing calibration observations. >> Presently, they are >> few mentions of calibrations at all in the official list: >> instr.calib (calibration parameter) >> phot.calib (photometric calibration) >> and they are sorely needed for things like VOEvent and RTML. >> It's trivial to say that there's a big different between >> calibrations (see above) and calibration >> observations, so new UCD's are needed and it seems the likely >> candidates would be: >> obs.calib (calibration observation) >> obs.calib.dome-flat (dome-flat observation) >> obs.calib.flux (flux calibration observation) >> obs.calib.freq (frequency calibration observation) >> obs.calib.guide-star (guide-star observation, e.g. for >> intial setup) >> obs.calib.phot (photometric calibration >> observation) >> obs.calib.pos (astrometric calibration observation >> obs.calib.sky-flat (sky-flat observation) >> obs.calib.slit-mask (slit-mask calibration observation) >> obs.calib.spect (spectral type calibration >> observation) >> obs.calib.veloc (radial velocity calibration >> observation, e.g. standard star) >> obs.calib.wl (wavelength calibration observation) > Looks like you are trying to define a data model for observation > and data reduction with UCD... which is perhaps not the best way to go? Absolutely NOT!!!! I just want to be able to say what something is, just like the original VOTable types who wanted to describe their catalogue entries. There's nothing fundamentally different in a VO sense between a calibration image (say, an obs.calib.phot) and a table entry of the resulting calibration (say, phot.calib). Right now, UCD is mainly (some but not me might say only) useful for tables, which is why it needs to be extended to non-table standard VO uses. A "data model for observation and data reduction" looks very different indeed, though it must ultimately use elements for which the VO has a primitive description. UCD is our VO dictionary and data/observation/reduction models are VO prose or poetry: do you want us to write a VO poem using words no one (i.e. no app) understands? >> For completeness, one should then also add >> phot.calib.flux (photometric flux calibration) >> phot.calib.mag (photometric magnitude calibration) >> pos.calib (astrometric calibration) >> spect.calib (spectroscopic calibration) >> spect.calib.wl (" " in wavelength) >> spect.calib.freq (" " in frequency) >> 3. Suggested addition to spect (Spectroscopy) >> spect.cont (spectral continuum) > I like it (personnaly), but why not then spect.background.... If it's needed, why not? Your favorite VO app should be able to know the difference between a spectral line and a spectral contiinuum and, in the real world, between the spectrum in the background (sky). Again, we have spect.line right now only because there are spectral line catalogues out there but few spectral continuum catalogues. No, I'm not trying to get a VO ontology through the back door: ontologies tell us what the intimate relations between objects are, whereas UCD simply gives us the ability to name things. We're still in the VO Neadertaler age where we've only agreed that "Ugga" means "rock". I'm worrying about how we ultimately want to transmit the knowledge of turning a rock into a spear. I hope that the problem now isn't going to be getting our colleagues to agree that we need a word for "stick".... Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From andrea.preitemartinez at rm.iasf.cnr.it Sun May 1 22:15:45 2005 From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez) Date: Mon, 2 May 2005 07:15:45 +0200 Subject: New list of words Message-ID: <20050502071545.o2qry3nmgtcgok8s@webmail.sic.rm.cnr.it> Dear member of the UCD_wg, since last Friday (20050429) an updated list of UCD words is available at: http://vizier.u-strasbg.fr/UCD/ucd1p-words.txt at the UCD page: http://vizier.u-strasbg.fr/UCD/ The new list of words has been edited according to the very valuable comments coming from the community and also thanks to the (almost!) every day use of them made by Sebastien and myself. The most important differences with the previous version (20040823) concern - distances and sizes (linear/angular) - the introduction of a rectangular/cartesian reference frame - the phot.color section, much simplified - spelling, abbreviations, syntax ... At the UCD page you can also find un updated version of the UCD_tree browser(s) and a new tool, the ucd_builder: http://vizier.u-strasbg.fr/UCD/cgi-bin/descr2ucd that uses a description in "natural" language to find the relevant ucd_words, and then tries to build a valid ucd out of them. In these two weeks before Kyoto please explore the list, use the tools and send back comments. A more "formal" comment page is available to suggest changes in the list of words at: http://vizier.u-strasbg.fr/UCD/cgi-bin/comment/ucdComments Have fun. Andrea ============================================================================== Andrea Preite Martinez andrea at rm.iasf.cnr.it Istituto di Astrofisica Spaziale Tel.:+39.06.4993.4641 Area di Ricerca di Tor Vergata Fax.:+39.06.2066.0188 Via del Fosso del Cavaliere 100 Cell:+39.339.3817355 00133 Roma ============================================================================== From Alberto.Micol at eso.org Mon May 2 03:25:47 2005 From: Alberto.Micol at eso.org (Alberto Micol) Date: Mon, 2 May 2005 12:25:47 +0200 Subject: New list of words In-Reply-To: <20050502071545.o2qry3nmgtcgok8s@webmail.sic.rm.cnr.it> References: <20050502071545.o2qry3nmgtcgok8s@webmail.sic.rm.cnr.it> Message-ID: Dear Andrea, Thanks a lot for the new list! A couple of comments/suggestions: Versioning: the ucd1p-words.txt file does not contain any version one could refer to. On this topic, the UCD page (http://vizier.u-strasbg.fr/UCD/) provides a link to "ucd1p-words.txt" and a link to "ucd1p-words-20050429.txt" and it is not clear whether one is a link to the other (I would prefer to always see the version in the file name). Also, beware that the document pointed to in the UCD page ("Explanations on the vocabulary are available in IVOA WD-UCDlist-20050429.pdf") is not found on the ivoa web site. Then, looking at the list with biased eyes given that these days I'm working on the Characterisation DM, I have a remark on some asymmetry within the list. For example let's take the Resolution concept for which I can find: Q|instr.angRes |Angular resolution Q|instr.spect.resolution |Spectral (or velocity) resolution Q|time.resolution |Time resolution The problems I see with this are: 1.- the resolution (think of an image from the ground) is not only a instrumental effect (unless one thinks of the atmosphere as part of the instrument) 2.- In the charcterisation DM, resolution on the various axes is treated symmetrically Hence, my preference would go for something along these lines: Q|pos.resolution |Angular resolution Q|spect.resolution |Spectral (or velocity) resolution Q|time.resolution |Time resolution What do you think? Ciao, Alberto PS: Just another little question on: S|instr.pixel |Pixel what is that for? In which case is it used? Thanks. On May 2, 2005, at 07:15, Andrea Preite Martinez wrote: > Dear member of the UCD_wg, > > since last Friday (20050429) an updated list of UCD words is available > at: > > http://vizier.u-strasbg.fr/UCD/ucd1p-words.txt > > at the UCD page: > > http://vizier.u-strasbg.fr/UCD/ > ... From andrea.preitemartinez at rm.iasf.cnr.it Mon May 2 04:56:47 2005 From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez) Date: Mon, 2 May 2005 13:56:47 +0200 Subject: New list of words In-Reply-To: References: <20050502071545.o2qry3nmgtcgok8s@webmail.sic.rm.cnr.it> Message-ID: <20050502135647.sugef32llp0gkk4g@webmail.sic.rm.cnr.it> Dear Alberto > > beware that the document pointed to in the UCD page > ("Explanations on the vocabulary are available in IVOA > WD-UCDlist-20050429.pdf") is not found on the ivoa web site. sorry, still editing a section... > I have a remark on some asymmetry within the list. For example > let's take the Resolution ... > ... my preference would go for something along these lines: > > Q|pos.resolution |Angular resolution > Q|spect.resolution |Spectral (or velocity) > resolution > Q|time.resolution |Time resolution > > What do you think? I like your proposal. I'm sure you'll have other before Kyoto! > PS: Just another little question on: > S|instr.pixel |Pixel > what is that for? In which case is it used? Try "pixel size" on the builder. Andrea From Hessman at Astro.physik.Uni-Goettingen.DE Mon May 2 05:58:37 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Mon, 2 May 2005 14:58:37 +0200 Subject: New UCDs for VOEvent please In-Reply-To: <4272824B.7010900@gsfc.nasa.gov> References: <32fd4a5efbfd9d3afbbae300411c0379@Astro.physik.Uni-Goettingen.DE> <426FBAC9.2050600@cacr.caltech.edu> <4272824B.7010900@gsfc.nasa.gov> Message-ID: <71e0852515f7c6122fe60632c6efb16d@Astro.physik.Uni-Goettingen.DE> On 29 Apr 2005, at 8:51 pm, Ed Shaya wrote: > But we can also be keeping another eye on the longer time scale where > we want to be able to put data in machine understandable terms so that > applications can do the most possible on our behalf. This requires > something a bit more sophisticated than just a simple class hierarchy > of terms. An ontology would be more complete but probably not even an > order of magnitude (factor 10) more than the UCD is now. In fact, > given the requests and requirements to augment UCDs, with time, the > UCD will probably grow to the size of an ontology anyway. So, it is > probably wise to start doing some thinking in terms of the formal OWL > standard now. What we do with the ontology can vary greatly. > 1. Use it as a string identifier, exactly as UCDs are. The advantage > is that one can read the Ontology at that point to get more context > for the meaning of the term. > 2. Use it as one more model builder for developing schemas. This is > like UML but more in tune with knowledge/information structures. I > think this is what Mathew had in mind. > 3. Use it to test completeness and consistency of terms. This would > not be on the fly, but rather as one adds new terms one can see > whether it is clashing with other terms and Venn diagrams let you see > something about completeness. This then makes it more acceptable for > groups to be adding terms into their namespace without going to the VO > heads or the IAU. > 4. One can use it as the defining structure of all information being > exchanged. Sounds daring but in fact several other related science > fields are preparing to do just that, including space physics. > 5. One can use it to reason out pathways to converting, pipelining, > and analysing data. It should be possible to automatically find the > transformation and queries needed to satisfy an arbitrary stated goal > or request. Our group at UMD has an NASA/AISRP grant to figure out > the basics of how this might be done using OWL. Ummm.... maybe my googling didn't go quite as far or I'm missing something: the "ontology" I found was a "low-level" (no - that sounds too negative - let's say "very fundamental") means of describing scientific quantities - nothing particularly "astronomical" about it. If this is as far as anyone has gotten, then I vote for a mid-term temporary solution - what I've called "VOThings" - which someone else can turn into a full astronomical ontology in the future. Thus, - Small, multiple, overlapping, incompatible lists within different schemata will be an unnecessary pain, so we need a minimal common-ground list. - A formal development of a real astronomical ontology will take many years and we can't wait that long. - We should resist the temptation to make VOThings "complete" since it won't ever be such and we'd waste time in trying. Maybe having such a terrible name will be a good thing - let's get it over quickly knowing that some day somebody else will get it right. Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From Alberto.Micol at eso.org Tue May 3 01:54:53 2005 From: Alberto.Micol at eso.org (Alberto Micol) Date: Tue, 3 May 2005 10:54:53 +0200 Subject: New list of words In-Reply-To: <20050502135647.sugef32llp0gkk4g@webmail.sic.rm.cnr.it> References: <20050502071545.o2qry3nmgtcgok8s@webmail.sic.rm.cnr.it> <20050502135647.sugef32llp0gkk4g@webmail.sic.rm.cnr.it> Message-ID: Dear Andrea, > I'm sure you'll have other before Kyoto! I'm taking it seriously :-) Here some other comments, in no particular order: 1. pos.frame exists, can we also add the spect.frame and time.frame? 2. instr.spec: probably not needed because otherwise we would also need instr.imager, and similarly for other kinds of instruments. Also, instr.spect.dispersion could simply be instr.dispersion instr.spect.order " " " instr.order (in fact there is no need to say instr.imager.scale, instr.scale is enough). 3. Transmission (an old friend of mine): some time ago Sebastien and I exchanged some emails and, if I remember correctly, we agreed that there should be a phys.transmission which could be attached to any of: instr.det, instr.filter, instr to distinguish between the transmission/sensitivity of the various components (detector, filter, optical elements) and the overall transmission (filter * detector * optical elements) including even the atmosphere if necessary. 4. instr.sensitivity; Its description reads: Instrument sensitivity, detection threshold I would say that sensitivity and detection threshold, while linked, are two different concepts, and would be better to split that one into 2 different UCDs 5. Descriptions: sometimes the description of a ucd is ambiguous, e.g.: a. instr.tel.focus (Q): Telescope focus b. instr.bandpass (Q): Bandpass of instrument c. instr.pixel (S): Pixel a. Is instr.tel.focus the "name" of the telescope focus (eg nasmith), or the focal length of the telescope? b. instr.bandpass How many services will make use of this ucd to describe a table column that contains the numeric transmission at a given wavelength of a given filter? Some other service will use this ucd to describe the name of the bandpass (or the filter name). Which one of the two is legitimate, both? (see (3) above). c. Another, though different, example is the instr.pixel I can think of a catalog associated with an image, where X and Y indicate at which detector coordinates the source was found (pos;instr.pixel). But it can be used to indicate the pixel scale of the detector (phys.angSize;instr.pixel) The fact is that instr.pixel is a Secondary word, hence its meaning could be broader. For that reason probably both above mentioned cases are legitimate: instr.pixel is only an attribute (an adjective in a grammar-speak). I think it is very important to be clear, especially on those words that could be Primary, because otherwise people might misuse UCDs and that would make the entire concept collapse. 6. Abbreviations: Why temperature is some times abbreviated and some other times not? (e.g., instr.skyTemp, phot.antennaTemp, phys.temperature) Wouldn't be better to be consistent? 7. wcs information pos.wcs.ctype: How would the software recognise ctype1 from ctype2 ? Would it be possible to say: pos.wcs.ctype;arith.first and pos.wcs.ctype;arith.second? Or maybe (see cdmatrix below): arith.1 and arith.2 The same for pos.wcs.crpix, crval and naxis pos.wcs.cdmatrix: how to distinguish the various matrix elements? what about accompaining the cdmatrix with a arith.1_1, arith.1_2, etc.? That arith.1, etc. could be useful to rank things. 8. question regarding files meta.file exists; how can I describe the size (eg in bytes) of a file? and its CRC? Probably enough for this morning... ;-) And, beware, I might come back with more DM issues. :-) Ciao, Alberto From norman at astro.gla.ac.uk Tue May 3 07:18:22 2005 From: norman at astro.gla.ac.uk (Norman Gray) Date: Tue, 3 May 2005 15:18:22 +0100 Subject: UCD name documentation Message-ID: <1eff2d5b2ed291becf05825cb37fd8e6@astro.gla.ac.uk> Greetings, I've just been involved in a discussion in another forum about UCDs, and their general desirability as metadata keywords (in fact it was in the context of the keywords to be extracted by a putative FITS plugin for MacOS X 10.4's Spotlight -- extremely nice). I was trying to discourage folk from using FITS keywords as general metadata, and encourage them to use UCDs instead. As part of this, I produced a set of UCD equivalents for a candidate list of FITS keywords. There were some gaps, however, and I wasn't sure how to go about filling them. Is there a better way than looking through the one-line descriptions in the current list at ? There are two UCD tree browsers on the UCD page, of course, but they're really just a more attractive presentation of the text list and don't, for example, have more discursive documentation. The other UCD tools didn't produce any useful suggestions for `BITPIX' or `number of axes' What would be _really_ nice, of course, is a tool which allowed you to enter one of a subset of FITS keywords and produced one of a few possible UCDs to use instead. So my question is, am I missing something (much more likely than I wish it were)? Such a thing would require an injection of Copious Free Time, of course, but I found myself in a rather awkward place, recommending UCDs over FITS keywords, to an audience which is familiar with FITS, but for whom the UCD list is opaque and rather thinly documented. All the best, Norman -- ---------------------------------------------------------------------- Norman Gray : Physics & Astronomy, Glasgow University, UK http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk From andrea.preitemartinez at rm.iasf.cnr.it Tue May 3 07:41:14 2005 From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez) Date: Tue, 3 May 2005 16:41:14 +0200 Subject: UCD name documentation In-Reply-To: <1eff2d5b2ed291becf05825cb37fd8e6@astro.gla.ac.uk> References: <1eff2d5b2ed291becf05825cb37fd8e6@astro.gla.ac.uk> Message-ID: <20050503164114.gxpb53ye89ygogo4@webmail.sic.rm.cnr.it> Dear Norman, > As part of this, I produced a set of UCD equivalents for a candidate > list of FITS keywords. I did the same exactly a year ago. UCDs have evolved since then, and the list I'm appending was not revised according to the new list now on-line. The list was generated merging the headers produced by 7 observatories/data_producers (with data in all ranges of wl). > There were some gaps, however, and I wasn't > sure how to go about filling them. Is there a better way than looking > through the one-line descriptions in the current list at > ? There are two UCD > tree browsers on the UCD page, of course, but they're really just a > more attractive presentation of the text list and don't, for example, > have more discursive documentation. The other UCD tools didn't produce > any useful suggestions for `BITPIX' or `number of axes' I agree, even the "builder" will not be of great help with BITPIX! > What would be _really_ nice, of course, is a tool which allowed you to > enter one of a subset of FITS keywords and produced one of a few > possible UCDs to use instead. If you think that the appended list (better, an updated version of it) could be the base for such a tool, I'll do it (the tool, I mean) All the best, Andrea -------------- next part -------------- #FITS Keyword | Description | Proposed UCD1+ #Andrea, 10/10/2003 | Rev.17/05/2004 | # | | AIRMASS | air mass | obs.air.mass AIRT_EOS | air temperature at End of Scan | phys.temperature;obs.air AIRT_SOS | air temperature at Start of Scan | phys.temperature;obs.air AMASS_FC | approximate air mass at image center | obs.air.mass AM_EOS | air mass at End of Scan | obs.air.mass AM_SOS | air mass at Start of Scan | obs.air.mass APERTURE | name of field of view aperture | meta.id;instr.fov ARCFILE | archive file name | meta.id;meta.file ARYT_EOS | array temperature at End of Scan | phys.temperature;instr AUTHOR | author of the data | meta.bib.author BANDPASS | GSSS bandpass code | instr.bandpass BANDW | total bandwidth of observation | instr.bandwidth BAR_EOS | barometric pressure at End of Scan | phys.pressure;obs.air BAR_SOS | barometric pressure at Start of Scan | phys.pressure;obs.air BASE | pixel dwell time | time;instr.pixel BITPIX | bits per data value | meta.fits.bitpix BLANK | value used for undefined array elements | meta.code;meta.table BLOCKED | is physical blocksize a multiple of 2880? | meta.code;meta.fits BSCALE | linear factor in scaling equation | arith.factor BUNIT | physical units of the array values | meta.unit BZERO | zero point in scaling equation | arith.zp CALID | calibration identifiers for image | meta.id;phot.calib CDELTia | coordinate increment along axis ia | pos.wcs CDi_ja | linear transformation matrix (with scale) | pos.wcs CHECKSUM | checksum for the current HDU | meta.fits.software CHECKVER | version of checksum algorithm | meta.fits.software COMMENT | descriptive comment | meta.note CONFIGUR | s/w configuration used to process the data | meta.fits.software CONTINUE | denotes the CONTINUE long string keyword convention | meta.note CREATOR | name of software task that created the file | meta.id;meta.fits.software CROTAn | coordinate system rotation angle | pos.wcs CRPIXja | pixel coordinate of the reference point | pos.wcs CRVALia | coordinate system value at reference point | pos.wcs CTYPEa | axis type | pos.wcs CUNITia | units of CRVALia and CDELTia | pos.wcs DATAMAX | maximum data value | stat.max DATAMEAN | mean data value | stat.mean DATAMED | median data value | stat.median DATAMIN | minimum data value | stat.min DATAMODE | pre-processor dat mode | meta.fits.software DATARMS | RMS of data values | stat.stdev DATASUM | checksum of the dat records | meta.fits.software DATE | date of file creation | time.epoch;meta.fits DATE-END | date of the end of observation | time.end DATE-OBS | date of the observation | time.epoch DATE_EOS | U.T. date at End of Scan | time.end DATE_SOS | U.T. date at Start of Scan | time.start DAYNUM | sequential survey day number | time.epoch DEC | declination of the observed object | pos.eq.dec DEC_EOS | scan reference declination J2000 | pos.eq.dec DEC_NOM | nominal declination of the observation | pos.eq.dec DEC_OBJ | declination of the observed object | pos.eq.dec DEC_PNT | dec of the pointed direction of the instrument | pos.eq.dec DEC_SCX | declination of the X spacecraft axis | pos.eq.dec;instr DEC_SCY | declination of the Y spacecraft axis | pos.eq.dec;instr DEC_SCZ | declination of the Z spacecraft axis | pos.eq.dec;instr DEC_SOS | scan reference declination J2000 | pos.eq.dec DETNAM | name of detector used to make the observation | meta.id;instr.det DXFS | cross-scan frame step for image | # DYFS | in-scan frame step for image | # ELAPTIME | elapsed time of the observation | time.expo END | marks the end of the header keywords | meta.note EPOCH | equinox of celestial coordinate system | time.equinox EQUINOX | equinox of celestial coordinate system | time.equinox EXPOSURE | exposure time | time.expo EXPTIME | exposure time | time.expo EXTEND | may the FITS file contain extensions? | meta.code EXTLEVEL | hierarchical level of the extension | meta.code EXTNAME | name of the extension | meta.id;meta.code EXTVER | version of the extension | meta.id;meta.code FILENAME | name of the file | meta.id;meta.file FILETYPE | type of file | meta.code;meta.file FILTER | name of filter used during the observation | meta.id;instr.filter FILTERn | name of filters used during the observation | meta.id;instr.filter FLXSCALE | relative flux scale | arith.factor;phot.flux FN_PRNX | observatory filename prefix | meta.id;meta.file FOCUS | telescope focus setting | meta.code;instr.tel.focus FREQ0 | rest frequency | em.freq FREQR | reference frequency | em.freq GCOUNT | group count | meta.number;meta.fits GRATING | name of the grating used during observation | meta.id;instr.grating GRATINGn | name of the grating used during observation | meta.id;instr.grating GROUPS | indicates random groups structure | meta.note HA_EOS | hour angle at End of Scan | pos.az.ha HA_SOS | hour angle at Start of Scan | pos.az.ha HDUCLASS | general identifier for the classification of the data | meta.fits.hdu HDUCLASn | hierarchical classification of the data | meta.fits.hdu HDUDOC | reference to document describing the data format | meta.fits.hdu HDULEVEL | hierarchical level of the HDU | meta.fits.hdu HDUNAME | descriptive name of the HDU | meta.fits.hdu HDUVER | version number of the HDU | meta.fits.hdu HDUVERS | specific version of the document referenced by "HDUDOC" | meta.fits.hdu HIERARCH | denotes the HIERARCH keyword convention at ESO | meta.fits.eso HISTORY | processing history of the data | meta.note;meta.fits ICSVERSN | "ics" script version | meta.fits.software INHERIT | denotes the INHERIT keyword convention | meta.note;meta.fits INSTRUME | name of instrument | meta.id;instr IS_OFF1 | in-scan offset - SOS to frame 1 | # IS_OFF2 | in-scan offset - SOS to end frame | # JD-END | Julian Day at end | time.end JD-START | Julian Day at start | time.start JDAY | Julian Day of observation | time.epoch LATITUDE | geographic latitude of the observation | pos.earth.lat LIVETIME | exposure time after deadtime correction | time.expo MAGZP | calibrated zero point for image (magnitudes) | arith.zp;phot.calib MAPLAB | label of the map | meta.id;obs.field MISSION | mission name | meta.id;instr.obsty MJD-OBS | modified Julian Day at start | time.start MJDREF | modified Julian Day zero point for times | time.epoch MOONANGL | angle between the observation and the moon | pos.posAng NAXIS | number of axes | phys.dimens;meta.table NAXISn | size of the axis n | phys.size;meta.table.axis NEXTEND | Number of standard extensions | meta.number NOISE | noise value in map | instr.det.noise NORM | normalization factor in "fast fourier transform" | arith.factor;stat.Fourier NUMFRMS | number of frames in scan | meta.number OBJECT | name of observed object | meta.id;src OBJNAME | IAU name of observed object | meta.id;src OBSERVER | observer who acquired the data | obs.observer OBS_ID | unique observation ID | meta.id;obs OBS_MODE | instrumental mode of the observation | meta.code;instr.setup ONTIME | integration time during the observation | time.expo ORDATE | observation reference date | time.epoch ORIENTAT | position angle of image y axis (deg. E of N) | pos.posAng ORIGFILE | original file name | meta.id;meta.file ORIGIN | organization responsible for the data | meta.id;instr.obsty PA_PNT | position angle of the pointing | pos.posAng PCDEC | pointing center declination | pos.eq.dec;obs PCOUNT | parameter count | meta.number PCRA | pointing center R.A. | pos.eq.ra;obs PCi_ja | linear transformation matrix | pos.wcs PIXNAM | "pixphot" processing namelist configuration id | meta.fits.software PLATEID | GSSS plate id | meta.id;instr.plate PLTDECD | Dec (degrees) of plate center | pos.eq.dec.degrees;instr.plate PLTDECM | Dec (arcmin) of plate center | pos.eq.dec.arcmin;instr.plate PLTDECS | Dec (arcsec) of plate center | pos.eq.dec.arcsec;instr.plate PLTDECSN | Dec (sign) of plate center | pos.eq.dec.sign;instr.plate PLTGRADE | plate quality grade | meta.code;instr.plate PLTLABEL | observatory plate label | meta.id;instr.plate PLTRAH | R.A. (hours) of plate center | pos.eq.ra.hours;instr.plate PLTRAM | R.A. (minutes) of plate center | pos.eq.ra.minutes;instr.plate PLTRAS | R.A. (seconds) of plate center | pos.eq.ra.seconds;instr.plate PLTSCALE | plate scale (arcsec per mm) | instr.scale POSITNID | observatory scan position identifier | meta.id;pos,obs.field PROGRAM | the name of the s/w task that created the file | meta.id;meta.fits.software PSCALn | parameter scaling factor axis n | arith.factor PSi_ma | coordinate parameter m (char) | pos.wcs PTYPEn | name of random groups parameter | #meta.id PVi_ma | coordinate parameter m (float) | pos.wcs PZEROn | parameter scaling zero point | arith.zp RA | R.A. of the observation | pos.eq.ra;obs RADECSYS | coordinate reference frame | pos.frame RA_EOS | scan reference R.A. J2000 | pos.eq.ra;obs RA_NOM | nominal R.A. of the observation | pos.eq.ra;obs RA_OBJ | R.A. of the observed object | pos.eq.ra RA_PNT | R.A. of the pointed direction of the instrument | pos.eq.ra;instr RA_SCX | R.A. of the X spacecraft axis | pos.eq.ra;instr RA_SCY | R.A. of the Y spacecraft axis | pos.eq.ra;instr RA_SCZ | R.A. of the Z spacecraft axis | pos.eq.ra;instr RA_SOS | scan reference R.A. J2000 | pos.eq.ra;obs REFERENC | bibliographic reference | meta.bib REGION | GSSS region name | meta.id;instr.plate ROOTNAME | rootname of the file | meta.id;meta.file SATURATE | Data value at which saturation occurs | # SCANDIR | scan direction | # SCANIMG | name of original scan | meta.id;obs SCANNO | nightly scan number | meta.number;obs SCANNUM | identifies scan of the plate | meta.id;instr.plate SCHEDVER | scan scheduled version | meta.code;obs SCRPTFN | script template file name | meta.fits.software SCRPTVER | script template version | meta.fits.software SEESH | seeing shape parameter for image | instr.obsty.site.seeing SEE_EOS | seeing at End of Scan | instr.obsty.site.seeing SEE_SOS | seeing at Start of Scan | instr.obsty.site.seeing SIMPLE | does file conform to the Standard? | meta.code;meta.fits SITELAT | latitude of observatory | pos.earth.lat SITELONG | longitude of observatory | pos.earth.lon SKIPRDOS | number of frames skipped at start of scan | meta.number SKYSIG | point source filtered noise estimate for image | instr.det.noise SKYVAL | modal sky estimate for image | instr.det.noise STRIP_ID | 2MASS tile number | meta.id;obs.field ST_EOS | sidereal time at End of Scan | time.end ST_SOS | sidereal time at Start of Scan | time.start SUNANGLE | angle between the observation and the sun | pos.posAng TBCOLn | beginning column number | meta.id;meta.table.column TDBINn | default histogram bin size for the column | # TDIMn | dimensionality of the array | phys.dimens;meta.table.column TDISPn | display format | meta.code;meta.fits TDMAXn | maximum physical value in the column | stat.max TDMINn | minimum physical value in the column | stat.min TELAPSE | elapsed time of the observation | time.expo TELESCOP | name of telescope | meta.id;instr.tel TELNAME | telescope location (name of site) | instr.obsty.site TELT_EOS | telescope temperature at End of Scan | phys.temperature;instr.tel TELT_SOS | telescope temperature at Start of Scan | phys.temperature;instr.tel TFIELDS | number of columns in the table | meta.number;meta.table.column TFORMn | column data format | meta.code;meta.table.column THEAP | offset to starting data heap address | arith.diff;phys.size;meta.fits TIME-END | time at the end of the observation | time.end TIME-OBS | time at the start of the observation | time.start TIMEDEL | time resolution of data | time.resolution TIMER0 | read1 time | time;instr.setup TIMER1 | read2-read1 time | time;instr.setup TIMER2 | secondary settling time | time;instr.setup TIMEREF | time reference (barycenter/local) | meta.ref;time TIMESYS | time system | meta.ref;time TIMEUNIT | time unit | meta.unit;time TIMEZERO | clock correction | arith.factor;time TIMVERSN | timing system definition | meta.ref;time TITLE | title for the observation or data | meta.id;obs TLMAXn | maximum legal value in the column | stat.max TLMINn | minimum legal value in the column | stat.min TNULLn | value used to indicate undefined table element | meta.code;meta.table TOT-EXPT | total cumulative exposure time | time.expo TOT-IMAG | total number of images | meta.number;obs.image TSCALn | linear data scaling factor | arith.factor TSORTKEY | defines the sort order of a table | # TSTART | start time of observation | time.start TSTOP | end time of observation | time.end TTYPEn | column name | meta.id;meta.table.column TUNITn | column units | meta.unit;meta.table.column TYPE | scan type | meta.code;obs TYPEn | name of random groups parameter | # TZEROn | column scaling zero point | arith.zp;meta.table.column USXREF | 2MASS U-scan X coordinate at image center | # USYREF | 2MASS U-scan Y coordinate at image center | # UT | U.T. time at start | time.start UT_DATE | U.T. date of scan | time.epoch UT_EOS | U.T. at End of Scan | time.end UT_OFF1 | U.T. offset - Start Of Scan to frame 1 | arith.diff;time.start UT_SOS | U.T. at Start of Scan | time.start VEL | center velocity | src.veloc VELCODE | code for center velocity | meta.code;src.veloc VELR | reference velocity | src.veloc WAVEF_P | secondary waveform data file | meta.id;meta.file WCSAXESa | number of axes in WCS description | pos.wcs WDIR_EOS | wind direction at End of Scan | obs.air.wind WDIR_SOS | wind direction at Start of Scan | obs.air.wind WSPD_EOS | wind speed at End of Scan | obs.air.wind WSPD_SOS | wind speed at Start of Scan | obs.air.wind XPIXELSZ | x pixel size | phys.size;instr.pixel XS_OFF1 | x-scan offet - SOS to frame 1 | # XS_OFF2 | x-scan offet - SOS to end frame | # XTENSION | marks beginning of new HDU | meta.note;meta.fits.hdu YPIXELSZ | y pixel size | phys.size;instr.pixel ZD_EOS | zenith distance at End of Scan | pos.az.zd ZD_SOS | zenith distance at Start of Scan | pos.az.zd ZP | zero point calibration | arith.zp;phot.calib ZP_ERR | error in zero point | stat.error;arith.zp;phot.calib From norman at astro.gla.ac.uk Tue May 3 09:21:39 2005 From: norman at astro.gla.ac.uk (Norman Gray) Date: Tue, 3 May 2005 17:21:39 +0100 Subject: UCD name documentation In-Reply-To: <20050503164114.gxpb53ye89ygogo4@webmail.sic.rm.cnr.it> References: <1eff2d5b2ed291becf05825cb37fd8e6@astro.gla.ac.uk> <20050503164114.gxpb53ye89ygogo4@webmail.sic.rm.cnr.it> Message-ID: Andrea, On 2005 May 3 , at 15.41, Andrea Preite Martinez wrote: > If you think that the appended list (better, an updated version of it) > could be the base for such a tool, I'll do it (the tool, I mean) Thanks -- that's just the thing I was looking for. Will this appear on the UCD pages at some point? If anyone's interested, this came up on a `osxastro' list (OS X for astronomy applications). The thread is `Tiger's Spotlight & FITS files' at . All the best, Norman -- ---------------------------------------------------------------------- Norman Gray : Physics & Astronomy, Glasgow University, UK http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk From edward.j.shaya.1 at gsfc.nasa.gov Tue May 3 14:09:31 2005 From: edward.j.shaya.1 at gsfc.nasa.gov (Ed Shaya) Date: Tue, 03 May 2005 17:09:31 -0400 Subject: New UCDs for VOEvent please In-Reply-To: <71e0852515f7c6122fe60632c6efb16d@Astro.physik.Uni-Goettingen.DE> References: <32fd4a5efbfd9d3afbbae300411c0379@Astro.physik.Uni-Goettingen.DE> <426FBAC9.2050600@cacr.caltech.edu> <4272824B.7010900@gsfc.nasa.gov> <71e0852515f7c6122fe60632c6efb16d@Astro.physik.Uni-Goettingen.DE> Message-ID: <4277E88B.7030305@gsfc.nasa.gov> Fred, Actually, I've been slaving away at an ontology for several months. It is still quite broad and far from complete. But if you are interested and have the facility to examine OWL, then have a look. I am open to any and all comments.: http://archive.astro.umd.edu/ont/ (an svn archive) Ed Frederic V. "Rick" Hessman wrote: > > On 29 Apr 2005, at 8:51 pm, Ed Shaya wrote: > >> But we can also be keeping another eye on the longer time scale >> where we want to be able to put data in machine understandable terms >> so that applications can do the most possible on our behalf. This >> requires something a bit more sophisticated than just a simple class >> hierarchy of terms. An ontology would be more complete but probably >> not even an order of magnitude (factor 10) more than the UCD is >> now. In fact, given the requests and requirements to augment UCDs, >> with time, the UCD will probably grow to the size of an ontology >> anyway. So, it is probably wise to start doing some thinking in >> terms of the formal OWL standard now. What we do with the ontology >> can vary greatly. >> 1. Use it as a string identifier, exactly as UCDs are. The >> advantage is that one can read the Ontology at that point to get >> more context for the meaning of the term. >> 2. Use it as one more model builder for developing schemas. This >> is like UML but more in tune with knowledge/information structures. >> I think this is what Mathew had in mind. >> 3. Use it to test completeness and consistency of terms. This would >> not be on the fly, but rather as one adds new terms one can see >> whether it is clashing with other terms and Venn diagrams let you >> see something about completeness. This then makes it more >> acceptable for groups to be adding terms into their namespace >> without going to the VO heads or the IAU. >> 4. One can use it as the defining structure of all information being >> exchanged. Sounds daring but in fact several other related science >> fields are preparing to do just that, including space physics. >> 5. One can use it to reason out pathways to converting, pipelining, >> and analysing data. It should be possible to automatically find the >> transformation and queries needed to satisfy an arbitrary stated >> goal or request. Our group at UMD has an NASA/AISRP grant to >> figure out the basics of how this might be done using OWL. > > > Ummm.... maybe my googling didn't go quite as far or I'm missing > something: the "ontology" I found was a "low-level" (no - that sounds > too negative - let's say "very fundamental") means of describing > scientific quantities - nothing particularly "astronomical" about > it. If this is as far as anyone has gotten, then I vote for a > mid-term temporary solution - what I've called "VOThings" - which > someone else can turn into a full astronomical ontology in the > future. Thus, > > - Small, multiple, overlapping, incompatible lists within > different schemata will be an unnecessary pain, so we need a minimal > common-ground list. > > - A formal development of a real astronomical ontology will take > many years and we can't wait that long. > > - We should resist the temptation to make VOThings "complete" > since it won't ever be such and we'd waste time in trying. Maybe > having such a terrible name will be a good thing - let's get it over > quickly knowing that some day somebody else will get it right. > > Rick > > ------------------------------------------------------------------------ > ------------------------ > Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE > Universitaets-Sternwarte Tel. +49-551-39-5052 > Geismarlandstr. 11 Fax +49-551-39-5043 > 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman > ------------------------------------------------------------------------ > ------------------------- > MONET: a MOnitoring NEtwork of Telescopes > http://monet.uni-goettingen.de > ------------------------------------------------------------------------ > ------------------------- > > From Hessman at Astro.physik.Uni-Goettingen.DE Fri May 6 03:17:02 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Fri, 6 May 2005 12:17:02 +0200 Subject: [Voevent-core] Draft v0.6, VOThings & UCD usage In-Reply-To: <011EA67F-8093-408A-A5C5-AF6BC33A70A3@noao.edu> References: <427A7DAB.3010102@cacr.caltech.edu> <011EA67F-8093-408A-A5C5-AF6BC33A70A3@noao.edu> Message-ID: <4cd59db0ee26584cabeaaece611a1fcd@Astro.physik.Uni-Goettingen.DE> > - It seems to me that VOThing is unlikely to be embraced as a name. > Suggestions? Perhaps this facility should exist underneath VOEvent > itself in some fashion. Other VO projects needing access would then > simply reference us in return. Remember: I purposefully used this terrible name to emphasize the need for a VO-wide solution. How about "VOConcept"? It seems that the UCD community will also have to address the usefuless of the present UCD usage: one requires a separate parser to disentagle what "em.X-ray;phot.count;obs.image" is supposed to mean, whereas parsing something like em.X-rayphot.countobs.image would fall out of the normal processing of the XML document with no real additional effort. This is why I've been playing with UCDType and VOThingType in the experimental VOEvent schema (http://monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/ SchemaTableOfContents). This is a good chance to force our VO colleagues to think a bit more about how different VO projects can be made more compatible (at least) and more useful (we hope) in the near future. I'd like to see VOEvent's and turn into something like ("concept" <--> "VOConcept" = "VOThing") em.opt process.burst phot.flux em.opt.R supernova.Type_Ia NGC 1234 galaxies The whole point of XML, after all, is to do as much as possible in XML, othewise one can stick to old ASCII formats. > - There appears to be no purpose for the "type" attribute of the > VOEvent element. This functionality is encapsulated under the > citations. Comments on section 3.2 would be quite welcome. I think it's a bit tricky that the ultimate purpose of the document is hidden in the cite attributes in a lower-level element. Yes, we can agree what everything is supposed to mean, but you certainly can't call it elegant. And no, I don't really have a better suggestion..... > - Timestamp? I vote for subelement of Curation, not attribute of > VOEvent. Unless I get some immediate support for my suggestion, I assume we keep the original syntax. > - There is no error attribute for a VOTable Param, so there should be > none for VOEvent. I FIRMLY disagree with this. With VOTable, the syntax is designed to describe rows and columns in a table and errors are often kept in separate entries. VOEvent needs to be able to describe a measurement, and I've always told my students that a measurement without an error and some units isn't a measurement. It's artificially cumbersome to force people to use s in order to attach an error by adding another element which is identical with the partner element except for the ".error" appendix on the ucd. > - I think all elements of a packet should be optional. A completely > empty VOEvent should be acceptable, for instance, for testing. It is > not our job to try to limit usage only to sensible packets. The first > thing any subscribing client will do is to perform a reality check on > the semantics of the message *from the point of view of the needs of > the client itself*. If a client driving a robotic telescope receives > a discovery packet with no WhereWhen, it will be a simple matter to > reject it. It would, on the other hand, be a hellaciously complicated > job to try to construct a protocol/language in which no nonsense could > be spoken. (See the Sunday morning talk shows for examples.) I started to say that a packet without a is anonymous, but that's not entirely true: if the packet HAS to have a unique ivo: ID, then there's at least somebody who knows where the message came from. Is this enough? What if your system gets a message with the id "ivo://other/message12345678"? Do you assume that somebody within the IVOA was wise in letting somebody who knows what s/he's doing insert a nearly blank message claiming to have found a optical transient? > - We are relying on STC and RTML (and other stuff like UCD). How > should we mandate (or not) what versions of each standard are > acceptable for a packet conforming to VOEvent vM.n? Should we > constrain the usage to the latest stable version of each dependency at > the time of our own releases? Surely the VO must have run into this > before? When STC and RTML is inserted in the schema, one is forced to specify a particular version. As the schema is updated, the appended schemata can also be updated. A performance issue is implicit here: if extremely fast processing times are required, either your system will have to forget about formal schema-based parsing or probably should force the parser to use local copies of the schemata (e.g. updated regularly from the IVOA). > - I think How should continue to live at the top level (not underneath > Curation). It should, however, typically only correspond to a pointer > to an RMTL document or earlier VOEvent packet. (This is the > equivalent of the familiar "N more" syntax for commanding additional > exposures under a variety of data acquisition systems.) In many > cases, How will be omitted entirely. Hear! Hear! If somethings comes from Raptor or a similarly trustworthy source, for instance, we won't need to have the grimy details in the message. Good practice should dictate, however, that there really should be a useful link (a , for example) which permits one to take a look if needed. Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From pfo at star.le.ac.uk Fri May 6 03:37:07 2005 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Fri, 6 May 2005 11:37:07 +0100 (BST) Subject: [Voevent-core] Draft v0.6, VOThings & UCD usage In-Reply-To: <4cd59db0ee26584cabeaaece611a1fcd@Astro.physik.Uni-Goettingen.DE> Message-ID: Hi Frederick, On Fri, 6 May 2005, Frederic V. "Rick" Hessman wrote: > > - It seems to me that VOThing is unlikely to be embraced as a name. > > Suggestions? Perhaps this facility should exist underneath VOEvent > > itself in some fashion. Other VO projects needing access would then > > simply reference us in return. > > Remember: I purposefully used this terrible name to emphasize the need > for a VO-wide solution. How about "VOConcept"? > > It seems that the UCD community will also have to address the usefuless > of the present UCD usage: one requires a separate parser to disentagle > what "em.X-ray;phot.count;obs.image" is supposed to mean, whereas > parsing something like > > em.X-rayphot.countobs.image ucd> > > would fall out of the normal processing of the XML document with no > real additional effort. Possibly, but that makes UCDs tied to a particular representation (XML), which I don't believe should be the way to go. If UCDs are to be used widely, they should remain as independent of the "way to write them" as possible. Some people (include me) would like to use UCDs in a non XML context, and build our own tools. Furthermore, which usages do you have in mind where a piece of software would be required to "understand" the meaning of a UCD? (other than just compare with other UCDs, either completely or partially) Cheers, Patricio --- Patricio F. Ortiz pfo at star.le.ac.uk Department of Physics & Astronomy Phone: +44 (0)116 252 2015 University of Leicester Leicester, LE1 7RH, UK From Hessman at Astro.physik.Uni-Goettingen.DE Fri May 6 03:59:11 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Fri, 6 May 2005 12:59:11 +0200 Subject: [Voevent-core] Draft v0.6, VOThings & UCD usage In-Reply-To: References: Message-ID: On 6 May 2005, at 12:37 pm, Patricio F. Ortiz wrote: >>> - It seems to me that VOThing is unlikely to be embraced as a name. >>> Suggestions? Perhaps this facility should exist underneath VOEvent >>> itself in some fashion. Other VO projects needing access would then >>> simply reference us in return. >> >> Remember: I purposefully used this terrible name to emphasize the need >> for a VO-wide solution. How about "VOConcept"? >> >> It seems that the UCD community will also have to address the >> usefuless >> of the present UCD usage: one requires a separate parser to disentagle >> what "em.X-ray;phot.count;obs.image" is supposed to mean, whereas >> parsing something like >> >> em.X-rayphot.countobs.image> ucd> >> >> would fall out of the normal processing of the XML document with no >> real additional effort. > > Possibly, but that makes UCDs tied to a particular representation > (XML), > which I don't believe should be the way to go. If UCDs are to be used > widely, they should remain as independent of the "way to write them" > as possible. Some people (include me) would like to use UCDs in a non > XML context, and build our own tools. Furthermore, which usages do you > have in mind where a piece of software would be required to > "understand" > the meaning of a UCD? (other than just compare with other UCDs, either > completely or partially) I don't see any problem: in produing the UCDType (not to be confused with VOTable's "ucdType", which just says what a ucd should look like lexographically), I simply took the official list and put it in a schema enumeration so that it could be checked syntactically. This certainly doesn't preclude someone else using the list for totally different purposes. The whole point of UCD's was, at least as I understood it, that one could use an official label for a concept which a computer could then process. The UCD tags aren't for people - they're for computers. By making the UCD list available within a schema, we can make the list simpler for computers to process. Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From pfo at star.le.ac.uk Fri May 6 04:13:46 2005 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Fri, 6 May 2005 12:13:46 +0100 (BST) Subject: [Voevent-core] Draft v0.6, VOThings & UCD usage In-Reply-To: Message-ID: On Fri, 6 May 2005, Frederic V.Rick Hessman wrote: > On 6 May 2005, at 12:37 pm, Patricio F. Ortiz wrote: > > >>> - It seems to me that VOThing is unlikely to be embraced as a name. > >>> Suggestions? Perhaps this facility should exist underneath VOEvent > >>> itself in some fashion. Other VO projects needing access would then > >>> simply reference us in return. > >> > >> Remember: I purposefully used this terrible name to emphasize the need > >> for a VO-wide solution. How about "VOConcept"? > >> > >> It seems that the UCD community will also have to address the > >> usefuless > >> of the present UCD usage: one requires a separate parser to disentagle > >> what "em.X-ray;phot.count;obs.image" is supposed to mean, whereas > >> parsing something like > >> > >> em.X-rayphot.countobs.image >> ucd> > >> > >> would fall out of the normal processing of the XML document with no > >> real additional effort. > > > > Possibly, but that makes UCDs tied to a particular representation > > (XML), > > which I don't believe should be the way to go. If UCDs are to be used > > widely, they should remain as independent of the "way to write them" > > as possible. Some people (include me) would like to use UCDs in a non > > XML context, and build our own tools. Furthermore, which usages do you > > have in mind where a piece of software would be required to > > "understand" > > the meaning of a UCD? (other than just compare with other UCDs, either > > completely or partially) > > I don't see any problem: in produing the UCDType (not to be confused > with VOTable's "ucdType", which just says what a ucd should look like > lexographically), I simply took the official list and put it in a > schema enumeration so that it could be checked syntactically. This > certainly doesn't preclude someone else using the list for totally > different purposes. Perhaps, I can see it from your point of view. That means that anyone getting an XML document adopting that convention and wanting to use "total" UCDs needs to append these elements into a new element which will look like the original. Non-XML representations will remain as originally proposed, right? > The whole point of UCD's was, at least as I understood it, that one > could use an official label for a concept which a computer could then > process. The UCD tags aren't for people - they're for computers. By > making the UCD list available within a schema, we can make the list > simpler for computers to process. In an ideal world, yes, UCDs should be for computers, but in a few cases the information for a given column is so "cryptic" that a human would get more information from the UCD than from an explanation/column-name combination. Besides, I can think of cases in which users are faced with a choice between a number of "things" (to use that term :-) :-) in which the UCD will play an important role to understand what they are dealing with. Searches launched by users will not always return "precise answers", (eg, a registry query) so one of the discriminating elements may well be the UCD. > Rick Cheers, Patricio --- Patricio F. Ortiz pfo at star.le.ac.uk Department of Physics & Astronomy Phone: +44 (0)116 252 2015 University of Leicester Leicester, LE1 7RH, UK From Hessman at Astro.physik.Uni-Goettingen.DE Fri May 6 08:06:54 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Fri, 6 May 2005 17:06:54 +0200 Subject: [Voevent-core] Draft v0.6, VOThings & UCD usage In-Reply-To: References: Message-ID: <09edf63bac6eaf3722da225c046d3a4f@Astro.physik.Uni-Goettingen.DE> >>>>> - It seems to me that VOThing is unlikely to be embraced as a name. >>>>> Suggestions? Perhaps this facility should exist underneath VOEvent >>>>> itself in some fashion. Other VO projects needing access would >>>>> then >>>>> simply reference us in return. >>>> >>>> Remember: I purposefully used this terrible name to emphasize the >>>> need >>>> for a VO-wide solution. How about "VOConcept"? >>>> >>>> It seems that the UCD community will also have to address the >>>> usefuless >>>> of the present UCD usage: one requires a separate parser to >>>> disentagle >>>> what "em.X-ray;phot.count;obs.image" is supposed to mean, whereas >>>> parsing something like >>>> >>>> em.X-rayphot.countobs.image>>> ucd> >>>> >>>> would fall out of the normal processing of the XML document with no >>>> real additional effort. >>> >>> Possibly, but that makes UCDs tied to a particular representation >>> (XML), >>> which I don't believe should be the way to go. If UCDs are to be used >>> widely, they should remain as independent of the "way to write them" >>> as possible. Some people (include me) would like to use UCDs in a non >>> XML context, and build our own tools. Furthermore, which usages do >>> you >>> have in mind where a piece of software would be required to >>> "understand" >>> the meaning of a UCD? (other than just compare with other UCDs, >>> either >>> completely or partially) >> >> I don't see any problem: in produing the UCDType (not to be confused >> with VOTable's "ucdType", which just says what a ucd should look like >> lexographically), I simply took the official list and put it in a >> schema enumeration so that it could be checked syntactically. This >> certainly doesn't preclude someone else using the list for totally >> different purposes. > > Perhaps, I can see it from your point of view. That means that anyone > getting an XML document adopting that convention and wanting to use > "total" UCDs needs to append these elements into a new element which > will look like the original. I'm not sure what you mean by "total" - "original"? UCD information which gets passed via its XML representation can be turned into any format you want: e.g. em.opt.Rphot.flux... is the same as in a VOTable, and we hope the human at the end only sees "R-band optical flux of 1.234e-4 W/m^2" (or something similarly intelligent) and neither of the above computer representations! > Non-XML representations will remain as originally proposed, right? My point is that UCDs will have a life of their own as an official representation of astronomical quantities and concepts - to be used for whatever purposes people find them useful for - but that their use as a means of communication between computers and between people and computers will be much simpler if there is an official XML representation. The current model of simple string concatenation is a cumbersome one for computers given that everything else is cast in XML. Thus, the creation of an official UCD standard list should be accompanied (not replaced!) by an attempt to make the list XML-enabled. My suggestion of using concatenated elements instead of concatenated UCD content is just one obivous way to achieve this functionality. >> The whole point of UCD's was, at least as I understood it, that one >> could use an official label for a concept which a computer could then >> process. The UCD tags aren't for people - they're for computers. By >> making the UCD list available within a schema, we can make the list >> simpler for computers to process. > > In an ideal world, yes, UCDs should be for computers, but in a few > cases > the information for a given column is so "cryptic" that a human would > get > more information from the UCD than from an explanation/column-name > combination. Besides, I can think of cases in which users are faced > with > a choice between a number of "things" (to use that term :-) :-) in > which > the UCD will play an important role to understand what they are dealing > with. Searches launched by users will not always return "precise > answers", (eg, a registry query) so one of the discriminating elements > may > well be the UCD. Absolutely - the UCD can be the syntactical glue by which the human users are finally able to communicate with the external VO world. All the more reasons to invest (1) in a more useful parallel version of the UCD list (XML) and (2) in extensions to the now still VOTable-ish UCD list (a la but not necessarily exactly like VOThing). Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From jcm at head.cfa.harvard.edu Sun May 8 23:04:47 2005 From: jcm at head.cfa.harvard.edu (Jonathan McDowell) Date: Mon, 9 May 2005 02:04:47 -0400 (EDT) Subject: New UCD list Message-ID: <200505090604.j4964lFb012041@urania.cfa.harvard.edu> Dear Andrea, I've been looking at the new UCD list. I have a question, some comments and a concern. question: I assume that the suggestion I made in Aug 2004 for "phot.flux.beam" should now be handled by "phot.flux;instr.beam" using the new "instr.beam" UCD? comment: I applaud the simplification of phot.color. How are you handling this in the Vizier tables with more than one color? Adding secondary pairs of "em.*" UCDs? comment: The UCD desc for 'phot.count' still includes the comment "count (/s)" even though on Oct 19 you agreed on the feedback form that we drop the "/s". comment: I second Alberto's suggestions on homogenization of things like resolution. comment: However, On attempting to map the WCS keywords with things like arith.1_1, I think this is trying to take UCDs beyond where they should go (something I've been accused of myself!). That's what a UTYPE is for, to map it to a data model. All the components of cdmatrix are the same kind of thing and should have the same ucd. concern: On the comments page I also asked in August-Sept. 2004 for feedback on the following proposed UCDs: em.veloc.radio meta.curation phys.energy-density src.net I'm a bit disappointed that many months later a new list has emerged without none of these being addressed, even with a "well, I don't think this is sensible for a UCD". These were proposed not just for fun, but as things needed for the spectral data model document. I also still think that it would be a good idea if new UCDs were circulated for comment to the UCD WG "board" before the web page was updated, the process still seems a bit opaque and over-centralized. (by the way, the automated emails we get with "A suggestion has been made for a new UCD" would I think be much more useful if the text of the suggestion was included, removing one step in the process, since I have the impression few WG members have been responding to them). Best wishes, Jonathan McDowell From norman at astro.gla.ac.uk Mon May 9 06:45:02 2005 From: norman at astro.gla.ac.uk (Norman Gray) Date: Mon, 9 May 2005 14:45:02 +0100 Subject: New UCD list In-Reply-To: <200505090604.j4964lFb012041@urania.cfa.harvard.edu> References: <200505090604.j4964lFb012041@urania.cfa.harvard.edu> Message-ID: Greetings, On 2005 May 9 , at 07.04, Jonathan McDowell wrote: > (by the way, the automated emails we get with "A suggestion has been > made for > a new UCD" would I think be much more useful if the text of the > suggestion > was included, removing one step in the process, since I have the > impression > few WG members have been responding to them). Who is the `we', here? Is this the CDS panel for discussing new UCDs, or the list of folk on the WG, which I take to be approximately coextensive with the list of authors of the UCD1+ proposal? I understood I was still on the WG, though I don't recall any such automated emails. Norman -- ---------------------------------------------------------------------- Norman Gray : Physics & Astronomy, Glasgow University, UK http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk From andrea.preitemartinez at rm.iasf.cnr.it Mon May 9 08:06:49 2005 From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez) Date: Mon, 9 May 2005 17:06:49 +0200 Subject: New UCD list Message-ID: <20050509170649.srzz6v0z3gkgossw@webmail.sic.rm.cnr.it> Dear Jonathan, > question: I assume that the suggestion I made in Aug 2004 for "phot.flux.beam" > should now be handled by "phot.flux;instr.beam" using the new "instr.beam" > UCD? You're right, that was the idea. > comment: I applaud the simplification of phot.color. How are you handling > this in the Vizier tables with more than one color? Adding secondary pairs of > "em.*" UCDs? Yes, if U-B and V-K are present, we would simply have phot.color;em.opt.U;em.opt.B phot.color;em.opt.V;em.IR.K > comment: The UCD desc for 'phot.count' still includes the comment "count (/s)" > even though on Oct 19 you agreed on the feedback form that we drop the "/s". Thanks, this will be fixed in version 1.01 of the list. > comment: I second Alberto's suggestions on homogenization of things like > resolution. Yes, I agree. Anyone opposing the following changes ? instr.angRes -> pos.resolution (angular resolution) instr.spect.resolution -> spect.resolution (spectral resolution) > comment: However, On attempting to map the WCS keywords with things like > arith.1_1, I think this is trying to take UCDs beyond where they should > go (something I've been accused of myself!). That's what a UTYPE is for, > to map it to a data model. All the components of cdmatrix are the same > kind of thing and should have the same ucd. I also agree with you. > concern: > > On the comments page I also asked in August-Sept. 2004 for feedback on the > following proposed UCDs: > em.veloc.radio There are several things at stake with this one. You can now describe velocities with the following combinations: For radial velocities derived from a spectrum: spect.veloc -- which can be followed by a word em.* : spect.veloc;em.opt or spect.veloc;em.radio or spect.veloc;em.line.HI ... For other velocities : src.veloc (by the way, the definition is wrong in the list! It should not read "radial velocity", but simply "Velocity"). You first suggested em.veloc.radio to account for the 2 conventions to derive velocities from spectra (optical and radio conventions). If nobody ever applies the optical convention to a radio spectrum (or vice versa), then we can live with spect.veloc;em.opt and spect.veloc;em.radio What do you think? > meta.curation What about having a few specific words to describe the elements of VOResource metadata: meta.entity (or meta.identity and meta.organization) meta.version ... > phys.energy-density Yes, but spelled phys.energyDensity ? > src.net You suggested three words to distinguish total source flux, background flux, and net source flux. I don't feel comfortable with src.net, because net values should be the default... The background could be described by a qualifier, e.g. renaming instr.background to stat.background. "Total" is too general a word. Can you suggest a more specific word to describe source+background? Would this be the same as aperture photometry in the optical (i.e. total flux measured within some radius). > I also still > think that it would be a good idea if new UCDs were circulated for > comment to the UCD WG "board" before the web page was updated, the > process still seems a bit opaque and over-centralized. I think the role of the Kyoto session will also be to formalize the existence of the board. Emails like yours contribute to make the process less opaque! > (by the way, the automated emails we get with "A suggestion has been made for > a new UCD" would I think be much more useful if the text of the suggestion > was included, removing one step in the process, since I have the impression > few WG members have been responding to them). Okay, it can be done! Andrea. ============================================================================== Andrea Preite Martinez andrea at rm.iasf.cnr.it Istituto di Astrofisica Spaziale Tel.:+39.06.4993.4641 Area di Ricerca di Tor Vergata Fax.:+39.06.2066.0188 Via del Fosso del Cavaliere 100 Cell:+39.339.3817355 00133 Roma ============================================================================== From arots at head.cfa.harvard.edu Mon May 9 08:38:24 2005 From: arots at head.cfa.harvard.edu (Arnold Rots) Date: Mon, 9 May 2005 11:38:24 -0400 (EDT) Subject: New UCD list In-Reply-To: <20050509170649.srzz6v0z3gkgossw@webmail.sic.rm.cnr.it> Message-ID: <200505091538.j49FcOfq024961@xebec.cfa.harvard.edu> Andrea Preite Martinez wrote: > ... > You first suggested em.veloc.radio to account for the 2 conventions to > derive velocities from spectra (optical and radio conventions). If > nobody > ever applies the optical convention to a radio spectrum (or vice versa), > then we can live with spect.veloc;em.opt and spect.veloc;em.radio > What do you think? > O yes! The optical definition needs to be (and is) used for plenty of radio observations. Do you distinguish between LSR, geocenter, barycenter, topocenter, Galactic center (to name the most popular ones)? > ... -------------------------------------------------------------------------- Arnold H. Rots Chandra X-ray Science Center Smithsonian Astrophysical Observatory tel: +1 617 496 7701 60 Garden Street, MS 67 fax: +1 617 495 7356 Cambridge, MA 02138 arots at head.cfa.harvard.edu USA http://hea-www.harvard.edu/~arots/ -------------------------------------------------------------------------- From debray at obs-besancon.fr Mon May 9 11:40:48 2005 From: debray at obs-besancon.fr (Bernard Debray) Date: Mon, 09 May 2005 20:40:48 +0200 Subject: UCDs and optical and near-infrared bandpasses References: <20050502071545.o2qry3nmgtcgok8s@webmail.sic.rm.cnr.it> Message-ID: <427FAEB0.1040507@obs-besancon.fr> Dear UCD list members, I apologize if the subject of the remarks below has already been addressed or this turns out eventually to be outside the scope of the UCD field. This is both a remark on the UCD electromagnetic spectrum scheme and a question about the use of UCDs. I have browsed the archive of the UCD mailing list and found only one message, by Patricio Ortiz, already a long time ago (October 2003, http://www.ivoa.net/forum/ucd/0310/0067.htm) that fits this topic and looked quite sound to me. One of the claimed aims of UCDs is interoperability. Therefore, they should serve, for instance, the purpose of comparing magnitudes from different catalogues in given filters. Therefore, one should be able to identify unambiguously through which filter, photometric system, ... a magnitude is supplied in a catalogue or by a simulation tool. In the division of the electromagnetic spectrum in the UCD document, optical and near-infrared subparts of the spectrum where given names which are the ones of filters in the Johnson, ... photometric system, whereas they designate contiguous portions of the electromagnetic spectrum. While Johnson filters do fit in the subparts so defined, this is not always the case for filters from other photometric systems. For instance, the g filter of the SDSS photometric system has an effective wavelength of 482.5 nm but the flux in this band encompasses widely both the em.opt.B and em.opt.V domains. On the other hand, there seems to be,as far as I can see, no UCD which refers to the specification of a photometric system which could complement the UCD for the description of the electromagnetic spectrum subpart. Alternatively, the UCDs for specific filters such as those of SDSS' system, which could become more widespread that Johnson's in the future, could be handed over to particular namespaces. But it then still seems to me that, in order to release ambiguity in the meaning of optical and near-infrared parts of the spectrum, the corresponding UCDs should be named slightly differently, not simply U, B, V, ... Finally, if the desired achievement of identifications of data columns in the purpose of comparaison is beyond the scope of UCDs, should the cross-comparaison process be handed over to VO tools at more sophisticated levels ? Thanks in advance for your remarks and comments. Best regards, Bernard Debray Bernard Debray bernard.debray at obs-besancon.fr Observatoire de Besan?on http://www.obs-besancon.fr/ BP 1615 25010 Besan?on Cedex France Andrea Preite Martinez wrote: >Dear member of the UCD_wg, > >since last Friday (20050429) an updated list of UCD words is available at: > >http://vizier.u-strasbg.fr/UCD/ucd1p-words.txt > >at the UCD page: > >http://vizier.u-strasbg.fr/UCD/ > >The new list of words has been edited according to the very valuable >comments coming from the community and also thanks to the (almost!) every >day use of them made by Sebastien and myself. > >The most important differences with the previous version (20040823) concern > >- distances and sizes (linear/angular) >- the introduction of a rectangular/cartesian reference frame >- the phot.color section, much simplified >- spelling, abbreviations, syntax ... > > >At the UCD page you can also find un updated version of the UCD_tree >browser(s) >and a new tool, the ucd_builder: > >http://vizier.u-strasbg.fr/UCD/cgi-bin/descr2ucd > >that uses a description in "natural" language to find the relevant >ucd_words, and then tries to build a valid ucd out of them. > >In these two weeks before Kyoto please explore the list, use the tools and >send back comments. >A more "formal" comment page is available to suggest changes in the list of >words at: >http://vizier.u-strasbg.fr/UCD/cgi-bin/comment/ucdComments > >Have fun. >Andrea > > From pfo at star.le.ac.uk Mon May 9 13:29:14 2005 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Mon, 9 May 2005 21:29:14 +0100 (BST) Subject: UCDs and optical and near-infrared bandpasses In-Reply-To: <427FAEB0.1040507@obs-besancon.fr> Message-ID: Hi Andrea, Bernard, et al, I've been sitting on my hands to see if there was any reaction to the way UCDs are heading, but as I was mentioned in the last post, I feel I can free my hands and re-phrase my concerns again. I fully agree with Bernard's position, which something isn't quite right with the way UCD1+ are heading, particularly in the photometry section, which comprises and will comprise the bulk of the data in astronomy. We should ask ourselves why we want to attach a UCD to a column's metadata, and how we intend to use it. To the first question, the initial answer (pre-historic UCDs :-) was that we wanted to be able to recognize the content of any given column in as accurate a way as possible in order to compare it with others (we had datamining in mind); we wished not to mix apples, pears, oranges or lemmons, so, there would be different UCDs for apples, lemmons and oranges (to follow Roy's way of exemplifying things) :-) Now, we have reached a point in which we're lucky to have one ucd for apples and pears and one for lemmons and oranges (citrics). Perhaps we only have one UCD for fruits.which.grow.on.trees.of.more.than.two.metres.high :-) Which leads us to the second question... How do we intend to use them? Do we want to find "things" using ucds? Sure, 1- I(*) want to find all catalogues containing observations with the gunn g filter (enough of fruits, we're astronomers :-). Perhaps I'd like to compare observations done by different observers? (*) replace I by "user" or "users". 2- Another possibility is that I want to find observations in the optical blue section of the em-spectrum? Fine, I may be just interested in discovering resources rather than comparing on a very accurate level. 3- I want to discover which objects have been observed in the radio regime of the CO emission at 3.whatever mm [go back to normal use of 'I'] As far as I can see, ucd1+ allows us to answer [2] accurately and possibly completely, while [1] and [3] will give us a lot of answers with a low S/N, ie, correct answers combined with irrelevant information (to the person questioning). One of the initial ideas of UCDs (mine at least) was to tag columns accurately (including filter/photometric systems), but having "virtual UCDs", ie, UCDs which will be accessible to those querying, but never (or rarely) attached to columns. Translation tables would take care of interpreting that if I asked for "blue magnitude" I would get Johnsons' B, Stroemgrem, gunn, washington, HST, Sloan, etc, etc. However accurate querying was possible. The problem of UCD1+ is that if I want HST Blue observations I have to weed through all the other systems which were put in the same box!! Somehow I feel as if I went to a supermarket to buy AAA alkaline batteries and I'm told "Ah! batteries, they are all in this box (AAA, AA, C, D, N, etc., alkaline, zn, li, new-tech, etc.), here, help yourself" I don't think I'll go back to buy batteries there again! OK, so what can be done? I'm not just complaining here! :-) UCD1+ have already the broad classification, *I* think we need to add the fine structure, so no information is lost and needs to be re-discovered time after time For instance, S|em.opt.B should be left for a magnitude for which we have no idea how it was measured (old catalogues), while a Johnson's B should be something like S|em.opt.B:phot.jhn.B Yes, the ucd tree will grow again (or we'll have to handle this with UTYPE or some other meta-data element), but the example just given gives an accurate description of the quantity, yet can be used in fuzzy searches. Alternatively, we could have phot.jhn.B by itself as the UCD, but have something like S|em.opt.B -> (S|em.opt.B, phot.jhn.B, phot.HST.B, ....... ) That means that in the context of a query, whenever a tool finds the left term it should look for columns which contain a UCD listed in the right hand side. If no list is associated with a "virtual UCD", exact matches should be performed (which should not prevent us from searching for 'phot.HST' regarding of the filter observed! I've implemented tools like this, that's why I'm voicing this proposition. To finish, I just took a quick look at the 'em.line' section... well, absorption and emission lines exist across the spectrum: Ly-alpha, CIV (QSOs), molecular lines, (CO, H20) in Radio, FeXIV in X, etc. By not leaving room for accurate description with UCDs we are making UCDs less useful as accurate descriptors and discovery tools. I feel more threatened by a lack of accuracy in the description of a column than for a largish set of terms (which only reflects our trade). Cheers, Patricio On Mon, 9 May 2005, Bernard Debray wrote: > Dear UCD list members, > > I apologize if the subject of the remarks below has already been > addressed or this turns out eventually to be outside the scope of the > UCD field. This is both a remark on the UCD electromagnetic spectrum > scheme and a question about the use of UCDs. > > I have browsed the archive of the UCD mailing list and found only one > message, by Patricio Ortiz, already a long time ago (October 2003, > http://www.ivoa.net/forum/ucd/0310/0067.htm) that fits this topic and > looked quite sound to me. > > One of the claimed aims of UCDs is interoperability. Therefore, they > should serve, for instance, the purpose of comparing magnitudes from > different catalogues in given filters. Therefore, one should be able to > identify unambiguously through which filter, photometric system, ... a > magnitude is supplied in a catalogue or by a simulation tool. > > In the division of the electromagnetic spectrum in the UCD document, > optical and near-infrared subparts of the spectrum where given names > which are the ones of filters in the Johnson, ... photometric system, > whereas they designate contiguous portions of the electromagnetic spectrum. > > While Johnson filters do fit in the subparts so defined, this is not > always the case for filters from other photometric systems. For > instance, the g filter of the SDSS photometric system has an effective > wavelength of 482.5 nm but the flux in this band encompasses widely both > the em.opt.B and em.opt.V domains. > On the other hand, there seems to be,as far as I can see, no UCD which > refers to the specification of a photometric system which could > complement the UCD for the description of the electromagnetic spectrum > subpart. > > Alternatively, the UCDs for specific filters such as those of SDSS' > system, which could become more widespread that Johnson's in the future, > could be handed over to particular namespaces. But it then still seems > to me that, in order to release ambiguity in the meaning of optical and > near-infrared parts of the spectrum, the corresponding UCDs should be > named slightly differently, not simply U, B, V, ... > > Finally, if the desired achievement of identifications of data columns > in the purpose of comparaison is beyond the scope of UCDs, should the > cross-comparaison process be handed over to VO tools at more > sophisticated levels ? > > Thanks in advance for your remarks and comments. > > Best regards, > Bernard Debray > > Bernard Debray bernard.debray at obs-besancon.fr > Observatoire de Besan?on http://www.obs-besancon.fr/ > BP 1615 > 25010 Besan?on Cedex > France > > > Andrea Preite Martinez wrote: > > >Dear member of the UCD_wg, > > > >since last Friday (20050429) an updated list of UCD words is available at: > > > >http://vizier.u-strasbg.fr/UCD/ucd1p-words.txt > > > >at the UCD page: > > > >http://vizier.u-strasbg.fr/UCD/ > > > >The new list of words has been edited according to the very valuable > >comments coming from the community and also thanks to the (almost!) every > >day use of them made by Sebastien and myself. > > > >The most important differences with the previous version (20040823) concern > > > >- distances and sizes (linear/angular) > >- the introduction of a rectangular/cartesian reference frame > >- the phot.color section, much simplified > >- spelling, abbreviations, syntax ... > > > > > >At the UCD page you can also find un updated version of the UCD_tree > >browser(s) > >and a new tool, the ucd_builder: > > > >http://vizier.u-strasbg.fr/UCD/cgi-bin/descr2ucd > > > >that uses a description in "natural" language to find the relevant > >ucd_words, and then tries to build a valid ucd out of them. > > > >In these two weeks before Kyoto please explore the list, use the tools and > >send back comments. > >A more "formal" comment page is available to suggest changes in the list of > >words at: > >http://vizier.u-strasbg.fr/UCD/cgi-bin/comment/ucdComments > > > >Have fun. > >Andrea > > > > > > --- Patricio F. Ortiz pfo at star.le.ac.uk Department of Physics & Astronomy Phone: +44 (0)116 252 2015 University of Leicester Leicester, LE1 7RH, UK From francois at vizir.u-strasbg.fr Tue May 10 00:52:39 2005 From: francois at vizir.u-strasbg.fr (Francois Ochsenbein) Date: Tue, 10 May 2005 09:52:39 +0200 Subject: No subject Message-ID: <200505100752.j4A7qdE20199@vizir.u-strasbg.fr> Hi Patricio, et al., This question of accurate/inaccurate description was discussed many times --- and one of the results was the definition of 2 different entities : -- the UCDs which have the role of broad classification -- the "utype" was introduced to fulfil the role of the accurate description -- the "utype" being in principle connected to a data model which gives the necessary level of detail. In the photometric domain, each of the two entities has its role: -- from a ucd: 2 quantities showing the same UCD can be compared at least in a statistical way; -- from a utype: the accurate specification of each filter must be accessible; quantities can then be combined. In practice however the required level of details is frequently not fully known. There is exactly the same problem in the astrometric domain: while UCDs can be used to define the RA and Dec, an accurate definition of these values requires a lot of extra parameters -- have a look at Arnold's Space-Time model and be sure you have specified everything if you want to be accurate... In many practical cases -- e.g. for statistical cross-matching -- a full description is not required, and then the UCDs have their place. --francois ================================================================================ Francois Ochsenbein ------ Observatoire Astronomique de Strasbourg 11, rue de l'Universite F-67000 STRASBOURG Phone: +33-(0)390 24 24 29 Email: francois at astro.u-strasbg.fr (France) Fax: +33-(0)390 24 24 17 ================================================================================ From jcm at head.cfa.harvard.edu Tue May 10 05:06:07 2005 From: jcm at head.cfa.harvard.edu (Jonathan McDowell) Date: Tue, 10 May 2005 08:06:07 -0400 (EDT) Subject: How precise should UCDs be? Message-ID: <200505101206.j4AC67oh015174@urania.cfa.harvard.edu> Francois wrote: > This question of accurate/inaccurate description was discussed > many times --- and one of the results was the definition of 2 > different entities : > -- the UCDs which have the role of broad classification > -- the "utype" was introduced to fulfil the role of the accurate > description -- the "utype" being in principle connected to a > data model which gives the necessary level of detail. My own thoughts on the relation between UCD and utype/DM have evolved a little (although it comes to essentially the same answer as Francois). I believe that the UCD should have a precise and accurate definition, but that when you need metadata, or parameters, i.e. you need to refer to other UCDs, the utype/DM is needed. It's not a question of level of detail or "accurate", it's a question of "complete" - do you need more than one number of value to describe the idea? Thus, flux.photDens.sb and flux.photDens;instr.beam are different physical concepts - subtly different, and we are going to a high level of detail, but it's necessary to do so. But RA2000 and RA1950 are the same basic concept differing only by a parameter. The concept 'RA' and the concept 'equinox' are the two different concepts here: pos.eq.ra (value = 12:26:03.4) and time.equinox (value = 2000.0) and these are related to each other in the context of a coordinate frame (e.g. STC) data model. RA1950 and RA2000 are really the same physical concept simply with different metadata. pos.eq.ra is PRECISELY defined, it's just not COMPLETELY defined without tying it to the STC metadata. In contrast, you can't really say that about "surface brightness" and "flux density per beam", there's no associated metadata to distinguish them. (I guess you could use instr.scale or instr.pixel and tie it to the spatially variable beam size in the second case but I think implicitly using an algorithm to connect two concepts is cheating.) Of course for pragmatic reasons we do break this paradigm for the "phot.*;em.*" UCDs where the "em.IR" is really metadata for the "phot.*" concept. But in general I think this is a good rule of thumb for deciding whether you need a new UCD, or whether you need to relate two different UCDs via a data model. > while UCDs can be used to define the RA and Dec, an accurate > definition of these values requires a lot of extra parameters > -- have a look at Arnold's Space-Time model and be sure you > have specified everything if you want to be accurate... > In many practical cases -- e.g. for statistical cross-matching -- > a full description is not required, and then the UCDs have their > place. The key phrase here is "requires a lot of extra parameters". In some other practical cases, a full description *is* required: so you need the parameters and a data model to relate them to each other. But if the data model is very generic you still need the UCDs to describe precisely what the individual parameters are. This is of course fuzzy, since sometimes - as in parts of STC - the utype implies what the UCD must be. But sometimes the utype describes only the precise relationship between two concepts, and the UCDs describe the precise identity of the concepts - both precise, but doing different jobs. Thus you might use utypes to link a velocity and its standard of rest, but you still need to use UCDs to explain that this is the escape velocity from the star (src.veloc.escape) and not the expansion velocity of the wind (src.veloc.expansion) that you're talking about. If you look at the src.veloc tree I see three different kinds of UCD: Group 1 - different kinds of velocity src.veloc src.veloc.ang (src.veloc means radial velocity, we're missing a way to say "(norm of) 3D space velocity", I suggest src.veloc.space or src.veloc.total) Group 2 - the velocity of what? (distinguishing different physics concepts): src.veloc.dispersion src.veloc.escape src.veloc.expansion src.veloc.microTurb src.veloc.pulsat src.veloc.rotat Group 3 - shortcuts for giving parameter values of the STC frames: src.veloc.cmb src.veloc.lg src.veloc.lsr Do other people see the same distinction I'm seeing here? I suggest that instead of Group 3 we should have pos.frame.cmb, pos.frame.lg, pos.frame.lsr, pos.frame.src and allow combinations like src.veloc;pos.frame.lsr src.veloc.space;pos.frame.lsr to make more clear that the concept that's changing is the frame, not the velocity. - Jonathan From Alberto.Micol at eso.org Tue May 10 05:59:29 2005 From: Alberto.Micol at eso.org (Alberto Micol) Date: Tue, 10 May 2005 14:59:29 +0200 Subject: How precise should UCDs be? In-Reply-To: <200505101206.j4AC67oh015174@urania.cfa.harvard.edu> References: <200505101206.j4AC67oh015174@urania.cfa.harvard.edu> Message-ID: <536c867aa5ebeae2ff9af6b55dc312a5@eso.org> On May 10, 2005, at 14:06, Jonathan McDowell wrote: > > The key phrase here is "requires a lot of extra parameters". In some > other practical cases, a full description *is* required: so you need > the > parameters and a data model to relate them to each other. But if the > data model is very generic you still need the UCDs to describe > precisely > what the individual parameters are. > > This is of course fuzzy, since sometimes - as in parts of STC - the > utype implies what the UCD must be. But sometimes the utype describes > only the precise relationship between two concepts, and the UCDs > describe the precise identity of the concepts - both precise, but > doing different jobs. Thus you might use utypes to > link a velocity and its standard of rest, but you still need to > use UCDs to explain that this is the escape velocity from the > star (src.veloc.escape) and not the expansion velocity of the > wind (src.veloc.expansion) that you're talking about. > [...] > Group 2 > - the velocity of what? (distinguishing different physics concepts): > src.veloc.dispersion > src.veloc.escape > src.veloc.expansion > src.veloc.microTurb > src.veloc.pulsat > src.veloc.rotat > Devil's advocate point of view It looks to me as if you are trying to model a generic astronomical source by using UCDs. Wouldn't that be the role of a "Generic Astronomical Source Data Model" instead? That is, the UCD could be src.veloc leaving to the utype of the GAS-DM to tell which part of the source is being described. Drawing a line between UCDs and UTYPEs is something we have not achieved yet. The fact is that we have never really tried. I have never seen a VOTABLE using both UCDs and UTYPEs; until we see one and we experiment with it I fear we could philosophically talk about it for ages. We need real examples (self-criticism: hence we need some DM :-) ). In my view, precise UCDs means: a pragmatic, though incomplete, approach; an approach that is useful to fill a gap: the absence of a DM. To counter-balance such sentence I can certainly add that on the other hand, we will never have all the DMs we would need. Help! :-) Alberto From derriere at newb6.u-strasbg.fr Tue May 10 06:10:55 2005 From: derriere at newb6.u-strasbg.fr (Sebastien Derriere) Date: Tue, 10 May 2005 15:10:55 +0200 Subject: New UCD list References: <200505090604.j4964lFb012041@urania.cfa.harvard.edu> Message-ID: <4280B2DF.400C25E2@astro.u-strasbg.fr> Norman Gray wrote: > > > Who is the `we', here? Is this the CDS panel for discussing new UCDs, > or the list of folk on the WG, which I take to be approximately > coextensive with the list of authors of the UCD1+ proposal? I > understood I was still on the WG, though I don't recall any such > automated emails. Hi Norman, You are still on the WG. People who receive these emails are those who explicitly asked to receive automated notifications for additions made on the following page: http://vizier.u-strasbg.fr/UCD/cgi-bin/comment/ucdComments Currently, this means: Sebastien Derriere, Bob Mann, Anita Richards, Jonathan McDowell, Pedro Osuna, Andrea Preite-Martinez, and Nausicaa Delmotte. I can add you if you want. From now on, automated messages should include the explanation of the suggested change (previously you had to check details on the web page). Sebastien. -- _______ / ~ /, Sebastien Derriere mailto:derriere at astro.u-strasbg.fr / ~~~~ // Observatoire de Strasbourg Phone +33 (0) 390 242 444 /______// 11, rue de l'universite Telefax +33 (0) 390 242 417 (______(/ F-67000 Strasbourg France From pfo at star.le.ac.uk Tue May 10 06:16:19 2005 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Tue, 10 May 2005 14:16:19 +0100 (BST) Subject: How precise should UCDs be? In-Reply-To: <536c867aa5ebeae2ff9af6b55dc312a5@eso.org> Message-ID: On Tue, 10 May 2005, Alberto Micol wrote: > On May 10, 2005, at 14:06, Jonathan McDowell wrote: > > The key phrase here is "requires a lot of extra parameters". In some > > other practical cases, a full description *is* required: so you need > > the > > parameters and a data model to relate them to each other. But if the > > data model is very generic you still need the UCDs to describe > > precisely > > what the individual parameters are. > > > > This is of course fuzzy, since sometimes - as in parts of STC - the > > utype implies what the UCD must be. But sometimes the utype describes > > only the precise relationship between two concepts, and the UCDs > > describe the precise identity of the concepts - both precise, but > > doing different jobs. Thus you might use utypes to > > link a velocity and its standard of rest, but you still need to > > use UCDs to explain that this is the escape velocity from the > > star (src.veloc.escape) and not the expansion velocity of the > > wind (src.veloc.expansion) that you're talking about. > > [...] > > Group 2 > > - the velocity of what? (distinguishing different physics concepts): > > src.veloc.dispersion > > src.veloc.escape > > src.veloc.expansion > > src.veloc.microTurb > > src.veloc.pulsat > > src.veloc.rotat > > > > Devil's advocate point of view > > It looks to me as if you are trying to model a generic astronomical > source > by using UCDs. Wouldn't that be the role of a "Generic Astronomical > Source Data Model" > instead? > That is, the UCD could be src.veloc leaving to the utype of the GAS-DM > to tell which part of the source is being described. > > Drawing a line between UCDs and UTYPEs is something we have not > achieved yet. > > The fact is that we have never really tried. I have never seen a VOTABLE > using both UCDs and UTYPEs; until we see one and we experiment with it > I fear we could philosophically talk about it for ages. > We need real examples (self-criticism: hence we need some DM :-) ). > > In my view, precise UCDs means: a pragmatic, though incomplete, > approach; > an approach that is useful to fill a gap: the absence of a DM. > > To counter-balance such sentence I can certainly add that > on the other hand, we will never have all the DMs we would need. > > Help! > :-) > > Alberto Alberto, that's exactly my problem! I've never seen any VOT with both ucds and utype that would allow me to think how to identify quantities which are "kind of equivalent" or "equivalent enough" so the user has a short list to pick what is of his/her interest. Whether that line exists, or how it will be defined is quite important. We have already a number of people (astronomers and non-astronomers) wondering why we bother with UCDs (let alone utype!). I second your position that we need practical examples, not just philosophical discussions on how we should write this or that. In my case, the clash with reality comes when consulting a registry (or the META tables in vizier) trying to retrieve resources of a particular type. Personally if I want to get catalogues with HST blue data, I'd like to get back a list with as little overhead as possible, not five times larger, poluted by all other observations in the blue bands which fall into the same box... again, I haven't seen utype widely used yet. If I could narrow down the search using utype + ucd or utype alone, fine, we can always write a piece of software to perform this task. My complaints last night had to do with the fact that up to this point in time, using only ucd1+ our searches would bring back too much overhead. Cheers, Patricio --- Patricio F. Ortiz pfo at star.le.ac.uk Department of Physics & Astronomy Phone: +44 (0)116 252 2015 University of Leicester Leicester, LE1 7RH, UK From Markus.Dolensky at eso.org Tue May 10 06:21:08 2005 From: Markus.Dolensky at eso.org (Markus Dolensky) Date: Tue, 10 May 2005 15:21:08 +0200 Subject: How precise should UCDs be? In-Reply-To: <536c867aa5ebeae2ff9af6b55dc312a5@eso.org> References: <200505101206.j4AC67oh015174@urania.cfa.harvard.edu> <536c867aa5ebeae2ff9af6b55dc312a5@eso.org> Message-ID: <4280B544.2010503@eso.org> Alberto Micol wrote: > I have never seen a VOTABLE using both UCDs and UTYPEs; Alberto, Here you are: http://www.ivoa.net/internal/IVOA/IvoaDAL/ssample20041021.xml The lack of examples is due to the fact that the utype attribute is new to version 1.1 of VOTable, but more importantly that we are just starting to write services that produce data model compliant data (chicken & egg thing). BEWARE: Above example is obsolete as far as the used data model is concerned, but it should be a valid VOTabled doc nonetheless. - Markus From debray at obs-besancon.fr Tue May 10 11:56:43 2005 From: debray at obs-besancon.fr (Bernard Debray) Date: Tue, 10 May 2005 20:56:43 +0200 Subject: How precise should UCDs be? References: <200505101206.j4AC67oh015174@urania.cfa.harvard.edu> Message-ID: <428103EB.5030205@obs-besancon.fr> Dear all, Jonathan McDowell wrote: >Francois Ochsenbein wrote: > >>This question of accurate/inaccurate description was discussed >>many times --- and one of the results was the definition of 2 >>different entities : >>-- the UCDs which have the role of broad classification >>-- the "utype" was introduced to fulfil the role of the accurate >> description -- the "utype" being in principle connected to a >> data model which gives the necessary level of detail. >> >>In the photometric domain, each of the two entities has its role: >>-- from a ucd: 2 quantities showing the same UCD can be compared >> at least in a statistical way; >>-- from a utype: the accurate specification of each filter must be >> accessible; quantities can then be combined. >> In practice however the required level of details is frequently >> not fully known. >> >>There is exactly the same problem in the astrometric domain: >>while UCDs can be used to define the RA and Dec, an accurate >>definition of these values requires a lot of extra parameters >>-- have a look at Arnold's Space-Time model and be sure you >>have specified everything if you want to be accurate... >>In many practical cases -- e.g. for statistical cross-matching -- >>a full description is not required, and then the UCDs have their >>place. >> >>--francois > >My own thoughts on the relation between UCD and utype/DM have evolved a >little (although it comes to essentially the same answer as Francois). I >believe that the UCD should have a precise and accurate definition, but >that when you need metadata, or parameters, i.e. you need to refer to >other UCDs, the utype/DM is needed. It's not a question of level of >detail or "accurate", it's a question of "complete" - do you need >more than one number of value to describe the idea? > >... >But > RA2000 and RA1950 are the same basic concept differing only by a parameter. > The concept 'RA' and the concept 'equinox' are the two different concepts > here: > pos.eq.ra (value = 12:26:03.4) and > time.equinox (value = 2000.0) > >and these are related to each other in the context of a coordinate frame >(e.g. STC) data model. RA1950 and RA2000 are really the same physical >concept simply with different metadata. pos.eq.ra is PRECISELY defined, >it's just not COMPLETELY defined without tying it to the STC metadata. > >... > >Of course for pragmatic reasons we do break this paradigm for >the "phot.*;em.*" UCDs where the "em.IR" is really metadata for the >"phot.*" concept. But in general I think this is a good rule of thumb >for deciding whether you need a new UCD, or whether you need to >relate two different UCDs via a data model. > >>while UCDs can be used to define the RA and Dec, an accurate >>definition of these values requires a lot of extra parameters >>-- have a look at Arnold's Space-Time model and be sure you >>have specified everything if you want to be accurate... >>In many practical cases -- e.g. for statistical cross-matching -- >>a full description is not required, and then the UCDs have their >>place. >> >> >The key phrase here is "requires a lot of extra parameters". In some >other practical cases, a full description *is* required: so you need the >parameters and a data model to relate them to each other. But if the >data model is very generic you still need the UCDs to describe precisely >what the individual parameters are. > >... > - Jonathan > Yes, definitely. If I go back to my particular initial concern about photometric bandpasses, I pointed that the definition of the UCDs for electromagnetic spectrum in the document NoteEMSpectrum-2004052-3.pdf which is still referred in the last version of the UCD1+ Working Draft Document (2005-04-29) is somewhat ambiguous for the optical and near-infrared parts. For example, the note in the table for em.opt.U says "B band" which, I think, for the average astronomer is Johnson B filter bandpass. On the other hand, there is no ucd to define a photometric system. Therefore in this case, the definition is not "precise" in the sense that it can be confusing. On the other hand, I would tend to think that in order to be used in registries, UCDs should allow a more complete description than for being used in statistical cross-matching (e.g. "I need a resource which has g magnitude in the SDSS photometric system for a given part of the sky"). Does that mean this should be envisaged through data modelling as well ? Bernard Debray bernard.debray at obs-besancon.fr Observatoire de Besan?on http://www.obs-besancon.fr/ BP 1615 25010 Besan?on Cedex France From jcm at head.cfa.harvard.edu Tue May 10 15:21:37 2005 From: jcm at head.cfa.harvard.edu (Jonathan McDowell) Date: Tue, 10 May 2005 18:21:37 -0400 (EDT) Subject: New UCD list Message-ID: <200505102221.j4AMLb3d015644@urania.cfa.harvard.edu> Andrea, Just a couple of followups to your reply to me on Monday: - I agree with your spelling change: phys.energyDensity - spec.veloc; em.opt: I agree if the implication of this is agreed to be "optical method for determining velocity" rather than "velocity measured from the optical spectrum". (Following Arnold's point that yes, alas, all methods are used for all kinds of data) - meta.entity etc as "a few specific words to describe VOResource" Yes... although we should be careful to define them in a general way. I'll try and propose some specifics at Kyoto. - I'm not sure "stat.background" is quite right - to me, background is an astronomical/physical rather than statistical concept. Let me be clear about my proposal: the src.* would be secondary words, so you'd write phot.flux;em.IR;src.total I agree src.net should be the default, but maybe it's helpful for clarity in some cases. instr.background seems not right, because the background can be of cosmic rather than instrumental origin. Thanks, Jonathan From derriere at newb6.u-strasbg.fr Wed May 11 06:37:36 2005 From: derriere at newb6.u-strasbg.fr (Sebastien Derriere) Date: Wed, 11 May 2005 15:37:36 +0200 Subject: UCD simple tools Message-ID: <42820AA0.A5821669@astro.u-strasbg.fr> Hello, I just released a series of basic tools to ease manipulation of the UCD1+. They are described here, with simple CGI forms: http://cdsweb.u-strasbg.fr/UCD/tools.htx A Web Service access is also available, and documented here: http://cdsweb.u-strasbg.fr/cdsws/ucdClient.gml These tools allow: translate: convert UCD1 into default corresponding UCD1+ explain: get the description of a UCD1+ word/combination validate: check whether a UCD1+ is well-formed upgrade: convert deprecated UCD1+ to a valid expression assign: attempt to find the best UCD1+ corresponding to a plain text description They will be presented to those of you attending the meeting in Kyoto, during the UCD session! Sebastien. -- _______ / ~ /, Sebastien Derriere mailto:derriere at astro.u-strasbg.fr / ~~~~ // Observatoire de Strasbourg Phone +33 (0) 390 242 444 /______// 11, rue de l'universite Telefax +33 (0) 390 242 417 (______(/ F-67000 Strasbourg France From derriere at newb6.u-strasbg.fr Thu May 12 12:08:01 2005 From: derriere at newb6.u-strasbg.fr (Sebastien Derriere) Date: Thu, 12 May 2005 21:08:01 +0200 Subject: New UCD list References: <200505091538.j49FcOfq024961@xebec.cfa.harvard.edu> Message-ID: <4283A991.2A3EED5F@astro.u-strasbg.fr> Arnold Rots wrote: > > Andrea Preite Martinez wrote: > > ... > > You first suggested em.veloc.radio to account for the 2 conventions to > > derive velocities from spectra (optical and radio conventions). If > > nobody > > ever applies the optical convention to a radio spectrum (or vice versa), > > then we can live with spect.veloc;em.opt and spect.veloc;em.radio > > What do you think? > > > > O yes! The optical definition needs to be (and is) used for plenty of > radio observations. Hi, In order to find the relevant UCD, we need an accurate description/ explanation of the quantity we want to describe. My understanding is the following: there are 3 kinds of velocities 1. physical velocities (ratio of a distance and a time) 2. radio "velocity" representing a frequency shift 3. optical "velocity" representing a wavelength shift 2 and 3 have no physical meaning, they only correspond to a physical radial velocity for motions << c (speed of light). The difference is that (2) depends on the rest frequency, while (3) depends on the observing frequency. But (2) seems to be deprecated by the IAU. In the UCD, you have the word "src.veloc" for case (1). - Again, the description of this word should read simply "Velocity", not "Radial velocity" sorry for the confusion. There is also a word "spect.veloc" for so-called velocities derived from a spectrum. We had in mind that it could be complemented by a word indicating what kind of spectra was used, e.g : spect.veloc;em.opt -> radial "velocity" derived from optical spectrum spect.veloc;em.line.HI -> radial "velocity" derived from a shift of the HI line With your input, I understand that we should have two words, for cases (2) and (3), for example: spect.opticalVeloc and spect.radioVeloc , and we could say: "spect.opticalVeloc;em.radio" for a measurement-of-a-frequency-shift-in a-radio-spectrum-expressed-as-a-velocity-with-the-optical-convention ?! My concern with this is that if someone asks the proper UCD for a "radio velocity", the answer could be "spect.opticalVeloc;em.radio" or "spect.radioVeloc", because the description given by the user is ambiguous. > Do you distinguish between LSR, geocenter, barycenter, topocenter, > Galactic center (to name the most popular ones)? There are a few UCD words which describe some reference frames: pos.geocentric pos.heliocentric pos.galactocentric You are allowed to append them to indicate in which frame the velocity was measured: src.veloc;pos.geocentric src.veloc;pos.cartesian.y;pos.galactocentric (to indicate one component of the velocity) In 3 cases where the frame was only used for velocities, some specific words exist, as noted by Jonathan: src.veloc.cmb src.veloc.lsr src.veloc.lg Sebastien. -- _______ / ~ /, Sebastien Derriere mailto:derriere at astro.u-strasbg.fr / ~~~~ // Observatoire de Strasbourg Phone +33 (0) 390 242 444 /______// 11, rue de l'universite Telefax +33 (0) 390 242 417 (______(/ F-67000 Strasbourg France From arots at head.cfa.harvard.edu Thu May 12 12:43:14 2005 From: arots at head.cfa.harvard.edu (Arnold Rots) Date: Thu, 12 May 2005 15:43:14 -0400 (EDT) Subject: New UCD list In-Reply-To: <4283A991.2A3EED5F@astro.u-strasbg.fr> Message-ID: <200505121943.j4CJhEkY024567@xebec.cfa.harvard.edu> You may want to look the gory detail up in the STC document. I'd much rather tie "radial velocities" to redshift and, yes, they are basically just formalisms, not physical velocities; but your description is not entirely accurate. - Arnold Sebastien Derriere wrote: > Arnold Rots wrote: > > > > Andrea Preite Martinez wrote: > > > ... > > > You first suggested em.veloc.radio to account for the 2 conventions to > > > derive velocities from spectra (optical and radio conventions). If > > > nobody > > > ever applies the optical convention to a radio spectrum (or vice versa), > > > then we can live with spect.veloc;em.opt and spect.veloc;em.radio > > > What do you think? > > > > > > > O yes! The optical definition needs to be (and is) used for plenty of > > radio observations. > > Hi, > > In order to find the relevant UCD, we need an accurate description/ > explanation of the quantity we want to describe. > My understanding is the following: there are 3 kinds of velocities > 1. physical velocities (ratio of a distance and a time) > 2. radio "velocity" representing a frequency shift > 3. optical "velocity" representing a wavelength shift > > 2 and 3 have no physical meaning, they only correspond to a physical > radial > velocity for motions << c (speed of light). The difference is that (2) > depends > on the rest frequency, while (3) depends on the observing frequency. But > (2) > seems to be deprecated by the IAU. > > In the UCD, you have the word "src.veloc" for case (1). - Again, the > description of this word should read simply "Velocity", not "Radial > velocity" > sorry for the confusion. > > There is also a word "spect.veloc" for so-called velocities derived > from a spectrum. We had in mind that it could be complemented by a word > indicating what kind of spectra was used, e.g : > spect.veloc;em.opt -> radial "velocity" derived from optical > spectrum > spect.veloc;em.line.HI -> radial "velocity" derived from a shift of the > HI line > > With your input, I understand that we should have two words, for cases > (2) > and (3), for example: spect.opticalVeloc and spect.radioVeloc , and we > could > say: "spect.opticalVeloc;em.radio" for a > measurement-of-a-frequency-shift-in > a-radio-spectrum-expressed-as-a-velocity-with-the-optical-convention ?! > My concern with this is that if someone asks the proper UCD for a > "radio velocity", > the answer could be "spect.opticalVeloc;em.radio" or "spect.radioVeloc", > because > the description given by the user is ambiguous. > > > > Do you distinguish between LSR, geocenter, barycenter, topocenter, > > Galactic center (to name the most popular ones)? > > There are a few UCD words which describe some reference frames: > pos.geocentric > pos.heliocentric > pos.galactocentric > > You are allowed to append them to indicate in which frame the velocity > was measured: > src.veloc;pos.geocentric > src.veloc;pos.cartesian.y;pos.galactocentric (to indicate one > component of the velocity) > > In 3 cases where the frame was only used for velocities, some specific > words exist, as noted by Jonathan: > src.veloc.cmb > src.veloc.lsr > src.veloc.lg > > Sebastien. > -- > _______ > / ~ /, Sebastien Derriere mailto:derriere at astro.u-strasbg.fr > / ~~~~ // Observatoire de Strasbourg Phone +33 (0) 390 242 444 > /______// 11, rue de l'universite Telefax +33 (0) 390 242 417 > (______(/ F-67000 Strasbourg France > -------------------------------------------------------------------------- Arnold H. Rots Chandra X-ray Science Center Smithsonian Astrophysical Observatory tel: +1 617 496 7701 60 Garden Street, MS 67 fax: +1 617 495 7356 Cambridge, MA 02138 arots at head.cfa.harvard.edu USA http://hea-www.harvard.edu/~arots/ -------------------------------------------------------------------------- From derriere at newb6.u-strasbg.fr Fri May 13 07:32:41 2005 From: derriere at newb6.u-strasbg.fr (Sebastien Derriere) Date: Fri, 13 May 2005 16:32:41 +0200 Subject: New UCD list References: <200505121943.j4CJhEkY024567@xebec.cfa.harvard.edu> Message-ID: <4284BA89.EAC5A4EB@astro.u-strasbg.fr> Arnold Rots wrote: > > You may want to look the gory detail up in the STC document. > I'd much rather tie "radial velocities" to redshift and, yes, they are > basically just formalisms, not physical velocities; but your > description is not entirely accurate. Hi, I had looked at the FITS spectral coordinates paper, as this is what Jonathan originally referenced to in his suggestion. See http://pan-starrs.ifa.hawaii.edu/ project/IPP/wcs_paper3_20050126.pdf I read there that there are 4 different quantities: 1. apparent radial velocity 2. "radio" velocity 3. "optical" velocity 4. redshift My last mail was just to suggest that we could have 2 ucd words for quantities 2 and 3 (I suggest spect.radioVeloc and spect.opticalVeloc), instead of the single spect.veloc existing now, which is not accurate enough for some people. I don't pretend we can/need be as accurate as STC with a few UCD words - leave this to specific stc:utypes. At least we must try to describe the basic existing quantities with UCD. Sebastien. -- _______ / ~ /, Sebastien Derriere mailto:derriere at astro.u-strasbg.fr / ~~~~ // Observatoire de Strasbourg Phone +33 (0) 390 242 444 /______// 11, rue de l'universite Telefax +33 (0) 390 242 417 (______(/ F-67000 Strasbourg France From Hessman at Astro.physik.Uni-Goettingen.DE Mon May 30 04:06:23 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Mon, 30 May 2005 13:06:23 +0200 Subject: T0 : extensions to em, obs, spect, instr Message-ID: 1. I suggest we rename em from "electromagnetic spectrum" to "emission" and add em.grav-wave (gravitational wave) em.neutrino (neutrino) Alternatively, add phys.grav-wave (gravitational wave) phys.particle (particle emission) phys.particle.cosmic-ray phys.particle.neutrino ...? 2. I suggest we add UCD's for describing calibration observations. Presently, they are few mentions of calibrations at all in the official list: instr.calib (calibration parameter) phot.calib (photometric calibration) and they are sorely needed for things like VOEvent and RTML. It's trivial to say that there's a big different between calibrations (see above) and calibration observations, so new UCD's are needed and it seems the likely candidates would be: obs.calib (calibration observation) obs.calib.dome-flat (dome-flat observation) obs.calib.flux (flux calibration observation) obs.calib.freq (frequency calibration observation) obs.calib.guide-star (guide-star observation, e.g. for intial setup) obs.calib.phot (photometric calibration observation) obs.calib.pos (astrometric calibration observation obs.calib.sky-flat (sky-flat observation) obs.calib.slit-mask (slit-mask calibration observation) obs.calib.spect (spectral type calibration observation) obs.calib.veloc (radial velocity calibration observation, e.g. standard star) obs.calib.wl (wavelength calibration observation) For completeness, one should then also add phot.calib.flux (photometric flux calibration) phot.calib.mag (photometric magnitude calibration) pos.calib (astrometric calibration) spect.calib (spectroscopic calibration) spect.calib.wl (" " in wavelength) spect.calib.freq (" " in frequency) 3. Suggested addition to spect (Spectroscopy) spect.cont (spectral continuum) We already have spect.line. Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From Hessman at Astro.physik.Uni-Goettingen.DE Mon May 30 04:23:44 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Mon, 30 May 2005 13:23:44 +0200 Subject: Txx Message-ID: <84bb0f6cc51a46b0499a99dc75f16b0a@Astro.physik.Uni-Goettingen.DE> Again, because of VOEvent and RTML, I'd like to suggest we include at least event (physical or observational event) event.burst ("sudden" observed change in state) event.chirp (continuous change in frequency) event.discovery (discovery of previously unknown object) event.eclipse (intrinsic eclipse of physically related objects) event.eruption ("sudden" physical change in state resulting in more/less observed emission) event.explosion (physical explosion) event.glitch (discontinuous change in frequency) event.occulation (extrinsic occulation of physically unrelated objects) event.variation (variation in some observable property) event.variation.phot (photometric variation) event.variation.pos (astrometric shift in position) event.variation.spect (spectroscopic variation) If we're going to have solar system UCD's, then it's only fair to have stellar and extragalactic ones: I suggest looking at http://monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/ UnifiedContentDescriptors were there are unit UCD's like "stars", "ism", "galaxy" (as in milky way), "galaxies", and "cosmology". Yes, we don't have to adopt ALL of them, but it would help to have the basic ones. Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From pdidelon at cea.fr Tue May 31 06:09:03 2005 From: pdidelon at cea.fr (Pierre Didelon) Date: Tue, 31 May 2005 15:09:03 +0200 Subject: T0 : extensions to em, obs, spect, instr In-Reply-To: References: Message-ID: <429C61EF.4020300@cea.fr> Hi, Frederic V. "Rick" Hessman wrote: > 1. I suggest we rename em from "electromagnetic spectrum" to "emission" electromagnetic spectrum can concern absorption! > and add > > em.grav-wave (gravitational wave) > em.neutrino (neutrino) > > Alternatively, add > > phys.grav-wave (gravitational wave) > phys.particle (particle emission) > phys.particle.cosmic-ray > phys.particle.neutrino why not electron, proton, neutron.... UCD must define preferentially concept I suppose, isn't it? Enumerated lists must be handle with other mechanisms! Keyword (<=>UCD) and the corresponding values...Y/N? > ...? > > 2. I suggest we add UCD's for describing calibration observations. > Presently, they are > few mentions of calibrations at all in the official list: > > instr.calib (calibration parameter) > phot.calib (photometric calibration) > > and they are sorely needed for things like VOEvent and RTML. > > It's trivial to say that there's a big different between > calibrations (see above) and calibration > observations, so new UCD's are needed and it seems the likely > candidates would be: > > obs.calib (calibration observation) > obs.calib.dome-flat (dome-flat observation) > obs.calib.flux (flux calibration observation) > obs.calib.freq (frequency calibration observation) > obs.calib.guide-star (guide-star observation, e.g. for > intial setup) > obs.calib.phot (photometric calibration observation) > obs.calib.pos (astrometric calibration observation > obs.calib.sky-flat (sky-flat observation) > obs.calib.slit-mask (slit-mask calibration observation) > obs.calib.spect (spectral type calibration observation) > obs.calib.veloc (radial velocity calibration > observation, e.g. standard star) > obs.calib.wl (wavelength calibration observation) Looks like you are trying to define a data model for observation and data reduction with UCD... which is perhaps not the best way to go? > > For completeness, one should then also add > > phot.calib.flux (photometric flux calibration) > phot.calib.mag (photometric magnitude calibration) > pos.calib (astrometric calibration) > spect.calib (spectroscopic calibration) > spect.calib.wl (" " in wavelength) > spect.calib.freq (" " in frequency) > > 3. Suggested addition to spect (Spectroscopy) > > spect.cont (spectral continuum) I like it (personnaly), but why not then spect.background.... > > We already have spect.line. > > > Rick > > ------------------------------------------------------------------------ > ------------------------ > Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE > Universitaets-Sternwarte Tel. +49-551-39-5052 > Geismarlandstr. 11 Fax +49-551-39-5043 > 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman > ------------------------------------------------------------------------ > ------------------------- > MONET: a MOnitoring NEtwork of Telescopes > http://monet.uni-goettingen.de > ------------------------------------------------------------------------ > ------------------------- > -- Pierre ------------------------------------------------------------------ DIDELON :@: pdidelon_at_cea.fr Phone : 33 (0)1 69 08 58 89 CEA SACLAY - Service d'Astrophysique 91191 Gif-Sur-Yvette Cedex ------------------------------------------------------------------ Aidez les enfants Tib?tains : http://www.a-e-t.org/jcparrain.htm ou d'autres : http://www.sosesf.org/ ------------------------------------------------------------------ Seule compte la d?marche. Car c'est elle qui dure et non le but qui n'est qu'illusion du voyageur... Saint Exupery - Citadelle ------------------------------------------------------------------ From Hessman at Astro.physik.Uni-Goettingen.DE Tue May 31 08:06:22 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Tue, 31 May 2005 17:06:22 +0200 Subject: T0 : extensions to em, obs, spect, instr In-Reply-To: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> Message-ID: <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE> On 31 May 2005, at 3:09 pm, Pierre Didelon wrote: > Frederic V. "Rick" Hessman wrote: > >> 1. I suggest we rename em from "electromagnetic spectrum" to >> "emission" and add >> em.grav-wave (gravitational wave) >> em.neutrino (neutrino) > electromagnetic spectrum can concern absorption! Yes, but if you see anything at all, it's ultimately emission (even if attenuated). Admittedly, the better solution is... >> Alternatively, add >> phys.grav-wave (gravitational wave) >> phys.particle (particle emission) >> phys.particle.cosmic-ray >> phys.particle.neutrino > why not electron, proton, neutron.... If people are detecting them, why not? The whole point of em is to describe by what means we observe something, and photons are only one of many ways. I'm sure my LIGO colleagues would be happy with phys.grav-wave and my HESS/MAGIC friends phys.particle.neutrino. The present UCD isn't complete and we probably won't need phys.particle.axion for a long while, so the (other) missing entries aren't a problem, but right now there are some glaring holes..... > UCD must define preferentially concept I suppose, isn't it? > Enumerated lists must be handle with other mechanisms! > Keyword (<=>UCD) and the corresponding values...Y/N? I'm not sure what you mean.... >> ...? >> 2. I suggest we add UCD's for describing calibration observations. >> Presently, they are >> few mentions of calibrations at all in the official list: >> instr.calib (calibration parameter) >> phot.calib (photometric calibration) >> and they are sorely needed for things like VOEvent and RTML. >> It's trivial to say that there's a big different between >> calibrations (see above) and calibration >> observations, so new UCD's are needed and it seems the likely >> candidates would be: >> obs.calib (calibration observation) >> obs.calib.dome-flat (dome-flat observation) >> obs.calib.flux (flux calibration observation) >> obs.calib.freq (frequency calibration observation) >> obs.calib.guide-star (guide-star observation, e.g. for >> intial setup) >> obs.calib.phot (photometric calibration >> observation) >> obs.calib.pos (astrometric calibration observation >> obs.calib.sky-flat (sky-flat observation) >> obs.calib.slit-mask (slit-mask calibration observation) >> obs.calib.spect (spectral type calibration >> observation) >> obs.calib.veloc (radial velocity calibration >> observation, e.g. standard star) >> obs.calib.wl (wavelength calibration observation) > Looks like you are trying to define a data model for observation > and data reduction with UCD... which is perhaps not the best way to go? Absolutely NOT!!!! I just want to be able to say what something is, just like the original VOTable types who wanted to describe their catalogue entries. There's nothing fundamentally different in a VO sense between a calibration image (say, an obs.calib.phot) and a table entry of the resulting calibration (say, phot.calib). Right now, UCD is mainly (some but not me might say only) useful for tables, which is why it needs to be extended to non-table standard VO uses. A "data model for observation and data reduction" looks very different indeed, though it must ultimately use elements for which the VO has a primitive description. UCD is our VO dictionary and data/observation/reduction models are VO prose or poetry: do you want us to write a VO poem using words no one (i.e. no app) understands? >> For completeness, one should then also add >> phot.calib.flux (photometric flux calibration) >> phot.calib.mag (photometric magnitude calibration) >> pos.calib (astrometric calibration) >> spect.calib (spectroscopic calibration) >> spect.calib.wl (" " in wavelength) >> spect.calib.freq (" " in frequency) >> 3. Suggested addition to spect (Spectroscopy) >> spect.cont (spectral continuum) > I like it (personnaly), but why not then spect.background.... If it's needed, why not? Your favorite VO app should be able to know the difference between a spectral line and a spectral contiinuum and, in the real world, between the spectrum in the background (sky). Again, we have spect.line right now only because there are spectral line catalogues out there but few spectral continuum catalogues. No, I'm not trying to get a VO ontology through the back door: ontologies tell us what the intimate relations between objects are, whereas UCD simply gives us the ability to name things. We're still in the VO Neadertaler age where we've only agreed that "Ugga" means "rock". I'm worrying about how we ultimately want to transmit the knowledge of turning a rock into a spear. I hope that the problem now isn't going to be getting our colleagues to agree that we need a word for "stick".... Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ -------------------------