Okay, so I want to start, and I submitted a DevTrack presentation and the expectation
that I'd have like 25 minutes, maybe half an hour, and I ended up with about 12 minutes.
So a lot has been cut, but I'm around, find me during coffee breaks, and if I spend too
long on a slide, I'm just going to stop where I'm talking and keep moving.
But I want to start with the reason this is important.
So if anybody that currently uses the Romeo API in any of their systems, at the end of
this year, we're turning it off.
So whatever relies on it will break.
And so what we would like you to do is start using the new API.
And if anybody wants to talk to me more about that, come and find me a copy.
So we have just released a developer preview.
I do apologize.
This is the new standard GIS slide template.
I love it.
I have about a third of a slide picture.
But I'm on brand.
So we have the developer preview launched, and we're working towards a full beta launch
later this summer.
I only just didn't get it out in time for the conference.
And I want to start this kind of this presentation with a little bit of a walk through the user
interface because it will help talk about what the user experience and how things look
from the front end and how that matches with the data repository.
So I'm going to go out on a limb here and ask if anybody has a favorite journal.
How do you spell that?
Giga science.
All right.
So we have it's kind of gone down to the screen so small, it's kind of gone down to something
sort of approaching a phone view on it.
But we have a smattering of metadata for the publication, and then we present the policy
information, actually, if I can, there we go, that's better.
We present the policy information as per document what open access routes are available for
this document.
And you can see that we have slightly different versions.
And there are two options for the published version, and this second one has a set of
prerequisites so it's only available if you are funded by one of these funders.
So the, if I can go back, the example I like is cancer, somehow whenever working with repositories
cancer has become my go to search because everybody is interested in it so there's always
lots of stuff.
And again, you can see we've got these three versions.
So the submitted version, you can put in these places straight away, the accepted version,
we have a 12 month embargo on, and the published version, there's no embargo, but you do have
to pay a fee.
We don't actually record what the fee is, but if you have to pay extra to make it open
access, that fact is recorded.
So back to the presentation.
Okay, so the data model.
Publisher policies, they're not really, they don't really exist.
They only exist when seen through the lens of a publication.
So a publication can have any number of publishers.
A publisher policy is a set of things that you are allowed to do.
And each thing you're allowed to do is represented by a route.
A route is how you can make this thing open access.
And so a policy can have any number of routes and a publication can have any number of publishers
as long as, sorry, a publication can have any number of publisher policies as long as
they all share the same publisher.
So what does that look like?
First let's talk about permitted route briefly.
So this is a permitted route and it stores the properties that we are interested in in
terms of open access that define a way something got to be open access, if that makes sense.
So are there any prerequisites?
Is this dependent on being in a certain country or having a certain funder or it being a certain
year?
Which versions of the document?
The concept of versions that submitted the accepted published version runs through this
quite a lot.
Where it can be, is it your institutional repository?
Is it just the journals open access version on their site?
Is there an embargo?
What are the licenses?
Are there fees?
And are there any conditions?
Unfortunately, conditions, everything else is sets of values or integers, whereas conditions
are often free text still, but we're working at trying to reduce the amount of free text
in that field too.
And so cancer looks like this.
So blue is the journal, pink are the publishers, and yellow are the policy and permitted OAs.
So we have two policies attached to this, each of which has two routes and has actually
no difference semantically for what the user will see on the screen if it was implemented
like this inside the system.
This is a decision of the editor who sat at the back of the room, my colleague Jane Anders.
And there are situations where doing this is better and there are other situations where
doing this is better in terms of making these objects easy for us to manage.
So let's talk very briefly again about the API.
And I think I sometimes get a little bit defensive about the API because I've, as every developer
has this tension between building the system they want to build and shipping something.
And we have a very agile philosophy to this, is what we tried to do is we tried to build
a minimum viable product.
So we've put out there something that you can use, but it's also something that we will
continue improving, continue building on.
And this is one of the messages I want to get across here.
Please do tell me what you want.
Please do get in contact if you have any feature requests or if you find any shortcomings or
if you can identify any way that we can make better.
But let's see if we can make it work.
So first of all, where is the API?
So if you look at help, we've got these frequently asked questions.
One of which is, is there an API?
Yes, there is.
And we also have documentation.
And so this goes through what the parameters are.
Unfortunately we don't yet have data model documentation or detailed documentation about
the JSON structures that are returned.
But we do have documentation about how you can get it.
And so we have this URL here.
I need my API key.
So you do need an account to have an API key.
But it's okay.
It's not protecting anything.
Everything you can get with your API key is already publicly visible through the human
interfaces.
At the moment it's not really securing anything, it's just making sure that everybody has
an account and that if we do start to have problems and need to introduce things like
rate limiting, it's really very easy to do that.
So let's just copy this.
So actually, I'm just going to, because I'm running out of time, I'm just going to kind
of cheat and paste what's in my history in there.
And so this is, let me just check what I've got set in there.
So I'm asking for publications.
Because the important thing to realize here is this isn't really the Romeo API.
This is the Sherpa API.
We've gone from running kind of three or four siloed services to having one dataset at the
back end and then some different views on them with slightly different contexts.
So when you look at OpenDoor, you're looking at the same database, the same platform as
you are when you're looking from Romeo, the branding is different and the object type
you are requesting is different, but everything else is just one API.
So if I change publication to funder, I'd be getting data from our Juliet service.
I'm asking for it as JSON, and there's no filter on here.
So we have, let's just see.
So this is a journal.
It's called Fauna of China, and it happens to have our internal ID of one.
Now you might not be interested in getting a page of 100 journals.
You might.
You can use offset and limit to page through data to download them all, but if you want
to get cancer, hang on, that came out wrong, if what you need to do is you need to put
a filter on.
So can people see what that says?
Filters are basically JSON arrays, and each array you can put up to three filters in,
and each filter is an array containing a field name, an operator, and a value.
And so what I'm asking for is for the publication that matches title equals cancer.
And so if I do that, I get back cancer.
It comes out kind of, and the order is undefined in a, so, hang on.
So I will show you that this is cancer.
Just give me a second.
There you go, title cancer.
And then you can see the publisher policy objects down here, which talk about, you know, this
is for the submitted version, these are the places it can be put, that's the named ones
because named repository is set here, what the conditions are, whether there's an additional
LAP.
So like I could have done like an hours presentation on that.
Please I'm around.
Come and talk to me.
Ask me any questions.
And actually we have a little bit of time for questions now, yes?
No.
Any questions?