[OSGeo-Standards] link relations for features

[Carl Reed]

This is a really good conversation. This discussion got me thinking about 
time and time series data - really important in many geo-domains. So I did a 
bit of searching. There are numerous RESTful APIs out there (open source, 
commercial open source, commercial) for time series data. So I looked more 
closely. Each API was different, used their own ID system for a time series, 
different metadata, different this and that, and each with their own data 
store. Nothing interoperable there!

Which is why this discussion is good. My sense is that everyone/organization 
is developing their own RESTful APIs for their stacks. A bunch of silos. 
>From a standards perspective, them, we do need standard relations, keywords, 
query patterns, and so forth. This gets back to defining best practices for 
defining consistent and harmonized geo REST APIs. Along the lines that Peter 
B and the WCS SWG has been doing for coverages.

Cheers

Carl




-----Original Message----- 
From: Raj Singh
Sent: Thursday, July 11, 2013 12:45 PM
To: Rushforth, Peter
Cc: standards at lists.osgeo.org
Subject: [OSGeo-Standards] link relations for features

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

_______________________________________________
Standards mailing list
Standards at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/standards