Re: URIs for great circle arcs

Neat implementation, I like the idea a lot!

One directed-towards-Toby thought, and another more meandering one for the
group, if I may :)

First off - the whole "infinite set of points" Container is a tough one to
swallow, without nasty URI-hacking to suggest a resolution for how many
points you want to see, etc. I wonder if there's a neat Linked-Data way of
doing this, to make it browseable. For example, how about describing those
points in terms of the arcs that connect them (caveat: I know
little-to-nothing about geodesic arcs!) So, what I'm imagining is that you
can describe the arc from A to B via C in terms of the arc from A to C and
the arc from C to B, recursively. In this way you can build up a greater
resolution of points on the arc without having to URI-hack your way to the
solution. Would this even work in this domain?

More generally, I'm intrigued by the notion of the slight mix of services
you're offering here. On the one hand is a really-quite-cool "linked data
great circle arc" service. On the other, there's the ability for the user of
the service to essentially perform a mesh-up (or is this a mash-up? I get
confused ;)) of this data with any other service. Are these safe to mix? Is
it desirable to let the user "puppet" my mouth to say anything they wish?

I'd have imagined (from a provenance and trust perspective) it would be
safer and more web-of-data-y to offer linked data URIs for the points you
describe, and let the downstream service (be it a user agent, another LD
service, or a more traditional web server) perform the smushing of data;
i.e. if it wants to assert (through its own trust system) that (URI here not
prescriptive, just an example!)

<;-0.128056> owl:sameAs <>

should that perhaps be its own decision to make, rather than
a) Some other service that has handed it a URI with this data encoded, or
b) Something it has itself inserted into your existing arc URI to make it
look like "you" (the arc server) asserted that fact

Does that kinda make sense? I'm just not certain, ottomh what downstream
users gain by adding that capability to *any* service (this isn't limited to
the arc case by a long shot!).

What do others think? Am I being naively purist, would features like this
enrich the LD web? Or are they too easy to abuse, potentially weakening the
trust we can place in services that offer them?


On Sun, Jun 21, 2009 at 10:45 AM, Toby A Inkster <> wrote:

> Great circle arcs are the shortest surface paths between two points on a
> spherical body. I've minted some URIs (and am serving up RDF/XML) for great
> circle arcs on the surface of the Earth. Amongst other things, the RDF/XML
> returned will tell you the distance between the points, the compass bearing
> and the midpoint.
> For example, the arc between London and Tokyo is represented as:
> <;-0.128056/35.683333;139.766667>
> which is a geo:SpatialThing. There is also:
> <
> 51.507778;-0.128056/35.683333;139.766667#points>
> which is an rdfs:Container representing the (infinite) set of all points
> between the two endpoints of the line.
> An additional feature is the ability to link to URIs representing the
> endpoints. e.g.:
> <
> 51.507778;-0.128056/35.683333;139.766667?uri1=
> resource/London&uri2=>
> The document you get returned still has a primaryTopic of
> <;-0.128056/35.683333;139.766667>
> (i.e. it doesn't alter the linked data URI) but now contains explicit
> dbpedia references for the end points. Those URIs don't have to be from
> dbpedia - they could be anything - they're not used in calculations of
> distances, etc - just included in the output.
> Possible uses: flight and travel linked data.
> Any ideas for improvements?
> --
> Toby A Inkster
> <>
> <>

Received on Monday, 22 June 2009 08:53:03 UTC