 not a problem. So hi, my name is May Smith. I work within the data policy and informatics team at Geoscience Australia. My colleague, Lara Sedgman, who leads the data and catalog team, which publishes the vocabs is also here today, as usual. Progressing. That's moved on. It's moved on, but we can't hear you. Marguerite, you're on mute. Yeah, I'm not sure why it went on mute. Apologies, I have to keep an eye on that. Now we've got your little eye you've moved, yeah. I'll screen. That's good. Are you OK? Try again. I'd like to acknowledge the traditional custodians of country throughout Australia and recognise a continuing connection to lands, water and communities. I'm speaking today from none of our neighboring country. I pay my respects to Aboriginal and Torres Strait Islanders in this meeting and to elders past prison and emerging. Hopefully that's progressed. So GA have been undertaking a refresh on the way it collects and releases vocabs, codelists and glossaries and looking at how to make it easy for the users to create these vocabs. The GA register is small at the moment, but there's gradually more interest in how it might be used. I presented some of this information at a NICEF meeting recently, but I'm going to go into the publishing process in more detail. I realise this audience is well aware of vocabularies and delivery, but GA are back at the beginning in terms of their vocab creation and management, and we're working on making the process as accessible as possible for the organisation. So since 2016, the idea of using a vocab has been promoted by a few staff who understand what they are and how to use them. Like other organisations, GA has previously relied on the great tools provided by the ARDC and the RVA register. So as a refresh and following our catalogue model, we want to be able to publish our own content using existing data release workflows and to make this discoverable by staff. So far in this journey, a provider has set up a VocPres instance so GA could register their vocabs and we're initially finding GA teams that want to publish a vocab or data dictionary so we can test what the workflow might look like in production. There is no mandate for this in the building, so hence the reason we're testing this with those who want to engage before we advertise it as a production ready workflow. There's also the desire obviously to mirror our vocabs at RVA so that will require some effort to clean up what is currently there and work through the process of pushing what we have across there as well. So in developing a vocab publishing workflow, we initially went to encourage teams, want to encourage teams to think of a vocab as a communication tool for data elements that may only ever be released as a web service or in static documentation like a PDF. So the register is also a good reference point for new staff and particularly for contractors who brought into complete database work but have no history within the organisation. The GA Country Codes profile is an example of work undertaken two years ago. Additional country codes needed to be added into a database and they did not know where to get the codes from. So at the time they were encouraged to use the ISO Country Codes standard and initially used a spreadsheet view of the codes but ongoing this vocab will be published and updated as required. It's not going to be a current Country Code list but rather a representation of the codes held within GA databases at a point in time. We've also had some requests from external organisations for GA to publish a vocab on behalf of their community and this is where it can be a little bit tricky as an Australian government entity and custodianship and what we're seeing to promote and the justification for funding this work so we're still working through these things. As I mentioned before, we used to use pool party and then we published an RBA. We had a vocab management policy and confluence page within the organisation with some guidance. So in having our own register, we need to be proactive in its use and management. The policy and tools we have supporting the management and release of vocabs at the moment are, let's see if this works. The vocab management policy, the product management and release policy, Vock Excel template, an online translator, RDF validator and the online product management and release tool. So the release of data is a well known process at GA now and we're treating a vocab as a data set for the purpose of the cataloging process. So as I mentioned before, we're using the voc Excel template approach to support users developing a vocab and the spreadsheet contains a read me tab explaining what the content is required and the GA policy and publishing process covers governance and custodianship requirements and responsibilities. So far users have been able to understand the requirements in the spreadsheet but there definitely needs to be more procedural guidance around vocab creation generally and specifically for the Excel sheet to support the general non-technical user. So down the bottom to convert and validate the vocab, so this is an opening paragraph in the user guide at the moment. It looks like it's technical and this will be off-putting for staff who are not familiar with RDF. I don't think you need to be familiar with RDF because I'm not to use these tools but I can see that it will give some people pause if they're confronted with these sorts of instructions. So more work needed here. This is a mind map of the product release workflow for a vocab so far and as more user process there will be improvements and I've also not included the step to make the vocab visible on RVA. So working through the process as it stands, number one, so the policies expect that there will exist a domain community for the vocab content and a GA custodian who takes responsibility for the maintenance of the vocab. The custodian is expected also to get approval to work on the vocab before they start. They're also expected to discover if a vocab already exists and if it does, if GA needs to profile it. The vocab has created an Excel template and once completed the custodian emails are copied to the data catalog team and they also begin the data release process through the PMR tool. So the data catalog team converts the Excel to TTL and checks that it validates and then they push it into a non or push it onto a non-prod vocab page and the vocab reviewer is sent to the link so they can complete the review. And then once the PMR process has been approved, the metadata is published, the vocab is published and the Excel and TTL files are archived. So I'm not yet clear on what we should do for vocabs published elsewhere that GA users should be made aware of and what that workflow might look like. For example, do we just need an approval to publish a link on the register even though the vocabs held elsewhere that would seem to be the obvious thing. But the ongoing question is how we find out what vocabs are in use at GA that should be published or sorry that GA using elsewhere that should be published or if we should be pushing more that people should be specifically using things more of a mandate I guess from headed. I'm just going to run through an example of vocab that we're publishing from the boreholes database and apologies. I know you're all familiar with Voxel, Voxel template, but I'll walk through the content that we require and also what the reviewer should also be checking. So as part of the publishing and release workflow they need an ECAT ID before we can publish the vocab because that tells us that they've been through the approvals process. The custodian is usually a team. The metadata record in ECAT will have a person identified as subject matter expert. Providence in this example is the database table the information comes from. A description and title which will appear in the register page and the IRI for the vocab. In this example we've left the concept as it was given to us by the custodian with the underscore, but I wonder if there are any thoughts from the group on naming conventions for IRIs. So entering the concept is very straightforward and the only pain point if any is for the definitions. In this example the original database just repeated the name of the term in the definition. So by creating the vocab the team remediated the database which I think is a good thing. I won't go through this in detail but GA has vocprez as a vocab register and the vocabs are published through Github and we have a test dev and prod page at the moment which is visually confusing for the external users and it's something that we need to be remediating in the coming months. Once it's clear what the process meant to end is going to look like. So I said in the workflow before I showed you that the as part of the data release process the vocab reviewer is sent a link. So this is what they will see and so they'll be expected to go find the vocab and then look at the concepts and all the narrow concepts in detail. So they'll just go through this process hopefully. Check that everything works. The data and catalog team will check the IRIs are all consistent prior to transforming the excel into turtle so that side of it wouldn't validate any way I wouldn't have thought if they didn't and I think the landing pages provided by the register could include more information but there will need to be more research done before we go down that path. As I mentioned before in this example the actual database did not contain the definitions only label and alt label so this publishing process allowed them to update the database content. Now the actual vocab also has the page number that the definition was taken from in the field guide as provenance but it's not yet made it into the landing page and I'm not sure how it should so it's something to think about. This is a published register and as you can see there are no field geology vocabs as they haven't officially been approved for release yet. The team got caught up in another data release so we're just waiting on that and also highlights the similarity between pre-published register and the published register which will need to change. So in summary GA is gradually publishing vocabs persistently using voc prez. The vocabs are primarily a communication of the terms and definitions being used in products released by GA. These can be used by anybody but that's not the current driver. The vocabs are released using the standard data release process. The terms within a vocab and the vocab itself are persistently cited. The vocabs will eventually be discoverable at RVA and if we extend a non-GA vocab we obviously use the existing point of truth IRIs and then include the GA IRIs for the extension terms and that's we've used that already for the codelists for the 19115 metadata that we've got in our catalogue and some future ideas include using the IRI and the metadata records for codelists and keyword terms. Web service developers are working towards incorporating vocab links instead of a static PDF but this is not going to be quick and to have more metadata and help guides exposed on the vocab landing page for people to get a better understanding of what it is they're looking at and that's it in a nutshell. So are there any questions?