About Me

My photo
Web person at the Imperial War Museum, just completed PhD about digital sustainability in museums (the original motivation for this blog was as my research diary). Posting occasionally, and usually museum tech stuff but prone to stray. I welcome comments if you want to take anything further. These are my opinions and should not be attributed to my employer or anyone else (unless they thought of them too). Twitter: @jottevanger

Saturday, November 27, 2010

When should I give a toss about open source-i-ness?

Open source, or just the assurance of knowing there’s a fire exit nearby? What's more important to a museum?

I've never really got into the debate about open source software because, well, I can't really get into it. Sure, there are philosophical aspects that ring my bell a little bit, and there are pragmatic aspects too, but I don't have a feeling that using open source software is the only morally acceptable answer so, overall, I'm ambivalent. Ambivalence (or nuance?) makes for poor polemic, which OSS advocates never lack.

All the same it does often nag at me that I should bring together the strands of my thoughts, if only because the cheerleaders of open source software have such an easy case to make! And on the contrary side, those that use less open alternatives sometimes seem obliged to take oppositional defensive stances attacking OSS on principle: an equally bullshit attitude.

Clearly there is a philosophical question about the right of software developers to own and limit access to software; a right which is in direct opposition to OSS. Personally I think there's nothing morally wrong with asking people to pay for something you made, although obviously I think there's plenty that’s morally right about giving it away! There are people who think that buying software from a company is Inherently Wrong, or that buying it without having the right and ability to modify the source-code is objectionable and a dereliction of duty. I think merely that it's a bad idea quite a bit of the time. I think this, not because it's immoral to pay for software that you can't do with exactly as you will, but because practically speaking it may expose you to costs or risks that you should try to avoid.

So bollocks to the principle, what about the practical? At least that lets us have a discussion. There’s the question of having access to the source code, as well as permission to mess with it. Now I don’t know about you, but for me this has never been a strong reason to use Linux. I have less than zero intention or likelihood of getting under the bonnet of any flavour of Linux and messing with the source, any more than I’d learn C in order to rewrite PHP itself for my own idiosyncratic needs. The further up the stack you come, the more likely I am to want access to the source – there’s perhaps a 10-20% chance we at IWM might have to mess with the Drupal core at some level (undesirable as that may seem), as we implement our new CMS; and if I can ever get my head round Java I might even one day try to contribute to the development of Solr (realistically that’s more like a 1% chance). So it’s all about what bit of the stack you’re talking about, but much of the time diving into the source is only a very theoretical possibility.
Of course freely-licensed source code also means that others can tinker with it, and this may be a good thing – someone else can make you your personalised Linux distro, perhaps? Also, for better or worse, you do tend to see products fork. Sometimes this is managed well by packaging up the diversification in modules that share a common core – this can become a bit of a nightmare of conflict management, but it’s got its merits too. Again, PHP or Drupal are examples. If nothing else it’s a nice fall-back if you know that the source is open, just in case the product is dropped by its owner (or community). And on occasion closed code has been thrown open, sometimes with great success – see Mozilla, which emerged from Netscape and took off.

How about the community? Well as usual this is a multi-level thing. If you want a community of support for the users of a product, this is not just the preserve of open source. Sometimes OSS develops a huge community of users contributing extensions, plugins etc, and sometimes it doesn’t, and it’s the same for non-OSS. Lots of Adobe or Microsoft products and platforms have massive communities around them and the sheer volume of expertise, of problems-already-solved, around the implementation or use of a product might be more important than the need to change the product itself. Once again, it’s about what you or your organisation really needs, and the potential cost of compromise.

How about the question of ownership? If a commercial company has control over the roadmap and licensing terms of some mission-critical software are you not exposing your organisation by using it? Perhaps, yes, and sometimes it’s clear that OSS can buffer you from this risk, but other times we can get a nasty surprise. MySQL is now owned by Oracle. A bunch of changes to the licence happened this autumn, and whilst Oracle might be positioning MySQL for a more enterprise-scale future its suddenly possible to pay an awful lot for a licence, depending upon your needs. And Java? Sun owns this. It’s meant to be open source too, but ownership of the standard is complex and there’s an almighty struggle going on, with the Apache Foundation finding itself suddenly looking quite weak in the battle for control of the language that underlies most of its flagship products. And now we wonder, is even Linux going to end up open to a Microsoft attack? Some people worry that it could, following the sale of Novell. Symbian has been deserted by all its partners and is now being killed off by Nokia. If you want the Symbian source so you can plough your own furrow/fork your own eye-balls, you’d better grab it about now.

This is simply to say: the merits of OSS aren’t uniformly distributed, they’re not necessarily always of great importance in a given scenario, and sometimes they may not be worth the cost of those benefits. Cost and benefit is what should matter to a museum, not the politics of software development and ownership.

To be fair I should also mention the downsides of non-open sourced software, but for expediency I’ll just say: potentially any and all of the risks for OSS mentioned above and some more.

For instance, although it’s a truism to say that what is good for the consumer is good for business it’s not that simple - business. I need only say “DRM” to make the point (although where it’s been foisted upon music consumers they have voted against it and seen a partial roll-back) [edit 14/12/10: semi-relevant XKCD image follows]


The noxious Windows verification software which stops you from changing the configuration of your machine extensively – who asked for that except for Billg? A road-map determined by profit maximisation therefore doesn’t always seem to coincide with what the users want – see also Apple’s slow striptease of technology when they introduce some new gizmo-porn for an example. You want expandable memory with that? GPS? Video? You’ll have to wait a generation or two, perhaps forever.

Then there’s buying licences. At MoL we used Microsoft’s CMS2002, and in truth I’d had relatively little problem with the source-code being closed – it seemed to do what we wanted, had the power of .Net available to extend it, and there was little obvious need to mess with the “closed” parts. We got the software at a trivial price (about 1% of Percussion’s ticket price at the time, I think), but that wasn’t to last. CMS2002 was initially marketed alongside SharePoint Portal Server, but in due course the two were integrated into MOSS2007. When CMS2002 was taken off the market the only way to buy a licence for it was to get a MOSS2007 licence, and this (being a much bigger application) was about 10 times the price. Still cheap compared to much paid-for competition but no longer trivial. I wouldn’t have wanted to use MOSS2007 even if we had the resources to migrate the code but that’s what we had to buy and then downgrade the licence. I’d never even thought about the issue of licences being taken off the market, but of course if you want to add another production server (as we did) you have to buy what they’re selling. In principle they could have chosen not even to sell us an alternative or asked whatever they liked. Now that was a lesson for me, and that’s a genuine reason for avoiding products where licenses are at the discretion of a vendor.

So what really matters?

OK, so there’s a debate to be had over when it’s right and important to go open source. Is it a tool, or a platform? Does it offer you a fire-exit so you can take your stuff elsewhere? What’s the total cost of ownership? Have you sold your soul? And blah blah blah.

Most of the time, though, a more pertinent question is how one procures custom applications. Throughout my time as a museum web person I have always sought to ensure that when a custom application was built for us we required the source code (and other files) and the right to modify, reuse and extend that code. We didn’t necessarily require a standard open source licence (difficult for all sorts of reasons), but enough openness for us to remain, practically speaking, independent of the supplier once the software was delivered. On rare occasions pragmatism has compromised this – for instance, when we used System Simulation’s Index+ to power Museum of London’s Postcodes site – with mixed results. In the latter case, we got a great application but one that we couldn’t really support ourselves nor afford to have SSL support adequately (a side effect of project funding).

The wrap

So, when should a museum use open source software? I don’t have the answer to that, but I do say that if there’s a principle that museums should follow it’s the principle of pragmatic good management, and the politics or ethical “rightness” of (F)OSS should give way to this. I’d always try to get custom applications built and licensed in a way that enables other people to maintain and extend them. And I’d select software or platforms by taking a list that looks something like the following and seeing how it applied to that specific software, to my organisations own situation and to the realities of what we’d want to be able to do with the software in the expected lifecycle of the system.

OSS goodness:

  • Access to the source so you can fiddle with it yourself
  • Access to the source so others can fiddle and you aren’t in thrall to a software co.
  • Free stuff

and potentially:

  • A community of like-minded developers working together to make what you, the users, want
  • Greater sustainability?
OSS badness (a menu of possibilities):
  • lack of roadmap or leadership
  • lack of clear ownership
  • lack of support contracts
  • poorly integrated code, add-ons/modules etc

proprietary goodness:

  • all the stuff OSS can be bad at...
  • sometimes, great communities of users and people who develop on top of the software

Finally, stuff I like to see but which may be present or absent from either open or proprietary software:

  • Low total cost of ownership
  • Known life-cycle/roadmap for several years ahead
  • A clear exit strategy: open standards, comprehensive cross-compatible export mechanism
  • Flexible licence, ability to buy future licences!
  • Ability to change the code...sometimes
  • Confidence that, if the version I want to use gets left behind, I’ll be able to take it forward myself, or do so with a bunch of others
  • Not-caringness of the software: if it’s something I could do with one tool or another and really not care, then I’m free to migrate as I please. I don’t care that, say, PhotoShop isn’t open source because if it doesn’t do what I want or I can’t afford to put it on my new workstation I’ll use something else, and nothing too bad will happen

Jesus. Can I blame ambivalence for my long-windedness? Please don’t answer that.

P.S. At IWM we are shifting to a suite of open-source applications for our new websites. Some are familar to me, some entirely new, but it's a good time to make the jump - a clean slate. I'm very excited.

Thursday, November 04, 2010

The Mashificator: comments please!

Here's a quick post to mention the thing I've spent some evenings on recently that, for want of a halfway decent name, I called the Mashificator. If you've got any comments on it, here's where to make them since I've not put a feedback mechanism on the site. In short, it's a way to find cultural heritage content that's contextually relevant(ish) to whatever you happen to be looking at, the best way being through a bookmarklet. Please give it a go and let me know what's good and bad.

Seb Chan from the Powerhouse Museum (one of the APIs I used) was kind enough to do an e-mail interview with me for his Fresh + New(er) blog. If you don't know his blog, you really should.

Monday, October 18, 2010

Open Culture 2010 ruminations #2: Europeana, UGC and the API, plus a bit of "what are we here for?"

OK here's a relatively quick one: there was lots of discussion at Open Culture 2010 about user-generated content, and (praise be!) lots about the API. Where I see a gap is in the link between these two.
Some background: Jill Cousins, Europeana's Director, outlined the four objectives that drive project/service/network/dream (take your pick), which go approximately like this:
  1. To Aggregate – bringing everything together in one place, interoperable, rich (or rich enough) and multilingual

  2. To Facilitate – to encourage innovation in digital heritage, to stimulate the digital economy, to bring greater understanding between the people of Europe, to build an amazing network of partners and friends

  3. To Distribute – code, data, content

  4. To Engage – to put the content into forms that engage people, wherever they may be and however they want to use it
Jill pointed out that there are multiple stakeholders with their own agendas, all of whom need serving. They aren’t always in conflict, but it’s our job and Europeana’s job to help to show them how their agendas actually align. We have users (that’s a pretty large and heterogeneous group!), content providers (only slightly less so), policy-makers, ministries, business users.... Having identified the value propositions for these groups it becomes clear where we need to fill some gaps in content, partners, functionality and marketing (the latter really hasn’t started yet).
A key plank in the distribution strategy is the API. For engagement, an emerging social strategy includes opportunities for users to react to and create content themselves, and to channel the content to external social sites (Facebook and the like). Both of these things are too big to go into here, but I think one thing we haven't got covered properly is the overlap between the two. Channeling content to people on 3rd party sites ticks the "distribution" box but whilst that in iteself may be engaging it is not the same as being "social" or facilitating UGC there. If people have to come to our portal to react they simply won't. In other words, our content API has to be accompanied by a UGC API - read and write. Even if the "write" part does nothing more than allow favouriting and tagging it will make it possible to really engage with Europeana from Facebook etc.
What falls out of this is my answer to one of Stefan Gradmann's questions to WP3 (the technical working party). Stefan asked, do we want to recommend that work progresses on authentication/authorization mechanisms (OAuth/OpenID, Shibboleth etc) for the Danube release (July 2011)? My answer is a firm "yes". Until that is sorted out we can't have a "social" API to support Europeana's engagement objective off-site, and if such interaction not possible off-site then we're really not making the most of the "distribution" strand either.

Open Culture 2010 ruminations #1: Linked Data

I just came back from the Europeana plenary conference, Open Culture 2010, in Amsterdam. Before the conference I went to meetings of Working Party 1 (Users) and WP3 (Technical), and at all three gatherings I found myself ruminating on a few key areas: the question of Linked Data and the API; how social media and user generated content relate to the distribution model for Europeana; and the future of the project itself. In this first post I'll look at Linked Data and why I think we need to worry less about some things and more about others that aren't getting much attention; and I'll suggest some analogies etc that we might use to help sell the idea a bit.



Linked (Open) Data was a constant refrain at the meetings (OK, not at the WP1 meeting) and the conference, and two things struck me. Firstly, there’s still lots of emphasis on creating out-bound links and little discussion of the trickier(?) issue of acting as a hub for inbound links, which to my mind is every bit as important. Secondly, there’s a lot of worry about persuading content providers that it’s the right thing to do. Now the very fact that it was a topic of conversation probably means that there really is a challenge there, and it’s worth then taking some time to get our ducks in a row so we can lay out very clearly to providers why it is not going to bring the sky crashing down on their heads.
During a brainstorming session on Linked Data, the table I sat with paid quite a lot of attention to this latter issue of selling the idea to institutions. The problem needs teasing apart, though, because it has several strands – some of which I think have been answered already. We were posed the questions “Is your institution technically ready for Linked Data” and “Does it have a business issue with LD?”, but we wondered if it’s even relevant if the institution is technically ready: Europeana’s technical ability is the question, and it can step into the breach for individual institutions that aren't technically ready yet. With regard to the "business issue" question, one wonders whether such issues are around out-going links, or incoming links? Then, for inbound linkage, is it the actual fact of linkage, or the metadata at the end of the link that are more likely to be problematic? And what are people’s worries about outbound links?
What we resolved it down to in the end was that we expected people would be most worried about (a) their content being “purloined”, and (b) links to poor-quality outside data sources. But how new are these worries? Not new at all, is the answer, and Linked Data really does nothing to make them more likely to be realised, when you think about what we already enable. In fact, there’s a case to be made that not only does LD increase business opportunities but it might also increase organisations’ control over “their” data, and improve the quality of things that are done with it: letting go of your data means people don’t do a snatch-and-grab instead.
Ultimately, I think, Linked Data really doesn’t need a sales effort of its own. If Europeana has won people over to the idea of an API and the letting-go of metadata that it implies, then Linked Data is nothing at all to worry about. What does it add to what the API and HTML pages already do? Two things:
  • A commitment to giving resources a URI (for all intents and purposes, read “stable URL”), which they should have for the HTML representation anyway. In fact, the HTML page could even be at that URI and either contain the necessary data as, say, RDFa in the HTML, or through content negotiation offer it in some purer data format (say, EDM-XML).
  • Links to other data sources to say “this concept/thing is the sameAs that concept/thing”. People or machines can then optionally either say “ah, I know what you mean now”, or go to that resource to learn more. Again, links are as old as the Web and, not to labour the point, are kinda implicit in its name.

So really there’s little reason to worry, especially if the API argument has already been put to bed. However I thought it might be an idea to list some ways in which we can translate the idea of LD so it’s less scary to decision-makers.

  • Remember the traditional link exchange? There’s nothing new in links, and once upon a time we used to try to arrange link exchanges like a babysitting circle or something. We desperately wanted incoming links, so where’s the reason in now saying, “we’re comfortable linking out, but don’t want people linking in to our data”?
  • Linked data as SEO. Organisations go to great lengths to optimise their sites so they fare well in search engine rankings. In other words, we already encourage Google, Bing and the like spider, copy and index our entire websites in the name of making them easier to discover. Now, search is fine, but it would be still better to let people use our content in more places (that’s what the API is about), and Linked Data acts like SEO for applications that could do that: if other resources link to ours, applications will “visit”.
    The other thing here is that we let search engines take our content for analysis, knowing they won’t use it for republication. We should also licence our content for complete ingestion so that applications indexing it can be as powerful as possible.
  • It’s already out there, take control! We let go of our content the moment we put it on the web, and we all know that doing that was not just a good thing, it’s the only right thing. But whilst the only way to use it is cut-n-paste (a) it’s not reused and seen nearly as much as it should be, and (b) it’s completely out of our control, lacking our branding and “authority”, and not feeding people back to us. Paradoxically, if we make it easier to reuse our content our way than it is to cut and paste, we can change this for the better: maintain the link with the rest of our content, keep intellectual ownership, drive people back to us. Helping reuse through linked data and APIs thus potentially gives us more control.
  • Get there first. There is no doubt that if we don’t offer our own records of our things in a reusable form online then bit by bit others will do it for us, and not in the way we might like. Wikipedia/DBPedia is filling up with records of artworks great and small, and will therefore be the reference URIs for many objects.
  • Your objects as context. Linked data lets us surround things/concepts with context;

So if I think fears about LD should something of a non-issue, what do I think are the more important questions we should be worrying about? Basically, it’s all about what’s at the end of the reference URI and what we can let people do with it. Again, it’s really a question as much about the API as it is about Linked Data, but it’s a question Europeana needs to bottom out. How we license the use of data we’re releasing from the bounds of our sites is going to become a hotter area of debate, I reckon, with issues like:

  • Is Europeana itself technically prepared to offer its contents as resources for use in the LD web? Are we ready to offer stable URIs and, where appropriate, indicate the presence of alternative URIs for objects?
  • What entities will Europeana do this for? Is it just objects (relatively simple because they are frequently unique), or is it for concepts and entities that may have URIs elsewhere?
  • What’s the right licence for simple reuse?
  • Does that licence apply to all data fields?
  • Does it apply to all providers’ data?
  • Does it apply to Europeana-generated enrichments?
  • Who (if anyone) gets the attribution for the data? The provider? Aggregator? Disseminator (Europeana)?
  • Do we need to add legal provisions for static downloads of datasets as opposed to dynamic, API-based use of data?

Just to expand a little on the last item, the current nature of semantic web (or SW-like) applications is that the tricky operation of linking the data in your system to that in another isn't often done on the fly: often it happens once and the results ingested and indexed. Doing a SPARQL query over datasets on opposite sides of the Atlantic is a slow business you don’t want to repeat for every transaction, and joining more sets than that is something to avoid. The implication of this is that, if a third party wanted to work with a graph that spread across Europeana and their own dataset, it might be much more practical for them to ingest the relevant part of the Europeana dataset and index and query it locally. This is in contrast to the on-the-fly usage of the metadata which I suspect most people have in mind for the API. Were we be allow data downloads we might wish to add certain conditions to what they could do with the data beyond using it for querying.

In short I think most of the issues around Linked Data and Europeana are just issues around opening the data full stop. LD adds nothing especially problematic beyond what an API throws up, and in fact it's a chance to get some payback for that because it facilitates inbound links. But we need to get our ducks in a row to show organisations that there's little to be worried about and a lot to gain from letting Europeana get on with it.

Sunday, October 03, 2010

Internet Archive and the URL shortener question

There's been a bit of chat lately about the risks of URL shorteners, prompted I think partly by the arrival of Google's goo.gl service. The Guardian covers the basic argument here but it's the obvious thing: what happens to all the short links that get circulated if a link shortener goes tits-up? (The Guardian quotes from Joshua Schachter's bloggage of last year, which has a lot more detail to think about.)

So ealier this week @tmtn tweeted from the Royal Society
"Penny-drop moment. If bit.ly goes belly up, all the links we've used it for, break."
and there followed a little exchange about what might be done to help - the conclusion being, I think, not a lot. For your own benefit you might export a list of your links as HTML or OPML (as you can from Delicious, which does link shortening now), but for whoever else has your links there's no help.

But it got me thinking about how the Internet Archive might fit in. Schachter mentions archiving the databases of link shortening services, and here's one home for them that really could help. Wouldn't it be cool if your favourite URL shortener hooked up with them so that every link they shortened was pushed into the IA index? It could be done live or after a few weeks delay, if necessary. The IA could then offer a permified version of the short URL, along the lines of
http://www.archive.org/surl/*/http://bit.ly/aujkzd [non-functioning entirely mythical link]
Knowing just the short URL it will be easy to find the original target URL (if it still exists!) There's also a nice bit of added value: the Wayback Machine, one of the Internet Archive's greatest pieces of self-preservation, snapshots sites periodically and the short links (being, hopefully, timestamped) could be tied to these snapshots, so that you could skip to how a page looked when the short link was minted. They might even find that the submission of short links was a guide to popularity they could use in selecting pages to archive.

OK, so the Internet Archive itself maybe isn't forever, but it's been around a while and looks good for a while longer, it's trusted, and it's neutral. Perhaps Bitly, Google, tr.im, TinyURL and all the rest might think about working with the IA so we can all feel a little more sanguine about the short links we're constantly churning out? It would certainly make me choose one provider over another, which is the sort of competitive differentiator they might take note of.

Saturday, August 21, 2010

No decisions without value/s

I was getting hot under the collar the other day listening to an interview with some religious type who was upset by the decision to prevent a Catholic charity from excluding same-sex couples from using their adoption service. The Charities Commission ruled that they could either change their policy, or stop acting as an adoption agency, and as far as they were concerned the former was not an option so the latter was the only possible outcome. Now, nothing is likely to bring me round to their antediluvian* point of view re parenthood and sexuality, but it did help calm me down to remember that, whilst the discussion may often hover around "facts" (because they're easier for everyone to get a grip on, even when flaky), it's actually not about something that has a right or wrong answer: it's about a decision to support one side or another of the argument, and decisions are fundamentally dependent upon values: these are the only thing that give the "facts" any weight for the decision maker.

"Facts", in principle, are established by gathering objective evidence. Decisions, on the other hand, are the reverse: they always involve value. Value, whilst it can be a purely emotional response (a desire for something, or a positive feeling towards it), can also be transformed into values (not the same thing), which in a sense provide a template for valuing a given phenomenon. In other words, value is the outcome of an assessment, whilst values are a tool that for making that assessment.

Further, values (the tool/template) may be the internal values of an individual, perhaps embedded sub-consciously in a decision or even somatic ("instinctual", if you like, though that's a debate to avoid); or they may the externalised values embodied as a set of rules guiding a decision. This ostensibly makes the decision objective, but only by removing the value judgement into an earlier stage of the decision-making: the framing stage, where the rules for the decision are composed. These rules might even be ossified into an automated process, where rules are coded as machine instructions. They may also have been distorted along the way, so that in fact the rules represent no values held by a person at all. Whichever is the case, the values of a person or a group of people have been injected at some stage in order to make a decision possible.

The push and pull of emotion are a tide that can move our internal values incessantly, and this is one reason why it is often helpful to turn values into a set of explicit rules. Another is to externalise them so that they can be discussed and referred to as law, policy, doctrine or maybe something more informal. Of course, there's a psychological cost if this then results in dissonance between the codified values and the internalised values.

So in making decisions, or trying to influence the decisions made by other people or systems, or merely trying to understand the perspective of someone who argues in a direction that you just don't get, should we focus on the facts or on the values? Should we try to gather more evidence to demonstrate that the facts are as we see them? Should we examine the values held by another party and attempt to present the facts consonantly with them? Should we even try to change the values that are so critical in turning facts into value into decisions? Well, that's a tough one. But the one thing you can't do is address value directly: value is the product of the perceived "facts" of a scenario and the process or template for assessing the value of those facts. You can address the facts, and you can address the process of assessing but it's pointless to simply state that the value is something other than the assessment itself.

Ultimately, values themselves can be shaken by enough well-aimed evidence, but these may be of a quite different category to those facts that are put together with established values in order to reach a decision. For example, the evidence or experience required to make me a Catholic and subscribe to the values of the person I heard interviewed I cannot even imagine, even though ultimately it must be possible (perhaps on the road to Damascus). On the other hand, there are some facts through which I might be persuaded that it was wrong to prevent that particular charity from handling adoptions as it chose - for example, if it were the only agency in the country and the result of this decision was that there would be no adoption agencies at all, I might (might) feel, for purely pragmatic reasons, that it would be better to let them carry on even if that meant living with their discriminatory policy. Thankfully that's not the situation!

I don't know if this framework I've outlined is useful or right. I'm not a psychologist, a philosopher or a logician. Perhaps there are people out there who have very different ways of making decisions and this model of splitting out values from assessments of value doesn't work for them. I myself can see complications in examining the adoption agency question, which is nothing if not a clash of values. For my research into the role of decision making in digital sustainability, though, I think it may be a useful distinction to make, extending the insights given by Lessig's modalities of regulation (PDF) (this is typically looked at as a legal theorem but it's really about the "regulation" of decisions).

*yes, I know

Sunday, April 11, 2010

Posted elsewhere: Pecker up, Buttercup

I was kindly invited to contribute a post to the Museum Computer Group's "This week in cultural heritage online" series. I came up with Pecker up, Buttercup, an attempt to highlight some of the things that are great about working in this area, which was published last Friday. It's more about large-scale issues than funky technology, but of course the latter is the really fun stuff, so do go ahead and tell us what gets you really excited.
Incidentally, your pecker is your nose.

Thursday, March 25, 2010

All change for the Imperial War Museum

...well, me at least.

I delayed this post a while whilst the paperwork got sorted out, but it's not been a secret for quite a while that I'm leaving the Museum of London next month (like, I told the world here). However even today a friend at work came up to me and whispered "I heard you're leaving", so for those other friends I've somehow not managed to tell, well, it's true.
It was 8 years ago in January that I began here in my first paid museum job, though I'd never imagined working with computers before starting my Museum Studies MA. It's very much time to leave now, and as luck would have it the perfect opportunity for me turned up at the right time - or as close to the right time as I could reasonably hope! After all, good digital media jobs in museums don't turn up all that often, and if you're looking for a little extra responsibility the choices are fewer still.
Which makes me feel all the more fortunate to have been given the chance to work as Technical Web Manager at the Imperial War Museum. I will be working for Carolyn Royston, who steered the huge and hugely challenging National Museums Online Learning Project through. She was appointed a year ago by the then-recently-installed director, Diane Lees, and since then she's been busy planning how to "put digital at the heart of the museum", assessing what the IWM has and how to move forward, and building a team fit for purpose. I feel lucky to be about to become a part of that digital team, which benefits from a strong vision and backing at the most senior level - not to mention an exceptional collection (both "real" and digitised).
My role, as I understand it (and I guess being new it will evolve plenty) will be some combination of programming and planning, developing a technical strategy to compliment the overall digital strategy, specifying infrastructure and so on. The IWM has some of key factors in place already (a decent DAMS, recently centralised collections databases), but the opportunities are plentiful for doing something fresh. I know that it also has a team of people that are itching to make that happen and I'm so looking forward to getting to know them and finding my place beside them.
I can't leave it at that without also saying how sorry I am to be leaving my friends at the Museum of London. I'm going to miss them. We have been through some real trials but somehow, despite unfair winds, we have managed to do some pretty good stuff, I think. I also regret having to take my leave at this exact point in time (well, in May) before I can fully see out two of the most significant projects I have been part of, and without a single in-house web developer to hand over to. I know that this will make life difficult for some of my most valued colleagues (as well as for the people who are responsible for the previous statement being true).
But whilst a couple of things may have to, well, not happen or not happen for some time, I should be around long enough to see our Collections Online system completed. If not then it won't be far off (thanks to Knowledge Integration), and the first public interface for it in our glorious new Galleries of Modern London should be in testing (thanks to Precedent).
So with only limited handover possible, I'm spending the last few weeks working on this project and wrapping up a few things that have been hanging on forever. Fingers crossed I can leave a few people happy that yes, it finally did get done.

Friday, March 19, 2010

Did I never blog this? Eejit! Here's the LAARC API

I have a feeling I never blogged about the existence of the LAARC API. Currently this is only simple search and we've not as yet "eaten our own dog food" i.e. rebuilt the LAARC catalogue site itself on top of this - that's waiting for the advanced search API, though I couldn't guess at a delivery date for that...
I think I'd meant to do a big explanatory post and since I didn't get round to that just never mentioned it. So for now I'll just get the word out and say, this is the work of Julia Fernee who re-engineered the whole back-end of the LAARC system to make it work sweetly, fixed stuff broken by a change to Mimsy XG, got digital downloads behaving again and ironed out various other un-noticed bugs. Ultimately it's all still based on the work of Sarah Jones and later Mia Ridge, but Julia's work now puts the database in a place where we can build from. Play with the API and let us know what you think.

Wednesday, March 17, 2010

LIDO references

I've had cause to send links about LIDO (Lightweight Information Describing Objects) to a bunch of people and every time struggle to find them because they don't float to the top in Google and, being PDFs, the Delicious bookmarklet doesn't cope with some of them so I hadn't put them there.
So anyway, if you're looking for a way in to LIDO, here are a couple of good references:
If you know any other resources worth adding, let me know. Also, your thoughts on where LIDO fits in and what its strengths and limitations are would be very welcome! The documents stress that it is a harvesting format rather than a full data exchange format, but is it actually perfectly good for this in many circumstances? If I choose to use it as the format for records coming out of our (forthcoming) API, will I be missing something important?
BTW I have now added these to Delicious the manual way: http://delicious.com/jottevanger/lido

Thursday, February 25, 2010

Linked Data meeting at the Collections Trust

[December 2010: I don't even know anymore if this was ever published, or if I simply edited it and it went back into draft. If the latter, duh. If the former, well, in the spirit of an end-of-year clearout here's something I wrote many months ago]
[UPDATE, March 2010: Richard Light's presentation is now available here]

On February 22nd Collections Trust hosted a meeting about Linked Data (LD) at their London Bridge offices. Aside from yours truly and a few other admitted newbies amongst the very diverse set of people in the room, there was a fair amount of experience in LD-related issues, although I think only a few could claim to have actually delivered the genuine article to the real world. We did have two excellent case studies to start discussion, though, with Richard Light and Joe Padfield both taking us through their work. CT's Chief Executive Nick Poole had invited Ross Parry to chair and tasked him with squeezing out of us a set of principles from which CT could start to develop a forward plan for the sector, although it should be noted that they didn’t want to limit things too tightly to the UK museum sector.

In the run-up to the meeting I’d been party to a few LD-related exchanges, but they’d mainly been concentrated into the 140 characters of tweets, which is pragmatic but can be frustrating for all concerned, I think. The result was that the merits, problems, ROI, technical aspects etc of LD sometimes seemed to disappear into a singularity where all the dimensions were mashed into one. For my own sanity, in order to understand the why (as well as the how) of Linked Data, I hoped to see the meeting tease these apart again as the foundation for exploring how LD can serve museums and how museums can serve the world through LD. I was thinking about these as axes for discussion:


  • Creating vs consuming Linked Data

  • End-user (typically, web) vs business, middle-layer or behind-the-scenes user

  • Costs vs benefits. ROI may be thrown about as a single idea, but it’s composed of two things: the investment and the return.

  • On-the-fly use of Linked Data vs ingested or static use of Linked Data

  • Public use vs internal drivers
So I took to this meeting a matchbox full of actual knowledge, a pocket full of confusion and this list of axes of inquiry. In the end the discussion did tread some of these axes whilst others went somewhat neglected, but it was productive in ways I didn’t expect and managed to avoid getting mired in too much technology.

To start us off, Richard Light spoke about his experiments with the Wordsworth Trust’s ModesXML database (his perennial sandbox), taking us through his approach to rendering RDF using established ontologies, to linking with other data nodes on the web (at present I think limited to GeoNames for location data, grabbed on the fly), and to cool URIs and content negotiation. Concerning ontologies, we all know the limitations of Dublin Core but CIDOC-CRM is problematic in its own way (it’s a framework, after all, not a solution), and Richard posed the question of whether we need any specific “museum” properties, or should even broaden the scope to a “history” property set. He touched on LIDO, a harvesting format but one well placed to present documents about museum objects and which tries to act as a bridge between North American formats (CDWALite) and European initiatives including CIDOC-CRM and SPECTRUM (LIDO intro here, in depth here (both PDF)). LIDO could be expressed as RDF for LD purposes.

For Richard, the big LD challenges for museums are agreeing an ontology for cross-collection queries via SPARQL; establishing shared URLs for common concepts (people, places, events etc); developing mechanisms for getting URLs into museum data; and getting existing authorities available as LD. Richard has kindly allowed me to upload his presentation Adventures in Linked Data: bringing RDF to the Wordsworth Trust to Slideshare.

Joe Padfield took us through a number of semantic web-based projects he’s worked on at the National Gallery. I’m afraid I was too busy listening to take many notes, but go and ferret out some of his papers from conferences or look here. I did register that he was suggesting 4store as an alternative to Sesame for a triple store; that they use a CRM-based data model; that they have a web prototype built on a SPARQL interface which is damn quick; and that data mining is the key to getting semantic info out of their extensive texts because data entry is a mare. A notable selling point of SW to the “business” is that the system doesn’t break every time you add a new bit of data to the model.

Beyond this, my notes aren’t up to the task of transcribing the discussion but I will put down here the things that stuck with me, which may be other peoples’ ideas or assertions or my own, I’m often no longer sure!

My thoughts in bullet-y form
I’m now more confident in my personal simplification that LD is basically about an implementation of the Semantic Web “up near the surface”, where regular developers can deploy and consume it. It seems like SW with the “hard stuff” taken out, although it’s far from trivial. It reminds me a lot of microformats (and in fact the two can overlap, I believe) in this surfacing of SW to, or near to, the browsable level that feels more familiar.

Each audience to which LD needs explaining or “selling” will require a different slant. For policy makers and funders, the open data agenda from central government should be enough to encourage them that (a) we have to make our data more readily available and (b) that LD-like outputs should be attached as a condition to more funding; they can also be sold on the efficiency argument or doing more with less, avoiding the duplication of effort and using networked information to make things possible that would otherwise not be. For museum directors and managers, strings attached to funding, the “ethical” argument of open data, the inevitability argument, the potential for within-institution and within-partnership use of semantic web technology; all might be motives for publishing LD, whilst for consuming it we can point to (hopefully) increased efficiency and cost savings, the avoidance of duplication etc. For web developers, for curators and registrars, for collections management system vendors, there are different motives again. But all would benefit from some co-ordination so that there genuinely is a set of services, products and, yes, data upon which museums can start to build their LD-producing and –consuming applications.

There was a lot of focus on producing LD but less on consuming it; more than this, there was a lot of focus producing linkable data i.e. RDF documents, rather than linking it in some useful fashion. It's a bit like that packaging that says "made of 100% recyclable materials": OK, that's good, but I'd much rather see "made of 100% recycled materials". All angles of attack should be used in order to encourage museums to get involved. I think that the consumption aspect needs a bit of shouting about, but it also could do with some investment from organisations like Collections Trust that are in a position potentially to develop, certify, recommend, validate or otherwise facilitate LD sources that museums, suppliers etc will feel they can depend upon. This might be a matter of partnering with Getty, OCLC or Wikipedia/dbPedia to open up or fill in gaps in existing data, or giving a stamp of recommendation to GeoNames or similar sources of referenceable data. Working with CMS vendors to make it easy to use LD in Modes, Mimsy, TMS, KE EMu etc, and in fact make it more efficient than not using LD; now that would make a difference. The benefits depend upon an ecosystem developing, so bootstrapping that is key.

SPARQL: it ain’t exactly inviting. But then again I can’t help but feel that if the data was there, we knew where to find it and had the confidence to use it, more museum web bods like me would give it a whirl. The fact that more people are not taking up the challenge of consuming LD may be partly down to this sort of technical barrier, but may also be to do with feeling that the data are insecure or unreliable. Whilst we can “control” our own data sources and feel confident to build on top of them, we can’t control dbPedia etc., so lack confidence of building apps that depend on them (Richard observed that dbPedia contains an awful lot of muddled and wrong data, and Brian Kelly's recent experiment highlighted the same problem). In the few days since the meeting there have been more tweets in this subject, including references to this interesting looking Google Code project for a Linked Data API to make it simpler to negotiate SPARQL. With Jeni Tennison as an owner (who has furnished me with many an XSLT insight and countless code snippets) it might actually come to something.

Tools for integrating LD into development UIs for normal devs like me – where are they?

If LD in cultural heritage needs mass in order for people to take it up, then as with semantic web tech in general we should not appeal to the public benefit angle but to internal drivers: using LD to address needs in business systems, just as Joe has shown, or between existing partners.

What do we need? Shared ontologies, LD embedded in software, help with finding data sources, someone to build relationships with intermediaries like publishers and broadcasters that might use the LD we could publish.

Outcomes of the meeting
So what did we come up with as a group? Well Ross chaired a discussion at the end that did result in a set of principles. Hopefully we'll see them written up soon coz I didn't write them down, but they might be legible on these images:










Monday, February 08, 2010

Museums and online logins pt.3: making a better “why” (with a bit of how)

Breaking down collections database silos has long been a dream for me as a user (and consequently as a developer), hence my involvement in and (perhaps unrealistically) high hopes for Europeana. Well, collections-related functions aren’t all that museum sites have in common, and lots of things would work better if a few more walls were knocked over. In Part 3 I’ll suggest some of the things that a service built around universal museum login could offer that aren’t going to happen with the current situation, but could be of value to both museums and their online users.

In the scenario in Part 2 you used your MuPPort ID to log into a museum site that you’d never visited before, and then fiddled around with your profile before using the museum’s thimble freaks’ forum. What else could you do? How about bookmark a few items in the thimble collection’s pages? You could then tag them and put them in a set along with the thimbles you faved on the Framley Museum site, then share this set with a group of thimble lovers on the MoPPort site. Whilst you’re there you put some pictures from the V&A next to others from the British Postal Museum and perhaps use them to build a nice little timeline in Magic Studio (I’d better mention my Declaration of Interest here). How about saving some events listings, filtered to your preferences, from a few museum sites, supplemented with the events listings held in the Culture24 database? This being an OpenID site, if gave it permission to link to your Flickr account you could also see your museum-related groups and contacts here, perhaps filtering new uploads of thimble-related images from known museum Flickr accounts for you to view and comment upon. In short, this would be a service where all your stuff from UK museums would be in one place for you to mix up, share, discuss, tag.

What would be required of museums? Well actually, unless they wanted some function based on registration that the service didn't offer or if they needed access control functionality (authorisation), nothing at all. Imagine then that most of the time you didn’t need to log into museum sites at all, only MuPPort, using the MuPPort bookmarklet to favourite object records and save searches. A museum would be added automatically to your master profile whenever this happened. When login was necessary on a given site – such as for using a forum – it would be semi-automated, much like logging into YouTube when already logged into Google (or like Athens, if you know that). But many services would be much more valuable when run across institutions and would be fit for MuPPort, or a developer building on its platform. And much of the time login is important for tying data to a user rather than for authorising that user, so lots of tools could wrap around sites in just the way that Delicious does: requiring nothing of the site itself, only that the user is logged in to Delicious. If nothing at all is required of the museum, where’s the catch?

Well actually more interesting is, where’s the extra value for museums? Here we’re finally back to recommendation systems, which got me mulling over universal login again. Pretty much any museum isn’t going to learn much from the patterns of their own users alone, whether through their explicit, conscious actions such as favouriting and tagging, or the trails they implicitly leave browsing and searching their site. Put together, though, many users over many sites, hopefully doing more, adds up to a lot of knowledge and a good source of recommendations. This is good for museums and for users.

Well it's late and I've spent too much time on this so I’m going to leave it at that. There’s clearly overlap here with what could be offered by Europeana, but in the UK there are other organisations well suited to the task (of course I’m looking at you, Nick). I wouldn’t want to say really who or what should provide a service like this, but I do think that universal login is only a part: the whole point is to build real value on top of a nexus of users and specialised content which current generalist alternatives can’t really offer. Is there a case for a service like this? I’d love to hear your thoughts. And thanks for getting this far...

Postscript
I’ve put a quick survey up to find out what sort of registration-dependent activities museums run at the moment on and off their own websites. If you work on a museum website it would be really interesting to have your input, which I’ll put on this blog in due course.

Other posts in this series:

Sunday, February 07, 2010

Museums and online logins pt.2: making a better “how”

(or "It's a universal tribulation")
In Part 1, I posited that one reason for museums not to integrate registration and login with their sites must be the hassle for both parties (museum and user). So, what if it wasn't a hassle to give your users a registration facility and a bunch of tools that depend on it? What if it was easy technically and yielded lots of value because it was popular? In short, what if the business case was good (which is incidentally the essence of my perspective on sustainability: sustaining appropriate levels of resources by identifying and sustaining value). If the users liked it because the value to them was higher: the benefits of logged-in actions extended beyond a single museum and let you bring together all your "stuff" from countless museums and galleries? In Part 2 I’ll look at lowering the barrier, before moving on to boosting the rewards in Part 3. First, though, let’s quickly off-road to look at the context within which museums operate online.

A digression: the Modalities of Regulation (from The Digital Sustainability Foundation Course)
I find it difficult these days to think about investment without thinking about sustainability. This isn't just because sustainability should be on your mind when you build something new (doh!), but because the things that make something worth building are the same as those that make it worth your while to keep it going. Or they can be, but that's another blog post.

An organisation’s internal drivers are vital in the question of whether and how they go about "building" and "operating", but these values and imperatives are in constant negotiation with the environment within which they operate. Larry Lessig talks about this in terms of the regulation of behaviour i.e. external factors that affect decisions, amongst them the law, the market, social norms and "architecture", which amounts to the stuff you just have to live with (whether that be the law of gravity, the presence of a mountain in your path, or your inability to see through walls).

An interesting constraint in this discussion is the market, which relates both to the users we have in mind and the ecosystem of competitors, peers and solution providers we operate within (often enough a "competitor" is also a provider of a solution, according to how you come at them c.f. Google, Wikipedia, Flickr, and many more). It's immediately apparent that the market has enabled museums to achieve a lot of social stuff without having to do the tricky stuff themselves, and as importantly tap into a much larger audience as a result. Several brilliant examples of using Flickr make it the most notable case, for me. On the architectural side, OpenID (http://openid.net) is a liberating “constraint” with market-y aspects, being a technical framework that relies on the market for OpenID providers. OpenID hasn't yet seen a lot of museum usage, perhaps because it's a bit technical or again simply because the use case is still too weak for offering logged in sections at all. The Brooklyn Museum lets people use their Google IDs to login (they use this for their famous Posse, which is clearly a compelling use case) but it's not exactly a widespread practice.

Whenever thinking about a solving problem it makes sense to look at the environment, especially the market, and examine what solutions already exist, how they fail, and perhaps how they could be adopted or adapted. For now I'll just say that with Delicious, Google's SideWiki, Zotero and many other relatively generalist, site-agnostic, "wrap-around" tools we have some great foundations to build upon. They form an important aspect of “the market”, and in some cases also the architecture. Before trying to reproduce what they do we should ask the question of whether they fall short in significant ways. I would suggest that they do because, whilst their success is based upon their not requiring anything particular of the web resources they are used upon, there is not much scope for pushing crowd-sourced knowledge back to those resources.

Lower the barrier or De-hassle the users, de-hassle the techs
As a developer, if I were asked to create some functionality that needed people to register I know various ways I could go about it, but it’s not trivial and if you had to deploy it over multiple web apps it could be a bit of a nightmare for a hack like me. Most other museums are even more thinly resourced than my own in terms of developer capacity.

As a user, I’ve got enough logins, thank you, and I’d pause for thought before registering with the Louvre or the BM, let alone Colchester Castle Museum. Another password? Another profile to build and manage? And although I’m going to do much of the same stuff as on all the other museum websites I visit, no connection between them? How useful is a Facebook widget for a my favourite objects from single museum? How many such widgets will I add to my profile? (probably none because I don’t know of any right now, but perhaps that’s due to exactly this barrier: it’s not worthwhile for users nor for single museums to make single museum apps of this sort)

So I’m proposing a UK museum passport – let’s call it a MuPPort for now, so that we remember to change it – a universal(ish) digital login service, although perhaps with an off-line dimension. This would help to lower the barrier for both sides. It would probably be built around OpenID and, to make museum coders' lives easier, would come with a bunch of widgets and code snippets. There would be access level control for those parts of a museum’s site that needed to be restricted to a particular group. Users would benefit from feature profile management tools and from various value-added stuff we’ll look at in Part 3, much of which might not even need the museum to implement MuPPort on their site because it’s not about access control, it’s just about identifying the user and keeping their stuff tied to their identity.

Imagine a scenario where, as a user, you can go to a museum site that you've never visited before and log in using your Google ID, or whatever OpenID identity you have attached to your MuPPort. Before going any further, you decide to visit the MuPPort site and check out your passport master account, where you see individual accounts for three museums you had logged into on previously, together with the stub of an account for the one you just went to. You customise your profile for the new museum, then when you go and contribute to their thimble-lovers’ forum MuPPort will ensure that the right avatar and username show up and are linked through to your Facebook page and blog.

So logging in could be made easier for everyone, but how about the more compelling case for users? Well that's where the fun starts, because whilst it could simply be a central sign-in system that then relies on individual museum websites to take care of all of the real action, for many functions it would make a lot more sense to run them centrally and gain from the pooled content as a result.

Other posts in this series:

Museums and online logins pt.1: who’s doing what, where and why

It's not happening
Right now, not that many museums let users register and do extra stuff online. That assertion is very unscientific, but looking around the London nationals' websites (but looking no further than the home pages/main menus) I find:

  • British Museum: No login

  • Imperial War Museum: No login

  • National Gallery: No login

  • National Maritime Museum: No login

  • National Portrait Gallery: No login

  • Natural History Museum: Login for NaturePlus (forums, blogs, bookmarking etc.)

  • Science Museum: No login

  • Tate: No login

  • Victoria & Albert Museum: No login
Of these, all but the National Gallery are also partners in Creative Spaces, the "grown up" part of the National Museums Online Learning Project launched last year. This requires you to log in to do much of the interesting stuff, and the need for this and benefits of doing so are pretty self-evident (at least if you buy into the application, and there are others in the museum geek community who don't). The login, though, is not good outside Creative Spaces AFAIK.

I realise that my sample was purely London majors and there are perhaps other UK museums that do have registered user areas, but if this sample is at all representative, why is registration, or more pertinently the sort of activity that would require registration, apparently so scarce on museum sites? I mean, there must be lots of things we'd like to do with museum/gallery content or in museum/gallery contexts (meat-space or digital) that would need you to sign up, and there's always loads of talk about funky collaborative stuff, social media, personalisation... So if the big 'uns don't generally do it there's got to be a reason worth digging in to.

There are plenty of reasons why this may be so and I'll have a look at some later on, but in simple terms I'd put it down to "it's tricky to do" and "is it worth it anyway?" (that last referring to the value that both museums and their users would get for all the hassle). Certainly at the Museum of London we've had the registration discussion more than once. Mia was always opposed, and rightly so I think, on the grounds that it's exclusive and off-putting with little to gain from it; yet the temptation is there, especially if you're considering value-added features that depend upon registration to be effective - say, favouriting objects or saving searches. In fact, the redesign that we’re currently engaged in on the MOL sites is another reason why registration has been on my mind again, since it always brings up the suggestion of a special area for the Friends. Quite what they’d get in that area I couldn’t tell ya. It does bring up one important distinction between reasons for “doing” login: it can be for access control, or it can be for identifying the user and associating them with their stuff (or both of the above).

Of course, doing some of this stuff needn’t involve logging in to our sites at all. So the nest question is, what sort of things are museums doing with third party services that involve people using (optionally or otherwise) registered identities? And would it ever make sense to try to go it alone instead?

Social media basics: Twitter, Facebook
The whole point of participating in the likes of Facebook or Twitter is to become part of a wide existing social network. Whilst museums might sometimes have specific narrower audiences in mind for some of what they do here, there’s surely nothing to be gained by doing it anywhere but where the people are. For richer but more targeted social networks, Ning is a popular alternative hosted solution.

Blogs, forums, and comments
Lots of museums run blogs, some of them on hosted services like Blogger, others on their own installations (MOL, for example). These may have their own login system (Wordpress, for example) but they often hook into OpenID too, so if users want to make comments they can use an existing identity. Forums, too, can be installed and run without having to run a registration/login system, or you can use hosted alternatives like Google or Yahoo! groups (for all their failings). And of course, people feed back to museums through “contact us” forms. It would be a fool who made these accessible only to logged-in users, but one can see how it could be useful to link together contact forms with known users.

Wikis and Wikipedia
Installing MediaWiki or using the likes of PBWiki can involve some sort of user management, although you don’t have to build your own system for this. Perhaps in some cases you can use OpenID? If users currently have to register to edit your wiki, one can see how it might be easier if this was tied to other things they might have to register for.

Wikipedia, of course, is not under your control and nor do you need to be registered to edit it, so although plenty of museums use it for their own purposes it doesn’t really fit into this discussion. Wikipedia is socially produced but is not a social space in the same way as other sites, although discussions can grow up around topics.

Sharing media
YouTube, iTunes and Flickr are the classic places for sharing media, and this is for a combination of pragmatic/economic reasons (free hosting, unlimited bandwidth, no real technical challenges, easy embedding, a UI dedicated to that medium) and because of the ready access to a user base, many of them registered, who can favourite, tag and comment on your assets. Museums’ use of Flickr is much more sophisticated overall than with, say, YouTube, owing partly to the simple fact that photographs constitute a large part of many collections (and can represent most of the rest). A recent flurry of tweets and bloggage on the relative merits of Flickr Commons and Wikimedia Commons brought out the value of the social aspect of Flickr.

Bookmarking
Take your pick here, but Delicious is the big social bookmarking app, and as a user it’s more important to tag your bookmarks than pretty much anything else. This makes it a great source of user generated data on bookmarked pages, although whether any museums mine the info on how their pages are bookmarked and tagged I know not but if you’ve got time you can do it (here for example is a search for how people have bookmarked the MOL home page). If people bookmarked using a museum’s own app instead of Delicious (or Digg, Stumbleupon, whatever), what would that do for them or for the museum? Well, for users I think I’ll leave that until later, but for museums patterns of use and tagging would be a potential goldmine.

Museums exist in social contexts all around the web. Sometimes they put themselves there – on Facebook, through blogging, via Flickr – and other times they simply find themselves or their content there – mentioned on Twitter, faved in Google Reader or tagged in Delicious, written up in TripAdvisor or Wikipedia. Doubtless I have some of the details of my little environmental scan wrong but that’s not really too important: the point is the multitude of interactions and the fragmentation of the information – no, the relationships – that result. All that wealth of knowledge and opinion, all that social capital, spread all over the shop. It makes you wonder if there’s more we could be doing to marshal it for the good of all museums, because rich as this ecosystem is, it can be pretty hard to learn from it.

Other posts in this series:

Museums and online logins: the preamble

I was recently asked for my thoughts on recommendation systems and cultural heritage organisations and it set off a train of thought that took me back to an old idea, one I'm sure I must have discussed with many people and which perhaps someone's working on right now.

The idea is universal login. OK "universal" might be a bit strong, so let's just start with UK-wide, museum website login. For whatever reason (possibly coz it's a rubbish idea) it's not happened yet and I want to think about why, and whether there's a way it might happen successfully. I thought I’d do a quick post on it but it needed some background and rapidly ballooned, with the result that I’ve split it into three posts (four if you count this one).

The first post looks briefly at what museums are doing with registration and login to their own site, as well as touching on some of the other places they encourage “identity-tied” user engagement without having to build their own mechanisms. Then I talk about some of the ways these fall short and speculate on why login is still pretty rare amongst museum sites.

The second post proposes “universal login” as a way to tackle one of the barriers to doing this: the effort involved.

The third post is really the first one I wanted to write, but that would have meant skipping straight to a “solution” without framing the “problem” or describing universal login, which is a necessary (but insufficient) intermediate step. It’s about the more important barrier: the lack of value in creating another login silo.

Finally, there's also a survey to find out what other museums are doing and what you think. If you're involved with a museum website I'd very much appreciate your input, which I'll wrap up into a further post in the future.

Other posts in this series: