 Yeah, I can do that. OK, so we've got 43 slides, 10 minutes, no problem. OK, here we go. This is a very speculative talk. It is not a product we have built. It is just an idea. It's not specifically E-Life. It's an idea that we encountered in the last few months. And I think this community has something which could really contribute to this. So a talk called Threads. We even get the scholarly text, literature, using an annotation-based approach. So I'm going to talk about the ideas. Essentially, could we build a storify for science? I'm going to tell you where the idea comes from, why E-Life is interested in it, what we've done heading in that direction, what problems there are with the idea, and what happens next from our point of view. I'm here to ask you how you think it should be built, what the problems are that I'm missing, and would anybody be interested in doing it? But that's why I'm here, basically. So one of the problems is science sucks at getting better at doing science. Essentially, since the 1660s, we've been stuck with the same method of communicating with each other since this guy, Henry Oldenburg, invented the academic journal on peer review. Scientists have adopted a few improvements. Email, PDF. Now, PDF, I think you could think of as being a very lightweight version of paper. It doesn't weigh very much, but it provides you the same affordances as paper. It's got durability, readability, printability, annotatability. I think that's one of the reasons why scientists haven't moved away from it as much. And if you look at the kinds of tools that we've built to try and replace it, they kind of suck, too. So that is one of the reasons why I think many researchers don't read articles that much online. But I think that we're missing a big trick by not utilizing the web to communicate science as well as we all know in this room that we could. And so threads is an idea which I think has the potential to help a little bit, just a little bit. So where did it come from? There was a research project which landed sometime last year called the ENCODE project. I'm not gonna talk about that at all, but I'll just point out that it was a big project. 3,000 experiments, over 400 authors, and they, in the end, published six high-profile papers and 35 companion papers. So you kind of can, that they were all published at exactly the same moment. You kind of think of these papers as a flotilla of papers wending their way through the peer-review system and then they all landed at the same time. Some of them had to get it re-reviewed and they waited for them and then they caught up and then they landed and it was this big publishing event. And they wanted to do something really innovative around that. And they had these three innovations that they were looking for. They introduced interactive figures, they provided a virtual machine with all the analysis and then they did this thing. It's almost a side thought called threads and it turned out to be really popular with them as researchers and with readers. So what is a thread? Like I said, it's like a store for science. You take articles, there's three articles there with components. You pull out components and then you just publish those components in their own individual, new published object. This is the thread. And they built a very nice web interface with nature. So you see on one side is the left side. Left side, you have the 13 curated threads that were curated by the PIs. And one of the ideas here was to try and bring a relationship between those key papers and the supporting papers and show what that relationship was. So you click on a thread, you go to a web page and you've got on one side the blob and on the other side the provenance of that blob. They thought they didn't need to peer review the thread because all of the components came from peer reviewed articles. But how do they do it? The way they built this is they got the PIs to cut and paste sections from the submitted manuscripts or the peer reviewed manuscripts into a Word document. That Word document was sent to editorial staff at Nature who then checked that the text in the Word document actually matched the text in the papers and then it went into production and then it hit the web page. So the idea is a great idea but the implementation could possibly be improved. I think one of the other interesting and compelling things about the threads idea is often researchers actually build papers from the inside out rather than the outside in. So you often get, particularly in the biomedical literature, you'll get people who start with their three figures and then build out the rest of the paper from those three figures. So if you think about a threads kind of way, it's sort of gross, gross annotation. So at a very broad level. But if you think about it, it matches the way that many researchers actually think about how they interact with components of literature. So it has this sort of immediate affordance of working in the way that people like to work. So why am I interested in this? Well, this guy, Ewan Burney, who's the Associate Director of the EBI in Cambridge gave talk in January to the Eli staff, to the Plas staff. He was involved in those innovations I mentioned earlier. And he basically pointed out that in order to make those threads work, all of those publications have to be made CCBI because of the remixing that happened with that content. And he said, it was his first experience as a scientist where he saw the value of electronic publishing over print publishing, the whole process. And he said, you guys, as publishers, as open access publishers in particular, this is what you should be building. And I liked the idea. And at Eli, we liked the idea. And the reason I'm standing here today is I think this community could build this idea pretty cheaply, pretty quickly. So building a thread gives the overview of the topic to the person who's doing it. It could give credit to the composer of the thread. The readers could benefit from well-constructed threads. They're easier to create than review articles. They explicitly show the upside of open access content. I think one of the gaps of dismissing with CCBI content is we don't have compelling use cases that would make researchers think that they ought to publish their articles as CCBI. If threads became a compelling tool that they were using, that might help with that process. It might be great to not have to do this in word, just a thought. So why is Eli interested in this? Well, we are supported by three of the world's largest research funders. I'm not going to talk about Eli in great detail in this talk. I'll just say we have three areas of concern that they have told us that we should be going and looking at. One is to help early-stage researchers. We've got two young people who went on to become two of the greatest scientists in history here. We want to help people who are at that early stage in their career and help those become some of the greatest researchers in history going forward. We want to promote open access and we want to innovate, which from my point of view means having lots of coffee. So we think that the threads idea is an idea. How much time does that mean I have? Oh, I've got loads of time. So we're looking at a number of product ideas that could help with the innovation aspect of our mission. We are going through a process of looking at threads as a potential product. We are trying to do an analysis of how we could get involved in helping with that idea emerge. We're doing a couple of things on the technology side, which made us think initially, actually this might not be that difficult to build. So I'd like to talk to you, I spent two minutes just talking about some of the stuff that we're doing on the technology side that made us be interested in this. We're currently creating an API into our own content using a system called Fluid Info, which is a key value store. We're creating objects in this database and you can query over rest any of the metadata from our articles. And it returns a nice big long JSON blob. And essentially what you get is this key value set, but you can create any key value pairs with any attributes in that data store. And so we thought actually, a thread could just be a bag of metadata in this data store, which we're already running with, which is quite nice. So you could see how that could potentially be something that might work. You can get information about our API there. We're also looking at a new way of thinking about how the underlying XML of an article has these intrinsic relationships, but they're implicit, they're not explicit. We're trying to figure out how to make those relationships between bits of an article explicit, expressive. So we're converting XML currently from our published articles into a JSON blob. And so this is where I was thinking about threads as potentially being something that could be done through an annotation approach. This is the JSON that we're creating. It has these indices of the pieces of the article. You look at the nodes of the article, and then you look at the annotations which ties some of those nodes together. And so it allows us to create a view. This is very experimental at the moment we think it could work in peer review. I'm just gonna switch to here. So this is kind of a demo of this viewer. If I look at a section of text on one side and I highlight it like so, I can see all the figures that that section is referring to on the right. If I highlight on a particular para here, we see on the left, we see that this is the one reference that's relating to that paragraph, but that reference is also relating to this paragraph up here. And that's by atomizing the XML and looking at the XML's set of relationships between each of those pieces. If we thought of threads as just being more of those nodes, you could possibly think about how you could build it using this kind of system. So back to my talk. There are some problems for people. How do you make the system easy to use? Most still use paper, many still use paper, most still use PDFs. What would be a sufficient volume of content to provide value with this tool? How do you get the researcher to care that you've created this product? How would you find worthwhile threads? There are technical problems to overcome. Going from a DOI to the underlying XML is not trivial. That's how we thought we might approach this. XML is not uniform anyway, sad face. No workflow tool will integrate today, like Mendeley, Zotero. If we turn around to those guys and say, hey, do threads, they'd be like, yeah, we've got all this other stuff that we need to do as well. Where would we store them? We don't know any of the answers to these sorts of questions. Well, we know some of the answers, but we don't know many of the answers. So our next step is we're gonna go back to the EBI, talk to them a little bit about where they see the potential for investing in the idea. And I'm here to ask you guys how you think it should be built, what problems were missing, and would you be interested in helping? And that's my talk. Thank you.