Extracting geographic data from Wikipedia
CC Attribution 3.0 Germany:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Mueller, Hal
A large fraction of Wikipedia's millions of articles include geographic references. This makes Wikipedia a potentially rich source for themed, curated geographic datasets. But the free form nature of Wikipedia's markup language presents some technical challenges. I'll walk through the Wikipedia API, show how to get to the various places where spatial info might be found, and show some blind alleys I've followed. Examples are from a project that uses Wikipedia to enhance a map-based iOS app of some US National Park Service data.
 Well, good afternoon, everybody. Thanks for coming in. My name's Hal Mueller. I'm a one-man software shop up in Seattle. Most of what I have been working on the last few years has been iOS and Mac software. I keep one foot in the open source world. And what I'm going to talk to you today about is some geographic data production that I went through for an application of mine, History Pointer, which is an iOS app, an iOS mapping app with particular focus. History Pointer is a portable version of the National Register of Historic Places, which is a data set of about 100,000 properties in districts. It's a database that's administered by the National Park Service. It contains all kinds of cool stuff. I mean, it has old buildings, factories, historic districts. Maybe there'll be commercial buildings, a building associated with a particular person, maybe their birthplace, their place they died, a place where the Civil War ended, maybe a particular architect. If you wander around just in Portland with this application, you're going to see lots of really cool commercial buildings. There's a Minuteman II missile silo in the National Register. And there's also the houseware home on the range was composed. So it's a pretty diverse data set. It's not, in my experience, been a real friendly data set to work with because it was originated starting back in the 60s when we weren't really doing GIS yet. We weren't really doing any geographic information. So my original idea when I started working on this project or when I started working on the second version was to link to Wikipedia in order to get some richer information. So if you look at the Broadway Bridge, which is just off our balcony here, the original nomination information, the original history information, is not available at the National Park Services website. It's a pile of paper that hasn't been scanned yet. But I was able to link to Wikipedia so you can find out a little bit about the Broadway Bridge. So when we get over to the geographic data side, we have some problems. The data set is inherently noisy. It's outdated. I can go home to Seattle and I can find out that the USS Missouri is supposedly moored right across the water in Bremerton. Well, actually, that's where the Missouri was when she was entered into the National Historic Register, but she's now over in Honolulu and has been there for some time. But this is not a data set that the Park Services funded to maintain. It's certainly not funded to maintain current information. Sometimes it was just entered wrong. Sometimes there was a typographical error. And then some of these descriptions are just inherently really, really hard to geocode. And there's the last one there. If I had a map, I couldn't find it. County Road 326 between Delaware 12 and County Road 83, Duck Creek 100. Good luck. But what I have found is that the Wikipedia people really care deeply about the articles they're writing. And so what I've been trying to do is pull the relevant geographic data out of the Wikipedia article. So here we are in the convention center. And we can find out information about the Portland, which is the tug more up the river, and then go straight to the Wikipedia article. And also, I've managed to georeference the Portland, which again, is a ship. The location they have in the original database for the Portland is not correct. If we look at this Wikipedia article, I don't know how many normal people actually look closely at a Wikipedia article. It was not something I had ever done until I started this project. But there is quite a bit of pre-rigorous structure. In addition to the plain text, there are numerous info boxes. An info box in Wikipedia is software driven. You'll put in certain keywords with values. And then the Wikipedia renderer will present the information based on the requirements in the info box template and also based on the key values in the info box. So if you look here, we have, in fact, a standard information box for National Historic Register Properties, which gives us the location, often the coordinates, significant years. It was the governing body when it was admitted. And this catalog number, that 9,700, 0847, which is its unique identifier within the National Register. So what I'd like to do is a couple of things. First, I want to link the relevant Wikipedia articles to the appropriate National Register properties. Because if I've done that much, now I've enriched my product. I've gotten a nice Wikipedia description for the property. And then I also would like to pull out the coordinates if they're available. So the coordinates are embedded in this Wikipedia markup. And it looks like it ought to be pretty straightforward to pull out. And it wasn't always straightforward, but it worked out pretty well. So Wikipedia URLs have several forms. There's the normal Wikipedia URL, which you would type in. Most of us, frankly, aren't going to type in a URL. We're going to hit the home page, and we're going to hit a search box, or we'll do a Google search or something. But this first URL, that's the normal top-level reference for an article. But then there's also a more specific reference, which is that article URL with an ID appended to it. So now what I've done is I've identified the article on the steam tug Portland, and a particular revision. So if you all go out now and tour the Portland and find out interesting stuff, and everybody goes out and updates the Wikipedia articles, that old ID number is going to get incremented. But the original URL is not going to change. And then there's also a numeric ID, which is going to reference the Portland, even if maybe the article gets renamed, or suppose we decide we're not going to have an article on this ship anymore, we're going to have instead one article on all the steam tugs up and down the Willamette River. But that current ID number, that's going to stay the same. That's the numeric ID, and that's kind of the gold standard, as far as I've been able to tell. That's the number that you want to be referring to if you want to pull a Wikipedia article rigorously. And then finally, there's an API which allows you to iterate through a series of Wikipedia articles. So this API is your starting point if you wanted to pull out all of the article titles that reference this one in the second and third line, the National Register of Historic Places. So this is where you would start if you want to pull out some subset of Wikipedia articles. So when you pull this article, you had the option then of pulling down the XML. The XML is going to contain the revision info, who revised the page, what was the date, what was their internet address, and the plain ASCII markup. So Wikipedia is not going to send you the rendered markup. It's not going to give you the ASCII text version of this thing. All right, so I've got a math degree from a reputable school. I've taken a lot of computer science classes. I'm going to find myself a parser and figure out this parser and just parse the markup. And it turns out that writing a parser for Wikipedia markup or Wikipedia markup is a pretty popular idea. There have been a lot of projects that have tried to do this, and several of them have achieved some success. All right, so looking at all of this, I thought, well, maybe I don't really need a parser. Because this is just a pattern. This is the sort of thing I'm looking for. So maybe I can just write a regular expression-based thing to pull these numbers out. The reason this quote is so famous is that regular expressions, I'm not going to give you the computer science theory behind this, but a regular expression is a really elegant way to say something, but it's devilishly difficult to get it right. I didn't listen to Jamie. The fundamental problem is that what I need to be able to do is extract these balance to delimiters. So if I see the opening brace, I want to see the closing brace and pull all that information out. With a regular expression, with the richness of that particular engine, it's impossible for me to tell the difference in that bottom line between open brace, closed brace, the first closed brace, and open brace, and all the way through the final closed brace. And so in the Wikipedia markup, we can get a real mess. We can have some nested info boxes. We could have maybe multiple historic properties that are relevant to one article. The coordinates might be in a different info box. We see this especially with battlefields, where the main info box is going to be the battlefield info box. That's going to have the coordinates. And then, oh, by the way, this is also in the National Historic Register. And we also just see badly formed input. You're not going to go to Wikipedia and hit a page, and it's going to say, sorry. There's a syntax error in the markup. I'm not going to tell you anything. Wikipedia always is going to display something. But what I ended up doing was, this was plan B, was going for what I called a good enough regular expression. That is, instead of trying to write a perfect parser that understands every nuance of the article, I just need to throw away the stuff I don't care about. I need to throw away everything but the NRHP info box. And then, within that, throw away everything but the catalog number and the location. And so that ended up working pretty well. So when I ran that API call I showed you a few slides ago, I retrieved 64,000 articles that refer to the National Historic Register. After running through this good enough processing, I ended up able to handle about three quarters of them. I ended up with 16,000 orphan articles, articles that I couldn't match to a particular historic property. And that's going to be an artificially high number, because many of those are articles that are all the National Historic Register properties in King County, Washington, all historic ships on the West Coast. So I could maybe, dawn down the road, maybe I can exploit those articles. But these are not the one-to-one matches I'm looking for. So this is pretty good. And I was pretty happy with that. And that's where I was as of submitting the abstract. So I could stop here, but I've got another eight minutes, so I'm going to keep going here. So a while back, a couple of months ago, I discovered Dbpedia. And I've learned a lot more about Dbpedia in the last two days than I knew when I walked into the building. But Dbpedia is a project based on the notion of a semantic web. It's parsing all of Wikipedia and creating RDF articles. So creating facts in a very formal specification, creating records of the facts that are in the Wikipedia articles. This project has been going on for, I want to say, about 10 years. It's quite mature. They're up to version 3.9 now. But all of their extracts are going to be in the forms of triple, so it'll be a noun, a predicate, a verb. So Tug Portland is a ship. Tug Portland has latitude of 45.3 north. Dbpedia also has a Sparkle endpoint. Sparkle is an SQL-ish looking language that lets you do these semantic media queries. So I'll post these slides, but I wanted to give you a couple of quick links to get back to Dbpedia, because there's a lot of other information in there. The two big ways to get to it are either through their bulk downloads or through the Sparkle endpoint. All of this stuff is based on that numeric Wikipedia page ID. They've also got some canned data sets, all of the mountain peaks, large cities, various themed tables. There's about 500 of them. Unfortunately, none of the 500 were of direct use to me. But I want to make just a quick aside. If you're interested in this semantic web stuff at all, there have been two great talks here. One of them was yesterday talking about using semantic web for humanitarian assistance. And the other was this morning talking about pulling words and phrases out. So if you're interested in what I'm saying now, you're also interested in going back and watching these two talks on the video. So the Portland reference in Dbpedia is pretty easy to follow. So here's our original Wikipedia article ID, the Steamtag 1947. We can start from that a URI, which is dbpedia.org. That's not really something you can open in a web browser, but that's the specification that you use to search on. That's the key that they use for all of their triples. And then we also have a page link from the Wikipedia page to a different project, wiki data, which I'm going to talk about a little bit later. So here's a nicely formatted version of all of the facts that dbpedia was able to extract from the Portland's Wikipedia article in retabular form and then displayed in a human-readable form. Here's what some of the triples end up looking at. So you notice we're keyed always on that dbpedia.org slash resource slash name of the ship. And then the second element is going to be what predicate we have, and then finally the value for that predicate. So I chose to work with the downloads file because I didn't want to have to deal with lots and lots of network queries to sparkle. I didn't want to have to learn sparkle. So I'm loading all of the relevant downloads into an Objective C program and then querying that based on page ID. So page ID gives me the dbpedia ID. dbpedia ID is now my key into these other tables to extract the information that I care about. The information that I care about, in addition to the coordinates, was the abstract of the article, short abstract of the article, some of the media links. All right, so how are you going to do this for your own project? You've got to start with an idea, some theme that you're going to explore. And now you need to find either a template or a common article, some way to pull out all of those relevant Wikipedia articles. From those numeric IDs that you pull out, now you can go into dbpedia and grab the relevant facts. This is going to be your key to the abstracts and the text version, the title, text version, the abstract, any other properties. So some numbers here. I end up with about 36,000 dbpedia articles that referenced back to the National Historic Register. We have two different downloads in dbpedia. One is what they claim to be geocoordinates, and the other is what they claim to be keyed bits of information, this mapping-based properties. There was about an 80% overlap between their geocoordinates and the actual coordinates that were in this second file. I haven't figured out what the reason for that is. But the bottom line is you need to look at both of those. So the net change for me was another 1,500 properties that were georeferenced. Some of the figures that I was able to fix were articles where I had the location, but I didn't know what property it matched. Some I could match the property, but I didn't know what the location. So this is a decent improvement. So I also wanted to point you to a similar project I haven't worked with at all, but I'm aware of it. It's called WikiData. It's another semantic web project. Their idea is to have two-way communication. dbpedia is reading Wikipedia and then creating product, and that's the end of it. The notion of WikiData is you can edit the database, and then that automatically updates the info box in the relevant Wikipedia article. I haven't found an API. I haven't found any good downloads. But here's what the WikiData entry on the Portland looks like. And in fact, they were able to identify the property and they were able to identify the location. So to summarize, Wikipedia has some pretty well structured information if you know how to find it. If you follow the rules, you start with a list of Wikipedia articles generated somehow, maybe manually, maybe by following a formula. And then you've got a choice. You could either extract that with your own parser. You could use the dbpedia or dbpedia downloads or Sparklin. Maybe you can get something out of it in WikiData. Fundamentally, dbpedia is not human readable. The updates to it are pretty tedious. The downloads only come out annually. So I've been working with records that came out last August. WikiData appears to be pretty well funded. I think they've got some Google money and they've got some other pretty heavy hitters. But from what I've been able to see so far, WikiData is not very far along yet. But I guess the challenge I want to send to you is that this conference, we tend to spend a lot of time thinking about geometry. Geospatial is not just about geometry. It's not about projecting rasters and points and vectors. It's about getting information. And so this is a pretty handy way to get information into the hands of your users that's already organized geographically. So we can take a couple of questions, wait for the mic, or I can read the question. Thank you. Have you looked at Wikipedia to help you find these places? I have not looked at Wikimapia in detail. No, I haven't. There's one up here. Two up here. Sorry. Do either API find a way to make it Wikimapia this? Do the APIs find a way to, if you have existing coordinates to see what Wiki articles are around you, or do you have to start with a known article and get the coordinates of that particular article? From what I've seen so far, there's no geographic search in Wikipedia or Wiki data. There might be some geographic search capability if you hit the sparkle endpoint, but I haven't tried to use the sparkle endpoint yet. Yeah, I was just curious. You said you got about 1,500 X results using the dbpd approach. But were there any results that you found using your regular expression search and not with dbpd? I think there are some results that I found with my regular expression code and not dbpd. But I'm not sure what that means, because I'm working with, on dbpd results from a year ago. That is, they captured Wikipedia a year ago. I'm looking at articles that have been updated since then. So I am seeing some results that I'm getting that dbpd is not finding, but I don't have an explanation for it. OK, well thank you all for coming in.
 Well, good afternoon, everybody.  Thanks for coming in.  My name's Hal Mueller.  I'm a one-man software shop up in Seattle.  Most of what I have been working on the last few years  has been iOS and Mac software.  I keep one foot in the open source world.  And what I'm going to talk to you today about  is some geographic data production  that I went through for an application of mine, History  Pointer, which is an iOS app, an iOS mapping  app with particular focus.  History Pointer is a portable version  of the National Register of Historic Places,  which is a data set of about 100,000 properties  in districts.  It's a database that's administered  by the National Park Service.  It contains all kinds of cool stuff.  I mean, it has old buildings, factories, historic districts.  Maybe there'll be commercial buildings,  a building associated with a particular person,  maybe their birthplace, their place they died,  a place where the Civil War ended,  maybe a particular architect.  If you wander around just in Portland with this application,  you're going to see lots of really cool commercial buildings.  There's a Minuteman II missile silo in the National Register.  And there's also the houseware home on the range was composed.  So it's a pretty diverse data set.  It's not, in my experience, been a real friendly data set  to work with because it was originated starting back  in the 60s when we weren't really doing GIS yet.  We weren't really doing any geographic information.  So my original idea when I started working on this project  or when I started working on the second version  was to link to Wikipedia in order  to get some richer information.  So if you look at the Broadway Bridge, which is just  off our balcony here, the original nomination information,  the original history information,  is not available at the National Park Services website.  It's a pile of paper that hasn't been scanned yet.  But I was able to link to Wikipedia  so you can find out a little bit about the Broadway Bridge.  So when we get over to the geographic data side,  we have some problems.  The data set is inherently noisy.  It's outdated.  I can go home to Seattle and I can find out  that the USS Missouri is supposedly  moored right across the water in Bremerton.  Well, actually, that's where the Missouri was when  she was entered into the National Historic Register,  but she's now over in Honolulu and has been there for some time.  But this is not a data set that the Park Services funded  to maintain.  It's certainly not funded to maintain current information.  Sometimes it was just entered wrong.  Sometimes there was a typographical error.  And then some of these descriptions  are just inherently really, really hard to geocode.  And there's the last one there.  If I had a map, I couldn't find it.  County Road 326 between Delaware 12 and County Road 83,  Duck Creek 100.  Good luck.  But what I have found is that the Wikipedia people really  care deeply about the articles they're writing.  And so what I've been trying to do  is pull the relevant geographic data out  of the Wikipedia article.  So here we are in the convention center.  And we can find out information about the Portland, which  is the tug more up the river, and then go straight  to the Wikipedia article.  And also, I've managed to georeference the Portland, which  again, is a ship.  The location they have in the original database for the Portland  is not correct.  If we look at this Wikipedia article,  I don't know how many normal people actually look closely  at a Wikipedia article.  It was not something I had ever done  until I started this project.  But there is quite a bit of pre-rigorous structure.  In addition to the plain text, there are numerous info boxes.  An info box in Wikipedia is software driven.  You'll put in certain keywords with values.  And then the Wikipedia renderer will present the information  based on the requirements in the info box template  and also based on the key values in the info box.  So if you look here, we have, in fact,  a standard information box for National Historic Register  Properties, which gives us the location, often the coordinates,  significant years.  It was the governing body when it was admitted.  And this catalog number, that 9,700, 0847,  which is its unique identifier within the National Register.  So what I'd like to do is a couple of things.  First, I want to link the relevant Wikipedia articles  to the appropriate National Register properties.  Because if I've done that much, now I've enriched my product.  I've gotten a nice Wikipedia description for the property.  And then I also would like to pull out the coordinates  if they're available.  So the coordinates are embedded in this Wikipedia markup.  And it looks like it ought to be pretty straightforward  to pull out.  And it wasn't always straightforward,  but it worked out pretty well.  So Wikipedia URLs have several forms.  There's the normal Wikipedia URL, which you would type in.  Most of us, frankly, aren't going to type in a URL.  We're going to hit the home page, and we're going to hit a search  box, or we'll do a Google search or something.  But this first URL, that's the normal top-level reference  for an article.  But then there's also a more specific reference, which is  that article URL with an ID appended to it.  So now what I've done is I've identified the article on the  steam tug Portland, and a particular revision.  So if you all go out now and tour the Portland and find out  interesting stuff, and everybody goes out and  updates the Wikipedia articles, that old ID number is  going to get incremented.  But the original URL is not going to change.  And then there's also a numeric ID, which is going to  reference the Portland, even if maybe the article gets  renamed, or suppose we decide we're not going to have an  article on this ship anymore, we're going to have instead one  article on all the steam tugs up and down the  Willamette River.  But that current ID number, that's going to stay the same.  That's the numeric ID, and that's kind of the gold  standard, as far as I've been able to tell.  That's the number that you want to be referring to if you  want to pull a Wikipedia article rigorously.  And then finally, there's an API which allows you to  iterate through a series of Wikipedia articles.  So this API is your starting point if you wanted to pull  out all of the article titles that reference this one in  the second and third line, the National Register of  Historic Places.  So this is where you would start if you want to pull out  some subset of Wikipedia articles.  So when you pull this article, you had the option then of  pulling down the XML.  The XML is going to contain the revision info, who  revised the page, what was the date, what was their internet  address, and the plain ASCII markup.  So Wikipedia is not going to send you the rendered markup.  It's not going to give you the ASCII text version of this  thing.  All right, so I've got a math degree from a reputable  school.  I've taken a lot of computer science classes.  I'm going to find myself a parser and figure out this  parser and just parse the markup.  And it turns out that writing a parser for Wikipedia markup  or Wikipedia markup is a pretty popular idea.  There have been a lot of projects that have tried to  do this, and several of them have achieved some success.  All right, so looking at all of this, I thought, well, maybe  I don't really need a parser.  Because this is just a pattern.  This is the sort of thing I'm looking for.  So maybe I can just write a regular expression-based  thing to pull these numbers out.  The reason this quote is so famous is that regular  expressions, I'm not going to give you the computer  science theory behind this, but a regular expression is a  really elegant way to say something, but it's  devilishly difficult to get it right.  I didn't listen to Jamie.  The fundamental problem is that what I need to be able to  do is extract these balance to delimiters.  So if I see the opening brace, I want to see the closing  brace and pull all that information out.  With a regular expression, with the richness of that  particular engine, it's impossible for me to tell  the difference in that bottom line between open brace,  closed brace, the first closed brace, and open brace, and  all the way through the final closed brace.  And so in the Wikipedia markup, we can get a real mess.  We can have some nested info boxes.  We could have maybe multiple historic properties that are  relevant to one article.  The coordinates might be in a different info box.  We see this especially with battlefields, where the main  info box is going to be the battlefield info box.  That's going to have the coordinates.  And then, oh, by the way, this is also in the National  Historic Register.  And we also just see badly formed input.  You're not going to go to Wikipedia and hit a page,  and it's going to say, sorry.  There's a syntax error in the markup.  I'm not going to tell you anything.  Wikipedia always is going to display something.  But what I ended up doing was, this was plan B, was going  for what I called a good enough regular expression.  That is, instead of trying to write a perfect parser that  understands every nuance of the article, I just need to  throw away the stuff I don't care about.  I need to throw away everything but the NRHP info box.  And then, within that, throw away everything but the  catalog number and the location.  And so that ended up working pretty well.  So when I ran that API call I showed you a few slides ago,  I retrieved 64,000 articles that refer to the National  Historic Register.  After running through this good enough processing, I ended up  able to handle about three quarters of them.  I ended up with 16,000 orphan articles, articles that I  couldn't match to a particular historic property.  And that's going to be an artificially high number,  because many of those are articles that are all the  National Historic Register properties in King County,  Washington, all historic ships on the West Coast.  So I could maybe, dawn down the road, maybe I can exploit  those articles.  But these are not the one-to-one matches I'm  looking for.  So this is pretty good.  And I was pretty happy with that.  And that's where I was as of submitting the abstract.  So I could stop here, but I've got another eight minutes,  so I'm going to keep going here.  So a while back, a couple of months ago, I discovered  Dbpedia.  And I've learned a lot more about Dbpedia in the last two  days than I knew when I walked into the building.  But Dbpedia is a project based on the notion of a semantic  web.  It's parsing all of Wikipedia and creating RDF articles.  So creating facts in a very formal specification, creating  records of the facts that are in the Wikipedia articles.  This project has been going on for, I want to say, about  10 years.  It's quite mature.  They're up to version 3.9 now.  But all of their extracts are going to be in the forms of  triple, so it'll be a noun, a predicate, a verb.  So Tug Portland is a ship.  Tug Portland has latitude of 45.3 north.  Dbpedia also has a Sparkle endpoint.  Sparkle is an SQL-ish looking language that lets you do  these semantic media queries.  So I'll post these slides, but I wanted to give you a  couple of quick links to get back to Dbpedia, because  there's a lot of other information in there.  The two big ways to get to it are either through their bulk  downloads or through the Sparkle endpoint.  All of this stuff is based on that numeric Wikipedia page ID.  They've also got some canned data sets, all of the  mountain peaks, large cities, various themed tables.  There's about 500 of them.  Unfortunately, none of the 500 were of direct use to me.  But I want to make just a quick aside.  If you're interested in this semantic web stuff at all,  there have been two great talks here.  One of them was yesterday talking about using semantic  web for humanitarian assistance.  And the other was this morning talking about pulling  words and phrases out.  So if you're interested in what I'm saying now, you're  also interested in going back and watching these two talks  on the video.  So the Portland reference in Dbpedia is pretty easy to  follow.  So here's our original Wikipedia article ID, the  Steamtag 1947.  We can start from that a URI, which is dbpedia.org.  That's not really something you can open in a web browser,  but that's the specification that you use to search on.  That's the key that they use for all of their triples.  And then we also have a page link from the Wikipedia page  to a different project, wiki data, which I'm going to talk  about a little bit later.  So here's a nicely formatted version of all of the facts  that dbpedia was able to extract from the Portland's  Wikipedia article in retabular form and then  displayed in a human-readable form.  Here's what some of the triples end up looking at.  So you notice we're keyed always on that dbpedia.org  slash resource slash name of the ship.  And then the second element is going to be what predicate we  have, and then finally the value for that predicate.  So I chose to work with the downloads file because I  didn't want to have to deal with lots and lots of network  queries to sparkle.  I didn't want to have to learn sparkle.  So I'm loading all of the relevant downloads into an  Objective C program and then querying that  based on page ID.  So page ID gives me the dbpedia ID.  dbpedia ID is now my key into these other tables to extract  the information that I care about.  The information that I care about, in addition to the  coordinates, was the abstract of the article, short abstract  of the article, some of the media links.  All right, so how are you going to do this for your own  project?  You've got to start with an idea, some theme that you're  going to explore.  And now you need to find either a template or a common  article, some way to pull out all of those relevant  Wikipedia articles.  From those numeric IDs that you pull out, now you can go  into dbpedia and grab the relevant facts.  This is going to be your key to the abstracts and the text  version, the title, text version, the abstract, any  other properties.  So some numbers here.  I end up with about 36,000 dbpedia articles that  referenced back to the National Historic Register.  We have two different downloads in dbpedia.  One is what they claim to be geocoordinates, and the other  is what they claim to be keyed bits of information, this  mapping-based properties.  There was about an 80% overlap between their geocoordinates  and the actual coordinates that were in this second file.  I haven't figured out what the reason for that is.  But the bottom line is you need to look at both of those.  So the net change for me was another 1,500 properties  that were georeferenced.  Some of the figures that I was able to fix were articles  where I had the location, but I didn't know what property  it matched.  Some I could match the property, but I didn't know what  the location.  So this is a decent improvement.  So I also wanted to point you to a similar project I haven't  worked with at all, but I'm aware of it.  It's called WikiData.  It's another semantic web project.  Their idea is to have two-way communication.  dbpedia is reading Wikipedia and then creating product, and  that's the end of it.  The notion of WikiData is you can edit the database, and  then that automatically updates the info box in the  relevant Wikipedia article.  I haven't found an API.  I haven't found any good downloads.  But here's what the WikiData entry on the Portland looks  like.  And in fact, they were able to identify the property and  they were able to identify the location.  So to summarize, Wikipedia has some pretty well structured  information if you know how to find it.  If you follow the rules, you start with a list of  Wikipedia articles generated somehow, maybe manually,  maybe by following a formula.  And then you've got a choice.  You could either extract that with your own parser.  You could use the dbpedia or dbpedia downloads or  Sparklin.  Maybe you can get something out of it in WikiData.  Fundamentally, dbpedia is not human readable.  The updates to it are pretty tedious.  The downloads only come out annually.  So I've been working with records that came out last  August.  WikiData appears to be pretty well funded.  I think they've got some Google money and they've got  some other pretty heavy hitters.  But from what I've been able to see so far, WikiData is not  very far along yet.  But I guess the challenge I want to send to you is that  this conference, we tend to spend a lot of time thinking  about geometry.  Geospatial is not just about geometry.  It's not about projecting rasters and points and vectors.  It's about getting information.  And so this is a pretty handy way to get information into  the hands of your users that's already organized  geographically.  So we can take a couple of questions, wait for the mic,  or I can read the question.  Thank you.  Have you looked at Wikipedia to help you find these places?  I have not looked at Wikimapia in detail.  No, I haven't.  There's one up here.  Two up here.  Sorry.  Do either API find a way to make it Wikimapia this?  Do the APIs find a way to, if you have existing coordinates  to see what Wiki articles are around you, or do you have to  start with a known article and get the coordinates of that  particular article?  From what I've seen so far, there's no geographic search in  Wikipedia or Wiki data.  There might be some geographic search capability if you hit  the sparkle endpoint, but I haven't tried to use the  sparkle endpoint yet.  Yeah, I was just curious.  You said you got about 1,500 X results using the  dbpd approach.  But were there any results that you found using your  regular expression search and not with dbpd?  I think there are some results that I found with my  regular expression code and not dbpd.  But I'm not sure what that means, because I'm working  with, on dbpd results from a year ago.  That is, they captured Wikipedia a year ago.  I'm looking at articles that have been updated since then.  So I am seeing some results that I'm getting that dbpd is  not finding, but I don't have an explanation for it.  OK, well thank you all for coming in.
06_Hal_Mueller_720_0_4955.png 06_Hal_Mueller_720_4956_5627.png 06_Hal_Mueller_720_5628_7235.png 06_Hal_Mueller_720_7236_7463.png 06_Hal_Mueller_720_7464_8783.png 06_Hal_Mueller_720_8784_11831.png 06_Hal_Mueller_720_11832_13139.png 06_Hal_Mueller_720_13140_13247.png 06_Hal_Mueller_720_13248_13535.png 06_Hal_Mueller_720_13536_13727.png 06_Hal_Mueller_720_13728_22211.png 06_Hal_Mueller_720_22212_22859.png 06_Hal_Mueller_720_22860_28607.png 06_Hal_Mueller_720_28608_32123.png 06_Hal_Mueller_720_32124_32207.png 06_Hal_Mueller_720_32208_32255.png 06_Hal_Mueller_720_32256_32351.png 06_Hal_Mueller_720_32352_33527.png 06_Hal_Mueller_720_33528_34115.png 06_Hal_Mueller_720_34116_34847.png 06_Hal_Mueller_720_34848_34895.png 06_Hal_Mueller_720_34896_34930.png