Google AppEngine for Personal Web Presence?

Some thinking aloud…
I’ve browsed through the Google App Engine gallery and the applications you can find there at the moment are pretty much what you’d expect: lots of Web 2.0 “share this, share that” sites. These are what you’d expect because firstly they’re the kind of simple application you’d build whilst exploring any new environment. Secondly because they’re exactly the kind of sites that are currently being released every which way you turn.
But for me App Engine is intriguing as it might provide an interesting new perspective on distributing shrink-wrapped packaged software. When Google take the lid off of the number of sign-ups, its going to be a simple matter for anyone to have their own App Engine environment. Forget cheap web hosting and the expensive and configuration overhead that that entails: just sign up for an App Engine account.
App Engine has the potential to provide an enormous number of people with a well-documented stable environment into which an application can be deployed.
It will be interesting to see if anyone seizes on App Engine as an opportunity to create a simple personal application that combines elements of all of the Web 2.0 favourites: bookmarks, blogging, calendar, photos, travel, and perhaps an OpenId provider. One that that makes me the administrator of all of my own data, but doesn’t scrimp on the options for other people to harvest, syndicate and browse what I’m uploading.
At the moment our online identities start out fragmented, because we have to push data into a number of different services. And then we strive for ways to bring that data together and knit it into other sites that we, or our social network, use.
But why not turn this on it’s head? And seize on App Engine as a way to avoid this early fragmentation and instead start out with a centralized, personal web presence; but one which seamlessly integrates with data in other spaces. The potential is in open data, and services that are built around it. So why aren’t we managing our own open data repositories and letting others offer us services against particular aspects of it?
The App Engine environment doesn’t involve any configuration on behalf of the end user, and I suspect you could probably create an App Engine Deployer using App Engine itself. So sign-up, deployment and upgrades could also be pretty straight-forward. Python seems well suited for creating a simple modular web application that could be extended to cover new areas as users needed.
Instead of using lots of different web applications, we can each have our own modular web application that is intimately linked into the web, and becomes the primary repository for the data you want on the web. Data portability follows from the fact that you’d be the administrator of your own data.
This would also change the nature of the kinds of applications that we’d need elsewhere on the web. Instead of lots of specialist databases, we need more generic services and more community/local/temporary aggregations.

Teaching a Six Year Old About Triples

I’ve written in the past about how both of my kids are star wars geeks thanks to Lego Star Wars. My son had a Star Wars Annual for Christmas which he’s been poring over, in that obsessive way that young boys do. Anyway, we got to talking about some of the relationships between the different characters: that Luke was Anakin’s son; that Anakin and Vader are the same person; etc. We went back and forth a bit as he was getting confused by some of the secret identities and the overall timeline (he’s not seen all of the films of course; he’s only six).
I suggested to him that we try drawing it out. I thought that this might help him get a better mental picture. I explained to him that we could try writing down the characters names and start drawing lines between them to illustrate the relationships.
He got it straight away.
Here’s what we came up with after about half an hours work. Click through to see the larger image:

We started out in the bottom left with Luke, drawing an arc from him to Anakin. I suggested he label the line with “dad” to describe the relationship.
He then decided we should move on to Anakin and capture a fact about him next. We discussed this a bit, in particular, what would be a good name for the label between Anakin and Vader. He settled on “became”. We then recorded a further fact, that Darth Sidious “trained” Vader.
So far so good. He easily grasped the simple pattern of “X relates to Y” and also grokked a number of other things quite quickly. Firstly he reused “became” to record that Palpatine was also Darth Sidious, he saw that it was basically the same relationship. Secondly, he pointed out to me that “Anakin became Darth Vader” is actually a sentence. He also noted that my original suggestion of “Luke dad Vader” didn’t read very well! Finally he also saw that the technique was quite general: he observed that we could also capture facts about which weapons each of the characters used.
We also recorded a relationship between Luke and Vader: “fights”. After we’d drawn this out I pointed out to him that if Luke fights Vader, Vader is actually Anakin, and Anakin is Luke’s dad, then Luke must have been fighting his dad. This was the source of much hilarity. But he was easily able to see how this made sense from his drawing.
We rounded off the drawing with a few facts about the droids, which are a particular favourite of his.
I found the whole exercise quite interesting as it seemed to be a good way to lay out some facts in a way that was both amenable for teaching, but was also fun. I certainly didn’t force him into doing it. And a bit of father and son time never hurts.
Really its a testament to the simplicity at the heart of the RDF model, the simple triple, that it can be understood by a six year old.
(No, this isn’t an April Fool)