Re: SPARQL & SemWeb

On Sun, Apr 16, 2006 at 09:52:06AM +0200, Luk Vloemans wrote:
> Hey Christopher, 
> 
> Thanks for your response. Unfortunately, the approximation solution you
> provide (the rectangle box) has a catch: The Lat-Lon grid is not equally
> devided, meaning: 1 degree longitude on the northpole is a few meter, whilst
> on the equator, it could be a few kilometer, so you're not actually drawing
> squares but rectangles. (the latitude range is globally equal).

Ah, so you actually care about distance -- that makes it a whole
different ballgame then :) (Most people know so little about curvature
of the earth that even mentioning it would be confusing.)

> Given this situation, it is at least necessary to goniometrically translate
> the source/dest GPS-coords. This involves mathematical functions as cosinus
> and sinus, and as far as I understand, SparQL does not support those? Does
> it?

I'm relatively certain that SPARQL itself doesn't support it, but that
doesn't neccesarily mean that it would be impossible for you to add this
to some given SPARQL implementation -- I think features like REGEX, etc.
are provided by the implementation, and that you could include these
into a SPARQL query engine -- but you probably wouldn't want to.

In that case, what you would probably want to do is create a bounding
box wide enough to capture all your results, then do secondary
processing to determine the actual distance. So the process would be
something like:

  * Take '500m' input from user
  * Turn 500m into a bounding box containing the area no matter where on
    the globe it is -- this requires some extra query selection
  * Select your data from the database
  * Post-process the data by running a comparison on the actual
    distances -- this is where you bring in curvature of the earth, etc.
    into the equation.

This is actually a relatively common solution: PostGIS querying suggests
this method when using bounding box queries, because selecting from a
geographical index is way slower than a simple comparison index, so you
select a bounding box, then filter that based on the geographical
information. In this case, you're just splitting that work between the
query engine and the rest of the application.

> Another interesting query would be "Give me all pictures I took in city X".
> In order to solve this puzzle, one would have to know the exact spatial data
> of city X (a bounding rectangle would not be enough) and be able to pinpoint
> Lat/Lon within that range, using a RDF-querylanguage... I think that's a
> hard one to answer for.

In this case, again, you'd take your post-processing solution. However,
I think that conflating semweb/GIS databases is a bad idea. Instead,
what I would personally do is take each geo:Point in my crawled
database, store it in a PostGIS database with either the URL or bnode
identifier. You can then submit queries against the PostGIS database for
lat/long queries, and then look up the data in the RDF datastore for the
actual content that you want. 

Damnit, now you're going into a field I'm actually interested in at the
moment, that's not fair at all. I'm supposed to hate RDF! :) [1] Next
thing you know, I'll actually be building an example of this.

Actually, now that I think about it, this sounds a lot like what jo was
heading for with nodel[2]... no idea how far she went though.

[1] http://crschmidt.net/blog/archives/85/exhaustion-with-rdf/
[2] http://map.wirelesslondon.info/docs/nodel-howto.html

-- 
Christopher Schmidt
Web Developer

Received on Sunday, 16 April 2006 12:53:31 UTC