XMLArmyKnife

SPARQL Geo Extensions

I've been experimenting with some ARQ Extensions for manipulating geographical information in SPARQL.

I've implemented three functions which are now running on this server, to use them you'll need to add the following PREFIX to your queries:


PREFIX myfn: <java:com.ldodds.sparql.>


You're free to change the name of the PREFIX, but the URI must be the above for now. WARNING: the URI is likely to change, initially to a proper URI for the collection of geo extensions. Hopefully eventually to a formally specified URI if I can drum up interest amongst SPARQL developers to implement the extensions on other engines. So use with care now and check bac for updates.

With that PREFIX declared you can now use the following three functions:


myfn:Distance(?a, ?b)


The Distance function will return the distance between two points in kilometres. It assumes that the variables its passed conform to the examples given on the GeoRSS in RDF docs. The literal values are automatically split to get the latitude and longitude. Here's an example query.

A better option for data that uses the Geo vocab such as this data mapping a walk through Bristol is to use the following function:


myfn:Distance(?lat1, ?lon1, ?lat2, ?lon2)


Here's an example query.

The final function allows a query to test whether an arbitrary point is within a bounding box:


myfn:PointInBoundingBox(?minlat, ?minlon, ?maxlat, ?maxlon, ?lat, ?long)


The first four parameters define the southwest and northeast corners of the bounding box. The last two define the point to test.

There's an example query.

Let me know if you come up with any interesting hacks, or whether you think the math is wrong!

Applying XSLT to SPARQL Results

Using the XSLT service its possible to apply a transformation to any XML document, including the results of SPARQL queries.

The Jena RDF/XML-ABBREV output which can be used to serialize the results of CONSTRUCT and DESCRIBE queries can be processed with XSLT as its more regular than the default RDF/XML format. For example Masahide Kanzaki has as stylesheet that can be used to transform RDF calendar data to an HTML calendar view.

However its the SPARQL results format which is most amenable to post-processing with XSLT. It's a very regular and simple format that can be easily transformed into many different vocabularies.

As a convenience feature I've updated the SPARQL query service to accept an extra xslt-uri parameter. The parameter should indicate an XSLT stylesheet that will automatically be applied to the results of any SELECT query. Only this response format is supported at present, although I'll expand it to cover the other options when I get chance.

Any non-SPARQL protocol parameters present in the query string, i.e. anything not listed in the documentation, will be automatically made available to the XSLT stylesheet engine (Saxon 8.6). This means the stylesheet can be parameterised to take in additional data.

To set the mime type for the response, ensuring that you use the xsl:output element in the stylesheet, and configure an appropriate media-type attribute.

Morten Frederiksen has previously demonstrated how to convert SPARQL results to RSS. I've taken his stylesheet and made a few tweaks (bringing it up to date, renaming a few parameters) and made it available on my server. So using this stylesheet you can transform the results of any SPARQL query to RSS 1.0.

There are a couple of rules to follow:

• Ensure there are variables called rsstitle and rsslink in your response. These will form the rss:title and rss:link tags of each item. Note: rsslink MUST be bound to a URI in the query.
• Provide a title parameter in the URL to set the rss:title of the feed
• The channel and description parameters are similarly mapped to the their respective top-level channel elements

Here's an example of a SPARQL query that provides results in the correct format. It selects the 10 most recently tagged items from 2 users of del.icio.us. Here's the results in HTML. And here's the results with the stylesheet applied.

The nice aspect to this approach is that you can serialize any result set that conforms to the expectations of the stylesheet. "Shape" your query to match expectations and you can do all sorts of interesting transformations.

Content-Type Bug Fixes

I've made some bug fixes to all of the services that should resolve problems with generating results that contain non-ASCII characters. I should have caught this earlier, but I wasn't correctly setting the charset parameter in all responses.

I've also double-checked and ensured that I'm returning the correct mimetype for N3, Turtle, etc.

If you notice any other Content-Type related bugs (or anything else for that matter!) please drop me a mail.