bobdc.blog

I've only written up about half of my list of semantic web project ideas first described here, and the 2007 Semantic Web Challenge has just been announced, so I wanted to get another one of the ideas out there.

An RDF report generator could be the RDF killer app.

A GUI front end to SPARQL that generates SPARQL queries without requiring someone to know SPARQL—in short, an RDF report generator—could be the RDF killer app, because providing useful access to data that made more sense in a triplestore than in a relational database would provide a vivid demonstration of the value of the RDF data model to people who wanted to avoid hands-on experience with RDF or SPARQL syntax. The project isn't ultimately about SPARQL, although obviously implementing it would require a high comfort level with the query language. It's about proving the value of the RDF data model for data that typical end users need.

Submitting queries to an RDF front end to relational data wouldn't prove anything. For example, imagine that you put an RDF interface in front of a movie relational database application and then created a form-based interface to send SPARQL queries to that RDF interface. Jane Moviefan could fill out those forms to look up more movies by the director of the film she loved so much last night, but so what? Forms to generate the SQL queries to send to the relational database are easy enough to create, and additional moving parts inside the black box won't make any difference to Jane.

What would make a difference to the end users would be the ability to query against data that didn't fit well into relational databases. These users may not care about relational versus non-relational storage, but they should have a shot at an "aha" moment when using this application with data that they care about and can't conveniently gain access to elsewhere. What data fits in RDF triplestores better than it fits into normalized relational tables? Who wants to query this data apart from RDF geeks who are comfortable with SPARQL syntax? These questions will help lay out the use cases for this application.

Reducing the domain scope would be important, because a general-purpose query form that worked for all RDF data but doesn't require query language syntax would be difficult. In other words, a general-purpose front end to generate any SPARQL query for any domain would be too ambitious. Finding useful applications within a given domain for the following queries would be a good start—I wouldn't be surprised if such a tool already exists in the world of biology and pharmaceuticals—because these queries would be easy enough to generate from a forms-based front end:

• Show all data about the subject with a dc:title value of "Lost in Translation"

• Show a subset of data about the subject with a particular dc:title based on entered criteria

• List all subjects an imdb:director value of imdbn:nm0001068

• Show all data about subjects with an imdb:director value of imdbn:nm0001068

• Show selected predicate/object (name-value) pairs for subject imdbn:nm0001068

I realize that after saying that a movie database would be not be a good example because such data fits just fine into a relational database, I'm using movie data for use case queries. A good example database would take advantage of the added flexibility of RDF, so that drop-down selections of "fields" to query when retrieving "records" (while not technically correct terms, "field" and "record" could still be helpful metaphors for the end-user to understand how to use the query tool) would be based on the available data, not on some schema that predates the data—which I'm sure is the case with IMDB. For flexible data that lots of people care about, I like to use address book data in my own examples.

Hooking up an XForms front end to an RDF triplestore back end would be an interesting place to start. Also check out Leigh Dodds' Twinkle, which is an aid to constructing SPARQL queries to submit to a SPARQL engine, as opposed to a forms-based interface that hides the actual queries from the user, but plenty of good work has gone into it. I haven't had a chance to take a close look at Oracle's RDF offerings, but if they're so far along with it, maybe they have a way to create forms that create queries against the RDF for use by people who know nothing about RDF. I look forward to finding out.