Re: Time-series spatial data [was: Re: TCGA / Microscopy Imaging Use Case] [SEC=UNCLASSIFIED]

Hi all.

Jeremy will address the time-series spatial data aspects at the face-to-face if required.

Bruce


From: Jeremy Tandy <jeremy.tandy@gmail.com<mailto:jeremy.tandy@gmail.com>>
Date: Tuesday, 10 March 2015 22:54
To: Bill Roberts <bill@swirrl.com<mailto:bill@swirrl.com>>
Cc: Bruce Bannerman <B.Bannerman@bom.gov.au<mailto:B.Bannerman@bom.gov.au>>, Frans Knibbe | Geodan <frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>>, "public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>" <public-sdw-wg@w3..org<mailto:public-sdw-wg@w3.org>>
Subject: Re: Time-series spatial data [was: Re: TCGA / Microscopy Imaging Use Case] [SEC=UNCLASSIFIED]

Hi Bill - all good points. Regarding use of the RDF Data Cube & climate data, folks at the Bureau of Meteorology (who Bruce works for) published one of their ‘gold-standard’ climate datasets (surface air temperature) using a pre-standardised version of the RDF Data Cube. See [ACORN-SAT][1]

Coming from the meteorological domain myself, I’m pretty interested in making sure the “when _and_ where” use case is dealt with. As Bill says, I think that _one resource_ can be described using properties from both _spatial_ and _temporal_ ontologies in order to meet this requirement. (e.g. we don’t need a “spatiotemporal” ontology)

Jeremy

[1]:http://lab.environment.data.gov.au

On 10 Mar 2015, at 11:42, Bill Roberts <bill@swirrl.com<mailto:bill@swirrl.com>> wrote:


"From my perspective in managing climate data, all of our data is time-series spatial data. It is very important to understand the ‘when’ as well as there ‘where’ with respect to the data (together with the data provenance etc)."

Bruce's use case is certainly an important one and we need to make sure we can handle it.  But I think it is still possible to separate out time and location concerns in the sense of vocabularies and data representation patterns. For a particular data point (or event or whatever), an approach like RDF Data Cube, or similar n-ary relationship, can link the data point to the appropriate location and time.


So (as I see it) the location specification itself does not need to incorporate a concept of time in this case, but rather each data point needs to connect both to a location and a time period.  Let me know Bruce if I am missing something important here!


(A separate issue is where a location named by an identifier might change it's definition over time - eg 'London' is bigger now than it was a hundred years ago).


Cheers

Bill