Scientific publishing has in many ways remained largely unchanged since 1665. Scientific discoveries are still published in journal articles where the article is a review, a piece of metadata if you will, of the scientists’ research.

Cover of the first issue of Nature, 4 November 1869.

This is of course not all bad. For example, I think it is fair to say that this approach has played a part in creating the modern world. The scientific project has helped us understand the universe, helped eradicate diseases, helped decreased child mortality and helped free us from the drudgery of mere survival. The process of publishing peer reviewed articles is the primary means of disseminating this human knowledge and as such has been, and remains, central to the scientific project.

And if I am being honest nor is it entirely fair, to claim that things haven’t changed in all those years – clearly they have. Recently new technologies, notably the Web, have made it easier to publish and disseminate those articles, which in turn has lead to changes in the associated business models of publishers e.g. Open Access publications.

However, it seems to me that scientific publishers and the scientific community at large has yet to fully utilize the strengths of the Web.

Content is distributed over http but what is distributed is still, in essence, a print journal over the Web. Little has changed since 1665 – the primary objects, the things a SMT publisher publishes remain the article, issue and journal.

The power of the Web is its ability to share information via URIs and more specifically its ability to globally distribute a wide range of documents and media types (from text to video to raw data and software (as source code or as binaries)). The second and possibly more powerful aspect of the Web is its ability to allow people to recombine information, to make assertions and statements about things in the world and information on the Web. These assertions can create new knowledge and aid discoverability of information.

This is not to say that there shouldn’t be research articles and journals – both provide value – for example journals provides a useful point of aggregation and quality assurance to the author and reader. The article is an immutable summary of the researchers work at a given date and, of course, the paper remains the primary means of communication between scientists. However, the Web provides mechanisms to greatly enhance the article, to make it more discoverable and allow it to place it into a wider context.

In addition to the published article STM publishers already publish supporting information in the form of ‘supplementary information’ unfortunately this is often little more than a PDF document. However, it is also not clear (to me at least) if the article is the right location for some of this material – it appears to me that a more useful approach is that of the ‘Research Object’ [pdf], semantically rich aggregations of resources, as proposed by the Force11 community.

It seems to me that the notion of a Research Object as the primary published object is a powerful one. One that might make research more useful.

What is a Research Object?

Well what I mean by a Research Object is a URI (and if one must a DOI) that identifies a distinct piece of scientific work. An Open Access ‘container’ that would allow an author to group together all the aspects of their research into a single location. These resources within it might include:

• The published article or articles if a piece of research resulted in a number of articles (whether they be OA or not);
• The raw data behind the paper(s) or individual figures within the paper(s) (published in a non-proprietary format e.g. csv not Excel);
• The protocols used (so an experiment can be easily replicated);
• Supporting or supplementary video;
• URLs to News and Views or other commentary from the Publisher or elsewhere;
• URLs to news stories;
• URLs to university reading lists;
• URLs to profile pages of the authors and researchers involved in the work;
• URLs to the organizations involved in the work (e.g. funding bodies, host university or research lab etc.);
• Links to other research (both historical i.e. bibliographic information but also research that has occurred since publication).

Furthermore, the relationship between the different entities within a Research Object should be explicit. It is not enough to treat a Research Object as a bag of stuff, there should be stated and explicit relationship between the resources held within a Research Object. For example, the relationship between the research and the funding organization should be defined via a vocabulary (e.g. funded_by), likewise any raw data should be identified as such and where appropriate linked to the relevant figures within a paper.

Something like this:

The major components of a Research Object.

It is important to note that while the Research Object is open access the resources it contains may or may not be. For example, the raw data might be open whereas the article might not. People would therefore be able to reference the Research Object, point to it on the Web, discuss it and make assertions about it.

In the FRBR world a Research Object would be a Work i.e. a “distinct intellectual creation”.

Making research more discoverable

The current publishing paradigm places seriously limitations on the discoverability of research articles (or research objects).

Scientists work with others to research a domain of knowledge; in some respects therefore research articles are metadata about the universe (or at least the experiment). They are assertions, made by a group of people, about a particular thing based on their research and the data gathered. It would therefore be helpful if scientists could discover prior research along these lines of enquiry.

Implicit in the above description of a Research Object is the need to publish URIs about: people, organisations (universities, research labs, funding bodies etc.) and areas of research.

These URIs and the links between them would provide a rich network of science – a graph that describes and maps out the interrelationships between people, organisations and their area of interest, each annotated with research objects, such a graph would also allow for pages such as:

• All published research by an author;
• All published research by a research lab;
• The researchers that have worked together in a lab;
• The researchers who have collaborated on a published paper;
• The areas of research by lab, funding body or individual;
• Etc.

Such a graph would help readers to both ‘follow their nose’ to discover research and provide meaningful landing pages for search.

Digital curation

One of the significant benefits a journal brings to its readership is the role of curation. The editors of the journal selects and publishes the best research for their readers. On the Web there is no reason this role couldn’t be extended beyond the editor to the users and readers of a site.

Different readers will have different motivations for doing so but providing a mechanism for those users to aggregate and annotate research objects provides a new and potentially powerful mechanism by which scientific discoveries could be surfaced.

For example, a lecturer might curate a collection of papers for an undergraduate class on genomics, combining research objects with their own comments, video and links to other content across the web. This collection could then be shared and used more widely with other lecturers. Alternatively a research lab might curate a collection of papers relevant to their area of research but choose to keep it private.

Providing a rich web of semantically linked resources in this way would allow for the development of a number of different metrics (in addition to Impact Factor). These metrics would not need to be limited to scientific impact; they could be extended to cover:

• Educational indices – a measure of the citations in university reading lists;
• Social impact – a measure of citations in the mainstream media;
• Scientific impact of individual papers;
• Impact of individual scientists or research labs;
• Etc.

Such metrics could be used directly e.g. research indexes or; indirectly e.g. to help readers find the best/ most relevant content.

Finally it is worth remembering that in all cases this information should be available for both humans and machines to consume and process. In other words this information should be available in structured, machine readable formats.

Banksy by rocor, some rights reserved.

Anyway when we started work on on the BBC’s Nature site we set out our development manifesto. I thought you might be interested in it:

1. Peristence — only mint a new URIs if one doesn’t already exist: once minted, never delete it
2. Linked open data — data and documents describe the real world; things in the real world are identified via HTTP URIs; links describe how those things are related to each other.
3. The website is the API
4. RESTful — the Web is stateless, work with this architecture, not against it.
5. One Web – one canonical URI for each resource (thing), dereferenced to the appropriate representation (HTML, JSON, RDF, etc.).
6. Fix the data don’t hack the code
7. Books have pages, the web has links
8. Do it right or don’t do it at all — don’t hack in quick fixes or ‘tactical solutions’ they are bad for users and bad for the code.
9. Release early, release often — small, incremental changes are easy to test and proof.

It’s worth noting that we didn’t always live up to these standards — but at least when we broke our rules we did so knowingly and had a chance of fixing them at a later date.

This is a very, very good idea – it should allow for better content discovery, new ways to aggregate news stories about people, places or subjects and generally allow computers to help people process some of the structured information behind a story.

Newspaper by Luc De Leeuw

rNews is still in draft. At the time of writing the published spec is at version 0.1, there are clearly ambitions to built out on this work and it will be interesting to see where it goes.

Although I’m sure much of this has been thought about before I thought I would jot down my initial thoughts on this early draft.

More URIs please

The current spec makes extensive use of xsd:string and xsd:double to assign attributes to a class. For example, the Location Class includes attributes for longitude, latitude and altitude but no URIs for places.

Using URIs to name places (and people, subjects, organisations etc.) would allow for much more interesting things to be done with the data.

It would make it easier to aggregate content from more than one news outlet and generally link things together by location, person and area of interest.

There’s obviously an issue here – there needs to be a good source of URI for places – but in reality there are lots of candidates out there from dbpedia to geonames.

Greater reuse of existing vocabularies

There are existing vocabularies that describe the some of the classes described in rNew – notably FOAF and Dublin Core.

I would prefer rNews reusing those vocabularies or at least linking (owl:sameAS) to them.

I’m not a fan of tags

I don’t really like “tagging” it lack semantics and is extremely ambiguous.

If I tag a news story am I claiming it’s primarily about that thing, features that thing, also about that thing, what? And whatever you think it means I guarantee I can find someone else who disagrees!

I would rather see more defined predicates such as primarilyAbout etc. I recognise this would add a bit of complexity but it would also increase the utility of the vocabulary.

If the intention is to aid discoverability through categorisation then use SKOS.

Explicit predicates for source materials

I think it’s really important to explicitly link to source material, especially for science and medicine (it’s why Nature News and has always done so).

A simple set of predicates for the DOI, abstract URI, scientist/researcher of the original research and/or a URI for the raw data should suffice.

Again, it would also help if there was a handy source of URIs for scientists.

Should the story be at the heart of the ontology?

I’ve always thought of news stories as metadata about real world events.

If you reframe the problem in this way then what you really want are predicates to describe the relationship of the story (article, photo, video) to the event. You also then want links between people & places and those events (which could be inferred through the various news stories).

Building the ontology this way round would allow for some very powerful analysis and discovery of stories.

Anyway – I’ll be really interested to see how the ontology develops and how widely it gets adopted.

The big change to this version is the removal of much of the publication specific stuff since this is handled elsewhere otherwise otherwise it should look like a fairly obvious evolution from the previous versions.

Version 3 of the science domain model

And here’s a N3 serialisation of the model. There’s still lots to do, it needs checking against what happens when there are multiple ranges are given for a property, we need to write proper definitions, add namespaces, look for existing ontology reuse etc.

<!-- Science Ontology - First version! Still to do: Declare namespaces Define ontology (name, author etc) Finish definitions Look for existing ontologies for reuse etc. Publish! -->

<!-- Classes -->

so:Observation a owl:Class;
	rdfs:label "Observation";
	rdfs:comment "Definition goes here" .

so:Hypothesis a owl:Class;
	rdfs:label "Hypothesis";
	rdfs:comment "Definition goes here" .

so:Experiment a owl:Class;
	rdfs:label "Experiment";
	rdfs:comment "Definition goes here" .

so:Equipment a owl:Class;
	rdfs:label "Equipment";
	rdfs:comment "Definition goes here" .

so:Method a owl:Class;
	rdfs:label "Method";
	rdfs:comment "Definition goes here" .

so:Collaboration a owl:Class;
	rdfs:label "Collaboration";
	rdfs:comment "Definition goes here" .

so:ExperimentalObservation a owl:Class;
	rdfs:label "Experimental Observation";
	rdfs:comment "Definition goes here";
	rdfs:subClassOf so:Observation .

so:Data a owl:Class;
	rdfs:label "Data";
	rdfs:comment "Definition goes here" .

so:Analysis a owl:Class;
	rdfs:label "Analysis";
	rdfs:comment "Definition goes here" .

so:Publication a owl:Class;
	rdfs:label "Publication";
	rdfs:comment "Definition goes here" .

so:Theory a owl:Class;
	rdfs:label "Theory";
	rdfs:comment "Definition goes here" .

so:Prediction a owl:Class;
	rdfs:label "Prediction";
	rdfs:comment "Definition goes here" .

so:Agent a owl:Class;
	rdfs:label "Agent";
	rdfs:comment "Definition goes here"
	rdfs:subClassOf foaf:Agent .

<!-- Properties -->

so:inspiredBy a owl:ObjectProperty;
	rdfs:label "inspiredBy";
	rdfs:comment "definition goes here - but what happens with multiple ranges? hypotheses can be inspired by Observations, Theories and Predictions...";
	rdfs:domain so:Hypothesis;
	rdfs:range so:Observation;
	rdfs:range so:Theory;
	rdfs:range so:Prediction .

so:makes a owl:ObjectProperty;
	rdfs:label "makes";
	rdfs:comment "definition goes here";
	rdfs:domain so:Theory;
	rdfs:range so:Prediction .

so:tests a owl:ObjectProperty;
	rdfs:label "tests";
	rdfs:comment "definition goes here";
	rdfs:domain so:Experiment;
	rdfs:range so:Hypothesis .

so:equipment a owl:ObjectProperty;
	rdfs:label "equipment";
	rdfs:comment "Relates a piece of equipment to an experiment it is used in.";
	rdfs:domain so:Experiment;
	rdfs:range so:Equipment .

so:method a owl:ObjectProperty;
	rdfs:label "method";
	rdfs:comment "Relates a method to an experiment it was used in.";
	rdfs:domain so:Experiment;
	rdfs:range so:Method .

so:experimentalObservation a owl:ObjectProperty;
	rdfs:label "experimental observation";
	rdfs:comment "Relates an observation made as a result of an experiment to the experiment it was made in.";
	rdfs:domain so:Experiment;
	rdfs:range so:ExperimentalObservation .

so:captures a owl:ObjectProperty;
	rdfs:label "captures";
	rdfs:comment "Relates data to an experimental observation it was captured in.";
	rdfs:domain so:ExperimentalObservation;
	rdfs:range so:Data .

so:analyses a owl:ObjectProperty;
	rdfs:label "analyses";
	rdfs:comment "Definition goes here";
	rdfs:domain so:Analysis;
	rdfs:range so:Data .

so:published a owl:ObjectProperty;
	rdfs:label "published";
	rdfs:comment "Relates an Analysis to a Publication it was published in.";
	rdfs:domain so:Analysis;
	rdfs:range so:Publication .

<!-- Analysis to Theory -->

so:establishes a owl:ObjectProperty;
	rdfs:label "establishes";
	rdfs:comment "Definition goes here";
	rdfs:domain so:Analysis;
	rdfs:range so:Theory .

so:validates a owl:ObjectProperty;
	rdfs:label "validates";
	rdfs:comment "Definition goes here.";
	rdfs:domain so:Analysis;
	rdfs:range so:Theory .

so:modifies a owl:ObjectProperty;
	rdfs:label "modifies";
	rdfs:comment "Definition goes here.";
	rdfs:domain so:Analysis;
	rdfs:range so:Theory .

so:contradicts a owl:ObjectProperty;
	rdfs:label "contradicts";
	rdfs:comment "Definition goes here.";
	rdfs:domain so:Analysis;
	rdfs:range so:Theory .

<!-- Analysis to Hypothesis -->

so:supports a owl:ObjectProperty;
	rdfs:label "supports";
	rdfs:comment "Definition goes here.";
	rdfs:domain so:Analysis;
	rdfs:range so:Hypothesis .

so:modifies a owl:ObjectProperty;
	rdfs:label "modifies";
	rdfs:comment "Definition goes here.";
	rdfs:domain so:Analysis;
	rdfs:range so:Hypothesis .

so:disproves a owl:ObjectProperty;
	rdfs:label "disproves";
	rdfs:comment "Definition goes here.";
	rdfs:domain so:Analysis;
	rdfs:range so:Hypothesis .

<!-- Agent properties -->

so:proposes a owl:ObjectProperty;
	rdfs:label "proposes";
	rdfs:comment "Definition goes here.";
	rdfs:domain so:Agent;
	rdfs:range so:Hypothesis .

so:collaborates a owl:ObjectProperty;
	rdfs:label "collaborates";
	rdfs:comment "Definition goes here.";
	rdfs:domain so:Agent;
	rdfs:range so:Collaboration .

so:funds a owl:ObjectProperty;
	rdfs:label "funds";
	rdfs:comment "Definition goes here.";
	rdfs:domain so:Agent;
	rdfs:range so:Experiment .

so:performs a owl:ObjectProperty;
	rdfs:label "performs";
	rdfs:comment "Definition goes here.";
	rdfs:domain so:Agent;
	rdfs:range so:Experiment .

so:observes a owl:ObjectProperty;
	rdfs:label "proposes";
	rdfs:comment "Definition goes here.";
	rdfs:domain so:Agent;
	rdfs:range so:Observation .

so:forms a owl:ObjectProperty;
	rdfs:label "forms";
	rdfs:comment "Definition goes here.";
	rdfs:domain so:Agent;
	rdfs:range so:Analysis .

so:creates a owl:ObjectProperty;
	rdfs:label "creates";
	rdfs:comment "Definition goes here.";
	rdfs:domain so:Agent;
	rdfs:range so:Publication .

so:creditedWith a owl:ObjectProperty;
	rdfs:label "credited with";
	rdfs:comment "Definition goes here.";
	rdfs:domain so:Agent;
	rdfs:range so:Theory .

so:participates a owl:ObjectProperty;
	rdfs:label "participates";
	rdfs:comment "Definition goes here.";
	rdfs:domain so:Agent;
	rdfs:range so:Agent .

so:collaboratesOn a owl:ObjectProperty;
	rdfs:label "proposes";
	rdfs:comment "Definition goes here.";
	rdfs:domain so:Collaboration;
	rdfs:range so:Experiment;
	rdfs:range so:Hypothesis .

Second attempt at a science ontology

A few things worth highlighting:

The previous version contained included “Observation” defined as “an observed phenomena in the natural world cf “data” an observation resulting from an experiment.” While I still think the concept is valid (people observe things in the natural world and wonder why its like that) the term caused confusion – it wasn’t clear that that sort of observation was different from experimental observations. So now have two concepts:

1. Noticings – which replaces the previous “Observations” i.e. is an observed phenomena in the natural world;
2. Observations – which are experimental observations.

We added in “equipment” and “method” to experiment – this allows us to have URIs for things like the LHC and the Hubble Space Telescope which is handy.

We’ve expanded out the agent role a bit to include “Collaborations” which hopefully allows for the modeling of research projects such as the LHC, the Human Genome Project and the like.

And finally we’ve fleshed out the paper, peer review stuff.

What do you think?

First attempt at a science ontology

To give  a bit of context – the idea behind the ontology is to provide a relatively high level model to describe the scientific method so that organisations, such as the BBC, could structure their content (archive footage, news stories etc.) using the model.

Hopefully most of the terms used are self explanatory, but for those that might not be:

Hypothesis – to quote from Princeton University – an hypothesis is a “a tentative insight into the natural world; a concept that is not yet verified but that if true would explain certain facts or phenomena”. A non-scientist might call this a theory.

Theory – again to quote from Princeton University a theory is “a well-substantiated explanation of some aspect of the natural world; an organized system of accepted knowledge that applies in a variety of circumstances to explain a specific set of phenomena.”  A non-scientist might think of this as a ‘fact’.

Agent – adopting the FOAF:agent this is a person or organisation.

Observation – an observed phenomena in the natural world cf “data” an observation resulting from an experiment.

As others have already pointed out we’re missing a lot of detail around the role of the agent, we’re missing important predicates, such as other forms of influence other than publication. And looking at it again we’ve failed to include anything about the predictions a theory might make of the natural world. But what else are we missing?

Now until recently I would have said “yes you do need both”, but recently I’ve been thinking that perhaps it’s not quite so black and white.

Before I get into why I think it probably makes sense to backtrack a little and explain the background to the question. After all for many people this question seems odd: why on earth would you need a URI for anything other than the web page, the document?

Library Parabola by Alex Watson, some rights reserved

In the real world we give all sorts of things identifiers: people have passports and National Insurance Numbers; buildings get Post Codes; books ISBNs etc. We do this because it’s useful to be able to unambiguously identify stuff. To be able to point, discuss and share information about things.

On the Internet we have email addresses and URIs on the Web. OpenID for example is predicated on the notion that a person can have an URI to identify themselves. And the Linked Data project gives URIs for not just people, but all sorts of things: people, places, animals, music, and through dbpedia the myriad of things described in Wikipedia.

Once you have an identifier for a thing you can make assertions about that thing. How big it is, where it is (in the real world), when it was created, who owns it, anything. You can also describe how those things relate to other things – this person is friends with this person and works for this company, which is at this address etc.

Now many people will tell you (indeed I probably will too) that you need to distinguish the statements you make about the thing in the real world from the statements about the document. For example, a URI for me might return a document with some information about me, but the creation date for that document and the creation date for me are two different things. And because you don’t want to get confused it’s better to have a URI for the thing and another one for the document making assertions about the thing. Make sense?

For those that are interested there are a couple of different ways of achieving this separation. For the purposes of this post it’s not important to know how to do this, but if you’re interested have a look at this paper by Richard.

But here’s the thing, many people will tell you that this is all too complex and frankly unnecessary, indeed you may well be thinking the same thing right about now.

Some people will tell you that the whole non-information resource thing isn’t necessary – we have a web of documents and we just don’t need to worry about URIs for non-information resources; others will claim that everything is a thing and so every URL is, in effect, a non-information resource.

Michael, however, recently made a very good point (as usual): all the interesting assertions are about real world things not documents. The only metadata, the only assertions people talk about when it comes to documents are relatively boring: author, publication date, copyright details etc.

If this is the case then perhaps we should focus on using RDF to describe real world things, and not the documents about those things.

On the Web there are a number of different ways of making an assertion about a thing (as identified via a URI): you can state how it relates to other things, you can link it to a piece of data (e.g. RDF literals) or you can link it to a document which makes some statements about the thing (e.g. a news article).

The question is: is there much utility in defining non-information resources in this third scenario: do you need URIs for the documents? Obviously they still need a URL so you can link to it and you should make that document available in a variety of representations but do you need a separate identifier for the non-information resource?

I think not.

This is how I’ve started to think about it: RDF is a great way of describing how (real world) things relate to each other and for this you need URIs for non-information resources. And because you’re dealing with real world things (I know documents are real world things too, but going down this path is how we ended up with the confusion we have today) you will hopefully have interesting and useful links to other things, useful chunks of data and links to useful documents about that thing. Those documents could be in any format – they could be an HTML document, a (Flash) movie, MP3 file, even a csv file. The point is the documents decorate the tree they are discoverable via the RDF graph but they don’t need to be published as RDF themselves.

An RDF graph of things is therefore a great way to: discover documents, to make assertions and share what we know about how those things. Or put another way RDF is a way of building a vocabulary to describe how web resources related to real world objects. I my however me wrong and I would be interested to hear what others think.

It’s the classic internet hourglass with signal carriers down the bottom, IP in the middle and applications up top. You can see the World Wide Web perched atop HTTP, one more technical layer in a technical layer cake.

It’s maybe because I’m not that technical but I’ve never really seen the web as a technical layer on top of the internet. In terms of technical design there’s not that much there. The design decisions of the web always seemed more political / ethical than pure technical. So at least in my opinion the web is a political / ethical layer above the internet.

As Ben Ward recently pointed out we tend to obsess on new standards OAuth, OpenID, Contacts, Connect, Geolocation, microformats, widgets, AJAX, HTML5, local storage, SPDY, ‘The Cloud’ and lose track of what the web is actually for. In Ben’s words articles and poems and pictures and movies and music, everywhere! How brilliant is that! Or put in my simple terms the point of the web is universal access to information. Everything else is just window dressing and mostly leads to restrictions. I think just about every blog post I’ve written includes this quote from Tim Berners-Lee. Now doesn’t seem like a good time to break that habit so:

The Web is designed as a universal space. Its universality is its most important facet. I spend many hours giving talks just to emphasize this point. The success of the Web stems from its universality as do most of the architectural constraints.

And that’s more important than any tech spec. The web isn’t politically / ethically neutral and wasn’t designed by people who are / were politically / ethically neutral. Which is why the most important design decision of the web was statelessness and the most important architectural style is REST. Statelessness means everyone has equal access to information regardless of age or gender or ethnic background or physical location or physical ability etc etc etc. Because the web doesn’t care about who you are, only what you asked for.

Which is also why accessibility really matters. Anything that restricts access to information to any one group is bad. Which means accessibility also means mobile views (because that’s the main access point for many people in “less developed” countries) and data views (because for some people the access they want is to the raw data).

And it’s why anything that attempts to impose state on top of the web is, in general, bad. It just adds friction and any friction reduces people’s access to information. So walled gardens, paywalls, anything that requires you to log in, anything that forces you to accept cookies, anything that needs to know something about you before it gives you information.

At the risk of descending properly into freetard territory the other great thing about the web is once you’ve found what you’re looking for nothing is locked down (other than a few clumsy attempts at DRM). More or less anything you find (text, images, a/v files) can be taken away and played with and recontextualised and republished and taken again…

Which sometimes is bad. Like when someone posts a picture of their friend pulling a silly face to flickr. And fails to understand licencing and makes it available for commercial use. And some company takes it, adds a demeaning strapline and posts it on billboards across Australia causing some degree of pain and distress…

But more often it’s a good thing. Because I could search for the TimBL quote above, find it, copy it and paste it in here. And when my daughter does her homework (actually she’s 4 so doesn’t really have any yet) she can go to the web and take a picture and paste it into the story she’s writing. And sometimes she’ll probably steal and sometimes probably give credit but in general what you can find you can borrow and take into your real life and reshape and recontextualise and make new meanings. And that’s good.

And there’s other ways it’s good. The election day Sun front page barely left the presses before pictures of it were winging round the web. And then people took that image, downloaded it (because the web makes that easy – it didn’t have to but it does), modified it and uploaded new versions. Which people commented on and talked about so more people made more versions and talked more about press bias and made jokes. And I think that’s healthy.

There have been occasional attempts to fragment the web. To create an academic space or a commercial space or a copyleft space or a ‘safe’ space. Apple’s shiny iThing app store model is just the latest attempt. Usually the motivations have been honourable. But the effect is always to create a something that’s less free than the open web; to take a public space and turn it into a policed enclosure. Or maybe like a public space in the same way a shopping mall might be thought to be a public space but is owned and controlled and often privately policed. Policing access is dangerous because it removes universality. And policing re-contextualisation is dangerous because it takes away the right to fair usage (my daughter’s homework…). But the people who really do want to steal will always find a way round any form of rights restriction that’s embodied in code and not in community norms. So you punish the “fair users” in an attempt to restrict the real “criminals” who get round the restrictions anyway. And end up building something that just frustrates.

So I really think the web (not the internet which is really just some pipes) is the greatest thing we’ve ever created. More than telly, more than radio, more than newspapers, more than books. Because it’s universal and because it’s open for reuse.

But there are problems. Anything that requires a computer and a phone line (or at least a web capable mobile) can’t quite be universal unless everyone has those things (or lives in a community with shared access to those things.) There’s a lot of talk about digital inclusion, about taxes to fund broadband and about universal access to the web. But it all misses the point. It was never just about having access to other people’s information. It was always about everybody, everywhere having the ability to add their thoughts, the things they know, to the web. Treating digital inclusion as a question of connecting pipes to homes is an easy mistake to make because it follows established patterns of water and gas and electricity and television aerials. But the web was never designed to be a broadcast / distribution mechanism. Digital inclusion doesn’t just mean everyone needs to have a receiver on their roof; it means they need access to a transmitter too. Without the ability to transmit, to publish, people just become passive consumers of other people’s information. And digital inclusion has to include the ability to produce as well as consume.

So physical access is only the first hurdle. Once you’re over that, the barrier to publishing is still too high. Owning your own publishing space means you have to start understanding domain names and DNS and server set ups and code installs and updates. Which for most people is just too difficult. It’s certainly too difficult for me which is why I end up publishing this here (wherever here turns out to be). Luckily “social media” sites arrived to fill the skills gap. But social media is a bit of a misnomer. The web was always supposed to be social and always meant to be open to contributions from everyone. The innovation of social media wasn’t really socialness. From Flickr to WordPress to Blogger to YouTube to Twitter the real innovation was the commoditisation of publishing technology. Now everyone could share what they knew. But at a price.

The most obvious price of commodity publishing is loss of control over your content. In almost all cases the hosting organisation will take a permissive licence on your content:

a worldwide, non-exclusive, royalty-free, transferable licence (with right to sub-licence) to use, reproduce, distribute, prepare derivative works of, display, and perform that User Submission in connection with the provision of the Services and otherwise in connection with the provision of the Website and YouTube’s business, including without limitation for promoting and redistributing part or all of the Website (and derivative works thereof) in any media formats and through any media channels

where for YouTube you can pretty much substitute any website with user submissions from Facebook to the BBC. It means you retain copyright but we we give ourselves so many rights your copyright is virtually useless. Content acquisition on the cheap. It’s a bigger problem than digital literacy because there’s no point educating people about the issues if they still can’t publish and avoid them.

The second major problem is privacy. You’d have had to be living life under stones to not notice that privacy has become the big issue of year. Facebook in particular have gotten regularly flamed for their ever decreasing privacy circle. Now they’re stepping outside the realms of knowing about your social network, your status and your photos and attempting to own the graph of what you like from elsewhere on the web. There are, as ever, arguments on both sides but the only one really worth reading is danah boyd‘s Privacy and Publicity in the Context of Big Data. There’s too much in there to really sum up in a one liner but my attempt would be: privacy issues aren’t about how much information you share; they’re about the gap between your perception of the context of sharing and the reality. Extrapolating from that, once you trust your personal information to “the cloud” you lose control over the context of use. Your data can be meshed with other data in ways you didn’t even begin to anticipate. And the rules around context can be nudged in whatever direction most benefits the cloud service.

It’s like building a giant Tesco loyalty card in the sky. Clive Humby (chairman of Dunnhumby (the people who run the real Tesco clubcard)) once said:

credit-card data tells you how they live generally, the supermarket data tells you their motivations, the media data tells you how to talk to them. If you have those three things, you’re in marketing nirvana

The social media “cloud” seems uncomfortably like Mr Humby’s dream web. And unlike Tesco it doesn’t even pay you for your data. Obviously there are worse fates than being the target of one of Clive’s targeted mail drops. Liberal democracies tend to assume they’ll always be liberal democracies. History seems to suggest otherwise. If the worst were to happen do you really want all that personal data out there outside your control? You might end up with more to worry about than whether your prospective boss sees you drunk on Facebook.

Is Clive’s web the one we really want to build? Or is there a fairer, more distributed solution that allows everyone to share the things they know on their terms? With the power to publish, redact, edit… I’m probably in danger of jumping on Steven Pemberton‘s bandwagon (who’s been saying this for several years now) but until everyone owns and controls their own publishing space we won’t really have built the web. And (with my day job hat on) until “the public” can “broadcast” without fear or favour we won’t really have built public service broadcasting.

I’ll leave with this:

It’s the original logo for the World Wide Web drawn by its co-creator Robert Cailliau. Until Dan Brickley pointed me at it I wasn’t even aware of its existence. The most important point is it doesn’t attempt to qualify the ‘us’; it just means everyone.

In my dream world everybody working with the web in any capacity would have this stapled above their desk. So when all the talk of product planning and sprint planning and deployment and test driven development and check ins and check outs and branded experience and user stories gets too tiring you can look up and remember why we’re doing this.

Well I don’t know about whether such a move by the BBC would have an impact on the market or not (although I agree with Martin, I think it was inevitable that the Trust has would review the plans), but I do think the BBC could tackle the problem in a different, more open way.

There’s a lot of hype and hyperbole around mobile apps – and in some ways you can understand why, lots are downloaded and some folks are making money from them but I’m not so sure it’s going to last. I suspect that mobile apps are successful for a few reasons:

1. They are hooked into a big marketing push. Apple et al. are all publicising their stores on your handset on the telly, on posters and in papers.
2. The app stores are targeted and people know where to look, the Web could be The Store (as it’s been for other things) but that’s not how regular folks appear to see software nor do they want to dig about for what to install.
3. The Web (mostly) only works when you’re online, apps (mostly) work offline too.
4. Some stuff can only be built as a native app (rather than via the web), probably.

But as phones expose more of their API to the browser, as HTML 5 with its support for offline browsing and other goodies becomes adopted and, as libraries and support become available so the technical and user experience barriers start to become less relevant — it may once again be universally seen as sensible to develop web apps. Of course either the fear of being locked in or being locked out of the relationship with their customer might kick companies along a bit too.

So in the near future we should be able to build web apps every bit as good as mobile apps? Yes, but I would go further: for most of the things the BBC wants to do, the technology is already good enough. And with a web focused mind set you can start to invest in the sorts of things you can only do server side — just look at the sorts of things Google are building: word processors, voice communications, email clients, image recognition, maps etc. I think it’s better to embrace the future than play catch-up with the near past.

But what if I’m wrong and mobile apps are the future of content delivery? Well the BBC could still take a different approach – one where it licensed its content in such a way that others could build apps with its content. Of course, unless things changed, the app would need to be non-commercial and the use of the BBC logo and brand would be protected. Of course the non-commercial aspect might be reviewed under certain circumstances — indeed the BBC already licenses content to third parties both outside and inside the UK via its commercial arm BBC Worldwide, why not online? Although I can’t see any circumstance under which the BBC would allow use of its brand and logo since this is central to protecting its reputation, to avoid this sort of thing.

If the BBC did license its content in such as way as to allow others to build stuff then we might see all sorts of interesting innovation on all sorts of different devices and not just mobiles. Perhaps I’m missing something but I don’t see why the BBC needs to control the entire distribution chain, from encoding to eye balls, when distributing content over IP but not when broadcasting to your TV or radio. The BBC doesn’t make its own televisions nor radios instead it lets the market manage that bit, why not encourage the same sort of thing on the web?

For my part I presented the work we’ve been doing on Wildlife Finder – how we’re starting to publish and consume data on the web. Ed Summers has a great write up of what we’re doing I’ve also published my slides here:

I also joined Paul Miller, Jeni Tennison, Ian Davis and Timo Hannay on a panel session discussing Linked Data in the enterprise.

In terms of Wildlife Finder there are a few things that I wanted to highlight:

1. If you’re interested in the RDF and how we’re modelling the data we’ve documented the wildlife ontology here. In addition to the ontology itself we’ve also included some background on why we modelled the information in the way we have.
2. If you want to get you’re hands on the RDF/XML then either add .rdf to the end of most of our URLs (more on this later) or configure your client to request RDF/XML – we’ve implemented content negotiation so you’ll just get the data.
3. But… we’ve not implemented everything just yet. Specifically the adaptations aren’t published as RDF – this is because we’re making a few changes to the structure of this information and I didn’t want to publish the data and then change it. Nor have we published information on the species conservation status that’s simply because we’ve not finish yet (sorry).
4. It’s not all RDF – we are also marking-up our taxa pages with the species microformat which gives more structure to the common and scientific names.

Anyway I hope you find this useful.