I wrote a bit about how I imported it over this way: http://cruncht.com/361/uriverse-dbpedia-drupal-case-study/

It was a labour of love which took a lot of SQL hacking to get to work. I could not afford to do node_loads and node_saves for 13M nodes so I opted to do the DB inserts directly. That way I could get 1000s of inserts a second rather than 10. I learnt a lot about MySQL, indexes, efficient queries and how to import stuff as quickly as possible. Also, how to recover from where you left off when a long running process died. All up it took a couple of months of tooling around with code and SQL. Once all of it was in it took another couple of months for Solr to index it all

I wouldn’t recommend this approach as it is a one hit import which takes a lot of effort.

If you have a smaller dataset then you have a few options.

Firstly, the migrate module couple be a good way to go if you have complex relationships and IDs to maintain. I really want to get into this big time one of these days. Imports will still be slow but you have the most flexibility.

Secondly, you have the feeds module. Good if you have a flat data structure and one to one mappings. You might be able to get away with crafting up a CSV and importing that way. I believe that Lin Clark has some good screencasts with Feeds and SPARQL (IIRC). Theres a lot of flexibility in Feeds too so this might be an easier option for you if you like wiring up config instead of writing code.

Thirdly, you can go old school and just write your own PHP script and do it with node_saves. Fire it up with “drush scr”. I like this approach because it feels natural to me. However, Migrate gives you a lot of nice goodies such as rollback, tracking IDs and making stub objects which will save you from pulling your hair out.

Finally, you have SQL inserts if you are handling a very big dataset. This will be more tedious now because of the way fields is handled. ie. a lot more inserts over more tables. You’ll get to know Drupal’s schema well though.

Oh yeah – another option is to just keep Dbpedia in a triple store and then provide a view onto that. That way you have more chance of keeping up with updates from Dbpedia. It isn’t updated that often though.

You may also want to take a look at Freebase. They have a nice API, up to date data and links to Dbpedia as well. You might consider importing from there using the search, image, mql etc apis. I’ve been doing a bit of that lately and it is quite pleasant.

All the best with it.

I am interested in learning more about how you imported DBPedia into Drupal. I am attempting something similar for a small subset of Wikipedia – but using Drupal 7.