From roy at cacr.caltech.edu Wed Mar 24 10:45:35 2004 From: roy at cacr.caltech.edu (Roy Williams) Date: Wed, 24 Mar 2004 10:45:35 -0800 Subject: New UCD1+ for SIA protocol Message-ID: <02f401c411d0$3215b650$0c0ba8c0@cacr.caltech.edu> Dear UCD and DAL folks Three of us (Sebastian Derriere, Andrea Preite-Martinez, myself) have been working on an update for the SIA protocol that uses the standard UCD set, now called UCD1+, rather than the ad hoc namespace VOX that SIA 1.0 has been using. In the following, all UCD from the original SIA specification are listed below. The old SIA UCD is written first, then the suggested new UCD1+ is written in the line beginning "-->" The UCD1+ is not fully documented yet, but you can find a dictionary from UCD1 to UCD1+ at http://vizier.u-strasbg.fr/UCD/lists/ucd1-ucd1p.txt and http://vizier.u-strasbg.fr/UCD/lists/ucd1p-composed.txt The SIA protocol is defined at http://us-vo.org/pubs/files/ACF8DE.pdf The new SIA will be version 1.1, and we are hoping to draft and approve this at the IVOA meeting at the end of May. Thank you for your comments and suggestions on these new assignments Andrea, Roy, Sebastian -------------------------------------------------------- VOX:Image_Title --> meta.title containing a short (usually one line) description of the image. This should concisely describe the image to a user, typically identifying the image source (e.g., survey name), object name or field coordinates, bandpass/filter, and so forth. INST_ID --> meta.id;instr identifying the instrument or instruments used to make the observation, VOX:Image_MJDateObs --> time.epoch representing the mean modified Julian date of the observation. POS_EQ_RA_MAIN --> pos.eq.ra representing the ICRS right-ascension of the center of the image. POS_EQ_DEC_MAIN --> pos.eq.dec representing the ICRS declination of the center of the image. VOX:Image_Naxes --> pos.wcs.naxes specifying the number of image axes. VOX:Image_Naxis --> pos.wcs.naxis with the array value giving the length in pixels of each image axis. VOX:Image_Scale --> instr.scale with the array value giving the scale in degrees per pixel of each image axis. VOX:Image_Format --> meta.code.mime specifying the MIME-type of the object associated with the image acref, VOX:STC_CoordRefFrame --> pos.frame representing the coordinate system reference frame, selected from "ICRS", "FK5", "FK4", "ECL", "GAL", and "SGAL". VOX:STC_CoordEquinox --> time.equinox representing the Equinox (not required for ICRS) of the coordinate system VOX:WCS_CoordProjection --> pos.wcs.ctype the array value being the three-character code ("TAN", "ARC", "SIN", and so forth) specifying the celestial projection VOX:WCS_CoordRefPixel --> pos.wcs.crpix with the array value specifying the image pixel coordinates of the WCS reference pixel. This is identical to "CRPIX" in FITS WCS. VOX:WCS_CoordRefValue --> pos.wcs.crval with the array value specifying the world coordinates of the WCS reference pixel. This is identical to "CRVAL" in FITS WCS. VOX:WCS_CDMatrix --> pos.wcs.cdmatrix with the array (matrix) value specifying the WCS CD matrix. This is identical to the "CD" term in FITS WCS, and defines the scale and rotation (among other things) of the image. VOX:BandPass_ID --> instr.bandpass identifying the bandpass by name (e.g., "V", "SDSS_U", "K", "K-Band", etc.). VOX:BandPass_Unit --> meta.unit identifying the units used to represent spectral values, selected from "meters", "hertz", and "keV". VOX:BandPass_RefValue --> em.wl OR em.freq OR em.energy specifying the characteristic (reference) frequency, wavelength, or energy for the bandpass model. VOX:BandPass_HiLimit --> em.wl;stat.max OR em.freq;stat.max OR em.energy;stat.max specifying the upper limit of the bandpass. VOX:BandPass_LoLimit --> em.wl;stat.min OR em.freq;stat.min OR em.energy;stat.min specifying the lower limit of the bandpass. VOX:Image_PixFlags --> meta.code specifying the type of processing done by the image service to produce an output image pixel. VOX:Image_AccessReference --> meta.ref.url specifying the URL to be used to access or retrieve the image. VOX:Image_AccessRefTTL --> time.interval;stat.min specifying the minimum time to live in seconds of the access reference. VOX:Image_FileSize --> phys.size;meta.file representing the actual or estimated size of the encoded image in bytes (not pixels!). From womullan at skysrv.pha.jhu.edu Wed Mar 24 10:56:55 2004 From: womullan at skysrv.pha.jhu.edu (Wil O'Mullane) Date: Wed, 24 Mar 2004 13:56:55 -0500 Subject: New UCD1+ for SIA protocol In-Reply-To: <02f401c411d0$3215b650$0c0ba8c0@cacr.caltech.edu>; from roy@cacr.caltech.edu on Wed, Mar 24, 2004 at 10:45:35AM -0800 References: <02f401c411d0$3215b650$0c0ba8c0@cacr.caltech.edu> Message-ID: <20040324135655.D29227@skysrv.pha.jhu.edu> At the risk of being told this laready and having forgotten ... why do the standard ones like POS_EQ_RA_MAIN change ? I thought this was a move to reomve the VOX: not rename all ucds ... Although I like the dots more than the _.. wil this will break lots of apps which rely on thoose ucds .. On Wed, Mar 24, 2004 at 10:45:35AM -0800, Roy Williams wrote: > Dear UCD and DAL folks > > Three of us (Sebastian Derriere, Andrea Preite-Martinez, myself) have been > working on an update for the SIA protocol that uses the standard UCD set, > now called UCD1+, rather than the ad hoc namespace VOX that SIA 1.0 has been > using. > > In the following, all UCD from the original SIA specification are listed > below. The old SIA UCD is written first, then the suggested new UCD1+ is > written in the line beginning "-->" > > The UCD1+ is not fully documented yet, but you can find a dictionary from > UCD1 to UCD1+ at > http://vizier.u-strasbg.fr/UCD/lists/ucd1-ucd1p.txt > and > http://vizier.u-strasbg.fr/UCD/lists/ucd1p-composed.txt > > The SIA protocol is defined at > http://us-vo.org/pubs/files/ACF8DE.pdf > > The new SIA will be version 1.1, and we are hoping to draft and approve this > at the IVOA meeting at the end of May. > > Thank you for your comments and suggestions on these new assignments > Andrea, Roy, Sebastian > > -------------------------------------------------------- > > VOX:Image_Title > --> meta.title > containing a short (usually one line) description of the image. This should > concisely describe the image to a user, typically identifying the image > source (e.g., survey name), object name or field coordinates, > bandpass/filter, and so forth. > > INST_ID > --> meta.id;instr > identifying the instrument or instruments used to make the observation, > > VOX:Image_MJDateObs > --> time.epoch > representing the mean modified Julian date of the observation. > > POS_EQ_RA_MAIN > --> pos.eq.ra > representing the ICRS right-ascension of the center of the image. > > POS_EQ_DEC_MAIN > --> pos.eq.dec > representing the ICRS declination of the center of the image. > > VOX:Image_Naxes > --> pos.wcs.naxes > specifying the number of image axes. > > VOX:Image_Naxis > --> pos.wcs.naxis > with the array value giving the length in pixels of each image axis. > > VOX:Image_Scale > --> instr.scale > with the array value giving the scale in degrees per pixel of each image > axis. > > VOX:Image_Format > --> meta.code.mime > specifying the MIME-type of the object associated with the image acref, > > VOX:STC_CoordRefFrame > --> pos.frame > representing the coordinate system reference frame, selected from "ICRS", > "FK5", "FK4", "ECL", "GAL", and "SGAL". > > VOX:STC_CoordEquinox > --> time.equinox > representing the Equinox (not required for ICRS) of the coordinate system > > VOX:WCS_CoordProjection > --> pos.wcs.ctype > the array value being the three-character code ("TAN", "ARC", "SIN", and so > forth) specifying the celestial projection > > VOX:WCS_CoordRefPixel > --> pos.wcs.crpix > with the array value specifying the image pixel coordinates of the WCS > reference pixel. This is identical to "CRPIX" in FITS WCS. > > VOX:WCS_CoordRefValue > --> pos.wcs.crval > with the array value specifying the world coordinates of the WCS reference > pixel. This is identical to "CRVAL" in FITS WCS. > > VOX:WCS_CDMatrix > --> pos.wcs.cdmatrix > with the array (matrix) value specifying the WCS CD matrix. This is > identical to the "CD" term in FITS WCS, and defines the scale and rotation > (among other things) of the image. > > VOX:BandPass_ID > --> instr.bandpass > identifying the bandpass by name (e.g., "V", "SDSS_U", "K", "K-Band", etc.). > > VOX:BandPass_Unit > --> meta.unit > identifying the units used to represent spectral values, selected from > "meters", "hertz", and "keV". > > VOX:BandPass_RefValue > --> em.wl OR em.freq OR em.energy > specifying the characteristic (reference) frequency, wavelength, or energy > for the bandpass model. > > VOX:BandPass_HiLimit > --> em.wl;stat.max OR em.freq;stat.max OR em.energy;stat.max > specifying the upper limit of the bandpass. > > VOX:BandPass_LoLimit > --> em.wl;stat.min OR em.freq;stat.min OR em.energy;stat.min > specifying the lower limit of the bandpass. > > VOX:Image_PixFlags > --> meta.code > specifying the type of processing done by the image service to produce an > output image pixel. > > VOX:Image_AccessReference > --> meta.ref.url > specifying the URL to be used to access or retrieve the image. > > VOX:Image_AccessRefTTL > --> time.interval;stat.min > specifying the minimum time to live in seconds of the access reference. > > VOX:Image_FileSize > --> phys.size;meta.file > representing the actual or estimated size of the encoded image in bytes (not > pixels!). From arots at head.cfa.harvard.edu Wed Mar 24 11:46:14 2004 From: arots at head.cfa.harvard.edu (Arnold Rots) Date: Wed, 24 Mar 2004 14:46:14 -0500 (EST) Subject: New UCD1+ for SIA protocol In-Reply-To: <02f401c411d0$3215b650$0c0ba8c0@cacr.caltech.edu> Message-ID: <200403241946.i2OJkEu1003422@xebec.cfa.harvard.edu> SIAP 1.1: I had asked that SCORE (used to be GRADE) be included in the list of optional input and output parameters and there seemed to be agreement that it is a useful thing. Output SCORE is a floating point value that ranks returned images according to their relevance for the query as perceived by the server. This is meant to aid the client (especially the non-specialist client) in choosing from a list of images in case more than one image satisfies the query criteria. The scale is always relative and only meaningful in the context of the result in which it is provided. It may measure things like exposure time, image quality, proximity to the specified position, resolution, etc. Input SCORE is a string and may assume two values: SCORE=TOP If multiple images satisfy the query criteria, only the one with the highest value of SCORE (in output) is returned. SCORE=ALL (default) All images satisfying the query criteria are returned. This issue is important for archives of pointed observations where dozens of images may be available satisfying a single query. Expert users may want to see the metadata on all of them and choose, but less sophisticated users and more general services (the issue came up in some of our prototypes/demos as a real problem!) are more likely get annoyed and say: just get me what you think is the best one. And that's what this is about. There is no UCD that fits this, it's a context-dependent thing and, besides, it has a different datatype on input and output. But I'd appreciate its being added. - Arnold Roy Williams wrote: > Dear UCD and DAL folks > > Three of us (Sebastian Derriere, Andrea Preite-Martinez, myself) have been > working on an update for the SIA protocol that uses the standard UCD set, > now called UCD1+, rather than the ad hoc namespace VOX that SIA 1.0 has been > using. > > In the following, all UCD from the original SIA specification are listed > below. The old SIA UCD is written first, then the suggested new UCD1+ is > written in the line beginning "-->" > > The UCD1+ is not fully documented yet, but you can find a dictionary from > UCD1 to UCD1+ at > http://vizier.u-strasbg.fr/UCD/lists/ucd1-ucd1p.txt > and > http://vizier.u-strasbg.fr/UCD/lists/ucd1p-composed.txt > > The SIA protocol is defined at > http://us-vo.org/pubs/files/ACF8DE.pdf > > The new SIA will be version 1.1, and we are hoping to draft and approve this > at the IVOA meeting at the end of May. > > Thank you for your comments and suggestions on these new assignments > Andrea, Roy, Sebastian > > -------------------------------------------------------- > > VOX:Image_Title > --> meta.title > containing a short (usually one line) description of the image. This should > concisely describe the image to a user, typically identifying the image > source (e.g., survey name), object name or field coordinates, > bandpass/filter, and so forth. > > INST_ID > --> meta.id;instr > identifying the instrument or instruments used to make the observation, > > VOX:Image_MJDateObs > --> time.epoch > representing the mean modified Julian date of the observation. > > POS_EQ_RA_MAIN > --> pos.eq.ra > representing the ICRS right-ascension of the center of the image. > > POS_EQ_DEC_MAIN > --> pos.eq.dec > representing the ICRS declination of the center of the image. > > VOX:Image_Naxes > --> pos.wcs.naxes > specifying the number of image axes. > > VOX:Image_Naxis > --> pos.wcs.naxis > with the array value giving the length in pixels of each image axis. > > VOX:Image_Scale > --> instr.scale > with the array value giving the scale in degrees per pixel of each image > axis. > > VOX:Image_Format > --> meta.code.mime > specifying the MIME-type of the object associated with the image acref, > > VOX:STC_CoordRefFrame > --> pos.frame > representing the coordinate system reference frame, selected from "ICRS", > "FK5", "FK4", "ECL", "GAL", and "SGAL". > > VOX:STC_CoordEquinox > --> time.equinox > representing the Equinox (not required for ICRS) of the coordinate system > > VOX:WCS_CoordProjection > --> pos.wcs.ctype > the array value being the three-character code ("TAN", "ARC", "SIN", and so > forth) specifying the celestial projection > > VOX:WCS_CoordRefPixel > --> pos.wcs.crpix > with the array value specifying the image pixel coordinates of the WCS > reference pixel. This is identical to "CRPIX" in FITS WCS. > > VOX:WCS_CoordRefValue > --> pos.wcs.crval > with the array value specifying the world coordinates of the WCS reference > pixel. This is identical to "CRVAL" in FITS WCS. > > VOX:WCS_CDMatrix > --> pos.wcs.cdmatrix > with the array (matrix) value specifying the WCS CD matrix. This is > identical to the "CD" term in FITS WCS, and defines the scale and rotation > (among other things) of the image. > > VOX:BandPass_ID > --> instr.bandpass > identifying the bandpass by name (e.g., "V", "SDSS_U", "K", "K-Band", etc.). > > VOX:BandPass_Unit > --> meta.unit > identifying the units used to represent spectral values, selected from > "meters", "hertz", and "keV". > > VOX:BandPass_RefValue > --> em.wl OR em.freq OR em.energy > specifying the characteristic (reference) frequency, wavelength, or energy > for the bandpass model. > > VOX:BandPass_HiLimit > --> em.wl;stat.max OR em.freq;stat.max OR em.energy;stat.max > specifying the upper limit of the bandpass. > > VOX:BandPass_LoLimit > --> em.wl;stat.min OR em.freq;stat.min OR em.energy;stat.min > specifying the lower limit of the bandpass. > > VOX:Image_PixFlags > --> meta.code > specifying the type of processing done by the image service to produce an > output image pixel. > > VOX:Image_AccessReference > --> meta.ref.url > specifying the URL to be used to access or retrieve the image. > > VOX:Image_AccessRefTTL > --> time.interval;stat.min > specifying the minimum time to live in seconds of the access reference. > > VOX:Image_FileSize > --> phys.size;meta.file > representing the actual or estimated size of the encoded image in bytes (not > pixels!). > -------------------------------------------------------------------------- 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 Alberto.Micol at eso.org Wed Mar 24 12:56:11 2004 From: Alberto.Micol at eso.org (Alberto Micol) Date: Wed, 24 Mar 2004 21:56:11 +0100 Subject: New UCD1+ for SIA protocol In-Reply-To: <02f401c411d0$3215b650$0c0ba8c0@cacr.caltech.edu> References: <02f401c411d0$3215b650$0c0ba8c0@cacr.caltech.edu> Message-ID: After a first glance: I like it! Well, this is not really helping anybody out there, is it? Only two points (in the temporary absence of an established data model): > VOX:Image_Scale > --> instr.scale > with the array value giving the scale in degrees per pixel of each > image > axis. > Wouldn't it be better to have it as --> pos.wcs.scale ? This parameter has to do with the way the data are sampled, and any software could resample it (eg drizzle) onto a different grid than the original instrumental pixel scale (and think of the case where data from different instruments are mosaic'd together). In the end the instrument (instr.) has nothing to do with the pixel scale. And, anyway the pixel scale can be computed from the pos.wcs.cdmatrix... why do we need it? Probably for queries ... Unless you meant the actual resolution (Rayleigh, seeing, etc) Yet again in this case instr. is not the place to store it. Actually, where is the resolution in this scheme? Probably it was not in the SIAP, but I should read the SIAP specs again. > VOX:Image_AccessReference > --> meta.ref.url > specifying the URL to be used to access or retrieve the image. This is complex ... there could be various URLs associated to the same image, e.g., to access the full product or only a preview; but I need to read the SIAP doc again before insisting on this. Alberto From brian.thomas at gsfc.nasa.gov Wed Mar 24 13:21:17 2004 From: brian.thomas at gsfc.nasa.gov (Brian Thomas) Date: Wed, 24 Mar 2004 16:21:17 -0500 Subject: New UCD1+ for SIA protocol In-Reply-To: References: <02f401c411d0$3215b650$0c0ba8c0@cacr.caltech.edu> Message-ID: <200403241621.17502.brian.thomas@gsfc.nasa.gov> On Wednesday 24 March 2004 03:56 pm, Alberto Micol wrote: > After a first glance: I like it! Well, this is not really helping > anybody out there, is it? Well, I will try to push for this in the NOAO data model that our group is working on. =b.t. From dtody at aoc.nrao.edu Wed Mar 24 13:52:33 2004 From: dtody at aoc.nrao.edu (Doug Tody) Date: Wed, 24 Mar 2004 14:52:33 -0700 (MST) Subject: New UCD1+ for SIA protocol In-Reply-To: Message-ID: Hi Alberto - On Wed, 24 Mar 2004, Alberto Micol wrote: > Only two points (in the temporary absence of an established data model): > > > VOX:Image_Scale > > --> instr.scale > > with the array value giving the scale in degrees per pixel of each > > image > > axis. > > > > Wouldn't it be better to have it as --> pos.wcs.scale ? > This parameter has to do with the way the data are sampled, > and any software could resample it (eg drizzle) onto a different grid > than the original instrumental pixel scale (and think of the case where > data from different instruments are mosaic'd together). > In the end the instrument (instr.) has nothing to do with the pixel > scale. > > And, anyway the pixel scale can be computed from the pos.wcs.cdmatrix... > why do we need it? Probably for queries ... All we are doing here is normalizing the UCDs for SIA - for V1.1 we would prefer to minimize serious changes to the interface. Anyway, although the image scale can be computed from the CD matrix, 1) scale is a major image attribute which we prefer to have readily available to the client without having to process the WCS, 2) while the image scale is a required parameter, the WCS is merely "strongly recommended" and data providers are not required to provide it. If the WCS is missing, it can be approximated from the required image parameters, i.e., CRPIX the image center, CRVAL is POS in IRCS coordinates, the image is assumed to be nonrotated, and the CD matrix is thus defined by the naxis and scale values. > Actually, where is the resolution in this scheme? > Probably it was not in the SIAP, but I should read the SIAP specs again. SIA does not currently have the full sampling/bandpass data characterization which we have discussed elsewhere. At some point we would like to add this. V1.1 is conceivable if it comes along fast enough. > > VOX:Image_AccessReference > > --> meta.ref.url > > specifying the URL to be used to access or retrieve the image. > > This is complex ... there could be various URLs associated to > the same image, e.g., to access the full product or only a preview; > but I need to read the SIAP doc again before insisting on this. These each get a different row of the query response VOTable, hence each has a different acref URL. We have another proposal (again from Roy) to define an optional logical name which can be used to tag each row in the query result. Rows which refer to the "same image" but differ only in image format, bandpass, or whatever, would have the same logical name to indicate that they are associated. - Doug From Alberto.Micol at eso.org Wed Mar 24 14:19:34 2004 From: Alberto.Micol at eso.org (Alberto Micol) Date: Wed, 24 Mar 2004 23:19:34 +0100 Subject: New UCD1+ for SIA protocol In-Reply-To: <200403241621.17502.brian.thomas@gsfc.nasa.gov> References: <02f401c411d0$3215b650$0c0ba8c0@cacr.caltech.edu> <200403241621.17502.brian.thomas@gsfc.nasa.gov> Message-ID: <5441B66E-7DE1-11D8-A564-000A95D007D2@eso.org> Dear Doug, Yes, I completely agree with all you said, and understand the normalisation of UCDs; my only objection was on the UCD name not to be linked to the instrument (instr.scale) but to the pos.wcs. That is, I'm proposing: instr.scale to be replaced by pos.wcs.scale for all the reasons I already reported. Sorry not to have been too clear the first time. Alberto PS: I understand from Brian that also my comment ("not helping anybody out there") was misunderstood: I was in no way criticising the normalisation, which in fact I like. It looks like this is not my day, better I close here and go to bed ... From hanisch at stsci.edu Thu Mar 25 06:44:06 2004 From: hanisch at stsci.edu (Robert Hanisch) Date: Thu, 25 Mar 2004 09:44:06 -0500 Subject: New UCD1+ for SIA protocol References: Message-ID: <00cc01c41277$9ffe2e20$7deca782@stsci.edu> I just want to add my support for Alberto's objection to instr.scale -- I think this could be very confusing. The scale here is not an attribute of the instrument, but of the image. Glancing quickly through the UCD-UCD1+ mapping, however, I do not see a UCD that fits very well. Is meta.bullshit going to stay? Bob ----- Original Message ----- From: "Doug Tody" To: "Alberto Micol" Cc: "Roy Williams" ; ; Sent: Wednesday, March 24, 2004 4:52 PM Subject: Re: New UCD1+ for SIA protocol > Hi Alberto - > > On Wed, 24 Mar 2004, Alberto Micol wrote: > > Only two points (in the temporary absence of an established data model): > > > > > VOX:Image_Scale > > > --> instr.scale > > > with the array value giving the scale in degrees per pixel of each > > > image > > > axis. > > > > > > > Wouldn't it be better to have it as --> pos.wcs.scale ? > > This parameter has to do with the way the data are sampled, > > and any software could resample it (eg drizzle) onto a different grid > > than the original instrumental pixel scale (and think of the case where > > data from different instruments are mosaic'd together). > > In the end the instrument (instr.) has nothing to do with the pixel > > scale. > > > > And, anyway the pixel scale can be computed from the pos.wcs.cdmatrix... > > why do we need it? Probably for queries ... > > All we are doing here is normalizing the UCDs for SIA - for V1.1 we would > prefer to minimize serious changes to the interface. Anyway, although > the image scale can be computed from the CD matrix, 1) scale is a major > image attribute which we prefer to have readily available to the client > without having to process the WCS, 2) while the image scale is a required > parameter, the WCS is merely "strongly recommended" and data providers are > not required to provide it. If the WCS is missing, it can be approximated > from the required image parameters, i.e., CRPIX the image center, CRVAL > is POS in IRCS coordinates, the image is assumed to be nonrotated, and > the CD matrix is thus defined by the naxis and scale values. > > > Actually, where is the resolution in this scheme? > Probably it was > not in the SIAP, but I should read the SIAP specs again. > > SIA does not currently have the full sampling/bandpass data characterization > which we have discussed elsewhere. At some point we would like to add this. > V1.1 is conceivable if it comes along fast enough. > > > > VOX:Image_AccessReference > > > --> meta.ref.url > > > specifying the URL to be used to access or retrieve the image. > > > > This is complex ... there could be various URLs associated to > > the same image, e.g., to access the full product or only a preview; > > but I need to read the SIAP doc again before insisting on this. > > These each get a different row of the query response VOTable, hence each > has a different acref URL. We have another proposal (again from Roy) > to define an optional logical name which can be used to tag each row in > the query result. Rows which refer to the "same image" but differ only > in image format, bandpass, or whatever, would have the same logical name > to indicate that they are associated. > > - Doug > > From dtody at nrao.edu Thu Mar 25 07:04:09 2004 From: dtody at nrao.edu (Doug Tody) Date: Thu, 25 Mar 2004 08:04:09 -0700 (MST) Subject: New UCD1+ for SIA protocol In-Reply-To: <00cc01c41277$9ffe2e20$7deca782@stsci.edu> Message-ID: On Thu, 25 Mar 2004, Robert Hanisch wrote: > I just want to add my support for Alberto's objection to instr.scale -- I > think this could be very confusing. The scale here is not an attribute of > the instrument, but of the image. Glancing quickly through the UCD-UCD1+ > mapping, however, I do not see a UCD that fits very well. I also agree, this is the image scale not an instrument attribute. A larger point here is that in the process of normalizing the UCDS in SIA V1.1, we also plan to introduce UTYPE. The recommendation for folks writing software interfaces to interpret SIA tables will be to use UTYPE to identify the formally defined elements of the interface. This is very straightforward whereas UCD is not; we can evolve UCD independently and our interfaces will not break. Hence it is up to the UCD folks to assign the best UCDs for these fields, and if we have to adjust or generalize them later we will be able do so. In general I think UCD should be used for hard things like inference, semantic associations, smart queries, etc. UTYPE is much simpler and is what we need to identify interface elements in a straightforward manner. - Doug From amsr at jb.man.ac.uk Thu Mar 25 07:14:13 2004 From: amsr at jb.man.ac.uk (Anita Richards) Date: Thu, 25 Mar 2004 15:14:13 +0000 (GMT) Subject: New UCD1+ for SIA protocol In-Reply-To: <00cc01c41277$9ffe2e20$7deca782@stsci.edu> References: <00cc01c41277$9ffe2e20$7deca782@stsci.edu> Message-ID: Bob Hanisch wrote > I just want to add my support for Alberto's objection to instr.scale -- I > think this could be very confusing. The scale here is not an attribute of > the instrument, but of the image. Glancing quickly through the UCD-UCD1+ > mapping, however, I do not see a UCD that fits very well. Alberto (I think) wrote > > Actually, where is the resolution in this scheme? > Probably it was > not in the SIAP, but I should read the SIAP specs again. To underline these points, I think thaat there may be a tendency to think of images as products of instruments using pixel detectors, where the pixel scale of the instrument determines the resolution of the image and the sampling interval of the image. But of course that ain't necessarily so. As has been pointed out, data processing can change the image pixel size of even CCD images let alone other forms of data. The resolution is determined by the PSF, but even that means different things in different regimes. Both pixel size and resolution are variable e.g. by weighting radio data. Hence for describing images you need an image pixel size. Resolution is tricker since even in a single image that can be brightness dependent. In the Registry we would use a range but in describing images I think that the choices are 1) Just use image pixel size and assume that everyone uses something close to the convention of 3 pixels across a resolution element most of the time (but as resolution is unspecified the user will have to think about it and hence will not be misled). This is probably best for images but maybe not for catalogue data. 2) Use a 'characteristic resolution'. However, that is problematic for images as this may not be specified in the FITS header (e.g. in radio images the restoring beam size is usually in there but can be buried deep in the history). However it is often what is given in catalogues. cheers a - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Anita M. S. Richards, AVO Astronomer MERLIN/VLBI National Facility, University of Manchester, Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K. tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax). From roy at cacr.caltech.edu Thu Mar 25 07:17:04 2004 From: roy at cacr.caltech.edu (Roy Williams) Date: Thu, 25 Mar 2004 07:17:04 -0800 Subject: New UCD1+ for SIA protocol References: <00cc01c41277$9ffe2e20$7deca782@stsci.edu> Message-ID: <020801c4127c$3bf4a530$7201a8c0@Ropy> > Is meta.bullshit going to stay? Definitely. From andrea at rm.iasf.cnr.it Thu Mar 25 07:45:07 2004 From: andrea at rm.iasf.cnr.it (Andrea Preite Martinez) Date: Thu, 25 Mar 2004 16:45:07 +0100 (ora solare Europa occidentale) Subject: New UCD1+ for SIA protocol In-Reply-To: <00cc01c41277$9ffe2e20$7deca782@stsci.edu> References: <00cc01c41277$9ffe2e20$7deca782@stsci.edu> Message-ID: A comment on 1) VOX:Image_Scale --> instr.scale and 2) UCD1+:meta.bullshit (Bob's message) 1. In the list of ucd1+ that I derived, the atoms "image" and "scale" are present in instr.scale and obs.image . To me the concept of scale in this context is more important than the concept of image, then I supported "instr.scale". A much better alternative could be the definition of the new ucd1+: obs.image.scale 2. While examining all the tables and columns in Vizier I came across 2 or 3 columns whose names and descriptions were so cryptical that even going to the original papers I could not understand the nature of what the author(s) had in mind to describe. My limitation, of course. I then marked those cases with this (probably a bit offensive) tag. The file ~/ucd1-ucd1p.txt was then automatically generated from a much bigger/detailed file, and the tag slipped through. If and when we will move to ucd1+, I'll remove it. 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 hanisch at stsci.edu Thu Mar 25 07:52:09 2004 From: hanisch at stsci.edu (Robert Hanisch) Date: Thu, 25 Mar 2004 10:52:09 -0500 Subject: New UCD1+ for SIA protocol References: <00cc01c41277$9ffe2e20$7deca782@stsci.edu> Message-ID: <018101c41281$219f5db0$7deca782@stsci.edu> ----- Original Message ----- From: "Andrea Preite Martinez" To: "Robert Hanisch" Cc: "Doug Tody" ; "Alberto Micol" ; "Roy Williams" ; ; Sent: Thursday, March 25, 2004 10:45 AM Subject: Re: New UCD1+ for SIA protocol > A comment on > > 1) VOX:Image_Scale --> instr.scale > and > > 2) UCD1+:meta.bullshit (Bob's message) > > 1. In the list of ucd1+ that I derived, the atoms "image" and "scale" are > present in instr.scale and obs.image . To me the concept of scale in this > context is more important than the concept of image, then I supported > "instr.scale". > A much better alternative could be the definition of the new ucd1+: > obs.image.scale Yes, much better! > 2. While examining all the tables and columns in Vizier I came across 2 or > 3 columns whose names and descriptions were so cryptical that even going to > the original papers I could not understand the nature of what the author(s) > had in mind to describe. My limitation, of course. I then marked those > cases with this (probably a bit offensive) tag. > The file ~/ucd1-ucd1p.txt was then automatically generated from a much > bigger/detailed file, and the tag slipped through. If and when we will move > to ucd1+, I'll remove it. How about meta.unknown? Not that I am so easy to offend, mind you, but... Bob > > 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 dtody at aoc.nrao.edu Thu Mar 25 07:59:16 2004 From: dtody at aoc.nrao.edu (Doug Tody) Date: Thu, 25 Mar 2004 08:59:16 -0700 (MST) Subject: New UCD1+ for SIA protocol In-Reply-To: Message-ID: Taking this one step further: if we start inventing UCDs which are nothing more than the names of data model attributes, this may indicate that something is wrong. Perhaps what we should be doing is using UTYPE to define the data model attribute or interface element (if there is one), and UCD to say something about the quantity given as the value. For example, if the UTYPE is something like image.scale, then the UCD might define the type of physical quantity including units. Currently we try to fix the quantity/units, but there are cases where this needs to vary even though we are talking about a single data model attribute. - Doug On Thu, 25 Mar 2004, Doug Tody wrote: > On Thu, 25 Mar 2004, Robert Hanisch wrote: > > I just want to add my support for Alberto's objection to instr.scale -- I > > think this could be very confusing. The scale here is not an attribute of > > the instrument, but of the image. Glancing quickly through the UCD-UCD1+ > > mapping, however, I do not see a UCD that fits very well. > > I also agree, this is the image scale not an instrument attribute. > > A larger point here is that in the process of normalizing the UCDS in > SIA V1.1, we also plan to introduce UTYPE. The recommendation for folks > writing software interfaces to interpret SIA tables will be to use UTYPE > to identify the formally defined elements of the interface. This is very > straightforward whereas UCD is not; we can evolve UCD independently and > our interfaces will not break. Hence it is up to the UCD folks to assign > the best UCDs for these fields, and if we have to adjust or generalize them > later we will be able do so. > > In general I think UCD should be used for hard things like inference, > semantic associations, smart queries, etc. UTYPE is much simpler and is > what we need to identify interface elements in a straightforward manner. > > - Doug > > From amsr at jb.man.ac.uk Thu Mar 25 08:00:08 2004 From: amsr at jb.man.ac.uk (Anita Richards) Date: Thu, 25 Mar 2004 16:00:08 +0000 (GMT) Subject: New UCD1+ for SIA protocol In-Reply-To: References: <00cc01c41277$9ffe2e20$7deca782@stsci.edu> Message-ID: > > 1) VOX:Image_Scale --> instr.scale > > A much better alternative could be the definition of the new ucd1+: > obs.image.scale That still suggest to me that the scale is inherant to the observations - but it is better > 2) UCD1+:meta.bullshit (Bob's message) > bigger/detailed file, and the tag slipped through. If and when we will move > to ucd1+, I'll remove it. Or jsut wait until your critics stop talking bullshit? You and Roy and Sebastien have done a pretty good job if people can only find 1.5 ucd1+'s to complain about! a From jcm at head.cfa.harvard.edu Thu Mar 25 08:01:31 2004 From: jcm at head.cfa.harvard.edu (Jonathan McDowell) Date: Thu, 25 Mar 2004 11:01:31 -0500 (EST) Subject: New UCD1+ for SIA protocol Message-ID: <200403251601.i2PG1VKf007368@urania.cfa.harvard.edu> Apologies if this is already covered, I missed some emails.. My biggest problem is "pos.wcs" which generalizes poorly. Seems to me that naxis and naxes are properties of the pixels, and indeed of the image and not of pos itself. What if you have an x,y,time cube? I would argue it would be obs.image.naxes obs.image.naxis or perhaps obs.image.wcs.naxes obs.image.wcs.naxis (or array.naxes or whatever the top level thing, but not pos) but not pos.naxes = 2 time.naxes = 1 pos.naxis = 512 512 time.naxis = 30 Similarly, the other wcs.* should probably be image.wcs.* not pos.wcs.* ? I agree with others comments about instr.scale; Should be image.wcs.scale I am generally confused about what is in "wcs" and what is not: "pos.frame" not part of wcs, but "pos.wcs.naxes" is? > > meta.bullshit > meta.unknown? I think the first is a more accurate description; how about meta.badly_defined or meta.obscure :-) - Jonathan From Alberto.Micol at eso.org Thu Mar 25 08:05:00 2004 From: Alberto.Micol at eso.org (Alberto Micol) Date: Thu, 25 Mar 2004 17:05:00 +0100 Subject: New UCD1+ for SIA protocol References: <00cc01c41277$9ffe2e20$7deca782@stsci.edu> Message-ID: <4063032C.2090803@eso.org> >1. In the list of ucd1+ that I derived, the atoms "image" and "scale" are >present in instr.scale and obs.image . To me the concept of scale in this >context is more important than the concept of image, then I supported >"instr.scale". >A much better alternative could be the definition of the new ucd1+: >obs.image.scale > Sorry Andrea, But if we go for obs.image.scale then one would also think that the following should exist: obs.spectrum.scale And furthermore, personally if I see a scale at that level then I also expect: obs.image.wcs.ctype obs.image.wcs.crpix obs.image.wcs.crval obs.image.wcs.cdmatrix etc. and similarly for obs.spectrum ... Hence, I like much better the pos than the obs.image because it is more generic. So in the end I like much better: pos.wcs.ctype pos.wcs.crval pos.wcs.scale !!! etc etc because we can reuse it in many different contexts (spectra, images etc). Let's keep together all the "how is the dataset sampled?" elements under the same UCD (pos) and not let them spread under different ones. Alberto PS: Yes Anita they did a good job indeed! From pdidelon at cea.fr Thu Mar 25 08:14:00 2004 From: pdidelon at cea.fr (Pierre Didelon) Date: Thu, 25 Mar 2004 17:14:00 +0100 Subject: New UCD1+ for SIA protocol In-Reply-To: <018101c41281$219f5db0$7deca782@stsci.edu> References: <00cc01c41277$9ffe2e20$7deca782@stsci.edu> <018101c41281$219f5db0$7deca782@stsci.edu> Message-ID: <40630548.2030906@cea.fr> Robert Hanisch wrote: > ----- Original Message ----- > From: "Andrea Preite Martinez" > To: "Robert Hanisch" > Cc: "Doug Tody" ; "Alberto Micol" > ; "Roy Williams" ; > ; > Sent: Thursday, March 25, 2004 10:45 AM > Subject: Re: New UCD1+ for SIA protocol > > > >>A comment on >> >>1) VOX:Image_Scale --> instr.scale >>and >> >>2) UCD1+:meta.bullshit (Bob's message) >> >>1. In the list of ucd1+ that I derived, the atoms "image" and "scale" are >>present in instr.scale and obs.image . To me the concept of scale in this >>context is more important than the concept of image, then I supported >>"instr.scale". >>A much better alternative could be the definition of the new ucd1+: >>obs.image.scale > > > Yes, much better! > Does images always be related tightly to observation? what about an image loosely related to observation, obtained, as already stressed, by drizzle or anyother image processing task, or even "images" obtained by simulation and so no much link with obs.? But this is may be a too DM oriented view. -- Pierre -------------------------------------------------------------------------- DIDELON :@: pdidelon_at_cea.fr Phone : 33 (0)1 69 08 58 89 CEA SACLAY - Service d'Astrophysique 91191 Gif-Sur-Yvette Cedex -------------------------------------------------------------------------- From dtody at aoc.nrao.edu Thu Mar 25 09:45:20 2004 From: dtody at aoc.nrao.edu (Doug Tody) Date: Thu, 25 Mar 2004 10:45:20 -0700 (MST) Subject: New UCD1+ for SIA protocol In-Reply-To: Message-ID: On Thu, 25 Mar 2004, Anita Richards wrote: > > 1) VOX:Image_Scale --> instr.scale > > > > A much better alternative could be the definition of the new ucd1+: > > obs.image.scale > > That still suggest to me that the scale is inherant to the observations - > but it is better This is a general issue with what we are calling the "observation" data model. This may be just a naming issue but I worry that we may try to describe actual observations. What we really need to do for VO is characterize the physical attributes of a dataset. A dataset may be a calibrated observation, or it may be the result of an arbitrary amount of processing of multiple observations, or it may be synthetic data. It does not matter how the dataset was generated if we describe only the physical attributes of the actual final dataset we are dealing with. Scale and resolution are good examples of such physical attributes. For VO data analysis where we may need to deal uniformly with data from many origins, physical dataset characterization is what is needed. At this level we should not have any information about the actual observations, instrument characteristics, etc., (if any) used to produce the dataset. Such information may be present in each individual dataset, and can be useful to fully understand individual datasets, but is not very useful for automated processing of data from many origins. A simple example is exposure time. While a typical attribute of an individual original observation, it tells us almost nothing about an arbitrary dataset. To understand what this means we would have to understand the full instrumental model and configuration, and all the post-processing done to get to the final dataset we are actually looking at. The related physical dataset attributes are the sampling and coverage in time of the final (possibly aggregate) dataset, and some physical measure of the limiting flux of a signal detected by the dataset. From pfo at star.le.ac.uk Thu Mar 25 10:22:20 2004 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Thu, 25 Mar 2004 18:22:20 +0000 (GMT) Subject: New UCD1+ for SIA protocol In-Reply-To: Message-ID: Doug, I fully agree with you, I think you hit the nail, it is the dataset that the user gets what needs proper description, regardless of what's been done to reach this result. A dataset has an angular scale ("/pix) or a linear scale (km/pix, eg, solar or planetary images), the dataset's origin may be real observations or simulations, simple observations (classical CCD image), mosaics, images based on radio data, multiwavelength composites, whatever. Scales can be degraded or modified from the initial products (eg, DSS) As you said, something similar happens when describing the time coverage. Quantities which make sense to individual observations don't necessariry apply to final products (datasets), for instance, exposure_time != end_of_exposure - start_of_exposure in a dataset which does not represent an individual observation. Color composite images are another example of a final product where the individual observations' parameters may vary considerably, talking about instrument.scale or obs.scale does not seem appropriate anymore. At the time of the construction of UCD0 it did make sense to group these items (read drop these items) in the "instrumental" category. That doesn't apply any longer. Cheers, Patricio On Thu, 25 Mar 2004, Doug Tody wrote: > On Thu, 25 Mar 2004, Anita Richards wrote: > > > > 1) VOX:Image_Scale --> instr.scale > > > > > > A much better alternative could be the definition of the new ucd1+: > > > obs.image.scale > > > > That still suggest to me that the scale is inherant to the observations - > > but it is better > > This is a general issue with what we are calling the "observation" > data model. This may be just a naming issue but I worry that we may try > to describe actual observations. > > What we really need to do for VO is characterize the physical attributes > of a dataset. A dataset may be a calibrated observation, or it may be > the result of an arbitrary amount of processing of multiple observations, > or it may be synthetic data. It does not matter how the dataset was > generated if we describe only the physical attributes of the actual final > dataset we are dealing with. Scale and resolution are good examples of > such physical attributes. > > For VO data analysis where we may need to deal uniformly with data from > many origins, physical dataset characterization is what is needed. At this > level we should not have any information about the actual observations, > instrument characteristics, etc., (if any) used to produce the dataset. > Such information may be present in each individual dataset, and can be > useful to fully understand individual datasets, but is not very useful > for automated processing of data from many origins. > > A simple example is exposure time. While a typical attribute of an > individual original observation, it tells us almost nothing about an > arbitrary dataset. To understand what this means we would have to > understand the full instrumental model and configuration, and all the > post-processing done to get to the final dataset we are actually looking at. > The related physical dataset attributes are the sampling and coverage in > time of the final (possibly aggregate) dataset, and some physical measure > of the limiting flux of a signal detected by the dataset. --- Patricio F. Ortiz pfo at star.le.ac.uk AstroGrid project Department of Physics and Astronomy University of Leicester Tel: +44 (0)116 252 2015 LE1 7RH, UK From derriere at newb6.u-strasbg.fr Fri Mar 26 09:50:50 2004 From: derriere at newb6.u-strasbg.fr (Sebastien Derriere) Date: Fri, 26 Mar 2004 18:50:50 +0100 Subject: New UCD1+ for SIA protocol References: <200403241946.i2OJkEu1003422@xebec.cfa.harvard.edu> Message-ID: <40646D7A.9EE207DD@astro.u-strasbg.fr> Arnold Rots wrote: > > SIAP 1.1: > > I had asked that SCORE (used to be GRADE) be included in the list of > optional input and output parameters and there seemed to be agreement > that it is a useful thing. Hello Arnold, If this SCORE is added to the parameters, there is one UCD that could be used: meta.code.qual is a quality/precision/reliability index or flag. 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 Fri Mar 26 12:35:11 2004 From: arots at head.cfa.harvard.edu (Arnold Rots) Date: Fri, 26 Mar 2004 15:35:11 -0500 (EST) Subject: New UCD1+ for SIA protocol In-Reply-To: <40646D7A.9EE207DD@astro.u-strasbg.fr> Message-ID: <200403262035.i2QKZCM4000824@xebec.cfa.harvard.edu> Sebastien, Yes, I had noticed that one but thought that maybe it should be preserved for a more formal and precise quality or, more specifically, the quality of the data. For instance, when you have two exposures, one of 1000 s and one of 100000 s, the score of the latter may be higher, even though the quality of the data in the former may be better. What it amounts to is that score and quality are notr quite the same concept. Data quality is a component but not the only thing that goes into a score. - Arnold Sebastien Derriere wrote: > Arnold Rots wrote: > > > > SIAP 1.1: > > > > I had asked that SCORE (used to be GRADE) be included in the list of > > optional input and output parameters and there seemed to be agreement > > that it is a useful thing. > > Hello Arnold, > > If this SCORE is added to the parameters, there is one UCD that > could be used: meta.code.qual is a quality/precision/reliability > index or flag. > > 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 roy at cacr.caltech.edu Wed Mar 24 10:45:35 2004 From: roy at cacr.caltech.edu (Roy Williams) Date: Wed, 24 Mar 2004 10:45:35 -0800 Subject: New UCD1+ for SIA protocol Message-ID: <02f401c411d0$3215b650$0c0ba8c0@cacr.caltech.edu> Dear UCD and DAL folks Three of us (Sebastian Derriere, Andrea Preite-Martinez, myself) have been working on an update for the SIA protocol that uses the standard UCD set, now called UCD1+, rather than the ad hoc namespace VOX that SIA 1.0 has been using. In the following, all UCD from the original SIA specification are listed below. The old SIA UCD is written first, then the suggested new UCD1+ is written in the line beginning "-->" The UCD1+ is not fully documented yet, but you can find a dictionary from UCD1 to UCD1+ at http://vizier.u-strasbg.fr/UCD/lists/ucd1-ucd1p.txt and http://vizier.u-strasbg.fr/UCD/lists/ucd1p-composed.txt The SIA protocol is defined at http://us-vo.org/pubs/files/ACF8DE.pdf The new SIA will be version 1.1, and we are hoping to draft and approve this at the IVOA meeting at the end of May. Thank you for your comments and suggestions on these new assignments Andrea, Roy, Sebastian -------------------------------------------------------- VOX:Image_Title --> meta.title containing a short (usually one line) description of the image. This should concisely describe the image to a user, typically identifying the image source (e.g., survey name), object name or field coordinates, bandpass/filter, and so forth. INST_ID --> meta.id;instr identifying the instrument or instruments used to make the observation, VOX:Image_MJDateObs --> time.epoch representing the mean modified Julian date of the observation. POS_EQ_RA_MAIN --> pos.eq.ra representing the ICRS right-ascension of the center of the image. POS_EQ_DEC_MAIN --> pos.eq.dec representing the ICRS declination of the center of the image. VOX:Image_Naxes --> pos.wcs.naxes specifying the number of image axes. VOX:Image_Naxis --> pos.wcs.naxis with the array value giving the length in pixels of each image axis. VOX:Image_Scale --> instr.scale with the array value giving the scale in degrees per pixel of each image axis. VOX:Image_Format --> meta.code.mime specifying the MIME-type of the object associated with the image acref, VOX:STC_CoordRefFrame --> pos.frame representing the coordinate system reference frame, selected from "ICRS", "FK5", "FK4", "ECL", "GAL", and "SGAL". VOX:STC_CoordEquinox --> time.equinox representing the Equinox (not required for ICRS) of the coordinate system VOX:WCS_CoordProjection --> pos.wcs.ctype the array value being the three-character code ("TAN", "ARC", "SIN", and so forth) specifying the celestial projection VOX:WCS_CoordRefPixel --> pos.wcs.crpix with the array value specifying the image pixel coordinates of the WCS reference pixel. This is identical to "CRPIX" in FITS WCS. VOX:WCS_CoordRefValue --> pos.wcs.crval with the array value specifying the world coordinates of the WCS reference pixel. This is identical to "CRVAL" in FITS WCS. VOX:WCS_CDMatrix --> pos.wcs.cdmatrix with the array (matrix) value specifying the WCS CD matrix. This is identical to the "CD" term in FITS WCS, and defines the scale and rotation (among other things) of the image. VOX:BandPass_ID --> instr.bandpass identifying the bandpass by name (e.g., "V", "SDSS_U", "K", "K-Band", etc.). VOX:BandPass_Unit --> meta.unit identifying the units used to represent spectral values, selected from "meters", "hertz", and "keV". VOX:BandPass_RefValue --> em.wl OR em.freq OR em.energy specifying the characteristic (reference) frequency, wavelength, or energy for the bandpass model. VOX:BandPass_HiLimit --> em.wl;stat.max OR em.freq;stat.max OR em.energy;stat.max specifying the upper limit of the bandpass. VOX:BandPass_LoLimit --> em.wl;stat.min OR em.freq;stat.min OR em.energy;stat.min specifying the lower limit of the bandpass. VOX:Image_PixFlags --> meta.code specifying the type of processing done by the image service to produce an output image pixel. VOX:Image_AccessReference --> meta.ref.url specifying the URL to be used to access or retrieve the image. VOX:Image_AccessRefTTL --> time.interval;stat.min specifying the minimum time to live in seconds of the access reference. VOX:Image_FileSize --> phys.size;meta.file representing the actual or estimated size of the encoded image in bytes (not pixels!). From womullan at skysrv.pha.jhu.edu Wed Mar 24 10:56:55 2004 From: womullan at skysrv.pha.jhu.edu (Wil O'Mullane) Date: Wed, 24 Mar 2004 13:56:55 -0500 Subject: New UCD1+ for SIA protocol In-Reply-To: <02f401c411d0$3215b650$0c0ba8c0@cacr.caltech.edu>; from roy@cacr.caltech.edu on Wed, Mar 24, 2004 at 10:45:35AM -0800 References: <02f401c411d0$3215b650$0c0ba8c0@cacr.caltech.edu> Message-ID: <20040324135655.D29227@skysrv.pha.jhu.edu> At the risk of being told this laready and having forgotten ... why do the standard ones like POS_EQ_RA_MAIN change ? I thought this was a move to reomve the VOX: not rename all ucds ... Although I like the dots more than the _.. wil this will break lots of apps which rely on thoose ucds .. On Wed, Mar 24, 2004 at 10:45:35AM -0800, Roy Williams wrote: > Dear UCD and DAL folks > > Three of us (Sebastian Derriere, Andrea Preite-Martinez, myself) have been > working on an update for the SIA protocol that uses the standard UCD set, > now called UCD1+, rather than the ad hoc namespace VOX that SIA 1.0 has been > using. > > In the following, all UCD from the original SIA specification are listed > below. The old SIA UCD is written first, then the suggested new UCD1+ is > written in the line beginning "-->" > > The UCD1+ is not fully documented yet, but you can find a dictionary from > UCD1 to UCD1+ at > http://vizier.u-strasbg.fr/UCD/lists/ucd1-ucd1p.txt > and > http://vizier.u-strasbg.fr/UCD/lists/ucd1p-composed.txt > > The SIA protocol is defined at > http://us-vo.org/pubs/files/ACF8DE.pdf > > The new SIA will be version 1.1, and we are hoping to draft and approve this > at the IVOA meeting at the end of May. > > Thank you for your comments and suggestions on these new assignments > Andrea, Roy, Sebastian > > -------------------------------------------------------- > > VOX:Image_Title > --> meta.title > containing a short (usually one line) description of the image. This should > concisely describe the image to a user, typically identifying the image > source (e.g., survey name), object name or field coordinates, > bandpass/filter, and so forth. > > INST_ID > --> meta.id;instr > identifying the instrument or instruments used to make the observation, > > VOX:Image_MJDateObs > --> time.epoch > representing the mean modified Julian date of the observation. > > POS_EQ_RA_MAIN > --> pos.eq.ra > representing the ICRS right-ascension of the center of the image. > > POS_EQ_DEC_MAIN > --> pos.eq.dec > representing the ICRS declination of the center of the image. > > VOX:Image_Naxes > --> pos.wcs.naxes > specifying the number of image axes. > > VOX:Image_Naxis > --> pos.wcs.naxis > with the array value giving the length in pixels of each image axis. > > VOX:Image_Scale > --> instr.scale > with the array value giving the scale in degrees per pixel of each image > axis. > > VOX:Image_Format > --> meta.code.mime > specifying the MIME-type of the object associated with the image acref, > > VOX:STC_CoordRefFrame > --> pos.frame > representing the coordinate system reference frame, selected from "ICRS", > "FK5", "FK4", "ECL", "GAL", and "SGAL". > > VOX:STC_CoordEquinox > --> time.equinox > representing the Equinox (not required for ICRS) of the coordinate system > > VOX:WCS_CoordProjection > --> pos.wcs.ctype > the array value being the three-character code ("TAN", "ARC", "SIN", and so > forth) specifying the celestial projection > > VOX:WCS_CoordRefPixel > --> pos.wcs.crpix > with the array value specifying the image pixel coordinates of the WCS > reference pixel. This is identical to "CRPIX" in FITS WCS. > > VOX:WCS_CoordRefValue > --> pos.wcs.crval > with the array value specifying the world coordinates of the WCS reference > pixel. This is identical to "CRVAL" in FITS WCS. > > VOX:WCS_CDMatrix > --> pos.wcs.cdmatrix > with the array (matrix) value specifying the WCS CD matrix. This is > identical to the "CD" term in FITS WCS, and defines the scale and rotation > (among other things) of the image. > > VOX:BandPass_ID > --> instr.bandpass > identifying the bandpass by name (e.g., "V", "SDSS_U", "K", "K-Band", etc.). > > VOX:BandPass_Unit > --> meta.unit > identifying the units used to represent spectral values, selected from > "meters", "hertz", and "keV". > > VOX:BandPass_RefValue > --> em.wl OR em.freq OR em.energy > specifying the characteristic (reference) frequency, wavelength, or energy > for the bandpass model. > > VOX:BandPass_HiLimit > --> em.wl;stat.max OR em.freq;stat.max OR em.energy;stat.max > specifying the upper limit of the bandpass. > > VOX:BandPass_LoLimit > --> em.wl;stat.min OR em.freq;stat.min OR em.energy;stat.min > specifying the lower limit of the bandpass. > > VOX:Image_PixFlags > --> meta.code > specifying the type of processing done by the image service to produce an > output image pixel. > > VOX:Image_AccessReference > --> meta.ref.url > specifying the URL to be used to access or retrieve the image. > > VOX:Image_AccessRefTTL > --> time.interval;stat.min > specifying the minimum time to live in seconds of the access reference. > > VOX:Image_FileSize > --> phys.size;meta.file > representing the actual or estimated size of the encoded image in bytes (not > pixels!). From arots at head.cfa.harvard.edu Wed Mar 24 11:46:14 2004 From: arots at head.cfa.harvard.edu (Arnold Rots) Date: Wed, 24 Mar 2004 14:46:14 -0500 (EST) Subject: New UCD1+ for SIA protocol In-Reply-To: <02f401c411d0$3215b650$0c0ba8c0@cacr.caltech.edu> Message-ID: <200403241946.i2OJkEu1003422@xebec.cfa.harvard.edu> SIAP 1.1: I had asked that SCORE (used to be GRADE) be included in the list of optional input and output parameters and there seemed to be agreement that it is a useful thing. Output SCORE is a floating point value that ranks returned images according to their relevance for the query as perceived by the server. This is meant to aid the client (especially the non-specialist client) in choosing from a list of images in case more than one image satisfies the query criteria. The scale is always relative and only meaningful in the context of the result in which it is provided. It may measure things like exposure time, image quality, proximity to the specified position, resolution, etc. Input SCORE is a string and may assume two values: SCORE=TOP If multiple images satisfy the query criteria, only the one with the highest value of SCORE (in output) is returned. SCORE=ALL (default) All images satisfying the query criteria are returned. This issue is important for archives of pointed observations where dozens of images may be available satisfying a single query. Expert users may want to see the metadata on all of them and choose, but less sophisticated users and more general services (the issue came up in some of our prototypes/demos as a real problem!) are more likely get annoyed and say: just get me what you think is the best one. And that's what this is about. There is no UCD that fits this, it's a context-dependent thing and, besides, it has a different datatype on input and output. But I'd appreciate its being added. - Arnold Roy Williams wrote: > Dear UCD and DAL folks > > Three of us (Sebastian Derriere, Andrea Preite-Martinez, myself) have been > working on an update for the SIA protocol that uses the standard UCD set, > now called UCD1+, rather than the ad hoc namespace VOX that SIA 1.0 has been > using. > > In the following, all UCD from the original SIA specification are listed > below. The old SIA UCD is written first, then the suggested new UCD1+ is > written in the line beginning "-->" > > The UCD1+ is not fully documented yet, but you can find a dictionary from > UCD1 to UCD1+ at > http://vizier.u-strasbg.fr/UCD/lists/ucd1-ucd1p.txt > and > http://vizier.u-strasbg.fr/UCD/lists/ucd1p-composed.txt > > The SIA protocol is defined at > http://us-vo.org/pubs/files/ACF8DE.pdf > > The new SIA will be version 1.1, and we are hoping to draft and approve this > at the IVOA meeting at the end of May. > > Thank you for your comments and suggestions on these new assignments > Andrea, Roy, Sebastian > > -------------------------------------------------------- > > VOX:Image_Title > --> meta.title > containing a short (usually one line) description of the image. This should > concisely describe the image to a user, typically identifying the image > source (e.g., survey name), object name or field coordinates, > bandpass/filter, and so forth. > > INST_ID > --> meta.id;instr > identifying the instrument or instruments used to make the observation, > > VOX:Image_MJDateObs > --> time.epoch > representing the mean modified Julian date of the observation. > > POS_EQ_RA_MAIN > --> pos.eq.ra > representing the ICRS right-ascension of the center of the image. > > POS_EQ_DEC_MAIN > --> pos.eq.dec > representing the ICRS declination of the center of the image. > > VOX:Image_Naxes > --> pos.wcs.naxes > specifying the number of image axes. > > VOX:Image_Naxis > --> pos.wcs.naxis > with the array value giving the length in pixels of each image axis. > > VOX:Image_Scale > --> instr.scale > with the array value giving the scale in degrees per pixel of each image > axis. > > VOX:Image_Format > --> meta.code.mime > specifying the MIME-type of the object associated with the image acref, > > VOX:STC_CoordRefFrame > --> pos.frame > representing the coordinate system reference frame, selected from "ICRS", > "FK5", "FK4", "ECL", "GAL", and "SGAL". > > VOX:STC_CoordEquinox > --> time.equinox > representing the Equinox (not required for ICRS) of the coordinate system > > VOX:WCS_CoordProjection > --> pos.wcs.ctype > the array value being the three-character code ("TAN", "ARC", "SIN", and so > forth) specifying the celestial projection > > VOX:WCS_CoordRefPixel > --> pos.wcs.crpix > with the array value specifying the image pixel coordinates of the WCS > reference pixel. This is identical to "CRPIX" in FITS WCS. > > VOX:WCS_CoordRefValue > --> pos.wcs.crval > with the array value specifying the world coordinates of the WCS reference > pixel. This is identical to "CRVAL" in FITS WCS. > > VOX:WCS_CDMatrix > --> pos.wcs.cdmatrix > with the array (matrix) value specifying the WCS CD matrix. This is > identical to the "CD" term in FITS WCS, and defines the scale and rotation > (among other things) of the image. > > VOX:BandPass_ID > --> instr.bandpass > identifying the bandpass by name (e.g., "V", "SDSS_U", "K", "K-Band", etc.). > > VOX:BandPass_Unit > --> meta.unit > identifying the units used to represent spectral values, selected from > "meters", "hertz", and "keV". > > VOX:BandPass_RefValue > --> em.wl OR em.freq OR em.energy > specifying the characteristic (reference) frequency, wavelength, or energy > for the bandpass model. > > VOX:BandPass_HiLimit > --> em.wl;stat.max OR em.freq;stat.max OR em.energy;stat.max > specifying the upper limit of the bandpass. > > VOX:BandPass_LoLimit > --> em.wl;stat.min OR em.freq;stat.min OR em.energy;stat.min > specifying the lower limit of the bandpass. > > VOX:Image_PixFlags > --> meta.code > specifying the type of processing done by the image service to produce an > output image pixel. > > VOX:Image_AccessReference > --> meta.ref.url > specifying the URL to be used to access or retrieve the image. > > VOX:Image_AccessRefTTL > --> time.interval;stat.min > specifying the minimum time to live in seconds of the access reference. > > VOX:Image_FileSize > --> phys.size;meta.file > representing the actual or estimated size of the encoded image in bytes (not > pixels!). > -------------------------------------------------------------------------- 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 Alberto.Micol at eso.org Wed Mar 24 12:56:11 2004 From: Alberto.Micol at eso.org (Alberto Micol) Date: Wed, 24 Mar 2004 21:56:11 +0100 Subject: New UCD1+ for SIA protocol In-Reply-To: <02f401c411d0$3215b650$0c0ba8c0@cacr.caltech.edu> References: <02f401c411d0$3215b650$0c0ba8c0@cacr.caltech.edu> Message-ID: After a first glance: I like it! Well, this is not really helping anybody out there, is it? Only two points (in the temporary absence of an established data model): > VOX:Image_Scale > --> instr.scale > with the array value giving the scale in degrees per pixel of each > image > axis. > Wouldn't it be better to have it as --> pos.wcs.scale ? This parameter has to do with the way the data are sampled, and any software could resample it (eg drizzle) onto a different grid than the original instrumental pixel scale (and think of the case where data from different instruments are mosaic'd together). In the end the instrument (instr.) has nothing to do with the pixel scale. And, anyway the pixel scale can be computed from the pos.wcs.cdmatrix... why do we need it? Probably for queries ... Unless you meant the actual resolution (Rayleigh, seeing, etc) Yet again in this case instr. is not the place to store it. Actually, where is the resolution in this scheme? Probably it was not in the SIAP, but I should read the SIAP specs again. > VOX:Image_AccessReference > --> meta.ref.url > specifying the URL to be used to access or retrieve the image. This is complex ... there could be various URLs associated to the same image, e.g., to access the full product or only a preview; but I need to read the SIAP doc again before insisting on this. Alberto From brian.thomas at gsfc.nasa.gov Wed Mar 24 13:21:17 2004 From: brian.thomas at gsfc.nasa.gov (Brian Thomas) Date: Wed, 24 Mar 2004 16:21:17 -0500 Subject: New UCD1+ for SIA protocol In-Reply-To: References: <02f401c411d0$3215b650$0c0ba8c0@cacr.caltech.edu> Message-ID: <200403241621.17502.brian.thomas@gsfc.nasa.gov> On Wednesday 24 March 2004 03:56 pm, Alberto Micol wrote: > After a first glance: I like it! Well, this is not really helping > anybody out there, is it? Well, I will try to push for this in the NOAO data model that our group is working on. =b.t. From dtody at aoc.nrao.edu Wed Mar 24 13:52:33 2004 From: dtody at aoc.nrao.edu (Doug Tody) Date: Wed, 24 Mar 2004 14:52:33 -0700 (MST) Subject: New UCD1+ for SIA protocol In-Reply-To: Message-ID: Hi Alberto - On Wed, 24 Mar 2004, Alberto Micol wrote: > Only two points (in the temporary absence of an established data model): > > > VOX:Image_Scale > > --> instr.scale > > with the array value giving the scale in degrees per pixel of each > > image > > axis. > > > > Wouldn't it be better to have it as --> pos.wcs.scale ? > This parameter has to do with the way the data are sampled, > and any software could resample it (eg drizzle) onto a different grid > than the original instrumental pixel scale (and think of the case where > data from different instruments are mosaic'd together). > In the end the instrument (instr.) has nothing to do with the pixel > scale. > > And, anyway the pixel scale can be computed from the pos.wcs.cdmatrix... > why do we need it? Probably for queries ... All we are doing here is normalizing the UCDs for SIA - for V1.1 we would prefer to minimize serious changes to the interface. Anyway, although the image scale can be computed from the CD matrix, 1) scale is a major image attribute which we prefer to have readily available to the client without having to process the WCS, 2) while the image scale is a required parameter, the WCS is merely "strongly recommended" and data providers are not required to provide it. If the WCS is missing, it can be approximated from the required image parameters, i.e., CRPIX the image center, CRVAL is POS in IRCS coordinates, the image is assumed to be nonrotated, and the CD matrix is thus defined by the naxis and scale values. > Actually, where is the resolution in this scheme? > Probably it was not in the SIAP, but I should read the SIAP specs again. SIA does not currently have the full sampling/bandpass data characterization which we have discussed elsewhere. At some point we would like to add this. V1.1 is conceivable if it comes along fast enough. > > VOX:Image_AccessReference > > --> meta.ref.url > > specifying the URL to be used to access or retrieve the image. > > This is complex ... there could be various URLs associated to > the same image, e.g., to access the full product or only a preview; > but I need to read the SIAP doc again before insisting on this. These each get a different row of the query response VOTable, hence each has a different acref URL. We have another proposal (again from Roy) to define an optional logical name which can be used to tag each row in the query result. Rows which refer to the "same image" but differ only in image format, bandpass, or whatever, would have the same logical name to indicate that they are associated. - Doug From Alberto.Micol at eso.org Wed Mar 24 14:19:34 2004 From: Alberto.Micol at eso.org (Alberto Micol) Date: Wed, 24 Mar 2004 23:19:34 +0100 Subject: New UCD1+ for SIA protocol In-Reply-To: <200403241621.17502.brian.thomas@gsfc.nasa.gov> References: <02f401c411d0$3215b650$0c0ba8c0@cacr.caltech.edu> <200403241621.17502.brian.thomas@gsfc.nasa.gov> Message-ID: <5441B66E-7DE1-11D8-A564-000A95D007D2@eso.org> Dear Doug, Yes, I completely agree with all you said, and understand the normalisation of UCDs; my only objection was on the UCD name not to be linked to the instrument (instr.scale) but to the pos.wcs. That is, I'm proposing: instr.scale to be replaced by pos.wcs.scale for all the reasons I already reported. Sorry not to have been too clear the first time. Alberto PS: I understand from Brian that also my comment ("not helping anybody out there") was misunderstood: I was in no way criticising the normalisation, which in fact I like. It looks like this is not my day, better I close here and go to bed ... From hanisch at stsci.edu Thu Mar 25 06:44:06 2004 From: hanisch at stsci.edu (Robert Hanisch) Date: Thu, 25 Mar 2004 09:44:06 -0500 Subject: New UCD1+ for SIA protocol References: Message-ID: <00cc01c41277$9ffe2e20$7deca782@stsci.edu> I just want to add my support for Alberto's objection to instr.scale -- I think this could be very confusing. The scale here is not an attribute of the instrument, but of the image. Glancing quickly through the UCD-UCD1+ mapping, however, I do not see a UCD that fits very well. Is meta.bullshit going to stay? Bob ----- Original Message ----- From: "Doug Tody" To: "Alberto Micol" Cc: "Roy Williams" ; ; Sent: Wednesday, March 24, 2004 4:52 PM Subject: Re: New UCD1+ for SIA protocol > Hi Alberto - > > On Wed, 24 Mar 2004, Alberto Micol wrote: > > Only two points (in the temporary absence of an established data model): > > > > > VOX:Image_Scale > > > --> instr.scale > > > with the array value giving the scale in degrees per pixel of each > > > image > > > axis. > > > > > > > Wouldn't it be better to have it as --> pos.wcs.scale ? > > This parameter has to do with the way the data are sampled, > > and any software could resample it (eg drizzle) onto a different grid > > than the original instrumental pixel scale (and think of the case where > > data from different instruments are mosaic'd together). > > In the end the instrument (instr.) has nothing to do with the pixel > > scale. > > > > And, anyway the pixel scale can be computed from the pos.wcs.cdmatrix... > > why do we need it? Probably for queries ... > > All we are doing here is normalizing the UCDs for SIA - for V1.1 we would > prefer to minimize serious changes to the interface. Anyway, although > the image scale can be computed from the CD matrix, 1) scale is a major > image attribute which we prefer to have readily available to the client > without having to process the WCS, 2) while the image scale is a required > parameter, the WCS is merely "strongly recommended" and data providers are > not required to provide it. If the WCS is missing, it can be approximated > from the required image parameters, i.e., CRPIX the image center, CRVAL > is POS in IRCS coordinates, the image is assumed to be nonrotated, and > the CD matrix is thus defined by the naxis and scale values. > > > Actually, where is the resolution in this scheme? > Probably it was > not in the SIAP, but I should read the SIAP specs again. > > SIA does not currently have the full sampling/bandpass data characterization > which we have discussed elsewhere. At some point we would like to add this. > V1.1 is conceivable if it comes along fast enough. > > > > VOX:Image_AccessReference > > > --> meta.ref.url > > > specifying the URL to be used to access or retrieve the image. > > > > This is complex ... there could be various URLs associated to > > the same image, e.g., to access the full product or only a preview; > > but I need to read the SIAP doc again before insisting on this. > > These each get a different row of the query response VOTable, hence each > has a different acref URL. We have another proposal (again from Roy) > to define an optional logical name which can be used to tag each row in > the query result. Rows which refer to the "same image" but differ only > in image format, bandpass, or whatever, would have the same logical name > to indicate that they are associated. > > - Doug > > From dtody at nrao.edu Thu Mar 25 07:04:09 2004 From: dtody at nrao.edu (Doug Tody) Date: Thu, 25 Mar 2004 08:04:09 -0700 (MST) Subject: New UCD1+ for SIA protocol In-Reply-To: <00cc01c41277$9ffe2e20$7deca782@stsci.edu> Message-ID: On Thu, 25 Mar 2004, Robert Hanisch wrote: > I just want to add my support for Alberto's objection to instr.scale -- I > think this could be very confusing. The scale here is not an attribute of > the instrument, but of the image. Glancing quickly through the UCD-UCD1+ > mapping, however, I do not see a UCD that fits very well. I also agree, this is the image scale not an instrument attribute. A larger point here is that in the process of normalizing the UCDS in SIA V1.1, we also plan to introduce UTYPE. The recommendation for folks writing software interfaces to interpret SIA tables will be to use UTYPE to identify the formally defined elements of the interface. This is very straightforward whereas UCD is not; we can evolve UCD independently and our interfaces will not break. Hence it is up to the UCD folks to assign the best UCDs for these fields, and if we have to adjust or generalize them later we will be able do so. In general I think UCD should be used for hard things like inference, semantic associations, smart queries, etc. UTYPE is much simpler and is what we need to identify interface elements in a straightforward manner. - Doug From amsr at jb.man.ac.uk Thu Mar 25 07:14:13 2004 From: amsr at jb.man.ac.uk (Anita Richards) Date: Thu, 25 Mar 2004 15:14:13 +0000 (GMT) Subject: New UCD1+ for SIA protocol In-Reply-To: <00cc01c41277$9ffe2e20$7deca782@stsci.edu> References: <00cc01c41277$9ffe2e20$7deca782@stsci.edu> Message-ID: Bob Hanisch wrote > I just want to add my support for Alberto's objection to instr.scale -- I > think this could be very confusing. The scale here is not an attribute of > the instrument, but of the image. Glancing quickly through the UCD-UCD1+ > mapping, however, I do not see a UCD that fits very well. Alberto (I think) wrote > > Actually, where is the resolution in this scheme? > Probably it was > not in the SIAP, but I should read the SIAP specs again. To underline these points, I think thaat there may be a tendency to think of images as products of instruments using pixel detectors, where the pixel scale of the instrument determines the resolution of the image and the sampling interval of the image. But of course that ain't necessarily so. As has been pointed out, data processing can change the image pixel size of even CCD images let alone other forms of data. The resolution is determined by the PSF, but even that means different things in different regimes. Both pixel size and resolution are variable e.g. by weighting radio data. Hence for describing images you need an image pixel size. Resolution is tricker since even in a single image that can be brightness dependent. In the Registry we would use a range but in describing images I think that the choices are 1) Just use image pixel size and assume that everyone uses something close to the convention of 3 pixels across a resolution element most of the time (but as resolution is unspecified the user will have to think about it and hence will not be misled). This is probably best for images but maybe not for catalogue data. 2) Use a 'characteristic resolution'. However, that is problematic for images as this may not be specified in the FITS header (e.g. in radio images the restoring beam size is usually in there but can be buried deep in the history). However it is often what is given in catalogues. cheers a - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Anita M. S. Richards, AVO Astronomer MERLIN/VLBI National Facility, University of Manchester, Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K. tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax). From roy at cacr.caltech.edu Thu Mar 25 07:17:04 2004 From: roy at cacr.caltech.edu (Roy Williams) Date: Thu, 25 Mar 2004 07:17:04 -0800 Subject: New UCD1+ for SIA protocol References: <00cc01c41277$9ffe2e20$7deca782@stsci.edu> Message-ID: <020801c4127c$3bf4a530$7201a8c0@Ropy> > Is meta.bullshit going to stay? Definitely. From andrea at rm.iasf.cnr.it Thu Mar 25 07:45:07 2004 From: andrea at rm.iasf.cnr.it (Andrea Preite Martinez) Date: Thu, 25 Mar 2004 16:45:07 +0100 (ora solare Europa occidentale) Subject: New UCD1+ for SIA protocol In-Reply-To: <00cc01c41277$9ffe2e20$7deca782@stsci.edu> References: <00cc01c41277$9ffe2e20$7deca782@stsci.edu> Message-ID: A comment on 1) VOX:Image_Scale --> instr.scale and 2) UCD1+:meta.bullshit (Bob's message) 1. In the list of ucd1+ that I derived, the atoms "image" and "scale" are present in instr.scale and obs.image . To me the concept of scale in this context is more important than the concept of image, then I supported "instr.scale". A much better alternative could be the definition of the new ucd1+: obs.image.scale 2. While examining all the tables and columns in Vizier I came across 2 or 3 columns whose names and descriptions were so cryptical that even going to the original papers I could not understand the nature of what the author(s) had in mind to describe. My limitation, of course. I then marked those cases with this (probably a bit offensive) tag. The file ~/ucd1-ucd1p.txt was then automatically generated from a much bigger/detailed file, and the tag slipped through. If and when we will move to ucd1+, I'll remove it. 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 hanisch at stsci.edu Thu Mar 25 07:52:09 2004 From: hanisch at stsci.edu (Robert Hanisch) Date: Thu, 25 Mar 2004 10:52:09 -0500 Subject: New UCD1+ for SIA protocol References: <00cc01c41277$9ffe2e20$7deca782@stsci.edu> Message-ID: <018101c41281$219f5db0$7deca782@stsci.edu> ----- Original Message ----- From: "Andrea Preite Martinez" To: "Robert Hanisch" Cc: "Doug Tody" ; "Alberto Micol" ; "Roy Williams" ; ; Sent: Thursday, March 25, 2004 10:45 AM Subject: Re: New UCD1+ for SIA protocol > A comment on > > 1) VOX:Image_Scale --> instr.scale > and > > 2) UCD1+:meta.bullshit (Bob's message) > > 1. In the list of ucd1+ that I derived, the atoms "image" and "scale" are > present in instr.scale and obs.image . To me the concept of scale in this > context is more important than the concept of image, then I supported > "instr.scale". > A much better alternative could be the definition of the new ucd1+: > obs.image.scale Yes, much better! > 2. While examining all the tables and columns in Vizier I came across 2 or > 3 columns whose names and descriptions were so cryptical that even going to > the original papers I could not understand the nature of what the author(s) > had in mind to describe. My limitation, of course. I then marked those > cases with this (probably a bit offensive) tag. > The file ~/ucd1-ucd1p.txt was then automatically generated from a much > bigger/detailed file, and the tag slipped through. If and when we will move > to ucd1+, I'll remove it. How about meta.unknown? Not that I am so easy to offend, mind you, but... Bob > > 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 dtody at aoc.nrao.edu Thu Mar 25 07:59:16 2004 From: dtody at aoc.nrao.edu (Doug Tody) Date: Thu, 25 Mar 2004 08:59:16 -0700 (MST) Subject: New UCD1+ for SIA protocol In-Reply-To: Message-ID: Taking this one step further: if we start inventing UCDs which are nothing more than the names of data model attributes, this may indicate that something is wrong. Perhaps what we should be doing is using UTYPE to define the data model attribute or interface element (if there is one), and UCD to say something about the quantity given as the value. For example, if the UTYPE is something like image.scale, then the UCD might define the type of physical quantity including units. Currently we try to fix the quantity/units, but there are cases where this needs to vary even though we are talking about a single data model attribute. - Doug On Thu, 25 Mar 2004, Doug Tody wrote: > On Thu, 25 Mar 2004, Robert Hanisch wrote: > > I just want to add my support for Alberto's objection to instr.scale -- I > > think this could be very confusing. The scale here is not an attribute of > > the instrument, but of the image. Glancing quickly through the UCD-UCD1+ > > mapping, however, I do not see a UCD that fits very well. > > I also agree, this is the image scale not an instrument attribute. > > A larger point here is that in the process of normalizing the UCDS in > SIA V1.1, we also plan to introduce UTYPE. The recommendation for folks > writing software interfaces to interpret SIA tables will be to use UTYPE > to identify the formally defined elements of the interface. This is very > straightforward whereas UCD is not; we can evolve UCD independently and > our interfaces will not break. Hence it is up to the UCD folks to assign > the best UCDs for these fields, and if we have to adjust or generalize them > later we will be able do so. > > In general I think UCD should be used for hard things like inference, > semantic associations, smart queries, etc. UTYPE is much simpler and is > what we need to identify interface elements in a straightforward manner. > > - Doug > > From amsr at jb.man.ac.uk Thu Mar 25 08:00:08 2004 From: amsr at jb.man.ac.uk (Anita Richards) Date: Thu, 25 Mar 2004 16:00:08 +0000 (GMT) Subject: New UCD1+ for SIA protocol In-Reply-To: References: <00cc01c41277$9ffe2e20$7deca782@stsci.edu> Message-ID: > > 1) VOX:Image_Scale --> instr.scale > > A much better alternative could be the definition of the new ucd1+: > obs.image.scale That still suggest to me that the scale is inherant to the observations - but it is better > 2) UCD1+:meta.bullshit (Bob's message) > bigger/detailed file, and the tag slipped through. If and when we will move > to ucd1+, I'll remove it. Or jsut wait until your critics stop talking bullshit? You and Roy and Sebastien have done a pretty good job if people can only find 1.5 ucd1+'s to complain about! a From jcm at head.cfa.harvard.edu Thu Mar 25 08:01:31 2004 From: jcm at head.cfa.harvard.edu (Jonathan McDowell) Date: Thu, 25 Mar 2004 11:01:31 -0500 (EST) Subject: New UCD1+ for SIA protocol Message-ID: <200403251601.i2PG1VKf007368@urania.cfa.harvard.edu> Apologies if this is already covered, I missed some emails.. My biggest problem is "pos.wcs" which generalizes poorly. Seems to me that naxis and naxes are properties of the pixels, and indeed of the image and not of pos itself. What if you have an x,y,time cube? I would argue it would be obs.image.naxes obs.image.naxis or perhaps obs.image.wcs.naxes obs.image.wcs.naxis (or array.naxes or whatever the top level thing, but not pos) but not pos.naxes = 2 time.naxes = 1 pos.naxis = 512 512 time.naxis = 30 Similarly, the other wcs.* should probably be image.wcs.* not pos.wcs.* ? I agree with others comments about instr.scale; Should be image.wcs.scale I am generally confused about what is in "wcs" and what is not: "pos.frame" not part of wcs, but "pos.wcs.naxes" is? > > meta.bullshit > meta.unknown? I think the first is a more accurate description; how about meta.badly_defined or meta.obscure :-) - Jonathan From Alberto.Micol at eso.org Thu Mar 25 08:05:00 2004 From: Alberto.Micol at eso.org (Alberto Micol) Date: Thu, 25 Mar 2004 17:05:00 +0100 Subject: New UCD1+ for SIA protocol References: <00cc01c41277$9ffe2e20$7deca782@stsci.edu> Message-ID: <4063032C.2090803@eso.org> >1. In the list of ucd1+ that I derived, the atoms "image" and "scale" are >present in instr.scale and obs.image . To me the concept of scale in this >context is more important than the concept of image, then I supported >"instr.scale". >A much better alternative could be the definition of the new ucd1+: >obs.image.scale > Sorry Andrea, But if we go for obs.image.scale then one would also think that the following should exist: obs.spectrum.scale And furthermore, personally if I see a scale at that level then I also expect: obs.image.wcs.ctype obs.image.wcs.crpix obs.image.wcs.crval obs.image.wcs.cdmatrix etc. and similarly for obs.spectrum ... Hence, I like much better the pos than the obs.image because it is more generic. So in the end I like much better: pos.wcs.ctype pos.wcs.crval pos.wcs.scale !!! etc etc because we can reuse it in many different contexts (spectra, images etc). Let's keep together all the "how is the dataset sampled?" elements under the same UCD (pos) and not let them spread under different ones. Alberto PS: Yes Anita they did a good job indeed! From pdidelon at cea.fr Thu Mar 25 08:14:00 2004 From: pdidelon at cea.fr (Pierre Didelon) Date: Thu, 25 Mar 2004 17:14:00 +0100 Subject: New UCD1+ for SIA protocol In-Reply-To: <018101c41281$219f5db0$7deca782@stsci.edu> References: <00cc01c41277$9ffe2e20$7deca782@stsci.edu> <018101c41281$219f5db0$7deca782@stsci.edu> Message-ID: <40630548.2030906@cea.fr> Robert Hanisch wrote: > ----- Original Message ----- > From: "Andrea Preite Martinez" > To: "Robert Hanisch" > Cc: "Doug Tody" ; "Alberto Micol" > ; "Roy Williams" ; > ; > Sent: Thursday, March 25, 2004 10:45 AM > Subject: Re: New UCD1+ for SIA protocol > > > >>A comment on >> >>1) VOX:Image_Scale --> instr.scale >>and >> >>2) UCD1+:meta.bullshit (Bob's message) >> >>1. In the list of ucd1+ that I derived, the atoms "image" and "scale" are >>present in instr.scale and obs.image . To me the concept of scale in this >>context is more important than the concept of image, then I supported >>"instr.scale". >>A much better alternative could be the definition of the new ucd1+: >>obs.image.scale > > > Yes, much better! > Does images always be related tightly to observation? what about an image loosely related to observation, obtained, as already stressed, by drizzle or anyother image processing task, or even "images" obtained by simulation and so no much link with obs.? But this is may be a too DM oriented view. -- Pierre -------------------------------------------------------------------------- DIDELON :@: pdidelon_at_cea.fr Phone : 33 (0)1 69 08 58 89 CEA SACLAY - Service d'Astrophysique 91191 Gif-Sur-Yvette Cedex -------------------------------------------------------------------------- From dtody at aoc.nrao.edu Thu Mar 25 09:45:20 2004 From: dtody at aoc.nrao.edu (Doug Tody) Date: Thu, 25 Mar 2004 10:45:20 -0700 (MST) Subject: New UCD1+ for SIA protocol In-Reply-To: Message-ID: On Thu, 25 Mar 2004, Anita Richards wrote: > > 1) VOX:Image_Scale --> instr.scale > > > > A much better alternative could be the definition of the new ucd1+: > > obs.image.scale > > That still suggest to me that the scale is inherant to the observations - > but it is better This is a general issue with what we are calling the "observation" data model. This may be just a naming issue but I worry that we may try to describe actual observations. What we really need to do for VO is characterize the physical attributes of a dataset. A dataset may be a calibrated observation, or it may be the result of an arbitrary amount of processing of multiple observations, or it may be synthetic data. It does not matter how the dataset was generated if we describe only the physical attributes of the actual final dataset we are dealing with. Scale and resolution are good examples of such physical attributes. For VO data analysis where we may need to deal uniformly with data from many origins, physical dataset characterization is what is needed. At this level we should not have any information about the actual observations, instrument characteristics, etc., (if any) used to produce the dataset. Such information may be present in each individual dataset, and can be useful to fully understand individual datasets, but is not very useful for automated processing of data from many origins. A simple example is exposure time. While a typical attribute of an individual original observation, it tells us almost nothing about an arbitrary dataset. To understand what this means we would have to understand the full instrumental model and configuration, and all the post-processing done to get to the final dataset we are actually looking at. The related physical dataset attributes are the sampling and coverage in time of the final (possibly aggregate) dataset, and some physical measure of the limiting flux of a signal detected by the dataset. From pfo at star.le.ac.uk Thu Mar 25 10:22:20 2004 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Thu, 25 Mar 2004 18:22:20 +0000 (GMT) Subject: New UCD1+ for SIA protocol In-Reply-To: Message-ID: Doug, I fully agree with you, I think you hit the nail, it is the dataset that the user gets what needs proper description, regardless of what's been done to reach this result. A dataset has an angular scale ("/pix) or a linear scale (km/pix, eg, solar or planetary images), the dataset's origin may be real observations or simulations, simple observations (classical CCD image), mosaics, images based on radio data, multiwavelength composites, whatever. Scales can be degraded or modified from the initial products (eg, DSS) As you said, something similar happens when describing the time coverage. Quantities which make sense to individual observations don't necessariry apply to final products (datasets), for instance, exposure_time != end_of_exposure - start_of_exposure in a dataset which does not represent an individual observation. Color composite images are another example of a final product where the individual observations' parameters may vary considerably, talking about instrument.scale or obs.scale does not seem appropriate anymore. At the time of the construction of UCD0 it did make sense to group these items (read drop these items) in the "instrumental" category. That doesn't apply any longer. Cheers, Patricio On Thu, 25 Mar 2004, Doug Tody wrote: > On Thu, 25 Mar 2004, Anita Richards wrote: > > > > 1) VOX:Image_Scale --> instr.scale > > > > > > A much better alternative could be the definition of the new ucd1+: > > > obs.image.scale > > > > That still suggest to me that the scale is inherant to the observations - > > but it is better > > This is a general issue with what we are calling the "observation" > data model. This may be just a naming issue but I worry that we may try > to describe actual observations. > > What we really need to do for VO is characterize the physical attributes > of a dataset. A dataset may be a calibrated observation, or it may be > the result of an arbitrary amount of processing of multiple observations, > or it may be synthetic data. It does not matter how the dataset was > generated if we describe only the physical attributes of the actual final > dataset we are dealing with. Scale and resolution are good examples of > such physical attributes. > > For VO data analysis where we may need to deal uniformly with data from > many origins, physical dataset characterization is what is needed. At this > level we should not have any information about the actual observations, > instrument characteristics, etc., (if any) used to produce the dataset. > Such information may be present in each individual dataset, and can be > useful to fully understand individual datasets, but is not very useful > for automated processing of data from many origins. > > A simple example is exposure time. While a typical attribute of an > individual original observation, it tells us almost nothing about an > arbitrary dataset. To understand what this means we would have to > understand the full instrumental model and configuration, and all the > post-processing done to get to the final dataset we are actually looking at. > The related physical dataset attributes are the sampling and coverage in > time of the final (possibly aggregate) dataset, and some physical measure > of the limiting flux of a signal detected by the dataset. --- Patricio F. Ortiz pfo at star.le.ac.uk AstroGrid project Department of Physics and Astronomy University of Leicester Tel: +44 (0)116 252 2015 LE1 7RH, UK From derriere at newb6.u-strasbg.fr Fri Mar 26 09:50:50 2004 From: derriere at newb6.u-strasbg.fr (Sebastien Derriere) Date: Fri, 26 Mar 2004 18:50:50 +0100 Subject: New UCD1+ for SIA protocol References: <200403241946.i2OJkEu1003422@xebec.cfa.harvard.edu> Message-ID: <40646D7A.9EE207DD@astro.u-strasbg.fr> Arnold Rots wrote: > > SIAP 1.1: > > I had asked that SCORE (used to be GRADE) be included in the list of > optional input and output parameters and there seemed to be agreement > that it is a useful thing. Hello Arnold, If this SCORE is added to the parameters, there is one UCD that could be used: meta.code.qual is a quality/precision/reliability index or flag. 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 Fri Mar 26 12:35:11 2004 From: arots at head.cfa.harvard.edu (Arnold Rots) Date: Fri, 26 Mar 2004 15:35:11 -0500 (EST) Subject: New UCD1+ for SIA protocol In-Reply-To: <40646D7A.9EE207DD@astro.u-strasbg.fr> Message-ID: <200403262035.i2QKZCM4000824@xebec.cfa.harvard.edu> Sebastien, Yes, I had noticed that one but thought that maybe it should be preserved for a more formal and precise quality or, more specifically, the quality of the data. For instance, when you have two exposures, one of 1000 s and one of 100000 s, the score of the latter may be higher, even though the quality of the data in the former may be better. What it amounts to is that score and quality are notr quite the same concept. Data quality is a component but not the only thing that goes into a score. - Arnold Sebastien Derriere wrote: > Arnold Rots wrote: > > > > SIAP 1.1: > > > > I had asked that SCORE (used to be GRADE) be included in the list of > > optional input and output parameters and there seemed to be agreement > > that it is a useful thing. > > Hello Arnold, > > If this SCORE is added to the parameters, there is one UCD that > could be used: meta.code.qual is a quality/precision/reliability > index or flag. > > 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/ --------------------------------------------------------------------------