 Good afternoon everyone. Welcome to this thematic session on librarians. My name is Michiel Jong, I'm from the Delft University of Technology, and I will be the session chair this afternoon. Yeah, just a quick notice. The presentations will be 20 minutes each. After 15 minutes, I'll give the speakers a reminder that's five minutes remaining, and then hopefully we can build in some time for questions at the end. If you have a question, feel free to come to the front and grab one of the microphones. They are all supposed to work, or if you feel more comfortable shouting your question to the front. That's fine with me as well. If the speaker can't hear you, I'll repeat the question for him. And with that, I think it's about time that we start. So our first speaker for today is Axel Klinger from Hanover, Germany, and I'll leave it to him to introduce himself. Thank you, Axel. Yes, thank you very much. Hello everyone, and good afternoon. My name is Axel Klinger from the Technische Informations Bibliothek in Hanover, Germany. And I would like to present you our recent project on open medication resources, which is about an open medication resources search index, abbreviated as IRC. And this is a collaborative project between the University Library Center of North Rhine-Westphalia and Technische Informations Bibliothek in Hanover. So, getting into a short agenda, it's about what I would like to tell you. What is the IRC? Why do we need the IRC? And as well as how to extend the IRC for further repositories. And then one of the current topics that we have is internationalization. So how to bring together international multilingual, cross-lingual repositories. And some view on a kind of repositories that we have in mind, which is based on GitLab. So first of all, the IRC is a light-white search index where we connect different heterogeneous repositories from all over Germany for now, and which is available at IRC.org on the web. And the thing is about the technology stack that we have an elastic search, back-end, a reactive search, front-end, and there's a connection with MetaFacture to have an interface to connect different repositories as well. The whole project is open-sourcing, could be reused for other projects as well, if you are interested in building a regional search index, for example, to harvest information from learning management systems or regional university repositories. So you could just set up an equal search index and connect this later on, again to the IRC, for example. So why do we need an IRC? When we first started to create a regional repository for the universities of Lower Saxony in Germany, then we saw there were a lot of other repositories as well, arising from federated states, universities, and so on. And the problem is that with every new repository that comes ahead, the effort for teachers is getting more and more hard to find the right resources for them as they have to search in different repositories. So the idea was to bring them all together to have one entry point for search. And that would also be a benefit of each repository if we don't have multiple small repositories with a little amount of content, then it's not relevant enough. But if we bring that all together to summarize it, it would be more relevant for teachers to find stuff for their subject, their topics, and so on. So just one example is our local repository, which is called Twillow, and available at twillow.de, which is for Lower Saxony and funded by the Ministry of Science and Culture in Hannover, Germany. This repository is hosted by the Technische Informations Bibliotheque as well, and that is just one example that is based on Edu-sharing, an open source software which is a content management system, or let's say a document management system where teachers can work together in a closed workspace and later on publish their work as open educational resources with the right license. And in the same way, there have been a lot of other repositories from universities like Darmstadt or Düsseldorf or other federated states in Germany, like Bavaria or Nordstein-Westphalia, Baden-Württemberg, for example, and those need to be brought together in one place. And that's the idea that we had our current approach to create a network of open educational repositories, educational resources repositories. And it's not about just a hierarchical structure where we harvest all the repositories, but the idea is that we bring it back to the repositories themselves, that they could include the overall search index by carrying an API from the search index. And so this is what we have tried out with Twillow or Orca for Nordstein-Westphalia as well. They just call all the search queries directly on the earthy and bring back the results of the query into their front end of the repository. So that's the idea to have some kind of bidirectional connections between repositories and the search index. Just about a few words, how to extend this earthy search index is that we have in the main place the modular ETL import process, which is based on the MetaFacture framework. And there we have some kind of domain-specific language for harvesting repositories, which is great if we have similar kind of repositories like multiple instances of Edu-sharing, for example, we could reuse those scripts in order to have a lightweight import process. And the other way that we also use is just having other scripting languages. In our case, it's mostly Python that we use to connect to repositories that are not standardized, that don't have an API, for example, or a sitemap, and where it's a little bit harder to pass the content, which is very individual. So both it's possible to bring in new repositories. And if you have any idea or suggestion which repository could be great to be integrated in some kind of global index, then just use the contact form and get in contact with us. We will check what is possible to include university repositories or other regional repositories as well. So getting to the idea of internationalization, we see that within the German repositories we already have different content in English language, for example, or some content also in French or Italian language. And the idea is to support repositories from outside of Germany as well and also different languages to search across the languages. And the idea is not to translate the content of the Open Educational Resources, but to map the search query by finding the same search term in another language. And this is not done by translation in our case, but we all only use the query of wiki data or the mapping that exists in wiki data. And for all the keywords that we have in the search index, we query all them from wiki data, look what mapping is existing between those languages. And then we can search in one language and get out content of Open Educational Resources also in different other languages. So the current state of this approach is that we have supported the translation of our user interface and vocabulary as well by getting some kind of first version automatic translation. And later on we have curation process for the user interface and the vocabulary for subjects or resource types. And we have translated both of those components in German, English, and last month also in Ukrainian language. And for the keyword mapping, this is a completely automatic process where we don't have any curation because it's about 30,000 to 40,000 words that we have translated. But those are done with a simple automated process and we have regular updates to get new translations or updates of the existing translations as well. And the first approach shows that we have a coverage of about 60 to 30% for the more widespread languages like English, French, or Spanish. And even for the smaller languages like Dutch or Danish or Ukrainian, we have about 45 to 55% of mappings for keywords, which are mostly the keywords that are more used than others. And this is our first approach and we try to get better with this by optimizing the set of keywords that are selected by filtering some kind of keywords that are not set that much relevant for this. And so we also try to minimize the time that's necessary to translate the whole application into other languages. So you could, even for now, try out the result of such search by, for example, the word climate change that we have as an overall first example, but you could also type in some other subject topic, whatever, to find out if there is a matching search result on this. Just for the example of climate change, we get about 262 results in different languages. Then you can choose which language you would like to have some content in. So that could be helpful for international students who would like to go to another country, need the related subject specific content for their own subject or a specific topic. For example, yes, that's the current state of the approach of internationalization and just a few words at the end I would like to have for a different kind of repositories that we connect to. So one of these examples was that we use either sharing for our local repository, but we also have some approaches on using GitLab as a repository or backend for open educational resources. So GitLab is an open source version control system that's mainly used for software projects where we can store and have different versions of source code, but we could also use this for files, text files like Markdown or LaTeX that could be used for any other kind of interesting materials, not only for teachers, but also for students. So for example, we could start with a thesis as a student and later on use it for projects to work together and collaborate on this platform and we could create textbooks or interactive course materials as well on GitLab and later on bring those materials directly by harvesting GitLab instances into a central index like the RC for open educational resources. Just to give you a short example, how we have done so is that we have some experiments with old thesis, for example, from my side where I just tried to write it down in Markdown. I translated an old thesis from a work document within two or three hours it was into Markdown file and later on from Markdown I can generate HTML file, a PDF file or even ebook files in the EPUB format to get some more modern format of output than only the PDF form which is paper based and not that good readable, let's say, on mobile devices, for example. And we can also use those output formats as templates in order to prepare the technical process for also other teachers who are not familiar with GitLab and the technical processes. They just need to copy a template project and can then fill in their content and easily create the same interactive results for their courses. One example I also would like to show you here is a very simple example from the framework of LeaScript. LeaScript is some kind of interpreter where you don't need any extension in the GitLab project, you just need a Markdown file and if you point to the URL from the raw Markdown file and put it into the LeaScript website, you will get a rendered course material and there are a lot of examples on the website of leaScript.github.io that you could easily reuse and just try out to make some interactive courses with interesting features. One thing to think about if you use or think about using GitLab as a repository is that we also need some meta data in order to find the materials, the right repositories to include into a search index. And that could be for example, that we prevent a simple text file like a YAML file but it's hard to write it down by hand and so maybe we can just provide a simple form that we do with the GitLab page that could be shared in other projects or in a template file to support the authors by bringing in the necessary information that we will use for the RC to bring together all this harmonized meta data. That's just one proof of concept but it could easily reuse in other contexts as well. So just a few last words that I would like to give you is how to contribute to this project if you're interested in extending this functionality. So the easiest thing is to just context us for questions, feedback, suggestions by the contact form on the side of RC.org or if you're a more technical person you can rise an issue for a feature request or a bug report or even contribute to the project by as an open source project by just creating a pull request for this. And if you're interested just contact us for reusing or integrating RC in other platforms that would be even interesting for us because we would like to spread it out into a connected distributed network of open educational resources. So just as a short conclusion the idea is to have open source projects like the RC or GitLab to create a network of open educational resources that could be easily set up on different places and connected to each other and that would be a pragmatic solution even if it's some kind of proof of concept in some components but it's easy for those who don't yet have any solution in their place and want to build it with a minimum effort to create one of those components. That's it from my side and thank you for your attention. If you have questions, yes, please. Thank you, Axel. Yeah, there's room for questions. I found a wireless mic so I can just walk up to anyone with questions. Hi, Patricia Serrano from University of Nantes. I have several questions but maybe we will talk later but right now I would like to know how do you collect words, key words? I mean, there is an analysis of resource and also it's related. Those resources are only a text or also, I don't know, code or videos or something else. So you mean the key words on the resources themselves. This is as we have different resources connected depending on each source. For example, repository Twillow that we have in North Saxony, each author is responsible to put in some key words and so it's hard to harmonize it. We have some open key words and we have also some sets of key words that could be assigned but there's no general approach for all of those sources. Okay, so key words have the same relevance. Yeah. Okay. And any other questions for Axel at this time? Yeah. I have many questions and we will talk later but how are you ranking the results? What sort of, how do you decide what to show first? So that's a good question and we don't have an answer at the moment. So we think about having at least an order by date but for the moment we do not even have this because the repositories that we connect just have about 10% of their data really assigned with a creation date or a publication date and even those are heterogeneous by meaning and therefore we don't yet have a ranking on this. We have a good filtering mechanism where you can just see which one you need to reduce the set of results but we don't have a ranking yet. Well, actually follow up question. What, I wasn't familiar with Wiki data yet but is that the, like what defines categories? Is that defining categories of information? Like how are you, what metadata schema is being used to put in resources? Like how do you know it's engineering or? So the result that we get out if you have Sparkle queries on Wiki data is that we got just get a simple CSV file that what we use for the index later on to create the synonyms but we don't have a real schema list. So it's just what Wiki data has with all the terms and we just put out this and flatten it. Gotcha. Okay, so you're just collecting everything and showing everything. There's no, you're not putting things into buckets of subjects. No. Okay, cool. All right, so that's all the time we have for questions. Axel, thank you once more and I'd like to invite Christina and Brian up to the stage. Thank you.