 Okay, so this tool, VockPress, is I'm not going to repeat the reasons why you might want a tool that looks or does similar things to what SysVock does, because VockPress does some of those. So, you know, why you want vocabaries and whatnot and how you might want a machine readable and or a human readable endpoint. So I'm not going to repeat that. So I would just say that this tool was developed in the last six months. It does a bit of what VockPress, of what SysVock does, it does some different things. And part of this meeting is actually, I think for all of us, including Jonathan myself, to work out the differences between these things. Okay, so about the tool, the code repo is there, and it doesn't have a SysVock.info style website yet. So there we go, but it has a GitHub repository. And I should mention that this tool has had a bit of input from Tern and Geoscience Australia in their development. Thanks for that, partners. So why it's developed is what I'll say I mentioned first, what it is, where it's deployed and future development prospects. Okay, so it was developed, it was triggered by, the very specific thing that triggered it was actually the way SysVock and not just SysVock, it's the underlying toolkits do multi-lingual tags and a few other bits and pieces. So there's some elements in the way SysVock displays things which are not super easy to configure, partly because of the elder underlying toolkit that SysVock uses. So it's possible. And when I was at GA, we looked at configuring SysVock to do some things differently, but it was difficult. So there was a specific requirement to deal with a specific set of display issues there, and that's what triggered the idea that might be something a bit different. The second sort of thing was that in the cases where we wanted to do things that have loosely termed vocabularies but are very not SCOS-based. So SCOS plus a lot of other things, we start to push the boundaries on what tools like SysVock can do, given that they presupposed on SCOS. Now, that doesn't mean that, again, that SysVock and others can't be tuned to do any of the other things they can, but it depends on how much effort's involved. A third requirement that came up recently was very strong organizational branding. So some deployments of vocabularies like in Queensland government, if they're to be considered official government websites, have to follow a very strict branding from the government, and that requires interfaces that look and feel a particular way. And to achieve very strong templating and branding, we thought we might do something a bit different as well. And now the final thing is a general point, which is templating for things, and I'll explain that more later on. It might be all you need in certain circumstances. And if you have vocabulary management covered, so again, SysVock reads vocabularies that have been established elsewhere. This tool does too. It doesn't help you manage them directly. It's a consumer of vocabs that are created and managed. And if you need a deployment of a tool to deliver vocabulary information where you only have a few types of things per deployment, so you want one organization delivering a set of vocabularies that are fairly similar. This is the kind of tool that you might consider. Okay, so let's have a look at it. So what it is. So it's a template-based front-end to SCOS vocabulary, or extended things, and I'll get to that. Yeah, initially SCOS can be extended. And it has been extended recently to deliver organizational information, so let me rephrase that, to deliver information about organizations and people that's not really SCOS-based, it's sort of SCOS-based, but it's really information delivered according to different data models, and I'll show some examples. It's templating a system, it looks like this. You take the RDF data, you feed it into Python's RDF management toolkit. That toolkit, in turn, feeds the data into PyLD API, which is a link data delivery toolkit, which performs some of the functions that elder performs, but it's a simpler toolkit. Depending on the request that's made, that toolkit will forward on the information it's got to a templating mechanism, a very simple one, and that templating mechanism will generate, it'll either generate a web page in HTML or it will just forward you on the data that it's got, depending on the request that you've made. And I should say that it's pretty functionally equivalent to what CISVoc does in terms of you're going and requesting either web pages or machine readable views of vocabaries or vocabulary items. Now, the per instance data model dictates the specific views of things. And what I mean by this is that if you've configured this tool to show you SCOS elements like concept schemers, collections, and concepts, then you would configure a particular instance to do that and that's what some of our instances have got. And that's really configuration in one of the underlying toolkits and in the templates that you use. And yes, I've said it's to be extended for organisations and people. Okay, so this is an example of what the front page of the Geological Survey of Queensland's vocab list looks like and the list you see there going down the page and getting cut off has got about 20 vocabs in it now. Most of the vocabs are their own and some of the vocabs are not their own, they're from Geoscience Australia and from the Commission for Geoscience Information and what Geological Survey of Queensland wanted was all of those vocabaries, whether they were their own or whether they were ones that they were interested in, being delivered in one place so that their own staff can go there and say, is the vocab I'm interested in this list or not? Now, it's an organisational issues to whether they put all the vocabs they were interested in in there or not, but they have the capacity to do this. And part of that is because this tool can read vocabs from a number of sources and so you can quite happily on deliver vocabs that someone else has published. So you could take a CISVoc published vocab and we do and on deliver that through this tool. Okay. Now, the exact Queensland Government theme that you see is used here. I suppose it's elegant and that it's unpluttered and whatnot. It's a normal webpage, it has to be a normal webpage. This is what the Queensland Government requirements are and the templating here is open-ended. We can do as much or as little as needed so we can exactly match the whatever themes are required. Now, of course, that puts an impulse on the developers to fiddle with these templates, but that is the requirement in this case is to exactly deliver certain content or content in a certain style. So this is a small GSQ vocab. It's the so-called ball holes types. And you can see there's coal and coal-seed gas, mineral, water, et cetera. And what you see here is just the top concepts and the concept hierarchy, which in this case, the one for one, there's only a few terms in this vocab, so it's very simple. And then if you drill down, oh, sorry, here's a big vocab, which is the Commission for Geoscience Information's contact type. And you can see the top concept here is contact and then it's got this concept hierarchy within that. Now, this vocab, I should point out, is delivered via CGI's vocab loaded into the ANS research vocab, well, sorry, the ARDC, Research Vocab Research Australia portal, which is then delivered in SysVoc. And what we're doing here is we're just re-delivering that same information by hooking into the data view from the RVA portal. We're on delivery. Here's just a particular term, a very small amount of information for this one concept. So the concept here is chronoscratographic zone contact. And then there's the definition, a contact between bodies of material having different ages of origin. Now, what's happening here is the template that you see in action is a limited template. It's only showing the information that it's configured to show. It's not a general purpose template that can understand any RDF property and then to display that intelligently. It's not at all intelligent, it's done. It only displays exactly what it's told to display. So this is limiting in the sense that if you have different data, it's not gonna know how to display it, but it's powerful in that you can exactly display it however you want to display it. So if you wanna make a incremental change to using not bold but italic or shift things around or whatever, any of those changes are available to you pretty easily. And that's, again, that's the goal. Here's the commission for Geoscience Information, not fully public yet, a list of vocabs that's sort of happening using the same tool. And again, some of these vocabs, Geological Server Queensland are also delivering. And yeah, there's, I think there's about 50 vocabs there and Alex who's on the call has been fiddling around with an instance of vocpres to list all of those. Okay, so I've mentioned it already, but vocpres is designed to render exactly what you want per deployment, it's just that you have to make it do that. So what we don't have is we don't have to fight a very complicated tech stack here to achieve outcomes because we don't have a huge tech stack. So we don't have to burrow through lots of modules of code to make some more changes. On the other hand, the compromise is that you get less out of the box and you need to customize what you want. This is an example of further customization. This is turn to Australia's research network delivering a Queensland government themed instance of vocpres, themed differently to the other ones you saw. And they've modified vocpres quite substantially to do a few things and I'll show those in a minute. And you can see here, they've got different information presented in different ways. Again, their vocabs are managed in RVA. Here is Queensland government, sorry, sorry, not Queensland government, turn delivering a list of people using an extension of vocpres that is not a SCOS-based thing. I mean, it is a SCOS-based thing in that there is a shell of SCOS-ness to all of this, but they're really important information in this vocabulary or listing is not really SCOS sort of stuff, it's people information. So here's an important person. And you can see that what you need to know about Nicholas Carr is his email address. And if I scroll down further, you would see other information about me that are not SCOS elements, they're other elements according to schema.org and according to the organization ontology. And you can make vocpres pretty easily deliver that, you just have to configure it. Okay, now another important point about vocpres is you can use any backend you like as long as you're willing to configure it. Now, we've already configured it to use IDF text files, text files or IDF files in GitHub, Fockbench, which is what the geological survey of Queensland uses to manage vocabularies or generic sparkle endpoints. So it's when the system connects to a generic sparkle endpoint that it's reading vocabs like that contact type one I showed you before, which SysFock and other tools re-deliver as a sparkle endpoint. This tool can just read that sparkle endpoint and re-re-deliver that information. This is a picture that was actually on the front page of this or the front slide of this presentation and it's on the code repository just to show you that there's vocpres in the red and it delivers a link data API, it delivers HTML web pages and it delivers a sparkle endpoint based on one of a number of potential backend. So you can have a vocbench with its database backend, you can have a generic sparkle endpoint or text files and it can treat those pretty much the same. Okay, so just a picture of the actual config that is in place in the geological survey of Queensland's instance of vocpres and what it's telling you in the first little bit is it's reading a whole bunch of vocabs from a sparkle source, which is the GSQ vocabularies and there's about 17, 18, 19, 20 of those. And so it's got a so-called source of a sparkle source to read vocabs from there. It's got another source, the RVA source that we've created to read vocabs from RVA. Now RVA has got hundreds of vocabs and so when you configure the RVA source, unlike the sparkle source where you just tell it, just read from there, the RVA source, you have to say which vocabularies with which ID you need to actually read. And so here you can see three vocabularies are listed. So this instance now is delivering about 17 to 20 vocabs from GSQ vocabularies, a sparkle endpoint and three vocabularies from RVA and it could also deliver text files if that's what we wanted or from GitHub. Okay, so now it runs on a pretty modern tech stack because it's only been built recently and a one that we like to use. It runs, it's built in Python three. It uses the Python RDF lib toolkit and it uses a ginger templates. Now because it's a Python thing and because it's a very small and single layer tool, pretty much any element of this can be adjusted. And recently we've had some adjustments to some of the underlying toolkits that this tool relies on, which we are also involved in development of. So it's not hard to push changes upstream. Here's just a screenshot of the Python RDF lib toolkit. It's a family of tools and this vocabularies uses everything in Python. It uses the core RDF lib tool. It also uses a thing called sparkle wrapper, which is just a little tool to access a sparkle endpoint also written in Python. And it uses PyLD API, which is the toolkit that we've worked on for a number of years, which is somewhat like the elder toolkit, which is a links data views provisioning toolkit. That's really a type of web application layer or web framework. Oh, I've presented already why I was developed. That's obviously a duplicate. Let me just check. Yes, I've presented that already. Okay, where it's deployed and why? Well, I think I've shown these already. So the Geological Survey of Queensland has an instance. That's the main one. It's work on that one that really paid for the development. And that one may and is likely to be extended to deliver their organization's lists, which they're busy building. Terrestrial Ecosystem Research Network. It has an instance to deliver some of its vocabs. Again, remember this is on delivery. They're already delivered in the RFA system. It's delivering their peoples and organizations lists as well. Alex is on the call and others could better describe where GA is up to, but certainly in some testing with delivering GA's vocabs. And the CGI vocabs, 50 of them, I showed a screenshot there before. That's, I think, in testing. Now, future development. And, oh, let me just check my notes. Oh, before I talk about future development, I'll go back a slide. Jonathan mentioned the work that's happened recently in SysFoc around assisting people deploy with containerization. So this tool, it could be containerized if enough, but it's because it's only, it doesn't have a database backend or a triple store. It requires one. I mean, you would have to have one that's already there or point to a remote one or something. Because of that, the deployment of this tool is pretty lightweight. There's not much to do other than pull the code down to whichever server you want to deliver it from, configure it and hit go. So it's delivered as a code repository with different branches that include different branding from different organizations. So we, for instance, have a very vanilla master branch, which is like a black and white delivery of vocab information. And then there's a geological survey of Queensland and a GA branch, which carry those organizations branding at the top. So if you want to make your own organizations implementation of this, you could really just look at one of those branches and see what they've done to configure it, which really just comes down to, you know, HTML and CSS changes. And we have this delivered in, I think, all instances via the AWS cloud. Therefore, we've got information on how to deploy this sensibly in even auto scaling groups in Amazon work services. Now, Jonathan mentioned config time. So it really depends on how uniform your source of information is for this tool. If your set of vocabries are very similar, like our geological survey of Queensland, you tinker with the templates and then you can keep adding vocabries all day and deploy very easily. If your source of information is more complex, like you've got very different shaped vocabries, then you have to do more tinkering. And this is what Alex and others at GS Science Australia have experienced. They've got vocabs of different shapes and they need to change the queries and change the templates to deal with those. And there's no easy way around that. I mean, this is what this tool is good at doing. It's good at getting you to dealing with the templates and the queries that you need to get whatever style of viewing you want out quickly. And per instance, there's a single place to implement most of the config, which tells the system where it gets this information from. And then there's the individual source configurations where if you decided tomorrow to read vocabries from a very different kind of source, imagine a relational database, you could do that. You would just have to add a new source component to this tool. Okay, future development. So all forms of SCOS vocabries, as needed, will be added, all the forms. So what we discovered, and this was part of the design reason, was that there are different shapes of vocabries out there and do we want to make them look different or do we want to beat them into similarity? This tool lets us choose. And so as we're encountering different styles of vocabries, we think about whether we want to cater for them or not. Do we change the data if we can? If we can't, do we change the tool to make the data display the same? Or do we just reissue the templates that the tool uses to display the data differently? Handling of vocabulary like collections at different locations, that we're already doing. So the organization and people this turn are coming out using this tool. And as I said, geological survey queries, that's probably gonna be the same. Something that I'm thinking about doing in Simon, you might be interested, is to make a graphical display of a particular vocab, the time scale vocab. And the way I'm thinking about doing that is to build a completely separate front end that looks just like the chronoscratographic chart. But when you click on each item, it then goes to a mini homepage for each object in the time scale vocabulary. And we could do that on top of Vokpres pretty easily, or SysVok actually, but Vokpres would be quite easy, I think, to accommodate such a radically different front end. I think the graphical front end like that for that vocabulary would be great. And I have a student and some money that might be able to be put into that task. But the main thing I'll stress is as needed, this tool's a very simple tool. It only does a few things and it does them simply and it's meant to do it simply. And things can be added to it as needed. But look, this is a delivery tool, not a research project. So we don't have grand ambitions to test out things necessarily. We'll do what essentially the customers want. And if that means delivering things exactly according to a particular government's required website template, we'll do that. There are a few issues that have been listed and anyone who uses the tool is welcome to list issues for us, the developers, me, GA, turn, et cetera, to deal with. Okay, that's it.