Re: [Plastic-devs] spectrum load message
Brought to you by:
johndavidtaylor,
thomasboch
Menu
▾
▴
Re: [Plastic-devs] spectrum load message
|
From: Noel W. <Noe...@ma...> - 2006-09-14 11:31:16
|
Just trying to implement this now. The SSAP responses I see coming back from current services seem to do a good job of annotating their columns with UCDs. However, utypes are either incomplete or utterly missing. > the spectrum. The entries of this map take the form of > utype->value pairs, where the keys (utypes) are as defined > in the SSAP specification, e.g. "Access.Format" for MIME > type. As many or few of these entries as are known may be > filled in. would UCD->Value pairs be acceptable to everyone? cheers noel. On 13 Sep 2006, at 12:23, Mark Taylor wrote: > On Tue, 12 Sep 2006, Isa Barbarisi wrote: > >> Dear Mark, >> >> I agree with the approach about defining additional arguments in the >> message related more to the type of object (spectrum) than to the >> format of this object (votable, fits..). In fact, this is what we >> tried >> to do when we defined the first SSAP definition. >> During the process of implementation of VOSpec, we found that only >> a few >> parameters are needed to manipulate most of the spectra formats. Of >> course, not all the possible spectra serializations can be used in >> VOSpec, but that collection of parameters allows our application to >> display thousand of spectra in different formats from ~15 different >> projects. >> >> List of parameters: C: compulsory - O: Optional >> --------------------------------------------------------------------- >> --------------------------------------------------------------------- >> - >> >> Title - <title> - C - e.g. "ISO SWS01 Spectrum Target: M31_BULGE" >> URL - <url> - C - e.g. >> "http://pma.i....../jsp/product.jsp?obsno=40001501" >> ServerTitle - <server_title> - O - e.g. "ISO Data Archive" >> WaveLengthColumnName - <wave_column_name> - C - e.g. SWAAWAVE >> FluxColumnName - <flux_column_name> - C - e.g. SWAAFLUX >> WaveUnitsScaleq - <wave_units_scaleq> - C - e.g. 1.E-6 >> WaveUnitsDimeq - <wave_units_dimeq> - C - e.g. L >> FluxUnitsScaleq - <flux_units_scaleq> - C - e.g. 1.E-23 >> FluxUnitsDimeq - <flux_units_dimeq> - C - e.g. MT-2 >> Ra - <ra> - O - e.g 10.691809995 >> Dec - <dec> - O - e.g 41.27003 >> Format - <format> - C - e.g spectrum/fits >> --------------------------------------------------------------------- >> --------------------------------------------------------------------- >> --- >> >> >> Our proposal is to have (at least) all the compulsory fields in the >> message, so VOSpec (as message consumer) and e.g. Aladin and >> Astroscope >> (as message senders) could be immediately updated to load spectra >> using it. >> Note that all the information requested is already present in the >> existing SSAP services, and it is going to be included (perhaps with >> some minimal syntax changes) in the next SSAP specification. > > Isa, > > thanks for your message. I hadn't given much thought to these > additional > metadata items. I suppose in most cases they can be obtained from > the spectrum itself after retrieval, but in some cases the information > is available before retrieval (and useful) because the relevant fields > are filled in for each row of the SSAP response table. > > So I've revised my proposal, as follows: > > boolean ivo://votech.org/spectrum/loadFromURL( String url, > String id, > Map meta ) > > Loads a spectrum or SED. id is an identifier as for the VOTable > load message - use the URL if there's no reason to do otherwise. > The meta argument is a map/struct containing additional > information about the type of data found at url which encodes > the spectrum. The entries of this map take the form of > utype->value pairs, where the keys (utypes) are as defined > in the SSAP specification, e.g. "Access.Format" for MIME > type. As many or few of these entries as are known may be > filled in. > > Discussions on the SSAP standard including the most recent > draft can be found at http://www.ivoa.net/twiki/bin/view/IVOA/ > SsaInterface > (see sec 7.5 of the SSA query interface V0.95 doc). > > Sending this message should be easy to implement by an SSAP client > (e.g. AstroScope) which wants to pass the spectrum selection on to > viewers, since it can just scoop up the fields from the relevant > row of the SSAP response VOTable and pass them on in a Map without > having to know or care what they mean. > > VO-friendly spectrum viewers such as VOSpec should be well-equipped > to receive and act on such messages, since in order to understand > SSAP queries which they already do, they must know how to make > sense of fields keyed by utypes in this way. The various optional > and compulsory parameters that you describe above can be included, > as well as any others that may be available. > > And an added bonus is that decisions about what metadata items > are/can be/should be passed by the message is taken care of by the > DAL/DM groups whose job it is to worry about such things, rather > than us plastickers who (well, speaking for myself) may not > understand spectra so well. > > This message can of course be used to pass spectra around which > do not result from actual SSAP queries, since you can add metadata > map entries by hand as if they'd come from SSAP (or just leave the > metadata map empty). > > Opinions? > > Mark > > -- > Mark Taylor Astronomical Programmer Physics, Bristol > University, UK > m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/ > ~mbt/ > > > ---------------------------------------------------------------------- > --- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Plastic-devs mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/plastic-devs > |
