WEBVTT

1
00:00:18.040 --> 00:00:32.179
Rachael Lammey: Okay, welcome everyone. I can see the participant, the participant number ticking up as people join this demos experiments. And Q&A session today.

2
00:00:33.010 --> 00:00:44.680
Rachael Lammey: thank you for joining and hopefully, you will find lots of relevance interest and things to ask questions about over the over, the course of the session.

3
00:00:46.900 --> 00:00:56.880
Rachael Lammey: it said, I'm just going to give a few more minutes in case anyone else is trying to join. Find the link. All of those kind of things, and then we'll get started.

4
00:01:08.210 --> 00:01:12.470
Rachael Lammey: Okay, so let's let's go to the the next slide.

5
00:01:16.060 --> 00:01:18.479
Rachael Lammey: So again, just

6
00:01:18.890 --> 00:01:32.919
Rachael Lammey: for some of you who've joined the earlier sessions today. You'll have heard our notes. But just to make you aware of Cross Ref's code of conduct. If you are on

7
00:01:33.280 --> 00:01:40.769
Rachael Lammey: if you are on mastodon or X, then you can join the discussion. We'd welcome you to do so on those platforms.

8
00:01:40.770 --> 00:02:04.499
Rachael Lammey: But I think probably the most effective thing for this session is, if you've got questions, use the QA. Box to pose those to our our presenters. We're going to take questions for each of the presenters, after after each of their sections. So that they're still fresh in your mind, and we will share the slides and recordings.

9
00:02:04.500 --> 00:02:06.959
Rachael Lammey: Afterwards. Next slide.

10
00:02:08.979 --> 00:02:11.420
Rachael Lammey: I'm the

11
00:02:12.270 --> 00:02:21.350
Rachael Lammey: reminder. You've got, I think, around 2 h left. So if you haven't voted for the 2023 board slate, then

12
00:02:22.040 --> 00:02:48.930
Rachael Lammey: our ballots close pretty soon, but if you wish to submit a vote or change your proxy, vote, then then let Lucy know in her emails in this. So we've got a really good interesting slate of candidates this year. So part of being a member of Crossref is having the capacity to be able to vote and make sure that our Board is as representative as possible of you and your communities and your needs. So we'd really encourage you to do that

13
00:02:50.860 --> 00:02:52.000
Rachael Lammey: next slide.

14
00:02:54.290 --> 00:03:24.360
Rachael Lammey: So I'm going to start by introducing the session. As I said, this is product demos, experiments and questions for those who are willing to to present would say, the aim of this session is to give a view across the things that we are at the early stages of exploring and working on both from the product and development teams and also you'll see strong representation from the from the labs team across Ref as well.

15
00:03:24.620 --> 00:03:29.750
Rachael Lammey: We're gonna give some hints and tips for using our Apis

16
00:03:30.080 --> 00:03:44.400
Rachael Lammey: ones that you're probably very familiar with, or would like to get more familiar with and newer ones as well, and then external integrations with our with cross ref from our colleagues at the Public knowledge project

17
00:03:44.520 --> 00:04:05.239
Rachael Lammey: for whom it's very early. So so thank you, Eric. Each demo will last for around 1520 min, and we should have time for questions for our panelists. So Luis and I are. Gonna keep an eye on the QA. And try to make sure that those get to the right people at at the right time.

18
00:04:05.570 --> 00:04:06.560
Rachael Lammey: So

19
00:04:09.220 --> 00:04:11.979
Rachael Lammey: our first demo is

20
00:04:13.040 --> 00:04:29.629
Rachael Lammey: is currently under development. So again, we've got for a couple of these things are under active development. We've tried to step away for them and not from them, and not touch them for the for the purposes of the Demos today, but as any of you have done, a live demo know they can be all sorts of fun. So

21
00:04:29.720 --> 00:04:51.000
Rachael Lammey: kudos to my my colleagues but our first demo is of our currently under development registration form for for journal content. Lena Stall will share a sneak peak of the work that we've been doing to create a simple user interface to make it easier for members to register good quality journal article metadata.

22
00:04:51.290 --> 00:04:53.520
Rachael Lammey: So over to you, Lena.

23
00:04:55.410 --> 00:05:08.520
Lena Stoll: Thanks very much, Rachel. We're actually starting out quite safe. I'm not doing a live demo. I just have screenshots and slides so everyone can relax for the next 1015 min, and then it gets really exciting when people start doing things live.

24
00:05:08.750 --> 00:05:19.970
Lena Stoll:  yeah. Great to be here today for the many of you who don't know me yet. As Rachel said, my name is Lena. I joined the product team at Cross-ref over the summer

25
00:05:20.050 --> 00:05:25.540
Lena Stoll: I'm based in beautiful gray Berlin, Germany. And

26
00:05:25.630 --> 00:05:40.740
Lena Stoll: I'd like to tell you a little bit today about the work that we've been doing to develop. As Reisha said, a simple user interface or ui to allow members to register journal articles. Without having to touch an Xml file.

27
00:05:41.030 --> 00:06:02.080
Lena Stoll:  I say, we have been doing this work, which is quite generous. For myself, because I've only been here a few months and actually on the product side, most of this is the result of a lot of work by my colleague, Sarah Berman, who many of you might know better. But I've taken on this work because, she recently went on, Maternity leave

28
00:06:02.340 --> 00:06:10.289
Lena Stoll: so just in case you're wondering why there's a new face talking about this and on the tech side shout out to Patrick Vail. I know you're watching.

29
00:06:10.330 --> 00:06:15.079
Lena Stoll: Okay? So anyway, what we're doing there is

30
00:06:15.480 --> 00:06:33.929
Lena Stoll: basically an extension of the concept behind the new grants registration form that we released, I think, towards the end of last year, that some of you might have used before or seen Sarah Demo in the past. So a lot of this might be familiar. If you're

31
00:06:34.030 --> 00:06:35.930
Lena Stoll: if you're familiar with that tool.

32
00:06:36.780 --> 00:06:39.520
Lena Stoll: So if you go to the next slide, please.

33
00:06:41.010 --> 00:06:45.160
Lena Stoll:  yeah, I just want to acknowledge that

34
00:06:45.370 --> 00:06:48.399
Lena Stoll: some people of the audience might be thinking.

35
00:06:48.580 --> 00:06:51.249
Lena Stoll: aren't there already multiple ways of

36
00:06:51.270 --> 00:06:55.869
Lena Stoll: registering records, especially journal articles? And it's

37
00:06:56.170 --> 00:07:02.309
Lena Stoll: 10 points to you if you recognize all of these options I've represented on this slide, and if you can name them all

38
00:07:02.780 --> 00:07:28.800
Lena Stoll: we have our trusty old web deposit form that you can see at the top. Right? We have a metadata manager. We have a plugin for Oj. S. For those that use that platform to manage their journal articles. We have an admin console where you can upload Xml files if you're able to create them. And then, of course, there's the option of depositing Xml in an automated way to our Apis.

39
00:07:28.920 --> 00:07:33.960
Lena Stoll: using Https post, which is represented on the bottom right. and

40
00:07:34.080 --> 00:07:37.849
Lena Stoll: that is, of course, the most kind of

41
00:07:38.700 --> 00:07:45.689
Lena Stoll: reliable, scalable, efficient way of registering metadata. But we do know that

42
00:07:45.760 --> 00:07:58.610
Lena Stoll: today the majority of our members are either institutions or their small publishers, and not everyone runs an Xml first workflow. Not everybody even has the

43
00:07:58.620 --> 00:08:07.489
Lena Stoll: technical resources to or know how to create Xml automated way and deposit it. So we do want to offer.

44
00:08:07.500 --> 00:08:16.980
Lena Stoll: These user interfaces that allow everyone to at least perform all of the most essential tasks that you need to do to be a good cross-ref, citizen.

45
00:08:17.300 --> 00:08:34.760
Lena Stoll:  but the goal isn't and can't really be to represent absolutely everything that you could do with direct calls to our Apis through a user interface. Because with, if you're familiar with our metadata schema, the sheer complexity behind everything that

46
00:08:34.789 --> 00:08:45.040
Lena Stoll: you can in principle register with us, then you'll understand that that's not really realistic to do in a form that people still have a fighting chance of actually using.

47
00:08:45.130 --> 00:08:47.270
Lena Stoll: But that's just an aside

48
00:08:47.800 --> 00:08:53.570
Lena Stoll: getting off my virtual soapbox. I guess the main point of this slide is just to say

49
00:08:54.000 --> 00:09:02.790
Lena Stoll: all of these different routes. All of these different roads ultimately lead to the same database and to the same Api's. So why

50
00:09:02.800 --> 00:09:06.740
Lena Stoll: would we bother creating yet another tool for depositing?

51
00:09:07.310 --> 00:09:09.879
Lena Stoll: And if you go to the next slide.

52
00:09:10.660 --> 00:09:26.790
Lena Stoll:  actually, each one of the tools that we've built so far that work around the requirement to work with a with Xml files directly, all of them serve their own little niche of use cases.

53
00:09:26.940 --> 00:09:41.080
Lena Stoll: and you have to be pretty familiar with the cross-ref tool ecosystem to kind of understand which one is the right one to use, for which purpose and each of our tools also has its own kind of specific limitations.

54
00:09:41.500 --> 00:09:58.969
Lena Stoll: For example, metadata manager is very complex technically, and for that reason it has a number of bugs and issues that we're aware of, that we've never been able to and fully address. The web deposit form is a little bit awkward to use, and it doesn't cover all record types, and so on, and so on.

55
00:09:59.400 --> 00:10:16.909
Lena Stoll: And all of this together kind of leads to a confusing user experience for those members who are trying to deposit their metadata manually, and it's also quite inefficient for us to have to maintain all these different tools in parallel. They're all different code bases.

56
00:10:16.980 --> 00:10:31.770
Lena Stoll:  if we make a change to a metadata schema, for example, we have to then, as a result of that, make multiple changes in multiple places, to to reflect that in all of our tools, and so what we've been building

57
00:10:31.960 --> 00:10:39.900
Lena Stoll: yeah, since. Since we started with the Grant's registration form last year. And now with this general article, registration form is

58
00:10:39.910 --> 00:10:45.829
Lena Stoll: different, because it is being built in and what we call a schema driven way.

59
00:10:46.190 --> 00:10:56.609
Lena Stoll: And by that I just mean that we're we're creating the interface, the form that you actually enter permitted into

60
00:10:56.840 --> 00:10:59.600
Lena Stoll: in an indirect way from

61
00:10:59.760 --> 00:11:10.679
Lena Stoll: the schema itself. So it takes the schema as an input and then creates a form out of it, which means that if there's a change to the schema, it's much, much easier and much faster for us to reflect that in the actual interface

62
00:11:10.810 --> 00:11:22.390
Lena Stoll: and it's also an interesting both of concepts for the wider community to show that it is possible to build your own interfaces in that way that suit your specific needs.

63
00:11:22.630 --> 00:11:29.970
Lena Stoll: Because, as I already said earlier, we will likely never be able to build the ultimate

64
00:11:30.330 --> 00:11:40.610
Lena Stoll: one single tool that is usable that. But that also allows you to do absolutely everything that you could do if you were talking to the Xml Api directly.

65
00:11:41.280 --> 00:11:49.519
Lena Stoll: And so the idea is that if we build a unified set of forms like the grants deposit form and like now the new Journal article form

66
00:11:49.730 --> 00:11:53.370
Lena Stoll: eventually we'll be able to replace

67
00:11:53.420 --> 00:11:57.659
Lena Stoll: some of the tool tools that we know aren't really

68
00:11:57.710 --> 00:12:00.650
Lena Stoll: serving a community in the way that they could.

69
00:12:00.660 --> 00:12:10.590
Lena Stoll: I'm talking specifically now about Metadata Manager, which. if you've used it lately, you've seen a little banner at the top. You'll know that we've been planning to deprecate that for a while now.

70
00:12:10.810 --> 00:12:23.359
Lena Stoll: and if you want to read more about the reasoning behind that decision, and why we're doing what we're doing, then there's a blog post linked on this slide that Sarah wrote a little while ago, called Next Steps for content registration.

71
00:12:23.750 --> 00:12:37.909
Lena Stoll: And we're also building all of our new tools in a way that they are easily, automatically translatable. That's a process called localization. And that they can also be used by users with disabilities.

72
00:12:39.150 --> 00:12:46.370
Lena Stoll: Okay, so that's the preamble. If you go to the next slide. I just wanted to show you a few

73
00:12:46.550 --> 00:12:50.739
Lena Stoll: screenshots. Hope they're not too small in your screens.

74
00:12:51.010 --> 00:13:06.480
Lena Stoll: Just of the current state of the prototype of this film that we've been working on. It's still at a very early stage, as Rachel kind of gave it a little disclaimer at the beginning and a bit of a warning. But I just want to show you. Just give you a little bit of a flavor of what I'm talking about.

75
00:13:07.000 --> 00:13:18.089
Lena Stoll: So if you've used the Grant's registration form in the past, or if you've seen it, then a lot of the kind of design of this interface is going to look quite familiar to you.

76
00:13:18.490 --> 00:13:21.920
Lena Stoll: We're deliberately keeping it very simple. So

77
00:13:22.160 --> 00:13:28.989
Lena Stoll: sorry these screens aren't particularly shiny or telephone but we're focusing on the

78
00:13:29.000 --> 00:13:35.509
Lena Stoll: most important, the most widely used fields in the metadata schema for journal articles and

79
00:13:35.650 --> 00:13:50.769
Lena Stoll:  just again, not every little thing, but the schema in theory allows, for in an Xml file can be represented in a form without making it so complex that it doesn't work for any anyone anymore. But we're focusing on the most important field just to make sure that we can

80
00:13:50.840 --> 00:13:55.370
Lena Stoll: meet the needs, especially of those types of members who we know

81
00:13:55.410 --> 00:14:00.689
Lena Stoll: can't afford to programmatically generate exobil, and who know who need these kinds of tools.

82
00:14:01.170 --> 00:14:13.119
Lena Stoll:  in terms of how the tool is used. We've conceived of it as a kind of wizard that guides you through the sequence of necessary steps. One by one you can see a little stepper at the top.

83
00:14:13.230 --> 00:14:24.190
Lena Stoll: And also anytime that you enter something, or you try to complete the steps. The tool will validate for you whether what you've just entered makes any sense, and whether it fits what's allowed in the schema?

84
00:14:24.550 --> 00:14:35.509
Lena Stoll: That's just because, of course. anytime you make a tool that's used by human beings. There's a capacity for people making typos or copy paste errors.

85
00:14:35.560 --> 00:14:37.259
Lena Stoll: especially with such a

86
00:14:37.900 --> 00:14:53.199
Lena Stoll: total task as registering dozens of journal articles by hand. If you've done it before, I'm sure you've made some copy and paste errors, and it's a lot more costly if you have to correct those after the fact. So it's very important to validate inputs early on, which is what we're doing.

87
00:14:53.490 --> 00:15:07.289
Lena Stoll: You can see an example of this actually, on this screenshot in red. Towards the bottom, because I've entered an invalid dui and also, if you're a very keen observer, you might have seen at the top, right. There is a

88
00:15:07.560 --> 00:15:12.530
Lena Stoll: language switcher button. This is what I mentioned earlier about localization.

89
00:15:12.640 --> 00:15:26.530
Lena Stoll: A really important thing that we want to do with any of the new tools that we're building is to make sure that, especially with those languages that we know a lot of our members are much more comfortable with than English. They can be used in those other languages.

90
00:15:26.920 --> 00:15:31.569
Lena Stoll: and the phone could also be navigated using your keyboard.

91
00:15:31.740 --> 00:15:38.470
Lena Stoll: so we're designing it to be accessible enough that it can be used by anyone in the community who actually need it.

92
00:15:39.180 --> 00:15:51.919
Lena Stoll:  yeah. So if you look at the slipper at the top you can see that the form asks you first for information on the journal, and then it goes down to the issue level, and then finally the article itself that you're registering.

93
00:15:51.980 --> 00:15:56.029
Lena Stoll: and if you go to the next slide you'll see some of the issue screen.

94
00:15:57.070 --> 00:16:04.249
Lena Stoll:  there's not going to be that many surprises there for you in terms of the fields that are represented.

95
00:16:04.410 --> 00:16:16.390
Lena Stoll: You might have noticed already at the top that several titles can be entered both for the journal and for the issue, and then also for the article. That's just because we support multiple languages for titles.

96
00:16:16.680 --> 00:16:21.839
Lena Stoll: Yeah. And like, I said, we're focusing on the key metadata fields and

97
00:16:21.890 --> 00:16:24.600
Lena Stoll: those that are gonna be highest value for

98
00:16:25.210 --> 00:16:33.869
Lena Stoll: making a high quality record and also for the people who use our metadata to have a chance to then discover that content.

99
00:16:34.530 --> 00:16:39.519
Lena Stoll: That's the issue. And then if you go one slide further, you'll see the article level.

100
00:16:40.170 --> 00:16:47.610
Lena Stoll: and you'll be able to see that in this example I've given the article a couple of different titles and different languages.

101
00:16:47.870 --> 00:16:59.170
Lena Stoll: I don't speak so many. So this had to do and there is also a role. Look up already built in if you look closely, you can see for the contributor.

102
00:16:59.550 --> 00:17:07.860
Lena Stoll: you can. If you start entering the affiliation the tool will find

103
00:17:08.020 --> 00:17:20.650
Lena Stoll: the unique identification and the raw database for it. that's something that was quite a crowd pleaser in the grants registration form. And there are

104
00:17:20.890 --> 00:17:23.019
Lena Stoll: more of those kinds of.

105
00:17:23.060 --> 00:17:34.840
Lena Stoll: I guess, quality of life improvements. For using the tool that we know already will definitely need to or want to offer in the form. Once we actually have it, go live for members to use

106
00:17:34.900 --> 00:17:40.690
Lena Stoll:  just right now. Not all of them are there yet, because we've been focusing very much on

107
00:17:40.780 --> 00:17:49.769
Lena Stoll: getting a prototype into a state as quickly as possible that we can share it with all of you and with the wider community and get some feedback.

108
00:17:51.130 --> 00:18:06.210
Lena Stoll: If you go one more slide ahead. We'll go to the fourth step at the end of the whole registration process. If, again, if you know the Grants registration form, you'll you'll know what this looks like. We'll be able to give

109
00:18:06.270 --> 00:18:10.629
Lena Stoll: the user adjacent file download of the record that they have just created.

110
00:18:10.870 --> 00:18:26.670
Lena Stoll: The Xml actually doesn't visibly get involved at any point that's just created in the background by the tool automatically and deposited in much the same way that it would be deposited. If the user directly used our Xml Api.

111
00:18:26.800 --> 00:18:29.730
Lena Stoll:  the

112
00:18:30.580 --> 00:18:40.970
Lena Stoll: this Json file. So that's one another. One of the things that I said, we know will will want to do. Because it makes a big difference in how useful the tool is. Is that

113
00:18:41.080 --> 00:18:57.720
Lena Stoll: we will allow for users to be able to load those Json files back into the form later and then make changes, which is something that is already the case on the Grant registration form. Just for this very first prototype. We're focusing just on the initial registration part so that we can test that

114
00:18:57.780 --> 00:18:59.240
Lena Stoll: with the community.

115
00:18:59.290 --> 00:19:08.310
Lena Stoll: But we know that editing records after the fact. Especially for general articles, is something that people use metadata manager for a lot.

116
00:19:08.920 --> 00:19:11.629
Lena Stoll: Yeah. So that's just a note on that

117
00:19:12.050 --> 00:19:15.199
Lena Stoll: and actually on that topic, if you go to the

118
00:19:16.130 --> 00:19:19.529
Lena Stoll: next slide. Oh, some people having issues, not seeing slides.

119
00:19:20.480 --> 00:19:34.550
Lena Stoll: I'm just gonna pretend I didn't read that and keep talking if it's working for most. Yeah. Okay. So since I've already used the word soon.

120
00:19:35.100 --> 00:19:48.549
Lena Stoll: obviously, next, questions are, what's coming next. What are the kind of timelines like? I said at the beginning. We went. quite ready and confident enough to

121
00:19:48.700 --> 00:20:01.819
Lena Stoll: To do this live yet and grow into the actual prototype and enter things, and show you how it reacts. So I took the safe route out of taking screenshots. Sorry about that

122
00:20:01.820 --> 00:20:20.289
Lena Stoll: and we can't quite share a link to the prototype yet, either, for you to play around with your sales for the same reason. But like I said, the goal is to get there as quickly as possible. So we're just putting some finishing touches on it. And it's again a very early version, so don't expect to see it in production tomorrow just yet.

123
00:20:20.560 --> 00:20:23.020
Lena Stoll: But of course we'll keep

124
00:20:23.260 --> 00:20:29.259
Lena Stoll: our community updated as we make more progress. We're going to be iterating over the coming

125
00:20:29.270 --> 00:20:31.579
Lena Stoll: weeks and months on

126
00:20:31.690 --> 00:20:37.980
Lena Stoll: early initial feedback that we're going to be getting both internally and then from

127
00:20:38.020 --> 00:20:43.259
Lena Stoll: from some key members of our community. So I just actually, I should say thanks at this point to

128
00:20:43.620 --> 00:20:57.769
Lena Stoll: those of you who are cross-ref ambassadors who have already volunteered to to help us test the prototype will be getting in touch with you very soon. There are also some people who volunteered on the community forum already in the past to be involved in this process, which is great.

129
00:20:57.910 --> 00:21:07.650
Lena Stoll:  and then in terms of some future next steps again, if you've used metadata manager

130
00:21:07.670 --> 00:21:15.380
Lena Stoll: recently or not even not so recently, you will have seen that in the Yellow Banner, and the tuss is going to be deprecated. It still says 2023.

131
00:21:15.500 --> 00:21:17.199
Lena Stoll: Right now is the date of

132
00:21:17.210 --> 00:21:24.610
Lena Stoll: sun setting it. But we don't want to rush this while. It's still needed. Because what we're building

133
00:21:24.790 --> 00:21:32.189
Lena Stoll: out as a minimum viable version of this new tool, that's what the Mvp on the slide means minimum viable product for those

134
00:21:32.450 --> 00:21:46.729
Lena Stoll: who aren't so deep in the tech robot hole. Yeah, it's we we don't wanna rush this on. I've put 2024 in here, cause that's probably more realistic. But the idea is that

135
00:21:47.070 --> 00:21:49.330
Lena Stoll: once we've got

136
00:21:49.400 --> 00:22:02.669
Lena Stoll: once we've a bit more formally reached out for community feedback, like we always do with such an important project. And we've iterated on that. And we're getting confident that we have a viable version of this tool.

137
00:22:02.890 --> 00:22:05.800
Lena Stoll: we will be able to put the

138
00:22:05.910 --> 00:22:16.129
Lena Stoll: ghost of metadata manager, I guess. Bit of a Halloween theme here for you. To rest finally and and look to the future.

139
00:22:16.490 --> 00:22:20.100
Lena Stoll: So yeah, if you are

140
00:22:20.370 --> 00:22:39.180
Lena Stoll: one of those people who really resonate with with what I've been talking about and who maybe currently uses metadata manager, or even the web deposit form to register your journal articles, and you want to help us shape this new thing. Then absolutely feel free to get in touch with me. I think the next slide will tell you how to do that.

141
00:22:39.960 --> 00:22:48.229
Lena Stoll: Or not. Okay. That was supposed to be a Thank you. Slide with my email address on it. But I'll make sure to

142
00:22:48.490 --> 00:23:01.490
Lena Stoll: to add that after the fact, I guess. Sorry about that as well. Yeah, it's it's also pretty easy to get

143
00:23:01.700 --> 00:23:17.990
Lena Stoll: But yeah, but I also wanted to say that the the community forum is always also a great place to be if you want to stay up to date with what everyone is doing at crossroads. One of the first places that you'll find out when there's news or something to test or give input on. So

144
00:23:18.600 --> 00:23:29.979
Lena Stoll: shadow for the community Forum. And I'll put my email address in the chat. Look forward to speaking to some of you about this, some more, and for now I think that's it for me.

145
00:23:30.430 --> 00:23:34.110
Lena Stoll:  oh, thanks, Jenny. Okay, there it is already.

146
00:23:35.160 --> 00:23:40.540
Lena Stoll: Thanks to you, Rachel, I guess, Leila, there's a question for you in the Q. And A.

147
00:23:41.660 --> 00:23:46.060
Lena Stoll:  Yes, okay. We have

148
00:23:46.370 --> 00:23:57.589
Lena Stoll: a question that says. given the driving cross for get publishers to register reference lists, will there be an option to upload reference lists, either in their entirety for passing, or as a list of duis only.

149
00:23:57.750 --> 00:24:09.719
Lena Stoll: That's a very good question. Of course we know that references are a very, very important metadata type, and also one that we've been kind of

150
00:24:09.980 --> 00:24:32.439
Lena Stoll: pushing our members when we discuss their participation reports with them. All that kind of thing to to really consider investing in. So we know that we want to be representing that in this, in this tool, in some way, we haven't really made the definitive decision yet on what the best way of doing those if there will be

151
00:24:32.840 --> 00:24:51.479
Lena Stoll: some way to use our simple text query that we tool that we have to to get Dois for references if you don't have them yet, or if it's better to do them the other way around. I don't think that I would. I have a definitive answer on this yet. But that's exactly why we

152
00:24:51.600 --> 00:25:11.900
Lena Stoll: I'll trying to get this out for community testing and feedback as quickly as possible, so that we can nail these sorts of things down. But that's the kind of thing that we don't wanna make a decision on to early on before we know what's actually most valuable. So if you think you have input on that, then get in touch with me for sure.

153
00:25:13.330 --> 00:25:21.099
Rachael Lammey:  And I think we let's I can see there are other questions, but I want to

154
00:25:21.530 --> 00:25:28.870
Rachael Lammey: and I think some advice as well. I want to keep us moving and jump on to the next presentation, just so that we don't run over time.

155
00:25:29.350 --> 00:25:35.769
Rachael Lammey: But we can answer those in the QA. As well, and come back to them. If we've got time at the end, I would suggest, is that right?

156
00:25:35.910 --> 00:25:39.489
Lena Stoll: Perfect? Thanks. Yeah. It's not ready a question, anyway. I think so. I'll just respond.

157
00:25:39.680 --> 00:25:40.490
Rachael Lammey: cool.

158
00:25:40.920 --> 00:25:54.659
Rachael Lammey: Thank you. Okay. So next up we have Eric Hanson from the Public Knowledge project. Or Pkp, who's gonna demonstrate the latest crossref Plugin.

159
00:25:54.680 --> 00:26:20.480
Rachael Lammey: in Ojs 3.4 the Doi work flow has been completely rewritten addressing usability and issues and providing a better overall user experience. So with so many of our members using Ojs extensively, and these improvements are really timely and thanks to the team for sharing them with us and giving us the the opportunity towards the end of last year to test them out. Eric, can we hand over to you.

160
00:26:21.780 --> 00:26:24.429
Erik Hanson: Yeah, thank you. I'll start

161
00:26:25.540 --> 00:26:28.030
Erik Hanson: by sharing my screen if I can.

162
00:26:36.170 --> 00:26:38.980
Erik Hanson: Does not look like I am able to share my screen.

163
00:26:50.970 --> 00:26:52.980
Rachael Lammey: Would you like to have another go?

164
00:26:57.030 --> 00:26:58.030
Erik Hanson: Yes.

165
00:27:00.200 --> 00:27:02.830
Erik Hanson: oh, no, and

166
00:27:03.040 --> 00:27:05.900
Erik Hanson: perhaps fairly typical. Zoom.

167
00:27:06.780 --> 00:27:14.969
Erik Hanson: a live demo of contact slide recently reset my computer. And I unfortunately do have to briefly log off of zoom and restart zoom. I'm terribly sorry about this.

168
00:27:15.260 --> 00:27:32.520
Rachael Lammey: Do you want to? What we can do is we can. We can tweak the order a little bit if you wanna leave, and then we join. I think a couple of us have been hit with zoom updates this morning, which is, of course, another another variable, and all of this. So we'll keep a lookout for you. Add you back in

169
00:27:32.760 --> 00:27:38.879
Rachael Lammey: and and I think that will work. Martin Richman, if you're happy to go next.

170
00:27:39.240 --> 00:27:46.160
Martyn Rittman: Yeah, no problem. I can jump in. So yeah, let me share my screen and hope that hope that all the

171
00:27:47.260 --> 00:27:48.200
Martyn Rittman: it's work.

172
00:27:48.420 --> 00:27:51.559
Martyn Rittman:  yeah. So yeah, this is

173
00:27:51.680 --> 00:28:13.819
Martyn Rittman: awesome. Good. So yeah, this is a presentation about a new Api endpoint that we that we have and I'm gonna demonstrate it via a Jupyter notebook. I realize this is in python, and some of you might be might be not familiar with python. Don't worry. I will explain and point out the the most relevant bits as we

174
00:28:13.820 --> 00:28:25.330
Martyn Rittman: as we go through. But basically, this is looking at different ways that we can, that we can look at cross-ref metadata. So I'm going to talk about relationships. Firstly, how you

175
00:28:25.640 --> 00:28:43.160
Martyn Rittman: can get hold of relationships, and where, how we will combine those into one endpoint in the future. So if you are familiar with python. All I'm doing here is using the requests library to query, Apis, here's the endpoints. If you'd like to try this out.

176
00:28:43.160 --> 00:29:12.190
Martyn Rittman: then then you can go to to this this URL, which which has the the endpoints, and I'll give you a few more pointers at at the end for that I've also I'm not running this off a Co. Lab notebook, but I have a Co Lab notebook, and I'll share the link for that. At the end. As as well. So yeah, we're just gonna start the the notebook with a few useful functions which are to show you the URL, that we're querying. See that in a moment. And then this is this is the function that does the the work.

177
00:29:12.190 --> 00:29:24.860
Martyn Rittman: And it it it. Queries some URL, and it expects a Json output. So this is Json is the the format of the data that that gets returned from our Apis.

178
00:29:25.640 --> 00:29:55.390
Martyn Rittman: So as we're we're talking about just now very timely. References are very important, and many of our members send us references. And what we can. What we, what we do at Crossref is display those through a works endpoint. So each item has an entry. And you can query the works endpoint. Using this URL. So you know, Api dot crosswift org slash works. And then we have in there this

179
00:29:55.420 --> 00:30:01.139
Martyn Rittman: filter which say, it says, does this item have references or not. Just give me the ones with references.

180
00:30:01.270 --> 00:30:20.660
Martyn Rittman: And just to give you examples, we have, you know, 8 references for this, do I? 80, 90 for this? I don't know what this this is. Maybe it's a book or something, but 424 references. II feel sorry for the the poor production people who who have to go through all of those. What do these actually look like in in Json?

181
00:30:20.860 --> 00:30:31.529
Martyn Rittman: well, this is the this is the Json list of references. I just pulled out the the reference part of of the of the response.

182
00:30:31.530 --> 00:30:51.389
Martyn Rittman: And we can see that this do I? Here is citing a number of of things, and this is this is one of them that I'm highlighting here. It has a doi. It also has the title, The authors and we've got this unstructured references as as well. You don't have to pass references to put them into our

183
00:30:51.600 --> 00:31:05.889
Martyn Rittman: To to deposit them with with us. You can have just unstructured text like here. You don't even need a doi. We will try and match that for you. So you can see. Just kind of, you know, more examples with similar kind of information.

184
00:31:06.010 --> 00:31:07.780
Martyn Rittman: So that's that's references.

185
00:31:07.940 --> 00:31:16.419
Martyn Rittman: There's another way that you can add links between outputs in in slightly more descriptive ways.

186
00:31:16.910 --> 00:31:19.500
Martyn Rittman: And that's using the relationships.

187
00:31:19.660 --> 00:31:22.749
Martyn Rittman: Part of our schema. And

188
00:31:22.940 --> 00:31:31.730
Martyn Rittman: again, I'm going to query, the works endpoint? Gonna query the same endpoint. But instead of saying, has references, we says, has has relations?

189
00:31:31.750 --> 00:31:42.699
Martyn Rittman: Does does it have a relationship? And that's that's run nice and quickly, thankfully, this is always always risky doing a live demo. But anyway, here's just one example, and we have

190
00:31:42.780 --> 00:31:51.589
Martyn Rittman: here we have the type of relationship. That we just pulled the relationship part out of the the Json response.

191
00:31:51.760 --> 00:32:03.409
Martyn Rittman: And then it says it says what the relationship is to as well. And this is just an an identifier says it's a doi. You can add other types of identifier in there as well.

192
00:32:03.440 --> 00:32:08.830
Martyn Rittman: And we say who it's asserted by so subject means that it's asserted, asserted by

193
00:32:08.860 --> 00:32:19.920
Martyn Rittman: the the the member that deposited this metadata. If it said object, then it would have been asserted by the member who deposited the metadata for the related item.

194
00:32:20.330 --> 00:32:43.509
Martyn Rittman: So it's you know, there's 2 sides to a relationship, and one. This happens in life as well. But you know, 1 one person says one thing, one person says another thing. And as you know, they don't always agree. Here's just a few more examples. So we have reviews. We have comments, then these are mostly reviews. This is one with, an article with a preprint

195
00:32:44.100 --> 00:33:11.339
Martyn Rittman: and we can see that, you know. Some of these were asserted by the the member who deposited the the object, the the metadata, some of them were asserted by for example, this one was asserted by the the member who deposited the comment and said, it comments on on this, and we match up in our as has already been mentioned, we we match up the reverse relationship here. So that's kind of nice. But you might notice that this output looks very different from what we saw before, with the references different kind of

196
00:33:11.360 --> 00:33:13.160
Martyn Rittman: of metadata available.

197
00:33:14.220 --> 00:33:19.410
Martyn Rittman: So I mentioned briefly that you can link to things outside of Crossref.

198
00:33:19.760 --> 00:33:25.670
Martyn Rittman: We have a project called Event Data, which, where we go and look for relationships.

199
00:33:25.960 --> 00:33:38.650
Martyn Rittman: From crossraf duis that are kind of, you know, mentioned around the web. So, for example, on Wikipedia hypothesis, annotations, we look on on Reddit, and just kind of blogs and websites

200
00:33:38.930 --> 00:33:40.170
Martyn Rittman: and

201
00:33:40.620 --> 00:33:56.780
Martyn Rittman: I'll just show you one example here. We're looking at specifically at Wikipedia. And now the the Eagle light among you might notice that. The event. Data. Api is being closed down from the end of next month.

202
00:33:56.980 --> 00:34:12.050
Martyn Rittman: This is because we will continue to collect events. But we want to be able to. We want to focus on the new endpoint, the relationships endpoint as you'll which you'll see in in a moment. And the best use of our resources is to

203
00:34:12.440 --> 00:34:25.469
Martyn Rittman: stop is is to stop with event data, put all of event data into the relationships, endpoint and make that usable for for the users that that are doing that. So if you are using event data,

204
00:34:25.530 --> 00:34:28.100
Martyn Rittman: you'll want to look at the

205
00:34:28.389 --> 00:34:33.700
Martyn Rittman: at the relationships endpoint as as you ever in the next few weeks.

206
00:34:34.520 --> 00:34:42.329
Martyn Rittman: So this is an example of an event, and you'll see again. It looks very different to the references. It looks different to the relationship metadata that we saw.

207
00:34:42.420 --> 00:34:50.069
Martyn Rittman: But essentially, we've got the same kind of information. So we've got an identifier for the subject. In this case, it's a yeah. URL Wikipedia page.

208
00:34:50.389 --> 00:34:55.079
Martyn Rittman: We have an identifier for the object, which is a crossref. DO.

209
00:34:55.250 --> 00:35:08.310
Martyn Rittman: And we say how these 2 things are linked together. And and this is as as as a reference. So you've seen here. There's 3 different ways that we essentially deliver the same metadata

210
00:35:08.730 --> 00:35:27.140
Martyn Rittman: and you know we've been looking a great deal in the, you know, in the past few few months and years at the research nexus and that doesn't really preference any kind of item or any kind of relationship. And so we said, Well, why don't we reflect that in our Apis

211
00:35:27.140 --> 00:35:39.179
Martyn Rittman: and provide all of the relationships that we know about through a single endpoint and in the same format. And this is what we've been been building for a while now.

212
00:35:39.280 --> 00:35:59.410
Martyn Rittman:  And, as I said at the at the beginning, this is the this is the URL, and I'm just looking for, you know, a single day. So we've got. We've got a number of of filters time filters, for example, on the on the output. And you see, on this day there were about 2.4 million relationships found.

213
00:35:59.460 --> 00:36:03.480
Martyn Rittman: I'm not going to show you all of those. But this is just one of them. And

214
00:36:03.560 --> 00:36:17.879
Martyn Rittman: again, we've we've tried to pair it down to the the minimum kind of useful information. And we'd love feedback as to whether this is sufficient, whether we need more, whether we need less and what would make this useful for for you to use.

215
00:36:18.270 --> 00:36:25.900
Martyn Rittman: And so we have a subject. So this relationship comes from across F doi, and in this case

216
00:36:26.140 --> 00:36:29.140
Martyn Rittman: is going to an organization.

217
00:36:29.380 --> 00:36:45.909
Martyn Rittman: So this, I can tell you, because I've I've looked at this way too often, is is wily, and it says that this doi was published by Wiley, essentially and this information was asserted, instead of just saying subject or object, or or a word, we're using a raw identifier for crossref.

218
00:36:45.930 --> 00:36:54.420
Martyn Rittman: So basically, crossref is asserting that Wiley is is permitted to to manage the metadata record of of this doi

219
00:36:55.800 --> 00:37:08.789
Martyn Rittman:  So in the first instance, we are focusing on data citations which have been mentioned quite a number of times already. So I'm I'm really happy to to have heard that it kind of

220
00:37:08.890 --> 00:37:14.949
Martyn Rittman: hopefully, I don't need to give too much motivation for why data citations are interesting and and important.

221
00:37:15.030 --> 00:37:25.650
Martyn Rittman: And again, we're going to query the relationships endpoint. We're going to look for things that have the type data set. And we're just going to look for a single day and see what the

222
00:37:25.760 --> 00:37:26.950
Martyn Rittman: what we find.

223
00:37:28.370 --> 00:37:35.159
Martyn Rittman: And we find. Actually, there were a hundred and 147 data citations, or

224
00:37:35.250 --> 00:37:40.039
Martyn Rittman: found on this day. Now, this. What this means is

225
00:37:40.240 --> 00:38:05.510
Martyn Rittman: the subject type data set. This is with a capital D is, the is is used by data site. So these are actually not data citations deposited by crosswf members. These are data citations being deposited by data site members. They very kindly pass that information on to us, and we're able to make it available through the through our endpoints. And you know we do that reciprocally as well.

226
00:38:05.570 --> 00:38:09.110
Martyn Rittman: And let's just have a look at the, at the output there. So we can see.

227
00:38:09.610 --> 00:38:14.500
Martyn Rittman: You know, there's various relationship types which are used. So you know this.

228
00:38:14.600 --> 00:38:22.340
Martyn Rittman: this? This, this doi here. So this one here is is metadata for this crossref. Doi

229
00:38:22.350 --> 00:38:28.449
Martyn Rittman: this data site doi is posted content, which is

230
00:38:29.510 --> 00:38:35.170
Martyn Rittman: So yes, this. This is across Fdi, which is posted content. And

231
00:38:35.510 --> 00:38:42.920
Martyn Rittman: it's cited by this this data site Doi, which is in Zenodo, and and so on, and and so forth.

232
00:38:43.280 --> 00:39:02.809
Martyn Rittman: So of course I mean II don't know whether doing a live presentation on this make makes sense. But you know, the idea is that this is machine readable. And if you want to look up more information about a doi, you can just go to our works, endpoint and and retrieve the the metadata for that. This is really focused on the, on the relationships.

233
00:39:03.430 --> 00:39:09.009
Martyn Rittman: It's like I should have short on the output for this one, anyway.

234
00:39:09.750 --> 00:39:22.339
Martyn Rittman: you can. This is. This is why I'm not convinced is going to work, because this query has been taking rather a long time. At the moment. But you can query for everything which has been registered by data site.

235
00:39:23.260 --> 00:39:36.720
Martyn Rittman:  and the the output I've I've done. I've done a short kind of put the output here, but you know this is this is the output that you will see. There's just to to show you. You know, more kinds of queries that you can make

236
00:39:37.560 --> 00:39:42.380
Martyn Rittman: and so I'm not quite sure how I'm doing for time here. But

237
00:39:42.660 --> 00:39:47.080
Martyn Rittman: yeah, we can. We can let people get to the end. What else?

238
00:39:47.500 --> 00:39:58.900
Rachael Lammey:  in the. But yeah, just a about a minute left be great. Okay? Fine. Yeah, so just very, very quickly. Then you can. You don't have to look at a doi. You can look at orchids.

239
00:39:58.950 --> 00:40:05.210
Martyn Rittman: You can look at organizations you could. There's funding metadata in here.

240
00:40:05.240 --> 00:40:11.170
Martyn Rittman: So yeah, this is, says the orchid was an author of of that. This

241
00:40:11.240 --> 00:40:15.699
Martyn Rittman: we can see, that cargo has has deposited 50,000

242
00:40:15.910 --> 00:40:31.910
Martyn Rittman: references, and you know we've got funding information in here as well. Sorry to kind of blast through that very quickly, but I will put this I will put this colab notebook link into the the chat, and you can have a look and have a look by yourself.

243
00:40:33.480 --> 00:40:36.329
Martyn Rittman: Yeah, thanks. Thanks a lot for for your attention.

244
00:40:38.050 --> 00:40:45.090
Rachael Lammey: Awesome. Thank you very much. That was really interesting.

245
00:40:45.740 --> 00:40:53.449
Rachael Lammey: there's the link to the notebook for anyone to have a look at. I am really conscious of time. Maybe one question

246
00:40:53.770 --> 00:40:58.920
Luis Montilla: Luis, you want to take, and then we can get to the other ones in the chat. Sure, alright, perfect.

247
00:41:00.260 --> 00:41:03.530
Luis Montilla: There is one question. Maybe you can answer very quickly.

248
00:41:04.060 --> 00:41:21.299
Martyn Rittman: yeah, so yeah, is event data going to be available in relationships. Api, from day one. The answer is, actually, probably not. There will be a a gap we have committed to making all of event data available by the end of January 2024.

249
00:41:21.420 --> 00:41:30.709
Martyn Rittman: but we we, you know, event data for those of you who've been using it has been unstable for quite some time, and we've decided that it's better to focus on something new

250
00:41:30.770 --> 00:41:43.379
Martyn Rittman: and stable, and there may be a a gap in which some events are not available. We've really focused on data citation because we know that that's a very important use case. And all of data site,

251
00:41:43.590 --> 00:41:51.650
Martyn Rittman: all all of the data citations that we know about will be available. From day one. The rest we will add. Gradually over over time.

252
00:41:55.650 --> 00:42:05.139
Rachael Lammey: That's great. Thank you? No, said you can. There's a few other questions in the chat that you can pick up. Thank you, Eric. Should we try again?

253
00:42:06.180 --> 00:42:10.459
Erik Hanson: Yes, fingers crossed. Thank you so much for moving things around for no worries.

254
00:42:18.310 --> 00:42:19.939
Rachael Lammey: Yep, we can see your screen

255
00:42:20.550 --> 00:42:33.060
Erik Hanson: perfect. Okay. So, jumping back to a few minutes ago. But those of you who are unfamiliar with open journal systems or Ojs, that I'd give just a brief

256
00:42:33.170 --> 00:42:39.079
Erik Hanson:  overview of what it is. It's an open source journal management and publishing platform.

257
00:42:39.090 --> 00:42:45.420
Erik Hanson: It encompasses a submission workflow, peer review as well as the production workflow.

258
00:42:45.910 --> 00:43:09.379
Erik Hanson: And it's currently in use by more than 30,000 journals worldwide and today I'd like to share with you a little bit about the new doi work flow in the latest release. 3.4, which came out in June ninth. But in order to provide a little bit of context around that, I'd first like to show you a little bit from the previous version 3.3

259
00:43:09.380 --> 00:43:18.820
Erik Hanson: set up. Why these changes are so big and helpful, especially for people who are managing lots and lots of dois.

260
00:43:19.410 --> 00:43:30.280
Erik Hanson: So for those of you who are unfamiliar with Ojs. This is the home screen view for. And then editor would log in. I just want to show an example of

261
00:43:32.640 --> 00:43:49.529
Erik Hanson: what's some of the pain points are when dealing with the Dois in the previous version. So to start with, one of the major ones are around doi creation. It's spread out throughout many different places throughout the application. So, for example, if we were to pull up

262
00:43:50.740 --> 00:44:00.010
Erik Hanson: this published article, currently I only have a article, do you enabled? But I'll show an example of where all of those would go. So

263
00:44:00.540 --> 00:44:04.100
Erik Hanson: this is the kind of publication tab for

264
00:44:04.110 --> 00:44:09.590
Erik Hanson: a published submission. The article Dui would be under here

265
00:44:09.890 --> 00:44:19.189
Erik Hanson: under the identifiers tab. If you have a galley, dui, it would be separately under here, and the issues would be yet under a different tab entirely.

266
00:44:19.630 --> 00:44:35.280
Erik Hanson:  Another pain point that this brings about is, you can see from this big red Banner. This version has been published and cannot be edited, and this often happens that an article will be published. This is especially prominent in with preprints

267
00:44:35.290 --> 00:44:38.869
Erik Hanson: before a Dui has necessarily been assigned to it.

268
00:44:39.050 --> 00:44:48.569
Erik Hanson: and this has previously been impossible in Ojs. And encourages bad practices around things like unpublishing it to update the metadata, then republicing it.

269
00:44:51.640 --> 00:44:55.150
Erik Hanson: Highlight. One other pain point here

270
00:44:55.740 --> 00:45:07.219
Erik Hanson: is around the previous and doi pattern, and this is what we call the default. Doi suffix generation in Ojs. 3.3 and previous.

271
00:45:07.350 --> 00:45:15.320
Erik Hanson: If you come to assign the Doi, you'll see this warning, which says, you cannot generate a doi until this publication has been assigned to an issue

272
00:45:16.520 --> 00:45:22.620
Erik Hanson: to just quickly show at a glance what that entails. Going to the Dui settings for this version.

273
00:45:26.580 --> 00:45:43.690
Erik Hanson: and in Ojs. 3.3 and earlier, we use a pattern-based suffix generation which does contain semantic information about the item in question. The most common one is for articles, and it includes information about the issue.

274
00:45:43.810 --> 00:45:57.070
Erik Hanson: The volume number Ids inherent to it from Ojs itself, and this is often very problematic, because the Doi cannot be assigned to an item until it has been assigned to an issue. And this is

275
00:45:57.110 --> 00:46:13.630
Erik Hanson: often very problematic, because maybe an item shouldn't be assigned to an issue yet. But you would like to have a dui right. You shuffled around, and you want to be able to assign it, doi. It's part of the pre-production, so it's a little bit of background on some of the kind of pain points of Doi

276
00:46:14.080 --> 00:46:15.510
Erik Hanson: generation

277
00:46:18.460 --> 00:46:20.179
Erik Hanson: which brings us to

278
00:46:21.380 --> 00:46:26.659
Erik Hanson: OJS. 3.4 and the same view here just as a starting point.

279
00:46:28.560 --> 00:46:29.850
Erik Hanson: So

280
00:46:30.100 --> 00:46:38.449
Erik Hanson: I'll do a quick walkthrough of the process of setting things up as well as show some of the highlights of the new workflow.

281
00:46:38.480 --> 00:46:57.790
Erik Hanson: So first of all, you'll notice Duis are featured very prominently on the sidebar here. So one of the major changes is that Dois are now a core part of the application. Previously they were a separate plugin, which kind of limited the amount of integration, deep integration into the application that was possible.

282
00:46:58.070 --> 00:47:13.960
Erik Hanson: and the Crossraf Plugin and any of the other registration agency plugins are still plugins, but this new architecture allows them to be more deeply integrated into the application. And I hope, as they go through some of that today, you'll be able to see some of that

283
00:47:14.410 --> 00:47:15.970
Erik Hanson: to start with.

284
00:47:16.330 --> 00:47:25.739
Erik Hanson: Show you what some of the settings look like. Just to provide some context. duis can be enabled or disabled as part of the distribution workflow

285
00:47:25.880 --> 00:47:27.300
Erik Hanson: globally here.

286
00:47:28.650 --> 00:47:41.060
Erik Hanson:  next up. It's very similar to previous versions items with the Dois. Currently, I only have articles selected. This also varies across the different

287
00:47:41.260 --> 00:47:48.030
Erik Hanson: software applications that Pkp makes for one for monographs and one for preprints. But it's roughly the same idea.

288
00:47:48.100 --> 00:47:56.610
Erik Hanson: One new thing here in particular is that by default. Anything that O. Js can create a dui for is possible here

289
00:47:56.990 --> 00:47:59.439
Erik Hanson: of note is the article, galleys

290
00:47:59.490 --> 00:48:08.370
Erik Hanson: and this is usually in the most default context that publish Pdf cross-ref for the cross-ref Plugin. This option is disabled.

291
00:48:08.750 --> 00:48:16.180
Erik Hanson: and this can be configured for other registration agencies. If, say they didn't take issue Duis, for instance, and

292
00:48:16.870 --> 00:48:26.449
Erik Hanson: potentially more applicable, is for monographs, if different services do or do not take Chapter duis, or that don't have the capability to distinguish between those types of things.

293
00:48:26.620 --> 00:48:28.570
Erik Hanson: and I'll show what that looks like here.

294
00:48:29.860 --> 00:48:36.180
Erik Hanson:  next big thing is the automatic dui assignment.

295
00:48:36.780 --> 00:48:47.809
Erik Hanson: the philosophy around this was just to be able to generate Duis as early as possible so that they're there as part of the production process part of the layout process.

296
00:48:47.850 --> 00:48:53.890
Erik Hanson: It's gonna be done on reaching the copy editing stage, which essentially means as early as possible

297
00:48:54.110 --> 00:49:04.090
Erik Hanson: on publication or never, in other words, manually and when we looked at the pain point from Oj.

298
00:49:05.090 --> 00:49:06.719
Erik Hanson: What that

299
00:49:08.580 --> 00:49:13.449
Erik Hanson: kind of has bearing on for this is that you needed to have assigned things to an issue

300
00:49:13.530 --> 00:49:19.729
Erik Hanson: that is no longer the case. The default suffix generation now creates

301
00:49:19.870 --> 00:49:29.309
Erik Hanson: a unique 8 character suffix. And this is a pattern we took from inspiration, from a data site tool

302
00:49:29.620 --> 00:49:41.349
Erik Hanson: that would create an 8 character suffix, and it includes a checksum digit so it can be checked programmatically to make sure there are no typos in a similar way to iss ends or Isbn's

303
00:49:41.580 --> 00:49:54.379
Erik Hanson: so one of the other big wins is because it's a unique character suffix. It does not contain any semantic information, and there is no temptation for editors or journal managers to want to use

304
00:49:54.680 --> 00:50:06.389
Erik Hanson: the duis to convey any sort of semantic information that they might want to change later. For instance, if the name of the journal changes, they won't want to change their dui subjects because it doesn't have any information about that, to begin with.

305
00:50:07.570 --> 00:50:24.320
Erik Hanson: next bit is all information about the registration agencies has also been co-located here. So the name of the game with a lot of these changes is co-location. So, wanting all the settings to be co-located as well as the actual doi management itself.

306
00:50:24.610 --> 00:50:26.280
Erik Hanson: So we go here.

307
00:50:27.550 --> 00:50:37.620
Erik Hanson: We can check which registration agency. We'd like to rich registration agency Plugin we'd like to work with right now. I have crosswift setup.

308
00:50:37.690 --> 00:50:44.540
Erik Hanson: Let's see Crossword Demo, and that makes the most sense. But all of these settings are co-located here.

309
00:50:44.660 --> 00:50:57.490
Erik Hanson: Automatic deposit is still functional. and all of the settings are here, along with some added context about the username and the roles for setting those up.

310
00:50:58.260 --> 00:51:00.239
Erik Hanson: Go ahead and enable that.

311
00:51:01.150 --> 00:51:15.850
Erik Hanson: and then move on to the new doi manager interface. So this interface here will be more or less the same, regardless of which registration agency is used. If a registration agency Plugin is enabled at all.

312
00:51:15.960 --> 00:51:21.760
Erik Hanson: and this will be the same across all the applications. So this was really done in an effort to

313
00:51:22.010 --> 00:51:27.480
Erik Hanson: unify the way that journal managers and editors can work with duis.

314
00:51:27.800 --> 00:51:32.560
Erik Hanson: So a few things I'd like to highlight around this

315
00:51:33.320 --> 00:51:42.070
Erik Hanson: are the basics of doi assignment as well as some of the quality of life things. So some of the first things that jump out are the

316
00:51:42.150 --> 00:51:45.320
Erik Hanson: red badges here? These will usually

317
00:51:45.420 --> 00:51:55.460
Erik Hanson: show the top priority things that a journal manager would want to see when they come to the screen, and this includes things like whether items still need to be assigned as Dois

318
00:51:55.600 --> 00:52:05.249
Erik Hanson: once items have been published, whether they are are unregistered as well as if there are any errors in the registration process.

319
00:52:05.360 --> 00:52:07.730
Erik Hanson: so we can filter things based on

320
00:52:07.770 --> 00:52:12.890
Erik Hanson: these types of things. So you want to see all of the items that need duis

321
00:52:15.720 --> 00:52:19.120
Erik Hanson: that includes everything, because nothing has doi assigned. At this time.

322
00:52:20.460 --> 00:52:23.530
Erik Hanson: There is an explanation for what all of these

323
00:52:23.780 --> 00:52:33.899
Erik Hanson: individual statuses mean as well as the filters. that can be updated or that can be viewed. If you are looking here at a later time.

324
00:52:34.160 --> 00:52:36.650
Erik Hanson: also impossible to filter by

325
00:52:36.880 --> 00:52:41.860
Erik Hanson: issues. And if you're using an issue-based workflow can manage everything

326
00:52:41.930 --> 00:52:42.980
Erik Hanson: there.

327
00:52:43.760 --> 00:52:55.859
Erik Hanson: One of the other big improvements in terms of the workflow for time. I didn't show an example of this in the Pain Point section in 3.3, but the ability to do bulk actions so

328
00:52:56.230 --> 00:53:11.849
Erik Hanson: to paint a picture of it. Imagine you had 300 items that you needed to assign Dois, or reassign or re-register. Previously you had to tick all of these manually, and this was just a quirk of the design of the forms.

329
00:53:12.000 --> 00:53:19.200
Erik Hanson: We now have bulk actions, and this is where the heart of a lot of the functionality is we filtered for the issue we want.

330
00:53:19.260 --> 00:53:23.299
Erik Hanson: We select it all. And now we'd like to assign some duis to these.

331
00:53:26.380 --> 00:53:30.810
Erik Hanson: and we can now see that the status of these move from needs do I to unregistered

332
00:53:32.500 --> 00:53:43.690
Erik Hanson: Dois can be edited under this expanded view. If you have more than one dui for an item. You are using galley duis, or if you're working with monographs and have more

333
00:53:43.940 --> 00:53:48.139
Erik Hanson: types of items that have duis, those can all be managed here.

334
00:53:48.620 --> 00:54:00.510
Erik Hanson: It can be edited here as well. and once you're ready it can be deposited. So I'd also like to just take a moment to highlight this as the

335
00:54:00.760 --> 00:54:10.189
Erik Hanson: new type of suffix. It is still more or less human, readable. We tried to strike a balance between it being easy to

336
00:54:10.900 --> 00:54:13.770
Erik Hanson: share and read without having.

337
00:54:15.840 --> 00:54:17.760
Erik Hanson: without being too long

338
00:54:18.090 --> 00:54:21.750
Erik Hanson: and still maintaining enough unique

339
00:54:21.880 --> 00:54:24.510
Erik Hanson: possibilities. So the current pattern we have.

340
00:54:24.520 --> 00:54:33.429
Erik Hanson: there's a bit high. 1 billion different unique combinations that are possible per prefix

341
00:54:33.670 --> 00:54:41.330
Erik Hanson: on the off chance that we do run into duplicate issues. A new soft fix can always just be generated for that item, although that's quite unlikely

342
00:54:48.810 --> 00:54:56.559
Erik Hanson: before showing the deposit workflow. I want to show you how the automatic workflow works. So I gave a brief

343
00:54:58.320 --> 00:55:00.520
Erik Hanson: an example of that

344
00:55:01.620 --> 00:55:05.080
Erik Hanson: the previous one. I will

345
00:55:05.260 --> 00:55:14.570
Erik Hanson: show it for this as well. So I'll take an item here that has not yet been through the review process, but will pretend

346
00:55:14.800 --> 00:55:20.650
Erik Hanson: for moments that this has been accepted for publication.

347
00:55:22.910 --> 00:55:31.750
Erik Hanson: record that submission. And now it is moved into the copy editing stage. If you recall, we've now set up dos to be assigned as soon as an item reaches the copy editing stage.

348
00:55:32.260 --> 00:55:35.580
Erik Hanson: So if we go over to the Dois tab it loads up.

349
00:55:36.510 --> 00:55:43.570
Erik Hanson: We should now see that this item that we were just looking at now has a doi assigned. This is something that was not previously possible.

350
00:55:43.710 --> 00:55:57.799
Erik Hanson: and ends up, causing a lot more headaches than it might initially appear. Not having do I. Assignment tied to any semantic information about Ojs metadata is a huge thing for us, and consequently

351
00:55:58.230 --> 00:56:08.710
Erik Hanson: creates fewer problems downstream for registration agencies like crosswf. As a final bit. I'd like to just show the registry

352
00:56:09.910 --> 00:56:15.199
Erik Hanson: registration process. One other pain point from previous versions was that

353
00:56:16.290 --> 00:56:23.420
Erik Hanson: when you were trying to submit multiple items to be registered, they would often time out, and it was not always clear

354
00:56:24.600 --> 00:56:35.799
Erik Hanson: what the threshold for that was. The registration process has been reworked to use a jobs-based system. So for each of these items that we want to

355
00:56:36.300 --> 00:56:44.040
Erik Hanson: deposit, they will now be queued in a jobs queue. And so if we go here, what that means, we go to deposit them.

356
00:56:45.200 --> 00:56:49.200
Erik Hanson: Ui feedback should be instant, and they've been queued for deposit.

357
00:56:49.270 --> 00:56:58.419
Erik Hanson: and the Xml generation and all of that slow process will happen one at a time. and as those are updated, please refresh the page. We should see.

358
00:57:00.020 --> 00:57:03.360
Erik Hanson: once those processes have finished, that

359
00:57:06.290 --> 00:57:08.680
Erik Hanson: the deposit will be successful.

360
00:57:08.870 --> 00:57:16.950
Erik Hanson: I won't make you watch that, because that is a very long and slow process sometimes, which is the whole point of moving it into a background job.

361
00:57:17.740 --> 00:57:24.770
Erik Hanson:  And I believe that is all that I wanted to share with you today.

362
00:57:26.370 --> 00:57:27.800
Erik Hanson: Thank you so much.

363
00:57:32.590 --> 00:57:39.770
Rachael Lammey: Great thanks, Eric. We got it ruling in the end. So I think there's a question that's just come in.

364
00:57:44.020 --> 00:57:47.150
Erik Hanson: Yes.

365
00:57:47.690 --> 00:57:51.930
Rachael Lammey: from Tom. So yeah, this is the automatic assignment.

366
00:57:52.120 --> 00:58:00.710
Erik Hanson: Yes. Copy. The way it works is copy edit. The copy editing stage would be the first opportunity

367
00:58:00.800 --> 00:58:06.019
Erik Hanson: for things to be assigned. If, when it moves to the production stage, it could also be assigned.

368
00:58:06.220 --> 00:58:12.699
Erik Hanson: And so the idea is that this accommodates work flows where editors and journals

369
00:58:12.730 --> 00:58:32.529
Erik Hanson: either use or do not use the copy editing stage, but one way or another, it will have to go to either the copy, the editing stage, or the production stage before being published, so the automatic assignment will, it will attempt the automatic assignment at both of those stages. And this is also true if the legacy pattern generation

370
00:58:32.530 --> 00:58:44.170
Erik Hanson: is also still in place, because obviously that would require an issue to be assigned. So it will first try at the copy editing stage, if it skips, that it will try at the production stage, and if it skips that.

371
00:58:44.250 --> 00:58:54.390
Erik Hanson: or if it's still not possible, it will try again on publication, so it will try as many times as possible. But we'll rewrite steelies if they're already created. That answers your question.

372
00:58:56.050 --> 00:59:21.000
Rachael Lammey: Awesome. Thank you. I'm conscious of time. There's another question that's just come into the chat, and I think probably my question is around just where people can get information on upgrading to Ojs 3.4, so they can take advantage of a a lot of improvements. I think it'll just really help kind of ease a lot of those kind of pain points. So yeah, appreciate it. Thank you

373
00:59:21.580 --> 00:59:31.999
Erik Hanson: absolutely. I'll put my email if anyone has any questions, and I will also link out to the release post about Ojs 3.4, and I'll add that to the chat.

374
00:59:32.430 --> 00:59:33.890
Rachael Lammey: Excellent! Thank you.

375
00:59:34.470 --> 00:59:39.869
Rachael Lammey:  So at this point I'm gonna hand over to

376
00:59:40.130 --> 00:59:43.419
Rachael Lammey: Luis Montier, who's been

377
00:59:45.360 --> 00:59:49.229
Rachael Lammey: who's been leading things on the technical side.

378
00:59:53.750 --> 01:00:00.729
Luis Montilla: Sure. Oh, can you share my slides for me, please? Yes, I can indeed. Let me just grab those. Thank you.

379
01:00:22.420 --> 01:00:24.069
Rachael Lammey: Oh, sorry! 2 s.

380
01:00:46.920 --> 01:00:49.039
Rachael Lammey: Sorry I've got these.

381
01:01:10.100 --> 01:01:11.560
Rachael Lammey: I

382
01:01:17.970 --> 01:01:21.119
Rachael Lammey: I'm sorry. I just need to jump through to your slides.

383
01:01:31.720 --> 01:01:45.929
Rachael Lammey: Yeah, if you want to go ahead and introduce your session, then, sure, yeah, I will. I will. I'll catch up with you. Perfect. Thank you very much. Thank you. Everybody for being here. My name is Luis Montelia. I'm the technical community manager at crossroads.

384
01:01:46.070 --> 01:01:53.469
Luis Montilla: And today I will be talking about well, giving up a very basic introduction to the crossroads Api.

385
01:01:53.770 --> 01:01:58.290
Luis Montilla: which will start in the minutes next one. Yes, perfect.

386
01:01:58.520 --> 01:01:59.740
Luis Montilla: Next one, please.

387
01:02:01.350 --> 01:02:15.899
Luis Montilla: So this presentation will be about Apis. But more importantly, it will be about the possibilities that the community has to interact with the past network of relationships between research objects, and which is what we call the research nexus

388
01:02:16.230 --> 01:02:28.610
Luis Montilla: in more practical terms. We are talking about metadata, which are the basically the descriptors of of research objects and how we can establish relationships between them. Next one please.

389
01:02:31.280 --> 01:02:47.959
Luis Montilla: So we make this meet today openly available via our Api's and our public data files enabling the people and machines to incorporate it into their research tools and services, and at the same time, we collect and we operate distributed this metadata

390
01:02:48.190 --> 01:03:03.869
Luis Montilla: as part of the ever-growing research nexus. It's safe to assume that not everybody understands what an Api actually means. They're forced the purpose of this presentation. It's to provide a quick introduction to the use of the crossroads. Api.

391
01:03:04.240 --> 01:03:23.790
Luis Montilla: So if we see the slide, we see, then a an Api is an software intermediary that allows 2 applications to talk to each other, and Apis are often compared to a weather service, facilitating communication between customers ordering items from a menu and the kitchen producing those items

392
01:03:24.510 --> 01:03:25.700
Luis Montilla: next one, please.

393
01:03:29.360 --> 01:03:44.459
Luis Montilla: So we make this metadata open through our rest. Api. You can visit the URL to access our documentation. I also shared the link in the chat and the presentation before and then you can use this to perform chorus directly from your web browser.

394
01:03:44.740 --> 01:03:53.820
Luis Montilla: There is no registration required. Cross Ref. Once again, it's committed to providing an open and as anonymous as possible access to scholarly metadata

395
01:03:54.140 --> 01:03:59.260
and keep this URL at hand for the next examples. Please.

396
01:04:02.080 --> 01:04:10.219
Luis Montilla:  however, we do have some recommendations and etiquette suggestions to follow. If you wish to retrieve metadata

397
01:04:10.560 --> 01:04:22.250
Luis Montilla: first, by adding your email address to your request, we can contact you in case of issues. then, additionally, we redirect this request to a specific polite.

398
01:04:22.300 --> 01:04:23.750
Luis Montilla: a pool of servers.

399
01:04:23.840 --> 01:04:32.939
Luis Montilla: These servers are generally more reliable because we can more easily protect them from misbehaving scripts in contrast with full anonymous requests.

400
01:04:33.670 --> 01:04:39.879
Luis Montilla: And then there is a third alternative, especially if you are using our rest. Api for a production service

401
01:04:39.900 --> 01:04:52.440
Luis Montilla: that require high predictability this option is to consider using our our paid plus service which which provides you with an authentication token that directs you to your request

402
01:04:52.560 --> 01:04:55.550
to a pool of service that are extremely predictable.

403
01:04:56.310 --> 01:04:57.530
Luis Montilla: Next one, please.

404
01:04:58.700 --> 01:05:14.079
Luis Montilla: So for the specific examples, I'm going to show you next. I'm going to use postman, which is an Api client, and we don't endorse this app, but we acknowledge that it is widely used, and it provides a set of functionalities that makes metadata retrieval much easier.

405
01:05:14.320 --> 01:05:24.890
Luis Montilla: However, you can also execute these words directly in your web browser once again. In most cases your browser will display this quarter results as in adjacent format.

406
01:05:25.030 --> 01:05:30.239
Luis Montilla: However, in some instances you might need to install a browsering extension

407
01:05:31.480 --> 01:05:32.749
Luis Montilla: next one, please.

408
01:05:34.100 --> 01:05:39.180
So, before moving on, I would like to take a second to establish some basic vocabulary

409
01:05:39.400 --> 01:05:51.080
Luis Montilla: that will that you will encounter throughout these presentations. So the text that you see here that at the top represents a query. The first part that you see color in yellow indicates the server.

410
01:05:51.420 --> 01:06:06.790
Luis Montilla: So this identifies the entity providing the service, and all of our crossraft-related cores will share this common route. Then you have the endpoints. This is a key term that we will use to identify the digital locations that receive a connection.

411
01:06:06.990 --> 01:06:12.089
Luis Montilla: And I will show you soon the other end points that we have available to the general community.

412
01:06:12.400 --> 01:06:19.089
Luis Montilla: And then, finally, we have the the parameters you can identify them as being preceded by a question mark.

413
01:06:19.620 --> 01:06:23.849
Luis Montilla: and then they follow the notation of having a key and a value.

414
01:06:23.980 --> 01:06:40.630
Luis Montilla: So, for example, in this specific example, you can see a query that has the the mail to parameter in these parts basically allow you to specify resources and also to perform all directions such as in this case identifying yourself

415
01:06:41.420 --> 01:06:42.620
Luis Montilla: next one, please.

416
01:06:43.920 --> 01:06:52.589
So if we check the documentation. We'll find a list of different locations for the endpoints that our Api contains. Data of interest

417
01:06:53.000 --> 01:07:10.179
Luis Montilla: in this presentation. I'll show you some basic examples of the data that you can retrieve using some of these. Perhaps you know this in the previous slide that I was using the funders endpoint but we have endpoints specifically for journals, works across rough members and several others.

418
01:07:10.870 --> 01:07:12.030
Luis Montilla: Next one, please.

419
01:07:14.210 --> 01:07:21.040
Luis Montilla: What? Now, let's explore some basic examples. We'll start with Funder to article relationships.

420
01:07:21.090 --> 01:07:28.089
This is interesting because funders do not automatically know when the work that they have funded is polished

421
01:07:28.470 --> 01:07:43.969
Luis Montilla: and it. But it's also essential for reporting on the impact of brands. And then finding this information can be challenging through other means. Because of publisher software and institution institutions do not systematically report it.

422
01:07:44.660 --> 01:07:45.880
Luis Montilla: Next one, please.

423
01:07:46.790 --> 01:08:03.409
Luis Montilla: I'm going to. This is not going to be a live demo. This is going to be through done through screenshots so as you can see here. We include in the top part the string that contains our server. The endpoint that I was mentioning before the funders endpoint

424
01:08:03.630 --> 01:08:16.790
Luis Montilla: and other parameters. In this specific case I'd like to start with the a very general search, so I include the mail to parameter to make a product request, and I add a query with the text, German Research Foundation.

425
01:08:17.970 --> 01:08:19.270
Luis Montilla: next one, please.

426
01:08:20.140 --> 01:08:37.569
Luis Montilla: So when you submit this query. You will receive best a status code. In this case, everything it it's okay. And then we luckily we can see how many items we are retrieving with this query, which I'm highlighting here you can see that we are retrieving 4 results

427
01:08:38.359 --> 01:08:39.650
Luis Montilla: next one, please.

428
01:08:40.479 --> 01:08:54.730
So if we examine hopefully, it's very. They had have a good resolution. But if we examine the output in detail, we will notice that our peripiers, as part of the field, alternative names and organization that we are looking for appears on top

429
01:08:55.279 --> 01:09:03.010
Luis Montilla: and then from here we can take notice of the Id number. Then can you use this to refine, refine our queries next one, please.

430
01:09:04.279 --> 01:09:10.920
Luis Montilla: So, for example, if we use this Id as part of the an additional path level in our funders endpoint.

431
01:09:11.020 --> 01:09:23.449
Luis Montilla: we can retrieve organization specific data. For example, here you, we can see that almost 200,000 works have the the Grf as part of the re funding organization

432
01:09:24.790 --> 01:09:26.639
Luis Montilla: next one, please. Thank you.

433
01:09:27.670 --> 01:09:40.089
Luis Montilla: So we can take a few seconds. And in case you want to try this, or if, of course, if you're watching the recording, you can post a presentation. So please visit this URL, you can scroll down to the Funder section.

434
01:09:40.390 --> 01:09:50.949
Luis Montilla: Click, get. And please remember to add your email to the mail, to field and finally include the any funding organization that you wish in that query field.

435
01:09:51.310 --> 01:09:52.889
Luis Montilla: Let's have a few seconds.

436
01:09:59.890 --> 01:10:02.120
Luis Montilla: Okay, next one, please.

437
01:10:03.780 --> 01:10:18.849
Luis Montilla: So this screenshot shows one possible result. Please notice that you should get the status code 200, indicating that your query proceeded correctly, and what it's called here. The response body contains your data.

438
01:10:20.470 --> 01:10:21.770
Luis Montilla: Next one, please.

439
01:10:22.820 --> 01:10:35.769
Luis Montilla: If you're pasting these queries directly in your web browser at the search world, it will likely look like this the latest versions of fire folks and Chrome and several others should let you visualize this Jason file.

440
01:10:36.060 --> 01:10:43.089
Luis Montilla: I was doing some testing safari, and then, if it was one, they want required to installing an extension. Consider this

441
01:10:45.110 --> 01:11:02.860
Luis Montilla: next one. Thank you. So we can pro of this output a little bit more by adding additional field queries. Once again, these are listed in our documentation. Some of these accept text rings, some others are numbers, the others are Boolean expressions, meaning true or false.

442
01:11:03.100 --> 01:11:07.080
Luis Montilla: and of course they can be combined different ways. Next one, please.

443
01:11:08.780 --> 01:11:17.790
Luis Montilla: So, for example, here, let's imagine that we are interested in knowing how many of the selected organizations funded journal articles are publicly available.

444
01:11:18.150 --> 01:11:25.980
Luis Montilla: So in this case we can add one filter that includes the type element. In this case, we're setting these to journal articles.

445
01:11:26.090 --> 01:11:34.130
Luis Montilla: and we are also adding the filter that asking if this contains a full text element, and we are setting this to false

446
01:11:36.220 --> 01:11:44.100
Luis Montilla: next one, please. So you can try combining some of these. I'm showing you here the example that I just used.

447
01:11:51.040 --> 01:11:59.919
Luis Montilla: And then, of course, we can combine these fields more. So, for example, we can also explore, we can query the specific

448
01:12:00.000 --> 01:12:04.559
Luis Montilla: awarded grants that is available in the in the work list.

449
01:12:06.480 --> 01:12:07.800
Luis Montilla: Next one please

450
01:12:09.210 --> 01:12:20.920
Luis Montilla: of, we can also facet aggregate data using the facet fields. In this case, we can use this. For example, to aggregate the results in terms of the publication year

451
01:12:22.360 --> 01:12:23.420
Luis Montilla: next one.

452
01:12:24.670 --> 01:12:30.119
Luis Montilla: And here I'm showing the example. In case you want to replicate these examples.

453
01:12:33.520 --> 01:12:48.459
Luis Montilla: and what with this slide that will finish my presentation, feel free to contact me, I will let my details in the chat and hope. This presentation was kind enough to anyone who was not aware of how to use an Api before. Thank you very much.

454
01:12:53.390 --> 01:13:06.099
Rachael Lammey: And, Louise, that was excellent. Thank you very much. And again, just to reiterate, we'll share the slides and the recordings so that you can. You can dig into this more

455
01:13:06.790 --> 01:13:21.469
Rachael Lammey: Louise joined the the team at Crossraf a couple of months ago. So if you enjoyed that demo and there'll be loads more to come in future and just help people get to to grips with how to use the the crossref metadata.

456
01:13:21.930 --> 01:13:22.900
Rachael Lammey: I'm

457
01:13:24.030 --> 01:13:49.009
Rachael Lammey: again questions in the charts or in the Q. And a, and we'll pick those up. In the meantime, I'm going to keep screen sharing and I'm going to talk just really quickly about the the work that we've been doing with the with the data that's come from retractionwatch. And Martin Eve is going to help me out whenever I get when it as. And when I get stuck.

458
01:13:49.130 --> 01:13:50.910
Rachael Lammey: the

459
01:13:52.490 --> 01:14:21.760
Rachael Lammey: just for for context, in case you weren't aware, crossraf acquired and opened the retraction watch data in the middle of September. And I've linked to the blog post that describes that in more detail. The other thing I will do as well is for the context of why this information is important, etc. We covered in a community in a community session

460
01:14:21.770 --> 01:14:29.259
Rachael Lammey: last month as well. So we'll share those which will give you lots more context than we have time to do today.

461
01:14:29.980 --> 01:14:41.780
Rachael Lammey: There are lots of things that we know and expect our community to do with more comprehensive complete information on retractions? So

462
01:14:41.910 --> 01:14:54.769
Rachael Lammey: we wanted to make the data available. A, you know, in a very simple Csv format, but also via our labs Api, so that people can can start to get to grips with it early doors.

463
01:14:54.930 --> 01:15:00.510
Rachael Lammey: I'm so, as I said, as well as the

464
01:15:01.410 --> 01:15:11.270
Rachael Lammey: Csv format. We made the our more more accurately. Martin made the data available via our labs. Api.

465
01:15:11.510 --> 01:15:19.179
Rachael Lammey: What I mean when I say the Labs Api is that it's it's an environment where we test stuff out.

466
01:15:19.270 --> 01:15:38.779
Rachael Lammey: adding new data and new representations of existing data. And I think the main message of this presentation is. It's where we'd love some feedback on how we are displaying and representing the the data. There's a little snapshot of it over to the the right hand side of this. This slide

467
01:15:39.050 --> 01:15:46.420
Rachael Lammey:  As Louise mentioned, we asked you to use a meal, too. So your email to

468
01:15:46.600 --> 01:15:49.579
Rachael Lammey: when you're accessing the the data

469
01:15:49.690 --> 01:15:59.350
Rachael Lammey: and the information is available. As you can see via the Via. The works route in the in the Labs Api.

470
01:16:00.050 --> 01:16:28.770
Rachael Lammey: I've pulled some of the information out just to try to make it a little bit clearer. Martin, I'm happy again. You can talk to the pieces that I've missed. But what sort of jumped out to me is someone who uses and is really interested in this is that we've got a couple of fields here, so we've got the the raw Id of the center for scientific integrity. Who are the folks behind the retraction watch data. So I think that's a that's a

471
01:16:28.800 --> 01:16:41.059
Rachael Lammey: a nice thing. Because again, we've got rural identifiers. We want to be able to use those 2 uniquely and accurately identify institutions. And we've got

472
01:16:41.210 --> 01:17:03.769
Rachael Lammey: we're trying to be really clear about who made the about who made the assertion that an article has been retracted, because in many instances we've got a retraction being asserted by retraction. Watch that isn't currently reflected in the publisher metadata. And again, of course, we really hope and expect that that will that that will change over time.

473
01:17:04.050 --> 01:17:09.209
Rachael Lammey:  and we're thinking about how we model retractions full. Stop.

474
01:17:09.490 --> 01:17:26.650
Rachael Lammey:  so, said Martin, implemented the workflow and crunched the retraction watch data to make it available via these routes. So thank you very much. But do you want to say more about the current implementation and the plans going ahead.

475
01:17:27.770 --> 01:17:29.070
Martin Eve: Sure. So

476
01:17:29.360 --> 01:17:53.209
Martin Eve: there are some limitations around what we've got at the moment. So, for instance, it's not easy to do filters in our Labs Api system. So this should not be at this point a full replacement for the production Api, and and you shouldn't expect the same same stability or performance. What it does do, though, is, let us test whether the information that we're representing is in a format that's of use to our community.

477
01:17:53.680 --> 01:18:17.190
Martin Eve: So what I would urge is, if you are someone who's been making use of the retraction watch data, and you're thinking about using it in an Api format. If you could have a go at using the Labs Api, and seeing whether it meets your needs and giving us feedback on what's missing, what you need. What's there? What's good? That would all be incredibly helpful for us in thinking about how we move this through to production

478
01:18:17.330 --> 01:18:19.230
Martin Eve: at a later stage.

479
01:18:22.810 --> 01:18:27.380
Martin Eve: Is that is that enough, Rachel? I'm not, as I'm not sure what else I can add there. At this point

480
01:18:27.560 --> 01:18:29.610
Rachael Lammey: I think that

481
01:18:29.970 --> 01:18:54.540
Rachael Lammey: I think that that's more than enough, and we will again. We'll pass on information on how you can get in touch with us about that and I know that lots of people have already. So I think that's really important. And again, please feel free to jump into the chat or QA. And ask us questions about the data, and we'll also post a link to the the webinar

482
01:18:54.670 --> 01:19:02.600
Rachael Lammey: from a couple of weeks ago to do that. So we just want to flag this up. This is an area where we're really keen for for feedback. So

483
01:19:02.930 --> 01:19:05.840
Rachael Lammey: so so do go ahead and give us that

484
01:19:06.170 --> 01:19:07.140
Rachael Lammey: I am.

485
01:19:09.470 --> 01:19:29.680
Rachael Lammey: I am going to. So, Martin, I'm gonna leave you to your own devices for the next demo. So and so you've been doing work to analyze the present preservation status of content registered by crossref members. So. I'll leave it to you to to share your analysis and your your thinking around that. Now, thank you.

486
01:19:30.890 --> 01:19:39.849
Martin Eve: Thank you very much. Just bear with me a second while I try to work out. I'm gonna share the correct monitor, or whether I'm gonna show everyone all my emails.

487
01:19:40.120 --> 01:19:44.590
Martin Eve:  try that one.

488
01:19:45.900 --> 01:20:03.109
Martin Eve: Have you got presentation there, Rachel, or presentation and no emails? That was a good guess. Then, on the on the one of 3 notice. Okay, thanks everyone. So I'm gonna talk today a little bit about the state of digital preservation and a study that we conducted across 7 million dois.

489
01:20:04.150 --> 01:20:19.660
Martin Eve:  this is a really important aspect of crossrefs. Practice that sometimes goes under remarked upon, which is that for crossref to provide a stable linking service between different platforms, we need to know that material has been safely, digitally preserved.

490
01:20:19.880 --> 01:20:35.190
Martin Eve: Why is that? Because if the original source goes offline, where's the doi going to end up pointing, if there's no digital preservation source to which we can redirect doi, then actually, the persistence of our yeah Urls is limited to the lifetime of of an original

491
01:20:35.270 --> 01:20:37.579
Martin Eve: Http endpoint.

492
01:20:39.130 --> 01:20:47.459
Martin Eve: So when you join Crossref, one of the conditions of membership is that you will make best efforts to ensure that your material is safely, digitally preserved.

493
01:20:47.680 --> 01:20:59.669
Martin Eve: But we don't know what proportion of scholarly objects assigned to do. I are actually adequately preserved in a recognized dark, archiving system, like clocks, locks, portico, or even the Internet Archive.

494
01:21:00.300 --> 01:21:16.879
Martin Eve: We don't really know how stable those preservation systems that underpin the persistence of these persistent identifiers is at the moment we haven't yet had a mass extinction event of of Dois, or anything that has has really used us to use those systems en masse.

495
01:21:17.540 --> 01:21:24.400
Martin Eve: We don't know which actors of our membership are behaving well on this theme. Who does digital preservation well and who does it badly?

496
01:21:24.910 --> 01:21:36.109
Martin Eve: We don't even really know in the era of digital who should be doing this? Is it libraries? Is it publishers? Has that changed since the print era? Should it be both of those parties.

497
01:21:36.680 --> 01:21:43.899
Martin Eve: and most importantly, perhaps with a slightly apocalyptic tone. Again, is it already too late?

498
01:21:44.040 --> 01:21:53.060
Martin Eve: Is a vast suite of material that is not preserved, that we're now going to struggle to get into some preservation mechanism. At this late stage in the day.

499
01:21:55.710 --> 01:22:06.229
Martin Eve: So I set about building an item level preservation database system that would allow us to iterate over a sample of Dois, and to figure out where these things are preserved.

500
01:22:06.890 --> 01:22:16.089
Martin Eve: There's an existing system called the Keepers registry that performs a similar function, but it doesn't have an Api with open use that we could just use to query at scale

501
01:22:16.100 --> 01:22:21.209
Martin Eve: a large number of Dois. It also looks at the container level.

502
01:22:21.230 --> 01:22:27.949
Martin Eve: so it will tell you. This issue and this volume of this journal are preserved, not whether this do I is preserved.

503
01:22:28.400 --> 01:22:46.249
Martin Eve: So I had to build something that would translate between those layers. But I built a system that incorporates the the archives that you can see on this slide share. So Carrioniano, which is predominantly southern Latin American material clocks controlled lots of copies, keep stuff safe. Archive.

504
01:22:46.310 --> 01:23:01.110
Martin Eve: have the trust Internet Archive locks. The more general version of clocks, pkps, private locks network, which is a system that Pkp implemented to help open journal systems users ensure their material is safe

505
01:23:01.370 --> 01:23:06.730
Martin Eve: at Portico, another dark archive and the Oakall scholars portal in Canada.

506
01:23:09.950 --> 01:23:22.630
Martin Eve: I also needed some way of figuring out how to score members and how they're doing on digital preservation. It's all very well to just say, this is what's going on. But you need some way of ranking them and understanding the categorization.

507
01:23:22.680 --> 01:23:27.390
Martin Eve: So I invented a scale because there is no standardized scale for digital preservation

508
01:23:27.510 --> 01:23:50.489
Martin Eve: where I gave gold medals to those that have 75% of their content digitally preserved in 3 or more recognized archives. Silver members in my scale are those with 50% of their content in 2 or more recognized archives, bronze 25% in one or more recognized archives and unclassified those that don't even meet the bronze categorization.

509
01:23:50.740 --> 01:24:02.529
Martin Eve: So this is a scoring mechanism that works across 2 axes at the same time it works across a sense preserved, and in a number, and the number of archives that there are duplicate preservations in.

510
01:24:03.120 --> 01:24:11.320
Martin Eve: So the very best in this would be to have all of your content in 3 or more of the recognized archives that I've been working with.

511
01:24:11.480 --> 01:24:16.990
Martin Eve: whereas the worst would be, you have less than 25%, not even in one archive.

512
01:24:20.530 --> 01:24:32.939
Martin Eve: So what does it look like overall? I looked at 7 million duis from our sampling framework, and I found some pretty disturbing results in some ways, but perhaps not unexpected to those who've been looking at this for a while.

513
01:24:33.570 --> 01:24:41.889
Martin Eve: So those in the real danger zone, the unclassified space with that less than 25% in one archive, we found that approximately

514
01:24:42.210 --> 01:24:45.169
Martin Eve: 33%. Third of all the content.

515
01:24:45.470 --> 01:24:55.850
Martin Eve: From members that I looked at was in that group. Meanwhile, bronze, which you know is is okay, it's one archive with at least 25% in it made up

516
01:24:56.000 --> 01:25:12.110
Martin Eve: approximately 57.7% of of the members that we we examined silver again. It's a much smaller percent, 8.4 6, and only about 2% or so made it into that gold category. The

517
01:25:12.120 --> 01:25:15.759
Martin Eve: gold gold star system at the top there.

518
01:25:15.910 --> 01:25:23.539
Martin Eve: So there's a worrying preservation picture emerging across crossraf members that we need to perhaps do something about.

519
01:25:25.120 --> 01:25:30.639
Martin Eve: I want to know also which types of members were behaving in in what type of way?

520
01:25:30.690 --> 01:25:47.970
Martin Eve: There's a variety of ways in which you can classify the size of cross-ref members, we can do it by revenue. So this is a chart that shows the breakdowns from those who have the very lowest levels of revenue at the top through to those that have the highest level at the bottom here.

521
01:25:48.310 --> 01:25:52.350
Martin Eve: and I think what you can see is the silver bar, which is perhaps the

522
01:25:52.770 --> 01:26:04.230
Martin Eve: a key sign that people are doing things well with at least 2 archives backing. The majority of their material increases substantially as we get down towards those with more resources.

523
01:26:04.850 --> 01:26:29.020
Martin Eve: perhaps heartening, though even in though even among those with the lowest resources of our members, we do see that bronze bar where they are conducting at least one source of digital preservation, for for some of their material is happening. So there is an awareness growing Eve, among all types of publisher members that they should be doing digital preservation, and that it's something that does matter for their membership with Crossrath.

524
01:26:31.940 --> 01:26:46.080
Martin Eve: You can also do this by number of member deposits. But I think the picture again is clear. You can see this silver bar grows substantially as we get down to the bigger members who are doing more deposits. The bronze bar likewise stays.

525
01:26:46.690 --> 01:27:13.650
Martin Eve: kind of goes down again at the end, because the silver bars eaten it up, which is a good sign. But if you take bronze and silver collectively, as a marker of who's doing preservation apart from the very last bar of size, we've actually got a good good level of growth as we go down there. But clearly there are a number of smaller members here in this type of categorization who need us to to have a chat with them about what they're doing for digital preservation, because at the moment their material is not particularly safe.

526
01:27:16.030 --> 01:27:35.350
Martin Eve: If you look at this on the works front. So that was looking at members as a whole rather than looking at the number of actual works, though. So we found that approximately 60% were preserved at least once. So 60% of the content in that sample had some kind of backup system in place that could rescue it if if the site went down.

527
01:27:35.890 --> 01:27:55.629
Martin Eve: But that left approximately 30% in our sample that seemed unpreserved. And a serious risk with an exclusion of 14% for being too recent. So they're in the current year. So they weren't yet in digital preservation archives, not being journal articles or having insufficient date mess data for us to identify the source.

528
01:27:58.590 --> 01:28:22.509
Martin Eve: So what are we gonna do about this? We've got a forthcoming peer review paper that sets out the the data behind this, and gives you the opportunity to read in more detail about the processes that we use to come to these conclusions. We've got some lay and easy read summaries of preservation situation coming out as well so that we can start spread the word even among non technical users, or less technically minded publishers.

529
01:28:23.300 --> 01:28:39.190
Martin Eve: we'd like to conduct some direct member outreach. I think it's really important that we, in a non confrontational way, get in touch with people who are not yet doing this well and work with them because it benefits everybody to have a secure and persistent linking system between our articles

530
01:28:39.360 --> 01:28:42.410
Martin Eve: and other types of work that use Dois.

531
01:28:43.550 --> 01:29:11.179
Martin Eve: We're also working on experimental system called Project OP. Sit, which I've just started work on the last couple of weeks. This is a project that aims to integrate. Do I deposit with ingestion into digital preservation archives, and then tries to monitor an endpoint. So a doi resolution point to see whether it's gone down. And to tell people this is a problem. You can now view it at this archive instead, if you like.

532
01:29:11.800 --> 01:29:26.629
Martin Eve: So if you Google for that project of Sit and Crossref, you should find the specification document and call for call for comment on that if you want to feed back on that it's not too late. Still, get in touch.

533
01:29:27.250 --> 01:29:35.880
Martin Eve: And full charts and data set behind. These findings are available at the website there. The hyphen vaults fly. Dot dev.

534
01:29:38.250 --> 01:29:41.319
Martin Eve: Thank you very much. I hope that was of interest.

535
01:29:44.960 --> 01:29:48.240
Rachael Lammey: Excellent. Thank you. So I think there's

536
01:29:48.680 --> 01:29:54.939
Rachael Lammey: already interested in going to zoom in on the

537
01:29:55.040 --> 01:30:08.430
Rachael Lammey: the charts, and to be able to to find more information on that. So Rhiannon, do go and check I the link that Luis is just posted in the in the chat. And

538
01:30:09.420 --> 01:30:11.920
Rachael Lammey: again, if if you've got, follow up questions.

539
01:30:14.240 --> 01:30:15.789
Rachael Lammey: let Martin know.

540
01:30:17.340 --> 01:30:18.189
Martin Eve: Thank you.

541
01:30:21.390 --> 01:30:43.979
Rachael Lammey: And Martin, are you hanging around for sort of the next sort of 1520 min? So if you're mulling over a question, he'll still be. He'll still be here if you want to add answered, more more live? But yes, it's it's a really interesting analysis, and there's definitely follow up options that we can see both this cross ref on this and his community, I expect.

542
01:30:49.820 --> 01:30:55.389
And there's a question just jump jumped into the into the QA. As well.

543
01:31:00.230 --> 01:31:29.230
Martin Eve: I think that the this is because of bad mess data on locations. So the question was that there are cities, sometimes, or regions in the location or Co. What we call country. It's supposed to be a country feel. But sometimes people put more detailed information in there. So it's the best you know. I could spend a lot of time clearing up that data and going through. But with 7 million records filtering in just have to basically

544
01:31:29.230 --> 01:31:34.129
Martin Eve: take it with a pinch of salt. The the location fields in there, and we've done our best on location.

545
01:31:35.300 --> 01:31:35.980
Rachael Lammey: Oh.

546
01:31:36.640 --> 01:31:38.600
Rachael Lammey: thank you?

547
01:31:39.360 --> 01:31:44.489
Rachael Lammey: So the final presentation stroke demo for this session

548
01:31:44.560 --> 01:31:53.169
Rachael Lammey: is duis for for static sites. So I should. Data from our from our

549
01:31:53.230 --> 01:32:00.450
Rachael Lammey: Labs team is going to give us a quick demo, an overview of the static Site

550
01:32:00.670 --> 01:32:18.159
Rachael Lammey: identifier generator using the Crossref website as a as a test case. I should appreciate a semi live demo of stuff that is in active development. But again, I think you've you've put some safeguard. You've you've put some safeguards in place as well. So I'll hand over to you to to talk us through it.

551
01:32:18.500 --> 01:32:22.950
Esha Datta: Alright. Great! Thank you so much, Rachel. I'm gonna share my screen.

552
01:32:25.540 --> 01:32:28.250
Esha Datta: Can everyone see my screen?

553
01:32:29.310 --> 01:32:33.749
Rachael Lammey: Yeah, we can see the slide deck. Okay?

554
01:32:33.970 --> 01:32:54.700
Esha Datta: Yeah. So I'm going to just kind of talk about this a little bit and then do a video demo because some of the processing takes a little time. And that's boring. So basically, I am going to give a demo of this lovely, wordy piece of software called static

555
01:32:54.790 --> 01:33:22.330
Esha Datta: Page id generator. Because I couldn't think of a better name. It is developed to help create pids such as Dois for blogs or other research materials built by static site generators, such as Hugo Jekyll, or others. Currently, the software is being tested with Hugo. We decided to develop the software because increasingly at Crossref, we are seeing a need to develop permanent urls for our own use on our website

556
01:33:22.370 --> 01:33:30.899
Esha Datta: and could see a use for the wider community as well. Our website is built using Hugo the software

557
01:33:32.180 --> 01:34:01.289
Esha Datta: can track a git repository of the static site in question. And if a user specifies a path, it'll start focusing on any files under that path. It'll generate unique ids for the files that a user wants tracked. And if the user is a cross ref member, it'll build the Xml deposit files, deposits the metadata for the files into cross Ref registers the dois and adds the doi back to the file in question.

558
01:34:01.290 --> 01:34:26.429
Esha Datta: If you're not a crossword member for now, basically, all it'll do is features one and 2, which is, tracks the files and generates a unique Id, but we are developing a Plugin architecture so that it can accommodate other use cases and other registration agencies, and also other types of unique ids that you'd want. So I'm gonna start with the end result of this, which is

559
01:34:26.780 --> 01:34:32.349
Esha Datta: that here is an example page of the test version of Crossref

560
01:34:32.380 --> 01:34:39.779
Esha Datta: of the Crossroft site. So I basically just created this very lovely test page and ran the script

561
01:34:39.780 --> 01:35:02.559
Esha Datta: against it, which then deposited this this metadata into crossref, which you can see in the Api. And here's the doi for that, and it can also then be used in downstream applications set up, such as the metadata Search, where, if you did a search on this, you would find the same

562
01:35:02.900 --> 01:35:07.009
Esha Datta: article. And if I go back to it, here is the file.

563
01:35:07.040 --> 01:35:22.019
Esha Datta: So basically, I'm going to show you how to show you 2 ways of how I use the script. First is in the Get Lab Repository, which contains the test version of the site

564
01:35:22.030 --> 01:35:46.980
Esha Datta: and then the second is the command line version. So in this repository we run the script using Git lab's continuous integration setup. And if you use, if you have a repository that's in Github. It has a similar process. So I first ran in the Git lab Repository, a setup process that creates a config file which contains the information. Let me.

565
01:35:47.070 --> 01:36:10.889
Esha Datta: I have it queued up in my video. So here's the config file. So here, you see that I'm asking the script to track everything in the repo. I've put in a test. Do I prefix? I have this crazy, long domain, which is basically just the test version of the sites domain.

566
01:36:10.890 --> 01:36:20.130
Esha Datta: I'm specifying that I want an Id type of doi. And the Json file basically contains all of the information of the files that are being tracked.

567
01:36:20.200 --> 01:36:32.069
Esha Datta: And now I'm going to play the video, not sure how much time we have. So I'll check in again after I've finished the get the repository part of the demo. And if we have more time, I can also show you the cli.

568
01:36:32.100 --> 01:36:35.540
Esha Datta: Yeah, I think we're okay for time. Okay, cool.

569
01:36:36.750 --> 01:36:41.149
Esha Datta: A Json file contains. Can you all hear that all of the information for the file

570
01:36:41.170 --> 01:37:00.099
Esha Datta: start tracking a file? I created this file, which is new and basically added some front matter. So it includes some of some basically labels that is recognized by the Hugo site.

571
01:37:00.100 --> 01:37:22.549
Esha Datta: And also crucially, I added this X version tag, which basically tells the script to start tracking it. The value to the right of X version is in semantic version, style. So basically, the first 0 tells you that this is the major version. The next one is the minor version, and this is the patch.

572
01:37:22.600 --> 01:37:46.609
Esha Datta: So the script looks for a default version of 0 point 0 point 0, and it knows that this is a new file, and to begin tracking it. So once I push this file. I start to get a process that runs this job and it pulls down a docker image and

573
01:37:46.610 --> 01:38:04.059
Esha Datta: runs the script essentially. So we are mentioning giving some credentials for it. And then we are also saying that it needs to check the repository over here, that submission type is cross Ref.

574
01:38:04.430 --> 01:38:28.029
Esha Datta: and that it needs some more submission, information, or deposit information for the script to deposit the metadata that you will be using eventually. So what it does is it adds the file information to the Json file. It deposits the Xml. And then it also

575
01:38:28.250 --> 01:38:46.709
Esha Datta: creates a doi and adds it back to this file, and you know that all is well because the job has succeeded. It has run successfully. We can check the page back again, and we can see that a doi has been added to this page.

576
01:38:46.710 --> 01:38:59.350
Esha Datta: and we can also see that once the site has been deployed to production. If we click on this and go to this dui, it takes you to the site.

577
01:38:59.410 --> 01:39:26.069
Esha Datta: to the page that's been deployed to production. So this is basically how you would run it. and continuous integration on a git lab hosted repository. There is a similar operation that you would do if it was hosted on Github as well, because Github also has a continuous integration setup

578
01:39:28.550 --> 01:39:47.039
Esha Datta: or running the script on the command line. I have cloned the static page id script generator on to my computer. And I have installed all of the requirements in a virtual environment. And in another

579
01:39:47.100 --> 01:40:06.309
Esha Datta: terminal I have my static site Repository. I first need to initialize the repository for the script which generates 2 files that helps the script track. The versioned files so to run the initialize script.

580
01:40:06.310 --> 01:40:19.090
Esha Datta: I run this command, which requires a few arguments that tells the script a few things. It tells the script that you to track this particular repository

581
01:40:19.220 --> 01:40:31.860
Esha Datta: to track the path in the repository which is content. It gives it the production domain that it needs to generate a doi and a doi prefix.

582
01:40:31.860 --> 01:40:51.000
Esha Datta: So once that is generated it will create 2 files. This is to track the files, and this is essentially contains all the values needed to generate Dois. So I already ran this, and so there is a config dot yaml and a pid, dot Json, which looks

583
01:40:51.240 --> 01:40:59.630
Esha Datta: like this for the config. Yeah, Yaml file, and it's just an empty pit, Dot Json file, because I haven't run anything.

584
01:41:00.120 --> 01:41:19.690
Esha Datta: So in order to let the script know that I want it to be tracked, I add this particular tag with its value in the front matter. So I tell the script that I want this to be versioned, and I add an exp version tag to it. And I follow the semantic versioning

585
01:41:19.830 --> 01:41:36.030
Esha Datta: style, which is major major version, minor version and patch version. So currently, we have functionality that looks to see if the version number is 0 dot 0, and it's

586
01:41:36.170 --> 01:41:49.970
Esha Datta: belonging to this tag, and then it will start to run all that's needed run the script after telling the script which files we want to be tagged.

587
01:41:49.990 --> 01:42:10.270
Esha Datta: and we do this by again specifying the repository path. We're telling it that the submission type is going to be crossref because you're going to deposit this into crossref. And then we have another file that tells the submission scripts, some more information to make the submissions successful.

588
01:42:11.260 --> 01:42:14.240
Esha Datta: So it's going to generate some

589
01:42:14.340 --> 01:42:17.970
Esha Datta: hits. It's gonna track the files.

590
01:42:18.500 --> 01:42:27.029
Esha Datta: And it has now submitted the file. And now it's going to check the doi registration status.

591
01:42:27.600 --> 01:42:35.990
Esha Datta: Once it runs it, it checks the dois, and then it adds the doi back to the file which you can see

592
01:42:36.040 --> 01:42:37.340
Esha Datta: over here.

593
01:42:37.420 --> 01:42:48.990
Esha Datta: So now we know that this file has a doi and can be accessed once this once the website has been deployed to production.

594
01:42:49.120 --> 01:42:56.560
Esha Datta: So that's how you would run it in the Cli so wanted to show you what it would look like if I

595
01:42:56.640 --> 01:43:08.069
Esha Datta: checked the doi from the command line. So this is a page that has actually been deployed to production, which is the test

596
01:43:08.110 --> 01:43:10.390
Esha Datta: website that I have. So if I

597
01:43:10.640 --> 01:43:26.129
Esha Datta: copy and pay to paste this, or just follow the link, this will show me the page that has been deployed, and, as you can see, the doi is listed on the page here. And this is all of my test text, of course.

598
01:43:29.400 --> 01:43:43.470
Esha Datta: So that's basically the demo for this. Thank you for bearing with the video and the extraneous sounds. Future steps include that. It's still an active development, and we still have

599
01:43:43.470 --> 01:44:06.259
Esha Datta: a ways to go, including incorporating it into the crossroads website, workflow. I'm I'm planning on converting this into a library and allowing plugin functionality so that it can accommodate other types of used cases as well, and I'm happy to hear more feedback from all of you. And you know, see how we can collaborate better on this. Thank you so much.

600
01:44:13.430 --> 01:44:26.870
Rachael Lammey: That's great. Thank you very much. It all worked very very smoothly, and there are a couple of hopefully quick questions. In the QA. If you want to call those up

601
01:44:27.710 --> 01:44:30.520
Esha Datta:  or I can. Just

602
01:44:31.550 --> 01:44:39.049
Esha Datta: yeah. Is it the do you have thoughts? Is that the one? Yeah, the thoughts of like the

603
01:44:39.320 --> 01:44:45.809
Rachael Lammey: on the archiving of the final rendered static page with images, for example.

604
01:44:45.960 --> 01:44:50.499
Esha Datta: that's a really good question. I haven't really thought about it. But

605
01:44:50.770 --> 01:45:04.180
Esha Datta: yeah, that is, that is super interesting. And also, yeah, we could also talk to Martin Eve about possibly looking into how to preserve this. And so that's a that's a nice tie in into that for sure.

606
01:45:05.860 --> 01:45:15.349
Rachael Lammey: And and then there's a second question about or actually, Martin, I'll let you jump. I've seen you've unmuted. Let's let's take a bit more time on that question.

607
01:45:15.650 --> 01:45:17.319
Martin Eve: I was just gonna

608
01:45:17.580 --> 01:45:44.900
Martin Eve: draw attention actually to Martin Fenner's work that was mentioned earlier today, I think, in a different session. This been looking into the preservation of logs and static sites. So there's already some experimentation around the preservation function here. But you're right. We've we've got an ideal point. Now, if we're signing up a dui to these items to think about how we might get them into an archive, so that we know that the stuff is preserved at that point.

609
01:45:44.950 --> 01:45:46.270
Martin Eve: because obviously, the

610
01:45:46.410 --> 01:45:56.059
Martin Eve: if. If we just open the floodgates and say everyone can have a dui for this content. But then, unaware that there's that preservation responsibility, then we're in quite a difficult position.

611
01:46:01.780 --> 01:46:06.269
Rachael Lammey: And then there's another question. Aisha,

612
01:46:06.410 --> 01:46:09.939
Rachael Lammey: how does this tool handle? Multiple resolution?

613
01:46:11.110 --> 01:46:20.790
Esha Datta: Yeah, again, a very good question. Currently, it's still very much an active development. So we should definitely talk more about all of those types of use cases.

614
01:46:28.720 --> 01:46:35.609
Rachael Lammey: Great. I will give people a few more minutes. I

615
01:46:35.640 --> 01:46:57.730
Rachael Lammey: the next session will start on the R, and I'll give people a few more minutes in case there are any final questions. But I don't miss wanna miss the opportunity to say, thanks to all of our fantastic presenters, and also for for your really good questions. I hope this gives a flavor of the

616
01:46:57.920 --> 01:47:09.600
Rachael Lammey: the variety and even just a small subset of the things that we're working about and thinking up about across the various teams.

617
01:47:10.270 --> 01:47:26.100
Rachael Lammey: Brace has just posted the link to the next session, which is a discussion among crossrest staff and other members of our community on what we still need to build a research nexus. So I hope we hope that you'll that you'll also join us for that.

618
01:47:29.350 --> 01:47:32.240
Rachael Lammey: Yeah, if you want to take a few minutes.

619
01:47:32.400 --> 01:47:41.209
Rachael Lammey: ask any further questions, or go and get a cup of tea, coffee, glass of water? This is your chance. But thank you again.

620
01:48:24.040 --> 01:48:27.569
Rachael Lammey: Okay, I can see people starting to

621
01:48:28.220 --> 01:48:33.129
Rachael Lammey: starting to to head off and take up the opportunity of a

622
01:48:33.960 --> 01:48:57.210
Rachael Lammey: of a coffee again. There are lots of mechanisms by which you can, you know, by which you can get in touch with crossraf our community forums. A great resource for that as well. So this isn't kind of the end of the opportunity to to ask questions and and to find out more information. And obviously we'll we'll follow up by posting the video and a link to the

623
01:48:57.210 --> 01:49:06.150
Rachael Lammey: the slides in the in the coming days. Once we've pulled everything together. So I'm going to leave it there. Thanks again, and we hope to see you in the next session.