- From: Peter Coetzee <peter@coetzee.org>
- Date: Mon, 22 Jun 2009 08:52:45 +0100
- To: Toby A Inkster <tai@g5n.co.uk>
- Cc: Linked Data community <public-lod@w3.org>
- Message-ID: <94dd97c40906220052i1fb9f0cfua1f3b8fa534ca7df@mail.gmail.com>
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!) <http://ontologi.es/point/51.507778;-0.128056> owl:sameAs < http://dbpedia.org/resource/London> 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? Cheers, Peter On Sun, Jun 21, 2009 at 10:45 AM, Toby A Inkster <tai@g5n.co.uk> 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: > > <http://ontologi.es/place/arc/51.507778;-0.128056/35.683333;139.766667> > > which is a geo:SpatialThing. There is also: > > <http://ontologi.es/place/arc/ > 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.: > > <http://ontologi.es/place/arc/ > 51.507778;-0.128056/35.683333;139.766667?uri1=http://dbpedia.org/ > resource/London&uri2=http://dbpedia.org/resource/Tokyo> > > The document you get returned still has a primaryTopic of > > <http://ontologi.es/place/arc/51.507778;-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 > <mailto:mail@tobyinkster.co.uk> > <http://tobyinkster.co.uk> > > > > >
Received on Monday, 22 June 2009 08:53:03 UTC