W3C home > Mailing lists > Public > public-egov-ig@w3.org > August 2014

RE: (groan, not again): OGC Temporal DWG. Was: space and time

From: Gannon Dick <gannon_dick@yahoo.com>
Date: Thu, 14 Aug 2014 12:38:34 -0700
Message-ID: <1408045114.24611.YahooMailBasic@web122903.mail.ne1.yahoo.com>
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:41:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:53 UTC