web

The Distributed Web

Jeni — Sun, 11 May 2008 22:07:29 +0100

XTech was subtitled “the mobile web”, but one of the major themes for me was that of the distributed web. The first keynote, by Simon Wardley, gave a vision of a future in which hardware, frameworks and applications are services in the cloud rather than products on machines we own: where we use flickr to store our photographs, Google App Engine to host our applications, and Amazon S3 to store our data. In David Recordon’s keynote (written up by Jeremy Keith), he talked about small, specific services provided by sites that aren’t “destination sites”. The same picture was painted by Gareth Rushgrove in his talk on Design Strategies for a Distributed Web.

So I was surprised at how contentious Steven Pemberton’s talk on Why you should have a Website (thankfully again documented by Jeremy Keith) proved to be. Because to me it seemed to be the logical extension to the distribution of hardware, frameworks and application: the distribution of data. In fact, I’ve written about the same idea myself, as has Leigh Dodds, more recently.

From the session, the main question seems to be “how could we do flickr without them holding our data?” I don’t want to particularly pick on flickr, especially because it’s not one of the worst offenders, but the problem of serving and sharing images does illustrate a whole range of issues, so I will use it as an example. I could just as easily be talking about ancestry.com. The way I see it, you need three levels:

providers which make information available in known formats
user interfaces which provide the end-user with a way to access and manipulate the information
brokers which locate information on the web and provide an aggregated interface

(It occurs to me that this is similar to a model/view/controller architecture: the providers give the model, the user interfaces give the views and the brokers control the flow between the two.)

Where flickr is at the moment is a conglomeration of the three: to have your photo appear on flickr, and to gain the advantages that it gives you in terms of tag-based aggregations and social networking, you have to upload it. They are then the provider of the image+metadata (perhaps the only place it is located on the web), the user interface on the image+metadata (the interface through which the image is annotated), and the broker (they provide keyword-based retrieval, for example).

What would it look like to separate those functions?

First, you, as the owner of the image+metadata, could put your data anywhere: on a home wireless network box, on a webserver hosted by an ISP of your choice, on a site specifically designed for hosting photos. Your data is exposed to the larger web through a standard read/write protocol (I’m betting on AtomPub) that allows you to provide metadata both about resources and the links between resources. The point of it being read/write is that it allows other people to add metadata to or links from your resource to others, such as adding a comment on your image.

Second, an information broker would locate your photos by crawling for them (or perhaps by you submitting the URL somewhere, but mostly that shouldn’t be necessary). There are already information brokers around: Google provides a RESTful API for general search results, as does Yahoo!; at XTech, Richard Cyganiak talked about Sindice, and Aidan Hogan about the Semantic Web Search Engine, both of which crawl for RDF triples and provide an API for querying the results. In an AtomPub-based environment, you’d want an information broker that located Atom feeds and resources, indexed them, and provided an AtomPub-based API for publishers to use.

Third, a user interface would provide an attractive and usable front-end that brought together many different sets of information. For example, flickr might combine your friends feed with an image search to provide a view of images recently made available by your friends. There’s no requirement for your friends to use flickr for this to work: flickr queries a broker for a list of your friends, then queries a broker for images by a particular person, the broker searches its index and points the application to the original resources that are provided by your friends.

A user interface has another role, though: to add to the web. Flickr wants to make it easy to add tags to photos, to create sets and collections that help you navigate your photos, for others to add comments and so on and on. And that’s fine, because AtomPub is a read/write API. To add a tag to a photo, flickr simply edits the resource with PUT. To add a comment, it locates the comment feed (which would be referenced from the entry for the particular image) and POSTs to create a new resource. And everyone can see those changes — the added value that you get from a social network.

None of this is to say that a single application can’t act as provider, broker and publisher at the same time, but I’m certain that users will favour those applications that do all of each role: provide to the whole web, broker the whole web, provide a user interface to the whole web. Flickr is almost there, but it doesn’t do the whole brokering job because it only brokers the data it provides, and therefore it doesn’t provide the whole user interface job.

This distributed web is a clear win, particularly for users, over walled gardens. They can switch from user interface to user interface, even use more than one at a time (perhaps one application is good for browsing while another is good for categorising), without any cost. They can choose who to use to serve their information on the basis of things that matter when you’re serving information (low downtime, backups, security, etc.) rather than on how pretty an interface looks or how much functionality it gives you. On the other side of the equation, applications get to do one thing and do it well.

It seems to me that this is simply how the web works, and the questions we should be asking are about privacy and trust and licensing and revenue models and standards development.

XTech 2008

Jeni — Sun, 11 May 2008 11:25:40 +0100

I finally have some time to write about XTech. What a great conference! I know that Edd would like it bigger, but its modest size gives it a family feel. Like a family gathering, there are pontificating oldsters whose wisdom goes largely unappreciated by young upstarts who themselves bring energy and innovation to the crowd. And a bunch in the middle trying to translate across the gap: to explain the vision to the old and the reality to the new.

Another way of putting it is the divide between the XML crowd and the Web 2.0 crowd. In Sean McGrath’s closing keynote, thankfully written up by Jeremy Keith, he talked about navigating the path between the document web and the programmable web, and the danger of tipping the balance too much in either one way or the other. XTech provides a great service in providing that balance, and of giving those of us with feet in both camps a home.

Particularly encouraging for me was to see some of the principles of the programmable web filtering into sites such as the Guardian and the BBC which aren’t part of the Web 2.0 vowel-deprived clique. It gives me hope for the public information sector, in which I happily find myself.

So many many thanks to Edd and to everyone who supplied me with alcohol, deprived me of sleep, and talked to me about tech. I can’t wait until next year.

APECKS, ten years on

Jeni — Wed, 16 Apr 2008 21:34:43 +0100

Roughly ten years ago, I was attending KAW’98. I remember that conference as one of the best weeks of my life. I had great company. I saw scenery like I’d never seen before. I presented my PhD work for the first time to people who were (at least politely) interested in it. And I learned a lot, both from the presentations and less formal discussions.

(I remember driving back to Nottingham when we returned; a rainbow appeared in front of us, seeming to arch over our destination in a perfect finale.)

Looking back at that paper is like looking at my past generally is: much of it makes me cringe, but parts of it are surprisingly good. What’s interesting is that if you swap a few terms for modern buzzwords, it’s still a pretty neat idea. It’s also amazing how far we’ve come — how much has become common-place — in just ten years.

In modern terms, what I did was develop web-based social software, called APECKS, for ontology creation. The idea was that people would create their own ontologies (either from scratch or based on others), and the system would find similarities and differences between them, with the aim of starting conversations about and sharing knowledge.

APECKS was built on top of a web application framework written in a dynamic programming language. We didn’t have Ruby on Rails in those days: I turned a MOO (a text-based virtual reality) into a HTTP server (with caching and everything!) and that formed the basis of the application.

APECKS was designed to use (lowercase) web services. It used one for some of the complex ontology comparison that it needed to do. RDF was nowhere near done; OWL not even in a twinkle in its parents’ eyes: nowadays, you’d build around those formats, which fit fairly well onto the KIF-based formalism that APECKS used. (The lack of a standard way to make the captured knowledge available was one of the reasons I got interested in XML — we’ve just celebrated that 10-year anniversary too.)

APECKS captured change history and design rationale as well as supporting unstructured communication between users. It didn’t provide feeds because, guess what, feeds hadn’t been invented yet. If I were doing it today, they would be a major feature.

APECKS didn’t do REST properly, but that concept wasn’t around either! APECKS was also rather formal and uninventive in getting knowledge out of people (although it did use those knowledge-acquisition techniques that are automatable, such as card sorts). Now, you could make the interface so much better, because now we have AJAX.

Part of me wants to update it. The semantic web is going to happen, and we’re going to need tools that help people share and link together the ontologies that they create. Tools that help people create ontologies without being semantic-web experts.

But I’ve been there, and done that, and anyway I’m sure that today’s students are creating applications that are much more innovative.

PRESTO and the limits of XPath-based URLs

Jeni — Thu, 13 Mar 2008 20:18:56 +0000

Rick Jelliffe has been writing recently about PRESTO, most recently about the design of URLs based on the PRESTO system. In his latest post, Rick talks about using XPath as the basis of a URL scheme:

The Xpath for accessing a particular part’s title would be /law/part[2]/title so the PRESTO URLs would need some kind of convention.

[snip]

Now, I am not sure I understand the issues well enough to say which system for indexing is absolutely best. But I think the advantage of http://www.eg.com/law/part2/title over http://www.eg.com/law/part2/title is that it is probably a more common case that your system is interested in /law/part[2]/title rather than all titles of parts /law/part/title. But it is a matter of the particular use case and the consequent virtual schema.

This has particular interest to me because I’ve recently been involved in putting some of the UK’s legislation online. We don’t expose the parts/sections and so on as individual documents at the moment (although this is something that you get with the Statute Law Database, albeit with an awful URL scheme).

Anyway, we do have anchors for parts/sections within the main legislation which follow a similar scheme to the one that Rick suggests here. But they have a drawback: at least for consolidated legislation (which reflects the “current state” of legislation that has been amended by later legislation), the anchors don’t reflect the semantics of the numbering scheme used by the document. For example, see Section 5A of the Rent Act 1977, whose URL is:

http://www.opsi.gov.uk/RevisedStatutes/Acts/ukpga/1977/cukpga_19770042_en_2#pt1-pb2-l1g6

As you can see, the URL ends in a 6 rather than 5A because it’s the 6th Section that appears in the document.

The thing is that generic, position-based XPaths into content are seldom the ones that make most sense semantically. A friendly XPath to Section 5A would look like:

/part[1]/group[2]/section[3]

and even if you just counted sections it would be:

//section[6]

when what you really want is the equivalent of:

//section[number = '5A']

Given this, I wonder if a “striped” URL scheme would be better, by which I mean something that follows the general pattern /name/identifier/name/identifier. For example:

/part/I/section/5A

There are several advantages to this. The resulting URLs are more semantically meaningful than those based on positions. They are more robust to changes in the document (which naturally happen with consolidated legislation). They also provide a neat method of returning all the sections in a particular part, such as:

/part/I/section

(though you could get this advantage with a position-based scheme as well, depending on how you map from XPath to URL).

The main disadvantage is that you have to provide a custom mapping from XPath to URL, because it’s not immediately obvious what identifier to use for a given element: it might be a <number> element child for one kind of element, but an id attribute for another element, and the position of the child for some other element. Of course you could add annotations to your schema to indicate what acts as the identifier for that particular element type, but it does raise the implementation barrier.

Web 2.0 project: privacy in genealogy

Jeni — Thu, 17 Jan 2008 21:48:58 +0000

There were a couple of comments on my previous post about RDF and uncertainty in our Web 2.0 genealogy project concerning the problems of privacy in a genealogy app. My ideas about this aren’t fully thought-through, let alone implemented, but I thought I’d share them anyway.

First, the things we could restrict access to are:

sources of information (eg birth records)
personas (eg Charles Darwin) and assertions about them
events (eg the Beagle Voyage) and assertions about them
groups (eg the Royal Society) and assertions about them

There are different kinds of things you might do to the resources:

who can know it exists?
who can read it?
who can change it?
who can delete it?

and different levels of access for each of those things:

global (public)
group (restricted)
user (private)

I imagine that at any point, a user will have a default set of permissions in play. For example, they might be generating information that anyone can know exists and can read, but only a restricted set of people can change, and only the user themselves can delete.

Searchability

I’m going to side-track for a second here to explain why I’ve separated out “knowing something exists” from “readable”.

Our genealogy application is evidence-based, which means that to say that someone exists you must have a source for that information, be it a birth certificate or a picture or the transcription of an interview. The persona that you believe to exist on the basis of one source may or may not be the same persona that you believe to exist on the basis of a different source. A separate step is required to link the two personas together.

The intention is that our application will help you link personas (and events, groups and anything else that might be quoted in more than one piece of evidence) together through searching through other personas (etc) to find those that are similar. They might have similar names, but most of the evidence for similarity will come from similar assertions having been made about them.

Now say that I have some evidence about Charles Darwin and enter it into the system, and you similarly have some evidence about Charles Darwin that you enter into the system. We both create “Charles Darwin” personas based on our evidence. I’d like it to be the case that, even if we don’t want the information we’ve captured about Charles Darwin to be readable by others, we can still make it searchable so that others can find out we’re working on that person too so that (after some interpersonal negotiation) the two sets of information can be brought together.

So the “who can know it exists?” access is about making your information searchable, even if the details aren’t readable.

Default access

As I understand it, in genealogy circles it would be bad form to make any information about living people publicly available. Some would argue that any information that is currently publicly available (on the web, or even off it, in electoral rolls, phone books, wherever) is fair game: if it’s already “out there” then you can use it. But I don’t agree with that. There’s a big difference between there being multiple disparate, human-readable sources of information about an individual “out there somewhere” and providing a single aggregated public source for all this data in a computer-readable format. In short, I agree with Jeff “Coding Horror” Atwood’s recent post on privacy in which he characterises privacy as an inalienable right.

Also, some people make money from doing genealogical research, and it would be short-sighted to prevent people from using the application if they simply wanted to keep what they were doing private for their own reasons.

So there must be a setting such that information can be kept entirely private, to the extent that only the person who constructed it knows that it exists.

On the other hand, many of the benefits of Web 2.0 applications come from integrating your own material with other people’s. Genealogy is a good example of this, because there’s a distinct thrill in hooking into other people’s research and discovering other branches of the family.

So there must be a setting such that information can be made globally available to all and sundry, even to the extent of others changing and deleting it.

I think the default has to be that the information you enter is completely private. I’d like to encourage people to share their information, but I think that the way to do that is through social mechanisms (eg the more useful information you share, the more kudos you get) rather than technological ones.

User Groups

Public and private access aside, there’s a huge middle ground of access that’s somehow restricted to a subset of users. I don’t think I’m being particularly radical if I say that the current state of the art of social software access control isn’t great, that the “restricted” subset is usually to “my friends”, but people don’t have one social circle: they operate in different spheres, and have a different set of friends/colleagues in each.

The same is true in our genealogy app. A given user might be working (collaboratively) on several projects, with different teams. For example, I might work on a family tree with my mother for her side of the family and my father for his, with no need for either of them to be aware of the other (unless they overlap, in which case “searchability” comes into play).

So I think it makes sense to use the familiar notion from *nix of “user groups”, and assign each item (sources/people/events/groups) to one or more user groups. User groups will probably mostly arise from those working on particular projects, but could be more arbitrary. I’m thinking:

moderated (by-invitation) and open (by-subscription) user groups
private, public and restricted permissions on the user groups

The other thing I was considering here was having a notion of “degrees of separation”. If I entered details about our daughters into a family tree, I might be happy for immediate family, and their immediate family, to see them: a separation of two. I don’t know whether this kind of network-based user group would be useful or a pain to manage, or even implementable; it’s just an idea I had.

I am not a number!

Jeni — Fri, 30 Nov 2007 23:06:52 +0000

Questions of identity and privacy are rather topical at the moment, especially here in Britain where last week a database dump including the names, addresses, bank details of half the country, along with our children’s names and dates of birth, got “lost in the post”.

So what better time to announce a new online identity metric? My PhD supervisor, Nigel Shadbolt is the CTO of Garlik, so earlier in the week I got an invite to the launch of QDOS.

Like the online identity calculator that I wrote about before, QDOS gives you a score based on your online presence. However, this score isn’t just based on a Google search. It has four components (which are each represented by a different colour, and are combined to give a very pretty pictorial “fingerprint”; check out Tim Berners-Lee’s QDOS, for example).

The four components are:

popularity: “They say that it’s not what you do that counts, but who you know. It’s the same online – your digital profile is affected by the number of friends and contacts you have. So the more friends you have on social or business networking sites, the higher your popularity score.”
impact: “Your online impact is manifested by your credibility and influence across the web. If your name is widely referenced, or if what you have to say – whether through quotes or a personal blog – is read by a large group of people, then your impact score will be higher.”
activity: “Activity quantifies what you do online – how long you spend there, how many sites you visit, how often you buy and sell things and so on. The more you do, the higher your activity score will be.”
individuality: “In DNA terms we may be individual, but online it’s not so easy. Your individuality depends on the uniqueness of your name and other aspects of your identity. John Smith, civil servant, living in London, would have a low score because there may be a number of them in the city. But Xavier du Plessis, tightrope walker, living in Hartlepool, would be more unique and therefore more likely to score higher.”

From the descriptions of these facets, you can guess some of what they’re searching: friends lists on Facebook, MySpace, LinkedIn; Google searches and feed statistics; electoral rolls; companies house. The activity metric is probably the most perturbing; like the Facebook dispossessed, I don’t really want my online sales and purchases to be monitored, and it’s not immediately apparent how they could get hold of that information — even eBay identifiers are supposed to be unrelatable to your personal identity.

But it’s all powered by the magic of Semantic Web Technology, so I guess I shouldn’t be surprised by anything.

As usual, I found it hard to work out which one of my identities I should use. If you enter “Jeni Tennison” in the search box, you’re told that there’s one Jeni Tennison with a QDOS score and then get shown the QDOS score of the Coronation Street actor Jane Danson (Q3009). I suppose “Jeni Tennison” sounds similar to “Jane Danson” and I’m sure Jane Danson is more well-known than me — she has her own Wikipedia page, after all. Perhaps Semantic Web Technologies suffer from foibles we usually associate with slightly deaf elderly relatives.

My “Jenifer Tennison” identity gets translated as “Jennifer Tennison” (Q443), who I suppose could be a mis-spelled me, but who knows? There are no automatic links to pages that would help identify the person with that name, so it’s very hard to work out who it means. It looks like it’s pretty easy to add links for people, but to do that you have to be sure who the person is, and for most people a name isn’t going to be enough.

Of course, adding a postcode should help, but which one to use? We’ve moved house twice in the past two years, and I imagine a fair amount of data about me is still associated with one or other of my old addresses. Whichever postcode I use, with whichever name I use, I get the same message:

Results for: Jeni Tennison (postcode elided)

We have calculated your QDOS based on your name and postcode. To calculate a more accurate QDOS, click on ‘Claim your QDOS’ now.

The QDOS score that’s shown at this point seems to be a semi-random number around the 700-900 mark. My children have roughly the same level of QDOS scores as me. I know the almost-four-year-old spends a lot of time on CBeebies, but I think I have a little more online popularity, impact, activity and individuality than her (but maybe that’s just wishful thinking).

I did try to claim my QDOS, but:

We are currently in beta testing phase. If you would like to become one of our first users please leave us your email address and we will send you an invite as soon as we have space available.

and I haven’t heard anything in the last 24 hours, so I guess there’s no space.

The founders of Garlik (Mike Harris, Tom Ilube and Nigel Shadbolt) can all be found with a simple search. Mike Harris and Nigel Shadbolt have two entries a piece, which implies that the problem of multiple identities isn’t limited to those of us who commonly abbreviate our True Names. Tom Ilube and Nigel Shadbolt’s entries are private, which means you can’t tunnel down into their individual scores (or see any links that would confirm that they were the Tom Ilube or Nigel Shadbolt you were looking for).

The name “QDOS” reminded me of the concept of kudos as described in Iain M. Banks’ The Algebraist, where it’s used as a kind of currency amongst the Dwellers. But unsurprisingly, Garlik aren’t claiming your QDOS score actually means anything. Rather, they’re aiming to get people to think about managing their online identity (so they will pay for their online identity management product).

And I’m left once again questioning who I really am. Am I Dr Jenifer Tennison the knowledge engineer, or Jeni Tennison the XSLT expert, or Jane Danson the Coronation Street actor? (The latter had actually never occurred to me before, but that’s the power of QDOS!)

A sketch: personal APP servers and feed-based web apps

Jeni — Fri, 19 Oct 2007 22:27:58 +0100

OK, so I can’t remain a Luddite for long. What’s a technological solution to the posterity problem, in particular in regard to web applications that tuck away all your data in their databases, just waiting to be forgotten?

Well, what if web applications accepted information as feeds rather than through forms? The original data would be distributed rather than centralised. Web applications would use the web as more than a distribution medium: they would be of the web rather than simply on the web.

How it would work:

Keep your data on your computer (in XML where possible). Use whatever tool you like to create and edit it (by hand, using a dedicated standalone application, using a browser-based application in the manner of TiddlyWiki, or however), in some common markup language.
Serve your data through a web server that supports APP, and provide a feed that exposes the data. I’m not saying that this is easy for Joe Bloggs to do now, but if we’re talking about having web servers on mobile phones then surely it’s not long before having a personal web server is a matter of course, and why not with APP support? Feeds could be generated based on directory structures, or simply created as the main file format for a particular application.
Visit the web application that you want to use and point them at your data feed. They access, store and index your data, and relate it to the other data that they have stored from other people’s feeds. It’s their responsibility to keep their database up to date by doing a regular crawl of the feeds they know about; they don’t have to store all your data, just the bits that enable them to do their job.
Edit your data through the web application’s interface; it can update your data for you using APP. (The web application is a APP client, and you host an APP server.) That can include adding comments or whatever other community-level annotations you might expect.

Why bother?

You have all your data locally (although it might be mirrored elsewhere).
You can edit your data in whatever tool you want to use, but still use a funky “rich internet application” to view it and share it.
You can provide the same data feed to any number of web applications; you’re not locked in.
Because it’s stored locally, your data is available for viewing and editing even when you’re offline.
Because the important parts are cached by a web application, your data is available for viewing and editing even when you’re away from your normal computer.
Your friends can access your data directly in a peer-to-peer network.

The obvious problems:

Setup: Web servers aren’t that easy to set up and maintain at the moment, because they’re designed for the use of sysadmins who are quite happy hacking text-based configuration files. That could change (look at WiFi router setup nowadays compared to how it was a few years ago).
Security: you might not want everyone to be able to access the data you keep on your personal web server. So you’ll need a way of assigning user names and passwords to feeds, and only handing those over to web applications that you trust.
Server load: it’s not so much DoS attacks (which tend to have big juicy targets), but the fact you’re more likely to experience large volumes of requests if, say, a picture you host suddenly gets popular, and might not be able to respond to them, or might have to start paying heavily for the bandwidth. So sites that offer hosting will still be really useful, particularly for media that’s (a) large and (b) likely to be embedded in other people’s pages.
Schemas: you can’t split creation of XML from processing of XML unless you have some kind of mutual understanding about the markup language that’s used. This used to seem like a major stumbling block to me, but in fact people seem to be sensible enough to use standards where there are standards, write stylesheets to convert between languages, extend what exists with what they need in more-or-less acceptable ways and generally muddle through without spending years in meetings thrashing out a single consensual model. And Atom and APP are pretty good at supporting extensions and so on that would make that work.

My hope is that we’ll get round to trying some of these ideas out in our genealogy-based Web 2.0 project.

Posterity

Jeni — Wed, 17 Oct 2007 23:08:29 +0100

We just had photos taken of the children, and it’s put me in a reflective mood. Norm posted the other day about his experience with information/task management products:

Then it hit me.

None of them, with the notable exception of Tinderbox, seem to store the data in any open format. I was seriously considering one of these commercial black boxes for an important chunk of the data that drives my day-to-day life. The little voice in my head reacted viscerally when the observation was made: “What the hell you thinking, man! Stop that!”

I’ve been experimenting a bit with GTD applications recently, and have the same reaction as Norm. The two tools that I’ve tried, ThinkingRock and FreeMind, can both export to an XML format (and import too), which is great, no doubt about it, but you’ve got to remember to do the exporting to take advantage of it. I know me: I just won’t do it (even with my GTD tool to remind me to). What I really want is an application that natively stores its data as XML, preferably in some nicely structured, standard format. So even after I’ve wiped the original application off my computer, or moved the file from one computer to another, I can still read that file and (with a little XSLT magic) load it into something else.

This is possibly the biggest thing that bugs me about most of the Web 2.0 applications out there. Of course I’ve got to be connected to the ‘net to use them, and I’m not all the time (most particularly at tech conferences, it seems). But more important, they’ve got my data tucked away in their databases, out of reach. Some of them will let me export it, or get at it through an API, but that isn’t enough for me. I want it here, so that even if the company folds or I forget my login and password, or the key I used to encrypt my personal data from potentially prying eyes… even years later, I can still read that file. It’s part of my history, but I won’t remember to keep it until it’s gone.

I’m thinking, you see, about some of the things I did on computers years ago. A half-finished book I wrote when I was about 18. The code I wrote for my PhD. Letters from my university days. These aren’t from that long ago, but now here I am using radically different software, in a completely different world, and these pieces from my past are lost, irretrievable because of the formats used to save them (as well as the hardware on which they’re saved: it’s getting harder to read a floppy nowadays).

I read Glasshouse by Charles Stross a couple of months ago (well worth the read). It’s set in the far future, and contains the following passage:

“We know why the dark age happened,” Fiore continues. “Our ancestors allowed their storage and processing architectures to proliferate uncontrollably, and they tended to throw away old technologies instead of virtualizing them. For reasons of commercial advantage, some of their largest entities deliberately created incompatible information formats and locked up huge quantities of useful material in them, so that when new architectures replaced old, the data became inaccessible.

“This particularly affected our records of personal and household activities during the latter half of the dark age. Early on, for example, we have a lot of film data captured by amateurs and home enthusiasts. They used a thing called a cine camera, which captured images on a photochemical medium. You could actually decode it with your eyeball. But a third of the way into the dark age, they switched to using magnetic storage tape, which degrades rapidly, then to digital storage, which was even worse because for no obvious reason they encrypted everything. The same sort of things happened to their audio recordings, and to text. Ironically, we know a lot more about their culture around the beginning of the dark age, around old-style year 1950, than about the end of the dark age, around 2040.”

I’m looking forward to the end of the dark age. In the meantime, the photos of the children will be hardcopies in the shoebox at the bottom of the wardrobe. And I think I might try the index card version of GTD.

Claiming your online identity

Jeni — Wed, 11 Jul 2007 13:24:00 +0100

I (“Jeni Tennison”) manage to score 10/10 on the online identity calculator, thanks to having a pretty rare name and there being multiple archives of XSL-List, to which I was a prolific contributor in my early XML days. (I think I can also claim to be “Jenni Tennison”, “Jenny Tennison” less so, “Jenifer Tennison” is obviously the pre-XML me, and “Jennifer Tennison” not me at all, and quite rightly so.)

Anyway, I’ve just registered with claimID to get myself an OpenID, to lower the barrier to accessing certain sites. As well as getting a claimID URL (eg http://claimid.com/jenitennison) to use as an OpenID, you can also use the URL of your own web page as your OpenID identity URL which delegates to the claimID identity URL, by adding links to the claimID server in the head of the web page. (View the source of my home page to see what this looks like.) This provides some flexibility in the event that claimID stops functioning: I can move to another OpenID provider without changing my OpenID.

ClaimID uses microID to verify that the pages that you say you own are really pages that you own. A microID is a hash of your email address and the URI of the page, placed in a <meta> element in the head of the HTML page (or in the class attribute of a section of a page). It bothered me for a bit that other people could easily create this hash and put it on their own pages, claiming that I’d created them. Then I realised that microID’s for confirming your claim that you own a page, not for discovering who owns a page (the hashing algorithm is non-reversible), and the only person who can claim a given page (at least on any reputable site) using the email jeni@jenitennison.com is me.

So now I have to work out how to get Drupal to add the hash into the head of my blog pages, and to enable OpenID and microID for people who post comments.

Dopplred

Jeni — Mon, 18 Jun 2007 22:34:19 +0100

Norm Walsh invited me onto Dopplr, and like a fool I joined. Why, oh why, did I bother? I never leave home. All my “fellow travellers” know where I am. And it just makes me jealous knowing they’re jetting off to… let’s see… Montreal, Sebastapol, San Francisco, Redmond, Barcelona, Amsterdam, Limoges, San Jose, Toulouse, Berlin, Seattle, Monterey, Lahaina, Tokyo, Geneva, Naples, Prague, and so on.

Maybe I’ll pretend my immobility is a principled stance against superfluous air travel.