 Hello, my name is Meredith Soda. I'm the product manager for the Synapse platform and I work with SageBio Networks And I'm going to acknowledge right away that if you are looking at the link in the etherpad I cheated and hid a bunch of slides that have more information in case you're curious But I'm going to try to keep the actual presentation pretty short So SageBio Networks is a research organization non-profit Focused on open science and building up research communities to do reproducible open science and research communities It's mission-driven and focused on the idea that Building collaboration and communication and enabling open science will actually just make science better and We spoke earlier about byproducts of you know different projects and this whole platform is essentially a byproduct Of the work that Sage was trying to do to build these open science communities So I'm okay with that as a product manager, but we're going to be working on ways to make it better going forward So it was originally built up by the scientists. They were they were sort of dictating their needs Sharing across these different institutional boundaries working with sensitive human data These were all challenges that hadn't really been solved in a kind of efficient or easy to implement way When they built the platform about 10 years ago when they started building a platform So we're working in all these different groups Across specific consortia or specific collaborations, but the tools that they were building were appropriate for kind of any kind of group So I want to draw the distinction between the organization Sage and the platform Synapse because they're frequently conflated but the work that Sage has focused on has sort of allowed Synapse to flourish and become this more Generalizable tool for open science and is now accessible and usable for anybody not just people working in these specific communities So there's some links here for later, but it's fully open source It's an API enabled platform and the goals are supporting open Although we'll talk in a little bit about like open being not necessarily all the way public, but open amongst groups and setting it up to be public and it's striving to support Collaborations in the research space not just publication or data archiving. These are active working collaborations full of errors and Though hopefully no retractions, but revisions and edits and things like that We also want to make sure that the work that they're doing is reproducible. So we'll talk a little bit more about that a little bit. I Hate architecture diagrams. So this is a cartoon instead The goal of what I'm trying to show here is that we believe that everything should be really driven by the API So we consume our own dog food in a variety of ways And it's all based on this restful API layer so work on our goal is to Connect people working across primarily institutional boundaries, although sometimes those barriers exist even within the same institutions or even within the same labs So it's any kind of research We want to connect. We have analytic clients written in R and Python that operate off of the same API as our web client to allow more computational folks to Talk to people who would prefer to write in real words So again trying to bring together these communities of researchers and then the piece of the bottom is just to denote federated storage because We sort of learned from the very beginning that we're not going to be the one platform that everybody flops to Necessarily that would be cool, but it may not happen So we don't necessarily want to own your data You should keep it wherever you want to and we will link to it instead And the idea is that you can build up these connections between people between tools between data and Start to form cohesive research projects out of them and they're sort of ever-evolving but always connected via metadata and the API So I saw a couple of the people showing research life cycle slides This is more about how different features it's been apps support team science And how team science is not just this linear path between oh, I have an idea Let me get some data and then I'm gonna figure it out and publish on it It's going to iterate through each of these phases a number of times and some sometimes start Again at the very beginning because we're wrong. That's totally fine We want to connect this process mostly through metadata and version control in a lot of different ways, so There's features to support all of these pieces And some of the varied links in here are examples of those if you want to look at them later I'm gonna quickly get to our roadmap I mentioned earlier that we're built for scientists by scientists one of the major shifts in strategic direction was hiring product manager immediate follow-on point was hiring UX person So a lot of our focus going forward is around enhancing usability of the existing system. It's quite powerful And candidly pieces of it are quite confusing So we'll be focusing on revamping lots of pieces to make it more approachable frankly But still focusing on what the scientists need to do their day-to-day So we'll be adding support for workflows and cloud computing And integrations with those outside systems. We don't intend to roll our own We intend to adopt some common standards and interoperate with those folks This is another case where we kind of built a thing early on and then standards became more available. So we have a DIY system for evaluations and cues sounds a lot like work clothes and processes So we'll be sort of deprecating our old system and adopting the common standards Another folks mentions building up communities. So we have the organizing principle for Synapse is research projects And people can be organized in two teams for group permissions and other sorts of fancy stuff But groups of projects often make more sense than individual projects individually. So we'll be building up Well really operationalizing we've been sort of ad hoc grouping projects under parent projects It's not going to fly for very much longer. So we're trying to figure out how to build those up into proper communities We will be adding and expanding a loss 2.0 support To integrate with different systems primarily to support workflows and distributed data storage Because nobody has any interest in shuffling around terabytes of data just to compute on it Again adding lots of UX support you look at the website. We're actively shipping new UX improvements every week So things are going to change And then I also want to call out Improved support for provenance. So one of the cool things that we have done from the very beginning is support the W3C spec for provenance So that all of the bits and pieces in Synapse can be connected Through those processes, but it's really hard to use. So it exists. You can use it if you want Good luck. And so we're going to be adding Some usability support for that as well as allowing it to become walkable and searchable, which I think will Really enhance the existing provenance relationships that are already there and perhaps convince other people to add them Okay