From seaman at noao.edu Fri Jan 13 11:04:19 2012 From: seaman at noao.edu (Rob Seaman) Date: Fri, 13 Jan 2012 12:04:19 -0700 Subject: Terminology of time Message-ID: Howdy, I thought it might be useful to bring the attached document to the attention of the "terminologists" of the IVOA. The ITU Radiocommunication Assembly in Geneva next week will vote on something called the "Draft Revision to ITU-R Recommendation TF.460-6" which would have the effect of redefining Coordinated Universal Time without leap seconds (and therefore no longer a type of Universal Time). As we debate issues of semantics and terminology in the IVOA we would be well advised to keep an eye out for pitfalls such as this. Clarity and consensus of usage are key. Comments welcome. Rob -- -------------- next part -------------- A non-text attachment was scrubbed... Name: Statement-ISOTC 37-to-ITURadioAssembly-F.pdf Type: application/pdf Size: 144097 bytes Desc: not available URL: -------------- next part -------------- From norman at astro.gla.ac.uk Fri Jan 27 06:54:47 2012 From: norman at astro.gla.ac.uk (Norman Gray) Date: Fri, 27 Jan 2012 14:54:47 +0000 Subject: Units discussion Message-ID: <16C788CA-A26A-4E9B-A13F-AFE17F30AFB9@astro.gla.ac.uk> Greetings, all. On the IVOA wiki page about units , Markus and I appear to be reaching rough consensus on what's required (is that fair, Markus?). I'm sure the discussion would benefit from more voices, either there or on this list. I mention it here only because the wiki doesn't generate alerts for edits, so this may have dropped off some people's radar. All the best, Norman -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK From msdemlei at ari.uni-heidelberg.de Fri Jan 27 07:23:15 2012 From: msdemlei at ari.uni-heidelberg.de (Markus Demleitner) Date: Fri, 27 Jan 2012 16:23:15 +0100 Subject: Units discussion In-Reply-To: <16C788CA-A26A-4E9B-A13F-AFE17F30AFB9@astro.gla.ac.uk> References: <16C788CA-A26A-4E9B-A13F-AFE17F30AFB9@astro.gla.ac.uk> Message-ID: <20120127152315.GA25162@ari.uni-heidelberg.de> On Fri, Jan 27, 2012 at 02:54:47PM +0000, Norman Gray wrote: > On the IVOA wiki page about units > , > Markus and I appear to be reaching rough consensus on what's > required (is that fair, Markus?). Hmha, maybe the one point deserving the attention of the list is (and I think it's less fundamental than it might seem at first) and maybe a brief discussion here is this: [quoting Norman on the wiki page:] # One possibility is that we should aim for a minimal grammar (in which # case the CDS grammar is probably the most nearly minimal of the # three), or a lenient but still well-defined one (in which case the # FITS covers almost all bases, even though it's not a strict superset # of the others). I'd push for the latter: it's well-defined, but most # nearly compatible with everyone, plus it's flexible enough that # people don't have to try to memorise what is and isn't permitted # (principle of least surprise). I, on the other hand, maintain that having a simple grammar that uniquely defines how a given unit is expressed is preferable on grounds that VOUnits is, in effect, part of the VOTable spec, and people will, as soon as they do anything with the units at all, need to throw around parse trees (e.g.: unifying values in different units from two different tables). The less flamboyant the things they have to expect are the better. True, a parser library can help providing a unified interface here, but if we can keep the standard so simple that almost any kind of parser library will do the trick, even better, no? That some services may have to rework their units seems, in comparison, a small price to pay, even more so since they only have to write and run the conversion software once (as opposed to VOTable clients having to understand all kinds of syntaxes everytime they parse a unit, in every VOTable library). Similarly, I'd doubt a sensible spec will ever provide a "least surprise" -- people will always expect something that's not in the spec. Let's rather have something clear that's easy to learn and lets parsers easily give expressive error messages (which becomes harder when more different strings are valid expressions). > I'm sure the discussion would benefit from more voices, either > there or on this list. I mention it here only because the wiki > doesn't generate alerts for edits, so this may have dropped off > some people's radar. +1 from me. At this stage, I guess the difference between the "minimal" grammar and the "lenient" grammar are not huge, so a decision doesn't mess anything up badly in either direction. Deciding to go for minimal might help ward off later requests for additional features, though. Deciding to go for lenient might, on the other hand, make for a more relaxed RFC... Cheers, Markus From norman at astro.gla.ac.uk Sun Jan 29 11:45:32 2012 From: norman at astro.gla.ac.uk (Norman Gray) Date: Sun, 29 Jan 2012 19:45:32 +0000 Subject: Units discussion In-Reply-To: <20120127152315.GA25162@ari.uni-heidelberg.de> References: <16C788CA-A26A-4E9B-A13F-AFE17F30AFB9@astro.gla.ac.uk> <20120127152315.GA25162@ari.uni-heidelberg.de> Message-ID: <06CE7D69-74F7-4DA3-9A3E-26CAC40EA9EE@astro.gla.ac.uk> Markus and all, hello. On 27 Jan 2012, at 15:23, Markus Demleitner wrote: > [quoting Norman on the wiki page:] > > # One possibility is that we should aim for a minimal grammar (in which > # case the CDS grammar is probably the most nearly minimal of the > # three), or a lenient but still well-defined one (in which case the > # FITS covers almost all bases, even though it's not a strict superset > # of the others). I'd push for the latter: it's well-defined, but most > # nearly compatible with everyone, plus it's flexible enough that > # people don't have to try to memorise what is and isn't permitted > # (principle of least surprise). > > I, on the other hand, maintain that having a simple grammar that > uniquely defines how a given unit is expressed is preferable on > grounds that VOUnits is, in effect, part of the VOTable spec, and > people will, as soon as they do anything with the units at all, need > to throw around parse trees (e.g.: unifying values in different units > from two different tables). The less flamboyant the things they have > to expect are the better. > > True, a parser library can help providing a unified interface here, > but if we can keep the standard so simple that almost any kind of > parser library will do the trick, even better, no? I don't think there's a big problem here. Looking at the current grammar files , the three grammars are pretty similar, at 24, 26 and 27 lines long, ignoring comments and blank lines, and the differences are pretty minor. The three grammars differ in what tokens they accept (FITS accepts '^' and '**' as power indicators, OGIP and CDS accept only '**', and the multiplication operator is '.' for CDS, space or '*' for OGIP, and space, '*' or '.' for FITS. The main difference is the list of units that they recognise. Again, FITS is the most lenient, but I've already run into units you'd reasonably have in a RDBMS schema which aren't in there, so I plan to have an alternate syntax in the unity library which has a very generous set of units. > That some services may have to rework their units seems, in > comparison, a small price to pay, even more so since they only have > to write and run the conversion software once (as opposed to VOTable > clients having to understand all kinds of syntaxes everytime they > parse a unit, in every VOTable library). I'm interested in serving the latter case, too, with the unity library. All the best, Norman -- Norman Gray : http://nxg.me.uk