 Hello, everyone. Welcome to this webinar, which is on some technical changes to the way in which the DOI service is now going to be delivered in Australia. I'm Adrian Burton. We've got a number of other presenters here today to just walk you through exactly what will be changing and what the new situation will be like. I'll get on with it. ARDC and Data Site have been collaborating for a long time now. The timeline goes back to even well before Data Site itself was actually formed in 2009. One of the predecessor organisations for the ARDC and was involved even before Data Site itself was constituted. We helped with actually writing the constitution for Data Site, and we were there right at the very first member meeting in France in 2010. It's a very long-term relationship that we have with Data Site and that we intend to keep going well into the future. In 2010, we just formed Data Site, but there was nothing there, and we had to build up the infrastructure, the global infrastructure for minting DOIs for data sets and other non-traditional research outputs. In 2011, the ARDC started to build parts of the infrastructure in collaboration with Data Site. It looked something like this, that the Australian research institutions came through the ARDC systems, and we provided a number of front-end things that made it a little bit easier to create metadata and reserve DOIs and manage the DOIs, update them once they've been created. We had validation and link checkers to see that the links were working nicely. In the background, whenever we've always minted a DOI, we've registered that with Data Site. At the beginning, that was the key role of Data Site was to register that into the international DOI system and to resolve all the requests for DOIs. We had a front-end that was helping people at that minting and managing stage, and then all the really fundamental DOI infrastructure has always been run by Data Site. We've always also had very strong support, not just on how to mint a DOI, but why and what kind of business processes and whereabouts in workflows. We've always worked very closely with the research organisations in Australia to pick the right way in which to implement DOIs for datasets in a research organisation. If we fast forward through to 2020, where we are now, there are some changes that's happened in the Data Site system itself. Centrally in Data Site now, there are some very mature systems that actually provide all the functionalities and more than what we've ever provided here locally for Australian clients. They're very strong set of outreach and develop that new period. What we've found now is that if you look at those two, the light blue box, which is the ARDC systems, it's fairly much just mimicking now what could be done centrally at Data Site. So that's what this changes the transition that we're talking about now. As it related to this over time now, the functionalities are just being mirrored. So what we're proposing that 2021 might look like, sorry, no direction. 2021 would look like this systems area that ARDCs no need for us to keep maintaining that now because it's all that functionality is available centrally at Data Site. So we over the next year plan to remove that sort of software application from ARDC local systems, provide consortium access for all the Australian research organizations to get direct access to the Data Site systems. And pretty much all the functions that you've been used to at the ARDC are available now in the Data Site systems. Some of them are not exactly the same. Some of them are still being developed in slightly different ways from what you might be used to. But in general, the general just it's a true statement to say that the key functionality that you've grown used to using through the ARDC systems is now available through the Data Site systems. And just to be clear, those Data Site systems are our systems. We are consortium members, you are all members of a consortium that is part of Data Site. Those Data Site systems are our systems. So we're now just all using the same central system. So that's what 2021 will look like. And that's in general the changes that we're now talking about today. I might hand over now just before I hand over to Sel. So if you look along at this big picture in 2010, we had the establishment of Data Site for the first 10 years. ARDC provided a whole set of extra functionality for Australian Minters. And we've always provided that as part of the Australian research infrastructure. Now in 2020, ARDC still provides all that backing and support, provides you access to the Data Site infrastructure through the consortium that we fund and resource. And now you'll be getting that functionality from the central Data Site systems. Into the future, it's important to note that we continue our support for the consortium, for minting DOIs in Australia, and for more. We're ARDC now with our other resources. We'll be focusing in on how to really get the best value out of having, after you've minted a DOI, then what does it actually do for you? How can we really help with the global tracking of the outcomes and the impacts of research by using Data Site DOIs? More on that a little bit later. I'll hand over to Sel now. I've got these slides up on the screen, Sel, so maybe if you just want to talk to them and I'll forward the slides when you're ready. Thank you, Adrienne. Can everybody hear me? Yes, good afternoon everybody. I am Sel Pilapil and I am the ARDC ID Services Coordinator. On the screen today, you'll see the proposed timing for the transition to Data Site Fabrica. So during the months of April and May, ARDC and Data Site have worked together in preparation for the transition of all our clients. During the month of May, we have also started creating all the Data Site Fabric accounts and started a distribution of those test accounts as well. We have sent announcements and completed some documentation to help aid all our users in the preparation for the transition. So some of you or a majority of you would have probably received the Data Site Test Fabric accounts. So for all our manual meeting users, we would really recommend that you start testing now. Data Site will present later the Fabrica interface. However, we would expect that by the end of September, everybody would have all the manual meeting users would have already transitioned to Data Site Fabrica interface. By the end of September, that would mean that we would have to commission the DOI manual interface that you access from the RDA registry, which is my DOIs. Also for our manual meeting users, I'm sorry, machine-to-machine meeting users, once you have received your Data Site Test Fabrica accounts, we would like to ask you to start planning for demigration, any code changes, any configuration changes that you will have to do in your system, please start planning and start testing. We would expect that everybody, all our M2M API users would have completed demigration by end of December, at which time we will commission the ARDC DOI service. If at this stage you anticipate that there will be issues with demigration and you will not be able to complete it by the end of December, we would really encourage you to get in touch with ARDC. Let us know any issues so that we can work together and that we can plan on a transition that works for both you and ARDC. So that's the timing. If any feedback or any suggestion regarding the proposed timing, please let us know. Next slide, Adrienne. Coming. Thank you. These are the transition steps at a very high level. This is in line with the transition timing that I have just presented. So first step is the creation of all your new Fabrica accounts. The Fabrica accounts, as you are probably aware, is the same account that you use to manually meet, that means to log into Data Site Fabrica and to authenticate through the Data Site API. Once you have received your test Fabrica accounts, you are going to conduct all your testing. So you let us know when you have completed the testing and then when you're done, we will then distribute your Fabrica production accounts. At that time, you will start demigration and then when you are done and finally when you are finally completed the migration to production, what you have to do is just let us know. Let us know when you are ready. And at that time, we will disable your access to both my DOIs and the ARDC DOI API. That will mark the completion of your migration. So those are just the four easy steps. We create your account. We distribute it to you. You conduct your testing. Once testing is done, we will distribute your production account. You will migrate to production and then you let us know when you have completed the migration. Next slide, Adrienne. Yep. Thank you. Nothing has changed when it comes to supporting you from the ARDC point of view. ARDC will remain your single point of contact even after the transition to Data Site Fabrica. Any issues, feedback, suggestions, queries that you may have in relation to Data Site Fabrica and the API, you set it directly to services at ARDC.edu.au. In turn, if there are issues that we need to escalate, we will work closely with Data Site and we will work to resolve your issues as soon as possible. It is important to note that you contact us in the first instance. So nothing has changed when it comes to the support of ARDC to all our DOI service. Do we have questions? Yeah, there is no question. So the question from Paula about how do we get a test account? Paula, if you can send an email to services at ARDC, all our existing ARDC users, DOI users have already been contacted when it comes to the creation of the test DOI Fabrica account. If you are a new user, if you are a new prospective user, then you send an email to services at ARDC.edu.au and we will get in touch with you and we will send you your test Fabrica account once we have done all the administrative tasks. Is there any other question? That's it at the moment. Good. Have you done the sales or anything else on the support? Yes, that's all Adrian. Thank you. Then through to Joel now. So yeah, I just encourage people to put any questions they have in the chat box. That's probably the easiest way to raise the questions and we'll sort of as they come through, we'll sort of try and answer those in context or at the end of sort of each section. So hi everybody, I'm Joel Ben. I'm the DevOps Manager at ARDC. I've got a couple of slides just to sort of reiterate some of the information we put out in the documentation earlier this year around sort of the scenarios that our users will come up against when they're transitioning over to data site services. So the first, so there's three scenarios, really three main scenarios and the first one is for manual minters. So this is ARDC DOI users who currently log into the RDA registry to manually mint DOI so they might only just use manual interface, but we also have some users who primarily use the API to mint but they will still log into the interface to deactivate DOIs or enrich some of the metadata manually instead of doing it through their API connection. So for these users that the transition is obviously going to be fairly straightforward for the interface. Once you've got your credentials as we just spoke about to the Fabrica test instance, you'll be able to log in with those credentials and start sort of having a look around and familiarizing yourself with the interface. And I believe Mary is going to run us through the Fabric interface in a little bit. But really it's like any new application there will be an adjustment period. Adrian sort of touched on that the same functionality is across the two applications more or less and it's just a different interface and a different way of sort of approaching minting DOIs. The other thing to note is that there are separate instances. So now when you use the ARDC service to do test and production, minting you log into a single instance to do that with your account. Whereas when you're going to Fabrica, there'll be a test Fabrica instance and a production Fabrica instance. And that allows you sort of to keep them very obviously separate when you're doing your sort of testing within Fabrica. Next slide please Adrian. So the next scenario is users of the ARDC DIY API. And this is going to be the majority of our users I believe. This API has been around since the early days of when we started to mint data site APIs. So the bulk of our clients using the APIs, our APIs will be using this API. Now the ARDC API is quite different to the data site APIs. So they've got really different signatures. There's different request endpoints. There's different messages that have to be posted. And there's also different responses and error codes that come back. So I can almost guarantee that there will be code changes required for clients using this API. And it's probably sort of where the bulk of the work is going to be for our users. The API itself, data sites APIs, they offer several APIs to register DOIs. The two primary APIs, the REST API and the MDS API. The services that we offer through the ARDC DIY service is underpinned by the MDS API. And that's probably the older data site API. The REST API is a newer API. It underpins a lot of the functionality in data site Fabrica. And it's probably the preferred API to go with. But it will depend on your circumstances and what you're comfortable in using. So the REST API is a JSON specification API. So it operates purely on JSON objects, whereas the MDS API handles XML. So it will come down to sort of what your developers have a preference for and which ones you can integrate with. In terms of testing the APIs, once you've got your credentials to test Fabrica, you can start using either of those APIs to sort of start integrating and testing. And in parallel, you can continue to use the ARDC service. So that won't stop anything from occurring through your normal systems. But you can set up an extra test system and start sort of tinkering around with those APIs to work out which one is going to be best for you. We've also obviously got technical staff. So if you come up with some, come up against a few challenges in doing some sort of integration with the new APIs or how to handle the messages coming back, please flick an email through to services at ARDC and we can try and assist you. Next slide, please, Adrian. So the last scenario is probably the easiest one. So this is a very small subset of our DIY service users. And these are clients using the Datasite client API. So this API from ARDC is basically a replica of the Datasite MDS API. And it was constructed so that people with third party applications such as FigShare, Dataverse, Pure could configure their application to talk to the ARDC service to mint Datasite DUIs. So the users of this API really won't have too much to do. There will be some configuration changes within the application. So a new API URL obviously pointing to Datasite, a new username. So that's your new account that Cell will provide. And you will get a new test prefix. So with the creation of new test accounts, you're getting a new test prefix. So any of your existing test DUIs you won't have access to once you migrate into the new test account. Just to note that your application may only support one of the Datasite APIs. So it's best to check the configuration manual for your application. Or if you don't have one, just check with your technical support. But I can say if you've been integrated with our Datasite client API, then you will be able to use the Datasite MDS API. But it would be worth checking if you could also use the REST API. I think that's more or less done. Mike, pause for any questions. I've got a few that I can read out, John. That would be great. What happens to our old set of DUIs and their prefix now that our organization prefix is going to change? That's a good question. So the test, as I just said, the test DUIs within Test Fabrica, they actually get routinely cleaned up. So they get deleted by Datasite on a regular basis. So they'll probably go away anyway. And so every now and then you'll probably go to update a test DUI and you'll get an error back saying that it doesn't exist. And that's most likely because it's been removed. So with your new test account, you will get a new test prefix and you will lose access to any of those test DUIs. With your production account, though, you will maintain the same prefix. So all those DUIs that exist in your current production account will be migrated over to your new production account. And that's sort of the process that's been happening. And I think we've almost migrated all clients. I think there's probably sold maybe about 10 left to migrate. But then everyone will have their new accounts ready to go. And the prefix remains the same as our job between the two. The production account. Yep. The production account. Correct. Good. I've got another question here. What's going to happen to the existing records that has DUIs? Will that be migrated as well to production? I'm not sure. It might be the same question as the one before, just so that, you know, if you've published, I'll just jump in there. Not quite sure what the first part of that question is. But if you have allocated a DOI name, meaning you've identified a dataset with a DOI previously, that remains exactly the same because, you know, that will have been published, you know, potentially is references in journal publications and it will be out there in the literature. People will ever refer to it. We're not asking you to change any of that. That's fine. That all stays in place and they will resolve into the future. There's no, absolutely no change with the previous DOIs that you've minted. What we're doing is, when we say we're migrating them, we're migrating them into that new interface so that if you need to update them or review them, et cetera, you'll be able to view all of that in the Fabrica interface. So anything that you've minted in the ARDC interface over the last 10 years, you'll be able to see all of that in the data side interfaces as soon as you migrate across. And the DOIs themselves just be 100% sure and nothing changes if you've got a nature article that refers to your favorite dataset. We are using a DOI that remains absolutely as it is. Nothing changes there. The DOI remains exactly the same and it will continue to resolve as long as the DOI infrastructure stays in place, which is being set up to stay in place for a very, very long time in accordance to the requirements of scholarly communications, which is, yeah, we're talking the very long run. All right. There was another question there. Will the slides also be sent out? Yes, we'll send the slides out. Yes, we'll have anyone who's registered for this webinar. We'll be linked to the slides. I think this one might be for you, Joel. Will using the MDS API create technical debt in the future? How long will that be available? Yep, that is a really good question. So I might have to pass over to Mary or Helena on this one. We've been advised that there is no changes going ahead to deprecate or remove the MDS API, but maybe Mary, Helena, you could comment on that. I think Robin is probably the best person to answer that she's responsible for our APIs. Yes, hello. Hi, this is Robin Dassler, the product manager at DataSites. So we do not yet have a firm date on the retirement of the MDS API, but the ultimate intention is that, yes, at some point, it will go away. Currently, our thinking is that it's probably on the order of year or two kind of timeline. We don't yet have a firm date for this. Thanks, Robin. And I probably should have pointed out one of the major differences between the REST API and the MDS APIs. Using the REST API, you can make a single call to Mint and register your DOIs, whereas with the MDS API, you actually have to make two calls. So it may be easier in the long run just to use the REST API. With the MDS API, you actually have to sort of register the metadata and the URL separately for the DOIs, so that might be something to factor in. And the REST API also supports full JSON, if that matters for anyone, so you don't have to send your metadata packages as XML if you use the REST API, depending on how your shop works. There's a follow-up question from Tim, who originally asked, what happens to our old set of DOIs and their prefix now that the organization prefix is going to change? So the answer to that from Joel was the organization prefix only changes in the test account, not in the production one. The follow-up from Tim was including ones that are currently set as disabled. So does that mean that... I suppose the question is that the disabled one's been transitioned across? Yep, there should be no changes to those DOIs. So anything that's deactivated at the moment should remain the same. Now, do you still be able to help bulk updates once the DOIs have migrated across? Yeah, I mean, I don't see why not. We can definitely have that discussion. One of the things that is on the roadmap for Datasite is to be able to sort of do the batch minting and batch updating. We have the functionality within the registry at the moment, but we could possibly help out in updating the DOIs in the future. Any comments from our Datasite colleagues? Any comments from the bulk update functionality? Yes, we are aware that this is something that people are very interested in. We also do not yet have a firm timeline for this one either, but that is something that we know people are interested in, so we're exploring our options. Sure, thank you. I've got a message from Lyle. I could read it out. Lyle, if your audio works, I'm happy for you to say it yourself. So I might just go on to the next question. I'll come back to that if you don't have a microphone or if the webinar thing doesn't allow that. Confirm that the TOS recent, confirm that the MDS API doesn't have a set date, but would be potentially retired in 2022. I think that was a question. We have not yet decided when to do that. We've been trying to run them both in parallel for a long time to get used to the new REST API and make any changes, but we do not yet know exactly when we're going to retire that. It seems that Lyle's microphone is muted and I don't have the magical power to unmute it, so I'll just read it out. I think he might be unmuted now, Adrian. Okay, Lyle, go ahead. I just thought I'd pass on to everyone that we underwent the migration process to the data site system and it went pretty smoothly. Now we've got our fixed share repository and it's minting stuff via the Fabrica system API and the prefix, sorry, the suffix hasn't changed at all. We're also looking at the manual user interface and it looks to do everything we need, so look, everything was fine. Good. Well, thank you, Lyle. That's a nice contribution. All right. It might be time for us to move on to our next section. I think we're done with the questions that have come up there. If you've got further questions, don't hesitate to put them in whilst you're listening. I think we'll hand over to our data site colleagues. First of all, maybe just to introduce the data site support team and what you guys do and what kind of roles there are there and then to give us a run through the Fabrica interface. Helena. Hi, good afternoon. Yes, we did want to take the opportunity to also briefly introduce ourselves so that going forward, you know who you're talking to. So my name is Helena. I'm Data Sites Director of Community Engagement. So I am responsible for membership. I will probably mainly be working with ARDC directly, but if you have any questions about our member model, about the consortium structure, about what it means to be a consortium organization, then I am the right person to talk to. Maybe before I hand over to Robin to introduce herself. You can reach all of us by emailing support at data site org. That's our main email address. And then your question will get assigned to one of us depending on the topic and you will get an answer from us. So yeah, Robin. Yes, hello. And like I said, I'm Robin Deslar, I'm the product manager at Data Sites. So that basically means that I am the interface person between Helena's engagement team and our development team. So I kind of helped bridge that gap and figure out where we're going with our services based on what you guys want. So feel free to let us know. Yeah. And so basically if you have suggestions about product functionality, about DOI Fabrica, about the API, then Robin is the main person and she'll be able to add that to our product board so that the things you need are being developed by our dev team. So Mary. Yeah, hi. I'm Mary Hirsch. I'm the support manager at Data Sites and I work mainly with a kind of help desk service that we provide to our members. So I work closely with the dev team to resolve issues and try to make sure our documentation is up to date. So if you do have any feedback on the documentation or if you have any questions, as Helena said, you can contact us at support at DataSite.org. And Mary will now talk you through DOI Fabrica and the transition process. If I was shipping off Mary's getting ready, I would be really excited now to actually be able to provide all that we're not changing any of the support allocation that we do at ARDC and we're now complementing it with our only team in DataSite. And so we're really quite excited about being able to really promote the use of digital object identifiers for datasets and promoting the actual datasets of those class objects in the scholarly communication cycle. And as I said before, really working globally in Australia and with DataSite on the systems that allow us to track what the impact of research was, what the impact of some of these datasets, where they were used, what kind of references there were, what kind of usage there is to them. So I think that's where I'm very excited about the new step up in our collaborative relationship. Yeah, we're also very excited that ARDC will be leading or continue to lead the Australian consortium. You've already done so much great work in this space and I think there is a lot more we can still do and Mary will also mention at the end of her presentation that there will be a virtual member meeting, also one hopefully in the right time zone. So that will give us another opportunity to interact with this group so that we can also really hear from you what we can do in the region. Okay, so I think I should just go ahead. I'm going to talk you through our web interface, which is called Fabrica. So let me just see. Okay, so what is Fabrica? So Fabrica is a web interface for DOI registration so you can register DOIs and you can register metadata and it also is where you can update and manage your accounts. As Joel mentioned, there's a production environment and a test environment and they are completely separate. So as has already been mentioned, it would be great if you go into our test environment and you can create as many DOIs as you want. You can play around with it. You can fill in all the fields of the metadata and none of those DOIs will ever go live in our production system. So yeah, we highly recommend that. It's a sandbox so go and play around and then when you're ready, you can move into the production system. And I've just put the link to our support site where you can find documentation about Fabrica and I've added a few more links into the slides as well to our support sites. So the first thing I think I wanted to talk through was the account setup that we have in Fabrica. So you may or may not be aware that we transitioned to a three tiered structure for consortium. So you're all part of the ARDC consortium and this allows the consortium organizations to manage repositories and prefixes themselves and then the top level consortium which is ARDC in this case is our primary point of contact and here is a very nice diagram that was created by Robin which kind of demonstrates how we've set up the accounts. So at the very top there is the consortium leads in this case ARDC and then below are the different consortium organizations and those consortium organizations have minimum of one repository and then maybe more as needed. So what does that actually look like in practice? Okay well here is what happens when you log in with your consortium organization account. This is the first screen that you will see. We're using opaque IDs really at the moment although I think you guys have well that's essentially a four character or five ID that you use to log in and you will see at the top right when you're logged in with your consortium organization account you can see the ID at the top right there you can also see it in the organization information. You can update your organization information we would recommend that you do that to include the service contact and any other information about your organization and then at the bottom right there I just pointed to the feedback button so that's quite useful if you want to send us any screenshots that will take a screenshot directly of the page that you're looking at so if you need any technical support you can use that it's quite helpful and then we'll see here this is the repository account so the ID that you will use to log into your repository account will be the consortium organization ID followed by a dot and then a string of characters so it's different this is a different account and when you log in you will see again at the top right the ID that you've used to log in and information about your repository and you can update the repository settings as well so what can you do once you've logged into Fabrica well I've just tried to show some of the differences between the permissions in terms of functionality when you log in with either your consortium organization account or your repository account so basically for consortium organization you can go in and of course you can update the settings and the information about your organization but the main purpose of this account is to create repositories and manage your repositories so part of an important function of that is that you will assign prefixes to those repositories and then you can move the prefix between repositories and you can move the DOIs between the repositories but this account is just for creating repositories if you want to create DOIs you need to log into the repository account and so on the right there you see that the permissions that you have when you log in to the repository account are essentially to create and manage DOIs and metadata so I am actually going to do an attempt a live demo but I'll just flip through these three slides on how to actually create a DOI in Fabrica so as we've seen in the previous slide you need to log in with your consortium with your repository account credentials you navigate to the DOIs tab so you'll see there are four tabs when you log in as a repository and the DOIs tab is one on the right and this repository already has four DOIs and just there on the left hand side you will see the create options that you have so I'm just going to talk you through the form today if you want to use XML you can directly actually there's a few accepted formats that you can use to create a DOI using the file upload but we'll just focus on the form today so you just click on the create form button and then you can go ahead and fill in the required metadata fields we've just recently added the recommended and optional metadata fields so you can actually fill out all of the available metadata fields for your DOI in Fabrica form now so let me see if I can just quickly show you this live so here we have I've just logged into this repository example one and here we have info about the number of DOIs the settings you can update the repository settings here there's a few fields like the software that you're using or the repository type and also you can include the certificate here so yes please go ahead and update that information make sure you have a prefix so you won't be able to create DOIs unless you have a prefix assigned and then you need to navigate to the DOIs tab and click create form so I'm just going to click to this tab where I have one I prepared earlier and I'll just quickly walk through it I think that most of this hopefully is quite intuitive so you will see the required fields have the red star next to them which means that you have to include this information or you won't be able to register the DOIs so there's the DOI here at the top with the prefix you want to use if you have more than one you can edit the suffix if you don't choose to edit that's fine you will just get a randomly generated suffix here which is what we recommend generally the state of the DOI refers to whether the DOI is publicly facing publicly available or not we recommend using the draft states this is useful because if you make a mistake you can delete a draft DOI even in production once the DOI is registered or findable you can no longer delete it it's registered if it's in production within the global handle server and it can't be removed so please use test and please use draft and then obviously you can move it to register the state once you've got everything as you want it then the URL you need to include the landing page where the data set or the content will be located in the creators field you have a couple of options fulfilling in the creator so here I included a name identifier which is an ORCID ID you need to include the full URL and this is a person and the given name or family name are auto-populated in this case you can also type the given name and family name into these fields and this field at the bottom will be auto-populated you can add the affiliation here if you want by typing in the name of the organization and then the title you can just type that in there you can include a title type if this isn't the main title include the publisher, the publication year and the resource type general this is also a required field and it's a controlled vocabulary list you can select this dropdown you can add more information here if you wanted to so those are the required fields I'm not going to go through all of the other metadata fields I have included links to the documentation and in fact you can find a description of every field in here so you'll be able to come look at that in your own time I was just going to show the related identifier field I just took a DOI from here which is a publication and now we have the option to include the related identifier you can see the related identifier type is auto-populated because well it detects that it's a DOI and we can have the relation type is cited by sorry, it should be size okay so I think we can just register this DOI I think things will be fine we can see that we have the information about the DOI registered here it will appear into our list of DOIs and you can also go in and change the state to findable or date so I think that gives an idea hopefully of how this works and hopefully it's not too complicated and you can go and have a look and play around with it your son's in our test environment so there's some useful resources I've included obviously a link to our support site we would encourage you to sign up to the PID forum discussion platform for anything related to persistent identifiers it's really great, it's not just data site DOIs, Crossref, ORCID many organizations are contributing so you can sign up to get an account and if you would like to be added to the data site chat room we have a private group you can send an email to support the data site.org we have a Twitter account which you can follow and then I also included the status page where you can sign up for alerts so if there is ever a problem, one of our services we update the status page to let users know just one more thing I wanted to mention that Helena just also mentioned briefly we will be hosting our member meeting in 2020 but because of the current global situation we'll be doing it in a different format so it will be our first ever virtual meeting we'll be taking place in October of this year and we will host three meetings of each two hours long and we'll host them across three time zones and so we would really like to invite you to join us in your time zone so that will be on the 21st of October save the date from 1pm to 3pm Australian Eastern time and we'll be hosting that on Zoom and we'll be sending out the invite and program soon yes so I think that's all from me good well we've got some questions here which we might zip through just in the last few minutes should the system email stay as services at ardcedu.au or do we change that yes I think that that would be the first point of context Adrian Sell here right now the default is set to services at ardce.edu.au you are actually free to change that there is also other that's the system email that normally receives notifications when someone changed the password and things like that there are also a field where you can put in the contact the primary contact person and the email of that person so you can have generic group email in your system email and then you can have another email address in a contact email so you can have both so yes feel free to change that if you need to can we add more than one related identifier yes you can you'll see there's an option to add related identifier and then here you see it says add another related identifier so yeah you can do that findable in the test site is not findable though is that correct basically what our test environment mirrors production in the sense that you can do everything you can do in production but you can't make real DOIs so you can make a findable what looks like a findable DOI but it will not be registered in the global handle server so it's not findable in the same sense they do resolve if it's not in the global system they do resolve if you have the link but they're not essentially like I won't be in a search correct we made our own fake resolvers so they appear to resolve because we had a lot of clients that wanted to make sure resolution would work in some way and so they appear to resolve but it's not real I've made example landing page which doesn't resolve but yeah you could put a proper URL in this field you would be able to click on this link and it would go to the page good and is there a graph or something related to see what resources are related so I think maybe this is the GraphQL API I can take that yes yes so currently we store all the related identifier information in our metadata but via our either our REST API or the GraphQL API you can retrieve some of those relations because we work in conjunction with Crossref and now it's part of this EU funded project we're trying to connect all these relationships together so technically speaking there is not like a nice dashboard interface somewhere where you guys can see a graph but that information is available for my APIs and you can query for the conceptual graph of things that are related to your DOI and you can find more information about that on our support pages or you can contact us if you have a DOI minting through data site automatically added to Re3Data do we have anyone from Re3Data? I think Robin can take that no they are not they are not automatically added to Re3Data no Re3Data has a separate curation process and so in order to be listed with Re3Data you need to actually reach out to them and ask them questions we're at the end of our current questions there's a couple of minutes left if you already have something to share there I'm just checking if I shared my screen now someone is saying yes or no whether they can see my screen no not yet obviously click the button to make it very, very visible I'm hoping it should be now is that right you know whilst we're in unless there's any other there's a couple of little questions there I'll be very quick about this I just wanted to share with you a couple of the when I keep harping on about this we're going to help you mint identifiers but we are really going to work with you to be able to get the benefit of having identifiers and that's in the tracking systems and in the reporting systems so on the screen now I've just got a page 23 of the ARC final report instructions that's the Australian Research Council it's the funder in Australia page 23 and section C2 in the report so this is after you've done an ARC project you have to report on well there is a question and it says provide details of the data outputs produced by this project the question is mandatory and there's no yes no answer so you have to report some kind of data output the only way which you can report that data output is through DOI so this is again just a little snapshot of what's happening in the world of why we're allocating the DOI's and the connections that we've been working with the ARC around this interface and around their policy and around the infrastructure so that's why we make it part of the Australian research infrastructure so that you can have policies like this from the ARC and you'll see into the future if those related identifiers if we can relate those to ground IDs then when a researcher comes to do the recording at the end there's auto-populate and all sorts of other things in here anyway I'm going to the details of this we will be talking to the sector about this kind of thing in the future but that's just one of the sort of green shoots that are showing how by minting identifiers we're really helping the tracking and reporting the other one is just something that's come up through data site just in the last couple of months actually when you go into search something in the data site system and you find the record then this is one that's come from the Australian Antarctic Division you see down the bottom here they've just started to bring in where there are some back end systems with crossref and other suppliers to check whether there's been any references to this to this data set through other relationships to other DOIs so again another really nice green shoot it's just the beginning it's not perfect yet and this number is potentially a little bit misleading on this particular record but it's just to show you that these making the links between identifiers and really reaping the benefits of having allocated DOIs is what this next ten years of us working with data site and the Australian repositories will be about now I've got extracted there is a question from Nick DOI require persistence of data so is ARDC able to or planning to provide long term curation of research data as a necessary part of the National Data Fabric I wish I hadn't come back to this very last question with only one minute to go yes we are we have other people will know the identifiers and this part of our service arm we also have a lot of projects and other infrastructure data storage infrastructure as well as project infrastructure to build up the infrastructure of the research organizations and research groups in Australia so yes we are that's part of the holistic approach here persistence into the future is a very wicked problem and part of our the way we're approaching that is through these partnerships partnering working with research organizations and research groups to build up their capacity and our injection of national infrastructure into that as part of a partnership I wish I had more time it's five o'clock unless there's anything if I hear from anyone else that there's anything else we need to do before we wrap up I will just thank everyone who's presented thanks very much for that information thanks for getting up early or going to bed late I don't know which one you've done and we look forward to this transition if you take these take-homes if you've got any questions then services at ARDC.edu.au there's a number of support materials that have also been provided by ARDC and by a data site so we will also send the recording of this will be available to participants as well as the slides will send around to anyone who registered I'm not hearing anyone saying that I've forgotten anything if that's the case thank you very much for your time and we look forward to working with you and making this a smooth transition and continuing to reap the benefits of DIYs into the future thanks very much bye thanks everyone