 So yes, I'm the technical program manager here for PioPortal. I was originally hired and I'm still leading a program called Cedar, which is Center for Expanded Data Annotation and Retrieval. And it's a nice metadata management program. Think of it as forms with semantics, sort of an application that uses semantics. So if any of you need a nice metadata front end management or full life cycle management system, feel free to contact me about Cedar as well. And so I still, in the background, work on the MMI Ontology Registry and Repository from which Core was created. But I'm mostly moral support, really for both of these in many ways, that technical work is largely done by others. And then I tell users about them. And this is in the larger context lots of principle repositories being out there, including some of the Australia ones that I understand you are already quite familiar with. I wanted to start with this page because I just created it for the last talk. And I've been trying to do it for two years before that. So I'm very happy to have it now. And it just is a short summary of the highest level requirements that are associated with these kinds of repositories. And to create it mostly, I tried to think of all of the features that were in BioPortal. And I'm sure there are a few features that are useful that BioPortal doesn't do, but its richness is pretty impressive. And I still am not very much of a deep expert, but I can do a presentation like this. So this was actually presented in the context of environmental and earth science vocabularies. And so I emphasized AgriPortal a little bit more. And the reason I could do that is because BioPortal is a web service that also presents itself as a system that other people can download and set up for their own purposes. And AgriPortal is an application that has done that. And so it's only been around for a few years, but has almost 100 vocabularies. I should ask how long you'd like this to go. I'm imagining 10 to 15 minutes. That's great, John. Yeah, we will need to finish up on the hour so to leave a bit of time for conversation. Yeah. Sure, sure. So this slide just gives a sense overall of what these resources are like. And as you might have guessed with all those features BioPortal, which has 800 or so public vocabularies in it, has tons of semantic features. Its usability suffers. It's more about a lot of researchy features that have been melded over time into a high-end repository. So the user interface suffers accordingly, although a lot of improvements are being made right now to take care of some of that. AgriPortal was agriculturally based. BioPortal was originally biomedically based, but is growing to support other things. And there's one called Biblioportal now. And in fact, we've started a hosting mechanism that's like Biblio.ontoportal.org. So we're thinking about having a whole suite of resources under the Ontoportal system. That's possible future direction that we're playing with. And it's a very, it'll be more comfortable working with BioPortal if you're working with ontologies and or it's got vocabularies in a fairly significant way. But the vocabulary quality is pretty good, even though it's not a curated system. BioPortal is not a curated system. AgriPortal is to some degree, although we get rid of the true DREC. And its scale is just ginormous. And so the result of that is that it's hard to keep it running 100% of the time. We average about 99% of the time, which is not quite production scale reliability. You're looking at a view now of AgriPortal and the topmost ontologies in it. AgriPortal being a quite sizable ontology of about 700,000 concepts, talking to some of the library people I was talking about. There are big vocabularies with a million or more concepts. And they said, huh, you call that big. And they deal with much, much larger. And so now we're learning to deal with the next scale up about 12 million concepts. And some of it works well. There are particular systems, as you might imagine, that don't work so well, particular API interfaces and so forth that need to be tuned. You can see a lot of categories on the left side. A lot of different ways that you can pivot to a facet on different things to look at. This is, again, an AgriPortal, but in Bioportal, it looks very similar to Bioportal, where we provide a lot of information about the ontology, which can be any kind of vocabulary or ontology that's supported by the API. So SCOS is not a problem. If it's well-structured SCOS with root concepts and the like, if it's not well-structured SCOS, then we can have issues. And these systems do get a lot of visits. We get something like 16,000, 20,000 user interface hits a week and on the order of a million API hits a day. So on Bioportal, it's quite heavily used. There's a pretty strong API on this system, lots and lots of features. But again, you have to sort of work into it a little bit. It returns JSON-LD. I believe you can also ask for XML, at least for some of these features. And then moving on to this other resource. So whereas Bioportal is sort of the gorilla in the room that can deal with a lot of different things and provide you lots of different automated features, the ontology recommender is particularly strong. I argue it's probably the best in its class. And mappings, automated and manual mappings, and so forth. The MMI Ontology Registry and Repository, which was developed about the same time, about 12, 13 years ago, was developed for a group, the marine science community, that was not at all familiar with semantic tools and technologies. And so we really created it for people who might have their vocabulary in a list. And they wanted to publish it in a formal, controlled way, but they didn't know how to do that. And so we have very nice ways to just try it out and ease yourself in and put your vocabulary into a little spreadsheet. And it will generate all of the nice things. It generates the SCOS RDF. It generates the URIs according to a system that I think has survived very well that gives you both versioned URIs and unversioned URIs. So we don't have to solve that problem of deciding, which is more important. And it's a little more usable and user-friendly than Bioportal can handle beginner users much better, I would say. The catch here is there is somewhat less full-time investment, but Bioportal has about two people supporting it full-time, two and a half, three on a bad day. And these tools have more like a quarter of the person supporting them. They still are very extraordinarily reliable. Carlos Rida has done most of the code from Mmbari and has done an excellent job on it. So in the original MMI repository, we have 289 vocabulary's varying qualities in ESIP community ontology repository. ESIP evaluated the MMI tool and decided that they would like to use it as a resource for earth science vocabulary's. And so they have 243 resources, assets in it, but which is very exciting, except that about 200 of them are all sweet vocabulary's and sub vocabulary's. So it's not quite as impressive that way, but it's only been around about three or four months. So the community is starting to advocate for it and work out how it can be used in the ESIP context, which is a very community-oriented activity. So we have several members of the community who are engaged with COR in the ESIP context and excited to move it forward by contributing technical work and by contributing their efforts to publish ontologies like sweet in it, which is a pretty significant step forward. And again, so they just quickly can give you a feel for what that user interface looks like. You get some of the same facets to search on. Most of the IRIs you see here, the ones that do not start, COR, ESIP, Fed.org, are cases where the people are what we call remote hosting. They're ontologies. They're putting the ontology in the COR, but it actually lives as its primary location somewhere else. And if that's resolvable, then these links will resolve to that ontology, obviously. We have the capability to do groups, have people be members of groups to manage ontology. And you can see the versioning column there that lets people see when the most recent entry was, but keeps track of all the different entries so you can actually access things specifically by their version. And the various tools to upload on ontology or create your own vocabulary or create a mapping or at the top there. One of the things that we did that was new at the time, if 12 years ago, was support heavily well-defined metadata concepts that people could fill out to really describe their ontology. And it's very easy to use and it gets mixed usage. Some of us use it heavily and some of us don't use it at all unless we're forced to. And finally, a nice API and presentation of the API with a swagger and a rich set of API interfaces that you can use here as well. Very different level of detail and power in these interfaces. I think it's all any basic or average user would need. But if you're dealing with something that has 100,000 terms and you want to have autocomplete on a branch that has 10,000 terms in that ontology, the widget capability that BioPortal provides is really, really nice. And so that's the place you'd want to put your 100,000 or 500,000 term ontology if you plan to build things on top of it. And you see that as a result in the actual applications that are using the tool that there are actually some production level operational applications and a couple of systems in the biomedical community that are repurposing their repurposing BioPortal content for their users. And so we get some complaints when the system is down, but none of them have offered to pay us large amounts of money to guarantee that it's up. So we're not feeling too guilty yet, given the richness of the system. And I think that's just all that I had to cover, aside from all the other social discussion of my complaints about not getting funded.