web

TAG F2F, June 2011

Jeni — Fri, 17 Jun 2011 10:44:12 +0000

As you may know, I accepted an appointment to the W3C’s Technical Architecture Group earlier this year. Last week was the first face-to-face meeting that I attended, hosted in the Stata Center at MIT. As you can tell from the agenda (which was in fact revised as we went along) it was a packed three days.

What I intend to do here is to briefly report on the major areas that we discussed and give a tiny bit of my own personal take on them. In no way should any of what I write here be judged as revealing the official opinion of the TAG, it’s just me saying what I think, and I’m not going to go into anything in depth because they’re all incredibly gnarly and contentious topics and I’d not only be here all year but also end up in a tar pit.

Role of the TAG

Usefully for me as a newcomer, our first session was about the ongoing role of the TAG. The TAG occupies a unique position within the W3C. According to its charter it was set up

To improve the effectiveness of Working Groups, to reduce misunderstandings and overlapping work, and to improve the consistency of Web technologies developed inside and outside W3C

The TAG ultimately has three routes to do this:

by providing specific advice on issues that are brought to its attention
by writing documents on basic web architecture principles that go through community review, particularly through the general review of the W3C standards track and become Recommendations
by advising the W3C Director (Tim Berners-Lee) about what he should do on the extremely rare occasions when there are issues that he is supposed to adjudicate on

In none of these cases is there anything that binds the people receiving the advice of the TAG, or reading Findings or Recommendations made by the TAG, to accept them or do anything about them. The power and authority of the TAG depends solely on the quality and utility of its arguments, which is how it should be in my opinion.

Client-Side Application State

The first technical session was about client-side application state and was a review of the Identifying Application State draft that T.V. Raman began before he left the TAG and that Ashok Malhotra has been working on since. This should in the next few months or so be published as a TAG Finding (though it is currently on the Recommendation track).

This work is essentially about documenting the different ways in which you can identify application state within a URI, why that’s a useful thing to do, and some of the pitfalls of using hash URIs to do so. Most of the discussion was about details to do with wording within the document. One thing I thought particularly interesting was the point that URI-based application state is relevant in all ‘active content’, not just in HTML; for example, scripting in SVG or in PDFs bring the same considerations.

Buffer Bloat

Over lunch on Monday we listened to and discussed a presentation by Jim Gettys on buffer bloat. Basically (and all the errors here are introduced by me), TCP/IP is designed to route around network blockages, but it can only do so if it detects them quickly. When you have big buffers in place, as in the case of all modern operating systems and hardware, blockages aren’t detected quickly; they’re only detected when the buffers fill up. Then buffers empty and the data has to be sent again. The net result is that connections get really slow, not just for upload or download but for both, not just for you but for everyone using the network.

Jim talked about how this is exacerbated by the large amount of web traffic and the design of HTTP, particularly the lack of use of HTTP pipelining (whereby several HTTP requests and responses are sent over one long-term connection), because it leads to lots of small messages which can’t be handled effectively. There’s lots more about this on his blog.

Jim also talked about the failure of certificate authorities and how we should be looking at distributed protocols using digitally signed data, pointing us in particular to CCNx.

Fragment ID Semantics

First thing Tuesday was a session that I led on fragids, in particular the problems that are arising out of the mime type registration of +xml types (3023bis) clashing with those that are used for, say, images, and what happens when these come together in something like SVG.

The same issues arise whenever you have documents with types that ‘inherit’ fragid semantics from two directions. For example, XHTML documents are XML documents, so constraints on +xml mean you shouldn’t use interpreted fragids (eg hash-bangs) on them, but they are also ‘active content’ which makes interpreted fragids useful. Similarly, in linked data you shouldn’t really use a hash URI to mean a Person with a primary resource that provides as a response an XML document with embedded RDFa, because according to XML fragid semantics, such a URI should point to an XML element.

Basically the use of fragids has grown markedly outside their original scope and these situations aren’t really covered in the specs. I am now tasked to create a document that describes the issues and suggests ways forward. So that will be fun.

Telcon with IAB

The second session on Tuesday was a telcon with the IAB which has a similar role within the IETF as the TAG does within the W3C. This was a bit of a ‘getting to know you’ session, covering the work of the two groups on:

versioning and extensibility
security
privacy, including Do Not Track

and talking about opportunities to meet and work together on various topics like these.

URI Definition Discovery and Metadata Architecture

The afternoon session on Tuesday was spent on Jonathan Rees’s work on the Architecture of the World Wide Semantic Web, which covers, amongst other things, what people in semantic web circles call httpRange-14. At core, this is about the kinds of URIs we can use to refer to real-world things, what the response to HTTP requests on those URIs should be, and how we find out information about these resources.

Jonathan has put together a document called Providing and discovering definitions of URIs which covers the various ways that have been suggested over time, including the 303 method that was recommended by the TAG in 2005 and methods that have been suggested by various people since that time.

It’s clear that the 303 method has lots of practical shortcomings for people deploying linked data, and isn’t the way in which URIs are commonly used by Facebook and schema.org, who don’t currently care about using separate URIs for documents and the things those documents are about. We discussed these alongside concerns that we continue to support people who want to do things like describe the license or provenance of a document (as well as the facts that it contains) and don’t introduce anything that is incompatible with the ways in which people who have been following recommended practice are publishing their linked data. The general mood was that we need to support some kind of ‘punning’, whereby a single URI could be used to refer to both a document and a real-world thing, with different properties being assigned to different ‘views’ of that resource.

Jonathan is going to continue to work on the draft, incorporating some other possible approaches. It’s a very contentious topic within the linked data community. My opinion is while we need to provide some ‘good practice’ guides for linked data publishers, we can’t just stick to a theoretical ideal that experience has shown not to be practical. What I’d hope is that the TAG can help to pull together the various arguments for and against different options, and document whatever approach the wider community supports.

Can publication of hyperlinks cause copyright infringment?

The first session on Wednesday was another session that I led, discussing the Publishing and Linking on the Web draft that Dan Appelquist and I have been working on.

The aim of this document is to explain the tensions between terms that are commonly used in legal documents such as “possession”, “adaptation” and “distribution” and the way that publication works on the web, in which multiple servers may have copies of the same document (because they cache copies to make the ‘net go faster), automated agents may make changes to those documents (such as compressing or resizing documents, or merging Javascript) and people may refer others to those documents through linking.

We’re particularly keen to argue that linking to something is not the same thing as distributing it. The web’s power arises through its links, so it’s important that people are able to link to something without being worried about what happens when/if the domain they link to is taken over by something illegal.

Dan and I are going to continue to work on this document in response to various suggestions around organisation and terminology, with a view to getting some ‘friendly legal experts’ to look it over and then seeking wider review. The intention is for it to eventually become a Recommendation as this will give greater weight to it as a document for a legal audience.

API Minimisation and Client-Side Storage

There were then a couple of short sessions.

Dan talked about API Minimisation, which is the design principle that to increase privacy we should design APIs that enable people requesting information to say exactly what information they need, and return only that rather that everything known about a think. Dan’s put together an draft and should be calling for review for it soon.

Ashok then led discussion on client-side storage and we brainstormed around some of the architectural/design issues about which we might want to write if we were to put together a document. This work is at a very early stage.

TAG Priorities

After lunch, we had a session on TAG priorities where we discussed which of the various pieces of work that we’re doing should receive the most attention and had a quick review of who is doing what within the TAG.

Our basic problem is that a lot of this stuff feels quite urgent, and we want to be responsive, but with only 5-6 of us “actively involved” (which means 1 day/week) in drafting documents, and other TAG duties taking up our time, it feels like we have taken on too much work. Our focus for the next little while is going to be on responding to issues where our lack of response might either hold people up or cause longer term problems (for example the publication of contradictory mime type definitions), which means things like the document on publishing and linking on the web will need to bubble in the background rather than being the focus of activity.

HTML5 Last Call

Our final session, for which we were joined by Philippe Le Hégaret, was on the HTML5 Last Call documents. The TAG has raised various issues over the course of HTML5 development and want to follow up on how those issues have been addressed in the documents. Our role means that we’re responsible for making sure there’s consistency with other specifications, and that there isn’t anything that seems like it’s going to cause problems in the long term.

The part that we spent most discussion time on was the relationship between Microdata and RDFa. We talked about the precedents for having two specifications that do very similar things but with different approaches, such as CSS and XSL, and how this isn’t necessarily a bad thing so long as they don’t contradict each other and people can move between them easily (because they have the same conceptual foundations).

I’m going to save my opinion on this topic for another post. Suffice it to say that microdata and RDFa as currently specified don’t work well with each other but it’s not at all clear what the best path forward is. The TAG decided to recommend that the W3C set up a Task Force to look at what the best way forward might be.

Final Words

If you want links to the minutes of the TAG F2F, they’re available within the agenda or on separate pages for:

If you have anything to say on any of these topics, please send email to the TAG mailing list. Or you could comment here or email me directly if you like. Which leads me on to talking about what I’d like to do in the TAG.

One of the guidance notes for new members to the TAG says:

TAG members are elected or appointed not to represent their individual member organizations, but the Web community as a whole. We try to take that responsibility very seriously.

I do take that responsibility seriously. Web architecture has to be a combination of practice and theory, balancing approaches that work right now with a desire to not break anything long term. I do practical work developing web applications with HTML, CSS, Javascript, XML, RDF, XSLT, XQuery and so on and so on every day, but I know I don’t see all the difficult corners of the open web standard space: no one person can.

I can listen though, so that’s what I will try to do: listen, digest, reflect and act.

But I have limited resources. Unlike most of the members of the TAG, I am not employed by a large organisation that pays me for time I take on the work that I do for the TAG. The W3C kindly paid for my flights to and from F2Fs, but not hotels or expenses. I wouldn’t have taken this on if I wasn’t prepared to shoulder the financial burden, but if there is anyone out there who might sponsor my participation, I’d love to hear from you.

Opaque URIs != Unreadable URIs

Jeni — Sat, 25 Jul 2009 20:41:34 +0000

I’ve been talking about URIs a lot recently. One of the things that has bothered me about some of the conversations is the conflation of the concepts of “opaque URIs” and “non-human-readable URIs”. This is my argument for keeping the concepts separate.

The opacity of URIs is an important axiom in web architecture. It states that web applications must not try to pick apart URIs in order to work out information from them. Applications must not, for example, use the fact that a URI has .html at the end to infer that it resolves to an HTML document. It’s closely related to hypertext as engine of application state, in that opaque URIs should not be generated by web applications either: they must be discovered through links and the submission of forms.

But this has nothing to do with readability or hackability, both of which are extremely important for human users. Readable URIs help human users understand something about the resource that the URI is pointing to. Hackable URIs (by which I mean ones that people might manipulate by altering or removing portions of the path or query) enable human users to locate other resources that they might be interested in.

Before I go further, a couple of caveats:

I am not saying that every URI must contain a natural language identifier. An example is the URI for a school, which could include:

the name of the school
the unique reference number for the school
the record number for the school in the database that is being published on the web

Using the name of the school, as I’ve discussed, is probably a bad idea because of its lack of longevity. Using the record number for the school within the particular database that’s being published is entirely non-human-readable because there is simply no way of finding out what that would be for a given school. The unique reference number for the school, on the other hand, may be an obscure series of digits, but it is a meaningful one which renders the URI readable and hackable.

There are also times when uniquely identifying a resource using natural identifiers within the URI leads to incredibly long and complex URIs, in which case the ‘human readable’ version isn’t actually human readable. Introducing non-human-readable components is then the only option.

Back to my argument:

Why should URIs support humans doing things that applications must not? Because humans are intelligent. When humans hack a URI, they are aware that they are making a guess, taking a chance and might or might not end up at something useful. If they get a 404, or even more importantly if they get to information about something that they weren’t expecting, they are intelligent enough to recognise that the chance they took didn’t pay off. Applications aren’t intelligent. They can’t tell the difference between a right guess and a wrong guess, so it’s best not to let them guess at all.

Let me give an example. Let’s say that I’m creating a URI for a particular house. Here are two possible URIs:

http://id.example.org/house/NG9_3HZ/4
http://id.example.org/house/0aef0218

The first is readable and hackable. A human could change the house number or the postcode. They could remove the house number and expect a list of houses within the postcode. The second is not readable or hackable: there is no way to know what you would get if you changed the identifier within the URI.

Now it is true that an application accessing a site that used the URIs like the first could create those URIs programmatically whereas it couldn’t (perhaps) create a URI like the second. But if it did create the URIs programmatically it would be the fault of the application, not the fault of the URI.

As publishers, it is our responsibility to provide humans URIs that are meaningful and hackable, and to provide applications with the means of creating or identifying these URIs through forms and links. But it is not our responsibility to prevent applications from doing things that they should not do by deliberately obfuscating our URIs.

Versioning URIs

Jeni — Wed, 22 Jul 2009 22:16:20 +0000

Yesterday I went along to a workshop on developing URI guidelines for the UK public sector. Because of the current drive to get more UK public sector information online, and the fact that we have Tim Berners-Lee on board, there’s a growing recognition of the fact that we need URIs for the real-world and conceptual things that we talk about in the public sector: schools, roads, hospitals, services, councils, and so on.

One of the particular points of contention at the meeting was whether URIs for non-information resources (ie for real-world and conceptual things) should contain dates or version numbers, or not.

Let’s get some of the argument out of the way first. We are not talking about documents here. Documents will almost always have multiple versions, and if you care at all about maintaining a historical record you will want to refer to the previous version of a document. So dates or version numbers within URIs that refer to documents are often a really good idea. Even better if you have one URI without a date that consistently redirects (through a 307 Temporary Redirect) to the current version of the document.

Documents (that people read) are just one form of “information resource”: things that are information and therefore can be transmitted electronically. Other things in the world are “non-information resources”: things that are more than simple information and therefore cannot be transmitted electronically, such as schools, roads, hospitals and so on. A lot of things that we want to talk about (make RDF assertions about) are non-information resources. We give them URIs to name them, so that we can talk about them unambiguously, and we give them HTTP URIs so that we have a way of finding information resources (documents) that give us information about them.

Does the information that you get when you resolve a non-information resource URI change? Absolutely. A request to a non-information resource URI will respond with a 303 See Other that redirects to an information resource (probably without a version number) that itself redirects (307 Temporary Redirect) to a URI for a particular version of information about the resource. For example an identifier that means a particular school such as:

http://id.example.org/education/school/78

can 303 redirect to the current version of a document that contains information about that school, such as:

http://www.example.org/education/school/78

which will 307 redirect to a particular version of information about that school, such as:

http://www.example.org/education/school/78/2008-09-01

The date is in the URI for the information resource (the information about the school), and therefore it doesn’t need to be in the URI for the non-information resource (the school).

OK, but say that the identifier for a school changes over time. Let’s say that you’ve designed your URIs for schools like:

http://id.example.org/school/bracknell-forest/broadmoor-primary

and the name of the school changes. Now the above identifier isn’t applicable any more, and any RDF statements out there on the web that have used this identifier are now talking about something that no longer exists. How do you deal with this?

Well, the first rule is that non-information resource URIs must not include information that is likely to change. That’s why a lot of URIs contain numbers rather than names. So we shouldn’t have included the name of the school in the URI? OK, we’ll use a number instead:

http://id.example.org/school/bracknell-forest/78

Hang on. Bracknell Forest is a council, and historically it’s been known for councils to change, either in their boundaries (which would mean that a school would move council) or in its name, or they are merged, or… well, there are lots of things that could happen to a council. So in the face of all these possibilities, and given that we no longer need the council name to disambiguate the school name (because we have a number instead), we can employ a second rule: non-information resource URIs must not include unnecessary hierarchy. We can eliminate part of the path and still identify the school:

http://id.example.org/school/78

And so we come to the final thing that could change: “school”. Now surely, you might say, the concept of a school cannot change. And maybe you’re right, maybe it won’t. On the other hand, in the UK we have in the past had things called polytechnics), which are now known as universities, so the types of educational establishments that we have do change over time.

We could do a bunch of things to help prevent a conceptual change like this from requiring a change to the URI:

we keep the number of concepts named within the URI to a minimum (eg don’t have both ‘education’ and ‘school’)
we use wide terms rather than narrow terms (eg use a generic ‘school’ rather than having separate ‘grammar-school’, ‘primary-school’ and so on)
we could change the term ‘school’ to a code (eg use ‘C3X0’ instead of ‘school’), but I don’t think this will help: you’ll still have problems if ‘C3X0’ and ‘F9R2’ mean the same thing in the future, whatever they’re called.
we could eliminate the concept term from the URI altogether, and label everything under one flat naming scheme, using something that has billions and billions of possible combinations. I know, a UUID! No, I’m not serious.

And so we come to the question of versioning the URIs themselves. This is what Tim Berners-Lee says in Cool URIs don’t change:

I’ll go into this danger in more detail as it is one of the more difficult things to avoid. Typically, topics end up in URIs when you classify your documents according to a breakdown of the work you are doing. That breakdown will change. Names for areas will change. At W3C we wanted to change “MarkUp” to “Markup” and then to “HTML” to reflect the actual content of the section. Also, beware that this is often a flat name space. In 100 years are you sure you won’t want to reuse anything? We wanted to reuse “History” and “Stylesheets” for example in our short life.

This is a tempting way of organizing a web site - and indeed a tempting way of organizing anything, including the whole web. It is a great medium term solution but has serious drawbacks in the long term

Part of the reasons for this lie in the philosophy of meaning. every term in the language it a potential clustering subject, and each person can have a different idea of what it means. Because the relationships between subjects are web-like rather than tree-like, even for people who agree on a web may pick a different tree representation. These are my (oft repeated) general comments on the dangers of hierarchical classification as a general solution.

Effectively, when you use a topic name in a URI you are binding yourself to some classification. You may in the future prefer a different one. Then, the URI will be liable to break.

A reason for using a topic area as part of the URI is that responsibility for sub-parts of a URI space is typically delegated, and then you need a name for the organizational body - the subdivision or group or whatever - which has responsibility for that sub-space. This is binding your URIs to the organizational structure. It is typically safe only when protected by a date further up the URI (to the left of it): 1998/pics can be taken to mean for your server “what we meant in 1998 by pics”, rather than “what in 1998 we did with what we now refer to as pics.”

Let’s spell out the danger with some examples. Let’s say that in 20 year’s time, nurseries and primary schools merge into ‘schools’ and secondary schools, sixth-form colleges and universities merge into ‘academies’. A particular primary school currently known as:

http://id.example.org/school/78

will continue to be known by that URI. A particular university currently known as:

http://id.example.org/university/307

is now known as:

http://id.example.org/academy/79

To support these changes, we have to set up some 301 Moved Permanently redirects; http://id.example.org/university/307 has to redirect to http://id.example.org/academy/79. The RDF found at the end of the new URIs has to include owl:sameAs triples that link the new URIs back to the old ones, to indicate they are talking about the same institution:

<http://id.example.org/academy/79> owl:sameAs <http://id.example.org/university/307>

or this would be derived from the 301 response.

Similar changes may or may not happen within the RDF hosted elsewhere that talks about these institutions. Since it can be discovered that they are identical, there’s no real reason for anyone to start using the new URIs unless they want to.

Then 30 years later, the government of the time decide to create a new kind of institution which they call a ‘university’. The university of 50 years hence isn’t actually the same as the ‘university’ as we mean it — they are virtual meeting places for independent researchers, each centered on a particular topic of study rather than a physical location — but they need URIs. And since they are called ‘university’ that is the name that should be used in the URI. Now someone mints the URI:

http://id.example.org/university/307

But disaster! This University 307 is not at all the same as the old University 307, now known as Academy 79. The same URI has been used for two different things. Redirections halt, graphs are smushed, distinctions are lost and fallacies haunt the web.

TimBL’s solution to this possibility is for every URI that includes a topic to include the year in which the topic was minted. So we would have:

http://id.example.org/2009/school/78

that remains the same, and then:

http://id.example.org/2009/university/307

redirecting to:

http://id.example.org/2029/academy/79

and the introduction of:

http://id.example.org/2059/university/307

which can be guaranteed to be distinct from http://id.example.org/2009/university/307.

This, to me, is the crux of the argument for including a version inside the URIs that you use for non-information resources. It means that you can reuse old terms with new meanings within URIs without breaking the web.

On the other hand, many people, myself among them, really dislike the use of years or version numbers within URIs for non-information resources (unless, I should say, they are used as part of the identification of the resource). I think there are four main reasons:

they are additional cruft that add to the length of a URI but provide no information about the thing being identified
they can give a misleading impression about the relevance of a concept; for example FOAF is stuck at version 0.1 (http://xmlns.com/foaf/0.1/) despite being widely used, while http://www.w3.org/1998/Math/MathML is feeling distinctly old (in internet time) despite being under active development
it leads to a proliferation of URIs and creates additional work for people who want to keep their URIs up to date, even when the concepts themselves don’t change (such as for the primary school’s URI above)

In essence, the likelihood of a term being reused with a different meaning seems low enough that the cost (in readability, understandability and maintainability) of supporting URIs that contain versions or years doesn’t seem worthwhile. We can keep the likelihood low by using terms that are unlikely to change their meaning (particularly avoiding those that have more than one meaning) and by disambiguating them (for example by using ‘train-station’ rather than just ‘station’).

There is also, perhaps, a middle way here that can keep the majority of URIs clean without leading to overlapping names. That’s to start with a URI scheme that does not include a version number or year, and only to start introducing them when it becomes necessary due to the reuse of previous terms. In the example above, in 2059 we might have:

http://id.example.org/school/78
http://id.example.org/academy/79
http://id.example.org/university2.0/307

In other words, we make a decision now that our future selves will have to act upon. All we have to worry about is our future selves caring as much about persisting historical URIs as we do about persisting our current ones.

What do you think? Should versioning be avoided in URIs at all costs, or always be included just in case? Are there other arguments for or against including versions or years in URIs? What other design considerations are there that help prevent changes to URIs over (long periods of) time?

Your Website is Your API: Quick Wins for Government Data

Jeni — Sun, 01 Feb 2009 09:28:57 +0000

This is the talk I prepared for the UKGovWeb Barcamp, in blog form. It’s probably better this way. Most of what’s written here seems blindingly obvious to me, and probably to most readers of this blog, but maybe Google will direct someone here who finds it useful.

Working with public-sector information on the web, one of the things that I take an interest in is making government data freely available for anyone to re-present, mash-up, analyse and generally do whatever they want to do. This post is born out of a feeling that the people who control data don’t realise that the smallest changes can be beneficial: they don’t need to do everything right now, just something.

There are three fundamental things that you need to do:

identify the data that you control
represent that data in a way that people can use
expose the data to the wider world

but you can choose the degree to which you do each of these things.

Identify

Take a look at what data you have some kind of responsibility for or control over. You might be a PDF containing a table of schools in the local area and their intakes over the last couple of years. You might have a spreadsheet of the amount of money assigned to maintaining the playgrounds within the borough. You might have a database of company information. You might have a set of HTML agendas for court cases.

The first step is simply to identify what the information is about. Schools, playgrounds, companies, court cases — each row in your table or spreadsheet or database, or each section in your document will be about something. We call this a resource.

To play nicely with the web, every resource should have an identifier. A Uniform Resource Identifier. A URI. That URI tells us where we can find information about the resource (we’ll get to what those look like later). So your second step is to work out URIs for each of your resources.

Now, there are actually three levels of URIs that you can care about:

identifier URIs
document URIs
representation URIs

You probably already have document and representation URIs on your web server. Representation URIs are URIs for particular formats and languages and views of the information that you make available. Document URIs are typically the same URI without an extension; web servers use content negotiation to work out which representation to serve up when a web browser asks for the page at a particular document URI.

So you already have a URI for the PDF that contains the table of schools, for the Excel spreadsheet about the playgrounds. You already have URIs for the results of a particular query on your database, and of course the HTML pages that you deliver have URIs already. That’s all in place. You don’t want to change it.

But identifier URIs are what are really important when it comes to opening up your data. They shift the focus from the documents that you serve to the resources that they are about. By assigning URIs to resources, you enable other people to talk about them. Even if that’s all you do, you have done good.

For example, if Companies House stated that companies could be referred to using URIs of the form http://www.companieshouse.co.uk/id/company/{registeredNumber} then other people who needed to talk about companies (websites containing customer feedback, monitoring companies going into receivership, displaying stock price information, whatever) could use these URIs whenever they referred to a company. If all websites that make data available about companies point to the same identifier for a company, then it’s possible to pull that data together very easily.

Now the URIs that you use should be short, clean, readable, hackable, hierarchical and so on. If you can, you should use a natural identifier for the resource within the URI for that resource. So URIs for registered companies should use their registered number. URIs for schools should use the school’s unique reference number (URN). URIs for playgrounds could use the name of the playground (scoped within the council responsible for the playground). URIs for court cases should include the court, the year, and the case number. And so on.

Remember as you’re creating these identifier URIs that they are nothing to do with the structure of your website or the user’s experience of navigating through your website. For navigation, you might want to group schools into primary, secondary and sixth-form, but you shouldn’t do that in the identifier URIs. To help decide, imagine someone wanting to construct a URI and the information that they need to do so. If any of the information they need can be derived from other information (as a school’s type can be derived from its URN), leave it out.

When you’re doing this, you might realise that actually you shouldn’t be the one in control of these URIs. If you’re not the one assigning the registered number, URN or case number then there’s probably a higher authority that does assign those (real-world) identifiers. Don’t let that stop you creating URIs — you’ll still find them useful for identifying your information about that particular resource — but do look to see if there are existing URIs that you could point to and reuse whatever scheme they’re using if there are.

Represent

So I said in the last section that assigning URIs to resources was useful. And it is. But it’s even more useful if you provide some kind of response when someone requests those URIs. A request for a URI can be done by a web browser or one of those search-engine-spider-things that crawls the web looking for data. Requests are done on the web using HTTP (hypertext transfer protocol), specifically using a GET request, which means “get this resource”.

When a web server receives a request, it sends back a response. The first part of the response is a status code that tells the browser, spider, or whatever issued the request, generally what kind of response it is. Now when a browser says “get this company” or “get this school” a web server should either respond with a 404 Not Found response or a 303 See Other response.

If the company or school doesn’t exist, a web server should respond with a 404 Not Found response. It’s actually really useful to give appropriate 404 Not Found responses, because it tells whoever made the request that the resource (company/school/playground/court case) doesn’t exist. This can act as simple validation: if I’m building a site that parents can use to rate schools, and a parent enters a URN into a form, I can construct a URI based on that URN, try to GET the information about that school, and if I get a 404 Not Found response then I know that the parent has entered an invalid URN.

If the company or school exists, a web server should respond with a 303 See Other response that points the browser to a document URI that contains information about the company or school. After all, the web server can’t very well deliver the company or school itself into your lap; all it can do is give you information about it. 303 See Other means “if you want information about that, see that other thing over there instead”. The “other thing over there” will be a document of some kind. It might be the PDF that contains information about the school, or the spreadsheet that contains information about the playground.

Simply giving a yes-this-exists or no-this-doesn’t-exist response is useful. Even if that’s all you do, you have done good.

It’s even more useful, though, if you can make the information that you have about the school, playground, company, court case or whatever, available in a format that can be processed by a computer reasonably easily. PDFs are really really hard to extract information from, so do everything you can not to use PDFs. Word documents and Excel spreadsheets are next worse; if you have to use them, keep them really really simple and definitely don’t use Word Art or embed images to display your data.

You should always make your data available in HTML. Try to make it as clean and regular as you can; use microformats to indicate information about people, places and events. If you want to push the boat out, use RDFa to mark up the data in your page even more explicitly.

The great thing about HTML is that it’s human readable as well as (if you do it well) machine readable. You can also make your data available in explicitly machine-readable forms as well if you want: XML, JSON, RDF/XML, whatever floats your boat. If there are already standard formats or ontologies for the kind of data that you’re making available, then use them, certainly, but it’s very likely that there aren’t. And in comparison to the nightmare of extracting anything useful from a PDF, it’s easy to transform between different formats, so you only have to concern yourself with different formats if you want to.

If you do provide multiple formats for your data, you should use server-driven content negotiation to deliver the data in an appropriate format to whatever’s requesting it. So a web browser will request HTML; a semantic web crawler will request RDF/XML; a Javascript program will request JSON and so on. The 200 OK response that the web server sends with your data should include a Content-Location header that gives the representation URI of whichever format is being returned, and a Vary header that tells caches how it’s decided which representation to serve up.

Expose

All the good work identifying resources and representing them comes to naught if you don’t expose it. You can (and should!) tell other people about the URIs that you’ve developed, but the best way to give them exposure is to use them yourself, within your website. Simply using the URIs within your website gives them exposure. Even if that’s all you do, you have done good. People who are interested in linking to you will look at your site and they will learn about your URI scheme from your use of it.

The identifier URIs that you’ve created might not be particularly easy to generate. For example, with the URI scheme that I suggested above for Companies House, unless you happen to know that Tesco Plc’s registered company number is 00445790, you’re not going to be able to get to information about them. So you should have a way of searching based on something that people will know, such as the name of the company. Use an HTML search form that makes GET requests like

http://www.companieshouse.gov.uk/company?name=Tesco Plc

The response should be a 302 Found that redirects (using the Location header) to the true identifier URI for the company (http://www.companieshouse.gov.uk/id/company/00445790). If it’s not possible to identify a single resource from the search string (for example, there are lots of companies with ‘Tesco’ in their name), then the correct response is a 300 Multiple Choices that provides a list of links to the possible URIs (in HTML).

There are other ways to help people find your data. If there aren’t gazillions of resources, you can list the URIs within your sitemap, which will make them discoverable by search engines. You can also list them on web pages and, especially for data that’s constantly updating, in (Atom) feeds which you link to from your HTML pages. Use metadata within the pages and feeds to help the consumers of your data work out what’s relevant to them.

To help even more, slice your Atom feeds into portions that different consumers of your data are going to be interested in. Slice by type, by area, by subject. That way people can stay up to date with just the resources that they’re interested in, and not be bothered with information about those that are irrelevant to them.

That’s It

What I’ve tried to describe here is the minimum that you need to do to help people use the information you have, and some of the other things that you can do to make it even more useful. Here are some things that you shouldn’t do:

don’t wait for someone else to define a URI scheme for the things that you want to talk about
don’t wait for someone else to define an XML schema or RDF ontology for your data
don’t wait until you can find the time and money to do it all “properly”

Just do what you can, now.

The Distributed Web

Jeni — Sun, 11 May 2008 21:07:29 +0000

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 10:25:40 +0000

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 20:34:43 +0000

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!)