 is to really get some discussion on, especially on interoperability issues related with the guidelines. So we will start here by making a brief presentation of the guidelines just to make sure that everybody is on the same page. So just know that everybody will know what is the current situation. We have here copies of printed copies of the current draft versions of the guidelines. These are draft versions that you can pick up if you are interested. So we will start by having that presentation. So Mikael, Lars and Jochen will present the guidelines now, and then we will split in groups. So the NOAADs, the National Open Access Test from Opener Plus Project, will stay in this room, and you will have the opportunity to, with Irina and Pedro, will stay here with you, and the rest of the people will split in three other groups. So we will have a room after the coffee break. So there are a whole with three rooms. One room has a sign saying crease. So we will have a small discussion group on the crease guidelines. Another room has a sign for data repository. So we will have another small discussion group for data repositories. And the third room has a sign saying literature repositories. And we will have also a small discussion group on that. And probably around half past three, we will convene all together again here, and there will be some short reporting from each of those groups. So by the way, on the literature repository, Jochen and myself will be there. On the data repository, Lars and Najla will be there. And on the crease group, Mikael and Natalia, right, will be there. And we will then report back. So Mikael, please. I just need the folder where all the, actually, it's Jochen who's that out. Right. Are you ready? So hello. I just want to go quite quickly. I just want to go quickly through some slides. Just to remember how we started with repository guidelines. It's now almost five years ago with the driver guidelines. The idea was, of course, to normalize the use of DC WCore elements in the repositories and to give some guidelines on the use of the OIIPMH protocol. The result of these guidelines were the introduction of an OII set driver to indicate bibliographic records about open access publications. And it was also about an introduction of a vocabulary, for instance, about the publication type. The next big step with the open-air project and special requirements to indicate funding information. So we introduced just another set. You see funded resources to indicate FP700 projects. We extended the vocabularies with terms about access rights and Bargo period. And we introduced an identifier scheme for FP7 project information. The next step is with an autumn last year, the introduction of guidelines version two, which allow us to harvest from OII aggregators. There are not so many out there, but we are currently harvesting from the Dutch Narciss aggregator. And with the introduction of the open-air plus project, we are going beyond FP7 funding information. So we had to extend the identifier scheme for project information. So what has happened in the last five years does the community, the repository community really use the guidelines. Here's an example for the adoption of the driver guidelines, analyzing from 3000 OII compliant repositories, which are covering 50 million bibliographic records. We are looking for values in the DC type element. And we found out that from the top 100 of values in this element, the vocabulary from driver is really used. And so, for instance, for the optical publication type 200 and for repositories uses vocabulary and describes over 1 million 200 records. So with the new open-air plus project, we have new requirements, we need new guidelines. What are the big challenges and what will change in our ecosystem? One point is that we will merge the information spaces from driver and open-air to one information space. And we are going beyond literature repositories. So we will also collect metadata from data repositories, data archives and research information systems. And as already mentioned, we are going beyond EC FP7. In open-air plus, we want to collect open-access publication, metadata about open-access publications, which doesn't have necessarily funding information. And we want to collect bibliographic metadata about research outcome from funding information. This can be open-access but also embargoed or closed-access publications. What does it mean for repositories, especially for those that already participate in driver or open-air? First of all, we keep things as they already are, so status quo. Repositories compliant with the driver guidelines or with the open-air guidelines version one or two will be also harvested, of course, in the future. They don't need to change anything at the moment. But what does it mean for newly joining repositories? In this case, we want to introduce yet another OEI set called open-air. But in the future, we don't want to support driver and EC funded resources anymore, so we will drop it away at some point in time but not tomorrow. This new set open-air will help us to indicate all the record we want to collect in open-air and these are open-access publications. So the open-access status of the publication needs to be indicated in the Dublin core elements, preferably in the DC rights element and funding information in the DC relation element. We have some challenges to solve. That's why at the moment we can only provide a draft of the new guidelines. One big challenge is that we, for the vocabularies, we use a namespace called info colon u minus ripple semantics and this kind of namespace will discontinue. So we don't want to introduce big challenges but we have to move on in some way. And we are also currently discussing how we can extend the vocabulary to support the grant information, funder information. For this reason, because we are going beyond FP7, we will probably provide a registry so that the repository can look up the funders and projects we are interested in open-air plus. And of course we will also try to be aligned with other initiatives like ORCID to identify authors. So what are the arguments for the guidelines? Of course that will help us to indicate open-access content in repositories. It will help us to identify content that is related to funding information. It's quite important that repositories adopt these guidelines because then we can provide a normalized content that can be used by third-party services for sophisticated services. And up to now we want to also rely on a flat format because it's quite easy to implement and avoids a lot of complications. And with this new draft of the guidelines, we introduce also the possibility to express links to related publications like citations and datasets and research information. Thank you. Okay, so I'm Lars and I'm coming from CERN. And I'm quickly going to present the data arc, the guidelines for data archive managers. So Mikheil already showed some of it yesterday. It's based on the data side metadata schema version 2.2 and we'll naturally keep it updated once the new version comes out. The data side is really, as you might have seen in the presentations over today and yesterday, that it's the most adopted metadata schema for describing heterogeneous datasets. So the minimal things you have to define in data side is really the example you see here. So you need an author, you need a publication year, a title, publisher, and a DUI. So that's the minimal thing you need for data side. What we add on top of it is that it doesn't need to be a DUI. You're great for your dataset. We accept some other identifiers. On top of that, in the bottom line you'll see that there's some extra information you can add and most of it is optional. So we need a publication date. We need a description if you have it. It's optional. And then there's, I'll detail the funding access right and related datasets and publications on the next slide. So the type of datasets that we are interested in is the one that I connected to a peer-reviewed article in the first round. So we're not interested in a lot of genome data if there's no publication based on it because there's so much data that we cannot harvest everything in the infrastructure. So just to give some examples, then for the access rights, we're using the same vocabulary as in the literature guidelines, which then might change, as you'll see, but we're also allowed to link to creative common licenses, most notably CC0. If you want to specify funding information, it's done in this way. You have to specify the funders, the European Commission Funded P7 project, and then you're using the same vocabulary as in the literature guidelines. And for related datasets, yeah, as long as you have a persistent identifier, you can link to it. And there's a vocabulary for specifying the semantics in the relation. So, for instance, we have here that dataset could be referenced, is referenced by a peer-reviewed article in this case. And that's basically it to be able to be integrated into OpenAir. That's it. And this one is going to be very short because there are no guidelines yet for the sheriff. So that's what we really like to discuss with some of the experts here. How could it be done? So what is the case is that the internal data model of OpenAir, the OpenAir information space, is sheriff-compatible. It's a subset of sheriff entities. And we think that, you know, sheriff XML will be the right place to look for something which can be used as exchange of data between Chris's and OpenAir. So for those who want to go to this session, I would like to discuss with them, you know, how can Chris and OpenAir exchange data be like application profiles or guidelines or whatever and what kind of vocabulary should be used and so on. So that's very short for the sheriff part. So this is just very shortly the data model, which is probably not possible for anyone to see in the distance. It's just showing that we have these main entities like project and organizations and, well, publications or research output. Okay? So that's it for this. And I hope we have a good discussion with you now. Maybe you'll take over now or is it Eloi? Eloi. All right. Again, National Open Access Desks will stay in this room. All the rest of us will go away. You can follow me and you will...