SPARQL handling of DBPedia city redirects - sparql

Question

This SPARQL statement works:
PREFIX s: <http://dbpedia.org/resource/Del_Mar,_California>
PREFIX dbp: <http://dbpedia.org/property/>
PREFIX dbo: <http://dbpedia.org/ontology/>
SELECT * WHERE {
OPTIONAL { s: dbp:officialName ?officialName . }
OPTIONAL { s: dbp:name ?foaf_name . }
#-- ... [ about 20 more lines like the above ] ...
} LIMIT 2;
But some cities have redirect. For instance, Pacific_Beach,_California redirects to Pacific_Beach,_San_Diego. How can I handle this?
I've read Joshua Taylor's answer to Retrieving dbpedia-owl:type value of resource with dbpedia-owl:wikiPageRedirect value?, and I wonder if my s: prefix is messing me up here? I can't seem to implement his solution of:
select ?type where {
dbpedia:Cupertino dbpedia-owl:wikiPageRedirects*/dbpedia-owl:type ?type
}
Some other resources suggest using a union:
sparql using wikiPageRedirects
Using SPARQL to find the right DBpedia URI
Reading the Wikibooks chapter, XQuery/DBpedia with SPARQL - Football teams leaves me even more confused.
I am trying to learn this stuff, but I do have an immediate need to "just make it work". A solution and some links to read would be appreciated!

Answer 1

Pacific Beach, San Diego doesn't redirect to anything, but it is the redirect target of a number of resources:
is dbo:wikiPageRedirects of
dbr:Pacific_Beach,_CA
dbr:Pacific_Beach,_California
dbr:Pacific_Beach,_San_Diego,_CA
dbr:Pacific_Beach,_San_Diego,_California
dbr:Pacific_Beach,_San_Diego_California
That means that a modified version of your query should work just fine:
PREFIX s: <http://dbpedia.org/resource/Pacific_Beach,_San_Diego>
PREFIX dbp: <http://dbpedia.org/property/>
PREFIX dbo: <http://dbpedia.org/ontology/>
SELECT * WHERE {
OPTIONAL { s: dbp:officialName ?officialName . }
OPTIONAL { s: dbp:name ?foaf_name . }
#-- ... [ about 20 more lines like the above ] ...
} LIMIT 2
SPARQL results
Note that using prefix to abbreviate a single IRI is sort of unusual. It would be more common to use a values block to bind a specific variable, that you can use in the rest of your query. That is, I would write that query as:
PREFIX dbp: <http://dbpedia.org/property/>
PREFIX dbo: <http://dbpedia.org/ontology/>
SELECT * WHERE {
values ?s { <http://dbpedia.org/resource/Pacific_Beach,_San_Diego> }
OPTIONAL { ?s dbp:officialName ?officialName . }
OPTIONAL { ?s dbp:name ?foaf_name . }
#-- ... [ about 20 more lines like the above ] ...
} LIMIT 2;
That has the advantage that if you want to search values for additional cities, you can just add them to the list of values. Now, if you want to add a value that redirects to something else, that's not a problem. You'd just want to add a non-optional pattern that helps you follow to the redirect targets:
SELECT * WHERE {
values ?x { <http://dbpedia.org/resource/Pacific_Beach,_California> }
?x dbo:wikiPageRedirects* ?s .
OPTIONAL { ?s dbp:officialName ?officialName . }
OPTIONAL { ?s dbp:name ?foaf_name . }
#-- ... [ about 20 more lines like the above ] ...
} LIMIT 2
SPARQL results
As a final note, do be careful that if you're copying and pasting URIs from the browser that you make sure to use the right URI in the query. When you visit a DBpedia resource, e.g., http://dbpedia.org/resource/foo in the browser, you're redirected to the human readable form http://dbpedia.org/page/foo in the browser. That's just a quirk of DBpedia. (Really, they should use content-type negotiation and just return an HTML document for the former when a web browser is making the request.)

Answer 2

I'd suggest taking another look at "this answer from Joshua Taylor". One of the suggestions is to use SPARQL to inspect the data. So try this query:
SELECT * WHERE {
<http://dbpedia.org/resource/Pacific_Beach,_California> ?p ?o
}
This give you all of the data available for the URI <http://dbpedia.org/resource/Pacific_Beach,_San_Diego>. Note that in this case it does not include a dbpedia-owl:wikiPageRedirects property. It appears that the redirect is internal to the DBPedia browser and not included in the DBPedia data.
Using the aforementioned query will help you find what is actually in the data (nothing very interesting in this case).