 make a start. Firstly, as is customary ahead of ARDC webinars, we firstly pause to acknowledge and celebrate the first Australians on whose traditional lands we meet and we pay our respect to elders past, present and emerging. Welcome everyone to today's webinar on Metasat, a reminder that today's webinar is being recorded and will be made available on the ARDC YouTube channel. Backed by the John G. Walbark Library at the Harvard University Centre for Astrophysics and in partnership with the Libra Space Foundation, Metasat provides a vocabulary to describe satellite missions and a set of implementation tools. And as one part of an international engagement governance and community development strategy, Metasat wishes to explore opportunities for community engagement within Australia. Today, we're very fortunate to have Dana and Daniel to discuss Metasat. Dana is head librarian at the Harvard Smithsonian Centre for Astrophysics and Daniel is research fellow and Metasat curator, also based at the Harvard Smithsonian Centre for Astrophysics. With that, I'll pass over to Daniel to share his screen. We'll have presentation and discussion and there'll be time for people to ask questions and make comments later on. Thanks and over to you, Daniel and Dana. Okay, everyone I'm assuming can still hear me all right. So, okay, I see some dots. Thank you for humoring the confirmation. I'm really glad to have the opportunity to speak to you all this evening here and a good morning slash early afternoon to all of you over in Australia. I think that it was really exciting to get, I guess, the suggestion to have this webinar because one of the things like Rowan alluded to that we're trying to do right now is focus on Metasat's international applications and to think really concretely about where we go from here and to make sure we're grounding everything we do with an international perspective and so focusing in on Australia made sense for a couple of reasons and so we'll get to that in a minute but just thank you again for having us and I guess without further ado, next slide, Daniel. So, I guess a little background. So, Rowan gave a short introduction to who we are but I thought that it would be good for us to make it a little more clear where we're coming from and why we're working on them. So, who are we? We're librarians, librarians from training and in Daniel's context he's working mostly as a research fellow on this specific project. He's also a librarian and we're coming from the Center for Astrophysics which is a collaboration between Harvard and the Smithsonian where we serve a community of scholars and scientists and engineers who undertakes both space-based and ground-braced astrophysical research. So, because we're part of both Harvard and part of the Smithsonian, it's not always clear to some people that what we're talking about is not a purely academic community. About three-quarters of the people that our library serves are just locally anyway are actually staff scientists who work on missions funded externally, primarily by NASA but it's not a purely academic context so it's good to make that clear. So, next slide please. And I guess to make this even more abundantly clear what is it? What is the CFA? So, we are like I said a collaboration between Harvard University and the Smithsonian. We're based in Cambridge, Massachusetts and the group that we're talking about locally is actually one of the largest gatherings of astronomers on the planet and our library actually is one of the largest astrophysics research libraries in the world. So, we really are trying to cater to our local community which is itself pretty diverse and large but also due to the nature of where we are and the kinds of collections that we house and the services we provide, we're actually talking about trying to serve the whole astronomy community. So, when I say the community that we serve, I'm trying to think more globally about all of the researchers who could be undertaking this kind of work. And part of our mission, so I've made a big part of our mission, being to both anticipate and respond to challenges that impact that community, so that broad community, that global community of researchers, academics, engineers, what can we do as a library to try to give them the resources they need to do their work? And a big part of doing that is facilitating communication and collaboration. So, all of astronomy research just about is international in scope. One of the things that's wonderful about astronomy but adds complexity is that everyone needs to share. So, people share time on telescopes, people share data sets. This isn't a world where you get to redo observations. So, facilitating communication and collaboration is a big part of making sure we're supporting the community. So, next slide, please. And one of the ways that we do that is with metadata. So, Daniel's going to talk quite a bit more about what we're talking about specifically with MetaSat and with Metadata. But generally, you're all, I'm sure, somewhat aware of what we're getting at here with Metadata. But to sort of, I guess, distill it down in its essence, metadata is a consistent and precise way to describe things. And because our community is working on space missions, the things we're describing are all aspects of the mission itself. So, yeah, let's go on to the next slide. And a mission has many aspects. So, there's first, the things that the astronomers are studying. So, what is the actual focus of the research? And then there's the way in which they do the research. And we have built tools in collaboration with our communities, so working with the community to support their information needs for the prior side of the coin. So, when it comes to actually describing astronomy as a field, Katie Fry, who's on the call, is actually the curator of another project we have called the Unified Astronomy Thesaurus. So, this is a unified thesaurus that integrates kind of older disparate resources that were used to describe the field. And we have had this, had this vocabulary, this controlled vocabulary be implemented by the American Astronomical Society, among others. And it's currently hosted by the ARDC. Thank you. And like I said, it's curated by Katie. But this was our first aspect of supporting the community's information, sharing needs. Let's develop out this thesaurus that really describes the astronomy itself. So, next slide. And what about describing other aspects of the mission? So, if we weren't to be describing the science itself, there's many, many, many other aspects to a mission that need to be described so that we can actually work with each other so we can collaborate, that people can communicate, and so that they can work together internationally. So, this is where Metasat comes in. This is that other side of the coin. So, this is a project that I think we're really pulling a lot in building on what we've learned from the UAT because it has been so successful. So, next slide please. I thought it would be useful before we get into what Metasat is and how we've structured it and what we're doing with it to make it a little more concrete, what we're talking about when we talk about a mission. So, what pieces of a space mission even exist? And why is it challenging to do this? Because there have been past projects that have described components of a space mission, but nothing that really unifies them. The same way that the unified astronomy thesaurus had been these sort of disparate or incomplete resources. And the UAT is a way to bring those things together and it be this community-built tool. We want to do the same with Metasat and I guess I thought it would be good to give it an example. So, missions have, you know, the space-based aspects. So, there are actual spacecraft and everything that goes along with the operation and decommissioning even of those satellites after they've been planned and successfully launched. But there's also this ground-based component too. So, there's all of the work that goes into creating the spacecraft itself, the work of getting it up into space, into orbit, wherever it is going. And then there's also all of the work needed to communicate on a continuous basis with that spacecraft. So, you have multiple pieces involving multiple parties with a lot of complexity and a lot of different resources kind of implicated in all of those components. And so, distant teams, teams that are collaborating across the, across the planet have trouble sometimes communicating about this, even if they're something as sophisticated as a, as a NASA mission. So, my example here is actually from 1998, a mission referred to as the Mars Climate Orbiter. So, to make it clear how difficult the little details are sometimes when you can't quite communicate well and when your metadata isn't machine-actionable in this context. But the Mars Climate Orbiter was a NASA satellite that was launched in 1998 and it did all of the work of getting it up into space and approaching Mars. But one of the really big challenges once you get something to Mars is actually to get it into orbit around Mars. And because of a miscommunication between the software on Earth that was trying to communicate with the satellite and the satellite itself and the software that it was using, the spacecraft actually crashed into the planet. So, we had this issue where imperial units were being used by the software on Earth to measure propulsion. So, it was transmitting in pounds of force per second, whereas the software, so the software on Earth was using imperial units and the software on the spacecraft was using metric units. And so, this miscommunication just in something as simple and as trivial as what kind of units are being used by the software transmitted by the spacecraft actually caused this catastrophic event. So, sometimes the devil really is in the details and if your metadata isn't transparent and there's no agreement across systems about what's going on, you can really have kind of a bad time. So, next slide please. And so, if we want to prevent catastrophes and we want to be able to learn from past missions, ongoing missions, missions that we're just not even a part of at all, but that we might want to refer to for who knows why in the future. You need good metadata and you need to be able to have that metadata be open. But where do we start with all of this? Because the space mission is complicated. Is that a big space mission like the NCO is even more complicated. So, where do we go to kind of scope what we're trying to do effectively so that we can build. And what we decided to do is to start with small sats. So, a small sat is a small satellite and that's kind of relative. It's quite a range. So, that's anything under 500 kilograms. So, that can actually be quite large, but it's not infinitely large. So, something like Sputnik 1, that would be considered a small sat today, but many small sats are things like tube sats or femto sats, which are, you know, yay, big, and something like a femto sat actually could fit in the palm of your hand. And the apico sats, there's just an entire world of very small instrumentation that can be launched in the space. Something like Hubble, which is much larger, is not considered a small sat. But we think what we've built, what we're doing with small sats, will translate well to these larger space missions provided we're able to start with use cases that are extensible. So, you'll see just for kind of a size reference point, a movie model of Sputnik 1. So, this would be something that's considered small today. Daniel, next slide, please. And a little more on why small sats. So, in addition to being something that is small, like these missions are themselves reliant on many fewer components, like you only have so much you can fit in a small satellite. They're also increasingly important to astronomers and engineers. So, our community at the CFI has its own small sats initiative going on, where our scientists are trying to leverage small satellites as a platform to do their research more. And this isn't just our community. And it's not just NASA too, but I have a quote here from NASA, basically stating that small spacecraft, because of their ability to reduce costs in new space missions, it's a lot cheaper to fly something as small as you're as they can fit in the palm of your hand than something like Hubble, that they're enabling and expanding more access to space. And that they have the capacity to help facilitate entirely new architectures for a wide range of activities in space with potential for exponential jumps in transformative science. So, these platforms, although they're small, they are very important to the future of astronomical research and spaceflight engineering more broadly. So, focusing in on small sats seemed like the way to go. So, next slide, please. And to kind of drive home, I guess, the impact that we think we can have with MetaSat. I know I brought up MCO as a mission that was a catastrophic failure, quote, unquote. There was a lot learned from that. I don't want to understate that. It wasn't completely a loss for sure. But Q-sats and small sats, so Q-sats are a type of small sat, they've actually got a surprisingly high failure rate. And one of the things that contributes to those failures is the fact that lots of these missions are being run by, quote, hobbyists. So, that would include schools, universities, places where people are just starting to prototype new instrumentation, where they're doing their first research missions. And they have about a one in three failure rate, actually. When you look at the, quote, industrialists, people like NASA and SpaceX, you have a much lower reported failure rate, but we still have a very high proportion of satellites that are, quote, dead on arrival. So, about 20% of these small Q-sat missions are never able to actually communicate with Earth. So, they got all the way up and we never were able to actually establish that link to actually learn from what they were doing. And so, I should point out that that doesn't include things like these constellations. So, constellations of small sats that are all sort of working together on a single mission. So, these numbers don't include those. But, in case, long story short, the failure rate is really high. So, next slide, please. So, what do we do about that? Knowing that thousands of these small satellites are being launched every year, and we want to be able to learn from others who have had those failures. Well, how do we do that if finding detailed information about them is really challenging? Right now, or at least until that comes out, there's no real mechanism in place to help search across platforms or to really connect up all of the pieces of a mission so that you can really start learning from past missions and finding out more about ongoing missions. And so, that could be something as simple as who else used this sensor? Where are the papers associated with that mission? When was the launch? What was the orbit that that satellite established? These are sort of baseline questions at a high level about a given mission that are right now really challenging to answer. And so, we hope Metasat is a tool that will help us get past this bottleneck. And next slide. And I think, Daniel, this is where I hand it off to you. Sure. Thanks, Dana. Yeah. So, we started off, like Dana mentioned, with larger, envisioning using Metasat to describe large space missions. And since we decided to work with small satellites, things got a bit easier. And as far as the data, the software, and the hardware involved with those missions. And so, what Metasat does is we've created a vocabulary that can be used to describe all three of those parts of a small satellite mission in a way that is both human and machine actionable. So, on our website, which is schema.space, if you go forward slash Metasat, you'll find yourself at the main browsing page for our vocabulary. And so, here, we have decided to break down each mission into different segments and families. So, even though the small satellite mission is a lot simpler than the traditional large enterprise class mission, there's still an extreme level of complexity to them. So, at the highest level, we've broken down the lexicon into what we were calling mission segments. And so, they are space, ground, launch, and user. So, the space segment includes the spacecraft itself, all of its components, most major subsystems that are universal from mission to mission. So, that includes electrical power systems, thermal control systems, propulsion systems, things like that, including the onboard computer. So, just general metadata for computing parts. It also includes things like orbital parameters, orbital determination. So, things like apogee, perigee, different data points that can be used to pinpoint allocation of a spacecraft. We also have a ground segment, which includes a ground station terminal, which is used to communicate with the spacecraft. That segment also includes our ground station network portion. And so, we are currently piloting metasat terms on the sat-nogs ground station network, which is operated by the Lieber space foundation. And so, they use metasat terms to organize all the metadata associated with the ground stations that are a part of that network. So, that includes things ranging from bibliographic information on the ground station operators. It also includes telemetry metadata, things that are used to describe the physical components of ground stations like antennas in addition to frequency bands and stuff like that. So, that's the ground segment. The user segment is kind of an experimental segment that we're still not sure what direction it will take, but it is, you can almost look at it as a subsection of the ground segment, where it includes metadata that's involved with everything to do with how a user interacts with a spacecraft. So, for example, it would include metadata on, let's say, like a GPS transceiver in your car, or it also would include things that might be involved with GIS systems, or even satellite radio, TV, mobile communication networks, and stuff like that. So, this experimental segment is just getting started, but I'm excited to see where it will go. But then, the fourth segment that we have is the launch segment, which covers the launch vehicles. So, things like rockets. There's a lot of overlap there with our propulsion system as part of the space segment, but it's very rocket-focused, and it also includes metadata to describe launch service providers. So, companies like SpaceX or Rocket Labs, or, you know, different companies like that, we could use that segment to describe. So, and then the families are part of all those, are like a different subcategory of all those segments. And so, for example, in the space segment under the spacecraft, a family, we have a dedicated family for thermal control. And so, that's just a more granular look at the vocabulary. So, what makes the vocabulary special and what makes it machine-readable is that each, so we call our terms concepts, and for each concept, we have an accompanying Uniform Resource Identifier, or URI. And URIs, most people are familiar with URLs, which are a type of URI, but URIs are a specific identifier used to locate a resource. And so, in our vocabulary, our URI, which takes the form of a URL, which I would scheme about space, slash metasat, slash, so for example, gravity, this resolves to a page that we have on gravity. So, we included in that page, we have a description of it, which we have sourced. So, in this way, metasat is a bit of a dictionary. We have an example value just for the user's convenience. Then we have synonyms, which is one of the most important parts of the vocabulary. So, one issue, similar to the issues that were faced by the Mars climate orbiter, is that sometimes, different space agencies or even different databases involved with a single mission have different terms that are synonymous but are used to represent the same data. So, for example, sometimes gravity is mentioned as gravitation, or sometimes it's more specific and it's referred to as a gravitational force, where in multiple databases, these are all referring to the exact same value. And so, what metasat does in our synonym portion of the vocabulary is that we try to remove that ambiguity. And so, that is a big part of what we're trying to do with metasat. And then also, you can see at the bottom here, we have concept segments and we have concept families. So, those are examples of what I was talking about earlier. The next big part of the vocabulary is that each individual concept is also what we call crosswalked to another resource. And so, crosswalking is pretty much, so we'll have, let's say, there's a definition by encyclopedia Britannica on gravity. We map it to our definition of gravity, to our individual URI for that concept of gravity. And so, this is a way of bridging existing resources such that neither needs to change their identifier for a concept or what language it's in. So, for example, if your concept is in French, we can crosswalk to it, such that if you use your French term in your database, it resolves via our URI to our database, which is in English. And so, it's a great way of also reducing ambiguity between language. And so, relevant to Australia, we have already crosswalked to the Australian Education Vocabulary. And we also have crosswalked to the Unified Astronomy Dessaurus. And also, here's Australian Education Vocabulary for gravity. So, you can see that they have a URI for it here. And so, we have crosswalked to it, to our concept. But we have also crosswalked to, almost like I'm missing some slides here. Others talk about it. So, we also crosswalked to Wikidata. So, Wikidata is a massive, I must be the largest knowledge base of terms on the internet. And it is used by the Wikimedia Foundation, particularly through its project, you know, through Wikipedia, its main project to represent all the concepts that are in their knowledge base. So, for example, if you go to a Wikipedia page on gravity, Barrow B, and accompanying Wikidata identifier for that concept of gravity. And so, we have crosswalked all of every single one of our terms virtually, unless it's a brand new term that we've created to Wikidata. And so, this has been one of our biggest projects. And the fact that we've done that has helped a lot with things like using Metasat to bring up data that's Googled, that's used like in Google search. So, Google search utilizes Wikidata a lot. And so, if you were to Google, let's say gravity, it would pull up the probably your first result would be the Wikipedia page on gravity, which would also resolve to Wikidata, which would also resolve to Metasat. And so, that's something that we are pretty proud of that we've done. And also, Wikidata has many translations into different languages. And so, that's another perk of crosswalking to that. So, now on this slide. So, we already have some existing project partners. So, I already mentioned the Libre Space Foundation. So, we are currently being piloted on the Sat-Dogs Ground Station Network. And so, that has been fantastic. We are also working with NASA's Small Satellite Virtual Institute, so S3VI. They have a bunch of things going. So, their big one is their spoon database, which is small parts on orbit now. And so, that is a database used by the vendors of small satellite parts. And so, we are trying to use Metasat terms to create an agreement between different vendors on those parts, on those components. And then, lastly, also involved with NASA, but there's other private companies involved with this too, is the Small Satellite Reliability Initiative. They have recently put out a knowledge base, which addresses that problem that Dana had brought up earlier on the lack of any sort of warehouse for lessons learned documentation. And so, they are addressing that problem. And so, hopefully, we will be able to use Metasat to inform their glossary of terms. And so, when you are searching for lessons learned documents on a particular mission, you could use Metasat terminology to find your results. So, our big next step, and one thing that I thought was important to bring up during this presentation, is that we have decided to create what we are calling the Metasat Steering Committee. So, since Metasat is an open and collaboratively driven project where it's entirely feedback based. So, none of us, as we are Liberians, are experts or space engineers in the area. Any sort of area of aerospace engineering is not something that we are familiar with. So, our whole project has been community driven, and that has been extremely fruitful. So, we have a lot of voices involved and we want to make a system, and we want to put a system in place where all those different voices can steer the development of Metasat into the future. And so, this would be an advisory body for Metasat's governance. And it consists of a group of a dozen or so different partners, both with their government, university, private sector, that would all contribute to the development of the Metasat vocabulary and toolkit. And so, we envision NASA to be a part of that. We would love the Australian Space Agency who I am in contact with to be a part of that. All sorts of open source organizations and individuals. So, we'll see where this goes. But we are roughly basing it off of the UATs, the steering committee model. And so, that could be a point of reference if you're interested in learning more about what we're trying to do. And so, this brings me to one of the final slides for the future of Metasat. So, I mentioned the new government structure and we also have revised our release cycle. So, versioning of this vocabulary is quite tricky. And so, if you go to our GitLab repository, which is on, you could find on our website, through our website, you can see that we have a release cycle fleshed out. But that might be something that will change with the incorporation of a new steering committee. So, some of the slides that weren't working before were about this data format that we use called JSON-LD that is used to organize our URIs. So, JSON-LD is a variant of regular JSON for linked data. And so, what it is, it's a very lightweight data format that could be used to organize all of your URIs in one place such that you could use that to create a metadata schema which could then be used to say organize a database or to to be, it could be used to let's say organize all the URIs that are used in an API. And so, we like JSON-LD because it's lightweight, it's flexible, it's also human readable, which you could see if you go to our GitLab repository. We have a bunch of examples of using Metasat URIs in the format. But it's also great because it has this feature called the context feature and context feature. What that means is we could link, we could incorporate different vocabularies directly in the document and pretty much create a key for each of those vocabularies and then refer to those vocabularies within the document itself. And so, we have a lot of resources on the website that you want to look into this more. And it's just one of many different ways that you could use the Metasat vocabulary and URIs. The other way is, right now, the most popular method of say organizing a database is through using the resource description framework, RDF. And so, we would really like to be able to create many more RDF files for each individual Metasat concept. That's something that we don't have yet. And so, we would love to do that, like the UIT. And in order to accomplish that, we need to change how we store our URIs, which right now is just in a regular database. And the thing about the RDF celerizations too, the RDF is that we could serialize it into different formats. So, we envision it being an RDF XML, RDF turtle, and triples, and different things like that. That could be used for a variety of applications. Things that we're not even, I'm sure, aware of. And then the last few things that Metasat is looking to do in the future is could likely create our own API that could be used. That will just include all the Metasat terms. And so, people could use that in order to, let's say, create their own crosswalks or all sorts of semantic web applications could be used via a Metasat API. We also were looking for further adoption integrations, like I mentioned, New York Stirling Space Agency is a new partner that we're interested in collaborating with open source communities. We're looking at the AMSAT, a bunch of different other groups in universities, especially University of Colorado Boulder. And so, we're interested in seeing what they can provide for feedback, but also with their integration of Metasat into their own systems. We're also interested in using Metasat terms for search engine optimization, so SEO. So, if anyone's familiar with web development, a lot of times, these JSON-LD files are used in, are embedded within header files, well, within the header of an HTML document that is used for Google search algorithms. So, kind of what I was talking about before, Google Knowledge Graph. So, if you use Metasat terms in your JSON-LD file of the header of your HTML page, you could actually benefit greatly by indexing higher in Google search. So, there is a commercial side of it as well. And then the last thing, as I said before, also with further adoption integration is that, you know, for a community-driven project. And so, in the future, we'd like to see, you know, where different voices will take us. And that's pretty much it for me. So, if you have any questions, I think you could get into that now and see there's some comments in the chat. Thanks very much, Daniel and Dana. And we certainly do have some time for comment and discussion. The first, I can see there was a question came up in the chat from Min asking about whether the crosswalks to other vocabularies were done manually and automatically. Dana commented that initially they'd been done manually, but that sounded like wanting to facilitate crosswalking via an API. Min or Dana, is there anything else you'd like to ask about or comment on in relation to that topic? I can at least clarify that one of the things that we prioritized was crosswalking. So, the crosswalks themselves are sort of part of the Metasat toolkit, so to speak, because those were developed manually and painstakingly. So, primarily led by Daniel and supported by a few of our other staff assistants in the library with lots of consulting from the community as well. So, those were manually developed, but the goal is to kind of make the use of those things much more flexible via an API. And also, those crosswalks are going to continue to evolve, and we're open to crosswalking to other resources too. But what we wanted to do with Metasat wasn't to just kind of create another quote unquote standard that we wanted everyone to switch over to, so to speak. So, we wanted to kind of acknowledge the reality that everyone's not going to use the same jargon, even if we wanted them to. And that the implementation we created in JSON-LD, which unfortunately the slide didn't load, kind of makes it so you can use the quote at context section to use multiple vocabularies. So, if you wanted to use the UAT and Metasat and say schema.org or something like that, you could. So, I think the crosswalks right now, they were created manually, but we have a lot of aspirations for what we'll do next with them. Min, do you have any follow-up comments or thoughts in relation to what Dana was elaborating on? No, I think the answer is pretty clear. So, no further answer question. So, I ask the next question because I was browsing the GitHub and the website. I wanted to wear, you know, for community to use cases or propose terms, but I think now I finally had to now. Yeah. Yeah, so that would be you. Yeah. Right there on the last link on the slide. So, our GitHub.com. Metasat, that would be the spot. There we go. Yep. Issue. Perfect. Yep. Thanks. Are there other comments or questions? I just wanted to make, sorry, I just wanted to make one more point about where you can actually make suggestions. Can I actually share my screen, Daniel? Okay. So, I'm going to share my screen. Just so you see, I pulled up randomly selected one of our URIs. So, this is for a fine error sensor. And you'll see down at the bottom there's actually a suggest and edit button. So, one of the really great things is that even if you don't necessarily go to our GitLab and see like our contributing file or anything like that, we are trying to encourage people to help us make the vocabulary available. So, I also just want to point out this button. Yeah, that's good. That's probably accessible more widely beyond the GitHub. Are there other comments or questions for Daniel or Dana? While people are thinking, when something that came to mind, Daniel, you mentioned that it's tricky to version this resource. Can you say a little about some of the challenges that you're facing and the approaches that you may be considering? Yeah, absolutely. So, with the vocabulary at large, there are a lot of minor changes that need to be made. There are things that, you know, I catch all the time. So, for example, let's say there is an incorrect example value in the database. So, how do we go about fixing that change and then creating a new version for Metasat that reflects that change? And so, we've adopted semantic versioning, which there is a certain system of kind of doing these batch updates where we could include all the minor updates in addition to the larger ones. So, that includes adding and deprecating concepts. That's a larger update, bigger one. And there's also, like I said, smaller updates on the more of the minor attributes of each concept. And so, we are trying to be as transparent as possible with the updates. And so, all of them are documented, recorded as issues in our good lab repository. We also, for each version, we mint a DOI for it, and we archive it. And so, you could keep track of that in our repository, but also on Zenodo. So, that's another thing that we do. But, yeah, we're still looking to improve our release cycle, like I mentioned, hopefully, with some more voices in the steering committee and better guidance. We could improve it. Yeah, I think one of the, just to kind of build on that, is one of the things that's been wonderful with the UAT is that with the steering committee, it's been, Katie's been able to work with a lot of different stakeholders to determine kind of a reasonable cadence for updates and kind of an agreed upon sense of what constitutes major and minor changes and what the expectations would be for a communication about those changes and the like. And so, I think that we're still kind of getting there in terms of how it, how sophisticated is our decision-making process about those releases, opposed to there being kind of challenges in the mechanics. The mechanics of it involve updating a database and archiving past releases and communicating about what's in those changes, which is just its own pile of work that we don't necessarily want to be done more frequently than is valuable, if that makes sense. Well, certainly the approach that you seeking to take to be in tune with the community, with the users, to understand that the things that will be of importance to them, that sounds like a really good approach to take in it to help consider what is or isn't worth doing. Yeah, I think another thing too, just to sort of build on that, depending on the different stakeholders, I guess what it would mean to implement a new version may be more or less challenging, depending on the platform and how they're making use of the technology. So, I think if we were to have a, as we move forward, having more people wanting to and actually moving forward with implementations and different approaches to using the tool, that'll really kind of inform the cadence and everything else around what we want to do. Any other comments or questions for Dana or Daniel? Or otherwise, Dana and Daniel, are there any other points you'd like to make or issues you may wish to reiterate or draw out further from the discussion today? I think I might just want to say one other thing about our use cases, that we didn't really touch on in the presentation. And this is kind of the building on, I guess, what we've seen with the UAT. The first implementations of the UAT have been in the publishing landscape. So, UAT is being used, like you said, by the WAS to tag journal articles, publications, it's also being used internally for some systems around telescope time proposals for things like Hubble. So, ideally, you'd be able to say like, okay, well, you proposed to do work in this area. So, you had this subject in mind for your observation. What did you actually publish on? It's like a line that can be drawn when you have those two kinds of implementations. But we had not initially been thinking of reaching out as much to publishers when we started working on MetaSat, because we were focused more on our engineering teams that we're working with. And increasingly, it became apparent from the opportunities with different types of platform developers. So, people are developing things like this Knowledge Base that Dana alluded to and the Australian Space Agency and their forthcoming website is really kind of part of the conversation that we're having with them now. But we are planning to kind of circle back more and think about publishers in this context and how they might be able to take advantage of MetaSat and the UAT. And kind of along similar lines, where there's opportunity for us to incorporate MetaSat, there may be opportunities to bring the UAT into that discussion as well, provided that what the instrumentation they're building is being used for astronomy. It might behoove them to take advantage of the source we have for describing astronomy. So, these things are kind of two sides of the same coin. Okay, well, looking in the chat, I don't see any additional questions or comments. So, we're approaching the hour. Last chance for any final questions or comments to Dana and Daniel. If not, well, thanks so much, Dana and Daniel, for coming along to discuss MetaSat today's session. It's a wonderful initiative and really useful to hear about all of the activity and development work that's going on. A reminder to everyone that this session will be, well, is being recorded. It'll go up on the ARDC YouTube site and we'll send out a reminder to everyone who registered so that they'll be able to see the recording. And thanks also to everyone who came along today and participated. And with that, we'll draw the session to a close. Thanks again. Bye all. Thank you. Thank you, everyone. Thanks, everyone.