[OSGeo-Standards] link relations for features

Rushforth, Peter Peter.Rushforth at NRCan-RNCan.gc.ca
Thu Jul 11 13:36:15 PDT 2013


Yes, I agree, the term "RESTful API" has become code for "our silo to keep your IP tightly bound to our platform".

However, and perhaps not surprisingly, this is actually the antithesis of REST, which seeks to de-couple client and server via the hypermedia format specification.


From: Carl Reed [creed at opengeospatial.org]
Sent: July 11, 2013 3:17 PM
To: Raj Singh; Rushforth, Peter
Cc: standards at lists.osgeo.org
Subject: Re: [OSGeo-Standards] link relations for features

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.



-----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

More information about the Standards mailing list