Ubiquitous I A: Building for change and web 3.0Presentation Transcript
Ubiquitous Information Architecture: Building for change and Web 3.0 Chris Thorne Information Architect BBC
Me
An Information Architect.
Playing in metadata and the web since 1999.
Before that a Multimedia Research Scientist (for Philips Electronics).
About the BBC
The largest broadcasting corporation in the world
Mission: To inform, educate and entertain.
Public service broadcaster, established by a Royal Charter and funded by the licence fee that is paid by UK households.
Services include: 8 national TV channels plus regional programming, 10 national radio stations, 40 local radio stations and an extensive website, bbc.co.uk.
My Part of the BBC
- Provides web technology for the whole of the BBC.
- Primary customers - BBC Audio, Music and Mobile.
My Part of the BBC
/Programmes – a multiplatform dynamic semantic publishing service to support all programmes broadcast by the BBC.
My Part of the BBC
/Programmes – a multiplatform dynamic semantic publishing service to support all programmes broadcast by the BBC.
My Part of the BBC
/music – a multiplatform dynamic published semantic service to support music activities by the BBC.
My Part of the BBC - Multiplatform
PC, Mac, Mobile (WAP, iphone et al) and future devices and platforms.
As Information Architects
We play a key role in determining:
How information systems interact.
How information is stored.
How users and businesses get the most out of these systems and services.
The world around us is changing……
‘ Ever more pervasive, ever harder to perceive, computing has leapt off the desktop and insinuated itself into everyday life. Such ubiquitous information technology “everyware” – will appear in many different contexts and take a wide variety of forms, but it will effect almost every one of us, whether we’re aware of it or not”.
[‘Everyware: The dawning age of ubiquitous computing’ – Adam Greenfield]
Mobile Devices
Kiosks and multi user devices
Public Information/Advertising
Discound/Credit/Travel Cards and readers
Radios using the web
Even TV is changing – the web is on TV
And how is the web? :-)
Where we are now – web 2.0
Computers can’t help much
The Apple=Apple=Apple problem.
A computer struggles to understand the different ‘Apples’.
Web 2.0 - Too many Silos.
If you want to use a web 2.0 service in your website, you have to persuade your engineers and developers to learn a new API, with new data formats and new interfaces.
The Semantic Web is not just academic….
The challenges include everyday life.
Its hard getting to work.
Its hard shopping for stuff.
Its hard to socialise……
These user journeys are part of our everyday lives and yet the web and current everyware isn’t that much help.
Semantic Web – A web for machines.
Trying to build a web of things (including documents) that machines can understand.
So machines can help us solve everyday problems more easily.
Idea 1
‘ Everyware’ is here now and will increasingly influence our everyday lives.
Idea 1 continued
But it needs a lot of improvement.
(we still have a job, yay!)
Idea 2
The Semantic web will succeed.
It will be web 3.0, web 4.0 or web 5.0……
Semantic web will power significant amounts of everyware.
Idea 3
Information Architects need to engage with semantic web and ‘everyware’…..
Idea 4
We can build now for a semantic future, where the web is supporting a variety of information services and devices.
Idea 4 continued
… .even if we’re building microsites.
Idea 4 continued
… .even if they are statically
published.
… ..The BBC and others are doing this now.
Semantic Web – machine readable data
Trying to explain:
Who
What
Where
When
To machines……
The BBC Semantic Ambition:
Progress so far:
Progress so far:
Progress so far:
Bbc.co.uk/music
Powered by musicbrainz data.
440825 artist profiles and growing.
BBC is not solely responsible for maintaining and growing the database - but is able to contribute BBC effort to the benefit of the whole web.
Semantic Web - How does it work?
Standardised building blocks – XML, RDF, Ontologies, HTTP
Allows easier exchange, crawling and use of data.
Semantic Web - Layers of a cake?
Semantic Web - Example RDF statements Statement 1: Chris - Knows - Michael. Statement 2: Chris - Lives in - London Statement 3: Chris - Age - 34. Ie simple statements about things. Aka ‘triples’ - dbpedia.org has 116.7 million triples.
Semantic web - Linked Data Principles
Use URIs as names for things.
Use HTTP URIs so that people can look up those names.
When someone looks up a URI, provide useful RDF information.
Include RDF statements that link to other URIs so that they can discover related things.
Tim Berners-Lee 2007
http://www.w3.org/DesignIssues/LinkedData.html
In other words
Based on standard web etiquette. BUT…..
Without unique URIs and persistent URIs, people aren’t going to like using your data.
Each time they want to know something its in a different place? You’re having a laugh :-).
Semantic Web, Restful design, Google juice
Publishing semantic data, like maximising google ‘pagerank’, relies on persistence.
The URIs you use should be persistent.
Otherwise your google juice/other companies/users/machines get lost.
Google pagerank maximising – what we know...
Do good stuff.
Practice RESTfull principles.
Put your ‘good stuff’ in one place only.
Keep it there forever.
Get your H1s right.
Tell others so they link to it.
Get companies with a high page rank to link to it.
Restful design principles in brief:
If the contents of a page changes state, the URI changes.
This means personalisation using cookies can be bad – if a page has changed state without changing the URI.
The musicbrainz identifier for the artist ‘Prince’.
It doesn’t change, even if he changes his name. This allows carefully built URIs involving Prince to be persistent.
It is webscale because it is understood by more than one website.
This enables BBC, Musicbrainz and LastFM to exchange data about an artist easily.
In fact, identifiers are useful for all websites……..
Google and identifiers in URLs.
Persistence is most important.
Other sites link to you = higher page rank.
Users can bookmark and share persistent content.
If you move your pages to new URLs you lose google juice.
[ok you can put in a HTTP 301, but its still bad, as Tim BL says ‘Cool URIs don’t change’]
[see: http://www.w3.org/Provider/Style/URI ]
Identifiers – Helping us cope with change.
Avoid losing your google juice when names change.
Unique alpha numeric codes used to uniquely identify a thing.
Must be persistent.
Use the same identifier across several companies to make information exchange easier.
How BBC designs Persistant URIs - tips
Persistent URIs are built from our knowledge of the domains we work in…….
/Programmes Domain
Domain modelling tips:
You’re modelling things not web pages.
Trying to understand the relationships between the things.
I As work with domain experts to model the domain and understand it.
Its hard, it takes time to get something you believe in, but it’s a really really important step in semantic web design.
Consider the Episode… Can have a parent brand or series…… Episode 4 of Top Gear series 10 for example…… What is the URI?
URI of Top Gear Series 10 episode 4.
Could be: bbc.co.uk/programmes/topgear/series10/episode4.shtml
But we don’t put our technology (.shtml) into the URI.
We don’t put technology into the URI
If users want the document, they don’t mind what technology delivers it, they just want the information at that URI.
They don’t want to have to go to different URIs on different devices. Why do they have to remember?
Remember everyware? Multiplatform is going to become more of an issue.
The technology used might change over the next few years.
URI of Top Gear Series 10 episode 4 ctd.
Could be:
bbc.co.uk/topgear/series10/episode4
But from our discussions with the domain masters (editorial staff).
The same episode could be broadcast by different brands (Top Gear, Best of Top Gear, Top Gear Take 2 etc).
The episode could be reused across different series.
The episode could change its title over its lifetime.
URI of Top Gear Series 10 episode 4. Oh dear.
URI of Top Gear Series 10 episode 4. In fact the URI of the document about this episode is: http://www. bbc .co.uk/programmes/b0087f0s
URI design and change http://www.bbc.co.uk/programmes/b0087f0s We’ve taken out everything that can change . We’re using our own identifier ( http://www.bbc.co.uk/programmes/b0087f0s ) to label it because there wasn’t a suitable webscale identifier already in semantic web for programmes, and because everything else (title, series, brand etc) could change.
URI design and change continued. http://www.bbc.co.uk/programmes/b0087f0s If it can change (brand, title, series, episode number), we’ve taken it out of the URI.
Categories, taxonomys on the page….not in the URI.
Categories, taxonomys on the page….not in the URI.
Because categories and taxonomies will change during the lifetime of the product and your website……
URI design to maximise persistance. Know your domain. Work out your business rules. Think about all the things that might change (including each time you redesign the website). Take them out of the URI. www.mycompany.com/products/:product Might be a good place to start, where ‘:product’ is an identifier.
Designing for multiplatform So, how to deliver the document across multiple platforms, at the same URI?
Content negotiation example:
Multiplatform design at the same URI:
Delivering the same information but in the most appropriate way for that device.
So the RDF document is just the same as the HTML document, but expressed in a different language.
The mobile document is the same as the HTML, but perhaps without images, or with the current information emphasised and other information linked to rather than put on the page.