Exhibit your RDF databases!

I\'ve written a short script that reads in an Exhibit JSON template file, and turns it into SPARQL queries, queries a local ARC RDF store, and injects the results back into the items array of the JSON template, which it then outputs.

The script will generate a new query for every item it finds in the items array. The format of the template is the same as a normal Exhibit JSON file, except:

• you need to specify your types and properties in the \"types\" and \"properties\" objects, and give them an \"uri\" property, containing the uri of the RDF Class or Property in the database. Actually, this is still normal to Exhibit, which can use these URIs in its RDF/XML exporter (though the exporter apparently needs a bit of work before it will do this for the rdf:types).
• In each item, use empty strings for values that should be variables in the query
• The value of the \"label\" property should be the name of another property from the properties object.

Here is an example:

			{

			    types: {
			        \"Person\": {
						uri: \"http://xmlns.com/foaf/0.1/Person\",
			            pluralLabel:  \"People\"
			        }
			    },
			    properties: {
			      
			        \"name\": {
						\"uri\": \"http://xmlns.com/foaf/0.1/name\",
			            label:        \"Name\",
			            valueType:    \"item\"
			        },
					\"email\": {
						\"uri\": \"http://xmlns.com/foaf/0.1/mbox\",
			            label:        \"E-Mail\",
						\"pluralLabel\": \"e-mails\",
			            valueType:    \"uri\",
			        },
					 \"knows\": {
							\"uri\": \"http://xmlns.com/foaf/0.1/knows\",
				            label:        \"Knows\",
				            valueType:    \"item\"
				        },
			    },
			    items: [
					{
						\"type\":	\"Person\",
						\"label\": \"name\",
						\"name\": \"\",
						\"knows\": \"\",
					},
					{
							\"type\":	\"Person\",
							\"label\": \"name\",
							\"email\": \"\",
							\"name\": \"\",
					}
			    ]
			}
			
		

You can see this in use at this basic Exhibit, and have a look at the json-to-sparql-and-back script itself.

What\'s the point? It\'s easy to write SPARQL queries.

It is pretty easy to do this manually anyway (in part, at least, because of the RDF-like nature of Exhibit\'s data structure), and I can\'t pretend the script does anything technically complicated or clever, but if you\'re putting up an Exhibit anyway, this script can let you remain in that mindset, or indeed make Exhibits from RDF datastores without knowing SPARQL at all - or even very much about RDF (beyond the concept of letting URI\'s identify concepts).

Where this idea could really become cool though, is if there was a web service to which you could send your json template and the location of a SPARQL endpoint, and get back a nice full Exhibit database object.

If you coupled this with some of SIMILE\'s other products (Piggybank and Solvent), then you\'ve got a relatively easy way to present the data you\'ve screenscraped, without doing any server-side coding at all. You could just scrape your data, save it to SIMILE\'s databank, and write your Exhibit with a call to the webservice, sending the query to your SIMILE databank. In fact, the webservice bit isn\'t even totally necessary - you could maybe use Lee Feigenbaum\'s sparql.js library to fetch the results, and the rest of the code would be trivial to rewrite in javascript too (though there are the cross-site XMLHttpRequest security restrictions you\'d have to contend with).

Safer than SPARQL, easier and more open than an API

This also offers a minor solution to another problem: I might want to provide open access to my RDF data (or some of it), but I\'m not going to put up a public SPARQL endpoint. If I gave you an endpoint to my ARC RDF store for instance, you could easily write (or miswrite!) a query that would give the database a lot to think about for a long time. I also probably wouldn\'t want you to see all my data, if I\'m storing user account details and things in there (there are actually some ways around this with Arc, involving splitting sensitive properties into different tables).

It would be easy to provide an Exhibit JSON endpoint instead. You could predefine the properties and types objects of the classes and properties that you want to make available to the public, and publish what they are. And because there\'s no need for a DISTINCT in the generated query (Exhibit does a lovely job of smooshing together objects with the same id), and you can choose the LIMIT and set it relatively low, it shouldn\'t (I think, correct me if I\'m mistaken!) be possible to send an Exhibit JSON query that would result in a hugely expensive query.