 Hello, good morning, good evening, good afternoon, and welcome to Neo4j Live today with Sebastian Lobentanzer. Hello, Sebastian. How's it going? Hi there. Good. How are you? Good. I'm good. Thank you for joining. Thank you for taking the time and for being here today. I tried something new, this one here. If I don't move too much, it will stay where it is and don't fall off this very improvised stand-in for my little display here. But I'm hoping it'll stay for a while. It's just a fun little gadget that Michael got me and it was always very far away. But now it's closer. So I'm happy to have you join today. So maybe a little background. So we kind of met via the Health Echo team, which is part of the Graphs for Good initiative. So Neo4j's Graphs for Good opportunity is a way of giving back a little bit. So if you have, you know, a nonprofit organization, nonprofit initiative, and would like to use a graph database, there is the graphs for good page. And then specifically for life sciences or healthcare with COVID, I think there was the COVID graph, which was famous, somewhat famous a couple of years ago. And there is this health and life sciences community that formed around this initiative. And there were lots of people trying to make a knowledge graph or trying to make knowledge accessible around the research for COVID back in the day in early 2020. So almost three years ago to the date. And yeah, Sebastian is part of that community. And Sebastian is from the BioCypher initiative. But before we talk about BioCypher, maybe Sebastian, say a few, oops, wrong button. Maybe Sebastian, we say a few words about who you are, what you do and what we are. Yeah, I'm a postdoc at the moment at the Institute for Computational Biomedicine in Heidelberg University Hospital. I joined there about two years ago now. Before that, I did my PhD in pharmacology. So a bit further away from bioinformatics, but I kind of got into the bioinformatics with my PhD because I worked on the interaction of small RNA molecules with larger RNA molecules. And for that, in the beginning of my PhD, I happened upon Neo4j at the time. It was 2015, I think. We're in version two or three. Yeah, early. That's a good while. Early. And it has grown a lot since then. But it always seemed kind of natural to me to encode biological entities in the property graph as opposed to other systems. I find it more intuitive. That may be subjective, but yeah, I've got a bit of a history with Neo4j. I'm not the hackiest person, so I don't know the ins and outs. I've just been using it in several contexts and that became helpful when we developed this framework that now also has property graph outputs. So maybe as a brief summary. So early on, I think that's great to hear. And then I guess you followed the progress and you followed the steps along the way a little bit from a graph user's perspective, sort of. So that's always interesting. So, you know, adding new features, adding new capabilities, adding new, you know, performance boosts and all that stuff. So I think that's super good. Although I must say that academia generally is a bit sluggish when it comes to the iterations that you do with software. So I think this BioCypher project is much, much more agile than my PhD work was because I stayed on the same version for very long because you don't want to deal with adaptations that you need to know. Of course. Yeah. Yeah. Yeah. And nowadays I think it's the, the iteration has, has increased a little bit. We used to, I think with Neo4j 5 was released late last year, so somewhere around October, November timeframe, 5.0. At the moment, it's April, so let's say half a year later, we are at version 5.7. But the updates are smaller, but the iteration goes quicker. Also, the language models help us write the code, actually. So that's that, and that's, I think, we hope, it's obviously always like you say, I mean, you know, maintaining systems and updating the system is always like something you don't want to do as often as you, as little as possible, really, because you don't want to touch as often as you as as little as possible really because you don't want to touch everything it's as long as it's working and the good old saying never touch a running system i guess is true yeah but still if you want to get ahead with you know having more functionality maybe doing from the scientific point of view doing more fancy analyses or doing something that wasn't possible before then maybe at some point you need to move on. And this is actually quite a point in BioSiphon that we want to make this process easy, but also transparent so that everybody knows which versions of which data, of which technology were used at any given time. So then after your PhD, the topic knowledge graph kind of stuck with you, and then you were like, always like, was it back in your mind, or was it really front-facing? More back as a mind, actually. Yes, now that you mentioned it. So I joined Julio's lab with the objective of doing causal reasoning in the molecular landscape. And that requires some semantics, I guess, but it's also a bit mathematical. And I needed to read into all the developments that these great economists and epidemiologists have done, like like Imbens and Julia Pearl, like like imbens and judy appall noble prize stuff and i didn't really plan to just stick with knowledge graphs forever but it kind of naturally happened that i realized that for for causal reasoning in the molecular space we do need to have a knowledge representation and that's also why this project and the paper that accompanies it is called Democratizing Knowledge Representation, because we want to make this available to basically any person that wants to set it up and then i was constantly maintaining it also and we see this in science as well that the you know the well-off labs that can afford a single person only dealing with their knowledge representation needs they can do that they can afford this but smaller labs or individuals usually have to use what's there for example use the health echograph and then just work with it if it's not completely suited to their purpose, they need to buy it or they need to leave it basically. Yeah. Yeah. It was interesting before we dive in, but maybe a little diversion sort of, we had, there was the Neo4j Graph Summit happening in Munich last week and we had Katharina Kari from IKEA InterSystems. She's kind of like this knowledge graph. I guess you know her and I guess people in the scene, I would say, are very familiar with her work and she's like a very, you know, a knowledge graph influencer almost like or very, very, very much in favor of in of knowledge graphs all kinds not not not necessarily based on neo4j but obviously neo4j is one way of of organizing or creating your knowledge graph and she was also talking about this setting up and creating this knowledge graph is is like a lot of work up front you have to organize everything you have to set your um you know your data points you have to do a semantic analysis almost on your terminology, on your data, on how you address things, how you organize things, how things are related in a big picture kind of way. And then you drill down. And this can take a lot of time. And this is almost something that, like you just said, a couple smaller companies or smaller smaller teams that have don't have the bandwidth they are sometimes very you know down down to business with what they're currently dealing with and then this big task is actually so important but then nobody dares to to do it and then it's like this always it is ever ever you know there's always this mountain in front of you. You have to kind of either you go around or you go over it. Yeah. Usually you use something that's already there and then people have used it. Maybe it's five years old or 10. And that's just the standard in the field. And we could move much faster if not everybody had to reinvent the wheel in this way. That was the basic motivation to come out with a framework in the way that it is. I mean, we could have done it differently, but yeah, I think now is the time to kind of get the community going for this abstract process of building knowledge graphs. And I've read this IKEA knowledge graph blog post, which actually has a lot to do with our reasoning so that, you know, you have a small set of concepts that you want to reason about in whichever setting you are. And this you can manage manually. But then when you get to the data points, which are millions or billions, then you need to trust in your representation that it actually makes sense. Yeah, absolutely, absolutely. Cool. I guess we can switch over. You have a couple of slides and then we can talk some more. As always, this is obviously live and interactive. So if you're watching this right now, then you can use the chat on, on, you know, LinkedIn, sorry, not Discord. Well, you could use it on Discord. We'll look at it later, but Facebook, Twitch, or YouTube, and I can have a, you know, an eye out for it. So Q and A is definitely, can be a part of this. So if you have comments, anything, then, then yeah, please. We can also make technical breaks in the presentation. Like there's different topics. So if you feel that there's questions for a specific topic, we can also discuss them in the middle. Yeah, that sounds good. So don't be shy. Just type it, type, type away. Right. Yeah. All right, Sebastian, I think then the stage is yours. Okay, so let's get started. So in a broad sense, we're dealing with lots of different types of biomedical data and the new methods for measuring these biomedical data come out very rapidly. There's lots and lots of entities and lots and lots of interactions that we can measure now. And most of them are then collected in some arbitrary format and they just end up on some server in a web API or something. And to integrate them, usually people have done this manual knowledge graph creation thing, which has led to a huge number of heterogeneous knowledge graphs that are out there for a specific purpose. They differ by scale. They differ by the specific purpose that they have. they differ by the technology that is beneath them, they differ by the research area. And that alone is a good indication that we do have different representational needs. And a lot of time goes into creating one of these, let alone something that then brings two of them or more together. In the ZEISS lab where I am now, we have this thing called Omnipath, which is now almost 10 years old, done by Dinesh Ture. It started out as a database that, similar to most of the others, was for a specific purpose to drive these causal inference methods that they used at the time. It was in the beginning, protein-protein interaction network. You do see my pointer, right? Yes, I see you. Yeah, yeah, we see your pointer. So it started out as this PPI, then it quickly also added gene regulatory interactions, so not only protein-protein, but also protein-mRNA interactions. And then over the years, we added lots and lots of stuff. For example, enzyme-substrate interactions, complexes, diverse annotations of whatever you can think of. And more recently, also this hot topic of intercellular communication. So how do cells communicate to cause phenotypes, cause diseases? And we see that the complexity of this knowledge representation task very generally increases continuously, so much that even now in the lab which has grown a bit we would require different versions of OmniPath to really fuel the specific needs of one particular researcher and so there is this no one size fits all problematic that we wanted to use an abstract framework to generalize this build process to allow more flexibility in creating because this now also is a huge collection of over the years accumulated scripts it's a Python program that just do this for this very specific purpose and to change it to something else would require knowing it's in the ins and outs and then also actually doing a lot of work to get it going. And then we also coincidentally wanted to migrate the back end of Omnipath to include even more regulatory and microbiotic and other influences, which gives you combinatorial explosions if you connect proteins to all the organisms that express them and so on. And the best candidate at the time was Neo4j also. And probably it had something to do with me already knowing a bit about Neo4j. So we had this general task of migrating OmniPath to a database backend, and then we had the idea to just take this migration as an incentive to just develop a framework that would do the migration, and then it can be reused for other migrations as well. And what we ended up with is this thing we call BioCypher. It's also a Python framework, and it has what I call a threefold modularity, which is in the first place the resources, of course. So you get the data from somewhere, you get information about proteins, about tissues, about drugs, whatever you want to reason about, and you get it from a web API as a flat file as something. And so we have what we call adapters that are just ETL piping the data into the Biosurfer framework. The second component is ontologies. So as I said, I think semantics are really important for dealing with inferencing in any space, but also in the molecular one, of course. So we have the second module where we can use different ontologies, which are expertly curated, and we can just reuse this information. We bring them together using a configuration. So we map the data contents to the ontology contents. And the third modular component is the output side where we can have a label property graph, but we could also, for example, in some other projects, we like to use SQL or we're working on RDF to be more in the semantic space. And together, this is basically the pipeline that people would use to go from the raw data to something that's integrated and you can work with. And a fairly large component of this project is actually just the meta level organization and making the data available to people. What is there? What can I reuse? And maybe some examples for people that are new to the field. What do I even need to look out for when I think about my knowledge representation, whatever that means. And so we collect all the components in a project board on GitHub. This is this new project thing that was in beta for a while and now actually is, I think, mature enough to deal with. At least for the last couple of weeks it worked fairly well. And we collect these parts, I'd say input, which is where the data comes in, and the output, which is basically the adapter to the databases Neo4j or Arango or something. And then we have the ontology component, which we also list here what we can use. And then there's the pipelines, which are the meta-level programs that bring together the inputs and ontologies to form the outputs. And there we do the project planning and also contributor management. So we have this organization called BioCypher on GitHub and anybody who is interested and wants to do a pipeline, for example, can join that. And what I also did is build a BioCypher pipeline that takes this information and then builds a Neo4j graph that is available at meta.biocypher.org where people can more intuitively browse what is already out there. So which pipelines are there in genetics, for example, or in proteomics and which adapters do they use and in this way get access to reusable components that could be useful for them. And in this way, get access to reusable components that could be useful for them. So maybe briefly a couple of words about what this adapter thing is. So basically, it's just an ETL pipeline in itself, a small one, extract, transform, load. But they're supposed to be reusable and combinable by the framework. reusable and combinable by the framework. And so we have, for example, the universal protein resource, short Uniprot adapter, which then presents to the pipeline a number of fields. We have the different species that are available in Uniprot. We have the node field. So there is a length and the mass and sequence of the protein, for example. And we also have some edges in this adapter. There is the protein which organism does it belong to and also which gene encodes for this protein. And this is what it presents to the framework. And in this way, and this is a bit work in progress now, but in this way we want to have some more user-friendly integration functionality where we have multiple adapters and then, for example, the pipeline can tell some more user-friendly integration functionality where we have multiple adapters. And then for example, the pipeline can tell the user which are the best identifier systems to use to have the least trouble in mapping the entities of the individual adapters to one another and other fancy things. And if a box is checked here, does it mean you can check it as you like? Or is this what's currently in there? This is supposed to symbolize that the adapter is actually a Python module, I would say, which presents all this information to the framework, so to the user. And the user is able to say give me proteins but i only want human and i only want the length and the sequence remove the rest and then you don't need to deal with anything that you don't need so that's that's what these check boxes are supposed to visualize yeah yeah okay that's cool so you can customize basically depending on your specific requirements. And these adapters are basically community-driven. So, of course, we do the adapters for Omnipath, let's say. And I also have this thing which I call secondary adapter, which is not like a granular atomic resource, which is a unique data source as, for example, Uniprot. unique data source as, for example, Uniprot, but we also in the past have done adapters for entire pre-harmonized databases. So say Omnipath consists of over 140 resources now, but it has a lot of this harmonization stuff already going on inside it. So it's much easier to write one secondary adapter, which also details we have proteins and we have interactions between also details we have proteins and we have interactions between proteins and we have genes and we have this and that and this is presented by the adapter and then the user can just say yes i want the proteins and the interactions and leave out the rest yeah okay right a bit about ontologies, maybe. So it's a very active and very special field, the field of ontology. I call it facetiously the necessary evil here because most people that are not in the ontology field don't like to talk about ontologies or find it boring. But I think particularly in our time now where we want to transfer reasoning to great extent to machine learning processes, we need the semantics. And I like to compare how human researchers talk to one another versus how we talk to machines or even how machines talk to one another. So a human goes through some early period of development where they just have a, they gather a notion of the world. They gather a notion of causality. They do their own experiments in the macroscopic space, so to speak. What happens if I push this cup over the edge of the table? Simple things, right? Babies like to throw stuff on the ground. And then also we go through years of training as, for example, biomedical researchers, and we acquire a huge vocabulary of how do we talk to one another about an experiment, about a disease, what even is a disease? These are all concepts that we communicate, but machines don't have that. And that's what we see in their reasoning abilities. I mean, it gets better the more data points and the more parameters we shove into these large language models, the better they get at mimicking human behavior. But a notion of objectness and particularly the efficiency with which humans do this is so far not achieved by machines. And to kind of facilitate this, we want to fuel the knowledge graph with the semantic concepts that the ontology brings. And since we want to make it easy, we also have some usability functions in BioCypher. So we have the data coming in here and say we want to use not one ontology, but two, because we want to have a very general one. And then we want to have a specific one. I give here the example of a molecular tumor board, where we say we want a very general notion of biomedical things so biolink is a shallow top-level ontology that has things like genes diseases experiments things like that but it ends for example when you want to talk about genetic variants it ends at the sequence variant so the tree stops there but there there is, of course, there are multiple ontologies that are expert curated that tell you lots about what kinds of sequence variants there are. The most popular one is probably the sequence ontology. And with BioCypher, we can simply go and say, I want to use BioLink as my main one. But then at the sequence variant node, we attach also the sequence variant subtree of the sequence ontology. And so you get a hybrid ontology that has knowledge of the general things, but also of the very specific things that are in the sequence ontology, which is nice because then you don't need to maintain one humongous ontology, which contains basically everything, which has also been done. And it's kind of, you know, it has 500 million triples. So it's nothing to scoff at. Yeah. We want to make it as modular as we deal with the data to deal with the ontology. And then we have, as already stated, we have a couple of outputs that we then can put the data on top of the concepts that are encoded by the ontology and then deliver the ready-made knowledge graph, so to speak. And maybe this is a good point to remark that, as opposed to some of the RDF web semantic approaches, web semantic approaches. The general philosophy of BioCypher is more of an instance-based knowledge graph. So the concepts usually are not in the graph, but the concepts are used to encode what is in the graph. And with Neo4j that's actually kind of nice, because we can use multiple labels on each node to encode for the hierarchy of the ontology, say protein is a polypeptide is a biological entity. And if you want to look for all polypeptides, you can just filter your query for this label. But if you want to have a specific one, say proteins, or even more specific, like I only want ligands, then you can go to the more specific labels. So if that's good for your use case, we enable that. Yeah. Question on the ontology linking, is that done automatically or is that lots of manual, probably a combination of both, I guess. Manual. You mean by the user or by ourselves? By you, yeah. How do you, I guess. You mean by the user or by ourselves? By you. Yeah. How do you, I mean, if you say, let's see an example of BioLink and sequence ontology, is there an easy cutoff point where you say, okay, and then it goes on? Or is it? Yeah. So basically we ingest ontologies by using the OWL files. So the web ontology Language files in RDF. What we do to make this choice, basically, is we have two lines in the configuration YAML file at the moment. We want to make it accessible in a GUI down the line, but at the moment we are working with YAML. There you can specify my main ontology, then you give a URL and also the root node where it's supposed to start, which for BioLINK we just recommend using entity, which is the just top level node. And then you have also, you can have an arbitrary number of tail ontologies. So the ontologies that are supposed to be fused to the main ontology. And there you can just specify also where it lives. So the alpha locally or on the web, and then you specify the nodes that should be linked. And in this case, it's quite easy. You just say in biolink, you take sequence variant and sequence ontology, you sequence underscore variant, and then the framework does it for you. Okay, yeah, yeah. We had a session with Jesus a couple of weeks ago, underscore variant, and then the framework does it for you. Okay. Yeah. Yeah. We had a session with Jesus a couple of weeks ago, I think. Maybe it was in the last episode where we talked about, you know, mapping, combining two different ontologies into one single ontology, and then you find the links between these systems. And sometimes there is a match and sometimes there isn't. So you have to juggle around a little bit sometimes. I guess it's easier and sometimes it's a little bit okay. There is no direct representation or no direct equivalent of the two in the two different ontologies, but there is something in between and then it's a bit more tweaking. There could be massive problems in this. I mean, there are things that are pretty obvious. BioLink ends at sequence variant, and you are interested in oncology, you're interested, is this a SNP, is it a lethal variant, whatever the sequence ontology encodes. So you just tuck them onto one another. And with diseases and disease ontology, for example, it's exactly the same. But of course, if you want to merge, completely merge two ontologies that are on similar levels, like the disease ontologies, for example, there's several, maybe a dozen, and harmonizing them is a huge deal. And we actually want to enable this. So this is also still roadmap stuff, but by having this kind of back end here that can deal with fusing and maybe reasoning over ontologies. You could also imagine use cases where you have several disease ontologies which you specify in this configuration YAML and then instead of trying to tack them together at one specific point you can reason about which of the individual nodes may be matches. I mean, many ontologies already do this. They provide narrow matches or exact matches, right? So you can use this. But for example, this instance of having a triple which is not complete. So you have three ontologies and in two of them, no, between one and the other and between one and the third one, you have the, this is the same, but the third link is missing. And so this could be done. It's not implemented yet, but this could easily be done at this stage where you just have these three ontologies and then BioCypher does some computations and just spits out a harmonized ontology. So this is on the roadmap and it's actually an important topic in biomedical knowledge graphs. Absolutely. I think that kind of answers George's question. He says, do the vocabularies vary between the different bioontologies? Are there some constant definitions? I guess, yeah, that's what we just talked about well both yes so for example the obo foundry which we we like to use so the sequence ontology for example is from the obo foundry as well and they they often give cross references and then there are like master overarching ontologies like the EBI has done with their experimental factor ontology where they just for their in-house use cases curate other ontologies and say this is this concept so we're going to map it to ours. It's very difficult and I'd say also very debated field because there are opinions, these are all concepts so they're not real things that you can touch in a sense, it's just that someone says I think this is a disease and then another person says but maybe it's not a disease and you have different opinions. And so to harmonize this, I think, will be an eternal battle. Just out of philosophical reasons, not technically necessarily. But the thing that we want to provide with BioCypher is just some head space to make these technical tasks easy so that the people can sit down in the beginning of a project and really think about what kind of semantics do they need for their task. And that's the second component then is being able to build different layouts of a graph fairly easily. So not taking months, but rather taking a couple of days to just be able to test which representation actually is the right one for me. Or maybe I should use MONDO, maybe I should use disease ontology, or maybe let's go with experimental factor ontology. And the goal is that you just need to switch out this configuration line saying, I want to use this ontology now and then see what happens. Yeah, yeah. And that's great, I want to use this ontology now and then see what happens. Yeah, yeah. And that's great, I think. And that is, it is obviously some configuration a little challenge at some point, but it is also easier than you think it might be in some ways, because like you just said, with the closing of the triangles in graphs, it is, if two things point at the same way, it's very likely that the third one is also talking about the same. So you can fill in the gaps with this to some extent also almost automatically by using the graph technology. Yeah, but there may be questions that you can't really answer by using just the technology, but that needs to be decided by a domain expert. Like, is this a disease or not? Or is this a different disease than that one? And, you know, the medical professionals also don't sit still, right? They put out different versions of the DSM and the ICD. Are we at 11 now? I don't know. So these things also change. So it's important to have a modular framework where you can say, oh, they updated their definitions. Let's see what the new one looks like without having to deal with months of hacking away at some data file. Yeah. You mentioned, Nirmal asks, you mentioned this 500 million triple huge ontology. He wants to know, are they distinct or total graph weight? Do you know? This is the Uber graph. It's actually also a hybrid. It's basically, they did a paper which just took all of the Oboe Foundry ontologies that they were able to fit into this bigger framework. And then they fused them together. And then they also did some, I think, imputations for convenience or to be able to go to certain links quicker. So they added some triples that were inferred from the triples that were in there. And that's how they ended up with this enormous graph. Yeah. Yeah. Cool. Yeah. And then one more question from Ishwar is the different sections of the ontology. So A, B, C, D is just an example, right? So this just. Yeah. Yeah. This is just a graphical thing to show that you can have several ones and you can select the one that you, that you want. Okay. Cool. There was one more question on adapters. I don't know. Do we come back to adapters or should we do it now? We can do it now. We can also do it. I think we will have it very soon after the licensing. No, let's do it now. Let's do it now. Okay. Wenlang asks, do you have adapters developed for data in KEGG database? Yeah, there is one, I think, in the crossbar pipeline. But what I recommend in any of these questions is to go to the BioCypher website, which links to this adapter GitHub page where you can filter. You can also go to the meta.biocypher.org graph and look in the Neo4j instance that we have there, whether something that you're interested in is there already. Sometimes it may not be there yet because people are still working on it and we haven't had time to put it into this graph. There is also on the website this link to the Zulip chat where you can just informally go and say, hey, did anybody do something with Keg? And then you will quickly find out. Yeah. The links to the GitHub and to the Bioserver website are in the video description. So if you are wondering where to click, then you'll find them there. So should we go on? Yeah, let's go on. Let's go on. So one other distinct topic, but also very important, is licensing. So with BioCypher, we want to push a bit on the way that it is done at the moment, which is basically, we have this thing here, maybe it's a hybrid knowledge graph of 10 different sources, and all we do is we have a table somewhere that says, this source has this license, this source has this license. And then the user needs to figure out which entities come from which source, can I actually use them? And that's particularly problematic for corporations. So if you want to work with startups or even bigger companies in pharma, say, you always have these questions. And then you need to go through a whole lot of lawyers to figure this out. you always have these questions and then you need to go through a whole lot of lawyers to figure this out. And so the advantage in BioCypher, at least what we think the advantage is that we can have, and we also advise to have that licensing on each entity. So on each node and each relationship in the graph. And we can even turn on a strict mode, which doesn't allow adding entities to the knowledge graph that do not have information about their source, their version, and their license. And then we can also imagine in some use cases where you could just use some master switch which says, I can allow data from these licenses, but I can't, for example, use KEGG or Drug Bank, which are notorious examples for limiting the reuse of their data downstream. So this is just a convenience feature in this sense, but I think it's important to make this also as easy as possible so that people actually use it. And there's a lot of ignorance going on there, just people using things where they don't even know whether they can use them or people creating a great resource but then not attaching any license to it, which gives huge problems downstream. Because if you don't have a license, you're not really allowed or you're not sure whether you can use the stuff or not. Or what you can do with it. And I can see that if you are building up your, your knowledge graph, you, you, you obviously can rely or will rely on some resources from ontologies or from other, from other databases that have been created, but you will also, but a hundred percent will also use your own data to, to incorporate that in your, in your knowledge graph. And some of this data is is i'm pretty sure is ready for for a public uh release and you are fine with that but majority will probably be this is my own intellectual property my own data my own research i'm not going to share this because i don't want my competitors to have an advantage yeah it depends on your opinion actually in this in this regard. So also whether you're in academia or in industry, say, and also whether it's software or actually really data points. Most problematic, of course, are patient samples. Exactly. Like PDR problems, right? But that's another topic which we also address in some way in this federated learning type setup where you should be able to share the structure of your data but not the actual data itself which is kind of a way around of between a middle ground between sharing the data and then actually not having any interaction you can train in a federated manner without actually having access any interaction. You can train in a federated manner without actually having access to the data. That's cool. Yeah. I think that's an important step and an important way of making, you know, giving some confidence of users to work with that. So like you said, right, if you don't know what the license model is and, well, can I use this data later on or will I have to chuck it out again? And then you build something and then you realize, oh, this is not licensed and I have to, you know, I cannot use it. And it's very frustrating. Yeah, definitely. And, you know, sometimes people just have done things and where there's no jury, there's no crime or something like that saying exactly goes but um yeah this just in academia it happens and often it doesn't have any ramifications but if you look at at biotech companies they can't really risk doing something like that so that stops some projects in their tracks which is a shame because then they need to again go back and have entire teams internally working on something that the world will never hear of because yeah they don't share it yeah yeah i mean that then they are with this i think it's it's also nice because it gives you the option to give to give something back as a as a biotech company you can always say okay here we developed this in-house and we used the open source and the open databases and the open connectors here. And we add our own data and some of it is like, it's a clinical data or individual IP research is ours, but then we enrich the data and we give something back and we release that for public consumption. And then that makes, you know. Yeah, that would be great. And yeah, the EBI, for example, with the Open Targets platform, they regularly do try to bring academia and the companies closer together to have this sort of win-win relationship. But obviously you need to sail around all these IP and privacy considerations. Absolutely. It's not easy. No, no. But at least it's there. Exactly. That's what I was going to say. I mean, this makes it easy and this makes it possible to have the option to do it at least. It will depend on the individual case. But if it's there already, then sharing is possible and that's great. Yeah. So very briefly about the usage, I'd say, since it's a Python program, at the moment we are working already on an R implementation, at least of the downstream side. And also we want to do clients, obviously, for example, OmniPath. It will probably take a bit of time, but I think as it's looking now, at least the R implementation will be fairly quick with using Reticulate, which is this thing that can translate between Python and R. And then we're also looking at Galaxy, but that's just plans at the moment. So the way you would go about it in Python is you get the BioCypher interface, which is this core framework, the way that you interact with it. And then you need to get the adapters, however many you want. And you do this in kind of a script setup, which you can also then load into a Docker pipeline or something. and also then load into a Docker pipeline or something. And in this case, we have again the UniprotAdapter where we just import this adapter class, which presents all this information. Say I've got human and mouse and the zebra fish, and I've got all these fields and a couple of edges that you can use. And you do this by just saying, with the BioCypher interface, we write the nodes that we get from the adapter and we write the edges we get from the adapter. We can also write just anything. And this is how you would create a knowledge graph very superficially. The way you put it together with the ontologies is that you, of course, in the beginning, you decided on which ontologies to use. So you know which classes are in your ontology. And then if the adapter gives you something that is called protein, you want to map this to the protein class in the ontology. And that's basically all it is. It can become a bit more involved if you, for example, have a relationship that you want to represent as a node. more involved. If you, for example, have a relationship that you want to represent as a node, then BioCypher will reify this interaction for you and it will create not just one edge, but it will create an edge to a node, which is the association, and then another edge to the target of the association. And some other stuff, like you can define properties here in this configuration. And this is also something that we ultimately then want to move to something like a web app where you can have a drag-and-drop interface, the adapters tell you what kinds of information they have, and then you say I'll take the protein, I'll take the gene, and I'll take the interactions between proteins and then build me the graph. And then the framework goes to write, And then the framework goes to either write some output files or it connects to a running DBMS, for example, Neo4j through the old drivers, say. And depending on, for example, the extent of the knowledge graph that you want to write, you go with the one or the other. So if you want to create millions of nodes and edges, you would probably prefer the batch import thing. Whereas if you just have a running graph and you update a couple of nodes and edges every now and then, you probably want to more go with a driver-based approach where you don't need to stop the database. And this is, yeah, to some extent, everything of this is possible. Okay, cool. And then you can also go and at the moment, just manually optimize this knowledge representation so you can easily switch these configuration statements saying, now I want to represent this relationship, not as an edge, but as a node, because I want to connect something, see how this works. So you can iterate through this process and see how it works. Or you can maybe create an SQL and a property graph database and compare how fast they are in a particular task and find the one that suits you best. And then there are some couple of other nice small details like often the extracted knowledge graph that you get is fairly small so you can just take the bioscipher files and zip them and put them in a repository or something and then you automatically have reproducibility for example if you use this knowledge graph to to write a paper you can put it next to the paper on github or on zenodo or something. And then people will be able to access this and using just the import statement that is included in these files, they can just create this knowledge graph instance locally if they want to check it out or do something else with it. Yeah. So here we come back to the adapters, maybe a little example. For example, Uniprot, the adapter that I mentioned a couple of times already, they don't provide gene identifiers, this Ensembl gene ID, but they do provide transcript identifiers. But we want to connect to gene-centric resources, for example, the Open Targets platform, and so we use some mapping functionality to just use the ensemble transcript ID to get the gene IDs, and then the adapter also can provide the gene IDs. And this way, the adapters are a very flexible way of also modulating or adding to the data, enriching the data that comes from this resource. So in this case, we use PyPath, which is this backend for OmniPath, our database, which can map transcripts to genes and then we can connect, for example, to the Open Targets, which is a very gene-centric resource that doesn't have proteins. We can just add the proteins from Uniprot to the Open Targets platform data and then we also have proteins and can maybe reason about drug interactions with proteins or protein-protein interactions. We have lots of behind-the-scenes things to make the knowledge graph creation process also more robust in addition to making it faster. So all of the functions are unit tested, so you get some, if Bioscipher notices something is off, you get feedback about this particular thing. So for example, if some nodes in your ontology are disconnected, it tells you, if you have inputs in your data that you didn't map to the ontology, it tells you like, Hey, I got 700 nodes that are called disease, which are not in your configuration. Is this by accident or did you mean to do this? And it can also deal with duplicates, for example, which is kind of tricky, to be honest, because the identity or the uniqueness of the thing also depends on other attributes. So in a labeled property graph, for example, you can have multiple edges between two nodes and they may encode for useful information. So it may be valuable to have them both. But if you only look at the source and target node, then you would think that this is a duplicate. So you need to attach also the label of the edge, for example, if that is different, or even if the label is the same, maybe it has different properties. So the granularity with which you deduplicate also is not really trivial, and we try to make this easier with the adapters. And then there's some just user-friendly stuff, like you can look at the ontology. By default, BioCypher only shows you the classes that you actually use out of the ontology, by default, BioCypher only shows you the classes that you actually use out of the ontology. This is just from the tutorial toy example. This is a database where we actually use the sequence ontology. So we added this subtree of sequence variant to the BioLink ontology, which just encodes for the top level stuff. And then if you look at the entire ontology, you get lots of output, but we enable that. So if you want to quickly look at something, you can just have BioCypher show you the structure and then maybe you can figure out where to map a particular thing that's in the input, for example. Okay, that's cool. We also want to add some also community curated things like the bioregistry for passing identifiers. Say you have some identifiers where you don't know whether they already have a prefix like uniprot, colon, and then the identifier or not. And bioregistry as well as Gilda are two community open source tools developed by Ben Gyori and Charlie Hoyt at Harvard Medical School and Gilder can be used for grounding. So if you have an entity which you don't really know what it is but you have the name and you maybe have a sentence where it appears then it can tell you ah this is likely a gene or this is probably a protein or something like that. So with the adapters, we also want to enable interactivity in using other tools that are made for specific purposes in biomed. Yeah. Well, that's cool. I guess it could be interesting for when you, I mean, the ontologies are somewhat curated, I'd say. But if you bring in your own data, then you can kind of like use these tools to say, okay, where do they match? Where do they connect best? And then how do I, you know, then obviously then it becomes interesting, right? Finding the new relationships between what you have in your data in the combination with the added power of the knowledge graph. Exactly. And then what we want to do in terms of the roadmap or development, we like to try these things out in the adapters, which are very malleable. And then if it turns out that one functionality is particularly useful for basically any adapter, we want to migrate this into the BioCypher core so that just everybody who imports BioCypher has access to these functionalities. That's how it's planned to go about. Very cool. So we are already at the Outlook. We have some Docker solutions so that people can more easily set up their workflows. Maybe I'll show something like this in the last couple of minutes. I don't know if we have a hard deadline here. We don't have it. No, no, we can. Yeah, let's do that. So we want to extend to having some examples of representative workflows in different fields because the knowledge representation needs differ between proteomics or single cell researchers. Maybe you're interested in spatial omics or in genetics. And there is also, as I already mentioned, a huge interest in reasoning on the ontologies that are coming in here at this point before we build the knowledge graph. So to build the knowledge graph on a combination of ontologies or to complete these triples, for example, before you build the knowledge graph on a combination of ontologies or to complete these triples, for example, before you build the knowledge graph and then you have a reproducible but flexible pipeline in the sense that you can, if you have another ontology that you want to add or there's a new version of an ontology, you can run it again and you get again the best possible hybrid ontology for each case. Then, since we are shuffling data around all the time, we also want to work on the data management. So we already have reports from one of the teams at Stanford that deal with this impact of genomic variation on function project with BioCypher. They use PyPI to just simply run the same pipeline, but through PyPy, which is just in time compiled, and it made things apparently a lot faster without any development efforts. So you can just switch the regular Python implementation for PyPy, and apparently it worked in their case. And then there's also more involved possibilities like going to a format that is just pointer-based so that you don't really need to copy things, but you just have pointers to file on the disk. And then you just shuffle that around instead of the actual data, which it is at the moment. So for huge knowledge graphs, this can actually take a couple of hours, which is not the end of the world, but it can always be better. Which is not the end of the world, but it can always be better. And then also we want to, as I mentioned, deal with the interface. So I like to bring this example from audio engineering because I am an audio engineer. I did this before I studied pharmacy. And the thing with these machines that you have in audio engineering, like synthesizers or some compressor or something, is that these knobs that they have are very intuitive. If you work with it for a couple of hours, it becomes second nature to find something up or down. And we don't have the same thing in biomed engineering or in software engineering in many places. So we need to add these knobs and dials, look at the users, what they do and how to make it more accessible to them. So there is this open question about how to do this. Do we do a web app where we have like, we can have some graphical components where you drag and drop something and then it writes this configuration YAML for you. Let's say I drop a gene here and protein and draw an edge between and then you know you still need to get the data so if you have already a pre-made adapter do we have like an app store of adapters that you can then load and say i want to combine drugs and proteins and genes and maybe add some of your own data so this is something that we are very interested in and which we didn't have much time to develop yet. This is a community project. We're also very open for people having ideas in this space. Or if someone is a web developer and says, I can write a GUI for this thing in two hours, then you can also try that. I played around with Streamlit last week a bit for some other thing where we attach the knowledge graph to large language models. And then we have like a chat GPT app like to communicate about biomedical findings. And yeah, I would like to go more in this direction. But since I can't. How did that go in general? Very good, Very good. Very good. So with my basic Python knowledge, I've managed to get it working in like a week, which is much faster than I expected. But yeah, there's always like more powerful frameworks and, you know, people with lots of experience that can do a much better job of making these intuitive interfaces. Exactly. lots of experience that can do a much better job of making these intuitive interfaces. Exactly. How the user interacts with such an interface and then making it actually usable. Yeah. Yeah. Especially when you're talking to the experts of the field, they don't want to talk about anybody in particular, but I can imagine that they are not really developers or don't want to write terminal queries. But the backgrounds are super distinct. So maybe someone comes from computer science, maybe someone comes from biology. These two types of people have so different education in terms of how they interact with the basic things, right? And they don't know what does it mean if there is a knob here or a slider there or what to do with this. That's great. I think that's super good. So if you're watching this and think, hey, I want to write a web app for this, get in touch with Sebastian and the team so it can happen. That would be, I think that would be great to see. That's our main aim. Basically make everything open and try to engage as much of the community as possible, which works fine with the adapters so far. So writing adapters is not hard, but there are lots of adapters to be written potentially, and this just takes a bit of time. So the more people you have, the more you get things going. Did you try stuff like, for example, in Neo4j, you can visualize some, I mean, this is obviously after the fact that you created your knowledge graph, but with Bloom, for example, being a visualization tool or other technologies, you can, at least the representation of the graph can be a little bit more, let's say, easier to understand or... Yeah, I like this. This is a good example of downstream usability. So, for example, this Metagraph is a very basic example of how you can make this table-based GitHub layout more intuitive for people, or you have a graph where you kind of naturally, you get the pipelines which are in one area say genetics and then other pipelines that are more in proteomics or in um clinical stuff you you can more easily browse this and later on with with bloom as well just for figuring out how it works and in what ways it can be useful. But as you say, it's more a downstream thing. Totally. Yeah. Yeah. And also the graph data science thing is probably very interesting. Yeah. Also could be an incentive to go for a Neo4j graph as opposed to, for example, even a Rango, which is also graph based, but which doesn't have the same, I'd say intuitive things where you can just do some clustering, if that's what you're interested in. But for example, the IGBF people, which needed very specific genetic functionalities, like looking at the genomic region and then quickly returning which genes or which exons are in this region, they did some benchmarks and they went with a wrango because there you can have ranges, which wasn't the case in, let's say, SQL or another label property graph engine. Yeah. But that's very subjective. And that's why we think this more general framework is the way to go. Yeah. That makes sense. Yeah. This is basically it from me. You have the link. I need to thank all the people that worked with me on this. I should have updated this lab photo because this is just, we have several lab photos flying around with always half people missing. Actually, we're now like 35 people. Cool. And it's a nice lab. We are constantly looking for people. So if you do want to do a PhD or something like that, you can also get in contact. And with this, we can maybe, if you want to go to this more technical thing. We can. There were two questions I'd like to maybe talk about before we do the short hands-on part. From Wenliang again, where does the protein-to-protein interaction information come from? Can it be from different resources of your own data in your Uniprot example? Yes. So Uniprot doesn't have protein-protein interaction. It just is a very comprehensive resource on the proteins themselves. And for example, Omnipath, which we have a secondary adapter, as we call it, but since it is an enormous resource that has been growing for almost 10 years now, it obviously is tricky to migrate this all at once. So the secondary adapter is a nice option to have this already. And in terms of the protein-protein interactions, I think OmniPath even integrates like at least 30 of these. And yeah, there are individual atomic resources, say like string, which many people use, but if you want to combine it with something else, and often it comes from papers or something, so there's just some supplementary information in the paper which you'd like to use. And then in OmniPath or in PyPath, we create a function where we have this file and we add it to OmniPath in this very specific way. And in the same way, we imagine that you can just combine adapters for the different individual protein-protein interaction resources to build a knowledge graph. Cool. And then the other question was from Diego, and I guess that's a little bit what we talked about before about how to get in touch. But you mentioned the issue of support in academia in smaller in smaller groups what is envisioned in terms of keeping bios have a current and relevant just an active user community or additional institutional support well we do support bios cipher definitely but yeah we are only a handful of people and for this, we also want to build a community. So this project is not going to end up unsupported in a very brief time frame by us, as we can, for example, see with Omnipath, which is now supported by the same lab for almost 10 years. We do have a good track record, so to speak. And I'm the one that organizes all this but we have connections if you read for example the paper there's lots of people on that mainly from academia but we're also working as i said with for example open targets which brings some pharmaceutical companies in the mix and basically our opinion is that we do everything in the open. I also like that about Neo4j, that you have this, if you're open, we're open and graphs for what was it again? Yeah. I like these types of initiatives and this is exactly the way that we want to go. So everything is in the open. And if you want, if you think this could be useful either if you're a potential user or you want to develop something i would just recommend to get in contact and you will very quickly see how it works so this zulip thing just requires some signing up and then you can immediately jump into the interaction okay cool no cool. No, yeah, and everything is on this very website here, the Bioscipher team page. All right, officially we are at the end of the session, but I think we should try to get the demo in here. So obviously. Yeah, it's also very brief. It's just I wasn't planning on writing an adapter or anything. No. Because I can visualize some of the functionalities that we have. So this would be, for example, the schema configuration where we map to the ontology. We did actually go the way and revive-vived, so to speak, an ontology that was created 10 years ago, which is called Biomedical Resource Ontology, or for short, BRO. I really like the name. Basically, they did it 10 years ago to fuel a platform where they talked about biological or biomedical resources. And this seemed very fitting for our purpose. So we now use this to grab the data from the GitHub page that I had in this slide. You just, so maybe. Component page. We use the GitHub API to get this information in a BioCipher pipeline, which is what I'm showing here. So this is the mapping. This is the configuration. It says it's offline, so we don't talk to a running DB. We just write these files for input. As I said, we have this head ontology where we use mostly the BioLink model, which is just a very general overarching thing. And then for the information content entity, we join the resource, which is the top node of this biomedical resource ontology. We join it to this ontology, and then we have the combination of them. We have some Neo4j set up here, and then this adapter takes care of getting the data and giving it to the framework. And then we have this Docker Compose set up, which is three stages, mainly because we want a read-only instance that we can mount to this meta.bioscipher.org page. to this meta.biocypher.org page. And just to demonstrate what it does, we can run this. Don't mind this here. I'm on ARM architecture, and we build. The server is a Linux one, so that's why it gives this error message. So we are at the build stage, where we just pull this BioCypher image, which we have on Docker Hub, and it installs. And then it will run this script, which uses this adapter here, which is basically what I showed before in this usage thing. So we set up the environment. And once this is done, we start BioCypher. In this case, it's 0.5.9. And then it runs this creation script, which should run very quickly. We are calling the API at this point and then loading the ontologies. And now it's already done. So it joined the ontologies and it wrote for all of these different types that I defined in the adapter it wrote the corresponding neo4j input in this file here and it also shows you that we didn't we found duplicates in users because we have multiple connections between these issues and it shows you the structure so So we just have these very simple associations where we have part of and uses and then we have adapters. So we have input formats, data types, resource types and then the various adapters, input adapters, ontology adapters and output adapters. Then the second stage starts which just mounts the Neo4j Enterprise Edition, and it imports these files that have been generated by BioCypher. And then it stops again because we want to mount a third one that is read-only, which can only be done by importing it, stopping, and then starting another instance with the same database. Okay. Yeah. And then you can go to localhost or to meta.bioscipho.org. We don't have a password, but it's read-only. And then if you look at the entire graph, this is what I mentioned previously, this is the browsable overview of what we have in BioCypher. So if you, for example, are interested in say, oh, this shows ID. No, that's actually not what I'm interested in. So say you're interested in genetics. You could see the adapters that use genetic information. Then you could also see the pipelines that use these adapters. So for example, the IGVF project that I mentioned, this OncoDash tumor board thing uses a genetics adapter. And you can go either to the GitHub project page or directly to the URL of the pipeline or the adapter. So here is the OmniPath adapter, for example, and this is the OmniPath pipeline. And for biotech, Yana is a cell communication knowledge graph that we are building and so on. Yeah. So this is basically it, just a demonstration of this meta graph and what the BioCypher pipeline does, including the Docker integration to make things. And then it's there and then you can work with it and go and score. Yeah, and in multiple stages it records, for example, we have version 3.2.1 of the BioLink model and we have version 4.0.0 of the biomedical resource ontology. Yeah. And these files are imported into Neo4j in one second. So you can just zip these up and share them with someone. It's a zip file of maybe 500 kilobytes. And it's immediately reproducible. Of course, this can get much bigger in actual genetics application cases. But yeah, you can do lots of fancy things around these. So for example, the project which is probably most advanced is this one that I mentioned from Stanford, this impact of genomic variation on function, where they just took BioCypher and wrote like 10 adapters and are creating an API and also a GUI, I think, on top of that, and they did it in like three weeks. So that I think is really impressive. And the good thing is that we have these adapters in the GitHub and in this Metagraph and they are linked. They're open source. And if you want to use one of these resources, you can basically immediately reuse this adapter without having to write something yourself. Cool. That's great. Question from a couple of people is, is this sample you just showed here, is this available on the GitHub repository or can people... This is called Metagraph. So if you go to the website, we also link to the... So if you go, for example, to adapters, it explains about this thing, what we have in the adapters. We have a tutorial about the adapters, but we also have this Metagraph, which this is the link to the online version and this is the link to the repository, which on the main branch, there is a version that is not read-only, so you can modify it locally. But the read-only one is the version that we run on the server to provide this meta.bioscipher.org instance so that people can't just... No, of course. Yeah, that makes sense. so that people can't just know of course. Yeah, that makes sense. No, I mean, and then this is this is maybe so just to know that I guess to explain this is this is the meta graph of of of of the bio cipher project. And if you if you combine your own knowledge graph with a couple of these adapters, then you get your individual kind of. And you can I, I would assume that looking at these projects, so this components board is basically the main thing. That's also where the metagraph is built. So if you're interested in these things, you can just look at, say, you're interested in a pipeline, we look at crossbar, we have links to the individual adapters. So here's string, it's a protein-protein interaction database. And you can look at what the stage of the adapter at the moment is and then see whether it can reuse something, see whether you can get some inspiration about your own adapters. That's what I would recommend. And, of course, if you're new to the concept, then I would recommend going through the tutorial, which we have on the page where we go through basics, ontology considerations, and then also about the adapters. Yeah. And there's another question. How... I think you mentioned this briefly, but how would you say... I mean, let's say you initially created your knowledge graph of a couple of of resources and you want to let's say update that you you have uh something changed or so let's say every month or so you run a update is that something you would do via the the the BioCypher connectors or yeah basically this is what we already do with OmniPath it's not on BioCypher yet but this was the incentive for developing the framework in the first place. And we have a daily build. So if something changes in the resources, either it's the same resource that you already represent. So you just download the new data and it runs. Maybe if they added something, BioCypher will tell you, look, there's this new node here, which you have not in your configuration yet, but that's fairly easy to deal with. If you want to add an entirely new adapter, you would go the same way as you would when creating a new one. You just take your existing pipeline. You see whether someone already has done an adapter for this resource. If not, you need to write one, of course. And then you can also share it and everybody else can just use this adapter. And you basically need the adapter and you need to configure the adapter where it should go in the knowledge graph. So say you want to add information on diseases. So you reuse one of the disease adapters that we have, for example, from the OpenTargets platform, you say, give me the diseases and the categorization in ICD-10 and maybe what species they are in. And then you add this to your configuration and then BioCypher will just process the data and add it to your graph. I say just... Yeah, but that's super and makes it easy. And you don't have to worry as much about... You have to worry about keeping your graph up to date, but the process sounds at least very easy. So you don't have to do it all. There's all kinds of tricky pitfalls in this process, right? So if you're dealing with something that is conceptually very complex, like diseases, you always have issues with harmonizing stuff. So we are fans of this adapter layout because there you can also, so you have three resources, three primary adapters for some protein protein interaction stuff and maybe some of it is duplicated maybe some of it comes from the same paper and you don't want to count this information twice so there's always some logic going on but the good thing is that you can add this logic at any point you can add it in the adapter you can also have like a secondary adapter between these three initial adapters and your final script. You can also add some logic in the script. So it remains transparent what you do. I'm not saying we are single-handedly solving all of the harmonization issues of the field because that would be a bit much. We just want to make the, you know, the menial tasks of the data crunch. We want to make that as quick as possible so that you can dedicate time to the more important tasks or the more difficult ones. Thank you for doing this. I think there are lots of people who are struggling with this and who are probably tearing their hair out by having to do this regularly. And, and this makes it, makes it much easier. But technologically, as I said in the beginning, I think not even half of it is the actual technology or very brilliant Python programming that we do. Most of it is just communicating, getting, having a place where other people are that have the same problems and talking to them so this this kind of community management thing and bringing people to one place which so far doesn't exist in in knowledge representation as far as i know i mean there are ontology conferences but usually only ontology researchers go there and not somebody that is a PhD student somewhere and wants to write a knowledge graph for their particular task. So I guess that's where the democratization comes from that we have in our title. Cool. Yeah, I see no more questions. So yeah. Thank you very much, Sebastian, for presenting, for taking the time. Obviously, thank you for you and the BioCypher community for developing BioCypher. Seems to me like a great project. And again, invitation, open invitation, anybody. And again, invitation, open invitation, anybody, if you either want to use it or want to contribute, want to be part of BioCypher, have an adapter to write or have, we heard, a web application is a need. So if that is something you want to be part of, then reach out to the team, either via the BioCypher website or via the GitHub page. And you find the contact information website or via the GitHub page. And you find the contact information there or the what's called Zulu board for chat. So I think that's the easiest way to get in touch. Try it yourself. Obviously with the tutorials, I think it seems to me very easy and very user-friendly to get started. So that's always helpful. And yeah. Any final words, Sebastian? No. Thank you. Thank you to everybody for listening. Thank you for the invitation and to tell you a bit. And yeah, don't be shy. If you think this could be useful for you, and even if you think, think yeah my programming skills are not great or anything just join the community there are similar cases as that and we try to help where we can or we try to facilitate everybody helping one another so to speak yeah that's great so it sounds like a friendly community. So definitely join that. And yeah, with that, thank you for being here. Thank you, Sebastian, in the name of the Bioscipher team for developing this. And yeah, I hope you had a good session, everybody. I hope to see you soon at one of the next live streams. What's coming up is in this week on Thursday. So in two days, morning European time, Michael will do another episode with having fun with chat GPT and using chat GPT as a co-developer, co-coder for a fun project. So that's happening on Thursday. And then, yeah, next week going meta. So keeping the launch graph kind of going, we will do episode 16, Jesus and I, on knowledge graphs on Semantic Web and on ontology. So I'm not sure what the exact topic will be next week, but if you're interested in knowledge graphs, then tune in on a Tuesday. Yeah, when learning the others, videos will be available offline on YouTube. So if you go to youtube.com slash Neo4j, you'll find our channel there and then you see all the videos in the in the playlist. So everything is available afterwards. To watch again. Yeah, with that, thank you for watching. Thank you, Sebastian. And yeah, see you soon at another live stream or somewhere around the globe for Neo4j events. Take care, everybody, and have a good rest of your day. Bye-bye. Thank you. Bye-bye.
Neo4j Live: BioCypher
Building a knowledge graph for biomedical tasks usually takes months or years. What if you could do it in weeks or days?
For this exact reason, BioCypher was created to make the process of creating a biomedical knowledge graph easier than ever, but still flexible and transparent. BioCypher is built around the concept of a “threefold modularity”: modularity of data sources, modularity of structure-giving ontology, and modularity of output formats. This design allows for a high degree of flexibility and reusability, rationalising efforts by leveraging the biomedical community.

Links:
BioCypher https://biocypher.org/
Github https://github.com/biocypher
Paper: https://arxiv.org/abs/2212.13543
Sebastian Lobentanzer https://twitter.com/slobentanzer
Graphs4Good: https://neo4j.com/graphs4good/

0:00 Intro - About Sebastian Lobentanzer
11:10 BioCypher Overview
1:04:15 BioCypher Demo
1:17:20 Wrap-Up


#neo4j #graphdatabase #knowledgegraph #lifescience #biology #biotechnology #healthcare