 I'm Nicole Vasilevsky and I'll be co-presenting with my colleague here, Pete. We'll be talking today about a tool that we're building that enables us to build oncologies. So this is me in the center of the center and the center of the chasm of semantic despair. So I'm a biologist and I work at OHSU in a group where we are trying to aggregate data across this translation of slides where we're aggregating data from basic science and research and clinical practice in order to make it more interoperable. And we are faced with a lot of challenges of thinking data interoperable because the basic science and clinical practice, there's a little overlap with the kinds of data that are produced, the reasons why they're produced, and the ways in which they are modeled. So we are trying to create efforts to align these disparate tanks of data to make them more interoperable, discoverable, and reusable by building ontologies to structure this knowledge. So what are ontologies? So ontology is defined, or can be defined, as a knowledge classification comprised of terms that are formally defined and logically related. So to give you an example of ontology, say we were going to create an ontology around a particular domain or knowledge base. Let's use the example with beer. So if we had an ontology of beer, beer would be our upper level class and then we would have such types of beer. So ontology is a subclass classification where a light beer is a type of beer or a dark beer is a type of beer. And then you'd have other subclasses of each upper level class so we'd have types of light beer, could be pulmonary and loggers, and a type of dark beer could be a quarter or a sub. So this is just a very simple example of a type of ontology. I don't know of a beer ontology that actually exists, but we usually don't talk for hours so you can build one. So ontologies are used in many different applications. I think from Amazon to shop for books, other types of items, or to structure ontology data sets to describe the actual Amazon main course. So ontologies are expressed in a formal language. One example of this is the web ontology language which uses the acronym OWL and not whole. And when it asked why it is it, they said, why not make an inconsistent, at least one aspect of language which is all about consistency? So using the OWL language, we can model ontologies using complex logic. And this is a reference to a talk yesterday where I discussed an ontology about swans coined as the swantology. So if I wanted to make a swantology, I could model the WNS swans using this logic and relationships between the classes of swans. So I could use the NCBI taxonomy to classify the different types of swans, like swans are type of birds, and there's different subclasses of swans, like tender swans or black swans. And then we can relate the swans to the different types of anatomical features that they have using the Uber Anatomy ontology known as Uberon. So swans have a feed that are capable of biological processes like swimming behavior. So this is just an example of a complex logic that's used to model ontologies. And this logic is modeled using ontology languages like OWL. The ontologies can be used to integrate diverse data sets post hoc. So this is an example of some of the work that we do in our group at OHSU where we try to aggregate data about model organisms and databases for informing rare disease diagnoses. So we take diverse data sets such as genes or mechanisms and phenotypes. And then the data sets are annotated to the data sets come from disparate sources and then are annotated to disparate ontologies. And we've created these unifying ontologies that can aggregate these annotated data. And then we can take this data corpus and analyze it with various tools that we have that are part of our project, the Monarch Initiative. One of the biggest challenges with using ontologies and building ontologies is that there's a really steep learning curve for building ontologies. So a lot of ontology development requires specialized tools and expertise in order to build ontologies. So it makes it less accessible for domain experts to be able to contribute to ontologies. A lot of times domain experts are the people who need to be crazy intelligent and they understand the domain a lot of cases better than the actual ontology builders. So we want domain experts to be able to contribute to and develop ontologies, but we need to provide tools to the community that are easier to use the amount of tools that are currently available. So as part of our project, we are trying to build a new type of ontology tool, which currently is under development and doesn't have a proper name yet. So we're calling it the Table Editor for now. They don't have these suggestions, we're open to suggestions. And so we want the Table Editor to allow users to attest their concepts easily without having to use the current tool that are available, that are difficult to learn to use and to implement. We want the Table Editor to be familiar and easy to use, so a table-based editing, or especially format is accessible for most people. And we want the Table Editor to ensure that it has clean-linked data in a standardized format. So I'm going to share some features with you about the Table Editor. Like I said, it's under development, so it's not quite available. It's full, full functionality yet. But some of the features that we are really interested in are it will be deployed as a static website, so it'll be available online where anyone can go and access it. They can view an edited online, a specially formatted data, and it'll also integrate underlying ontology, so users can auto-complete and select from the semantic-based and standard ontology fictionaries. It'll be in support of formats both tab-separated values and comma-separated values, which in the software documentation will be thought to be referred to as an XSB file. And the complexity of the ontology logic will be captured by using these new patterns, which we're calling dead-simple ontology design patterns. And like OWL, the acronym is backwards. It's also developed by our colleague, David of Sydney-Solom, so the initials are also integrated into our acronym. So using the dead-simple design patterns, these allow us to specify the OWL design patterns behind the scenes, and then be integrated into the spreadsheet, which I'll show you shortly. With the patterns, I already have a format that can be converted into JSON. And we can use these patterns to generate documentation about how the logical definitions should be written for specific classes of terms. We can use it to generate new terms. So if we have a class of terms like abnormal morphology, we can have one pattern, and then quickly generate new terms using these patterns. We can also interpret old terms. One of our aims in our ontology development in our unified ontologies is to try to have interoperability between the ontologies. So these patterns can be used to write different terms to make the ontologies consistent and line with each other. And also, once we have a pattern, we can use this. We can reuse the patterns for the ontologies again to make the ontologies align and consistent. So I'll give you an example of how we can use these design patterns to create an ontology. So let's pretend we're still working on our bare ontology. So if we're building a bare ontology, we want to classify different types of fears that exist in the world. So let's start by building one class of that. So in an ontology, we always have a name for the class. We define the class textually and logically. So we have to name a beer. My favorite beer is India pale ale. So that will be the name that we'll use. And I'll have this in an IPA, which is more commonly known by. You're going to text definition, which is just a definition I got from Wikipedia, which is a happy beer within the bottom category of a pale ale. But if we wanted to logically define the attributes of an IPA, we would logically define the class using terms from other ontologies, rather ontological terms. So in the boxes here, I have listed some different attributes for other ontologies or other ontology classes that we can use to define, to logically define the beer. So I want to ask you, the audience, how would you logically define an IPA? So picking one term for each of these lists, which ones would you say? So IPA has much color. Pale. Yeah. And IPA is an idea. IPA is a copy. So I'd hire the IPA, which is more better. I would portlet 80 to 100. Right? Yeah. Just saying. Yeah, so for one source, I would have said 60 to 80. Right. Yeah, maybe the double IPA is 80 to 100. And does anyone know what type of use IPA is? They use the saccharomyces, same as DCA. So in the logical definition, we could build, we would use these ontology terms to build a logical definition. And we'll show you the table over there. We'll let you pick from a list of these terms in order to easily build a logical definition without downing the actual ALLE language. But what if we needed to add some other attributes to define our beers? So beers aren't only defined by color and yeast and yeast. Especially if you're drinking the beard beer, which is brewed by Rosemary Karen Orgen, which actually contains yeast that was found in the room master's beer. So in the beard beer, we had to classify this beer by the color, which is a pale ale. Apparently, non-bear coffee beer has IB use of 15 to 25. It's brewed from beer yeast, and it contains an anatomical feature, which you may not normally think to include in your beer, but in this case, you have to include it if it comes from the beer. So if you want to try the beer beer, it's available from us, which I haven't found just on history here. So the table editor will have something like this where the users will be, they'll be on the website. The users will be able to go into the website and add the names of their beers or whatever classes they want to include. And then they'll be able to go to a pick list and the terms will be constrained by the design patterns. So if you want to add the color to the beer, you'll be constrained to the colors that are included by the patterns. So in our cases, we have pale or dark or other kinds of patterns that are great, or twice as many included above. We can specify the taxonomy. So it comes from these different types of yeast strains that are used to prevent the beer. And in this case, if we have a beer beer, it includes an anatomical feature. So this is a very simple table editor that maybe users will use. And then the design patterns in the background will generate the ontology concepts from the spreadsheet. So we have this structure to go to the background and this is what the ontology model will look like. So we have beer classified as an American wild ale, which is the type of pale ale. We have colors coming from the quality ontology pay-doh. This is phenocytic attributes ontology. So the colors are coming from an ontology. We can include different yeast strains from the CVI taxonomy, et cetera. So this is what the actual mapping looks like for the patterns. So we can build these patterns to specify different types of classes of terms. And then these can be, this is what will run in the background of table editor and the users will just see the table editor. But these patterns will drive the classification and development of the ontology terms and definitions. So for the scope of the pattern, so we have the pattern name given by pattern name. This will be a beer type pattern. So we specify the classes that are used to build the logical definition to colorize the bitterness, yeast strains, and ontologies. How many of them is different ontologies? We define the relationships between these terms and then we have the kind of variables that we can use to build the patterns. And then we can have the pattern actually build the labels of the, the labels, the synonyms, and the text definitions, as well as the logical definitions. So if we had this term, this variable color, we can have it automatically create the label, which is the color and the pale ale. Give it synonyms, say specifying that they want it to be an ontological entity or the word ale. Then we can say the synonyms to be structurally like so. We can structure the text definitions by using different variables. And also we can develop the equivalence axioms based on these patterns here. And so we can use this table editor to build these patterns based on these patterns that are running in the background. And Dan here is going to talk to you about the technical architecture of how the team will edit various belts. Hello. Yeah, this is mostly the architectural diagram. Ultimately the code is designed to be just a bunch of static assets, which we, which makes it very easy to deploy in a light way. But then the app that the user experiences pulls from various ontologies that are already in the world. In this case, I wrote those as the shared ontologies so also the editor, the user would either start with no original CSV or they have an existing CSV which represented their subset of the ontology. They would bring it into the table editor. They would either add rows or edit rows. And as they did that, it would be constrained by the patterns and the ontologies. And then they would emit a new data file which would be the updated CSV. Behind the scenes, we also have the option of generating new OWL files that we can inject back into the ontology so that the next person that comes along now sees these new classes of beers that they can then relate the stuff to. And this is just a quick demo to show that the code is working. In this case, I'm actually selecting from a list of patterns that are canned. I think I'm going to end up choosing the beer, yeast, anatomy example. Nicole was showing. And then there's other ways to select patterns. You can have a pattern somewhere, have a pattern file somewhere in GitHub and then you can do refer to it. You can drag a pattern file from your desktop. But once you have a pattern file, that sort of sets up the columns that you have available in the edit. So in this case, I selected the beer, yeast, anatomy pattern and now I'm adding a new type of beer. So I'm selecting a paleo, maybe yeast here. And then I'm going to take some random anatomy part. We'll see how that works out. I think I get the internal cheek pouch. So I added auto labels to beer as in the paleo, paleo, beer with Sackerel, Misey, Cider, Misey, from the internal cheek pouch. Beer beer's probably better. And then finally, when we're done, after we've added a few beers, we can export that back to a CSV or behind the scenes we can take that same data and pattern and generate an updated auto file that we can inject into our ontology database. And that leaves it for me. So like we demonstrated here, we can use the table editor to contribute to and I said there's missing ontologies. So we can build these patterns so we can add new terms to ontologies based on patterns that are already used or we can use the table editor to create new ontologies. And we didn't show an example today, but we also can use the table editor for data curation so we can specify different columns and then have ontology drop-down lists and different columns that you can structure or you can map terms to autological terms to make data more structured. And all of this is available on the GitHub site here, and I'd like to thank our team, Mohsen Handel at RHSU with the dark group, Chris Mungle and Peter Robinson there. The co-pia is on the modern commission of Jill and Nukhari at RHSU. David O'Simmons in Southernland is the one who developed the design patterns and Jim Bellhop has been helping with this as well. And thank you very much for listening. Please feel free to email us or tweet to us for more information. And our group may be hiring in the future, so please contact us if you're interested in working out tools like this. And just email to infoatmoticinitiative.org. Thanks very much and we'll take any questions. Thank you.