on Webmaking Science

Since the end of October, Mozilla has had an open Directorship position for something called the ‘Webmaking Science Lab’. Other than this posted opening, I can’t seem to find anything written on this project. My assumption is that this is an idea that hasn’t been developed much beyond the recognition that ‘open science’ is an important area lacking critical open web infrastructure.

I’ve been eyeing this open position since the holidays, and I’ve decided to throw my hat into the ring the only way I know how: by starting to hack at it! And if someone else gets the position, hopefully I’ll have helped get them started with their awesome new job!

Apologies to peeps at the Mozilla Foundation if this turns into a case of awkward overstepping.. but it’s all about the love! <3

Where does Knowledge come from?

Mozilla’s Webmaker program is concerned with setting a high standard for web literacy and connected learning. I think Webmaker is an integral program for figuring out solutions to the problems identified in the recent Connected Learning Report because the way in which knowledge is modeled in the human brain mirrors how the web works: like a directed graph. Moving toward an educational paradigm that ‘works like the web’ also has the benefit of ‘working like the brain’. This is both personally humanizing and validating of the global brain theory.

But if open web conventions become the default means by which we encode our civilization’s understandings of how the universe works, how do we integrate the beginnings of understanding into the (social and technical) architecture of the web? How does the scientific process fit into the picture?

This is the question that underscores the idea of a ‘Webmaking Science Lab’ and I’m glad Mozilla’s asking! This is a really important question!

Oh, and it’s made of pure awesome!

Stand back, I'm going to try Science!

Webmaking Science Lab

And so it makes sense for the Mozilla Foundation to create a new ‘Open Lab’ in the tradition of HiveNYC, OpenNews, and OpenArt to investigate this question. And it makes sense to associate this Lab with Webmaker because at its core, science is about the creation of interconnected bodies of literature that encode knowledge and lead to learning. Scientific papers have been linking to each other before the web even existed.

But as our education system is breaking down, so are the research institutions associated with it. And it’s not just the economic models supporting scientific research that are in need innovation, but the way in which science is conducted itself. In fact, I just spent half an hour looking for some links to support these two assertions, and decided doing so would completely derail where I want to go with this blog post! Holy crap, there’s so much! I may come back to break these down further in a future. For now, let’s just say the opportunity space is VAST!

Finding starting points

I have a hypothesis: Figuring out the models that will make open science thrive is a prerequisite for solving the challenges that currently face journalism.

Given that science journalism generally sucks, I think the work OpenNews has done in their Source project would be a great way to build connectivity between the budding world of Open Science and innovative storytellers with global distribution.

Peter Aldhous of New Scientist has a profile in Source and an article published there, ‘How We Made “Your Warming World”,’ which explains the creation of an awesome interactive work of science data journalism!

Great start! Peter: I’m not even sure if I have any authority to make a statement like this, or if it even exists as a real thing yet.. but welcome to the Webmaking Science Lab!

Another hypothesis:  Scientific fields studying the web will be amongst the best collaborators in figuring out how to make open science webby.

The historical trend in science toward specialization is rapidly breaking down as cutting edge science is increasingly happening through interdisciplinary collaboration. At the very center of the cutting edge of interdisciplinary collaborations lies Network Science. From Wikipedia:

Network science is an interdisciplinary academic field which studies complex networks such as telecommunication networks, computer networks, biological networks, cognitive and semantic networks, and social networks. The field draws on theories and methods including graph theory from mathematics, statistical mechanics from physics, data mining and information visualization from computer science, inferential modeling from statistics, and social structure from sociology. The National Research Council defines network science as “the study of network representations of physical, biological, and social phenomena leading to predictive models of these phenomena.””

There is soooooooooo much I could say about how awesome network science is.. but instead, I’ll post two videos featuring field luminary Albert-László Barabási.

Here is a mindblowing  TED Medical video where he talks about the applications of network science for medicine. (This is the sexy video!)

And here’s an hour long lecture entitled “Web Science Meets Network Science.” (I found this one sexy too, but your mileage may vary..)

If my hypothesis is right, this leads dangerously to the meta-ist of meta-projects ever undertaken in the history of humankind. Webmaking science tools built in collaboration with scientists weaving in and out of the growing body of network science could become some of the most powerful tools Mozilla will ever have to, for starters, create analytics for informing future radical developments in the core architecture of the open web. This is an incredibly amazing side benefit that would make the cost of entry completely worth it. But I digress..

When it comes to engaging the scientific community for the Webmaking Science Lab, the two clusters of people I would initially focus on would be those involved in Open Science activism and Network Science.

Third hypothesis: Webby tools for scientific modeling will be just as helpful for conducting original science (plus replication of results) as it will be for making new knowledge accessible to the masses.

This is what makes the connection to Webmaker so amazingly prescient, and relates to why I started out with my hypothesis regarding journalism: interactive simulations of systems are the future of storytelling and the propagation of knowledge. Right now, the application of simulations within science are primarily for the creation of knowledge.. but not so much the transmission of it. Instead, we get pdf documents, textbooks, and poorly written fourth-hand news stories. What if the tools for conducting science were also the same tools for publishing, sharing, and remixing the science?

My third hypothesis will be difficult to find supporting material for because this is the major technical work that has to be done: researching what’s out there and coming up with product ideas for prototyping. But here are a few projects I’ve run across that get my tickle my imagination.

Last week I ran across a Javascript library for chemical informatics and graphical presentation. It’s called ChemDoodle Web Components and is based on the latest HTML5 technologies.

Here’s a demo of this technology rendering 3d molecules within a very old version of Firefox for Android:

This is very cool, and I could definitely see how this could be the starting point for creating webby chemistry content. An academic chemistry paper could be fully interactive using this technology, and these same simulations could be made to be embeddable for journalists who want to strip away all the academic jargon in order to tell a a more compelling story. Then some kid in Webmaker elementary school could remix this same simulation for a class project in such a way that leads the original chemist to find a cure to cancer!

Hey, stranger things have happened on the web! Let’s see.. what else is out there?

There’s an open source toolkit for applied Graph Theory called TinkerPop produced by a company called Aurelius. Graph Theory is one of the major tools used in Network Science, and this group of products includes a tool for interacting with graph data via RESTful web services.

There’s also a javascript statistics library based on R called jStat. A project like this might go well with something like the ROpenSci project to create webby tools for statistical analysis.

Oh! And I can’t forget the Hypothes.is project which seeks to create a distributed platform for web annotation! This project is directly relevant to making the culture around science (via Peer Review) operate more like the web. This is an ambitious project seeking to create a system that could eventually become a core technology built into the browser. Based on what I’ve read, I’m imagining something like Google Docs commenting feature tied to Mozilla Persona. Frankly, this almost feels like a Mozilla project already!

What’s next?

One of my major motivations for writing this was to get people talking! So far, the only indication that the ‘Webmaking Science Lab’ is a real thing is the description accompanying the Directorship position. Call me overeager.. but I’ve been wanting to know more and how I can contribute! I bet there are others as well.

Seeing as the position hasn’t been filled yet, I figured I’d start working on a framework for identifying key problems and opportunities this Lab might seek to explore. I really REALLY like where this is headed.. so I’ll be polishing my resume this week. ;)

On a side note, I’ve chatted a bit with a few people from the Open Science Federation over the past month, and they also seem really excited about the prospect of Mozilla becoming a voice in the Open Science movement. (They also really helped me out when I was looking for subject matter experts for CrisisCamp! They’re awesome!)

Partnership and community building opportunities abound, and I think there’s a large community ready to jump into whatever Mozilla ends up doing within this space.

Markup APIs and the Read/Write Web

In my previous post on how Web Components should inform the Mozilla Webmaker roadmap I make mention of ‘widgets, buttons, and badges.’ The context behind this grouping of things is Kin Lane‘s exploration of ‘Embeddable API Strategy‘ contributing to his work on defining API Building Blocks.

When Twitter first came out with their suite of embeddable widgets, it occurred to me that this was a way in which  web services could be democratized for hacking by the masses. I haven’t seen very many web startups build comprehensive widget offerings on top of their APIs, but the ones I have seen often tweak my personal vision for what the web can be.

I also haven’t seen very much written on the best practices of building an embeddable API strategy, and I think this is because we’re still in the early days of the practice. I also think Web Components finally landing could be the catalyst that changes this. Every consumer facing company with an API will want to make their users data available for mixing into the web. And if they don’t, their users may very well do it for them. Either way, Apps with APIs will be growing veins into the rest of the web more and more.

Last week Mozilla’s Atul Varma wrote up some thoughts in a post titled ‘Building Bridges Between GUIs and Code With Markup APIs‘ which not only upgrades our use of ‘widgets, buttons, and badges’ with the fantastic term ‘Markup API,’ but adds some serious clarity to how Markup APIs can preserve the accessibility of a read/write web as the web continues to Appify. This is some seriously important stuff!

A few weeks ago, I sent an email to Kin Lane and some people at Singly to talk about some of these ideas and how Webmaker could be an opportunity to define an embeddable API strategy for the entire web. I targeted Singly specifically because of how their dedication to personal data ownership is leading the development of their ‘API Fabric’ platform which generalizes an increasing number of APIs into a single sane API for developers to work with. A Singly Markup API would lower the learning threshold for anyone interested in remixing all of their personal information together in new ways.

Check out all the web services accessible via Singly’s API explorer: https://singly.com/explore

Now imagine if personal data from all of these services were available within Webmaker via Markup APIs.

I think Singly would make an excellent partner on Webmaker for this and many other reasons. Kin Lane and I are going to keep developing these ideas to see if this is a real opportunity.

In my previous post on this topic, I suggested that the x-tags registry could be thought of as a prototype for a Thimble Widget Directory. I stand by this idea.. but seeing as things keep evolving, I’m now going to call it a Webmaker Markup API Gallery prototype. We’ll see how long this moniker sticks around.

Speaking of ideas continuing to evolve, the Webmaker team got together this past week for some intensive hacking and yielded some exciting new prototypes which you can check out on Brett Gaylor’s blog! They are all extremely exciting, but the thing that stuck in my head was the ‘Save for Later’ experiment which provides a potential vector for integrating Webmaker with Firefox through the collection of web content intended for remix. Markup APIs should definitely be a collectible content type!

Furthermore, it would be super cool if there was a way for a Markup API to declare an interface for being hacked on within Webmaker. Imagine for instance if the Popcorn Maker timeline UI element was a hidden part of every Popcorn video or webpage with Popcorn content. Webmaker wouldn’t necessarily need to have Popcorn Maker code within the core application because the UI module for editing temporal based web content would come with content.

In this way, the content itself, once collected, extends the UI of Webmaker within the editing interface for ease of editing. Webmaker’s UX could be infinitely extensible this way, and it defines an avenue for getting everyone with an API in on the Webmaker vision for an accessible read/write web!

Aside from integration with ‘Save for Later’ prototypes, there’s another area where Markup APIs can help integrate Webmaker with Firefox: through Apps.

If a user installs an App with an API into their web browser, that user should have automatic access to their personal data through that API. And if an installed App has a Markup API, those widgets should automatically be a part of that users Webmaker experience.

The implication is that with every single App you install in your browser/OS, your ability to learn and make the web should grow.