Re: A proposal for two additional properties for LOCN

On 2014-09-12 1:14, Simon.Cox@csiro.au wrote:
> 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.
It is interesting to note that the fairly new Temporal Domain Working 
Group (DWG) has been formed in the OGC: 
http://www.opengeospatial.org/projects/groups/temporaldwg. If anything, 
it shows that time is important in the geospatial world.

I think a related problem here is the closed world assumption in the 
OGC: all real world phenomena need to be expressed in terms of 
geographical models (ISO191**, GML,..). That is why the corpus of things 
modelled by the OGC keeps growing and growing, and why it involves many 
things that are not directly related to geography. In a model that 
assumes an open world (like Linked Data) it is easier to use concepts 
external to the domain.

Once the new W3C-OGC working group gets under way, hopefully theories 
and practices about time in geoinformatics will find some more focus.

>
> 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?
Well, I think WKT is great!  But yes, one does need a CRS to go along 
with it. It is probably easier to accept a global reference system for 
time because time is governed by cosmological processes. Location on 
Earth is influenced by plate tectonics, which robs us of the option of 
using one global reference system.

Regards,
Frans

>
> 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.
>


------------------------------------------------------------------------
Frans Knibbe
Geodan
President Kennedylaan 1
1079 MB Amsterdam (NL)

T +31 (0)20 - 5711 347
E frans.knibbe@geodan.nl
www.geodan.nl <http://www.geodan.nl> | disclaimer 
<http://www.geodan.nl/disclaimer>
------------------------------------------------------------------------