- From: Gannon Dick <gannon_dick@yahoo.com>
- Date: Thu, 14 Aug 2014 12:38:34 -0700
- To: "andrea.perego@jrc.ec.europa.eu" <andrea.perego@jrc.ec.europa.eu>, "frans.knibbe@geodan.nl" <frans.knibbe@geodan.nl>, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, Chris Beer <chris@codex.net.au>, ChrisLittle <chris.little@metoffice.gov.uk>
- Cc: "public-locadd@w3.org" <public-locadd@w3.org>, "public-egov-ig@w3.org" <public-egov-ig@w3.org>, public-lod <public-lod@w3.org>, "temporal@lists.opengeospatial.org" <temporal@lists.opengeospatial.org>, Piero Campalani <cmppri@unife.it>, Matthias Müller <matthias_mueller@tu-dresden.de>
Hello Chris, Thank you for this. I think a lot of people have forgotten how much mathematics and science were engendered by trying to construct calendars and timescales, for whatever purposes, and I think you are helping carry that flag. ============= Yes ============= However, in the OGC context of trying to produce a first Best Practice and some straightforward recommendations for future work, we have already ruled calendars, especially weeks and months, other than ISO8601 Gregorian, out of scope. And sadly, I think we will rule out true solar time too, though people's need for conversion to and from local solar time is a well established, and has very important use cases, such as for aerial imagery shadow interpretation. ============== That is a spreadsheet versus javascript problem. The *advantage* to ISO 8601 formats is that they round off time predictably, and that feature would be very worthwhile to retain. The "spreadsheet versus javascript" problem is that COBAL dates extend back to 1600 AD and there are many base dates for *nix and PC time, none of which come close to 1600 AD. The Julian Date extends back to 4713 BC. All of these are *day* standards, with FUBAR time-of-day rounding which requires conversion to UTC. There exist spreadsheets for local solar time[1]. As well as details of the calculation[2] and tables of observed (or forecast) seasonal set points (Solstice) and transits (Equinox) [3]. ============== I think we should capture that particular use case and incorporate details of the conversion of UTC to and from local solar time, perhaps as an engineering report, but I think the resources are not available for our stated delivery in December 2014. Do you know of any authoritative sources that we could reference? =============== see links below. NOAA = (Earth System Research Laboratory, National Oceanic and Atmospheric Administration) USNO = (Astronomical Applications Department of the U.S. Naval Observatory) NASA, for authoritative purposes, plays with big, loud, cool toys. Please don't tell them I said that. =============== my take: I think of linked data as ... as you are driving by the Taj Mahal the Turing Machine you are married to says "Look the Taj Mahal" and then a little light on your AI equipped dashboard lights up and says "Taj Mahal, India". Never contradict a Turing Machine even when Linked Data agrees ;-) My spreadsheet is a different, Linked Data specific use case. Because Time of Day is not roundable, you risk an inversion in Work-Life Balance where 8 hours of Rest is isometric with 16 hours of Activity. Only Overseas Banks and Government Mint Printing Presses "work" 24x7. The Solar Time (workday) Standard at the Equator is 12 Hours (plus ca. 7.5 Minutes) not 16 hours in mid-summer London. Make of that what you will :-) http://www.rustprivacy.org/2014/balance/gts/inversionEquator.jpg http://www.rustprivacy.org/2014/balance/gts/inversion50N.jpg Best Wishes, Gannon [1] http://www.esrl.noaa.gov/gmd/grad/solcalc/calcdetails.html [2a] http://www.esrl.noaa.gov/gmd/grad/solcalc/solareqns.PDF [2b] http://www.gandraxa.com/length_of_day.xml (this is someone's personal site, but the ability to include or exclude Twilight (Atmospheric Refraction) is important) [3] http://aa.usno.navy.mil/data/docs/EarthSeasons.php Best wishes, Chris -----Original Message----- From: Gannon Dick [mailto:gannon_dick@yahoo.com] Sent: Wednesday, August 13, 2014 6:38 PM To: andrea.perego@jrc.ec.europa.eu; frans.knibbe@geodan.nl; Simon.Cox@csiro.au; Chris Beer; Little, Chris Cc: public-locadd@w3.org; public-egov-ig@w3.org; public-lod; temporal@lists.opengeospatial.org; Piero Campalani; Matthias Müller Subject: (groan, not again): OGC Temporal DWG. Was: space and time Hi Chris, FWIW. While commerce depends upon Product Release Dates and Versioning, geographic information can default to the Julian Calendar harmonics. Not having to deal with this administrative detail is a real, pardon the expression, time saver. So, I did the math and made a spreadsheet (FODS or EXCEL), a prototype generic version "Release Clock". This calendar is not in harmony with astronomical calculations, which use the Winter Solstice as an anchor rather than New Year's. I apologize for this shameless attempt to curry favour with Champagne Manufacturers ;-) The calendar is by year, with anchors at New Year's and New Year+1. There are three arc control points. These are arbitrary but can be recognized holidays - and the key word is "recognized". For example I used Easter ~ Passover ~ Jerusalem Tourist Season. The control point labels (identity) has no Controlling Authority, that is, they have no effect on the graph (timeline). http://www.rustprivacy.org/2014/balance/gts/utct.zip Overseas Banks and Government Mint Printing Presses work over night. Human Resources and a Retail Store's safe in the back room do not. Neither do many Cultural Heritage resources. Work-Life Balance gets, um, unbalanced. --Gannon -------------------------------------------- On Tue, 7/29/14, Gannon Dick <gannon_dick@yahoo.com> wrote: Subject: RE: OGC Temporal DWG. Was: space and time Date: Tuesday, July 29, 2014, 12:45 PM On Tue, 7/29/14, Little, Chris <chris.little@metoffice.gov.uk> wrote: And I agree that transparency about calendar algorithms is an issue, not just in their book. This isone thing that I hope that an OGC Best Practice document could help, in however a small way. ============ Hi Chris, Maybe it is time to "go big" - Universal Coordinated Calendar Time (UTCT). In the near term, (this Julian Century) the Calendar has no unidentified shifts. We know about Leap Days and the Calendar is ignorant of Leap Seconds. So, it is possible. This presents a problem for Linked Data because even though Personal Identity is coupled to Occupation and Occupation is coupled to the Location of the Workplace, these are couplings not correlations. Mid-day, Noon, is a mean value, but one can't assume regression to the mean. At the Equator the "Authority" - Solar Noon - has a whopping 7 1/2 minute time shift. This is not hidden, but it is overwhelmed by the Equation of Time. The shifts, on a day-to-day basis do not accumulate to significance on a year-to-year basis. To determine coupling constants is a fools errand. e.g. http://www.rustprivacy.org/2014/balance/utct.jpg When people triangulate in their heads they use 3,4,5 triangles to keep the math easy. For this reason, the Axis length is 500%. All "shifts" (events which impact Work Life Balance) are vertical. Sorry, the "Day" indicator can't update automatically - it's a PDF. WDYT? Best, --Gannon (J.) Dick ;-) I'm not a commuter, I have a funny name. -----Original Message----- From: Gannon Dick [mailto:gannon_dick@yahoo.com] Sent: Thursday, July 24, 2014 5:24 PM To: andrea.perego@jrc.ec.europa.eu; frans.knibbe@geodan.nl; Simon.Cox@csiro.au; Chris Beer; Little, Chris Cc: public-locadd@w3.org; public-egov-ig@w3.org; public-lod; temporal@lists.opengeospatial.org; Piero Campalani; Matthias Müller Subject: Re: OGC Temporal DWG. Was: space and time Hi Chris, who wrote: One concern that I have is that we do not re-invent the wheel, and do nugatory work, hence this email. I do not envisage that we will need to do much with Calendars, which have been covered so well by Dershowitz and Reingold. ===================================== No question the quality of the issue coverage (Calendars) is first rate. However, the computations are not transparently self-evident and the references you cite in the Wiki are not available on-line - or are they ? 3. Calendrical Tabulations 1900-2200, Edward M. Reingold, Nachum Dershowitz. Hardcover: 636 pages. Publisher: Cambridge University Press (16 Sep 2002) Language: English ISBN-10: 0521782538 ISBN-13: 978-0521782531 4. Calendrical Calculations, Nachum Dershowitz, Edward M. Reingold. Paperback: 512 pages. Publisher: Cambridge University Press; 3 edition (10 Dec 2007) Language: English ISBN-10: 0521702380 ISBN-13: 978-0521702386 Accessability to "Wheels known to have been invented" is a Wiki issue, I think. --Gannon -------------------------------------------- On Thu, 7/24/14, Little, Chris <chris.little@metoffice.gov.uk> wrote: Subject: OGC Temporal DWG. Was: space and time To: "Gannon Dick" <gannon_dick@yahoo.com>, "andrea.perego@jrc.ec.europa.eu" <andrea.perego@jrc.ec.europa.eu>, "frans.knibbe@geodan.nl" <frans.knibbe@geodan.nl>, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, "Chris Beer" <chris@codex.net.au> Cc: "public-locadd@w3.org" <public-locadd@w3.org>, "public-egov-ig@w3.org" <public-egov-ig@w3.org>, "public-lod" <public-lod@w3.org>, "temporal@lists.opengeospatial.org" <temporal@lists.opengeospatial.org>, "Piero Campalani" <cmppri@unife.it>, "Matthias Müller" <matthias_mueller@tu-dresden.de> Date: Thursday, July 24, 2014, 9:36 AM #yiv4303497829 #yiv4303497829 -- .yiv4303497829EmailQuote {margin-left:1pt;padding-left:4pt;border-left:#800000 2px solid;}#yiv4303497829 Dear Colleagues, OGC started a Temporal Domain Working Group last year to address a number of problems in the geospatial domain. In particular, that time is usually just viewed as Yet Another Attribute of Features, rather than a first class coordinate. We agreed earlier this year, in Geneva, that the OGC Naming Authority would have a branch to register Temporal, and index based, Coordinate Reference Systems, and we agreed on the fundamental attributes that a CRS should have to be registered. We hope to produce a Best Practice document this year to help clarify many confusions between CRSs, notations, calendars, operations and calculations. I think that now we have a good enough understanding of the underlying conceptual issues and current geospatial standards. We have been accumulating info on an open wiki http://external.opengeospatial.org/twiki_public/TemporalDWG/WebHome and discussing via our mailing list, though we are not very disciplined about it. One concern that I have is that we do not re-invent the wheel, and do nugatory work, hence this email. I do not envisage that we will need to do much with Calendars, which have been covered so well by Dershowitz and Reingold. Best wishes, Chris Chris Little Co-Chair, OGC Meteorology & Oceanography Domain Working Group Co-Chair, OGC Temporal Domain Working Group IT Fellow - Operational Infrastructures Met Office FitzRoy Road Exeter Devon EX1 3PB United Kingdom Tel: +44(0)1392 886278 Fax: +44(0)1392 885681 Mobile: +44(0)7753 880514 E-mail: chris.little@metoffice.gov.uk http://www.metoffice.gov.uk I am normally at work Tuesday, Wednesday and Thursday each week
Received on Thursday, 14 August 2014 19:42:01 UTC