 Thanks for coming to this session. I'm Herbert van der Sompel, Los Alamos National Laboratory, and this is Michael Nelson, Alderman University. So Michael and I have worked together on a wide variety of information interoperability efforts over really the past 17 or so years. And we decided that it might be interesting to look back at what we've done to see whether there was some structure to the madness actually. And it's actually rather interesting because when you are involved in writing interoperability specifications, you work with people to arrive at the consensus about all that. You think that you're writing truth, that there's some objective truth in what you are doing. But in hindsight, you actually start seeing that these specifications come with an awful lot of attitude. They really start from a certain world view. That is the typically predominant world view at the moment where you create these specs. And so we're going to walk you through a bit of evolution of the perspectives that we have taken in various of these efforts. And you'll see us walk from a repository-centric perspective to a web-centric perspective. And in the web-centric perspective, we'll give two examples. One based on an RDF technology stack, which we call the descriptive kind of track. And then another based on typed HTTP links, which we'll call the navigational kind of approach. And for each of these tracks, we'll basically explain by example what we mean by these things. So the repository-centric one that Michael will do, that will be illustrated by the protocol for metadata harvesting. I'll do OAI ORE, which is an example of the RDF stack in the descriptive web-centric approach. Then Michael will do Memento, which is really all based on type links, content negotiation, things like that. And then I will end with a couple more examples of achieving interoperability using that approach. It's really the low-hanging fruit kind of approach, whereby we could start connecting an increased amount of scholarly notes across the web. All of this is based on a piece we published in D-Lib magazine last month. So feel free to leave the room if you want to see another session. It's all in this paper. Before I end over to Michael to talk about PMH, I want to give a little bit of context about research communication and increasingly also the research process itself moving to the web. So obviously it is a highly distributed activity and there's an increased amount of, I will call them nodes, think of institutional repositories, publishers, dataset repositories, software environments, etc. that are all involved in doing stuff for scholarly communication for the scholarly process. And to a very large extent, currently they're just all silos that sit apart from each other. Cliff talked earlier about, you know, moving, automatically moving things from one repository to the other. That's just one example of things that we are not really doing and could be doing. Okay, so here you go. I just lost projection. See that thing is there again. Just one moment please. Anyhow, what I wanted to say that achieving interoperability in such a highly distributed environment is quite a significant challenge. And it's even almost a unique challenge when you look at the web in general. And the reason is that most of the big web environments, you think about the Googles of this world, etc., these are not about achieving interoperability. They basically impose their rule on the world and then everyone plays by their rules. And we are in scholarly communication, not in such a kind of world. So in order to achieve interoperability, we really need to work with each other. At this very moment, I think to a very large extent, the only interoperability that we have reached across the entire scholarly system has to do with identification. Crossref DUIs, Datasite DUIs, Orchids, Cliff mentioned also. And one can see what this actually brings. You can see a whole bunch of services that relate to that. So this talk is about one can achieve interoperability in many kind of different ways. And we'll talk you through the ways that we've explored in the past. And we'll give a hint at what we think could be a best approach to achieve meaningful yet simply achievable interoperability across a wide range of scholarly nodes. So I'm going to hand over to Michael here, who's going to start with the repository centric perspective. Okay, so Herbert and I started working together in sort of 1998, 1999 time frame. And this is when we started working with the Open Archives Initiative protocol for metadata harvesting. And really, the idea is, at this time, we were aware that there were islands of e-prints and pre-prints that were surfacing. There was a lot of interesting content, but we needed some mechanism to stitch them together. And it was in this larger context of trying to, I guess, start a revolution, if you will, of open access. And that's why the first two letters are open access. But to understand how we approach this problem, you really have to go back and remember the bad old days, right? And so this is an interesting phenomena. Probably a lot of people in this room remember these days. But in the classes I teach, nobody remembers a time before Google and search as the predominant discovery, right? So prior to 2000, and even for a while then, search engines were really awful. They were not very good. And they didn't always help you find the thing that you were looking for. Moreover, we typically use directories as a mechanism for registering and putting something online. And most of my students have never used a directory. We talk about DMOS or something, and they have no idea what it was. The other aspect is storage was very expensive, right? So we have a sort of a standard graph of price per gigabyte falling. But in addition to this, network capacity was rare. So basically everything that we designed in digital libraries and repositories was focused on economics of scarcity and keeping robots out. Now it's hard to imagine a time when we want robots to come in, right? If Google doesn't index your stuff, you don't exist. But at the time, we focused on keeping robots up. If you remember the physics e-print server that ran at Los Alamos and then moved to Cornell, it would have a nasty thing if it detected robots downloads. It was going to launch an attack or something like that. I don't think that was ever real, but it was a frightening aspect at the time, right? So this is one of the original slides that we use for OAIPMH. And you can tell because Herbert was in love with Comic Sans and Great Background. So anytime you see those two things, you know you're getting a vintage slide. But when we talk about what OAIPMH is, there's really two things that jump out here. One is the focus on metadata. Again, rolling the clock back, a lot of things that were online weren't really online. We only had metadata records in the book, the report, whatever it was, only existed in hard copy format. If it was online, it was in PostScript or maybe PDF. And those were very large files. We didn't know how to index them very well. And really honestly, we didn't know what to do with 100,000 PDF files, right? Who had that kind of a disk space at circa 1999? So the other word on here is systems, right? In this case, systems really means repositories are really most likely SQL databases for which we build scripts that act as the front end. Those are the first class citizens in this world that we're operating in. Those are the viewpoint, the repository centric viewpoint that we operate with. So we're really moving metadata around, not the real stuff, because that's expensive and sometimes just doesn't exist. And we're really coming from the point of view of a database that's got a script and we call that a repository and that's our viewpoint on the world. So what we end up with is this kind of graph where on one hand we have, on the right hand side we have the data providers. Those are the repositories. And on the left hand side we have the things that harvest the data providers and those are the service providers. And we've defined six protocol specific verbs for how the service provider and the data provider can synchronize, how they can discover new metadata, updated metadata, etc. Right, so we come up with a custom based protocol that runs on top of HTTP but doesn't really use HTTP. So the idea here is in HTTP you have to again roll the clock back to circa 1999. We use HTTP but we don't really embrace it in the way that we do now. So Roy Fielding's dissertation only comes out in year 2000. The W3C web architecture document doesn't come out until 2004. The early RFCs have some of the concepts that would show up in those later documents. And you can make the argument that we should have sort of seen those things emerging, but the other thing working against us if you will is anyone remember Gopher and HTTP and Waze. And so we had this idea that transport protocols have this two or three year life cycle, we need to create a custom protocol that rides on top of whatever today's protocol is, but don't get too invested in it because it's going to go away. Well, the music has stopped, we're stuck with HTTP. It's our Fortran if you will, right? We'll be with it forever, but once you get okay with that you realize, well, HTTP gives us a lot of really good semantics. And if you don't keep it at arm's length, if you actually embrace it, you'll actually get a much cleaner protocol that results. So when you read the early OAIPMH documents, you can sense this discomfort with HTTP, right? We're using HTTP, but we're not embracing it. We're not being restful as Roy Fielding would later describe, right? So we have error conditions that are separate from HTTP error conditions and all kinds of things that you can actually, if you go back and look at the first versions of the PMH protocol, we're actually more restful. But then we consciously made a decision said, no, no, no, that's a terrible idea. We want to move in retrospect, we should have stayed with our first perspective, but that's how it is. And how we interact with the repository, remember those six verbs. Here's an example of a get record verb. And one of the things, this isn't going to be a lesson about rest, but one of the shortcuts is when you look at a URI, if that URI has a verb in it, some kind of action oriented verb, then you're probably doing remote procedure call and not rest, right? And rest URI should be nouns. And here we see a get record verb in the URI. And really this getting function should be provided by HTTP if you wanted to be restful, but again, we imagined all kinds of other transport protocols. And so we defined our own mechanism. The other aspect instead of just using the HTTP methods that are already defined is this notion of using links that are defined, okay? So in OAPMH we had the resumption token and basically that's almost a link, but it requires coupling between the client and the server because the client has to have the domain-specific knowledge to take the partial information returned by the server. And build that into a link. Now in retrospect, clearly we should have just provided a link, right? The server had all of this information, but that's not the way we did it. And that's one of our main regrets. So HTTP link is one of the fundamental building blocks that the web architecture provides. And that's not just the HTML links that we interact with on a daily basis, but the links that are actually provided by the protocol itself. So in summary, we approach this problem with a repository-centric view of the universe, right? If we go back to those directories that we had, you don't register 10,000 or 100,000 papers in a Yahoo or DMOS directory, you register your repository. So we had a very repository-centric view of the world. We use HTTP, but we didn't embrace it, right? We were not restful. We did not employ links and so forth as we should. Essentially, what we ended up with was a projection of a conventional bricks and mortar library. Just put that onto the web and had the same view of the universe. So then something interesting happened, fast-forwarding to the work that we did for ORE. And this what I'm going to discuss now in two minutes basically consisted of phenomenal shift of perspective in thinking about interoperability. As Michael explained, we were with PMH in this mode of repository-centric thinking. So it's almost like you sit in your repository and you say, okay, these people want to use my stuff. I'm going to put a little front end to it and that's how they'll be able to use it. For ORE, suddenly we turn things 100% around. And we step outside of the repository into the web. And we look to the repository from the perspective of the web. And the thing is, when you do that, when you truly work with the web, the notion of a node, the notion of a repository, not even a web server exists when you look at the architecture of the worldwide web document. The only things that really exist are URIs, resources with URIs, and there's the HTTP protocol, etc. And so basically, any interoperability problem that you're going to solve, you're going to purely use the fundamental primitives of the web. And they're all listed here, the resource URI, HTTP as the API. As Michael said, not transport a verb on your HTTP URI, but rather use the tools that the HTTP protocol gives you itself, head and get, post-put, delete. There's obviously the notion of representation, it's what you get back from URI, media type, link, and content negotiation. These are the tools. And basically, in the two examples that we're going to give you, both ORE and Memento, this is what we used with a little add-on. In order to define interoperability for problems that really are not trivial. But the core of the matter here is that you need to be able to think this way, to put yourself on the web, rather than put yourself in the repository, to be able to achieve interoperability in this way. So the first example is going to take the web-centric path, but using the semantic web stack, and that was ORE. ORE was all about a compound object, so it was the consideration that increasingly scholarly object were no longer atomic. But they started to consist of multiple resources that could be spread over the web. They could sit in one repository, two repositions, three repositories. They could be all over the place, basically. And so the question was, how are we going to convey the compoundness in a web-centric way? How are we going to express the relationships and the dependencies that exist between these objects? What is really interesting, and this is again one of these old slides. I started using a white background, I see, in 2006. And what you see here is the early depictions of the thinking of ORE. And in essence, this is PMH on steroids. This is now about 2006. There was really no excuse to still think repository-centric, because all the information was out there to start thinking web-centric. But the background in digital libraries led us to still make pictures like this, where you see the repository there with the objects inside. And then there is a harvest interface and an obtain and a put interface. All things that really exist in HTTP. What's interesting is just a few months later, the shift had been made. And suddenly, we are not seeing this picture anymore like the PMH one, with the repository at the center. Now we see the web. You see the web graph at the center of this picture. And basically what we say is, okay, all of these resources are things on the web that have HTTP arise. And the problem that we're trying to solve is somehow draw a line around the things that belong together. That's the compound object. And we also need to give that thing an identity, because we need to be able to refer to it. But you see that it's a web graph now. Yes, the repositories exist, because these things live in repositories. But it doesn't matter that repository. What matters is the URIs on the web. And so out of that comes the solution, whereby, again, this is from the old box. At the right-hand side, you see three resources that, according to someone, belong together. And this whole notion of aggregation, solving the aggregation problem, only takes two things, two insights. One is, well, we'll introduce a new resource. That's the A1 there in the middle. And that basically identifies the union of these three at the right-hand side. And then at the left-hand side, you introduce a resource that describes this fact. It says, there is this resource A1 that stands for the union of A1, A2, and A3. That's it. And all of this was done, in this case, with an RDF vocabulary that basically described these relationships. So when you look at the stack that was used here, it were these primitives that I mentioned before that come straight out of the architecture of the World Wide Web. And in addition to that, in order to achieve meaningful interoperability, type links, and the control vocabulary for type links, in this case, the ORE vocabulary. And this was done, in this case, based on the RDF, the semantic web stack, basically. Several other efforts since then have followed this kind of an approach. There's open annotation work that is still ongoing at the W3C now, a W3C provenance has done this. The research object work at Manchester University builds on these same kind of principles. This is an approach that is very nice to take because it provides you with very extensive expressiveness for description of things. So it's typically based on publishing documents that adhere to a certain profile. And in the documents, you find relationships, properties, et cetera, of materials of a certain kind. Mind you, though, that this is not the simplest kind of approach towards interoperability. You see it in the slow adoption of various of these technologies that I list there, actually, to quite a few players in our world and beyond our world. This is still a really big threshold to move from the regular kind of world, the normal things that they do to a semantic stack. Otherwise, a lot more of semantic fueled tools and applications would be available nowadays. So I'm going to hand over to Michael now to talk about another web-centric approach that we followed. So in about 2009, Herbert and I got together again. And we had sort of a similar aspect where at this point, we noticed there were several web archives emerging, right? There had always been the internet archive. It was the first, the biggest, et cetera. But now, because of the decreasing storage costs, lots of other places, national libraries, national archives, et cetera, could set up their own web archives. And we had this idea again of, well, let's do something to allow the interoperation of these archives. Let's find a way that we can glue them together. But at this point, instead of being a repository, or in this case, archive-centric view of the world, we had, as a result of the ORE work, shifted to a resource-centric view of the world. And the idea here is we shouldn't view the archives as a place that people go to spend an afternoon in the past, right? In the same way of a library, you go to the library, spend an afternoon in the stacks, find your material. That's not actually how people are going to interoperate with the web archive. What we wanted to do is make it resource-centric. So for example, here's an example of using Memento for Chrome as the browser. And on the left-hand side, we're on a web page. I can't make out which it is, one of the conferences he went to. And then in the middle frame, he clicks on a date button, and a calendar comes up. And you specify the point in the past that you want to travel to. And then in the right-hand frame, it's automatically gone and found the closest available copy. So in this case, we asked for August 1st, and we got August 15th, right? So we can't make something be archived if it wasn't archived. But if you have a desire for something in the past, we'll try to find the closest available copy across multiple archives. Now, the repository-centric view here is we're on the web page. And the user expresses an interest in this historical version of the web page. And the client is responsible for figuring out where those Mementos or archived copies of that page exist. So the idea here in Memento is to create a bidirectional linkage between the live web and the past web. So in this example, on the left-hand side, we have the original resource, URIR, the live web page. And its idea here is on the right-hand side, we have copies of that page archived. And in this case, it shows one archive, but it could be many different archives. From the live web, we don't expect the live web necessarily to know where all of the various copies are. But it points to a time gate, because in computer science, we solve everything with a level of indirection. So in this case, the live web resource has a smart friend. It's called a time gate. And we name things time gates and time maps, because we love science fiction, obviously. And so the live web points to a time gate. And it's the time gate's job to figure out, based on the preferences, using content negotiation, one of the core principles in the web architecture, to figure out which archive and which Memento archived version in the archives best suits your need. So in this case, we're flowing left to right, going from the live web to the past web. The other aspect is providing a standard machine readable way for the past web pages to link to the live web. So if you arrive at an archived copy, it can say, I'm an archived copy for this page, and I was archived at this particular date. And if you would like to go back to the live web, then you can follow this link. So what we're doing here is building up this bi-directional link between the live web and the archived copies. These things had existed as sort of ad hoc HTML interfaces, but they had never been standardized in a machine readable way, so the client could transition back and forth. So in this graph, the top half is still the same HTTP stack that we have, right? So we've got the content negotiation, we've got the core principles of the URI identifies the resource, and when you dereference the resource, you get the representation back. On the bottom part, what we're using here is not RDF and AL and all of those technologies, we're using the IANA registry for typed links. So we've registered links like Memento and TimeGate and TimeMap and so forth. And the idea here is now our client can transition through versions in the past and can make its way through multiple archives to different versions of the past web, different representations that have been archived. So at this point, we have turned the web into a distributed versioning system where we don't have to care about the implementation specifics of individual archives. Now this is roughly rolled up in a constraint on rest and lots of people know about rest but they don't know about the thing at the bottom called hate OAS. So basically, there's a lot we could say about that but basically it's called follow your nose, right? If you're at a particular page, provide the client with links so they can transition to another page. As long as they understand the types, they can understand here's where I can find a TimeGate, here's where I can find the live web version, here's where I can find the archived web version. And so the client doesn't have to have all the special knowledge like we had in the resumption token with BMH. The client can just make transitions. We do this all the time in HTML, right? I'm at a page and I click to go up to the top or I click to purchase the item or I make transitions from HTML pages all the time. We don't expect the same thing of our robots, right? We expect our robots to manufacture their own links and do all kinds of crazy stuff, right? So in summary, what we have here is Memento using typed links becomes the navigational API across web archives, across versioning systems, independent of individual archives. So the client can figure out where it is in Time and where it is in a particular web archive and then we've provided a transition for versioning for clients they can make without any specialized knowledge about particular archives. So this notion of providing typed links to let the client know where it is so it can follow its nose is the thing that informs our next forward-looking portion of this proposal. So the problem addressed by Memento, really a very simple extension of the HTTP protocol is not a simple problem at all. It had been outstanding for more than 10 years, actually, until Michael and I provided this solution to navigate across versions of resources on the web. And we did this with extremely simple means. I mean, Michael just explained, in the end it's content negotiation and typed links that make the thing work. So this led us to think, well, if we can solve that kind of a problem, a significant problem with these kind of simple means, then there's probably other things that we can do also. And we started to think of where in the scholarly web could we start applying these kind of atheists principles to tie all these nodes that play a role in scholarly communication and the scholarly process closer together. So do not think that what we will talk about now solves all of the interoperability problems. I'm talking about specific kind of cases, I call them patterns almost, that could very easily be addressed with very simple kind of technologies and we would achieve an enormous amount of extra interoperability if we were to do that. So I'm going to give you a couple of patterns. But first, let me explain what these type links really look like in a browser, well, not in a browser, to a robot. So this is the paper that we published in DLIP Magazine. And here we are actually doing an HTTP head on the URI of that paper. And you see there HTTP 200 okay, that's the response that comes back as is. So if you would dereference this URI now in DLIP, this would be your HTTP protocol header that the machine can read. But we can do better than that. We can now, for example, say, well, we're going to use a link header, you see that in the red there, that's a standard HTTP header. And we're going to use it to actually provide a link to my Orchid identifier. I'm the author of this paper, okay. And so we provide a link now, it's based on Orchid and it uses a registered relation type, which is called author, okay. So now the only thing a robot needs to do if it's interested in my profile is go to a paper of me, do a head and now follow the nose to this URI. So that's what we do now. So we're now in Orchid, we basically try to get this document. We're being redirected to the URI in red. So again, follow your nose, the robot goes on and now the robot does a get on the URI that came out of the location header there and here you see the profile page. And in there, I see my Twitter account, for example, and now basically just by having looked at the paper that I published, someone could tweet me, right. Fully automatically, a robot could send a tweet to me. That's the power of follow your nose. So I'm going to talk through, I think three patterns that one could address and create interoperability for. The first one is one that has been annoying me like forever and it's this whole notion of persistent identifiers like the DUI and then the splash page and then the stuff that sits under the splash page. And to this date, although we've been using DUIs for 20 years, no one really knows what identifies, what is the relationship between all these resources. So what you see here is a DUI on top and then there's three resources that are related to a paper, right. So you have an HTML version, a PDF version and you have an image. And then there's of course the splash page that sits in the middle there. And what we know today is that when we dereference DUI, we are being redirected to the landing page and on the landing page, there are a couple of links and some of these links lead to the things that are identified by the DUI but there's other links on that page also, right. They lead anywhere. And as Michael says, as a human, it's very easy to distinguish. You know, well, that's the PDF there. That's what I want. A machine has no freaking clue when it ends up at that splash page. It just does not know how to delineate whether A and B are part of this thing or are not part of this thing, okay. And so we can actually really address this. So the first thing, so we're going to start using these type links in order to clarify this entire pattern. So the first thing that we're going to do is we're going to say, well, the DUI URI, that actually is described by the human landing page. So just think of again, I'm going to add this HTTP header. Here you go. I insert a link and it basically says that, you know, the DUI is described by the page that you see there, which is the landing page, okay. And now we keep going. We can also put the link in the other direction. The landing page describes the thing identified by the DUI. Both these relationships exist actually, they're registered. I'm only using registered relation types here. Now you know the problem that you end up on the splash page and now you want to reference this thing, right. Well, what does everyone do? They copy paste URI in the address bar and you end up with 50% of references that don't use the DUI but use the landing page URI as it should not be. Well, actually one could solve this. There is a relation type that's called canonical and one could point from the landing page to the DUI and say, if you really want to refer to me, don't use the splash page URI, use that DUI. And the machine could actually consume that information and say, I'm not going to reference the landing page URI, I'm going to reference the DUI. Now this problem of what is in or what is out that you could address, for example, by saying, well, we're going to handle this landing page as being a collection. And all these things there are items in the collection and one item is HTML, another is PDF, and another is JPEG. We don't provide these item links for A or B because they don't belong in. So now a machine that is on your landing page looks at the HTTP headers. It knows which components are part of this DUI identified object or not. Next thing we do is we point back from these resources that are part of the DUI identified object to the landing page. And we do that with the inverse relationship, which is called collection. So this becomes interesting now, right? Because what I can do now is, as a robot, let's say I land on the HTML page, I can now climb up to the splash page and I now climb up further via the canonical or via the describes and I know that this HTML page actually has an associated DUI. This is really important if you think from the perspective of annotation, right? Because we're going to annotate the HTML page. But you would like this annotation, of course, to be associated with the DUI. Well, this is a way to do it in a fully automatic way. The only thing that your annotation client has to do is climb the hierarchy up. In the same way, we can now provide these links from the DUI to the authors, right? I showed you this before. And now, basically, just landing there on the HTML, you know, you can climb up and figure out what the orchids are of the people that wrote this paper. Obviously, you can provide that at the HTML page level also in the headers, but this would be another way to do it in the centralized manner at the DUI. So there's a lot you can achieve, you know, just using these couple of type links, you totally clarify this pattern to a robot. Next one, resource versions. Michael talked about it. Cliff actually talked about how important they are. And there are things we can do using the Memento protocol to clarify versions. Note that here we're talking about temporal versions, not semantic versions like the published, the preprint, et cetera. We're basically talking about versions in time. And the depiction that you see here basically is taken from ideas that Tim Berners-Lee had when thinking about this problem of versioning on the web. It's a pattern that you see very frequently on the web, actually. At the bottom, you see what Tim Berners-Lee calls a time-generic resource. And basically, it is a URI from which at any moment in time, you can obtain the then-current version of that resource. But then there are also, for the same resource, the time-specific resources. And that is basically where for every version, every temporal version of this resource, you mint a separate URI. And so this resource at the top there, URI M0, is active between time zero and time one. And then the next time, one time two, time two, time three, et cetera. This is a pattern that you see all over the web. You look at W3C specifications. They are actually identified in exactly this way. So now, again, using Memento, we can address this whole notion of, okay, I know what the time-generic resource is because I land there every day, right? But I would like to see what the version was at some moment in the past. For example, when it was cited, when this resource was cited in the paper. Well, this is where Memento comes in. Just this time gate link that Michael explained to you, towards this resource that allows you to do content negotiation in the time dimension. And I do that, and I end up at the resource and it was at some moment in the past. As Michael said, you can also turn around, you land up on an old version, and you come to the present, okay? So this is really temporal versioning solved by Memento. Only using type links and content negotiation. Obviously, you can interlink each of these resources also, right? These versions to be able to just traverse from one version to the other. I have a document explaining this entire pattern on the Memento website. In addition to that, Michael did not talk about this. Memento has this notion of a time map that provides an overview of all the versions of resource, provided in a standardized manner, okay? So I think a lot of versioning issues that we are discussing in this community can easily be solved by using this kind of pattern. I'm thinking about software repositories with a lot of versions of software. I'm thinking about data repositories with versions of data and so on. It's done. The last one, the last pattern that I want to address is this notion where people have started to basically write their code in public platforms like GitHub and then because they want to get credit for the software they wrote, they take a snapshot, they put it in Zenodo or what is the other one? There's two of those. Basically, they put it in another environment and they get a DUI in return that they can then cite. These two things are totally separate. So when you're in GitHub, you don't know that there's, well, as a machine, okay? You don't know that there's anything sitting there in Zenodo or in FiX share or the other way around. When you're in FiX share in Zenodo and there was a snapshot taken of a piece of software at one moment in time, you don't know what the relationship is with the original repository. This will be revealed to humans, but again, not to machines. So the example we have here is on the top there, S is the software, right? This is the time generic URI of the repository, the software repository. And at the bottom, you see three versions of it, S1, S2, S3. And here we have basically a researcher who decides, I'm going to now take a snapshot of S3. I'm going to put it in FiX share or Zenodo so that I have a citable DUI, right? And that's what you see at the right hand side. DUI, obviously again, splash page thingy going on. We've solved this problem in the first pattern. I'm just repeating this here. So now how are we going to reveal the connection between these two repositories and actually the connection between these resources here? What does relation types for that? First of all, we're going to use duplicate. Duplicate basically says I'm a mirror copy of the other one. So we can from the Z there point directly back to S3 to say I'm a duplicate of S3. And also in the other way around, you can say S3 duplicate to Z. Michael introduced to you the memento relationship called original to point back from a snapshot, right? A version to the time generic URI. Here you go. We use it from Z to S because that's the original resource. We can do the same in GitHub actually and just assume for a moment that GitHub implements memento, okay? So we now have all these original links pointing there. We have a time gate there, okay? And we can now do content negotiation in GitHub. Would be a very easy thing to achieve by the way, making GitHub memento compliant. Here's what I can do now. I am in fixed share, let's say and using these type links, I can immediately as a robot follow the link to what the current version of this software is in GitHub. I can also say, well, I am actually interested in what the version of this software was at some other moment in time and I can do that again using memento. I follow from Z the original link to S from their time gate and from there I do daytime negotiation in order to arrive at the version and it was available at some moment in time. These are pretty significant challenges and they can be solved very easily by using this kind of HATIOS technology stack. The primitives of the World Wide Web type the HTTP links. We're not the first to think of this. There's a very interesting paper which I'm showing here. This was a paper about using HATIOS technology for environmental modeling and these are people that are doing heavy computation in environmental sciences and they actually even talk about memento also but here they're not only talking about basically using this technology stack for navigational purposes but even to start pointing at process interactions I highly recommend reading this paper. It's a very interesting thing. I think we've come at the end of the presentation so we gave you an overview of what is basically 17 years of collaboration that we've had and different kind of perspectives on working towards interoperability. Moving from a repository centric approach where you take the node, the repository at the center of the universe you slam an interface in front of it and you hope that people will start using it towards a web centric approach where it's all about playing nicely with the web and using the primitive technologies of the web in order to achieve interoperability not with another repository but with the web at large and hence making it easier for robots to start using information that is out there. Obviously when we make information more easily usable, accessible, more easily navigatable by robots that leads to better services for humans. All right, thank you.