 Thank you for coming all of you. We are Apache annotator one of the newest incubating projects. I found these really cute PowerPoint slides that sort of look like you know comment bubbles so gonna run with that. This is gonna be a talk not only about the Apache annotator project itself but kind of the history of why it exists and how we got there some of the stuff we hope to do with it. We do have some code I think we're at like commit number 11 so just getting that started. We joined the incubator in near the end of last year but I have some history slides I'll get to momentarily. This is me at least online I'm Big Boo Pat. My real name is Benjamin Young but that's a super common name so this is how you can find me. I did not write a book on dating. I am not a sports somebody I think he's a soccer player. I don't know anyway there's lots of Benjamin Young. I am a Sousa Lucian architecture architect for John Wiley and Sons which means I'm doing both open standards and open source and that has in turn gotten us to Apache annotator which take a look at. I'll be posting these slides and these are links to all the various me's and all the various places. So my history with Apache goes all the way back to 2000 when I built a site on Apache cocoon which is still not in the attic which is great. People are still using it. It's an XML XSLT pipeline processing thing changed the way I thought about building web apps and and CMSs. Content comes in one end and goes through in number of pipes kind of unixie and then goes out the other end as HTML or SVG or a PNG or whatever. It's a super fabulous project. I have no idea where it is at now. This is the largest site I built at the time was like 6,000 pages for university and it was great and then I left and they rewrote it in PHP and you know whatever. Then there was a gap where I was running my own business and not heavily involved in Apache. I was too heavily involved in paying bills and then I got into Apache CouchDB and started contributing there and sponsoring events about CouchDB while I was running my own business. Joined some of the companies that Adam mentioned in his keynote yesterday. It was part of CouchOne, became CouchBase, left and did a CTO gig and then first start up and then joined Cloud, which became IBM or the other way around. Yeah, it's been great and somewhere along the way I got Apache CouchDB Committer access and haven't really had time to use it. So 2016, which brings us up to late last year, we decided to start Apache Annotator out of kind of what remained of the Annotator.js community. If you've ever looked into doing highlighting type stuff on the web, you've found Annotator.js at some point. It's pretty much abandoned and we'll go into how that all happened and our hope is to resurrect that in some form. So my history with Annotation includes finding Tim Berners-Liesl documents called Design Issues, W3.org Design Issues. If you're into the web at any level, these are great things to read. They're not specs. They're more his thoughts on how he was thinking when he designed it in the first place or what he would like to see now and they're great. They're all great documents. The web axioms in there are super helpful. URLs are opaque. How many of you believe that? It's great. It's a super useful thing. They're just strings that identify things but there's loads of stuff in there that can really help as you think through web development. If you do that, I hope you do. I built some CNMSs and lots of them and then I went to work for the Hypothesis Project and they're an open source nonprofit. They build a MIT licensed annotation tool but it's governed by the nonprofit and it's mostly designed internally which is fine. It's working for them and it was actually while I was at Hypothesis as their developer advocate that we decided to start this process of doing incubation at Apache around some of the core code so that there would be a longer lasting community that could persist beyond what may or may not happen to the nonprofit. We hope nothing happens bad to it. Nothing is right now. They're up into the right which is great. I'm a co-editor of the web annotation data model spec and the vocabulary specification at the W3C. That happened also while I was at Hypothesis. I had the opportunity to collaborate with the people there and design or continue the design of an annotation model that's very webby. You can distribute these things and they can re-anchor on stuff. There's ways to do and we'll take a look at the documents later ways to have anchoring strategies to make sure that you can deal with the change of the document underneath and things like that. A lot of lot of thought and work has gone into that. I helped write the testing framework for the web annotation protocol which is a way to distribute the annotations and then joined John Wiley and Sons about a year ago to help them move their existing annotation implementation towards web annotation as well as continue standards work and do open source on and on and on. So, Annotator.js, it was originally started by the Open Knowledge Foundation and then the Hypothesis project started contributing developer time and trying to really make that library be the canonical thing and they built hypothesis around that but then very quickly realized that the architecture wasn't going to scale and so they kept pieces of it and basically hypothesis is like a giant fork of Annotator.js. In the meantime everyone else who used Annotator.js ended up forking it because it didn't have a really great plug-in system at the time. So, if you really wanted it to do something idiosyncratic, which as we learned collectively as a community, everyone does annotation pretty idiosyncratically. There are reasons to do sidebars. There are reasons to not do sidebars and do stuff in the page. So, they did a fork. Lots of other people did a fork. Shuttleworth Foundation funded the initial hypothesis project. Also, a bunch of people on Kickstarter did and these three gentlemen here are the ones that really got it started. Nick Stenning is responsible for like the first 50 odd commits on that and then Aaron Carroll came along. He now works for Dropbox. Shortly after he joined Dropbox, Dropbox had comments, maybe related. I don't know if it is. Randall Leeds is also on the Apache Annotator project and he is previously a hypothesis as well. Both of these other two guys are listed on the initial committers list in our proposal. They're busy, so we haven't seen them yet. But the busyness of these three guys is why Annotator.js ultimately failed, besides the fact that it was forking. There's a big push-out hypothesis to rewrite Annotator.js as a new version that hypothesis could get off of its fork, basically, and get onto a community-built version, which was Annotator 2.0 that there's still an alpha release up for. Aaron and Nick, or not Aaron and Nick, Nick and Randall, banged out that pre-release version in Budapest while we were all in Budapest for a hypothesis meeting. And that's as far as I got because then everybody got busy again. So there wasn't any real governance that was outside of hypothesis for this project. There wasn't anybody to step up and say, hey, we want to use it, or like want to continue its development. But there were loads and loads of forks and loads and loads of people benefiting from it and enjoying it, but no clear way to give back to it. So covered a lot of that. Oh, but hypothesis also helped the creation of the open annotation working group, which eventually published an annotation model of itself, and then they also were instrumental in getting the W3C's web annotation working group started. Join that, hired me, I worked on the specs, and now we have the specs we'll look at later. Fractured, it's also got mixed licenses, the Annotator JS code. It's a hybrid, it's a dual license thing. jQuery did this a while ago, I think maybe they still do, where it's GPL and MIT, which is silly, don't ever do that. Like, the MIT is fully compatible with the GPL. There's really no reason on earth that you would also GPL it that I know of legally or otherwise. So it's licensed under both. So basically that means, strangely to me, that if you fork it, you can pick or you can also do a license. So what that means practically is that all the plugins pick the one that they felt fit their project. So half of the plugins were GPL, then half of the plugins were MIT, and if you're say IBM, you're not going to touch half those plugins. So you only get half the community, and you only get half the projects, and you can only contribute to half of it. So it was just weird, like nobody knew where to look, or how to be involved without running into something. The other problem was that because of the dual licensing and all the forking, it wasn't clear who actually owned the original annotator code. It was funded by OKFN, Open Knowledge Foundation, or just Open Knowledge now. But the copyright stated was SNCC, Stining, and eventually Aaron, and then the contributors, in which case if you're going to do a license change, you now have to go figure out who all those people are. You have to contact them, make the change. So it's related to the reason Apache Annotator doesn't have any code to start with. We started with a community, and we're birthing code now that there are people in the room. So it's a little backwards, and that was part of the holdup was working through, before we even did the proposal, was working through, is this possible at the ASF? Can you come here with just a community? If it's community over code, that seems okay. Turns out it is. But then obviously we need to ship releases for something. So we started coding, not just because we need a release. So there was also no driving impetus to give back to that particular project. Like we saw with Hypothesis, they essentially were a big fork of Annotator, and they had a governance model, and they had a reason to run it over here with their own governance. Whereas Annotator.js was this confused, tangled thing that was not clearly governed. It was governed by people who worked for Hypothesis. So like, why bother also doing it over here? And there was no real motivation to do that. The mailing lists were active. There's still several hundred people subscribed to it. But yeah, the BDFLs moved on, and it's up there rotting right now. So this was an attempt along the way to try and bring balance to the force, which was the, oh, there's supposed to be a photo there. Anyway, it's a picture of the OpenAnnotation.org website, which is not terribly pretty. So it's okay, Brooke. The spec development happened essentially in line with Annotator.js and was somewhat influenced by its architecture. Some of the same people were involved in both things, but mostly Nick and Randall. A lot of the specification stuff was happening, or did happen, by archivists and gallery people and scholarly education and stuff like that. So they didn't just solve the, I want to highlight some text on medium and leave a comment. Like, that's what most people on the web think of Annotation. It's like what Genius.com did for a while. Apparently, now they're a video company as of two weeks ago. I don't know. Weird pivot. So yeah, most people think, oh, Annotator is going to let me highlight stuff and comment on stuff. And it's true. It does do that. But our objective is to also deal with these scholarly educational, scholarly and educational concerns such as double blind peer review and portable student annotations where you've annotated as a student and you're wanting to give them to your teacher to review and or vet and or give you a grade on or you're collaboratively annotating as a classroom and building up your collective thoughts on Hamlet because you're going to discuss it the next week. Or you're the Vatican, which is where this there's another conference coming up and you have all these images that you've taken of all these giant things, these art pieces. And you want to be able to perhaps translate these texts that are illuminated. And there's another spec called the from the triple if I can never remember what all the eyes stand for interoperable image, something, something. I'll look it up at the end if anyone's really curious. But that is a spec for highly scalable images such that you can have an image that is of say the Mona Lisa stored at its actual size. And then you don't want to push that over the wire every time, right? So you get like a smaller version of it encoded. And then you can just scroll and zoom in. And it's only going to take your viewport and just give you that part of the image as you scroll in at different scales. So it's a way to deal with as gallery archivists and people like that want to be able to get all the way down to the paint strokes on the Mona Lisa digitally and zoom all the way back out again and be able to talk about each piece of that without having the like small Mona Lisa and the medium size Mona Lisa and the big like it doesn't work that way. That doesn't scale. So it looks a lot like mapping service at the end of the day. Like the experience you have with Google Maps is not dissimilar. In fact, the APIs look awfully similar. But these people were also involved along with the Skalcom people and the education people. So they addressed like loads of problems that most people don't even know annotation can deal with or is related to. And they tried to spec it in a way that could also deal with things like talking about part of a brain scan in three dimensions. Like we don't want to just say like this part of his head is broken. No, it's like this part in like XYZ index and and to be able to deal with pointing at stuff that we don't know how to point at yet. Like there's not a there's not necessarily a way to talk about certain things yet. So they tried to make it marginal modular enough so that you could target anything. Once those selectors is what we call them for the targets were specified. Once there was a way to talk about that part of the brain, then it can fit into the model right here. So we'll look at that soon. So that's the history kind of verbose. But it is suitable for production. It is in production. This open annotation spec. This is what Wiley uses. We do this for our editorial process. And this is what I'm helping to move towards web annotation, which was born out of this group at the W3C, which was chartered out of the digital publishing interest group at the time. I think it's in here. Yeah. And the interest group had published use cases for annotation, which cover some of the ones I just mentioned. A lot of them are related to the experience of online documents, web pages, but also the offline webby ish sort of things like e pubs and PDFs that we distribute online, but aren't themselves HTML. So we needed a model that could talk about stuff irrespective of the media type that you got. So you could have Tim Burner's Lee's information management or proposal, which is the document he wrote at CERN that said, I want to build this web thing before you even called it that, right? It's like seven, eight pages. You can find it as a PDF on Georgia University site. You can find it as an HTML file on his site. And then how do you how do if I quote that, which I do often? How do I re anchor that on all those editions, all those printings of that thing on the web or off the web? If I've downloaded that HTML page or have that PDF say on a Kindle or some other reader, how does it know? Well, you've got this annotation. Where do I put it? How do I show it on that? Does it even point at this same thing? Is this a version of that thing? So it was a lot of exploration around identification, targeting, selecting, specifying, good, good, good fun. I don't know if any of you have done specs before, but I highly recommend it if you're at all wonky in this regard. Or if you like just tech history, which is a hobby of mine. So the open annotation community group had been around kind of at the same time this use case document came out or a little bit before they've been built this use case document because a lot of the same people were in the digital publishing interest group. And then there was enough sort of sort of mass forming with hypothesis and the groups that they said, well, let's give it its own top level sort of project at the W3C. So W3.org slash annotation will tell you all these things. And so they took the community group, which anyone can be involved in, and then moved it into like the intellectual property safe zone of the W3C membership, where it was then kind of hardened and fleshed out as the web annotation data model. And during the charter of this group, which was like two and a half years, I guess. Yeah. So it built on the open annotation spec and burst the web annotation spec. I'm saying that a billion times because it still confuses people. Web annotation is the new one. So yeah, let's see what's next. Yeah, Apache annotator why I'm talking about all of this right now and not at a W3C event. The community needed these things, most of which I've mentioned before, they needed a shared space to collaborate because it still is not clear where to do that. We're working on that. People say I want to add, and this is the most common case, I want to add highlighting and commenting to my webpage or my online docs or whatever, right? I'm an open source project. I've published this great documentation, there be typos. I want people to tell me there are typos. I want people to help each other, you know, in the sidebar maybe or have a conversation or all kinds of reasons. So people find annotator.js and think, Oh, it's great. I download it and I put it on my website. And it works. Then I want to change it. So I'll go to the mailing list and wow, no posts since like 2015 and no commit since 2015. And where did everybody go? Oh, they went to hypothesis. Well, I'll use hypothesis, but hypothesis is either public service run by a non-profit and it's this MIT licensed massive thing that uses elastic search and I've got to run like all kinds of stuff to get the thing up and running. And so that's not what they want. And this other smaller thing looks dead. So where do they go? So we wanted to give a place where all those people, the hypothesis, perhaps the genius, how they continue to do annotation. The libraries that have annotation tools, the other publishing services, like medium and places like that, that have annotation tools to come and like, share their problems and fix the wider code issues with annotating on the web first, and then annotating elsewhere too, and like mobile apps and things like that. And we needed it to be a place where the ownership was shared. So when the BDFLs wandered off to do other things or got hired, the thing could persist and the project would live on, which you may have heard if you've been another Apache way talks. It's super important. We wanted there to be a shared objective. Everybody does it idiosyncratically, but if you do it as a Venn diagram, there's this big chunk that we can all share. There's a data model that's specified. There's a protocol that's specified. There's some code around this, but we want to put it in a safe place like the Apache Foundation, where it will get maintained as long as somebody wants to maintain it. And we can share making that happen in that circle of that Venn diagram. And then on top of that, people can be different, right? They can do, you know, in this case, it's really important that this person be able to do different color highlighting. Like one person gets 10 different colors because they're going to use red for the people and they're going to use blue for the places, in which case now they're starting to do stuff that looks like natural language processing. But what if the robot did the annotations, and then the person's just plus oneing them, that already happens at Apache UMA, which uses open annotation data model stuff already, but they don't necessarily have a way to display it on the web page. So if we build these tools, we can take UMA output, show it on a web page and then build interfaces, idiosyncratic ones that give you a plus one minus one on each one of those NLP findings. So you say, yeah, that's that's Brooklyn the person, not Brooklyn the place or vice versa. So there's all kinds of tools that can be built on this. And we don't plan to build all the interfaces. We plan to just build the tooling that can provide that. And we'll have some demos that are interfaces. But we're not doing the kitchen sink thing again, because that didn't work. Annotator JS had a file called kitchen sink JS. So yeah, it tried. So all that history and all that background has landed us with being the place that people are beginning to look to come and collaborate. So Randall leads mentioned early early on in this talk, and myself are Apache couch TV committers. So we knew our way around Apache. It had all the enterprisey safe zone things that a community would need. And it was a place that we could start fresh using his libraries because he eventually out of the annotator JS project, rewrote the anchoring libraries and anchoring is the bit that like takes the selectors and finds it in the DOM and either gives you a highlight or says it can't find it or turns it into an actual selection like you would do with your mouse, or the ability to flip that were given a selection that you just made. I want to turn it into a selector. He had small libraries like that, but they're just in his get up. And if he got here with the bus, they'd be over. So we're gradually moving those things in as well. So let's take a look at what a web annotation document actually looks like. So you can get a sense for what we're going to build. So interstitial is a fabulous word that more people should use. Marketers use it occasionally when they talk about landing pages that are in between things. Basically, interstitial refers to anything that's like compensatory, which is another great word. Yeah, and that cleared it up. So like ligaments and things like that are interstitial. It's the space in between. And usually it's the filling of the space in between to combine two other things. So annotations always sit between most of the time, a target and a body, which could be, in this case, the two totally separate things, right? You've got this page and then you've got a blog post that's talking about that page and it in turn is an annotation. So in the data model, there's no assumption that you're actually going to encode the body of the annotation, which would be the comment or the tags or the plus one or whatever. There's no mandate that it be in the actual annotation document, which means I can have an image annotate an image or I can have a video talk about an image or I can have a human being not accessible on the web annotated by a photo and things like that. It made it possible to talk about Mona Lisa paint textures with a Wikipedia page, which there weren't existing models for this so much. So interstitial awesome. So proof case, here's an annotation done with audio in the body. The ID points to the resource itself on the web and then there's some helpers basically for the interface to say this is in this media format. So be ready to play it or if you can't play it, just ignore it. If you don't know how to put this out or just link to it as a fallback and it's in French. So if your readers in English, let them know they're going to hear French upfront or Chinese or whatever. And then it's still targeting that page. So in this case, this is the audio version of that post we saw earlier. In the top level ID here, I'll come back to the context document in a minute, but the ID here is for the annotation itself. So you can also have annotations reference other annotations in a replying sort of fashion or I can annotate your annotation. The annotations all the way down. Take that too far really easily. And I have. So in this case, the body is maybe an HTML document again and it's targeting a very specific part of an image. This is not using the triple IF awesome as I was talking about earlier. This is using a thing called media fragments, which is a fragment identifier that can apply to images. There's also one for videos. So this is the XY width and height of square positioned at this XY on this two dimensional JPEG apparently. And so these things serve as hints again to say if you're an annotation tool that's looking for images, this is an image. And so you can expect that there's media fragment identifiers. And this is that part specifically that I'm talking about. I'm not talking about the whole image. I'm talking about all the Mona Lisa. I'm talking about her smile and this blog post or Wikipedia page is about Mona Lisa's smile. And so I'm targeting just the smile. It's kind of the idea. Mona Lisa's super small by the way. Yeah. And the starry night is like dinky. It's like 12 inches by something. I don't know. If you ever see them in person, they don't look as great as sometimes as they do in the book, which is weird. Mona's water lilies though. Like you can drown in those things. Sorry. CSS selectors. You use these all the time if you do any kind of web development. So we've exposed them here as a way that you can encode them because they're not encodable as a fragment selector. Right. You can't put it in the URL of anything. I mean, you can. You can. But it doesn't work. So in this case, this is what we call a specific resource. The target doesn't have an ID now. The target has a source. And the source is this page. So it's sort of like saying the Mona Lisa thing. But then like I'm focused only on her smile. In this case, I've got this HTML page, and I'm only focused on this ID, this specific paragraph within this space. And this is a great selector if you support CSS in the rendering engine, which, you know, Acrobat does not. So we need more selectors. So here's another one which presumes hierarchical markup language. But it works really great if you have XPath. And we have options for combining these. So if you are in a browser, your browser supports both CSS and XPath, and the developer implementing the reading or the experience of viewing the annotation can use both to make sure that it's in the right place. Can use either of them for optimization purposes. XPath tends to be faster. Not always. So there are reasons to record more than one. And here's a nice generic one. I don't know. We're back to body now. Yeah. We'll get back to selectors. There are ways to talk about just the text. As a text quote selector. And those are the most generic. But then there's other issues with those. So this is an inline textual body. You know, that's 90% of the comments on the web, right? The nice ones. And that's talking about a photo. So in this case, our format stuff in the language are talking about the body itself. It's in English. And it's an HTML annotation. By default, they're text plain. If that's a textual body with a value, the assumption is it's just plain text. Text slash plain. So there should be no markup in it. But I could make markdown format annotations that I could ship around as well. And there are ways to provide multiple bodies. So if you are doing a tagging system and also providing the ability to have a comment, then each one of those are standalone bodies that all are annotations of this target down here or these targets. Actually, there's more than one. So in this case, I'm talking about the Wikipedia page about cats and this particular photo together. And these things, both these annotations apply independently to both of those targets. It's the current meaning. So they both get the cat tag and they both get cat's heart furry, which is super helpful. And we have these purposes, which also have a thing on top called motivation. Those are essentially the same thing. And those are additional hints to the rendering agent for knowing that you're doing editorial with this annotation. Or that was your intent, right? You showed up with this annotation and cat is still just a textual body like the one right below it. These are the same types of things. They're both text plain, but this one here is tagging and this one here is describing. So if I only care about the tags, I can just look for stuff that had bodies that have the purpose of tagging. And if I'm doing editorial, I can ignore the things that are classifying or whatever. Here's one that has been passed around a bit. We introduced canonical and via. Via is actually from Adam pub and Adam feeds have this via thing where in an Adam feed, you can you can inline a post or part of a post and it has an Adam via URL that says, I'm not the whole post. This XML you just got that has like markup in it. I'm not the post. The post is over here. I came into this feed via this other bigger thing. I'm probably not even the whole thing. So we use that sort of like history chaining to be able to do offline first annotation. So in this case, this is a version for you ID that presumably was the original identifier of this annotation made in my browser. And I have since published it to example dot org and 20. And the original identifier got moved to the canonical one. So if I published it to 10 places, canonical should all be this identifier. So you can find them all again and do some deduplication. But the IDs could be retrieval points for any of these. So there might be a Twitter annotation ID, there might be a Facebook annotation ID, but they should all persist while they have to if they're doing the protocol, persist that canonical identifier so that when I get them back or you get my annotations in some way, you can dedupe them even if they come across loads of different spaces. The via one is also the service that perhaps this was relayed through. So it may have come through an Adam feed type service. So you actually got it from another hop. So it also had this other idea, other location at one point. Perhaps I sent it through mastodon and then that persisted it out to Twitter and whatever. And so now it's got this via chain that can be an array. And they're just other identifiers known about this thing. So it depends on how you want to architect it. But what this allows you to do is move annotations through lots of services and sort of like aggregate all those IDs as the thing moves along so that if you encounter any of its versions, you know, hey, we're all connected. We're all the same ID or all the same annotation. And here there's a review body. And in this case, I've defined the rights of the body. It's not the rights of the annotation. It's not the rights of the target. It's just the rights of the body. So I can use rights on the whole annotation, which is debatably copyrightable. I think most people say it's not for just this little Jason chunk. But I certainly can express the rights of the body. I can put that on target, but that implies an ownership of the target that may not be there. But I can still hint to the tool I'm talking about copyrighted material or not copyrighted material, but really legally, you should go check and make sure that the target is actually licensed that way. So let's take a deeper dive into the protocol. The biggest thing that protocol adds is a container system or a collection system. It's based on link data platform, which is from IBM and itself LDP to its friends is based on atom pop. So hence we were reading those documents to curb stuff from. And it is a simple get post put and delete way of storing anything in containers. And then there's more advanced stuff that LDP does. But we just needed the basic container bit. So we define this discovery mechanism that says the protocol lives here wrapped poorly. These links should be on separate lines. So it's a basic container. So if you have an LDP client, it can read these. But then it mentions this constrained by relationship that says if you do annotations on specifically an annotation container. So if you can do more awesome stuff with the stuff you find in here, please do. E tags for good caching. And then the rest is pretty standard stuff. The media type down here in the accept post header is saying that you can write to it. If you know web annotation document types, you can send that you can send it in JSON or you can send it in turtle if you prefer. Which is a RDF based triple expression thing. So annotation containers look like this, which are yet more JSON LD. How many of you know what JSON LD is? Okay. It's first time I mentioned it, but we've been looking at it this whole time. It looks just like JSON, except it has this little at context thingy in the top. And what that allows you to do is make all those otherwise Englishy strings that means zero to your software initially. And means zero in Mandarin. You can give them identifiers on the web from which you can potentially look up documentation, look up meaning in other languages, look up all kinds of stuff. That's all gravy. The biggest thing it actually does is make all of those longer URIs that have some ownership and persistence such that everyone can use those identifiers and not have collision around things like type and ID, which most of us use in all the APIs we've ever built. You can find out the meaning of total, but you can also be sure that we're talking about the total number of annotations in an annotation container in this context. So it's a really fascinating way to extend JSON to be moved around the web in very webby fashions with minimal collision and the ability to transform it into different JSON shapes and stored in all kinds of things like triple stores and graph databases or couch DB or whatever. So that is the sum total of a container. There are other representations we'll take a look at. But this is sort of the Atom service document if you're familiar with Atom. And it just says like I'm here. I'm an annotation container. The first page is here potentially the last page is here if you wanted to figure that out as the service provider. And I'm a basic LDP container and an annotation collection specifically. So another option is to inline the first page. So for optimization you a lot of times don't want to get the like oh yeah okay you're a collection super. Now I got to go get the first page of annotations. You want to do that in one thing. So you can send this preference with your get request that says I prefer the full representation. So give me basically the container and the first page because I'm going to just render those things right off. And I'll deal with pagination later. So this is the first page. The next page is linked to here. And that it has an ID for retrieval later. This thing is opaque. There's no definition in web annotation how any of your URLs should be structured. So if that doesn't look like the way you like to paginate things. No worries. It's a hyper media API. So if you say next and you give it a string we assume it's in a URL. That could say start key equals whatever if you're using couch TV and in key equals something else. And in this case the items are contained IRIs prefer contained IRIs up top. IRI is internationalized resource identifier. It's like a URI which can be in Chinese and whatever else. And so in this case it's just the identifiers of the annotation. So we streamlined it a bit. We're getting the collection and we're getting the first page but we're not getting the annotations. Those potentially are being gotten asynchronously and then populated in the interface or the database or whatever you're doing. But you can also include the whole thing. I think I didn't change that supposed to contain. I don't remember what it is. Oh, prefer contained descriptions. I just didn't update the URL. So this is a way to include the entire annotation out of the protocol such that you can get the collection, the first page and all the annotations in the first page and then just get to work highlighting. So you streamline it so you make fewer get requests basically. Here is another one which I think we've essentially already looked at. Yeah, the minimal container is the one we saw first and that's the default. Cool. So there are lots of ways to get involved in this project if I haven't just bored you stiff. The open annotation community group is back up and running and if you've never been involved in the W3C the community groups are the free and open way to do that. You don't have to pay a membership fee. It's actually a WordPress run site. You just go click join. You make an account. You say I'm not affiliated with any member. If you're not, if you are, then you've got to probably talk to somebody at your company. But if you're not, you can pop right in and you can read the reports and you can join the mailing lists and do all kinds of stuff. And we're continuing to discuss there whether or not we're going to do an annotation 2.0 and if so what that sort of thing. And of course, you're here at ApacheCon. So you can get involved in the incubating Apache project. The code is just booting up, but we have a really solid framework for developing. So we've got all the build kit in place. We're doing pure ES6 models. This is all like crazy, crazy hype cycle content, but it's cool. ES6 developed modules that you hot reload in Chrome or Firefox so you can have your console open and edit the stuff off your hard drive. And as you save it there, it hot reloads the page on the left or top or wherever you got it positioned because the dev server is watching all that and auto bundling. And anyway, out of the it's a mono repo. So out of that mono repo, we can package idiosyncratic combinations. So if you don't even have to use all of what we're going to put in an annotator, you can say I'm only doing as X path selectors and I want your DOM highlighter and I don't need CSS and I don't need whatever. Give me a bundle that's just that. And we'll also have the opportunity or option to distribute each one of those as MPM modules. And then we'll also be doing protocol server that code exists. We just have to go through the donation process. So thanks. Any questions? Yeah, right. Yes, that is covered. I didn't cover it specifically, but the model provides for it. Sorry for the screen flashing in this in this fact that targets can be multiple things as well as bodies. There are ways to say I'm a list of targets or to provide the meaning that you want to attempt a series of within a target you have selectors, which we saw back here. So you can have multiple selectors as well, which is one of the flexibilities that Jason LD model got us. So you could define the expat selector, which is most likely to break, right? Like if you move that paragraph, you're not talking about same paragraph anymore. So you would combine with this a text quote selector, potentially a broader CSS selector or something with a specific ID, perhaps, such that you can use those strategies to say I as the implementer, and this is where it gets idiosyncratic again, all of these have to anchor to the same Dom range thing. Or it didn't apply, like because it's an editorial thing, right? You're like fix this typo right here, not throughout the whole document, just this one. So if they made that change in the next version, you don't want that annotation to ever anchor again because you fix the problem. But then if it's changing on, like New York Times redesigns their website, you still want all your annotations to anchor on all the past articles, in which case you're going to use something more generic, like text quote selector such that if they move that quotation around in the page or, you know, mess up the Dom with all kinds of new webby stuff, that's okay. You still find the text in there. Or, you know, the terrible thing where they're not even providing the text in the page, they inject it later with JavaScript. And you don't have a stable Dom, so you use text quote selector or something like that. Researching all the cases for how to deal with change is something hypothesis has done a lot of. And they've said they would be donating some of this anchoring code. Some of Randall's libraries, his text quote selector one already does advanced diff match patch finding. So we actually have a bug in that because it doesn't conform to the spec. Text quote selector should find you the first version and his is already set up for fuzzy matching. So it actually drops in the middle and does a binary search to find the nearest match for you. And really that's a developer preference. Whether or not in your scenario, you want text quote selector to be to the spec and I'm all I only want the first one. Or I know within this space that just get me the dang highlight. I don't care if it moved. I need to find out whether or not this text is still here. Or I made my own little notes on this Wikipedia page that I've come back to maybe five years later. And I want to know that it's still anchors are I want to see it if it does and know that it's orphaned, if not, and then have something to do with it. Like what was I talking about? What was the quote again? And you can inline your quotations as well, which is one of the advantages of always storing the text quote selector, which is a shame I don't have an example of. But you you store the exact highlight and then a prefix and a suffix such that you can know like in a villanelle that you're talking about line five and not line six seven or eight. Yeah. And there's also data position and text position. There's a raft of about six, no, 10 that we defined. And then it can you can plug in anything like the media fragment identifier, you can plug in any known URL fragment identifier. You can also spec out your own type whatever. And there's a range selector that hypothesis done that actually made it into the spec during the process. But that's what the community groups for us to say like none of these selectors work for me. I have this new way to do it or I'm doing it on a media type you didn't even know about because it's a brain image or whatever. And there's also a way to refine the selectors. So say like I want this chunk that is the content of the page right now. And I want to refine it down to a specific thing later. Anyway, the selecting bits the hard part. But that's also the Venn diagram part that all annotation projects want to see solved. So we plan to have testing infrastructure for that to look at in these scenarios, this should do these things and give developers the tools to say, this has to anchor. You know, like try this if it returns false, then it's a success in the editorial case. But if it returns true in my like I want to see my highlights again case, then in that case, that's what they want. So but it's up to the developer. Yeah, long answer. Any last questions? One more. So yes, it is not in our repo yet, but I will give you a demo of what's going into the repo because Randall didn't quite get it committed. We are also putting it up. Sorry, this keyboard is buggy. And we are also doing what's it called? Somewhere in there. I'm also a gamer. And as you can see from my humble bundle and bundled in and Barger VG. Crap, I don't have the link handy. Oh, you know, where I can find it is the annotator wiki. Yeah, no. Good grief. Sorry. Anyway, find me later. I'll show you. But what the demo does is you can select the text and it'll show you the web annotation, like as you change the selection, you can see the annotation JSON document change shape with your selectors, multiple ones. And then in a recent Firefox, the crazy thing is that you can make your highlight control C and it puts the annotation document in your clipboard so that if you paste it into a thing that understands annotation documents, it will re anchor it, which of course, that page understands those. So you make your highlight, you copy it, you click off someplace, and then you just control V on the page and it re does the highlight. So we're also exploring like what is the annotation experience like across different surfaces. The our expectation is not to stay in the browser all the time. That's just our initial surface. So the hope is to also be able to make it possible. And the specs allow for this to pass annotations around over email. So I email you my annotations because there's maybe no place I want to publish them because maybe they're inflammatory or maybe they're not inflammatory. Maybe we're both trying to hide. So I send them through encrypted email, but you can still anchor them on the web page, because now they're your annotations. I sent them to you. So there are reasons to allow for all these different systems of moving things. But the anchoring bit is the hard part. So Plunker, that's what he used. Plunker. Anyway, there was one more question, which I'll answer quickly that you had if you still have it. Yes. So there are specs for pointing to well, two things. The web annotation spec does not do that. But we have the targeting system built in such a way that if those things are knowable of your resource, then yes, you can do that. And we're working with the and myself and Randall are working with the wiki media foundation to sort out how they do versions. And they do it well in that they have URLs for every single version. And you could just hit those URLs and get the past versions. So then we're helping them express those in a way that the annotation tool can discover that the one I'm on has a previous version by using link data to say, you know, I'm the working copy or I'm the published copy. And this is where my history lives. And then from there, they're in this order. And so there's great reason to say to write an annotation that says this version and this version are wrong in this history of 12 things. And that annotation actually talks about both versions. And says there's there's false data in these. We should find out who did that, you know, that kind of thing. Or these last five are wrong. Or this editorial thing is still wrong in all these versions, like we need to fix that. So what we need services to do, we as annotation people everywhere is just identify stuff better. And that's part of what's being explored at the digital publishing working group that's just spinning up the W3C is how do we do that portably across the web? Such that if I were to email you a web page, or what we're hoping to call portable web publications, that my annotations that I sent in a maybe separate email anchor to your copy and everyone else's copy in the same way, because it's known to be the same thing. And then how do you do that at like legitimately web scale? Easy problems. Yeah, thank you, everybody.