 So, I'm Rob Sanderson, the Symmetric Architect out for the Vehicle Beauty Trust in Los Angeles. Dan, wait for me to talk about the double-explicitisation and what we've done and where we go. So, essentially, woohoo! You did it! By the way, everyone here, the work would not have been completed. This decade were not for the support of the community around annotation, particularly hypothesis. I annotate the community, the educational community, the media community that has been fantastic. So, term, Colt, wage, wage term is one of my co-chairs for the work. Benjamin Young, who has stored something in the back, wage, Benjamin, the coordinator for the specifications. So, thank you to the work of them. Can I, certainly, you're sort of in the group and group. Anyone else who I haven't seen already? So, thank you, thank you to all, Randall, here we go. Thank you to everyone who participated, so you're welcome to go from the start. So, for those of you who were not part of the work for the last nine years, what did you do? So, we published in February three technical recommendations. So, these are specifications with the same status as HTML, CSS, JavaScript, etc. So, this is the highest level, but the W3C. The data model, which is how to express an annotation and how to format it using JSON. The vocabulary, which is the semantics, the meaning behind all of the features of the model so that it can interact with that data. And the web annotation protocol, which is how to transfer annotations between systems, be they client and server or server server. We also wrote two root-root notes, so these are less formal, however, and no less important. One around meeting web annotations within HTML pages. So, if you are the constant creator and you want to provide annotations that you've selected as being interesting and important to your audience, how do they become interoperable in this way? One of the other aspects that we thought was much broader than just annotations was how to select or describe regions of web resources in the state of the web resources. So, we also published a note to say this is how you can use some of our technologies in other contexts. What else did we do? So, one of the wish lines for getting through the specification process is that everything means to be tested and implemented. So, we came up with more than 350 JSON schemas to help the developers and product owners to test their implementation starting with the broadest, there's just an annotation at all, does it have a feature. I'm going to have to go quite quickly through these 350, just a minute. We tested 12 implementations that planned compliance, which was very helpful. So, it's mostly green, a few red fails for things that were required in a couple of implementations. The requirement that we've received is that there are at least two implementations for every feature. As you can see, we have far more than that. So, that was also great. We knew to get up, take the people in the room, for managing the process and for publishing the content. So, we tracked all of our comments and criticisms and suggestions as GitHub issues, and we got through 260 sites of them. We're going to get up and we'll see where we're at next year, and you'll be able to see everything that we did. We took the very conscious and deliberate choice to do everything in public, which worked really well. As for the previous discussion, it was important for the commitment. We also engaged with some of the W3C groups, some of which would be very interested in the current discussions. So, particularly, we spent a lot of time working with the internationalisation group. How can we ensure that annotation technologies are fully internationalised, such that if you speak Swahili or Zulu or German or French or English, that you can still use the content that is being provided. You work with the social web working group. So, this is another group that was working at the same time as us in a similar sort of area, and we borrowed or used very rapidly some of their technologies, their technologies are compatible with the group that we completed. So, we were very happy that this was not an arms race or a competition to see if we could do it, but a lot more collaboratively. Security. Well, it's just the security implications of annotating the web. So, we worked with the security group to ensure that our specifications were not opening up holes that people could drive with a max truck of hacking through to get access to predictive privacy, and very important, particularly for annotation and the distinction between student anonymity, anonymity and full identity is important, and what are you giving up by annotating and what can you expect from annotating. Critically important, as Tim Berners-Lee says, the power of the web is in its universality exists by everyone regardless of disability as an essential aspect. How are annotations accessible, what can we do to make them more accessible to people both in the creating of them and the consumption of them. So, what didn't we do? Well, it seemed like we didn't sleep too much, but you probably don't care about that. What we didn't work on was authentication and authorisation. These are the common concerns that apply to every single evidence that should be protected, particularly if you need to create things in other people's servers. We didn't, well, we discussed, but didn't formalise groups or user group modelling. So, this was very interesting. However, the different requirements of different organisations didn't lend themselves to any single model that we did with it. We also didn't work, given the constituency of the group, on browser-level APIs. So, there was discussion around a client-text API, which is essentially control-left. How do you find, in a better way than just the exact strength, the text that you're looking for in a web page, such that you can then attach an annotation to it? So, we came up with the draft, but when we shopped it around to the big browser vendors, it was less engagement than we had hoped for. We also intended to do browser-level annotation and creation and management APIs, such that developers wouldn't have to worry about browser extensions quite so much. We did not get through that. So, mostly, those were set aside because of the constituency of the group rather than the left interest. If the browser guys aren't there, we're not going to tell the boss. So, what now? So, the working group formally closed in March of this year, and all of the issues and further discussion has moved over to a community group. So, for folks who are less familiar with the W3C, working groups are restricted to members who have paid up and used, but community groups are open to everyone. So, if you would like to participate and discuss how we can move this forward at the sort of web infrastructure standards level, please do join the invitation, open invitation community group, and that will be the forum for where we can, as a community, make progress until we get to a community group. So, a little bit of history then. A community group was instrumental in the formation of a working group at the time we were the fifth largest community group in the W3C with some 200 people. We were behind things like the mobile web and the automotive industry, but beyond that, that's certainly something which was seen as extremely important and clearly still is. So, yeah, please do participate. This is the opportunity to ensure that your voice is heard and that we get the richest and broadest set of requirements in your spaces for many of you to work. So then, what next? The community group is now. So, gathering and discussing new requirements, discussing issues such as groups that we postpone to work and so on. So, if we can find out where the group is, where people are excited to work, we can then focus on those areas, make progress, and then propose a new working group to get back into the standards track. However, community groups can also produce draft standards. This was particularly successful recently with the Jason LD community group that essentially broke the standard. The working group appeared said there's the standard, we're done and we're done. So, it's not that community groups can't write specs, they just can't formalise them. So, with any sort of luck, we could work together to build the region 1.1 with the specifications that address the issues that are concerned and then finally push that out to a new working group in the future. So, that is where we are and where we are going and I think you very much have your attention. I have a new year's resolution to never ask for questions because that implies that I'm somehow your expert and that's not true. What I would very much like for us to do is to continue the discussion that we started earlier about how we can do this together. Thank you all for your attention.