From Marco.Leoni at eso.org Fri Mar 7 08:00:15 2003 From: Marco.Leoni at eso.org (Marco Leoni) Date: Fri, 07 Mar 2003 17:00:15 +0100 Subject: [Fwd: RE: UCDs - repost] Message-ID: <3E68C20F.7020700@eso.org> -------- Original Message -------- Subject: RE: UCDs - repost Date: Fri, 7 Mar 2003 09:25:19 -0500 From: "Wil O'Mullane" To: registry at ivoa.net I note in your paper you mention not being able to express functions in an Ontology. Many years ago I worked with Ontoloigua and KIF(Knowledge Interchange Format) this indeed allows one to express functions on numbers . http://logic.stanford.edu/kif/kif.html Of course KIF is lisp (Lots of Incomprehensilble Silly Brackets indeed) based and not very pretty . Still I see KSL have now extended Ontalingua in to the web world and suggest provideing it as a Server... it may bear looking at. Perhaps this has already been explored .. wil > > Hello all, > > Maybe some of you have not subscribed to the > ucd at ivoa.net list, but might have interest in > reading the paper I posted there: > > http://www.ivoa.net/forum/ucd/0001.htm > > Sorry for those who received this info twice. > > 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 ----- End forwarded message ----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From amsr at jb.man.ac.uk Mon Mar 17 08:03:55 2003 From: amsr at jb.man.ac.uk (Anita Richards) Date: Mon, 17 Mar 2003 16:03:55 +0000 (GMT) Subject: UCD Status and Perscpectives Message-ID: Sebastien's 'UCD: Status and Perspectives' gives a very clear summary of the recent discussions, responding on the basis of the considerable experience of CDS. Thanks very much - I actually enjoyed reading it, especially the ontology section. It suggests to me some issues which it would help if we made decisions on, or at least reached a working agreement for the immediate future. Maybe Sebastien (or anyone) could suggest what is most urgently needed for discussion at the IVOA registry meeting Wednesday 19 Mar - is anyone planning a presentation? This is what occurs to me: 1) Registries needs UCDs. 'Status and Perspectives' discusses relevant issues in '3. UCDs and data models'. We need general UCDs which describe an entire data set ("Header metadata"), e.g. for which wavelength regime (Radio, IR, Optical etc) - where such currently UCDs exist, they are often parts or parents, rather than ones which are instantiated. See e.g. [[http://www.stsci.edu/~hanisch/NVO/ResourceServiceMetadataV6.doc][Bob Hanisch ResourceServiceMetadataV6.doc]] or [[http://www.stsci.edu/~hanisch/NVO/ResourceServiceMetadataV6.pdf][ResourceServiceMetadataV6.pdf]] and [[http://wiki.astrogrid.org/bin/view/Astrogrid/RegistrySchema][AstroGrid draft registry schema]] We also need a means to associate header data with column labels, e.g. if all data in one catalogue is at 1.4 GHz and another at 1.6 GHz this currently has two separate column UCDs, PHOT_FLUX_RADIO_1.4G and PHOT_FLUX_RADIO_1.6G - dozens of UCDs in all. Using the atom idea across the header and the columns, this could be achieved using one column UCD PHOT_FLUX, and header UCDs for the wavelength regime (radio) and the nominal frequency. This does require that we evaluate the data corresponding to UCDs, see below. 2) Evaluating data identified by UCDs Many people think of UCDs as primarily for selection of catalogues for a human to then view the contents. This is their primary funtion as far as the Registry is concerned, but for actually executing queries we need to compare values within cagtalogues and possibly associate the results with a new UCD (e.g. compare flux densities to derive a colour). Until recently, UCDs were only evaluated routinely (e.g. via Vizier) in one of the most difficult cases - coordinate conversion. Otherwise, the user said 'give me a list of catalogues containing information about x' and the service converted x into UCDs and returned a list of catalogues containing columns corresponding to x. This is now extended to photometry but only for special formats (see above or the AVO demo). We now need UCDs which can enable selection via evaluating UCDs, e.g. if I want flux density measurements between 1.4 and 1.6 GHz I should be able to access data at 1.5 GHz too, via the registry search seeing there is a catalogue containing radio flux densities, and the query execution finding OBS_FREQUENCY 1.5 GHz - in the header, or as a column heading for a collection of measurements at a range of frequencies, as well as a column PHOT_FLUX. This may be a problem where one UCD describes several columns e.g. TIME_DATE for the start and stop of observations, but we want to evaluate both e.g. for error bars on a proper motion measurement. Or do we just need an algorithm which says 'if there are two TIME_DATEs and they are different, take the difference'? 3. Who reads UCDs? The document asks 'how do I find the proper UCD to decribe my data set'. At present, this is done automatically if you are someone contributing a 'simple' table e.g. out of a paper; the average astronomer is not _forced_ to be exposed to UCDs, and a user doing a search certainly isn't (although they might want to use them directly). Data providers of major archives may need to investigate them to check they are allocated correctly or suggest new ones, as do VO workers. Thus they should be reasonably human-readable and available for anyone, but not restricted to the lowest common denominator of astronomical understanding. We could increase the present number ten or even 100 fold (still <10^5) - I am not saying we should, but we need to be afraid of it. For example, if I am using the SED tool in Aladin, I really do not want to know that an optical data set has UCDs for photometric zero point and colour corrections (although an optical astronomer might and I had to learn...) but fortunately the Aladin prototype SED tool knows how to use these to plot magnitudes in Jy. Conversely an optical astronomer does not want to know parameters associated with radio visibility data but if s/he wants to extract an off-centre image at a certain resolution from the MERLIN archive, they need the extraction tool to know about baseline lengths, visibility integration times etc. to chose a data set with an appropriate field of view and resolution. Thus, completeness of UCDs for their purpose is more important than economy, and in fact the savings in going to an atomic structure would probably mean we could add UCDs for specific errors, and remove the degeneracy of things currently under 'TIME_DATE' or 'NUMBER' etc., without making UCDs unmanagable. As the document says, the creation of new UCDs should certainly be restricted to defined bodies (e.g. via a central monitoring panel) to avoid duplication and maintain consistency at a functional level. This probably means UCDs will proliferate slowly, acquire some clumsy ones, and then be pruned or refactored over a cycle of months or years. Best wishes Anita - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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 pfo at star.le.ac.uk Tue Mar 18 05:08:39 2003 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Tue, 18 Mar 2003 13:08:39 +0000 (GMT) Subject: UCD Status and Perscpectives In-Reply-To: Message-ID: Hi Anita, as a reflexion on your thought I wrote the following lines, which I think may be relevant. I must add that I agree with your points nearly 100% :-) Cheers, Patricio UCDs for the photometric and time domain. At nearly 5 years since the beginning of the work on UCDs a number of things have evolved which make it worth re-thinking how these two observation-related quantities can be represented for the new usages broght by the advent of the IVO and the possible usages by both human users or machine users (eg registries). Both of these variables can be seen as continuous, and one single observation will cover a certain range in wavelength (frequency) and a certain range in time. Historically, the wavelength domain has been split in "bands" by the use of photometric systems and observing bands in the different domains. UCDs tried to adjust to this scheme as it is useful to find comparable quantities in a simple datamining model. What was done was very similar to have POS_EQ_RA_MAIN_1H, POS_EQ_RA_MAIN_2H... The position in the sky, of course, was never constrained by instrumental settings and systems. Today though, we have seen the broad possibilities of searching in archived data and this scheme attached to UCDs can hardly cope with some of the newly imposed requirements. The problem is not to add more UCDs to the system, as that was seen as a clear possibility since the beginning, but to have a system able to respond in a simple way to queries like "I want observations in this wavelength regime". UCDs can (and should) still be attached to columns for proper characterization of each data column, but a solution can be found in a similar way to characterizing the sky coverage (where one can split the sky in arbitrary tiles and put 1 when observations exist in a given catalogue). What I propose is a system which represents the whole electromagnetic spectrum in a linear way. If one takes the space of log(wavelength) going from 0.003 nm to 3km we have nearly 15 decades of coverage, which could be split in 1000 parts to give enough spectral resolution. Each photometric filter and bandpass will be represented by a series of bits which should be set to 1. A catalogue which contains Jonhson's V magnitue and B-V colour index plus some radio data and X-ray data would have a fingerprint where the bits on will be the ones corresponding to the B and V filters, the radio bandpass(es) and the X-ray band(s). This information will be part of the catalogue's metainformation and should be stored in data-centers and possibly registries to which users will have access. A user may then submit a query to a registry where s/he can decide which ranges in the EMS to search for. The registry machine will create a "search fingerprint" to compare with the catalogues it knows about and/or it could pass this fingerprint to another grid service which will do its own search. The user should then receive a list of catalogue handles which satisfy his/her requirements. A number of scenarios of search logics can be envisioned, from full intersection to partial intersection of fingerprints. That is a point we should develop based on use cases. I've experimented with a solution where I split the interval (in log) in 15000 bins (1000 per decade) and it gives a reasonably good resolution in all wavelength regimes. More testing is needed and suggestions are welcome. The time domain It presents itself as a similar problem to wavelength. One could define a starting point, and fix a time resolution, then each timed observation could be defined by a series of bits set to 1 wherever this observation falls. If one were to take 1 day as the time resolution, 100yrs require 36525 bits If one were to take 1 hour as the time resolution, 100yrs require 876600 bits The numbers look large, but one can represent the time coverage of a catalogue by just a few bits set to 1. Each catalogue time-fingerprint can be reconstructed on the fly. Again, a user may form his/her own time-fingerprint to perform searches, like "I'm interested in recovering data for region X observed in this period of time or periods separated by one year afterwards", eg, one wants to measure proper motions. In summary, by linearizing and binning these two quantities one can build search engines which give users high flexibility to perform searches and solve so the problem of multiplying UCDs to high levels. Patricio F. Ortiz On Mon, 17 Mar 2003, Anita Richards wrote: > > > Sebastien's 'UCD: Status and Perspectives' gives a very clear summary of > the recent discussions, responding on the basis of the considerable ..... --- Dr. 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 jcm at head-cfa.cfa.harvard.edu Wed Mar 19 05:36:13 2003 From: jcm at head-cfa.cfa.harvard.edu (jcm at head-cfa.cfa.harvard.edu) Date: Wed, 19 Mar 2003 08:36:13 -0500 (EST) Subject: UCD Status and Perspectives Message-ID: <200303191336.h2JDaDs05535@urania.cfa.harvard.edu> Dear Patricio, I think your suggestion ("UCDs for the photometric and time domain") works well for search engines and catalog queries, but it does not work to describe the data precisely enough to do on-the-fly interconversions ("match this table with fluxes at 4100A to this other table with fluxes at 4200A assuming a spectral index of 0.7") at the level of accuracy wanted for data analysis, never mind the problem of "convert this kind of B filter to this slightly different kind of B filter". Maybe that's OK, but in that case some other language analogous to UCDs will be needed for robust data description and we should be clear that UCDs will only apply to the query process (indeed their current and original intention). Anita's comments are well taken, but perhaps she can clarify: you are suggesting replacing PHOT_FLUX_RADIO_1.4G with PHOT_FLUX and a header UCD of OBS_FREQUENCY 1.4 GHz, right? But what if you have three flux columns in the catalog, ( a bit like the problem you alluded to of TIME_DATE for start and stop), say PHOT_FLUX_RADIO_1.4G and PHOT_FLUX_RADIO_5.0G and PHOT_FLUX_RADIO_22.0G? Then we need three OBS_FREQUENCY header UCDs and a way to map them to the respective columns - which is essentially the 'parameterized UCD' I have suggested elsewhere. - Jonathan McDowell From pfo at star.le.ac.uk Wed Mar 19 06:18:43 2003 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Wed, 19 Mar 2003 14:18:43 +0000 (GMT) Subject: UCD Status and Perspectives In-Reply-To: <200303191336.h2JDaDs05535@urania.cfa.harvard.edu> Message-ID: Dear Jonathan, On Wed, 19 Mar 2003 jcm at head-cfa.cfa.harvard.edu wrote: > Dear Patricio, > > I think your suggestion ("UCDs for the photometric and time domain") > works well for search engines and catalog queries, but it does not work > to describe the data precisely enough to do on-the-fly interconversions > ("match this table with fluxes at 4100A to this other table with fluxes > at 4200A assuming a spectral index of 0.7") at the level of accuracy > wanted for data analysis, never mind the problem of "convert this kind > of B filter to this slightly different kind of B filter". Maybe that's > OK, but in that case some other language analogous to UCDs will be > needed for robust data description and we should be clear that UCDs will > only apply to the query process (indeed their current and original > intention). I couldn't agree more with you on this point. Discovering the existence of information is one issue, which could be solved with the scheme I proposed, and with UCDs but converting or transforming quantities is a completely different ball game. As we discussed in the meeting at CfA, full characterization of the filters and bandpasses should be achieved before attempting the conversion and a lot of "knowledge" or expertise will be required for us to get to this point. Can you expand on your first example please? "match this table with fluxes at 4100A to this other table with fluxes at 4200A assuming a spectral index of 0.7" What do you have in mind? Do you want to match by position first and then find the sources which have similar fluxes based on 4100 and 4200 band? I find your example quite interesting, that's why I'd like to know more what you have in mind. > > Anita's comments are well taken, but perhaps she can clarify: > you are suggesting replacing PHOT_FLUX_RADIO_1.4G with PHOT_FLUX > and a header UCD of OBS_FREQUENCY 1.4 GHz, right? But what if you > have three flux columns in the catalog, ( a bit like the problem > you alluded to of TIME_DATE for start and stop), say PHOT_FLUX_RADIO_1.4G > and PHOT_FLUX_RADIO_5.0G and PHOT_FLUX_RADIO_22.0G? Then we need three > OBS_FREQUENCY header UCDs and a way to map them to the respective columns > - which is essentially the 'parameterized UCD' I have suggested elsewhere. > > - Jonathan McDowell Although the last question is for Anita, let me jump in the case as well. If I understand well enough, when you produce a catalogue which contain observations in one frequency (band) one might think in calling the column PHOT_FLUX and qualify the whole catalogue. Well, that was exactly the situation we found in the published data. Tables made full sense when attached to their paper, and even the table name could tell us what band someone was observing. There were hundreds of tables where the column name was "Mag"; taking the table out of context (like in a table depository) one had no idea what this Mag meant, that's why UCDs were introduced, to solve this kind of degeneracy. I feel that if we do so with UCDs we'll go backwards in a sense. Jonathan, can you point me to a document with your proposed 'parameterized UCD'? I just searched with google and got nowhere :-( Cheers, Patricio --- Dr. 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 Markus.Dolensky at eso.org Thu Mar 20 07:58:55 2003 From: Markus.Dolensky at eso.org (Markus Dolensky) Date: Thu, 20 Mar 2003 16:58:55 +0100 Subject: UCDs status and perspectives References: <200303201516.h2KFG7P07723@rosetta.saclay.cea.fr> Message-ID: <3E79E53F.3050209@eso.org> Hi Pierre, I couldn't agree more on the notion of your second point: > 2) Adding UCD. > > As Patricio said, "the problem is not to add more UCDs", everbody > would agree on that, but it is certainly _how_ to perform > the metadata bank update, when _really_ needed. > A very strict and tedious approvment by an "expert group", > as proposed in sebastien's doc, is certainly not appropriate > for a lot of cases, where quick even instantaneous > response is needed. > Once more, migrating to parametrized atomic Descr (PAD?), > will perhaps facilitate their dynamic handling. It would be great if we could agree on some rules for using UCDs rather than looking at them individually. This might not be fully in line with the original idea when UCDs were invented as some sort of table column identifiers. The scope, however, is much broader now - it's about meta data in a more general sense. We need them in the registry, as query specifiers, as a way for interpreting VOTable docs, as tags in data models, ... Markus +--- | Markus Dolensky Mailto:Markus.Dolensky at eso.org | AVO Technical Lead Web: www.euro-vo.org | Voice: ++49 89 32006/261 Fax: ++49 89 32006/480 +--- From dide at discovery.saclay.cea.fr Thu Mar 20 07:16:07 2003 From: dide at discovery.saclay.cea.fr (DIDELON Pierre) Date: Thu, 20 Mar 2003 16:16:07 +0100 (MET) Subject: UCDs status and perspectives Message-ID: <200303201516.h2KFG7P07723@rosetta.saclay.cea.fr> Hello UCD Fan's and Pro's, the ongoing discussion seems very promising to me, and the experts certainly have a goog understanding of that's going on. Nevertheless I would like to make comments on three recurrent subjects. My point of view is perhaps obvious and trivial, but as UCD, and more generaly ontology, try to make implicit assumption became explicit, I felt free to post the following. The points are related to the UCD handling, the way of adding UCD, and UCD usage at different levels. 1) UCD Handling I was very happy to read the following in Sebastien's doc. "The hierchical tree is not fundamental - it's merely a way of classification". What is actually very important for me is the knowledge base represented by the UCDs, which certainly describe very well, even if not exhaustively the columns of astronomical catalogs. The ways, different people want to look at this metadata pond/container will certainly be differents. But actually the UCD structure and even the name structure itself does not promote or facilitate others point of view on this fabulous metadata bank. But as stressed also in sebastien's doc, "it is clear that the definition of right roots does not exist, and is influenced by the user's own needs". It means that a static absolute and final UCD structuration is not realistic, and so "different structures corresponding to different views" of UCD must coexist. It is one more argument in addition to a parametrized and atomic definition of Descriptors. 2) Adding UCD. As Patricio said, "the problem is not to add more UCDs", everbody would agree on that, but it is certainly _how_ to perform the metadata bank update, when _really_ needed. A very strict and tedious approvment by an "expert group", as proposed in sebastien's doc, is certainly not appropriate for a lot of cases, where quick even instantaneous response is needed. Once more, migrating to parametrized atomic Descr (PAD?), will perhaps facilitate their dynamic handling. To clarify my point of view, perhaps a little bit too broad and common, let's take an example. Try to imagine a Web service which can create data on the flight and must be able to assign UCDs to these _dynamic_ data. A very simple example would be a data bank of SED or photometric data covering a very wide spectral range, and which can delivered a flux, mag, color or anyelse sensible combined data at whatever wavelength required by the user. This service don't want to register one predifine UCD for any data conmbination but needs only to parametrize the UCD and perhaps, in the most complex case re-organize the basic predifined atoms. Then the atoms definitions and the combination rules allowed must be approved by an "expert group", but the parameter s and the combinations used can be freely adapted by each data provider, portal or anyelse service or tool. 3) UCD usage at different level As already mention by sebastien and anita, any UCD used as column description in one dataset can be used as header or global metadata in another dataset, and some times an association between these two uses must be performed. To my feeling the answer already exist in the VOTable structure. UCDs exist in two class, FIELD and PARAM. And it is obvious that they are specialization of a more general class which could be called vardescr (variables descriptors). In the particular case of PARAM instances, the values are attached to the description, while for the FIELD the data link is more loosely. Adressing this more general class would certainly facilitate the association between global/header metadata and column description. The main problem is that UCD are historically concerned with column descriptors and so cover very well this field of interest but it is not obvious how exhaustive are the existing UCD to cover the needs of global metadata used in headers (Fits) or definitions (VOTable). I hope that these comments are not out of scope, and that the expression of my feelings are not unpleasant to anybody. Sincerely yours, Pierre Didelon From dide at discovery.saclay.cea.fr Thu Mar 20 08:25:38 2003 From: dide at discovery.saclay.cea.fr (DIDELON Pierre) Date: Thu, 20 Mar 2003 17:25:38 +0100 (MET) Subject: UCDs status and perspectives Message-ID: <200303201625.h2KGPcu07938@rosetta.saclay.cea.fr> > From Markus.Dolensky at eso.org Thu Mar 20 17:01:00 2003 > To: DIDELON Pierre > CC: ucd at ivoa.net > Subject: Re: UCDs status and perspectives > > Hi Pierre, > > I couldn't agree more on the notion of your second point: > > > 2) Adding UCD. > > > > As Patricio said, "the problem is not to add more UCDs", everbody > > would agree on that, but it is certainly _how_ to perform > > the metadata bank update, when _really_ needed. > > A very strict and tedious approvment by an "expert group", > > as proposed in sebastien's doc, is certainly not appropriate > > for a lot of cases, where quick even instantaneous > > response is needed. > > Once more, migrating to parametrized atomic Descr (PAD?), > > will perhaps facilitate their dynamic handling. > > It would be great if we could agree on some rules for using UCDs rather > than looking at them individually. I totally agree. What I had in mind is not a traduction one by one of all the existing UCD, but the definition of atoms and parameters which allow to handle the existing UCD in a more flexible way. So, PAD can point to UCD, but the reverse would perhaps not always be true. But it is not clear to me, if the two systems coexists in the future, which will be the needs of update synchronism and joined maintenance! >...This might not be fully in line with > the original idea when UCDs were invented as some sort of table column > identifiers. The scope, however, is much broader now That's why PAD is perhaps more appropriate than UCD, because we no longer deal only with column descriptors but with _global_ metadata. >...- it's about meta > data in a more general sense. We need them in the registry, as query > specifiers, as a way for interpreting VOTable docs, as tags in data > models, ... > > Markus > Sorry for being unclear with rough english, cordially, Pierre From borne at rings.gsfc.nasa.gov Tue Mar 25 14:30:55 2003 From: borne at rings.gsfc.nasa.gov (Kirk Borne) Date: Tue, 25 Mar 2003 17:30:55 -0500 (EST) Subject: UCDs status and perspectives Message-ID: <200303252230.RAA09366@rings.gsfc.nasa.gov> Ray: I believe that your suggestions carry a lot of merit. I had a nagging feeling when reading Jonathan's comments that our metadata efforts could easily diverge (as you suggest) if we are not careful. The data model is key to this -- consequently, the ability of XML Schema to carry the knowledge about both the data model and the metadata relationships, using standardized techniques, makes a lot of sense -- especially with regard to reconciling the two metadata approaches that you mention. I think that disaster can be averted, and Jonathan's and your suggestions can illuminate the way. The PHOT_FLUX(PHOT_BAND_ID) is an excellent example of the problem and a good solution. - Kirk > Date: Tue, 25 Mar 2003 15:15:13 -0600 (CST) > From: Ray Plante > To: ucd at ivoa.net > Subject: Re: UCDs status and perspectives > > We have been bouncing around in our community two models for tagging > metadata that we will eventually need to reconcile. One is essentially > XML-based and the other is based on the current UCD set. The former makes > the most sense for descriptions stored in a registry, while the latter is > useful for tagging a set of data (e.g. in a table column). Both are > important and necessary. Both reflect a common data model. However, it > would inconvenient if not disasterous if there were not a direct > correlation between to two representations. > > I feel the answer can be found in existing XML technologies. I would > claim that the atomic descriptors being discussed (PAD, PCD, etc.) are > really just a short hop from an XML model. The main thing that PCD has > in common with XML tags is that both are essentially pointers into a > data model. The main difference between them is that with a UCD/PCD, we > need that pointer to be representable as a simple string (e.g. that can be > put in the ucd attribute in a VOTable). > > XML has such a pointer; it's called an XPath. If we define the data > model as an XML Schema, then our UCD/PCDs fall right out. There are other > advantages: > * XML Schema provides a machine readable form for a data dictionary. > * The extensibility of XML schemas provides the extensibility for > UCDs automatically. > * When necessary, metadata in direct XML form (as envisioned in a > registry) into UCD-tagged VOTable data. > * The modeling that Jonathan proposed is largely still applicable. > * The approach is consistant with the data modeling activities that > have been done to date. > > As an example, consider the example Jonathan cited: > > > For instance the two UCDs PHOT_FLUX_RADIO_1.4G > > and PHOT_FLUX_RADIO_1.6G would map to a single PCD > > PHOT_FLUX(PHOT_BAND_ID) with PHOT_BAND_ID taking the values 1.4 GHz and > > 1.6 GHz. > > Suppose a data model defined more or less in the following way: > > > > > > Secondly, however, how much can be done 'seamlessly' based on the > existing, working CDS UCD system? It is important to keep that going, not > just because astronoemrs depend on it and want to see it do these things > they hear about in reports from VO meetings, but because we need to test > developments on the community as much as possible, and we will find > subjects much more easily if we can give people prototypes which look as > familiar as possible (as with the AVO demo). Also many new functions e.g. > the SED tool and VOPlot are being developed based on the existing UCDs. I completely agree. It will take some time to shake out a refactored model that covers everything already in the current UCDs. Therefore, we will need a mechanism for continuing to support UCDs as they are now. It's important to note that the current UCDs represent the most practical use-case as they were drawn directly from real catalogs. As we build up more complicated models, e.g. photometry measurements, even images, we will need to make sure that the relevent UCD concepts are covered. In fact, that could be made a formal of the definition process. cheers, Ray From roy at cacr.caltech.edu Wed Mar 26 08:19:13 2003 From: roy at cacr.caltech.edu (Roy Williams) Date: Wed, 26 Mar 2003 08:19:13 -0800 Subject: Fw: UCDs and XML Message-ID: <003a01c2f3b3$727a2be0$6601a8c0@roxy> My thinking on UCD is going around the idea of "recognition". In writing code for VO applications, I am looking for specific UCDs. Reading the result of a cone search means finding the POS_EQ_RA_MAIN. Reading the result of a SIAP means looking for the UCD called VOX:Image_AccessReference. Therefore it should be allowed to have multiple UCDs describing the same attribute, so that different applications can recognize and use it. One person sees a galaxy, another sees a database record, another sees clip-art -- but it's all the same entity underneath. This recognition idea allows us to use UCD to subclass objects. If I have a table from a cone search, then it must have UCDs corresponding to RA, Dec, ID. Let us subclass this, for example, to a service that returns black-hole candidates. In this case, we would expect further UCDs to be present: BH_mass and BH_Spin. There is a lot that can be done with UCD, and the real question is how to allow this semantic flexibility to blossom, but without having everyone make their own UCD and losing all interoperability! Roy --- Caltech Center for Advanced Computing Research roy at cacr.caltech.edu 626 395 3670 From jcm at head-cfa.cfa.harvard.edu Mon Mar 24 19:43:19 2003 From: jcm at head-cfa.cfa.harvard.edu (jcm at head-cfa.cfa.harvard.edu) Date: Mon, 24 Mar 2003 22:43:19 -0500 (EST) Subject: UCDs status and perspectives Message-ID: <200303250343.h2P3hJN18502@urania.cfa.harvard.edu> Dear UCD list, Following the discussion of last week, I append below some notes on a controlled vocabulary related to UCDs that I sent to Sebastien some time ago. It represents a more radical change than most people are probably ready to go for, but I think it may be relevant to the current discussion. - Jonathan McDowell -------------------------------------------------------------------- I've been thinking a lot this week about UCDs and their possible role in VO data models. My conclusion is that while the present design of UCDs is very useful for the catalog cross matching problem, we need a somewhat more flexible data dictionary to handle the data analysis problem. I think we need both kinds of dictionary, with of course a mapping between the two for the applications that need the appropriate ones. Specifically, I propose to parallel the UCDs with PCDs (Parameterized Content Descriptors). These differ from UCDs in that they can include functional parameters. For instance the two UCDs PHOT_FLUX_RADIO_1.4G and PHOT_FLUX_RADIO_1.6G would map to a single PCD PHOT_FLUX(PHOT_BAND_ID) with PHOT_BAND_ID taking the values 1.4 GHz and 1.6 GHz. This reflects the fact that PHOT_FLUX_RADIO_1.4G and PHOT_FLUX_RADIO_1.6G do not really describe fundamentally different physical quantities. The PCD also differ from UCD in that they are organized to form the bottom level attributes of a structured data model for astronomy, so the top level domains are different from the UCDs. So far my proposed main PCD fields are (1) about the universe PHYS Physical data which is true generally and not a property of a specific astronomical location or object. POP Properties of a population of astronomical objects SAMPLE Properties of a sample of sources. OBJ The things we study are astronomical objects in space (with more or less defined boundaries). MED To understand the physics of these objects we describe the physical medium constituting them, including matter (solid, liquid, gas, plasma), radiation, and electromagnetic, gravitational and other fields. LOS A direction on the sky we observe corresponds to a line of sight along which objects may lie. (2) about our observations of the universe SRC When we have a dataset, we can identify a subset of that dataset as a source, which we can identify with an object. PCDs are SRC when they are to do with the direct measurements of an object with a telescope, and OBJ when they are to do with the intrinsic properties of the object (in its rest frame, without LOS effects etc). BKG A special sort of source we call the background OBS We have to describe things to do with the observing instrument, configuration and conditions. (a major subset is OBS_COV_ which ) SURVEY_ A group of observations SRC_PHOT We measure the absolute intensity of radiation from the sky SRC_SPEC Like PHOT, but dealing with many photon energies at once? EVENT A detected photon or background event _POS Information about positions (also OBJ_POS etc) _TIME Information about times (also in OBS_COV_TIME...?) (3) about our analysis of the observations DATA We also need to describe things about the datasets themselves. REFER Bibliographic info Below I give my first attempt at mapping the UCDs to a data model oriented set of PCDs. There are quite a few UCDs that I still have to understand by looking at their actual use in catalogs, so this is only a sketch and some are left blank. At the end I give the beginnings of extra UCD/PCD names needed for X-ray astronomy datasets. Appendix 1: A possible list of PCDs to be the data model equivalent of UCDs. Given in UCD alphabetical order. PHYS_AT_ AT Atomic Data PHYS_AT_COLL AT_COLL Atomic Collisional Quantities PHYS_AT_COLL_RATE AT_COLL_EXCIT-RATE Collisional Excitation Rate # Is this an atom prop or a line prop? PHYS_AT_COLL_STRENGTH AT_COLL_STRENGTH Collisional strength PHYS_AT_CONFIG . AT_CONFIG Electronic Configuration PHYS_AT_CONST? AT_CONSTANT Atomic Constant PHYS_AT_DAMPING_ AT_DAMPING Atomic Damping Quantities PHYS_AT_DAMPING_VDW AT_DAMPING_VDWAALS Van der Waals damping ? AT_DATA Various Atomic data PHYS_AT_DEGEN? AT_DEGENERACY Atomic Degeneracy Parameter PHYS_AT_DIPOLE_? AT_DIPOLE Atomic Dipole ? AT_DIPOLE_MISC Atomic Dipole PHYS_AT_DIPOLE_MOMENT AT_DIPOLE_MOMENT Atomic Dipole Moment PHYS_AT_EIGENVECTOR AT_EIGENVECTOR Atomic Eigenvector PHYS_AT_ELECCOEFF AT_ELEC-COEFF Atomic Electric Coefficient PHYS_AT_ELEMENT AT_ELEMENT Atomic Element Name or number, eventually with ionization stage # See also PHYS_AT_Z PHYS_PLASMA_EMISSIVITY_AT AT_EMISSIVITY Atomic Emissivity #What does this mean? It's a function of physical conditions. #It's a property of the plasma expressed on a per-atom basis. #So it's not PHYS_AT_EMISSIVITY but #eg PHYS_PLASMA_EMISSIVITY_AT(Z,T,n) PHYS_AT_ENERGY_ AT_ENERGY Atomic Energy or Potential #Heterogeneous class? PHYS_AT_TRANS_NAME AT_ENERGY_BAND Atomic (molecular) Energy Band PHYS_AT_TRANS_ENERGY_DISCREPANCY AT_ENERGY_DIFF Energy difference between experimental and calculated quantities PHYS_AT_TRANS_ENERGY AT_ENERGY_EXCIT Excitation Energy PHYS_AT_STATE_ENERGY_IONIZATION AT_ENERGY_IONIZ Ionization Energy or Potential PHYS_AT_STATE_ENERGY(LEVEL) AT_ENERGY_LEVEL Energy Level PHYS_AT_ENERGY_FORM AT_ENERGY_FORMATION Formation energy (or heat for molecules) PHYS_AT_ENERG_POT AT_ENERGY_POTENTIAL Atomic Energy or Potential PHYS_AT_STATE_ENERGY_ROT AT_ENERGY_ROTATION Rotation Energy PHYS_AT_STATE_ENERGY_TOT AT_ENERGY_TOTAL Total atomic energy PHYS_AT_TRANS_FREQ AT_FREQUENCY Transition Frequency PHYS_AT_TRANS_FREQ_REST AT_FREQUENCY_NU Transition Frequency at rest PHYS_AT_TRANS_FREQ_ROT AT_FREQUENCY_ROTAT Rotation Frequency PHYS_AT_FS_ AT_FS Fine Structure Quantities PHYS_AT_FS_COLLSTR AT_FS_COLL-STR Fine Structure Collision Strength PHYS_AT_FS_CONST? AT_FS_CONSTANT Fine Structure Constant PHYS_AT_TRANS_FS_WIDTH AT_FS_CONTRIB Fine Structure Contribution to Line Profile PHYS_AT_TRANS_FS_SPLIT AT_FS_SPLIT Fine Structure Splitting PHYS_AT_TRANS_GA AT_GA Atomic ga value PHYS_AT_LINE_INTENSITY AT_INTENSITY Line Intensity PHYS_AT_ION_ AT_ION Ions PHYS_AT_ION_ID AT_ION_ID Ion Identification PHYS_AT_ION_STAGE AT_ION_STAGE Ionization Stage PHYS_AT_LANDEFACT AT_LANDE-FACT Lande Factor (gf) PHYS_AT_LEVEL AT_LEVEL Level Identification PHYS_AT_STATE_LIFE AT_LIFETIME Radiative Lifetime PHYS_AT_LINE_ AT_LINE Atomic or Molecular Lines # What is the difference between LINE and TRANS? PHYS_AT_LINE_EMISSIVITY AT_LINE_EMISSIVITY Line Emissivity PHYS_AT_LINE_FLOURYIELD AT_LINE_FLUOR-YIELD Line Fluorescence Yield PHYS_AT_LINE_ID AT_LINE_ID Line Identification PHYS_AT_LINE_STRENGTH AT_LINE_STRENGTH Line Strength PHYS_AT_LINE_MAIN-TERM? AT_MAIN-TERM Main Term PHYS_AT_MOL_ AT_MOL Quantities Related to Molecules PHYS_AT_MOL_DIELFN AT_MOL_DIEL-FN Molecular Dielectric Function PHYS_AT_MOL_EDISSOC AT_MOL_DISS-ENRGY Molecular Dissociation Energy PHYS_AT_MOL_ID AT_MOL_ID Molecule Identification PHYS_AT_TRANS_MOL_LEVEL AT_MOL_LEVEL Molecule Transition Level PHYS_AT_MULTIPLET_ AT_MULTIPLET Quantities Related to Multiplets PHYS_AT_MULTIPLET_ID AT_MULTIPLET_ID Multiplet Identification PHYS_AT_MULTIPLET_N AT_MULTIPLET_N Multiplet Number element PHYS_AT_Z AT_NUMBER Atomic Number PHYS_AT_OSC_ AT_OSC Oscillator Related Quantities PHYS_AT_OSC? AT_OSC_STRENGTH Oscillator Strength PHYS_AT_PARITY AT_PARITY Atomic Parity PHYS_AT_Q_ AT_Q-N Atomic Structure, Quantum Numbers PHYS_AT_Q_L AT_Q-N_ANG-MOM Angular Momentum Quantum Number PHYS_AT_Q_K AT_Q-N_K K quantum number PHYS_AT_Q_UNK AT_Q-N_MISC Atomic Structure Quantum Number PHYS_AT_Q_ORB AT_Q-N_ORBITAL Orbital Quantum Number PHYS_AT_Q_PRIN AT_Q-N_PRINCIPAL Principal Quantum Number PHYS_AT_Q_PRIN1 AT_Q-N_PRINCIPAL_FIRST First Principal Quantum Number PHYS_AT_Q_PRIN2 AT_Q-N_PRINCIPAL_SECOND Second Principal Quantum Number PHYS_AT_Q_ROT AT_Q-N_ROTATIONAL Rotational Quantum Number PHYS_AT_Q_TOR AT_Q-N_TORSIONAL Torsional Quantum Number PHYS_AT_Q_VIB AT_Q-N_VIBRATIONAL Vibrational Quantum Number PHYS_AT_REACTION AT_REACTION Atomic Reaction PHYS_AT_SHELL AT_SHELL-NUMBER Shell Quantum Numbers PHYS_AT_SPECIES_LIST AT_SPECIES Atomic Species Participating in a Reaction PHYS_AT_TRANS_STARK_ AT_STARK Stark Effect PHYS_AT_TRANS_STARK_BROAD AT_STARK_BROAD Broadening due to Stark Effect PHYS_AT_TRANS_STARK_INT AT_STARK_INTENSITY Intensity due to Stark Effect PHYS_AT_TRANS_SWEIGHT AT_STAT-WEIGHT Statistical Weight PHYS_AT_TRANS_WIDTH? AT_STRENGTH-PARAM Strength Parameter or Expect Width PHYS_AT_TRANS AT_TRANS Quantities Related to Transitions PHYS_AT_TRANS_BRANCH AT_TRANS_BRNCH-RATIO Transition Branching Ratio PHYS_AT_TRANS_ENERGY AT_TRANS_ENERGY Transition Energy (or wave number) PHYS_AT_TRANS_ID AT_TRANS_ID Transition Identification PHYS_AT_TRANS_LEVELS AT_TRANS_LEVELS Transition Level PHYS_AT_TRANS_PROB AT_TRANS_PROB Transition Probability PHYS_AT_TRANS_STRENGTH AT_TRANS_STRENGTH Transition Strength PHYS_AT_TRANS_TYPE AT_TRANS_TYPE Transition Type PHYS_AT_TRANS_RECOMB AT_TRANS_RECOMBIN Recombination coefficients in atomic transitions PHYS_AT_TRANS_LAMBDA AT_WAVELENGTH Laboratory or Theoretical Line Wavelength PHYS_AT_WEIGHT AT_WEIGHT Atomic Weight OBJ_CLASS+ CLASS Various Classification Descriptors OBJ_CLASS_CODE CLASS_CODE Classification Code OBJ_CLASS_COLOR CLASS_COLOR Color Classification OBJ_CLASS_STAR_MK_TYPE OBJ_CLASS_CLG_DIST CLASS_DISTANCE Abell Distance Class OBJ_CLASS CLASS_MISC Various Classification Descriptors OBJ_CLASS CLASS_OBJECT Object Type Classification OBJ_CLASS_CLG_RIC CLASS_RICHNESS Abell Richness Class OBJ_CLASS_UNK_GAL CLASS_STAR/GALAXY Star galaxy discriminator or classification. OBJ_CLASS_UNK_BM CLASS_STRUCT Structure Classification (e.g. cluster Bautz-Morgan classification) _CODE CODE Codes or Flags _ERROR_CODE CODE_ERROR Flag denoting uncertainty about a given quantity _FLAG_LIMIT CODE_LIMIT Lower or Upper limit Flag _FLAG_MEMB CODE_MEMB Membership Code _CODE CODE_MISC Miscellaneous Codes or Flags OBJ_CLASS_MULT CODE_MULT Codes related to Multiplicity (particularly stars) OBJ_CLASS_MULT CODE_MULT_FLAG A code or flag indicating a multiplicity of binarity OBJ_CLASS_MULT_N CODE_MULT_FREQUENCY Multiplicity Frequency Code OBJ_CLASS_MULT_N CODE_MULT_INDEX Multiplicity Index Code _QUAL CODE_QUALITY Quality Code OBJ_CLASS_VAR CODE_VARIAB Variability Code or Flag DATA_ DATA Quantities Related to the Data _SCALE_EXP DATA_FACTOR-EXP Scale Factor Exponent (Base 10) DATA_LINK DATA_LINK Link to additional data (in VizieR or any other database) _MAX DATA_MAXIMUM Maximum data value found in a database column _SCALE DATA_SCALE-FACTOR Factor to Convert a Data Column to a normal value _DATATYPE DATA_TYPE Data Type DYN_ DYN Dynamic Data Quantities (mixed column content) DYN_QUANTITY DYN_QUANTITY Used when a Column means more than one thing. DYN_VALUE DYN_VALUE Identification of a Dynamic Value _ERROR ERROR Error or Uncertainty in Measurements POS(,EQ)_RA_ERROR ERROR # I/176 POS(,EQ)_DEC_ERROR ERROR # I/176 PHOT_FLUX(5 GHz)_ERROR ERROR # VIII/14 SRC_REG EXTENSION Quantities used to describe the extension in the sky of objects SRC_REG_AREA EXTENSION_AREA Angular Area Covered by an Object SRC_REG_DIA_DEC EXTENSION_DEC Angular Extension in Declination SRC_REG_DIA EXTENSION_DIAM Angular Diameter or Size of the Major Axis SRC_REG_DIA_FWHM EXTENSION_FWHM Angular Full Width at Half Maximum (FWHM) SRC_REG_DIA_FWHM EXTENSION_FWHM_CIRC Angular Full Width at Half Maximum (FWHM) SRC_REG_DIA_MAJ_AXIS_FWHM EXTENSION_FWHM_MAJ Angular FWHM along the Major Axis SRC_REG_DIA_MIN_AXIS_FWHM EXTENSION_FWHM_MIN Angular FWHM along the Minor Axis SRC_REG_DIA_MIN_AXIS_FWHI EXTENSION_HALFINT Angular Size at Half Intensity along the Minor Axis SRC_REG_DIA_MIN_AXIS EXTENSION_MIN Angular Diameter of an object along the Minor Axis SRC_REG_DIA_BEAMS EXTENSION_NORM Angular diameter normalized to beam size SRC_REG_DIA_RA EXTENSION_RA Angular extension in right ascension SRC_REG_RADIUS EXTENSION_RAD Angular radius of an object or Semi-major axis SRC_REG_RADIUS_SCALELENGTH EXTENSION_SC-LENGTH Angular Scale Length (bulge or disk) SRC_REG_RADIUS_MIN_AXIS EXTENSION_SMIN Angular size of Semi-Minor Axis _FIT FIT Fits of Models to Observational Data _FIT_ERR FIT_ERROR Fit Error _FIT_GOODNESS FIT_GOODNESS Fit Goodness _FIT_ID FIT_ID Identification of the fit or solution POP_LF FIT_LF Luminosity function POP_LF_FIT_PARAMS FIT_LF Fit of Luminosity Function POP_LF_FIT FIT_LF_GENERAL Fit of Luminosity Function POP_LF_FIT_MAG? FIT_LF_MAG Magnitudes related to the LF POP_LF_FIT_MAG_MAX FIT_LF_MAG_MAX Magnitude interval upper limit POP_LF_FIT_MAG_MIN FIT_LF_MAG_MIN Magnitude interval lower limit _FIT_RATIO FIT_MEAS/THEOR Ratio of Measurement to Theoretical Value _FIT_PAR FIT_PARAM Fit Parameter _FIT_PAR_ID FIT_PARAM_ID Fit Parameter Identification _FIT_MISC FIT_PARAM_MISC Miscellaneous fit parameters POS(,EQ)_RA_STAT_SIGMA FIT_PARAM_MISC # In I/176 S0RA, FIT_PARAM_MISC is the sigma-0 (?) for the RA _FIT_COVAR FIT_PARAM_COVAR Covariance of the fitting parameter _FIT_RESID FIT_RESIDUAL Fit Residual _FIT_CHI2 FIT_CHI2 Chi-square Fit Measurement _FIT_SIGMA FIT_STDEV Fit's Standard Deviation _FIT_TYPE FIT_TYPE Fit or Solution Type POS(,EQ)_FIT_TYPE FIT_TYPE I/176 _ZERO FIT_ZP Fit Zero Point (mostly in linear fits) PHOT_COL_INDEX_DIFF FIT_ZP # In III/218 DIFF, FIT_ZP is the scatter in mag of the spectroscopic index POS(,EQ)_DEC_STAT_SIGMA FIT_ZP # In I/176 S0DE, FIT_ZP is the sigma-0 (?) in arcseconds? for the Dec - ID Fields Used as Identifiers OBJ_ID_ALT ID_ALTERNATIVE Alternative identification OBJ_ID_FIELD ID_AREA Area Identification (usually in a photographic plate) SRC_ID_XID ID_ASSOCIATED Identification of Associated Object (counterpart) SRC_ID_AUTHOR ID_AUTHOR Author Name SRC_ID_CAND ID_CANDIDATE Candidate Identification SRC_ID_CAT ID_CATALOG Catalog Identification SRC_ID_FCHART ID_CHART Finding Chart Identification SRC_ID_COMP ID_COMPARISON Name of a Comparison Object SRC_ID_CONSTEL ID_CONSTEL Constellation Name SRC_ID_XID ID_CROSSID Cross Identification (counterpart) OBS_DB_ID ID_DATABASE Database Identification OBS_DS_ID ID_DATASET Data-Set Identification OBS_EXP_ID ID_EXPOSURE Exposure Identification INST_FIBER ID_FIBER Fiber Optics Identification (for M.O.S.) OBS_FIELD ID_FIELD Field Identification SRC_NOTES_FIG ID_FIGURE Figure Identification Number SRC_NOTES_FILE ID_FILE File Identification SRC_NOTES_FRAME ID_FRAME Frame Identification ? ID_GROUP Group Identification OBS_AUTHOR_CODE ID_HUMAN Identification of Discoverer or Observer SRC_DISCOVERER_CODE ID_HUMAN SRC_ID_INTERNAL ID_IDENTIFIER Identification of a source or object, incomplete or for internal use. OBS_IMAGE_ID ID_IMAGE Image Identification SRC_ID (or OBJ_ID?) ID_MAIN Main Identifier of a Celestial Object SRC_ID:1 ID_MAIN:1 First component of an identification field. SRC_ID:2 ID_MAIN:2 Second component of an identification field. SRC_ID:3 ID_MAIN:3 Third component of an identification field. ? ID_MAP Map Identification SRC_CAT_ID ID_NUMBER Numeric Identification (usually sequential) ? ID_PARAM Identification or name of a parameter, or the name of a column in a table SRC_PARENT ID_PARENT Parent Identification (galaxy, cluster, nebulae) OBS_PLATE ID_PLATE Plate Identification OBS_REGION_ID ID_REGION Region Identification (not necessarily sky region) OBS_SET_ID ID_SET Set or Subset Identification, also bin or sample number OBS_SITE_ID ID_SITE Site/Location/Observatory/City/Country identifier INST_APER_ID ID_SLIT Slit Identification (usually in the context of M.O.S.) # Hmm MOS have many apertures, 1 disperser? SRC_ID_SURVEY ID_SURVEY Survey Identification SRC_ID_TABLE ID_TABLE Table Identification SRC_ID_TARGET? ID_TARGET Target Identifier OBJ_CLASS_VAR? ID_VARIAB Variable Object Identification DATA_PROC_SYS_VER ID_VERSION Identification of the software version. ? ID_VOLUME Volume Identification ? ID_ZONE Durchmusterung zone identification/sign INST_ INST Instrumental Quantities - INST_ANG Angular Properties of the Instruments/Telescopes SRC_OFFAX INST_ANG_OFFAXIS Off-axis angle respect to main direction of observation # Presumably the instrument coords of a source, not a prop of the instru OBS_SITE_ORBIT_PHASEANG INST_ANG_PHASE Satellite phase angle INST_RESP_SPATIAL_RES INST_ANG_RESOL Angular resolution of instrument OBS_SITE_ORBIT_ANGVEL INST_ANG_VEL Satellite angular velocity INST_DET_NOISE_TANT INST_ANTENNA-TEMP Antenna temperature INST_GEOM_DIA INST_APERT Instrument/telescope aperture INST_GEOM_AREA INST_AREA Collecting area or detector area PHOT_BKG_INST INST_BACKGROUND Background contribution INST_COV_BAND INST_BAND Instrumental Band quantities INST_CAL_BAND_DRIFT INST_BAND_DRIFT Band's drift rate INST_COV_BAND_TRANS? INST_BAND_PASS Bandpass INST_COV_BAND_WIDTH INST_BANDWIDTH Spectral window used for the observation INST_INT_BASELINE INST_BASELINE Baseline (interferometry) INST_RESP_SPATIAL INST_BEAM Beam properties ? INST_BEAM_MISC Miscellaneous beam properties INST_RESP_SPATIAL_RES INST_BEAM_SIZE Beam width or size INST_DET_NOISE_TBEAM INST_BEAM_TEMP Beam temperature INST_PHOT_CAL INST_CALIB Instrument calibration quantities INST_PHOT_CAL_ERR INST_CALIB_ERROR Instrument calibration error ? INST_CALIB_MISC Miscellaneous instrument calibration quantities ? INST_CALIB_PARAM Calibration parameter ? INST_CORR-FACTOR Correction (no only correction factor) INST_DET INST_DET Detector parameters INST_PHOT_FLUX_LIMIT INST_DET_LIMIT Detector limit UNK INST_DET_MISC Miscellaneous quantities related to the detector (plate or CCD) INST_GEOM_SIZE INST_DET_SIZE Detector size # number of pixels, vs DET_SIZE with mm size INST_DISP_SCALE INST_DISPERSION Dispersion scale in a spectrograph INST_QE INST_EFFICIENCY Instrument efficiency PHOT_ERR_INST INST_ERROR Errors associated to the instrument INST_FILTER INST_FILTER Filter characteristics INST_FILTER INST_FILTER_CODE Filter characteristics type/code INST_COV_BAND_FWHM INST_FILTER_FWHM FWHM of the used filter (also bandpass) INST_COV_BAND_TRANS INST_FILTER_TRANSM Transmission characteristics of the filter (response) INST_NAME INST_ID Instrument/Detector Identification INST_LINE_WIDTH INST_LINE-WIDTH Instrumental Line-Width INST_DET_NOISE INST_NOISE Detector/Instrument noise level rms INST_PARAM? INST_PARAM Various Instrumental Parameters INST_GEOM_PIX_SIZE INST_PIXSIZE Pixel Size # distinguish pix size in mm and arcsec INST_DET_PLATE INST_PLATE Quantities related to Photographic Plates INST_DET_SIZE INST_PLATE_DIMENSION Size or plate dimension # Is the fact that it's a plate relevant? could be any detector SRC_OFFSET_PIX INST_PLATE_DIST Distance measurement on a plate # ? distance between two sources in pixels? INST_DET_PLATE_EMULSION INST_PLATE_EMULSION Plate Emulsion Type # Now we care about it being a plate, only plates have emulsion SRC_REG_DIA_PIX INST_PLATE_EXTENSION Extension of an object in a plate (in plate units) INST_DET_POS INST_POS Position on a detector or M.O.S template INST_PHOT_PRECISION INST_PRECISION Instrumental Precision # Presumably photometric? INST_RESP_SPATIAL INST_PSF Detector's Point Spread Function (PSF) INST_DET_QE INST_QE Detector's Quantum Efficiency SRC_DET_SN INST_S/N Instrumental signal to noise ratio (S/N) # What does this mean? The S/N for a particular source? INST_RESP_TIME_RES INST_SAMP-TIME Instrumental Sampling Time INST_GEOM_SCALE INST_SCALE Instrumental Scale (ccd or plate) # In arcsec/mm? otherwise pixel size INST_RESP_SPATIAL_RES INST_SEEING Seeing or fwhm of PSF INST_PHOT_FLUX_LIMIT INST_SENSITIVITY Detector's Sensitivity (Flux limit) INST_SETUP INST_SETUP Instrument configuration or set-up - INST_SKY Instrumental Sky Properties PHOT_COUNTS_SKY? INST_SKY_LEVEL Local Sky Level PHOT_TEMP_SKY INST_SKY_TEMP Sky Temperature PHOT_TEMP_SIGMA_SKY INST_SKY_SIGMA Sigma of sky value distribution - INST_SPECT Spectroscopic instruments' quantities INST_COV_BAND_LAMBDA_RANGE INST_SPECT_BAND Spectroscopic observation band INST_DISP_TYPE_CODE INST_SPECT_CODE Spectroscopic instrument specification (prism, grism, grating) INST_DISP_ORDER INST_SPECT_ORDER Spectral Order INST_DISP_SLIT_DX INST_SPECT_SLIT-LENGTH Slit Length INST_DISP_SLIT_DY INST_SPECT_SLIT-WIDTH Slit Width - INST_TEMP Instrument Temperature (radio regime) INST_DET_NOISE_TBEAM INST_TEMP_BEAM Beam Temperature or Brightness # TEMP_BEAM is a way of describing the instrument noise INST_DET_TSYS INST_TEMP_SYST System Temperature INST_DET_TRIGGER? INST_TRIGGER Detector's triggering Threshold INST_TYPE INST_TYPE Instrument Type INST_COV_BAND_VEL? INST_VELOC Velocity Quantities at the Instrumental Level INST_COV_BAND_VEL0 INST_VELOC_CENTRAL Instrumental Central Velocity INST_COV_BAND_VEL_RES INST_VELOC_SPACING Instrumental Velocity Channel Spacing INST_COV_BAND_VEL_RANGE INST_VELOC_WINDOW Detector's Velocity Range OBS_COV_BAND_LAMBDA INST_WAVELENGTH Observation's Wavelength properties # We should distinguish between the wavelength coverage designed into an instrument # and the wavelength coverage of a specific observation, I think the latter is meant here. OBS_COV_BAND_LAMBDA_RANGE INST_WAVELENGTH_COVERAGE Instrument's Wavelength Range OBS_COV_BAND_LAMBDA_EFF INST_WAVELENGTH_EFFECTIVE Observation's Effective Wavelength OBS_COV_BAND_LAMBDA INST_WAVELENGTH_VALUE Wavelength related to an instrument, filter, etc. MUTUAL_OCCULT(*OBJ) - MUTUAL_OCCULT(L) LUNAR-OCCULT Lunar Occultaion related quantities # Occultations of anything could have the same parameters. So let's specify that # it's lunar by an argument L, and generalize eg # MUTUAL_OCCULT(PLUTO)_ANG MUTUAL_OCCULT(L)_ANG LUNAR-OCCULT_ANGLE Lunar Occultation Contact Angle MUTUAL_OCCULT(L)_FRAC LUNAR-OCCULT_FRACTION Percentage of the moon illuminated during the time of occultation MUTUAL_OCCULT(L)_LIMBSLOPE LUNAR-OCCULT_LIMB-SLOPE Lunar Occultation Limb Slope _MODEL MODEL Quantities generated by Models SPEC_CONT_FLUX MODEL_CONTINUUM Continuum level _CORR MODEL_CORRECTION Correction or adjustment OBJ_VEL_DRIFT MODEL_DRIFT-VELOC Terminal drift velocity OBJ_GEOM_TRIAX MODEL_DYN-TRIAX Dynamical triaxiality ? MODEL_ENERGY Energy modeled quantities SPEC_SED_MODEL MODEL_ENERGY_DIST Energy distribution PHYS_BULK_EOS MODEL_EOS Equation of state PHYS_BULK_EOS_ID MODEL_EOS_ID Name of used equation of state LOS_ISM_EXT MODEL_EXTINCTION Interstellar extinction quantities LOS_ISM_EXT_COEFF MODEL_EXTINCTION_COEFF Insterstellar extinction coefficient # Extinction coeffs and other theory are always 'model'. _MODEL_FEATURE MODEL_FEATURE Model Feature PHOT_FLUX_MODEL MODEL_FLUX Modeled Flux _MODEL_ID MODEL_ID Model Identification SPEC_LINE_FLUX_MODEL MODEL_LINE-FLUX Model Spectral Line Flux PHOT_MAG_MODEL MODEL_MAG Model-generated Magnitude _MODEL_DIFF MODEL_MAG_CORR Magnitude Correction or Difference _MODEL MODEL_MAG_VALUE Magnitude (in any band) generated by a model (or templates) ? MODEL_MOMENT-FLUX-RATIO Moment Flux Ratio _MODEL_PARAM MODEL_PARAM Model Parameter POP_SPEC_SYNTH MODEL_POP-SYNTHESIS Population Synthesis Quantity _MODEL_RESIDUAL MODEL_RESIDUAL Model Residual _MODEL_RESULT MODEL_RESULT Model Solution Value _MODEL_TYPE MODEL_TYPE Model Type PHYS_AT_TRANS_ZEEMAN MODEL_ZEEMAN Zeeman Effect Quantities PHYS_AT_TRANS_ZEEMAN_CO MODEL_ZEEMAN_COEFF Zeeman Effect Coefficient OBJ_CLASS_MORPH? MORPH Morphology of celestial objects OBJ_CLASS_GAL_ARMS MORPH_ARMS Spiral Arms Structure (galaxies) OBJ_CLASS_GAL_ARMS_RATIO MORPH_ARMS_RATIO Ratio of Spiral Arm (galaxies) OBJ_CLASS_GAL_ARMS_WOUND MORPH_ARMS_WOUND Wound Parameter of a spiral arm galaxy OBJ_CLASS_GAL_ASYM MORPH_ASYMMETRY Asymmetry Induced by Rotation OBJ_CLASS_GAL_BAR MORPH_BAR Presence or detection of a bar in a galaxy OBJ_CLASS_MORPH_CODE MORPH_CODE Code refering to a morphological property OBJ_CLASS_MORPH_PARAM MORPH_PARAM Morphological (geometrical) parameter OBJ_CLASS_MORPH_TYPE MORPH_TYPE Morphological Type _NOTE NOTE A Note related to a certain quantity or value _N NUMBER Number Of ``things'' (stars, observations, etc.) OBJ(*OBJ) - Specific object OBJ(E)_NUT NUTATION Earth's Nutation Related Quantities OBJ(E)_NUT_ANGLE NUTATION_PARAM Nutation Parameter # I'm guessing this is the angle _OBS ? OBS Observational Quantities SRC_REG_DIA OBS_ANG-SIZE Observational angular size OBS_INST_BAND OBS_BAND Band or Filter used for the observation PHOT_CAL OBS_CALIB Calibrations related to observations PHOT_CAL_ZERO OBS_CALIB_CONST Calibration's Constant PHOT_CAL_SCALE OBS_CALIB_FACTOR Calibration conversion factor # This is heterogeneous...I'm guessing flux cal is meant here, but # need ones for wave cal too etc OBS_ID OBS_CODE Observation code for observing run OBS_SITE_CONDS OBS_CONDITIONS Observation condition PHOT_LIMIT OBS_DETECT-LIMIT Detection Limit # This is a property of a region of an observation - you may have an upper limit # at a point or a single detection limit for a whole field, it's the same thing # (so note there is an association between limit and region) # It may have suffix of bandpass SRC_DET_SIG OBS_DETECT-SIGNIF Detection Significance # This is a property of a detected source _DIFF OBS_DIFF Observations' offset, difference, or deviation # Append to UCD of whatever is offset OBS_POS_UNC_DRIFT OBS_DRIFT Positional drift during the observation OBS_COV_BAND_FREQ OBS_FREQUENCY Frequency of the observation OBS_ID OBS_ID Observation identification # Comment: OBS_ mixes observation conditions and observed quantities. SPEC_LINE_WIDTH_G OBS_LW Observed gaussian line-width OBS_METHOD OBS_METHOD Observational Method/Technique UNK OBS_OTHER Other Measurements # Comment: useless? OBS_PARAM ? OBS_PARAM Additional Observational Parameters OBS_PLATE ? OBS_PLATE Quantities related to measurements on plates SRC_REG_DIA? OBS_PLATE_APERT Plate (Circular) Aperture SRC_REG_DIA OBS_PLATE_EXTENSION Linear diameter of an object measured on a Plate # Comment: what does this really mean? Is this really different to a normal measured diameter? _MODEL_RATIO OBS_PRED/OBS Fraction of predicted to observed quantities # Comment: is this really different to FIT MEAS/THEORY? Need to attach to whatever UCD is being measured. OBS_RUN OBS_RUN Observation run SRC_REG_DIA OBS_SIZE Observed size # Comment: I doubt that OBS_SIZE and EXTENSION_DIAM are really different. SRC_REG_DIA_DEC OBS_SIZE_DEC Observed size in declination OBS_DISP OBS_SLIT Spectroscopic slit properties # Applies to any dispersive system, not always a slit spectrograph? SRC_DISP_Y OBS_SLIT_OFFSET Slit offset respect to the nucleus of galaxy # Comment: this is really "position of source in slit coordinates". OBS_DISP_THETA OBS_SLIT_ORIENT Slit orientation # Comment: is this "PA of slit on sky" or "orientation of slit wrt source major axis"? # I suspect the former. OBS_SPECTRUM? OBS_SPECTRUM Spectral observations OBS_TYPE ? OBS_TYPE Type of observation OBS_SITE OBSTY Data on Observatories OBS_SITE_POS_ALT OBSTY_ALTITUDE Observatory Altitude OBS_SITE_CODE OBSTY_CODE Observatory Code OBS_SITE_NAME OBSTY_ID Observatory Identification/Name ORBIT ORBIT Orbital elements (planets, double stars, galaxies) ORBIT_ELT_NODE ORBIT_ASC-NODE Longitude of ascending node ORBIT_COMET? ORBIT_COMETS Cometary orbit parameter ORBIT_CONV_ANG? ORBIT_CONV-ANGLE Convergence angle ORBIT_PERI ORBIT_DISTANCE Distance, perihelion, or separation between components ORBIT_DIST ORBIT_DISTANCE Distance, perihelion, or separation between components # Here instantaneous distance ORBIT_ELT_E ORBIT_ECCENTRICITY Orbital eccentricity ORBIT_ELONG ORBIT_ELONGATION Elongation of radiant ORBIT_FREQ ORBIT_FREQUENCY Orbital frequency (orbital angular velocity) ORBIT_ELT_M ORBIT_MEAN-ANOMALY Mean anomaly - ORBIT_P-ASTRON Quantities related to the Periastron ORBIT_ELT_AOP ORBIT_P-ASTRON_ARG Periastron argument or longitude ORBIT_ELT_TPERI ORBIT_P-ASTRON_DATE Date of occurance of periastron ORBIT_PERIDOT ORBIT_P-ASTRON_RATE Rate of periastron advance ORBIT_ELT_AOP ORBIT_P-HELION Perihelion argument or longitude - ORBIT_PARAM Orbital parameter ORBIT_PERIOD ORBIT_PERIOD Orbital period ORBIT_PDOT ORBIT_PERIOD_DERIVATIVE Time derivative of orbital period ORBIT_PHASEANG ORBIT_PHASE-ANGLE Orbital phase angle ORBIT_RV ORBIT_RV Orbital radial velocity properties ORBIT_RV_AMP ORBIT_RV_S-AMPLITUDE Semi amplitude of radial velocity curve ORBIT_DIA_PROJ ORBIT_SEPARATION Orbital Separation (angular distance) ORBIT_DIA ORBIT_SIZE Orbital size ORBIT_RADIUS ORBIT_SIZE_RADIUS Orbital radius (binary stars) ORBIT_ELT_A ORBIT_SIZE_SMAJ Semi-major axis of the orbit PHOT_ PHOT Photometry, extending to several wavelength regimes (X to Radio) PHOT_MAG_13C_ PHOT_13C 13 color system (Stellar Applications) GCPD#66 PHOT_COL(13C,33-52) PHOT_13C_33-52 Color index 33-52 (13C) PHOT_COL(13C,35-52) PHOT_13C_35-52 Color index 35-52 (13C) PHOT_COL(13C,37-52) PHOT_13C_37-52 Color index 37-52 (13C) PHOT_COL(13C,40-52) PHOT_13C_40-52 Color index 40-52 (13C) PHOT_COL(13C,45-52) PHOT_13C_45-52 Color index 45-52 (13C) PHOT_MAG(13C,52) PHOT_13C_52 Magnitude 52 (13C) PHOT_COL(13C,52-110) PHOT_13C_52-110 Color index 52-110 (13C) PHOT_COL(13C,52-58) PHOT_13C_52-58 Color index 52-58 (13C) PHOT_COL(13C,52-63) PHOT_13C_52-63 Color index 52-63 (13C) PHOT_COL(13C,52-72) PHOT_13C_52-72 Color index 52-72 (13C) PHOT_COL(13C,52-80) PHOT_13C_52-80 Color index 52-80 (13C) PHOT_COL(13C,52-86) PHOT_13C_52-86 Color index 52-86 (13C) PHOT_COL(13C,52-99) PHOT_13C_52-99 Color index 52-99 (13C) _ABS PHOT_ABS-MAG Absolute magnitude _ABS PHOT_ABS-MAG_BAND Absolute magnitude in a band, regardles of band PHOT_MAG_BOL_ABS PHOT_ABS-MAG_BOL Bolometric absolute magnitude OBS_ATM_ PHOT_ATM Earth Atmosphere Parameters Linked to Photometry OBS_ATM_AIRMASS PHOT_ATM_AIRMASS Air mass OBS_ATM_EXT PHOT_ATM_EXT Atmospheric extinction coefficient PHOT_BOL_ PHOT_BOL Bolometric Quantities PHOT_COL_BOL() PHOT_BOL_CORR Bolometric correction PHOT_FLUX_BOL PHOT_BOL_FLUX Bolometric Flux PHOT_LUM_BOL PHOT_BOL_LUMINOSITY Bolometric luminosity PHOT_MAG_BOL PHOT_BOL_MAG Bolometric magnitude SRC_IMAGE_SLOPE PHOT_BRIGHTNESS-SLOPE Spatial brightness distribution slope # This is part of a spatial flux model for a source # PHOT_COL PHOT_CI Color index in unspecified system PHOT_COL(,102-C220) PHOT_CI_102-C220 Color index 102-C220 PHOT_COL(UNK,B-R) PHOT_CI_B-R Color index B-r PHOT_COL(HALPHA,LINE-CONT) PHOT_CI_ALPHA Color index based on H-alpha line PHOT_COL(HBETA,LINE-CONT) PHOT_CI_BETA Color index beta or h-beta (not Stroemgren index) PHOT_COL(BALMER,LINE-CONT) PHOT_CI_BALMER Color index using the Balmer lines Hgamma or higher PHOT_COL(UNK,B-I) PHOT_CI_B-I Color index B-I from heterogeneous photometric systems PHOT_COL(UNK,B-K) PHOT_CI_B-K Color index B-K from heterogeneous photometric systems PHOT_COL(UNK,B-V) PHOT_CI_B-V Color index B-V in a non-conventional system PHOT_COL(,CN-TiO) PHOT_CI_CN-TIO Color index CN-TiO PHOT_COL_CODE PHOT_CI_CODE Codes associated with color index PHOT_COL_FRACT PHOT_CI_FRACT Fractional color index PHOT_COL(g,b-v) PHOT_CI_GB-GV Color index gb-gv PHOT_COL(g,u-b) PHOT_CI_GU-GB Color index gu-gb PHOT_COL(IRAS,) PHOT_CI_IR Various far IR color indices (e.g. with IRAS bands) PHOT_COL(,IR-OPT) PHOT_CI_IR-OPT Color index Infrared minus optical PHOT_COL(,M-51) PHOT_CI_M-51 Color index M-51 PHOT_COL(,R-HALPHA) PHOT_CI_R-HALPHA Color index R minus Halpha PHOT_COL(,R-I) PHOT_CI_R-I Color index R-I PHOT_COL(,U-B) PHOT_CI_U-B Color index u-B U-B PHOT_COL(,U-R) PHOT_CI_U-R Color index u-r PHOT_COL(UNK,UNK) PHOT_CI_UNDEF Color index in unspecified system PHOT_COL(,UV-OPT) PHOT_CI_UV-OPT Color index uv minus Optical (UV-OPT) PHOT_COL(,V-I) PHOT_CI_V-I Color index V-I (no standard system specified) PHOT_COL(,V-R) PHOT_CI_V-R Color index V-R (no standard system specified) ? PHOT_CLASS Classification of photometry PHOT_COL_ PHOT_COLOR Quantities related to color indices PHOT_COL_EXCESS PHOT_COLOR_EXCESS Color excess (not just E(B-V)) PHOT_RATE PHOT_COUNT-RATE Count rates in several wavelength regimes PHOT_RATE(UV) PHOT_COUNT-RATE_UV Count rate in ultraviolet PHOT_RATE(XR) PHOT_COUNT-RATE_X Count rate in x-ray PHOT_COUNTS PHOT_COUNTS Count measured in the detector PHOT_COUNTS(IUE/SWP) PHOT_COUNTS_IUE Count from IUE PHOT_COUNTS(IUE/LWP) PHOT_COUNTS_IUE Count from IUE PHOT_COUNTS PHOT_COUNTS_MISC Count measurement in the detector PHOT_COUNTS(RADIO) PHOT_COUNTS_RADIO Counts in radio regime PHOT_COUNTS(GAMMA) PHOT_COUNTS_GAMMA Count in gamma-ray regime PHOT_RATE(GAMMA) PHOT_COUNT-RATE_GAMMA Count rate of gamma photons PHOT_COUNT_RATIO PHOT_COUNTS_RATIO Ratio of photon counts, or relative counts. PHOT_COUNTS(XR) PHOT_COUNTS_X Counts in X-ray PHOT_MAG(COUS) PHOT_COUS Cousins photometric system GCPD#54 PHOT_MAG(COUS,I) PHOT_COUS_I Cousins magnitude Ic PHOT_MAG(COUS,R) PHOT_COUS_R Cousins magnitude R COUS PHOT_COL(COUS,R-I) PHOT_COUS_R-I Cousins R-I color index COUS PHOT_COL(COUS,V-I) PHOT_COUS_V-I (Kron-)Cousins V-I color index COUS PHOT_COL(COUS,V-R) PHOT_COUS_V-R (Kron-)Cousins V-R color index PHOT_MAG(DDO,) PHOT_DDO DDO Photometric System GCPD#12 PHOT_COL(DDO,35-38) PHOT_DDO_35-38 Color index 35-38 DDO PHOT_COL(DDO,38-41) PHOT_DDO_38-41 Color index 38-41 DDO PHOT_COL(DDO,41-42) PHOT_DDO_41-42 Color index 41-42 DDO PHOT_COL(DDO,42-45) PHOT_DDO_42-45 Color index 42-45 DDO PHOT_COL(DDO,42-48) PHOT_DDO_42-48 Color index 42-48 DDO PHOT_COL(DDO,45-48) PHOT_DDO_45-48 Color index 45-48 DDO PHOT_COL(DDO,48-51) PHOT_DDO_48-51 Color index 48-51 DDO PHOT_MAG(DDO,48) PHOT_DDO_M48 Magnitude m48 DDO - PHOT_DIFF Differences or differential quantities PHOT_COL()_DIFF PHOT_DIFF_CI Difference in color index PHOT_MAG()_DIFF PHOT_DIFF_MAG Difference in or differential magnitude PHOT_SB()_DIFF PHOT_DIFF_SB Difference in surface brightness SRC_DIST_MAG PHOT_DIST-MOD Distance Modulus # Distance modulus is not a brightness, it's a distance expressed in mag PHOT_EXT PHOT_EXTINCTION Extinction total to differential PHOT_EXT_GAL PHOT_EXTINCTION_GAL Galactic extinction PHOT_EXT_INT PHOT_EXTINCTION_INT Internal extinction PHOT_EXT_ISM PHOT_EXTINCTION_ISM Interstellar Absorption PHOT_EXT_R PHOT_EXTINCTION_R Insterstellar extinction (ratio total to differential) PHOT_EXT_TOT PHOT_EXTINCTION_TOTAL Total Extinction PHOT_FLUENCE PHOT_FLUENCE Fluence PHOT_FLUX PHOT_FLUX Flux PHOT_FLUXD PHOT_FLUX_DENSITY Flux density PHOT_FLUX(GAMMA) PHOT_FLUX_GAMMA Flux in gamma rays PHOT_FLUX(HALPHA) PHOT_FLUX_HALPHA H-Alpha Flux PHOT_FLUX(HBETA) PHOT_FLUX_HBETA H Beta line flux PHOT_FLUX(IRAS) PHOT_FLUX_IR IR flux (IRAS or others) PHOT_FLUX(6 mu) PHOT_FLUX_IR_6 Flux density around 6 microns (e.g. ISO at 6.7 microns) close to M filter PHOT_FLUX(9 mu) PHOT_FLUX_IR_9 Flux density around 9 microns (range 8-10) PHOT_FLUX(IRAS12) PHOT_FLUX_IR_12 Flux density (IRAS) at 12 microns, or around 12 microns (ISO at 14.3) PHOT_FLUX(IRAS25) PHOT_FLUX_IR_25 Flux density (IRAS) at 25 microns PHOT_FLUX(3.5 mu) PHOT_FLUX_IR_3.5 Flux density at 3.5 microns PHOT_FLUX(15 mu) PHOT_FLUX_IR_15 Flux density around 15 microns (e.g. 14.3um ISO) PHOT_FLUX(IRAS60) PHOT_FLUX_IR_60 Flux density (IRAS) at 60 microns PHOT_FLUX(IRAS100) PHOT_FLUX_IR_100 Flux density (IRAS) at 100 microns PHOT_FLUX(170 mu) PHOT_FLUX_IR_170 Far infra-red Flux density around 170um (1750GHz) PHOT_FLUX(300 mu) PHOT_FLUX_IR_300 Far infra-red Flux density around 300um (3000GHz) PHOT_FLUX(FIR) PHOT_FLUX_IR_FAR Far Infrared flux PHOT_FLUX(H) PHOT_FLUX_IR_H Flux Density in Johnson's H Band PHOT_FLUX(L) PHOT_FLUX_IR_L Flux Density in Johnson's L Band PHOT_FLUX(UNK) PHOT_FLUX_IR_MISC Miscellaneous IR fluxes PHOT_FLUX_RATIO PHOT_FLUX_NORM Normalized Flux, always dimensionless PHOT_FLUX(OPTICAL) PHOT_FLUX_OPTICAL Flux in the Optical (unspecified system and/or units) PHOT_FLUX(RADIO) PHOT_FLUX_RADIO Flux density at radio frequencies PHOT_FLUX(22 MHz) PHOT_FLUX_RADIO_22M Radio flux density around 22MHz (13.6m) PHOT_FLUX(31 MHz) PHOT_FLUX_RADIO_31M Radio flux density around 31MHz (9.7m) PHOT_FLUX(43 MHz) PHOT_FLUX_RADIO_43M Radio flux density around 43MHz (7.0m) PHOT_FLUX(61 MHz) PHOT_FLUX_RADIO_61M Radio flux density around 61MHz (4.9m) PHOT_FLUX(87 MHz) PHOT_FLUX_RADIO_87M Radio flux density around 87MHz (3.5m) PHOT_FLUX(110 MHz) PHOT_FLUX_RADIO_110M Radio flux density around 110MHz (2.7m) PHOT_FLUX(150 MHz) PHOT_FLUX_RADIO_150M Radio flux density around 150MHz (2.0m) PHOT_FLUX(175 MHz) PHOT_FLUX_RADIO_175M Radio flux density around 175MHz (1.7m) PHOT_FLUX(250 MHz) PHOT_FLUX_RADIO_250M Radio flux density around 250MHz (1.2m) PHOT_FLUX(325 MHz) PHOT_FLUX_RADIO_325M Radio flux density around 325MHz (92cm) PHOT_FLUX(365 MHz) PHOT_FLUX_RADIO_365M Radio flux density around 365MHz (82cm) PHOT_FLUX(400 MHz) PHOT_FLUX_RADIO_400M Radio flux density around 400MHz (75cm) PHOT_FLUX(500 MHz) PHOT_FLUX_RADIO_500M Radio flux density around 500MHz (60cm) PHOT_FLUX(600 MHz) PHOT_FLUX_RADIO_600M Radio flux density around 600MHz (50cm) PHOT_FLUX(700 MHz) PHOT_FLUX_RADIO_700M Radio flux density around 700MHz (43cm) PHOT_FLUX(850 MHz) PHOT_FLUX_RADIO_850M Radio flux density around 850MHz (35cm) PHOT_FLUX(1 GHz) PHOT_FLUX_RADIO_1G Radio flux density around 1GHz (30cm) PHOT_FLUX(1.4 GHz) PHOT_FLUX_RADIO_1.4G Radio flux density around 1.4GHz (21cm) PHOT_FLUX(1.6 GHz) PHOT_FLUX_RADIO_1.6G Radio flux density around (OH maser) PHOT_FLUX(2.0 GHz) PHOT_FLUX_RADIO_2G Radio flux density around 2GHz (15cm) PHOT_FLUX(2.7 GHz) PHOT_FLUX_RADIO_2.7G Radio flux density around 2.7GHz (11cm) PHOT_FLUX(3.9 GHz) PHOT_FLUX_RADIO_3.9G Radio flux density around 3.9GHz (7.7cm) PHOT_FLUX(5.0 GHz) PHOT_FLUX_RADIO_5G Radio flux density around 5GHz (6cm) PHOT_FLUX(7.5 GHz) PHOT_FLUX_RADIO_7.5G Radio flux density around 7.5GHz (4cm) PHOT_FLUX(8.4 GHz) PHOT_FLUX_RADIO_8.4G Radio flux density around 8.4GHz (3.6cm) PHOT_FLUX(10.7 GHz) PHOT_FLUX_RADIO_10.7G Radio flux density around 10.7GHz (2.8cm) PHOT_FLUX(15.0 GHz) PHOT_FLUX_RADIO_15G Radio flux density around 15GHz (2cm) PHOT_FLUX(22.0 GHz) PHOT_FLUX_RADIO_22G Radio flux density around (H2O maser) PHOT_FLUX(36.0 GHz) PHOT_FLUX_RADIO_36G Radio flux density around 36GHz (8.3mm) PHOT_FLUX(43.0 GHz) PHOT_FLUX_RADIO_43G Radio flux density around 43GHz (7.0mm) PHOT_FLUX(63.0 GHz) PHOT_FLUX_RADIO_63G Radio flux density around 63GHz (4.8mm) PHOT_FLUX(90.0 GHz) PHOT_FLUX_RADIO_90G Radio flux density around 90GHz (3.3mm) PHOT_FLUX(125.0 GHz) PHOT_FLUX_RADIO_125G Radio flux density around 125GHz (2.4mm) PHOT_FLUX(180.0 GHz) PHOT_FLUX_RADIO_180G Radio flux density around 180GHz (1.7mm) PHOT_FLUX(250.0 GHz) PHOT_FLUX_RADIO_250G Radio flux density around 250GHz (1.2mm) PHOT_FLUX(350.0 GHz) PHOT_FLUX_RADIO_350G Radio flux density around 350GHz (860um) PHOT_FLUX(500.0 GHz) PHOT_FLUX_RADIO_500G Radio flux density around 500GHz (600um) PHOT_FLUX(700.0 GHz) PHOT_FLUX_RADIO_700G Radio flux density around 700GHz (430um) PHOT_FLUX(RADIO) PHOT_FLUX_RADIO_MISC Miscellaneous Radio flux density PHOT_FLUX(SiO-Maser) PHOT_FLUX_RADIO_SIO-MASER SiO maser peak radio flux PHOT_FLUX_RATIO PHOT_FLUX_RATIO Flux ratio PHOT_FLUX_RATIO PHOT_FLUX_REL Relative (normalized) flux PHOT_FLUX(UV) PHOT_FLUX_UV Ultraviolet flux (uv far-uv euv) PHOT_FLUX(X) PHOT_FLUX_X X-ray flux PHOT_MAG(GEN,) PHOT_GEN Geneva's photometric system GCPD#13 PHOT_COL(GEN,B-V) PHOT_GEN_B-V Geneva color index B-V (GEN) PHOT_COL(GEN,B1-B) PHOT_GEN_B1-B Geneva color index B1-B (GEN) PHOT_COL(GEN,B2-B) PHOT_GEN_B2-B Geneva color index B2-B (GEN) PHOT_COL(GEN,G-B) PHOT_GEN_G-B Geneva color index G-B (GEN) PHOT_COL(GEN,) PHOT_GEN_MISC various geneva photometric color indices (and linear combinations) PHOT_COL(GEN,U-B) PHOT_GEN_U-B Geneva color index U-B (GEN) PHOT_MAG(GEN,V) PHOT_GEN_V Geneva magnitude filter V (GEN) PHOT_COL(GEN,V-B) PHOT_GEN_V-B Geneva color index V-B (GEN) PHOT_COL(GEN,V1-B) PHOT_GEN_V1-B Geneva color index V1-B (GEN) PHOT_MAG(GUNN,) PHOT_GUNN Gunn Photometric System GCPD#38 PHOT_MAG(GUNN,G) PHOT_GUNN_G Magnitude g (GUNN) PHOT_COL(GUNN,G-I) PHOT_GUNN_G-I Color index g-i (GUNN) PHOT_COL(GUNN,G-R) PHOT_GUNN_G-R Color index g-r (GUNN) PHOT_MAG(GUNN,I) PHOT_GUNN_I Magnitude i (GUNN), also used in DENIS (0.82{mu}m) PHOT_COL(GUNN,I-Z) PHOT_GUNN_I-Z Color index I-z (GUNN) PHOT_MAG(GUNN,R) PHOT_GUNN_R Magnitude R (GUNN) PHOT_COL(GUNN,R-I) PHOT_GUNN_R-I Color index R-I (GUNN) PHOT_MAG(GUNN,V) PHOT_GUNN_V Magnitude v (GUNN) PHOT_COL(GUNN,V-R) PHOT_GUNN_V-R Color index V-R (GUNN) PHOT_MAG(GUNN,Z) PHOT_GUNN_Z Magnitude z (GUNN) PHOT_MAG(HEI,) PHOT_HEI Heidelberg s Photometric System (HEI) PHOT_COL(HEI,U-B) PHOT_HEI_U-B Heidelberg photometry U-B (HEI) PHOT_MAG(HIP,) PHOT_HIPPAR Hipparcos' photometry system PHOT_MAG(HST,) PHOT_HST HST Photometric System (by filter name) (HST) PHOT_MAG(HST,F1042M) PHOT_HST_F1042M Magnitude F1042M (HST) PHOT_MAG(HST,F140W) PHOT_HST_F140W Magnitude M104W (HST) PHOT_COL(HST,IR-IR) PHOT_HST_CI_IR HST Color Index from IR filters, e.g. F140W-F210W PHOT_COL(HST,U-B) PHOT_HST_CI_U-B HST Color Index close to U-B, e.g. F336W-F430W PHOT_MAG(HST,F170W) PHOT_HST_F170W Magnitude F170W (HST) PHOT_MAG(HST,F175W) PHOT_HST_F175W Magnitude F175W (HST) PHOT_MAG(HST,F220W) PHOT_HST_F220W Magnitude F220W (HST) PHOT_MAG(HST,F255W) PHOT_HST_F255W Magnitude F255W (HST) PHOT_MAG(HST,F275W) PHOT_HST_F275W Magnitude F275W (HST) PHOT_MAG(HST,F300W) PHOT_HST_F300W Ultraviolet Magnitude F300W (HST) PHOT_COL(HST,U-V) PHOT_HST_CI_U-V HST Color Index close to U-V, e.g. F336W-F555W PHOT_MAG(HST,F342W) PHOT_HST_F342W Ultraviolet Magnitude in filters F330W or F342W (HST) PHOT_MAG(HST,F430W) PHOT_HST_F430W Ultraviolet magnitude F430W or F439W (HST) PHOT_COL(HST,B-V) PHOT_HST_CI_B-V HST Color Index close to B-V, e.g. F430W-F555W PHOT_MAG(HST,F450W) PHOT_HST_F450W Ultraviolet Magnitude F450W (HST) PHOT_MAG(HST,F480LP) PHOT_HST_F480LP Magnitude F480LP (HST) PHOT_MAG(HST,F547M) PHOT_HST_F547M Magnitude F547M (HST) PHOT_MAG(HST,F555W) PHOT_HST_F555W Magnitude F555W (HST) PHOT_COL(HST,B-R) PHOT_HST_CI_B-R HST Color Index close to B-R, e.g. F430W-F675W PHOT_COL(HST,V-R) PHOT_HST_CI_V-R HST Color Index close to V-R, e.g. F555W-F675W PHOT_COL(HST,R-I) PHOT_HST_CI_R-I HST Color Index close to R-I, e.g. F675W-F814W PHOT_MAG(HST,F569W) PHOT_HST_F569W Magnitude F569W (HST) PHOT_MAG(HST,F606W) PHOT_HST_F606W Magnitude F606W (HST) PHOT_COL(HST,V-I) PHOT_HST_CI_V-I HST Color Index close to V-I, e.g. F555W-F814W PHOT_MAG(HST,F622W) PHOT_HST_F622W Magnitude F622W (HST) PHOT_MAG(HST,F675W) PHOT_HST_F675W Magnitude F675W (HST) PHOT_MAG(HST,F702W) PHOT_HST_F702W Magnitude F702W (HST) PHOT_MAG(HST,F725LP) PHOT_HST_F725LP Magnitude F725LP (HST) PHOT_MAG(HST,F785LP) PHOT_HST_F785LP Magnitude F785LP (HST) PHOT_MAG(HST,F791W) PHOT_HST_F791W Magnitude F791W (HST) PHOT_MAG(HST,F814W) PHOT_HST_F814W Magnitude F814W (HST) PHOT_MAG(HST,F850LP) PHOT_HST_F850LP Magnitude F850LP (HST) PHOT_MAG(HST,V) PHOT_HST_V Magnitude V (visual) HST (unspecified filter name) PHOT_COL() PHOT_INDX Photometric index (usually in narrow bands) PHOT_COL(,HI) PHOT_INDX_HI Neutral hydrogen HI photometry index PHOT_MAG()_INT PHOT_INT-MAG Integrated or isophotal magnitudes PHOT_MAG(,B)_INT PHOT_INT-MAG_B Integrated total or isophotal blue magnitude PHOT_MAG(,I)_INT PHOT_INT-MAG_I Integrated, total or isophotal, I magnitude PHOT_MAG(UNK,)_INT PHOT_INT-MAG_MISC Miscellaneous Integrated or isophotal magnitudes PHOT_MAG(,R)_INT PHOT_INT-MAG_R Integrated, total or isophotal, R magnitude PHOT_MAG(,I)_INT PHOT_INT-MAG_U Integrated, total or isophotal, V magnitude PHOT_MAG(,V)_INT PHOT_INT-MAG_V Integrated, total or isophotal, V magnitude PHOT_INTENSITY_ PHOT_INTENSITY Intensity PHOT_INTENSITY_ADU PHOT_INTENSITY_ADU Intensity expressed in ADU (analog to digital units) PHOT_INTENSITY_ADU PHOT_INTENSITY_ESTIMATED Estimated intensity # What in astronomy is *not* estimated? PHOT_INTENSITY_ADU? PHOT_INTENSITY_MISC Miscellaneous Intensity PHOT_INTENSITY_RATIO PHOT_INTENSITY_NORMALIZED Normalized intensity SRC_IMAGE_RADIAL_PROFILE_INTENSITY PHOT_INTENSITY_PROFILE Intensity profile PHOT_INTENSITY_RATIO PHOT_INTENSITY_RATIO Intensity ratio PHOT_MAG(,IR) PHOT_IR Infrared magnitudes (not well inserted in photometric systems) PHOT_COL(IRAS,IRAS12-IRAS25) PHOT_IR_12-25 Infrared color index 12-25 (IRAS) PHOT_COL(CO 2.29mu,LINE-CONT) PHOT_IR_2.29 CO band index magnitude at 2.29 micron PHOT_COL(IRAS ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 25 Hi Anita, Ray et al, I globally and fully agree with all your points and comments, the most important one is to use the only available quite exhaustive metadata (UCD) as a crucial use case to elaborate a more flexible and sophisticated schema. I am impressed by Ray's willingness to define a metadata model to refactored the domain, and I am waiting it with great eagerness. I was thinking about such a process and the most difficult part for me is the mechanism to keep a link to UCD and continuing to support them. I tried to formalize the possible inter-relations in the attached UML diag, (triangle at the beginning of a line is inheritance, others lines are relations; assoc,agreg....). Several question araise already in my mind even at this very simple level : - Does Descriptor and Group... need to inheritate from Atom and Descriptor, or is the association use/is_part_of sufficient? In other words, do we need several level of composition? Group of group of Descriptors?... - is the relation UCD/PAD formally needed? - Which is the link between the actual UCD_Tree and all the possible and usefull descriptors associations? cheers, pierre ---------- X-Sun-Data-Type: gif-file X-Sun-Data-Description: gif-file X-Sun-Data-Name: AtomUCD-UML.gif X-Sun-Encoding-Info: uuencode X-Sun-Content-Lines: 162 begin 600 AtomUCD-UML.gif M1TE&.#=A\@)S O< /\ /___^CX !4 , . \ #_ "^ #8 ) M J /]Z "0 +X -D ( " ( .," "!, +X6 -J* 1H 2 ! $ M ) "L $" )!,% 9 %L %Z Q &@ -D" %Q, 8 #V GX !6( M I #F "7D 'X /8# ;_ $"^ #9 UL !< $ \ $D $@\%. M 8 \"% & ?(!$ +0 ! !% +< / " , 3X0 =@ 90, <@ & M=P! <@ ":0 Z= ( C> :0

< ;QH 3 ,.&."!\!F(X(+=*=B0 at PQ&:)N"_OUW4(445BA0 at 1HBA*$ 'PJ% M888CEFCBB2BFJ.***$KHHD84@@CA0 9:6..&-"9D8X%%Q;@ABT &*>20';YH M)$49*N2CC#?BZ"%!/!*UI(5)47GDE0\Y6&1!/C:YI$%:@MACCC\N9266:"H) MYI,XVNBDF![&..-/4\XII9UIYEDFDSH6.:*,>U[8X99T!GJF48?JJ2A$>)J5 MZ)V+1JIDB7!&9&)5CPZ5J:2<$2VZNJK_K#& M*BN0$JF:DJVK?C?KKKSVZNNNM1Y:*DFXYMK at L)$5RR&7?C;+)Z%((FNLKM(^ MIFR@;[Z9)*#<6E3LM-I]NQBNVY*9K9OG8B0NN->MFQBY?T(I[[Q?5MLGN^FY MBYBM$%H9)KWF5EJ1OOA*1[!A_#([+[9-"FQOG 6?=W!A"2O,L+GUJOMPQ-5- M3)BJ6X;8+)4:?@BMI1MS/)W'@[$,D\LJ(PW8R7S?YW=C@ =>W^", M%6[X?(@K%N_B^#4.M>*0OR?YOB%6;M_E"/_'N>:[??ZQYZ*#7O7>JNV(NNG< ME1Z8LZS+YSK-),\>.VRV^^5O[K>WQOM>A/[>>^JKFQ:\\,.?ACQ>PBZ?/&G. MVY5H],^'1OU<)U->O7?7RY5]]]MO!CY_YUE2 2DEH "F$#E&%!]#&R at S")8F@=* MD' 4A%X&+[C #G(P/!:TWP=!N$'1A'"$ASDA_TJ(PMZH$"TO;*%@8N at H%LI0 M-S0L2PYON#,;?F:'_CP$G@\] \0 at YJ6(84&B$:4WQ,XH<8E7:R)GG at A%[TE1 M?%>LHN^RF!DJ:O%37$1?&+^(&B]RQ8QD%*%PT)C&%7JPC<]A8U;D"$<=CM$R M=*SC6/)H%3[J$2Q^I$H at _]B504K%D(34"B*ALLA$7J613H&D(P5YQ\I(4M= @V7B0.F+U,H3,<5LYNQT2:DP#DA;G:.G.7\)CJWJ,YUJLV<%(.G.Z/8SGF649XM_L.G M/C"=*0%K*DS$.I216I4B:NM((MK5FWVMKVMKC-K6YWR]O> MUC8ZM/6M<(=+W.(:][C(S2UP69L1V7YTLK_<:+B8"TCJ!E1HUG4I7IT3W+AE M]Z3+E:[[H M8\6+'N2A!;UN_&RWODMUW(WHFH]Z;U96EXL>O>[3K- MO.W*[QP%'%'^RM>_S(GO>!&\' 6?E\"/A#!J :P_"6/*PJW%\%HU/#<.1^6^ M?/4P7!>LV?T>4<2?G>_14 PF%I.6P0YT,91DO$<:*P7$G:5PQVS<2^@X., J M#AV/<;P3(HO$R*+5,7607%,>]W'(3A9IE+?J8RCWM\155O+*IKQ-$Z?TRM'- MLH%)'.8X6OG 6#:S_I8-QN5QJGG,#PXR#L],YO**^<1 at MO.;\8SF,G.7SG&& M<7)^7&$YYX;0.S8T,P$-9$%/$"X!B'2D6YQG^+;YPQ:>M D;;$Z6]K+:]'T MI@/0Z4"G^<]O$;6H_UIH1Q\GD*06R*J[96H__U:OJ!N2[&-W6<]HQK.P79VK[_<[$_?.=7+9G6B76T<0^9:UZWF];#7 MG&QD7SMIE]8OMXN#Z"6G^[GGUJZGS;UG:L][Q>4.ZKV%G&^E'AO?\9;IN['" MY(\4G"7MWK*B3T?N@ .\WNC^-[\=[N]JT_O9?-[WG/MM18EOG.(=M_C#_C%N M[UI+>]S0#K>P&\QHE9^>SI1O6]PP][F[>5X; MG7/\YD?GI\T7G72JBGSB-->WR6=.\H at __>-1K[C&D0[RIRZ=X5U7^M6YGO60 M;YWI87?ZV<%>=J^/'>UM%_O:>QYWM4_]XM.V^MR+CG.FB(MT'%)=C?J7N>0: M_E)H/;SB$;C-Q3O^55!#4HZ6!:<;@:I.CT\N!#//>4HUOO. at 3U'D[3MY$I4, M675*_'4SKJF!]W1=72)=BTN5^KIV..:#=7W?:<2TPC%UGW MHP_6Z4W_HV'Y7MLOMKW>6Y],S/6$^! V?E&1_F]]GA*X^"TG:?6)>?WO9S_\ M=.(^^;VO^O:S7D3J[USHW7][H>-W_/('/?TO^WYXSW#W_L=_]==_XI=/CR9] M,(1^]V> KV9^JU=R\(=_QH1+V/> TQ>!##A'!"(P(;9_"8A[8Q5_[[)]'IAB M]E=^$I at TC$*"+-A8)2AU&/A_6\%\@E([;I(YLQ=XP 1[G@+(C'+A>[<5[GF2!\D9]&4AP3J at C&(,N2Q at P41*"35B%/7-DYQ>$ M4C.$F#)C=M(E3O(EGC)Y+8 at RE-9\)&*&25)X at 0>'O%<[X+9A4%AS73:%C[0F MJ-(F7A(PG;:%0MB%_E4XAWNBA"=RAXNXAF+2 at PX!A*O55%0F@^H6/S8H>WEH MAWQRB/8U(X+G.8"H+<&W+?_RB*&XAQPA>BMX?)>(5#AH$L4D1YO%@Y36/*D( MB0X#,(38,&[X at F?3+\'"?GUX$:J37K7(7)>2,HA7@,5HAGGH)\+7BV2RBY6' MB )H<*@3/$QXC$CEA24!+:%DBV?4>_WR?(*B;;OX+UKBCMKX at 6!XC8/'B;_W MCIMH;,OG@[$X,.4B,I1'A\\B++H&D+LSD %$?#.(CLRVB%OX?,"GA5>X,&J8 M)6$(AG]RD'.BCAQ8+Q#)0,(S,_HD&MX)JEXDB3Y/B$9>C Y_HN3 M*(EW6(_X:)/-5Y/2Z(DR:5:L.(R)N).0Z"^G."7!UUP-)9*/8Y080Y&G*([# MUY 9\U/3%),Q&2J5*(Q4J8I0"8=$^8M-28@:TX_QZ(C9DI-A>2Z/8XI.F2Y; MZ6;>%$U9B8 ZM9',0HQ2>91,>99C"8[^N(Y1&91I&9CBJ(9[F85EF7[6))<9 M]9-O^90J68 at -29C8V)=P^9>E.)76N)GI2)$K*9&/&8,"!SOEET64F#5V28]' MV9)MR99\B8Q)N3K-DY81Z9J$Z86U^9EBB9F7B3T329<%UF0JJ82?&#+[Z(DY M:3(N\Y(:HXM,,C((^9S1J9/%:9PZ^(F6*872_O.; ]B=%QB B]F;WL.=VRB/ M!*B8?@B>OJDM#JB5;B>><0F?Y&,H[0F<6J>=DN678KB0COF>^!F>_[F?ZF:? M9A>@#D66)YAA_2EW!AJ?#0J!)DB at _BF: $JA0F25OK6@=F>A!ZJ?V(6AO:6A M6(6@#LJA6J1]N9>"T-A&*,J%Z;FB:=2BH(B)\@E%()IY)&I1L4EU772CCI>C M MJ!>*='(\6<0UI'1;JC] 6 >\>'-9I-!R=D/@J30,HU^+-$4WJ5'EI.5ZI: M);IH7>JE07I/E">FW3=G=6BFZ_=Q8:JF47 at ZY>*F+PJE<2BGX[ZJ >5 MA$Q:6I1JD9JZJ9S5J3,Y*:"*6:+*$(1WJ>ZK1)ZJ]ZZH=<:KM]*K.0JKM%ZKN69KNH:H<[:KN;YKO : MG/(ZKQ/6K?::1,7Z,OO*J?WJ$L>*40%KD?D:K]I:L/K*HPB;L/BZL.>HL [K M%0,[JA&KH U;L03WKRZ(L5(&L1P[8![[L1$6LB)[821;LE,QL3Z)LOQY_K$L M^X0N^[*6&+,RZW<:BW W2UDJBZHY&UD[JX[0WUK.- MJ;0IR[3*Z+1/F[126Z7 at 6K4S:[18*U54N[4F2G=>R[6CF:5D6[9FRUM; TEG MN[9LV[:^DK8L1E at _VZA&H[8W.[>!&C-V>U?LJC)[JU=0.Q)X:ZW9&DOCJK=Q M>[>!.X]4\[>/=;A^F[A\RW9U*[F >["1JZS!A+D MVTJ0V[F6^[A]J[JC:TRE6S"G:[BM:[JK^[F+BYIP^[K)1[D_,[N9Y;LX [R; MF[JVR[MG*KRBVZRH6[NR>[O-J[R9R[RT*[VN_DN]P0NVOPN]U:N]P\N]V1NL MC0N^Q>N\^$*\I&N\SXN\:VJ]QXN]Y>N^ZPN_Z6N^[(*^L*N^YTN^]2N_^QMJ MDI9MN]RXL6JK9L QR[_WO OS9K$:R_]RM@%0S!BBO! M&>P6N7;!]@LN?)1MG=B_##R];&'"(NR_'[S"(X:['DS"_)N_(SPM^-N[*7R] M R8K.O"-*QL+-S!&!S$]&O#0(S#-:S#XMLT.9R\._R^T!J_43R_4XS"35RY M['M.1:S$6QQ/,^S%1\S$4&K 5XS$53S!9TS&5[N]7ZRB;?R];WRGX43 5$RX M=US&XSO'-)K$QO+$_NV;QB^\QE"%KRI.,RJ'LQ[D" MR+$LR$8,RRSEMDBDRZ";M9R<8;Q<8[K\(K0\H#G'C#'5R\?,QT\&LPR[S"[R M-;RL>$WKRQUKS0LBS=-L>-4,S<]LL\1\1S,U->:SR\ELQ][9S7]*BT!ESD^A MS."\L7T\CNV,S.^,SNM*-#A'SO5<$P%LPHSKS1&BS6 6:8L/<]+\](S M$=,R;=(5K29I:(^)"K0Z79=(+;&F>=317-.T5J:5&/79#@-IOA:+%I?8]TG;<^ MZ8KY8=DUY=@*-ETNXJ>W=F at +=6A6]3/29.R8]'"*=8ZY:)VW9RKS=JB M3;"OW=A"/2FM+=PU2-:68UP[/=N(S=OLG-DY_CBQ]7.C<\UUCCYG> M])G7%^[;MAW. at P*2HHB%#@.,*PF,_)W:T>*<.IG at Q/UD^PV;BXV#+N[?'D[8 MG<7>03(WJOG0GD[?A[L*CB M;UV#V\U3Y'GEJ*GD/HWA_//D/Q78&F[BD%GEO8W-UXBJ6'GD:HZ1-8[9PZU# M8C[F44Z;'"DGQT3D_DC^E$Y=*&X^T_KLY25]S4[.FDFNTG)8J/F(F#3!YV_> MU:M99!O^YAE%Z%0]Y^7:5E];P'T.FD%]%..3-Z3MX]\LHH_>Z2[]Z6X9ZE;[ MH$L>Y[Z*VNA*Z>HIYY%>D;RXI:+.3:7NVJ?NGNNE3Y NZ$^]5AF]T"2%Z0=N MZ-QZV%!N['@-UE\J%:N[,&>[*W'[!8.LH7+[6DN[<;,YH>?.U,ZN[E+UWRVX[8#@>J'':+0?YYQ7NZ;4NW=Z.W!(>\10_\>=8_N"0 M'8C W>R%+NS^J$D)">PA#_!',)=>2JS"7 at W"?*H;BF;O3L[O^@$O]*- M7B;4_?#]+N^*0O-K(BJJF)OYC?%(>.$\G_3TGB=, M[RE./^(-/WSQ\N$#S_(.?S&[7N)NN9=XF=Z:F?!P3O(*;O*QG>WMGK<- KY>O&=]2/I1;_O5^'4FK6F?B ;9O9 MV)JZGM-1!?F5#VQ3'XA/W^$=/S 6WZ=?29"N.?>Z>9MVGU-E7Y2%Z/64[^;$ M>?J8S_H6 at X:QG_4$3IZ'&7LO+E0X+Y.2:/!W_EGTA,\O5"_B.T^'0!_?]9B< M@(>6A)^1)A0X4*T^1 @ $2*%2U>Q)A1XT:. M'3U^!!E2)$>)(TV>+'E2YQ)E3YTZ!$GW^!!I4Z%"B M18T>18J4YU*',YD^[?@3ZE2J5:U>Q=HRZ5:N7;U^]9D5JE.20E].I!I4[%JV M;=V^30L4[MR59#?@D?OK at WHV*45ET:1AQ9\F3* M(=56QIR0<>*\G2?V_ at U;6$#8T .EBJZ*]W1FUJU=3[[\VO5FBV:']B284G=G MTVAIXR0;6_9PXL7CKC:.^;=,SZ:=XWX^.G?OTWGC1H2<7/MV[I:S=X^\'.)C MWKEGEH<>W/I4QL+!OXW"ZT?YSD*GEZ%,P0PT73'##N1AL*#_4 (R0/__PBH[$F.[#T$,7 M7V2O0QC= G$AY";<[3/0=-R1NL\*VJVWFT!L<48CCV2I2"39JO'%)I5<,DHI M:Y-QRJR:=!%+'$NSLDLO%8+RRP#%!+)"_,(D,TT/T51S+#.GU-*\*MND_C,^ ML^IL*TX-]2SS1CS_[.Y.0-?B4\%"^^1R4$5E8W/1I0XU$%)$$W6T4L0:M70G M2>O;=$ _,P651DQ#S:E3.]_T:%125QUR3E8?135*4[%S]55;DZSU5IUF?8]7 M6C_5-=B1!!5VS#9]!3/78I=M4%EF;4*6NVB3=?99:XFU-K58EYS61FRS!==' M2L-UD\YN0U25W$R_53=&<[>EB=UV2;UM7JS PC=????E]USFTK7WRWH#OK=? M at P]&N-\KY258388;AIBRAR.6%6"*+_YK8HPW''ACCUGK^.,,0Q:Y9.4T-MDX ME%-FV;Z56Y;X99AG%HQDFF&S^6:=<99YYX5[[O8YZ(QS%OHJHHI&^K6BDM86 M:*:?YM!IJ%,E>FJK8Y8ZPP"VWCK2JJ\&^^2LY>M: *[A6SILM9-+^\BRS0Y MVJ/7ICO0N5]\^^WAC*J[;[3YWC!N@?0&N6V_#YA]?UJU.[(CYY^ K^Z2W![]:[\?W.V'RST<_??779[]]]]^'/W[YYZ>_?OOOQS]__?<_," .[>^ end ---------- X-Sun-Data-Type: postscript-file X-Sun-Data-Description: postscript-file X-Sun-Data-Name: AtomUCD-UML.ps X-Sun-Charset: us-ascii X-Sun-Content-Lines: 225 %!PS-Adobe-2.0 %%Title: AtomUCD-UML.ps %%Creator: fig2dev Version 3.2 Patchlevel 1 %%CreationDate: Thu Mar 27 11:01:40 2003 %%For: dide at rosetta (DIDELON Pierre) %%Orientation: Landscape %%BoundingBox: 39 109 555 732 %%Pages: 1 %%BeginSetup %%IncludeFeature: *PageSize A4 %%EndSetup %%Magnification: 0.9610 %%EndComments /$F2psDict 200 dict def $F2psDict begin $F2psDict /mtrx matrix put /col-1 {0 setgray} bind def /col0 {0.000 0.000 0.000 srgb} bind def /col1 {0.000 0.000 1.000 srgb} bind def /col2 {0.000 1.000 0.000 srgb} bind def /col3 {0.000 1.000 1.000 srgb} bind def /col4 {1.000 0.000 0.000 srgb} bind def /col5 {1.000 0.000 1.000 srgb} bind def /col6 {1.000 1.000 0.000 srgb} bind def /col7 {1.000 1.000 1.000 srgb} bind def /col8 {0.000 0.000 0.560 srgb} bind def /col9 {0.000 0.000 0.690 srgb} bind def /col10 {0.000 0.000 0.820 srgb} bind def /col11 {0.530 0.810 1.000 srgb} bind def /col12 {0.000 0.560 0.000 srgb} bind def /col13 {0.000 0.690 0.000 srgb} bind def /col14 {0.000 0.820 0.000 srgb} bind def /col15 {0.000 0.560 0.560 srgb} bind def /col16 {0.000 0.690 0.690 srgb} bind def /col17 {0.000 0.820 0.820 srgb} bind def /col18 {0.560 0.000 0.000 srgb} bind def /col19 {0.690 0.000 0.000 srgb} bind def /col20 {0.820 0.000 0.000 srgb} bind def /col21 {0.560 0.000 0.560 srgb} bind def /col22 {0.690 0.000 0.690 srgb} bind def /col23 {0.820 0.000 0.820 srgb} bind def /col24 {0.500 0.190 0.000 srgb} bind def /col25 {0.630 0.250 0.000 srgb} bind def /col26 {0.750 0.380 0.000 srgb} bind def /col27 {1.000 0.500 0.500 srgb} bind def /col28 {1.000 0.630 0.630 srgb} bind def /col29 {1.000 0.750 0.750 srgb} bind def /col30 {1.000 0.880 0.880 srgb} bind def /col31 {1.000 0.840 0.000 srgb} bind def end save 5.5 77.5 translate 90 rotate 1 -1 scale /cp {closepath} bind def /ef {eofill} bind def /gr {grestore} bind def /gs {gsave} bind def /sa {save} bind def /rs {restore} bind def /l {lineto} bind def /m {moveto} bind def /rm {rmoveto} bind def /n {newpath} bind def /s {stroke} bind def /sh {show} bind def /slc {setlinecap} bind def /slj {setlinejoin} bind def /slw {setlinewidth} bind def /srgb {setrgbcolor} bind def /rot {rotate} bind def /sc {scale} bind def /sd {setdash} bind def /ff {findfont} bind def /sf {setfont} bind def /scf {scalefont} bind def /sw {stringwidth} bind def /tr {translate} bind def /tnt {dup dup currentrgbcolor 4 -2 roll dup 1 exch sub 3 -1 roll mul add 4 -2 roll dup 1 exch sub 3 -1 roll mul add 4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb} bind def /shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul 4 -2 roll mul srgb} bind def /$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def /$F2psEnd {$F2psEnteredState restore end} def %%EndProlog $F2psBegin 10 setmiterlimit n -1000 10525 m -1000 -1000 l 12358 -1000 l 12358 10525 l cp clip 0.05766 0.05766 sc %%Page: 1 1 /Times-Roman ff 270.00 scf sf 6600 5025 m gs 1 -1 sc (FixAtom) col0 sh gr /Times-Roman ff 270.00 scf sf 9525 5025 m gs 1 -1 sc (ParamAtom) col0 sh gr /Times-Roman ff 270.00 scf sf 1800 8250 m gs 1 -1 sc (Group/) col0 sh gr /Times-Roman ff 270.00 scf sf 1800 8880 m gs 1 -1 sc (Frame/...) col0 sh gr /Times-Roman ff 270.00 scf sf 1800 8565 m gs 1 -1 sc (Association/) col0 sh gr /Times-Roman ff 270.00 scf sf 4500 8175 m gs 1 -1 sc (PAD) col0 sh gr /Times-Roman ff 270.00 scf sf 9900 8550 m gs 1 -1 sc (UCD_Tree) col0 sh gr /Times-Roman ff 270.00 scf sf 6225 8025 m gs 1 -1 sc (?) col4 sh gr /Times-Roman ff 300.00 scf sf 2250 7275 m gs 1 -1 sc (?) col4 sh gr /Times-Roman ff 300.00 scf sf 7050 9525 m gs 1 -1 sc (?) col4 sh gr /Times-Roman ff 300.00 scf sf 3375 3900 m gs 1 -1 sc (?) col4 sh gr /Times-Roman ff 210.00 scf sf 750 8025 m gs 1 -1 sc (uses) col0 sh gr /Times-Roman ff 210.00 scf sf 1950 4575 m gs 1 -1 sc (uses) col0 sh gr /Times-Roman ff 210.00 scf sf 2100 750 m gs 1 -1 sc (is_part_of) col0 sh gr /Times-Roman ff 210.00 scf sf 900 4875 m gs 1 -1 sc (is_part_of) col0 sh gr /Times-Roman ff 210.00 scf sf 3975 750 m gs 1 -1 sc (n) col0 sh gr /Times-Roman ff 210.00 scf sf 2475 4575 m gs 1 -1 sc (n) col0 sh gr /Times-Roman ff 210.00 scf sf 2475 5100 m gs 1 -1 sc (n) col0 sh gr /Times-Roman ff 210.00 scf sf 1200 8250 m gs 1 -1 sc (n) col0 sh gr /Times-Roman ff 210.00 scf sf 6825 8250 m gs 1 -1 sc (n) col0 sh gr /Times-Roman ff 210.00 scf sf 5550 8325 m gs 1 -1 sc (0..1) col0 sh gr /Times-Roman ff 270.00 scf sf 2925 4950 m gs 1 -1 sc (Descriptor) col0 sh gr % Polyline 30.000 slw n 6975 7725 m 8250 7725 l 8250 8400 l 6975 8400 l cp gs col0 s gr /Times-Roman ff 270.00 scf sf 7350 8175 m gs 1 -1 sc (UCD) col0 sh gr % Arc gs n 6937.5 2400.0 7200.9 119.0 61.0 arcn gs col0 s gr gr % Polyline n 4125 675 m 5325 675 l 5325 1125 l 4125 1125 l cp gs col0 s gr % Polyline gs clippath 4613 1535 m 4725 1175 l 4838 1535 l 4838 1080 l 4613 1080 l cp clip n 4725 1125 m 4725 3075 l 3600 3075 l 3600 4500 l gs col0 s gr gr % arrowhead n 4613 1535 m 4725 1175 l 4838 1535 l 4725 1535 l 4613 1535 l cp gs col7 1.00 shd ef gr col0 s % Polyline n 2625 4500 m 4350 4500 l 4350 5175 l 2625 5175 l cp gs col0 s gr % Polyline n 4725 3075 m 10125 3075 l 10125 4500 l gs col0 s gr % Polyline n 7050 3075 m 7050 4500 l gs col0 s gr % Polyline n 6075 4500 m 8025 4500 l 8025 5250 l 6075 5250 l cp gs col0 s gr % Polyline n 9150 4500 m 11250 4500 l 11250 5325 l 9150 5325 l cp gs col0 s gr % Polyline n 3600 6525 m 4800 6525 l 4800 7725 l gs col0 s gr % Polyline n 1350 7800 m 3450 7800 l 3450 9150 l 1350 9150 l cp gs col0 s gr % Polyline n 4125 7725 m 5400 7725 l 5400 8475 l 4125 8475 l cp gs col0 s gr % Polyline n 4800 6525 m 7725 6525 l 7725 7725 l gs col0 s gr % Polyline n 5400 8100 m 6975 8100 l gs col0 s gr % Polyline n 9750 8175 m 11325 8175 l 11325 8700 l 9750 8700 l cp gs col0 s gr % Polyline n 8250 8025 m 9750 8400 l gs col0 s gr % Polyline n 2625 4650 m 1650 4650 l 1650 825 l 4125 825 l gs col0 s gr % Polyline n 1350 8100 m 600 8100 l 600 4950 l 2625 4950 l gs col0 s gr % Polyline gs clippath 3488 5660 m 3600 5300 l 3713 5660 l 3713 5205 l 3488 5205 l cp clip n 3600 5250 m 3600 6525 l 2475 6525 l 2475 7800 l gs col0 s gr gr % arrowhead n 3488 5660 m 3600 5300 l 3713 5660 l 3600 5660 l 3488 5660 l cp gs col7 1.00 shd ef gr col0 s /Times-Roman ff 270.00 scf sf 4350 975 m gs 1 -1 sc (Atom) col0 sh gr $F2psEnd rs showpage From jcm at head-cfa.cfa.harvard.edu Sun Mar 30 16:29:05 2003 From: jcm at head-cfa.cfa.harvard.edu (jcm at head-cfa.cfa.harvard.edu) Date: Sun, 30 Mar 2003 19:29:05 -0500 (EST) Subject: UCD Status and Perspectives Message-ID: <200303310029.h2V0T5M29580@urania.cfa.harvard.edu> Patricio, I realize I never followed up your message of Mar 19. For the record, what I had in mind with my spectral index example, I had in mind finding the sources in a subsample and calculating what their 4100A fluxes are, for instance to get a sample for an observing proposal of the 10 brighest northern objects of a particular class, brightest by 4100A flux. And I want to do it even including objects whose 4100A flux is not actually known, but can be guessed from other published fluxes assuming an SED. In general, the existing UCDs are great for getting general information but not for knowing exactly what you have, that was the broader point. A side point from this example is that I think the VO will need to allow users to specify certain assumptions to provide a context for queries (I'm looking for quasars, and here's what you can assume about quasars - e.g. a typical SED - so that you can handle my query even in cases where the information is incomplete... a bit like a Bayesian prior in spirit, I guess). Regards, Jonathan From Marco.Leoni at eso.org Fri Mar 7 08:00:15 2003 From: Marco.Leoni at eso.org (Marco Leoni) Date: Fri, 07 Mar 2003 17:00:15 +0100 Subject: [Fwd: RE: UCDs - repost] Message-ID: <3E68C20F.7020700@eso.org> -------- Original Message -------- Subject: RE: UCDs - repost Date: Fri, 7 Mar 2003 09:25:19 -0500 From: "Wil O'Mullane" To: registry at ivoa.net I note in your paper you mention not being able to express functions in an Ontology. Many years ago I worked with Ontoloigua and KIF(Knowledge Interchange Format) this indeed allows one to express functions on numbers . http://logic.stanford.edu/kif/kif.html Of course KIF is lisp (Lots of Incomprehensilble Silly Brackets indeed) based and not very pretty . Still I see KSL have now extended Ontalingua in to the web world and suggest provideing it as a Server... it may bear looking at. Perhaps this has already been explored .. wil > > Hello all, > > Maybe some of you have not subscribed to the > ucd at ivoa.net list, but might have interest in > reading the paper I posted there: > > http://www.ivoa.net/forum/ucd/0001.htm > > Sorry for those who received this info twice. > > 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 ----- End forwarded message ----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From amsr at jb.man.ac.uk Mon Mar 17 08:03:55 2003 From: amsr at jb.man.ac.uk (Anita Richards) Date: Mon, 17 Mar 2003 16:03:55 +0000 (GMT) Subject: UCD Status and Perscpectives Message-ID: Sebastien's 'UCD: Status and Perspectives' gives a very clear summary of the recent discussions, responding on the basis of the considerable experience of CDS. Thanks very much - I actually enjoyed reading it, especially the ontology section. It suggests to me some issues which it would help if we made decisions on, or at least reached a working agreement for the immediate future. Maybe Sebastien (or anyone) could suggest what is most urgently needed for discussion at the IVOA registry meeting Wednesday 19 Mar - is anyone planning a presentation? This is what occurs to me: 1) Registries needs UCDs. 'Status and Perspectives' discusses relevant issues in '3. UCDs and data models'. We need general UCDs which describe an entire data set ("Header metadata"), e.g. for which wavelength regime (Radio, IR, Optical etc) - where such currently UCDs exist, they are often parts or parents, rather than ones which are instantiated. See e.g. [[http://www.stsci.edu/~hanisch/NVO/ResourceServiceMetadataV6.doc][Bob Hanisch ResourceServiceMetadataV6.doc]] or [[http://www.stsci.edu/~hanisch/NVO/ResourceServiceMetadataV6.pdf][ResourceServiceMetadataV6.pdf]] and [[http://wiki.astrogrid.org/bin/view/Astrogrid/RegistrySchema][AstroGrid draft registry schema]] We also need a means to associate header data with column labels, e.g. if all data in one catalogue is at 1.4 GHz and another at 1.6 GHz this currently has two separate column UCDs, PHOT_FLUX_RADIO_1.4G and PHOT_FLUX_RADIO_1.6G - dozens of UCDs in all. Using the atom idea across the header and the columns, this could be achieved using one column UCD PHOT_FLUX, and header UCDs for the wavelength regime (radio) and the nominal frequency. This does require that we evaluate the data corresponding to UCDs, see below. 2) Evaluating data identified by UCDs Many people think of UCDs as primarily for selection of catalogues for a human to then view the contents. This is their primary funtion as far as the Registry is concerned, but for actually executing queries we need to compare values within cagtalogues and possibly associate the results with a new UCD (e.g. compare flux densities to derive a colour). Until recently, UCDs were only evaluated routinely (e.g. via Vizier) in one of the most difficult cases - coordinate conversion. Otherwise, the user said 'give me a list of catalogues containing information about x' and the service converted x into UCDs and returned a list of catalogues containing columns corresponding to x. This is now extended to photometry but only for special formats (see above or the AVO demo). We now need UCDs which can enable selection via evaluating UCDs, e.g. if I want flux density measurements between 1.4 and 1.6 GHz I should be able to access data at 1.5 GHz too, via the registry search seeing there is a catalogue containing radio flux densities, and the query execution finding OBS_FREQUENCY 1.5 GHz - in the header, or as a column heading for a collection of measurements at a range of frequencies, as well as a column PHOT_FLUX. This may be a problem where one UCD describes several columns e.g. TIME_DATE for the start and stop of observations, but we want to evaluate both e.g. for error bars on a proper motion measurement. Or do we just need an algorithm which says 'if there are two TIME_DATEs and they are different, take the difference'? 3. Who reads UCDs? The document asks 'how do I find the proper UCD to decribe my data set'. At present, this is done automatically if you are someone contributing a 'simple' table e.g. out of a paper; the average astronomer is not _forced_ to be exposed to UCDs, and a user doing a search certainly isn't (although they might want to use them directly). Data providers of major archives may need to investigate them to check they are allocated correctly or suggest new ones, as do VO workers. Thus they should be reasonably human-readable and available for anyone, but not restricted to the lowest common denominator of astronomical understanding. We could increase the present number ten or even 100 fold (still <10^5) - I am not saying we should, but we need to be afraid of it. For example, if I am using the SED tool in Aladin, I really do not want to know that an optical data set has UCDs for photometric zero point and colour corrections (although an optical astronomer might and I had to learn...) but fortunately the Aladin prototype SED tool knows how to use these to plot magnitudes in Jy. Conversely an optical astronomer does not want to know parameters associated with radio visibility data but if s/he wants to extract an off-centre image at a certain resolution from the MERLIN archive, they need the extraction tool to know about baseline lengths, visibility integration times etc. to chose a data set with an appropriate field of view and resolution. Thus, completeness of UCDs for their purpose is more important than economy, and in fact the savings in going to an atomic structure would probably mean we could add UCDs for specific errors, and remove the degeneracy of things currently under 'TIME_DATE' or 'NUMBER' etc., without making UCDs unmanagable. As the document says, the creation of new UCDs should certainly be restricted to defined bodies (e.g. via a central monitoring panel) to avoid duplication and maintain consistency at a functional level. This probably means UCDs will proliferate slowly, acquire some clumsy ones, and then be pruned or refactored over a cycle of months or years. Best wishes Anita - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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 pfo at star.le.ac.uk Tue Mar 18 05:08:39 2003 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Tue, 18 Mar 2003 13:08:39 +0000 (GMT) Subject: UCD Status and Perscpectives In-Reply-To: Message-ID: Hi Anita, as a reflexion on your thought I wrote the following lines, which I think may be relevant. I must add that I agree with your points nearly 100% :-) Cheers, Patricio UCDs for the photometric and time domain. At nearly 5 years since the beginning of the work on UCDs a number of things have evolved which make it worth re-thinking how these two observation-related quantities can be represented for the new usages broght by the advent of the IVO and the possible usages by both human users or machine users (eg registries). Both of these variables can be seen as continuous, and one single observation will cover a certain range in wavelength (frequency) and a certain range in time. Historically, the wavelength domain has been split in "bands" by the use of photometric systems and observing bands in the different domains. UCDs tried to adjust to this scheme as it is useful to find comparable quantities in a simple datamining model. What was done was very similar to have POS_EQ_RA_MAIN_1H, POS_EQ_RA_MAIN_2H... The position in the sky, of course, was never constrained by instrumental settings and systems. Today though, we have seen the broad possibilities of searching in archived data and this scheme attached to UCDs can hardly cope with some of the newly imposed requirements. The problem is not to add more UCDs to the system, as that was seen as a clear possibility since the beginning, but to have a system able to respond in a simple way to queries like "I want observations in this wavelength regime". UCDs can (and should) still be attached to columns for proper characterization of each data column, but a solution can be found in a similar way to characterizing the sky coverage (where one can split the sky in arbitrary tiles and put 1 when observations exist in a given catalogue). What I propose is a system which represents the whole electromagnetic spectrum in a linear way. If one takes the space of log(wavelength) going from 0.003 nm to 3km we have nearly 15 decades of coverage, which could be split in 1000 parts to give enough spectral resolution. Each photometric filter and bandpass will be represented by a series of bits which should be set to 1. A catalogue which contains Jonhson's V magnitue and B-V colour index plus some radio data and X-ray data would have a fingerprint where the bits on will be the ones corresponding to the B and V filters, the radio bandpass(es) and the X-ray band(s). This information will be part of the catalogue's metainformation and should be stored in data-centers and possibly registries to which users will have access. A user may then submit a query to a registry where s/he can decide which ranges in the EMS to search for. The registry machine will create a "search fingerprint" to compare with the catalogues it knows about and/or it could pass this fingerprint to another grid service which will do its own search. The user should then receive a list of catalogue handles which satisfy his/her requirements. A number of scenarios of search logics can be envisioned, from full intersection to partial intersection of fingerprints. That is a point we should develop based on use cases. I've experimented with a solution where I split the interval (in log) in 15000 bins (1000 per decade) and it gives a reasonably good resolution in all wavelength regimes. More testing is needed and suggestions are welcome. The time domain It presents itself as a similar problem to wavelength. One could define a starting point, and fix a time resolution, then each timed observation could be defined by a series of bits set to 1 wherever this observation falls. If one were to take 1 day as the time resolution, 100yrs require 36525 bits If one were to take 1 hour as the time resolution, 100yrs require 876600 bits The numbers look large, but one can represent the time coverage of a catalogue by just a few bits set to 1. Each catalogue time-fingerprint can be reconstructed on the fly. Again, a user may form his/her own time-fingerprint to perform searches, like "I'm interested in recovering data for region X observed in this period of time or periods separated by one year afterwards", eg, one wants to measure proper motions. In summary, by linearizing and binning these two quantities one can build search engines which give users high flexibility to perform searches and solve so the problem of multiplying UCDs to high levels. Patricio F. Ortiz On Mon, 17 Mar 2003, Anita Richards wrote: > > > Sebastien's 'UCD: Status and Perspectives' gives a very clear summary of > the recent discussions, responding on the basis of the considerable ..... --- Dr. 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 jcm at head-cfa.cfa.harvard.edu Wed Mar 19 05:36:13 2003 From: jcm at head-cfa.cfa.harvard.edu (jcm at head-cfa.cfa.harvard.edu) Date: Wed, 19 Mar 2003 08:36:13 -0500 (EST) Subject: UCD Status and Perspectives Message-ID: <200303191336.h2JDaDs05535@urania.cfa.harvard.edu> Dear Patricio, I think your suggestion ("UCDs for the photometric and time domain") works well for search engines and catalog queries, but it does not work to describe the data precisely enough to do on-the-fly interconversions ("match this table with fluxes at 4100A to this other table with fluxes at 4200A assuming a spectral index of 0.7") at the level of accuracy wanted for data analysis, never mind the problem of "convert this kind of B filter to this slightly different kind of B filter". Maybe that's OK, but in that case some other language analogous to UCDs will be needed for robust data description and we should be clear that UCDs will only apply to the query process (indeed their current and original intention). Anita's comments are well taken, but perhaps she can clarify: you are suggesting replacing PHOT_FLUX_RADIO_1.4G with PHOT_FLUX and a header UCD of OBS_FREQUENCY 1.4 GHz, right? But what if you have three flux columns in the catalog, ( a bit like the problem you alluded to of TIME_DATE for start and stop), say PHOT_FLUX_RADIO_1.4G and PHOT_FLUX_RADIO_5.0G and PHOT_FLUX_RADIO_22.0G? Then we need three OBS_FREQUENCY header UCDs and a way to map them to the respective columns - which is essentially the 'parameterized UCD' I have suggested elsewhere. - Jonathan McDowell From pfo at star.le.ac.uk Wed Mar 19 06:18:43 2003 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Wed, 19 Mar 2003 14:18:43 +0000 (GMT) Subject: UCD Status and Perspectives In-Reply-To: <200303191336.h2JDaDs05535@urania.cfa.harvard.edu> Message-ID: Dear Jonathan, On Wed, 19 Mar 2003 jcm at head-cfa.cfa.harvard.edu wrote: > Dear Patricio, > > I think your suggestion ("UCDs for the photometric and time domain") > works well for search engines and catalog queries, but it does not work > to describe the data precisely enough to do on-the-fly interconversions > ("match this table with fluxes at 4100A to this other table with fluxes > at 4200A assuming a spectral index of 0.7") at the level of accuracy > wanted for data analysis, never mind the problem of "convert this kind > of B filter to this slightly different kind of B filter". Maybe that's > OK, but in that case some other language analogous to UCDs will be > needed for robust data description and we should be clear that UCDs will > only apply to the query process (indeed their current and original > intention). I couldn't agree more with you on this point. Discovering the existence of information is one issue, which could be solved with the scheme I proposed, and with UCDs but converting or transforming quantities is a completely different ball game. As we discussed in the meeting at CfA, full characterization of the filters and bandpasses should be achieved before attempting the conversion and a lot of "knowledge" or expertise will be required for us to get to this point. Can you expand on your first example please? "match this table with fluxes at 4100A to this other table with fluxes at 4200A assuming a spectral index of 0.7" What do you have in mind? Do you want to match by position first and then find the sources which have similar fluxes based on 4100 and 4200 band? I find your example quite interesting, that's why I'd like to know more what you have in mind. > > Anita's comments are well taken, but perhaps she can clarify: > you are suggesting replacing PHOT_FLUX_RADIO_1.4G with PHOT_FLUX > and a header UCD of OBS_FREQUENCY 1.4 GHz, right? But what if you > have three flux columns in the catalog, ( a bit like the problem > you alluded to of TIME_DATE for start and stop), say PHOT_FLUX_RADIO_1.4G > and PHOT_FLUX_RADIO_5.0G and PHOT_FLUX_RADIO_22.0G? Then we need three > OBS_FREQUENCY header UCDs and a way to map them to the respective columns > - which is essentially the 'parameterized UCD' I have suggested elsewhere. > > - Jonathan McDowell Although the last question is for Anita, let me jump in the case as well. If I understand well enough, when you produce a catalogue which contain observations in one frequency (band) one might think in calling the column PHOT_FLUX and qualify the whole catalogue. Well, that was exactly the situation we found in the published data. Tables made full sense when attached to their paper, and even the table name could tell us what band someone was observing. There were hundreds of tables where the column name was "Mag"; taking the table out of context (like in a table depository) one had no idea what this Mag meant, that's why UCDs were introduced, to solve this kind of degeneracy. I feel that if we do so with UCDs we'll go backwards in a sense. Jonathan, can you point me to a document with your proposed 'parameterized UCD'? I just searched with google and got nowhere :-( Cheers, Patricio --- Dr. 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 Markus.Dolensky at eso.org Thu Mar 20 07:58:55 2003 From: Markus.Dolensky at eso.org (Markus Dolensky) Date: Thu, 20 Mar 2003 16:58:55 +0100 Subject: UCDs status and perspectives References: <200303201516.h2KFG7P07723@rosetta.saclay.cea.fr> Message-ID: <3E79E53F.3050209@eso.org> Hi Pierre, I couldn't agree more on the notion of your second point: > 2) Adding UCD. > > As Patricio said, "the problem is not to add more UCDs", everbody > would agree on that, but it is certainly _how_ to perform > the metadata bank update, when _really_ needed. > A very strict and tedious approvment by an "expert group", > as proposed in sebastien's doc, is certainly not appropriate > for a lot of cases, where quick even instantaneous > response is needed. > Once more, migrating to parametrized atomic Descr (PAD?), > will perhaps facilitate their dynamic handling. It would be great if we could agree on some rules for using UCDs rather than looking at them individually. This might not be fully in line with the original idea when UCDs were invented as some sort of table column identifiers. The scope, however, is much broader now - it's about meta data in a more general sense. We need them in the registry, as query specifiers, as a way for interpreting VOTable docs, as tags in data models, ... Markus +--- | Markus Dolensky Mailto:Markus.Dolensky at eso.org | AVO Technical Lead Web: www.euro-vo.org | Voice: ++49 89 32006/261 Fax: ++49 89 32006/480 +--- From dide at discovery.saclay.cea.fr Thu Mar 20 07:16:07 2003 From: dide at discovery.saclay.cea.fr (DIDELON Pierre) Date: Thu, 20 Mar 2003 16:16:07 +0100 (MET) Subject: UCDs status and perspectives Message-ID: <200303201516.h2KFG7P07723@rosetta.saclay.cea.fr> Hello UCD Fan's and Pro's, the ongoing discussion seems very promising to me, and the experts certainly have a goog understanding of that's going on. Nevertheless I would like to make comments on three recurrent subjects. My point of view is perhaps obvious and trivial, but as UCD, and more generaly ontology, try to make implicit assumption became explicit, I felt free to post the following. The points are related to the UCD handling, the way of adding UCD, and UCD usage at different levels. 1) UCD Handling I was very happy to read the following in Sebastien's doc. "The hierchical tree is not fundamental - it's merely a way of classification". What is actually very important for me is the knowledge base represented by the UCDs, which certainly describe very well, even if not exhaustively the columns of astronomical catalogs. The ways, different people want to look at this metadata pond/container will certainly be differents. But actually the UCD structure and even the name structure itself does not promote or facilitate others point of view on this fabulous metadata bank. But as stressed also in sebastien's doc, "it is clear that the definition of right roots does not exist, and is influenced by the user's own needs". It means that a static absolute and final UCD structuration is not realistic, and so "different structures corresponding to different views" of UCD must coexist. It is one more argument in addition to a parametrized and atomic definition of Descriptors. 2) Adding UCD. As Patricio said, "the problem is not to add more UCDs", everbody would agree on that, but it is certainly _how_ to perform the metadata bank update, when _really_ needed. A very strict and tedious approvment by an "expert group", as proposed in sebastien's doc, is certainly not appropriate for a lot of cases, where quick even instantaneous response is needed. Once more, migrating to parametrized atomic Descr (PAD?), will perhaps facilitate their dynamic handling. To clarify my point of view, perhaps a little bit too broad and common, let's take an example. Try to imagine a Web service which can create data on the flight and must be able to assign UCDs to these _dynamic_ data. A very simple example would be a data bank of SED or photometric data covering a very wide spectral range, and which can delivered a flux, mag, color or anyelse sensible combined data at whatever wavelength required by the user. This service don't want to register one predifine UCD for any data conmbination but needs only to parametrize the UCD and perhaps, in the most complex case re-organize the basic predifined atoms. Then the atoms definitions and the combination rules allowed must be approved by an "expert group", but the parameter s and the combinations used can be freely adapted by each data provider, portal or anyelse service or tool. 3) UCD usage at different level As already mention by sebastien and anita, any UCD used as column description in one dataset can be used as header or global metadata in another dataset, and some times an association between these two uses must be performed. To my feeling the answer already exist in the VOTable structure. UCDs exist in two class, FIELD and PARAM. And it is obvious that they are specialization of a more general class which could be called vardescr (variables descriptors). In the particular case of PARAM instances, the values are attached to the description, while for the FIELD the data link is more loosely. Adressing this more general class would certainly facilitate the association between global/header metadata and column description. The main problem is that UCD are historically concerned with column descriptors and so cover very well this field of interest but it is not obvious how exhaustive are the existing UCD to cover the needs of global metadata used in headers (Fits) or definitions (VOTable). I hope that these comments are not out of scope, and that the expression of my feelings are not unpleasant to anybody. Sincerely yours, Pierre Didelon From dide at discovery.saclay.cea.fr Thu Mar 20 08:25:38 2003 From: dide at discovery.saclay.cea.fr (DIDELON Pierre) Date: Thu, 20 Mar 2003 17:25:38 +0100 (MET) Subject: UCDs status and perspectives Message-ID: <200303201625.h2KGPcu07938@rosetta.saclay.cea.fr> > From Markus.Dolensky at eso.org Thu Mar 20 17:01:00 2003 > To: DIDELON Pierre > CC: ucd at ivoa.net > Subject: Re: UCDs status and perspectives > > Hi Pierre, > > I couldn't agree more on the notion of your second point: > > > 2) Adding UCD. > > > > As Patricio said, "the problem is not to add more UCDs", everbody > > would agree on that, but it is certainly _how_ to perform > > the metadata bank update, when _really_ needed. > > A very strict and tedious approvment by an "expert group", > > as proposed in sebastien's doc, is certainly not appropriate > > for a lot of cases, where quick even instantaneous > > response is needed. > > Once more, migrating to parametrized atomic Descr (PAD?), > > will perhaps facilitate their dynamic handling. > > It would be great if we could agree on some rules for using UCDs rather > than looking at them individually. I totally agree. What I had in mind is not a traduction one by one of all the existing UCD, but the definition of atoms and parameters which allow to handle the existing UCD in a more flexible way. So, PAD can point to UCD, but the reverse would perhaps not always be true. But it is not clear to me, if the two systems coexists in the future, which will be the needs of update synchronism and joined maintenance! >...This might not be fully in line with > the original idea when UCDs were invented as some sort of table column > identifiers. The scope, however, is much broader now That's why PAD is perhaps more appropriate than UCD, because we no longer deal only with column descriptors but with _global_ metadata. >...- it's about meta > data in a more general sense. We need them in the registry, as query > specifiers, as a way for interpreting VOTable docs, as tags in data > models, ... > > Markus > Sorry for being unclear with rough english, cordially, Pierre From borne at rings.gsfc.nasa.gov Tue Mar 25 14:30:55 2003 From: borne at rings.gsfc.nasa.gov (Kirk Borne) Date: Tue, 25 Mar 2003 17:30:55 -0500 (EST) Subject: UCDs status and perspectives Message-ID: <200303252230.RAA09366@rings.gsfc.nasa.gov> Ray: I believe that your suggestions carry a lot of merit. I had a nagging feeling when reading Jonathan's comments that our metadata efforts could easily diverge (as you suggest) if we are not careful. The data model is key to this -- consequently, the ability of XML Schema to carry the knowledge about both the data model and the metadata relationships, using standardized techniques, makes a lot of sense -- especially with regard to reconciling the two metadata approaches that you mention. I think that disaster can be averted, and Jonathan's and your suggestions can illuminate the way. The PHOT_FLUX(PHOT_BAND_ID) is an excellent example of the problem and a good solution. - Kirk > Date: Tue, 25 Mar 2003 15:15:13 -0600 (CST) > From: Ray Plante > To: ucd at ivoa.net > Subject: Re: UCDs status and perspectives > > We have been bouncing around in our community two models for tagging > metadata that we will eventually need to reconcile. One is essentially > XML-based and the other is based on the current UCD set. The former makes > the most sense for descriptions stored in a registry, while the latter is > useful for tagging a set of data (e.g. in a table column). Both are > important and necessary. Both reflect a common data model. However, it > would inconvenient if not disasterous if there were not a direct > correlation between to two representations. > > I feel the answer can be found in existing XML technologies. I would > claim that the atomic descriptors being discussed (PAD, PCD, etc.) are > really just a short hop from an XML model. The main thing that PCD has > in common with XML tags is that both are essentially pointers into a > data model. The main difference between them is that with a UCD/PCD, we > need that pointer to be representable as a simple string (e.g. that can be > put in the ucd attribute in a VOTable). > > XML has such a pointer; it's called an XPath. If we define the data > model as an XML Schema, then our UCD/PCDs fall right out. There are other > advantages: > * XML Schema provides a machine readable form for a data dictionary. > * The extensibility of XML schemas provides the extensibility for > UCDs automatically. > * When necessary, metadata in direct XML form (as envisioned in a > registry) into UCD-tagged VOTable data. > * The modeling that Jonathan proposed is largely still applicable. > * The approach is consistant with the data modeling activities that > have been done to date. > > As an example, consider the example Jonathan cited: > > > For instance the two UCDs PHOT_FLUX_RADIO_1.4G > > and PHOT_FLUX_RADIO_1.6G would map to a single PCD > > PHOT_FLUX(PHOT_BAND_ID) with PHOT_BAND_ID taking the values 1.4 GHz and > > 1.6 GHz. > > Suppose a data model defined more or less in the following way: > > > > > > Secondly, however, how much can be done 'seamlessly' based on the > existing, working CDS UCD system? It is important to keep that going, not > just because astronoemrs depend on it and want to see it do these things > they hear about in reports from VO meetings, but because we need to test > developments on the community as much as possible, and we will find > subjects much more easily if we can give people prototypes which look as > familiar as possible (as with the AVO demo). Also many new functions e.g. > the SED tool and VOPlot are being developed based on the existing UCDs. I completely agree. It will take some time to shake out a refactored model that covers everything already in the current UCDs. Therefore, we will need a mechanism for continuing to support UCDs as they are now. It's important to note that the current UCDs represent the most practical use-case as they were drawn directly from real catalogs. As we build up more complicated models, e.g. photometry measurements, even images, we will need to make sure that the relevent UCD concepts are covered. In fact, that could be made a formal of the definition process. cheers, Ray From roy at cacr.caltech.edu Wed Mar 26 08:19:13 2003 From: roy at cacr.caltech.edu (Roy Williams) Date: Wed, 26 Mar 2003 08:19:13 -0800 Subject: Fw: UCDs and XML Message-ID: <003a01c2f3b3$727a2be0$6601a8c0@roxy> My thinking on UCD is going around the idea of "recognition". In writing code for VO applications, I am looking for specific UCDs. Reading the result of a cone search means finding the POS_EQ_RA_MAIN. Reading the result of a SIAP means looking for the UCD called VOX:Image_AccessReference. Therefore it should be allowed to have multiple UCDs describing the same attribute, so that different applications can recognize and use it. One person sees a galaxy, another sees a database record, another sees clip-art -- but it's all the same entity underneath. This recognition idea allows us to use UCD to subclass objects. If I have a table from a cone search, then it must have UCDs corresponding to RA, Dec, ID. Let us subclass this, for example, to a service that returns black-hole candidates. In this case, we would expect further UCDs to be present: BH_mass and BH_Spin. There is a lot that can be done with UCD, and the real question is how to allow this semantic flexibility to blossom, but without having everyone make their own UCD and losing all interoperability! Roy --- Caltech Center for Advanced Computing Research roy at cacr.caltech.edu 626 395 3670 From jcm at head-cfa.cfa.harvard.edu Mon Mar 24 19:43:19 2003 From: jcm at head-cfa.cfa.harvard.edu (jcm at head-cfa.cfa.harvard.edu) Date: Mon, 24 Mar 2003 22:43:19 -0500 (EST) Subject: UCDs status and perspectives Message-ID: <200303250343.h2P3hJN18502@urania.cfa.harvard.edu> Dear UCD list, Following the discussion of last week, I append below some notes on a controlled vocabulary related to UCDs that I sent to Sebastien some time ago. It represents a more radical change than most people are probably ready to go for, but I think it may be relevant to the current discussion. - Jonathan McDowell -------------------------------------------------------------------- I've been thinking a lot this week about UCDs and their possible role in VO data models. My conclusion is that while the present design of UCDs is very useful for the catalog cross matching problem, we need a somewhat more flexible data dictionary to handle the data analysis problem. I think we need both kinds of dictionary, with of course a mapping between the two for the applications that need the appropriate ones. Specifically, I propose to parallel the UCDs with PCDs (Parameterized Content Descriptors). These differ from UCDs in that they can include functional parameters. For instance the two UCDs PHOT_FLUX_RADIO_1.4G and PHOT_FLUX_RADIO_1.6G would map to a single PCD PHOT_FLUX(PHOT_BAND_ID) with PHOT_BAND_ID taking the values 1.4 GHz and 1.6 GHz. This reflects the fact that PHOT_FLUX_RADIO_1.4G and PHOT_FLUX_RADIO_1.6G do not really describe fundamentally different physical quantities. The PCD also differ from UCD in that they are organized to form the bottom level attributes of a structured data model for astronomy, so the top level domains are different from the UCDs. So far my proposed main PCD fields are (1) about the universe PHYS Physical data which is true generally and not a property of a specific astronomical location or object. POP Properties of a population of astronomical objects SAMPLE Properties of a sample of sources. OBJ The things we study are astronomical objects in space (with more or less defined boundaries). MED To understand the physics of these objects we describe the physical medium constituting them, including matter (solid, liquid, gas, plasma), radiation, and electromagnetic, gravitational and other fields. LOS A direction on the sky we observe corresponds to a line of sight along which objects may lie. (2) about our observations of the universe SRC When we have a dataset, we can identify a subset of that dataset as a source, which we can identify with an object. PCDs are SRC when they are to do with the direct measurements of an object with a telescope, and OBJ when they are to do with the intrinsic properties of the object (in its rest frame, without LOS effects etc). BKG A special sort of source we call the background OBS We have to describe things to do with the observing instrument, configuration and conditions. (a major subset is OBS_COV_ which ) SURVEY_ A group of observations SRC_PHOT We measure the absolute intensity of radiation from the sky SRC_SPEC Like PHOT, but dealing with many photon energies at once? EVENT A detected photon or background event _POS Information about positions (also OBJ_POS etc) _TIME Information about times (also in OBS_COV_TIME...?) (3) about our analysis of the observations DATA We also need to describe things about the datasets themselves. REFER Bibliographic info Below I give my first attempt at mapping the UCDs to a data model oriented set of PCDs. There are quite a few UCDs that I still have to understand by looking at their actual use in catalogs, so this is only a sketch and some are left blank. At the end I give the beginnings of extra UCD/PCD names needed for X-ray astronomy datasets. Appendix 1: A possible list of PCDs to be the data model equivalent of UCDs. Given in UCD alphabetical order. PHYS_AT_ AT Atomic Data PHYS_AT_COLL AT_COLL Atomic Collisional Quantities PHYS_AT_COLL_RATE AT_COLL_EXCIT-RATE Collisional Excitation Rate # Is this an atom prop or a line prop? PHYS_AT_COLL_STRENGTH AT_COLL_STRENGTH Collisional strength PHYS_AT_CONFIG . AT_CONFIG Electronic Configuration PHYS_AT_CONST? AT_CONSTANT Atomic Constant PHYS_AT_DAMPING_ AT_DAMPING Atomic Damping Quantities PHYS_AT_DAMPING_VDW AT_DAMPING_VDWAALS Van der Waals damping ? AT_DATA Various Atomic data PHYS_AT_DEGEN? AT_DEGENERACY Atomic Degeneracy Parameter PHYS_AT_DIPOLE_? AT_DIPOLE Atomic Dipole ? AT_DIPOLE_MISC Atomic Dipole PHYS_AT_DIPOLE_MOMENT AT_DIPOLE_MOMENT Atomic Dipole Moment PHYS_AT_EIGENVECTOR AT_EIGENVECTOR Atomic Eigenvector PHYS_AT_ELECCOEFF AT_ELEC-COEFF Atomic Electric Coefficient PHYS_AT_ELEMENT AT_ELEMENT Atomic Element Name or number, eventually with ionization stage # See also PHYS_AT_Z PHYS_PLASMA_EMISSIVITY_AT AT_EMISSIVITY Atomic Emissivity #What does this mean? It's a function of physical conditions. #It's a property of the plasma expressed on a per-atom basis. #So it's not PHYS_AT_EMISSIVITY but #eg PHYS_PLASMA_EMISSIVITY_AT(Z,T,n) PHYS_AT_ENERGY_ AT_ENERGY Atomic Energy or Potential #Heterogeneous class? PHYS_AT_TRANS_NAME AT_ENERGY_BAND Atomic (molecular) Energy Band PHYS_AT_TRANS_ENERGY_DISCREPANCY AT_ENERGY_DIFF Energy difference between experimental and calculated quantities PHYS_AT_TRANS_ENERGY AT_ENERGY_EXCIT Excitation Energy PHYS_AT_STATE_ENERGY_IONIZATION AT_ENERGY_IONIZ Ionization Energy or Potential PHYS_AT_STATE_ENERGY(LEVEL) AT_ENERGY_LEVEL Energy Level PHYS_AT_ENERGY_FORM AT_ENERGY_FORMATION Formation energy (or heat for molecules) PHYS_AT_ENERG_POT AT_ENERGY_POTENTIAL Atomic Energy or Potential PHYS_AT_STATE_ENERGY_ROT AT_ENERGY_ROTATION Rotation Energy PHYS_AT_STATE_ENERGY_TOT AT_ENERGY_TOTAL Total atomic energy PHYS_AT_TRANS_FREQ AT_FREQUENCY Transition Frequency PHYS_AT_TRANS_FREQ_REST AT_FREQUENCY_NU Transition Frequency at rest PHYS_AT_TRANS_FREQ_ROT AT_FREQUENCY_ROTAT Rotation Frequency PHYS_AT_FS_ AT_FS Fine Structure Quantities PHYS_AT_FS_COLLSTR AT_FS_COLL-STR Fine Structure Collision Strength PHYS_AT_FS_CONST? AT_FS_CONSTANT Fine Structure Constant PHYS_AT_TRANS_FS_WIDTH AT_FS_CONTRIB Fine Structure Contribution to Line Profile PHYS_AT_TRANS_FS_SPLIT AT_FS_SPLIT Fine Structure Splitting PHYS_AT_TRANS_GA AT_GA Atomic ga value PHYS_AT_LINE_INTENSITY AT_INTENSITY Line Intensity PHYS_AT_ION_ AT_ION Ions PHYS_AT_ION_ID AT_ION_ID Ion Identification PHYS_AT_ION_STAGE AT_ION_STAGE Ionization Stage PHYS_AT_LANDEFACT AT_LANDE-FACT Lande Factor (gf) PHYS_AT_LEVEL AT_LEVEL Level Identification PHYS_AT_STATE_LIFE AT_LIFETIME Radiative Lifetime PHYS_AT_LINE_ AT_LINE Atomic or Molecular Lines # What is the difference between LINE and TRANS? PHYS_AT_LINE_EMISSIVITY AT_LINE_EMISSIVITY Line Emissivity PHYS_AT_LINE_FLOURYIELD AT_LINE_FLUOR-YIELD Line Fluorescence Yield PHYS_AT_LINE_ID AT_LINE_ID Line Identification PHYS_AT_LINE_STRENGTH AT_LINE_STRENGTH Line Strength PHYS_AT_LINE_MAIN-TERM? AT_MAIN-TERM Main Term PHYS_AT_MOL_ AT_MOL Quantities Related to Molecules PHYS_AT_MOL_DIELFN AT_MOL_DIEL-FN Molecular Dielectric Function PHYS_AT_MOL_EDISSOC AT_MOL_DISS-ENRGY Molecular Dissociation Energy PHYS_AT_MOL_ID AT_MOL_ID Molecule Identification PHYS_AT_TRANS_MOL_LEVEL AT_MOL_LEVEL Molecule Transition Level PHYS_AT_MULTIPLET_ AT_MULTIPLET Quantities Related to Multiplets PHYS_AT_MULTIPLET_ID AT_MULTIPLET_ID Multiplet Identification PHYS_AT_MULTIPLET_N AT_MULTIPLET_N Multiplet Number element PHYS_AT_Z AT_NUMBER Atomic Number PHYS_AT_OSC_ AT_OSC Oscillator Related Quantities PHYS_AT_OSC? AT_OSC_STRENGTH Oscillator Strength PHYS_AT_PARITY AT_PARITY Atomic Parity PHYS_AT_Q_ AT_Q-N Atomic Structure, Quantum Numbers PHYS_AT_Q_L AT_Q-N_ANG-MOM Angular Momentum Quantum Number PHYS_AT_Q_K AT_Q-N_K K quantum number PHYS_AT_Q_UNK AT_Q-N_MISC Atomic Structure Quantum Number PHYS_AT_Q_ORB AT_Q-N_ORBITAL Orbital Quantum Number PHYS_AT_Q_PRIN AT_Q-N_PRINCIPAL Principal Quantum Number PHYS_AT_Q_PRIN1 AT_Q-N_PRINCIPAL_FIRST First Principal Quantum Number PHYS_AT_Q_PRIN2 AT_Q-N_PRINCIPAL_SECOND Second Principal Quantum Number PHYS_AT_Q_ROT AT_Q-N_ROTATIONAL Rotational Quantum Number PHYS_AT_Q_TOR AT_Q-N_TORSIONAL Torsional Quantum Number PHYS_AT_Q_VIB AT_Q-N_VIBRATIONAL Vibrational Quantum Number PHYS_AT_REACTION AT_REACTION Atomic Reaction PHYS_AT_SHELL AT_SHELL-NUMBER Shell Quantum Numbers PHYS_AT_SPECIES_LIST AT_SPECIES Atomic Species Participating in a Reaction PHYS_AT_TRANS_STARK_ AT_STARK Stark Effect PHYS_AT_TRANS_STARK_BROAD AT_STARK_BROAD Broadening due to Stark Effect PHYS_AT_TRANS_STARK_INT AT_STARK_INTENSITY Intensity due to Stark Effect PHYS_AT_TRANS_SWEIGHT AT_STAT-WEIGHT Statistical Weight PHYS_AT_TRANS_WIDTH? AT_STRENGTH-PARAM Strength Parameter or Expect Width PHYS_AT_TRANS AT_TRANS Quantities Related to Transitions PHYS_AT_TRANS_BRANCH AT_TRANS_BRNCH-RATIO Transition Branching Ratio PHYS_AT_TRANS_ENERGY AT_TRANS_ENERGY Transition Energy (or wave number) PHYS_AT_TRANS_ID AT_TRANS_ID Transition Identification PHYS_AT_TRANS_LEVELS AT_TRANS_LEVELS Transition Level PHYS_AT_TRANS_PROB AT_TRANS_PROB Transition Probability PHYS_AT_TRANS_STRENGTH AT_TRANS_STRENGTH Transition Strength PHYS_AT_TRANS_TYPE AT_TRANS_TYPE Transition Type PHYS_AT_TRANS_RECOMB AT_TRANS_RECOMBIN Recombination coefficients in atomic transitions PHYS_AT_TRANS_LAMBDA AT_WAVELENGTH Laboratory or Theoretical Line Wavelength PHYS_AT_WEIGHT AT_WEIGHT Atomic Weight OBJ_CLASS+ CLASS Various Classification Descriptors OBJ_CLASS_CODE CLASS_CODE Classification Code OBJ_CLASS_COLOR CLASS_COLOR Color Classification OBJ_CLASS_STAR_MK_TYPE OBJ_CLASS_CLG_DIST CLASS_DISTANCE Abell Distance Class OBJ_CLASS CLASS_MISC Various Classification Descriptors OBJ_CLASS CLASS_OBJECT Object Type Classification OBJ_CLASS_CLG_RIC CLASS_RICHNESS Abell Richness Class OBJ_CLASS_UNK_GAL CLASS_STAR/GALAXY Star galaxy discriminator or classification. OBJ_CLASS_UNK_BM CLASS_STRUCT Structure Classification (e.g. cluster Bautz-Morgan classification) _CODE CODE Codes or Flags _ERROR_CODE CODE_ERROR Flag denoting uncertainty about a given quantity _FLAG_LIMIT CODE_LIMIT Lower or Upper limit Flag _FLAG_MEMB CODE_MEMB Membership Code _CODE CODE_MISC Miscellaneous Codes or Flags OBJ_CLASS_MULT CODE_MULT Codes related to Multiplicity (particularly stars) OBJ_CLASS_MULT CODE_MULT_FLAG A code or flag indicating a multiplicity of binarity OBJ_CLASS_MULT_N CODE_MULT_FREQUENCY Multiplicity Frequency Code OBJ_CLASS_MULT_N CODE_MULT_INDEX Multiplicity Index Code _QUAL CODE_QUALITY Quality Code OBJ_CLASS_VAR CODE_VARIAB Variability Code or Flag DATA_ DATA Quantities Related to the Data _SCALE_EXP DATA_FACTOR-EXP Scale Factor Exponent (Base 10) DATA_LINK DATA_LINK Link to additional data (in VizieR or any other database) _MAX DATA_MAXIMUM Maximum data value found in a database column _SCALE DATA_SCALE-FACTOR Factor to Convert a Data Column to a normal value _DATATYPE DATA_TYPE Data Type DYN_ DYN Dynamic Data Quantities (mixed column content) DYN_QUANTITY DYN_QUANTITY Used when a Column means more than one thing. DYN_VALUE DYN_VALUE Identification of a Dynamic Value _ERROR ERROR Error or Uncertainty in Measurements POS(,EQ)_RA_ERROR ERROR # I/176 POS(,EQ)_DEC_ERROR ERROR # I/176 PHOT_FLUX(5 GHz)_ERROR ERROR # VIII/14 SRC_REG EXTENSION Quantities used to describe the extension in the sky of objects SRC_REG_AREA EXTENSION_AREA Angular Area Covered by an Object SRC_REG_DIA_DEC EXTENSION_DEC Angular Extension in Declination SRC_REG_DIA EXTENSION_DIAM Angular Diameter or Size of the Major Axis SRC_REG_DIA_FWHM EXTENSION_FWHM Angular Full Width at Half Maximum (FWHM) SRC_REG_DIA_FWHM EXTENSION_FWHM_CIRC Angular Full Width at Half Maximum (FWHM) SRC_REG_DIA_MAJ_AXIS_FWHM EXTENSION_FWHM_MAJ Angular FWHM along the Major Axis SRC_REG_DIA_MIN_AXIS_FWHM EXTENSION_FWHM_MIN Angular FWHM along the Minor Axis SRC_REG_DIA_MIN_AXIS_FWHI EXTENSION_HALFINT Angular Size at Half Intensity along the Minor Axis SRC_REG_DIA_MIN_AXIS EXTENSION_MIN Angular Diameter of an object along the Minor Axis SRC_REG_DIA_BEAMS EXTENSION_NORM Angular diameter normalized to beam size SRC_REG_DIA_RA EXTENSION_RA Angular extension in right ascension SRC_REG_RADIUS EXTENSION_RAD Angular radius of an object or Semi-major axis SRC_REG_RADIUS_SCALELENGTH EXTENSION_SC-LENGTH Angular Scale Length (bulge or disk) SRC_REG_RADIUS_MIN_AXIS EXTENSION_SMIN Angular size of Semi-Minor Axis _FIT FIT Fits of Models to Observational Data _FIT_ERR FIT_ERROR Fit Error _FIT_GOODNESS FIT_GOODNESS Fit Goodness _FIT_ID FIT_ID Identification of the fit or solution POP_LF FIT_LF Luminosity function POP_LF_FIT_PARAMS FIT_LF Fit of Luminosity Function POP_LF_FIT FIT_LF_GENERAL Fit of Luminosity Function POP_LF_FIT_MAG? FIT_LF_MAG Magnitudes related to the LF POP_LF_FIT_MAG_MAX FIT_LF_MAG_MAX Magnitude interval upper limit POP_LF_FIT_MAG_MIN FIT_LF_MAG_MIN Magnitude interval lower limit _FIT_RATIO FIT_MEAS/THEOR Ratio of Measurement to Theoretical Value _FIT_PAR FIT_PARAM Fit Parameter _FIT_PAR_ID FIT_PARAM_ID Fit Parameter Identification _FIT_MISC FIT_PARAM_MISC Miscellaneous fit parameters POS(,EQ)_RA_STAT_SIGMA FIT_PARAM_MISC # In I/176 S0RA, FIT_PARAM_MISC is the sigma-0 (?) for the RA _FIT_COVAR FIT_PARAM_COVAR Covariance of the fitting parameter _FIT_RESID FIT_RESIDUAL Fit Residual _FIT_CHI2 FIT_CHI2 Chi-square Fit Measurement _FIT_SIGMA FIT_STDEV Fit's Standard Deviation _FIT_TYPE FIT_TYPE Fit or Solution Type POS(,EQ)_FIT_TYPE FIT_TYPE I/176 _ZERO FIT_ZP Fit Zero Point (mostly in linear fits) PHOT_COL_INDEX_DIFF FIT_ZP # In III/218 DIFF, FIT_ZP is the scatter in mag of the spectroscopic index POS(,EQ)_DEC_STAT_SIGMA FIT_ZP # In I/176 S0DE, FIT_ZP is the sigma-0 (?) in arcseconds? for the Dec - ID Fields Used as Identifiers OBJ_ID_ALT ID_ALTERNATIVE Alternative identification OBJ_ID_FIELD ID_AREA Area Identification (usually in a photographic plate) SRC_ID_XID ID_ASSOCIATED Identification of Associated Object (counterpart) SRC_ID_AUTHOR ID_AUTHOR Author Name SRC_ID_CAND ID_CANDIDATE Candidate Identification SRC_ID_CAT ID_CATALOG Catalog Identification SRC_ID_FCHART ID_CHART Finding Chart Identification SRC_ID_COMP ID_COMPARISON Name of a Comparison Object SRC_ID_CONSTEL ID_CONSTEL Constellation Name SRC_ID_XID ID_CROSSID Cross Identification (counterpart) OBS_DB_ID ID_DATABASE Database Identification OBS_DS_ID ID_DATASET Data-Set Identification OBS_EXP_ID ID_EXPOSURE Exposure Identification INST_FIBER ID_FIBER Fiber Optics Identification (for M.O.S.) OBS_FIELD ID_FIELD Field Identification SRC_NOTES_FIG ID_FIGURE Figure Identification Number SRC_NOTES_FILE ID_FILE File Identification SRC_NOTES_FRAME ID_FRAME Frame Identification ? ID_GROUP Group Identification OBS_AUTHOR_CODE ID_HUMAN Identification of Discoverer or Observer SRC_DISCOVERER_CODE ID_HUMAN SRC_ID_INTERNAL ID_IDENTIFIER Identification of a source or object, incomplete or for internal use. OBS_IMAGE_ID ID_IMAGE Image Identification SRC_ID (or OBJ_ID?) ID_MAIN Main Identifier of a Celestial Object SRC_ID:1 ID_MAIN:1 First component of an identification field. SRC_ID:2 ID_MAIN:2 Second component of an identification field. SRC_ID:3 ID_MAIN:3 Third component of an identification field. ? ID_MAP Map Identification SRC_CAT_ID ID_NUMBER Numeric Identification (usually sequential) ? ID_PARAM Identification or name of a parameter, or the name of a column in a table SRC_PARENT ID_PARENT Parent Identification (galaxy, cluster, nebulae) OBS_PLATE ID_PLATE Plate Identification OBS_REGION_ID ID_REGION Region Identification (not necessarily sky region) OBS_SET_ID ID_SET Set or Subset Identification, also bin or sample number OBS_SITE_ID ID_SITE Site/Location/Observatory/City/Country identifier INST_APER_ID ID_SLIT Slit Identification (usually in the context of M.O.S.) # Hmm MOS have many apertures, 1 disperser? SRC_ID_SURVEY ID_SURVEY Survey Identification SRC_ID_TABLE ID_TABLE Table Identification SRC_ID_TARGET? ID_TARGET Target Identifier OBJ_CLASS_VAR? ID_VARIAB Variable Object Identification DATA_PROC_SYS_VER ID_VERSION Identification of the software version. ? ID_VOLUME Volume Identification ? ID_ZONE Durchmusterung zone identification/sign INST_ INST Instrumental Quantities - INST_ANG Angular Properties of the Instruments/Telescopes SRC_OFFAX INST_ANG_OFFAXIS Off-axis angle respect to main direction of observation # Presumably the instrument coords of a source, not a prop of the instru OBS_SITE_ORBIT_PHASEANG INST_ANG_PHASE Satellite phase angle INST_RESP_SPATIAL_RES INST_ANG_RESOL Angular resolution of instrument OBS_SITE_ORBIT_ANGVEL INST_ANG_VEL Satellite angular velocity INST_DET_NOISE_TANT INST_ANTENNA-TEMP Antenna temperature INST_GEOM_DIA INST_APERT Instrument/telescope aperture INST_GEOM_AREA INST_AREA Collecting area or detector area PHOT_BKG_INST INST_BACKGROUND Background contribution INST_COV_BAND INST_BAND Instrumental Band quantities INST_CAL_BAND_DRIFT INST_BAND_DRIFT Band's drift rate INST_COV_BAND_TRANS? INST_BAND_PASS Bandpass INST_COV_BAND_WIDTH INST_BANDWIDTH Spectral window used for the observation INST_INT_BASELINE INST_BASELINE Baseline (interferometry) INST_RESP_SPATIAL INST_BEAM Beam properties ? INST_BEAM_MISC Miscellaneous beam properties INST_RESP_SPATIAL_RES INST_BEAM_SIZE Beam width or size INST_DET_NOISE_TBEAM INST_BEAM_TEMP Beam temperature INST_PHOT_CAL INST_CALIB Instrument calibration quantities INST_PHOT_CAL_ERR INST_CALIB_ERROR Instrument calibration error ? INST_CALIB_MISC Miscellaneous instrument calibration quantities ? INST_CALIB_PARAM Calibration parameter ? INST_CORR-FACTOR Correction (no only correction factor) INST_DET INST_DET Detector parameters INST_PHOT_FLUX_LIMIT INST_DET_LIMIT Detector limit UNK INST_DET_MISC Miscellaneous quantities related to the detector (plate or CCD) INST_GEOM_SIZE INST_DET_SIZE Detector size # number of pixels, vs DET_SIZE with mm size INST_DISP_SCALE INST_DISPERSION Dispersion scale in a spectrograph INST_QE INST_EFFICIENCY Instrument efficiency PHOT_ERR_INST INST_ERROR Errors associated to the instrument INST_FILTER INST_FILTER Filter characteristics INST_FILTER INST_FILTER_CODE Filter characteristics type/code INST_COV_BAND_FWHM INST_FILTER_FWHM FWHM of the used filter (also bandpass) INST_COV_BAND_TRANS INST_FILTER_TRANSM Transmission characteristics of the filter (response) INST_NAME INST_ID Instrument/Detector Identification INST_LINE_WIDTH INST_LINE-WIDTH Instrumental Line-Width INST_DET_NOISE INST_NOISE Detector/Instrument noise level rms INST_PARAM? INST_PARAM Various Instrumental Parameters INST_GEOM_PIX_SIZE INST_PIXSIZE Pixel Size # distinguish pix size in mm and arcsec INST_DET_PLATE INST_PLATE Quantities related to Photographic Plates INST_DET_SIZE INST_PLATE_DIMENSION Size or plate dimension # Is the fact that it's a plate relevant? could be any detector SRC_OFFSET_PIX INST_PLATE_DIST Distance measurement on a plate # ? distance between two sources in pixels? INST_DET_PLATE_EMULSION INST_PLATE_EMULSION Plate Emulsion Type # Now we care about it being a plate, only plates have emulsion SRC_REG_DIA_PIX INST_PLATE_EXTENSION Extension of an object in a plate (in plate units) INST_DET_POS INST_POS Position on a detector or M.O.S template INST_PHOT_PRECISION INST_PRECISION Instrumental Precision # Presumably photometric? INST_RESP_SPATIAL INST_PSF Detector's Point Spread Function (PSF) INST_DET_QE INST_QE Detector's Quantum Efficiency SRC_DET_SN INST_S/N Instrumental signal to noise ratio (S/N) # What does this mean? The S/N for a particular source? INST_RESP_TIME_RES INST_SAMP-TIME Instrumental Sampling Time INST_GEOM_SCALE INST_SCALE Instrumental Scale (ccd or plate) # In arcsec/mm? otherwise pixel size INST_RESP_SPATIAL_RES INST_SEEING Seeing or fwhm of PSF INST_PHOT_FLUX_LIMIT INST_SENSITIVITY Detector's Sensitivity (Flux limit) INST_SETUP INST_SETUP Instrument configuration or set-up - INST_SKY Instrumental Sky Properties PHOT_COUNTS_SKY? INST_SKY_LEVEL Local Sky Level PHOT_TEMP_SKY INST_SKY_TEMP Sky Temperature PHOT_TEMP_SIGMA_SKY INST_SKY_SIGMA Sigma of sky value distribution - INST_SPECT Spectroscopic instruments' quantities INST_COV_BAND_LAMBDA_RANGE INST_SPECT_BAND Spectroscopic observation band INST_DISP_TYPE_CODE INST_SPECT_CODE Spectroscopic instrument specification (prism, grism, grating) INST_DISP_ORDER INST_SPECT_ORDER Spectral Order INST_DISP_SLIT_DX INST_SPECT_SLIT-LENGTH Slit Length INST_DISP_SLIT_DY INST_SPECT_SLIT-WIDTH Slit Width - INST_TEMP Instrument Temperature (radio regime) INST_DET_NOISE_TBEAM INST_TEMP_BEAM Beam Temperature or Brightness # TEMP_BEAM is a way of describing the instrument noise INST_DET_TSYS INST_TEMP_SYST System Temperature INST_DET_TRIGGER? INST_TRIGGER Detector's triggering Threshold INST_TYPE INST_TYPE Instrument Type INST_COV_BAND_VEL? INST_VELOC Velocity Quantities at the Instrumental Level INST_COV_BAND_VEL0 INST_VELOC_CENTRAL Instrumental Central Velocity INST_COV_BAND_VEL_RES INST_VELOC_SPACING Instrumental Velocity Channel Spacing INST_COV_BAND_VEL_RANGE INST_VELOC_WINDOW Detector's Velocity Range OBS_COV_BAND_LAMBDA INST_WAVELENGTH Observation's Wavelength properties # We should distinguish between the wavelength coverage designed into an instrument # and the wavelength coverage of a specific observation, I think the latter is meant here. OBS_COV_BAND_LAMBDA_RANGE INST_WAVELENGTH_COVERAGE Instrument's Wavelength Range OBS_COV_BAND_LAMBDA_EFF INST_WAVELENGTH_EFFECTIVE Observation's Effective Wavelength OBS_COV_BAND_LAMBDA INST_WAVELENGTH_VALUE Wavelength related to an instrument, filter, etc. MUTUAL_OCCULT(*OBJ) - MUTUAL_OCCULT(L) LUNAR-OCCULT Lunar Occultaion related quantities # Occultations of anything could have the same parameters. So let's specify that # it's lunar by an argument L, and generalize eg # MUTUAL_OCCULT(PLUTO)_ANG MUTUAL_OCCULT(L)_ANG LUNAR-OCCULT_ANGLE Lunar Occultation Contact Angle MUTUAL_OCCULT(L)_FRAC LUNAR-OCCULT_FRACTION Percentage of the moon illuminated during the time of occultation MUTUAL_OCCULT(L)_LIMBSLOPE LUNAR-OCCULT_LIMB-SLOPE Lunar Occultation Limb Slope _MODEL MODEL Quantities generated by Models SPEC_CONT_FLUX MODEL_CONTINUUM Continuum level _CORR MODEL_CORRECTION Correction or adjustment OBJ_VEL_DRIFT MODEL_DRIFT-VELOC Terminal drift velocity OBJ_GEOM_TRIAX MODEL_DYN-TRIAX Dynamical triaxiality ? MODEL_ENERGY Energy modeled quantities SPEC_SED_MODEL MODEL_ENERGY_DIST Energy distribution PHYS_BULK_EOS MODEL_EOS Equation of state PHYS_BULK_EOS_ID MODEL_EOS_ID Name of used equation of state LOS_ISM_EXT MODEL_EXTINCTION Interstellar extinction quantities LOS_ISM_EXT_COEFF MODEL_EXTINCTION_COEFF Insterstellar extinction coefficient # Extinction coeffs and other theory are always 'model'. _MODEL_FEATURE MODEL_FEATURE Model Feature PHOT_FLUX_MODEL MODEL_FLUX Modeled Flux _MODEL_ID MODEL_ID Model Identification SPEC_LINE_FLUX_MODEL MODEL_LINE-FLUX Model Spectral Line Flux PHOT_MAG_MODEL MODEL_MAG Model-generated Magnitude _MODEL_DIFF MODEL_MAG_CORR Magnitude Correction or Difference _MODEL MODEL_MAG_VALUE Magnitude (in any band) generated by a model (or templates) ? MODEL_MOMENT-FLUX-RATIO Moment Flux Ratio _MODEL_PARAM MODEL_PARAM Model Parameter POP_SPEC_SYNTH MODEL_POP-SYNTHESIS Population Synthesis Quantity _MODEL_RESIDUAL MODEL_RESIDUAL Model Residual _MODEL_RESULT MODEL_RESULT Model Solution Value _MODEL_TYPE MODEL_TYPE Model Type PHYS_AT_TRANS_ZEEMAN MODEL_ZEEMAN Zeeman Effect Quantities PHYS_AT_TRANS_ZEEMAN_CO MODEL_ZEEMAN_COEFF Zeeman Effect Coefficient OBJ_CLASS_MORPH? MORPH Morphology of celestial objects OBJ_CLASS_GAL_ARMS MORPH_ARMS Spiral Arms Structure (galaxies) OBJ_CLASS_GAL_ARMS_RATIO MORPH_ARMS_RATIO Ratio of Spiral Arm (galaxies) OBJ_CLASS_GAL_ARMS_WOUND MORPH_ARMS_WOUND Wound Parameter of a spiral arm galaxy OBJ_CLASS_GAL_ASYM MORPH_ASYMMETRY Asymmetry Induced by Rotation OBJ_CLASS_GAL_BAR MORPH_BAR Presence or detection of a bar in a galaxy OBJ_CLASS_MORPH_CODE MORPH_CODE Code refering to a morphological property OBJ_CLASS_MORPH_PARAM MORPH_PARAM Morphological (geometrical) parameter OBJ_CLASS_MORPH_TYPE MORPH_TYPE Morphological Type _NOTE NOTE A Note related to a certain quantity or value _N NUMBER Number Of ``things'' (stars, observations, etc.) OBJ(*OBJ) - Specific object OBJ(E)_NUT NUTATION Earth's Nutation Related Quantities OBJ(E)_NUT_ANGLE NUTATION_PARAM Nutation Parameter # I'm guessing this is the angle _OBS ? OBS Observational Quantities SRC_REG_DIA OBS_ANG-SIZE Observational angular size OBS_INST_BAND OBS_BAND Band or Filter used for the observation PHOT_CAL OBS_CALIB Calibrations related to observations PHOT_CAL_ZERO OBS_CALIB_CONST Calibration's Constant PHOT_CAL_SCALE OBS_CALIB_FACTOR Calibration conversion factor # This is heterogeneous...I'm guessing flux cal is meant here, but # need ones for wave cal too etc OBS_ID OBS_CODE Observation code for observing run OBS_SITE_CONDS OBS_CONDITIONS Observation condition PHOT_LIMIT OBS_DETECT-LIMIT Detection Limit # This is a property of a region of an observation - you may have an upper limit # at a point or a single detection limit for a whole field, it's the same thing # (so note there is an association between limit and region) # It may have suffix of bandpass SRC_DET_SIG OBS_DETECT-SIGNIF Detection Significance # This is a property of a detected source _DIFF OBS_DIFF Observations' offset, difference, or deviation # Append to UCD of whatever is offset OBS_POS_UNC_DRIFT OBS_DRIFT Positional drift during the observation OBS_COV_BAND_FREQ OBS_FREQUENCY Frequency of the observation OBS_ID OBS_ID Observation identification # Comment: OBS_ mixes observation conditions and observed quantities. SPEC_LINE_WIDTH_G OBS_LW Observed gaussian line-width OBS_METHOD OBS_METHOD Observational Method/Technique UNK OBS_OTHER Other Measurements # Comment: useless? OBS_PARAM ? OBS_PARAM Additional Observational Parameters OBS_PLATE ? OBS_PLATE Quantities related to measurements on plates SRC_REG_DIA? OBS_PLATE_APERT Plate (Circular) Aperture SRC_REG_DIA OBS_PLATE_EXTENSION Linear diameter of an object measured on a Plate # Comment: what does this really mean? Is this really different to a normal measured diameter? _MODEL_RATIO OBS_PRED/OBS Fraction of predicted to observed quantities # Comment: is this really different to FIT MEAS/THEORY? Need to attach to whatever UCD is being measured. OBS_RUN OBS_RUN Observation run SRC_REG_DIA OBS_SIZE Observed size # Comment: I doubt that OBS_SIZE and EXTENSION_DIAM are really different. SRC_REG_DIA_DEC OBS_SIZE_DEC Observed size in declination OBS_DISP OBS_SLIT Spectroscopic slit properties # Applies to any dispersive system, not always a slit spectrograph? SRC_DISP_Y OBS_SLIT_OFFSET Slit offset respect to the nucleus of galaxy # Comment: this is really "position of source in slit coordinates". OBS_DISP_THETA OBS_SLIT_ORIENT Slit orientation # Comment: is this "PA of slit on sky" or "orientation of slit wrt source major axis"? # I suspect the former. OBS_SPECTRUM? OBS_SPECTRUM Spectral observations OBS_TYPE ? OBS_TYPE Type of observation OBS_SITE OBSTY Data on Observatories OBS_SITE_POS_ALT OBSTY_ALTITUDE Observatory Altitude OBS_SITE_CODE OBSTY_CODE Observatory Code OBS_SITE_NAME OBSTY_ID Observatory Identification/Name ORBIT ORBIT Orbital elements (planets, double stars, galaxies) ORBIT_ELT_NODE ORBIT_ASC-NODE Longitude of ascending node ORBIT_COMET? ORBIT_COMETS Cometary orbit parameter ORBIT_CONV_ANG? ORBIT_CONV-ANGLE Convergence angle ORBIT_PERI ORBIT_DISTANCE Distance, perihelion, or separation between components ORBIT_DIST ORBIT_DISTANCE Distance, perihelion, or separation between components # Here instantaneous distance ORBIT_ELT_E ORBIT_ECCENTRICITY Orbital eccentricity ORBIT_ELONG ORBIT_ELONGATION Elongation of radiant ORBIT_FREQ ORBIT_FREQUENCY Orbital frequency (orbital angular velocity) ORBIT_ELT_M ORBIT_MEAN-ANOMALY Mean anomaly - ORBIT_P-ASTRON Quantities related to the Periastron ORBIT_ELT_AOP ORBIT_P-ASTRON_ARG Periastron argument or longitude ORBIT_ELT_TPERI ORBIT_P-ASTRON_DATE Date of occurance of periastron ORBIT_PERIDOT ORBIT_P-ASTRON_RATE Rate of periastron advance ORBIT_ELT_AOP ORBIT_P-HELION Perihelion argument or longitude - ORBIT_PARAM Orbital parameter ORBIT_PERIOD ORBIT_PERIOD Orbital period ORBIT_PDOT ORBIT_PERIOD_DERIVATIVE Time derivative of orbital period ORBIT_PHASEANG ORBIT_PHASE-ANGLE Orbital phase angle ORBIT_RV ORBIT_RV Orbital radial velocity properties ORBIT_RV_AMP ORBIT_RV_S-AMPLITUDE Semi amplitude of radial velocity curve ORBIT_DIA_PROJ ORBIT_SEPARATION Orbital Separation (angular distance) ORBIT_DIA ORBIT_SIZE Orbital size ORBIT_RADIUS ORBIT_SIZE_RADIUS Orbital radius (binary stars) ORBIT_ELT_A ORBIT_SIZE_SMAJ Semi-major axis of the orbit PHOT_ PHOT Photometry, extending to several wavelength regimes (X to Radio) PHOT_MAG_13C_ PHOT_13C 13 color system (Stellar Applications) GCPD#66 PHOT_COL(13C,33-52) PHOT_13C_33-52 Color index 33-52 (13C) PHOT_COL(13C,35-52) PHOT_13C_35-52 Color index 35-52 (13C) PHOT_COL(13C,37-52) PHOT_13C_37-52 Color index 37-52 (13C) PHOT_COL(13C,40-52) PHOT_13C_40-52 Color index 40-52 (13C) PHOT_COL(13C,45-52) PHOT_13C_45-52 Color index 45-52 (13C) PHOT_MAG(13C,52) PHOT_13C_52 Magnitude 52 (13C) PHOT_COL(13C,52-110) PHOT_13C_52-110 Color index 52-110 (13C) PHOT_COL(13C,52-58) PHOT_13C_52-58 Color index 52-58 (13C) PHOT_COL(13C,52-63) PHOT_13C_52-63 Color index 52-63 (13C) PHOT_COL(13C,52-72) PHOT_13C_52-72 Color index 52-72 (13C) PHOT_COL(13C,52-80) PHOT_13C_52-80 Color index 52-80 (13C) PHOT_COL(13C,52-86) PHOT_13C_52-86 Color index 52-86 (13C) PHOT_COL(13C,52-99) PHOT_13C_52-99 Color index 52-99 (13C) _ABS PHOT_ABS-MAG Absolute magnitude _ABS PHOT_ABS-MAG_BAND Absolute magnitude in a band, regardles of band PHOT_MAG_BOL_ABS PHOT_ABS-MAG_BOL Bolometric absolute magnitude OBS_ATM_ PHOT_ATM Earth Atmosphere Parameters Linked to Photometry OBS_ATM_AIRMASS PHOT_ATM_AIRMASS Air mass OBS_ATM_EXT PHOT_ATM_EXT Atmospheric extinction coefficient PHOT_BOL_ PHOT_BOL Bolometric Quantities PHOT_COL_BOL() PHOT_BOL_CORR Bolometric correction PHOT_FLUX_BOL PHOT_BOL_FLUX Bolometric Flux PHOT_LUM_BOL PHOT_BOL_LUMINOSITY Bolometric luminosity PHOT_MAG_BOL PHOT_BOL_MAG Bolometric magnitude SRC_IMAGE_SLOPE PHOT_BRIGHTNESS-SLOPE Spatial brightness distribution slope # This is part of a spatial flux model for a source # PHOT_COL PHOT_CI Color index in unspecified system PHOT_COL(,102-C220) PHOT_CI_102-C220 Color index 102-C220 PHOT_COL(UNK,B-R) PHOT_CI_B-R Color index B-r PHOT_COL(HALPHA,LINE-CONT) PHOT_CI_ALPHA Color index based on H-alpha line PHOT_COL(HBETA,LINE-CONT) PHOT_CI_BETA Color index beta or h-beta (not Stroemgren index) PHOT_COL(BALMER,LINE-CONT) PHOT_CI_BALMER Color index using the Balmer lines Hgamma or higher PHOT_COL(UNK,B-I) PHOT_CI_B-I Color index B-I from heterogeneous photometric systems PHOT_COL(UNK,B-K) PHOT_CI_B-K Color index B-K from heterogeneous photometric systems PHOT_COL(UNK,B-V) PHOT_CI_B-V Color index B-V in a non-conventional system PHOT_COL(,CN-TiO) PHOT_CI_CN-TIO Color index CN-TiO PHOT_COL_CODE PHOT_CI_CODE Codes associated with color index PHOT_COL_FRACT PHOT_CI_FRACT Fractional color index PHOT_COL(g,b-v) PHOT_CI_GB-GV Color index gb-gv PHOT_COL(g,u-b) PHOT_CI_GU-GB Color index gu-gb PHOT_COL(IRAS,) PHOT_CI_IR Various far IR color indices (e.g. with IRAS bands) PHOT_COL(,IR-OPT) PHOT_CI_IR-OPT Color index Infrared minus optical PHOT_COL(,M-51) PHOT_CI_M-51 Color index M-51 PHOT_COL(,R-HALPHA) PHOT_CI_R-HALPHA Color index R minus Halpha PHOT_COL(,R-I) PHOT_CI_R-I Color index R-I PHOT_COL(,U-B) PHOT_CI_U-B Color index u-B U-B PHOT_COL(,U-R) PHOT_CI_U-R Color index u-r PHOT_COL(UNK,UNK) PHOT_CI_UNDEF Color index in unspecified system PHOT_COL(,UV-OPT) PHOT_CI_UV-OPT Color index uv minus Optical (UV-OPT) PHOT_COL(,V-I) PHOT_CI_V-I Color index V-I (no standard system specified) PHOT_COL(,V-R) PHOT_CI_V-R Color index V-R (no standard system specified) ? PHOT_CLASS Classification of photometry PHOT_COL_ PHOT_COLOR Quantities related to color indices PHOT_COL_EXCESS PHOT_COLOR_EXCESS Color excess (not just E(B-V)) PHOT_RATE PHOT_COUNT-RATE Count rates in several wavelength regimes PHOT_RATE(UV) PHOT_COUNT-RATE_UV Count rate in ultraviolet PHOT_RATE(XR) PHOT_COUNT-RATE_X Count rate in x-ray PHOT_COUNTS PHOT_COUNTS Count measured in the detector PHOT_COUNTS(IUE/SWP) PHOT_COUNTS_IUE Count from IUE PHOT_COUNTS(IUE/LWP) PHOT_COUNTS_IUE Count from IUE PHOT_COUNTS PHOT_COUNTS_MISC Count measurement in the detector PHOT_COUNTS(RADIO) PHOT_COUNTS_RADIO Counts in radio regime PHOT_COUNTS(GAMMA) PHOT_COUNTS_GAMMA Count in gamma-ray regime PHOT_RATE(GAMMA) PHOT_COUNT-RATE_GAMMA Count rate of gamma photons PHOT_COUNT_RATIO PHOT_COUNTS_RATIO Ratio of photon counts, or relative counts. PHOT_COUNTS(XR) PHOT_COUNTS_X Counts in X-ray PHOT_MAG(COUS) PHOT_COUS Cousins photometric system GCPD#54 PHOT_MAG(COUS,I) PHOT_COUS_I Cousins magnitude Ic PHOT_MAG(COUS,R) PHOT_COUS_R Cousins magnitude R COUS PHOT_COL(COUS,R-I) PHOT_COUS_R-I Cousins R-I color index COUS PHOT_COL(COUS,V-I) PHOT_COUS_V-I (Kron-)Cousins V-I color index COUS PHOT_COL(COUS,V-R) PHOT_COUS_V-R (Kron-)Cousins V-R color index PHOT_MAG(DDO,) PHOT_DDO DDO Photometric System GCPD#12 PHOT_COL(DDO,35-38) PHOT_DDO_35-38 Color index 35-38 DDO PHOT_COL(DDO,38-41) PHOT_DDO_38-41 Color index 38-41 DDO PHOT_COL(DDO,41-42) PHOT_DDO_41-42 Color index 41-42 DDO PHOT_COL(DDO,42-45) PHOT_DDO_42-45 Color index 42-45 DDO PHOT_COL(DDO,42-48) PHOT_DDO_42-48 Color index 42-48 DDO PHOT_COL(DDO,45-48) PHOT_DDO_45-48 Color index 45-48 DDO PHOT_COL(DDO,48-51) PHOT_DDO_48-51 Color index 48-51 DDO PHOT_MAG(DDO,48) PHOT_DDO_M48 Magnitude m48 DDO - PHOT_DIFF Differences or differential quantities PHOT_COL()_DIFF PHOT_DIFF_CI Difference in color index PHOT_MAG()_DIFF PHOT_DIFF_MAG Difference in or differential magnitude PHOT_SB()_DIFF PHOT_DIFF_SB Difference in surface brightness SRC_DIST_MAG PHOT_DIST-MOD Distance Modulus # Distance modulus is not a brightness, it's a distance expressed in mag PHOT_EXT PHOT_EXTINCTION Extinction total to differential PHOT_EXT_GAL PHOT_EXTINCTION_GAL Galactic extinction PHOT_EXT_INT PHOT_EXTINCTION_INT Internal extinction PHOT_EXT_ISM PHOT_EXTINCTION_ISM Interstellar Absorption PHOT_EXT_R PHOT_EXTINCTION_R Insterstellar extinction (ratio total to differential) PHOT_EXT_TOT PHOT_EXTINCTION_TOTAL Total Extinction PHOT_FLUENCE PHOT_FLUENCE Fluence PHOT_FLUX PHOT_FLUX Flux PHOT_FLUXD PHOT_FLUX_DENSITY Flux density PHOT_FLUX(GAMMA) PHOT_FLUX_GAMMA Flux in gamma rays PHOT_FLUX(HALPHA) PHOT_FLUX_HALPHA H-Alpha Flux PHOT_FLUX(HBETA) PHOT_FLUX_HBETA H Beta line flux PHOT_FLUX(IRAS) PHOT_FLUX_IR IR flux (IRAS or others) PHOT_FLUX(6 mu) PHOT_FLUX_IR_6 Flux density around 6 microns (e.g. ISO at 6.7 microns) close to M filter PHOT_FLUX(9 mu) PHOT_FLUX_IR_9 Flux density around 9 microns (range 8-10) PHOT_FLUX(IRAS12) PHOT_FLUX_IR_12 Flux density (IRAS) at 12 microns, or around 12 microns (ISO at 14.3) PHOT_FLUX(IRAS25) PHOT_FLUX_IR_25 Flux density (IRAS) at 25 microns PHOT_FLUX(3.5 mu) PHOT_FLUX_IR_3.5 Flux density at 3.5 microns PHOT_FLUX(15 mu) PHOT_FLUX_IR_15 Flux density around 15 microns (e.g. 14.3um ISO) PHOT_FLUX(IRAS60) PHOT_FLUX_IR_60 Flux density (IRAS) at 60 microns PHOT_FLUX(IRAS100) PHOT_FLUX_IR_100 Flux density (IRAS) at 100 microns PHOT_FLUX(170 mu) PHOT_FLUX_IR_170 Far infra-red Flux density around 170um (1750GHz) PHOT_FLUX(300 mu) PHOT_FLUX_IR_300 Far infra-red Flux density around 300um (3000GHz) PHOT_FLUX(FIR) PHOT_FLUX_IR_FAR Far Infrared flux PHOT_FLUX(H) PHOT_FLUX_IR_H Flux Density in Johnson's H Band PHOT_FLUX(L) PHOT_FLUX_IR_L Flux Density in Johnson's L Band PHOT_FLUX(UNK) PHOT_FLUX_IR_MISC Miscellaneous IR fluxes PHOT_FLUX_RATIO PHOT_FLUX_NORM Normalized Flux, always dimensionless PHOT_FLUX(OPTICAL) PHOT_FLUX_OPTICAL Flux in the Optical (unspecified system and/or units) PHOT_FLUX(RADIO) PHOT_FLUX_RADIO Flux density at radio frequencies PHOT_FLUX(22 MHz) PHOT_FLUX_RADIO_22M Radio flux density around 22MHz (13.6m) PHOT_FLUX(31 MHz) PHOT_FLUX_RADIO_31M Radio flux density around 31MHz (9.7m) PHOT_FLUX(43 MHz) PHOT_FLUX_RADIO_43M Radio flux density around 43MHz (7.0m) PHOT_FLUX(61 MHz) PHOT_FLUX_RADIO_61M Radio flux density around 61MHz (4.9m) PHOT_FLUX(87 MHz) PHOT_FLUX_RADIO_87M Radio flux density around 87MHz (3.5m) PHOT_FLUX(110 MHz) PHOT_FLUX_RADIO_110M Radio flux density around 110MHz (2.7m) PHOT_FLUX(150 MHz) PHOT_FLUX_RADIO_150M Radio flux density around 150MHz (2.0m) PHOT_FLUX(175 MHz) PHOT_FLUX_RADIO_175M Radio flux density around 175MHz (1.7m) PHOT_FLUX(250 MHz) PHOT_FLUX_RADIO_250M Radio flux density around 250MHz (1.2m) PHOT_FLUX(325 MHz) PHOT_FLUX_RADIO_325M Radio flux density around 325MHz (92cm) PHOT_FLUX(365 MHz) PHOT_FLUX_RADIO_365M Radio flux density around 365MHz (82cm) PHOT_FLUX(400 MHz) PHOT_FLUX_RADIO_400M Radio flux density around 400MHz (75cm) PHOT_FLUX(500 MHz) PHOT_FLUX_RADIO_500M Radio flux density around 500MHz (60cm) PHOT_FLUX(600 MHz) PHOT_FLUX_RADIO_600M Radio flux density around 600MHz (50cm) PHOT_FLUX(700 MHz) PHOT_FLUX_RADIO_700M Radio flux density around 700MHz (43cm) PHOT_FLUX(850 MHz) PHOT_FLUX_RADIO_850M Radio flux density around 850MHz (35cm) PHOT_FLUX(1 GHz) PHOT_FLUX_RADIO_1G Radio flux density around 1GHz (30cm) PHOT_FLUX(1.4 GHz) PHOT_FLUX_RADIO_1.4G Radio flux density around 1.4GHz (21cm) PHOT_FLUX(1.6 GHz) PHOT_FLUX_RADIO_1.6G Radio flux density around (OH maser) PHOT_FLUX(2.0 GHz) PHOT_FLUX_RADIO_2G Radio flux density around 2GHz (15cm) PHOT_FLUX(2.7 GHz) PHOT_FLUX_RADIO_2.7G Radio flux density around 2.7GHz (11cm) PHOT_FLUX(3.9 GHz) PHOT_FLUX_RADIO_3.9G Radio flux density around 3.9GHz (7.7cm) PHOT_FLUX(5.0 GHz) PHOT_FLUX_RADIO_5G Radio flux density around 5GHz (6cm) PHOT_FLUX(7.5 GHz) PHOT_FLUX_RADIO_7.5G Radio flux density around 7.5GHz (4cm) PHOT_FLUX(8.4 GHz) PHOT_FLUX_RADIO_8.4G Radio flux density around 8.4GHz (3.6cm) PHOT_FLUX(10.7 GHz) PHOT_FLUX_RADIO_10.7G Radio flux density around 10.7GHz (2.8cm) PHOT_FLUX(15.0 GHz) PHOT_FLUX_RADIO_15G Radio flux density around 15GHz (2cm) PHOT_FLUX(22.0 GHz) PHOT_FLUX_RADIO_22G Radio flux density around (H2O maser) PHOT_FLUX(36.0 GHz) PHOT_FLUX_RADIO_36G Radio flux density around 36GHz (8.3mm) PHOT_FLUX(43.0 GHz) PHOT_FLUX_RADIO_43G Radio flux density around 43GHz (7.0mm) PHOT_FLUX(63.0 GHz) PHOT_FLUX_RADIO_63G Radio flux density around 63GHz (4.8mm) PHOT_FLUX(90.0 GHz) PHOT_FLUX_RADIO_90G Radio flux density around 90GHz (3.3mm) PHOT_FLUX(125.0 GHz) PHOT_FLUX_RADIO_125G Radio flux density around 125GHz (2.4mm) PHOT_FLUX(180.0 GHz) PHOT_FLUX_RADIO_180G Radio flux density around 180GHz (1.7mm) PHOT_FLUX(250.0 GHz) PHOT_FLUX_RADIO_250G Radio flux density around 250GHz (1.2mm) PHOT_FLUX(350.0 GHz) PHOT_FLUX_RADIO_350G Radio flux density around 350GHz (860um) PHOT_FLUX(500.0 GHz) PHOT_FLUX_RADIO_500G Radio flux density around 500GHz (600um) PHOT_FLUX(700.0 GHz) PHOT_FLUX_RADIO_700G Radio flux density around 700GHz (430um) PHOT_FLUX(RADIO) PHOT_FLUX_RADIO_MISC Miscellaneous Radio flux density PHOT_FLUX(SiO-Maser) PHOT_FLUX_RADIO_SIO-MASER SiO maser peak radio flux PHOT_FLUX_RATIO PHOT_FLUX_RATIO Flux ratio PHOT_FLUX_RATIO PHOT_FLUX_REL Relative (normalized) flux PHOT_FLUX(UV) PHOT_FLUX_UV Ultraviolet flux (uv far-uv euv) PHOT_FLUX(X) PHOT_FLUX_X X-ray flux PHOT_MAG(GEN,) PHOT_GEN Geneva's photometric system GCPD#13 PHOT_COL(GEN,B-V) PHOT_GEN_B-V Geneva color index B-V (GEN) PHOT_COL(GEN,B1-B) PHOT_GEN_B1-B Geneva color index B1-B (GEN) PHOT_COL(GEN,B2-B) PHOT_GEN_B2-B Geneva color index B2-B (GEN) PHOT_COL(GEN,G-B) PHOT_GEN_G-B Geneva color index G-B (GEN) PHOT_COL(GEN,) PHOT_GEN_MISC various geneva photometric color indices (and linear combinations) PHOT_COL(GEN,U-B) PHOT_GEN_U-B Geneva color index U-B (GEN) PHOT_MAG(GEN,V) PHOT_GEN_V Geneva magnitude filter V (GEN) PHOT_COL(GEN,V-B) PHOT_GEN_V-B Geneva color index V-B (GEN) PHOT_COL(GEN,V1-B) PHOT_GEN_V1-B Geneva color index V1-B (GEN) PHOT_MAG(GUNN,) PHOT_GUNN Gunn Photometric System GCPD#38 PHOT_MAG(GUNN,G) PHOT_GUNN_G Magnitude g (GUNN) PHOT_COL(GUNN,G-I) PHOT_GUNN_G-I Color index g-i (GUNN) PHOT_COL(GUNN,G-R) PHOT_GUNN_G-R Color index g-r (GUNN) PHOT_MAG(GUNN,I) PHOT_GUNN_I Magnitude i (GUNN), also used in DENIS (0.82{mu}m) PHOT_COL(GUNN,I-Z) PHOT_GUNN_I-Z Color index I-z (GUNN) PHOT_MAG(GUNN,R) PHOT_GUNN_R Magnitude R (GUNN) PHOT_COL(GUNN,R-I) PHOT_GUNN_R-I Color index R-I (GUNN) PHOT_MAG(GUNN,V) PHOT_GUNN_V Magnitude v (GUNN) PHOT_COL(GUNN,V-R) PHOT_GUNN_V-R Color index V-R (GUNN) PHOT_MAG(GUNN,Z) PHOT_GUNN_Z Magnitude z (GUNN) PHOT_MAG(HEI,) PHOT_HEI Heidelberg s Photometric System (HEI) PHOT_COL(HEI,U-B) PHOT_HEI_U-B Heidelberg photometry U-B (HEI) PHOT_MAG(HIP,) PHOT_HIPPAR Hipparcos' photometry system PHOT_MAG(HST,) PHOT_HST HST Photometric System (by filter name) (HST) PHOT_MAG(HST,F1042M) PHOT_HST_F1042M Magnitude F1042M (HST) PHOT_MAG(HST,F140W) PHOT_HST_F140W Magnitude M104W (HST) PHOT_COL(HST,IR-IR) PHOT_HST_CI_IR HST Color Index from IR filters, e.g. F140W-F210W PHOT_COL(HST,U-B) PHOT_HST_CI_U-B HST Color Index close to U-B, e.g. F336W-F430W PHOT_MAG(HST,F170W) PHOT_HST_F170W Magnitude F170W (HST) PHOT_MAG(HST,F175W) PHOT_HST_F175W Magnitude F175W (HST) PHOT_MAG(HST,F220W) PHOT_HST_F220W Magnitude F220W (HST) PHOT_MAG(HST,F255W) PHOT_HST_F255W Magnitude F255W (HST) PHOT_MAG(HST,F275W) PHOT_HST_F275W Magnitude F275W (HST) PHOT_MAG(HST,F300W) PHOT_HST_F300W Ultraviolet Magnitude F300W (HST) PHOT_COL(HST,U-V) PHOT_HST_CI_U-V HST Color Index close to U-V, e.g. F336W-F555W PHOT_MAG(HST,F342W) PHOT_HST_F342W Ultraviolet Magnitude in filters F330W or F342W (HST) PHOT_MAG(HST,F430W) PHOT_HST_F430W Ultraviolet magnitude F430W or F439W (HST) PHOT_COL(HST,B-V) PHOT_HST_CI_B-V HST Color Index close to B-V, e.g. F430W-F555W PHOT_MAG(HST,F450W) PHOT_HST_F450W Ultraviolet Magnitude F450W (HST) PHOT_MAG(HST,F480LP) PHOT_HST_F480LP Magnitude F480LP (HST) PHOT_MAG(HST,F547M) PHOT_HST_F547M Magnitude F547M (HST) PHOT_MAG(HST,F555W) PHOT_HST_F555W Magnitude F555W (HST) PHOT_COL(HST,B-R) PHOT_HST_CI_B-R HST Color Index close to B-R, e.g. F430W-F675W PHOT_COL(HST,V-R) PHOT_HST_CI_V-R HST Color Index close to V-R, e.g. F555W-F675W PHOT_COL(HST,R-I) PHOT_HST_CI_R-I HST Color Index close to R-I, e.g. F675W-F814W PHOT_MAG(HST,F569W) PHOT_HST_F569W Magnitude F569W (HST) PHOT_MAG(HST,F606W) PHOT_HST_F606W Magnitude F606W (HST) PHOT_COL(HST,V-I) PHOT_HST_CI_V-I HST Color Index close to V-I, e.g. F555W-F814W PHOT_MAG(HST,F622W) PHOT_HST_F622W Magnitude F622W (HST) PHOT_MAG(HST,F675W) PHOT_HST_F675W Magnitude F675W (HST) PHOT_MAG(HST,F702W) PHOT_HST_F702W Magnitude F702W (HST) PHOT_MAG(HST,F725LP) PHOT_HST_F725LP Magnitude F725LP (HST) PHOT_MAG(HST,F785LP) PHOT_HST_F785LP Magnitude F785LP (HST) PHOT_MAG(HST,F791W) PHOT_HST_F791W Magnitude F791W (HST) PHOT_MAG(HST,F814W) PHOT_HST_F814W Magnitude F814W (HST) PHOT_MAG(HST,F850LP) PHOT_HST_F850LP Magnitude F850LP (HST) PHOT_MAG(HST,V) PHOT_HST_V Magnitude V (visual) HST (unspecified filter name) PHOT_COL() PHOT_INDX Photometric index (usually in narrow bands) PHOT_COL(,HI) PHOT_INDX_HI Neutral hydrogen HI photometry index PHOT_MAG()_INT PHOT_INT-MAG Integrated or isophotal magnitudes PHOT_MAG(,B)_INT PHOT_INT-MAG_B Integrated total or isophotal blue magnitude PHOT_MAG(,I)_INT PHOT_INT-MAG_I Integrated, total or isophotal, I magnitude PHOT_MAG(UNK,)_INT PHOT_INT-MAG_MISC Miscellaneous Integrated or isophotal magnitudes PHOT_MAG(,R)_INT PHOT_INT-MAG_R Integrated, total or isophotal, R magnitude PHOT_MAG(,I)_INT PHOT_INT-MAG_U Integrated, total or isophotal, V magnitude PHOT_MAG(,V)_INT PHOT_INT-MAG_V Integrated, total or isophotal, V magnitude PHOT_INTENSITY_ PHOT_INTENSITY Intensity PHOT_INTENSITY_ADU PHOT_INTENSITY_ADU Intensity expressed in ADU (analog to digital units) PHOT_INTENSITY_ADU PHOT_INTENSITY_ESTIMATED Estimated intensity # What in astronomy is *not* estimated? PHOT_INTENSITY_ADU? PHOT_INTENSITY_MISC Miscellaneous Intensity PHOT_INTENSITY_RATIO PHOT_INTENSITY_NORMALIZED Normalized intensity SRC_IMAGE_RADIAL_PROFILE_INTENSITY PHOT_INTENSITY_PROFILE Intensity profile PHOT_INTENSITY_RATIO PHOT_INTENSITY_RATIO Intensity ratio PHOT_MAG(,IR) PHOT_IR Infrared magnitudes (not well inserted in photometric systems) PHOT_COL(IRAS,IRAS12-IRAS25) PHOT_IR_12-25 Infrared color index 12-25 (IRAS) PHOT_COL(CO 2.29mu,LINE-CONT) PHOT_IR_2.29 CO band index magnitude at 2.29 micron PHOT_COL(IRAS ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 25 Hi Anita, Ray et al, I globally and fully agree with all your points and comments, the most important one is to use the only available quite exhaustive metadata (UCD) as a crucial use case to elaborate a more flexible and sophisticated schema. I am impressed by Ray's willingness to define a metadata model to refactored the domain, and I am waiting it with great eagerness. I was thinking about such a process and the most difficult part for me is the mechanism to keep a link to UCD and continuing to support them. I tried to formalize the possible inter-relations in the attached UML diag, (triangle at the beginning of a line is inheritance, others lines are relations; assoc,agreg....). Several question araise already in my mind even at this very simple level : - Does Descriptor and Group... need to inheritate from Atom and Descriptor, or is the association use/is_part_of sufficient? In other words, do we need several level of composition? Group of group of Descriptors?... - is the relation UCD/PAD formally needed? - Which is the link between the actual UCD_Tree and all the possible and usefull descriptors associations? cheers, pierre ---------- X-Sun-Data-Type: gif-file X-Sun-Data-Description: gif-file X-Sun-Data-Name: AtomUCD-UML.gif X-Sun-Encoding-Info: uuencode X-Sun-Content-Lines: 162 begin 600 AtomUCD-UML.gif M1TE&.#=A\@)S O< /\ /___^CX !4 , . \ #_ "^ #8 ) M J /]Z "0 +X -D ( " ( .," "!, +X6 -J* 1H 2 ! $ M ) "L $" )!,% 9 %L %Z Q &@ -D" %Q, 8 #V GX !6( M I #F "7D 'X /8# ;_ $"^ #9 UL !< $ \ $D $@\%. M 8 \"% & ?(!$ +0 ! !% +< / " , 3X0 =@ 90, <@ & M=P! <@ ":0 Z= ( C> :0

< ;QH 3 ,.&."!\!F(X(+=*=B0 at PQ&:)N"_OUW4(445BA0 at 1HBA*$ 'PJ% M888CEFCBB2BFJ.***$KHHD84@@CA0 9:6..&-"9D8X%%Q;@ABT &*>20';YH M)$49*N2CC#?BZ"%!/!*UI(5)47GDE0\Y6&1!/C:YI$%:@MACCC\N9266:"H) MYI,XVNBDF![&..-/4\XII9UIYEDFDSH6.:*,>U[8X99T!GJF48?JJ2A$>)J5 MZ)V+1JIDB7!&9&)5CPZ5J:2<$2VZNJK_K#& M*BN0$JF:DJVK?C?KKKSVZNNNM1Y:*DFXYMK at L)$5RR&7?C;+)Z%((FNLKM(^ MIFR@;[Z9)*#<6E3LM-I]NQBNVY*9K9OG8B0NN->MFQBY?T(I[[Q?5MLGN^FY MBYBM$%H9)KWF5EJ1OOA*1[!A_#([+[9-"FQOG 6?=W!A"2O,L+GUJOMPQ-5- M3)BJ6X;8+)4:?@BMI1MS/)W'@[$,D\LJ(PW8R7S?YW=C@ =>W^", M%6[X?(@K%N_B^#4.M>*0OR?YOB%6;M_E"/_'N>:[??ZQYZ*#7O7>JNV(NNG< ME1Z8LZS+YSK-),\>.VRV^^5O[K>WQOM>A/[>>^JKFQ:\\,.?ACQ>PBZ?/&G. MVY5H],^'1OU<)U->O7?7RY5]]]MO!CY_YUE2 2DEH "F$#E&%!]#&R at S")8F@=* MD' 4A%X&+[C #G(P/!:TWP=!N$'1A'"$ASDA_TJ(PMZH$"TO;*%@8N at H%LI0 M-S0L2PYON#,;?F:'_CP$G@\] \0 at YJ6(84&B$:4WQ,XH<8E7:R)GG at A%[TE1 M?%>LHN^RF!DJ:O%37$1?&+^(&B]RQ8QD%*%PT)C&%7JPC<]A8U;D"$<=CM$R M=*SC6/)H%3[J$2Q^I$H at _]B504K%D(34"B*ALLA$7J613H&D(P5YQ\I(4M= @V7B0.F+U,H3,<5LYNQT2:DP#DA;G:.G.7\)CJWJ,YUJLV<%(.G.Z/8SGF649XM_L.G M/C"=*0%K*DS$.I216I4B:NM((MK5FWVMKVMKC-K6YWR]O> MUC8ZM/6M<(=+W.(:][C(S2UP69L1V7YTLK_<:+B8"TCJ!E1HUG4I7IT3W+AE M]Z3+E:[[H M8\6+'N2A!;UN_&RWODMUW(WHFH]Z;U96EXL>O>[3K- MO.W*[QP%'%'^RM>_S(GO>!&\' 6?E\"/A#!J :P_"6/*PJW%\%HU/#<.1^6^ M?/4P7!>LV?T>4<2?G>_14 PF%I.6P0YT,91DO$<:*P7$G:5PQVS<2^@X., J M#AV/<;P3(HO$R*+5,7607%,>]W'(3A9IE+?J8RCWM\155O+*IKQ-$Z?TRM'- MLH%)'.8X6OG 6#:S_I8-QN5QJGG,#PXR#L],YO**^<1 at MO.;\8SF,G.7SG&& M<7)^7&$YYX;0.S8T,P$-9$%/$"X!B'2D6YQG^+;YPQ:>M D;;$Z6]K+:]'T MI@/0Z4"G^<]O$;6H_UIH1Q\GD*06R*J[96H__U:OJ!N2[&-W6<]HQK.P79VK[_<[$_?.=7+9G6B76T<0^9:UZWF];#7 MG&QD7SMIE]8OMXN#Z"6G^[GGUJZGS;UG:L][Q>4.ZKV%G&^E'AO?\9;IN['" MY(\4G"7MWK*B3T?N@ .\WNC^-[\=[N]JT_O9?-[WG/MM18EOG.(=M_C#_C%N M[UI+>]S0#K>P&\QHE9^>SI1O6]PP][F[>5X; MG7/\YD?GI\T7G72JBGSB-->WR6=.\H at __>-1K[C&D0[RIRZ=X5U7^M6YGO60 M;YWI87?ZV<%>=J^/'>UM%_O:>QYWM4_]XM.V^MR+CG.FB(MT'%)=C?J7N>0: M_E)H/;SB$;C-Q3O^55!#4HZ6!:<;@:I.CT\N!#//>4HUOO. at 3U'D[3MY$I4, M675*_'4SKJF!]W1=72)=BTN5^KIV..:#=7W?:<2TPC%UGW MHP_6Z4W_HV'Y7MLOMKW>6Y],S/6$^! V?E&1_F]]GA*X^"TG:?6)>?WO9S_\ M=.(^^;VO^O:S7D3J[USHW7][H>-W_/('/?TO^WYXSW#W_L=_]==_XI=/CR9] M,(1^]V> KV9^JU=R\(=_QH1+V/> TQ>!##A'!"(P(;9_"8A[8Q5_[[)]'IAB M]E=^$I at TC$*"+-A8)2AU&/A_6\%\@E([;I(YLQ=XP 1[G@+(C'+A>[<5[GF2!\D9]&4AP3J at C&(,N2Q at P41*"35B%/7-DYQ>$ M4C.$F#)C=M(E3O(EGC)Y+8 at RE-9\)&*&25)X at 0>'O%<[X+9A4%AS73:%C[0F MJ-(F7A(PG;:%0MB%_E4XAWNBA"=RAXNXAF+2 at PX!A*O55%0F@^H6/S8H>WEH MAWQRB/8U(X+G.8"H+<&W+?_RB*&XAQPA>BMX?)>(5#AH$L4D1YO%@Y36/*D( MB0X#,(38,&[X at F?3+\'"?GUX$:J37K7(7)>2,HA7@,5HAGGH)\+7BV2RBY6' MB )H<*@3/$QXC$CEA24!+:%DBV?4>_WR?(*B;;OX+UKBCMKX at 6!XC8/'B;_W MCIMH;,OG@[$X,.4B,I1'A\\B++H&D+LSD %$?#.(CLRVB%OX?,"GA5>X,&J8 M)6$(AG]RD'.BCAQ8+Q#)0,(S,_HD&MX)JEXDB3Y/B$9>C Y_HN3 M*(EW6(_X:)/-5Y/2Z(DR:5:L.(R)N).0Z"^G."7!UUP-)9*/8Y080Y&G*([# MUY 9\U/3%),Q&2J5*(Q4J8I0"8=$^8M-28@:TX_QZ(C9DI-A>2Z/8XI.F2Y; MZ6;>%$U9B8 ZM9',0HQ2>91,>99C"8[^N(Y1&91I&9CBJ(9[F85EF7[6))<9 M]9-O^90J68 at -29C8V)=P^9>E.)76N)GI2)$K*9&/&8,"!SOEET64F#5V28]' MV9)MR99\B8Q)N3K-DY81Z9J$Z86U^9EBB9F7B3T329<%UF0JJ82?&#+[Z(DY M:3(N\Y(:HXM,,C((^9S1J9/%:9PZ^(F6*872_O.; ]B=%QB B]F;WL.=VRB/ M!*B8?@B>OJDM#JB5;B>><0F?Y&,H[0F<6J>=DN678KB0COF>^!F>_[F?ZF:? M9A>@#D66)YAA_2EW!AJ?#0J!)DB at _BF: $JA0F25OK6@=F>A!ZJ?V(6AO:6A M6(6@#LJA6J1]N9>"T-A&*,J%Z;FB:=2BH(B)\@E%()IY)&I1L4EU772CCI>C M MJ!>*='(\6<0UI'1;JC] 6 >\>'-9I-!R=D/@J30,HU^+-$4WJ5'EI.5ZI: M);IH7>JE07I/E">FW3=G=6BFZ_=Q8:JF47 at ZY>*F+PJE<2BGX[ZJ >5 MA$Q:6I1JD9JZJ9S5J3,Y*:"*6:+*$(1WJ>ZK1)ZJ]ZZH=<:KM]*K.0JKM%ZKN69KNH:H<[:KN;YKO : MG/(ZKQ/6K?::1,7Z,OO*J?WJ$L>*40%KD?D:K]I:L/K*HPB;L/BZL.>HL [K M%0,[JA&KH U;L03WKRZ(L5(&L1P[8![[L1$6LB)[821;LE,QL3Z)LOQY_K$L M^X0N^[*6&+,RZW<:BW W2UDJBZHY&UD[JX[0WUK.- MJ;0IR[3*Z+1/F[126Z7 at 6K4S:[18*U54N[4F2G=>R[6CF:5D6[9FRUM; TEG MN[9LV[:^DK8L1E at _VZA&H[8W.[>!&C-V>U?LJC)[JU=0.Q)X:ZW9&DOCJK=Q M>[>!.X]4\[>/=;A^F[A\RW9U*[F >["1JZS!A+D MVTJ0V[F6^[A]J[JC:TRE6S"G:[BM:[JK^[F+BYIP^[K)1[D_,[N9Y;LX [R; MF[JVR[MG*KRBVZRH6[NR>[O-J[R9R[RT*[VN_DN]P0NVOPN]U:N]P\N]V1NL MC0N^Q>N\^$*\I&N\SXN\:VJ]QXN]Y>N^ZPN_Z6N^[(*^L*N^YTN^]2N_^QMJ MDI9MN]RXL6JK9L QR[_WO OS9K$:R_]RM@%0S!BBO! M&>P6N7;!]@LN?)1MG=B_##R];&'"(NR_'[S"(X:['DS"_)N_(SPM^-N[*7R] M R8K.O"-*QL+-S!&!S$]&O#0(S#-:S#XMLT.9R\._R^T!J_43R_4XS"35RY M['M.1:S$6QQ/,^S%1\S$4&K 5XS$53S!9TS&5[N]7ZRB;?R];WRGX43 5$RX M=US&XSO'-)K$QO+$_NV;QB^\QE"%KRI.,RJ'LQ[D" MR+$LR$8,RRSEMDBDRZ";M9R<8;Q<8[K\(K0\H#G'C#'5R\?,QT\&LPR[S"[R M-;RL>$WKRQUKS0LBS=-L>-4,S<]LL\1\1S,U->:SR\ELQ][9S7]*BT!ESD^A MS."\L7T\CNV,S.^,SNM*-#A'SO5<$P%LPHSKS1&BS6 6:8L/<]+\](S M$=,R;=(5K29I:(^)"K0Z79=(+;&F>=317-.T5J:5&/79#@-IOA:+%I?8]TG;<^ MZ8KY8=DUY=@*-ETNXJ>W=F at +=6A6]3/29.R8]'"*=8ZY:)VW9RKS=JB M3;"OW=A"/2FM+=PU2-:68UP[/=N(S=OLG-DY_CBQ]7.C<\UUCCYG> M])G7%^[;MAW. at P*2HHB%#@.,*PF,_)W:T>*<.IG at Q/UD^PV;BXV#+N[?'D[8 MG<7>03(WJOG0GD[?A[L*CB M;UV#V\U3Y'GEJ*GD/HWA_//D/Q78&F[BD%GEO8W-UXBJ6'GD:HZ1-8[9PZU# M8C[F44Z;'"DGQT3D_DC^E$Y=*&X^T_KLY25]S4[.FDFNTG)8J/F(F#3!YV_> MU:M99!O^YAE%Z%0]Y^7:5E];P'T.FD%]%..3-Z3MX]\LHH_>Z2[]Z6X9ZE;[ MH$L>Y[Z*VNA*Z>HIYY%>D;RXI:+.3:7NVJ?NGNNE3Y NZ$^]5AF]T"2%Z0=N MZ-QZV%!N['@-UE\J%:N[,&>[*W'[!8.LH7+[6DN[<;,YH>?.U,ZN[E+UWRVX[8#@>J'':+0?YYQ7NZ;4NW=Z.W!(>\10_\>=8_N"0 M'8C W>R%+NS^J$D)">PA#_!',)=>2JS"7 at W"?*H;BF;O3L[O^@$O]*- M7B;4_?#]+N^*0O-K(BJJF)OYC?%(>.$\G_3TGB=, M[RE./^(-/WSQ\N$#S_(.?S&[7N)NN9=XF=Z:F?!P3O(*;O*QG>WMGK<- KY>O&=]2/I1;_O5^'4FK6F?B ;9O9 MV)JZGM-1!?F5#VQ3'XA/W^$=/S 6WZ=?29"N.?>Z>9MVGU-E7Y2%Z/64[^;$ M>?J8S_H6 at X:QG_4$3IZ'&7LO+E0X+Y.2:/!W_EGTA,\O5"_B.T^'0!_?]9B< M@(>6A)^1)A0X4*T^1 @ $2*%2U>Q)A1XT:. M'3U^!!E2)$>)(TV>+'E2YQ)E3YTZ!$GW^!!I4Z%"B M18T>18J4YU*',YD^[?@3ZE2J5:U>Q=HRZ5:N7;U^]9D5JE.20E].I!I4[%JV M;=V^30L4[MR59#?@D?OK at WHV*45ET:1AQ9\F3* M(=56QIR0<>*\G2?V_ at U;6$#8T .EBJZ*]W1FUJU=3[[\VO5FBV:']B284G=G MTVAIXR0;6_9PXL7CKC:.^;=,SZ:=XWX^.G?OTWGC1H2<7/MV[I:S=X^\'.)C MWKEGEH<>W/I4QL+!OXW"ZT?YSD*GEZ%,P0PT73'##N1AL*#_4 (R0/__PBH[$F.[#T$,7 M7V2O0QC= G$AY";<[3/0=-R1NL\*VJVWFT!L<48CCV2I2"39JO'%)I5<,DHI M:Y-QRJR:=!%+'$NSLDLO%8+RRP#%!+)"_,(D,TT/T51S+#.GU-*\*MND_C,^ ML^IL*TX-]2SS1CS_[.Y.0-?B4\%"^^1R4$5E8W/1I0XU$%)$$W6T4L0:M70G M2>O;=$ _,P651DQ#S:E3.]_T:%125QUR3E8?135*4[%S]55;DZSU5IUF?8]7 M6C_5-=B1!!5VS#9]!3/78I=M4%EF;4*6NVB3=?99:XFU-K58EYS61FRS!==' M2L-UD\YN0U25W$R_53=&<[>EB=UV2;UM7JS PC=????E]USFTK7WRWH#OK=? M at P]&N-\KY258388;AIBRAR.6%6"*+_YK8HPW''ACCUGK^.,,0Q:Y9.4T-MDX ME%-FV;Z56Y;X99AG%HQDFF&S^6:=<99YYX5[[O8YZ(QS%OHJHHI&^K6BDM86 M:*:?YM!IJ%,E>FJK8Y8ZPP"VWCK2JJ\&^^2LY>M: *[A6SILM9-+^\BRS0Y MVJ/7ICO0N5]\^^WAC*J[;[3YWC!N@?0&N6V_#YA]?UJU.[(CYY^ K^Z2W![]:[\?W.V'RST<_??779[]]]]^'/W[YYZ>_?OOOQS]__?<_," .[>^ end ---------- X-Sun-Data-Type: postscript-file X-Sun-Data-Description: postscript-file X-Sun-Data-Name: AtomUCD-UML.ps X-Sun-Charset: us-ascii X-Sun-Content-Lines: 225 %!PS-Adobe-2.0 %%Title: AtomUCD-UML.ps %%Creator: fig2dev Version 3.2 Patchlevel 1 %%CreationDate: Thu Mar 27 11:01:40 2003 %%For: dide at rosetta (DIDELON Pierre) %%Orientation: Landscape %%BoundingBox: 39 109 555 732 %%Pages: 1 %%BeginSetup %%IncludeFeature: *PageSize A4 %%EndSetup %%Magnification: 0.9610 %%EndComments /$F2psDict 200 dict def $F2psDict begin $F2psDict /mtrx matrix put /col-1 {0 setgray} bind def /col0 {0.000 0.000 0.000 srgb} bind def /col1 {0.000 0.000 1.000 srgb} bind def /col2 {0.000 1.000 0.000 srgb} bind def /col3 {0.000 1.000 1.000 srgb} bind def /col4 {1.000 0.000 0.000 srgb} bind def /col5 {1.000 0.000 1.000 srgb} bind def /col6 {1.000 1.000 0.000 srgb} bind def /col7 {1.000 1.000 1.000 srgb} bind def /col8 {0.000 0.000 0.560 srgb} bind def /col9 {0.000 0.000 0.690 srgb} bind def /col10 {0.000 0.000 0.820 srgb} bind def /col11 {0.530 0.810 1.000 srgb} bind def /col12 {0.000 0.560 0.000 srgb} bind def /col13 {0.000 0.690 0.000 srgb} bind def /col14 {0.000 0.820 0.000 srgb} bind def /col15 {0.000 0.560 0.560 srgb} bind def /col16 {0.000 0.690 0.690 srgb} bind def /col17 {0.000 0.820 0.820 srgb} bind def /col18 {0.560 0.000 0.000 srgb} bind def /col19 {0.690 0.000 0.000 srgb} bind def /col20 {0.820 0.000 0.000 srgb} bind def /col21 {0.560 0.000 0.560 srgb} bind def /col22 {0.690 0.000 0.690 srgb} bind def /col23 {0.820 0.000 0.820 srgb} bind def /col24 {0.500 0.190 0.000 srgb} bind def /col25 {0.630 0.250 0.000 srgb} bind def /col26 {0.750 0.380 0.000 srgb} bind def /col27 {1.000 0.500 0.500 srgb} bind def /col28 {1.000 0.630 0.630 srgb} bind def /col29 {1.000 0.750 0.750 srgb} bind def /col30 {1.000 0.880 0.880 srgb} bind def /col31 {1.000 0.840 0.000 srgb} bind def end save 5.5 77.5 translate 90 rotate 1 -1 scale /cp {closepath} bind def /ef {eofill} bind def /gr {grestore} bind def /gs {gsave} bind def /sa {save} bind def /rs {restore} bind def /l {lineto} bind def /m {moveto} bind def /rm {rmoveto} bind def /n {newpath} bind def /s {stroke} bind def /sh {show} bind def /slc {setlinecap} bind def /slj {setlinejoin} bind def /slw {setlinewidth} bind def /srgb {setrgbcolor} bind def /rot {rotate} bind def /sc {scale} bind def /sd {setdash} bind def /ff {findfont} bind def /sf {setfont} bind def /scf {scalefont} bind def /sw {stringwidth} bind def /tr {translate} bind def /tnt {dup dup currentrgbcolor 4 -2 roll dup 1 exch sub 3 -1 roll mul add 4 -2 roll dup 1 exch sub 3 -1 roll mul add 4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb} bind def /shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul 4 -2 roll mul srgb} bind def /$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def /$F2psEnd {$F2psEnteredState restore end} def %%EndProlog $F2psBegin 10 setmiterlimit n -1000 10525 m -1000 -1000 l 12358 -1000 l 12358 10525 l cp clip 0.05766 0.05766 sc %%Page: 1 1 /Times-Roman ff 270.00 scf sf 6600 5025 m gs 1 -1 sc (FixAtom) col0 sh gr /Times-Roman ff 270.00 scf sf 9525 5025 m gs 1 -1 sc (ParamAtom) col0 sh gr /Times-Roman ff 270.00 scf sf 1800 8250 m gs 1 -1 sc (Group/) col0 sh gr /Times-Roman ff 270.00 scf sf 1800 8880 m gs 1 -1 sc (Frame/...) col0 sh gr /Times-Roman ff 270.00 scf sf 1800 8565 m gs 1 -1 sc (Association/) col0 sh gr /Times-Roman ff 270.00 scf sf 4500 8175 m gs 1 -1 sc (PAD) col0 sh gr /Times-Roman ff 270.00 scf sf 9900 8550 m gs 1 -1 sc (UCD_Tree) col0 sh gr /Times-Roman ff 270.00 scf sf 6225 8025 m gs 1 -1 sc (?) col4 sh gr /Times-Roman ff 300.00 scf sf 2250 7275 m gs 1 -1 sc (?) col4 sh gr /Times-Roman ff 300.00 scf sf 7050 9525 m gs 1 -1 sc (?) col4 sh gr /Times-Roman ff 300.00 scf sf 3375 3900 m gs 1 -1 sc (?) col4 sh gr /Times-Roman ff 210.00 scf sf 750 8025 m gs 1 -1 sc (uses) col0 sh gr /Times-Roman ff 210.00 scf sf 1950 4575 m gs 1 -1 sc (uses) col0 sh gr /Times-Roman ff 210.00 scf sf 2100 750 m gs 1 -1 sc (is_part_of) col0 sh gr /Times-Roman ff 210.00 scf sf 900 4875 m gs 1 -1 sc (is_part_of) col0 sh gr /Times-Roman ff 210.00 scf sf 3975 750 m gs 1 -1 sc (n) col0 sh gr /Times-Roman ff 210.00 scf sf 2475 4575 m gs 1 -1 sc (n) col0 sh gr /Times-Roman ff 210.00 scf sf 2475 5100 m gs 1 -1 sc (n) col0 sh gr /Times-Roman ff 210.00 scf sf 1200 8250 m gs 1 -1 sc (n) col0 sh gr /Times-Roman ff 210.00 scf sf 6825 8250 m gs 1 -1 sc (n) col0 sh gr /Times-Roman ff 210.00 scf sf 5550 8325 m gs 1 -1 sc (0..1) col0 sh gr /Times-Roman ff 270.00 scf sf 2925 4950 m gs 1 -1 sc (Descriptor) col0 sh gr % Polyline 30.000 slw n 6975 7725 m 8250 7725 l 8250 8400 l 6975 8400 l cp gs col0 s gr /Times-Roman ff 270.00 scf sf 7350 8175 m gs 1 -1 sc (UCD) col0 sh gr % Arc gs n 6937.5 2400.0 7200.9 119.0 61.0 arcn gs col0 s gr gr % Polyline n 4125 675 m 5325 675 l 5325 1125 l 4125 1125 l cp gs col0 s gr % Polyline gs clippath 4613 1535 m 4725 1175 l 4838 1535 l 4838 1080 l 4613 1080 l cp clip n 4725 1125 m 4725 3075 l 3600 3075 l 3600 4500 l gs col0 s gr gr % arrowhead n 4613 1535 m 4725 1175 l 4838 1535 l 4725 1535 l 4613 1535 l cp gs col7 1.00 shd ef gr col0 s % Polyline n 2625 4500 m 4350 4500 l 4350 5175 l 2625 5175 l cp gs col0 s gr % Polyline n 4725 3075 m 10125 3075 l 10125 4500 l gs col0 s gr % Polyline n 7050 3075 m 7050 4500 l gs col0 s gr % Polyline n 6075 4500 m 8025 4500 l 8025 5250 l 6075 5250 l cp gs col0 s gr % Polyline n 9150 4500 m 11250 4500 l 11250 5325 l 9150 5325 l cp gs col0 s gr % Polyline n 3600 6525 m 4800 6525 l 4800 7725 l gs col0 s gr % Polyline n 1350 7800 m 3450 7800 l 3450 9150 l 1350 9150 l cp gs col0 s gr % Polyline n 4125 7725 m 5400 7725 l 5400 8475 l 4125 8475 l cp gs col0 s gr % Polyline n 4800 6525 m 7725 6525 l 7725 7725 l gs col0 s gr % Polyline n 5400 8100 m 6975 8100 l gs col0 s gr % Polyline n 9750 8175 m 11325 8175 l 11325 8700 l 9750 8700 l cp gs col0 s gr % Polyline n 8250 8025 m 9750 8400 l gs col0 s gr % Polyline n 2625 4650 m 1650 4650 l 1650 825 l 4125 825 l gs col0 s gr % Polyline n 1350 8100 m 600 8100 l 600 4950 l 2625 4950 l gs col0 s gr % Polyline gs clippath 3488 5660 m 3600 5300 l 3713 5660 l 3713 5205 l 3488 5205 l cp clip n 3600 5250 m 3600 6525 l 2475 6525 l 2475 7800 l gs col0 s gr gr % arrowhead n 3488 5660 m 3600 5300 l 3713 5660 l 3600 5660 l 3488 5660 l cp gs col7 1.00 shd ef gr col0 s /Times-Roman ff 270.00 scf sf 4350 975 m gs 1 -1 sc (Atom) col0 sh gr $F2psEnd rs showpage From jcm at head-cfa.cfa.harvard.edu Sun Mar 30 16:29:05 2003 From: jcm at head-cfa.cfa.harvard.edu (jcm at head-cfa.cfa.harvard.edu) Date: Sun, 30 Mar 2003 19:29:05 -0500 (EST) Subject: UCD Status and Perspectives Message-ID: <200303310029.h2V0T5M29580@urania.cfa.harvard.edu> Patricio, I realize I never followed up your message of Mar 19. For the record, what I had in mind with my spectral index example, I had in mind finding the sources in a subsample and calculating what their 4100A fluxes are, for instance to get a sample for an observing proposal of the 10 brighest northern objects of a particular class, brightest by 4100A flux. And I want to do it even including objects whose 4100A flux is not actually known, but can be guessed from other published fluxes assuming an SED. In general, the existing UCDs are great for getting general information but not for knowing exactly what you have, that was the broader point. A side point from this example is that I think the VO will need to allow users to specify certain assumptions to provide a context for queries (I'm looking for quasars, and here's what you can assume about quasars - e.g. a typical SED - so that you can handle my query even in cases where the information is incomplete... a bit like a Bayesian prior in spirit, I guess). Regards, Jonathan