 Okay, so up until the last release, we required RIF-CS schema XML for harvesting, as Jerry described. We've now made some modifications so that we can accept metadata schemas other than RIF-CS, and we've enabled this by having a crosswalk actually at the end's registry side, so we can start the RIF-CS for you, for ingesting to the registry. We also have the ability, because we've had some metadata repositories that provide JSON data, we've implemented the ability to grab the JSON and then construct XML out of that, and then again have an XSL transformation to construct RIF-CS for ingests. In terms of protocols that we support, we've always supported the symbol HTTP GET of the RIF-CS, and we continue to do so, and as many of you will be aware, over the OAR-PMH protocol, which enables functionality for marking for deletion and filtering by sets, etc. So now we have the ability over OAR-PMH to accept schemas other than RIF-CS, and again have a transformation on our side to construct RIF-CS. We've also enabled the ability to harvest over the OGC compliant catalog service for the web interface, again accepting other metadata schemas, and as long as there's a crosswalk, then we're happy to accept it. And so here's an example, yeah, so for the JSON, accepting JSON, we've implemented this specifically for an implementation of CCAN, where the API conforms with the rest of the API architecture. It's quite tightly coupled at the moment to that implementation, but in theory and in practice we can easily extend this to accept any JSON objects over a similar architecture, just the protocol of obtaining all identifiers and then per identifier obtaining metadata, and then again transforming this to the eventual RIF-CS. This, as we know, so this was our common scenario previously, where we've had a lot of geo-network contributors using geo-network metadata repositories, so in the past we've had to have the transformation occur within the geo-network implementation, but now we can do, as has often been the case, accept ANZL, accept green community profile from the geo-network and then transform it on our side. We've implemented a fair few crosswalks to start with, ranging from the most simple to much more complicated for aggregating providers. Similarly, we can obtain the ANZL COVID catalog service for the web interface and transform it outside. Yeah, this was our scenario for the CCAN, so as I said, it's only CCAN at the moment, but it can potentially be any RESTful API implementation where we can get a list of identifiers and then obtain the data per each. Again, we've constructed some default crosswalks here that we've used for the data.gov and state portals, where we construct a collection object and then we infer parties and services from within those metadata records. Same story for the ANZL crosswalks that we've constructed in the marine community profile crosswalks. So we've constructed datasets and then constructed parties for the responsible parties within the ANZL and similarly where there have been connections to other services and publications, websites and other objects. We've been able to indicate those as well. Here's just a nice scenario that we have with the National Computational Infrastructure, where we had a provider, a term provider EMAST, providing metadata just in CSV format to the NCI, where they had a tool to construct the ANZL account of that. And then from their GN network we've been harvesting the RIFCS, which has gone, that's because we've had the crosswalk on their side and that's being pulled up by the term data discovery portal and similarly by us. But same scenario because we can obtain other metadata schemas from that GN network too. That's the option there for people to harvest, not RIFCS. So ANZL, for example, marine community profile, via the OAPMH interface or via the catalog service for the work interface implementation. And so we've constructed a heap of supportive documentation, specifically detailed for data source administrators to be able to implement or configure, sorry, our harvest over CSW or OAPMH, where a crosswalk need be applied when harvesting metadata schemas up in the RIFCS. So far as the documentation will indicate, it's been quite a partner approach. So a data source administrator would certainly rely on the outreach officer and services for configuring a crosswalk and applying it to the feed. But for the next release, there's going to be the ability to upload your own crosswalk. So that's all in progress too. And that's it for me.