Data Publication at CSIRO and Data Publishing at UQ Library #4 - 16 August 2016
Hogan, Dominic
Morgan, Helen
Data publishing is the process of preparing and publishing research data so that researchers and the broader community can find, access and (re)use the data. Data publishing may include sharing information about research datasets with Research Data Australia or discipline-specific portals or repositories, as well as making collections available to other end users of data, either on an individual basis or through a formal publication process. It can also include activities like minting a persistent identifier for the data and assigning a licence to the data.Most research institutions offer support for data publishing however there are variances in approaches and a common challenge is in working out how to link the process of data publishing with other systems that handle the data during its lifecycle. In this fourth webinar of the Research Data Information Integration Webinar Series, a panel of speakers discuss the data publishing process and systems at their institutions and how it links to the management of research data throughout its lifecycle.
 Good afternoon everyone, my name is Xiaoping Shen. I'm from Ants. Unfortunately, my colleague Natasha is not feeling well today, so I will be your host today. My colleague Susanna is also co-hosting today's webinar with me. This webinar is part of webinar series co-sponsored by Ants and the Council of Australia University Libraries on the theme of research data, information and integrations. Our previous three webinars have already covered the DMP tools, system managing ethics, and data storage. The recording of these three webinars are available on Ants YouTube channel. And today we will talk about the data publishing. First of all, we would like to acknowledge our co-sponsor, the Council of Australia University Libraries. We would like to thank them for their support. Secondly, we would like to say acknowledge Commonwealth Government for their support of Ants un-enquished programs. So with that, let me introduce our first speaker, Dom Hogan. Dom is from Cyro Research Data Service Support Team, Information Management and Technology site. Today, Dom will talk about data publishing at Cyro. Dom, over to you. Yeah, good day everyone. Thanks for having me along. So just to explain the broader context of data in Cyro, I have this little slide here from what things looked like about 10 years ago or maybe a little more than 10 years ago now. And we had about 20 or so – oh, actually, okay, I've forgotten the count – but we had a number of different what were called divisions at the top. And each of these pretty much ran their own show. They got their portion of Cyro's funding. They had their own departments. They had their own libraries. And there was collaboration between divisions and there was collaboration between the libraries. There was a Cyro library network. But all in all, there were varying standards of information management throughout the organization just due to the nature that they were run separately. So around that time, what happened is that there was a change to the formation of information management and technology. And so this was one service for all of the divisions in Cyro, which at the time included IT libraries and records. And that allowed us to take a unified approach to say data storage, networking, computer infrastructure. And so two of the things that came out of this was the publications repository. So we were able to merge our legacy publication citations and also have a unified approval system for new publications from 2009 on. And we also got working on data.cyro.au, which is our data repository. Now as I said before, with those many organizations that we had within CSIRO, some of them had very high data management standards and then others had much lower standards due to the needs of the research. So bringing in this data repository, actually there would have been some organization, some part of the parts of Cyro that actually felt that they had things pretty much under control and they weren't really in need of a new repository, whereas other parts of the organization had been really crying out for this sort of thing. So the goals with this repository was to provide consistent access to data and also version control. So this sort of enables the reproducibility of the scientific outputs so that you can actually get down to individual versions of what you have. And the other goal there was self-service, so we wanted Cyro researchers to be able to just log on and create their own data collections, write their own metadata. Now that can sound a bit scary, as like maybe researchers can be forced to write bad metadata. So far what we found is that the people who are using it are the people who really want to use it, they want to get their data out there and so they usually put the effort in to write fairly decent standard metadata. And there's also an approval system in there so that the approvers can go through and suggest reviewers and there's a little bit of peer review that can go on there. And another goal in here was scalable storage. So as we have many, many terabytes or petabytes of data coming in towards us in the future, the way to store this so that say maybe how things were done before is you would have, I'd say a file server with as much disk space as you could put in there and file sorted however they happen to be. And there's an expectation that those files will be available to me right now. I'll be able to get them. But that's a very expensive way to host data, especially when you're getting into the petabyte scale. So what the depth and what other parts of Sira storage going for is this, these different standards of storage categories so that data that maybe need to be preserved but doesn't necessarily need to be accessed instantly at any given time can sit on tape and then when it's requested it's loaded from tape onto disk where it can then be accessed. And so I've taken this slide from in-corner and Renee Tighouse who are working the storage area of CSIRO. And this is a bit of a model of their idea of a scientific workflow where in our cloud what we have here is the various storage categories. And so the researchers don't need to think of the individual machines hosting any of this data. It's somewhat abstracted from them. All they have to do is know what the address is and then the storage team actually takes care of the rest. So they don't need to migrate between servers when there's an upgrade to the hardware. They can just keep pointing to the same address. And then you have these different storage categories like input. You have the verified work and static. And so they are actually stored on different media that are optimised for different uses. So the static reference data may be sitting on tape and then reloaded later on when we need to reprocess it. And you can also see that the idea in there is that as a project goes on it would be moving the data through various quality control processes and eventually to publication. And the publication part I guess is where the data access portal comes in. But not always. Sometimes it can be a domain repository and then various parts of Soro have their own ways of managing data. But we're trying to move towards having one unified repository that at least catalogs everything in Soro. And we're making progress. So the data access portal itself. Now hopefully no one can read this because I realise there's a few errors in this diagram. But what I'm trying to represent here is that the data access portal is not really just one system. It's actually a few systems that play together nicely. So what we might have, I don't know if anyone can see my mouse cursor here, but so without Soro researcher they're entering metadata into the user interface and uploading at the moment uploading their data to an SFTV staging server. Which is all fairly straightforward and most researchers get that done without ever asking for any help. And then of course you've got a database that stores this data or the metadata and also assesses the data files that come in and records some metadata about the files as well. And then that all gets sent off to this thing called the logical collection manager. And what's happening there is this is the thing that takes in the requests for data or it takes in the submissions for data and then decides what to do with it. So if the data happens to be someone's requesting data from tape so we have our research community and they're saying either asking the user interface or the web services interface for some data then the logical collection manager is going okay well that's sitting on tape I'm going to need that to load that off onto disk here so that then somebody can then download it. And the thing about this tape is that the main delay that happens here is that the tapes themselves move data very fast once they're loaded it's just waiting for the robot to actually load the tape. So even for say a collection that is maybe hundreds of gigabytes typically this will only take about 15-20 minutes before somebody gets the notification saying hey here are the files we can start downloading. And then I also wanted to talk about some of the other systems that feed into this because what we're discovering is that we're going to need to set up this sort of what we're referring to as the data ecosystem. So the various different services and utilities that interact with each other to provide a broader network of data capability. Now here I've got this sort of big database store of SAP that's our organizational information system although I believe there's actually more to it than just SAP so take that with a pinch of salt. But anyway that's one system but it doesn't necessarily present the data for easy use by other systems. So what one of the teams in IM&T have done is create a series of different web services which just for developers really I don't think there's much in the way of a user friendly interface to any of this that takes information from here and from other sources of CSRO so like the publications repository and formats that in a way that then any other say service or application in SRO can then use. So the Data Access Portal grabs our business unit information and our project information from SAP but through these web services. So we don't really need to know how SAP works we just need to know how these web services work and yeah there are really great pieces of infrastructure that sort of sits underneath things and I think a lot of the glory goes to the end applications that wind up doing great things with these but these basic web services are what support that and enable that to happen. And so then once we're in so this is just a screenshot of the organizational data coming through to the Data Access Portal so the user is entering the information, they've selected their business unit and then they select their team and there's other information in there that goes so you can get project information, information about who the project leader is and things like that. And of course we could integrate more of that in the future so for instance there's an interface to our publications repository so we would be able to conceptually say what are the related publications. From these you're listed as an author that sort of thing. Now another thing that happens here with the DAP is we've got various different research groups that have already got metadata in their own systems, their own databases and they wanted to put these things in our repository so these formed pilot projects so we had a microscopy group that have a very complex database and a lot of information about their microscopy images and they wanted to transfer that over so they've got their own interface for doing that which sort of semi-automates the process so the system grabs the metadata out of their databases and then gets the user to just polish up the record, finish off the complete DAP collection record and then they have it in the repository. And a similar thing goes on with the astronomy collection so the first one we set up was the one for pulsar observation and this represents a very large volume of data that also gets used quite a bit and internationally so it's been quite a success and they also have very specific information about the radio astronomy data that they have a custom search and a recent addition to this is another set of radio astronomy data. This is from the Australian Square Kilometer or a Pathfinder project so I have a slide about that now. So this is just a sort of indication of the workflow that really ends with one point in the data access portal but there's a lot that happens before this. So I hope these are antennas and eventually there will be something like 32 of them and they transfer a tremendous volume of data to what's called the correlator. In fact this data, the volume of this data is really too big to actually store. It would be extremely expensive to set up a supercomputer that could do that. So what this correlator does is it then compresses that data down into something that can be transferred to the paucy centre and that data gets processed into what is actually stored. So rather than being, I think at full capacity it's going to be something like five petabytes a year. I didn't write the number down but it's a truly scary volume of data that they're dealing with here. So they crunch this down and then actually store what they're going to store in the data archive. And then they have several different ways of interfacing this. So they have what they call the CASDA application. So that's the SIDAR has CAHPS science data archive. And the astronomy community generally uses these virtual observatory tools which are like programming interfaces to access the data and they can query the data. And just because you can't really download this one even data that would be crazy. They use these programming interfaces to just query it for the data they are interested in. But there's also part of that is gone into the data access portal so that people can just use that user interface there and also search for data and request just the small portions of data that they do want to actually download and use. And then this is another one of the systems that the data access portal interacts with. This one's, it's an open-dap sort of threads server. And this is just one example of a fairly popular collection we have which is a hind cast of ocean waves. What they do is they create these net CDF files and the net CDF files have embedded metadata. They have information about what fields they are and we can see over here that we have information about the layer, what the units are in. There's a whole catalog of various different data sets stored this way. And the beauty of the open-dap services is that it provides various methods of accessing the data that just by default, so here I've shown an example of the mapping service. This is just a running in my browser. But in theory, another spatial portal could just link to the data services that run on top of this and then access the data in their own mapping, custom mapping service for whatever purpose they happen to have in mind. And so what we have in the data access portal is a set of metadata for the collection at large and that just points to these open-dap services. And at the moment, we only have a handful of collections that use this but they are very large. And then the hope is to improve this so that any researcher can just point to an arbitrary open-dap server and say this is where my data is. And that could include services at NCI or other institutions. So here, now oceans and atmospheres, this used to be called marine and atmospheric. Now they have their own metadata catalog for quite some time and they have their own data center with various databases and ways of accessing things. And what came up for them is that the new ship, the RV investigator, is collecting a lot more data than the previous vessels ever did because it has a lot more instruments and higher resolution instruments. So they were looking for a way to store this data securely and also minimise the problems of actually transferring that very large volume of data over the network. So what we do is we grab metadata from their system. They can write it still using the way they used to doing things and then transfer the tapes to our system and we can actually just plug those tapes straight into our tape library and it behaves like other depth collections that have already been prepared. And so what happens there is that they are able to share that with their university collaborators for the quality control process of the data that comes off the ship and then prepare that into data products that then go public. Now here's another example, land and water, that's a group within CSIRO and they also have had a very high standard of data management over the years. So they have this metadata catalogue that they use internally and they use this through the working life of their project. So they have a files server set up and they have very strict naming conventions on the folders and files and then as they go, well, certainly what they encourage their researchers to do is to write metadata, this is just Anselic standard metadata in their system and then what we've done is we've – so for this one and for the marine and atmospheric one, we've enabled the ability to just basically upload the XML. So at the moment that's Anselic or a marine community profile metadata can go in through here and when that's done, so this is just an example of one that's come through. So that's created the depth record, they can move their files in there and make that public or they can just share it with individual people. So we have different restriction levels that we can add to different collections so we can restrict access to the files but leave the metadata public or we can leave restrict access to even the metadata. So there would be some collections in the system that I can't find even as an administrator because I'm restricted from accessing them. Now one thing – I'll just get back to this previous slide so you'll see here that this one gets a DOI and we've got some policies around what gets a DOI, what does not get a DOI. So for instance this one has restricted files. We can see our little padlock here in the files and when we click on that we get told, oh you'll have to log on to access that. So this for whatever reason may be commercial sensitivity or the licences of source data, they are able to share this data. What they get is they get a handle instead. Now we are currently discussing amongst the team about maybe relaxing this so that metadata records can get a DOI. There's a little bit of debate going on there but certainly the researchers would be very keen – a lot of researchers are very keen to use DOIs as a preference for anything that they cite. And then this is an example. So this is a licensed dataset. I didn't want to show one that I can't show to anybody because it's restricted. So this is just one that you can get through GSR Australia and we've got our own copy in there just available to SyroStuff so that they don't have to go download it again. And so when we do that we don't get a DOI and we don't get a handle. This is just using an internal ID system and so this will only show up to SyroStuff for long on. And then we've got version control. So this is a bit of an example of a software collection that's been going through a few different versions and each time a new version gets created. If it's a minor update, say just fixing a typo, then the DOI is maintained. So you'll get several versions but you won't get a new DOI. But in the instance where the data changes, so this is an actual new version of the software and you can see that there are also subsequent versions that have new contributors to the data. So when those versions come through, so if they've changed something significant about these attribution statements, people in the title of the collection, they get a new version and they get a new DOI for each one. So what's in the future? Oh yeah and one thing I have completely neglected to talk about is the development we're doing of a data management plan tool. So if we think back all the way to that workflow where we were looking at, I'm going to, no I won't skip back, it's too many slides. When we think back to that workflow where we had the different categories of storage while researchers were working on their data before publication, they are starting to collect information about the files and information about what happens to those files as it goes. And that combined with the data management plan tool where researchers describe what they're planning to do and how they're planning to store things, we would like to get that metadata feeding into DAP collections so that they already have things written by the time they actually go to create the DAP record and it's less. So people maintain that metadata as they go. There's much lower transaction costs as one of my colleagues says when they're creating the metadata rather than remembering everything right at the end. Another thing we're working on, a number of research groups have been very keen on us setting up some features that would support linked data. So we've got semantic web features coming up like a persistent URL service which is a generally useful thing. What we find is that a lot of researchers would want to get DOIs but they may not really understand the policies around using and maintaining DOIs. So they might think that a DOI is just a persistent URL that points at whatever you want it to point at which it may be more like what a Perl would be. So I'm seeing a need and certainly for linked data there's a need to have persistent URLs that you can define the policies around. So having an institutional wide persistent URL service that both the data access portal could use but that any research group could use for tracking any object. It could be a person, it could be a data file, it could be a piece of software and this would lead in towards things like provenance tracking where you can actually identify each part of the process of the research workflow and record this and then that should improve transparency and reproducibility of the research itself. We also are looking at vocabulary services because that will be much – if for nothing else improving the way we enter keywords into our collections but there are numerous applications for vocabulary and then – so the main thing about this semantic web features is not to have say we're going to implement this all in the data access portal because there are other parts of CSRO that would like to use these services. So things like that persistent URL service may be its own entity. So I think the thing that the researchers are really looking for is the persistence and the reliability of it still being there in 10, 15 years time. So they might be working on short term projects, they might not be able to guarantee that sort of support for themselves but they're hoping the organization can support that and have that commitment to it. And the other thing we're working on with the web services interface is programmatic creation of collections, particularly for a data collection that is fairly routine. So we have say some geologists who are taking a lot of samples and scanning them and they would like to just feed those scans and information about those scans straight into a data collection that they can then reuse later. And so rather than manually going through and creating it each time, which is really infeasible at the moment, having a program that can do that for you, that's what they're looking for and so we're in a testing phase of that right now. So I can't get through this without acknowledging the support of the Australian National Data Service who funded quite a lot of the development of the data. And also that I took one of those slides from Air Corner and RNA Tie House from their presentation at E-Research last year. There is a cost of thousands that have worked on this over the years and this is by no means all of them. These are just a few people that I'm working with lately. So thank you to them and thank you for listening in. Do we have any questions? Yes, Dom, we do. Thank you, Dom. There's a couple of questions here. What do you use for project IDs? Is there a national service? No, we're just using internal identifiers for projects. So this is really just – they're probably codes that wouldn't make much sense outside of CSIRO. That's why I didn't really go into a huge amount of detail about that. So I guess there's certainly four projects that do have that sort of national scope. There's no reason why that couldn't be set up. But at the moment it's really codes that are sort of specific to how SAP works. There's also a comment from the same person who says that they're pushing orchid to supply these. Not quite sure that would work as orchid is pretty much just a person identifier, as far as I remember. Yes, well that's definitely on the list of things that we're trying to implement. So we want to register orchids. And because it's an opt-in thing, we can't just say, hey, everyone in CSIRO, here's your orchid. They have to actually volunteer for that. But yes, we definitely want to link orchids from both CSIRO researchers and external collaborators who are listed into records. Those are one of the identifiers that I think would be very useful. And so when I was talking about persistent identifier services, you know, to fill in gaps because they're all types of objects that could benefit from this that might not be covered by an internationally recognised service. The next question is, what is the policy you mentioned around DOIs? Is it publicly available? I'm not quite sure what the news is. Is the policy publicly available or whether the data is publicly available? Okay, so the policy on DOIs, I'm probably going to have to pass the buck on this. But I believe we can share it. I'm not sure if we've got it. I don't know if I could point to a website that posts it at the moment. So I'll either, well, I'll pass the buck to one of my colleagues. If I can get you to take a name down for that, I'm happy to get back to you. She's come back to say these policies that she wants to have shared. Yeah, yeah. And I believe that is actually part of our, if Sue Cook is in here, you could pass control over to her and give her voice. I think she's got some comments to make about this. She has actually made a comment that says the CSIRO DOI Business Rules are on the ANS website. Oh, there you go. Okay. Others have asked about C2, so they are on the ANS website. Okay, another question is, are there any of the open-depth components available for other research institutions to implement or use? Yeah, I believe, open-depth, I don't think we have a custom implementation of that. That's actually managed by a sort of data services team in Ciro, who I link to the high-performance computing team. So I don't, I'm probably going to guess that none of them are in this webinar. But yeah, as I understand, I believe that some open software that they have implemented there, so I don't think there's anything special about what we've done. Certainly, I know the NECDA or the NCI have some threads servers going, and I'm sure the Bureau of Meteorology do too, so I don't think there's anything particularly novel there. Maybe there's a few implementation details, but I can definitely put you in touch with Gareth Williams, who would be more than happy to talk about that. Jerry's made a comment, Jerry Ryder, who's from ANS, she says, with regards to PURLS for projects, ANS has a service for ARC and an HNMRC grants. Okay, and I think for the moment, that's all of the questions that have come in. Thank you very much. All right, thanks, Sam. Helen is the UQ Project Manager of Scholarly Communication and the Repository Service. Today, Helen will talk about data publishing at UQ. Helen, over to you. Hi, good afternoon, everyone. I was really pleased when Natasha got me to talk about data publishing, because here at UQ Library, we've been trying to build a bit of a solution around that, particularly for the long tail of research data here at UQ. So I have said it specifically about data publishing at UQ Library, because I'm very aware there are some groups around UQ doing some fabulous work in this space, but I will focus very much on what we're doing here in the repository. And so thinking about data publishing really raises questions of why we're going to do it, how we're going to do it, how are researchers going to gain credit for the data that they produce, and particularly how are they going to gain credit, separate from and in addition to the analysis of those data in publications. So what we're really trying to look at is really how we can build those meaningful connections between publishing the data and publishing the scholarly work. It's actually my favorite part of the data life cycle, data publishing, because it can be both the beginning and the end. So it might be that you're tidying up your data at the end of a project and looking to archive it, but if you go one step beyond the start, I do archiving your work and you really start looking at depositing your data or publishing it, and you really are giving sort of the start of another project. You're really, really putting your data out there to become the beginning as well as the end. So there's been talk for a while now about making data a first class scientific output. Here in this paper from 2012, they discussed achieving that through formalizing the methods for citation and publication, and thereby incentivizing data sharing. I think that's really important when we go around talking to researchers here at UQ is to really make sure that they're understanding that the incentives behind sharing data, if we talk about the data with them about being a primary research output, that really starts to click with them and they start to understand more often where we're coming from. Crucially, a point of difference which we talk about with researchers is around archiving data versus publishing data. So if when you archive your research data, that can be obviously very beneficial in terms of preserving the data, but when you publish it, it allows for things like validation and peer review of the data, which really enhances science as a whole. So we're going to researchers talking to them about not only the academic credit that they'll get, but also about that the results of their work will be verified by others, that they'll be able to expose their data to the side of peer review, which to some of them can be quite scary, especially when we're talking again, like I said, to that long tail of research data, who perhaps aren't as familiar with this idea as data sharing is on this, but we're really trying to provide a mechanism to ensure the quality of data sets available. So at UQ, what do researchers want when we go out and talk to them? What is it that we're saying that they want? They would like, I think, research data archive in some way to preserve their research data, a way of sharing it, a way to publish their research data in a way that treats it as a primary research output, and that's crucial, I think, as to why we've implemented the data publishing infrastructure here in our institutional repository. We very much wanted researchers to feel that they were going through that process of publication in a simple way as they would with their other scholarly work. And we do talk to them about peer review and verifiable results, making sure their results are validated and reproducible and the idea of getting academic credit. But I'm just putting all these words in their mouth. I'm not sure the researchers really know that they want that. So when we go out and talk to people, we've done a lot of work in this area and we're very lucky here in the library to have a team of librarians who work in research output services as well as that client service liaison librarians. So we're able to go out and talk to researchers about what they actually do want. So we did a couple of things. We've continually evaluated our data management service since 2014 as well as collected user stories from people. So they tell us that the largest ever data sets they work with perhaps aren't that big. We are really trying to provide this facility here for people who don't have other options who aren't working in these big areas which perhaps provide these nice, fancy work clothes for them. So they're telling us they're not working with huge data sets, but that they have many different types of data. That their storage locations for archived data are a little concerning that they will store it on their external hard drive or on their computer. So we know they want to preserve their data and they want to save it into the future, but perhaps they're not sure about how to do that. We know that 53% of them wanted to keep their data permanently. So the idea of data archiving isn't something that they're adverse to. They're happy to keep their data permanently, but it's taking that next step and actually publishing their data, sharing their data that perhaps they're trying to facilitate. So these are some of the real user stories, real researchers said these aren't things I've made up, that they want to store their research data in such a way that others can cite it. That seems to be really important that they get credit for their work, that they need access to institutional repository storage solutions for their data as required by the journals they intend to publish in. So we did a bit of an environmental scan recently where we looked at for the past five years everything that UQ has published, we analyzed those publications by journal and by funder. And then one of our data librarians went and dug out for the top 25 journals by productivity, so by sheer number of publications at UQ and also by overall time cited. So you can say by an overall total number of sites for papers in certain journals. So we got two lists of top 25 journals, one for productivity and one for overall time cited. What we found were there was policies for those journals, only 7 out of 25 in terms of sheer weight of numbers required data sharing, still a lot, 7 out of 25. But in the highly cited or, you know, journal list of the 25, 18 out of the 25 had a data sharing policy in place. So we know that UQ researchers are publishing in journals a huge number of which 18 out of 25 of which are requiring them to share their data. So this researcher here isn't unusual, the most off frequent phone call we're getting at the moment in the team is people who are trying to publish their research data in a journal that's requiring them to deposit their data somewhere and they're looking for a solution to that problem. They also would like stats on who downloads their data, so that's a little bit more difficult to work through for them, but they are interested in who's looking at their data. This researcher said they needed to be able to securely store their sensitive data but also share it with other researchers and collaborators. So we knew that we had to build infrastructure that made sense to people who had data that perhaps needed to be mediated access. This person would need to be able to permanently store their research data in a way that was open and accessible in order to meet the requirements of a funding agency. So as well as analyzing UQ's research output by journal requirements, we did the same for funding agency requirements. We looked at all the funding agencies named on UQ Research Outputs in the last five years and we found that there are multiple funding agencies that are putting this pressure on to researchers to make sure that their data is open and accessible. That's both Australian ones as well as international ones, named on UQ Research Publications. We knew that they wanted to store and accommodate all the research data along with everything that goes with it, so they need facilities to upload data dictionaries, metadata, lab notebooks so that it can be used by researchers in the future. So these are all really great user stories to come from our researchers. These are really good use cases that we're able to accommodate using our institutional repository. And I do think that over the years that we've been here and talking to researchers, very much the conversation is starting to change and we really are changing that terminology now. So people are beginning to start to talk to us about data publication instead of data sharing. The conversation is really, I think, the start of a culture change here at UQ, which is, I think, very good to see. And the idea that researchers should share data to advance knowledge and promote the common good is quite an old idea, but in recent years, you know, we're really seeing a lot of enthusiasm from them. I think because people are starting to look at how they can get that academic credit and how it can lead to very much a conversation around research integrity and an audit trail from raw to published data, but then also from the published data to the publication. And I think that's where you get very strong trustability. And this is what we're working towards is really the idea that data is deposited alongside and at the same time as publication of any school we are put at a time that UQ researcher is publishing a paper, that we give them an easy workflow and a trusted system for them to deposit the data that goes along with that publication and link the two things together. And really by integrating the data publishing with the other publishing, we're giving them real credibility, trustability. So it says here in this paper, data stewardship is best accomplished in systems and repositories where the custodian has trusted status within their relevant communities. And again, I think that's why it fits really well in the repository and really well with the library. But it also requires your post infrastructure that's quick and simple to use. And we first implemented the form which I will show you very shortly in our repository a couple of years ago. And it has come through a number of iterations where we've tried to make it very user centric and very straightforward for researchers to use. We do want them to do it. We want them to deposit the data. We want them to describe it. And so we're trying to make it so that they can use it and be confident that it's a straightforward workflow. So if it's going to become part of normal scientific practice, it really does have to be easy to achieve. So when researchers come and talk to us about publishing their research data, we will quite often talk to them about if there's a discipline specific repository because I do feel that those are very relevant to certain researchers. And we talk to them about instead of archiving their data on their external hard drive, perhaps go and use a specific repository like that, or we tell them also about UQE space. So the fact that they can actually describe their research data in UQE space, we talk to them about the idea that data that underpin a journal article should be made concurrently available. And we talk to them about the fact that we can link that data metadata record with their publication metadata record. They can be shown to be related objects. And I think that really does – they start to really understand the value behind what we're trying to achieve here. We make it discoverable. So we obviously send all our research data metadata up through to Research Data Australia. And then we also send that through to the data citation index. So we're able to track citations of their data sets through that, which has been really a key thing, I think, for people to really comprehend the impact that this can have, which is really good. So I'll show you a little bit more about how. But we have this needs some extra help – email data at library. So we have a generic email address there, which comes through to the team here in the library. We're very lucky to have some very skilled and specialist data librarians working here. We have – I suppose it's a relatively small team, but a very dedicated team that work very hard to process these records as they come through and to really have those conversations with researchers articulating clearly the relevant funder and journal requirements that they can use the institutional repository that it's known, that it's trusted, that it can integrate with that with the publication workflows and link to that with the related publications or data sets. We try and really keep it very research-centric and build them a profile of their data sets. We can give them DOIs for their data sets. We show them how to license the data set. We show them how to cite it and how they should be showing what the people have to cite their data correctly. We still find a lot of people just either acknowledge a data set or mention it somewhere in the paper, so we're really trying to push them out to proper citation. And then we can do things like if their data is actually stored in a trusted subject specifically, possibly we can link out to that, or they can upload their data if it's a fairly small data set. They can choose mediated access to their data, or they can choose open access so they can actually link to it or upload it, or they can just have a contact person so that people that wear their data sets exist but they would like to mediate their access to that. And we can also add an embargo period if required. So if somebody comes to us and says they need six months, 12 months, an embargo period on their data set, we can facilitate that as well. So this is what EQ Space looks like, the home page. And when you log in, you go into MyUQE Space. You'll notice here you can see myUPO options, that's something that I'll add and can see. So a researcher starts with the tabs My Research, possibly My Research, Admissing Publication, then they have two more options, My Research Data and Admissing Research Data. And I really think by having the data sets up there in that prominent, along with the publications, gives the right message. It gives the status of research data as a primary research output. So they know they're getting the list of my research publications. They know they can claim publications that might possibly be theirs and the system will present those to them. But they can add publications if they think we're missing them, but they can also get a list of their research data, which it looks like this. The data sets below are currently attributed to you and people really like this page. But then they can also go to Admissing Research Data Set and this is what they get. It's a fairly simple form and like I said, we've gone through a couple of different iterations and we are actually looking to, we design all the forms in this space at which point it will get a bit of a facelift, but I think we're pretty happy with the fields that we've got in there at the moment. So the person goes in, they add a simple amount of metadata, not too much. All the mandatory fields are up top so they can fill that in and get a lot of that done very quickly. They go through and they can add access conditions. So this is where they'll tell us if they'd like to be open access or media access. And this is where they'll pick a license in terms of access for the data set, which we talked to them about in great detail because obviously if you're making your data available online, you need to make sure that you're releasing it under conditions that you feel comfortable with and they also allow for reuse. So we talked to them about what the different restrictions on the different licenses mean. We talked to them about copyright and whether or not copyright exists in their data. If copyright doesn't exist in their data, which quite often is the case in Australia, we talked to them about UQ Terms and Conditions, which is a very simple thing that says you can very welcome to use my data, do anything you want with it, but I'd like you to attribute me. So we talked about various options around licensing in terms of access just to make sure that they're feeling comfortable. I think for some people it's quite a new idea that they're just going to put their data out there online or publish their data online. Then we go through various things. They can upload their work. They can add links to location of data if it's for in Pangea or Dryad and with their repository for example. And then they tick a little deposit agreement that says they're the creator or the co-creator that they're authorized to deposit it. They've got permission to include any third party content that it's original, doesn't infringe any legal rights, and that by depositing it, they're granting UQE space a license to reproduce it and make it available. And that the data creators' moral rights will be to be associated or be respected by UQE space. And then before the record's published, it's checked by one of our specialist research output librarians. So every record that comes through, every time a researcher says, add me some data collection and they fill through the metadata, it doesn't go automatically published online. It comes through to our team. We check very carefully through the record and we quite often will contact the researcher and speak to them about the metadata that they've provided and make sure that it's a rich resource because I do feel if you're publishing data, the metadata you provide around it is very important. And to make sure that that data and metadata are consistently high standard would be certainly an aim that we have here at UQE Library. So then you end up with a final record. This is a record from the E-FISH Genomic Database repository. They're a great group here at UQE. They analyze all these amazing fish and sharks and they get all the genomic information of which they say they use roughly about 3% of the information that they collect and then they're very happy to make the full amount of information available online. And you can see here we've got the file actually touched there so people can just download it and we also have a link through to the full text publication. So we're making sure that you've got that trail from the dataset to the publication and also to any other related publications or datasets. I do think that's the main thing here by popping all this information directly into their institutional repository. It's really giving us that advantage and that integration with other aspects of public publishing, which is where you're going to get the credibility I think with researchers. This is the second half of the record. You can see they pick their Creative Commons Attribution but Non-Commercial License. It tells you about type of data. All very standard metadata but enough for you to go off if you're going to try and discover the dataset. So in the future here at UQ, libraries and their plans that we have really centre around creating more of this research-centric data management infrastructure. So we have a couple of different projects on the go at the moment funded by the enhancing systems and services suite of projects. I guess you would call them here at UQ. They are trying very much to provide this umbrella and university-wide infrastructure that's really going to help researchers sort out their work clothes and that includes management and use of the data from the DMP all the way through to storage, preservation and reuse. So we expect this will tie in very closely with the existing information that we have in eSpace. We know from our user research that research has required that easy-to-use infrastructure that's available to them at no cost and that allows for best practice work clothes but with minimum administrative intervention. So we're not trying to give them an administrative task to do but we're trying almost like John said to be collecting that metadata earlier in the process so that by the time it comes to the end of publishing they're not having to remember everything that they've already got quite a well-established set of metadata by that point. So currently at the UQ library we do have a DMP online tool. There's no flaw in a metadata from that into the repository. There's no links to storage provisioning. There's no links to published record metadata. However we are well positioned to capture that information in eSpace because we know we've got the infrastructure I've shown you now. We've got that complementary projects around data sharing. We know we can do the licensing, the DOI. We can send it through to RDA. We can send it through to DCI. So we know we're in a good position to do this. We've done an awful lot of brainstorming and I like the little bit there on the wall that says can do. We know we can do this. There's another one that says it's my data. I'm not publishing it but I don't believe that one. So we really are going to work towards thinking about having an idea of project level minimum viable metadata which can be fleshed out into a DMP which can have other information added to it. We really are at UQ trying to look across a huge number of different disciplines and they all require something slightly different and a few of them have different ideas as to what data publishing even is. So by keeping this idea of minimum viable metadata at the project level, keeping it very simple, that allows I think for as wide as we can possibly get at UQ coverage. We're not trying to go for everyone. I'd said at the beginning there are people at UQ doing this really well without us so we're not trying to over arching trying to get onto all of those people but for the people that don't have working systems, the new system will allow research project level metadata captured in a DMP to cascade through the data lifecycle, automatically provision data storage and then we can use that information to publish one or more dataset metadata records linking back to the original data and also linking forward to a set of publications that came from that project level and data collection. So I think that's a really good situation to be getting into and certainly that's the vision although I think it would be not coming probably I'm going to say 12 months, give me a minute for this. Well it's certainly the direction that we're heading in and I've got a quote here from Vincent Smith who says the power of published data is amplified by ingenuity through applications and uses unimagined by the original and distant from the original field. Without connecting these disparate datasets the true potential of data reuse and repurposing is lost and that's from his paper on data publication towards a database of everything in which he has the idea that perhaps we can I want to say coagulate everything into one large huge database that can be queried and solve all kinds of interesting problems. So I really do think that publishing data is something worth investing a lot of infrastructure, money a lot of thought, a lot of infrastructure into and yeah something we're very excited to be part of here at the library today. Thanks Helen, we look forward to hearing more from you in one year's time but for now Susanna let's move to the question time. Any questions? Yes there is one there. Is it possible that UQ can share the list of journals that require data publishing? I'm about to start working this out for the journals that I see you publishing and it would be great to have a central repository for this information. Yes I'm very happy to share that information. We did look very specifically at UQ's publications of names and then slice the data just everywhere we can publish them but I'd imagine it would be very similar across the university so I'm very happy to share that information. That sounds fantastic. So what software are you using is the question? We use it's an in-house, it's just what's used to build our institute and repository so I do believe it's all open source and online but yeah it's all the in-house development stuff. Apart from the DMP online which is an implementation of the DCCs, DMP online from the UK. Obviously you're welcome with your brilliance Helen. Perfect, thanks everyone, thanks for your time. Thank you.
 Good afternoon everyone, my name is Xiaoping Shen. I'm from Ants. Unfortunately, my colleague  Natasha is not feeling well today, so I will be your host today. My colleague Susanna is  also co-hosting today's webinar with me. This webinar is part of webinar series co-sponsored  by Ants and the Council of Australia University Libraries on the theme of research data, information  and integrations. Our previous three webinars have already covered the DMP tools, system  managing ethics, and data storage. The recording of these three webinars are available on Ants  YouTube channel. And today we will talk about the data publishing. First of all, we would  like to acknowledge our co-sponsor, the Council of Australia University Libraries. We would  like to thank them for their support. Secondly, we would like to say acknowledge Commonwealth  Government for their support of Ants un-enquished programs. So with that, let me introduce our  first speaker, Dom Hogan. Dom is from Cyro Research Data Service Support Team, Information  Management and Technology site. Today, Dom will talk about data publishing at Cyro. Dom,  over to you.  Yeah, good day everyone. Thanks for having me along. So just to explain the broader context  of data in Cyro, I have this little slide here from what things looked like about 10  years ago or maybe a little more than 10 years ago now. And we had about 20 or so – oh,  actually, okay, I've forgotten the count – but we had a number of different what  were called divisions at the top. And each of these pretty much ran their own show. They  got their portion of Cyro's funding. They had their own departments. They had their  own libraries. And there was collaboration between divisions and there was collaboration  between the libraries. There was a Cyro library network. But all in all, there were varying  standards of information management throughout the organization just due to the nature that  they were run separately. So around that time, what happened is that there was a change to  the formation of information management and technology. And so this was one service for  all of the divisions in Cyro, which at the time included IT libraries and records. And  that allowed us to take a unified approach to say data storage, networking, computer  infrastructure. And so two of the things that came out of this was the publications repository.  So we were able to merge our legacy publication citations and also have a unified approval  system for new publications from 2009 on. And we also got working on data.cyro.au, which  is our data repository. Now as I said before, with those many organizations that we had  within CSIRO, some of them had very high data management standards and then others had much  lower standards due to the needs of the research. So bringing in this data repository, actually  there would have been some organization, some part of the parts of Cyro that actually felt  that they had things pretty much under control and they weren't really in need of a new repository,  whereas other parts of the organization had been really crying out for this sort of thing.  So the goals with this repository was to provide consistent access to data and also version  control. So this sort of enables the reproducibility of the scientific outputs so that you can  actually get down to individual versions of what you have. And the other goal there was  self-service, so we wanted Cyro researchers to be able to just log on and create their  own data collections, write their own metadata. Now that can sound a bit scary, as like maybe  researchers can be forced to write bad metadata. So far what we found is that the people who  are using it are the people who really want to use it, they want to get their data out  there and so they usually put the effort in to write fairly decent standard metadata.  And there's also an approval system in there so that the approvers can go through and suggest  reviewers and there's a little bit of peer review that can go on there. And another goal  in here was scalable storage. So as we have many, many terabytes or petabytes of data  coming in towards us in the future, the way to store this so that say maybe how things  were done before is you would have, I'd say a file server with as much disk space as you  could put in there and file sorted however they happen to be. And there's an expectation  that those files will be available to me right now. I'll be able to get them. But that's  a very expensive way to host data, especially when you're getting into the petabyte scale.  So what the depth and what other parts of Sira storage going for is this, these different  standards of storage categories so that data that maybe need to be preserved but doesn't  necessarily need to be accessed instantly at any given time can sit on tape and then  when it's requested it's loaded from tape onto disk where it can then be accessed. And  so I've taken this slide from in-corner and Renee Tighouse who are working the storage  area of CSIRO. And this is a bit of a model of their idea of a scientific workflow where  in our cloud what we have here is the various storage categories. And so the researchers  don't need to think of the individual machines hosting any of this data. It's somewhat abstracted  from them. All they have to do is know what the address is and then the storage team actually  takes care of the rest. So they don't need to migrate between servers when there's an  upgrade to the hardware. They can just keep pointing to the same address. And then you  have these different storage categories like input. You have the verified work and static.  And so they are actually stored on different media that are optimised for different uses.  So the static reference data may be sitting on tape and then reloaded later on when we  need to reprocess it. And you can also see that the idea in there is that as a project  goes on it would be moving the data through various quality control processes and eventually  to publication. And the publication part I guess is where the data access portal comes  in. But not always. Sometimes it can be a domain repository and then various parts of  Soro have their own ways of managing data. But we're trying to move towards having one  unified repository that at least catalogs everything in Soro. And we're making progress.  So the data access portal itself. Now hopefully no one can read this because I realise there's  a few errors in this diagram. But what I'm trying to represent here is that the data  access portal is not really just one system. It's actually a few systems that play together  nicely. So what we might have, I don't know if anyone can see my mouse cursor here, but  so without Soro researcher they're entering metadata into the user interface and uploading  at the moment uploading their data to an SFTV staging server. Which is all fairly straightforward  and most researchers get that done without ever asking for any help. And then of course  you've got a database that stores this data or the metadata and also assesses the data  files that come in and records some metadata about the files as well. And then that all  gets sent off to this thing called the logical collection manager. And what's happening there  is this is the thing that takes in the requests for data or it takes in the submissions for  data and then decides what to do with it. So if the data happens to be someone's requesting  data from tape so we have our research community and they're saying either asking the user  interface or the web services interface for some data then the logical collection manager  is going okay well that's sitting on tape I'm going to need that to load that off onto  disk here so that then somebody can then download it. And the thing about this tape is that  the main delay that happens here is that the tapes themselves move data very fast once  they're loaded it's just waiting for the robot to actually load the tape. So even for say  a collection that is maybe hundreds of gigabytes typically this will only take about 15-20  minutes before somebody gets the notification saying hey here are the files we can start  downloading. And then I also wanted to talk about some of the other systems that feed  into this because what we're discovering is that we're going to need to set up this  sort of what we're referring to as the data ecosystem. So the various different services  and utilities that interact with each other to provide a broader network of data capability.  Now here I've got this sort of big database store of SAP that's our organizational information  system although I believe there's actually more to it than just SAP so take that with  a pinch of salt. But anyway that's one system but it doesn't necessarily present the data  for easy use by other systems. So what one of the teams in IM&T have done is create a  series of different web services which just for developers really I don't think there's  much in the way of a user friendly interface to any of this that takes information from  here and from other sources of CSRO so like the publications repository and formats that  in a way that then any other say service or application in SRO can then use. So the Data  Access Portal grabs our business unit information and our project information from SAP but through  these web services. So we don't really need to know how SAP works we just need to know  how these web services work and yeah there are really great pieces of infrastructure  that sort of sits underneath things and I think a lot of the glory goes to the end applications  that wind up doing great things with these but these basic web services are what support  that and enable that to happen. And so then once we're in so this is just a screenshot  of the organizational data coming through to the Data Access Portal so the user is entering  the information, they've selected their business unit and then they select their team and there's  other information in there that goes so you can get project information, information about  who the project leader is and things like that. And of course we could integrate more  of that in the future so for instance there's an interface to our publications repository  so we would be able to conceptually say what are the related publications. From these you're  listed as an author that sort of thing. Now another thing that happens here with the DAP  is we've got various different research groups that have already got metadata in their own  systems, their own databases and they wanted to put these things in our repository so these  formed pilot projects so we had a microscopy group that have a very complex database and  a lot of information about their microscopy images and they wanted to transfer that over  so they've got their own interface for doing that which sort of semi-automates the process  so the system grabs the metadata out of their databases and then gets the user to just polish  up the record, finish off the complete DAP collection record and then they have it in  the repository. And a similar thing goes on with the astronomy collection so the first  one we set up was the one for pulsar observation and this represents a very large volume of  data that also gets used quite a bit and internationally so it's been quite a success  and they also have very specific information about the radio astronomy data that they have  a custom search and a recent addition to this is another set of radio astronomy data. This  is from the Australian Square Kilometer or a Pathfinder project so I have a slide about  that now. So this is just a sort of indication of the workflow that really ends with one  point in the data access portal but there's a lot that happens before this. So I hope  these are antennas and eventually there will be something like 32 of them and they transfer  a tremendous volume of data to what's called the correlator. In fact this data, the volume  of this data is really too big to actually store. It would be extremely expensive to  set up a supercomputer that could do that. So what this correlator does is it then compresses  that data down into something that can be transferred to the paucy centre and that data  gets processed into what is actually stored. So rather than being, I think at full capacity  it's going to be something like five petabytes a year. I didn't write the number down but  it's a truly scary volume of data that they're dealing with here. So they crunch this down  and then actually store what they're going to store in the data archive. And then they  have several different ways of interfacing this. So they have what they call the CASDA  application. So that's the SIDAR has CAHPS science data archive. And the astronomy community  generally uses these virtual observatory tools which are like programming interfaces to  access the data and they can query the data. And just because you can't really download  this one even data that would be crazy. They use these programming interfaces to just  query it for the data they are interested in. But there's also part of that is gone  into the data access portal so that people can just use that user interface there and  also search for data and request just the small portions of data that they do want to  actually download and use. And then this is another one of the systems that the data access  portal interacts with. This one's, it's an open-dap sort of threads server. And this  is just one example of a fairly popular collection we have which is a hind cast of ocean waves.  What they do is they create these net CDF files and the net CDF files have embedded metadata.  They have information about what fields they are and we can see over here that we have  information about the layer, what the units are in. There's a whole catalog of various  different data sets stored this way. And the beauty of the open-dap services is that it  provides various methods of accessing the data that just by default, so here I've shown  an example of the mapping service. This is just a running in my browser. But in theory,  another spatial portal could just link to the data services that run on top of this and  then access the data in their own mapping, custom mapping service for whatever purpose  they happen to have in mind. And so what we have in the data access portal is a set of  metadata for the collection at large and that just points to these open-dap services. And  at the moment, we only have a handful of collections that use this but they are very large. And  then the hope is to improve this so that any researcher can just point to an arbitrary  open-dap server and say this is where my data is. And that could include services at NCI  or other institutions. So here, now oceans and atmospheres, this used to be called marine  and atmospheric. Now they have their own metadata catalog for quite some time and they have  their own data center with various databases and ways of accessing things. And what came  up for them is that the new ship, the RV investigator, is collecting a lot more data than the previous  vessels ever did because it has a lot more instruments and higher resolution instruments.  So they were looking for a way to store this data securely and also minimise the problems  of actually transferring that very large volume of data over the network. So what we do is  we grab metadata from their system. They can write it still using the way they used to  doing things and then transfer the tapes to our system and we can actually just plug those  tapes straight into our tape library and it behaves like other depth collections that  have already been prepared. And so what happens there is that they are able to share that  with their university collaborators for the quality control process of the data that comes  off the ship and then prepare that into data products that then go public.  Now here's another example, land and water, that's a group within CSIRO and they also  have had a very high standard of data management over the years. So they have this metadata  catalogue that they use internally and they use this through the working life of their  project. So they have a files server set up and they have very strict naming conventions  on the folders and files and then as they go, well, certainly what they encourage their  researchers to do is to write metadata, this is just Anselic standard metadata in their  system and then what we've done is we've – so for this one and for the marine and atmospheric  one, we've enabled the ability to just basically upload the XML. So at the moment that's  Anselic or a marine community profile metadata can go in through here and when that's done,  so this is just an example of one that's come through. So that's created the depth  record, they can move their files in there and make that public or they can just share  it with individual people. So we have different restriction levels that we can add to different  collections so we can restrict access to the files but leave the metadata public or we  can leave restrict access to even the metadata. So there would be some collections in the  system that I can't find even as an administrator because I'm restricted from accessing them.  Now one thing – I'll just get back to this previous slide so you'll see here that this  one gets a DOI and we've got some policies around what gets a DOI, what does not get  a DOI. So for instance this one has restricted files. We can see our little padlock here  in the files and when we click on that we get told, oh you'll have to log on to access  that. So this for whatever reason may be commercial sensitivity or the licences of source data,  they are able to share this data. What they get is they get a handle instead. Now we are  currently discussing amongst the team about maybe relaxing this so that metadata records  can get a DOI. There's a little bit of debate going on there but certainly the researchers  would be very keen – a lot of researchers are very keen to use DOIs as a preference  for anything that they cite. And then this is an example. So this is a licensed dataset.  I didn't want to show one that I can't show to anybody because it's restricted. So this  is just one that you can get through GSR Australia and we've got our own copy in there just  available to SyroStuff so that they don't have to go download it again. And so when  we do that we don't get a DOI and we don't get a handle. This is just using an internal  ID system and so this will only show up to SyroStuff for long on.  And then we've got version control. So this is a bit of an example of a software collection  that's been going through a few different versions and each time a new version gets  created. If it's a minor update, say just fixing a typo, then the DOI is maintained.  So you'll get several versions but you won't get a new DOI. But in the instance where the  data changes, so this is an actual new version of the software and you can see that there  are also subsequent versions that have new contributors to the data. So when those versions  come through, so if they've changed something significant about these attribution statements,  people in the title of the collection, they get a new version and they get a new DOI for  each one.  So what's in the future? Oh yeah and one thing I have completely neglected to talk about  is the development we're doing of a data management plan tool. So if we think back all the way  to that workflow where we were looking at, I'm going to, no I won't skip back, it's too  many slides. When we think back to that workflow where we had the different categories of  storage while researchers were working on their data before publication, they are starting  to collect information about the files and information about what happens to those files  as it goes. And that combined with the data management plan tool where researchers describe  what they're planning to do and how they're planning to store things, we would like to  get that metadata feeding into DAP collections so that they already have things written by  the time they actually go to create the DAP record and it's less. So people maintain that  metadata as they go. There's much lower transaction costs as one of my colleagues says when they're  creating the metadata rather than remembering everything right at the end.  Another thing we're working on, a number of research groups have been very keen on us  setting up some features that would support linked data. So we've got semantic web features  coming up like a persistent URL service which is a generally useful thing. What we find  is that a lot of researchers would want to get DOIs but they may not really understand  the policies around using and maintaining DOIs. So they might think that a DOI is just  a persistent URL that points at whatever you want it to point at which it may be more like  what a Perl would be. So I'm seeing a need and certainly for linked data there's a need  to have persistent URLs that you can define the policies around. So having an institutional  wide persistent URL service that both the data access portal could use but that any  research group could use for tracking any object. It could be a person, it could be  a data file, it could be a piece of software and this would lead in towards things like  provenance tracking where you can actually identify each part of the process of the research  workflow and record this and then that should improve transparency and reproducibility of  the research itself. We also are looking at vocabulary services because that will be much  – if for nothing else improving the way we enter keywords into our collections but  there are numerous applications for vocabulary and then – so the main thing about this semantic  web features is not to have say we're going to implement this all in the data access portal  because there are other parts of CSRO that would like to use these services. So things  like that persistent URL service may be its own entity. So I think the thing that the  researchers are really looking for is the persistence and the reliability of it still  being there in 10, 15 years time. So they might be working on short term projects, they  might not be able to guarantee that sort of support for themselves but they're hoping  the organization can support that and have that commitment to it.  And the other thing we're working on with the web services interface is programmatic  creation of collections, particularly for a data collection that is fairly routine.  So we have say some geologists who are taking a lot of samples and scanning them and they  would like to just feed those scans and information about those scans straight into a data collection  that they can then reuse later. And so rather than manually going through and creating it  each time, which is really infeasible at the moment, having a program that can do that  for you, that's what they're looking for and so we're in a testing phase of that  right now. So I can't get through this without acknowledging the support of the Australian  National Data Service who funded quite a lot of the development of the data. And also  that I took one of those slides from Air Corner and RNA Tie House from their presentation  at E-Research last year. There is a cost of thousands that have worked on this over the  years and this is by no means all of them. These are just a few people that I'm working  with lately. So thank you to them and thank you for listening in. Do we have any questions?  Yes, Dom, we do.  Thank you, Dom.  There's a couple of questions here. What do you use for project IDs? Is there a national  service? No, we're just using internal identifiers for projects. So this is really just – they're  probably codes that wouldn't make much sense outside of CSIRO. That's why I didn't really  go into a huge amount of detail about that. So I guess there's certainly four projects  that do have that sort of national scope. There's no reason why that couldn't be set  up. But at the moment it's really codes that are sort of specific to how SAP works.  There's also a comment from the same person who says that they're pushing orchid to supply  these. Not quite sure that would work as orchid is pretty much just a person identifier,  as far as I remember.  Yes, well that's definitely on the list of things that we're trying to implement. So  we want to register orchids. And because it's an opt-in thing, we can't just say, hey,  everyone in CSIRO, here's your orchid. They have to actually volunteer for that. But yes,  we definitely want to link orchids from both CSIRO researchers and external collaborators  who are listed into records. Those are one of the identifiers that I think would be very  useful. And so when I was talking about persistent identifier services, you know, to fill in  gaps because they're all types of objects that could benefit from this that might not  be covered by an internationally recognised service.  The next question is, what is the policy you mentioned around DOIs? Is it publicly available?  I'm not quite sure what the news is. Is the policy publicly available or whether the data  is publicly available?  Okay, so the policy on DOIs, I'm probably going to have to pass the buck on this. But  I believe we can share it. I'm not sure if we've got it. I don't know if I could point  to a website that posts it at the moment. So I'll either, well, I'll pass the buck to  one of my colleagues. If I can get you to take a name down for that, I'm happy to get  back to you.  She's come back to say these policies that she wants to have shared.  Yeah, yeah. And I believe that is actually part of our, if Sue Cook is in here, you could  pass control over to her and give her voice. I think she's got some comments to make about  this.  She has actually made a comment that says the CSIRO DOI Business Rules are on the ANS  website.  Oh, there you go. Okay.  Others have asked about C2, so they are on the ANS website. Okay, another question is,  are there any of the open-depth components available for other research institutions  to implement or use?  Yeah, I believe, open-depth, I don't think we have a custom implementation of that.  That's actually managed by a sort of data services team in Ciro, who I link to the high-performance  computing team. So I don't, I'm probably going to guess that none of them are in this  webinar. But yeah, as I understand, I believe that some open software that they have implemented  there, so I don't think there's anything special about what we've done. Certainly,  I know the NECDA or the NCI have some threads servers going, and I'm sure the Bureau of  Meteorology do too, so I don't think there's anything particularly novel there. Maybe there's  a few implementation details, but I can definitely put you in touch with Gareth Williams, who  would be more than happy to talk about that.  Jerry's made a comment, Jerry Ryder, who's from ANS, she says, with regards to PURLS for  projects, ANS has a service for ARC and an HNMRC grants. Okay, and I think for the moment,  that's all of the questions that have come in.  Thank you very much.  All right, thanks, Sam. Helen is the UQ Project Manager of Scholarly Communication and the  Repository Service. Today, Helen will talk about data publishing at UQ. Helen, over to  you.  Hi, good afternoon, everyone. I was really pleased when Natasha got me to talk about  data publishing, because here at UQ Library, we've been trying to build a bit of a solution  around that, particularly for the long tail of research data here at UQ. So I have said  it specifically about data publishing at UQ Library, because I'm very aware there are  some groups around UQ doing some fabulous work in this space, but I will focus very much  on what we're doing here in the repository.  And so thinking about data publishing really raises questions of why we're going to do  it, how we're going to do it, how are researchers going to gain credit for the data that they  produce, and particularly how are they going to gain credit, separate from and in addition  to the analysis of those data in publications. So what we're really trying to look at is  really how we can build those meaningful connections between publishing the data and  publishing the scholarly work. It's actually my favorite part of the data life cycle, data  publishing, because it can be both the beginning and the end. So it might be that you're tidying  up your data at the end of a project and looking to archive it, but if you go one step beyond  the start, I do archiving your work and you really start looking at depositing your data  or publishing it, and you really are giving sort of the start of another project. You're  really, really putting your data out there to become the beginning as well as the end.  So there's been talk for a while now about making data a first class scientific output.  Here in this paper from 2012, they discussed achieving that through formalizing the methods  for citation and publication, and thereby incentivizing data sharing. I think that's  really important when we go around talking to researchers here at UQ is to really make  sure that they're understanding that the incentives behind sharing data, if we talk about the  data with them about being a primary research output, that really starts to click with them  and they start to understand more often where we're coming from.  Crucially, a point of difference which we talk about with researchers is around archiving  data versus publishing data. So if when you archive your research data, that can be obviously  very beneficial in terms of preserving the data, but when you publish it, it allows for  things like validation and peer review of the data, which really enhances science as  a whole. So we're going to researchers talking to them about not only the academic credit  that they'll get, but also about that the results of their work will be verified by  others, that they'll be able to expose their data to the side of peer review, which to  some of them can be quite scary, especially when we're talking again, like I said, to  that long tail of research data, who perhaps aren't as familiar with this idea as data  sharing is on this, but we're really trying to provide a mechanism to ensure the quality  of data sets available.  So at UQ, what do researchers want when we go out and talk to them? What is it that we're  saying that they want? They would like, I think, research data archive in some way to  preserve their research data, a way of sharing it, a way to publish their research data in  a way that treats it as a primary research output, and that's crucial, I think, as to  why we've implemented the data publishing infrastructure here in our institutional repository.  We very much wanted researchers to feel that they were going through that process of publication  in a simple way as they would with their other scholarly work. And we do talk to them about  peer review and verifiable results, making sure their results are validated and reproducible  and the idea of getting academic credit. But I'm just putting all these words in their  mouth. I'm not sure the researchers really know that they want that. So when we go out  and talk to people, we've done a lot of work in this area and we're very lucky here in  the library to have a team of librarians who work in research output services as well as  that client service liaison librarians. So we're able to go out and talk to researchers  about what they actually do want. So we did a couple of things. We've continually evaluated  our data management service since 2014 as well as collected user stories from people.  So they tell us that the largest ever data sets they work with perhaps aren't that big.  We are really trying to provide this facility here for people who don't have other options  who aren't working in these big areas which perhaps provide these nice, fancy work clothes  for them. So they're telling us they're not working with huge data sets, but that they  have many different types of data. That their storage locations for archived data are a  little concerning that they will store it on their external hard drive or on their computer.  So we know they want to preserve their data and they want to save it into the future,  but perhaps they're not sure about how to do that. We know that 53% of them wanted to  keep their data permanently. So the idea of data archiving isn't something that they're  adverse to. They're happy to keep their data permanently, but it's taking that next step  and actually publishing their data, sharing their data that perhaps they're trying to  facilitate. So these are some of the real user stories, real researchers said these  aren't things I've made up, that they want to store their research data in such a way  that others can cite it. That seems to be really important that they get credit for  their work, that they need access to institutional repository storage solutions for their data  as required by the journals they intend to publish in. So we did a bit of an environmental  scan recently where we looked at for the past five years everything that UQ has published,  we analyzed those publications by journal and by funder. And then one of our data librarians  went and dug out for the top 25 journals by productivity, so by sheer number of publications  at UQ and also by overall time cited. So you can say by an overall total number of sites  for papers in certain journals. So we got two lists of top 25 journals, one for productivity  and one for overall time cited. What we found were there was policies for those journals,  only 7 out of 25 in terms of sheer weight of numbers required data sharing, still a lot,  7 out of 25. But in the highly cited or, you know, journal list of the 25, 18 out of the  25 had a data sharing policy in place. So we know that UQ researchers are publishing  in journals a huge number of which 18 out of 25 of which are requiring them to share  their data. So this researcher here isn't unusual, the most off frequent phone call  we're getting at the moment in the team is people who are trying to publish their research  data in a journal that's requiring them to deposit their data somewhere and they're  looking for a solution to that problem. They also would like stats on who downloads their  data, so that's a little bit more difficult to work through for them, but they are interested  in who's looking at their data. This researcher said they needed to be able to securely store  their sensitive data but also share it with other researchers and collaborators. So we  knew that we had to build infrastructure that made sense to people who had data that perhaps  needed to be mediated access. This person would need to be able to permanently store  their research data in a way that was open and accessible in order to meet the requirements  of a funding agency. So as well as analyzing UQ's research output by journal requirements,  we did the same for funding agency requirements. We looked at all the funding agencies named  on UQ Research Outputs in the last five years and we found that there are multiple funding  agencies that are putting this pressure on to researchers to make sure that their data  is open and accessible. That's both Australian ones as well as international ones, named  on UQ Research Publications. We knew that they wanted to store and accommodate all the  research data along with everything that goes with it, so they need facilities to upload  data dictionaries, metadata, lab notebooks so that it can be used by researchers in the  future. So these are all really great user stories to come from our researchers. These  are really good use cases that we're able to accommodate using our institutional repository.  And I do think that over the years that we've been here and talking to researchers, very  much the conversation is starting to change and we really are changing that terminology  now. So people are beginning to start to talk to us about data publication instead of data  sharing. The conversation is really, I think, the start of a culture change here at UQ,  which is, I think, very good to see. And the idea that researchers should share data to  advance knowledge and promote the common good is quite an old idea, but in recent years,  you know, we're really seeing a lot of enthusiasm from them. I think because people are starting  to look at how they can get that academic credit and how it can lead to very much a  conversation around research integrity and an audit trail from raw to published data,  but then also from the published data to the publication. And I think that's where  you get very strong trustability. And this is what we're working towards is really the  idea that data is deposited alongside and at the same time as publication of any school  we are put at a time that UQ researcher is publishing a paper, that we give them an  easy workflow and a trusted system for them to deposit the data that goes along with that  publication and link the two things together. And really by integrating the data publishing  with the other publishing, we're giving them real credibility, trustability. So it says  here in this paper, data stewardship is best accomplished in systems and repositories where  the custodian has trusted status within their relevant communities. And again, I think that's  why it fits really well in the repository and really well with the library. But it also  requires your post infrastructure that's quick and simple to use. And we first implemented  the form which I will show you very shortly in our repository a couple of years ago. And  it has come through a number of iterations where we've tried to make it very user centric  and very straightforward for researchers to use. We do want them to do it. We want them  to deposit the data. We want them to describe it. And so we're trying to make it so that  they can use it and be confident that it's a straightforward workflow. So if it's going  to become part of normal scientific practice, it really does have to be easy to achieve.  So when researchers come and talk to us about publishing their research data, we will quite  often talk to them about if there's a discipline specific repository because I do feel that  those are very relevant to certain researchers. And we talk to them about instead of archiving  their data on their external hard drive, perhaps go and use a specific repository like that,  or we tell them also about UQE space. So the fact that they can actually describe their  research data in UQE space, we talk to them about the idea that data that underpin a journal  article should be made concurrently available. And we talk to them about the fact that we  can link that data metadata record with their publication metadata record. They can be  shown to be related objects. And I think that really does – they start to really understand  the value behind what we're trying to achieve here. We make it discoverable. So we obviously  send all our research data metadata up through to Research Data Australia. And then we also  send that through to the data citation index. So we're able to track citations of their  data sets through that, which has been really a key thing, I think, for people to really  comprehend the impact that this can have, which is really good. So I'll show you a  little bit more about how. But we have this needs some extra help – email data at library.  So we have a generic email address there, which comes through to the team here in the  library. We're very lucky to have some very skilled and specialist data librarians working  here. We have – I suppose it's a relatively small team, but a very dedicated team that  work very hard to process these records as they come through and to really have those  conversations with researchers articulating clearly the relevant funder and journal requirements  that they can use the institutional repository that it's known, that it's trusted, that  it can integrate with that with the publication workflows and link to that with the related  publications or data sets. We try and really keep it very research-centric and build them  a profile of their data sets. We can give them DOIs for their data sets. We show them  how to license the data set. We show them how to cite it and how they should be showing  what the people have to cite their data correctly. We still find a lot of people just either  acknowledge a data set or mention it somewhere in the paper, so we're really trying to push  them out to proper citation. And then we can do things like if their data is actually  stored in a trusted subject specifically, possibly we can link out to that, or they  can upload their data if it's a fairly small data set. They can choose mediated access  to their data, or they can choose open access so they can actually link to it or upload  it, or they can just have a contact person so that people that wear their data sets exist  but they would like to mediate their access to that. And we can also add an embargo period  if required. So if somebody comes to us and says they need six months, 12 months, an embargo  period on their data set, we can facilitate that as well. So this is what EQ Space looks  like, the home page. And when you log in, you go into MyUQE Space. You'll notice here  you can see myUPO options, that's something that I'll add and can see. So a researcher  starts with the tabs My Research, possibly My Research, Admissing Publication, then  they have two more options, My Research Data and Admissing Research Data. And I really  think by having the data sets up there in that prominent, along with the publications,  gives the right message. It gives the status of research data as a primary research output.  So they know they're getting the list of my research publications. They know they can  claim publications that might possibly be theirs and the system will present those to  them. But they can add publications if they think we're missing them, but they can also  get a list of their research data, which it looks like this. The data sets below are currently  attributed to you and people really like this page. But then they can also go to Admissing  Research Data Set and this is what they get. It's a fairly simple form and like I said,  we've gone through a couple of different iterations and we are actually looking to, we design  all the forms in this space at which point it will get a bit of a facelift, but I think  we're pretty happy with the fields that we've got in there at the moment. So the person  goes in, they add a simple amount of metadata, not too much. All the mandatory fields are  up top so they can fill that in and get a lot of that done very quickly. They go through  and they can add access conditions. So this is where they'll tell us if they'd like to  be open access or media access. And this is where they'll pick a license in terms of access  for the data set, which we talked to them about in great detail because obviously if  you're making your data available online, you need to make sure that you're releasing  it under conditions that you feel comfortable with and they also allow for reuse. So we  talked to them about what the different restrictions on the different licenses mean. We talked  to them about copyright and whether or not copyright exists in their data. If copyright  doesn't exist in their data, which quite often is the case in Australia, we talked to them  about UQ Terms and Conditions, which is a very simple thing that says you can very welcome  to use my data, do anything you want with it, but I'd like you to attribute me. So we talked  about various options around licensing in terms of access just to make sure that they're  feeling comfortable. I think for some people it's quite a new idea that they're just going  to put their data out there online or publish their data online. Then we go through various  things. They can upload their work. They can add links to location of data if it's for  in Pangea or Dryad and with their repository for example. And then they tick a little deposit  agreement that says they're the creator or the co-creator that they're authorized to  deposit it. They've got permission to include any third party content that it's original,  doesn't infringe any legal rights, and that by depositing it, they're granting UQE space  a license to reproduce it and make it available. And that the data creators' moral rights  will be to be associated or be respected by UQE space. And then before the record's published,  it's checked by one of our specialist research output librarians. So every record that comes  through, every time a researcher says, add me some data collection and they fill through  the metadata, it doesn't go automatically published online. It comes through to our  team. We check very carefully through the record and we quite often will contact the  researcher and speak to them about the metadata that they've provided and make sure that it's  a rich resource because I do feel if you're publishing data, the metadata you provide  around it is very important. And to make sure that that data and metadata are consistently  high standard would be certainly an aim that we have here at UQE Library.  So then you end up with a final record. This is a record from the E-FISH Genomic Database  repository. They're a great group here at UQE. They analyze all these amazing fish and sharks  and they get all the genomic information of which they say they use roughly about 3% of  the information that they collect and then they're very happy to make the full amount  of information available online. And you can see here we've got the file actually touched  there so people can just download it and we also have a link through to the full text  publication. So we're making sure that you've got that trail from the dataset to the publication  and also to any other related publications or datasets. I do think that's the main thing  here by popping all this information directly into their institutional repository. It's  really giving us that advantage and that integration with other aspects of public publishing,  which is where you're going to get the credibility I think with researchers. This is the second  half of the record. You can see they pick their Creative Commons Attribution but Non-Commercial  License. It tells you about type of data. All very standard metadata but enough for  you to go off if you're going to try and discover the dataset. So in the future here  at UQ, libraries and their plans that we have really centre around creating more of this  research-centric data management infrastructure. So we have a couple of different projects  on the go at the moment funded by the enhancing systems and services suite of projects. I  guess you would call them here at UQ. They are trying very much to provide this umbrella  and university-wide infrastructure that's really going to help researchers sort out  their work clothes and that includes management and use of the data from the DMP all the way  through to storage, preservation and reuse. So we expect this will tie in very closely  with the existing information that we have in eSpace. We know from our user research  that research has required that easy-to-use infrastructure that's available to them at  no cost and that allows for best practice work clothes but with minimum administrative  intervention. So we're not trying to give them an administrative task to do but we're  trying almost like John said to be collecting that metadata earlier in the process so that  by the time it comes to the end of publishing they're not having to remember everything  that they've already got quite a well-established set of metadata by that point. So currently  at the UQ library we do have a DMP online tool. There's no flaw in a metadata from  that into the repository. There's no links to storage provisioning. There's no links  to published record metadata. However we are well positioned to capture that information  in eSpace because we know we've got the infrastructure I've shown you now. We've got that complementary  projects around data sharing. We know we can do the licensing, the DOI. We can send it  through to RDA. We can send it through to DCI. So we know we're in a good position to  do this. We've done an awful lot of brainstorming and I like the little bit there on the wall  that says can do. We know we can do this. There's another one that says it's my data.  I'm not publishing it but I don't believe that one. So we really are going to work towards  thinking about having an idea of project level minimum viable metadata which can be fleshed  out into a DMP which can have other information added to it. We really are at UQ trying to  look across a huge number of different disciplines and they all require something slightly different  and a few of them have different ideas as to what data publishing even is. So by keeping  this idea of minimum viable metadata at the project level, keeping it very simple, that  allows I think for as wide as we can possibly get at UQ coverage. We're not trying to go  for everyone. I'd said at the beginning there are people at UQ doing this really well without  us so we're not trying to over arching trying to get onto all of those people but for the  people that don't have working systems, the new system will allow research project level  metadata captured in a DMP to cascade through the data lifecycle, automatically provision  data storage and then we can use that information to publish one or more dataset metadata records  linking back to the original data and also linking forward to a set of publications that  came from that project level and data collection. So I think that's a really good situation  to be getting into and certainly that's the vision although I think it would be not coming  probably I'm going to say 12 months, give me a minute for this. Well it's certainly  the direction that we're heading in and I've got a quote here from Vincent Smith who says  the power of published data is amplified by ingenuity through applications and uses unimagined  by the original and distant from the original field. Without connecting these disparate  datasets the true potential of data reuse and repurposing is lost and that's from his  paper on data publication towards a database of everything in which he has the idea that  perhaps we can I want to say coagulate everything into one large huge database that can be queried  and solve all kinds of interesting problems. So I really do think that publishing data  is something worth investing a lot of infrastructure, money a lot of thought, a lot of infrastructure  into and yeah something we're very excited to be part of here at the library today.  Thanks Helen, we look forward to hearing more from you in one year's time but for now  Susanna let's move to the question time. Any questions?  Yes there is one there. Is it possible that UQ can share the list of journals that require  data publishing? I'm about to start working this out for the journals that I see you  publishing and it would be great to have a central repository for this information.  Yes I'm very happy to share that information. We did look very specifically at UQ's publications  of names and then slice the data just everywhere we can publish them but I'd imagine it would  be very similar across the university so I'm very happy to share that information.  That sounds fantastic. So what software are you using is the question?  We use it's an in-house, it's just what's used to build our institute and repository  so I do believe it's all open source and online but yeah it's all the in-house development  stuff. Apart from the DMP online which is an implementation of the DCCs, DMP online from  the UK. Obviously you're welcome with your brilliance Helen.  Perfect, thanks everyone, thanks for your time.  Thank you.
Data_Publishing_eaybZBlAXeY_0_1427.png Data_Publishing_eaybZBlAXeY_1428_2063.png Data_Publishing_eaybZBlAXeY_2064_3167.png Data_Publishing_eaybZBlAXeY_3168_5183.png Data_Publishing_eaybZBlAXeY_5184_8171.png Data_Publishing_eaybZBlAXeY_8172_10523.png Data_Publishing_eaybZBlAXeY_10524_13223.png Data_Publishing_eaybZBlAXeY_13224_15767.png Data_Publishing_eaybZBlAXeY_15768_16691.png Data_Publishing_eaybZBlAXeY_16692_18671.png Data_Publishing_eaybZBlAXeY_18672_21227.png Data_Publishing_eaybZBlAXeY_21228_23519.png Data_Publishing_eaybZBlAXeY_23520_25151.png Data_Publishing_eaybZBlAXeY_25152_26207.png Data_Publishing_eaybZBlAXeY_26208_26507.png Data_Publishing_eaybZBlAXeY_26508_27263.png Data_Publishing_eaybZBlAXeY_27264_27323.png Data_Publishing_eaybZBlAXeY_27324_27551.png Data_Publishing_eaybZBlAXeY_27552_28583.png Data_Publishing_eaybZBlAXeY_28584_29231.png Data_Publishing_eaybZBlAXeY_29232_30335.png Data_Publishing_eaybZBlAXeY_30336_30551.png Data_Publishing_eaybZBlAXeY_30552_36011.png Data_Publishing_eaybZBlAXeY_36012_36191.png Data_Publishing_eaybZBlAXeY_36192_36359.png Data_Publishing_eaybZBlAXeY_36360_36467.png Data_Publishing_eaybZBlAXeY_36468_36539.png Data_Publishing_eaybZBlAXeY_36540_36611.png Data_Publishing_eaybZBlAXeY_36612_36671.png Data_Publishing_eaybZBlAXeY_36672_36767.png Data_Publishing_eaybZBlAXeY_36768_37235.png Data_Publishing_eaybZBlAXeY_37236_37751.png Data_Publishing_eaybZBlAXeY_37752_38303.png Data_Publishing_eaybZBlAXeY_38304_40679.png Data_Publishing_eaybZBlAXeY_40680_42299.png Data_Publishing_eaybZBlAXeY_42300_43835.png Data_Publishing_eaybZBlAXeY_43836_44471.png Data_Publishing_eaybZBlAXeY_44472_45347.png Data_Publishing_eaybZBlAXeY_45348_46667.png Data_Publishing_eaybZBlAXeY_46668_47915.png Data_Publishing_eaybZBlAXeY_47916_48527.png Data_Publishing_eaybZBlAXeY_48528_48959.png Data_Publishing_eaybZBlAXeY_48960_49031.png Data_Publishing_eaybZBlAXeY_49032_49391.png Data_Publishing_eaybZBlAXeY_49392_49799.png Data_Publishing_eaybZBlAXeY_49800_52487.png Data_Publishing_eaybZBlAXeY_52488_52883.png Data_Publishing_eaybZBlAXeY_52884_53735.png Data_Publishing_eaybZBlAXeY_53736_54491.png Data_Publishing_eaybZBlAXeY_54492_55595.png Data_Publishing_eaybZBlAXeY_55596_57647.png Data_Publishing_eaybZBlAXeY_57648_58235.png Data_Publishing_eaybZBlAXeY_58236_58643.png Data_Publishing_eaybZBlAXeY_58644_62027.png Data_Publishing_eaybZBlAXeY_62028_62135.png Data_Publishing_eaybZBlAXeY_62136_63407.png Data_Publishing_eaybZBlAXeY_63408_63575.png Data_Publishing_eaybZBlAXeY_63576_64247.png Data_Publishing_eaybZBlAXeY_64248_65783.png Data_Publishing_eaybZBlAXeY_65784_66011.png Data_Publishing_eaybZBlAXeY_66012_66647.png Data_Publishing_eaybZBlAXeY_66648_67727.png Data_Publishing_eaybZBlAXeY_67728_69143.png Data_Publishing_eaybZBlAXeY_69144_69503.png Data_Publishing_eaybZBlAXeY_69504_70607.png Data_Publishing_eaybZBlAXeY_70608_71339.png Data_Publishing_eaybZBlAXeY_71340_71387.png Data_Publishing_eaybZBlAXeY_71388_71543.png Data_Publishing_eaybZBlAXeY_71544_72131.png Data_Publishing_eaybZBlAXeY_72132_72551.png Data_Publishing_eaybZBlAXeY_72552_76007.png Data_Publishing_eaybZBlAXeY_76008_76079.png Data_Publishing_eaybZBlAXeY_76080_76139.png Data_Publishing_eaybZBlAXeY_76140_77039.png Data_Publishing_eaybZBlAXeY_77040_77087.png Data_Publishing_eaybZBlAXeY_77088_77615.png Data_Publishing_eaybZBlAXeY_77616_77724.png
Good afternoon everyone, my name is Xiaoping Shen. I'm from Ants. Unfortunately, my colleague Natasha is not feeling well today, so I will be your host today. My colleague Susanna is also co-hosting today's webinar with me. This webinar is part of webinar series co-sponsored by Ants and the Council of Australia University Libraries on the theme of research data, information and integrations. Our previous three webinars have already covered the DMP tools, system managing ethics, and data storage. The recording of these three webinars are available on Ants YouTube channel. And today we will talk about the data publishing. First of all, we would like to acknowledge our co-sponsor, the Council of Australia University Libraries. We would like to thank them for their support. Secondly, we would like to say acknowledge Commonwealth Government for their support of Ants un-enquished programs. So with that, let me introduce our first speaker, Dom Hogan. Dom is from Cyro Research Data Service Support Team, Information Management and Technology site. Today, Dom will talk about data publishing at Cyro. Dom, over to you. Yeah, good day everyone. Thanks for having me along. So just to explain the broader context of data in Cyro, I have this little slide here from what things looked like about 10 years ago or maybe a little more than 10 years ago now. And we had about 20 or so – oh, actually, okay, I've forgotten the count – but we had a number of different what were called divisions at the top. And each of these pretty much ran their own show. They got their portion of Cyro's funding. They had their own departments. They had their own libraries. And there was collaboration between divisions and there was collaboration between the libraries. There was a Cyro library network. But all in all, there were varying standards of information management throughout the organization just due to the nature that they were run separately. So around that time, what happened is that there was a change to the formation of information management and technology. And so this was one service for all of the divisions in Cyro, which at the time included IT libraries and records. And that allowed us to take a unified approach to say data storage, networking, computer infrastructure. And so two of the things that came out of this was the publications repository. So we were able to merge our legacy publication citations and also have a unified approval system for new publications from 2009 on. And we also got working on data.cyro.au, which is our data repository. Now as I said before, with those many organizations that we had within CSIRO, some of them had very high data management standards and then others had much lower standards due to the needs of the research. So bringing in this data repository, actually there would have been some organization, some part of the parts of Cyro that actually felt that they had things pretty much under control and they weren't really in need of a new repository, whereas other parts of the organization had been really crying out for this sort of thing. So the goals with this repository was to provide consistent access to data and also version control. So this sort of enables the reproducibility of the scientific outputs so that you can actually get down to individual versions of what you have. And the other goal there was self-service, so we wanted Cyro researchers to be able to just log on and create their own data collections, write their own metadata. Now that can sound a bit scary, as like maybe researchers can be forced to write bad metadata. So far what we found is that the people who are using it are the people who really want to use it, they want to get their data out there and so they usually put the effort in to write fairly decent standard metadata. And there's also an approval system in there so that the approvers can go through and suggest reviewers and there's a little bit of peer review that can go on there. And another goal in here was scalable storage. So as we have many, many terabytes or petabytes of data coming in towards us in the future, the way to store this so that say maybe how things were done before is you would have, I'd say a file server with as much disk space as you could put in there and file sorted however they happen to be. And there's an expectation that those files will be available to me right now. I'll be able to get them. But that's a very expensive way to host data, especially when you're getting into the petabyte scale. So what the depth and what other parts of Sira storage going for is this, these different standards of storage categories so that data that maybe need to be preserved but doesn't necessarily need to be accessed instantly at any given time can sit on tape and then when it's requested it's loaded from tape onto disk where it can then be accessed. And so I've taken this slide from in-corner and Renee Tighouse who are working the storage area of CSIRO. And this is a bit of a model of their idea of a scientific workflow where in our cloud what we have here is the various storage categories. And so the researchers don't need to think of the individual machines hosting any of this data. It's somewhat abstracted from them. All they have to do is know what the address is and then the storage team actually takes care of the rest. So they don't need to migrate between servers when there's an upgrade to the hardware. They can just keep pointing to the same address. And then you have these different storage categories like input. You have the verified work and static. And so they are actually stored on different media that are optimised for different uses. So the static reference data may be sitting on tape and then reloaded later on when we need to reprocess it. And you can also see that the idea in there is that as a project goes on it would be moving the data through various quality control processes and eventually to publication. And the publication part I guess is where the data access portal comes in. But not always. Sometimes it can be a domain repository and then various parts of Soro have their own ways of managing data. But we're trying to move towards having one unified repository that at least catalogs everything in Soro. And we're making progress. So the data access portal itself. Now hopefully no one can read this because I realise there's a few errors in this diagram. But what I'm trying to represent here is that the data access portal is not really just one system. It's actually a few systems that play together nicely. So what we might have, I don't know if anyone can see my mouse cursor here, but so without Soro researcher they're entering metadata into the user interface and uploading at the moment uploading their data to an SFTV staging server. Which is all fairly straightforward and most researchers get that done without ever asking for any help. And then of course you've got a database that stores this data or the metadata and also assesses the data files that come in and records some metadata about the files as well. And then that all gets sent off to this thing called the logical collection manager. And what's happening there is this is the thing that takes in the requests for data or it takes in the submissions for data and then decides what to do with it. So if the data happens to be someone's requesting data from tape so we have our research community and they're saying either asking the user interface or the web services interface for some data then the logical collection manager is going okay well that's sitting on tape I'm going to need that to load that off onto disk here so that then somebody can then download it. And the thing about this tape is that the main delay that happens here is that the tapes themselves move data very fast once they're loaded it's just waiting for the robot to actually load the tape. So even for say a collection that is maybe hundreds of gigabytes typically this will only take about 15-20 minutes before somebody gets the notification saying hey here are the files we can start downloading. And then I also wanted to talk about some of the other systems that feed into this because what we're discovering is that we're going to need to set up this sort of what we're referring to as the data ecosystem. So the various different services and utilities that interact with each other to provide a broader network of data capability. Now here I've got this sort of big database store of SAP that's our organizational information system although I believe there's actually more to it than just SAP so take that with a pinch of salt. But anyway that's one system but it doesn't necessarily present the data for easy use by other systems. So what one of the teams in IM&T have done is create a series of different web services which just for developers really I don't think there's much in the way of a user friendly interface to any of this that takes information from here and from other sources of CSRO so like the publications repository and formats that in a way that then any other say service or application in SRO can then use. So the Data Access Portal grabs our business unit information and our project information from SAP but through these web services. So we don't really need to know how SAP works we just need to know how these web services work and yeah there are really great pieces of infrastructure that sort of sits underneath things and I think a lot of the glory goes to the end applications that wind up doing great things with these but these basic web services are what support that and enable that to happen. And so then once we're in so this is just a screenshot of the organizational data coming through to the Data Access Portal so the user is entering the information, they've selected their business unit and then they select their team and there's other information in there that goes so you can get project information, information about who the project leader is and things like that. And of course we could integrate more of that in the future so for instance there's an interface to our publications repository so we would be able to conceptually say what are the related publications. From these you're listed as an author that sort of thing. Now another thing that happens here with the DAP is we've got various different research groups that have already got metadata in their own systems, their own databases and they wanted to put these things in our repository so these formed pilot projects so we had a microscopy group that have a very complex database and a lot of information about their microscopy images and they wanted to transfer that over so they've got their own interface for doing that which sort of semi-automates the process so the system grabs the metadata out of their databases and then gets the user to just polish up the record, finish off the complete DAP collection record and then they have it in the repository. And a similar thing goes on with the astronomy collection so the first one we set up was the one for pulsar observation and this represents a very large volume of data that also gets used quite a bit and internationally so it's been quite a success and they also have very specific information about the radio astronomy data that they have a custom search and a recent addition to this is another set of radio astronomy data. This is from the Australian Square Kilometer or a Pathfinder project so I have a slide about that now. So this is just a sort of indication of the workflow that really ends with one point in the data access portal but there's a lot that happens before this. So I hope these are antennas and eventually there will be something like 32 of them and they transfer a tremendous volume of data to what's called the correlator. In fact this data, the volume of this data is really too big to actually store. It would be extremely expensive to set up a supercomputer that could do that. So what this correlator does is it then compresses that data down into something that can be transferred to the paucy centre and that data gets processed into what is actually stored. So rather than being, I think at full capacity it's going to be something like five petabytes a year. I didn't write the number down but it's a truly scary volume of data that they're dealing with here. So they crunch this down and then actually store what they're going to store in the data archive. And then they have several different ways of interfacing this. So they have what they call the CASDA application. So that's the SIDAR has CAHPS science data archive. And the astronomy community generally uses these virtual observatory tools which are like programming interfaces to access the data and they can query the data. And just because you can't really download this one even data that would be crazy. They use these programming interfaces to just query it for the data they are interested in. But there's also part of that is gone into the data access portal so that people can just use that user interface there and also search for data and request just the small portions of data that they do want to actually download and use. And then this is another one of the systems that the data access portal interacts with. This one's, it's an open-dap sort of threads server. And this is just one example of a fairly popular collection we have which is a hind cast of ocean waves. What they do is they create these net CDF files and the net CDF files have embedded metadata. They have information about what fields they are and we can see over here that we have information about the layer, what the units are in. There's a whole catalog of various different data sets stored this way. And the beauty of the open-dap services is that it provides various methods of accessing the data that just by default, so here I've shown an example of the mapping service. This is just a running in my browser. But in theory, another spatial portal could just link to the data services that run on top of this and then access the data in their own mapping, custom mapping service for whatever purpose they happen to have in mind. And so what we have in the data access portal is a set of metadata for the collection at large and that just points to these open-dap services. And at the moment, we only have a handful of collections that use this but they are very large. And then the hope is to improve this so that any researcher can just point to an arbitrary open-dap server and say this is where my data is. And that could include services at NCI or other institutions. So here, now oceans and atmospheres, this used to be called marine and atmospheric. Now they have their own metadata catalog for quite some time and they have their own data center with various databases and ways of accessing things. And what came up for them is that the new ship, the RV investigator, is collecting a lot more data than the previous vessels ever did because it has a lot more instruments and higher resolution instruments. So they were looking for a way to store this data securely and also minimise the problems of actually transferring that very large volume of data over the network. So what we do is we grab metadata from their system. They can write it still using the way they used to doing things and then transfer the tapes to our system and we can actually just plug those tapes straight into our tape library and it behaves like other depth collections that have already been prepared. And so what happens there is that they are able to share that with their university collaborators for the quality control process of the data that comes off the ship and then prepare that into data products that then go public. Now here's another example, land and water, that's a group within CSIRO and they also have had a very high standard of data management over the years. So they have this metadata catalogue that they use internally and they use this through the working life of their project. So they have a files server set up and they have very strict naming conventions on the folders and files and then as they go, well, certainly what they encourage their researchers to do is to write metadata, this is just Anselic standard metadata in their system and then what we've done is we've – so for this one and for the marine and atmospheric one, we've enabled the ability to just basically upload the XML. So at the moment that's Anselic or a marine community profile metadata can go in through here and when that's done, so this is just an example of one that's come through. So that's created the depth record, they can move their files in there and make that public or they can just share it with individual people. So we have different restriction levels that we can add to different collections so we can restrict access to the files but leave the metadata public or we can leave restrict access to even the metadata. So there would be some collections in the system that I can't find even as an administrator because I'm restricted from accessing them. Now one thing – I'll just get back to this previous slide so you'll see here that this one gets a DOI and we've got some policies around what gets a DOI, what does not get a DOI. So for instance this one has restricted files. We can see our little padlock here in the files and when we click on that we get told, oh you'll have to log on to access that. So this for whatever reason may be commercial sensitivity or the licences of source data, they are able to share this data. What they get is they get a handle instead. Now we are currently discussing amongst the team about maybe relaxing this so that metadata records can get a DOI. There's a little bit of debate going on there but certainly the researchers would be very keen – a lot of researchers are very keen to use DOIs as a preference for anything that they cite. And then this is an example. So this is a licensed dataset. I didn't want to show one that I can't show to anybody because it's restricted. So this is just one that you can get through GSR Australia and we've got our own copy in there just available to SyroStuff so that they don't have to go download it again. And so when we do that we don't get a DOI and we don't get a handle. This is just using an internal ID system and so this will only show up to SyroStuff for long on. And then we've got version control. So this is a bit of an example of a software collection that's been going through a few different versions and each time a new version gets created. If it's a minor update, say just fixing a typo, then the DOI is maintained. So you'll get several versions but you won't get a new DOI. But in the instance where the data changes, so this is an actual new version of the software and you can see that there are also subsequent versions that have new contributors to the data. So when those versions come through, so if they've changed something significant about these attribution statements, people in the title of the collection, they get a new version and they get a new DOI for each one. So what's in the future? Oh yeah and one thing I have completely neglected to talk about is the development we're doing of a data management plan tool. So if we think back all the way to that workflow where we were looking at, I'm going to, no I won't skip back, it's too many slides. When we think back to that workflow where we had the different categories of storage while researchers were working on their data before publication, they are starting to collect information about the files and information about what happens to those files as it goes. And that combined with the data management plan tool where researchers describe what they're planning to do and how they're planning to store things, we would like to get that metadata feeding into DAP collections so that they already have things written by the time they actually go to create the DAP record and it's less. So people maintain that metadata as they go. There's much lower transaction costs as one of my colleagues says when they're creating the metadata rather than remembering everything right at the end. Another thing we're working on, a number of research groups have been very keen on us setting up some features that would support linked data. So we've got semantic web features coming up like a persistent URL service which is a generally useful thing. What we find is that a lot of researchers would want to get DOIs but they may not really understand the policies around using and maintaining DOIs. So they might think that a DOI is just a persistent URL that points at whatever you want it to point at which it may be more like what a Perl would be. So I'm seeing a need and certainly for linked data there's a need to have persistent URLs that you can define the policies around. So having an institutional wide persistent URL service that both the data access portal could use but that any research group could use for tracking any object. It could be a person, it could be a data file, it could be a piece of software and this would lead in towards things like provenance tracking where you can actually identify each part of the process of the research workflow and record this and then that should improve transparency and reproducibility of the research itself. We also are looking at vocabulary services because that will be much – if for nothing else improving the way we enter keywords into our collections but there are numerous applications for vocabulary and then – so the main thing about this semantic web features is not to have say we're going to implement this all in the data access portal because there are other parts of CSRO that would like to use these services. So things like that persistent URL service may be its own entity. So I think the thing that the researchers are really looking for is the persistence and the reliability of it still being there in 10, 15 years time. So they might be working on short term projects, they might not be able to guarantee that sort of support for themselves but they're hoping the organization can support that and have that commitment to it. And the other thing we're working on with the web services interface is programmatic creation of collections, particularly for a data collection that is fairly routine. So we have say some geologists who are taking a lot of samples and scanning them and they would like to just feed those scans and information about those scans straight into a data collection that they can then reuse later. And so rather than manually going through and creating it each time, which is really infeasible at the moment, having a program that can do that for you, that's what they're looking for and so we're in a testing phase of that right now. So I can't get through this without acknowledging the support of the Australian National Data Service who funded quite a lot of the development of the data. And also that I took one of those slides from Air Corner and RNA Tie House from their presentation at E-Research last year. There is a cost of thousands that have worked on this over the years and this is by no means all of them. These are just a few people that I'm working with lately. So thank you to them and thank you for listening in. Do we have any questions? Yes, Dom, we do. Thank you, Dom. There's a couple of questions here. What do you use for project IDs? Is there a national service? No, we're just using internal identifiers for projects. So this is really just – they're probably codes that wouldn't make much sense outside of CSIRO. That's why I didn't really go into a huge amount of detail about that. So I guess there's certainly four projects that do have that sort of national scope. There's no reason why that couldn't be set up. But at the moment it's really codes that are sort of specific to how SAP works. There's also a comment from the same person who says that they're pushing orchid to supply these. Not quite sure that would work as orchid is pretty much just a person identifier, as far as I remember. Yes, well that's definitely on the list of things that we're trying to implement. So we want to register orchids. And because it's an opt-in thing, we can't just say, hey, everyone in CSIRO, here's your orchid. They have to actually volunteer for that. But yes, we definitely want to link orchids from both CSIRO researchers and external collaborators who are listed into records. Those are one of the identifiers that I think would be very useful. And so when I was talking about persistent identifier services, you know, to fill in gaps because they're all types of objects that could benefit from this that might not be covered by an internationally recognised service. The next question is, what is the policy you mentioned around DOIs? Is it publicly available? I'm not quite sure what the news is. Is the policy publicly available or whether the data is publicly available? Okay, so the policy on DOIs, I'm probably going to have to pass the buck on this. But I believe we can share it. I'm not sure if we've got it. I don't know if I could point to a website that posts it at the moment. So I'll either, well, I'll pass the buck to one of my colleagues. If I can get you to take a name down for that, I'm happy to get back to you. She's come back to say these policies that she wants to have shared. Yeah, yeah. And I believe that is actually part of our, if Sue Cook is in here, you could pass control over to her and give her voice. I think she's got some comments to make about this. She has actually made a comment that says the CSIRO DOI Business Rules are on the ANS website. Oh, there you go. Okay. Others have asked about C2, so they are on the ANS website. Okay, another question is, are there any of the open-depth components available for other research institutions to implement or use? Yeah, I believe, open-depth, I don't think we have a custom implementation of that. That's actually managed by a sort of data services team in Ciro, who I link to the high-performance computing team. So I don't, I'm probably going to guess that none of them are in this webinar. But yeah, as I understand, I believe that some open software that they have implemented there, so I don't think there's anything special about what we've done. Certainly, I know the NECDA or the NCI have some threads servers going, and I'm sure the Bureau of Meteorology do too, so I don't think there's anything particularly novel there. Maybe there's a few implementation details, but I can definitely put you in touch with Gareth Williams, who would be more than happy to talk about that. Jerry's made a comment, Jerry Ryder, who's from ANS, she says, with regards to PURLS for projects, ANS has a service for ARC and an HNMRC grants. Okay, and I think for the moment, that's all of the questions that have come in. Thank you very much. All right, thanks, Sam. Helen is the UQ Project Manager of Scholarly Communication and the Repository Service. Today, Helen will talk about data publishing at UQ. Helen, over to you. Hi, good afternoon, everyone. I was really pleased when Natasha got me to talk about data publishing, because here at UQ Library, we've been trying to build a bit of a solution around that, particularly for the long tail of research data here at UQ. So I have said it specifically about data publishing at UQ Library, because I'm very aware there are some groups around UQ doing some fabulous work in this space, but I will focus very much on what we're doing here in the repository. And so thinking about data publishing really raises questions of why we're going to do it, how we're going to do it, how are researchers going to gain credit for the data that they produce, and particularly how are they going to gain credit, separate from and in addition to the analysis of those data in publications. So what we're really trying to look at is really how we can build those meaningful connections between publishing the data and publishing the scholarly work. It's actually my favorite part of the data life cycle, data publishing, because it can be both the beginning and the end. So it might be that you're tidying up your data at the end of a project and looking to archive it, but if you go one step beyond the start, I do archiving your work and you really start looking at depositing your data or publishing it, and you really are giving sort of the start of another project. You're really, really putting your data out there to become the beginning as well as the end. So there's been talk for a while now about making data a first class scientific output. Here in this paper from 2012, they discussed achieving that through formalizing the methods for citation and publication, and thereby incentivizing data sharing. I think that's really important when we go around talking to researchers here at UQ is to really make sure that they're understanding that the incentives behind sharing data, if we talk about the data with them about being a primary research output, that really starts to click with them and they start to understand more often where we're coming from. Crucially, a point of difference which we talk about with researchers is around archiving data versus publishing data. So if when you archive your research data, that can be obviously very beneficial in terms of preserving the data, but when you publish it, it allows for things like validation and peer review of the data, which really enhances science as a whole. So we're going to researchers talking to them about not only the academic credit that they'll get, but also about that the results of their work will be verified by others, that they'll be able to expose their data to the side of peer review, which to some of them can be quite scary, especially when we're talking again, like I said, to that long tail of research data, who perhaps aren't as familiar with this idea as data sharing is on this, but we're really trying to provide a mechanism to ensure the quality of data sets available. So at UQ, what do researchers want when we go out and talk to them? What is it that we're saying that they want? They would like, I think, research data archive in some way to preserve their research data, a way of sharing it, a way to publish their research data in a way that treats it as a primary research output, and that's crucial, I think, as to why we've implemented the data publishing infrastructure here in our institutional repository. We very much wanted researchers to feel that they were going through that process of publication in a simple way as they would with their other scholarly work. And we do talk to them about peer review and verifiable results, making sure their results are validated and reproducible and the idea of getting academic credit. But I'm just putting all these words in their mouth. I'm not sure the researchers really know that they want that. So when we go out and talk to people, we've done a lot of work in this area and we're very lucky here in the library to have a team of librarians who work in research output services as well as that client service liaison librarians. So we're able to go out and talk to researchers about what they actually do want. So we did a couple of things. We've continually evaluated our data management service since 2014 as well as collected user stories from people. So they tell us that the largest ever data sets they work with perhaps aren't that big. We are really trying to provide this facility here for people who don't have other options who aren't working in these big areas which perhaps provide these nice, fancy work clothes for them. So they're telling us they're not working with huge data sets, but that they have many different types of data. That their storage locations for archived data are a little concerning that they will store it on their external hard drive or on their computer. So we know they want to preserve their data and they want to save it into the future, but perhaps they're not sure about how to do that. We know that 53% of them wanted to keep their data permanently. So the idea of data archiving isn't something that they're adverse to. They're happy to keep their data permanently, but it's taking that next step and actually publishing their data, sharing their data that perhaps they're trying to facilitate. So these are some of the real user stories, real researchers said these aren't things I've made up, that they want to store their research data in such a way that others can cite it. That seems to be really important that they get credit for their work, that they need access to institutional repository storage solutions for their data as required by the journals they intend to publish in. So we did a bit of an environmental scan recently where we looked at for the past five years everything that UQ has published, we analyzed those publications by journal and by funder. And then one of our data librarians went and dug out for the top 25 journals by productivity, so by sheer number of publications at UQ and also by overall time cited. So you can say by an overall total number of sites for papers in certain journals. So we got two lists of top 25 journals, one for productivity and one for overall time cited. What we found were there was policies for those journals, only 7 out of 25 in terms of sheer weight of numbers required data sharing, still a lot, 7 out of 25. But in the highly cited or, you know, journal list of the 25, 18 out of the 25 had a data sharing policy in place. So we know that UQ researchers are publishing in journals a huge number of which 18 out of 25 of which are requiring them to share their data. So this researcher here isn't unusual, the most off frequent phone call we're getting at the moment in the team is people who are trying to publish their research data in a journal that's requiring them to deposit their data somewhere and they're looking for a solution to that problem. They also would like stats on who downloads their data, so that's a little bit more difficult to work through for them, but they are interested in who's looking at their data. This researcher said they needed to be able to securely store their sensitive data but also share it with other researchers and collaborators. So we knew that we had to build infrastructure that made sense to people who had data that perhaps needed to be mediated access. This person would need to be able to permanently store their research data in a way that was open and accessible in order to meet the requirements of a funding agency. So as well as analyzing UQ's research output by journal requirements, we did the same for funding agency requirements. We looked at all the funding agencies named on UQ Research Outputs in the last five years and we found that there are multiple funding agencies that are putting this pressure on to researchers to make sure that their data is open and accessible. That's both Australian ones as well as international ones, named on UQ Research Publications. We knew that they wanted to store and accommodate all the research data along with everything that goes with it, so they need facilities to upload data dictionaries, metadata, lab notebooks so that it can be used by researchers in the future. So these are all really great user stories to come from our researchers. These are really good use cases that we're able to accommodate using our institutional repository. And I do think that over the years that we've been here and talking to researchers, very much the conversation is starting to change and we really are changing that terminology now. So people are beginning to start to talk to us about data publication instead of data sharing. The conversation is really, I think, the start of a culture change here at UQ, which is, I think, very good to see. And the idea that researchers should share data to advance knowledge and promote the common good is quite an old idea, but in recent years, you know, we're really seeing a lot of enthusiasm from them. I think because people are starting to look at how they can get that academic credit and how it can lead to very much a conversation around research integrity and an audit trail from raw to published data, but then also from the published data to the publication. And I think that's where you get very strong trustability. And this is what we're working towards is really the idea that data is deposited alongside and at the same time as publication of any school we are put at a time that UQ researcher is publishing a paper, that we give them an easy workflow and a trusted system for them to deposit the data that goes along with that publication and link the two things together. And really by integrating the data publishing with the other publishing, we're giving them real credibility, trustability. So it says here in this paper, data stewardship is best accomplished in systems and repositories where the custodian has trusted status within their relevant communities. And again, I think that's why it fits really well in the repository and really well with the library. But it also requires your post infrastructure that's quick and simple to use. And we first implemented the form which I will show you very shortly in our repository a couple of years ago. And it has come through a number of iterations where we've tried to make it very user centric and very straightforward for researchers to use. We do want them to do it. We want them to deposit the data. We want them to describe it. And so we're trying to make it so that they can use it and be confident that it's a straightforward workflow. So if it's going to become part of normal scientific practice, it really does have to be easy to achieve. So when researchers come and talk to us about publishing their research data, we will quite often talk to them about if there's a discipline specific repository because I do feel that those are very relevant to certain researchers. And we talk to them about instead of archiving their data on their external hard drive, perhaps go and use a specific repository like that, or we tell them also about UQE space. So the fact that they can actually describe their research data in UQE space, we talk to them about the idea that data that underpin a journal article should be made concurrently available. And we talk to them about the fact that we can link that data metadata record with their publication metadata record. They can be shown to be related objects. And I think that really does – they start to really understand the value behind what we're trying to achieve here. We make it discoverable. So we obviously send all our research data metadata up through to Research Data Australia. And then we also send that through to the data citation index. So we're able to track citations of their data sets through that, which has been really a key thing, I think, for people to really comprehend the impact that this can have, which is really good. So I'll show you a little bit more about how. But we have this needs some extra help – email data at library. So we have a generic email address there, which comes through to the team here in the library. We're very lucky to have some very skilled and specialist data librarians working here. We have – I suppose it's a relatively small team, but a very dedicated team that work very hard to process these records as they come through and to really have those conversations with researchers articulating clearly the relevant funder and journal requirements that they can use the institutional repository that it's known, that it's trusted, that it can integrate with that with the publication workflows and link to that with the related publications or data sets. We try and really keep it very research-centric and build them a profile of their data sets. We can give them DOIs for their data sets. We show them how to license the data set. We show them how to cite it and how they should be showing what the people have to cite their data correctly. We still find a lot of people just either acknowledge a data set or mention it somewhere in the paper, so we're really trying to push them out to proper citation. And then we can do things like if their data is actually stored in a trusted subject specifically, possibly we can link out to that, or they can upload their data if it's a fairly small data set. They can choose mediated access to their data, or they can choose open access so they can actually link to it or upload it, or they can just have a contact person so that people that wear their data sets exist but they would like to mediate their access to that. And we can also add an embargo period if required. So if somebody comes to us and says they need six months, 12 months, an embargo period on their data set, we can facilitate that as well. So this is what EQ Space looks like, the home page. And when you log in, you go into MyUQE Space. You'll notice here you can see myUPO options, that's something that I'll add and can see. So a researcher starts with the tabs My Research, possibly My Research, Admissing Publication, then they have two more options, My Research Data and Admissing Research Data. And I really think by having the data sets up there in that prominent, along with the publications, gives the right message. It gives the status of research data as a primary research output. So they know they're getting the list of my research publications. They know they can claim publications that might possibly be theirs and the system will present those to them. But they can add publications if they think we're missing them, but they can also get a list of their research data, which it looks like this. The data sets below are currently attributed to you and people really like this page. But then they can also go to Admissing Research Data Set and this is what they get. It's a fairly simple form and like I said, we've gone through a couple of different iterations and we are actually looking to, we design all the forms in this space at which point it will get a bit of a facelift, but I think we're pretty happy with the fields that we've got in there at the moment. So the person goes in, they add a simple amount of metadata, not too much. All the mandatory fields are up top so they can fill that in and get a lot of that done very quickly. They go through and they can add access conditions. So this is where they'll tell us if they'd like to be open access or media access. And this is where they'll pick a license in terms of access for the data set, which we talked to them about in great detail because obviously if you're making your data available online, you need to make sure that you're releasing it under conditions that you feel comfortable with and they also allow for reuse. So we talked to them about what the different restrictions on the different licenses mean. We talked to them about copyright and whether or not copyright exists in their data. If copyright doesn't exist in their data, which quite often is the case in Australia, we talked to them about UQ Terms and Conditions, which is a very simple thing that says you can very welcome to use my data, do anything you want with it, but I'd like you to attribute me. So we talked about various options around licensing in terms of access just to make sure that they're feeling comfortable. I think for some people it's quite a new idea that they're just going to put their data out there online or publish their data online. Then we go through various things. They can upload their work. They can add links to location of data if it's for in Pangea or Dryad and with their repository for example. And then they tick a little deposit agreement that says they're the creator or the co-creator that they're authorized to deposit it. They've got permission to include any third party content that it's original, doesn't infringe any legal rights, and that by depositing it, they're granting UQE space a license to reproduce it and make it available. And that the data creators' moral rights will be to be associated or be respected by UQE space. And then before the record's published, it's checked by one of our specialist research output librarians. So every record that comes through, every time a researcher says, add me some data collection and they fill through the metadata, it doesn't go automatically published online. It comes through to our team. We check very carefully through the record and we quite often will contact the researcher and speak to them about the metadata that they've provided and make sure that it's a rich resource because I do feel if you're publishing data, the metadata you provide around it is very important. And to make sure that that data and metadata are consistently high standard would be certainly an aim that we have here at UQE Library. So then you end up with a final record. This is a record from the E-FISH Genomic Database repository. They're a great group here at UQE. They analyze all these amazing fish and sharks and they get all the genomic information of which they say they use roughly about 3% of the information that they collect and then they're very happy to make the full amount of information available online. And you can see here we've got the file actually touched there so people can just download it and we also have a link through to the full text publication. So we're making sure that you've got that trail from the dataset to the publication and also to any other related publications or datasets. I do think that's the main thing here by popping all this information directly into their institutional repository. It's really giving us that advantage and that integration with other aspects of public publishing, which is where you're going to get the credibility I think with researchers. This is the second half of the record. You can see they pick their Creative Commons Attribution but Non-Commercial License. It tells you about type of data. All very standard metadata but enough for you to go off if you're going to try and discover the dataset. So in the future here at UQ, libraries and their plans that we have really centre around creating more of this research-centric data management infrastructure. So we have a couple of different projects on the go at the moment funded by the enhancing systems and services suite of projects. I guess you would call them here at UQ. They are trying very much to provide this umbrella and university-wide infrastructure that's really going to help researchers sort out their work clothes and that includes management and use of the data from the DMP all the way through to storage, preservation and reuse. So we expect this will tie in very closely with the existing information that we have in eSpace. We know from our user research that research has required that easy-to-use infrastructure that's available to them at no cost and that allows for best practice work clothes but with minimum administrative intervention. So we're not trying to give them an administrative task to do but we're trying almost like John said to be collecting that metadata earlier in the process so that by the time it comes to the end of publishing they're not having to remember everything that they've already got quite a well-established set of metadata by that point. So currently at the UQ library we do have a DMP online tool. There's no flaw in a metadata from that into the repository. There's no links to storage provisioning. There's no links to published record metadata. However we are well positioned to capture that information in eSpace because we know we've got the infrastructure I've shown you now. We've got that complementary projects around data sharing. We know we can do the licensing, the DOI. We can send it through to RDA. We can send it through to DCI. So we know we're in a good position to do this. We've done an awful lot of brainstorming and I like the little bit there on the wall that says can do. We know we can do this. There's another one that says it's my data. I'm not publishing it but I don't believe that one. So we really are going to work towards thinking about having an idea of project level minimum viable metadata which can be fleshed out into a DMP which can have other information added to it. We really are at UQ trying to look across a huge number of different disciplines and they all require something slightly different and a few of them have different ideas as to what data publishing even is. So by keeping this idea of minimum viable metadata at the project level, keeping it very simple, that allows I think for as wide as we can possibly get at UQ coverage. We're not trying to go for everyone. I'd said at the beginning there are people at UQ doing this really well without us so we're not trying to over arching trying to get onto all of those people but for the people that don't have working systems, the new system will allow research project level metadata captured in a DMP to cascade through the data lifecycle, automatically provision data storage and then we can use that information to publish one or more dataset metadata records linking back to the original data and also linking forward to a set of publications that came from that project level and data collection. So I think that's a really good situation to be getting into and certainly that's the vision although I think it would be not coming probably I'm going to say 12 months, give me a minute for this. Well it's certainly the direction that we're heading in and I've got a quote here from Vincent Smith who says the power of published data is amplified by ingenuity through applications and uses unimagined by the original and distant from the original field. Without connecting these disparate datasets the true potential of data reuse and repurposing is lost and that's from his paper on data publication towards a database of everything in which he has the idea that perhaps we can I want to say coagulate everything into one large huge database that can be queried and solve all kinds of interesting problems. So I really do think that publishing data is something worth investing a lot of infrastructure, money a lot of thought, a lot of infrastructure into and yeah something we're very excited to be part of here at the library today. Thanks Helen, we look forward to hearing more from you in one year's time but for now Susanna let's move to the question time. Any questions? Yes there is one there. Is it possible that UQ can share the list of journals that require data publishing? I'm about to start working this out for the journals that I see you publishing and it would be great to have a central repository for this information. Yes I'm very happy to share that information. We did look very specifically at UQ's publications of names and then slice the data just everywhere we can publish them but I'd imagine it would be very similar across the university so I'm very happy to share that information. That sounds fantastic. So what software are you using is the question? We use it's an in-house, it's just what's used to build our institute and repository so I do believe it's all open source and online but yeah it's all the in-house development stuff. Apart from the DMP online which is an implementation of the DCCs, DMP online from the UK. Obviously you're welcome with your brilliance Helen. Perfect, thanks everyone, thanks for your time. Thank you.
on the theme of research data, information and management throughout the organization just due data or it takes in the submissions for data and about some of the other systems that feed into of the organizational data coming through to the complex database and a lot of information about portal interacts with. This one's, it's an just available to SyroStuff so that they don't coming up like a persistent URL service which is part of the process of the research workflow and in the data access portal because there are other is the persistence and the reliability of it to link orchids from both CSIRO researchers and talking about persistent identifier services, you for other research institutions to implement or it specifically about data publishing at UQ beginning as well as the end. So there's been about data publication instead of data sharing. that academic credit and how it can lead to very still find a lot of people just either link out to that, or they can upload their data also go to Admissing Research Data Set and this about to start working this out for the journals