- 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