RE: A proposal for two additional properties for LOCN

Whoa, Simon. That "tension" is very profitable for the data supply business.

It looks like "Open World" in CSV, if you are willing to misunderstand "Open World".
Spreadsheets are numbered starting with column "A" which ignores the "real" first cloumn, a two character zero-width joiner the Unicode folks call a Byte Order Mark (BOM).  If you imagine that a DOMain (pivot matrix) has a BOM in the first column then adding a column (Property) is something different from adding a row (a domain component or instance document).  The fundimental theorem of XML="DOMs need BOMs" 

Cheers,
Gannon
--------------------------------------------
On Thu, 9/11/14, Simon.Cox@csiro.au <Simon.Cox@csiro.au> wrote:

 Subject: RE: A proposal for two additional properties for LOCN
 To: mail@makxdekkers.com, andrea.perego@jrc.ec.europa.eu, frans.knibbe@geodan.nl
 Cc: ocorcho@fi.upm.es, public-locadd@w3.org
 Date: Thursday, September 11, 2014, 6:14 PM
 
 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 Friday, 12 September 2014 17:42:45 UTC