91Èȱ¬

Historically FM&T Journalism has focused primarily onÌý. ÌýThe reasons for this are many and none of them are any of my business but it is odd, because the first experiments that 91Èȱ¬ News made with 'On Demand' started in the early 1970s and they were on television sets. ÌýThe experiment still exists today and it is called Ceefax.

The principle is relatively simple, take some text Journalists with access to agency feeds and ask them to write short news stories. ÌýThen ask them to keep them updated, all the time. ÌýAnd so On Demand Journalism was born - no printing presses or Six O'Clock bulletin to meet, just up-to-date information when the viewer wanted it.

Fast-forward thirty five years and those principles remain, albeit in aÌývastly improved, richer environmentÌýon the internet. ÌýNow it's the Journalists writing the 91Èȱ¬ News website that feed Ceefax and its digital progeny theÌý91Èȱ¬ Red Button service. ÌýAnd as we know from audience research, it's the Ceefax and Red Button services that are now seen as clunky and slow, particularly when compared to their online competitors.Ìý So why do we persist withÌýswitching off analogue TV? Well the Red Button service is actually far richer than Ceefax could ever hope to be, but both services are at a disadvantage because of the underlying technology shared by analogue and digital, whether it be terrestrial, satellite or cable: Broadcast.

Television has always been about communities, the sports audience in the pub,Ìý Ìýin the office or at school the next day, and now an increasing community around theÌýiPlayer, DVRs, Twitter etc.ÌýÌýBut if you free the device from the one-to-many model used for it's first 70 years the communities can be reached from within the TV itself, and the possibilities for programming are immense.

This is our motivation for exploring partnerships with companies involved with IPTV, and why we co-developed a prototype-application with Microsoft that wasÌý Ìýearlier this year. Ìý Ìýis set-top box software that (among other things) allows IP based assets to be overlaid on top of a broadcast signal on a TV set. Ìý

Immediately this allowed us to replicate a number of things we offer on the web, on a home TV set. Ìý A quick list would include:

• On demand video content
• Live video content (unlimited by bandwidth constraints we could offer one of as many streams as was navigationally prudent)
• On demand text and data content

• ÌýFeeds of user generated content

• Simple personalisation (local News, Sport and Weather based on postcode)

Features that would be useful to Journalism were included, regardless of whether we have the back-end systems to support them at the moment:

• Simple linking from one video asset to another ("You've watched this - and this is related/background/might make you laugh")
  

• Deeper linking from one part of one video asset to another asset ("If you need a bit of help getting your head around watching this, then watch this firstÌýand then come back here")

• Send (a link to) the video to a friend's mobile or TV

Features not included (yet)

• Social networking ("Enjoyed Question Time this week? ÌýLink to it on Facebook straight from your TV.")
  

• Alerts ("Your friend Jenny says - Stop watching Eastenders, look at this giant squid they've caught in Australia")

The demo continues to be shown by Microsoft at trade shows worldwide, as an advertisement for the flexibility of their platform, and I continue to show it off within the 91Èȱ¬ as a device to get people talking about what IPTV can offer Journalism in the future.

What's been most exciting about the project has been seeing how Journalists react when they understand how they could allow their viewers to lead their own way through a story.Ìý

The traditional News package about Karen Matthews (for instance) tells the story from the Journalist's point of view.Ìý There are different treatments of this depending on whether you are watching The One, Newsround, Newsnight, ITN or Sky News.Ìý

Or, you can split some of the different sections out in a linear way, on a website, like we did recently.

But if you allow the user to navigate the story themselves, from within the video, you allow them to create new versions of the story, all built from the same constituent elements and equally valid, but different in terms of tone or emphasis.

This comes down to the difference between On Demand media on the web and on TV, we're really in the dark here at the moment, as TV Platforms have some way to go to catch up with the web in terms of complexity of content offering and of audience behavior.Ìý My hunch is that the two are very different, and eventually the preferred methods that the audience uses for "telling themselves the story" will be quite divergent.

Initial user testing on the model has been positive.Ìý Not surprising, and we get this from all interactive TV research, is the tension between the linear TV programme the viewer was watching to start with and the interactive area they enter.Ìý If this transition is too jarring then people feel like their 'focus' is being changed for them and they reject that.Ìý

The TV is a device that people have a peculiar relationship with, they are normally in complete control of its functionality, but they can quickly become mesmerized under its spell.Ìý We upset this relationship at our peril.

Tristram Biggs is Executive Product Manager for TV Platforms at 91Èȱ¬ Future Media & Technology (Journalism)

• Bookmark with:
• |
• |
• |
• |
• - What's this?

We've been experimenting with the using a prototype called . The question that we're trying to answer is: Can a computer reliably identify the people and organisations in news stories? This is still work in progress, but we have a prototype and an API that you're welcome to explore.

When a journalist refers to someone in a news story they usually give the person's full name and enough information so the reader can understand who they are talking about. If the full name is ambiguous they may have to add a title or give an explanation about who the person is. But sometimes, especially for household names, the reader is expected to infer the identity of the person from the context of the story and by applying a reasonable level of background knowledge.

Whilst a human reader takes for granted their abilities to pick up journalists' cues and understand context, a computer has to be programmed explicitly. It is difficult to design a system that can identify people from text and disambiguate them. It is even harder to build a system that meets editorial standards of accuracy. However, in theory, it should be possible. So we've been experimenting to develop an approach that could lead to a system that reliably identifies people (and organisations) in stories and marks up their textual names with semantic information. There are four key challenges:

• Build working prototypes
• Write tests for the prototypes that express editorial standards
• Refine the prototypes to reach defined levels of reliability
• Express the information usefully through semantic mark-up

Prototypes

The prototypes are ready to share with you. They have been built for us by a company called based in Sheffield. They were a successful participant in the .

There are two systems available. They are both based on (the structured version of Wikipedia) which provides the controlled vocabulary of people and organisations. Therefore, in these prototypes each person in a news story is described by their Wikipedia entry. Potentially, Wikipedia is a good controlled vocabulary source for news because it has wide scope, is open and dynamic. It is certainly useful for prototyping.

• The first method is called "Muddy". It works by extracting proper names from the story text and then matches them to entries in DBpedia. If a term is ambiguous, the system uses various strategies based on Wikipedia's disambiguation pages and the structure of DBpedia to resolve the conflict. More information can be found on Rattle's website
• The second method is called "conText". It was initially proposed by Chris Sizemore and is described in detail in his blog post here. This method uses search technology (Google and Lucene) to enhance the results further.

The good news for anyone who is not an expert in term or knowledge extraction is that Rattle implemented both methods behind a common abstract . In effect we can treat both methods like black boxes. We don't need to know how they work to use them and evaluate their ability to identify people.

In addition, Rattle implemented some visualisations so that we can get a feel for how the systems work. Below are some sample stories that have had people and organisations identified. You can also submit additional stories by following the final link.

Testing

It doesn't take long to see that neither prototype is perfect. Sometimes they miss people and sometimes they get them wrong. But that is the point of the research. How good are they really and can they be improved? Our next step is to measure them against our editorial standards.

So currently we are working with another Innovation Labs entrant to develop some tests. We're going to compare the performance of both systems (and any system that implements Rattle's API) to the performance of human beings. We will also be proposing measures that evaluate the systems from an editorial point of view. For example, is it editorially more acceptable for the system to fail to spot the name of cat owner whose cat gets stuck in a tree than the Prime Minister? And what should the system do when the name of that cat owner is Gordon Brown?

We will post more about this and our initial findings in the New Year, but in the meantime we'd like to hear your thoughts and feel free to have a look at the API and the prototypes.

• Bookmark with:
• |
• |
• |
• |
• - What's this?

Last August, the 91Èȱ¬ÌýtrialledÌýa new service calledÌýÌýon a hand picked selection of news stories (e.g.Ìý). Apture allows journalists to add links to the text of published stories and displays the link content in popover windows within the story page. This caused a bit of a buzz at the time on theÌý91Èȱ¬ Internet blog. So we thought we'd start our new blog by sharing our findings and set out what we're going to do next in this area.

Throughout the trial, we asked for feedback from the audience using a link at the bottom of each Apture window. This opened a pop-up window where people could state whether they found the service useful and then leave a text comment.

Your Feedback

Over 1200 people used this to give us feedback during the two weeks, which we think is quite a high response for such a limited piece of work. Over 90% of those that responded said that they found Apture useful. This was an unexpected result, even considering that the opt-in nature of the trial favoured early adopters.

Over 854 people left a positive comment. Whilst over half of those gave generic praise such as "I liked it", there were three key themes that dominated the comments:

• 177 people stated that they appreciated being able to explore background material without leaving the page or searching.
• 119 people said that they appreciated the editorial content in the links and made a specific reference to the fact the content was added manually.
• 98 people approved of the design of the system. This included that links were inline and could be turned off and on.

We also received 306 negative comments. There were a diverse range of concerns. The blog discussion focussed on the issues of simple hyperlinks, accessibility and web citizenship and we received 32 comments related to these issues. The top three concerns raised were:

• 65 people objected to the use of icons in the inline links. In particular, the use of a "W" to indicate a link to Wikipedia caused problems. Apture have now changed this, but there still questions about how to signal the content of links
• 55 people were unsure whether the 91Èȱ¬ should link to Wikipedia, raising issues of accuracy, perhaps echoing the that followed the .
• 50 people found that security restrictions caused a problem. This was often down to a local firewall that allowed access to the 91Èȱ¬, but blocked third party content. Also for some people Flash was not installed on their machine. This is a timely reminder that there can be problems when people move to rich AV and mashups.

Overall, we thought there was a lot that was interesting about these results. Clearly many people appreciate high quality, crafted background links in news stories. And, for the right kind of background information, some people appreciate being able to see it without having to navigate away from the page. The key challenges for us are two-fold:

• Can we deliver in-page navigation using baked in hyperlinks, maintain high standards of accessibility and serve those who prefer traditional linking behaviour?
• Can we provide journalists with the right tools so they can be at their most creative editorially and use their skills to provide the most relevant interesting links?

So what are we doing next?

We've decided to do go back to basics and look again at the fundamentals of linking in news stories. When the 91Èȱ¬ News website started in 1997 we placed background links to the side of the article instead of inline, for technical and user experience reasons. We haven't revisited that decision in any significant way until now.

In 2009, we're going to be refreshing how we markup our stories. We will discuss the details of this project in more detail here later. But this will give us a rare opportunity to improve the way we express links. We want to get that right. In the meantime, we're talking to Apture to explore whether it's possible to extend their product to deliver the functionality you liked and to answer your concerns.

There is plenty more about this trial that we could share and we'd really be interested to hear your thoughts and about what interests you the most. So leave a comment and we'll try to answer your questions.

Sample Stories

• Bookmark with:
• |
• |
• |
• |
• - What's this?