RE: A proposal for two additional properties for LOCN

Sounds good to me.  "An interval is a discrete Fourier Transform, not a meridional shift" might be another way of saying it.  When you are ready to tackle the "Local Solar Time" stuff, let me know and I'll show you how to turn the [New Year's <- Winter Solstice] "shift" into a lag (in the meantime statisticians are encouraged to stay away from their Standard Deviation of the Mean Buttons unless they've thought it through).  --Gannon
--------------------------------------------
On Wed, 9/24/14, Little, Chris <chris.little@metoffice.gov.uk> wrote:

 Subject: RE: A proposal for two additional properties for LOCN
 To: "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, "mail@makxdekkers.com" <mail@makxdekkers.com>, "andrea.perego@jrc.ec.europa.eu" <andrea.perego@jrc.ec.europa.eu>, "frans.knibbe@geodan.nl" <frans.knibbe@geodan.nl>
 Cc: "ocorcho@fi.upm.es" <ocorcho@fi.upm.es>, "public-locadd@w3.org" <public-locadd@w3.org>
 Date: Wednesday, September 24, 2014, 6:53 AM
 
 Simon and Colleagues,
 
 I hope I do not confuse an
 already long thread, but the OGC Temporal Domain WG, which I
 chair, is converging on a Best Practice that is along the
 lines of "A calendar is not a CRS", and vice
 versa. 
 
 In particular,
 ISO8601 is a "Notation" for both calendars and
 CRSs, and timescales (in the sense that the atomic time
 people, BIPM TAI, talk about it). The ISO8601 standard is
 actually a few things rolled up together: in particular
 notation and the Gregorian calendar definition, which
 contributes to confusion and bad or sloppy practice.
 
 We like the approach of
 clarifying the confusion by talking of temporal
 "Regimes". There are 4: 
 1.
 Events/Allen operators/no clock, no instants, no durations;
 
 2. Timescale, clock, ordinal integer
 arithmetic, instants and durations; 
 3. CRS,
 normal real arithmetic, continuous number line, instants and
 durations; 
 4. Calendars, algorithms,
 non-normal arithmetic and usual panoply of time stuff.
 
 ISO8601 notation can be used
 across 2,3,4.
 
 There is some
 well founded mathematical underpinning. Local solar time etc
 to be done later.
 
 HTH,
 Chris 
 
 
 Chris Little
 Co-Chair, OGC
 Meteorology & Oceanography 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
 
 
 
   
 
 -----Original Message-----
 From: Simon.Cox@csiro.au
 [mailto:Simon.Cox@csiro.au]
 
 Sent: Friday, September 12, 2014 12:14
 AM
 To: mail@makxdekkers.com;
 andrea.perego@jrc.ec.europa.eu;
 frans.knibbe@geodan.nl
 Cc: ocorcho@fi.upm.es;
 public-locadd@w3.org
 Subject: RE: A proposal for two additional
 properties for LOCN
 
 Ah yes
 - but there is a long-standing tension in geospatial as to
 whether time is just another dimension, or something
 different. Both views are defensible - it mostly depends on
 use-case. 
 
 Then there is
 the irony that while most are perfectly willing to accept a
 microformat for time (ISO 8601 and derivatives) they baulk
 at similar for space (e.g. WKT). Major problem in space is
 that you need the CRS as well as the coordinates, which
 brings us back to ... is time another coordinate? 
 
 Simon
 
 -----Original Message-----
 From: Makx Dekkers [mailto:mail@makxdekkers.com]
 Sent: Thursday, 11 September 2014 5:46 PM
 To: 'Andrea Perego'; 'Frans Knibbe
 | Geodan'
 Cc: Cox, Simon (L&W,
 Highett); 'Oscar Corcho'; 'LocAdd W3C CG Public
 Mailing list'
 Subject: RE: A proposal
 for two additional properties for LOCN
 
 > 
 > Probably (but Makx
 can correct me if I'm wrong) the point was that, in 
 > that point in time, DC terms were used
 just with literals, and not 
 > with class
 instances. In our case, the question is whether processing
 
 > would better be done at property level
 (:resolution vs
 > :spatialResolution) or
 rather at class level (:QuantityValue).
 >
 
 
 Yes, in fact, if you get a
 string value in dc:coverage, there is no way to know whether
 it indicates time or place. If the string is encoded as DCMI
 Point or DCMI Period, you can but the usage of those
 encodings is not mandatory.
 
 In a linked data approach it is slightly better
 because you can figure it out by resolving the Object URI
 and seeing what type/class the identified resource is, but
 that requires extra work.
 
 The fundamental problem as I remember was that
 people thought it was not really a good idea to have ranges
 that contained "or" joining different things:
 classes CatOrDog, StarSystemOrMolecule etc. might be of some
 use to someone, but it was thought that it would be better
 on the general level to define the classes like Cat, Dog,
 StarSystem, Molecule separately and then create joins when
 you really need them.
 
 Makx.

Received on Wednesday, 24 September 2014 21:43:07 UTC