RDF impressions at YAPC

While attending YAPC 2006 in Chicago, I've been once again impressed with the need to get a set of RDF tools working in Perl. There are so many interesting tools that could be implemented if only there were some basic RDF modules. We need something to do for RDF what DBI does for database access, but with flexibility that matches RDF's. I've heard that RDF::Helper may be a start in that direction, but it doesn't look nearly visionary enough. One of my highest priorities is to get this basic RDF toolchain working. I could use Redland, but I really want my RDF-related modules to work regardless of the implementation that a user chooses. For instance, at work, I developed an application that stores it's data as RDF in a Sesame repository. I should be able to switch from Redland to Sesame by changing very little code and have everything Just Work.

Here's a short list of some of the RDF modules that I want — and the inspiring/reminding talks where appropriate.

• RDFI — Generic RDF interface like DBI for RDF



I attended Joe McMahon's talk about Designing for Pluggability which reminded me of the importance of interchangeable parts and modifiable parts in modern software design. RDF is a great match for this pluggable design approach because it allows plugins to extend the data model as well as the code. I've been working on a timecard application for a while and I keep coming back to RDF as the perfect, extensible data model for that application. I don't want to write all the functionality into the core application. If someone wants to record the color of their hair at the time they clocked in, they should be free to extend the data model to accomodate that desire. That data should then become a first class citizen available for querying (SPARQL) and modification like any other data.





• RDF::Sync — synchronize the RDF in two repositories



During the lightning talks, Jesse Vincent presented a brief segment (during Adam Kennedy's talk) where he described the ideal situation where one's data lives on his laptop and out on the net. He wants to get off the airplane and have his laptop data automatically sync with the data that's stored out on the net.




I've wanted this same thing since I often switch between: connected desktop, connected laptop, disconnected laptop. I'm sick of trying flawed approaches to synchronize my bookmarks. When I'm off in the wilderness and want to find an email that I saw three months ago, I don't want to wait until I can get a net connection again. My data should be where I want it, when I want it.




Because RDF can be used as a universal data storage format, and it's easy to synchronize that data between different repositories, I think that RDF is a great solution to this problem.




• RDF::MSG — calculate the minimum self-contained graphs for an arbitrary RDF graph.



RDF synchronization and RDF signing both require a technique for splitting an RDF graph into atomic chunks. The technique is easy to implement, I just have to bundle it into a handy Perl module and toss it on the CPAN

Ingy döt Net gave a mostly incoherent lightning talk (by design, I'm sure), but amidst the swearing and random auditory noise, there were some good pieces about an idea that he called CogBase. I didn't get a chance to talk with him about it afterwards, but his notion seems to coincide with an idea I've had for a while: a single, versioned repository for all my data like contacts, email, bookmarks, websites visited, …. I think that RDF is the solution to this universal database. Look at the Description section of the CogBase module and compare that with what the RDF data model provides. 8 of the 15 requirements are already met by RDF. Solutions for versioning and access control issues are still an open question within the RDF community, but I don't think they're insurmountable. With those two pieces solved only the item about object-orientedness of schemas is still missing.

There are just too many cool apps that can be built once the tools are in place. I just need the time and resources to work on it. Let's see if I can implement it in less than the 3 years these ideas have been rolling in my head. Maybe next year I'll submit a collection of talks about RDF

• Introduction to RDF


• Using RDF as a Data Model


• Extensible Applications with RDF

or some such.

Review: Rackmounted.com

I've been using Rackmounted as my
provider for dedicated hosting for about a year now. During that time, the
service has been excellent. They provide one of the most
inexpensive dedicated server
packages that I've found anywhere. We've had no problems with the server and
responses to service tickets have always been prompt.

The event that prompted this review is that a little past midnight, our
server went down. I noticed it this morning and was unable to access the
server via SSH (even though I could ping it). I submitted a ticket to
Rackmounted and waited for an automated email response indicating that the
ticket request had been received. After a few minutes, one didn't arrive, so
I submitted another ticket. Within a minute or two, a
representative from Rackmounted called me on the phone. He said that he
noticed I had sent a second ticket and assumed that his email responses
weren't getting through, so he wanted to make sure I knew what was going on.
He was going to restart my server. Within a couple more minutes, everything
was back up and running.

Great service. One more reason to get dedicated server hosting from
Rackmounted.com

Thanks Rackmounted

Ephesians 6:17 - sword of the Spirit

As I was finishing the book of Ephesians this morning, I came across a marginal note I made while learning Biblical Greek. The note clarifies a single relative pronoun in Ephesians 6:17. We read Paul's counsel to take ... the sword of the Spirit which is the word of God. The question: what is the sword? Or in other words, what is the referent of which. The traditional Protestant view is that The word of God is the sword of the Spirit (Matthew Henry). Namely, the referent for which is sword. However, in Greek, the grammatical gender of a relative pronoun agrees with its referent. In Ephesians 6:17, the relative pronoun is ὅς (singular neuter). The referent therefore must be neuter. sword is μάχαιρα (singular feminine) and Spirit is πνεύματος (singular neuter). So the referent of which is Spirit. The Spirit is the sword and the Spirit is the word of God. Translating Ephesians 6:17 by dereferencing the relative pronoun gives something like And take the helmet of salvation, and the sword of the Spirit, which Spirit is the word of God:

So what? The point is that the sword Paul counsels us to take is the Spirit not the written word of God. A solid knowledge of the scriptures is commendable, useful and wise, but it does not provide the active, dividing power which the Spirit of the Lord provides. For it is the Holy Ghost which will show unto you all things what ye should do.

Migrating a Catalyst app from mod_perl to FastCGI

There's a web application that I developed at work which runs under the
Catalyst MVC framework for Perl.
Catalyst is fun to develop in, but this particular application has a lot of
code and made for very large Apache server processes. The result was a lot of
swapping on the server and really slow shutdown times for the Apache
process. I decided to migrate the application to FastCGI. Finding all the
configuration details was a bit of a pain, but the final steps are simple.
I've restated those steps here to save you (and me) some time.

Migrate to CGI

I found it easiest to make sure the Catalyst application was running under CGI
without trouble before beginning the FastCGI portion. It also helped me to
create an empty Catalyst application to make sure none of my code was
responsible for failure.

> catalyst TestApp

In your httpd.conf file, add directives like this
(assuming you have mod_cgi already installed and loaded).

Alias /testapp/ /absolute/path/to/TestApp/script/testapp_cgi.pl/
<Location /testapp/>
  SetHandler cgi-script
  Options +ExecCGI
</Location>

Now you can visit http://server/testapp/ to see the default Catalyst
screen.

Migrate to FastCGI

Once that's working, move the app over to FastCGI. You'll need to install
mod_fastcgi (available from
FastCGI's webpage) or install
mod_fcgid (a compatible
alternative). Now change your Apache directives to the following:

Alias /testapp/ /absolute/path/to/TestApp/script/testapp_fastcgi.pl/
<Location /testapp/>
  SetHandler fastcgi-script
  Options +ExecCGI
</Location>

The only changes in the above configuration are to add fast to
testapp_cgi.pl and cgi-script. Once
that works, you can replace the TestApp locations and names with the
ones for your real application.

Some documentation online mentioned using Apache's Action
directive. I wasn't able to make that work, but Alias
seems to do the trick.

The Question of Abstraction

As I recently read The First Epistle of Paul the Apostle to the Corinthians, I was reminded of an issue with hermeneutics. Namely, to what extent are the words of the prophets and apostles to be abstracted from their original context when deriving doctrine?

This example may demonstrate the point, however the question of abstraction is general and I'm not necessarily concerned with this particular application. We read in 1 Corinthians 5:11

But now I have written unto you not to keep company, if any man that is called a brother be a fornicator, or covetous, or an idolater, or a railer, or a drunkard, or an extortioner; with such an one no not to eat.

It's obvious how the Corinthians to whom this letter was sent were intended to understand the statement. But how is everyone else intended to understand this statement (or any statement from the Scriptures). In answer to the question For whom is Paul's statement proscriptive? there is a seemingly infinite continuum from concrete to abstract:

• only the Church of God which is at Corinth (see 1:2) which received the original epistle


• all saints of Paul's time regardless of geography


• all saints facing problems of fornication, idolatry, etc (see 5:1) regardless of geography or time


• all saints with or without such problems regardless of geography or time


• all persons regardless of religion, geography or time

These are but a few conclusions that could be drawn about the applicability of this particular statement. The problem arises in that a strictly concrete application of Paul's statement makes the Scriptures purely an historical document with little use for modern application. However, abstracting Paul's statement to apply to every circumstance certainly loses some of the context the author originally intended and in this case even condemns our Lord himself for associating with publicans and sinners. Whatever one's particular view on the matter, it's clear that practically any doctrine could be reasonably supported by appealing to a convenient location and the concrete-abstract spectrum.

I have a solution to these issues, but that will wait for another entry ... (I'd make Fermat proud).

Aravis, not the mountain range

Bouquetin à la Tournette
Originally uploaded by Loin des yeux.

Our daughter's name is Aravis. She's named after the character in the C.S. Lewis novel The Horse and His Boy. I searched for other photos on Flickr tagged with her name and came across some beautiful images of the Aravis Range in France. This one is particularly spectacular.

Review: Blink by Malcolm Gladwell

My wife and I finished Blink: The Power of Thinking Without Thinking by Malcolm Caldwell a couple nights ago. It was really a
fascinating book. The psychology experiments the author mentioned were amazingly clever. I
was particularly intrigued by the studies of the facial muscles and
cataloging all the possible expressions and their meanings. It was humorous to imagine university professors staring at each other and making faces. Nevertheless, the dedication of spending 7 years of one's life studying a single topic in such depth is admirable.

My wife and I disagreed with a couple conclusions the author made in the
book. The most egregious one was in the last chapter. He was talking
about blind auditions for symphonies and orchestras and saying that
the blind auditions had made classical music better. The disagreement
we had with is that he seems to have
forgotten his chapter on Pepsi vs Coke sip tests. In that chapter, he discusses the fact that Pepsi consistently performs better than Coke in blind sip tests. That success rate was what motivated Coca Cola's failure with New Coke in the 1980s. The point of the chapter was to say that nobody drinks soda at home in the form of a sip
test. Therefore, it doesn't really matter which cola performs better in that test. When people drink cola, they are aware of the packaging and all the associations they have with the brand. That awareness affects their experience of the beverage.

We saw that as exactly the problem with the blind auditions:
people don't listen to an orchestra or a symphony behind a blind. They
observe them in the concert hall. A conductor is perfectly
justified in choosing a musician based upon her appearance or the
expectations of his audience. If the audience is going to be distracted
from the music because a female is playing the french horn, that
detracts from the musical experience. Of course, when seleting members of an orchestra for recording purposes, blind auditions are rational.

Overall, the book was fascinating and makes for some good, light reading. I recommend it.