 I'm pleased to be introducing Maria Stoika, who's going to give the seminar today on the scientific variables ontology for the webinar. And I first hired Maria to work with me at CU back in, it was end of December, or December, 2015. And she was one of several candidates, but by far the best applicant for this position, overqualified, but she has a PhD in environmental, energy environmental and chemical engineering, but she had an interest in doing scientific programming type of work and had taken lots of Coursera courses that were very impressive. And so she was a good fit for this position. And ever since we've been working together and she's been on several EarthCube projects with me and one DARPA project, continuing to work mostly on that scientific variables ontology. And for those of you, she'll explain this, I'm sure, but this started with work on the CSDMS standard names that I initiated some time ago. And we wanted to formalize that into an official ontology that was more compatible with state-of-the-art ways of doing ontologies. And so that's what she's been doing for these number of years, mostly. And it's been fantastic. It's been really great working with her. And in 2018, she was promoted to research associate so she can start bringing in grants on her own if she so chooses. And then she's also was asked, which is kind of an honor. She was asked to co-chair the Research Data Alliance Iadopt working group, which has taken some of the ideas from the scientific variables ontology into their ontology. So they've been inspired by our work to try to describe variables and that's being used by them. And so without further ado, I will let Maria take over. Thank you so much, Scott. And thank you so much CSDMS for having me present our work on SVO. I was going to say, I think Scott was breaking up for me during the introduction a little bit. So I wanted to wave and say hi so you all can see what I look like, but I will turn my video off just because I wanna make sure that you can hear what I'm saying because that's more important than my face. So without further ado, let me share my screen. All right. So you can see I did a very quick, simple edit to the title of the talk today. And that was because the original title was supposed to be a simple introduction to the scientific variables ontology, but I decided the word gentle was a little bit more appropriate. And that's because as you'll see, SVO is a solution to quite a complex problem in many ways. And so SVO is not really simple because it can't really be. It's a very complex problem. However, I'm going to make this a very gentle introduction. I will try not to go too much into the technical details or spend too much time on very ontological definitions. And I'll try to do as many examples, concrete examples that hopefully you all can relate to. So yeah, so let's get started. So a little bit of background, if you're affiliated with CSDMS, it's very likely that you do computational work in the sciences. And you're familiar with the fact that computational work in the sciences requires electronic resources such as data and models. Have inputs and outputs. And some of those inputs can come from data sets while others may come directly from the outputs of other models. And this information that is exchanged between these resources that we're interested in are the scientific variables. And in this presentation, I'm going to focus on how do we know that these scientific variables that are passed between data sets and models, how do we know what they really are? What are the concepts that these scientific variables represent? So I will not be focusing on how these variables are collected or how they're stored, what the format of files is or what the structure of those files is. We're purely interested in the concepts represented by the scientific variables. And the problem of interoperability that arises is from this question of how do you know if a resource is appropriate to use as an input to a model? And conversely, if you've created a resource and you want to share it with others, how do others know that your resource might be the resource that they need? And so metadata provides a good solution to this. And in case you're not familiar with metadata, metadata is everywhere on the internet. And you can think of metadata as tags that are attached to your electronic resources. They may be embedded inside of the resource or external to the resource. And these tags may contain different types of labels that can essentially summarize what is contained inside your resource. And this summary can be used by search engines such as Google or it can just be used internally in databases or in repositories to index your resources and make them findable. And metadata is great. Well, in some ways, metadata is great. But metadata is not always structured. So sometimes metadata can be found in freeform text. Or, alternately, it may not follow a common set of representation principles across resources. So if a resource, say, uses a standard to represent a scientific variable, it may not be the same standard that another resource may use. So you might be thinking to yourself, well, that means we need a common language for representing scientific variables. Or we could call this a standard. We need a standard that is the mother of all scientific variable standards, right? And in the earth sciences, we do have a lot of standards or, if not necessarily, standards just lists of variables to pick from. So you might be familiar with the USGS NWIS parameter codes or the climate and forecasting standard names. You also have the CSDMS standard names built right here in-house. You also have NASA suite ontologies, the GCMD keywords. And so many more. I'm just popping up here the ones that I'm most familiar with, but I'm sure you know many others. So, and this brings up a really nice quote that I like that has a little bit of humor to it, which is that the great thing about standards is that there are so many to choose from. And the reason this is funny is because the whole point of a standard is that there should really only be one, right? And we should all be able to agree on a standard and all use that one standard. But it's hard for different groups to agree because different groups might need their standards to do different things or to have different functionalities. What I also thought was funny in context of this presentation with this quote is that it was attributed to Grace Hopper or to Andrew Tenenbaum or to a list of other possible attributes. And so even in this quote, people could not agree as to who actually said it. And so what I'm going to be talking to you about today is SVO, which is not, its intent is not to be a standard, which is the mother of all standards. Instead, what it's, what SVO is intended to be is a common language for computers to try to read scientific variables in all different kinds of forms and try to understand what is, what is the intended scientific variable that is being described. And so SVO is developed as a child, if you will, of the CSDMS standard names. And this work was very lengthy and detailed and important and it really highlighted the fact that there are essential components of scientific variables that are common to most standards and that some standards may be missing some components that are essential. Some standards may have extraneous components that are not domain independent and that are maybe not found across a lot of standards. But there are some core concepts with regards to scientific variables that occur or implied again and again and again. And this is what SVO tries to tackle. So SVO encodes these core components in a way that machines can understand. They can say, oh, okay, you're telling me that you're talking about a scientific variable. So I'm going to look for these components because I know that human scientists refer to these components when they're mentioning scientific variables. And so what is SVO exactly? And I tried to distill it down to a couple of sentences but there really are quite a few components to SVO itself. But overall, we think of SVO as a framework for representing scientific variables in a machine readable form. And it's particularly useful in automating computational scientific workflows. And this framework enables what we call modular, principled expression manipulation and creation of scientific variable concepts. And so the components of SVO that allow all this functionality are outlined here. And the first one is an upper ontology which essentially just defines a set of elementary concept categories. Some might use the term atomistic and some of these primary ones are the property, the phenomenon, or the process. And these are used to build complex scientific variables. So these concept categories, you can think of them as ways to classify your terminology. And secondly, there are also a set of design patterns that allow you to combine these elementary or atomistic classes to create more complex concepts and thus also more complex variables. And because the design patterns are reduced to be a simple set of design patterns, just it's under 10 design patterns that you can use to represent the different components and combinations in scientific variables with SVO, that can turn out to create quite bulky representations of variables. And so what we've also introduced is a set of rules that can be used to infer relationships between atomistic components that might be chained together across multiple relationships. And this can be used to condense down the representation to a simpler representation which will result in more diverse relationships between entities. But it allows the simpler representation that is more easily searchable. We also have an extensible lower ontology that contains the domain-specific instances of the classes defined in the upper ontology. And so one thing, you can think of this as basically just the terminology that you're using to define your variables. And one thing that I want to emphasize here is that SVO does not consider itself an authority in what terms you should use. And we do currently encourage pointing to external resources that define these instances in the lower ontology. We prefer to use Wikipedia and Wikidata because it can be editable by anyone. But you could also, of course, link to official ontologies. And we do allow creating a stub or a placeholder if you are not able to find a definition in an external ontology. But again, we do not define that term for you. And lastly, we have three tools that you can use with SVO. The first is to search for existing variables that are already represented in the ontology. So we have indexed a lot of the climate and forecasting variables as well as the CSDMS standard names and the NWES parameter codes into SVO forms. So those are available for you to search. We also have a tool for comparing the existing variables that are represented and determining whether they are similar and in what ways they might differ. And we're also working on a tool for guided creation of new variables from freeform text. So I'm just going to dive right in. I don't want to spend too much time on the nitty-gritty details. I'm just going to dive right in on the major SVO design patterns and the first one, which is probably the most important one, which is derived from the CSDMS standard names, is this idea that any scientific variable should be able to be decomposed into two distinct components. The first is the object of observation, which we call the phenomenon, and the second is the property, which inheres in that phenomenon. And in addition, when you have a quantitative property, that property may be defined with respect to a reference, and in that situation, the reference is required as well. So diving deeper into these two core components, the phenomenon and the property, there are in essence two types of phenomena, but the phenomenon at large is a four dimensional entity. So it has spatial aspects and temporal aspects, but a static phenomenon, which can be thought of as an object or a body. Here I've put up the very ontological definition, which we're not going to get into the details of that, but it's official definition as an independent concrete entity, which can be or is observed to exist or happen. Here I'm essentially just showing the design pattern for what you can think of as an object or a body, which is a static phenomenon, which does not necessarily involve a process, but to which you can attach different attributes so you can specify it at a highly granular level. And an attribute is simply a property value pair, and we do also provide some shorthand notation for the certain attributes that occur again and again and again, such as form, matter, role, and parts. We are going to give some examples, so don't worry too much about what each of these is. And now, as I mentioned before, there are also dynamic phenomena. So these are phenomena that involve processes. And for phenomena that involve processes, the design pattern is a bit different and it involves what we call participants, which are other phenomena. So again, these may be objects or more complex phenomena. And these participants, as they participate in the process, this process may also have a trajectory. So going to the property, the property is a characteristic of the object of interest of the scientific variable. And one of the things about the property is that its existence is not independent. Its existence depends on the phenomenon that it inheres in. And so here you can see some of the relationships between a property and some of the other entities in the ontology. And for quantitative properties, we know that a quantitative property may have dimensions. Quantitative property may also be operated on by some mathematical operation or transformation. It may also have a property type, and this means things like if it's a vector or a scalar. And in addition to this, a property may also pertain to what we call an abstraction, but you can think of this as a mathematical model for a phenomenon. And in that context, a property may also have a property role, such as being an exponent or a parameter. So here we're going to look at some examples. We've talked a lot about the theoretical, but what are some examples of scientific variables? Well, they can be very simple. You could have something like the height of a tree or the shape of an organism. Or you could have the solubility of carbon dioxide in water, where you have two target phenomena that you're looking at. You could be looking at the low level of chemical oxygen demand in unfiltered water. Or something more complex, like the time integral of the volume flux of water infiltrating the soil surface. Or lastly, you can have this very complicated one that I will not read. But I hope that you can see, as I've been talking about these different components of a scientific variable, that no matter how complex, if you study these descriptions enough, you can see that you can actually divide these descriptions into an object of interest and a corresponding property. So here are some examples of an object of interest. Again, we start with the simpler ones. And we build our way up to much more complicated ones. And we have phenomena that are static. So they're just like we can think of them as objects or bodies. And we have phenomena that involve processes. So they're dynamic. And we also have phenomena that include a lot of other information, such as context. And here are some examples of properties. We have qualitative properties such as shape, quantitative vector properties such as velocity. Properties that may be properties between two different objects, such as the sun and the moon. Sorry, the earth and the moon. We have electrical conductivity, molar concentration, which is the property of some entity and another entity. And we have coverage severity code, which is a sort of, you could think of it as a pseudo quantification of a qualitative property. We can have properties that are transformed by mathematical operations. But all in all, these are all properties. Here I'm showing just a few examples, one from CSCMS, one from the CF standard names and one from CSCMS. And here are some examples of how they're decomposed into their corresponding objective interests or phenomenon and property. And here are some examples of when you have a specific distinct phenomenon, how you could decompose it into its attributes to describe it. So here, for example, you have filtered water, the form is grain and the matter is sand or the bottom of the atmosphere. Furthermore, here, the previous, the ones that I showed on the previous slide were what we call bodies or objects or static phenomena. On this page, I'm showing dynamic phenomena. So these are phenomena that, for example, involve the motion of the earth or turning of fresh water or collection of a bed sediment sample. But again, these can also be decomposed into participants and the corresponding processes. Here, I'm showing some examples of properties and how properties can be decomposed. And the second two here, you can see that there are mathematical operations that act on the corpus. The first one is an interesting example of a property that is associated with a mathematical model of a phenomenon, the Flint law, and that also has a property role in that phenomenon, which is that it is the exponent. So you might remember that I mentioned that for some variables, there may also be a reference to the scientific variables. There may also be a reference required, which is a basis or standard for evaluating the value of the scientific variable. And we do provide a design pattern for decomposing this reference. However, again, just as with everything that I've covered so far, not every decomposition needs to be made. The more decomposition that you can make, the easier it is to understand what the variable is. But in some cases, it may be too tedious to expand this out. And so ultimately, some things may not be expanded out. I also mentioned that some phenomena are complex and you may want to include extra context for the phenomenon of interest. And so this is a design pattern to provide that context. And we'll go over some examples right here on this slide. So here you can see, for example, we might be talking about carbon dioxide from anthropogenic emission. And so the anthropogenic emission is the context in that case. You might be interested in some properties of soil that is five feet below the land surface. And in that case, a five feet below the land surface is the context. In this other more complicated example of the oil slick, you have two contexts that are provided, one that it's onshore and one that it's within 25 feet of the bed sediment sample collection. We also have a participant design pattern, which you might remember that I mentioned when I was talking about phenomena that involve processes. And so when we have a process, it might be necessary to identify for the participant phenomena what their roles are in that process. In addition to that, the participant design pattern also allows us to assign what we call variable roles. And this can help us deduce how a particular phenomenon is used to evaluate the property that's identified in a scientific variable. So if the property refers to multiple phenomena, such as a solute and a solvent, the variable role could help us determine which phenomenon pre-switchable. Here we have some examples of phenomena involving processes and how they might have multiple participants and each participant has a participant role. And again, just because you identify a participant, you do not need to identify a participant role that should really only be identified if it is deemed critical to the scientific variable. And lastly, I just wanted to show you this is really simple. I'm not sure that you could even call it a design pattern. This is just a relationship between a phenomenon and an abstraction. And so this is just a mathematical representation of a phenomenon. And this is just how you would link the two together. And so some examples of this would be that, for example, the temporal decay of aftershocks in a seismic sequence has a mathematical abstraction called the Modified Amory Law where the initiation of motion of sediment in a fluid flow can be described by Schild's formula. And here I also put that the Schild's parameter is the critical parameter in the Schild's formula. And so you can see how that links circularly since the Schild's parameter is a property that is associated with this mathematical model. So we're getting to the end of the presentation. And I just wanted to pop on here our most commonly asked question, which is, this is complicated. And the answer is it is. It really is. I mean, it's a complicated problem. And that is why there are so many standards and so many people out there trying to decide, you know, what's the best way to describe these scientific variables in a way that machines can understand. And I do think that SVO is a great tool for doing this. And we are aiming to automate as much of this process that I've been talking about as possible so that you, as a scientist, do not have to worry about it. It is good to have a basic understanding of what SVO is trying to do because with the automation process, there might be issues in the translation, might have to make corrections. So it's good to understand what's going on under the hood. But that is what we're trying to get to. And in the meantime, what I hope you're getting from this presentation mostly is that it's not so much that we're pushing that it's necessary for you to completely decompose a scientific variable representation down to its very atomistic components. But that I've gotten across the importance of understanding that there are these core components of a scientific variable. So when you do label your resource, if you want to make it accessible to others, I think it's very important to make sure that you're identifying your objective interest of your scientific variable, that you're identifying your property, that if there is a reference for evaluating that property, that you're representing this. Any context that might be important for, you deem important for identifying the scientific variable, that should be identified as well. In the meantime, I do encourage you to check out our new website. We're still updating it, but we have some new content up there. I'm also sharing the GitHub of where the web, because we have this hosted off of GitHub pages. Just in case you want to check that, that would be an easy way to follow when we do make updates to the website. Also, don't hesitate to email us with questions. And in conclusion, I just wanted to say that I think I'm very grateful that Scott gave me the opportunity to work on this project. And I think that SVO has a really good potential for becoming a very powerful language for understanding scientific variables from the perspective of a machine who's trying to read it and is trying to understand resources and make them available to scientists. So with that, thank you for listening to my talk. And I'll take any questions if there aren't. Do I, I see that Leslie has her hand up. How do I, I figured I saw that I finally read the pop-up and understood that I could unmute myself. Hello, Maria. Hi, Leslie. Thanks very much for that gentle introduction. I think you met your goal. Of course I still have questions, but at least I've now seen the overview. And my question is after many years, I can kind of, like if I see a CSDMS standard name, I can kind of look at it and I see the syntax. And I'm like, I think that's a CSDMS standard name. Now with everything you've explained, if I see a scientific variable and how it's actually expressed in plain text, like would I be able to know this is a CSDMS standard name versus a scientific variable, which is richer? Like, could you just explain that a little bit? Yeah, so that is a great question. How are the CSDMS standard names linked to SVO? So, so the CSDMS standard names are essentially strings. They have a chosen vocabulary and they follow the pattern of SVO. So on the back end, SVO and CSDMS are built on the same theory, which is that you decompose a variable in these two components and then each component is further decomposed. The differences that CSDMS standard name is, as I mentioned, it's a string. So you're chaining together these different terms that here, for example, in this last slide that I have that I'm still sharing, you can see how this variable has been decomposed into what we call atomistic components. So an SVO representation of a scientific variable would be this machine-readable cluster or bundle of information and relationships between entities. It would never really be something that you as a user look at. What I would do is that this would be stored as some data structure inside of a computer. And then I would have a translation mechanism that would take these individual atomistic components and it would string them together in a specific sequence based on where they are in this structure that I'm showing on the screen. Does that answer your question? Thank you, host, and sorry for muting myself. Okay, so I unmuted. It does answer my question except, it's complicated. It's a struct, a data structure. I don't know, like I may not be able to look at it as plain text, but then when it's string together, when it's like interpreted and then string together, do I have to know this is a scientific variable from SVO, not a CSDMS standard name, or should I just not think about that? I think you should not think about that. I think what's important for you is to know, is this the scientific variable that describes whatever I'm trying to label? Yeah. Yeah, so this is more the back end. This is so that the computer knows what that scientific variable name stands for. Thank you very much. I'm a very, I can only think of concrete things. So thank you for your explanation. Are there any final questions? This is Scott. I thought I would just add that one way to think about this is this representation is it, I think of it as an RDF bundle. With all this extra detail. But you can serialize that you can, you can make some rule as Maria said to sort of go from that. To just a string that has these parts. And we had a way to do that was with the CSDMS standard names that use different characters like double underscores and Tilda's and, and other symbols hyphens to be able to sort of serialize that. That was one proposed way to do it. But it wasn't possible to infer everything from that string that is captured in this bundle. This bundle is much more rich in terms of describing what, what actually is going on. So you kind of want both. You'd want the machine representation, but you'd also want some kind of a handy string. The human condition reading sort of hopefully say, yeah, that's my variable. And I'd also add a big part of this is disambiguation. There's in science, there's often concepts that are very closely related, but they're not the same thing. And a lot of problems with machine with interaction between resources is people are not specific about what they mean. There's lots of examples like. If you think of heat capacity, if you've got a thermal dynamics class, they have four or five, six different concepts of heat capacity, whether it's isobaric or isochoric or isothermal, and whether it's mass specific or volume specific. So all that has to be captured to fully disambiguate the concept of heat capacity. And that disambiguation until you, until you're sure there's nothing to conflict with, like rain rate, what kind of rain rate is it a volume flux and mass flux. There's lots of ways to talk about rain rates. So which one are you talking about exactly in this resource? So that I just, just throw that out there and hopefully that makes it a little bit more clear. And it looks like there's a question in the chat. Have you by chance represented many of the NWIS parameter codes already as an exercise? Yes. So that was done about, I want to say, two and a half or three years ago is the last time that we pulled the NWIS parameter codes. I said NWIS parameter codes, but there's also something that's called the SRS names, which are closely related to the NWIS parameter codes. And that's actually what we pulled up. But that was several years ago, and I know that they're populating it with more. We don't have some new ones, but we did do the ones that were available about. Three years ago, I want to say. Yeah, and actually that oil slick example that I had provided, it was from that list. Yeah, this is Scott again. One of the reasons for tackling NWIS in the CF convention standard aims early on was to, to make sure that we had a rich collection of existing names that had been already been identified as important. And just using this test cases for, for whether our system could represent all of those. And so both of those standard name collections has a pretty large collection of things. And they're in different contexts. The NWIS stuff is mostly aquatic chemistry, which is more than that. And the CF is mostly climate forecasting variables with the atmosphere and ocean, but they're both large. And so by, by showing that we could take every one of those names and represent it like this was a test that we had enough breadth to, to do whatever might come along. Oh, Risa. Would you like to ask a question? Am I saying the name right? Okay. I didn't know I could unmute myself. Okay. I guess what I'm, I guess what I'm wondering is maybe I'm, I'm not thinking about like the level, the level of this correctly, but like how flexible is it for, for example, for a scientist to, or scientists to, you know, want to like redefine a certain, a certain part of, of something that's going to change other things. Like, like, like a relation, like redefine a relationship. And then that's going to affect how something else is, is defined. But I mean, this is all based on definition anyway. So how, like, where does this stand as a standard in the hierarchy of scientific, you know, practice? Yeah, so that's a really great question. So again, I, SVO does not aim to be a standard. However, what we try to do, and I think if I'm answering, if I'm understanding your question correctly, I think you can see, for example, I have this example up on the screen right now that I think you can see. Because we have this saved as a kind of a bundle data structure. It actually is very flexible in changing. For example, you could just take this representation and you could go from, say this Brachionis organism to a different type of organism. And you would have the exact same representation. And it's just that you would change the genus of the organism that you're talking about. And so having this kind of representation does allow us to swap things and then to insert new design patterns. And we do think that this is very helpful and it's very useful as opposed to a standard name where, you know, you would have to have a group of people coming together and deciding, you know, always this standard name sufficient or do we have to change, you know, and having kind of a discussion about it. So we do believe that this is more flexible in that respect and making small changes. Okay. Thank you. This is Scott again. I'm sorry I keep jumping in, but I keep having thoughts I want to share triggered by these questions. For those of you that haven't ever thought about ontologies before, which included me a few years ago. This diagram in these has all these words to start with has, that's not something we made up. This is following a, some very well established established web standards like the RDF standard from the W3C group and things like SCOS and owl. So there's a, there's a, there are technology standards and ways that are used widely across the internet behind the scenes for representing things about the toaster you might want to buy or, or something you want an airline flight or whatever. And they use exactly these kinds of diagrams under the hood to organize that metadata. But to do it for a new, for whatever area you're thinking about, you need to develop the ontology for that class of things. So, so when you do a faceted search for the best flight, or when you do a faceted search online for the best item you want to buy. Under the hood, there are representations like this, they're allowing the machine to, to help understand what you're looking for and to present things to you in a way that's useful to you. So this is all following very well established standards. We can make up the standards. We're just, we're making the standard names conform to those standards is a way to think about it. Mark. Hey, thanks for the talk. I just wanted to mention something that resonated with me that you just said is like making standard names is kind of hard. I know that I struggled with that over the years and I, I bugged Scott, I bugged you, I bugged Eric. And I like the, the way you, the way you described it in that, you know, the bundle, the data structure is more flexible. And you don't have to have a committee of people sitting around trying to figure out how to construct the standard name. So I just wanted to say that I like that. I like that exact explanation you gave. Thank you. And Leslie, I think. Hi, thanks. I was trying to type it, but I'm a very slow thinker and typer. Okay. This is related to what Mark was just saying. I was wondering if there was an example from a CSDMS model usage in standard name where that standard name was kind of ambiguous. And like, it wasn't enough to describe it all the way so that this concept helped to describe the variable or concept more fully. Yeah, so I think I'm just pulling this off the top of my head. So this is not a super concrete example, but I'm pretty sure this is kind of close. So I believe there were two names that were overlapping. That were one of them was referring to groundwater. And the other one was referring to water. Like in the ground but below the land surface or something like that. It was essentially two things that were referring, both were referring to groundwater. But one was referring to groundwater in terms of. The water being like in the ground. And the other one was referring to it as being water under the land surface. And when we decomposed it this way, what we found was that essentially the water under the land surface, the land surface provides a context. And it being in the ground provides a different context, but they are not contradictory contexts. And so those two names would actually be compatible with each other, but they're just slightly different representations of the same concept, the same scientific variable. Is that does that kind of answer your question that totally answers my question and gives me a concrete example to think of if what, if what I understand of like. Groundwater with a capital G versus just like water under the surface of the earth. That's exactly what I was looking for. Thank you. Yeah. Yeah. This got again, just adding a couple of my favorite examples like some, we learned early on the some. Properties of things involve a pair of objects. And those objects have some relationship to each other. So for instance, a friction factor. Has to talk about two things that are in contact like pavement and rubber. And it's only when you have the two. Participants pavement and rubber identified that, that you haven't been a friction factor defined for those two things. It's impossible to really represent that context. In just a string, you know, it might be sort of intuited from reading the string that if I say concrete rubber friction factor. You might understand that the concrete rubber have to be touching that that's part of the idea, but that touching context is not really clear from the string. Another example is anytime you have a medium where you have one thing in another, like when molten metals mixed together, there's miscibility and there's solubility for things in water or whatever, or there's water in soil. So whenever there's something in something else like a medium or carbon dioxide and water, you can't, you can't fully capture that containment context. Unless you have classes like this, we tried to do it with the order in which the object part, things were represented. So it kind of was a drill down mechanism, but it really wasn't fully adequate for, for those kinds of things. And another one is, is if you, the earth and the moon have a special relationship to each other. And if you want to talk about things involving the two of them together, like the gravitational pull of, you know, the moon on the earth or vice versa. Those are two things that are interacting in the form of unit, but they're not touching and they're not contained. There's no containment and there's no touching, but there's this, still this connection through gravity between these two things. So that the context is really important to try to say, well, how do these two or more objects relate to each other? Is one inside the other? Is one touching the other? Is one pulling on the other? So I think of it a lot like that. Are there any final questions or comments? I have kind of a question for Maria. When you talk about references, we didn't elaborate too much on that, but does that include like, when I think of that, I think about there are certain properties that are only defined if you introduce a mathematical model first. Like if you want to talk about landscape profile curvature, there's an implicit assumption that you can do two derivatives of the landscape, but the landscape is really a not a smooth mathematical surface. So you have to introduce this construct of a twice differentiable surface as a model for the landscape before that becomes defined or for the earth, you have to introduce the concept of an ellipsoid before the semi major axis of the earth is defined, or you have to introduce the concept of a black body before you can talk about the black body temperature of the earth. And so there's these abstractions that you, that are often mathematical or physical like the black body example, but you have to put in place first before the quantity you want to talk about is really defined. Is that the, is that properly handled by the reference category? I think for the ellipsoids, that is more in the abstraction realm. So in that class of category, the reference is more for things like, like specifically quantities that are used to provide, I'm sorry if I don't say this exactly right. They're used to provide a reference point for the measurement of some value of a scientific variable. So for example, altitude is measured with respect to the earth's surface, let's say, or yeah, so things like that. So it's for a concrete quantity. Whereas what you're saying with the ellipsoid and applying a model that would be in the abstraction class, and you could definitely, these are things that are not 100% worked out in SVO at the moment, but I could see how you could link a reference to an abstraction in the sense that a reference would be associated with an abstraction. Yeah. Another one is datums like the mean seeds, which you can define by mean seed level or by other means, but in that case, you're defining a reference of where seed level is. Yeah. Shaped planet or whatever. And but there are more than one, there's more than one way to define a datum or an ellipsoid. Another example I like is a river centerline. Like if you're going to talk about the sinuosity of a river, you have to impose some concept of a centerline, but there really isn't a well-defined centerline to a river. So you have to lay this mathematical concept into the, into that situation before that concept of sinuosity really makes full sense. An abstract abstraction that you said. Well, I think we're getting close to the top of the hour. Thank you so much, Maria and Scott for providing the webinar. We really do appreciate it. And thank you everybody for joining us. We'll go ahead and send you the link to the presentation. It's been recorded and please feel free to circulate it with any colleagues that you think may also benefit from it. Thank you so much.