RE: SPARQL & SemWeb

-------- Original Message --------
> From: Christopher Schmidt <>
> Date: 16 April 2006 13:53
> 
> 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


What SPARQL does provide is extension functions.  You could define your
operations as a collection of extension functions (an extension function
can return a value or be used a filter itself):

So things like:

FILTER ( myMath:sin(?x) < 0.5 )
FILTER ( myGeoLib:distance(?x, ?y) < 100 )

Given this, you may be able to add bounding box support for filter
expressions.

	Andy

Received on Tuesday, 18 April 2006 12:52:24 UTC