1 |
59953
|
k.triantaf
|
<schema2jsonld [URL]="properties.domain"
|
2 |
|
|
[logoURL]="properties.domain + '/assets/common-assets/logo-small-graph.png'"
|
3 |
|
|
[description]="description"
|
4 |
|
|
type="other"
|
5 |
|
|
[name]="title">
|
6 |
|
|
</schema2jsonld>
|
7 |
59529
|
konstantin
|
<div class="about">
|
8 |
59546
|
k.triantaf
|
<div class="uk-section">
|
9 |
59534
|
konstantin
|
<div class="uk-margin-large-left uk-margin-medium-bottom">
|
10 |
|
|
<breadcrumbs [breadcrumbs]="breadcrumbs"></breadcrumbs>
|
11 |
|
|
</div>
|
12 |
59546
|
k.triantaf
|
<div class="firstBackground">
|
13 |
|
|
<div class="uk-container">
|
14 |
|
|
<h2 class="uk-text-center">About</h2>
|
15 |
|
|
<div class="uk-flex uk-flex-center">
|
16 |
|
|
<div class="uk-padding-small uk-width-4-5@m">
|
17 |
|
|
<p>
|
18 |
|
|
Open Science is gradually becoming the modus operandi in research practices, affecting the way researchers
|
19 |
|
|
collaborate and publish, discover, and access scientific knowledge.
|
20 |
|
|
Scientists are increasingly publishing research results beyond the article, to share all scientific
|
21 |
|
|
products (metadata and files) generated during an experiment, such as datasets, software, experiments.
|
22 |
|
|
They publish in scholarly communication data sources (e.g. institutional repositories, data archives,
|
23 |
|
|
software repositories), rely where possible on persistent identifiers (e.g. DOI, ORCID, Grid.ac, PDBs),
|
24 |
|
|
specify semantic links to other research products (e.g. supplementedBy, citedBy, versionOf), and possibly
|
25 |
|
|
to projects and/or relative funders.
|
26 |
|
|
By following such practices, scientists are implicitly constructing the Global Open Science Graph, where
|
27 |
|
|
by "graph" we mean a collection of objects interlinked by semantic relationships.
|
28 |
|
|
<br><br>
|
29 |
|
|
The OpenAIRE Research Graph includes metadata and links between scientific products (e.g. literature,
|
30 |
|
|
datasets, software, and "other research products"), organizations, funders, funding streams, projects,
|
31 |
|
|
communities, and (provenance) data sources - the details of the <a
|
32 |
|
|
href="https://zenodo.org/record/2643199#.XOqdstMzZ24" target="_blank">graph data model</a> can be found
|
33 |
|
|
in Zenodo.org.
|
34 |
|
|
<br><br>
|
35 |
|
|
The Graph is available and obtained as an aggregation of the metadata and links collected from ~70.000
|
36 |
|
|
trusted sources, further enriched with metadata and links provided by:</p>
|
37 |
|
|
<ul class="portal-circle">
|
38 |
|
|
<li class="uk-margin-bottom">OpenAIRE end-users, e.g. researchers, project administrators, data curators
|
39 |
|
|
providing links from scientific products to projects, funders, communities, or other products;
|
40 |
|
|
</li>
|
41 |
|
|
<li class="uk-margin-bottom">OpenAIRE Full-text mining algorithms over around ~10Mi Open Access article
|
42 |
|
|
full-texts;
|
43 |
|
|
</li>
|
44 |
|
|
<li>Research infrastructure scholarly services, bridged to the graph via OpenAIRE, exposing metadata of
|
45 |
|
|
products such as research workflows, experiments, research objects, software, etc..
|
46 |
|
|
</li>
|
47 |
|
|
</ul>
|
48 |
|
|
</div>
|
49 |
59529
|
konstantin
|
</div>
|
50 |
|
|
</div>
|
51 |
|
|
</div>
|
52 |
59534
|
konstantin
|
</div>
|
53 |
59546
|
k.triantaf
|
<div id="architecture" class="uk-container uk-section">
|
54 |
|
|
<div class="uk-padding-small">
|
55 |
|
|
<h2 class="uk-text-center">Architecture</h2>
|
56 |
|
|
<div class="uk-flex uk-flex-center">
|
57 |
|
|
<div class="uk-width-4-5@m">
|
58 |
|
|
<h3 class="uk-margin-medium-top portal-color">How we build it</h3>
|
59 |
|
|
<div>
|
60 |
|
|
<p>
|
61 |
|
|
OpenAIRE collects metadata records from more than 70K scholarly communication sources from all over the
|
62 |
|
|
world, including Open Access institutional repositories, data archives, journals.
|
63 |
|
|
All the metadata records (i.e. descriptions of research products) are put together in a data lake,
|
64 |
|
|
together
|
65 |
|
|
with records from Crossref, Unpaywall, ORCID, Grid.ac, and information about projects provided by national
|
66 |
|
|
and international funders.
|
67 |
|
|
Dedicated inference algorithms applied to metadata and to the full-texts of Open Access publications
|
68 |
|
|
enrich
|
69 |
|
|
the content of the data lake with links between research results and projects, author affiliations,
|
70 |
|
|
subject
|
71 |
|
|
classification, links to entries from domain-specific databases.
|
72 |
|
|
Duplicated organisations and results are identified and merged together to obtain an open, trusted, public
|
73 |
|
|
resource enabling explorations of the scholarly communication landscape like never before.
|
74 |
|
|
</p>
|
75 |
59529
|
konstantin
|
|
76 |
59546
|
k.triantaf
|
</div>
|
77 |
59529
|
konstantin
|
</div>
|
78 |
|
|
</div>
|
79 |
59546
|
k.triantaf
|
<div class="uk-flex uk-flex-center uk-inline uk-margin-medium-top">
|
80 |
|
|
<img [src]="'assets/graph-assets/about/architecture/'+architectureImage"
|
81 |
|
|
class="uk-width-4-5 architecture-image">
|
82 |
59529
|
konstantin
|
|
83 |
59549
|
k.triantaf
|
<a class="uk-position-absolute uk-transform-center uk-padding" style="left: 27%; top: 48%"
|
84 |
59546
|
k.triantaf
|
(click)="goTo('tabs_card'); changeTab(0)"
|
85 |
|
|
(mouseenter)="architectureImage = 'aggregation_hover.png'" (mouseleave)="architectureImage = 'gray.png'">
|
86 |
59549
|
k.triantaf
|
<action-point [class.uk-invisible]="architectureImage == 'aggregation_hover.png'"></action-point>
|
87 |
59546
|
k.triantaf
|
</a>
|
88 |
59549
|
k.triantaf
|
<a class="uk-position-absolute uk-transform-center uk-padding" style="left: 47%; top: 48%"
|
89 |
59546
|
k.triantaf
|
(click)="goTo('tabs_card'); changeTab(1)"
|
90 |
|
|
(mouseenter)="architectureImage = 'deduplication_hover.png'" (mouseleave)="architectureImage = 'gray.png'">
|
91 |
59549
|
k.triantaf
|
<action-point [class.uk-invisible]="architectureImage == 'deduplication_hover.png'"></action-point>
|
92 |
59546
|
k.triantaf
|
</a>
|
93 |
59549
|
k.triantaf
|
<a class="uk-position-absolute uk-transform-center uk-padding" style="left: 58%; top: 48%"
|
94 |
59546
|
k.triantaf
|
(click)="goTo('tabs_card'); changeTab(2)"
|
95 |
|
|
(mouseenter)="architectureImage = 'enrichment_hover.png'" (mouseleave)="architectureImage = 'gray.png'">
|
96 |
59549
|
k.triantaf
|
<action-point [class.uk-invisible]="architectureImage == 'enrichment_hover.png'"></action-point>
|
97 |
59546
|
k.triantaf
|
</a>
|
98 |
59549
|
k.triantaf
|
<a class="uk-position-absolute uk-transform-center uk-padding" style="left: 70%; top: 48%"
|
99 |
59546
|
k.triantaf
|
(click)="goTo('tabs_card'); changeTab(3)"
|
100 |
|
|
(mouseenter)="architectureImage = 'post_cleaning_hover.png'" (mouseleave)="architectureImage = 'gray.png'">
|
101 |
59549
|
k.triantaf
|
<action-point [class.uk-invisible]="architectureImage == 'post_cleaning_hover.png'"></action-point>
|
102 |
59546
|
k.triantaf
|
</a>
|
103 |
59549
|
k.triantaf
|
<a class="uk-position-absolute uk-transform-center uk-padding" style="left: 76%; top: 32%"
|
104 |
59546
|
k.triantaf
|
(click)="goTo('tabs_card'); changeTab(4)"
|
105 |
|
|
(mouseenter)="architectureImage = 'indexing_hover.png'" (mouseleave)="architectureImage = 'gray.png'">
|
106 |
59549
|
k.triantaf
|
<action-point [class.uk-invisible]="architectureImage == 'indexing_hover.png'"></action-point>
|
107 |
59546
|
k.triantaf
|
</a>
|
108 |
59549
|
k.triantaf
|
<a class="uk-position-absolute uk-transform-center uk-padding" style="left: 76%; top: 72%"
|
109 |
59546
|
k.triantaf
|
(click)="goTo('tabs_card'); changeTab(5)"
|
110 |
|
|
(mouseenter)="architectureImage = 'stats_analysis_hover.png'" (mouseleave)="architectureImage = 'gray.png'">
|
111 |
59549
|
k.triantaf
|
<action-point [class.uk-invisible]="architectureImage == 'stats_analysis_hover.png'"></action-point>
|
112 |
59546
|
k.triantaf
|
</a>
|
113 |
|
|
</div>
|
114 |
|
|
<div id="tabs_card"
|
115 |
59547
|
k.triantaf
|
class="uk-margin-xlarge-top uk-padding-small">
|
116 |
|
|
<div class="uk-card uk-card-default uk-card-body architecture-card">
|
117 |
|
|
<ul #tabs uk-tab class="uk-tab">
|
118 |
|
|
<li><a>Aggregation</a></li>
|
119 |
|
|
<li><a>Deduplication</a></li>
|
120 |
|
|
<li><a>Enrichment</a></li>
|
121 |
|
|
<li><a>Post-Cleaning</a></li>
|
122 |
|
|
<li><a>Indexing</a></li>
|
123 |
|
|
<li><a>Stats Analysis</a></li>
|
124 |
|
|
</ul>
|
125 |
59529
|
konstantin
|
|
126 |
59547
|
k.triantaf
|
<ul class="uk-switcher uk-margin">
|
127 |
|
|
<li>
|
128 |
|
|
<!-- uk-grid-->
|
129 |
|
|
<div class=" uk-margin-large-top uk-text-small">
|
130 |
|
|
<!-- <div class="uk-width-3-5@m">-->
|
131 |
|
|
<img class="uk-width-2-5@m uk-align-right@m uk-margin-remove-adjacent tab-image"
|
132 |
|
|
src="assets/graph-assets/about/architecture/aggregation.png" alt="Aggregation">
|
133 |
|
|
<div
|
134 |
|
|
[class]="'uk-margin-bottom uk-margin-medium-right '+(aggregationReadMore ? '' : 'lines-18 multi-line-ellipsis')">
|
135 |
|
|
<div>
|
136 |
|
|
OpenAIRE collects metadata records from a variety of content providers as described in
|
137 |
|
|
<a href="https://www.openaire.eu/aggregation-and-content-provision-workflows" target="_blank">https://www.openaire.eu/aggregation-and-content-provision-workflows</a>.
|
138 |
|
|
<br><br>
|
139 |
|
|
OpenAIRE aggregates metadata records describing objects of the research life-cycle from content
|
140 |
|
|
providers compliant to the
|
141 |
|
|
<a href="https://guidelines.openaire.eu" target="_blank">OpenAIRE guidelines</a>
|
142 |
|
|
and from entity registries (i.e. data sources offering authoritative lists of entities, like OpenDOAR,
|
143 |
|
|
re3data, DOAJ, and funder databases).
|
144 |
|
|
After collection, metadata are transformed according to the OpenAIRE internal metadata model, which is
|
145 |
|
|
used to generate the final OpenAIRE Research Graph that you can access from the OpenAIRE portal and
|
146 |
|
|
the
|
147 |
|
|
APIs.
|
148 |
|
|
<br><br>
|
149 |
|
|
The transformation process includes the application of cleaning functions whose goal is to ensure that
|
150 |
|
|
values are harmonised according to a common format (e.g. dates as YYYY-MM-dd) and, whenever
|
151 |
|
|
applicable,
|
152 |
|
|
to a common controlled vocabulary.
|
153 |
|
|
The controlled vocabularies used for cleansing are accessible at
|
154 |
|
|
<a href="http://api.openaire.eu/vocabularies" target="_blank">http://api.openaire.eu/vocabularies</a>.
|
155 |
|
|
Each vocabulary features a set of controlled terms, each with one code, one label, and a set of
|
156 |
|
|
synonyms.
|
157 |
|
|
If a synonym is found as field value, the value is updated with the corresponding term.
|
158 |
|
|
Also, the OpenAIRE Research Graph is extended with other relevant scholarly communication sources that
|
159 |
|
|
are too big to be integrated via the “normal” aggregation mechanism: DOIBoost (which merges Crossref,
|
160 |
|
|
ORCID, Microsoft Academic Graph, and Unpaywall), and ScholeXplorer, one of the Scholix hubs offering a
|
161 |
|
|
large set of links between research literature and data.
|
162 |
|
|
</div>
|
163 |
59529
|
konstantin
|
</div>
|
164 |
59547
|
k.triantaf
|
<div *ngIf="!aggregationReadMore" class="uk-width-3-5@m uk-text-center clickable"
|
165 |
|
|
(click)="aggregationReadMore = true">
|
166 |
|
|
<a class="custom-explore-toggle">Read more<span uk-icon="chevron-down"></span></a>
|
167 |
|
|
</div>
|
168 |
|
|
<div *ngIf="aggregationReadMore" class="uk-width-3-5@m uk-text-center clickable"
|
169 |
|
|
(click)="aggregationReadMore = false">
|
170 |
|
|
<a class="custom-explore-toggle">Read less<span uk-icon="chevron-up"></span></a>
|
171 |
|
|
</div>
|
172 |
|
|
<!-- </div>-->
|
173 |
|
|
<!-- <div class="uk-width-expand">-->
|
174 |
|
|
<!-- <img src="assets/graph-assets/about/architecture/aggregation.png">-->
|
175 |
|
|
<!-- </div>-->
|
176 |
59534
|
konstantin
|
</div>
|
177 |
59547
|
k.triantaf
|
</li>
|
178 |
|
|
<li>
|
179 |
|
|
<div class="uk-grid">
|
180 |
|
|
<!-- <div class="uk-width-3-5@m">-->
|
181 |
|
|
<div class="uk-margin-bottom uk-margin-medium-right uk-text-small">
|
182 |
|
|
<ul class="uk-subnav button-tab" uk-switcher>
|
183 |
|
|
<li><a>Clustering</a></li>
|
184 |
|
|
<li><a>Matching & Election</a></li>
|
185 |
|
|
</ul>
|
186 |
59529
|
konstantin
|
|
187 |
59547
|
k.triantaf
|
<ul class="uk-switcher uk-margin align-list">
|
188 |
|
|
<li>
|
189 |
|
|
<img class="uk-width-2-5@m uk-align-right@m uk-margin-remove-adjacent tab-image"
|
190 |
|
|
src="assets/graph-assets/about/architecture/deduplication.svg" alt="Deduplication">
|
191 |
|
|
<div
|
192 |
|
|
[class]="'uk-margin-bottom uk-margin-medium-right uk-text-small '+(dedupClusteringReadMore ? '' : 'lines-18 multi-line-ellipsis')">
|
193 |
59529
|
konstantin
|
<div>
|
194 |
59547
|
k.triantaf
|
<div>
|
195 |
|
|
Clustering is a common heuristics used to overcome the N x N complexity required to match all
|
196 |
|
|
pairs of objects to identify the equivalent ones.
|
197 |
|
|
The challenge is to identify a clustering function that maximizes the chance of comparing only
|
198 |
|
|
records that may lead to a match, while minimizing the number of records that will not be
|
199 |
|
|
matched while being equivalent.
|
200 |
|
|
Since the equivalence function is to some level tolerant to minimal errors (e.g. switching of
|
201 |
|
|
characters in the title, or minimal difference in letters), we need this function to be not
|
202 |
|
|
too
|
203 |
|
|
precise (e.g. a hash of the title), but also not too flexible (e.g. random ngrams of the
|
204 |
|
|
title).
|
205 |
|
|
On the other hand, reality tells us that in some cases equality of two records can only be
|
206 |
|
|
determined by their PIDs (e.g. DOI) as the metadata properties are very different across
|
207 |
|
|
different versions and no clustering function will ever bring them into the same cluster.
|
208 |
|
|
To match these requirements OpenAIRE clustering for products works with two functions:
|
209 |
|
|
</div>
|
210 |
|
|
|
211 |
|
|
<ul class="portal-circle">
|
212 |
|
|
<li>
|
213 |
|
|
<div>DOI: the function generates the DOI when this is provided as part of the record
|
214 |
|
|
properties;
|
215 |
|
|
</div>
|
216 |
|
|
</li>
|
217 |
|
|
<li>
|
218 |
|
|
<div>
|
219 |
|
|
Title-based function: the function generates a key that depends on
|
220 |
|
|
(i) number of significant words in the title (normalized, stemming, etc.),
|
221 |
|
|
(ii) module 10 of the number of characters of such words, and
|
222 |
|
|
(iii) a string obtained as an alternation of the function prefix(3) and suffix(3) (and
|
223 |
|
|
vice
|
224 |
|
|
versa) o the first 3 words (2 words if the title only has 2). For example, the title
|
225 |
|
|
“Entity
|
226 |
|
|
deduplication in big data graphs for scholarly communication” becomes “entity
|
227 |
|
|
deduplication
|
228 |
|
|
big data graphs scholarly communication” with two keys key “7.1entionbig” and
|
229 |
|
|
“7.1itydedbig”
|
230 |
|
|
(where 1 is module 10 of 54 characters of the normalized title.
|
231 |
|
|
</div>
|
232 |
|
|
</li>
|
233 |
|
|
</ul>
|
234 |
|
|
<div>
|
235 |
|
|
To give an idea, this configuration generates around 77Mi blocks, which we limited to 200
|
236 |
|
|
records each (only 15K blocks are affected by the cut), and entails 260Bi matches. Matches in
|
237 |
|
|
a
|
238 |
|
|
block are performed using a “sliding window” set to 80 records. The records are sorted
|
239 |
|
|
lexicographically on a normalized version of their titles. The 1st record is matched against
|
240 |
|
|
all
|
241 |
|
|
the 80 following ones, then the second, etc. for an NlogN complexity.
|
242 |
|
|
</div>
|
243 |
59534
|
konstantin
|
</div>
|
244 |
59547
|
k.triantaf
|
</div>
|
245 |
|
|
<div *ngIf="!dedupClusteringReadMore" class="uk-width-3-5@m uk-text-center clickable"
|
246 |
|
|
(click)="dedupClusteringReadMore = true">
|
247 |
|
|
<a class="custom-explore-toggle">Read more<span uk-icon="chevron-down"></span></a>
|
248 |
|
|
</div>
|
249 |
|
|
<div *ngIf="dedupClusteringReadMore" class="uk-width-3-5@m uk-text-center clickable"
|
250 |
|
|
(click)="dedupClusteringReadMore = false">
|
251 |
|
|
<a class="custom-explore-toggle">Read less<span uk-icon="chevron-up"></span></a>
|
252 |
|
|
</div>
|
253 |
|
|
</li>
|
254 |
|
|
<li>
|
255 |
|
|
<img class="uk-width-2-5@m uk-align-right@m uk-margin-remove-adjacent tab-image"
|
256 |
|
|
src="assets/graph-assets/about/architecture/deduplication.svg" alt="Deduplication">
|
257 |
|
|
<div
|
258 |
|
|
[class]="'uk-margin-bottom uk-margin-medium-right uk-text-small '+(dedupMatchingAndElectionReadMore ? '' : 'lines-18 multi-line-ellipsis')">
|
259 |
|
|
<div>
|
260 |
|
|
<div>
|
261 |
|
|
Once the clusters have been built, the algorithm proceeds with the comparisons.
|
262 |
|
|
Comparisons are driven by a decisional tree that:
|
263 |
|
|
</div>
|
264 |
|
|
<ul class="uk-list">
|
265 |
|
|
<li class="uk-margin-small-bottom">
|
266 |
|
|
<div>
|
267 |
|
|
<span class="portal-color">1.</span> Tries to capture equivalence via PIDs: if records
|
268 |
|
|
share
|
269 |
|
|
a PID then they are equivalent
|
270 |
|
|
</div>
|
271 |
|
|
</li>
|
272 |
|
|
<li class="uk-margin-small-bottom">
|
273 |
|
|
<div>
|
274 |
|
|
<span class="portal-color">2.</span> Tries to capture difference:
|
275 |
|
|
</div>
|
276 |
|
|
<ul class="uk-list">
|
277 |
|
|
<li class="uk-margin-small-bottom">
|
278 |
|
|
<div>
|
279 |
|
|
<span class="portal-color">a.</span>
|
280 |
|
|
If record titles contain different “numbers” then they are different (this rule is
|
281 |
|
|
subject to different feelings, and should be fine-tuned);
|
282 |
|
|
</div>
|
283 |
|
|
</li>
|
284 |
|
|
<li class="uk-margin-small-bottom">
|
285 |
|
|
<div>
|
286 |
|
|
<span class="portal-color">b.</span>
|
287 |
|
|
If record contain different number of authors then they are different;
|
288 |
|
|
</div>
|
289 |
|
|
</li>
|
290 |
|
|
<li class="uk-margin-small-bottom">
|
291 |
|
|
<div>
|
292 |
|
|
<span class="portal-color">c.</span>
|
293 |
|
|
Note that different PIDs do not imply different records, as different versions may
|
294 |
|
|
have
|
295 |
|
|
different PIDs.
|
296 |
|
|
</div>
|
297 |
|
|
</li>
|
298 |
|
|
</ul>
|
299 |
|
|
</li>
|
300 |
|
|
<li>
|
301 |
|
|
<div><span class="portal-color">3.</span> Measures equivalence:</div>
|
302 |
|
|
<ul class="uk-list portal-circle">
|
303 |
|
|
<li>
|
304 |
|
|
<div>
|
305 |
|
|
The titles of the two records are normalised and compared for similarity by applying
|
306 |
|
|
the
|
307 |
|
|
Levenstein distance algorithm.
|
308 |
|
|
The algorithm returns a number in the range [0,1], where 0 means “very different” and
|
309 |
|
|
1
|
310 |
|
|
means “equal”.
|
311 |
|
|
If the distance is greater than or equal 0,99 the two records are identified as
|
312 |
|
|
duplicates.
|
313 |
|
|
</div>
|
314 |
|
|
</li>
|
315 |
|
|
<li>
|
316 |
|
|
<div>Dates are not regarded for equivalence matching because different versions of the
|
317 |
|
|
same records should be merged and may be published on different dates, e.g. pre-print
|
318 |
|
|
and published version of an article.
|
319 |
|
|
</div>
|
320 |
|
|
</li>
|
321 |
|
|
</ul>
|
322 |
|
|
</li>
|
323 |
|
|
</ul>
|
324 |
|
|
<div>
|
325 |
|
|
Once the equivalence relationships between pairs of records are set, the groups of equivalent
|
326 |
|
|
records are obtained (transitive closure, i.e. “mesh”).
|
327 |
|
|
From such sets a new representative object is obtained, which inherits all properties from the
|
328 |
|
|
merged records and keeps track of their provenance.
|
329 |
|
|
The ID of the record is obtained by appending the prefix “dedup_” to the MD5 of the first ID
|
330 |
|
|
(given their lexicographical ordering).
|
331 |
|
|
A new, more stable function to generate the ID is under development, which exploits the DOI
|
332 |
|
|
when
|
333 |
|
|
one of the records to be merged includes a Crossref or a DataCite record.
|
334 |
|
|
</div>
|
335 |
|
|
</div>
|
336 |
|
|
</div>
|
337 |
|
|
<div *ngIf="!dedupMatchingAndElectionReadMore" class="uk-width-3-5@m uk-text-center clickable"
|
338 |
|
|
(click)="dedupMatchingAndElectionReadMore = true">
|
339 |
|
|
<a class="custom-explore-toggle">Read more<span uk-icon="chevron-down"></span></a>
|
340 |
|
|
</div>
|
341 |
|
|
<div *ngIf="dedupMatchingAndElectionReadMore" class="uk-width-3-5@m uk-text-center clickable"
|
342 |
|
|
(click)="dedupMatchingAndElectionReadMore = false">
|
343 |
|
|
<a class="custom-explore-toggle">Read less<span uk-icon="chevron-up"></span></a>
|
344 |
|
|
</div>
|
345 |
|
|
</li>
|
346 |
|
|
</ul>
|
347 |
|
|
</div>
|
348 |
|
|
<!-- </div>-->
|
349 |
|
|
<!-- <div class="uk-width-expand">-->
|
350 |
|
|
<!-- <img src="assets/graph-assets/about/architecture/deduplication.svg">-->
|
351 |
|
|
<!-- </div>-->
|
352 |
|
|
</div>
|
353 |
|
|
</li>
|
354 |
|
|
<li>
|
355 |
|
|
<div class="uk-grid">
|
356 |
|
|
<!-- <div class="uk-width-3-5@m">-->
|
357 |
|
|
<div class="uk-margin-bottom uk-margin-medium-right uk-text-small">
|
358 |
|
|
<ul class="uk-subnav button-tab uk-grid uk-grid-small" uk-switcher>
|
359 |
|
|
<li><a>General</a></li>
|
360 |
|
|
<li><a>Mining</a></li>
|
361 |
|
|
<li><a>Bulk tagging/ Deduction</a></li>
|
362 |
|
|
<li><a>Propagation</a></li>
|
363 |
|
|
</ul>
|
364 |
59529
|
konstantin
|
|
365 |
59547
|
k.triantaf
|
<ul class="uk-switcher uk-margin">
|
366 |
|
|
<li>
|
367 |
|
|
<img class="uk-width-2-5@m uk-align-right@m uk-margin-remove-adjacent tab-image"
|
368 |
|
|
src="assets/graph-assets/about/architecture/enrichment.svg" alt="Enrichment">
|
369 |
|
|
<div class="uk-margin-bottom uk-margin-medium-right uk-text-small">
|
370 |
|
|
<p>
|
371 |
|
|
The aggregation processes are continuously running and apply vocabularies as they are in a given
|
372 |
|
|
moment of time.
|
373 |
|
|
It could be the case that a vocabulary changes after the aggregation of one data source has
|
374 |
|
|
finished,
|
375 |
|
|
thus the aggregated content does not reflect the current status of the controlled vocabularies.
|
376 |
|
|
<br><br>
|
377 |
|
|
In addition, the integration of ScholeXplorer and DOIBooost and some enrichment processes
|
378 |
|
|
applied
|
379 |
|
|
on the raw
|
380 |
|
|
and on the de-duplicated graph may introduce values that do not comply with the current status
|
381 |
|
|
of
|
382 |
|
|
the OpenAIRE controlled vocabularies.
|
383 |
|
|
For these reasons, we included a final step of cleansing at the end of the workflow
|
384 |
|
|
materialisation.
|
385 |
|
|
The output of the final cleansing step is the final version of the OpenAIRE Research Graph.
|
386 |
|
|
</p>
|
387 |
|
|
</div>
|
388 |
|
|
</li>
|
389 |
|
|
<li>
|
390 |
|
|
<img class="uk-width-2-5@m uk-align-right@m uk-margin-remove-adjacent tab-image"
|
391 |
|
|
src="assets/graph-assets/about/architecture/enrichment.svg" alt="Enrichment">
|
392 |
|
|
<div
|
393 |
|
|
[class]="'uk-margin-bottom uk-margin-medium-right uk-text-small '+(enrichmentMiningReadMore ? '' : 'lines-18 multi-line-ellipsis')">
|
394 |
59529
|
konstantin
|
<div>
|
395 |
59547
|
k.triantaf
|
<div>
|
396 |
|
|
The OpenAIRE Research Graph is enriched by links mined by OpenAIRE’s full-text mining
|
397 |
|
|
algorithms
|
398 |
|
|
that scan the plaintexts of publications for funding information, references to datasets,
|
399 |
|
|
software URIs, accession numbers of bioetities, and EPO patent mentions.
|
400 |
|
|
Custom mining modules also link research objects to specific research communities, initiatives
|
401 |
|
|
and infrastructures.
|
402 |
|
|
In addition, other inference modules provide content-based document classification, document
|
403 |
|
|
similarity, citation matching, and author affiliation matching.
|
404 |
|
|
<br><br>
|
405 |
|
|
<span class="portal-color">Project mining</span>
|
406 |
|
|
in OpenAIRE text mines the full-texts of publications in order to extract matches to funding
|
407 |
|
|
project codes/IDs.
|
408 |
|
|
The mining algorithm works by utilising
|
409 |
|
|
(i) the grant identifier, and
|
410 |
|
|
(ii) the project acronym (if available) of each project.
|
411 |
|
|
The mining algorithm:
|
412 |
|
|
(1) Preprocesses/normalizes the full-texts using several functions, which depend on the
|
413 |
|
|
characteristics of each funder (i.e., the format of the grant identifiers), such as stopword
|
414 |
|
|
and/or punctuation removal, tokenization, stemming, converting to lowercase; then
|
415 |
|
|
(2) String matching of grant identifiers against the normalized text is done using database
|
416 |
|
|
techniques; and
|
417 |
|
|
(3) The results are validated and cleaned using the context near the match by looking at the
|
418 |
|
|
context around the matched ID for relevant metadata and positive or negative words/phrases, in
|
419 |
|
|
order to calculate a confidence value for each publication-->project link.
|
420 |
|
|
A confidence threshold is set to optimise high accuracy while minimising false positives, such
|
421 |
|
|
as matches with page or report numbers, post/zip codes, parts of telephone numbers, DOIs or
|
422 |
|
|
URLs, accession numbers.
|
423 |
|
|
The algorithm also applies rules for disambiguating results, as different funders can share
|
424 |
|
|
identical project IDs; for example, grant number 633172 could refer to H2020 project EuroMix
|
425 |
|
|
but
|
426 |
|
|
also to Australian-funded NHMRC project “Brain activity (EEG) analysis and brain imaging
|
427 |
|
|
techniques to measure the neurobiological effects of sleep apnea”.
|
428 |
|
|
Project mining works very well and was the first Text & Data Mining (TDM) service of OpenAIRE.
|
429 |
|
|
Performance results vary from funder to funder but precision is higher than 98% for all
|
430 |
|
|
funders
|
431 |
|
|
and 99.5% for EC projects.
|
432 |
|
|
Recall is higher than 95% (99% for EC projects), when projects are properly acknowledged using
|
433 |
|
|
project/grant IDs.
|
434 |
|
|
<br><br>
|
435 |
|
|
<span class="portal-color">Dataset extraction</span>
|
436 |
|
|
runs on publications full-texts as described in “High pass text-filtering for Citation
|
437 |
|
|
matching”, TPDL 2017[1].
|
438 |
|
|
In particular, we search for citations to datasets using their DOIs, titles and other metadata
|
439 |
|
|
(i.e., dates, creator names, publishers, etc.).
|
440 |
|
|
We extract parts of the text which look like citations and search for datasets using database
|
441 |
|
|
join and pattern matching techniques.
|
442 |
|
|
Based on the experiments described in the paper, precision of the dataset extraction module is
|
443 |
|
|
98.5% and recall is 97.4% but it is also probably overestimated since it does not take into
|
444 |
|
|
account corruptions that may take place during pdf to text extraction.
|
445 |
|
|
It is calculated on the extracted full-texts of small samples from PubMed and arXiv.
|
446 |
|
|
<br><br>
|
447 |
|
|
<span class="portal-color">Software extraction</span>
|
448 |
|
|
runs also on parts of the text which look like citations.
|
449 |
|
|
We search the citations for links to software in open software repositories, specifically
|
450 |
|
|
github, sourceforge, bitbucket and the google code archive.
|
451 |
|
|
After that, we search for links that are included in Software Heritage (SH,
|
452 |
|
|
https://www.softwareheritage.org) and return the permanent URL that SH provides for each
|
453 |
|
|
software project.
|
454 |
|
|
We also enrich this content with user names, titles and descriptions of the software projects
|
455 |
|
|
using web mining techniques.
|
456 |
|
|
Since software mining is based on URL matching, our precision is 100% (we return a software
|
457 |
|
|
link
|
458 |
|
|
only if we find it in the text and there is no need to disambiguate).
|
459 |
|
|
As for recall rate, this is not calculable for this mining task.
|
460 |
|
|
Although we apply all the necessary normalizations to the URLs in order to overcome usual
|
461 |
|
|
issues
|
462 |
|
|
(e.g., http or https, existence of www or not, lower/upper case), we do not calculate cases
|
463 |
|
|
where a software is mentioned using its name and not by a link from the supported software
|
464 |
|
|
repositories.
|
465 |
|
|
<br><br>
|
466 |
|
|
<span class="portal-color">For the extraction of bio-entities</span>, we focus on Protein Data
|
467 |
|
|
Bank (PDB) entries.
|
468 |
|
|
We have downloaded the database with PDB codes and we update it regularly.
|
469 |
|
|
We search through the whole publication’s full-text for references to PDB codes.
|
470 |
|
|
We apply disambiguation rules (e.g., there are PDB codes that are the same as antibody codes
|
471 |
|
|
or
|
472 |
|
|
other issues) so that we return valid results.
|
473 |
|
|
Current precision is 98%.
|
474 |
|
|
Although it's risky to mention recall rates since these are usually overestimated, we have
|
475 |
|
|
calculated a recall rate of 98% using small samples from pubmed publications.
|
476 |
|
|
Moreover, our technique is able to identify about 30% more links to proteins than the ones
|
477 |
|
|
that
|
478 |
|
|
are tagged in Pubmed xmls.
|
479 |
|
|
<br><br>
|
480 |
|
|
<span class="portal-color">Other text-mining modules</span> include mining for links to EPO
|
481 |
|
|
patents, or custom mining modules for linking research objects to specific research
|
482 |
|
|
communities,
|
483 |
|
|
initiatives and infrastructures, e.g. COVID-19 mining module.
|
484 |
|
|
Apart from text-mining modules, OpenAIRE also provides a document classification service that
|
485 |
|
|
employs analysis of free text stemming from the abstracts of the publications.
|
486 |
|
|
The purpose of applying a document classification module is to assign a scientific text one or
|
487 |
|
|
more predefined content classes.
|
488 |
|
|
In OpenAIRE, the currently used taxonomies are arXiv, MeSH (Medical Subject Headings), ACM and
|
489 |
|
|
DDC (Dewey Decimal Classification, or Dewey Decimal System).
|
490 |
|
|
<br><br>
|
491 |
|
|
<hr>
|
492 |
|
|
[1] Foufoulas, Y., Stamatogiannakis, L., Dimitropoulos, H., & Ioannidis, Y. (2017, September).
|
493 |
|
|
High-Pass Text Filtering for Citation Matching.
|
494 |
|
|
In International Conference on Theory and Practice of Digital Libraries (pp. 355-366).
|
495 |
|
|
Springer,
|
496 |
|
|
Cham.
|
497 |
|
|
</div>
|
498 |
59529
|
konstantin
|
</div>
|
499 |
|
|
</div>
|
500 |
59547
|
k.triantaf
|
<div *ngIf="!enrichmentMiningReadMore" class="uk-width-3-5@m uk-text-center clickable"
|
501 |
|
|
(click)="enrichmentMiningReadMore = true">
|
502 |
|
|
<a class="custom-explore-toggle">Read more<span uk-icon="chevron-down"></span></a>
|
503 |
|
|
</div>
|
504 |
|
|
<div *ngIf="enrichmentMiningReadMore" class="uk-width-3-5@m uk-text-center clickable"
|
505 |
|
|
(click)="enrichmentMiningReadMore = false">
|
506 |
|
|
<a class="custom-explore-toggle">Read less<span uk-icon="chevron-up"></span></a>
|
507 |
|
|
</div>
|
508 |
|
|
</li>
|
509 |
|
|
<li>
|
510 |
|
|
<img class="uk-width-2-5@m uk-align-right@m uk-margin-remove-adjacent tab-image"
|
511 |
|
|
src="assets/graph-assets/about/architecture/enrichment.svg" alt="Enrichment">
|
512 |
|
|
<div class="uk-margin-bottom uk-margin-medium-right uk-text-small">
|
513 |
|
|
The Deduction process (also known as “bulk tagging”) enriches each record with new information
|
514 |
|
|
that
|
515 |
|
|
can be derived from the existing property values.
|
516 |
|
|
<br><br>
|
517 |
|
|
As of September 2020, three procedures are in place to relate a research product to a research
|
518 |
|
|
initiative, infrastructure (RI) or community (RC) based on:
|
519 |
|
|
<ul class="portal-circle">
|
520 |
|
|
<li>subjects (2.7M results tagged)</li>
|
521 |
|
|
<li>Zenodo community (16K results tagged)</li>
|
522 |
|
|
<li>the data source it comes from (250K results tagged)</li>
|
523 |
|
|
</ul>
|
524 |
|
|
The list of subjects, Zenodo communities and data sources used to enrich the products are defined
|
525 |
|
|
by
|
526 |
|
|
the managers of the community gateway or infrastructure monitoring dashboard associated with the
|
527 |
|
|
RC/RI.
|
528 |
|
|
</div>
|
529 |
|
|
</li>
|
530 |
|
|
<li>
|
531 |
|
|
<img class="uk-width-2-5@m uk-align-right@m uk-margin-remove-adjacent tab-image"
|
532 |
|
|
src="assets/graph-assets/about/architecture/enrichment.svg" alt="Enrichment">
|
533 |
|
|
<div
|
534 |
|
|
[class]="'uk-margin-bottom uk-margin-medium-right uk-text-small '+(enrichmentPropagationReadMore ? '' : 'lines-18 multi-line-ellipsis')">
|
535 |
59529
|
konstantin
|
<div>
|
536 |
59547
|
k.triantaf
|
<div>
|
537 |
|
|
This process “propagates” properties and links from one product to another if between the two
|
538 |
|
|
there is a “strong” semantic relationship.
|
539 |
|
|
<br><br>
|
540 |
|
|
As of September 2020, the following procedures are in place:
|
541 |
|
|
<ul class="portal-circle">
|
542 |
|
|
<li>
|
543 |
|
|
Propagation of the property “country” to results from institutional repositories:
|
544 |
|
|
e.g. publication collected from an institutional repository maintained by an italian
|
545 |
|
|
university will be enriched with the property “country = IT”.
|
546 |
59529
|
konstantin
|
</li>
|
547 |
59547
|
k.triantaf
|
<li>
|
548 |
|
|
Propagation of links to projects: e.g. publication linked to project P “is supplemented
|
549 |
|
|
by”
|
550 |
|
|
a dataset D.
|
551 |
|
|
Dataset D will get the link to project P.
|
552 |
|
|
The relationships considered for this procedure are “isSupplementedBy” and “supplements”.
|
553 |
59529
|
konstantin
|
</li>
|
554 |
59547
|
k.triantaf
|
<li>
|
555 |
|
|
Propagation of related community/infrastructure/initiative from organizations to products
|
556 |
|
|
via affiliation relationships: e.g. a publication with an author affiliated with
|
557 |
|
|
organization O.
|
558 |
|
|
The manager of the community gateway C declared that the outputs of O are all relevant for
|
559 |
|
|
his/her community C.
|
560 |
|
|
The publication is tagged as relevant for C.
|
561 |
59529
|
konstantin
|
</li>
|
562 |
|
|
<li>
|
563 |
59547
|
k.triantaf
|
Propagation of related community/infrastructure/initiative to related products: e.g.
|
564 |
|
|
publication associated to community C is supplemented by a dataset D.
|
565 |
|
|
Dataset D will get the association to C.
|
566 |
|
|
The relationships considered for this procedure are “isSupplementedBy” and “supplements”.
|
567 |
59529
|
konstantin
|
</li>
|
568 |
|
|
<li>
|
569 |
59547
|
k.triantaf
|
Propagation of ORCID identifiers to related products, if the products have the same
|
570 |
|
|
authors:
|
571 |
|
|
e.g. publication has ORCID for its authors and is supplemented by a dataset D. Dataset D
|
572 |
|
|
has
|
573 |
|
|
the same authors as the publication. Authors of D are enriched with the ORCIDs available
|
574 |
|
|
in
|
575 |
|
|
the publication.
|
576 |
|
|
The relationships considered for this procedure are “isSupplementedBy” and “supplements”.
|
577 |
59529
|
konstantin
|
</li>
|
578 |
|
|
</ul>
|
579 |
59547
|
k.triantaf
|
</div>
|
580 |
59529
|
konstantin
|
</div>
|
581 |
|
|
</div>
|
582 |
59547
|
k.triantaf
|
<div *ngIf="!enrichmentPropagationReadMore" class="uk-width-3-5@m uk-text-center clickable"
|
583 |
|
|
(click)="enrichmentPropagationReadMore = true">
|
584 |
|
|
<a class="custom-explore-toggle">Read more<span uk-icon="chevron-down"></span></a>
|
585 |
59534
|
konstantin
|
</div>
|
586 |
59547
|
k.triantaf
|
<div *ngIf="enrichmentPropagationReadMore" class="uk-width-3-5@m uk-text-center clickable"
|
587 |
|
|
(click)="enrichmentPropagationReadMore = false">
|
588 |
|
|
<a class="custom-explore-toggle">Read less<span uk-icon="chevron-up"></span></a>
|
589 |
59534
|
konstantin
|
</div>
|
590 |
59547
|
k.triantaf
|
</li>
|
591 |
|
|
</ul>
|
592 |
|
|
</div>
|
593 |
|
|
<!-- </div>-->
|
594 |
|
|
<!-- <div class="uk-width-expand">-->
|
595 |
|
|
<!-- <img src="assets/graph-assets/about/architecture/enrichment.svg">-->
|
596 |
|
|
<!-- </div>-->
|
597 |
59529
|
konstantin
|
</div>
|
598 |
59547
|
k.triantaf
|
</li>
|
599 |
|
|
<li>
|
600 |
|
|
<div class="uk-text-small uk-margin-large-top">
|
601 |
|
|
<!-- <div class="uk-width-3-5@m">-->
|
602 |
|
|
<img class="uk-width-2-5@m uk-align-right@m uk-margin-remove-adjacent tab-image"
|
603 |
|
|
src="assets/graph-assets/about/architecture/post_cleaning.svg" alt="Post Cleaning">
|
604 |
|
|
<div class="uk-margin-bottom uk-margin-medium-right">
|
605 |
|
|
<p>
|
606 |
59548
|
konstantin
|
The aggregation processes are continuously running and apply vocabularies as they are in a given moment of time.
|
607 |
|
|
It could be the case that a vocabulary changes after the aggregation of one data source has finished, thus the aggregated content does not reflect the current status of the controlled vocabularies.
|
608 |
|
|
<br><br>
|
609 |
|
|
In addition, the integration of ScholeXplorer and DOIBoost and some enrichment processes applied on the raw and on the de-duplicated graph may introduce values that do not comply with the current status of the OpenAIRE controlled vocabularies.
|
610 |
|
|
For these reasons, we included a final step of cleansing at the end of the workflow materialisation.
|
611 |
|
|
The output of the final cleansing step is the final version of the OpenAIRE Research Graph.
|
612 |
59547
|
k.triantaf
|
</p>
|
613 |
|
|
</div>
|
614 |
|
|
<!-- </div>-->
|
615 |
|
|
<!-- <div class="uk-width-expand">-->
|
616 |
|
|
<!-- <img src="assets/graph-assets/about/architecture/post_cleaning.svg">-->
|
617 |
|
|
<!-- </div>-->
|
618 |
59546
|
k.triantaf
|
</div>
|
619 |
59547
|
k.triantaf
|
</li>
|
620 |
|
|
<li>
|
621 |
|
|
<div class="uk-text-small uk-margin-large-top">
|
622 |
|
|
<!-- <div class="uk-width-3-5@m">-->
|
623 |
|
|
<img class="uk-width-2-5@m uk-align-right@m uk-margin-remove-adjacent tab-image"
|
624 |
|
|
src="assets/graph-assets/about/architecture/indexing.svg" alt="Indexing">
|
625 |
|
|
<div class="uk-margin-bottom uk-margin-medium-right">
|
626 |
|
|
<p>
|
627 |
|
|
The final version of the OpenAIRE Research Graph is indexed on a Solr server that is used by the
|
628 |
|
|
OpenAIRE portals (EXPLORE, CONNECT, PROVIDE) and APIs, the latter adopted by several third-party
|
629 |
|
|
applications and organizations, such as:
|
630 |
|
|
</p>
|
631 |
|
|
<ul class="portal-circle">
|
632 |
|
|
<li class="uk-margin-small-bottom">
|
633 |
|
|
<span class="portal-color">EOSC</span>
|
634 |
|
|
--The OpenAIRE Research Graph APIs and Portals will offer to the EOSC an Open Science Resource
|
635 |
|
|
Catalogue, keeping an up to date map of all research results (publications, datasets, software),
|
636 |
|
|
services, organizations, projects, funders in Europe and beyond.
|
637 |
|
|
</li>
|
638 |
|
|
<li class="uk-margin-small-bottom">
|
639 |
|
|
<span class="portal-color">DSpace & EPrints</span>
|
640 |
|
|
repositories can install the OpenAIRE plugin to expose OpenAIRE compliant metadata records via their
|
641 |
|
|
OAI-PMH endpoint and offer to researchers the possibility to link their depositions to the funding
|
642 |
|
|
project, by selecting it from the list of project provided by OpenAIRE
|
643 |
|
|
</li>
|
644 |
|
|
<li>
|
645 |
|
|
<span class="portal-color">EC participant portal (Sygma - System for Grant Management)</span>
|
646 |
|
|
uses the OpenAIRE API in the “Continuous Reporting” section.
|
647 |
|
|
Sygma automatically fetches from the OpenAIRE Search API the list of publications and datasets in
|
648 |
|
|
the
|
649 |
|
|
OpenAIRE Research Graph that are linked to the project.
|
650 |
|
|
The user can select the research products from the list and easily compile the continuous reporting
|
651 |
|
|
data of the project.
|
652 |
|
|
</li>
|
653 |
|
|
</ul>
|
654 |
|
|
</div>
|
655 |
|
|
<!-- </div>-->
|
656 |
|
|
<!-- <div class="uk-width-expand">-->
|
657 |
|
|
<!-- <img src="assets/graph-assets/about/architecture/indexing.svg">-->
|
658 |
|
|
<!-- </div>-->
|
659 |
59546
|
k.triantaf
|
</div>
|
660 |
59547
|
k.triantaf
|
</li>
|
661 |
|
|
<li>
|
662 |
|
|
<div class="uk-text-small uk-margin-large-top">
|
663 |
|
|
<!-- <div class="uk-width-3-5@m">-->
|
664 |
|
|
<img
|
665 |
|
|
class="uk-width-2-5@m uk-align-right@m uk-margin-remove-adjacent tab-image uk-padding-large uk-padding-remove-top uk-padding-remove-horizontal"
|
666 |
|
|
src="assets/graph-assets/about/architecture/stats_analysis.svg" alt="Stats Analysis">
|
667 |
|
|
<div class="uk-margin-bottom uk-margin-medium-right">
|
668 |
|
|
<p>
|
669 |
|
|
The OpenAIRE Research Graph is also processed by a pipeline for extracting the statistics and
|
670 |
|
|
producing
|
671 |
|
|
the charts for funders, research initiative, infrastructures, and policy makers that you can see on
|
672 |
|
|
MONITOR.
|
673 |
|
|
Based on the information available on the graph, OpenAIRE provides a set of indicators for monitoring
|
674 |
|
|
the funding and research impact and the uptake of Open Science publishing practices,
|
675 |
|
|
such as Open Access publishing of publications and datasets, availability of interlinks between
|
676 |
|
|
research
|
677 |
|
|
products, availability of post-print versions in institutional or thematic Open Access repositories,
|
678 |
|
|
etc.
|
679 |
|
|
</p>
|
680 |
|
|
</div>
|
681 |
|
|
<!-- </div>-->
|
682 |
|
|
<!-- <div class="uk-width-expand">-->
|
683 |
|
|
<!-- <img src="assets/graph-assets/about/architecture/stats_analysis.svg">-->
|
684 |
|
|
<!-- </div>-->
|
685 |
59546
|
k.triantaf
|
</div>
|
686 |
59547
|
k.triantaf
|
</li>
|
687 |
|
|
</ul>
|
688 |
|
|
</div>
|
689 |
59546
|
k.triantaf
|
</div>
|
690 |
59547
|
k.triantaf
|
<div class="uk-padding-small uk-margin-top">
|
691 |
59546
|
k.triantaf
|
<h6>References</h6>
|
692 |
|
|
<ul class="uk-text-small portal-circle">
|
693 |
|
|
<li>
|
694 |
|
|
<a href="https://aka.ms/msracad" target="_blank">Microsoft Academic Graph</a>
|
695 |
|
|
which is made available under the ODC Attribution License.
|
696 |
|
|
For more information on Microsoft Academic Graph please also read
|
697 |
|
|
<a href="https://docs.microsoft.com/en-us/academic-services/graph/resources-faq" target="_blank">here</a>.
|
698 |
|
|
</li>
|
699 |
|
|
<li>
|
700 |
|
|
<a href="https://www.openaire.eu/aggregation-and-content-provision-workflows" target="_blank">https://www.openaire.eu/aggregation-and-content-provision-workflows</a>
|
701 |
|
|
</li>
|
702 |
|
|
</ul>
|
703 |
|
|
</div>
|
704 |
59534
|
konstantin
|
</div>
|
705 |
|
|
</div>
|
706 |
|
|
<div id="metrics" class="uk-container uk-container-large uk-section">
|
707 |
59546
|
k.triantaf
|
<div class="uk-padding-small">
|
708 |
59534
|
konstantin
|
<h2 class="uk-text-center">Data & Metrics</h2>
|
709 |
59539
|
konstantin
|
<h4 class="uk-text-center uk-margin-medium-top portal-color">Coming soon...</h4>
|
710 |
59546
|
k.triantaf
|
<!-- <div>-->
|
711 |
|
|
<!-- <h3 class="uk-margin-medium-top portal-color">Data</h3>-->
|
712 |
|
|
<!-- <div></div>-->
|
713 |
|
|
<!-- </div>-->
|
714 |
|
|
<!-- <div>-->
|
715 |
|
|
<!-- <h3 class="uk-margin-medium-top portal-color">Metrics</h3>-->
|
716 |
|
|
<!-- <div></div>-->
|
717 |
|
|
<!-- </div>-->
|
718 |
59529
|
konstantin
|
</div>
|
719 |
59534
|
konstantin
|
</div>
|
720 |
59548
|
konstantin
|
<div id="infrastructure" class="uk-container uk-section">
|
721 |
59546
|
k.triantaf
|
<div class="uk-padding-small">
|
722 |
|
|
<h2 class="uk-text-center">Infrastructure</h2>
|
723 |
59547
|
k.triantaf
|
<div>
|
724 |
59548
|
konstantin
|
<div class="uk-flex uk-flex-center uk-grid uk-grid-stack">
|
725 |
|
|
<!-- <div>-->
|
726 |
|
|
<p class="uk-width-4-5@m uk-padding-small">
|
727 |
60442
|
argiro.kok
|
The OpenAIRE Research Graph is operated and maintained at the <a
|
728 |
|
|
href="https://icm.edu.pl/en/centre-of-technology/" target="_blank">ICM cutting-edge Technology centre</a>
|
729 |
|
|
with the facilities and staff guaranteeing robust operation of the whole system.
|
730 |
59548
|
konstantin
|
Okeanos SuperComputer hosting the graph consists of 26016 cores in total providing 1082 Tflops/s.
|
731 |
|
|
Whole setup is energy efficient with 1.554 Gflops/Watts Power Efficiency resulting in 160th place on the "Top500 by energy-eficiency" list (as of 2019).
|
732 |
|
|
</p>
|
733 |
59550
|
k.triantaf
|
<img class="infrastructure-image uk-margin-top uk-margin-bottom" src="assets/graph-assets/about/infrastructure.png">
|
734 |
59548
|
konstantin
|
<p class="uk-width-4-5@m uk-padding-small">
|
735 |
|
|
ICM supports the continuous operation of the infrastructure including data aggregation, deduplication, inference and provision ensuring seamless 24/7 system uptime and availability.
|
736 |
|
|
System administration activities cover hardware maintenance and provisioning of the new computational resources, providing High Availability solutions to address resilience to failures by service-level redundancy and Load Balancing to distribute workloads uniformly across servers.
|
737 |
|
|
The most crucial parts of the persisted graph are covered with backups along with well defined restore procedures.
|
738 |
|
|
All the monitoring activities rely on an aggregated system-level monitoring accessible via various dashboards giving the better overview of system stability and potential requirements for system elements extension.
|
739 |
|
|
System level monitoring is supplemented with monitoring availability of all the publicly accessible endpoints.
|
740 |
|
|
Hence, the offer of the public API of OpenAIRE to third parties, is of high-standards.
|
741 |
|
|
</p>
|
742 |
|
|
<p class="uk-width-4-5@m uk-padding-small">
|
743 |
|
|
All the maintenance operations undertaken by experienced system administrators are founded on well established routines and emergency maintenance procedures.
|
744 |
|
|
</p>
|
745 |
|
|
|
746 |
|
|
<!-- The OpenAIRE graph operates based on a vast variety of hardware and software. As of December 2019, the-->
|
747 |
|
|
<!-- hardware infrastructure is the following:-->
|
748 |
|
|
<!-- </p>-->
|
749 |
|
|
<!-- </div>-->
|
750 |
59546
|
k.triantaf
|
</div>
|
751 |
59529
|
konstantin
|
</div>
|
752 |
|
|
</div>
|
753 |
59534
|
konstantin
|
</div>
|
754 |
|
|
<div id="team" class="uk-container uk-container-large uk-section">
|
755 |
59546
|
k.triantaf
|
<div class="uk-padding-small">
|
756 |
|
|
<h2 class="uk-text-center">Team</h2>
|
757 |
|
|
<div>
|
758 |
|
|
<div class="uk-margin-bottom">
|
759 |
59548
|
konstantin
|
<!-- <div class="uk-flex uk-flex-middle uk-grid" uk-grid="">-->
|
760 |
|
|
<!-- <div class="uk-text-center uk-width-1-1@s uk-width-1-3@m uk-first-column">-->
|
761 |
|
|
<!-- <img src="assets/graph-assets/about/team.svg">-->
|
762 |
|
|
<!-- </div>-->
|
763 |
59529
|
konstantin
|
|
764 |
59548
|
konstantin
|
<img class="uk-align-center uk-align-left@m uk-margin-remove-adjacent"
|
765 |
|
|
src="assets/graph-assets/about/team.svg" alt="Team">
|
766 |
|
|
|
767 |
|
|
<div class="uk-text-center uk-width-1-2@m uk-align-center uk-margin-remove-adjacent">
|
768 |
|
|
<div class="uk-margin-medium-bottom">
|
769 |
|
|
Key team members contributing to the Research Graph
|
770 |
59546
|
k.triantaf
|
</div>
|
771 |
59548
|
konstantin
|
<div>
|
772 |
|
|
<a class="uk-button portal-button" target="_blank" href="https://www.openaire.eu/research-graph-team">
|
773 |
|
|
Meet the team
|
774 |
59568
|
k.triantaf
|
<icon name="arrow_right" ratio="0.8" class="space"></icon>
|
775 |
59548
|
konstantin
|
</a>
|
776 |
|
|
</div>
|
777 |
59534
|
konstantin
|
</div>
|
778 |
59548
|
konstantin
|
<!-- </div>-->
|
779 |
59529
|
konstantin
|
</div>
|
780 |
|
|
</div>
|
781 |
|
|
</div>
|
782 |
59534
|
konstantin
|
</div>
|
783 |
59537
|
k.triantaf
|
</div>
|