Looks ok? Maybe on the first sight. But in my opinion, it’s a big mistake.

Let’s first look at the reasons for that change in the URI schema. It aims to provide a solution for semantically ambiguous properties. For example, the word “length” can be used to describe the long dimension of an object, like the length of a bridge. But it can be also used as a synonym for the runtime of a song or movie (like 90 minutes). Now, with only the one URI http://dbpedia.org/ontology/length, it’s unclear whether the range of that property is measured in metres or minutes (let alone inch, feet, and miles ;) ) So in order to properly represent the two different semantics, we need two different URIs. Consensus so far…

Now there are to possible solutions: Either you use two different property IDs (such as length and movie_length), or you use two different namespaces. The DBpedia team chose the latter. The problem is that they did the partitioning for every single property, even those unambiguous ones. And since the DBpedia ontology wasn’t entirely carefully designed upfront, but is instead due to community refinement, that leaves us with URIs that will most probably break in the future.

See for example http://dbpedia.org/ontology/ceo. Its domain is http://dbpedia.org/ontology/SoccerClub, which seems kind of strange, but is due to the way how the ontology was created: The Infobox Soccer Club was probably the only one with a ceo property, so the domain of http://dbpedia.org/ontology/ceo became SoccerClub. Clearly, once the community starts refining the ontology, the domain will be changed to Company or something similar more reasonable. That wouldn’t be much of deal since we’d only see a changed statement about the ceo property. But with the new URI schema, the SoccerClub is part of the property’s URI (http://dbpedia.org/ontology/SoccerClub/ceo). We have a problem…

If we’d change the property URI to http://dbpedia.org/ontology/Company/ceo now, all existing queries will break. If we leave the URI as it is, the encoded SoccerClub becomes misleading. It would have been even better to use http://dbpedia.org/ontology/abc123/ceo instead, since that string doesn’t suppose to have any meaning.

The simple, straightforward solution would have been: use different IDs to disambiguate properties which actually need to be disambiguated. Or to do it like Freebase and partition very carefully by topic…

But it didn’t used to be easy enough to find a DBpedia URI for a given keyword. DBpedia Lookup aims to fill that gap. It provides a service to find the most-likely DBpedia URIs for a given keyword. The algorithm ranks DBpedia resources based on their relevance in Wikipedia and includes synonyms into the underlying Lucene index.

Try the terms “Shakespeare“, “EU“, “Eiffel“, or “Cambridge” and see for yourself if the results you’d expect show up at the top. The result ranking is different – and supposed to be more useful – than a simple full-text search or SPARQL-Query with embedded regular expression for matching labels.

There is a web-service available as well. You can use the KeywordSearch method for searching full terms, and the PrefixSearch method for an autocompletion-style interface such as the one you see here. The webservice returns a list of resource URIs with English abstracts, dbpedia classes and categories.

Feel free to use the service as you like. If you plan to use it in a production system or to run a high-load batch process, please drop me a message to let me know.

I hope that DBpedia Lookup is useful, and I’d appreciate any feedback.

Many thanks to the semantic web folks at the BBC for their support and feedback on the development of DBpedia Lookup.