[OSGeo-Standards] link relations for features

[Rushforth, Peter]

> I 
> don't mind being at the code level for features, because I 
> think we're ready for that. I just thought the coverages 
> discussion still needs to be on a conceptual level. 

Well I was looking at the wiki page regarding wcs 2.0 that Peter
pointed to earlier, and I could see a number of ways to look
at that from a REST perspective that aren't too far afield from
the discussion of features.  Certainly nothing on that page
currently qualifies the proposed service as RESTful, IMHO.

> 
> I agree with everything you write below, but I don't think 
> "east" is a useful relation. Half the world is east of any 
> given feature, right? 

If you don't have such a relation, how does the client know how
to pan?  (Hint: you can't tell me what the URI looks like).

> I like topological relationships: 
> "within", "adjacent", "crosses", etc., but I think we need 
> more than those, but we also need to avoid the slippery slope 
> of moving into the semantic linked data arena. 

The slippery slope to the Fetid Swamps of Unaddressable Names....

> Here are some 
> other thoughts:
> - I don't see how a "next" relation helps with geodata

That's easy.  If a FeatureCollection has 1,000,000 
features in it, do you want to try to parse the whole thing in
one request/response? OK, how about another zero?  Maybe you do,
but you shouldn't *have to*.  That is what gives GML a bad name,
IMHO.  Sorry Ron.

> - I kind of like "near", but don't see how to define it consistently

It's a good one, I agree.  It should be useful in some situations, 
perhaps a radius search, or equal walking distance search
etc.


> - I like the idea of using a standard way of gridding up the 
> world so that our feature collections can be all features in 
> the grid cell, and you can use a "next" relation within the 
> grid cell. The grid gives us a standard way of linking across 
> data sets also.

The "world" is also a resource.  Maybe it is *the* resource in geo,
and representations of it contain links to sub-resources, all with
geospatial (among perhaps other) representations available.

A grid cell in a standard tile pyramid can then be a sub-representation
of the world.  It can have a represnetation as image/png or application/road+xml,
or for the kook kids among us, application/road+json etc.





> 
> On Jul 11, at 2:15 PM, "Rushforth, Peter" 
> <Peter.Rushforth at NRCan-RNCan.gc.ca> wrote:
> 
> >> 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
> 
>