[OSGeo-Standards] link relations for features

[Raj Singh]

I'm forking the discussion to the new subject "link relations for features" to talk only about vector features for a bit. 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. 

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? 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. Here are some other thoughts:
- I don't see how a "next" relation helps with geodata
- I kind of like "near", but don't see how to define it consistently
- 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.

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