forked from D-Net/openaire-graph-docs
Compare commits
9 Commits
main
...
aggregatio
| Author | SHA1 | Date |
|---|---|---|
Sandro La Bruzzo
|
cbfd719b77 | |
|
Sandro La Bruzzo
|
fe15c483da | |
 Claudio Atzori
|
f0cbce56c5 | |
|
Claudio Atzori
|
629fe0d51a | |
|
Claudio Atzori
|
2bd8fa9956 | |
|
Claudio Atzori
|
a5b100520c | |
|
Claudio Atzori
|
ec3d23ce88 | |
|
Claudio Atzori
|
797f7c21f7 | |
|
Claudio Atzori
|
616f6482f1 |
|
|
@ -18,3 +18,5 @@
|
|||
npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
|
||||
.idea/
|
||||
|
|
@ -16,7 +16,7 @@ For example, the organizations supporting a research infrastructure fall in the
|
|||
### id
|
||||
_Type: String • Cardinality: ONE_
|
||||
|
||||
The OpenAIRE id for the community/research infrastructure, created according to the [OpenAIRE entity identifier and PID mapping policy](entity-identifiers).
|
||||
The OpenAIRE id for the community/research infrastructure, created according to the [OpenAIRE entity identifier and PID mapping policy](../pids-and-identifiers).
|
||||
|
||||
```json
|
||||
"id": "00|context_____::5b7f9fa40bdc12072249204cedfa7808"
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ For example, a metadata record about a project carries information for the creat
|
|||
### id
|
||||
_Type: String • Cardinality: ONE_
|
||||
|
||||
The OpenAIRE id of the data source, created according to the [OpenAIRE entity identifier and PID mapping policy](entity-identifiers).
|
||||
The OpenAIRE id of the data source, created according to the [OpenAIRE entity identifier and PID mapping policy](../pids-and-identifiers).
|
||||
|
||||
```json
|
||||
"id": "10|issn___print::22c514d022b199c346e7f29ca06efc95"
|
||||
|
|
|
|||
|
|
@ -1,39 +0,0 @@
|
|||
---
|
||||
sidebar_position: 8
|
||||
---
|
||||
|
||||
# OpenAIRE entity identifier and PID mapping policy
|
||||
|
||||
OpenAIRE assigns internal identifiers for each object it collects.
|
||||
By default, the internal identifier is generated as `sourcePrefix::md5(localId)` where:
|
||||
|
||||
* `sourcePrefix` is a namespace prefix of 12 chars assigned to the data source at registration time
|
||||
* `localid` is the identifier assigned to the object by the data source
|
||||
|
||||
After years of operation, we can say that:
|
||||
|
||||
* `localId` are unstable
|
||||
* objects can disappear from sources
|
||||
* PIDs provided by sources that are not PID agencies (authoritative sources for a specific type of PID) are often wrong (e.g. pre-print with the DOI of the published version, DOIs with typos)
|
||||
|
||||
Therefore, when the record is collected from an authoritative source:
|
||||
|
||||
* the identity of the record is forged using the PID, like `pidTypePrefix::md5(lowercase(doi))`
|
||||
* the PID is added in a `pid` element of the data model
|
||||
|
||||
When the record is collected from a source which is not authoritative for any type of PID:
|
||||
* the identity of the record is forged as usual using the local identifier
|
||||
* the PID, if available, is added as `alternateIdentifier`
|
||||
|
||||
Currently, the following data sources are used as "PID authorities":
|
||||
|
||||
| PID Type | Prefix (12 chars) | Authority |
|
||||
|---------- |------------------- |--------------------------------------- |
|
||||
| doi | `doi_________` | Crossref, Datacite, Zenodo |
|
||||
| pmc | `pmc_________` | Europe PubMed Central, PubMed Central |
|
||||
| pmid | `pmid________` | Europe PubMed Central, PubMed Central |
|
||||
| arXiv | `arXiv_______` | arXiv.org e-Print Archive |
|
||||
| handle | `handle______` | any repository |
|
||||
|
||||
OpenAIRE also perform duplicate identification (see the [dedicated section for details](../../data-provision/deduplication/)).
|
||||
All duplicates are **merged** together in a **representative record** which must be assigned a dedicated OpenAIRE identifier (i.e. it cannot have the identifier of one of the aggregated record).
|
||||
|
|
@ -14,7 +14,7 @@ Organizations include companies, research centers or institutions involved as pr
|
|||
### id
|
||||
_Type: String • Cardinality: ONE_
|
||||
|
||||
The OpenAIRE id for the organization, created according to the [OpenAIRE entity identifier and PID mapping policy](entity-identifiers).
|
||||
The OpenAIRE id for the organization, created according to the [OpenAIRE entity identifier and PID mapping policy](../pids-and-identifiers).
|
||||
|
||||
```json
|
||||
"id": "20|openorgs____::b84450f9864182c67b8611b5593f4250"
|
||||
|
|
|
|||
|
|
@ -560,7 +560,7 @@ The measures computed for this instance (e.g. those provided by [BIP! Finder](ht
|
|||
### pid
|
||||
_Type: [ResultPid](#resultpid) • Cardinality: MANY_
|
||||
|
||||
The set of persistent identifiers associated to this instance that have been collected from an authority for the pid type (i.e. Crossref/Datacite for doi). See the [OpenAIRE entity identifier and PID mapping policy](entity-identifiers) for more information.
|
||||
The set of persistent identifiers associated to this instance that have been collected from an authority for the pid type (i.e. Crossref/Datacite for doi). See the [OpenAIRE entity identifier and PID mapping policy](../pids-and-identifiers) for more information.
|
||||
|
||||
```json
|
||||
"pid": [
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Of crucial interest to OpenAIRE is also the identification of the funders (e.g.
|
|||
### id
|
||||
_Type: String • Cardinality: ONE_
|
||||
|
||||
Main entity identifier, created according to the [OpenAIRE entity identifier and PID mapping policy](entity-identifiers).
|
||||
Main entity identifier, created according to the [OpenAIRE entity identifier and PID mapping policy](../pids-and-identifiers).
|
||||
|
||||
```json
|
||||
"id": "40|corda__h2020::70ea22400fd890c5033cb31642c4ae68"
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Moreover, there are the following sub-types of a `Result`, that inherit all its
|
|||
### id
|
||||
_Type: String • Cardinality: ONE_
|
||||
|
||||
Main entity identifier, created according to the [OpenAIRE entity identifier and PID mapping policy](entity-identifiers).
|
||||
Main entity identifier, created according to the [OpenAIRE entity identifier and PID mapping policy](../pids-and-identifiers).
|
||||
|
||||
```json
|
||||
"id": "50|doi_dedup___::80f29c8c8ba18c46c88a285b7e739dc3"
|
||||
|
|
@ -258,7 +258,7 @@ Timestamp of last update of the record in OpenAIRE.
|
|||
### pid
|
||||
_Type: [ResultPid](other#resultpid) • Cardinality: MANY_
|
||||
|
||||
Persistent identifiers of the result. See also the [OpenAIRE entity identifier and PID mapping policy](entity-identifiers) to learn more.
|
||||
Persistent identifiers of the result. See also the [OpenAIRE entity identifier and PID mapping policy](../pids-and-identifiers) to learn more.
|
||||
|
||||
```json
|
||||
"pid": [
|
||||
|
|
|
|||
|
|
@ -0,0 +1,74 @@
|
|||
# PIDs and identifiers
|
||||
|
||||
One of the challenges towards the stability of the contents in the OpenAIRE Research Graph consists of making its identifiers and records stable over time.
|
||||
The barriers to this scenario are many, as the Graph keeps a map of data sources that is subject to constant variations: records in repositories vary in content,
|
||||
original IDs, and PIDs, may disappear or reappear, and the same holds for the repository or the metadata collection it exposes.
|
||||
Not only, but the mappings applied to the original contents may also change and improve over time to catch up with the changes in the input records.
|
||||
|
||||
## PID Authorities
|
||||
|
||||
One of the fronts regards the attribution of the identity to the objects populating the graph. The basic idea is to build the identifiers of the objects in the graph from the PIDs available in some authoritative sources while considering all the other sources as by definition “unstable”. Examples of authoritative sources are Crossref and DataCite. Examples of non-authoritative ones are institutional repositories, aggregators, etc. PIDs from the authoritative sources would form the stable OpenAIRE ID skeleton of the Graph, precisely because they are immutable by construction.
|
||||
|
||||
Such a policy defines a list of data sources that are considered authoritative for a specific type of PID they provide, whose effect is twofold:
|
||||
* OpenAIRE IDs depend on persistent IDs when they are provided by the authority responsible to create them;
|
||||
* PIDs are included in the graph according to a tight criterion: the PID Types declared in the table below are considered to be mapped as PIDs only when they are collected from the relative PID authority data source.
|
||||
|
||||
| *PID Type* | *Authority* |
|
||||
|------------|-----------------------------------------------------------------------------------------------------|
|
||||
| doi | [Crossref](https://www.crossref.org), [Datacite](https://datacite.org) |
|
||||
| pmc, pmid | [Europe PubMed Central](https://europepmc.org/), [PubMed Central](https://www.ncbi.nlm.nih.gov/pmc) |
|
||||
| arXiv | [arXiv.org e-Print Archive](https://arxiv.org/) |
|
||||
|
||||
There is an exception though: Handle(s) are minted by several repositories; as listing them all would not be a viable option, to avoid losing them as PIDs, Handles bypass the PID authority filtering rule.
|
||||
In all other cases, PIDs are be included in the graph as alternate Identifiers.
|
||||
|
||||
## Delegated authorities
|
||||
|
||||
When a record is aggregated from multiple sources considered authoritative for minting specific PIDs, different mappings could be applied to them and, depending on the case,
|
||||
this could result in inconsistencies in the attribution of the field values.
|
||||
To overcome the issue, the intuition is to include such records only once in the graph. To do so, the concept of "delegated authorities" defines a list of datasources that
|
||||
assigns PIDs to their scientific products from a given PID minter.
|
||||
|
||||
This "selection" can be performed when the entities in the graph sharing the same identifier are grouped together. The list of the delegated authorities currently includes
|
||||
|
||||
| *Datasource delegated* | *Datasource delegating* | *Pid Type* |
|
||||
|--------------------------------------|----------------------------------|------------|
|
||||
| [Zenodo](https://zenodo.org) | [Datacite](https://datacite.org) | doi |
|
||||
| [RoHub](https://reliance.rohub.org/) | [W3ID](https://w3id.org/) | w3id |
|
||||
|
||||
|
||||
## Identifiers in the Graph
|
||||
|
||||
OpenAIRE assigns internal identifiers for each object it collects.
|
||||
By default, the internal identifier is generated as `sourcePrefix::md5(localId)` where:
|
||||
|
||||
* `sourcePrefix` is a namespace prefix of 12 chars assigned to the data source at registration time
|
||||
* `localid` is the identifier assigned to the object by the data source
|
||||
|
||||
After years of operation, we can say that:
|
||||
|
||||
* `localId` are generally unstable
|
||||
* objects can disappear from sources
|
||||
* PIDs provided by sources that are not PID agencies (authoritative sources for a specific type of PID) are often wrong (e.g. pre-print with the DOI of the published version, DOIs with typos)
|
||||
|
||||
Therefore, when the record is collected from an authoritative source:
|
||||
|
||||
* the identity of the record is forged using the PID, like `pidTypePrefix::md5(lowercase(doi))`
|
||||
* the PID is added in a `pid` element of the data model
|
||||
|
||||
When the record is collected from a source which is not authoritative for any type of PID:
|
||||
* the identity of the record is forged as usual using the local identifier
|
||||
* the PID, if available, is added as `alternateIdentifier`
|
||||
|
||||
Currently, the following data sources are used as "PID authorities":
|
||||
|
||||
| PID Type | Prefix (12 chars) | Authority |
|
||||
|-----------|------------------------|-----------------------------------------|
|
||||
| doi | `doi_________` | Crossref, Datacite, Zenodo |
|
||||
| pmc | `pmc_________` | Europe PubMed Central, PubMed Central |
|
||||
| pmid | `pmid________` | Europe PubMed Central, PubMed Central |
|
||||
| arXiv | `arXiv_______` | arXiv.org e-Print Archive |
|
||||
| handle | `handle______` | any repository |
|
||||
|
||||
OpenAIRE also perform duplicate identification (see the [dedicated section for details](../../data-provision/deduplication/)).
|
||||
All duplicates are **merged** together in a **representative record** which must be assigned a dedicated OpenAIRE identifier (i.e. it cannot have the identifier of one of the aggregated record).
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
---
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
||||
# Aggregation
|
||||
|
||||
OpenAIRE collects metadata records from a variety of content providers as described in the [aggregation and content provision workflows](https://www.openaire.eu/aggregation-and-content-provision-workflows).
|
||||
|
||||
OpenAIRE aggregates metadata records describing objects of the research life-cycle from content providers compliant to the [OpenAIRE guidelines](https://guidelines.openaire.eu/) and from entity registries (i.e. data sources offering authoritative lists of entities, like OpenDOAR, re3data, DOAJ, and funder databases). After collection, metadata are transformed according to the OpenAIRE internal metadata model, which is used to generate the final OpenAIRE Research Graph that you can access from the OpenAIRE portal and the APIs.
|
||||
|
||||
The transformation process includes the application of cleaning functions whose goal is to ensure that values are harmonised according to a common format (e.g. dates as YYYY-MM-dd) and, whenever applicable, to a common controlled vocabulary. The controlled vocabularies used for cleansing are accessible at http://api.openaire.eu/vocabularies. Each vocabulary features a set of controlled terms, each with one code, one label, and a set of synonyms. If a synonym is found as field value, the value is updated with the corresponding term. Also, the OpenAIRE Research Graph is extended with other relevant scholarly communication sources that are too big to be integrated via the “normal” aggregation mechanism: DOIBoost (which merges Crossref, ORCID, Microsoft Academic Graph, and Unpaywall), and ScholeXplorer, one of the Scholix hubs offering a large set of links between research literature and data.
|
||||
|
||||
|
||||
<p align="center">
|
||||
<img loading="lazy" alt="Aggregation" src="/img/docs/aggregation.png" width="65%" className="img_node_modules-@docusaurus-theme-classic-lib-theme-MDXComponents-Img-styles-module"/>
|
||||
</p>
|
||||
|
|
@ -0,0 +1,56 @@
|
|||
---
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
||||
# Aggregation
|
||||
|
||||
OpenAIRE materializes an open, participatory research graph (the OpenAIRE Research graph) where products of the research life-cycle (e.g. scientific literature, research data, project, software) are semantically linked to each other and carry information about their access rights (i.e. if they are Open Access, Restricted, Embargoed, or Closed) and the sources from which they have been collected and where they are hosted. The OpenAIRE research graph is materialised via a set of autonomic, orchestrated workflows operating in a regimen of continuous data aggregation and integration. [1]
|
||||
|
||||
## What does OpenAIRE collect?
|
||||
|
||||
OpenAIRE aggregates metadata records describing objects of the research life-cycle from content providers compliant to the [OpenAIRE guidelines](https://guidelines.openaire.eu/) and from entity registries (i.e. data sources offering authoritative lists of entities, like [OpenDOAR](https://v2.sherpa.ac.uk/opendoar/), [re3data](https://www.re3data.org/), [DOAJ](https://doaj.org/), and various funder databases). After collection, metadata are transformed according to the OpenAIRE internal metadata model, which is used to generate the final OpenAIRE Research Graph, accessible from the [OpenAIRE EXPLORE portal](https://explore.openaire.eu) and the [APIs](https://graph.openaire.eu/develop/).
|
||||
|
||||
The transformation process includes the application of cleaning functions whose goal is to ensure that values are harmonised according to a common format (e.g. dates as YYYY-MM-dd) and, whenever applicable, to a common controlled vocabulary. The controlled vocabularies used for cleansing are accessible at http://api.openaire.eu/vocabularies. Each vocabulary features a set of controlled terms, each with one code, one label, and a set of synonyms. If a synonym is found as field value, the value is updated with the corresponding term.
|
||||
Also, the OpenAIRE Research Graph is extended with other relevant scholarly communication sources that do not follow the OpenAIRE Guidelines and/or are too large to be integrated via the “normal” aggregation mechanism: DOIBoost (which merges Crossref, ORCID, Microsoft Academic Graph, and Unpaywall).
|
||||
|
||||
<p align="center">
|
||||
<img loading="lazy" alt="Aggregation" src="/img/docs/aggregation.png" width="65%" className="img_node_modules-@docusaurus-theme-classic-lib-theme-MDXComponents-Img-styles-module"/>
|
||||
</p>
|
||||
|
||||
The OpenAIRE aggregation system collects information about objects of the research life-cycle compliant to the [OpenAIRE acquisition policy](https://www.openaire.eu/content-aquisition-policy1) from [different types of data sources](https://explore.openaire.eu/search/find/dataproviders):
|
||||
|
||||
1. Scientific literature metadata and full-texts from institutional and thematic repositories, CRIS (Common Research Information Systems), Open Access journals and publishers;
|
||||
2. Dataset metadata from data repositories and data journals;
|
||||
3. Scientific literature, data and software metadata from Zenodo;
|
||||
4. Metadata about data sources, organizations, projects, and funding programs from entity registries, i.e. authoritative sources such as CORDA and other funder databases for projects, OpenDOAR for publication repositories, re3data for data repositories, DOAJ for Open Access journals;
|
||||
5. Metadata of open source research software from software repositories and SoftwareHeritge
|
||||
6. Metadata about other types of research products, like workflow, protocols, methods, research packages
|
||||
|
||||
Relationships between objects are collected from the data sources, but also automatically detected by [inference algorithms](https://www.openaire.eu/blogs/text-mining-services-in-openaire-1) and added by authenticated users, who can insert links between literature, datasets, software and projects via [the “Link” procedure available from the OpenAIRE explore portal](https://explore.openaire.eu/participate/claim).
|
||||
|
||||
## What kind of data sources are in OpenAIRE?
|
||||
|
||||
Objects and relationships in the OpenAIRE Research Graph are extracted from information packages, i.e. metadata records, collected from data sources of the following kinds:
|
||||
|
||||
- *Institutional or thematic repositories*: Information systems where scientists upload the bibliographic metadata and full-texts of their articles, due to obligations from their organization or due to community practices (e.g. ArXiv, Europe PMC);
|
||||
- *Open Access Publishers and journals*: Information system of open access publishers or relative journals, which offer bibliographic metadata and PDFs of their published articles;
|
||||
- *Data archives*: Information systems where scientists deposit descriptive metadata and files about their research data (also known as scientific data, datasets, etc.).;
|
||||
- *Hybrid repositories/archives*: information systems where scientists deposit metadata and file of any kind of scientific products, incuding scientific literature, research data and research software (e.g. Zenodo)
|
||||
- *Aggregator services*: Information systems that collect descriptive metadata about publications or datasets from multiple sources in order to enable cross-data source discovery of given research products. Examples are DataCite, BASE, DOAJ;
|
||||
- *Entity Registries*: Information systems created with the intent of maintaining authoritative registries of given entities in the scholarly communication, such as OpenDOAR for the institutional repositories, re3data for the data repositories, CORDA and other funder databases for projects and funding information;
|
||||
- *CRIS*: Information systems adopted by research and academic organizations to keep track of their research administration records and relative results; examples of CRIS content are articles or datasets funded by projects, their principal investigators, facilities acquired thanks to funding, etc..
|
||||
- *Research Graphs*: services that maintain an information space of (possibly interlinked) scholalrly communication objects. Examples are CrossRef, ScholeXplorer and OpenAIRE itself.
|
||||
|
||||
## How does OpenAIRE collect metadata records?
|
||||
|
||||
OpenAIRE collects metadata records describing objects of the research life-cycle from content providers compliant to the OpenAIRE guidelines and from entity registries (i.e. data sources offering authoritative lists of entities, like OpenDOAR, re3data, DOAJ, and funder databases).
|
||||
|
||||
The OpenAIRE aggregator collects metadata records in the majority of cases via [OAI-PMH](https://www.openarchives.org/pmh/), but also supports other standard exchange protocols like FTP(S), SFTP, and some RESTful API.
|
||||
|
||||
For additional details about the aggregation workflows, please refer to [2].
|
||||
|
||||
## References
|
||||
|
||||
[1] Manghi P. et al. (2014) "The D-NET software toolkit: A framework for the realization, maintenance, and operation of aggregative infrastructures", Program, Vol. 48 Issue: 4, pp.322-354, [10.1108/PROG-08-2013-0045](https://doi.org/10.1108/PROG-08-2013-0045)
|
||||
|
||||
[2] Atzori, Claudio, Bardi, Alessia, Manghi, Paolo, & Mannocci, Andrea. (2017). The OpenAIRE workflows for data management. Zenodo. [10.5281/zenodo.996006](http://doi.org/10.5281/zenodo.996006)
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
# Datacite
|
||||
This section describes the aggregation workflow of Datacite and the mapping implemented for it.
|
||||
|
||||
## Datacite datasource
|
||||
[Datacite](https://datacite.org/index.html) is a leading global non-profit organisation that provides persistent identifiers (DOIs) for research data and other research outputs.
|
||||
|
||||
## Datacite API
|
||||
The [DataCite REST API](https://support.datacite.org/docs/api) allows users to retrieve, query, and browse DataCite DOI metadata records. In particular, it exposes a method for incremental harvesting new datacite records.
|
||||
|
||||
```
|
||||
https://api.datacite.org/dois?page[cursor]=$CURSOR&page[size]=$NUMBER_OF_ITEM_PER_PAGE&query=updated:[$FROM_DATE_TIMESAMP TO $TO_DATE_TIMESAMP]
|
||||
```
|
||||
|
||||
On this API Request, we introduce some variables:
|
||||
- **CURSOR**: The value of the cursor to iterate the pages
|
||||
- **NUMBER_OF_ITEM_PER_PAGE**: (max 1000) defines how many records we can download for each page.
|
||||
- **FROM_DATE_TIMESAMP, TO_DATE_TIMESAMP** interval timestamp of the updated record
|
||||
|
||||
|
||||
Each record contains two pieces of information needed for incremental harvesting:
|
||||
- **isActive**: tells if the record is deleted (`isActive:false`)
|
||||
- **updated**: timestamp of last update
|
||||
|
||||
|
||||
## Collection Workflow
|
||||
|
||||
The collection workflow is responsible for aggregating new datacite records. Each record is stored on a table called Native Datacite Store with the following schema:
|
||||
- **DOI**: The DOI PID of the datacite record (It is a primary key)
|
||||
- **update_timestamp**: the last update date timestamp
|
||||
- **json**: the native record JSON
|
||||
|
||||
During the collection workflow, we identify the most updated record date, and the collection phase downloads all new datacite records and update the existing one through the API using this date as **FROM_DATE_TIMESAMP** variable.
|
||||
|
||||
|
||||
## Datacite Mapping
|
||||
The table below describes the mapping from the XML baseline records to the OpenAIRE Graph dump format.
|
||||
|
||||
|
||||
| OpenAIRE Result field path | Datacite record JSON path | # Notes |
|
||||
|------------------------------------|-------------------------------|-------------------|
|
||||
| `id` | `\attributes\doi`|the identifier will be created by folloing the openaire PID generation policy |
|
||||
| <ul><li>`instance`</li> <li>`instance.type`</li></ul> | <ul><li>`\attributes\types\resourceType`</li> <li> `\attributes\types\resourceTypeGeneral` </li> <li>`attributes\types\schemaOrg`</li></ul> | Use the vocabulary **_dnet:publication_resource_** to find a synonym to one of these terms and get the `instance.type`. Using the **_dnet:result_typologies_** vocabulary, we look up the `instance.type` synonym to generate one of the following main entities: <ul><li>`publication`</li> <li>`dataset`</li> <li> `software`</li> <li>`otherresearchproduct`</li></ul> |
|
||||
| `pid` | `\attributes\doi` | `scheme = doi` |
|
||||
| `dateofcollection` | `attributes\updated` | the timestamp is defined in milliseconds we convert to "yyyy-MM-dd'T'HH:mm:ssZ" format |
|
||||
| `author` | `\attributes\creators` | Each creator field will be mapped in the author entity below the subfield|
|
||||
|
||||
|
|
@ -0,0 +1,247 @@
|
|||
# DOIBoost: Crossref, Unpaywall, Microsoft Academic Graph, ORCID
|
||||
|
||||
DOIBoost is a dataset that combines research outputs and links among them from a selection of data sources.
|
||||
It enriches the records available on Crossref with what's available on Unpaywall, Microsoft Academic Graph, ORCID intersecting all those datasets by DOI.
|
||||
As consequence, DOIBoost does not contain any record from MAG, Unpaywall, or ORCID that doesn't provide a DOI available in Crossref.
|
||||
|
||||
The idea behind DOIBoost and its origin can be found in the paper (and related resources) at:
|
||||
|
||||
* La Bruzzo S., Manghi P., Mannocci A. (2019) OpenAIRE's DOIBoost - Boosting CrossRef for Research. In: Manghi P., Candela L., Silvello G. (eds) Digital Libraries: Supporting Open Science. IRCDL 2019. Communications in Computer and Information Science, vol 988. Springer, doi:10.1007/978-3-030-11226-4_11 . Open Access version available at: [10.5281/zenodo.1441071](https://doi.org/10.5281/zenodo.1441071)
|
||||
|
||||
Each Crossref record is enriched with:
|
||||
* ORCID identifiers of authors from ORCID
|
||||
* Open Access instance (with OA color/route and license) from Unpaywall
|
||||
* the following information from MAG:
|
||||
* abstracts
|
||||
* MAG identifiers of authors
|
||||
* affiliation (result - organization) relationships
|
||||
* subjects (MAG FieldsOfStudy)
|
||||
* conference or journal information
|
||||
|
||||
The Open Access status is also set by intersecting the journal information of a record with the journal lists available from DOAJ and the Gold ISSN list.
|
||||
|
||||
## Inputs
|
||||
|
||||
* *Crossref*: dump available to Crossref subscribers via MetadataPlus service, updated once a month.
|
||||
* *Microsoft Academic Graph*: downloaded version on 2021-02-15. We plan to take the latest version in Dec 2021 before MAG will be retired.
|
||||
* *ORCID*: baseline dump obtained in 2020-10-13, regularly updated every week from the [ORCID public API](https://info.orcid.org/documentation/features/public-api).
|
||||
* *Unpaywall*: public database snapshot downloaded in March 2021. Unpaywall updates it twice a year (https://unpaywall.org/products/snapshot)
|
||||
|
||||
The construction of the DOIBoost dataset consists of the following phases:
|
||||
|
||||
## 1. Crossref filtering
|
||||
|
||||
Records in Crossref are ruled out according to the following criteria
|
||||
|
||||
* have blank title, examples:
|
||||
* `10.1093/rheumatology/41.7.837`
|
||||
* `10.1093/qjmed/95.7.430`
|
||||
* `10.1371/journal.pone.0171434.g005`
|
||||
* have one of the following publishers: `"Test accounts"`, `"CrossRef Test Account"`
|
||||
* Examples from https://api.crossref.org/works?query.publisher-name=%22Test%20accounts%22
|
||||
* `10.1007/bf00344543`
|
||||
* `10.1007/bf00186154`
|
||||
* `10.1306/64ed947a-1724-11d7-8645000102c1865d`
|
||||
* have no authors with valid names, where valid means: not blank and different from all strings in this list: `List(",", "none none", "none, none", "none &na;", "(:null)", "test test test", "test test", "test", "&na; &na;")`
|
||||
* Examples for blank authors:
|
||||
* `10.1108/00070709810247807`
|
||||
* `10.1016/s1074-9098(02)00346-5`
|
||||
* `10.1136/heart.88.1.6`
|
||||
* Examples for `"none"` author from https://api.crossref.org/works?query.author=%22none%22
|
||||
* `10.4007/annals.2016.184.3.11`
|
||||
* `10.4007/annals.2012.176.1.6`
|
||||
* `10.2172/6393585`
|
||||
* Examples for `"test"` author from https://api.crossref.org/works?query.author=%22test%22
|
||||
* `10.5116/ijme.54ca.a5ae`
|
||||
* `10.5755/j01.ss.71.2.544`
|
||||
* `10.5755/j01.ee.22.2.319`
|
||||
* have `"Addie Jackson"` as author and `"Elsevier BV"` as publisher (empirically we say they are test records)
|
||||
* Examples from https://api.crossref.org/works?query.author=Addie+Jackson&query.publisher-name=%22Elsevier%20BV%22
|
||||
* `10.2139/ssrn.2082156`
|
||||
* `10.2139/ssrn.2202300`
|
||||
* `10.2139/ssrn.2255657`
|
||||
* have not one of the following values in the field `type` : `"book-section"`, `"book"`, `"book-chapter"`, `"book-part"`, `"book-series"`, `"book-set"`, `"book-track"`, `"edited-book"`, `"reference-book"`, `"monograph"`, `"journal-article"`, `"dissertation"`, `"other"`, `"peer-review"`, `"proceedings"`, `"proceedings-article"`, `"reference-entry"`, `"report"`, `"report-series"`, `"standard"`, `"standard-series"`, `"posted-content"`, `"dataset"`,
|
||||
* Example:
|
||||
* `10.1371/journal.pone.0171434.g005`
|
||||
* `10.7554/elife.21052.049`
|
||||
* `10.1371/journal.pcbi.1005379.s006`
|
||||
|
||||
Records with `type=dataset` are mapped into OpenAIRE results of type dataset. All others are mapped as OpenAIRE results of type publication.
|
||||
|
||||
## 2. Mapping Crossref properties into the OpenAIRE Research Graph
|
||||
|
||||
Properties in OpenAIRE results are set based on the logic described in the following table:
|
||||
|
||||
| OpenAIRE Result field path | Crossref path(s) | Notes |
|
||||
|----------------------------------------|--------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| `id` | `doi` | id in the form `doi_________::md5(doi)` |
|
||||
| `dateofcollection` | `indexed.datetime` | |
|
||||
| `lastupdatetimestamp` | `indexed.timestamp` | |
|
||||
| `type` | `type` | `dataset` if the Crossref type is dataset, `publication` otherwise (based on the filtering logics described above) |
|
||||
| `originalId` | `doi, clinical-trial-number, alternative-id` | |
|
||||
| `pid` | | The scheme tells the type of PID, the value contains the actual value |
|
||||
| `pid.scheme` | | Default value: doi |
|
||||
| `pid.value` | `doi` | The doi is normalised and lower-cased |
|
||||
| `maintitle` | `title` | |
|
||||
| `subtitle` | `subtitle` | |
|
||||
| `author` | `author` | if available the sequence is mapped to rank and the ORCID is also mapped |
|
||||
| `author.name` | `author.given` | |
|
||||
| `author.surname` | `author.family` | |
|
||||
| `author.fullname` | `author.given author.family` | |
|
||||
| `author.rank` | | based on the order, starts from 1 |
|
||||
| `author.pid` | | only if the ORCID is available |
|
||||
| `author.pid.id.scheme` | | Default `'pending_orcid'` (meaning that it is not an id confirmed by ORCID) |
|
||||
| `author.pid.id.value` | `author.ORCID` | |
|
||||
| `author.pid.provenance.provenance` | | Default 'Harvested' |
|
||||
| `author.pid.provenance.trust` | | Default '0.9' |
|
||||
| `description` | `abstract` | |
|
||||
| `subject` | `subject` | with `classid='keywords'`, i.e. no controlled vocabularies for Crossref subjects |
|
||||
| `publicationdate` | `issued.datetime` or, if not available, `created.datetime` | |
|
||||
| `publisher` | `publisher` | |
|
||||
| `source` | `source` | only if the record is not of type `book` |
|
||||
| `source` | concatenation of `container-title.head` + `"ISBN: "` + `ISBN.head` | only if the record is of type `book` |
|
||||
| `container` | | It is set only for publications with information about the journal it was published in. |
|
||||
| `container.name` | `container-title.head` | |
|
||||
| `container.issnOnline` | `issn-type.value` | if `issn-type.type='electronic'` |
|
||||
| `container.issnPrinted` | `issn-type.value` | if `issn-type.type='print'` |
|
||||
| `container.vol` | `volume` | |
|
||||
| `container.sp` | `page` | before `'-'` |
|
||||
| `container.ep` | `page` | after `'-'` |
|
||||
| `instance` | | One instance is created with the DOI URL |
|
||||
| `instance.accessright` | | Values in `instance.accessright.code` and `instance.accessright.label` are set based on license and dateofacceptance:<br/>- `UNKNOWN`: if the license is blank<br/>- `OPEN ACCESS`: if the license is a CC license or an ACS license or an APA license (considered OPEN also by Unpaywall, see [Unpaywall FAQ](https://support.unpaywall.org/support/solutions/articles/44002063718-what-is-an-oa-license-) for details) or if OUP license, but only after 12 months from the publication date<br/>- `EMBARGO`: OUP license, before 12 months from the publication date<br/>- `CLOSED`: if there is a license not covered by the previous cases |
|
||||
| `instance.accessright.code` | | Code from the [COAR vocabulary for access right](http://vocabularies.coar-repositories.org/documentation/access_rights/) |
|
||||
| `instance.accessright.label` | | One of: `OPEN`, `RESTRICTED`, `CLOSED`, `EMBARGO` |
|
||||
| `instance.accessright.scheme` | | Scheme that defines the code and label, i.e. the URL to the [COAR vocabulary for access right](http://vocabularies.coar-repositories.org/documentation/access_rights/) |
|
||||
| `instance.accessright.openAccessRoute` | | only if `instance.accessright.value = 'OPEN ACCESS'`. Default is `hybrid`. The route is fixed in subsequent phases of DOIBoost, namely when intersecting with Unpaywall and patching the hostedby via DOAJ and the Gold-ISSN list. |
|
||||
| `instance.license` | `license.URL ` | If there is a `license.content-version='vor'`, then this is used. Otherwise the first license entry is used. |
|
||||
| `instance.pid` | | The scheme tells the type of PID, the value contains the actual value |
|
||||
| `instance.pid.scheme` | | Default value: `doi` |
|
||||
| `instance.pid.value` | `doi` | The doi is normalised and lower-cased |
|
||||
| `instance.publicationdate` | `issued.datetime` or, if not available, `created.datetime` | |
|
||||
| `instance.refereed` | | set to `peerReviewed` only if `relation.has-review.id` is not empty, `UNKNOWN` otherwise. |
|
||||
| `instance.type` | `subtype` | mapped using the [OpenAIRE vocabulary for result typologies](https://api.openaire.eu/vocabularies/dnet:result_typologies) |
|
||||
| `instance.url` | `doi` | Full URL of the DOI |
|
||||
|
||||
All other fields of the Json schema not mentioned in the table contain empty values.
|
||||
|
||||
All the records from Crossref are related to the datasource with `name=Crossref` and `id=openaire____::081b82f96300b6a6e3d282bad31cb6e2`
|
||||
|
||||
Possible improvements:
|
||||
* map `clinical-trial-number` and `alternative-id` in `alternateIdentifiers`?
|
||||
* Verify if Crossref has a property for `language`, `country`, `container.issnLinking`, `container.iss`, `container.edition`, `container.conferenceplace` and `container.conferencedate`
|
||||
* Different approach to set the `refereed` field and improve its coverage?
|
||||
|
||||
h3. 2 Map Crossref links to projects/funders
|
||||
|
||||
Links to funding available in Crossref are mapped as funding relationships (`result -- isProducedBy --> project`) applying the following mapping:
|
||||
|
||||
| *funder* | *grant code* | *Link to* |
|
||||
|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| DOI: `{10.13039/100010663, 10.13039/100010661, 10.13039/501100007601, 10.13039/501100000780, 10.13039/100010665}` or name: `'European Union’s Horizon 2020 research and innovation program'` | series of `4-9` digits in `award` | Link to H2020 project |
|
||||
| DOI: `{10.13039/100011199, 10.13039/100004431, 10.13039/501100004963, 10.13039/501100000780}` | series of `4-9` digits in `award` | Link to FP7 project |
|
||||
| DOI: `10.13039/501100000781` OR name: `'European Union's'` | series of `4-9` digits in `award` | Link to FP7 or H2020 project |
|
||||
| DOI: `10.13039/100000001` | `award` | Link to NSF project |
|
||||
| DOI: `10.13039/501100001665` OR name: `{'The French National Research Agency (ANR)', 'The French National Research Agency'}` | `award` | Link to ANR project |
|
||||
| DOI: `10.13039/501100002341` | `award` | Link to Academy of Finland project |
|
||||
| DOI: `10.13039/501100001602` | `award`, removing the initial 'SFI' if present | Link to SFI project |
|
||||
| DOI: `10.13039/501100000923` | `award` | Link to ARC project |
|
||||
| DOI: `10.13039/501100000038` | `award` ignore: we cannot map the project codes in Crossref to project codes in OpenAIRE | Link to NSERC (`unidentified` project) |
|
||||
| DOI: `10.13039/501100000155` | `award` ignore: we cannot map the project codes in Crossref to project codes in OpenAIRE | Link to SSHRC (`unidentified` project) |
|
||||
| DOI: `10.13039/501100000024` | `award` ignore: we cannot map the project codes in Crossref to project codes in OpenAIRE | Link to CIHR (`unidentified` project) |
|
||||
| DOI: `10.13039/501100002848` OR name :`'CONICYT, Programa de Formación de Capital Humano Avanzado'` | `award` | Link to CONICYT project |
|
||||
| DOI: `10.13039/501100003448` | series of `4-9` digits in award | Link to GSRT project |
|
||||
| DOI: `10.13039/501100010198` | `award` | Link to SGOV project |
|
||||
| DOI: `10.13039/501100004564` | series of `4-9` digits in award | Link to MESTD project |
|
||||
| DOI: `10.13039/501100003407` | `award` | Link to MIUR project. Since OpenAIRE has a small subset of MIUR projects, a link to the MIUR funder (`unidentified`<br/> project) is also generated |
|
||||
| DOI: `{10.13039/501100006588, 10.13039/501100004488}` | `award`, removing `'Project No'` and `'HRZZ'` prefix, if present | Link to HRZZ or MZOS project |
|
||||
| DOI: `10.13039/501100006769` | `award` | Link to Russian Science Foundation project |
|
||||
| DOI: `10.13039/501100001711` | `award` after `'_'` and before `'/'` | Link to SNSF project |
|
||||
| DOI: `10.13039/501100004410` | `award` | Link to TUBITAK project |
|
||||
| DOI: `10.10.13039/100004440` or name: `Wellcome Trust Masters Fellowship` | `award` | Link to Wellcome Trust specific project and to the `unidentified` project. |
|
||||
|
||||
## 3. Intersect Crossref with UnpayWall by DOI
|
||||
|
||||
The fields we consider from UnpayWall are:
|
||||
* `is_oa`
|
||||
* `best_oa_location`
|
||||
* `oa_status`
|
||||
|
||||
The results of Crossref that intersect by DOI with UnpayWall records are enriched with one additional `instance` with the following properties:
|
||||
|
||||
| *OpenAIRE Result field path* | *Unpaywall field path* | *Notes* |
|
||||
|----------------------------------------|----------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| `instance` | | created only if `is_oa` and a `best_oa_location` is available |
|
||||
| `instance.accessright` | | default value `Open Access`: we do not add instances if UnpayWall says there is no open version |
|
||||
| `instance.accessright.code` | | Open Access code from the [COAR vocabulary for access right](http://vocabularies.coar-repositories.org/documentation/access_rights/) |
|
||||
| `instance.accessright.label` | | Always `OPEN` |
|
||||
| `instance.accessright.scheme` | | Scheme that defines the code and label, i.e. the URL to the [COAR vocabulary for access right](http://vocabularies.coar-repositories.org/documentation/access_rights/) |
|
||||
| `instance.accessright.openAccessRoute` | `oa_status` | |
|
||||
| `instance.url` | `best_oa_location` | |
|
||||
| `instance.license` | `best_oa_location.license` | |
|
||||
| `instance.pid` | | The scheme tells the type of PID, the value contains the actual value |
|
||||
| `instance.pid.scheme` | | Default value: `doi` |
|
||||
| `instance.pid.value` | `doi` | The doi is normalised and lower-cased |
|
||||
|
||||
For the definition of UnpayWall's `oa_status` refer to the [Unpaywall FAQ](https://support.unpaywall.org/support/solutions/articles/44001777288-what-do-the-types-of-oa-status-green-gold-hybrid-and-bronze-mean-)
|
||||
|
||||
The record will also feature a relation to the UnpayWall data source: `name="UnpayWall"`, `id=openaire____::8ac8380272269217cb09a928c8caa993`.
|
||||
|
||||
## 4. Intersect with ORCID
|
||||
|
||||
The fields we consider from ORCID are:
|
||||
* `doi`
|
||||
* `authors`, a list of authors, each with optional `name`, `surname`, `creditName`, `oid`
|
||||
|
||||
| *OpenAIRE field path* | *ORCID path* | *Notes* |
|
||||
|-------------------------------------|-----------------------|--------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| `pid` | `doi` | |
|
||||
| `author.name` | `capitalize(name)` | only mapped if not blank |
|
||||
| `author.surname` | `capitalize(surname)` | only mapped if not blank |
|
||||
| `author.fullname` | | if name and surname are not blank, they are concatenated (`capitalize(name) capitalize(surname)`), otherwise we use the `creditName` |
|
||||
| `author.pid` | | only if the `ORCID` is available |
|
||||
| `author.pid.id.scheme` | | Default `orcid` (meaning that it is confirmed by ORCID, (in contrast to the `orcid_pending` set from Crossref and Unpaywall) |
|
||||
| `author.pid.id.value` | `oid` | |
|
||||
| `author.pid.provenance.provenance` | | Default `Harvested` |
|
||||
| `author.pid.provenance.trust` | | Default `0.9` |
|
||||
|
||||
The records are enriched with the ORCID identifiers of their authors.
|
||||
|
||||
[//]: # (TODO: Update with the new approach implemented by Miriam.)
|
||||
|
||||
The current approach is:
|
||||
* if the number of authors from Crossref equals the size of authors from ORCID, then we pick the list of authors with more PIDs and try to enrich it with the PIDs from the other list, based on JaroWrinkler distance on authors' names, surnames, or fullnames, depending on which properties are available;
|
||||
* if the number of authors are different, then we take the longest and try to enrich it with the PIDs from the other author list, based on JaroWrinkler distance on authors' names, surnames, or fullnames, depending on which properties are available
|
||||
|
||||
Miriam will modify the process to ensure that:
|
||||
* the list of authors from Crossred always "win"
|
||||
* the identifiers from ORCID "win"
|
||||
|
||||
## 5. Intersect with Microsoft Academic Graph
|
||||
|
||||
*Important Notes*
|
||||
* Only papers with DOI are considered
|
||||
* Since for the same DOI we have multiple version of item with different MAG PaperId, we only take one per DOI (the last one we process). We call this dataset `Papers_distinct`
|
||||
|
||||
When mapping MAG records to the OpenAIRE Research Graph, we consider the following MAG tables:
|
||||
* `PaperAbstractsInvertedIndex`: for the paper abstracts
|
||||
* `Authors`: for the authors. The MAG data is pre-processed by grouping authors by PaperId
|
||||
* `Affiliations` and `PaperAuthorAffiliations`: to generate links between publications and organisations
|
||||
* `Journals` and `ConferenceInstances`: joined with `Papers_distinct` to have the information about the venues where the paper was published
|
||||
* TO BE REMOVED `PaperUrls`: to create one instance for the OpenAIRE publication
|
||||
* `FieldsOfStudy`: to add subjects
|
||||
|
||||
The records are enriched with:
|
||||
* abstracts
|
||||
* MAG identifiers of authors
|
||||
* affiliation relationships
|
||||
* subjects (MAG FieldsOfStudy)
|
||||
* conference or journal information (in the `journal` field) TODO: or `container`, in case of the dump?
|
||||
* [TO BE REMOVED] instances with URL from MAG
|
||||
|
||||
## 6. Enrich DOIBoost3 with hosting data sources (`hostedby`) and access right information
|
||||
|
||||
In this phase, we intersect DOIBoost3 with a dataset composed of journals from OpenAIRE, Crossref, and the ISSN gold list. Each journal comes with its International Standard Serial Numbers (`issn`, `eissn`, `lissn`) and, when available, a flag that tells if the journal is open access. The intersection is done on the basis of the International Standard Serial Numbers. The records with a `journal.[l|e]issn` that match are enriched as follows:
|
||||
* Each instance gain the `hostedby` information corresponding to the journal
|
||||
* If the journal is open access, the access rights of the instances are also set to `Open Access` with `gold` route (because by construction, the journals we know are open are from DOAJ or Gold ISSN list)
|
||||
|
||||
The hostedby of records that do not match are set to the `Unknown Repository`.
|
||||
|
|
@ -0,0 +1,61 @@
|
|||
# PubMed
|
||||
|
||||
This section describes the mapping implemented for [MEDLINE/PubMed](https://pubmed.ncbi.nlm.nih.gov/).
|
||||
|
||||
## Input
|
||||
|
||||
The native data is collected from the [ftp baseline](https://ftp.ncbi.nlm.nih.gov/pubmed/baseline/) site.
|
||||
It contains XML records compliant with the schema available at https://www.nlm.nih.gov/bsd/licensee/elements_descriptions.html.
|
||||
|
||||
## Mapping
|
||||
|
||||
The table below describes the mapping from the XML baseline records to the OpenAIRE Graph dump format.
|
||||
|
||||
|
||||
| *OpenAIRE Result field path* | PubMed record field xpath | Notes |
|
||||
|--------------------------------|--------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| **Publication Mapping** | | |
|
||||
| `id` | ?? | ?? |
|
||||
| `pid` | `//PMID` | `classid = classname = pmid` |
|
||||
| `publicationdate` | `//PubmedPubDate` | apply the function GraphCleaningFunctions.cleanDate before assign it |
|
||||
| `maintitle` | `//Title` | |
|
||||
| `description` | `//AbstractText` | |
|
||||
| `language` | `//Language` | cleaning vocabulary -> dnet:languages |
|
||||
| `subjects` | `//DescriptorName` | classId, className = keyword |
|
||||
| **Author Mapping** | | |
|
||||
| `author.surname` | `//Author/LastName` | |
|
||||
| `author.name` | `//Author/ForeName` | |
|
||||
| `author.fullname` | `//Author/FullName` | Concatenation of forename + lastName if exist |
|
||||
| `author.rank` | FOR ALL AUTHORS | sequential number starting from 1 |
|
||||
| **Journal Mapping** | | |
|
||||
| `container.conferencedate` | `//Journal/PubDate` | map the date of the Journal |
|
||||
| `container.name` | `//Journal/Title` | name of the journal |
|
||||
| `container.vol` | `//Journal/Volume` | journal volume |
|
||||
| `container.issPrinted` | `//Journal/ISSN` | ?? |
|
||||
| `container.iss` | `//Journal/Issue` | The journal issue |
|
||||
| **Instance Mapping** | | |
|
||||
| `instance.type` | `//PublicationType` | if the article contains the typology `Journal Article` then we apply this type else We have to find a terms that match the vocabulary otherwise we discard it |
|
||||
| `instance.pid` | `//PMID` | map the pmid in the pid in the instance |
|
||||
| `instance.url` | `//PMID` | creates the URL by prepending `https://pubmed.ncbi.nlm.nih.gov/` to the PMId |
|
||||
| `instance.alternateIdentifier` | `//ArticleId[./@IdType="doi"]` | |
|
||||
| `instance.publicationdate` | `//PubmedPubDate` | |
|
||||
|
||||
|
||||
| *OpenAIRE Relation field path* | PubMed record field xpath | Notes |
|
||||
|--------------------------------|---------------------------|-------|
|
||||
| | | |
|
||||
|
||||
#TODO
|
||||
|
||||
Missing item mapped
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
12
sidebars.js
12
sidebars.js
|
|
@ -23,6 +23,7 @@ const sidebars = {
|
|||
label: "Data model",
|
||||
link: {type: 'doc', id: 'data-model/data-model'},
|
||||
items: [
|
||||
{ type: 'doc', id: 'data-model/pids-and-identifiers' },
|
||||
{
|
||||
type: 'category',
|
||||
label: "Entities",
|
||||
|
|
@ -58,7 +59,16 @@ const sidebars = {
|
|||
label: "Data provision",
|
||||
link: {type: 'doc', id: 'data-provision/data-provision'},
|
||||
items: [
|
||||
{ type: 'doc', id: 'data-provision/aggregation' },
|
||||
{
|
||||
type: 'category',
|
||||
label: "Aggregation",
|
||||
link: {type: 'doc', id: 'data-provision/aggregation/aggregation'},
|
||||
items: [
|
||||
{ type: 'doc', id: 'data-provision/aggregation/doiboost' },
|
||||
{ type: 'doc', id: 'data-provision/aggregation/pubmed' },
|
||||
{ type: 'doc', id: 'data-provision/aggregation/datacite' }
|
||||
]
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: "Deduplication",
|
||||
|
|
|
|||
Loading…
Reference in New Issue