I will give an overview on the ETH Zurich DOI desk that is the DOI registration service that we have established in Switzerland at ETH Zurich and the ETH library where I work is the largest scientific and technical library in Switzerland.

I would like to share with you some experiences on how it came about that DOI's are today used as persistent identifiers in many Swiss open access repositories and digital collection platforms and also library hosted open access journals.

This service, the DOI desk, has been set up as one sub-project within the framework of a major innovation and collaboration project in Switzerland which was called ellip.ch, the Swiss electronic library between 2008 and 2012.

It is since run as a regular service by the ETH library with technical support from the ETH IT services. This framework program, ellip, consisted of 20 sub-projects which had the overall

aim of improving availability of scientific information and foster cooperation between libraries in Switzerland. One major field of action of ellip.ch was the development of digital collection platforms as sustainable online platforms.

It was certainly an important success factor for our own DOI project that we could work closely together with most of the digital collections that have been supported through this project and win them as pilot partners for our DOI project.

When you look at some of the names of the clients that the DOI desk serves today, you will see that repositories that host digitized library material such as rare books and

manuscripts, digitized journal articles and images are still an important group of clients of us today. Then another important group of clients are the Swiss open access repositories which host preprints, postprints, thesis and dissertations and other textual content.

We also have a couple of library hosted open access journals and recently we have found some new clients that registered UIs for research data such as a protein model archive or a world creation monitoring service. So overall at the moment we serve 20 clients with 29 different publication services and you can see here that

from our first pilot client in 2009 until the end of 2013 our clients have registered more than 700,000 UIs. So if you now look at the technical infrastructure of our service you will see that the

ETH DOI management application works as an intermediary service between our clients and the data site technical infrastructure. So there are two main reasons why we have built this kind of infrastructure in Switzerland.

One reason is that in Switzerland we have many small libraries or institutions that are interested in publishing small amounts of data or publications but they might not have the technical resources to integrate their services with the data site infrastructure directly.

So we thought that we would need a technical solution that could facilitate a registration workflow even for small publishing agents with limited technical resources. And the other reason was that while data site was incorporated in 2009 and infrastructure that it has today didn't really exist when we

began with our first pilot clients to register UIs in 2008 and we wanted to start the registration for them as soon as possible. So this is how our DOI infrastructure looks today. We are running our own handle server which stores the

UIs with the according URLs and pushes this information to the global DOI system which handles the resolving requests. Then additionally we have built a web application that can store the UIs, URLs and the according metadata for each

object and this metadata is exported to data site so that it is available in the dataset metadata store for harvesting. And our clients, they can either submit their UIs to our system via an automatic process

or via manual input form. So now we can have a closer look at both those workflows.

When using the automatic workflow the client generates a UI name for every new object according to the specified syntax that the client and the DOI does have agreed upon. The client then publishes the necessary metadata on the object, including the DOI name as an XML in doubling core simple format on an OAI server.

If the repository does not provide an OAI interface, the client can also publish the XML file via an Atom feed. Then once a day the DOI disk harvests the client's new or updated data and a few minutes later the data is in the global DOI system and the UIs can be resolved.

Also the DOI disk forwards all the UIs with their associated metadata to the dataset metadata store. The client administrator can observe and manage this process via a web interface.

Okay, now let's have a more detailed look. The whole process is actually quite simple if you are a little bit familiar with the OAI PMH protocol. So the client publishes an XML in doubling core format for each UI object, which includes the URI name and the URL it should resolve to.

For each client we have configured a so-called DOI pool in our web application, which stores the basic information about where and when we should harvest new and updated records from this client.

If the client has published new records with a DOI since the last harvesting routine, they will be stored in our database and pushed to our handled server. For the exporting routine to the dataset, we have implemented a mechanism

which transforms the data from doubling core format to the dataset metadata schema. If the client publishes only a very small number of digital objects, they can choose to use our manual workflow.

So the manual workflow can be executed from within the DOI management web application. For creating a new DOI, the client simply enters the DOI using the prefix that we have

assigned him, and then he enters the URL that the DOI should resolve to and the metadata. And both the automatic as well as the manual workflow can be monitored by us and by the client via the web application. So this was the description of the technical workflow.

And of course, as a registration office and member of the dataset, the DOI desk does not only have to ensure the technical stability of the system, we also have to make sure that our clients bring with them the necessary technical and organizational prerequisites for the UI registration.

So this is why we have developed a policy document that can be downloaded from our website, and this policy is based on the dataset business model's principles. The policy describes the requirements that a DOI user has to fulfill to become a client of the DOI desk.

So what are these requirements? So first of all, we only accept institutional clients. An individual can never be a client because only an institution has the necessary mechanism to guarantee that a digital object referenced by a DOI will be available in the long term.

And for a digital object, we request that they be available via the internet and that access restrictions should be avoided where possible. Of course, they have to be described with metadata, and once they have been assigned a DOI, they shouldn't be changed anymore.

If a new version is published of an object, it should receive a new DOI. Then there is a minimum set of metadata that has to be provided with each DOI to facilitate discovery and correct citation practices. And of course, the object should be saved on the trust versus service, and

the URL location must be updated immediately in the DOI system if it changes. So if we have come to the conclusion that a potential client can meet all our requirements, we will set up an individual

service level agreement with them, which defines the rights and duties of both parties and describes the service and workflow in more detail. And we also signed a prefix to the client's publication service and agree with them on which system text for the suffix they are going to use.

Then as part of our service, we also try to keep our clients up to date with the latest developments from data side and the IDF and share with them interesting initiatives from our data citation community and best practices for data citation. And we have, since recently, we have a newsletter that we send out to our clients and other interested parties on a regular basis.

And we are an active member in both the data side policy and best practices working group and the metadata working group. So now I would just like to give you two examples of clients that have

implemented DOIs with us and discuss some questions that came up during our talks with them. As I have already mentioned, most of the Swiss open access repositories have implemented DOIs as persistent identifiers, which I believe is not very common compared to other countries where URNs or handlers are more widely used in open access repositories.

So one question that usually comes up with open access repositories when they implement DOIs is if they should register a DOI for a paper that is a post print or a preprint of an article that already has a DOI.

So the concern behind this question from the repository managers is usually that users will be confused if a repository record has two DOIs, especially if the repository also fulfills the function of an institutional bibliography, for example.

So anyway, in my view, there are actually quite strong arguments for assigning DOIs to every full text that you have in your repository, no matter if it's a preprint or not, because otherwise you can provide DOIs for some documents in your repository and for others not.

Or you can only provide outward DOI links to the publisher platform, but they are the resource that might not be open access. So I think this is a question that can actually be resolved by thinking about how the repository displays the different identifiers of a resource.

So, for example, in this screenshot, I hope that you can at least imagine what it shows. We have a record from the University of Zurich open access repository, and they have decided they will assign their own DOIs to all full text that you have in your repository.

And they simply make it quite clear to the user which one is the publisher DOI. Okay, so here down, they have the publisher DOI and they name it publisher DOI, and up there, they have their own repository DOI, and they've named it permanent URL to this publication.

So this is an example of how they manage two DOIs for this resource. Then another client that we have worked with is the World Glacier Monitoring Service.

This is also an interesting example for me because when they approached us, they didn't have any experience with data publication. They just really thought that it would be great to be able to reference their database on fluctuations of glaciers via a DOI, but they didn't have the technical resources to set up a professional data repository.

So what they decided to do is to set up a simple web page and publish one version of their database each year as a zip file.

So for now, they register with us using our manual workflow, one DOI per year. But anyway, for me, this is really an interesting example because at first sight, you might think that this is not a professionally hosted repository when you encounter this website. But on the other hand, for them, this is an important first step.

So they have described their database with standardized metadata. They clearly state how this database should be cited. They provide a persistent identifier, and they register a new DOI for each version that they publish. And clearly, this is much more than many scientists that produce valuable data today do.

So to end my presentations, I've just written down some thoughts that I would like to share, especially with other dataset members on how to establish a successful URI service for your country or community.

So for me, these are the most important points. Target your potential clients directly, listen to your community and their needs, and be open and not exclusive about potential use cases for DUIs.

And also try to educate librarians and researchers about the fact that the UI registration with dataset can be much more than what first comes to your mind when you think about a data UI. So for our own service, I would say that an important success factor so far has been that

we have targeted those academic online platforms that already existed in Switzerland at an early stage in the project. And we have not exclusively focused our service on research data archives, but rather kept the service

open for the needs of the academic and library community and tried to accommodate the individual needs. The UI is now well known in this community as the central URI registration office for Switzerland. And at the same time, we see now the first initiatives for research data management and publication slowly emerging in Switzerland.

And of course, we expect that they will be another important group of clients for us in the near future. So thank you for your attention, and please visit our website if you want to read more, and I'm happy to answer your questions.

Yes, thank you, Barbara. Any questions from the audience? We have time for questions. Okay, Mark.

Just a point of clarification. The World Glacier Monitoring Service has been publishing data for decades, both alone and in collaboration with the National Snow and Ice Data Center. Did I miss something that you say they haven't been publishing data?

This is the coordination office at the University of Zurich at the Institute of Geography. And I'm talking about this special coordination office and the data that they collect from their collaborators.

I think I understand why the question was asked, because I was a bit surprised when

you say that these people may not be felt like people who deal with data professionally. You didn't say it that way, but it looked like for the data preservation community, the people

who preserve the research data, the way these people work, maybe not felt as professional data preservers. So I had a question to ask at the same time about the fact that these people have been

dealing with data for not centuries but a long time, and they are really able to deal with it. So now they just try to find a way to make it public in the way you propose to make it public and stamped. But they are professionals of dealing with data, basically, in my own feeling about how to deal with data.

I think it's just a question of vocabulary, maybe.