 Okay, why don't we get started? So I'm Jim Saylor, Scientific Project Manager at NIMBL, working on the Big Data Program. So welcome everybody to the NIMBL webinar series. This one's focusing on process ontology. Next slide please, Robert. So a few announcements before we dive into the content. Please put all your, everybody on the webinar will be muted throughout the presentation, so please use the chat feature to post a question. And go ahead and post a question whenever the question comes to you. We will address the questions at the end. Another reminder about the confidentiality this webinar is open to both Nimble members as well as non-members so please don't post any Nimble confidential confidential information or proprietary information in the chat. And And so following this webinar, you will receive a survey link by email. Please fill out that survey link. We value the information that we gather from there. One thing that you will get from filling out the survey link is immediate access to the webinar recording. So I would like to remind everybody about the the big data program that's coming up on March 15th and 16th. It's open to both NIMBLE members and non-NIMBLE members. There's an open session to everybody on March 15th and a NIMBLE membersonly session on March 16th. Please, if you're interested, please go to the Nimble website. The address is right down there. And register. If at all possible, please register for in-person. That would be great to meet everybody and have everybody in the same room. But if not, please register for virtual. And then you will receive some information and have everybody in the same room. But if not, please register for virtual. And then you will receive some information shortly about the actual agenda. If you're only able to attend virtually for a session that you're an SME in, please do go ahead and register for the the uh webinar for the program uh workshop and uh just join at that session that would be great uh i'd like to remind everybody that the registration closes uh this monday march 6th so uh please go ahead and register and uh if you would like to participate in the big data program or the big data bd1 work stream you can contact me if you're a member and i could i could fill you in on the program and and how to get involved if you are a non-member please go ahead and contact me as well and i'll put you in touch with the appropriate people to fill those questions. Next slide, please. So again, welcome to the NIMBL webinar series. This one is on the NIMBL biopharmaceutical process ontology, an introduction to ontology concepts and a path to implementation. It is given by Robert Hackathorn. Robert Hackathorn joined AstraZeneca. Back one slide. Robert, thanks. Robert joined AstraZeneca in 2008 as a senior scientist on the process cell culture team after spending the previous six years at Axelon Pharmaceuticals in a similar process development role. Early in his career, he saw the opportunity to make life easier for scientists through the automation of repetitive manual tasks. At that time, Robert began learning about databases and programming and was able to bring together some crude but effective tools automating data transfer from highly used lab instruments. These small efforts to automate data transfer from highly used lab instruments. These small efforts to automate data capture from cell culture instruments has evolved into a second session of his career, focused exclusively on creating fair, integrated lab ecosystems in the biopharmaceutical development that manages lab workflows and data, but also collaborates with robotics. Robert currently leads the informatics and software engineering team in biopharmaceutical development at AstraZeneca. Robert also enjoys playing stringed instruments like guitar, mandolin, and bass guitar. Thank you, and here's Robert. Robert B. Okay, great. Thank you for the introduction. I appreciate that. And before we really get into the presentation, I just want to sort of pre-acknowledge. So, we'll put the acknowledgments at the front here. And it's really everything we're talking about today and the work that we do within the big data initiative is impossible without the financial contributions, but also the collaborations from all of these member companies. So, thank you again for that. And in terms of the presentation today, we're really going to be focusing on ontology, but we're going to take our time getting there in terms of the biopharmaceutical process ontology that we've been working on. And we're going to start by really just introducing the concept of ontology. Where does it come from? How does that kind of ancient philosophy of ontology work its way into modern information science? How do we…what kind of technology do we need to have in order to implement ontologies within our organizations, within the information ecosystems within our organization. And, you know, in terms of the ontology itself, the biopharmaceutical process ontology that we've been working on, we're going to take a 30,000 foot view of that. I think we're going to see that as you start building an ontology and adding concepts to that ontology, the complexity really starts to increase. And so, for us to really zoom into the biopharmaceutical process ontology, it would be challenging for this presentation, but we will take a high level view of it. And then we'll talk about business processes within development organizations, within manufacturing organizations that can be potentially re-engineered as processes with the nimble ontology at the core. So, so we're going to start with ontology, an ontology is, and then we're going to go through a couple of things that it is. And 1st and foremost, it's, it's a buzzword right now. I think. You probably hear maybe in the hallway or just colleagues, you know, we need an ontology. I, you know, I'm guilty of saying this without, you know, really understanding what that means. I think the problem with buzzwords is that they evolved to BYOD, which is bring your own definition. And they tend to take on the meaning of the moment rather than sort of a static meaning. Other buzzwords or phrases that we've encountered, at least I've encountered in my career, digital transformation, these are all very important things. I'm not trying to diminish the importance of these initiatives. It's just that they tend to be blank canvas terms that people can assign their own meanings to. 5S, we need 5S our labs. We need data centric systems. We need FAIR data. So, we're going to spend some time really sort of defining what ontologies mean in our context, in our industry. Also ontologies are not new. This can be, they could be traced back to Aristotle probably even further if we wanted to dig further. But really it's a philosophy. It's concerned with existence. What is existence? What is reality? What does it mean to become? And some of the concepts that this philosophy deals with are things like categories. We can look at the world around us and start to classify things. We can say this is an apple and that an apple is fruit. We can also, there are one-to-one mappings. We could say this apple is red, which would be like a particular. There are universal. This would be more like a mini-to-one, like frogs and celery are green. So we've now made a mini-to to one classification of two different unrelated things. Now, where when we get into abstract and concrete, these are concepts that really make their way into our kind of modern use of ontology in a powerful way. So abstract abstract concepts like numbers, ideas, propositions, concrete things. We can touch a tree. These are things in the material world that we can interact with. A person, the sun, although we probably don't want to interact with the sun. So this is a very deep and old philosophy that anyone who's interested can really dig as far as they want. But what about information science? What does it mean for us? And luckily, we have this really hissy, clear definition of ontology for information science it's a specification specification of a conceptualization which actually i think is so clear we could probably just end the the webinar now and everybody get like 45 minutes back um but oh but actually it's not that helpful is it i think i have to admit the first time i heard this i had idea, I had no better idea of what an ontology was after hearing this definition than I did before. But I think we can spend some time digging into the what do we mean by conceptualization, what do we mean by specification, and maybe it'll start to become a little clearer. So conceptualization, this is the meaning that we associate with a set of terms. So I was talking with a colleague yesterday and he had a great example. He's like, if you just throw out the term table, it's, you know, for me, my mind immediately jumped to database table. My kids, though, would definitely not think about a database table. They would probably be thinking about the table at school, the art table or the dinner table. But when we start to specify what we mean by table and bring in dinner table or bring in database table, it removes that ambiguity that occurs. Between individuals, because we all have our different, we all have our different set of experiences that determined when I hear the word table, it means something. It means something to me that's different than when you hear the word table. So, that's still not super clear. So we're going to continue to try to push into this a little bit. And we're going to have a webinar participation exercise here. We can use the chat, I think. It's not necessary, though. But what I'm going to do is I'm going to put a concept. On the screen, and I just want you to think about the what what's the initial meaning that that that jumps into your head. Like, what is the 1st thing you think of what what does it mean to you when I put this concept on the screen. And so are you ready? Okay, so a fast horse. We'll just take a second and think about what what that means to you. And then for a moment, I just want to pretend that you're someone who you're who you aren't. So we're going to ask you to pretend that you're Bob Baffert, who's like one of the world-renowned trainer, right? So his horses are like winning Kentucky Derbies almost every single year. And then, and so how does your, how does when you're putting yourself in his shoes, how does your, that concept of fast horse differ from what your initial concept was? And then let's imagine you're the trainer of draft horses. So you're the person who's walking next to this team of Clydesdales, but your job is training draft horses. Your concept of fast horse might be very different than a fast racing horse. Right? So the conceptualization differs between individuals because it depends on domain knowledge. And domain knowledge is just your accumulated experiences and expertise. You know, this accumulates over a lifetime or over a career. And specification helps to remove and reduce the ambiguity in concept. So we could say a fast draft horse, and we would know that that would be, in terms of fast horses, that would be a very different thing than a fast thoroughbred. Okay so we're starting to make a little more sense. I think so we could we could take our original definition and we could start thinking about ontology as really being anything that helps make conceptualizations less ambiguous. So we're bringing specificity to ideas, basically. So will I know it when I see it? When I see an ontology, the chances are there are legacy information systems in your organizations that kind of fit this definition, at least loosely. I don't know that we would look at a. A vocabulary system and say, oh, that's an ontology, but it is a shade of gray, certainly closer to white than it is where we're ultimately going to land on the right side of the spectrum. But when we take steps as an organization to standardize vocabulary, oftentimes when I've heard people asking and advocating for ontologies, the next phrase is we need controlled vocabularies. Right? So this concept of lexicon, it is definitely related to ontology, and it is a shade of gray. And as we work our way left to right across this, we start to, if we add a little bit of functionality to a lexicon or to a vocabulary, we could start putting some hierarchy into it. So maybe we have a term that's called a bioreactor, and then bioreactors may have another term associated with them that is a controller. And so controller might be a pH controller or a temperature controller or something along those lines. But our taxonomy starts building some of these basic hierarchies of our terms. And then we could take that taxonomy and we can start adding essentially synonyms. So for me, within our organization, depending on where you've worked before or what group you went to school, like where you went to grad school or undergrad, you might refer to a bioreactor as a fermenter. These are kind of interchangeable terms. And so within our thesaurus, we may want to have that kind of a relationship, that they're connected related terms. But you still have those concepts of the hierarchy. So, we could then say that a fermenter also has pH and temperature controllers. Now, getting very close to sort of where the majority of my experience has been, and probably a lot of organizations, rely heavily on relational databases. So, you have SQL Server, Oracle, you know, your LIMM system might have an Oracle database, your other lab experiment management tools might be SQL Server. Well, the entity relationship model that went into designing those databases are really starting to get closer and closer to what we would think of as an ontology, where we have the concepts that are listed, the concepts are captured in the tables and the fields that are members of the tables, and the relationships are going to be managed through primary and foreign keys that sort of say this table and this concept is related to this other table and these concepts. And then we get to a graph database or the semantic web. And this is really where we want to land and where we're going to be spending the rest of the talk, like, yes, these are shades of gray, but really anybody who's working and developing an ontology isn't going to be just working on a controlled vocabulary. They're not just going to be working on these other things. They're going to have a specific set of tools and a specific set of practices that are going to go to build that ontology and to store that ontology and then to leverage that ontology. And it's a different set of tools than any of these other systems. So, we need to talk about graph databases and that they're used for representing ontologies. So just like I mentioned with the relational databases, we're used to seeing tables, columns and tables, and then the data being loaded into rows. It's a completely different concept with representing ontologies in a graph database. So information is stored in these systems in a format called triples. So a triple has three parts. It'd be funny if it had four parts or five parts, but they're called triples for a reason. They have this subject, predicate, and object, which as a person that only cared about science and math going through school, I kind of when I first started being introduced to this, I'm like, okay, that that also didn't make a whole lot of sense. But, but when when we break it down and illustrate it with a simple example, I think it's really clear. So, an ontology is going to be defined by a set of entities and relationships between those entities. And we name those things subjects, predicates, and objects. But in reality, we're naming two things, and we're saying that there's a relationship between it. So a trainer trains a horse. the horse, and the predicate is trains. So, hopefully that is super clear. And that's our ontology. And the interesting thing about this approach is that your data is described and stored in the exact same way in your graph database. And so, we may now have some data that we want to store in our database. So we want to say Bob Baffert trains Justify. So Bob Baffert's a real person, right? And he's a trainer and he's, he, and Justify is a real horse. between these two things. And then we can take it a step further and relate these things back to our ontology. So our data now being directly bound to our ontology. We can say that, well, Bob Baffert is a trainer. So now we've got a way of linking that concept of Bob Baffert is a trainer. So now we've got a way of linking that concept of Bob Baffert into our ontology and justify as a horse. So for everybody that are ontologists that may be connected to this webinar, I feel there's great power in simple examples, but we are building towards something. So if this is too simple, please just bear with me for a minute. And we'll get into some of that now because we want to talk about—so what we've seen so far are sort of typical ways of representing triples. And we can call this on the left side, we can actually refer to this now as a graph. But the data itself is stored in the graph database as triples, and it has a specific standard that has been developed. And there are multiple standards, depending on the systems that you use. For example, Oracle, go back to the relational databases, you may have nuanced differences between your queries that you write in Oracle as compared to SQL Server, right? So, there may be nuanced differences in terms of how data is stored and transferred between systems in graph databases. So we have something called RDF, and this is called Resource Description Framework. And just think of it as like JSON or XML or some other like markup language. It's a standard way. It's a syntax for capturing the information that we need to store into our graph database. And if we're thinking about ontologies specifically, so, you know, we pointed out that there's the there's triples for defining an ontology there's triples for defining data well so there's an extension or a variation of rdf that is specific for describing an ontology and defining an ontology and that's called owl which is the ontology web language or web ontology language, but I think if you say WOL, it's not as cool as OWL. So I think it's just ontology web language, we could say. But it is RDF, essentially, and it has a very nice human readable kind of way of being written. I'm gonna say this now, and I'll say it again towards the end of the talk. You don't have to know how to read or to write this code. Okay, we're gonna get into the systems that you use to edit and design ontologies. They're gonna write this owl for you. You're gonna be dragging and dropping and establishing relationships between things in a very intuitive way. The RDF, the owl, will be written for you by the system. But that being said, it is highly readable. We have this top section here that you see the word prefix. Actually, the prefix is actually, you know, we can say EX. Instead of writing this whole string of characters, any place below this, I can just use EX. And then that's so that essentially is defining the prefix. This is where you can import your ontologies that are sort of standard ontologies, or ones that you want to bring in and connect to. And then in this example, we're just going to have EX be the thing that we're defining. So we could walk through this code a little bit and say that we're going to define a class. So that's this class. I've been pointing to the wrong thing. So we're going to define a class so that's that's this class um oops i've been pointing to the wrong thing so we're going to define a class um which is called trainer and we're going to define another class which is called horse so that's these guys and we are then going to define the relationship between them which is called a property. And that's trains. And so it's really that simple. But you can imagine as this grows, your OWL document is going to contain potentially hundreds of these class definitions and property definitions. The data is exactly the same. It's RDF. And so now in order to describe Bob Baffert as a trainer and that he trains justify, we have two rows for that. And then we have justify as a horse. And so that it's that simple. Again, you don't have to learn how to write this. I find it useful to be able to look at it and extract some meaning from, oh yeah, read through it and it kind of makes sense. Now, if we wanted to, we're gonna talk about ontologies being designed, I mean, the great power in ontologies that I see, there's many, but is that they're able to be extended and they're really designed to be extended and to bring in other ontologies. So, you know, NIMBLE has, as an organization, has put a lot of effort into this, into the biopharmaceutical process ontology over the last year. At some point, that's going to be available to the outside world. And, you know, that'll be accessed by linking it into whatever their ontology system is that they have in their organization. I'm going to show you how easy it is to link in another ontology. So there's something called FOF, Friend of a Friend. And this is a really important ontology, actually, because a lot of your social media tools that you have on your phone are actually driven by FOF on the back end. And so it's an ontology for defining people and relationships and properties around people like their name and stuff like that. So we can make an import of FOF into our graph database, and we can then basically say Bob Baffert is a person, and we can capture that in our data. Bob Baffert has a name, and it's Bob Baffert. So, you know, so, but really extending the ontology, bringing in additional ontologies is that straightforward. In the relational database world, we would need to sort of re-architect, add fields, add tables, add other maybe foreign keys to do that same thing. So, this is the 30,000 foot view of the biopharmaceutical process ontology that Nimble's been working on that I alluded to earlier. So just as that previous slide was starting to get a little bit complex, you can imagine hundreds of concepts and relationships being built into the ontology and how complex. This is not the entire ontology. This was like a kind of a cool looking subsection of it. So, but I'll say that the, you know, when the work was initiated, there were certain use cases that were in mind. Things like process monitoring, you know, these are use cases that it would be great to be able to enable using the ontology. Process monitoring, cross domain project aggregation, you know, so if you've got you know maybe it's just creating line of sight across unit operations, you know, so that we can navigate the data from saw to drug product vial, for example. So raw material impact, so what's the impact of raw material inputs on the product quality would be an example of this type of a use case. And integration of results across process steps. So that's the line of sight that I was talking about, but also more than that, material genealogy, sample tracking, et cetera. So I'll say that for people that have worked in this industry for any time at all, probably ISA 88 is not a new term. It is a standard and it was a key component to informing this ontology. And just to reiterate, ontologies are always extendable. They are extendable in two important ways. Integrating with other existing ontologies, like that FOAF example that I just mentioned, or building new classes and properties to meet your organization's needs. So, you know, a antibody producing fed batch process is kind of what was in mind when this ontology was built. And there may be a lot of overlapping classes and and and properties that that for organizations that are solely focused on stem cells or car T. But that extension that's okay use the, you know, use the part of it that is relevant and then extend it to meet. The, the, the processes that your organization is running. So to get started, you're gonna need some tools, and a lot of them are not gonna cost anything. And you can certainly get started very, very, as a proof of concept, you probably could get started with ontologies in the, tomorrow, for example. Not with a nimble ontology. We'll talk about that in just a second. But the so open source, free license, a lot of these tools are Mobi, Protégé. These are environments that allow you to define classes, establish relationships between classes, and really just build up your ontology and ultimately export that OWL file that will be what your database needs for ingesting that ontology. So again, you don't have to write the code directly. You're going to need a database. So databases – some graph databases are also called triple stores. Neo4j is not a triple store. It is a labeled property graph, and it just has some additional features that may not be present in some of the other graph databases. ANZO is the tool that we've been using at Nimble. There are others that are quite popular, AllegroGraph and Neptune. Neptune is the AWS managed service for graph database. So in the end, what will that look like? What will sort of a cartoon schematic of your graph database look like? This is the Neptune icon. It just has a nice color, and I'm not trying to sell Neptune to anybody. But, you know, your nimble ontology OWL file will live there, any other ontologies that you have. There's a concept called shackle within most systems. This is just about data validation. So, making sure if you're ingesting a certain type of triple that you're getting, you know, and you're expecting a date-time that you're not getting an alphanumeric kind of formatted input. So it's just about the data validation. The graph data will live in your graph database, obviously, and then just like with relational databases there is a really nice easy to use intuitive query language called Sparkle and that's kind of what the tech stack regardless of which database you choose this is kind of what it's going to look like. There are different types of capabilities that can be constructed around not just the nimble ontology, but really any ontology. But we'll go through the thought exercise of saying, okay, let's say we have the nimble ontology right now. One of these is called, I would just kind of tag it as being capabilities that are all about insight, gaining more insight. These would be typical ML, AI kind of applications where you start with operational data sources. This could be well-structured, it could be unstructured or semi-structured data, and that's why you need a data engineer. This could be well-structured, it could be unstructured or semi-structured data, and that's why you need a data engineer. The data engineer is going to have skills like Python or, you know, so they could write some code to do ETL. ETL stands for Extract Transform Load. So basically, you could write code to pull large volumes of data out of your operational sources, curate that, clean that, normalize it if that's what's needed, and then bring it into your graph database. The other, this is probably the more common approach. You know, Nike automation is what we call it in our group. And this is just kind of brute force. Nike automation is essentially no automation other than the person. So I've seen examples of data set construction where having to go through and pull data out of PowerPoint files. If that's where the valuable information is, that's where you go for it. And sometimes you have to use the Nike automation. But in the end, you get a well curated data set that is a resource for BI, business intelligence, machine learning, AI, or advanced analytics. So the insights, maybe there's a prediction, you know, or, you know, there's a model that is developed based on the data set and the predictions can be made from that. Or maybe there's some kind of business intelligence visualizations that are stood up in Power BI or Spotfire or something. So some of the – to go back to the original use cases, you know, that cross-domain project aggregation, that line of sight across projects or across unit operations, raw material impacts on product – so inputs affecting product quality, you know, and then line of sight across uh and establishing material uh genealogy so there's another type of um implementation and this is this is where astrazeneca or at least our team is really going to be um focusing when we when when we start the the nimble ontology implementation we're going to be focusing on on building ontology driven operational tools. And so, and we'll go into this a little bit about what exactly that means, but instead of having that, you know, all of your systems, all of your operational systems sort of being in that legacy, either relational data based historians or others, having the operational tools generating the graph data from the beginning. The clients which are depicted on the right, so this would be the user interfaces that our scientists already have, they're not going to change. The APIs and business logic are going to operate on, it's just going to have a different back end. And, you know, this kind of retooling, at least as far as the operational tools themselves, it's going to be kind of a transparent change to our end users, but the shape of the data and its readiness for the data engineer is going to be a completely different, potentially game-changing scenario. So, we go back to this insight, building large curated data sets for BI, ML, and AI. Well, in the future, we're going to have fewer and fewer of these systems, potentially, hopefully, and more ontology-driven operational tools so that this Nike automation, this code writing for ETL is maybe less necessary, and it's more of a sparkle query to get the data that you need, and then it's more ready. I don't think we're ever going to make the data engineer's job easy, but we can certainly make it easier. And so, you know, ontology-driven operational tools streamline data engineering when building these multi-domain data sets. And so, okay, so this is a – this came about from me trying to find and identify, like, business processes in our organization that are – that don't depend. So, I work in a development organization organization and we develop and design the processes and. And then, you know, are transferring them to either clinical or commercial manufacturing, but a lot of our require knowledge that would be contained in, you know, or potentially driven by ontology based operational systems. So, this is just an exercise to show, okay, well, here's some of the basic business processes that we have that, you know, would involve equipment knowledge. Things like equipment utilization, instrument data acquisition. I kind of clicked the button too fast here, but equipment scheduling, metrology, all of these things are key things that we do as a development organization that depends on knowledge about the equipment. Knowledge about the process recipe. I have an experiment design. What is the process that I'm running that I'm basing that experiment around? I'll point out two more of these. Bringing context to the instrument data. So, okay, I have some data from a VICEL or from a cell counting instrument or from some other, you know, process monitoring instrument. What's the context around that? What was the process that was being run? At what point in that process was the sample removed? Likewise, bringing that same context to the product quality data. Was this a, process intermediate was this drug substance. And then finally, um, you know, more complex, so equipment recipe and maybe some business logic or some other integrations with other systems. Things like capacity modeling capability modeling tech transfer facility fit. These are all, you know, processes, things that we do as organizations that that depend on a intimate knowledge of. Of the process or the equipment, which is equipment is part of the process. So, so there is a future where where the nimble process ontology could be at the core of many of these operational data systems, which again, would make that data. Just, you know, we want to go back to fair data. It makes the data more fair, but it, but, but from a practical perspective, it makes the data more ready for for machine learning and AI and the more high value things that we do with our, with our data. And I'll, I'll plug document automation into that too. So since I've been in the industry, there's been talk about the holy grail being automated regulatory filings. So maybe that's something that we could inch closer towards as well. So in summary, ontology is a buzzword. It's also a powerful tool for information management. To get started, you're going to need an editor. You're going to need a database. You don't need to know how to write RDF code, which is a good thing. And I'll just also say that Nimble will be progressing the biopharmaceutical process ontology into production this year, so stay tuned. Just want to, by way of acknowledgments, just highlighting the folks at the bottom that really just keep everything moving forward so roger jim sandeep and taylor um special thanks to to you um and then uh i think with any luck at all i've i've ended with enough time for some questions yes thank you thank you robert yes we have a few minutes for questions um so if you haven't posted your question already, go ahead and post it in the chat. We do have a few that are ready to go right now. If you go back one slide, Robert. Not sure why that happened, but sure. I think I set my coffee down in the mouth. Oh, there you go. Okay, so first question we have here is, for what scale of an organization, like how many related products do you need, will the benefits of an ontology-based data system justify the part of that again? It's for what scale organization will the benefits of an ontology-based data system justify the cost of implementation? And they kind of asked in that question, like, how many related products do you need before you can say that this would be fit for an ontology? Yeah, that's a really interesting, interesting question. I think you can kind of bite off as much as you want, to be completely honest, because we could think huge about having a dramatic impact on the industry and having standards for tech transfer. So So if I develop a process, having an immediately compatible way of transferring that process to a CMO or to one of our internal manufacturing sites and just having that consistency of and compatibility across the industry, I think that is a much higher. Activation energy barrier than looking within your organization and saying, well, we have a lot of manual. Processes relating to our information, whether it's the data acquisition itself, or whether it's aggregating it together for things like the LA filings or for, you know, which would be some of the analytics that go along with that, and having some progress towards improving that. And, you know, having ontology-driven operational tools would definitely not be, you know, nothing we do is necessarily cheap, but certainly you can dip your toe in and sort of invest as value as you're starting to see return on the investment. So, you know, it's kind of a wishy-washy answer, I know, but, you know, I don't have a good, good number for that. Yeah. Okay, thank you. You might have covered this already and answering this previous question is, what are the business benefits associated with creation and use of a. By manufacturing process ontology by nimble members and the bio manufacturing community in general. Yeah, I mean, I think you could see the long game of being, hey, let's speak the same language and have compatibility across so that we can just streamline things like tech transfer from organization to organization. I think the sort of more intermediate term kind of practicality is that we can have internal streamlining of things like tech transfer of facility fit of these types of things without having, I think it is going to be a more challenging thing to impact the industry, but I think that is our objective long term is to have that kind of impact on the industry so that we at least have a way of translating from organization to organization. It may not be a one-to-one, but it may be that, okay, AstraZeneca is going to publish a process into the Nimble ontology structure so that it's then ready have to integrate directly to CMO1, but we're, you know, CMO1 is able to ingest recipes that are published into that structure. Great. So another question here is, has the ontologies for the various business processes highlighted been developed created already yeah i would say um the it's a it's a work in progress our our um our intent in terms of as we launch and go into production will be to have a planned roadmap for when. So if we think about the core ontology that has been built that is fairly comprehensive, there will be modules over time that are sort of maybe more domain specific. You know, that that maybe there's there's there needs to be a module that is specific around cell banking, for example, or maybe there's there's a module that needs to be built out that that that makes the ontology extended extended into into CAR T processes. Yeah. Great. And then there's another one. So do you align the ISA 88 process model, procedural control model, some legacy models like the chemical engineering's unit operation or some custom concepts terminology? For the – yeah, we did our best to preserve the ISA 88 standard. That being said, I think there were, there's obviously things that, you know, were extended beyond ISA 88. And, you know, one that I can throw out is the concept of units of measure standardization, you know, being able to bring in an existing ontology that already has solved that problem that, you know, that we can just tap into and so that that is um maybe outside the scope of is88 but it's something that still that that there's value in being able to have control of that aspect of of how you describe processes great thank you uh maybe just one more question um and if we don't get to your question i'm sorry there are a number of questions actually that came in through the through the chat. So we just don't have time to hit them all. But if you, if you really want to. You know, find that find an answer to your question, please reach out to me. My emails in the 1 of the 1st slides and I can get that answer for you. But I have one more quick question. Let's see. So bioprocess ontology is a big creation for standardizing nomenclature. Has Nimble looked into what other ontologies have been created and if and why they were adopted or not adopted? First of all, I would like this person to join our team in terms of the ontology work stream. But this is a challenge, right? So what makes you different than other initiatives, right? And, you know, we can look at IS-88. That's a standard, not an ontology. It tells you basically everything you need to know, there are other examples in our industry, like I think BatchML has had, you know, there was a lot that went into that. And why some things take off and don't, I think, is about the approach. How accessible is it? I think there's a reason we want to walk with members and others that are going to be adopting the ontology. We don't want to just throw it over the wall and say, here's this really complex thing. Just go run with it and try to figure it out on your own. I think our plan is to have implementation case studies that will be available to organizations that are adopting the ontology to not just sort of say, oh, we're done, we're going to publish it and we're walking away from it. We really want to create partnerships and kind of walk with those organizations that are implementing it so that they're not going to just sort of feel like, hmm, this is really complicated. I think I'm just going to stick with my relational database, right? I think that I can attest to that. I've been in that situation where I'm like the amount of education that I need to adopt this new thing is way greater than sort of maybe some of the shortcomings that I can work around in doing things the old way. Right? So, I think that's why some of these initiatives fail. You know, many of them have great initial concepts and ideas and intent. But, you know, we're working hard to not become that. Great. Thank you, Robert. And thank you everybody for sending in the questions. Sorry if we did not get through your question. Like I said, we got a large number of questions actually through the chat. So Robert, maybe go to the next slide. So if you want to find out any information on all things Nimble, including the Big Data program and ontology and the Big Data program please visit our website there's information on there you can also follow things that you you might want to get updates on and you won't get an overwhelming number of updates i think it goes out like once a week or something so thank you next slide robert again i just want to remind everybody that that the big data program workshop is coming up in the next couple of weeks. Please do go and register at nimble.org. And if you can, please join us in person. But if not, join us virtually. And even if it's just for the session that you're an SME in, we would really appreciate your input into the workshop. Next slide. So again, there will be a survey sent out after this after the webinar. Please fill out the survey. We value the information we collect from the surveys. And one carrot for filling out the survey is that you will get immediate access to this webinar recording. I would also like to remind everybody that there's another nimble webinar coming up on vaccine manufacturing initiative. It's next Wednesday, March 8th at the same time. And then next. So again, thank you to everybody. Thanks for attending. And again, if you need any, if you need any more information or need anything from the big data program, please reach out to me. My email is in this presentation that you'll have access to. Okay, thank you and thank you Robert for doing a great job. Take care everybody.
NIIMBL Big Data Biomanufacturing Process Ontology Webinar (March 1, 2023)
Create “standard ontologies” and drive adoption within Biopharmaceutical community to enable sharing within and between different enterprises to reduce time spent in tacit knowledge transfer and support digitization initiatives. Develop reusable and extendable modular ontologies to enable future use cases with version control and support stable enterprise system lifecycle management.