(continued from part III)
Over the last year I had hardly time to advance my Perl client to the AllegroGraph tuple server. Which is a shame, as it is fun to take the existing REST interface and to offer it in a perlish mindset.
So when the Perl hackathon (report) was in Vienna these days, and coincidentally also the RDF Perl hackathon Geilo next week, I thought I should use the opportunity to a rub shoulders with the Perl illuminaries, at least for half a day. But when I arrived, everyone was already in deep hacking mode, so I had no excuse but to do programming myself.
(continued from Part II)
One thing Formula 3 (F3) was designed to help with is the quantitative transformation of time series. If you had to compute the mean values over an 1-hour interval of, say, the ticket sales then the following TSP operator takes care of it:
every 10 minutes
(continued from Part I)
Last time I implicitly proposed to think some parts of a (geosemantic) application in terms of time series. This is not so farfetched, consider for instance a semantically enabled tourism application for, say, Vienna.
Sure, there are a number of very static things you would store into the semantic network:
- the sites, churches, cathedral, churches, and even more churches,
- the museums, galleries, museums and even more museums,
- the tourism ontology, containing buildings, museums, and yes, the churches.
But even if this is Vienna, not everything is static: There are (insane) traffic conditions, (predominantly italian and spanish) tourists roaming through the city, concert tickets sold at the weirdest places. All these are perfect candidates to be packed into time series.
When people design semantic systems, then a typical architecture looks something like this:
- An RDF tuple (or Topic Maps) store for the odd and irregular data, and
- some relational DB, either imported into the semantic store, or wrapped, or linked via a message bus (MQ, events, ...).
- Some more or less sophisticated integration, and
- the user interface on top of it.
Now this is all well and good for your middle-of-the-road semantic portal, but the class of applications I have in mind have one thing in common:
Data dynamics, with temporal and geospatial aspects. And that with physical units.
The Python client shipped with the distribution is using it, so I wondered how this would pan out in Perl. Pan out on CPAN, so to say. Last weekend I did some tinkering and concocted a first, naive Perl client.
A while back I experimented with the Java client API of AllegroGraph to talk to a triple store.
The latest release (V3.1.1) also sports a Python client which immediately aroused my interest, and that for several reasons:
- It is using a new HTTP protocol with the AllegroGraph server, one using JSON.
- And its API is following that of Sesame.
The following simply goes through the basic motions, as also described by the Python tutorial.
The other week at the Triple-I conference Andreas Blumauer mentioned to me AllegroGraph as a product which can do geospatial and temporal reasoning. I was not deterred by their
criminally 90'ish web site (Update 4.4.09: there is now a new flashy design!) and downloaded their free Java edition with an upper limit of 50,000,000 triples.
One of my main agendas here at the research center is to evaluate the usefulness of semantic technologies for geospatial applications.