RE: A proposal for two additional properties for LOCN

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 11:54:28 UTC