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 <http://lab.environment.data.gov.au/> 

> On 10 Mar 2015, at 11:42, Bill Roberts <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
>