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

And here is a paper with the detail about that datacube with  a time dimension  and (only point) location.  Note that it also uses the SSN ontology, which also on our work program. Unfortunately  the Data Cube and SSN do not dock together as well as I would like, and I hope that is something we can fix in this group.
In our coverage deliverable, I expect we will be extending this idea to a gridded coverage of space as well, over 2 or maybe 3 spatial dimensions.

http://ceur-ws.org/Vol-904/paper10.pdf



Kerry

From: Jeremy Tandy [mailto:jeremy.tandy@gmail.com]
Sent: Tuesday, 10 March 2015 10:55 PM
To: Bill Roberts
Cc: Bruce Bannerman; Frans Knibbe | Geodan; 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