07.19.06

A Queso Example

Posted in development, semantic web, web at 11:17 pm by wingerz

I received an email from a friend who wanted to learn more about my work. He is not that familiar with the Semantic Web, and I tweaked my reply to him because it does a decent job of explaining what Queso does. Pre-reading: Queso introduction, RDFa in Queso.

Core technologies, in order of appearance:

• RDF – Resource Description Framework – representing data in subject-predicate-object triples, heart and soul of the Semantic Web
• Atom – most widely known as a feed format, also for publishing content
• JSON – Javascript Object Notation – representing objects as strings that can be eval’ed in Javascript (there are also libraries for parsing JSON in other languages) – takes the pain out of parsing responses on the client
• XHTML – HTML as XML, which means that you can’t have open tags, (p, I’m looking at you), attribute values must have quotation marks around them, etc.
• RDFa – a standard for embedding RDF in XHTML
• SPARQL – SPARQL Protocol and RDF Query Language – I like it even more because 1) it’s a recursive acronym and 2) Elias and Lee are on the working group.
• Microtemplates – templates for HTML – bind Javascript objects to them to display your data

Our high-level goal this summer is to put a web front-end onto Boca, our RDF store. Most of our group’s work over the past few years has focused on building infrastructure to support the Semantic Web. Our UI work has primarily involved creating libraries for RCP-based applications, but we’ve always known that making things web-accessible is important.

In Queso, we want to store both data and XHTML/Javascript application code. We want web application designers to be able to dump their (potentially structured) data into the system, which stores everything as RDF triples. SPARQL provides an easy, standardized way to query for data in a flexible, precise manner. The data in the system can be easily extracted and repurposed for use in other applications, such as mash-ups. The following is a simple example where I’ve tried to improve readability by leaving out namespaces and base URIs. Don’t follow this as a copy-and-paste tutorial.

There’s a site called mywikimap that shows local gas prices on a Google Map. If you wanted to store data for an application like this using Queso, you could post Atom entries of the following format as XHTML:

<div about="[queso:thisEntry]">
	price: 		<span property="price">2.95</span>
	latitude: 	<span property="latitude">7</span>
	longitude: 	<span property="longitude">9</span>
	time found: 	<span property="time">2006-07-19T10:27:00</span>
</div>

While this will display in a (somewhat ugly) human readable form, it is also valid RDFa, so Queso extracts RDF triples from it (semicolon at the end of the line just means that the following triple has the same subject):

_:gasEntry  "2.95" ;
   "7" ;
   "9" ;
   "2006-07-17T10:27:00" .

These triples will be stored along with the triples that represent the Atom entry. Now you can query them using SPARQL, with the following query (which restricts the results to entries from July 17 or later located in a certain area):

select ?price ?lat ?lon ?time
where {
  ?entry  ?price ;
     ?lat ;
     ?lon ;
     ?time .
    filter (
    	?lat > 5 && ?lat < 10 
    	&& ?lon > 7 && ?lon < 12
    	&& ?time > "2006-07-17T00:00:00"
    )
}

What’s more, you can get this back as a JSON object that looks something like this (according to this standard):

{ price : "2.95", lat : "7" ... }

Then you can eval it in Javascript (in the real world you’d do some checking on it before eval’ing it):

var gasEntry = eval(jsonResult);
var str = "Price: " + gasEntry.price 
  + ", latitude: " + gasEntry.lat 
  + ", longitude: " + gasEntry.lon;

Rather than constructing a string on the client via string concatentation, we can use microtemplates to display the data. An example template (Note that the names of the classes match the names of the variables in the SPARQL query above):

<div id="gastemplate">
	price: <span class="price"></span>
	latitude: <span class="lat"></span>
	longitude: <span class="lon"></span>
	time found: <span class="time"></span>
</div>

In Javascript, the data can be bound to the template with the following line:

new IBM.ET4A.Template("gastemplate").bind(entry);

And now the div will show up with data values filled in.

So what’s so great about all of this? We didn’t have to deal with anything database related, like setting up tables and writing SQL code for inserting data into the system or querying. If we wanted to add additional data (say, the gas station name, the street address, etc.), we could encode additional triples very easily. We also didn’t have to write a web API to expose our data to the world. On the client, we didn’t have to parse any XML or RDF in Javascript. Anyone can use the data, either for its originally intended purpose (display on a Google Map) or something else (trend analysis across time and location or something more interesting).

Now that we’ve got the data set up, we move on to application development. In this (simple) case, one would develop the XHTML and Javascript files (including our libraries for Atom publishing and SPARQL querying) necessary for a web UI for this application and upload them to Queso. They would be posted to Queso as Atom entries containing the appropriate content types. And that’s it for application deployment – pointing your web browser to the appropriate URL would give you the content as XHTML. These files can also contain some RDFa markup so that additional metadata about the application can be stored. This would give us a server application registry for free via a SPARQL query for everything on the system that is of type application. For more complex applications we can set up traditional web frameworks and have them interact with Queso on behalf of a client.

Of course, there are a lot of problems as well. We haven’t looked much at security, though our store has built-in access control. We’re looking into how to make this as scalable as possible, and the thought of having an open SPARQL endpoint is frightening. But for now we hope that this can serve as a sandbox for people to experiment with RDF, Atom, RDFa, and SPARQL.

Permalink