 So, let's get started here. So again, welcome to the NIPL webinar series. This webinar is going to be on open sourcing biopharmaceutical manufacturing ontology. Next slide please. So, let's take care of a couple housekeeping items here. Some webinar details are the. All those who are participating in the webinar will be muted throughout the presentation. So please use the chat function. To ask any questions or post a comment, this webinar will be recorded. And then, as a confidentiality. Reminder, the webinar is open to members and members. So, please do not post a nimble confidential or proprietary information in the chat or the. The Q and a next slide. So, now I would like to introduce Dr. Roger Hart. So Dr. Hart joins Nimble with 30 years of experience in the biopharmaceutical field, having focused on the process development spanning preclinical molecular or molecule selection through commercial. Go back one, 1 slide Roger. So, um. It's the through commercial process implementation and support for protein therapeutics prior to joining nimble. Dr. Hart was the scientific director process development at amgen. Responsible for responsible for external scientific collaborations within the academic interface and external outreach programs to universities and technology incubators. Earlier in his career, he advanced numerous products such as Mavs, peptide bodies, and proteins, and small molecules, as well as technologies. As part of the management and scientific staff at. Amgen and Genentech that the heart received his bachelor's degree in biomedical engineering with a specialty in chemical engineering from University of New Mexico. In 1985, and his masters and PhD in chemical engineering with a specialty in biochemical engineering from Caltech in 1991. With that, welcome again, and I'll hand it over to Roger Hart. Thank you, Jim, for that kind introduction, and welcome to all of you to the open source biopharmaceutical manufacturing ontology. We're here to share that on behalf of the big data program within NIMBLE. We have a vision within the big data program that biopharmaceutical manufacturing is transformed by data-driven technologies which optimize the productivity of biopharmaceutical manufacturing and accelerate the delivery of high-quality medicines to patients. We're joined by numerous organizations representing biopharmaceutical manufacturing, supplying their suppliers, technology development companies, small and medium manufacturers, government entities and the like in order to realize our vision. We're composed of five different work streams, which are aligned with the data lifecycle, which begins with data creation. The work stream for data creation utilizes high-throughput technologies in order to create data, and we're advancing privacy-preserving computing approaches in order to realize benefit from even larger data sets. line sampling and advanced multivaried analytics for a collection of data and transformation of complex signals to extract meaningful attributes. Data storage, which involves establishing data storage standards and analysis standards contextualized for process, raw materials, and quality. Predictions from data, which involves next generation, combined mechanistic, statistical, and hybrid models for biopharmaceutical manufacturing, process development, and other valuable needs. And then ultimately control from data, making difference in the real world. And we have projects there which are utilizing advanced control strategies in order to control critical quality attributes. We'll be talking today specifically about data storage with respect to ontologies. And I mentioned the objectives previously, but the big data, one team is really focused on standardization, contextualization of data to realize both its storage and acquisition and retrieval for valuable purposes. The 2022 goals were focused on developing ontologies for bioreactor harvest and protein A capture, a limited extent of the process. And as a reminder for many, ontologies are semantic information models, which are tailored for domain experts with clear, formal, and natural language definitions and labels. It represents the data domain through entities, their relations to one another, and literal values. The diagram you can see underneath that definition is a data graph, which is actually connecting the different entities by their relationships across the chosen domain. This is an image that's shown from an ontology editor app. And you can see on the left panel the collection of the different domains and classes with which the entities and the representative graph are shown from. So it's a very accessible and user-friendly means to understand a domain using natural language and semantics. Our 2023 goals were to continue to mature and self-develop additional ontologies, and then to prepare to mature using open source software approaches. And for those that are not familiar, effectively in simple terms, open sourcing development entails an originating software which has limited scope and uses as created by an entity, us specifically in Nimble, and made available to a partner through an open license so that the source code is now available for community-guided maturation, utilizing trusted developers with a growing scope of use cases, and utilizing a community-funded, secure platform, which entails a trusted repository with verified functionality to produce software assets that the community can adopt, including the industry, academia, government, and the like, and ultimately customize that software versions for their own uses. And then to mature the resulting software assets using controlled means in order to assure reliability and performance. We've been developing the Nimble Ontology using good ontology development practices, specifically design and develop should happen in the context of real use cases. This is real world values. And the example that we started with was to examine the impact of raw materials on process behaviors. That is to connect the raw material process intermediate lineage across runs to analyze the effect of the material on the process performance. We did that using comparative analysis wherein we could aggregate and analyze data across many runs within a process or across scales to support trend analysis of process parameters high value cases, and we anticipate advancing those within the open source development format. Additional ontology development principles that we embodied utilize maximizing the extensibility and interoperability to layered ontology architecture, making use of upper-level, high-value, interoperable, domain-independent, and domain-and-source ontologies, which exists to ensure interoperability among our domain with other existing ontologies, and to utilize focused ontology development practices with real data schemas and real competency questions. That would be an example of, for instance, an instance within a site or a plant, and to align with upper-level ontology frameworks which ensure interoperability among ontologies. This is exemplified within the nimble ontology, which is organized around IS-88 and 95 concepts, contains things such as the recipe components, critical process parameters and attributes, equipment control, strategy materials, and the like. And that this then supports additional sub domain or other use case extensions to allow very deep articulation of the semantics for particular additional use cases. This nimble ontology then provides a core modeling framework for cell line development, upstream process, and downstream process. It provides initial terms for end-to-end processes and a framework for future use case extensions I mentioned for additional detailed use cases. And in terms of the alignment with upper ontologies, we're connected to the industrial ontology's core foundation ontology, which contains concepts such as plan specifications and manufacturing processes. Additionally, to a highly utilized domain ontology for quantities, units, dimensions, and types so that the articulation and descriptions of the measures of things is aligned across many different ontologies. And then the whole of these ontologies are aligned with the basic formal ontology, which represents the key for interoperability among ontologies as it contains concepts such as continuant, which are things that are continuously present. They're not time dependent. They're independent concepts such as materials or dependent such as quality, but they're not time dependent. And then a current, which do relate to time such as process temporal or spatiotemporal concepts. So all of these ontologies are then are connected to one another using good domain practices in order to ensure that we have coverage and interoperability. Additional development principles were ontology development requires coordination and of design and application. In order to really ensure maturation for the value of the whole of the community, we've been preparing ourselves to launch open source ontology, which you'll hear more about, by taking our ontology and applying a variety of different practices in order to prepare them, including, for instance, modularization. Modulization is needed for ontologies in terms of publication, release, validation, maintenance, reuse, all the kinds of things that one would think of in terms of lifecycle management. And within that modularization, we applied, again, the design space concepts related to IS-88 and 95 specifications, and modules designed and scoped in order to achieve encapsulation, independence from one another, and completeness. The Nimble ontology was partitioned into those designed modules, and then relevant concepts were extracted from other existing ontologies in order to complete the modularization. A maturity rubric was developed in order to guide the release of completed modules to ensure achievement of needed attributes for users. Examples of these maturity include, for instance, annotation consistency, quality with respect to cohesion or richness of the representation in the domain coverage, and to assure interoperability through intermodule connectedness and lack of term redundancy within the portfolio of ontologies, ultimately to evaluate the performance for the ontologies for the specified use cases with competency questions. And then finally, for the specified use cases with competency questions. And then finally, to identify new use cases so that we have a good understanding of what was the ultimate scope and content associated with the biomanufacturing ontology and collecting these use cases from the community in order to ensure a common understanding of the domains and how are they are interoperated within companies. So we've defined and prioritized anticipated use cases and uses for the ontology from a portfolio perspective, and we've defined the expected level of user versus system interoperability and the frequency of module and module cluster uses within the various use cases. All of this preparation has really been focused on developing us an ontology which can be matured very reliably in open source contact. What you're seeing here is a depiction of the modularization scheme associated with the nimble biopharmaceutical manufacturing ontology. The various concepts are modules shown by symbols and each of course contains many different classes and many different terms and relationships in order to describe the contents. Specific examples include, for instance, the recipe module, which represents the hierarchical and tempor mature with time during the process of development as it's transformed from a general recipe to a specific instance recipe, which is associated with a specific manufacturing batch. And then the batch production record, which represents all of the records associated with the production to support the quality and analysis of batches, identify exceptional batches, determine root cause and analysis of deviations, and detect future quality trends. Additional modules include the physical module, which represents the physical spaces where processing and storage occurs. Spaces are specific and bounded geographic locations which can be hierarchical and embedded. For instance, I'm speaking to you from my office, which is located within my house, which is located within my city. An agent module represents various types of agents, actors, and biopharmaceutical manufacturing. These actors are, correspond to both human actors, operators, analysts, and the like, as well as engineered systems and organizations, because biopharmaceutical manufacturing can, for instance, involve contracted third parties. Additionally, there's a material module which represents material types and their associated properties. Terms for characterizing the material usage in internal operating systems are also included. Examples being, for instance, consumables or process intermediates or final products. And then the material procurement and storage module represents the material tracking and tracing in connection with the process implementation and control. Additionally, equipment module, which represents equipment types and their properties, which exemplified by, for instance, their capabilities and their functions, their types, the stages of their validation and completeness. Then the manufacturing execution module, which represents the actual occur execution of monitoring and or controlling for both laboratory and manufacturing scale. And ultimately, the parameter module, which represents the process intermediate and product quality attributes, process indicators, and process parameters, which, of course, no surprise, are embodied within the recipe module. That illustrates the degree of interconnectedness between these modules, exemplified by process parameters, which were embodied within equipment specification, which is located in specific locations and called out in specific recipes, which utilize, for instance, specific materials such as single-use consumables. There's benefits associated with open source in the ontology. I'd like to take a moment to share those with you. The ecosystem associated with production of biopharmaceutical manufacturers is very complex. We have suppliers, which are composed of business units, which make very many products, which provide then to the manufacturers of biopharmaceuticals, which themselves are composed of many business units and make many products, which is supplied then to customers, which have many business units and distribute and provide many products. We have a many-to-many-to-many relationship. And not surprisingly, the work associated with developing and supporting a many-to-many connections of data scores scales very poorly. The cost associated with those connections tends to scale as N times N minus one. Let's just call it N squared. It's very explosive in terms of the number of connections associated with this type of ecosystem, and well as within a manufacturer as well as within a customer. That makes it very difficult, of course, in order to go about scaling the connections of all of the different concepts associated with the data for use cases within any one of these individual domains. And that hinders, of course, efforts to realize benefits from data, because you need to be able to connect the data in order to address meaningful use cases. The cost associated with one-to-many connections alternatively scales very well. The one-to-many concept is exemplified by this diagram, wherein, for instance, the supplier, the manufacturer, and the customer are all mapped to consensus semantics for integration and translation, exemplified by an ontology. The cost for this type of architecture is dramatically less and scales as two times N, where N is the number of connections, basically mapping to and from a particular concept. Each enterprise benefits individually from having an internal integration translation data model, their own data model. However, each enterprise additionally benefits more if they share a common canonical data model for interoperability among other partners within the community. So the ontology can serve as a high value, as a translator among different enterprises. Development of a consensus ontology requires community collaboration in order to create an asset which everyone calls ours. Open source development lowers the barriers for engagement. It also provides permissive licensing, which also lowers the barriers for adoption of the ontology for use, and for technology providers to create derivative offerings of an added value without associated royalties and impediments. So I think you can see that there's dramatic explosive use of open source derived software such as Python and the like, which now dominates many applications. So our approach for open sourcing first is aligned with our vision, our vision is to have a publicly accessible ontology for the biopharmaceutical manufacturing domain, which is developed using open exchange collaborative participation and community development. The source codes is shared with permissive licenses to enable users to modify it for their specialized uses and to be matured by managed governance to ensure security and change control. Industry, government, and academic SME use the code and contributes to its improvement to ensure the project adapts to the needs of the users according to lifecycle management. We, Nimble, are the developer for the initial source code. Ontology source code developed by NIMBLE Big Data Program is a source code or transferred to an open source partner via licensing, permissive licensing, to create the initial product offering. Developers with collaboration control, a semi-centralized balanced operating models used whereby governance committee composed of funding source representatives and invited experts authorize new developments and approve software releases according to maturity rubrics that I mentioned before. And developers from the community can be part of the core developer team after completing training or proving themselves to be reliable, valuable contributors. All of that development occurs on a trusted repository platform components so that the module ontology files are the core components of the open source project. They are collaboratively developed by the network using other open source programs to lower the cost and ensure easy access platforms such as Protege and GitHub with governance oversight. Extensible programs and platforms will provide core functions and interfaces are used to enable third-party applications and developers to interact with the platform. That provides the opportunity for third parties to create derivative offerings of added value without the impediment of royalties. Then the ontologies are made available to and distributed. The open source project is a non-commercial and non-profit. All revenues are used to sustain the project. Permissive licenses for the open source code hold minimal restrictions on how the software can be used, modified, or redistributed, specifically, for instance, an MIT license. Then that offers the availability of the ontology and the software to the primary users for profit businesses, for nonprofit businesses, for government organizations, and the like. Academic customers are considered key contributors to the development and maturation of the free offering. Primary value derives from functional use of the ontologies by enterprises, and key users of the ontology include software developers, software system integrators, and knowledge engineers who create the informatics tools to support end users within their enterprises. And, of course, this middle section is a managed collaborative effort, which is hosted on an external platform with a low cost profile from nonprofit. It's funded by a sponsorship model with governance for quality oversight to ensure that there's also means for lifecycle management improvement to address and resolve errors. Our approach for open sourcing is to utilize the Biomanufacturing Industrial Council, which was created for open reference ontologies for biopharmaceutical manufacturing. It's composed of the nimble seeded biopharmaceutical manufacturing ontologies. It has a sponsorship model, which I'll describe more in a little bit, and it has governance teams associated with it, a governance model, a technical board, a technical oversight board, and working groups in order to create more biopharmaceutical manufacturing domain-specific ontologies, which are all interoperable with the original seeded biomanufacturing ontologies. The Biopharmaceutical Manufacturing Council is embedded within the Industrial Ontologies Foundry, which works with government, industry, academic, and standards organizations to create open reference ontologies that span the domain of digital manufacturing. The IOF has ontology development policies and practices. It maintains a digital platform for the maturation and automated management of ontologies, and itself is composed of a governance board, a technical oversight board, and working groups, all of which is then located within the Open Access Group, which is a U.S.-based nonprofit standards organization established in 1995 for the purpose of addressing international standards for data, and it maintains permissive licenses and is a nonprofit organization, which maintains nonprofit status and provides revenue or provides monetary resources for the maintenance of and management of the IOF and the BMIC. In terms of the operating model, as I mentioned, the IOF is composed of a governance board, technical oversight board, and the working group. Well, similarly, the Biopharmaceutical Manufacturing Industry Council also has a governance board, a technical oversight board, and working groups, so that this is a semi-autonomous operating model, which utilizes collaborative principles in order to assure good development practices. Specifically, the biopharmaceutical manufacturing ontology will be developed within the Biopharmaceutical Manufacturing Industrial Council. And relationships between ontologies developed within IOF and those within the BMIC will exist and they will be managed to ensure that there's no redundancy and all ontologies are interoperable. The demarcation between the reference ontologies and the application-specific ontologies, extensions for specific applications, will be collectively established and maintained and managed. It's important to understand that there is domains of overlap between ontologies, and it's necessary to manage them to ensure interoperability and avoid redundancy. An illustration of that is simply shown below. The IOF ontologies currently contain ontologies in relation to material science and systems engineering, which clearly have importance of biopharmaceutical manufacturing industry council extensions in relation to materials and equipment, which contain concepts and semantics, which are very specific for biopharmaceutical manufacturing. This shows the instance of hierarchy. It also shows that there would be a high degree of interoperability alignment that occurs owing to the collaborative nature of the operating model devised. So, NIMBLE will continue to operate in partnership with IOF using a sponsorship model. Ontologies will be created, released, distributed, and matured within IOF. And there's benefits associated with membership of IOF. I'm joining IOF. I hope you do too as well. By being a member of the IOF, any biopharmaceutical industry council member has the right to join any IOF working group. There's a lot of different working groups working in a lot of different ontologies of high value for your enterprise. Things as, for instance, maintenance, things as, for instance, procurement and purchasing, all which are endemic and extensible across all industries. Those types of ontologies are being developed and maintained within IOF as we speak. Similarly, any IOF expert has the right to join any BIC working group. Well, that's highly valuable because there's a high degree of expertise presently in IOF, and this cross-fertilization of teams helps to ensure that there's a high degree of alignment to ensure interoperability and avoid redundancy. The Governance Board and the Technical Oversight Board within the biopharmaceutical manufacturing can form any working group or technical group that they deem necessary. And the working groups develop the ontologies. So you can be part of that development process by being part of the working groups by being a member of IOF. The technical oversight groups develop technical contents other than ontologies, for instance, software that can help with the ingestion and use of ontologies. Nimble will be working with IOF specifically through the sponsorship model. We will identify use cases and identify how those interoperate within the BMIC modules and the IOF ontologies that are existing. We will develop those use cases with competency questions and ensure the high quality delivery of that ontology asset, including, for instance, including a member assessment of the ontologies to ensure that it's fit for the intended purpose. That sponsorship model is available because when we created the Biopharmaceutical Manufacturing Institute Council, we created it with a sponsorship model. As a result of that, any IOF member has the right to finance a project which will be beneficial to the Biopharmaceutical Manufacturing Internal Council or the IOF. The party member providing the sponsorship has the right to set the scope of the utilization of the given funds. It's not just transfer funds, it's specification of how the support will be used by the funds. Upon determining the objectives, deliverables, and the targeted project timeline of the IOF member should present the plan to the BIC Governance Board to ensure that there's good understanding of the project. And then the IOF or the Governance Board or the BIC Governance Board would then take the responsibility to communicate the information to the appropriate stakeholders to ensure there's no overlap of conflicting work and approve the work if deemed necessary. In the case of a deliverable that's an ontology, it would be subject to the final release procedures and approval by the technical oversight board and the governance boards. In the case of a deliverable that's a report or some type of assessment, then similarly there will be a presentation, the report would be made available to IOF. So this is a depiction then of the opportunity to be able to describe valuable use cases, provide them by a sponsorship model, which contains, for instance, support by data scientists of academics in order to accelerate the creation and support through member, nimble member assessment to ensure that the ontology once developed is fit for purpose against its intended competency questions. And then for those ontologies to be developed within IOF and ultimately released to the community via the open source model. Thank you so much for your attention in this seminar. I hope that you're very interested like I in joining IOF in order to mature these ontologies. Happy to answer any questions that you might have. Yes, Roger, we have a few questions, but I'd like to remind everybody that you can ask a question through the through the chat feature. And I'll read them out to Roger for for the answers. So okay so why don't I get started with a couple questions here. There was a question early on which ontology editor is the team using? Oh well that's good. Well, we have an ANZO derivative that we're using now that we've been using within Nimble, but all of the ontologies have been organized within their modules with RDF files, which can be ingested by Protégé or any number of open source ontology editors. So, if you have one, I'm quite certain that the Nimble ontologies can be ingested and used with your editor. Great. Okay, we have another here. Can you provide a real-world example of how biomanufacturing floor operator or entry-level analyst can help develop these ontologies? And they have a couple of examples like interviews, actual deviations, errors with current processes, et cetera, bottoms up? Well, you answered your own question. Remember, an ontology is a semantic model. Semantics are words. We seek to encapsulate the meaning using the right words and the right relationships associated with different uses and different concepts. Well, the people closest to the work have the best knowledge of the words and their relationships. They're using the words and communicating the concepts all the time. So there are subject matter experts for various domains within your companies that actually have high value owing to their expertise within subject matter expertise within a domain. So for instance, you have quality analysts that are very familiar with the vocabulary associated with quality analysis, the various assays that are used, the nature of the deviation and investigation process. Similarly, you have experts within the material procurement area, which fully understand everything about quarantine of untested materials, the assurance that materials apply within or align with the specifications associated with their use, and all of the policies associated with distributing raw materials for use within the plant. The list goes on and on. The people within your companies, they really understand their domains well and the associated semantics to clearly articulate the work and the concepts involved. I hope that answered your question. Thanks, Roger. We had a couple more come in. So, it sounds like this is a question from somebody. It sounds like the. They sounds like the IOS approaches how you intend to proceed. How do you deal with interoperability with BFO ontologies that says BFO has a lot of standards in order to be accepted and published? Are you planning to meet those? Oh, yes. We're absolutely aligned with BFO standards now, as is all of the IOF. Everything that we build will be aligned with the BFO standards. And for those that don't know, the BFO standards are ones that were created really to help to organize many of the original ontologies that were developed in relation to biology and genomics. Because our space of biology and genomics is actually among the leaders in the creation and adoption of all ontology concepts. An example, for instance, would be the Oboe Foundry, where many of the ontologies related to biology concepts are stored. The Oboe ontologies in their original creation really lacked a tool to be able to help ensure that interoperability, and it is the BFO ontology, which has really closed that gap. So, the BFO ontology is really the key for interoperability among many ontologies. And it's really, to be honest, you know, among the key issues associated with ontology creation is ensure that you're aligned with standards and policies for interoperability. There's a real danger associated with creating isolated silo ontologies. They can work well within their intended domain, but they don't operate well with others. And that is a problem associated with the design. So we've been intentional in our development in a hierarchical manner to ensure that we were aligned with top level ontologies that have maximum interoperability with others. Thank you for the question. Thanks again. So there's been a couple related questions. So I'm just going to kind of compile it into one question. Does a company need to join Nimble or OAGI IOF to have access to biopharmaceutical manufacturing ontology? Oh, thank you for that question. We're pursuing open source principles, so you don't need to be a member of anything to have access to the ontologies that are being created. You would just need to download it from the IOF website and accept the permissive license associated with that download. That's the essence of the open source approach. Lower the barriers for adoption. Make the ontologies available for everybody in order to ensure ingestion and use of an aligned consensus standard. Are there benefits associated with joining IOWF? Well, of course, you can be part of creating future ontology modules. You can influence the type of modules that are being created if you're participating on the governance board, which makes decisions about priorities for different added work. And, of course, you can then bring your subject matter experts so that you can ensure that the ontology that's being created, the consensus standard, aligns well with your own internal practices. Of course, by being a member of NIMBLE, then you can benefit yet further because you can contribute to definition of the sponsor projects, they're sponsored both to incentivize their being done within IOF, but more importantly, they're sponsored with assets to help to ensure that they are created quickly. And that they are created according to the very best practices address all the questions that were asked in terms of alignment associated with the BFO ontology and the like. And their dedicated presence on the project owing to their stipends being paid by through the sponsorship means that there's a greater ability to be able to accelerate the creation of ontology. And then additionally, NIMBLE with its members, we will be evaluating the ontology by applying it in different contexts against the data systems that we have within our enterprises. So we will be testing it to ensure that it is meeting the quality standards that are necessary for us being fit for purpose. So clearly there's a benefit associated with being with Nimble because you can access that sponsorship model with others in order to accelerate the creation of ontologies of value to your company. So I hope that answered the question. Everybody benefits, whether you're a member of anything or not, by simply downloading because we pursued open source. But there's added benefits associated with being either or a member of IOF or NIMBLE. Thank you for the question. Okay, there's a few questions related to this same topic also. And you may have touched on this a little bit already. But with the with the ontology be applicable across different companies across different biopharmaceutical classes of products such as. Biologics, small molecules, those type of things. Oh, that's a very good question. Thank you. I've been intentional to use the term biopharmaceutical. Biopharmaceutical. In our own internal developments, we have been focusing on biologically derived products. But clearly there is a overlap, right? The types of practices, equipment, recipes, et cetera, involved in the formation of synthetic pharmaceuticals is a close cousin to biopharmaceutical products, such as fusion products, which actually contain combinations of small molecules that are conjugated with biologic molecules. So there's actually overlap between the two. So again, it's our intention to develop ontologies within a common environment in order to cover all. Well, we could conceivably develop pharmaceuticals within the biopharmaceutical manufacturing, or if deemed necessary, we could create a pharmaceutical industry council within IOF if it was necessary for there to be independence. I personally think there's a high degree of overlap. I think we could probably incorporate it within biopharmaceutical manufacturing. But having created terms of the ontology concepts that it will embrace. The best way to answer that question or influence that question is to join IOF. I hope that answered the question. Okay, so then another one is, is this ontology available for download now? And let's see. Well, let's start there. Oh, that's a good place to start. We have completed our modularization and transferred all of the ontology data files to IOS. There are ontology experts within IOF that are currently placing those ontology modules onto their GitHub and applying the hygiene principles, et cetera, in order to ensure compliance with the policies of IOF ontologies. And they are doing all that to ensure that they're really compliant with IOF needs. They will place those ontologies in a, I'm trying to remember the right term, a, we'll call it, you know, in process state, and that will be available on the open GitHub for download. It is not in a release state because it hasn the maturation of the ontologies will be within IOF to really take use cases and identify what's the full scope and expanse of the associated modules and complete them to bring them to a state of completeness for release and make them available on the master branch of the IOF GitHub as a released ontology. Thank you. Okay. Let's see. So, if my company already has an ontology, how can I use the Nimble ontology, the Nimble biophineer manufacturing ontology? Oh, well, that's a fine question, too. So, if you already have an ontology, you're already benefiting from ontologies, and you know what the value is. Good for you. Well, you can continue to utilize your ontology within your company. Your company, you know, has invested considerable assets for using it. I would argue that you probably ought to stay the course with your ontology. However, other enterprises don't have your ontology. And so the ability for you to be able to easily query or transfer data from other enterprises, say within the context of procurement of materials or supplies from suppliers, or within the context of transfer of data or recipes for use with contract manufacturing, right? Well other entities don't necessarily have your ontology unless, you know, you did it and created it in collaboration with them. So the consensus ontology that we're creating within the IOF has the opportunity to be the intermediating ontology. That's a way of thinking maybe as a translator. You get two different persons in a room and they don't speak the same language and you have a translator. And suddenly now you have good communication between the two persons. That's a simple metaphor for how the IOF ontology can be used by your company in order to support your data interoperability with other enterprises, wherein you effectively would map your ontology to the IOF ontology, and the partner that you want to translate data with would do the same mapping according to the diagram that I showed earlier, and now you would be using the IOF biopharmaceutical manufacturing ontology as a translator to be able to share and communicate data across your enterprises. Thank you for the question. Great, so maybe just one more quick question, and then we move on to the closeout. So, AFO or Allotrope is a very important ontology in this space. What is the team's approach to working with that and other ontologies that overlapped with or closely associated with this space, what is the team's approach to working with that and other ontologies that overlap with it, with or closely associated with this space? You may have touched a bit on this already, but this is a question that came up. Oh, no, it's an outstanding question. So, you know, we're urging portions of the Allotrope Foundation ontology that were specifically made open source and available to the community, right? We're utilizing what available open source ontology assets are available. Allotrope has a large amount of ontologies in my past history. I've worked with them and others, right? In order to help create ontologies. And so there's a lot of valuable ontology concepts that are out there. It's my hope that we can all work together because for instance, the Nimble ontologies were transferred to IOF via a data transfer mechanism that could be used by others. We have a sponsorship model that's not limited to Nimble. As you heard from what I read, it's available to everybody. IOF could sponsor creation of ontologies. Excuse me. Allotrope could sponsor creation of ontologies within IOF. Similarly, Nimble transferred its ontology assets to IOF by a permissive license. Well, Allotrope could do the same thing so that the valuable Allotrope ontologies that are available could now be joined with the other ontologies and we could be using IOF as a central repository to ensure interoperability, reliability, and make them all available as a portfolio of ontologies for download and use by the community. So in short answer, there's, you know, certain concepts that are mapped that were available because they're open source, as are other ontologies not created by Nimble or the, you know, BFO related. So, yes, I highly encourage collaboration among all the different parties that are creating ontologies. I believe IOF is the way to do that. And I would encourage people with questions to speak with their partners that they're working with to develop ontologies and start a conversation to see how it is that we can provide opportunities to really link and join these valuable ontologies. Thank you very much for that question. Great. Thank you, Roger. So we had a couple people ask about the availability of this recording. So I'll field that one um and then we'll move on to the close out uh so the recording will be available and uh it'll be available in a week or two uh on the nimble uh portal so please please go over to there to access this recording in the in the very short term or near future. So, okay, thank you. Next slide, please, Roger. So, I'd like to remind everybody that you could follow the Big Data program, which is where the zontologies were developed or any other projects within nimble by going into the portal and and then navigating to the program or project you're interested in and and clicking on the follow button right there whenever updates will be added to the to the portal you'll get an email once only once a week um that there's been an update and you can navigate to the portal with a with a link from that email so uh next slide please roger so like that let everybody know that the next webinar is march 27th at noon Eastern, and it's going to be related to evaluating next-gen sequencing as an alternative method for replacing the in vivo and in vitro adventitious virus detection assays. And it's being presented by Dr. Khan from FDA. And you can go to nimble. Events to get more information about that. Next, and as a reminder, the, the national meeting for nimble is fast approaching. It's coming up in June 25th through the 27th in Washington, DC. And this, this national meeting is open to members of NIMBL as well as federal stakeholders. Registration will be opening in a couple weeks in April. Again, you can go to the NIMBL portal to get more information or follow this nimblenationalmeeting.org. Next slide. And for those that are interested, there's still time to register to attend the U.S. Biopharma Workforce Partnership Conference, which is going to be taking place in Boston April 17th through the 18th. Again, navigate to the Nimble portal and go to the events area. So, to register next slide. And so we'd like to thank everybody for for attending the webinar as well as asking such such great questions. Thank you. Thank you all.
Open-source Biopharmaceutical Manufacturing Ontology Webinar (March 20, 2024)
NIIMBL's Roger Hart will provide an update on the development of the Biopharmaceutical Manufacturing Ontology (BPMO) platform. The BPMO will define the properties and relationships of concepts, enabling data engineers to efficiently capture and more readily access and transfer relevant data about the process. The opensource platform will ensure broad access across the industry and allow for continued modifications and expansion. The BPMO promises to be a game-changer as our industry looks to use data to gain deeper insights into manufacturing processes.