mapFINDS Ohio: A native iPhone App using the WorldCat Search API and mapFAST

mapFINDS Ohio iPhone appHello, I'm Steven Huwig, a programmer at OCLC, and Alice asked me to write a guest post about a recent iPhone project I've completed and published in the App Store. The application is called mapFINDS Ohio, and I developed it as an entry for eTech Ohio's Mobile Apps Development Contest. It makes heavy use of the WorldCat Search API and the experimental mapFAST geographic subject service.

I had never written a mobile application before this project. The idea came to me at the CodeMash conference, where I had been learning the basics about location-based mobile applications. One of my projects at the time was OCLC's WorldCat Digital Collection Gateway, which is software to automatically load metadata from digital repositories into WorldCat. That means a lot of scanned historical photographs, audio recordings, and other interesting and unique digital content. I thought to myself, "wouldn't it be cool to have a mobile app that would show you these digital items based on where you were?" For example, you could be standing in front of a city hall and see an image of it as it was one hundred years ago, or you could be out fishing and read engineering reports about the dam systems in the area. (OK, I'm a nerd, I admit it.)

When I came back to work, I got the go ahead from management to work on this project alongside my other priorities. Since one of the eTech Ohio contest requirements was that the app be available in the Apple App Store, I needed to write it as a native Objective-C program. Besides Apple's documentation, I found the free videos of Stanford's CS 193P iPhone Application Development course to be very good learning material—even though they don't seem to be cataloged in WorldCat yet!

I found a few Apple and Objective-C libraries and frameworks to be very important in my app. Those include:

  • MapKit - this let me avoid writing my own map-handling code
  • Core Data - this let me avoid writing my own memory management and data storage code
  • json-framework - this let me avoid writing my own JSON parser (are you sensing a pattern here?)
  • NSXMLParser - Apple's standard XML parser, needed to extract the data from MARC-XML records

As it turned out, my colleagues at OCLC had already written the majority of the app for me; it only took a frontend using those technologies, and a few user interface niceties, to make a web service-based native app for the iPhone. The biggest help was the mapFAST web service. OCLC Research had compiled all of the geographic subject headings in WorldCat into a location-based database and web service, allowing clients to search for nearby geographic subjects based on map coordinates.

When I first had my idea, I had planned to mine some public database of locations in Ohio, send them as search keywords to the WorldCat API, and hope for the best. With the mapFAST service, I'm confident that the spelling and content of location names will match something in WorldCat. Moreover, mapFAST provides both a display name (for use in the app's user interface) and normalized search terms (for use in WorldCat API calls).

In the application code, after getting a list of search results for a given location, one of the key pieces of data I wanted was a URL link to the digital item. To me, one of the biggest advantages of using a mobile device is immediacy—you can search or browse for some piece of information and have it immediately. This extends to the mapFINDS app: if I am looking for things about my vicinity on the phone, I want to see them, not just see their bibliography entry! By default, mapFINDS Ohio only shows results that have a URL in their bibliographic record, though there is a search option to show all items whether or not they can be seen on the device somehow.

Speaking of bibliographic records, it turns out that MARC-XML does have a few advantages over Dublin Core; specifically, you can tell summaries, abstracts, tables of contents, reproduction notes, and physical form notes apart from each other! I wanted summaries and abstracts in my item detail screen, not the more esoteric portions of these records. In my first pass at coding the WorldCat Search API code, I tried to use the Dublin Core version of the service, but all of those sorts of fields got listed as dc:description. I figured rewriting my code to target the MARC version of a record was an easier task than writing an artificial intelligence to tell tables of contents apart from summaries. As a result, the code to extract a summary from a record currently looks like this:

- (NSString *)recordInfo
    NSString *result = [self allElementsForField:@"520" subfield:@"a"];
    if (!result) {
        result = [self allElementsForField:@"500" subfield:@"a"];
    return resuamp;lt;

That's a good example of how catalogers have made finding the right information simpler.

Here are some things I'd like to add to the app in future releases. Some are minor, others are wishful thinking about an entirely different metadata framework.

  • Extend the app outside of Ohio, or provide a new app with wider coverage. Since the eTech Ohio contest wants an Ohio-focused app, and since I already knew that there were rich collections of digital items from the Ohio Memory project and the Ohio Historical Society, this limitation was made mostly for time's sake.
  • Augment the app for the tablet form factor of the iPad. Originally I thought that the immediacy of the current location made this an ideal iPhone app. After using it, I think there's a lot to be said for browsing around childhood homes or other places of interest, and a larger device makes that easier. Additionally, much of the content isn't done justice on the tiny phone screen.
  • Add additional search customization. Maybe someone is only interested in photographs, or recordings, or historical documents. There's no need to make them wade through theses and municipal websites. By the same token, people undertaking research of government reports regarding an area don't need to be bothered with old postcards.
  • Add user-driven relevancy data collection. The app currently allows people to mark items as "favorites" for later browsing. This information is currently only stored locally on the phone. It would be nice to collect anonymous statistics on which records have been marked as favorites—that data could be used to sort the results. If one person considers an item "interesting," it's more likely that someone else will too.
  • Get more precise location information. mapFAST currently just returns the geographic center of the subjects in the database. It would be nicer if the map view could place the mark where an actual item's subject is located, instead of the nearest town ten miles away. Unfortunately this would require that geographic coordinates be included in bibliographic metadata where appropriate, and not just for cataloged maps.

Hopefully if you use the app, you will come up with a list of more improvements and let us know—hint, hint!

Finally, I'd like to thank some of my OCLC colleagues for their help in creating the app. Mike Harsh did the graphic design and had some great advice for user interface design. Tip House, Leah Houser, Willie Neumann, Taylor Surface, and Mike Teets all graciously gave their time and support when I needed it. And of course, without OCLC Research and the WorldCat Web Services teams' prior work—well, I wouldn't have had the idea for the app in the first place, let alone have been able to complete it.

Editor's note: We'll add the app to the Application Gallery soon...

  • Alice Sneary

    Alice Sneary