From roy at cacr.caltech.edu Fri Apr 22 10:50:18 2005 From: roy at cacr.caltech.edu (Roy Williams) Date: Fri, 22 Apr 2005 10:50:18 -0700 Subject: New UCDs for VOEvent please Message-ID: <4269395A.9010802@cacr.caltech.edu> Dear Andrea and Sebastien This note is to ask the UCD working group for help in building a new section of the UCD vocabulary in support of the VOEvent working group. The first meeting of the VOEvent WG was last week in Pasadena, with the objective of describing "immediate astronomical events" in a semantically-meaningful way. One of the parts of that schema is parameters that say what was observed, and another part is a "hypothesis" of what astrophysics may be behind the event. As an example, what was observed could be a "mag 17 source in galaxy X that was not there last week", and the hypothesis could be "supernova". We would like the "hypothesis" section to be based on a standard vocabulary, so that people can select and query based on these words. In other words, we would like a UCD section covering astronomical event types. Could you help us with doing this? Perhaps a meeting at the Kyoto IVOA would be appropriate? I cannot be there, but Arnold Rots and Alasdair Allen could speak for VOEvent. In the meeting last week, we came up with the words below as a start. It is in two parts -- the astrophysical objects, and the actual events that relate to the objects. Roy Williams California Institute of Technology 626 395 3670 ** Object types AGN, Binaries, Black Holes, Globular Clusters, Pulsars, Quasars, Neutron Stars, Supernova Remnants, Soft Gamma-ray Repeaters, Planets (minor), Comets, Meteors, ** Events (includes discovery of the above and...) Solar flares Cataclysmic Variables report Gamma-Ray Bursts, Supernovae, Microlensing Events, Novae, Outbursts Of Unusual Variable Stars, Cepheid period change change from what? Inspirals Xray burst LIGO burst neutrino planetary transit pulsar glitch References -- IVOA VOEvent Working Group http://www.ivoa.net/twiki/bin/view/IVOA/IvoaVOEvent Presentations are available at http://www.ivoa.net/twiki/bin/view/IVOA/VOEventSchedule -- IVOA Unified Content Descriptors http://www.ivoa.net/Documents/latest/UCD.html http://cdsweb.u-strasbg.fr/UCD/ucd1p-words.txt -- Two example VOEvents are here: http://www.ivoa.net/internal/IVOA/VoeventWorkshop/voevent_example.xml http://www.ivoa.net/internal/IVOA/VoeventWorkshop/voevent_example_smallest.xml (if this XML renders badly in your browser, choose "View/Source") From becker at darkstar.astro.washington.edu Fri Apr 22 11:16:53 2005 From: becker at darkstar.astro.washington.edu (Andrew Becker) Date: Fri, 22 Apr 2005 11:16:53 -0700 Subject: New UCDs for VOEvent please In-Reply-To: <4269395A.9010802@cacr.caltech.edu> (message from Roy Williams on Fri, 22 Apr 2005 10:50:18 -0700) References: <4269395A.9010802@cacr.caltech.edu> Message-ID: <200504221816.j3MIGr4Y024933@darkstar.astro.washington.edu> Hi all - A quick read-through suggests a couple omissions in the "object types" - there are no basic "star" categories! E.g flare star, periodic variable star, AGB star, main sequence star, etc... /\ From pfo at star.le.ac.uk Fri Apr 22 12:26:17 2005 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Fri, 22 Apr 2005 20:26:17 +0100 (BST) Subject: datetime In-Reply-To: Message-ID: Glad to see this subject poping up, Francois Ochsenbein and I had a small exchange of ideas a few weeks back. Mark's explanation is quite good, but I would like to add a couple of things: a "datetime" (however it is represented) corresponds to an instant in time. Julian Date and Modified Julian Date (which do assume the usage of UTC) seem to be one of the most appropriate way of representing such instant in time. Using the ISO standard (string representation) is quite common, but any application wanting to compare instants in time needs to convert it to a floatinng number (double). Instants in time may mean a number of different things, which at this point we don't have any way to handle (more later). One of the problems I'm working on at the moment deal with comparing "simultaneity" or overlapping of time intervals. In this case, the application requires two instants in time: begining of event and end of event. One of the sample VOTables I'm using has five (yes 5) times listed, and as it is an observing log, they represent 1- begining of observation 2- end of observation 3- begining of event (a solar flare) 4- end of event 5- mid point of observation. UCDs don't have the structure to let us differentiate one "instant" from another, units don't help either, utype? Perhaps, but few people are using it yet, column explanation? We're lucky if there is one attached! At the end, the application I wrote let the user specify the columns for start_event & end_event... And those 5 examples are not the only ones, we could have - light curve peak time - time of discovery - time of minimum/maximun in a periodic light curve - time of transit - time of measurement etc. etc. etc. Seems to me that we need to: first agree in valid/meaningful ways of representing time, and spread the voice urbe et orbi, as we'll soon start wanting to know which events were observed with given instruments, in particular if the logs are available in the VO. second, start thinking how to identify the different things that an instant of time may mean, and to start, encourage people generating data to add meaningful explanations to the columns, so if the user is forced to make a decision by hand, at least it is an informed one. The sample VOTables I'm using right now don't have such explanations attached automagically yet I'm sure that information is available somewhere. Cheers, Patricio On Fri, 22 Apr 2005, Mark Taylor wrote: > On Fri, 22 Apr 2005, Tony Linde wrote: > > > Can I ask why datetime is not a datatype in VOTable? > > > > Cheers, > > Tony. > > Because there is no corresponding FITS BINTABLE TFORMn value; see: > > http://www.ivoa.net/Documents/REC/VOTable/VOTable-20040811.html#ToC11 > http://archive.stsci.edu/fits/fits_standard/node68.html#3124 > > VOTable takes its idea of what datatype a FIELD (or PARAM) can store > from the FITS binary table specification and not from XML Schema > (or anywhere else) and thus it's pretty low-level - there isn't even a > String type as such, you can only represent one as an array of characters. > The only type in VOTable but not FITS is unicodeChar, which is > presumably allowed because there is a clear 1:1 mapping between > UCS-2 Unicode characters and short integers. > > The datatype attribute is there to tell VOTable parsers how to > turn the content of a TD element or some bytes in a BINARY (and > possibly FITS) stream into a numeric/character value. Any semantic > interpretations put on those numbers/characters is up to the > application, perhaps by looking at other attributes such as > ucd/utype/units. The most obvious place to note that the > content of a particular column is intended to be understood as > a datetime-type value would probably be the units attribute, but > I don't think there is any standard way of doing this. > > It would certainly be useful for generic VOTable-consuming applications > if there was a standard way of telling that a string should be > interpreted to mean a date (or sky coordinate, ...) in a particular way, > but at the moment the VOTable standard does not operate at this level. > > Mark > > -- > Mark Taylor Starlink Programmer Physics, Bristol University, UK > m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ > > --- Patricio F. Ortiz pfo at star.le.ac.uk Department of Physics & Astronomy Phone: +44 (0)116 252 2015 University of Leicester Leicester, LE1 7RH, UK From seaman at noao.edu Fri Apr 22 13:01:01 2005 From: seaman at noao.edu (Rob Seaman) Date: Fri, 22 Apr 2005 13:01:01 -0700 Subject: datetime In-Reply-To: References: Message-ID: <37f3be7d4fa97c140bc4f8526774b646@noao.edu> Patricio Ortiz says: > a "datetime" (however it is represented) corresponds to an instant in > time. Well, simultaneity is not just an issue for GR. A datetime, whatever time scale is used, only makes sense with respect to the location of the observation (or a derived location such as the barycenter). Some representation with a complexity similar to STC is required to unambiguously capture that instant in full. > Julian Date and Modified Julian Date (which do assume the usage of UTC) > seem to be one of the most appropriate way of representing such instant > in time. Using the ISO standard (string representation) is quite > common, > but any application wanting to compare instants in time needs to > convert > it to a floatinng number (double). If the precision required is larger than a second (a typical case for ground based observations), an integer (long) may be preferable. A simple epsilon test may be sufficient to test for equality. A more general case may be constructing a histogram representing the passage of a wavefront (or non-EM event) - in that case we may want to consider more obscure questions like whether the histogram intervals are half-open on the top or the bottom. Deciding the simultaneity of two events that are extended in time rather than instantaneous is a more interesting question than simply whether two intervals overlap. (Even ignoring the differing physics of signal generation and propagation that may apply to two different wavelength regimes.) Rob Seaman NOAO From pfo at star.le.ac.uk Fri Apr 22 14:03:00 2005 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Fri, 22 Apr 2005 22:03:00 +0100 (BST) Subject: datetime In-Reply-To: <37f3be7d4fa97c140bc4f8526774b646@noao.edu> Message-ID: Hi Bob, now we're getting into the insteresting stuff :-) On Fri, 22 Apr 2005, Rob Seaman wrote: > Patricio Ortiz says: > > > a "datetime" (however it is represented) corresponds to an instant in > > time. > > Well, simultaneity is not just an issue for GR. A datetime, whatever > time scale is used, only makes sense with respect to the location of > the observation (or a derived location such as the barycenter). Some > representation with a complexity similar to STC is required to > unambiguously capture that instant in full. Yes, I've seen several flavours of time scales. The picture I painted was the most simplistic of all! > > Julian Date and Modified Julian Date (which do assume the usage of UTC) > > seem to be one of the most appropriate way of representing such instant > > in time. Using the ISO standard (string representation) is quite > > common, > > but any application wanting to compare instants in time needs to > > convert > > it to a floatinng number (double). > > If the precision required is larger than a second (a typical case for > ground based observations), an integer (long) may be preferable. A > simple epsilon test may be sufficient to test for equality. In any case it is an 8-byte representation. People determining periods usfing fourier transform methods can obtain results with several significant digits of a second. For practical applications, I doubt that equality will be of much interest, but I may be totally wrong in this one. > A more > general case may be constructing a histogram representing the passage > of a wavefront (or non-EM event) - in that case we may want to consider > more obscure questions like whether the histogram intervals are > half-open on the top or the bottom. Deciding the simultaneity of two > events that are extended in time rather than instantaneous is a more > interesting question than simply whether two intervals overlap. (Even > ignoring the differing physics of signal generation and propagation > that may apply to two different wavelength regimes.) Indeed that's one of the most interesting aspects, eg, observed solar events (flares or whatever) with atmospheric phenomena (aurorae or other), or GRBs with their subsequent X-ray/optical/IR/radio afterglow. Even orbit determination of solar system objects may fall into that category, one is not interested in simultaneous events in space-time, but events which are somehow related. Few things are instantaneous anyways, observations (other than perhaps, in photon counting mode) extend over a period of time (fractions of a second to hours or days). Perhaps "instants" can only be defined at a post-processing stage (eg, Peak time of a SN light curve), but even in those cases, the presence of an error bar in the determination of such instants convert them into intervals for comparison purposes. Cheers, Patricio --- Patricio F. Ortiz pfo at star.le.ac.uk Department of Physics & Astronomy Phone: +44 (0)116 252 2015 University of Leicester Leicester, LE1 7RH, UK From arots at head.cfa.harvard.edu Fri Apr 22 16:43:18 2005 From: arots at head.cfa.harvard.edu (Arnold Rots) Date: Fri, 22 Apr 2005 19:43:18 -0400 (EDT) Subject: datetime In-Reply-To: Message-ID: <200504222343.j3MNhJRf018702@xebec.cfa.harvard.edu> Several people have already addressed most of the important points. Accurate time needs a specification of time scale and reference position. STC contains an astronTimeType that may be helpful. However, let me say emphatically that JD and MJD (and ISO-8601, for that matter), only define something akin to a format and imply nothing about the associated timescale. A JD or MJD without a timescale is meaningless; UTC cannot be assumed. - Arnold Patricio F. Ortiz wrote: > > Julian Date and Modified Julian Date (which do assume the usage of UTC) > seem to be one of the most appropriate way of representing such instant > in time. Using the ISO standard (string representation) is quite common, > but any application wanting to compare instants in time needs to convert > it to a floatinng number (double). > -------------------------------------------------------------------------- Arnold H. Rots Chandra X-ray Science Center Smithsonian Astrophysical Observatory tel: +1 617 496 7701 60 Garden Street, MS 67 fax: +1 617 495 7356 Cambridge, MA 02138 arots at head.cfa.harvard.edu USA http://hea-www.harvard.edu/~arots/ -------------------------------------------------------------------------- From mchill at dial.pipex.com Fri Apr 22 17:01:14 2005 From: mchill at dial.pipex.com (Martin Hill) Date: Sat, 23 Apr 2005 01:01:14 +0100 Subject: datetime In-Reply-To: <200504222343.j3MNhJRf018702@xebec.cfa.harvard.edu> References: <200504222343.j3MNhJRf018702@xebec.cfa.harvard.edu> Message-ID: <4269904A.80704@dial.pipex.com> It seems to me that for *most* practical purposes the ISO-8601 form with an assumed UTC is sufficient. As an ignorant layman I thought UTC did indeed have a reference point and a timescale... It may not be ideal, but it seems the ideal needs a bit more thrashing out. If it's not sufficient, can anyone explain (in ignorant laymans terms please!) why not? Or obviously just point us at something that does so. What we really want for now is a way of including datetimes in our standard message forms; it doesn't really matter if they're perfectly described yet as the people using them understand the context they're given in. Cheers Martin Arnold Rots wrote: > Several people have already addressed most of the important points. > Accurate time needs a specification of time scale and reference > position. STC contains an astronTimeType that may be helpful. > > However, let me say emphatically that JD and MJD (and ISO-8601, for > that matter), only define something akin to a format and imply nothing > about the associated timescale. A JD or MJD without a timescale is > meaningless; UTC cannot be assumed. > > - Arnold > > Patricio F. Ortiz wrote: > >>Julian Date and Modified Julian Date (which do assume the usage of UTC) >>seem to be one of the most appropriate way of representing such instant >>in time. Using the ISO standard (string representation) is quite common, >>but any application wanting to compare instants in time needs to convert >>it to a floatinng number (double). >> > > -------------------------------------------------------------------------- > Arnold H. Rots Chandra X-ray Science Center > Smithsonian Astrophysical Observatory tel: +1 617 496 7701 > 60 Garden Street, MS 67 fax: +1 617 495 7356 > Cambridge, MA 02138 arots at head.cfa.harvard.edu > USA http://hea-www.harvard.edu/~arots/ > -------------------------------------------------------------------------- > -- Martin Hill www.mchill.net 07901 55 24 66 0131 668 8100 (ROE) From seaman at noao.edu Fri Apr 22 17:58:01 2005 From: seaman at noao.edu (Rob Seaman) Date: Fri, 22 Apr 2005 17:58:01 -0700 Subject: datetime In-Reply-To: <4269904A.80704@dial.pipex.com> References: <200504222343.j3MNhJRf018702@xebec.cfa.harvard.edu> <4269904A.80704@dial.pipex.com> Message-ID: <487e3908aee1907c801ecfa1ecb78c60@noao.edu> On Apr 22, 2005, at 5:01 PM, Martin Hill wrote: > It seems to me that for *most* practical purposes the ISO-8601 form > with an assumed UTC is sufficient. As an ignorant layman I thought > UTC did indeed have a reference point and a timescale... It may not be > ideal, but it seems the ideal needs a bit more thrashing out. I agree with the skepticism shown by the quotes around "most". For *many* utility purposes, UTC has indeed been the default, with GMT before that. If there has ever been a default reference location, that has likely been topocentric, i.e., the location at which an observation was made. Thus, even in this rather ad hoc default case, some indication of a reference location would be required. For many purposes it might be sufficient to refer to an observatory DB such as maintained by the IRAF NOAO package. > If it's not sufficient, can anyone explain (in ignorant laymans terms > please!) why not? Or obviously just point us at something that does > so. UTC has been under attack for several years. The threat of discontinuing leap seconds - while continuing to refer to civil time as "UTC" - would make our prior usage of UTC as an approximation to GMT completely invalid. See Steve Allen's excellent UTC resource page at: http://www.ucolick.org/~sla/leapsecs Note that the future of UTC is largely out of our direct control. We may be able to convince the precision timing community to rename civil time something other than UTC, but the question of whether leap seconds will continue to be issued is under the control (it appears) of the International Telecommunications Union. In any event, it would be prudent for VO and astronomy in general to plan for the worst. > Solar events are based on times rather than spatial positions, and so > the queries and the result sets need to include these times. These > are generally UTC timestamps and the solar community know how to deal > with them in their context For some utility purposes even a bastardized UTC would be acceptable as a timestamp. UTC will remain monotonic, for instance. (There is good reason to believe there could never be a negative leap second.) One imagines, however, that solar astronomers will care more than most about the relationship of time to the angle of the Earth relative to the Sun. It is this angular information that would be jettisoned with leap seconds. Mean Solar Time would no longer bear any simple relationship to the clock on the wall. > As a first-step I would suggest UTC of the standard string form, with > a datatype of 'datetime' (and units as 'UTC' perhaps?); there are > already plenty of libraries to handle this format for > simple/primitive/low level operations such as sorting and matching. > This at least gives us a way of including dates in a VO-standard way > while we thrash out the deeper problems. This is similar to FITS DATE-OBS usage and may be acceptable for a range of utility purposes. The general solution (typically required for precise, scientifically useful, purposes) requires something similar in complexity to STC. Rob Seaman NOAO From roy at cacr.caltech.edu Fri Apr 22 19:14:41 2005 From: roy at cacr.caltech.edu (Roy Williams) Date: Fri, 22 Apr 2005 19:14:41 -0700 Subject: datetime In-Reply-To: <487e3908aee1907c801ecfa1ecb78c60@noao.edu> References: <200504222343.j3MNhJRf018702@xebec.cfa.harvard.edu> <4269904A.80704@dial.pipex.com> <487e3908aee1907c801ecfa1ecb78c60@noao.edu> Message-ID: <4269AF91.2090702@cacr.caltech.edu> There are two things being discussed here: Scientific Time and what we can call Human Time or Office Time. The former has careful astronomical coordinates around it, and we are using STC. For the latter I would suggest ISO 8601, which is what the registry harvesting is using. From seaman at noao.edu Fri Apr 22 20:36:59 2005 From: seaman at noao.edu (Rob Seaman) Date: Fri, 22 Apr 2005 20:36:59 -0700 Subject: datetime In-Reply-To: <4269AF91.2090702@cacr.caltech.edu> References: <200504222343.j3MNhJRf018702@xebec.cfa.harvard.edu> <4269904A.80704@dial.pipex.com> <487e3908aee1907c801ecfa1ecb78c60@noao.edu> <4269AF91.2090702@cacr.caltech.edu> Message-ID: <7cb83e110c016f28d565d09d3cbde09a@noao.edu> On Apr 22, 2005, at 7:14 PM, Roy Williams wrote: > There are two things being discussed here: Scientific Time and what we > can call Human Time or Office Time. The name "Civil Time" is proving to be pretty standard in the UTC "deliberations". > The former has careful astronomical coordinates around it, and we are > using STC. > For the latter I would suggest ISO 8601, which is what the registry > harvesting is using. I don't have ISO 8601 in front of me, but from the various discussions surrounding the Y2K remediation wars I suspect that its connection to UTC is only tenuous at best. There is the business of appending "Z" to indicate Zulu time, but Zulu is really a specification of GMT in "zone" (so called standard time) parlance. And, of course, an implicit assumption is that such a timestamp is valid at all locations. I suspect we could find examples for why this might not be the case in civil usage as well as scientific usage. That said, current astronomical usage, e.g., FITS, does rely on ISO 8601 (a subset, at least) to express UTC (loosely, at least) for utility purposes (both civil and scientific) with topocentric observatory locations (or locationless specifications of time). Even for purely utilitarian purposes, the astronomical community faces the prospect of having to distinguish between situations in which the Earth orientation nature of time is important versus situations in which the Civil (clock on the wall) nature of time is more important. We may not be able to rely on a single time scale continuing to express both. Rob Seaman NOAO From Hessman at Astro.physik.Uni-Goettingen.DE Mon Apr 25 01:18:24 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Mon, 25 Apr 2005 10:18:24 +0200 Subject: New UCDs for VOEvent please In-Reply-To: <200504221816.j3MIGr4Y024933@darkstar.astro.washington.edu> References: <4269395A.9010802@cacr.caltech.edu> <200504221816.j3MIGr4Y024933@darkstar.astro.washington.edu> Message-ID: <46c44a5a3d9584a474a8ba7a0287abf4@Astro.physik.Uni-Goettingen.DE> Before everyone stars to put too much work into a list, I suggest looking at the one I've started at our VOEvent Twiki site: http://monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/ UnifiedContentDescriptors It's based on the ApJ keywords (a likely place to start, it would seem to me). Everyone is heartily invited to register at http://monet.uni-sw.gwdg.de/twiki/bin/view/TWiki/TWikiRegistration and edit on the list communally. This also gives you write-access to the VOEvent and RTML schema pages. Rick P.S. The schema at http://monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/ SchemaTableOfContents isn't quite there yet, but very soon now..... On 22 Apr 2005, at 8:16 pm, Andrew Becker wrote: > Hi all - A quick read-through suggests a couple omissions in the > "object types" - there are no basic "star" categories! E.g flare > star, periodic variable star, AGB star, main sequence star, etc... > > /\ > > ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From Hessman at Astro.physik.Uni-Goettingen.de Tue Apr 26 03:28:32 2005 From: Hessman at Astro.physik.Uni-Goettingen.de (Frederic V. "Rick" Hessman) Date: Tue, 26 Apr 2005 12:28:32 +0200 Subject: New UCDs for VOEvent please In-Reply-To: <4269395A.9010802@cacr.caltech.edu> References: <4269395A.9010802@cacr.caltech.edu> Message-ID: Gentlemen (and Ladies?), I've added more VOEvent examples, several suggestions for IVOA/UCD to the proposed object/event/process UCD list at http://monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/ UnifiedContentDescriptors (which I've tentatively called "VOThings" for the lack of any better name - "VOObjects" sounds a bit too software-ish and something like "VOZoology" sounds too trite) and have achieved a fairly complete equivalence to the ApJ/A&A/MN keyword list, including things like most types of variable stars. If something like this list has already been created, I'd appreciate hearing about it before I put much more work into our own. May I suggest that the issue of an additional UCD be placed prominently in the Kyoto discussion, since it tangents the work of many different groups (e.g. VOTable, VOEvent, Virtual Repository, Data Modelling). I'd love to go to Kyoto, but it's a long way away...... Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From seaman at noao.edu Tue Apr 26 07:20:05 2005 From: seaman at noao.edu (Rob Seaman) Date: Tue, 26 Apr 2005 07:20:05 -0700 Subject: New UCDs for VOEvent please In-Reply-To: References: <4269395A.9010802@cacr.caltech.edu> Message-ID: <816d402df50341a5d44aee3e499f23e8@noao.edu> On Apr 26, 2005, at 3:28 AM, Rick Hessman wrote: > I've added more VOEvent examples, several suggestions for IVOA/UCD to > the proposed > object/event/process UCD list at > > http://monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/ > UnifiedContentDescriptors Good start at a list. A search facility would add immensely to its usefulness as the list grows. This would also function as a validator for an astronomer's guess as to the proper syntax for a familiar class of objects. > If something like this list has already been created, I'd appreciate > hearing about > it before I put much more work into our own. This would be a good opportunity for VO to reach out to the larger community. It really isn't for us to mandate nomenclature. An interactive dictionary/beastiary of astronomical objects and processes could be useful all by itself, and will be of obvious utility for various VO projects. A common understanding of each "hypothesis" will indeed be key to VOEvent, for instance. I'm not sure, however, that the ApJ keywords are the best model for constructing this content descriptor list. Keywords are a way to partition the level of interest a member of the community may have in reading a paper. A UCD is a way of partitioning the underlying physics. For instance, given that the interest in working on this is arising out of VOEvent, it isn't surprising that there is a focus on processes more than objects, and that the selection of objects would be weighted toward time variability in various ways. There are dozens of fine shadings between variable stars. On the other hand, while one can distinguish between elliptical, irregular and spiral galaxies, there isn't any mechanism (yet) for specifying the precise type of each. I'm leery of encouraging these descriptors to become longer than they are, but it seems inappropriate to specify generally descriptive classes, like: stars.variable.irregular stars.variable.long_period stars.variable.semi-regular at the same level as members of prototypical classes, like: stars.variable.Cepheid stars.variable.RR_Lyr stars.variable.RS_CVn (And where is stars.variable.W_UMa? Just pointing out that the list will never be complete.) Perhaps it should be stars.variable.class.Cepheid? Or better yet, adjust in the other direction, maybe stars.variable.period.irregular? Or ideally, a general mechanism might be provided for parametrically classifying periodicity. The challenge here is not only that the list will never be complete, it is that we should be encouraging researchers to actively augment and improve the list. A workable classification scheme is often the first step in organizing a research program. But the result of a research program is often to overturn the original classification scheme. We don't want to provide a mechanism that is only useful for describing objects far removed from the cutting edge. Rob Seaman NOAO -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 3024 bytes Desc: not available URL: From Hessman at Astro.physik.Uni-Goettingen.de Tue Apr 26 07:45:27 2005 From: Hessman at Astro.physik.Uni-Goettingen.de (Frederic V. "Rick" Hessman) Date: Tue, 26 Apr 2005 16:45:27 +0200 Subject: New UCDs for VOEvent please In-Reply-To: <816d402df50341a5d44aee3e499f23e8@noao.edu> References: <4269395A.9010802@cacr.caltech.edu> <816d402df50341a5d44aee3e499f23e8@noao.edu> Message-ID: <83f2d949bed1694f983c1b81f65c67e2@Astro.physik.Uni-Goettingen.DE> On 26 Apr 2005, at 4:20 pm, Rob Seaman wrote: > On Apr 26, 2005, at 3:28 AM, Rick Hessman wrote: > >> I've added more VOEvent examples, several suggestions for IVOA/UCD to >> the proposed >> object/event/process UCD list at >> >> http://monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/ >> UnifiedContentDescriptors > > Good start at a list. A search facility would add immensely to its > usefulness as the list grows. This would also function as a validator > for an astronomer's guess as to the proper syntax for a familiar class > of objects. > >> If something like this list has already been created, I'd appreciate >> hearing about >> it before I put much more work into our own. > > This would be a good opportunity for VO to reach out to the larger > community. It really isn't for us to mandate nomenclature. An > interactive dictionary/beastiary of astronomical objects and processes > could be useful all by itself, and will be of obvious utility for > various VO projects. A common understanding of each "hypothesis" will > indeed be key to VOEvent, for instance. On the other hand, one can't have TOO many people laying on their hands, since there is a need for some level of editorial control. We'd be happy to provide our Twiki more-or-less as it is, since it's already interactive and available to anyone interested. > I'm not sure, however, that the ApJ keywords are the best model for > constructing this content descriptor list. Keywords are a way to > partition the level of interest a member of the community may have in > reading a paper. A UCD is a way of partitioning the underlying > physics. For instance, given that the interest in working on this is > arising out of VOEvent, it isn't surprising that there is a focus on > processes more than objects, and that the selection of objects would > be weighted toward time variability in various ways. There are dozens > of fine shadings between variable stars. On the other hand, while one > can distinguish between elliptical, irregular and spiral galaxies, > there isn't any mechanism (yet) for specifying the precise type of > each. Actually, the ApJ/A&A/MN keywords should really be a GREAT place to start, since they are supposed to capture what is eventually done with the content. It's clear that they don't provide a uniform and uniformly deep level of description, but at least they provide a good and evenly distributed place to start. > I'm leery of encouraging these descriptors to become longer than they > are, but it seems inappropriate to specify generally descriptive > classes, like: > > stars.variable.irregular > stars.variable.long_period > stars.variable.semi-regular > > at the same level as members of prototypical classes, like: > > stars.variable.Cepheid > stars.variable.RR_Lyr > stars.variable.RS_CVn > > (And where is stars.variable.W_UMa? Just pointing out that the list > will never be complete.) > Perhaps it should be stars.variable.class.Cepheid? Or better yet, > adjust in the other direction, maybe stars.variable.period.irregular? > Or ideally, a general mechanism might be provided for parametrically > classifying periodicity. No no no no : these are individual stars but names commonly used to typify a certain variable star behavior (just as we say "Cepheids" and really mean "delta Cepheids" = "stars like delta Cep"). There really are "W UMa" stars. Of course, the UCD can't be defined for individual objects other than a very few like the Sun, Moon, and major planets. Thus, "stars.variable.W_UMa" means the same as "stars.variable.class.W_UMa"; I suppose we could add on the "*.class*" just as a reminder, but at the cost of an additional hierarchical level of detail. > The challenge here is not only that the list will never be complete, > it is that we should be encouraging researchers to actively augment > and improve the list. A workable classification scheme is often the > first step in organizing a research program. But the result of a > research program is often to overturn the original classification > scheme. We don't want to provide a mechanism that is only useful for > describing objects far removed from the cutting edge. Fortunately, astronomers - even very good ones - are often rather traditional in their use of nomenclature, so we'll need such metadata whether someone thinks it's quaint or not. As a stellar astrophysicist interested in variability and accretion, I've included things I'd like to have and will leave it to others to include their own metatdata. Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 5440 bytes Desc: not available URL: From Hessman at Astro.physik.Uni-Goettingen.DE Tue Apr 26 07:57:35 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Tue, 26 Apr 2005 16:57:35 +0200 Subject: New UCDs for VOEvent please In-Reply-To: <816d402df50341a5d44aee3e499f23e8@noao.edu> References: <4269395A.9010802@cacr.caltech.edu> <816d402df50341a5d44aee3e499f23e8@noao.edu> Message-ID: Another thought.... On 26 Apr 2005, at 4:20 pm, Rob Seaman wrote: > The challenge here is not only that the list will never be complete, > it is that we should be encouraging researchers to actively augment > and improve the list. A workable classification scheme is often the > first step in organizing a research program. But the result of a > research program is often to overturn the original classification > scheme. We don't want to provide a mechanism that is only useful for > describing objects far removed from the cutting edge. The "cutting edge" will always be such that one won't have a useful classification scheme other than unusual combinations of the more general bits and pieces. That's why the UCD has to be hierarchical (to emphasize/extract general properties even when given specifics) and easily combined. Let's see..... cosmology.dark_energy <== cosmology.background;em.microwave cosmology.background.polarization;em.microwave stars.supernova.Type_Ia;process.eruption.hydrodynamic; process.eruption.thermonuclear galaxies.velocity_curve cosmology.abund .... (Aha - already discovered a few important UCD's to add....!) Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1887 bytes Desc: not available URL: From seaman at noao.edu Tue Apr 26 11:03:01 2005 From: seaman at noao.edu (Rob Seaman) Date: Tue, 26 Apr 2005 11:03:01 -0700 Subject: New UCDs for VOEvent please In-Reply-To: References: <4269395A.9010802@cacr.caltech.edu> <816d402df50341a5d44aee3e499f23e8@noao.edu> Message-ID: I said: >> The challenge here is not only that the list will never be complete, >> it is that we should be encouraging researchers to actively augment >> and improve the list. A workable classification scheme is often the >> first step in organizing a research program. But the result of a >> research program is often to overturn the original classification >> scheme. We don't want to provide a mechanism that is only useful for >> describing objects far removed from the cutting edge. Rick Hessman says: > The "cutting edge" will always be such that one won't have a useful > classification scheme other than unusual combinations of the more > general bits and pieces. That's why the UCD has to be hierarchical > (to emphasize/extract general properties even when given specifics) > and easily combined. Let's see..... > > cosmology.dark_energy <== cosmology.background;em.microwave > cosmology.background.polarization;em.microwave > stars.supernova.Type_Ia;process.eruption.hydrodynamic; > process.eruption.thermonuclear > galaxies.velocity_curve > cosmology.abund > .... > > (Aha - already discovered a few important UCD's to add....!) I'm becoming more skeptical that IVOA standard UCDs are appropriate for representing the often slippery nature of astronomical "processes" and "objects". (As I pointed out at in a similar context at the VOEvent workshop - one might choose to regard an object simply as a long lived process. A main sequence star is a ~10 Gy thermonuclear reaction.) But a UCD is targeted differently (from UCD-1.9.9b): "The Unified Content Descriptor (UCD) is a formal vocabulary for astronomical metadata that is controlled by the International Virtual Observatory Alliance (IVOA)." The question is whether the characterization of astronomical objects/processes represents "metadata". The whole point of the precision of a UCD specification (e.g., phot.flux;em.optical;meas.error;stat.max) is to provide a solid foundation for building a sound scientific argument - but such an argument typically results in drawing new insights and building new logical connections - often using new vocabulary. On the other hand, even the most well established nomenclature regarding astronomical objects and processes is subject to revision and extension as better data and more profound theory collide. Namespaces provide a possible way to address this. For instance, IVOA is developing a very basic namespace and various astronomical constituencies then support richer, and perhaps shorter latency, vocabularies of their own. However, we have this bit of constraining boilerplate to muddy the waters: "4.1.2 Namespaces. The use of namespaces, indicated by the presence of a colon in the word is possible, but should be avoided as far as possible. The namespace is defined by the string before the colon and the word follows. The words in the non-standard namespace must be distinct from all words currently in the IVOA namespace. While developers may need local namespace, they should be used only temporarily, for words that are not yet included into the UCD validated by the IVOA. New words should be added using the procedures discussed in section XX." What is the justification for trying to require that words in a non-standard namespace be distinct? For instance, we couldn't possibly require that two different non-standard namespaces not overlap. Why regard the IVOA namespace as *necessarily* preeminent? "Standard" does not equate with "compulsory". Either the standard makes sense or you won't be able to force folks to use it anyway. In any event, one would think that alternate interpretations of the same vocabulary would be one of the strongest justifications for alternate namespaces. This isn't an opportunity to lose control of alternate vocabulary - it's the way to enforce control of alternate usages. I also find the word "temporarily" to be curiously undefined for a science in which observations and inferences from decades and even centuries gone by may be revisited. To the list of UCD commandments: 1. UCDs should be short. 2. They should suggest the concept being labeled. 3. Only a single UCD should be appropriate for a given concept. 4. UCDs should be complete, describing all concepts of interest. 5. The vocabulary used within UCDs should be as small as possible. 6. Related concepts should have related UCDs. 7. Quantities with the same UCD should be comparable. I might suggest adding: 8. For IVOA to control its vocabulary, it must provide the opportunity for others to control their own. Ralph Waldo Emerson may shed some light: "The poets made all the words, and therefore language is the archives of history, and, if we must say it, a sort of tomb of the muses For, though the origin of most of our words is forgotten, each word was at a stroke of genius, and obtained currency, because for the moment it symbolizes the world to the first speaker and to the hearer. The etymologist finds the deadest word to have been once a brilliant picture. Language is fossil poetry." However much effort is expended to constrain and mandate standard usage, the users will seek ways to subvert the dominant paradigm. This isn't just the nature of users, it is the nature of science as poetry. Careful support for alternate usage is the key to controlling anarchy. Rob Seaman NOAO -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 5621 bytes Desc: not available URL: From Hessman at Astro.physik.Uni-Goettingen.DE Wed Apr 27 03:15:28 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Wed, 27 Apr 2005 12:15:28 +0200 Subject: New UCDs for VOEvent please In-Reply-To: References: <4269395A.9010802@cacr.caltech.edu> <816d402df50341a5d44aee3e499f23e8@noao.edu> Message-ID: <0b948e6b641050d8843597c4d28fc850@Astro.physik.Uni-Goettingen.DE> > I'm becoming more skeptical that IVOA standard UCDs are appropriate > for representing the often slippery nature of astronomical "processes" > and "objects". The question is whether the characterization of > astronomical objects/processes represents "metadata". The whole point > of the precision of a UCD specification (e.g., > phot.flux;em.optical;meas.error;stat.max) is to provide a solid > foundation for building a sound scientific argument - but such an > argument typically results in drawing new insights and building new > logical connections - often using new vocabulary. On the other hand, > even the most well established nomenclature regarding astronomical > objects and processes is subject to revision and extension as better > data and more profound theory collide. Ah, but the point of UCDs is not to let computers write papers but to be able to let computers organize and re-organize information using terms which we can easily formulate/manipulate. At a pretty trivial level, it can be something as simple as saying what the point of an observation is/was (the reason why a target classification is needed in RTML) or to describe what is roughly happening so that a computer can respond to it (the reason it's needed in VOEvent), but a broader use within the VO is obvious. While we're all spoiled by the services provided by Simbad, resolving astronomical names and querying catalogues won't permit us to combine information to the fullest unless we can express what it is we have and what we want in a fashion which goes far beyond the present IVOA/UCD (crafted really only for VOTable). Thus, RTML and VOEvent would certainly get by using their own little classification lists, but the adoption of a more generally used UCD for astronomical objects and processes is bound to become necessary. The earlier we start discussing it, the faster we will be able to profit from it. Fortunately, a supernova will always remain a supernova and a spiral galaxy won't loose it's spirals within our lifetime, so the evolution of UCD's will be in the direction of the addition of new terms - as they become needed - and the passive abandonment of old UCD's which no longer serve any but a purely historical purpose - well, we should let historians of science keep their access to old terms (they may actually want to know what a W UMa star was/is ;-) > 3. Only a single UCD should be appropriate for a given concept. > 4. UCDs should be complete, describing all concepts of interest. Rots of ruck! A UCD which attempts (!) to describe what it is we do will never be complete and unambiguous. The point is not that it can be perfect but that it exists at all. > However much effort is expended to constrain and mandate standard > usage, the users will seek ways to subvert the dominant paradigm. > This isn't just the nature of users, it is the nature of science as > poetry. Careful support for alternate usage is the key to controlling > anarchy. Frankly, I imagine that most users won't even see it. We're doing this to help stupid computers become more useful and not to constrain the science of our colleagues. Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 4076 bytes Desc: not available URL: From pfo at star.le.ac.uk Wed Apr 27 03:43:04 2005 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Wed, 27 Apr 2005 11:43:04 +0100 (BST) Subject: New UCDs for VOEvent please In-Reply-To: <0b948e6b641050d8843597c4d28fc850@Astro.physik.Uni-Goettingen.DE> Message-ID: Hi, I didn't want to jump into this discussion, but what the heck :-) OK, I'm concerned about the usage of this new proposal. UCDs were born to identify quantities listed in tables (essentially a way to let automated software recognize the nature of the columns in such table). We left out any attempt to include object types, after all, a magnitude is something which applies to a planet, star, galaxy, QSO, whatever, and so with many things like spectral features. It is obvious that in the context of the VO, we would like to have some way to attach a label to the kind of object we are talking about. And the proposed schemes sound doable, not easy, not 100% reliable, but workable. My questions to anyone interested are: "how do you envision using these new UODs (Unified Object-type Descriptor)?" By that, I mean, in which part of the metadata would you like to insert theses descriptors? Catalogues like USNO, 2mass, etc, contain a mixture of objects, and even homogeneous catalogues (like galaxies catalogues) will contain several flavours of galaxies, hence my concern. An object type may not be unique... How do we handle those cases? (after all, these are flags/labels to make our life easier. If the core of a galaxy is an AGN, what does the descriptor look like? UCDs of physical quantities are much easier to handle in that sense! (as noted below regarding the unicity of a UCD). How deep do we want to describe an object? Say that the same AGN has exhibited variations in HBeta flux (ok, kick for the incorrectness :-) :-) Do we want to describe such variability? For some people/applications it will be important, for others not. Although Frederic says that a SN will always be a SN, sure, but what about before? If Eta Car went SN next month, how would we label it? Furthermore, objects may not change in human-lifetime scales, but our perception can... I recall in the mid 80's that the core of the Tarantula Nebula (R136??) was thought to be a super-massive star, only to be discovered later, using instrument with higher angular resolution that it was a compact star cluster... I'm nearly sure there are other examples floating around. For the historians, as Frederic says, should we think of attaching a time stamp to any UOD/object pair? After all, if tomorrow we have to change it, should we erase the previous knowledge? Just my 2 pences :-) Patricio On Wed, 27 Apr 2005, Frederic V. "Rick" Hessman wrote: > > I'm becoming more skeptical that IVOA standard UCDs are appropriate > > for representing the often slippery nature of astronomical "processes" > > and "objects". The question is whether the characterization of > > astronomical objects/processes represents "metadata". The whole point > > of the precision of a UCD specification (e.g., > > phot.flux;em.optical;meas.error;stat.max) is to provide a solid > > foundation for building a sound scientific argument - but such an > > argument typically results in drawing new insights and building new > > logical connections - often using new vocabulary. On the other hand, > > even the most well established nomenclature regarding astronomical > > objects and processes is subject to revision and extension as better > > data and more profound theory collide. > > Ah, but the point of UCDs is not to let computers write papers but to > be able to let computers organize and re-organize information using > terms which we can easily formulate/manipulate. At a pretty trivial > level, it can be something as simple as saying what the point of an > observation is/was (the reason why a target classification is needed in > RTML) or to describe what is roughly happening so that a computer can > respond to it (the reason it's needed in VOEvent), but a broader use > within the VO is obvious. While we're all spoiled by the services > provided by Simbad, resolving astronomical names and querying > catalogues won't permit us to combine information to the fullest unless > we can express what it is we have and what we want in a fashion which > goes far beyond the present IVOA/UCD (crafted really only for VOTable). > > Thus, RTML and VOEvent would certainly get by using their own little > classification lists, but the adoption of a more generally used UCD for > astronomical objects and processes is bound to become necessary. The > earlier we start discussing it, the faster we will be able to profit > from it. > > Fortunately, a supernova will always remain a supernova and a spiral > galaxy won't loose it's spirals within our lifetime, so the evolution > of UCD's will be in the direction of the addition of new terms - as > they become needed - and the passive abandonment of old UCD's which no > longer serve any but a purely historical purpose - well, we should let > historians of science keep their access to old terms (they may actually > want to know what a W UMa star was/is ;-) > > > 3. Only a single UCD should be appropriate for a given concept. > > 4. UCDs should be complete, describing all concepts of interest. > > Rots of ruck! A UCD which attempts (!) to describe what it is we do > will never be complete and unambiguous. The point is not that it can > be perfect but that it exists at all. > > > However much effort is expended to constrain and mandate standard > > usage, the users will seek ways to subvert the dominant paradigm. > > This isn't just the nature of users, it is the nature of science as > > poetry. Careful support for alternate usage is the key to controlling > > anarchy. > > Frankly, I imagine that most users won't even see it. We're doing > this to help stupid computers become more useful and not to constrain > the science of our colleagues. > > Rick --- Patricio F. Ortiz pfo at star.le.ac.uk Department of Physics & Astronomy Phone: +44 (0)116 252 2015 University of Leicester Leicester, LE1 7RH, UK From aa at astro.ex.ac.uk Wed Apr 27 03:50:10 2005 From: aa at astro.ex.ac.uk (Alasdair Allan) Date: Wed, 27 Apr 2005 11:50:10 +0100 Subject: New UCDs for VOEvent please In-Reply-To: <0b948e6b641050d8843597c4d28fc850@Astro.physik.Uni-Goettingen.DE> References: <4269395A.9010802@cacr.caltech.edu> <816d402df50341a5d44aee3e499f23e8@noao.edu> <0b948e6b641050d8843597c4d28fc850@Astro.physik.Uni-Goettingen.DE> Message-ID: <2087F54E-B70A-11D9-BE5F-000D93C0E1F0@astro.ex.ac.uk> Rick Hessman wrote: > Rob Seaman wrote; >> However much effort is expended to constrain and mandate standard >> usage, the users will seek ways to subvert the dominant paradigm. >> This isn't just the nature of users, it is the nature of science as >> poetry. Careful support for alternate usage is the key to >> controlling anarchy. > > Frankly, I imagine that most users won't even see it. We're doing > this to help stupid computers become more useful and not to constrain > the science of our colleagues. Exactly, this isn't for user consumption, this is so that bits of software can route messages correctly. VOEvent messages are never meant to be consumed, or even seen, by a human user. Al. From Hessman at Astro.physik.Uni-Goettingen.DE Wed Apr 27 04:34:54 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Wed, 27 Apr 2005 13:34:54 +0200 Subject: New UCDs for VOEvent please In-Reply-To: References: Message-ID: <32fd4a5efbfd9d3afbbae300411c0379@Astro.physik.Uni-Goettingen.DE> > "how do you envision using these new UODs (Unified Object-type > Descriptor)?" By that, I mean, in which part of the metadata would you > like to insert theses descriptors? To explain where I'm coming from, let's look at VOEvent and RTML: - the VOEvent now has a element, where (name) can be something like "supernova" or "gamma-ray burst". - RTML has a TargetType used by a (name) element. Sound pretty similar? Yes, VOEvent could adopt RTML's element or vice versa, but what do the Virtual Repository people do? Is it really the job of VOEvent to suggest how all the VO colleagues are supposed to classify objects when they get around to needing such, especially when others start needed descriptions of objects and processes which will never produce an event? I admit I'm a newcomer with no (as yet) official function, but I can't imagine the VO getting much farther without being able to teach the software how to describe what is is we're actually studying beyond saying that the number in a table is supposed to mean (admittedly an important first step). > An object type may not be unique... How do we handle those cases? > (after > all, these are flags/labels to make our life easier. If the core of a > galaxy is an AGN, what does the descriptor look like? > UCDs of physical quantities are much easier to handle in that sense! > (as > noted below regarding the unicity of a UCD). Why the need for a final description? From a VOEvent perspective, something should gradually shift from one description to another, e.g. process.burst;em.gamma -> process.burst;em.vis -> galaxies;stars.supernova or - something which is bound to happen eventually (since it already has) - galaxies.Seyfert;galaxies.nucleus;em.X-ray -> stars.variable.cataclysmic.polar This capability for being able to descibe what people/computers think is happening has quite practical consequences when it comes to things like follow-up observations: some won't be interested in Seyferts, others in polars, and the Chandra ToO may insist that it be one or the other. > How deep do we want to describe an object? Say that the same AGN has > exhibited variations in HBeta flux (ok, kick for the incorrectness :-) > :-) > Do we want to describe such variability? For some people/applications > it > will be important, for others not. Deep enough to be useful, shallow enough to be manageable. Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From seaman at noao.edu Wed Apr 27 09:10:42 2005 From: seaman at noao.edu (Rob Seaman) Date: Wed, 27 Apr 2005 09:10:42 -0700 Subject: New UCDs for VOEvent please In-Reply-To: <32fd4a5efbfd9d3afbbae300411c0379@Astro.physik.Uni-Goettingen.DE> References: <32fd4a5efbfd9d3afbbae300411c0379@Astro.physik.Uni-Goettingen.DE> Message-ID: <72138974eda1f17ad78589973743b4ee@noao.edu> This is a timely discussion for the VOEvent folks, but likely perplexing for the UCD folks. The gist of my previous comments was not that VOEvent didn't need to wrestle with characterizing coherent descriptions for the "hypothesis" section of an event. The hypothesis is the key to fielding a richly useful VOEvent facility. Rather, I question whether a UCD, per se, is the correct way to represent this kind of information - clearly itself not a brand new topic for the UCD list :-) It might be that we need to borrow the syntax from UCD's and roll our own - or it might be that we just need to pick another namespace(s). Both the VO and the larger astronomical community would benefit from wrestling with the issues Rick has raised. In the mean time, Patricio asks a lot of good questions. Rob Seaman NOAO From mjg at cacr.caltech.edu Wed Apr 27 09:16:09 2005 From: mjg at cacr.caltech.edu (Matthew Graham) Date: Wed, 27 Apr 2005 09:16:09 -0700 Subject: New UCDs for VOEvent please In-Reply-To: <32fd4a5efbfd9d3afbbae300411c0379@Astro.physik.Uni-Goettingen.DE> References: <32fd4a5efbfd9d3afbbae300411c0379@Astro.physik.Uni-Goettingen.DE> Message-ID: <426FBAC9.2050600@cacr.caltech.edu> Hi, One alternative, though I do not know how practically viable it would be at present, is to use the astronomy ontology that Ed Shaya at University of Maryland is developing and presented a poster about at last year's ADASS. Cheers, Matthew From andrea.preitemartinez at rm.iasf.cnr.it Wed Apr 27 09:27:45 2005 From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez) Date: Wed, 27 Apr 2005 18:27:45 +0200 Subject: UCDs and VOEvents Message-ID: <20050427182745.g87w5yhcs76swcok@webmail.sic.rm.cnr.it> Dear Roy, dear members of the VOE group, > Dear Andrea and Sebastien > This note is to ask the UCD working group for help in building a new section of the UCD > vocabulary in support of the VOEvent working group. > ... thank you for your very interesting and challenging proposal! We think the UCDwg can be the right place to discuss all semantic aspects of the VO, not only those related to "bona fide" UCDs. Of course, we should clearly keep on the right track, as already defined in the last years, for what concerns the UCDs, their definition, their semantics, their syntax, their usage. For the main document on UCDs we have to go on from the stage of Proposed Recommendation to the formal stage of IVOA Recommendation. We also have to upgrade the (new!) list of ucd-words from the level of Draft to that of PR, through a formal RFC. We can do this in Kyoto. Your proposal of opening a discussion in the UCDwg > with the objective of > describing "immediate astronomical events" in a semantically-meaningful way > ... > covering astronomical event types is, as we said, both interesting and challenging. Interesting, because - it is a problem that has been tackled many times giving rise to a number of "subjective" solutions (each one valid/sound in its own context): it is time to discuss it starting from the work already done, but trying to do it in a "semantically-meaningful way" - it has to do with a semantic problem that is hard to locate in/assign to other IVOA WGs; - the UCDwg has the right competences to do the job. Challenging, because - definitely hard to do - not to be mixed up with UCDs, that are ment to serve other purposes. The "mail storm" produced by your proposal is a clear indication of interest, but it also tells us that the discussion has to be kept within clear and firm boundaries, having in mind the distinction between UCDs and their role on one hand, and the "event vocabulary" on the other. In conclusion, the answer to your questions: > Could you help us with doing this? > Perhaps a meeting at the Kyoto IVOA would be appropriate? is yes, we can help, yes, the final part of the UCD session in Kyoto will be devoted to the "event vocabulary". All VOEvent people are of course invited to this session. A tentative agenda could be: - A short presentation of the problem (somebody from the VOEwg has to volunteer for that! Please, let me (=>Andrea) know.) - Plenary discussion, actions. In order not to diverge too much before the start of the discussion in Kyoto, here you can find a few remarks/comments on http://monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/UnifiedContentDescriptors > Unfortunately, the IVOA/UCD list is incomplete: there's no complete > wavelength/frequency coverage in "em.*", for instance (e.g. no em.microwave). The UCD coverage of the electromagnetic spectrum *is* complete. The top-level wavelength/frequency division simply follows the one adopted for the Registry description for more compatibility, that is 7 large bands: radio, mm, IR, optical, UV, X-ray, gamma-ray. See "Spectral Coverage" in http://www.ivoa.net/Documents/REC/ResMetadata/RM-20040426.html Therefore, there is no top level like EUV, sub-mm or microwave, but I guess microwave is covered by the following UCD : em.radio.1500-3000MHz, em.radio.3-6GHz, em.radio.6-12GHz, ... It is important to first notice that the description of the electromagnetic division in the em.* words of the UCD is a special case: it can be seen as an enumeration of possible values for the observation passband. Take for example the description of an IRAS 12 micron flux in VOTable. We can write it: But we could have written: The introduction of all the em.* terms in the UCD vocabulary was done to allow the first description, instead of the 2nd that is less standard, because different people would use different values for the "bandpass" description (12um, IRAS 12 micron, 8.5-15micron, ...) The em.* words can be seen as named instances of the generic "instr.bandpass" UCD. These words were introduced into the vocabulary for two reasons: - they are absolutely needed: most astronomical information comes from photons, and we need to expres in which part of the spectrum a flux or magnitude was measured. - the problem is relatively simple, as it roughly only implies defining intervals on a one-dimensional axis. The astronomical object types haven't been so far introduced in the UCD vocabulary for several reasons: - the main use of UCDs is to describe table columns. The existing "src.class" and "meta.code.class" UCDs were sufficient for this purpose, allowing to describe that a catalogue's column contains an astronomical source classification. This classification (often a numeric code for UCD meta.code.class) is what the author of the catalogue writes, and is not standardized. - Even for the description of a single measurement, we should avoid putting all the metadata into a UCD. We'd hate to see that value 5.23mag is described by ucd="phot.mag;em.opt.V;object.star.supernova.individual.SN1987A;time.epoch.1990" Instead, we'd rather say (in VOTable-like syntax): - The precise definition of object types is very complex. There are examples in the journal keywords, but also in SIMBAD: http://simbad.u-strasbg.fr/guide/chF.htx or the IAU thesaurus http://msowww.anu.edu.au/library/thesaurus/english/ ... The object type definition is difficult, because we often have to deal with hierarchical structure/classification, and an object can belong to different classes: a galaxy can be at the same time: - galaxy - galaxy in cluster - IR source - radio source - X-ray source - emission-line galaxy - galaxy with active nucleus (AGN) - ... The classification can depend on the background of the astronomer (e.g. radio or optical astronomer), and in some cases the boundaries between different classes are fuzzy... (Also !) for these reasons, the definition of standard words for object types was deliberately left out of the UCD vocabulary. But it might be useful to create a new "object" branch, to enumerate a list of possible standardized object types. A careful explanation of each term should be provided, so there is no ambiguity: e.g. does Planetary_Nebula mean the central star, the nebula or both? This list of terms would correspond to an enumeration of possible values corresponding to ucd="src.class". In the same spirit, the "events" are poorly described with the current ucd words. There are a few ones, like pos.lunar.occult, phys.mass.loss or src.var.pulse, but they can certainly be better described by domain specialists. Andrea Sebastien From roy at cacr.caltech.edu Wed Apr 27 09:53:24 2005 From: roy at cacr.caltech.edu (Roy Williams) Date: Wed, 27 Apr 2005 09:53:24 -0700 Subject: New UCDs for VOEvent please In-Reply-To: <426FBAC9.2050600@cacr.caltech.edu> References: <32fd4a5efbfd9d3afbbae300411c0379@Astro.physik.Uni-Goettingen.DE> <426FBAC9.2050600@cacr.caltech.edu> Message-ID: <426FC384.5080509@cacr.caltech.edu> Part of the trouble with ontology/vocabulary discussions is that they can fly away so easily into abstraction. I would like to try and ground the discussion with some examples that I have heard over the last few days. How can we make the UCD set so that the following are possible? (1) Selection of events A client may wish to get, for example: "All events that involve cepheid sources" "All supernova events brighter than 18 magnitude" In order to service these subscriptions, the client would use specific UCDs in place of the natural language words "cepheid" and "supernova". We assume that a machine-learning system in the data pipeline has made probabilistic assessments that the event is "cepheid" or "supernova". We could also do this without the formal UCD structure by doing keyword search in the natural language "description" section of the event -- which of course assumes that some human had written the textual description. (2) When a followup changes the hypothesis Suppose there is an interesting event that is classified somehow (eg supernova). There might be many followup observations that cite the original event ID, and some of these might show a different classification. How can we decide if the classification status of an event has significantly changed, or become more definite, due to followup? From seaman at noao.edu Wed Apr 27 10:03:42 2005 From: seaman at noao.edu (Rob Seaman) Date: Wed, 27 Apr 2005 10:03:42 -0700 Subject: New UCDs for VOEvent please In-Reply-To: <426FBAC9.2050600@cacr.caltech.edu> References: <32fd4a5efbfd9d3afbbae300411c0379@Astro.physik.Uni-Goettingen.DE> <426FBAC9.2050600@cacr.caltech.edu> Message-ID: On Apr 27, 2005, at 9:16 AM, Matthew Graham wrote: > One alternative, though I do not know how practically viable it would > be at present, is to use the astronomy ontology that Ed Shaya at > University of Maryland is developing and presented a poster about at > last year's ADASS. I didn't want to muddy the waters by bringing up the "O" word. Google "Shaya astronomy ontology" for lots of hits on this. My visceral reaction to discussions over the last couple of years as well as the last couple of days is similar. A noble effort - so large and grand that pragmatic functioning systems can't possibly rely on the results in any strong sense. I also have a deep skepticism that practicing astronomers will embrace the results. Noble nonetheless and worthy of the best efforts that the VO can spare. On the other hand, VOEvent will amount to nothing if it is not rigorously pragmatic. I don't think that "pragmatic" and "ontology" are incompatible - and VOEvent provides a great test case for demonstrating this. We need to describe only certain astronomical processes/objects - the ones with a time varying nature. Our list should be biased by an artful sense of where the productive science lies - start with shadings of GRBs, SNs, solar system objects - and some variations on grab bag categories of "other" or "none of the above" or even "all of the above". Establish a process for adding to the list. And don't get too torqued up about "technical correctness". Rob Seaman NOAO From edward.j.shaya.1 at gsfc.nasa.gov Fri Apr 29 11:51:55 2005 From: edward.j.shaya.1 at gsfc.nasa.gov (Ed Shaya) Date: Fri, 29 Apr 2005 14:51:55 -0400 Subject: New UCDs for VOEvent please In-Reply-To: References: <32fd4a5efbfd9d3afbbae300411c0379@Astro.physik.Uni-Goettingen.DE> <426FBAC9.2050600@cacr.caltech.edu> Message-ID: <4272824B.7010900@gsfc.nasa.gov> Rob Seaman wrote: > On Apr 27, 2005, at 9:16 AM, Matthew Graham wrote: > >> One alternative, though I do not know how practically viable it would >> be at present, is to use the astronomy ontology that Ed Shaya at >> University of Maryland is developing and presented a poster about at >> last year's ADASS. > > > I didn't want to muddy the waters by bringing up the "O" word. Google > "Shaya astronomy ontology" for lots of hits on this. My! I took this advice and googled on "ontology shaya" and found the following information: *C. Paths to Enlightenment: Buddhist Art in India and Java* *The Life and Teachings of the Buddha (ca. 563-483):* Prince Siddhartha, surname Gautama, son of Queen Maya and King Suddhodana, born in the small kingdom of Kapilavastu near the Nepalese border. Known as Shakyamuni ("Sage of the Shaya Clan"). Nirvana, Parinirvana at Kusignagara. Formation of the Sangha or Order of Monks What this says is that an alias name for Buddha/Siddhartha is "Sage of the Shaya Clan". It logically follows that Ontology is part of the eightfold path to enlightenment or possibly the ninth fold. > My visceral reaction to discussions over the last couple of years as > well as the last couple of days is similar. A noble effort - so large > and grand that pragmatic functioning systems can't possibly rely on > the results in any strong sense. I also have a deep skepticism that > practicing astronomers will embrace the results. Noble nonetheless > and worthy of the best efforts that the VO can spare. > > On the other hand, VOEvent will amount to nothing if it is not > rigorously pragmatic. I don't think that "pragmatic" and "ontology" > are incompatible - and VOEvent provides a great test case for > demonstrating this. We need to describe only certain astronomical > processes/objects - the ones with a time varying nature. Our list > should be biased by an artful sense of where the productive science > lies - start with shadings of GRBs, SNs, solar system objects - and > some variations on grab bag categories of "other" or "none of the > above" or even "all of the above". Establish a process for adding to > the list. And don't get too torqued up about "technical correctness". With th end of the NVO NSF grant within 18 months, it certainly makes sense to find the quickest and simplest set of terms to fashion into a message for VOEvent alerting. Afterall, we just want to say an event happened at such a time and it appears to be one of these things. And it appears that it is almost finished except for a few details and agreement to standards. But we can also be keeping another eye on the longer time scale where we want to be able to put data in machine understandable terms so that applications can do the most possible on our behalf. This requires something a bit more sophisticated than just a simple class hierarchy of terms. An ontology would be more complete but probably not even an order of magnitude (factor 10) more than the UCD is now. In fact, given the requests and requirements to augment UCDs, with time, the UCD will probably grow to the size of an ontology anyway. So, it is probably wise to start doing some thinking in terms of the formal OWL standard now. What we do with the ontology can vary greatly. 1. Use it as a string identifier, exactly as UCDs are. The advantage is that one can read the Ontology at that point to get more context for the meaning of the term. 2. Use it as one more model builder for developing schemas. This is like UML but more in tune with knowledge/information structures. I think this is what Mathew had in mind. 3. Use it to test completeness and consistency of terms. This would not be on the fly, but rather as one adds new terms one can see whether it is clashing with other terms and Venn diagrams let you see something about completeness. This then makes it more acceptable for groups to be adding terms into their namespace without going to the VO heads or the IAU. 4. One can use it as the defining structure of all information being exchanged. Sounds daring but in fact several other related science fields are preparing to do just that, including space physics. 5. One can use it to reason out pathways to converting, pipelining, and analysing data. It should be possible to automatically find the transformation and queries needed to satisfy an arbitrary stated goal or request. Our group at UMD has an NASA/AISRP grant to figure out the basics of how this might be done using OWL. Ed > Rob Seaman > NOAO > > From roy at cacr.caltech.edu Fri Apr 22 10:50:18 2005 From: roy at cacr.caltech.edu (Roy Williams) Date: Fri, 22 Apr 2005 10:50:18 -0700 Subject: New UCDs for VOEvent please Message-ID: <4269395A.9010802@cacr.caltech.edu> Dear Andrea and Sebastien This note is to ask the UCD working group for help in building a new section of the UCD vocabulary in support of the VOEvent working group. The first meeting of the VOEvent WG was last week in Pasadena, with the objective of describing "immediate astronomical events" in a semantically-meaningful way. One of the parts of that schema is parameters that say what was observed, and another part is a "hypothesis" of what astrophysics may be behind the event. As an example, what was observed could be a "mag 17 source in galaxy X that was not there last week", and the hypothesis could be "supernova". We would like the "hypothesis" section to be based on a standard vocabulary, so that people can select and query based on these words. In other words, we would like a UCD section covering astronomical event types. Could you help us with doing this? Perhaps a meeting at the Kyoto IVOA would be appropriate? I cannot be there, but Arnold Rots and Alasdair Allen could speak for VOEvent. In the meeting last week, we came up with the words below as a start. It is in two parts -- the astrophysical objects, and the actual events that relate to the objects. Roy Williams California Institute of Technology 626 395 3670 ** Object types AGN, Binaries, Black Holes, Globular Clusters, Pulsars, Quasars, Neutron Stars, Supernova Remnants, Soft Gamma-ray Repeaters, Planets (minor), Comets, Meteors, ** Events (includes discovery of the above and...) Solar flares Cataclysmic Variables report Gamma-Ray Bursts, Supernovae, Microlensing Events, Novae, Outbursts Of Unusual Variable Stars, Cepheid period change change from what? Inspirals Xray burst LIGO burst neutrino planetary transit pulsar glitch References -- IVOA VOEvent Working Group http://www.ivoa.net/twiki/bin/view/IVOA/IvoaVOEvent Presentations are available at http://www.ivoa.net/twiki/bin/view/IVOA/VOEventSchedule -- IVOA Unified Content Descriptors http://www.ivoa.net/Documents/latest/UCD.html http://cdsweb.u-strasbg.fr/UCD/ucd1p-words.txt -- Two example VOEvents are here: http://www.ivoa.net/internal/IVOA/VoeventWorkshop/voevent_example.xml http://www.ivoa.net/internal/IVOA/VoeventWorkshop/voevent_example_smallest.xml (if this XML renders badly in your browser, choose "View/Source") From becker at darkstar.astro.washington.edu Fri Apr 22 11:16:53 2005 From: becker at darkstar.astro.washington.edu (Andrew Becker) Date: Fri, 22 Apr 2005 11:16:53 -0700 Subject: New UCDs for VOEvent please In-Reply-To: <4269395A.9010802@cacr.caltech.edu> (message from Roy Williams on Fri, 22 Apr 2005 10:50:18 -0700) References: <4269395A.9010802@cacr.caltech.edu> Message-ID: <200504221816.j3MIGr4Y024933@darkstar.astro.washington.edu> Hi all - A quick read-through suggests a couple omissions in the "object types" - there are no basic "star" categories! E.g flare star, periodic variable star, AGB star, main sequence star, etc... /\ From pfo at star.le.ac.uk Fri Apr 22 12:26:17 2005 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Fri, 22 Apr 2005 20:26:17 +0100 (BST) Subject: datetime In-Reply-To: Message-ID: Glad to see this subject poping up, Francois Ochsenbein and I had a small exchange of ideas a few weeks back. Mark's explanation is quite good, but I would like to add a couple of things: a "datetime" (however it is represented) corresponds to an instant in time. Julian Date and Modified Julian Date (which do assume the usage of UTC) seem to be one of the most appropriate way of representing such instant in time. Using the ISO standard (string representation) is quite common, but any application wanting to compare instants in time needs to convert it to a floatinng number (double). Instants in time may mean a number of different things, which at this point we don't have any way to handle (more later). One of the problems I'm working on at the moment deal with comparing "simultaneity" or overlapping of time intervals. In this case, the application requires two instants in time: begining of event and end of event. One of the sample VOTables I'm using has five (yes 5) times listed, and as it is an observing log, they represent 1- begining of observation 2- end of observation 3- begining of event (a solar flare) 4- end of event 5- mid point of observation. UCDs don't have the structure to let us differentiate one "instant" from another, units don't help either, utype? Perhaps, but few people are using it yet, column explanation? We're lucky if there is one attached! At the end, the application I wrote let the user specify the columns for start_event & end_event... And those 5 examples are not the only ones, we could have - light curve peak time - time of discovery - time of minimum/maximun in a periodic light curve - time of transit - time of measurement etc. etc. etc. Seems to me that we need to: first agree in valid/meaningful ways of representing time, and spread the voice urbe et orbi, as we'll soon start wanting to know which events were observed with given instruments, in particular if the logs are available in the VO. second, start thinking how to identify the different things that an instant of time may mean, and to start, encourage people generating data to add meaningful explanations to the columns, so if the user is forced to make a decision by hand, at least it is an informed one. The sample VOTables I'm using right now don't have such explanations attached automagically yet I'm sure that information is available somewhere. Cheers, Patricio On Fri, 22 Apr 2005, Mark Taylor wrote: > On Fri, 22 Apr 2005, Tony Linde wrote: > > > Can I ask why datetime is not a datatype in VOTable? > > > > Cheers, > > Tony. > > Because there is no corresponding FITS BINTABLE TFORMn value; see: > > http://www.ivoa.net/Documents/REC/VOTable/VOTable-20040811.html#ToC11 > http://archive.stsci.edu/fits/fits_standard/node68.html#3124 > > VOTable takes its idea of what datatype a FIELD (or PARAM) can store > from the FITS binary table specification and not from XML Schema > (or anywhere else) and thus it's pretty low-level - there isn't even a > String type as such, you can only represent one as an array of characters. > The only type in VOTable but not FITS is unicodeChar, which is > presumably allowed because there is a clear 1:1 mapping between > UCS-2 Unicode characters and short integers. > > The datatype attribute is there to tell VOTable parsers how to > turn the content of a TD element or some bytes in a BINARY (and > possibly FITS) stream into a numeric/character value. Any semantic > interpretations put on those numbers/characters is up to the > application, perhaps by looking at other attributes such as > ucd/utype/units. The most obvious place to note that the > content of a particular column is intended to be understood as > a datetime-type value would probably be the units attribute, but > I don't think there is any standard way of doing this. > > It would certainly be useful for generic VOTable-consuming applications > if there was a standard way of telling that a string should be > interpreted to mean a date (or sky coordinate, ...) in a particular way, > but at the moment the VOTable standard does not operate at this level. > > Mark > > -- > Mark Taylor Starlink Programmer Physics, Bristol University, UK > m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ > > --- Patricio F. Ortiz pfo at star.le.ac.uk Department of Physics & Astronomy Phone: +44 (0)116 252 2015 University of Leicester Leicester, LE1 7RH, UK From seaman at noao.edu Fri Apr 22 13:01:01 2005 From: seaman at noao.edu (Rob Seaman) Date: Fri, 22 Apr 2005 13:01:01 -0700 Subject: datetime In-Reply-To: References: Message-ID: <37f3be7d4fa97c140bc4f8526774b646@noao.edu> Patricio Ortiz says: > a "datetime" (however it is represented) corresponds to an instant in > time. Well, simultaneity is not just an issue for GR. A datetime, whatever time scale is used, only makes sense with respect to the location of the observation (or a derived location such as the barycenter). Some representation with a complexity similar to STC is required to unambiguously capture that instant in full. > Julian Date and Modified Julian Date (which do assume the usage of UTC) > seem to be one of the most appropriate way of representing such instant > in time. Using the ISO standard (string representation) is quite > common, > but any application wanting to compare instants in time needs to > convert > it to a floatinng number (double). If the precision required is larger than a second (a typical case for ground based observations), an integer (long) may be preferable. A simple epsilon test may be sufficient to test for equality. A more general case may be constructing a histogram representing the passage of a wavefront (or non-EM event) - in that case we may want to consider more obscure questions like whether the histogram intervals are half-open on the top or the bottom. Deciding the simultaneity of two events that are extended in time rather than instantaneous is a more interesting question than simply whether two intervals overlap. (Even ignoring the differing physics of signal generation and propagation that may apply to two different wavelength regimes.) Rob Seaman NOAO From pfo at star.le.ac.uk Fri Apr 22 14:03:00 2005 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Fri, 22 Apr 2005 22:03:00 +0100 (BST) Subject: datetime In-Reply-To: <37f3be7d4fa97c140bc4f8526774b646@noao.edu> Message-ID: Hi Bob, now we're getting into the insteresting stuff :-) On Fri, 22 Apr 2005, Rob Seaman wrote: > Patricio Ortiz says: > > > a "datetime" (however it is represented) corresponds to an instant in > > time. > > Well, simultaneity is not just an issue for GR. A datetime, whatever > time scale is used, only makes sense with respect to the location of > the observation (or a derived location such as the barycenter). Some > representation with a complexity similar to STC is required to > unambiguously capture that instant in full. Yes, I've seen several flavours of time scales. The picture I painted was the most simplistic of all! > > Julian Date and Modified Julian Date (which do assume the usage of UTC) > > seem to be one of the most appropriate way of representing such instant > > in time. Using the ISO standard (string representation) is quite > > common, > > but any application wanting to compare instants in time needs to > > convert > > it to a floatinng number (double). > > If the precision required is larger than a second (a typical case for > ground based observations), an integer (long) may be preferable. A > simple epsilon test may be sufficient to test for equality. In any case it is an 8-byte representation. People determining periods usfing fourier transform methods can obtain results with several significant digits of a second. For practical applications, I doubt that equality will be of much interest, but I may be totally wrong in this one. > A more > general case may be constructing a histogram representing the passage > of a wavefront (or non-EM event) - in that case we may want to consider > more obscure questions like whether the histogram intervals are > half-open on the top or the bottom. Deciding the simultaneity of two > events that are extended in time rather than instantaneous is a more > interesting question than simply whether two intervals overlap. (Even > ignoring the differing physics of signal generation and propagation > that may apply to two different wavelength regimes.) Indeed that's one of the most interesting aspects, eg, observed solar events (flares or whatever) with atmospheric phenomena (aurorae or other), or GRBs with their subsequent X-ray/optical/IR/radio afterglow. Even orbit determination of solar system objects may fall into that category, one is not interested in simultaneous events in space-time, but events which are somehow related. Few things are instantaneous anyways, observations (other than perhaps, in photon counting mode) extend over a period of time (fractions of a second to hours or days). Perhaps "instants" can only be defined at a post-processing stage (eg, Peak time of a SN light curve), but even in those cases, the presence of an error bar in the determination of such instants convert them into intervals for comparison purposes. Cheers, Patricio --- Patricio F. Ortiz pfo at star.le.ac.uk Department of Physics & Astronomy Phone: +44 (0)116 252 2015 University of Leicester Leicester, LE1 7RH, UK From arots at head.cfa.harvard.edu Fri Apr 22 16:43:18 2005 From: arots at head.cfa.harvard.edu (Arnold Rots) Date: Fri, 22 Apr 2005 19:43:18 -0400 (EDT) Subject: datetime In-Reply-To: Message-ID: <200504222343.j3MNhJRf018702@xebec.cfa.harvard.edu> Several people have already addressed most of the important points. Accurate time needs a specification of time scale and reference position. STC contains an astronTimeType that may be helpful. However, let me say emphatically that JD and MJD (and ISO-8601, for that matter), only define something akin to a format and imply nothing about the associated timescale. A JD or MJD without a timescale is meaningless; UTC cannot be assumed. - Arnold Patricio F. Ortiz wrote: > > Julian Date and Modified Julian Date (which do assume the usage of UTC) > seem to be one of the most appropriate way of representing such instant > in time. Using the ISO standard (string representation) is quite common, > but any application wanting to compare instants in time needs to convert > it to a floatinng number (double). > -------------------------------------------------------------------------- Arnold H. Rots Chandra X-ray Science Center Smithsonian Astrophysical Observatory tel: +1 617 496 7701 60 Garden Street, MS 67 fax: +1 617 495 7356 Cambridge, MA 02138 arots at head.cfa.harvard.edu USA http://hea-www.harvard.edu/~arots/ -------------------------------------------------------------------------- From mchill at dial.pipex.com Fri Apr 22 17:01:14 2005 From: mchill at dial.pipex.com (Martin Hill) Date: Sat, 23 Apr 2005 01:01:14 +0100 Subject: datetime In-Reply-To: <200504222343.j3MNhJRf018702@xebec.cfa.harvard.edu> References: <200504222343.j3MNhJRf018702@xebec.cfa.harvard.edu> Message-ID: <4269904A.80704@dial.pipex.com> It seems to me that for *most* practical purposes the ISO-8601 form with an assumed UTC is sufficient. As an ignorant layman I thought UTC did indeed have a reference point and a timescale... It may not be ideal, but it seems the ideal needs a bit more thrashing out. If it's not sufficient, can anyone explain (in ignorant laymans terms please!) why not? Or obviously just point us at something that does so. What we really want for now is a way of including datetimes in our standard message forms; it doesn't really matter if they're perfectly described yet as the people using them understand the context they're given in. Cheers Martin Arnold Rots wrote: > Several people have already addressed most of the important points. > Accurate time needs a specification of time scale and reference > position. STC contains an astronTimeType that may be helpful. > > However, let me say emphatically that JD and MJD (and ISO-8601, for > that matter), only define something akin to a format and imply nothing > about the associated timescale. A JD or MJD without a timescale is > meaningless; UTC cannot be assumed. > > - Arnold > > Patricio F. Ortiz wrote: > >>Julian Date and Modified Julian Date (which do assume the usage of UTC) >>seem to be one of the most appropriate way of representing such instant >>in time. Using the ISO standard (string representation) is quite common, >>but any application wanting to compare instants in time needs to convert >>it to a floatinng number (double). >> > > -------------------------------------------------------------------------- > Arnold H. Rots Chandra X-ray Science Center > Smithsonian Astrophysical Observatory tel: +1 617 496 7701 > 60 Garden Street, MS 67 fax: +1 617 495 7356 > Cambridge, MA 02138 arots at head.cfa.harvard.edu > USA http://hea-www.harvard.edu/~arots/ > -------------------------------------------------------------------------- > -- Martin Hill www.mchill.net 07901 55 24 66 0131 668 8100 (ROE) From seaman at noao.edu Fri Apr 22 17:58:01 2005 From: seaman at noao.edu (Rob Seaman) Date: Fri, 22 Apr 2005 17:58:01 -0700 Subject: datetime In-Reply-To: <4269904A.80704@dial.pipex.com> References: <200504222343.j3MNhJRf018702@xebec.cfa.harvard.edu> <4269904A.80704@dial.pipex.com> Message-ID: <487e3908aee1907c801ecfa1ecb78c60@noao.edu> On Apr 22, 2005, at 5:01 PM, Martin Hill wrote: > It seems to me that for *most* practical purposes the ISO-8601 form > with an assumed UTC is sufficient. As an ignorant layman I thought > UTC did indeed have a reference point and a timescale... It may not be > ideal, but it seems the ideal needs a bit more thrashing out. I agree with the skepticism shown by the quotes around "most". For *many* utility purposes, UTC has indeed been the default, with GMT before that. If there has ever been a default reference location, that has likely been topocentric, i.e., the location at which an observation was made. Thus, even in this rather ad hoc default case, some indication of a reference location would be required. For many purposes it might be sufficient to refer to an observatory DB such as maintained by the IRAF NOAO package. > If it's not sufficient, can anyone explain (in ignorant laymans terms > please!) why not? Or obviously just point us at something that does > so. UTC has been under attack for several years. The threat of discontinuing leap seconds - while continuing to refer to civil time as "UTC" - would make our prior usage of UTC as an approximation to GMT completely invalid. See Steve Allen's excellent UTC resource page at: http://www.ucolick.org/~sla/leapsecs Note that the future of UTC is largely out of our direct control. We may be able to convince the precision timing community to rename civil time something other than UTC, but the question of whether leap seconds will continue to be issued is under the control (it appears) of the International Telecommunications Union. In any event, it would be prudent for VO and astronomy in general to plan for the worst. > Solar events are based on times rather than spatial positions, and so > the queries and the result sets need to include these times. These > are generally UTC timestamps and the solar community know how to deal > with them in their context For some utility purposes even a bastardized UTC would be acceptable as a timestamp. UTC will remain monotonic, for instance. (There is good reason to believe there could never be a negative leap second.) One imagines, however, that solar astronomers will care more than most about the relationship of time to the angle of the Earth relative to the Sun. It is this angular information that would be jettisoned with leap seconds. Mean Solar Time would no longer bear any simple relationship to the clock on the wall. > As a first-step I would suggest UTC of the standard string form, with > a datatype of 'datetime' (and units as 'UTC' perhaps?); there are > already plenty of libraries to handle this format for > simple/primitive/low level operations such as sorting and matching. > This at least gives us a way of including dates in a VO-standard way > while we thrash out the deeper problems. This is similar to FITS DATE-OBS usage and may be acceptable for a range of utility purposes. The general solution (typically required for precise, scientifically useful, purposes) requires something similar in complexity to STC. Rob Seaman NOAO From roy at cacr.caltech.edu Fri Apr 22 19:14:41 2005 From: roy at cacr.caltech.edu (Roy Williams) Date: Fri, 22 Apr 2005 19:14:41 -0700 Subject: datetime In-Reply-To: <487e3908aee1907c801ecfa1ecb78c60@noao.edu> References: <200504222343.j3MNhJRf018702@xebec.cfa.harvard.edu> <4269904A.80704@dial.pipex.com> <487e3908aee1907c801ecfa1ecb78c60@noao.edu> Message-ID: <4269AF91.2090702@cacr.caltech.edu> There are two things being discussed here: Scientific Time and what we can call Human Time or Office Time. The former has careful astronomical coordinates around it, and we are using STC. For the latter I would suggest ISO 8601, which is what the registry harvesting is using. From seaman at noao.edu Fri Apr 22 20:36:59 2005 From: seaman at noao.edu (Rob Seaman) Date: Fri, 22 Apr 2005 20:36:59 -0700 Subject: datetime In-Reply-To: <4269AF91.2090702@cacr.caltech.edu> References: <200504222343.j3MNhJRf018702@xebec.cfa.harvard.edu> <4269904A.80704@dial.pipex.com> <487e3908aee1907c801ecfa1ecb78c60@noao.edu> <4269AF91.2090702@cacr.caltech.edu> Message-ID: <7cb83e110c016f28d565d09d3cbde09a@noao.edu> On Apr 22, 2005, at 7:14 PM, Roy Williams wrote: > There are two things being discussed here: Scientific Time and what we > can call Human Time or Office Time. The name "Civil Time" is proving to be pretty standard in the UTC "deliberations". > The former has careful astronomical coordinates around it, and we are > using STC. > For the latter I would suggest ISO 8601, which is what the registry > harvesting is using. I don't have ISO 8601 in front of me, but from the various discussions surrounding the Y2K remediation wars I suspect that its connection to UTC is only tenuous at best. There is the business of appending "Z" to indicate Zulu time, but Zulu is really a specification of GMT in "zone" (so called standard time) parlance. And, of course, an implicit assumption is that such a timestamp is valid at all locations. I suspect we could find examples for why this might not be the case in civil usage as well as scientific usage. That said, current astronomical usage, e.g., FITS, does rely on ISO 8601 (a subset, at least) to express UTC (loosely, at least) for utility purposes (both civil and scientific) with topocentric observatory locations (or locationless specifications of time). Even for purely utilitarian purposes, the astronomical community faces the prospect of having to distinguish between situations in which the Earth orientation nature of time is important versus situations in which the Civil (clock on the wall) nature of time is more important. We may not be able to rely on a single time scale continuing to express both. Rob Seaman NOAO From Hessman at Astro.physik.Uni-Goettingen.DE Mon Apr 25 01:18:24 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Mon, 25 Apr 2005 10:18:24 +0200 Subject: New UCDs for VOEvent please In-Reply-To: <200504221816.j3MIGr4Y024933@darkstar.astro.washington.edu> References: <4269395A.9010802@cacr.caltech.edu> <200504221816.j3MIGr4Y024933@darkstar.astro.washington.edu> Message-ID: <46c44a5a3d9584a474a8ba7a0287abf4@Astro.physik.Uni-Goettingen.DE> Before everyone stars to put too much work into a list, I suggest looking at the one I've started at our VOEvent Twiki site: http://monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/ UnifiedContentDescriptors It's based on the ApJ keywords (a likely place to start, it would seem to me). Everyone is heartily invited to register at http://monet.uni-sw.gwdg.de/twiki/bin/view/TWiki/TWikiRegistration and edit on the list communally. This also gives you write-access to the VOEvent and RTML schema pages. Rick P.S. The schema at http://monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/ SchemaTableOfContents isn't quite there yet, but very soon now..... On 22 Apr 2005, at 8:16 pm, Andrew Becker wrote: > Hi all - A quick read-through suggests a couple omissions in the > "object types" - there are no basic "star" categories! E.g flare > star, periodic variable star, AGB star, main sequence star, etc... > > /\ > > ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From Hessman at Astro.physik.Uni-Goettingen.de Tue Apr 26 03:28:32 2005 From: Hessman at Astro.physik.Uni-Goettingen.de (Frederic V. "Rick" Hessman) Date: Tue, 26 Apr 2005 12:28:32 +0200 Subject: New UCDs for VOEvent please In-Reply-To: <4269395A.9010802@cacr.caltech.edu> References: <4269395A.9010802@cacr.caltech.edu> Message-ID: Gentlemen (and Ladies?), I've added more VOEvent examples, several suggestions for IVOA/UCD to the proposed object/event/process UCD list at http://monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/ UnifiedContentDescriptors (which I've tentatively called "VOThings" for the lack of any better name - "VOObjects" sounds a bit too software-ish and something like "VOZoology" sounds too trite) and have achieved a fairly complete equivalence to the ApJ/A&A/MN keyword list, including things like most types of variable stars. If something like this list has already been created, I'd appreciate hearing about it before I put much more work into our own. May I suggest that the issue of an additional UCD be placed prominently in the Kyoto discussion, since it tangents the work of many different groups (e.g. VOTable, VOEvent, Virtual Repository, Data Modelling). I'd love to go to Kyoto, but it's a long way away...... Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From seaman at noao.edu Tue Apr 26 07:20:05 2005 From: seaman at noao.edu (Rob Seaman) Date: Tue, 26 Apr 2005 07:20:05 -0700 Subject: New UCDs for VOEvent please In-Reply-To: References: <4269395A.9010802@cacr.caltech.edu> Message-ID: <816d402df50341a5d44aee3e499f23e8@noao.edu> On Apr 26, 2005, at 3:28 AM, Rick Hessman wrote: > I've added more VOEvent examples, several suggestions for IVOA/UCD to > the proposed > object/event/process UCD list at > > http://monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/ > UnifiedContentDescriptors Good start at a list. A search facility would add immensely to its usefulness as the list grows. This would also function as a validator for an astronomer's guess as to the proper syntax for a familiar class of objects. > If something like this list has already been created, I'd appreciate > hearing about > it before I put much more work into our own. This would be a good opportunity for VO to reach out to the larger community. It really isn't for us to mandate nomenclature. An interactive dictionary/beastiary of astronomical objects and processes could be useful all by itself, and will be of obvious utility for various VO projects. A common understanding of each "hypothesis" will indeed be key to VOEvent, for instance. I'm not sure, however, that the ApJ keywords are the best model for constructing this content descriptor list. Keywords are a way to partition the level of interest a member of the community may have in reading a paper. A UCD is a way of partitioning the underlying physics. For instance, given that the interest in working on this is arising out of VOEvent, it isn't surprising that there is a focus on processes more than objects, and that the selection of objects would be weighted toward time variability in various ways. There are dozens of fine shadings between variable stars. On the other hand, while one can distinguish between elliptical, irregular and spiral galaxies, there isn't any mechanism (yet) for specifying the precise type of each. I'm leery of encouraging these descriptors to become longer than they are, but it seems inappropriate to specify generally descriptive classes, like: stars.variable.irregular stars.variable.long_period stars.variable.semi-regular at the same level as members of prototypical classes, like: stars.variable.Cepheid stars.variable.RR_Lyr stars.variable.RS_CVn (And where is stars.variable.W_UMa? Just pointing out that the list will never be complete.) Perhaps it should be stars.variable.class.Cepheid? Or better yet, adjust in the other direction, maybe stars.variable.period.irregular? Or ideally, a general mechanism might be provided for parametrically classifying periodicity. The challenge here is not only that the list will never be complete, it is that we should be encouraging researchers to actively augment and improve the list. A workable classification scheme is often the first step in organizing a research program. But the result of a research program is often to overturn the original classification scheme. We don't want to provide a mechanism that is only useful for describing objects far removed from the cutting edge. Rob Seaman NOAO -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 3024 bytes Desc: not available URL: From Hessman at Astro.physik.Uni-Goettingen.de Tue Apr 26 07:45:27 2005 From: Hessman at Astro.physik.Uni-Goettingen.de (Frederic V. "Rick" Hessman) Date: Tue, 26 Apr 2005 16:45:27 +0200 Subject: New UCDs for VOEvent please In-Reply-To: <816d402df50341a5d44aee3e499f23e8@noao.edu> References: <4269395A.9010802@cacr.caltech.edu> <816d402df50341a5d44aee3e499f23e8@noao.edu> Message-ID: <83f2d949bed1694f983c1b81f65c67e2@Astro.physik.Uni-Goettingen.DE> On 26 Apr 2005, at 4:20 pm, Rob Seaman wrote: > On Apr 26, 2005, at 3:28 AM, Rick Hessman wrote: > >> I've added more VOEvent examples, several suggestions for IVOA/UCD to >> the proposed >> object/event/process UCD list at >> >> http://monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/ >> UnifiedContentDescriptors > > Good start at a list. A search facility would add immensely to its > usefulness as the list grows. This would also function as a validator > for an astronomer's guess as to the proper syntax for a familiar class > of objects. > >> If something like this list has already been created, I'd appreciate >> hearing about >> it before I put much more work into our own. > > This would be a good opportunity for VO to reach out to the larger > community. It really isn't for us to mandate nomenclature. An > interactive dictionary/beastiary of astronomical objects and processes > could be useful all by itself, and will be of obvious utility for > various VO projects. A common understanding of each "hypothesis" will > indeed be key to VOEvent, for instance. On the other hand, one can't have TOO many people laying on their hands, since there is a need for some level of editorial control. We'd be happy to provide our Twiki more-or-less as it is, since it's already interactive and available to anyone interested. > I'm not sure, however, that the ApJ keywords are the best model for > constructing this content descriptor list. Keywords are a way to > partition the level of interest a member of the community may have in > reading a paper. A UCD is a way of partitioning the underlying > physics. For instance, given that the interest in working on this is > arising out of VOEvent, it isn't surprising that there is a focus on > processes more than objects, and that the selection of objects would > be weighted toward time variability in various ways. There are dozens > of fine shadings between variable stars. On the other hand, while one > can distinguish between elliptical, irregular and spiral galaxies, > there isn't any mechanism (yet) for specifying the precise type of > each. Actually, the ApJ/A&A/MN keywords should really be a GREAT place to start, since they are supposed to capture what is eventually done with the content. It's clear that they don't provide a uniform and uniformly deep level of description, but at least they provide a good and evenly distributed place to start. > I'm leery of encouraging these descriptors to become longer than they > are, but it seems inappropriate to specify generally descriptive > classes, like: > > stars.variable.irregular > stars.variable.long_period > stars.variable.semi-regular > > at the same level as members of prototypical classes, like: > > stars.variable.Cepheid > stars.variable.RR_Lyr > stars.variable.RS_CVn > > (And where is stars.variable.W_UMa? Just pointing out that the list > will never be complete.) > Perhaps it should be stars.variable.class.Cepheid? Or better yet, > adjust in the other direction, maybe stars.variable.period.irregular? > Or ideally, a general mechanism might be provided for parametrically > classifying periodicity. No no no no : these are individual stars but names commonly used to typify a certain variable star behavior (just as we say "Cepheids" and really mean "delta Cepheids" = "stars like delta Cep"). There really are "W UMa" stars. Of course, the UCD can't be defined for individual objects other than a very few like the Sun, Moon, and major planets. Thus, "stars.variable.W_UMa" means the same as "stars.variable.class.W_UMa"; I suppose we could add on the "*.class*" just as a reminder, but at the cost of an additional hierarchical level of detail. > The challenge here is not only that the list will never be complete, > it is that we should be encouraging researchers to actively augment > and improve the list. A workable classification scheme is often the > first step in organizing a research program. But the result of a > research program is often to overturn the original classification > scheme. We don't want to provide a mechanism that is only useful for > describing objects far removed from the cutting edge. Fortunately, astronomers - even very good ones - are often rather traditional in their use of nomenclature, so we'll need such metadata whether someone thinks it's quaint or not. As a stellar astrophysicist interested in variability and accretion, I've included things I'd like to have and will leave it to others to include their own metatdata. Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 5440 bytes Desc: not available URL: From Hessman at Astro.physik.Uni-Goettingen.DE Tue Apr 26 07:57:35 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Tue, 26 Apr 2005 16:57:35 +0200 Subject: New UCDs for VOEvent please In-Reply-To: <816d402df50341a5d44aee3e499f23e8@noao.edu> References: <4269395A.9010802@cacr.caltech.edu> <816d402df50341a5d44aee3e499f23e8@noao.edu> Message-ID: Another thought.... On 26 Apr 2005, at 4:20 pm, Rob Seaman wrote: > The challenge here is not only that the list will never be complete, > it is that we should be encouraging researchers to actively augment > and improve the list. A workable classification scheme is often the > first step in organizing a research program. But the result of a > research program is often to overturn the original classification > scheme. We don't want to provide a mechanism that is only useful for > describing objects far removed from the cutting edge. The "cutting edge" will always be such that one won't have a useful classification scheme other than unusual combinations of the more general bits and pieces. That's why the UCD has to be hierarchical (to emphasize/extract general properties even when given specifics) and easily combined. Let's see..... cosmology.dark_energy <== cosmology.background;em.microwave cosmology.background.polarization;em.microwave stars.supernova.Type_Ia;process.eruption.hydrodynamic; process.eruption.thermonuclear galaxies.velocity_curve cosmology.abund .... (Aha - already discovered a few important UCD's to add....!) Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1887 bytes Desc: not available URL: From seaman at noao.edu Tue Apr 26 11:03:01 2005 From: seaman at noao.edu (Rob Seaman) Date: Tue, 26 Apr 2005 11:03:01 -0700 Subject: New UCDs for VOEvent please In-Reply-To: References: <4269395A.9010802@cacr.caltech.edu> <816d402df50341a5d44aee3e499f23e8@noao.edu> Message-ID: I said: >> The challenge here is not only that the list will never be complete, >> it is that we should be encouraging researchers to actively augment >> and improve the list. A workable classification scheme is often the >> first step in organizing a research program. But the result of a >> research program is often to overturn the original classification >> scheme. We don't want to provide a mechanism that is only useful for >> describing objects far removed from the cutting edge. Rick Hessman says: > The "cutting edge" will always be such that one won't have a useful > classification scheme other than unusual combinations of the more > general bits and pieces. That's why the UCD has to be hierarchical > (to emphasize/extract general properties even when given specifics) > and easily combined. Let's see..... > > cosmology.dark_energy <== cosmology.background;em.microwave > cosmology.background.polarization;em.microwave > stars.supernova.Type_Ia;process.eruption.hydrodynamic; > process.eruption.thermonuclear > galaxies.velocity_curve > cosmology.abund > .... > > (Aha - already discovered a few important UCD's to add....!) I'm becoming more skeptical that IVOA standard UCDs are appropriate for representing the often slippery nature of astronomical "processes" and "objects". (As I pointed out at in a similar context at the VOEvent workshop - one might choose to regard an object simply as a long lived process. A main sequence star is a ~10 Gy thermonuclear reaction.) But a UCD is targeted differently (from UCD-1.9.9b): "The Unified Content Descriptor (UCD) is a formal vocabulary for astronomical metadata that is controlled by the International Virtual Observatory Alliance (IVOA)." The question is whether the characterization of astronomical objects/processes represents "metadata". The whole point of the precision of a UCD specification (e.g., phot.flux;em.optical;meas.error;stat.max) is to provide a solid foundation for building a sound scientific argument - but such an argument typically results in drawing new insights and building new logical connections - often using new vocabulary. On the other hand, even the most well established nomenclature regarding astronomical objects and processes is subject to revision and extension as better data and more profound theory collide. Namespaces provide a possible way to address this. For instance, IVOA is developing a very basic namespace and various astronomical constituencies then support richer, and perhaps shorter latency, vocabularies of their own. However, we have this bit of constraining boilerplate to muddy the waters: "4.1.2 Namespaces. The use of namespaces, indicated by the presence of a colon in the word is possible, but should be avoided as far as possible. The namespace is defined by the string before the colon and the word follows. The words in the non-standard namespace must be distinct from all words currently in the IVOA namespace. While developers may need local namespace, they should be used only temporarily, for words that are not yet included into the UCD validated by the IVOA. New words should be added using the procedures discussed in section XX." What is the justification for trying to require that words in a non-standard namespace be distinct? For instance, we couldn't possibly require that two different non-standard namespaces not overlap. Why regard the IVOA namespace as *necessarily* preeminent? "Standard" does not equate with "compulsory". Either the standard makes sense or you won't be able to force folks to use it anyway. In any event, one would think that alternate interpretations of the same vocabulary would be one of the strongest justifications for alternate namespaces. This isn't an opportunity to lose control of alternate vocabulary - it's the way to enforce control of alternate usages. I also find the word "temporarily" to be curiously undefined for a science in which observations and inferences from decades and even centuries gone by may be revisited. To the list of UCD commandments: 1. UCDs should be short. 2. They should suggest the concept being labeled. 3. Only a single UCD should be appropriate for a given concept. 4. UCDs should be complete, describing all concepts of interest. 5. The vocabulary used within UCDs should be as small as possible. 6. Related concepts should have related UCDs. 7. Quantities with the same UCD should be comparable. I might suggest adding: 8. For IVOA to control its vocabulary, it must provide the opportunity for others to control their own. Ralph Waldo Emerson may shed some light: "The poets made all the words, and therefore language is the archives of history, and, if we must say it, a sort of tomb of the muses For, though the origin of most of our words is forgotten, each word was at a stroke of genius, and obtained currency, because for the moment it symbolizes the world to the first speaker and to the hearer. The etymologist finds the deadest word to have been once a brilliant picture. Language is fossil poetry." However much effort is expended to constrain and mandate standard usage, the users will seek ways to subvert the dominant paradigm. This isn't just the nature of users, it is the nature of science as poetry. Careful support for alternate usage is the key to controlling anarchy. Rob Seaman NOAO -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 5621 bytes Desc: not available URL: From Hessman at Astro.physik.Uni-Goettingen.DE Wed Apr 27 03:15:28 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Wed, 27 Apr 2005 12:15:28 +0200 Subject: New UCDs for VOEvent please In-Reply-To: References: <4269395A.9010802@cacr.caltech.edu> <816d402df50341a5d44aee3e499f23e8@noao.edu> Message-ID: <0b948e6b641050d8843597c4d28fc850@Astro.physik.Uni-Goettingen.DE> > I'm becoming more skeptical that IVOA standard UCDs are appropriate > for representing the often slippery nature of astronomical "processes" > and "objects". The question is whether the characterization of > astronomical objects/processes represents "metadata". The whole point > of the precision of a UCD specification (e.g., > phot.flux;em.optical;meas.error;stat.max) is to provide a solid > foundation for building a sound scientific argument - but such an > argument typically results in drawing new insights and building new > logical connections - often using new vocabulary. On the other hand, > even the most well established nomenclature regarding astronomical > objects and processes is subject to revision and extension as better > data and more profound theory collide. Ah, but the point of UCDs is not to let computers write papers but to be able to let computers organize and re-organize information using terms which we can easily formulate/manipulate. At a pretty trivial level, it can be something as simple as saying what the point of an observation is/was (the reason why a target classification is needed in RTML) or to describe what is roughly happening so that a computer can respond to it (the reason it's needed in VOEvent), but a broader use within the VO is obvious. While we're all spoiled by the services provided by Simbad, resolving astronomical names and querying catalogues won't permit us to combine information to the fullest unless we can express what it is we have and what we want in a fashion which goes far beyond the present IVOA/UCD (crafted really only for VOTable). Thus, RTML and VOEvent would certainly get by using their own little classification lists, but the adoption of a more generally used UCD for astronomical objects and processes is bound to become necessary. The earlier we start discussing it, the faster we will be able to profit from it. Fortunately, a supernova will always remain a supernova and a spiral galaxy won't loose it's spirals within our lifetime, so the evolution of UCD's will be in the direction of the addition of new terms - as they become needed - and the passive abandonment of old UCD's which no longer serve any but a purely historical purpose - well, we should let historians of science keep their access to old terms (they may actually want to know what a W UMa star was/is ;-) > 3. Only a single UCD should be appropriate for a given concept. > 4. UCDs should be complete, describing all concepts of interest. Rots of ruck! A UCD which attempts (!) to describe what it is we do will never be complete and unambiguous. The point is not that it can be perfect but that it exists at all. > However much effort is expended to constrain and mandate standard > usage, the users will seek ways to subvert the dominant paradigm. > This isn't just the nature of users, it is the nature of science as > poetry. Careful support for alternate usage is the key to controlling > anarchy. Frankly, I imagine that most users won't even see it. We're doing this to help stupid computers become more useful and not to constrain the science of our colleagues. Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 4076 bytes Desc: not available URL: From pfo at star.le.ac.uk Wed Apr 27 03:43:04 2005 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Wed, 27 Apr 2005 11:43:04 +0100 (BST) Subject: New UCDs for VOEvent please In-Reply-To: <0b948e6b641050d8843597c4d28fc850@Astro.physik.Uni-Goettingen.DE> Message-ID: Hi, I didn't want to jump into this discussion, but what the heck :-) OK, I'm concerned about the usage of this new proposal. UCDs were born to identify quantities listed in tables (essentially a way to let automated software recognize the nature of the columns in such table). We left out any attempt to include object types, after all, a magnitude is something which applies to a planet, star, galaxy, QSO, whatever, and so with many things like spectral features. It is obvious that in the context of the VO, we would like to have some way to attach a label to the kind of object we are talking about. And the proposed schemes sound doable, not easy, not 100% reliable, but workable. My questions to anyone interested are: "how do you envision using these new UODs (Unified Object-type Descriptor)?" By that, I mean, in which part of the metadata would you like to insert theses descriptors? Catalogues like USNO, 2mass, etc, contain a mixture of objects, and even homogeneous catalogues (like galaxies catalogues) will contain several flavours of galaxies, hence my concern. An object type may not be unique... How do we handle those cases? (after all, these are flags/labels to make our life easier. If the core of a galaxy is an AGN, what does the descriptor look like? UCDs of physical quantities are much easier to handle in that sense! (as noted below regarding the unicity of a UCD). How deep do we want to describe an object? Say that the same AGN has exhibited variations in HBeta flux (ok, kick for the incorrectness :-) :-) Do we want to describe such variability? For some people/applications it will be important, for others not. Although Frederic says that a SN will always be a SN, sure, but what about before? If Eta Car went SN next month, how would we label it? Furthermore, objects may not change in human-lifetime scales, but our perception can... I recall in the mid 80's that the core of the Tarantula Nebula (R136??) was thought to be a super-massive star, only to be discovered later, using instrument with higher angular resolution that it was a compact star cluster... I'm nearly sure there are other examples floating around. For the historians, as Frederic says, should we think of attaching a time stamp to any UOD/object pair? After all, if tomorrow we have to change it, should we erase the previous knowledge? Just my 2 pences :-) Patricio On Wed, 27 Apr 2005, Frederic V. "Rick" Hessman wrote: > > I'm becoming more skeptical that IVOA standard UCDs are appropriate > > for representing the often slippery nature of astronomical "processes" > > and "objects". The question is whether the characterization of > > astronomical objects/processes represents "metadata". The whole point > > of the precision of a UCD specification (e.g., > > phot.flux;em.optical;meas.error;stat.max) is to provide a solid > > foundation for building a sound scientific argument - but such an > > argument typically results in drawing new insights and building new > > logical connections - often using new vocabulary. On the other hand, > > even the most well established nomenclature regarding astronomical > > objects and processes is subject to revision and extension as better > > data and more profound theory collide. > > Ah, but the point of UCDs is not to let computers write papers but to > be able to let computers organize and re-organize information using > terms which we can easily formulate/manipulate. At a pretty trivial > level, it can be something as simple as saying what the point of an > observation is/was (the reason why a target classification is needed in > RTML) or to describe what is roughly happening so that a computer can > respond to it (the reason it's needed in VOEvent), but a broader use > within the VO is obvious. While we're all spoiled by the services > provided by Simbad, resolving astronomical names and querying > catalogues won't permit us to combine information to the fullest unless > we can express what it is we have and what we want in a fashion which > goes far beyond the present IVOA/UCD (crafted really only for VOTable). > > Thus, RTML and VOEvent would certainly get by using their own little > classification lists, but the adoption of a more generally used UCD for > astronomical objects and processes is bound to become necessary. The > earlier we start discussing it, the faster we will be able to profit > from it. > > Fortunately, a supernova will always remain a supernova and a spiral > galaxy won't loose it's spirals within our lifetime, so the evolution > of UCD's will be in the direction of the addition of new terms - as > they become needed - and the passive abandonment of old UCD's which no > longer serve any but a purely historical purpose - well, we should let > historians of science keep their access to old terms (they may actually > want to know what a W UMa star was/is ;-) > > > 3. Only a single UCD should be appropriate for a given concept. > > 4. UCDs should be complete, describing all concepts of interest. > > Rots of ruck! A UCD which attempts (!) to describe what it is we do > will never be complete and unambiguous. The point is not that it can > be perfect but that it exists at all. > > > However much effort is expended to constrain and mandate standard > > usage, the users will seek ways to subvert the dominant paradigm. > > This isn't just the nature of users, it is the nature of science as > > poetry. Careful support for alternate usage is the key to controlling > > anarchy. > > Frankly, I imagine that most users won't even see it. We're doing > this to help stupid computers become more useful and not to constrain > the science of our colleagues. > > Rick --- Patricio F. Ortiz pfo at star.le.ac.uk Department of Physics & Astronomy Phone: +44 (0)116 252 2015 University of Leicester Leicester, LE1 7RH, UK From aa at astro.ex.ac.uk Wed Apr 27 03:50:10 2005 From: aa at astro.ex.ac.uk (Alasdair Allan) Date: Wed, 27 Apr 2005 11:50:10 +0100 Subject: New UCDs for VOEvent please In-Reply-To: <0b948e6b641050d8843597c4d28fc850@Astro.physik.Uni-Goettingen.DE> References: <4269395A.9010802@cacr.caltech.edu> <816d402df50341a5d44aee3e499f23e8@noao.edu> <0b948e6b641050d8843597c4d28fc850@Astro.physik.Uni-Goettingen.DE> Message-ID: <2087F54E-B70A-11D9-BE5F-000D93C0E1F0@astro.ex.ac.uk> Rick Hessman wrote: > Rob Seaman wrote; >> However much effort is expended to constrain and mandate standard >> usage, the users will seek ways to subvert the dominant paradigm. >> This isn't just the nature of users, it is the nature of science as >> poetry. Careful support for alternate usage is the key to >> controlling anarchy. > > Frankly, I imagine that most users won't even see it. We're doing > this to help stupid computers become more useful and not to constrain > the science of our colleagues. Exactly, this isn't for user consumption, this is so that bits of software can route messages correctly. VOEvent messages are never meant to be consumed, or even seen, by a human user. Al. From Hessman at Astro.physik.Uni-Goettingen.DE Wed Apr 27 04:34:54 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Wed, 27 Apr 2005 13:34:54 +0200 Subject: New UCDs for VOEvent please In-Reply-To: References: Message-ID: <32fd4a5efbfd9d3afbbae300411c0379@Astro.physik.Uni-Goettingen.DE> > "how do you envision using these new UODs (Unified Object-type > Descriptor)?" By that, I mean, in which part of the metadata would you > like to insert theses descriptors? To explain where I'm coming from, let's look at VOEvent and RTML: - the VOEvent now has a element, where (name) can be something like "supernova" or "gamma-ray burst". - RTML has a TargetType used by a (name) element. Sound pretty similar? Yes, VOEvent could adopt RTML's element or vice versa, but what do the Virtual Repository people do? Is it really the job of VOEvent to suggest how all the VO colleagues are supposed to classify objects when they get around to needing such, especially when others start needed descriptions of objects and processes which will never produce an event? I admit I'm a newcomer with no (as yet) official function, but I can't imagine the VO getting much farther without being able to teach the software how to describe what is is we're actually studying beyond saying that the number in a table is supposed to mean (admittedly an important first step). > An object type may not be unique... How do we handle those cases? > (after > all, these are flags/labels to make our life easier. If the core of a > galaxy is an AGN, what does the descriptor look like? > UCDs of physical quantities are much easier to handle in that sense! > (as > noted below regarding the unicity of a UCD). Why the need for a final description? From a VOEvent perspective, something should gradually shift from one description to another, e.g. process.burst;em.gamma -> process.burst;em.vis -> galaxies;stars.supernova or - something which is bound to happen eventually (since it already has) - galaxies.Seyfert;galaxies.nucleus;em.X-ray -> stars.variable.cataclysmic.polar This capability for being able to descibe what people/computers think is happening has quite practical consequences when it comes to things like follow-up observations: some won't be interested in Seyferts, others in polars, and the Chandra ToO may insist that it be one or the other. > How deep do we want to describe an object? Say that the same AGN has > exhibited variations in HBeta flux (ok, kick for the incorrectness :-) > :-) > Do we want to describe such variability? For some people/applications > it > will be important, for others not. Deep enough to be useful, shallow enough to be manageable. Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From seaman at noao.edu Wed Apr 27 09:10:42 2005 From: seaman at noao.edu (Rob Seaman) Date: Wed, 27 Apr 2005 09:10:42 -0700 Subject: New UCDs for VOEvent please In-Reply-To: <32fd4a5efbfd9d3afbbae300411c0379@Astro.physik.Uni-Goettingen.DE> References: <32fd4a5efbfd9d3afbbae300411c0379@Astro.physik.Uni-Goettingen.DE> Message-ID: <72138974eda1f17ad78589973743b4ee@noao.edu> This is a timely discussion for the VOEvent folks, but likely perplexing for the UCD folks. The gist of my previous comments was not that VOEvent didn't need to wrestle with characterizing coherent descriptions for the "hypothesis" section of an event. The hypothesis is the key to fielding a richly useful VOEvent facility. Rather, I question whether a UCD, per se, is the correct way to represent this kind of information - clearly itself not a brand new topic for the UCD list :-) It might be that we need to borrow the syntax from UCD's and roll our own - or it might be that we just need to pick another namespace(s). Both the VO and the larger astronomical community would benefit from wrestling with the issues Rick has raised. In the mean time, Patricio asks a lot of good questions. Rob Seaman NOAO From mjg at cacr.caltech.edu Wed Apr 27 09:16:09 2005 From: mjg at cacr.caltech.edu (Matthew Graham) Date: Wed, 27 Apr 2005 09:16:09 -0700 Subject: New UCDs for VOEvent please In-Reply-To: <32fd4a5efbfd9d3afbbae300411c0379@Astro.physik.Uni-Goettingen.DE> References: <32fd4a5efbfd9d3afbbae300411c0379@Astro.physik.Uni-Goettingen.DE> Message-ID: <426FBAC9.2050600@cacr.caltech.edu> Hi, One alternative, though I do not know how practically viable it would be at present, is to use the astronomy ontology that Ed Shaya at University of Maryland is developing and presented a poster about at last year's ADASS. Cheers, Matthew From andrea.preitemartinez at rm.iasf.cnr.it Wed Apr 27 09:27:45 2005 From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez) Date: Wed, 27 Apr 2005 18:27:45 +0200 Subject: UCDs and VOEvents Message-ID: <20050427182745.g87w5yhcs76swcok@webmail.sic.rm.cnr.it> Dear Roy, dear members of the VOE group, > Dear Andrea and Sebastien > This note is to ask the UCD working group for help in building a new section of the UCD > vocabulary in support of the VOEvent working group. > ... thank you for your very interesting and challenging proposal! We think the UCDwg can be the right place to discuss all semantic aspects of the VO, not only those related to "bona fide" UCDs. Of course, we should clearly keep on the right track, as already defined in the last years, for what concerns the UCDs, their definition, their semantics, their syntax, their usage. For the main document on UCDs we have to go on from the stage of Proposed Recommendation to the formal stage of IVOA Recommendation. We also have to upgrade the (new!) list of ucd-words from the level of Draft to that of PR, through a formal RFC. We can do this in Kyoto. Your proposal of opening a discussion in the UCDwg > with the objective of > describing "immediate astronomical events" in a semantically-meaningful way > ... > covering astronomical event types is, as we said, both interesting and challenging. Interesting, because - it is a problem that has been tackled many times giving rise to a number of "subjective" solutions (each one valid/sound in its own context): it is time to discuss it starting from the work already done, but trying to do it in a "semantically-meaningful way" - it has to do with a semantic problem that is hard to locate in/assign to other IVOA WGs; - the UCDwg has the right competences to do the job. Challenging, because - definitely hard to do - not to be mixed up with UCDs, that are ment to serve other purposes. The "mail storm" produced by your proposal is a clear indication of interest, but it also tells us that the discussion has to be kept within clear and firm boundaries, having in mind the distinction between UCDs and their role on one hand, and the "event vocabulary" on the other. In conclusion, the answer to your questions: > Could you help us with doing this? > Perhaps a meeting at the Kyoto IVOA would be appropriate? is yes, we can help, yes, the final part of the UCD session in Kyoto will be devoted to the "event vocabulary". All VOEvent people are of course invited to this session. A tentative agenda could be: - A short presentation of the problem (somebody from the VOEwg has to volunteer for that! Please, let me (=>Andrea) know.) - Plenary discussion, actions. In order not to diverge too much before the start of the discussion in Kyoto, here you can find a few remarks/comments on http://monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/UnifiedContentDescriptors > Unfortunately, the IVOA/UCD list is incomplete: there's no complete > wavelength/frequency coverage in "em.*", for instance (e.g. no em.microwave). The UCD coverage of the electromagnetic spectrum *is* complete. The top-level wavelength/frequency division simply follows the one adopted for the Registry description for more compatibility, that is 7 large bands: radio, mm, IR, optical, UV, X-ray, gamma-ray. See "Spectral Coverage" in http://www.ivoa.net/Documents/REC/ResMetadata/RM-20040426.html Therefore, there is no top level like EUV, sub-mm or microwave, but I guess microwave is covered by the following UCD : em.radio.1500-3000MHz, em.radio.3-6GHz, em.radio.6-12GHz, ... It is important to first notice that the description of the electromagnetic division in the em.* words of the UCD is a special case: it can be seen as an enumeration of possible values for the observation passband. Take for example the description of an IRAS 12 micron flux in VOTable. We can write it: But we could have written: The introduction of all the em.* terms in the UCD vocabulary was done to allow the first description, instead of the 2nd that is less standard, because different people would use different values for the "bandpass" description (12um, IRAS 12 micron, 8.5-15micron, ...) The em.* words can be seen as named instances of the generic "instr.bandpass" UCD. These words were introduced into the vocabulary for two reasons: - they are absolutely needed: most astronomical information comes from photons, and we need to expres in which part of the spectrum a flux or magnitude was measured. - the problem is relatively simple, as it roughly only implies defining intervals on a one-dimensional axis. The astronomical object types haven't been so far introduced in the UCD vocabulary for several reasons: - the main use of UCDs is to describe table columns. The existing "src.class" and "meta.code.class" UCDs were sufficient for this purpose, allowing to describe that a catalogue's column contains an astronomical source classification. This classification (often a numeric code for UCD meta.code.class) is what the author of the catalogue writes, and is not standardized. - Even for the description of a single measurement, we should avoid putting all the metadata into a UCD. We'd hate to see that value 5.23mag is described by ucd="phot.mag;em.opt.V;object.star.supernova.individual.SN1987A;time.epoch.1990" Instead, we'd rather say (in VOTable-like syntax): - The precise definition of object types is very complex. There are examples in the journal keywords, but also in SIMBAD: http://simbad.u-strasbg.fr/guide/chF.htx or the IAU thesaurus http://msowww.anu.edu.au/library/thesaurus/english/ ... The object type definition is difficult, because we often have to deal with hierarchical structure/classification, and an object can belong to different classes: a galaxy can be at the same time: - galaxy - galaxy in cluster - IR source - radio source - X-ray source - emission-line galaxy - galaxy with active nucleus (AGN) - ... The classification can depend on the background of the astronomer (e.g. radio or optical astronomer), and in some cases the boundaries between different classes are fuzzy... (Also !) for these reasons, the definition of standard words for object types was deliberately left out of the UCD vocabulary. But it might be useful to create a new "object" branch, to enumerate a list of possible standardized object types. A careful explanation of each term should be provided, so there is no ambiguity: e.g. does Planetary_Nebula mean the central star, the nebula or both? This list of terms would correspond to an enumeration of possible values corresponding to ucd="src.class". In the same spirit, the "events" are poorly described with the current ucd words. There are a few ones, like pos.lunar.occult, phys.mass.loss or src.var.pulse, but they can certainly be better described by domain specialists. Andrea Sebastien From roy at cacr.caltech.edu Wed Apr 27 09:53:24 2005 From: roy at cacr.caltech.edu (Roy Williams) Date: Wed, 27 Apr 2005 09:53:24 -0700 Subject: New UCDs for VOEvent please In-Reply-To: <426FBAC9.2050600@cacr.caltech.edu> References: <32fd4a5efbfd9d3afbbae300411c0379@Astro.physik.Uni-Goettingen.DE> <426FBAC9.2050600@cacr.caltech.edu> Message-ID: <426FC384.5080509@cacr.caltech.edu> Part of the trouble with ontology/vocabulary discussions is that they can fly away so easily into abstraction. I would like to try and ground the discussion with some examples that I have heard over the last few days. How can we make the UCD set so that the following are possible? (1) Selection of events A client may wish to get, for example: "All events that involve cepheid sources" "All supernova events brighter than 18 magnitude" In order to service these subscriptions, the client would use specific UCDs in place of the natural language words "cepheid" and "supernova". We assume that a machine-learning system in the data pipeline has made probabilistic assessments that the event is "cepheid" or "supernova". We could also do this without the formal UCD structure by doing keyword search in the natural language "description" section of the event -- which of course assumes that some human had written the textual description. (2) When a followup changes the hypothesis Suppose there is an interesting event that is classified somehow (eg supernova). There might be many followup observations that cite the original event ID, and some of these might show a different classification. How can we decide if the classification status of an event has significantly changed, or become more definite, due to followup? From seaman at noao.edu Wed Apr 27 10:03:42 2005 From: seaman at noao.edu (Rob Seaman) Date: Wed, 27 Apr 2005 10:03:42 -0700 Subject: New UCDs for VOEvent please In-Reply-To: <426FBAC9.2050600@cacr.caltech.edu> References: <32fd4a5efbfd9d3afbbae300411c0379@Astro.physik.Uni-Goettingen.DE> <426FBAC9.2050600@cacr.caltech.edu> Message-ID: On Apr 27, 2005, at 9:16 AM, Matthew Graham wrote: > One alternative, though I do not know how practically viable it would > be at present, is to use the astronomy ontology that Ed Shaya at > University of Maryland is developing and presented a poster about at > last year's ADASS. I didn't want to muddy the waters by bringing up the "O" word. Google "Shaya astronomy ontology" for lots of hits on this. My visceral reaction to discussions over the last couple of years as well as the last couple of days is similar. A noble effort - so large and grand that pragmatic functioning systems can't possibly rely on the results in any strong sense. I also have a deep skepticism that practicing astronomers will embrace the results. Noble nonetheless and worthy of the best efforts that the VO can spare. On the other hand, VOEvent will amount to nothing if it is not rigorously pragmatic. I don't think that "pragmatic" and "ontology" are incompatible - and VOEvent provides a great test case for demonstrating this. We need to describe only certain astronomical processes/objects - the ones with a time varying nature. Our list should be biased by an artful sense of where the productive science lies - start with shadings of GRBs, SNs, solar system objects - and some variations on grab bag categories of "other" or "none of the above" or even "all of the above". Establish a process for adding to the list. And don't get too torqued up about "technical correctness". Rob Seaman NOAO From edward.j.shaya.1 at gsfc.nasa.gov Fri Apr 29 11:51:55 2005 From: edward.j.shaya.1 at gsfc.nasa.gov (Ed Shaya) Date: Fri, 29 Apr 2005 14:51:55 -0400 Subject: New UCDs for VOEvent please In-Reply-To: References: <32fd4a5efbfd9d3afbbae300411c0379@Astro.physik.Uni-Goettingen.DE> <426FBAC9.2050600@cacr.caltech.edu> Message-ID: <4272824B.7010900@gsfc.nasa.gov> Rob Seaman wrote: > On Apr 27, 2005, at 9:16 AM, Matthew Graham wrote: > >> One alternative, though I do not know how practically viable it would >> be at present, is to use the astronomy ontology that Ed Shaya at >> University of Maryland is developing and presented a poster about at >> last year's ADASS. > > > I didn't want to muddy the waters by bringing up the "O" word. Google > "Shaya astronomy ontology" for lots of hits on this. My! I took this advice and googled on "ontology shaya" and found the following information: *C. Paths to Enlightenment: Buddhist Art in India and Java* *The Life and Teachings of the Buddha (ca. 563-483):* Prince Siddhartha, surname Gautama, son of Queen Maya and King Suddhodana, born in the small kingdom of Kapilavastu near the Nepalese border. Known as Shakyamuni ("Sage of the Shaya Clan"). Nirvana, Parinirvana at Kusignagara. Formation of the Sangha or Order of Monks What this says is that an alias name for Buddha/Siddhartha is "Sage of the Shaya Clan". It logically follows that Ontology is part of the eightfold path to enlightenment or possibly the ninth fold. > My visceral reaction to discussions over the last couple of years as > well as the last couple of days is similar. A noble effort - so large > and grand that pragmatic functioning systems can't possibly rely on > the results in any strong sense. I also have a deep skepticism that > practicing astronomers will embrace the results. Noble nonetheless > and worthy of the best efforts that the VO can spare. > > On the other hand, VOEvent will amount to nothing if it is not > rigorously pragmatic. I don't think that "pragmatic" and "ontology" > are incompatible - and VOEvent provides a great test case for > demonstrating this. We need to describe only certain astronomical > processes/objects - the ones with a time varying nature. Our list > should be biased by an artful sense of where the productive science > lies - start with shadings of GRBs, SNs, solar system objects - and > some variations on grab bag categories of "other" or "none of the > above" or even "all of the above". Establish a process for adding to > the list. And don't get too torqued up about "technical correctness". With th end of the NVO NSF grant within 18 months, it certainly makes sense to find the quickest and simplest set of terms to fashion into a message for VOEvent alerting. Afterall, we just want to say an event happened at such a time and it appears to be one of these things. And it appears that it is almost finished except for a few details and agreement to standards. But we can also be keeping another eye on the longer time scale where we want to be able to put data in machine understandable terms so that applications can do the most possible on our behalf. This requires something a bit more sophisticated than just a simple class hierarchy of terms. An ontology would be more complete but probably not even an order of magnitude (factor 10) more than the UCD is now. In fact, given the requests and requirements to augment UCDs, with time, the UCD will probably grow to the size of an ontology anyway. So, it is probably wise to start doing some thinking in terms of the formal OWL standard now. What we do with the ontology can vary greatly. 1. Use it as a string identifier, exactly as UCDs are. The advantage is that one can read the Ontology at that point to get more context for the meaning of the term. 2. Use it as one more model builder for developing schemas. This is like UML but more in tune with knowledge/information structures. I think this is what Mathew had in mind. 3. Use it to test completeness and consistency of terms. This would not be on the fly, but rather as one adds new terms one can see whether it is clashing with other terms and Venn diagrams let you see something about completeness. This then makes it more acceptable for groups to be adding terms into their namespace without going to the VO heads or the IAU. 4. One can use it as the defining structure of all information being exchanged. Sounds daring but in fact several other related science fields are preparing to do just that, including space physics. 5. One can use it to reason out pathways to converting, pipelining, and analysing data. It should be possible to automatically find the transformation and queries needed to satisfy an arbitrary stated goal or request. Our group at UMD has an NASA/AISRP grant to figure out the basics of how this might be done using OWL. Ed > Rob Seaman > NOAO > >