 Hi, I'm Charles, and I'm presenting some work with Matt Granger and Neil Hadaway on Structuring Data for Systematic Review. Yesterday, we heard from Emily Hennessy, very helpfully, on principle data sharing for evidence synthesis and why we might care about, say, for example, fair protocols where here I've highlighted the term interoperable, meaning that our data can talk to other analyses and it's readily implemented into new evidence synthesis, easier said than done. Of course, we know that there's a big problem with too many systematic reviews. For example, 88 days after who named the disease COVID-19, there were already 88 systematic reviews on COVID-19, one for every day since it was named. Now, Cochrane have provided a solution to this problem with a living evidence synthesis, which is great, where they regularly update and provide network meta-analysis and systematic review on the research as new research is coming in. However, this provides a practical obstacle for the people who practice now evidence synthesis. Meaning that most of us are not computer scientists by training, we're statisticians, ecologists, psychologists, and people in medicine. So whilst it's all well and good to aim for principle data sharing, actually doing it is another thing altogether. So in this talk, we're providing a data engineering perspective on sharing data for systematic review and rendering it interoperable for future and living evidence synthesis. Not only that, but there's a big problem with a lack of standardization of databases. There are people structure their data in completely different ways, which makes engineering it quite a hassle. In our paper associated with this talk, the particular issue that we highlight is that there's a difference between human readable data and machine readable data. So here I've taken some data and I've made it human readable, where you can see everything as a summary and it's output in an HTML format using the cable extra package in R. This makes it very nice on a slide easy to read, but it has condensed variables in one column and it's also summarized. So that makes it hard to extract and use in other analyses where we might be interested in different predictors, different subsets. Because people are not computationally trained until recently, sharing data openly was considered, well, here's my human readable data and I've shared it. So it's now open and whilst that's somewhat open, it doesn't make it readily included in future and living evidence synthesis. A machine readable format of that data is not nearly as human readable. Here, we've taken the same data set, but it's ended up with 14,000 rows when put into a machine readable format where each variable and subset is put into a different column and each row represents one observation for one specific category. This is very easy to use in a data engineering format. And unless you do a great deal of engineering, I don't think that's completely obvious. So this is this talk where sharing the engineers perspective on evidence synthesis, the ways to solve this. I don't think necessarily from tools, they may well be from tool chains where we string together various tools to come up with a machine readable format. What is what came out of this writing this paper, particularly for me, was a real understanding of how nuanced the concept of wide data and long data is. It really depends on what the data is describing as to how long it is or how wide it is. So providing tool chains and showing how we can engineer data to long and wide for specific purposes seems useful. And showing some of the nitty gritty of the fiddly aspects of data engineering also seems quite useful for people who don't have as much engineering experience. But of course, I don't have all the answers. So this is another computational way station where we're providing a forum that is not intended to be definitive, but provides a resource for people practicing systematic review and wanting to find tools in R that they can use to produce formats of data for human readable context, as well as machine readable context. They're both really important, but the ways that we achieve them have very different engineering tool chains, as well as a repository where we can develop new functions if there is a particular practice that's always done and a discussion forum where people can make suggestions. Thank you for listening. And Matt, Neil and I would be very interested in your thoughts about how to engineer data for human readable, as well as machine readable in systematic review. Please do get in touch and thank you for listening.