Hello, everybody.
I think when I first came to this conference,
the first thing that I was thinking is
that I would get an answer for it,
how to add value to all repositories,
your repositories, I guess.
And one way in which I think that could be
is by destroying the silos in which all repositories live.
Often, the collections that we have in our repositories
are completely not connected to other research
or puts that are somewhere else in the web,
maybe not the platform,
maybe they're not even connected to the researchers
that create them or the grads and fund them.
And today, what I want to share is a way
to remove the silos, which is based on the use
of persistent identifiers and the open services from dataset.
So if there are three things mostly
that I want you to get out of this talk,
the first one is what are these connections
and what are the types of these connections you can get,
how can you access them, and why is this a better approach?
My name is Christian Garza.
I'm an application developer for Datasite.
Datasite is one of the global providers
of persistent identifiers for research data
and other research outputs.
Our mission is actually to identify knowledge
and connect research.
And the connections that I'm talking about
are the connections that your resources
and your repositories have
with other research outputs on the web.
And precisely those ones that they have
with research outputs that have persistent identifiers.
That could be a dataset, another researcher,
and another research article.
For example, could be a relationship at the same time
with same identifier, for example,
a research article citing another research article
or a researcher actually linking to a dataset.
The important thing here is that the metadata
in these persistent identifiers provides a mechanism
to actually unambiguously link
these two types of research outputs.
And these connections, these links,
have been done every day by researchers
when they deposit their metadata in a repository
or when they cite an article or a dataset
in the reference sections of their article.
And we have been collecting those ones
for the last 10 years, so we have many of those links.
And those are the links and the connections
that I think can help repositories
to break out of due silos.
So one can model all these connections in a graph
in which the resources identified
with these persistent identifiers
are the nodes in the graph
and the connections are the edges of that graph.
By using that model, you can actually
make very powerful questions to that graph.
You can ask, for example, what are all the citations
that the publications of a specific researcher have?
And we call this the PID graph.
And this is where all those connections are living.
So that's the dataset that we have.
And now the question is how to access that dataset.
And the answer for that is the Dataside GraphQL API.
And Dataside GraphQL API is the combinations
of dataset services and GraphQL technology.
GraphQL is a syntax to query data in a graph.
And it already has been in development
by a community-driven endeavor,
has been already adopted by most of the major players
in the technology sector.
In the case of the Dataside GraphQL API,
this works pretty different to the REST APIs
that probably you're familiar with.
But it's a very compelling approach
to actually query all those connections in the graph,
especially because it takes advantage
of the persistent identifiers
because the GraphQL technology needs globally unique IDs.
And also it takes advantage of all the existing services.
So even when this is a new service,
you can be sure that in the background,
we are using all the production-grade services
that you are used to using,
like Orchid IPs and APIs,
and course of APIs and Dataside APIs.
So I want to give you a sense of how this works
with a very, very generic example.
When you make a query to a GraphQL API,
your query looks like a JSON snippet,
so something like this.
And your role is to start with a resource.
And for this example, the resource is me,
and I'm going to query for my name and my Twitter account.
That's the only thing that I want.
And the response will look like this.
And what I want you to notice about that
is only three things.
One is that I got the information,
only the information that I requested,
nothing else and nothing more.
There is, the shape of the response
is the same shape of the query,
so it's easy to understand for everybody
what you are requesting for, what you're obtaining.
And the last one is that there is only one endpoint
for this API.
I don't show the input here, but there's only one input,
and that should help with documenting
and not giving knowledge about the API.
Now, this is a very generic example,
so it's not very relevant.
So I'm going to show a small demo on that.
Put something that I think is closer for repositories.
When you start, when you call resources
in the Datasys GraphQL API,
you really have to start with a resource
that could be a dataset, a researcher,
but I'm going to start with a repository.
But I'm going to cheat very badly
because we don't have a PID for a repository,
but if your repository is a dataset client,
I can look for that.
So I'm going to query for a big repository.
Everybody knows these guys.
So I'm going to query for a fixture,
and I'm going to ask just two things.
I'm going to query their name and the description,
nothing else.
So when I run the query, I obtain that,
and I'm pretty sure you can notice the same three things.
The shape, the response is the same as the query.
There's only one single endpoint,
and I only got the information requested.
But this is a very boring example.
There's fixtures, so there might be many publications.
You can request those ones.
We can request the total number of publications
that fixture has.
Those publications have titles,
so we can request those ones.
And many of those ones will have IDs,
so we can ask for those IDs.
And when you run that one,
you will get the total number of accounts
for that's all the publications,
the titles of those publications,
and the IDs of those ones.
In this case, they are the OIs as well.
Once you do that, well, you can say,
well, those publications have creators.
There's someone that make them.
So you can say, well, give me the creators,
give me the names, and they might have orchid IDs.
So give me the orchid IDs as well.
And when you query that,
you get the same information you had before,
plus the creators.
There will be some authors that don't have orchids,
whatever is the adoption of that.
But I think you would tell,
well, I mean, you cannot break in any silo.
I mean, if I'm fixture, I know all that information.
So citations is something
that probably doesn't live in fixture.
So it's something that we also query.
And the related identifier world,
well, no, in the PID world,
the number, name for citations is a strange name.
It's called related identifier.
So we can query for those ones.
And get all the citations of each article
that is in fixture.
Well, those ones that have citations,
there are some that don't have.
There are some that have many, a few.
So you get those ones.
So by now, I hope I can give you an idea
or take the leap of what is next,
because for example, those creators of those publications
might have data sets that they use
for creating those publications.
So we can query for those data sets as well
and get there like this.
And the other thing is that those citations,
that themselves publications.
So we can get probably their titles,
also their creators, and maybe their citations as well.
So in that way, that will be that you get the citations,
of the citations of all the publications in your repository.
So that's a very fascinating query actually.
So if I run that, I should get all those relationships.
But I'm not going to run it.
Sorry about that.
The reason I'm not going to run it is because
the data set GraphQL API is a pre-release at the moment.
So it's not totally complete.
There's some functionality missing.
There might be bugs.
We are still working in support many use cases
for those queries.
But they will be supported in the near future.
The most important thing at the moment is your feedback.
So we invite you to use it, to come and play with it.
Don't worry, you are not a data set client.
If you have an RE3 data ID, your repository is there.
We will implement a functionality to make ways for that.
So you are in RE3 data and your repository uses
persistent identifiers.
You can do the exact same query that you just made.
We have tons of documentations about the GraphQL API
and we are working the Freya project
in many other use cases.
This is only one use case, but we have been working
in many other use cases
for the queries that you can make here.
We are very confident in the approach.
That this approach is in the PID graph
and the data set GraphQL API to actually break the silos
in your repositories because it's a machine
actual approach.
We get data from many parties, not only data sets effort.
So we value to go to the PID forum.
This is a forum for PID things
and ask any questions about these two things.
And yeah, that's it.
So we have time for questions.
Let's give an applause.
Thank you.