An agile approach to the development of Dublin Core Application Profiles

1 Reply

I have been asked to provide a position paper for next week’s Future of Interoperability Standards meeting hosted by CETIS. This blog post is one I have been meaning to write for ages so I’m offering it as a position paper of sorts.

UKOLN has been charged by JISC with the task of supporting the development of Dublin Core Application Profiles (DCAPs) in a number of areas. While I have not (so far) had much direct involvement in this work I have developed, over the last year or so, a real interest in the process of developing these.

The development of DCAPs is governed through the application of the Singapore Framework for Dublin Core Application Profiles. In this document, the concept of the application profile is explained thus:

The term profile is widely used to refer to a document that describes how standards or specifications are deployed to support the requirements of a particular application, function, community, or context. In the metadata community, the term application profile has been applied to describe the tailoring of standards for specific applications.

The requirements for an application profile to be legitimately termed a Dublin Core Application Profile are defined within the Singapore Framework. In brief, a DCAP is a “packet of documentation” which includes the following elements:

Functional requirements (mandatory)
Domain model (mandatory)
Description Set Profile (DSP) (mandatory)
Usage guidelines (optional)
Encoding syntax guidelines (optional)

This seems mostly sensible although I have not been party to much of the discussion around the Singapore Framework and so I have never entirely appreciated the purpose of or need for the Description Set Profile (DSP). In passing I will note that it seems to me that the DSP could be optional rather than mandatory, and that the Usage Guidelines should be mandatory rather than optional.

According to the Singapore Framework web page, “there are no stable, published examples of full-blown application profiles that conform to these guidelines”. With one exception, Scholarly Works Application profile (SWAP), it is difficult to find any examples of DCAPs which are close to being realised. SWAP was developed for the most part at UKOLN so I have an interest in seeing it adopted; however to date we have seen no actual usage of this DCAP.

I come from a background of software and service development, rather than standards development. For this reason, the development of application profiles is more appealing to me than is standards development per se, as I expect to be able to apply my experience and skills more readily to work which is aimed at supporting “specific applications”. It is natural for me to measure success in terms of usage. This means that I take usability seriously, and tend to focus on users and their responses.

Early in 2009 I began to notice a few things about how DCAPs such as SWAP were expected to be developed. It seemed to me that usability was not a stated priority. As, I think, a consequence of this, there is little attention given to testing the usability of DCAPs within a context involving users and applications. It does seem that DCAPs are expected to be tested for conformance to the standard, for internal cohesion and logic in terms of the underlying information model, and even for theoretical satisfaction of functional requirements, but if the DCAP has not been tested for usability before it gets to this point then it is at high risk of failure. It was also apparent to me that users, even experts in the domain for which the DCAP was intended, might struggle to be able to appreciate, test or criticise the DCAP documented according to the Singapore Framework, unless they had relatively rare information management knowledge and understanding.

At UKOLN, I got together with some colleagues and proposed that we consider a more Agile approach to the development process. I use the term Agile in the sense in which it has been applied to software development in recent years. A key feature of Agile development is that it allows the development of not only the solution, but also the requirements, in a highly iterative process. Agile development tends to favour working solutions over future capabilities and encourages near-continuous engagement with users during the development process, responding to changes in functional requirements as both the developer and the user increase their understanding of the problem space. I wondered if we couldn’t devise some tools and techniques which would allow the early development stages of DCAP development to be done iteratively, with close engagement from prospective end-users. The following is a description of what we have developed so far.

An Agile approach

In order to focus on usability in the development of DCAPs, we realised that we would need to introduce a methodology which would allow us to frequently test what had been developed so far against user-requirements and understanding. Borrowing again from software development, we decided to adopt a rapid prototyping method, where we would give prospective end-users the means to quickly assemble information models which made sense to them in the context of their requirements. Some of our early experiments were in the domain of scholarly works because we have a particular interest there. Our method therefore relies on being able to assemble small groups of prospective users to participate actively in the development process.

We have observed an issue with users’ engagement with application profiles. Application profiles are, essentially, intangible – users cannot interact with them directly. For many users, this presents a very real barrier to engagement. Even if formal documentation such as Description Set Profiles (DSP) is developed during the development iterations, it tales a certain kind of user with a particular interest to engage with these. Many users need to see the sort of system interface which they will ultimately be using in order to contribute feedback on the development of an AP. We have developed two approaches to making DCAPs tangible, paper-protoyping and a flexible user interface tool for information modelling.

In early stages of requirements gathering, a paper-prototyping approach has shown real promise as an accessible method for eliciting requirements from groups of users. This has the advantage of being potentially very free-form, such that the developer’s unconscious influence on users’ contributions is reduced. Users are encouraged, collectively, to develop their own understanding and to model it. You can read about this in more detail in Emma Tonkin’s paper: Multilayered Paper Prototyping for User Concept Modelling: Supporting the Development of Application Profiles.

One limitation of paper prototyping comes from this very free-formedness: it is difficult to correlate the outcomes of a free-form modelling exercise with the outcomes of other similar exercises. For this reason, we have developed a second stage development tool which uses software to structure and, crucially, record, users’ engagement with the developing application profile.

Our software for allowing users to experiment with modelling their domain is MrVobi. Below you can view a short video of it being demonstrated on an interactive whiteboard:

Users are encouraged to use this tool to create and restructure entities and attributes through a user-friendly and intuitive interface. The user interface is is connected to a web service which records every decision, and which can hold and serve up pre-recorded models so that users can start from an advanced position in a given session.

As we move users from the free-formed to the more structured interfaces, we can start to gain an important benefit. By recording the decisions that individuals make about the information model, we can aggregate these so that, theoretically, we can start to assign a level of confidence to the decisions which are eventually made about the application profile. For example, we can say something like “this attribute belongs with this other in this entity, and 71% of our test users from this domain agree with this”.

As an application profile becomes more developed, it can be presented to users for testing through this same interface. This means, importantly, that an application profile can be treated as something more dynamic. As a domain changes over time, with shifting aspirations, challenges and issues, so the application profile can be re-assessed in terms of its usability in a changing context.

A concern which we identified early in the development of these processes and tools was the fact that the tools influence the testing process: when a user gives feedback, they are to some extent commenting on the artificial interface as well as the application profile. The paper-prototyping patly mitigates this, as does the simple fact that we don’t rely on a single interface. Within the very real constraints of users’ patience and available time, the general approach is to introduce as many types of interface as the user can bear so that biases based on the idiosyncrasies of specific tools are gradually cancelled out.

To bring this back to the Singapore Framework: we believe that we are evolving an effective process to develop several parts of the ‘package’ – the functional requirements, the domain model, and the usage-guidelines. We believe that if these are developed with frequent recourse to user-testing, then the resulting DCAP will be more robust, and more likely to be adopted. We think that we can build into the process an aspect of evidence gathering to allow to make assertions about the resulting DCAP which are based on a certain degree of confidence.

This is very much a work in progress. We have experimented with the paper-prototyping approach with a number of different groups, and in more than one domain, with some very interesting results. We ran an interactive workshop at last year’s International Conference on Dublin Core and Metadata Applications using the MrVobi software which was very well received (this was informed by a presentation which is also a useful overview). We have received strong encouragement from the Dublin Core Metadata Initiative to continue to develop this approach and are now considering how how we might take this work forward in 2010. Any comments are welcome.

Note

This work has been been the result of collaboration within UKOLN. Special mention should be made of Emma Tonkin’s efforts which have been crucial in a number of aspects of this work. Others at UKOLN who have contributed are Andy Hewson, Talat Chaudhri, Mark Dewey, Stephanie Taylor, Julian Cheal and Tom Richards.

Direction counts!

2 Replies

I took advantage of an offer to upgrade my iPhone 3G to the 3Gs model just before Christmas. I spent some time considering the alternatives, and speculating about what might become available during the next eighteen months of my new contract, but I’ve been more than happy with the 3G so my decision was quite an easy one. The 3Gs offered three main improvements over the 3G:

a faster processor
a better camera
a ‘compass’

At first glance, these improvements seem quite modest. But, as we shall see, they add up to something quite significant.

The feature which attracted me mostly was the better camera. People talked about the paltry 2MP camera on the iPhone 3G but to be honest it wasn’t the resolution that was the problem – 2MP is actually adequate for the sorts of pictures I want to take with a pocket camera. The problem with the camera on the 3G was that it was just a rotten camera. I had a better camera in a Sony Clie PDA some five years ago. The camera on the 3Gs is, indeed, better than that on the previous model. It’s not great, but it is just about usable.

The surprise for me is the impact of the other two features. The faster processor was firmly in my ‘nice to have’ category – a welcome improvement but not especially important to me. Once I tried the new model however, I quickly realised what a difference this has actually made. With the previous model, I had attributed a lack of performance in certain applications to network latency. Essentially, I believed that a few apps were simply a little too advanced for the prevailing networks to serve them well. A good example of this was Evernote, an app which seemed promising but was just too sluggish on the 3G to be very useful to me. On the newest iPhone however, Evernote really flies, and network latency does not often impinge on it’s usability. Having a snappier user interface is always nice – but the 3Gs is so much more responsive as a result of its faster processor (and presumably its increased memory).

I had assumed the compass was, effectively, a gimmick. I could see how it would be occasionally useful to orient myself when using the GoogleMap application for example. But over Christmas I started to play with some of the many astronomy apps available for the iPhone. Several of these take advantage of the iPhone’s built-in GPS receiver and compass, allowing the screen to show the night-sky exactly as it appears to the user based on their location and the direction they are facing. This allowed me, for instance, to identify and point out Jupiter to my actually-quite-impressed-for-once family. Direction counts!

What the iPhone 3Gs offers to its applications is a sense of location and direction. Combined, these properties can afford a powerful new functionality.

During 2009 there was a little buzz about augmented reality, with apps such as Wikitude appearing for Android and iPhone, superimposing text and images over real-time views of the physical environment. While I try to avoid predictions for the new year, I’m confident that augmented reality apps will continue to develop, and will become more interesting, during 2010. All of the hardware ingredients – a fast processor, a decent camera, GPS + compass, are present in the iPhone 3Gs. I’m looking forward to what develops as a result.

Coincidentally, my good friend Peter just alerted me to an application called Star Walk. It doesn’t do anything that several other apps don’t also do, but it does it so beautifully. Like all Apple products, aesthetics count for much with the iPhone. When I fired up Star Walk I had a sudden thought – that the reality had just caught up with the aesthetics of mainstream science fiction. If you have an iPhone 3Gs, I recommend you spend the £1.19 for this application, if only to admire the way it looks.

Happy new year!

An infrastructure service anti-pattern

24 Replies

Last week I outlined an idea, that of the service anti-pattern, as part of a presentation I gave to the Resource Discovery Taskforce (organised by JISC in partnership with RLUK). The idea seemed to really catch the interest of and resonate with several of those members of the taskforce who were present at the meeting. My presentation was in a style which does not translate well to being viewed in a standalone context (e.g. on Slideshare) so I have decided to write it up here. I would very much welcome comments on this. (The presentation will be published on the Resource Discovery Taskforce pages and I will ask for this post to be linked to from there when it does appear).

The following diagram is meant to represent a design ‘pattern’ which I have seen often proposed, and sometimes implemented, in the JISC Information Environment (IE) as well as in the wider higher education (HE) sector in general:

It is my belief that readers who have been involved with the IE for some time will recognise this, at least in a general sense, if not in specific cases. In this arrangement, an aggregation of data is presented to the end user, through the development of a user-facing application or service. The user-facing service will in almost all cases be a web-interface, somewhat similar to the ‘portal’ concept of old but in a centralised, single, global deployment. Because it is generally accepted to be desirable to make such data available to other services (in keeping with the larger goal of interoperability through open standards), one or more machine interfaces or so-called APIs, giving access to the ‘backend’ of the system, will be offered. What this design pattern aspires to is a service implemented to be both user-facing service and machine-facing infrastructure component.

However, I contend that this is, in fact, what software engineers might call an anti-pattern. An anti-pattern is a design approach which seems plausible and attractive but which has been shown, with practice to be non-optimal or even counter-productive. It’s a pattern because it keeps coming up, which means it’s worth recording and documenting as such. It’s anti, because, in practice, it’s best avoided….

There is much which is implicit in this pattern, so I will attempt to surface what I believe are some hidden assumptions in a new version of this diagram: this is what this design pattern, once implemented, reveals:

In this second diagram, the orange colouring indicates the parts which actually get built and are supported; the yellow indicates the parts which might get built, but which won’t really be supported as a service – in a sense, this is stuff which is believed to work but actually doesn’t; in the case of the users, the yellow colouring indicates that their demand for this service is believed to exist; those components in the diagram which are neither orange, nor yellow, are the product of little more than speculation. In the end, the investment in creating a user-facing application based on an expectation of future demand which doesn’t materialise is wasted while, at the same time, the investment in providing unused machine interfaces is also wasted.

I believe that this design pattern rests on several assumptions which are actually fallacies, and is, therefore, an anti-pattern.

Fallacy 1: “Build it and they will come”:

While infrastructure services can, indeed should, be developed with future opportunity in mind, it is helpful to have an existing and real demand to satisfy, which the new development addresses. If the service is demonstrably useful to users, and is developed effectively with future opportunity in mind, then there is more chance of the service actually working, and of it being attractive to developers working on future opportunities.

Fallacy 2: Interoperability through additional machine interfaces:

Machine interfaces need as much specification, development, testing an maintenance as user-interfaces. Simply making a machine interface available through the adoption of a platform which has a built-in facility offering some standard interface is not enough. A system which proposes to offer three or four APIs is quite likely not going to support any of them adequately. I have argued before that ‘interoperability is not enough‘: in fact, this arrangement does not often lead to interoperability, let alone actual exploitation of the capability to interoperate.

Fallacy 3: People/organisations who can make good infrastructure are also going to be good at building end-user-facing services (and vice versa):

Effective infrastructure supports services which in turn support end-users. The skills and knowledge required to support service-providers are generally quite different from those needed to deliver good user-facing services.

I call this the infrastructure service anti-pattern because the result comes from conflated requirements to deliver both infrastructure (machine-to-machine interfaces) and compelling user-facing services and applications. The result can be something which satisfies neither requirement. The users, requirements and priorities are often completely different between these two problem spaces. I suggest that the following are some possible reasons for this anti-pattern appearing:

funding (naturally) tends to follow services, happy users and, importantly, new features.
funders like to see their investment showcased
infrastructure is mostly invisible making it hard to ascertain impact from users

Proposals for alternative design patterns

Here is a suggested alternative design-pattern:

In this design pattern, the API is developed before any user-facing application, or at least in parallel. An application is developed to exploit this API based on real users requirements. No service is developed until such requirements can be identified. This means that an API will be developed, and it will be being used in at least one case. Opportunities for third party integration for usage of the service are, ideally, identified beforehand. The API is properly supported from the start, or else the service fails completely. The value proposition being offered for further, opportunistic third-party developments, whether real or imagined, is now real and, crucially, supported.

An interesting alternative to this is the approach of combining the user-facing web pages and the machine-actionable API into one interface, through embedded RDFa for example:

It remains to be seen how this approach is going to work out over time, but we have seen hints of simpler approaches to combining user and machine interfaces in the past, such as RSS being styled to give a decent human-readable interface, or earlier attempts to do interesting things with XHTML.

I wonder if readers agree that the first diagrams represent an anti-pattern which they recognise. And would the proposed alternatives fare any better?

IDCC09

Linked, open, semantic?

26 Replies

During an interesting session called the ‘Great Global Graph’ at the CETIS conference this week I formed the opinion that, in the recent rush of enthusiasm for ‘linked data’, three ‘memes’ were being conflated. These next three bullets outline my understanding of how these terms have been used in recent discussions, including the CETIS session:

Open data: I see this as something expressed as a philosophy or, in more concrete terms, as a policy, such as that espoused by the UK Government. There are aspects of public ownership in this, but also a philosophical approach based on ‘openness’ and a rejection of the economic idea of value in scarcity of information. I think that specific technology does not come into this really: for example one concrete realisation of this policy in the UK is the Freedom of Information Act under which it is perfectly permissible for a data owner to supply data in any reasonable format and medium. Essentially, I generally take ‘open’ to mean accessible to all, notwithstanding conditions of use.
Linked data: This one is trickier, as the term is used in quite a precise way by some proponents, based on the principles of linked data form the W3C. There are others who prefer a looser definition. There have been some well-reshearsed arguments about this, which generally come down to whether or not RDF is a pre-requisite of linked data. I’ve become inclined to use the term in its more precisely defined sense, in recognition of the efforts going on in this space.
Semantic Web: This term introduces ‘semantics’ into the mix, by layering on ontologies allowing inferences to be made from the data itself.

It seems that these terms are often used together in the same discussions, and I suspect I could benefit from some separation of concerns in some of these discussions. It seems to me that the following are true:

data can be open, while not being linked
data can be linked, while not being open
data which is both open and linked is increasingly viable
the Semantic Web can only function with data which is both open and linked

Option 1 satisfies, in part at least, the drive to make available to the public data which has been paid for by the public and which might be useful to it. There are those (and I count myself among them) who generally believe that at present, for example, it would be better to quickly make the data open in some useable form than to delay this unduly while it is processed into RDF. However, there is a reasonable case to be made for not polluting information spaces with poorly prepared datasets.

Option 2 is an approach for organisations which want to take a more resource-oriented approach to managing and exploiting internal information assets. In the CETIS session an interesting idea was floated around how such an approach might go a long way to helping organisations address data-quality issues.

Option 3 seems increasingly viable. There is value in the ‘linked’ aspect, regardless of whether or not semantic layers are introduced. This is how the Web works after all, and much of the impetus behind Web 2.0 seems, to me, to have come from a healthy mixture of addressable and accessible information and human-mediated convention (e.g. ‘hackable URLs). Perhaps this is the ‘Great Global Graph’ and it’s just a matter of scale?

I’m very open to comment and argument on any of this. Perhaps I’m worrying unduly about these things being mixed up, but I do sense that this space could benefit from some clarity to match the excitement and endeavour.

Not ready to wave goodbye to email

11 Replies

Last week I posted a remark on Twitter:

Can’t help thinking that the idea that Google Wave will replace email rather misses the point….

The first response to this echoed my view on this suggesting that the real nature of Wave is rather harder to explain or understand, and implying that people fall back on a frame of reference with which they are comfortable. It certainly looks as though Google have anticipated this and offered some easily digested marketing messages. However, I also saw responses which suggested that some people still seem to be missing the point. One response insisted that Wave would only be successful if it was ‘integrated’ with email. I must confess that I still don’t understand this – I can’t really imagine what impact an integration between Wave and email would really have.

It seems to me that Wave is an ambitious attempt to exploit the idea that one future for the Web lies in social networked activity clustered around shared artefacts. Such artefacts, often what we still call ‘documents’, have been given the useful label social objects. At the centre of a Wave is a social object, with a series of applied and recorded operational transforms. Wave would therefore seem to be primarily about collaboration, as opposed to email or IM which are primarily concerned with messaging. Another way of looking at this would be to suggest that Wave is ‘object-centric’, as opposed to email which is message oriented with a facility to attach auxiliary objects.

The idea that Wave would replace email seems to be suggesting that we won’t need apples anymore because now we have oranges. This is not to say that Wave might not better fit some use-cases currently served by email – such as the problematic mode of collaborative editing of documents by sharing copies sent as email attachments. But even as we adopt better software for collaboration, there’s not much sign that we’re giving up using email. I don’t know about you, but my email inbox isn’t getting any smaller just because I use Google Docs, IM, Twitter…. Email has been tested quite thoroughly now over a few years, and appears to work quite well for asynchronous messaging!
Wave uses XMPP as its underlying protocol which is both interesting and important, but it is also slightly misleading as it implies an important connection with ‘instant messaging, which I think is illusory and unhelpful.

Wave is possible because the barrier of network latency is gradually being reduced. Real-time collaboration across the global network is now viable for many. Of course Wave is not the only game in town – other interesting approaches (mostly also using a variation on the pubsub paradigm) to the real-time Web, such as pubsubhubbub are being actively developed and experimented with. But Google Wave is important – because it’s Google who are doing it. It will gain a lot of publicity, and will likely play its part in driving a culture change allowing real-time collaboration across the global network to ‘go mainstream’. It should be remembered that Google’s Gmail, the poster-child for Web-based email, is still significantly smaller in terms of users than Yahoo and Hotmail.

Because Wave offers APIs to developers and users out of the box, I think it is going to be difficult to say what shape this new offering from Google will take once a significant number of people are using it. The ability to federate Wave services could be significant in this respect.

JISC Rapid Innovation Event

1 Reply

I have just spent an interesting and inspiring 24 hours at the JISC Rapid Innovation Programme meeting, which was organised by UKOLN (disclaimer: I work for UKOLN), and funded through the JISC-funded IE Demonstrator project. The venue chosen for the event was certainly an unusual one – the City of Manchester Stadium, home of Manchester City Football Club. I thought the venue worked very well for this event and would recommend it. The event was primarily aimed at developers from the JISC Rapid Innovation projects, but with a significant number of others delegates drawn from JISC programme management as well as the the wider developer community

With this event, we decided to address an issue that has become apparent as JISC has started to engage more directly with developers in the HE sector: developers are often untrained, and sometimes not naturally disposed to explaining their projects to others, especially when those others are not themselves developers. So we hit on the (admittedly somewhat artificial) exercise of requiring a representative of each project to deliver a 45 second ‘pitch’ to the assembled audience, which was recorded to video. The project reps were then given a 15 minute consultation with one of a set of panels of three ‘experts’, led by people from media and communications backgrounds, where they reviewed the video of their pitch and discussed ways of improving upon it. These were held in the Stadium’s executive boxes overlooking the pitch, which was pretty cool! The reps were warned that they would be required to deliver a new, improved 20 second pitch the following day….

This exercise was something of a gamble to be honest. We were confident that a significant number of the project reps would appreciate why it is important that they be able to clearly explain what their project is about in a few sentences, in terms that a wide variety of people might be able to understand. We hoped that the majority would be able to benefit from these exercises to the point where they could deliver a compelling, clear pitch for their project. The results, I’m really happy to say, were outstanding! The improvement over 24 hours was remarkable, and JISC now has a portfolio of clear explanations of the 40+ ‘rapid innovation’ projects, not to mention a group of developers better equipped to explain what it is they are working on.

As well as a training exercise, this event delivered a series of ‘lightening talks’, panel sessions and ‘show & tell’ opportunities – a set of features which has become a staple of developer-centric events. Twitter was actively used as a back-channel to the event so you can get a small sense of what was going on from that stream.

I also used this event to ‘officially’ launch the DevCSI project – but managed to cock up my presentation – by ‘losing’ my presenter’s display with all my notes. As I’d decided to go for a one word per slide approach for much of the presentation, this was a bit of a disaster for me. Oh well, I gathered some real interest in this nonetheless and some opportunities for events and other engagements. If you’re interested, you can read more about this on the project blog.

I’d like to extend a big thank-you to everyone who came, many of whom stepped some way out of their ‘comfort zone’ to engage with the ‘pitching’ exercise. I’d especially like to thank Mahendra Mahey (UKOLN) who did most of the organising together with David Flanders (JISC), as well as the ever-professional UKOLN Events Team (Natasha Bishop and Michelle Smith) who seemed to work non-stop for 24 hours. Our army of professional bloggers was fantastic, offering expert advice on the pitches as well as conducting interviews, all of which have already been transcribed to the IE Demonstrator Blog, with a large number of the projects. David Tarrant (Southampton University) and Julian Cheal (UKOLN) provided excellent technical support, maintaining a networked news service which was displayed all over the venue.

This event was a pleasure to be involved in – there was a great spirit of cooperation throughout which bodes really well for future events with the developer community.

No data here – just Linked Concepts

HEIs Get Facebook Fever (again)

10 Replies

Facebook rolled out its ‘usernames‘ function today. This is a new feature at Facebook which allows a user to claim their little bit of the Facebook namespace, along the lines of:


http://www.facebook.com/[preferred_name]/

The process started at 05:00 am UK local time – on a Saturday morning – yet several people in my social and professional networks got up early to claim their personalised Facebook URL. Not all were successful despite this determination, and some ended up having to settle for some variation on their preferred username.

As for me, I enjoyed a rare lie-in

So, why do people think this is important – and worth getting up at 05:00 for? And why am I not ‘bovvered’? From the various commentaries I’ve seen so far – blog posts and Twitter discussion primarily, here are some aspects & motives I’ve identified so far, and some of the issues I have with them.

Fear of someone else registering your preferred username

This seems to be the main reason for the 05:00 land-grab. The motivation for registering a username appears to be, primarily, a defensive one. I guess there’s a sense that this might become important. The majority of people, from my very limited straw-poll, seem to fall into this category. While I don’t personally feel the need, I understand this reasoning.

Wanting to be able to offer a neat & personalised Facebook URL for you or your organisation

This is covered by Brian Kelly – he describes the decision to register a Facebook URL for an organisational Facebook page as a ‘no-brainer’, and lists a few higher-education institutions (HEIs) which have rushed to register a URL.

In his post, Brian asks:

So tell me, what is the logic in having a personal or institutional Facebook account and keeping the long form for its address? Or are the tweets I’ve been seeing simply a minority view from the ideological purists….?

For some people, the personalised URL is immediately important as they intend to use it as a personal ‘identifier’. The motivations here are convenience – such a URL can be much more memorable, and ‘vanity’ – a personalised URL is undoubtedly more satisfying and attractive. (Note, I use the term ‘vanity’ here as it has been used by others in this context and I don’t intend any pejorative sense that this term might convey).

So, why was I lounging in bed rather than rushing to claim my Facebook ID, and why would I hesitate (‘ideological purity’ aside!) before registering and publicising a URL for my HEI?

I have a personal namespace, having registered the domain ‘paulwalk.net’. This is also my OpenID, through the use of delegation (I have already changed OpenID identity provider twice without changing my OpenID). I realise that maintaining a personal domain is not yet a mainstream activity – yet I’m frequently surprised by the fact that many of those generally very tech-savvy people in my professional/social networks do not bother to do this, instead investing a major part of their online identities with companies such as wordpress.com or Facebook.
Do you trust Facebook? How much? Because, by registering a Facebook URL and publicising it, you just tied a potentially major part of your online identity with the fortunes and behaviour of this company. As an individual, this risk might be worth the convenience perhaps. But as an HEI – why would you want to introduce this risk when you already own and manage your own namespace?
As an HEI, you will have, no doubt, invested considerably in establishing a strong URL-based online brand, being careful with search engine optimisation and the like. Why then would you introduce a competing URL which will tend to dilute your primary Web address’s prominence? It may be that some HEIs have, after careful deliberation, decided to base their online identity and the marketing of their organisation on the Facebook platform – but I’d be amazed if this were true. So what exactly is the point in establishing a public Facebook URL for your organisation?

An expectation that Facebook will become an OpenID identity provider in the future

More tech-savvy users recognise that the Facebook URL they claim could soon become an OpenID. If they are a regular user of Facebook, this could offer a measure of convenience in the sense that their identity provider will be also a service provider which they use frequently. But as the usability issues with OpenID (and there are several) are gradually ironed out, we can expect to see OpenID’s importance as an ‘identifying system’ rather than an authenticating mechanism come to the fore. Using Facebook (or any equivalent service provider) as an identity provider will make less and less sense.

Time will tell

It may be that I am wrong about these issues. However, I have challenged the HEI sector’s desire to jump on the Facebook bandwagon in the past, and I have not seen much evidence to convince me that Facebook is a significant platform for engagment with students. As part of a marketing strategy, it probably makes sense to maintain some sort of presence in Facebook – just as it might make sense to establish a presence in various other systems. But on the public Web, an HEI’s identity must surely be kept independent of any private commercial concern. The mechanisms for ensuring this are well established. And, increasingly, we can begin to apply these mechanisms to our individual identities.

Celebrating Ada Lovelace Day – Pattie Maes

5 Replies

Some time ago, Suw Charman-Anderson introduced the idea of an Ada Lovelace Day, to celebrate the achievements of women in technology. As part of this effort, Suw also created a ‘pledge’ on MySociety’s excellent and innovative PledgeBank service, which stated:

I will publish a blog post on Tuesday 24th March about a woman in technology whom I admire but only if 1,000 other people will do the same.

In her blog post, Suw says:

Women’s contributions often go unacknowledged, their innovations seldom mentioned, their faces rarely recognised. [...] Recent research by psychologist Penelope Lockwood discovered that women need to see female role models more than men need to see male ones. That’s a relatively simple problem to begin to address

Now, I will admit that in addition to wanting to support this excellent initiative for its own sake, I had another, related motive. When I read the original pledge I will confess that I couldn’t immediately think of a candidate to write about – which rather reinforces the point that Suw is making. In my day job I get to collaborate in one way or another with some talented women. One or two of them I really admire – but I won’t embarrass them here – some readers of this blog will know some of these women. There are some women I encounter in my professional life who will clearly carve out a place for themselves in the lore of their particular fields.

For some reason I set myself the following criteria for selecting a candidate:

they must have actually inspired me in some way, in a broadly technological context
they must have achieved a reasonable level of public exposure – ‘made an impression’ in other words

I found myself fretting about the fact that I couldn’t think of a woman who met these conditions (I should say that I can’t think of an awful lot of people, of either sex, who I would say have inspired me in this context). But a week ago someone mentioned ‘software agents’ in conversation, I started talking about the interest I had in this area in the 90s and then I remembered Pattie Maes.

In around 1996-97 I was writing my dissertation for my MSc on the area of software agents. I had prototyped some software which would follow the activity of users browsing the Web and harvest and collate pages of interest. My ‘Big Idea’ was to gradually establish an automated recommender system using agents acting on behalf of users across a University department. It never really worked because I was a naive developer at the time and made a bunch of poor tech choices but, hey, not such a bad idea. In the course of my research I discovered the Software Agents Group of MIT’s Media Lab, led at the time by Pattie Maes.

The aspect of my interest in software agents which really fascinated me was not so much the ‘software’, as the ‘agency’. Pattie’s work seemed to be focussed in this area, and she and her team were producing some very interesting results.

At some point in the writing of my dissertation, I remember I got very bogged down in trying to get something to work well enough to demonstrate some of the ideas I was developing. It got to the point where I was considering a rather drastic change of direction, abandoning this line of research entirely. Then I came across an interview with Pattie which I found utterly inspiring. I have just spent an hour tracking this down – I did not have a reference saved anywhere unfortunately, but I believe it was On Software Agents: Humanizing the Global Computer , even if this is not the source I used at the time.

Some highlights from this include:

Now that we have a network, it’s as though we already have our intelligent machine. It’s a huge distributed system in which, like an ant society, none of the components are critical.

and

The whole metaphor of direct manipulation, of viewing software as a tool that the user manipulates, was invented about 25 years ago when the personal computer was first emerging and when the situation for the user was completely different. Back then, the computer was being used for a very small number of tasks. It was being used by one person, who knew exactly where all the information was on the computer because he or she put it there. Nothing would happen unless that person made it happen. This was a very controlled, static, structured kind of environment.

The situation that a computer user faces today is completely different. Suddenly the computer is a window into a world of information, people, software. . . . And this world is vast, unstructured, and completely dynamic. It’s no longer the case that a person can be in control of this world and master it. So there is actually a mismatch between the way in which we interact with computers, or the metaphor that we use for human-computer interaction, and what the computer environment really is like today. I think we need a new metaphor.

and, in answer to the question: “Do you think the Microsoft 97 Office Advisor is an agent?”:

It’s a simple example of an agent, but it definitely is one. It’s just providing better help functionality, but it monitors your actions, and based upon the pattern of actions that you demonstrate, it recommends specific help topics to you. So it tries to recognize what your goal is and gives you help that is relevant to the current situation. It’s not personalized yet, it’s assisting me in the same way it’s assisting you, but it’s a first step. Hopefully people will like this first attempt, and Microsoft will take it further.

Hmmm – Well you can’t be right all the time. I guess some of us don’t miss that PaperClip…!

Reading this again, I’m struck by how much my subsequent work and thinking was influenced by this. I no longer maintain a close interest in software agents, but a particular paragraph leapt out at me as being highly relevant to my thinking and work today:

Definitely my priority is to build things that demonstrate the usefulness of this technology, so that it isn’t simply the next fad that everybody has forgotten about a year from now. I want to make sure that there is something substantial there. I’m less interested in coming up with the standards before we even know whether users want this stuff. [...] Yes, definitely. And I think it’s still too early to standardize agents and the languages they use. We need more experimentation first, more wild ideas that people try out, and different applications. Whenever you come up with standards you stop research and development right there, or at least slow things down a lot.

In the mid-late nineties, some of the best work of Pattie and her team was commercialised – notably with the launch of Firefly.com (now defunct). Around this time I had started reading Wired – only available as an import from the US at the time I think – and stumbled across a feature about Pattie, the work she was doing at MediaLab, and the business she had founded. It’s still an interesting read, and shows someone being successful both in the rarefied academic world of computer science, and in mainstream commercial entrepreneurship.

Pattie has moved on to other things at Media Lab, and now runs the Fluid Interfaces Group (great home page!). If you want to see the kind of cool stuff they do there, check out Pattie’s TED talk where she demos some very cool new technology developed by one of her students, Pranav Mistry.

Photo used under Creative Commons license. Copyright Wa-J.

paul walk's weblog

professional reflections