Question

I started teaching myself SPARQL yesterday, and I’m practicing against dbpedia. I’m trying to retrieve a list of all footballers who have played in two clubs near to the specified destinations (i.e. Swansea and Oxford). I have the following query, which works but is very slow:

SELECT ?player ?team ?team2
WHERE
{
  :Swansea geo:geometry ?point1_1 .
  ?team dbpedia-owl:ground ?ground .
  ?ground geo:geometry ?point1_2 .  
  FILTER (bif:st_distance( ?point1_1, ?point1_2) < 5)
  ?player dbpedia2:clubs ?team .

  :Oxford geo:geometry ?point2_1 .
  ?team2 dbpedia-owl:ground ?ground2 .
  ?ground2 geo:geometry ?point2_2 .
  FILTER (bif:st_distance( ?point2_1, ?point2_2) < 5)
  ?player dbpedia2:clubs ?team2 .
}

My problem is that the query often times-out when run on dbpedia’s query page (see http://tinyurl.com/d9pkluq). Is there any way to optimise this query? If I enter more towns, or specify a larger radius to search, I would still want it to run without timing-out in dbpedia’s query page.

Thanks for any help you can provide!

Answer 1

Your query is a perfectly valid one, and in an ideal world, the SPARQL query engine that processes your query would run in in the optimal way. However, many SPARQL implementations haven’t got that good query optimisers yet so you often have to optimise the query yourself. Typically you do this by re-ordering parts of the query.

One common technique is to try to order the graph patterns in your query so that the number of query results is reduced as soon as possible. Bear in mind that each graph pattern will be run against each and every match of previous patterns. You can think of your query as a series of nested loops; you want to avoid doing a lot of operations in the inner loops.

In your query example, you could for example reorder it as follows:

SELECT ?player ?team ?team2
WHERE
{
  :Swansea geo:geometry ?point1_1 .
  ?team dbpedia-owl:ground ?ground .
  ?ground geo:geometry ?point1_2 .  
  FILTER (bif:st_distance( ?point1_1, ?point1_2) < 5)
  ?player dbpedia2:clubs ?team .

  ?player dbpedia2:clubs ?team2 .
  FILTER(?team != ?team2)

  :Oxford geo:geometry ?point2_1 .
  ?team2 dbpedia-owl:ground ?ground2 .
  ?ground2 geo:geometry ?point2_2 .
  FILTER (bif:st_distance( ?point2_1, ?point2_2) < 5)
}

So, instead of looking for another town and a potentially very large number of combinations of towns, clubs and players, limit the choice of second teams you look at by constraining it to only ones that “interesting” players have played for. I’ve also added a check to avoid it matching the same team for ?team and ?team2.

I can’t say for sure if this will make things better in your case, this depends very much on the exact DBPedia endpoint you’re running against. But this is the sort of optimisations you can experiment with.