[OSGeo-Standards] Was: "file" formats. Is: GeoWeb

[Rushforth, Peter]

Hi Raj,


> I think the 
> biggest problem I have with designing RESTful resources 
> around coverage data is the fact that most coverages 
> represent natural phenomena that vary continuously across the 
> earth's surface (or atmosphere, or sub-surface). This means 
> that the actual cell values are only approximations of what 
> is expected to be observed in nature. 

Can a coverage be tiled?  Can you reproduce a coverage data structure by
re-assembling tiles?


> This is why I have a 
> hard time calling anything a resource other than the full coverage. 

But, a FeatureCollection is also a Feature, right?  A collection
can have in principle an unlimited number of features.   A representation
is just that: a representation of the resource.  Not the whole thing, necessarily.
Not the beginning of it, nor the end of it necessarily.  If one
can figure out how to provide access to a part of a resource,
and potentially link to other parts of it e.g. link at rel="next".

> 
> In contrast to coverages, I think features and sensor 
> observations (a specialized type of feature) should be much 
> easier. The resource is the feature. 

Well, not only is a feature a nice resource, but a tile is equally a resource,
which can be represented as collection of features, and not necessarily in
one response, either.  


> But the million dollar 
> question is, what are the appropriate links between features? 

I think that's up to the data modeller, right?  But, per the Web Arch
recommendation, we should think about links as relationships, not as APIs.

> I think Peter Rushforth is saying don't worry about it -- let 
> each service implementer design their own link structure. 

I agree that it needs to be *possible* to retrieve what is referred to, 
but I can imagine that how that retrieval is effected will be different
on different servers and server data structures, and the 'how' will be
reflected in the URL structure.  So spelling out a standard
formula for that structure constrains clients to work with that instead of
working with the representation (format).  That is the problem with OGC
specs relative to Web architecture.

> To 
> that I say, maybe so, but show me some good strategies and 
> maybe we can design some common best practices from there...


Allan Doyle came up with a zinger way back on geo-web-rest:

<link rel="east" href="..." type="application/coverage+xml"/>

I can think of a couple of ways to implement that @href value.  Maybe spatial
folks say "We don't need to be told what east is, we know that already",
but in so saying, you are reversing the contract, you're telling the
server that it has to respect the URL you've coded to.  Let the server
tell the client what the URL to the east is, and all of a sudden you've got REST!

Sorry if this takes it back to the "code" level, but that is where the
action is in hypermedia.  At least it's declarative :-).

Does that make sense?

Cheers,
Peter