Re: Beginnings of a draft report

Since I just have two comments in the Word doc, I just copy them here 
for easier discussability etc.

# 2nd paragraph of "Purpose":

A coverage is not just a grid. This is just the most common type. 
There’s also trajectories (measurements along a ship track e.g.), or 
point clouds, polygons … Grids are just a very common type. You can even 
have an infinite number of data points by representing a coverage as a 
formula from lat/lon to measurement value (not common, but interpolation 
would create such a thing, which you can then store again as a fixed 
grid for convenience).

Suggestion:
"A ‘Coverage’ assigns data values to a set of positions in space and/or 
time. A common type of structuring positions is using spatiotemporal 
grids. Satellite based earth observation imagery are an example of this 
since they comprise a simple grid of pixels, the value of which is 
represented for humans as a colour. The coordinates for each pixel in 
the image are typically stored as metadata next to the image. The values 
in each cell in the grid may represent human visible colours but can 
also represent things like sea state, temperature, albedo, ice depth, 
barometric pressure etc. Especially model based computed grids are often 
4 dimensional with a time and height dimension. Apart from structured 
grids, another common type of coverages are measurements from sensors 
like weather stations, typically at a fixed location measured over time. "

I don’t really understand the last sentence: “When represented in a 
Coverage, it may also include spatio-temporal links between different 
data items, perhaps across different EO datasets.” What exactly is this 
talking about? An example would be good. If you really mean linking a 
dataset to another dataset, then this may be at an upper level than 
coverages themselves (at DCAT level?). If you mean annotating a part of 
a coverage, then this probably also belongs to an upper level. I’m 
pretty sure this is not common practice yet if this is what you’re 
talking about.

# "Enabling Access and Delivery"

This is about the sentence "Hierarchical structures can also be 
described as links between different granularity/resolutions of the data 
as well as links that describe spatial and temporal relations between 
different data items in a data grid and/or a larger data collection."

What is granularity/resolution referring to in terms of the REST API? 
It’s not part of anything we/I developed so far. This is not subsetting!
Also, the other part about relations between data items in a grid is not 
clear what you really want to say. Can you explain that? Then I can 
suggest some text for that.

Cheers
Maik


Am 02.02.2016 um 16:38 schrieb Phil Archer:
> Thanks Payam,
>
> Ed made some comments in a Google doc and I've incorporated his and 
> your comments in the attached version.
>
> I'd rather be using GH for this but I'm not sure whether that would 
> suit all members of this group so I'm being cautious for now and just 
> using Word - I hope it doesn't crash on you again.
>
> Phil.
>
> On 31/01/2016 23:42, p.barnaghi@surrey.ac.uk wrote:
>> Hi Phil,
>>
>> Please find attached a copy of the document with some minor comments;
>> My MS Word crashed the first time and I lost all my changes; I tried 
>> to remember some of what I had written the 2nd time round.
>>
>> Best regards,
>> Payam
>>
>>
>> ________________________________________
>> From: Phil Archer <phila@w3.org>
>> Sent: 29 January 2016 17:41
>> To: public-ceo-ld@w3.org
>> Subject: Beginnings of a draft report
>>
>> Dear all,
>>
>> In an effort to show progress and to ensure that our meeting in Beijing
>> on 28 February is as productive as possible, I have made a tentative
>> start on the document that I hope will evolve into our final report
>> (attached*).
>>
>> It begins by re-stating some of the stuff from our initial meeting as
>> captured in the report [1] and then makes a quick summary of the work
>> Maik has been doing in Reading.
>>
>> @Maik - from an inexpert and all too quick review of your Coverage Data
>> REST API Core Specification [2] it seems to me that you have already
>> answered a lot of our key questions. I have added some questions to the
>> doc that I suggest we can look at - I'd be delighted if there are ready
>> answers to some or all of them and would be surprised if there weren't
>> more that can be added.
>>
>> I am aware that this work has been done in one specific context and that
>> it is crucial, of course, to see how this works in the contexts in which
>> our Chinese colleagues work.
>>
>> @Maik - what is your/Reading/MELODIES' plan for this doc and its
>> companions? Are you looking for it to become a formal standard? If so,
>> we seem well placed to help ;-) You define some relationship types. The
>> next iteration of the BP doc that Jeremy is co-editing will, I think,
>> include the standard spatial and temporal relationships and, via that
>> route, can be added to the Link Registry.
>>
>> I am painfully aware that as I write, China is shutting up shop ready
>> for the Spring Festival. Beihang is now closed until 17th February and I
>> imagine that will be the case for CAS as well.
>>
>> Comments, questions and additions to the doc please.
>>
>> Thanks
>>
>> Phil
>>
>>
>> * I considered doing this on GitHub or Google Docs but, for now at
>> least, a Word doc seems most likely to most convenient to the greatest
>> number of people. But I do hope we can move to an online shared space
>> quickly as passing round Word docs is a recipe for extra workload.
>>
>> [1] https://www.w3.org/2015/ceo-ld/kom
>>
>> [2]
>> https://github.com/Reading-eScience-Centre/coverage-restapi/blob/master/spec.md#coverage-data-rest-api-core-specification 
>>
>>
>> -- 
>>
>>
>> Phil Archer
>> W3C Data Activity Lead
>> http://www.w3.org/2013/data/
>>
>> http://philarcher.org
>> +44 (0)7887 767755
>> @philarcher1
>>
>