'Sector-wide initiatives' at 'UK Museums on the Web Conference 2008'

Session 2, 'Sector-wide initiatives', of the UK Museums on the Web Conference 2008 was chaired by Bridget McKenzie.

In the interests of getting my notes up quickly I'm putting them up pretty much 'as is', so they're still rough around the edges. There are quite a few sections below which need to be updated when the presentations or photos of slides go online. Updated posts should show in your RSS feed but you might need to check your settings.

[I hope Bridget puts some notes from her paper on her blog because I didn't get all of it down.]

The session was introduced as case studies on how cross institutional projects can be organised and delivered. She mentioned resistance to bottom-up or experimental approach, institutional constraints; and building on emerging frames of web.

Does the frame of 'the museum' make sense anymore, particularly on the web? What's our responsibilities when we collaborate? Contextual spaces – chance to share expertise in meaningful ways.

It's easy to revert to ways previous projects have been delivered. Funding plans don't allow for iterative, new and emergent technologies.

Carolyn Royston and Richard Morgan, V&A and NMOLP.
The project is funded by the 'invest to save' program, Treasury.

Aims:
Increase use of the digital collections of the 9 museums (no new website)
No new digitisation or curatorial content.
Encourage creative and critical use of online resources.
[missed one]
Sustainable high-quality online resource for partners.

The reality – it's like herding cats.

They had to address issue of partnership to avoid problems later in project.

Focussed on developing common vision, set of principles on working together, identify things uniquely achievable through partnership, barriers to success, what added value for users.

Three levels of barriers to success – one of working in an inter-museum collaborative way, which was first for those nationals; organisational issues – working inter-departmentally (people are learning or web or whatever people and not used to working together); personal issues – people involved who may not think they are web or learning people.

These things aren't necessary built in to project plan.

Deliverables: web quests, 'creative journeys', federated search, [something I missed], new ways of engaging with audiences.

Web Quests – online learning challenge, flexible learning tool mapped to curriculum. They developed a framework. It supports user research, analysis and synthesis of information. Users learn to use collections in research.

Challenges: creating meaningful collection links; sending people to collections sites knowing that content they'd find there wasn't written for those audiences; provide support for pupils when searching collections. Sustainable content authoring tool and process.

[I wondered if the Web Quest development tools are extendible, and had a chance to ask Carolyn in one of the breaks – she was able to confirm that they were.]

Framework stays on top to support and structure.

Creative journeys:
[see slide]

They're using Drupal. [Cool!]

[I also wondered about the user testing for creative journeys, whether there was evidence that people will do it there and not on their blogs, Zotero, in Word documents or hard drives – Carolyn also had some information on this.]

Museums can push relevant content.

What are the challenges?
How to build and sustain the Creative Journeys (user-generated content) communities, individually and as a partnership?
Challenge to curatorial authority and reputation
Work with messiness and complexity around new ways of communicating and using collections
Copyright and moderation issues

But partners are still having a go – shared risk, shared success.

Federated search
Wasn't part of original implementation plan
[slide on reasons for developing]
Project uses a cross collection search, not a cross collection search project. The distinction can be important.

The technical solution was driven by project objectives [choices were made in that context, not in a constraint-free environment.]

Richard, Technical Solution
The back-end is de-coupled from front end applications
A feed syndicates user actions.

Federated search – a system for creating machine readable search results and syndicating them out.
Real time search or harvester. [IMO, 'real time' should always be in scare quotes for federated searches – sometimes Google creates expectations of instantaneous results that other searches can't deliver, though the difference may only be a matter of seconds.]

Data manipulation isn't the difficult bit

Creative Journeys – more machine readable data

Syndicated user interactions with collections.
Drupal [slide]

Human factor – how to sell to board
Deploy lightweight solutions. RAD. Develop in house, don't need to go to agency.

[I'd love it if the NMOLP should have a blog, or a holding page, or something, where they could share the lessons they've learnt, the research they've done and generally engage with the digital museum community. Generally a lot of these big infrastructure projects would benefit from greater transparency, as scary as this is for traditional organisations like museums. The open source model shows that many eyeballs mean robust applications.]

Jeremy Ottevanger and Europeana/the European Digital Library
[I have to confess I was getting very hungry by this point so you might get more detailed information from Jeremy's blog when he adds his notes.]
Some background on his involvement in it, hopes and concerns.
"cross-domain access to Europe's cultural heritage"
Our content is more valuable together than scattered around.

Partnership, planning and prototyping
Not enough members from the UK, not very many museums.
Launch November this year
Won't build all of planned functionality – user-generated content and stuff planned but not for prototype.

Won't build an API or all levels of multiple linguality (in first release). Interface layer may have 3 or 4 major languages; object metadata (maybe a bit) and original content of digitised documents.

Originals on content contributors site, so traffic ends up there. That's not necessarily clear in the maquette (prototype). [But that knowledge might help address some concerns generally out there about off-site searches]

Search, various modes of browsing, timeline and stuff.

Jeremy wants to hear ideas, concerns, ambitions, etc to take to plenary meeting.

He'd always wanted personal place to play with stuff.

[Similarly to my question above, I've always wondered whether users would rely on a cultural heritage sector site to collate their data? What unique benefits might a user see in this functionality – authority by association? live updates of data? Would they think about data ownership issues or the longevity of their data and the reliability of the service?]

Why are there so few UK museums involved in this? [Based on comments I've heard, it's about no clear benefits, yet another project, no API, no clear user need] Jeremy had some ideas but getting in contact and telling him is the best way to sort it out.

Some benefits include common data standards, a big pool of content that search engines would pay attention to in a way they wouldn't on our individual sites. Sophisticated search. Will be open source. Multi-lingual technology.

Good news:
"API was always in plans".

EDLocal – PNDS. EU projects will be feeding in technologies.

Bad news: API won't be in website prototype. Is EDLocal enough? Sustainability problems.
'Wouldn't need website at all if had API'. Natural history collections are poorly represented.

Is OAI a barrier too far? You should be able to upload from spreadsheet. [You can! But I guess not many people know this – I'm going to talk to the people who coded the PNDS about writing up their 'upload' tool, which is a bit like Flickr's Uploadr but for collections data.]

Questions
Jim O'Donnell: regarding the issue of lack of participation. People often won't implement their own OAI repository so that requirement puts people off.

Dan Zambonini: aggregation fatigue. 'how many more of these things do we have to participate in'. His suggestion: tell museums to build APIs so that projects can use their data, should be other way around. Jeremy responded that that's difficult for smaller museums. [Really good point, and the PNDS/EDL probably has the most benefits for smaller museums; bigger museums have the infrastructure not to need the functionality of the PNDS though they might benefit from cross-sector searching and better data indexing.]

Gordon McKenna commented: EDLocal starts on Wednesday next week, for three years.

George Oates: what's been most surprising in collaboration process? Carolyn: that we've managed to work together. Knowledge sharing.

'The Machine That Changed the World' online

I think I'm posting this as much to tell you about it as to remind myself to watch it!

The Machine That Changed the World is the longest, most comprehensive documentary about the history of computing ever produced, but since its release in 1992, it's become virtually extinct. …

It's a whirlwind tour of computing before the Web, with brilliant archival footage and interviews with key players — several of whom passed away since the filming.

In other news, the mashed museum day is tomorrow, and the UK Museums on the Web conference is the day afterwards – see you there, maybe! I've been flat out so I've no idea what I'll work on tomorrow – I have lots of ideas but haven't had a chance to do any preparation.

Yahoo! SearchMonkey, the semantic web – an example from last.fm

I had meant to blog about SearchMonkey ages ago, but last.fm's post 'Searching with my co-monkey' about a live example they've created on the SearchMonkey platform has given me the kick I needed. They say:

The first version of our application deals with artist, album and track pages giving you a useful extract of the biography, links to listen to the artist if we have them available, tags, similar artists and the best picture we can muster for the page in question.

Some background on SearchMonkey from ReadWriteWeb:

At the same time, it was clear that enhancing search results and cross linking them to other pieces of information on the web is compelling and potentially disruptive. Yahoo! realized that in order to make this work, they need to incentivize and enable publishers to control search result presentation.

SearchMonkey is a system that motivates publishers to use semantic annotations, and is based on existing semantic standards and industry standard vocabularies. It provides tools for developers to create compelling applications that enhance search results. The main focus of these applications is on the end user experience – enhanced results contain what Yahoo! calls an "infobar" – a set of overlays to present additional information.

SearchMonkey's aim is to make information presentation more intelligent when it comes to search results by enabling the people who know each result best – the publishers – to define what should be presented and how.

(From Making the Web Searchable: The Story of SearchMonkey)

And from Yahoo!'s search blog:

This new developer platform, which we're calling SearchMonkey, uses data web standards and structured data to enhance the functionality, appearance and usefulness of search results. Specifically, with SearchMonkey:

  • Site owners can build enhanced search results that will provide searchers with a more useful experience by including links, images and name-value pairs in the search results for their pages (likely resulting in an increase in traffic quantity and quality)
  • Developers can build SearchMonkey apps that enhance search results, access Yahoo! Search's user base and help shape the next generation of search
  • Users can customize their search experience with apps built by or for their favorite sites

This could be an interesting new development – the question is, how well does the data we currently output play with it; could we easily adapt our pages so they're compatible with SearchMonkey; should we invest the time it might take? Would a simple increase in the visibility and usefulness of search results be enough? Could there be a greater benefit in working towards federated searches across the cultural heritage sector or would this require a coordinated effort and agreement on data standards and structure?

Update to link to the Yahoo! Search Blog post ;The Yahoo! Search Gallery is Open for Business' which has a few more examples.

Nice information design/visualisation pattern browser

infodesignpatterns.com is a Flash-based site that presents over 50 design patterns 'that describe the functional aspects of graphic components for the display, behaviour and user interaction of complex infographics'.

The development of a design pattern taxonomy for data visualisation and information design is a work in progress, but the site already has a useful pattern search, based on order principle, user goal, graphic class and number of dimensions.

Some ideas for location-linked cultural heritage projects

I loved the Fire Eagle presentation I saw at the WSG Findability event [my write-up] because it got me all excited again about ideas for projects that take cultural heritage outside the walls of the museum, and more importantly, it made some of those projects seem feasible.

There's also been a lot of talk about APIs into museum data recently and hopefully the time has come for this idea. It'd be ace if it was possible to bring museum data into the everyday experience of people who would be interested in the things we know about but would never think to have 'a museum experience'.

For example, you could be on your way to the pub in Stoke Newington, and your phone could let you know that you were passing one of Daniel Defoe's hang outs, or the school where Mary Wollstonecraft taught, or that you were passing a 'Neolithic working area for axe-making' and that you could see examples of the Neolithic axes in the Museum of London or Defoe's headstone in Hackney Museum.

That's a personal example, and those are some of my interests – Defoe wrote one of my favourite books (A Journal of the Plague Year), and I've been thinking about a project about 'modern bluestockings' that will collate information about early feminists like Wollstonecroft (contact me for more information) – but ideally you could tailor the information you receive to your interests, whether it's football, music, fashion, history, literature or soap stars in Melbourne, Mumbai or Malmo. If I can get some content sources with good geo-data I might play with this at the museum hack day.

I'm still thinking about functionality, but a notification might look something like "did you know that [person/event blah] [lived/did blah/happened] around here? Find out more now/later [email me a link]; add this to your map for sharing/viewing later".

I've always been fascinated with the idea of making the invisible and intangible layers of history linked to any one location visible again. Millions of lives, ordinary or notable, have been lived in London (and in your city); imagine waiting at your local bus stop and having access to the countless stories and events that happened around you over the centuries. Wikinear is a great example, but it's currently limited to content on Wikipedia, and this content has to pass a 'notability' test that doesn't reflect local concepts of notability or 'interestingness'. Wikipedia isn't interested in the finds associated with an archaeological dig that happened at the end of your road in the 1970s, but with a bit of tinkering (or a nudge to me to find the time to make a better programmatic interface) you could get that information from the LAARC catalogue.

The nice thing about local data is that there are lots of people making content; the not nice thing about local data is that it's scattered all over the web, in all kinds of formats with all kinds of 'trustability', from museums/libraries/archives, to local councils to local enthusiasts and the occasional raving lunatic. If an application developer or content editor can't find information from trusted sources that fits the format required for their application, they'll use whatever they can find on other encyclopaedic repositories, hack federated searches, or they'll screen-scrape our data and generate their own set of entities (authority records) and object records. But what happens if a museum updates and republishes an incorrect record – will that change be reflected in various ad hoc data solutions? Surely it's better to acknowledge and play with this new information environment – better for our data and better for our audiences.

Preparing the data and/or the interface is not necessarily a project that should be specific to any one museum – it's the kind of project that would work well if it drew on resources from across the cultural heritage sector (assuming we all made our geo-located object data and authority records available and easily queryable; whether with a commonly agreed core schema or our own schemas that others could map between).

Location-linked data isn't only about official cultural heritage data; it could be used to display, preserve and commemorate histories that aren't 'notable' or 'historic' enough for recording officially, whether that's grime pirate radio stations in East London high-rise roofs or the sites of Turkish social clubs that are now new apartment buildings. Museums might not generate that data, but we could look at how it fits with user-generated content and with our collecting policies.

Or getting away from traditional cultural heritage, I'd love to know when I'm passing over the site of one of London's lost rivers, or a location that's mentioned in a film, novel or song.

[Updated December 2008 to add – as QR tags get more mainstream, they could provide a versatile and cheap way to provide links to online content, or 250 characters of information. That's more information than the average Blue Plaque.]

'Finding yourself with Fire Eagle' at WSG Findability

On Wednesday I went to the WSG London Findability event, and I've finally got the last of my notes up.

The final talk was from Steve Marshall, on 'Finding yourself with Fire Eagle'.

Steve doesn't work on Fire Eagle but made the Python library.

Fire Eagle is a service that helps you manage your location data.

Most location-aware applications have two parts – getting the location, and using the location.

Better model – distribute the location information, but the application getting the location still has to know who's using it.

Even better model: a brokering service. Fire Eagle sits between any 'getting' applications and any 'using' applications, and handles the exchange.

[FWIW, 'Fire Eagle is a brokering service for location data' is probably the best explanation I've heard, and I'd heard it before but I needed the context of the 'get' and the 'use' applications it sits between for it to stick in my brain.]

So how does it work? In the web application context (it's different for desktop or mobile applications):
Web app: app asks for Request Token
Fire Eagle: returns Request Token
Web app: user sent to Fire Eagle with token in URL
Fire Eagle: user chooses privacy levels and authorises app
Web app: user sent back to callback URL with Request Token
Web app: app initiates exchange of Request Token
Fire Eagle: Request Token exchanged for Access Token
Web app: app stores Access Token for user

You can manage your applications, and can revoke permissions (who can set or get your location) at any time. You can also temporarily hide your location, or purge all your data from the service. [Though it might be kept by the linked applications.]

How to use:
1. Get API key
2. Authenticate with user (OAuth)
3. Make API call

Concepts:
Locations can be a point or a bounding box.
Location hierarchy – a set of locations at varying degrees of precision.

[There was some good stuff on who could/is using it, and other ideas, but my notes got a bit useless around this point.]

In summary: you can share your location online, control your data and privacy, and easily build location services.

Discussion:
Question: what makes it special? Answer: it's not coupled to anything. It plays to the strengths of the developers who use it.

'Fire Eagle: twitter + upcoming + pixie dust'.

URLs are bookmarkable, which means they can be easy to use on phone [hooray]. It doesn't (currently) store location history, that's being discussed.

Qu: what's the business model? Ans: it's a Brickhouse project (from an incubator/start-up environment).

All methods are http requests at the moment, they might also use XMP ping.

Qu: opening up the beta? Ans: will give Fire Eagle invitations if you have an application that needs testing.

I had to leave before the end of the questions because the event was running over time and I had to meet people in another pub so I missed out on the probably really interesting conversations down the pub afterwards.

My notes:
Looking at their hierarchy of 'how precisely will you let application x locate you', it strikes me that it's quite country-dependent, as a postcode identifies a location very precisely within the UK (to within one of a few houses in a row) while in Australia, it just gives you the area of a huge suburb. I'm not sure if it's less precise in the US, where postcodes might fit better in the hierarchy.

I've also blogged some random thoughts on how services like Fire Eagle make location-linked cultural heritage projects more feasible.

'Building websites with findability in mind' at WSG London Findability

Last night I went to the WSG London Findability event at Westminster University, part of London Web Week; here's part two of my notes.

Stuart Colville's session on 'Building websites with findability in mind' was full of useful, practical advice.

Who needs to find your content?

Basic requirements:
Understand potential audience(s)
Content
Semantic markup
Accessibility (for people and user agents)
Search engine friendly

Content [largely about blogs]:
Make it compelling for your audience
There's less competition in niche subjects
Originality (synthesising content, or representing existing content in new ways is also good)
Stay on topic
Provide free, useful information or tools
Comments and discussion (from readers, and interactions with readers) are good

Tagging:
Author or user-generated, or both
Good for searching
Replaces fixed categories
Enables arbitrary associations
Rich

Markup (how to make content more findable):
Use web standards. They're not a magic fix but they'll put you way ahead. The content:code ratio is improved, and errors are reduced.
Use semantic markup. Adds meaning to content.
Try the roundabout SEO test
Make your sites accessible. Accessible content is indexable content.

Markup meta:
Keywords versus descriptions. Tailor descriptions for each page; they can be automatically generated; they can be used as summaries in search results.
WordPress has good plugins – metadescription for auto-generated metadata, there are others for manual metadata.

Markup titles and headings:
Make them good – they'll appear as bookmark etc titles.
One H1 per page; the most meaningful title for that page
Separate look from heading structure.

Markup text:
Use semantically correct elements to describe content. Strong, em, etc.

Markup imagery:
Background images are fine if they're only a design element.
Use image replacement if the images have meaning. There are some accessibility issues.
Use attributes correctly, and make sure they're relevant.

Markup microformats:
Microformats are a simple layer of structure around content
They're easy to add to your site
Yahoo! search and technorati index them, Firefox 3 will increase exposure.

Markup Javascript:
Start unobtrusive and enhance according to the capabilities of the user agent.
Don't be stupid. Use onClick, don't kill href (e.g. href="#").
Use event delegation – no inline events. It's search engine accessible, has nice clean markup and you still get all the functionality.
[Don't break links! I like opening a bunch of search results in new tabs, and I can't do that on your online catalogue, I'll shop somewhere I can. Rant over.]

Performance and indexation:
Use 'last modified' headers – concentrate search agents on fresh content
Sites with Google Ads are indexed more often.

URLs:
Hackable URLs are good [yay!].
Avoid query strings, they won't be indexed
Put keywords in your URL path
Use mod_rewrite, etc.

URI permanence:
"They should be forever". But you need to think about them so they can be forever even if you change your mind about implementation or content structure.
Use rewrites if you do change them.

De-indexing (if you've moved content)
Put up a 404 page with proper http headers. 410 'intentionally gone' is nice.
There's a tool on Google to quickly de-index content.
Make 404s useful to users – e.g. run an internal search and display likely results from your site based on their search engine keywords [or previous page title].

Robots.txt – really good but use carefully. Robots-Nocontent – Yahoo! introduced 'don't index' for e.g. divs but it hasn't caught on.

Moving content:
Use 301. Redirect users and get content re-indexed by search engines.

Tools for analysing your findability:
Google webmaster tools, Google analytics, log files. It's worth doing, check for broken links etc.

Summary:
Think about findability before you write a line of code.
Start with good content, then semantic markup and accessibility.
Use sensible headings, titles, links.

WSG London Findability 'introduction to findability'

Last night I went to the WSG London Findability event at Westminster University. The event was part of London Web Week. As always, apologies for any errors; corrections and comments are welcome.

First up was Cyril Doussin with an 'introduction to findability'.

A lot of it is based on research by Peter Morville, particularly Ambient Findability.

So what do people search for?
Knowledge – about oneself; about concepts/meaning; detailed info (product details, specs); entities in society (people, organisations, etc.)
Opinions – to validate a feeling or judgement; establish trust relationships; find complementary judgements.

What is information? From simple to complex – data -> information -> knowledge.

Findability is 'the quality of being locatable or navigatable'.
Item level – to what degree is a particular object easy to discover or locate?
System level – how well does the environment support navigation and retrieval?

Wayfinding requires: knowing where you are; knowing your destination; following the best route; being able to recognise your destination; being able to find your way back.

The next section was about how to make something findable:
The "in your face" discovery principle – expose the item in places known to be frequented by the target audience. He showed an example of a classic irritating Australian TV ad, a Brisbane carpet store in this case. It's disruptive and annoying, but everyone knows it exists. [Sadly, it made me a little bit homesick for Franco Cozzo. 'Megalo megalo megalo' is also a perfect example of targeting a niche audience, in this case the Greek and Italian speakers of Melbourne.]

Hand-guided navigation – sorting/ordering (e.g. sections of a restaurant menu); sign-posting.

Describe and browse (e.g. search engines) – similar to asking for directions or asking random questions; get a list of entry points to pages.

Mixing things up – the Google 'search within a search' and Yahoo!'s 'search assist' box both help users refine searches.

Recommendations (communication between peers) – the searcher describes intent; casual discussions; advice; past experiences.
The web is a referral system. Links are entry doors to your site. There's a need for a relevancy system whether search engines (PageRank) or peer-based systems (Digg).

Measuring relevance (effectiveness):
Precision – if it retrieves only relevant documents
Recall – whether it retrieves all relevant documents.

Good tests for the effectiveness of your relevance mechanism:
Precision = number of relevant and retrieved documents divided by the total number retrieved.
Recall = number of relevant and retrieved documents divided by the total number of relevant documents.

Relevance – need to identify the type of search:
Sample search – small number of documents are sufficient (e.g. first page of Google results)
Existence search – search for a specific document
Exhaustive search – full set of relevant data is needed.
Sample and existence searches require precision; exhaustive searches require recall.

Content organisation:
Taxonomy – organisation through labelling [but it seems in this context there's no hierarchy, the taxon are flat tags].
Ontology – taxonomy and inference rules.
Folksonomy – a social dimension.

[In the discussion he mentioned eRDF (embedded RDF) and microformats. Those magic words – subject : predicate : object.]

Content organisation is increasingly important because of the increasing volume of information and sharing of information. It's also a very good base for search engines.

Measuring findability on the web: count the number of steps to get there. There are many ways to get to data – search engines, peer-based lists and directories.

Recommendations:
Aim to strike a balance between sources e.g. search engine optimisation and peer-based.
Know the path(s) your audience(s) will follow (user testing)
Understand the types of search
Make advertising relevant (difficult, as it's so context-dependent)
Make content rich and relevant
Make your content structured

I've run out of lunch break now, but will write up the talks by Stuart Colville and Steve Marshall later.

Fun with Freebase

A video of a presentation to the Freebase User Group with some good stuff on data mining, visualisation (and some bonus API action) via the Freebase blog.

If you haven't seen it before, Freebase is 'an open database of the world's information', 'free for anyone to query, contribute to, built applications on top of, or integrate into their websites'. Check out this sample entry on the early feminist (and Londoner) Mary Wollstonecraft. The Freebase blog is generally worth a look, whether you're interested in Freebase or just thinking about APIs and data mashups.