 First up, I'll give you a heavily unbranded slide, and that's because I actually wear two hats and I couldn't really decide what I was doing. So I didn't really want to brand heavily with either organization. So I'm doing this privately. So the two organizations I work for, the Open Geo Spatial Consortium and Surround Australia, where I work with Nick Carr and many of you know both of us. So the title was given was improving vocabulary, content and access, interoperability using profile and content negotiation by profile, which turns out to be a slightly huge subject. So I'm going to quickly go through a few things. Some of the things Nick's been working on and a few perspectives around the work I'm doing at OTC, in particular, which has been driving my involvement in this process. So introduction, well, that's me. So the first thing I'm going to presume that people are largely aware of this concept of fair, which is quite popular coming out of the European Union about interoperability, talking about things being findable, accessible, interoperable and reusable. And there's a link there to a write-up which will be updated shortly when we introduce the stuff I'm going to show you, which is the VOCPRES application, which Nick I think is previously described. And so there's a write-up there in a reference, we won't have time to go into much detail, but it talks a little bit about the nature of interoperability from those different viewpoints. And ultimately, most of those things actually are reliant on being able to understand what things mean, which means the idea is that there are pieces of information that can be semantically grounded. You can find out what they mean. You can follow somehow the metadata trail to a definition. But this actually implies that that metadata is fair too, that when you find the metadata itself, it should be findable, accessible, interoperable and reusable. And that's where sort of recovery services obviously come in heavily, preaching to the converted here. So I'm going to go into a little bit about the nature of profiling, because it may not be that obvious for my experience working with other groups, but it's actually quite a common practice, either implicitly or explicitly. Generally speaking, when you have a general purpose model, like SCOS or a DCAT or OWL or anything else, just try and get an addressing standard. When you actually try to apply it, you tend to come down to say, well, here's a simpler view of it that I need. And here's the constraints. Now, I'm not actually going to have multiple possible authors. I'm actually going to have one responsible author and it's going to be a member of my organization. So you end up with constraints when you actually implement anything. So from the fair perspective, profiles are easier to describe than a whole bunch of such constraints. If you have a whole suite of such constraints and you want to find data which follows them, how do you do that? It's actually not that easy, but if they form a well-known profile, you could potentially ask, okay, show me everything which actually conforms to the RDA vocabulary profile. Maybe more meaningful or show me anything which conforms to the Australian government geospatial data profile. Something like that is much easier to ask for than trying to detail all the constraints and try to match. Accessible means that the profile has a name. You can actually ask for the data, potentially by profile, if there's more than one option. I'll show you that in a second. Interoperable, it means that you can declare your intention to be interoperable across a suite of these constraints rather than trying to have all these constraints rather than trying to have to interpret and analyze all those detailed constraints, many of which may be written just down in words somewhere. And because they're named objects, they can be reused and they can also be inherited. One profile can constrain another profile. So I'm going to go into the deep side which probably Nick wouldn't have gone into. Which is the OGC view of the world of why we're interested in profiles is that we're aware that in the real world, there are lots of different types of information models. And we've really had a one-size-fits-all data modeling methodology for standards. But when the right-hand side, the implementations, people are doing different things with those standards with different levels of detail. And a really typical pattern is this idea that we get observations which are then aggregated into some sort of dimensional warehouse with a bunch of descriptive metadata with all our recoveries, et cetera. And then we want to use that. At the end of the day, we spit something out to the client at this far bottom right-hand corner who might then want to go back and find out what something actually means. So we end up with a range of different types of models on the left-hand side, this dimensional, how do we get to organize things. Then we have these general-purpose models like observations and measurements or SCOS or that. Then we have domain concepts which is where our control vocabruse tend to come in but also specific relationships. From the field, we tend to get very simplified message schemas come in which refer to those things but don't have a lot of detail about the model. And what tends to happen is we tend to bind the vocabruse to the data models by some sort of implementation profile which is our unit of interoperability which allows us to simplify the implementations which allows us to generate these sort of common schemas which include metadata. So allow us to aggregate simple data into these data warehouses. That's a really, really typical pattern but what we're starting to know and probably it sounds obvious but this middle tier of actually understanding what a profile is and the fact that it's actually a thing which people do in order to be able to use both general-purpose models and domain vocabruse consistently hasn't really been formalized in the past and that's again the work Nick and I have been working on is formalizing that. So I'm just gonna jump to a couple of examples if I can make that go away. Okay, so here's an example of a vocabulary which is a profile which is a asset description metadata schema and this is actually a profile of DCAT which it says down here for which identifies a whole series of different terms which come from other vocabruse which are recommended for use and declares just a few of its own where it says, okay, here's a particular one that we want to declare because none of the vocabruse we're profiling supplied. So this is a very, very typical pattern out there in the world and at the moment the profiling description is a document. This document is a declaration of the intent and there's a turtle vial or a vocabulary vial which generally speaking is just an aggregation of all these things come from different places. Really, really common problem. Okay, so that's just a bit of grounding the fact that profiles kind of exist in a real and what they are. The next aspect that Nick wanted to talk about was the role of profiles in particular around the publication of vocabruse. So the tool which I believe has been presented and is sort of reasonably well known vocabruse is an example of a model that, so a tool that actually uses a profile of SCOS. There's certain types of SCOS aspects that it's looking for. It depends on it recognizes and it presents those and sure enough we can walk through. And this is an example consistent with what we've just seen where this is a vocabulary extracted out of a data model. In this case, I'm a standard hydrology data model I'm familiar with. If I, but where it sort of becomes a bit more interesting is the fact that this data model itself may be available in different forms for different people. And so the idea of there being a set of alternative profiles which are available that you can ask for. So we can potentially ask for, this view of available profiles is itself a profile. It's called the alternate profile. But we can also ask for weird and wonderful things like showing me the class diagram for this particular resource. So that's a profile which is in a different representation paradigm but it's a subset of the data. We can also ask for, show me the L model. In this case, we showed me the L model as HTML or you can show me the L model as link data and JSON if I think this should be existing yet or we could show me the L model, no. So we have content negotiations, standard content negotiation plus this negotiation around what type of representation do I want. And there's an example here where this concept of punning comes up and the object is accessible as, this is actually a little thing I have to fix which is why this isn't live yet. That's actually, haven't quite got that bit right. So it's actually a visible as a vocabulary. So effectively, we take a SCOS profile view of the L object and say, right, every declaration is a vocabulary concept and we can look at it through the lens of SCOS through this tool. So that's VocPres and profiles interacting via and this concept of content negotiation by profile. And there are standards for each of these things and the definitions are available. For those via the link I had earlier the OJC definition server, which was, so this actually has links to all those standards. So it's actually reasonable, the good starting point for just understanding the concepts and the nature. There are also links built into VocPres, I think it talks about, I think it's got a bunch of, actually sorry, that's not relevant. I'll skip on. So there's another profile which Nick's been working on using the same link data API and that's a profile based on DCAT. So instead of a profile based on SCOS for documentation, it's a profile based on DCAT. And in fact, one of the things that we're in the process of setting up is a DCAT catalog of available profiles. So it's a little bit circular in eating your own dog food. As here's an example where the entry in the DCAT catalog is, so let me just go back to the root of it. There's a series of available profiles which are available and each profile itself has a series of resources or distributions which are available for themselves, which are available for this. And so that's another data profile and it's actually a catalog of profiles. So the ability to make these profiles reusable so that the content negotiation by profile is starting to use a bunch of reasonably well-known profiles is the work in progress. So at this stage we're at is that Nick's developed a whole bunch of profiles around his work Australian Government Link Data Working Group. I've developed a bunch of profiles around my work with the OGC in terms of what they need and we're currently looking at consolidating and categorizing which of those are reusable and which of them are idiosyncratic to our own organizations. So finally, this is an example of profiles being generated from data models in this case an application domain in agriculture. And we can see that this profile is a profile of a couple of different external models around agriculture and a whole bunch of resources are available, shackle constraints for the profile. So we can basically find a shackle derivation. And this is okay, that's kind of interesting. Profiles is also a way to find all the representations which is a kind of profiling of the underlying model. And there's also some tooling which is Nick probably wouldn't have gone here but I'll show you which is work I'm doing which is generating all these different versions of a vocabulary, all the different profiles automatically from the underlying information model as well as analyzing the external context and finding out what. So going back to our first pattern here, analyzing this and finding out actually what constraints does that put on decad? What constraints does it put on SCOS? And actually building the set of available profiles for that vocabulary, in this case a data model fairly automatically. So spitting out all these different flavors of profiles for a vocabulary. So that's a quick overview of a suite of interacting pieces that are held together by this concept of the profiles model which is our ability to say how does this set of constraints relates to another model or another set of constraints and what are the implementation resources which are relevant for a user to use that. So and then that profile model itself is then driving the presentation layer which basically knows how to do things with specific profiles and offer all the different profiles which may be available to the user. So it kind of links it all together. So it's been this missing piece of glue around all these different disparate practices about we have our models and we have our needs to use them in different ways. How do they all link together? And I think that's probably a good place to try to stop.