 I can get started. Welcome everybody and I'm glad you could join us today. I'm Cliff Lynch, I'm the director of the Coalition for networked information, and I will be introducing this session. This is one of the breakout sessions from the last day of week three of the CNI fall virtual member meeting for 2020. To remind you, the third week of the meeting is focused on technology standards and infrastructure. And this certainly checks all of those boxes. I would remind you also that there are a number of prerecorded sessions, as well as the scheduled breakout sessions that are part of week three, please enjoy those as your time permits. We are recording the session, it will be available later for public access. Close captioning is available. Please make use of that if it's helpful. There is a chat box which you're welcome to use throughout the session. There's also a Q&A tool at the bottom of your screen. You can use that to pose questions at any point during the session. We will address all of the questions after the presentations are complete. Diane Goldenberg Hart from CNI will moderate that Q&A session. And with that, let me introduce the session itself. We have two people with us who will be extremely familiar to the CNI community. They've been important contributors for many years now. They're from the Los Alamos National Labs and Herbert Von Disampel, who many of you will know from when he won the Paul Evan Peters Award a few years ago, as well as his many, many contributions over the years to networked technologies and infrastructure. The topic today is the fair signposting profile. Those of you who've been following this work for a while will be somewhat familiar at least with signposting, which is an idea that was developed some years ago to help with the discoverability of network scholarly resources, or indeed network resources more broadly. What's really interesting here is the way they've coupled the evolving ideas about the fair principles and their role in discovery. And certainly one of the great challenges of the last few years has been turning the fair principles into concrete practice. And they have worked out a way of recognizing those practices in a signposting profile. So I think this is going to be very helpful for us. And with that, let me just give a really warm welcome back to Herbert Martin and turn it over to Herbert to start the presentation. Thanks a lot, Cliff. That was really great summary of the motivation for the work that I've been doing with the number of colleagues in including Martin over the past couple months. So signposting itself is as Cliff indicated, not new. But with the fair signposting profile, we've basically gone from a couple of loose suggestions on how to help robots navigators call the web to a true implementation guideline on how to do so. And by indeed paying attention to the notion of fair. So in this cartoon that Martin will bring up now. You basically see the essence of what signposting really is about. It's about making the scholarly web more easy to navigate by machines and doing this by literally putting signposts out, like shown in this cartoon, like if you're interested as a bot in information about the author of a scholarly asset, follow this author sign. If you're interested in what the persistent identifier of this object is follow the site as sign, and so forth. So signposting. As we started it around 2015 always had this notion of, let's make the scholarly web more easy to navigate for machines. And just from the notion that landing page are okay for human users, you know they tell human users where to find the PDF or the data set etc, but they're absolutely not optimized for machine use. And this is where signposting comes in. Now signposting from the outset also as aimed for absolute simplicity in trying to achieve meaningful interoperability. It's based on, well, the big lesson learned from 20 years of doing interoperability work is when you don't keep things simple, things will not be adopted. When you have simple things then the chances for adoption grow significantly. So signposting is all about trying to achieve meaningful interoperability for machines to navigate the scholarly web in a very easy way. So the browser based follows the reds, he also hypertext as the engine of application state architectural notions. And it makes use of typed web links. Those are type links that are provided in the HTTP link header of landing pages. As we know them, and of the content resources that belong to a scholarly object. So link types that are being used in these type links. All are registered in the IANA registry for link relation types, and all of those are defined in formal specifications meaning robots can understand what each of these link types mean, and they are fully standardized via itf specs and via the IANA registry. So HTTP links are really used. This is not some marginal technology. This is used all over the web. And here you see a DPP, the URL on which an HTTP head is being issued. And you see the response to that HTTP head. And here you see a link header that actually contains three links on these different lines there under the linking. So if we look at the first one. That basically says that the resource on which we issued the HTTP head is available under this specific creative comments license. And the third link shows us that when we access the DPP to URI, then by default we will receive RDF XML as shown in the content type there, but there's also an alternative representation that is an other RDF serialization. The following there says that this URI on which we issued the HTTP head describes the city of Reykjavik because you see there the URI slash resource slash Reykjavik. That is the DPP's way to talk about the city of Reykjavik. And these are these type links used all over the web. They're actually really interesting because they work with HTTP head. They can be uniformly used for resources of all mine types. So not only for HTML landing pages, but for all the content resources that are of different mine types, you can use exactly this same approach. Again, because these links are accessible merely by using an HTTP head. No content transfer is required to see these links. So that means when you have massive resources like big data sets, or you have restricted content, you still can use this technique. These links, as I mentioned, can definitely be provided by value, as was shown there in the HTTP link header, but there was also a by reference approach, whereby a standalone document is published that contains a whole bunch of these links. And then that standalone document is being made discoverable, for example from the landing page, or the content resources, or both. These type links provide guidance to machines that are navigating the web and want to accomplish a certain task. And in order to accomplish that task, they will follow specific type links, you know, this one if I need order information this one if I need metadata and so on, and so forth. As I mentioned, signposting has been around since 2015. So what is new, what's really new is that we have turned these loose ideas of use these type links to achieve some interoperability into a concrete implementation guideline. This is a manual on how you can implement signposting. And it basically says, which kind of links, should you be providing for the landing page, and which kind of link should you provide for each of the content resources. The implementation guideline is targeted at platforms that host all kinds of scholarly output. So it's not only for data platforms as the notion of fair might suggest. It's also for institutional repositories publisher platforms. So basically, it can be used across all kinds of scholarly platforms. And the fair signposting profile, as Martin will show you later, has basically two levels. In level one, we provide a concise around a limited set of links by value in the HTTP link header. And that level two, we provide a comprehensive so complete set of links by reference so meaning in such a standalone document. Meaning that in level one, we are not providing a comprehensive set but rather a limited set of links is because there is a risk. If you would provide all the necessary links that your link header becomes too large, and that the web server would suffocate on them. Okay, so you want to avoid that. And this is why in level two, the links are provided by reference. Signposting definitely contributes to fair. It contributes to findable accessible reusable by informing machines, what the persistent identifier of an object is what the landing pages, where the content is where metadata is available that describes the object, where the persistent identifiers of the authors are, but it does not do this by means of a metadata format. It does this by means of these links, and hence by providing HTTP arise that machines can visit to find further information pertaining the object. Signposting also obviously provides contributes to the interoperability aspect of fair by providing all of this information in a uniform way. And it doesn't do this in a way that only applies to the scholarly web, quite to the contrary, it uses that techniques that are used in the web at large. While signposting clearly is something that requires an investment for these platforms that holds host scholarly content to implement right some investment needs to be made to implement the fair signposting profile. As I mentioned earlier, signposting has been designed to be so simple that the investment required is really minimal, and it is confirmed by certain implement test implementations that have been done in a minimal amounts of time. To create services that leverage this uniform signposting interface. Obviously, again, one will need to make some investment. But the good news here is that if repositories implement this if platforms implement this, then it means that the services only have to interface with one type of interface, not with a bunch of heterogeneous interface, meaning the barrier is lower, and it creates a level play level playing ground for the emergence of complimentary and competing services. Compare that with another approach to create service on top of repositories, which is basically saying, let the repositories just be what they are with the API's that they have all different API's and the central service provider will just deal with all of that complexity. It's so simple. And I see in a lot of European projects, this approach being taken. Unfortunately, the barrier to entry there is so high because the complexity of dealing with all these different interfaces is so high. Typically what you see is only one service provider can really have the resources to enter that kind of a market. So you have a monopoly and the sustainability problem in that case. And with this I'm going to hand it over to Martin, who will in some detail describe the fair signposting profile to you and actually even attempt a live demo. And so what I would like to do in the next few minutes is give you an overview of how the signposting fair profile can really work in the real world. And for the sake of this presentation, please bear with me for this abstract depiction of a scholarly object as it often is represented on the web. So in the center of this graph, you have our landing page. And for example, you have a persistent identifier that if you resolve that in your web browser you'd most likely be redirected to to a landing page of a scholarly object. On the bottom of this graph you see a number of metadata files that describe the scholarly object. On the top of it you see a number of authors that ideally have persistent identifiers such as an orchid, for example. And you see on the right of this graph, a number of content resources that belong to the scholarly object at large. So that's a very abstract way of looking at it. So for the sake of this presentation at Los Alamos National Laboratory, we went out and we installed a local instance in our infrastructure of the d space Chris system, and we also implemented all our signposting this the fair signposting profile in order to be able to give you a good idea of what can this actually look like in in reality. So for this sake, let me go switch windows here and show you my browser. If you navigate to d space demo dot memento web dot org slash JSP UI, you'll be able to to access this demo, this pilot implementation of a very vanilla d space Chris instance. The entry page of the of the system and a number of items that we have ingested into the system in order to showcase how signposting can work. So if I now just click on this link to show you the scholarly object representing our recent paper on the persistence of persistent identifiers of the scholarly web and I open this in a new tab switch to this tab. We see the typical d space landing page, describing the scholarly object, we see a number of pieces of information provided, such as the authors, the affiliation, the abstract of the work. And we also see that there's a, there's an item associated with this object, namely the PDF document that actually represents the actual paper. I can also click on this button here that shows full item record. And here I get basically an extended view of the landing page with more metadata provided about the item. I'll see that there's a license associated with the object. I also see that the object indeed actually has a persistent identifier right it has a do I right here. There's also a related data set hosted elsewhere that has an individual do I saw all these sort of pieces bits and pieces of information are available through the d space user interface. And again that's something that a human can fairly easily digest for a machine that's much harder to do. And of course also open this PDF document here in a new window just to give you an idea of. This is a real thing. This is our PDF document really representing the paper that we wrote right. So that's the sort of setup that we have established for the for the demo. And going back to my slides here. We've got level one for the signposting the fair signposting profile at level one all links pertaining to the landing page and also the content resources are conveyed by means of HTTP link headers. So if you do reference the landing page you will get a number of link headers in return, and those convey information about the scholarly object. So our mandatory according to our profile others are optional, the mandatory links here are indicated by the solid lines and the optional links for the dashed lines. And we see for example that a landing page has a mandatory link to its persistent identifier with a link relation type site s that Herbert mentioned earlier. Other links that are mandatory are links to metadata object describing the scholarly object with the described by relationship. And also mandatory is the link that would actually convey information about the type of the object. In this case, the type would be a landing page and we highly recommend the terminology from schema.org to to describe the type of the scholarly object there. The links are optional. So for example the link to the persistent identifier of the authors are optional in this level. The reason being is that we cannot guarantee that all authors have or even one author of an object has a persistent identifier hence we can't really make this link mandatory. The links to the individual content resources are at this level also optional and they're basically two reasons for this, some of which Herbert had already alluded to. It is entirely possible that your scholarly object has way too many content resources, and including each of them by means of an HTTP link in the response would just be too much right. And the other reason is that it's entirely possible also that these content resources are hosted on platforms that the publisher of the scholarly object has no control over. So we have no way of accessing HTTP headers and modifying what has been returned there. And those are basically the reasons why we cannot or do not want to make those links mandatory. So those are the number of links that are contained in level one when we're talking about the landing page, the perspective of the landing page. How about the perspective of the content resources of this object? Well, two different kinds of links that are also optional. One is basically the inverse of the item relation type. It's a way for content resource to convey I am actually part of this scholarly object by means of conveying I'm part of this collection. So that's a type collection link. And the other optional link for content resource would be to convey what sort of type it is so am I for example, a scholarly article or a data set. This would be other links there too. So if you, if you will notice that these sort of graphs also represent nicely the follow your nose approach in a way that if you recall the landing page had a mandatory link to its persistent identifier and let's say a do I. recall content resource one, for example, and I do convey that I am part of this landing page by means of the type collection and machine would also now know that my persistent identifier is what I should be using in order to reference the content resource one. This is the hopping following links and following your nose approach that machines can easily so do. Let's see what this may look like in practice. I go back to my landing page for my scholarly object in my d space repository. And if I can find my pointer, my mouse. Here we go. I copy the URL of the landing page command, and I use a terminal in order to be able to use the command line tool curl to send an HTTP head request against the URL of the landing page. And I'll see I get my HTTP response, including the response headers, representing information that is mandatory and optional for level one. So for example, I see a my site as link with the do I. I see a described by link here pointing at the metadata record. I see the link describing the type of the object. In this case it's an about pages landing page right and also see a number of optional links that we have included for example I have the optional link for level one, pointing at the PDF document in the relationship item. This is the item of this scholarly object. Both the authors have orchids so I can include those links here. And two more links that I want to highlight. One is the link for the relationship related pointing at the data set hosted a fixture in this case, and also another link that is not yet part of the profile but could very well be part of this down the road, which is the link to the, to the associated license document that the relationship license, the discussion discussion is currently ongoing whether that should be included online. So, realize I need to speed up a little bit so I go back to level two, which is where we as Herbert alluded to, where we convey all our links in a link set document so all the links pertaining to the landing page and all the links pertaining to the content resources are included in a link set document, and that link set document is also discoverable by means of HTTP links. So the, the notion of what is mandatory was optional has changed slightly from between level one and level two. Now for level two we see that they're described by links to all available metadata records as mandatory, and also the links to the content to all available content resources is mandatory in that level as well. For from the perspective of content resources, the previously seen optional links are now mandatory, meaning each content resource now has to convey the, the collection relationship, and also has to convey what sort of type it is so you can scroll the article, for example, you see new lines in this graph here so the dash dotted lines if you will, those lines represent cases. You're supposed to put those links into place, if and only if the conveyed information from the perspective of the content resource is different than what was conveyed from the perspective of the landing page. So the content resource and has a different persistent identifier than the landing page has, then you should put in a new site as link from the content resource and to its corresponding persistent identifier, right. So a brief example of what this could look like we go back to my link headers because here I'd already seen that my link set document is included in the HTTP response headers. I copy that URL, go back to my browser because looking at JSON on my browser is a little bit more friendly and increase the font a little bit. And here you see the links that document that was returned. I'll see my landing page and see the type of my landing page conveyed the site as link towards towards the persistent identifier, the two authors, my described by links, license link, my related link, and my item link pointing back at the PDF document. And also as mentioned the links from the perspective of the content resources are included in this document as well here conveying that this item is actually part of that collection pointing back to the landing page URL, and also as mandatory and level to conveying that it is off type scholarly article utilizing the schema.org terminology. With that I go back to my slides here and again and invite you to try it out yourself dspace demo dot moment of it.org slash JSP UI a very plain vanilla dspace Chris instance, not all that hard to set up. We ingested a number of scholarly objects that you know we're kind of familiar with in order to give an environment to test out our sign sign posting profile or fair sign posting profile. And I'll conclude this presentation that the quote from Luke pointing at the simplicity of this approach. Again a pointer to our fair sign posting profile and another pointer to a GitHub repository, where we invite you to provide feedback, and, for example, join the discussion about the potential inclusion of links to license documents to convey that additional information in our sign posting now fair sign posting profiles. So for that I'll end here. We're very appreciative of your time. Thanks a lot for listening we're most happy to to foster a discussion and answer questions that you may have. Thank you. Thank you. Thank you Martin and thank you Herbert for that wonderful presentation. Indeed, the possibilities with this approach, seeing very exciting. Indeed, and with that the floor is now open for questions I would like to invite our attendees to please enter your questions in the q amp a box, and our presenters will be happy to respond. So, just a quick question while we're waiting for attendees to type in their questions. Actually, Martin I was wondering, would you mind dropping the URL to the demo site in the chat. I have a feeling folks would appreciate that enjoy playing around with that site a little bit. And if I understand correctly, this approach is already in production right I mean are there are there organizations already making use of the protocol. So there's been early adopters of sign posting in general. And when you go to sign posting the dork, you actually will see a list of you know organizations platforms that have implemented early sign posting approach. When it comes to the fair sign posting profile. There's no real implementations yet, but there are things ongoing so Martin's experiment that he just demonstrated at dance. We are currently working in the context of European project called us cub on an implementation of the fair sign posting profile for the be to share platform, which is based on in venue. The basis of a Zenodo, and then there is enormous interest in implementing it for data first platforms also. So at dance we use data first, but there's other data first customers let's call it that are also really interested so I wouldn't be surprised that in the next coming weeks we start implementation there, but still very early days, the spec has basically been out only for, I think we started this three months ago, and it's been evolving still quite a bit recently. And then also kind of informed our decision to to install for the sake of this demo, a d space d space Chris instance because there was kind of the missing link sort of thing so we are very interested now and we have colleagues that are very involved in the development of the core d space code and so we're in touch with our friends and colleagues there to see how our lessons learned for implementing the first sign posting profile can be morphed and merged into into the core code of of d space and other platforms there too. Got it. That's great. Thank you very much. I appreciate that clarification. I see that we are a little bit past time here so I'm going to go ahead and stop the recording of the presentation but first I'd like to thank Martin and Herbert one final time for sharing this good work with us here at CNI really appreciate this presentation. I'd also to our attendees for making time to be with us here at CNI fall 2020 meeting we hope we'll see you back, but my understanding is that Martin, and perhaps Herbert for a little bit will be able to hang around if people want to stay back and ask questions or make comments please feel free to do so. Join the conversation just raise your hand and I'll be happy to unmute you. And with that, I will bid everyone a good rest of your day and hope to see you again soon. Bye bye.