dataesr/scientific-paragraphs-categorization huggingface dataset:
Therefore, whenever possible, a caching strategy should be defined with respect to the expected performance. There typically exist many syntactical variants of the same SPARQL query, hence classic HTTP cache servers set up between SPARQL clients and servers fail to reach efficient cache reuse. By contrast, Web API queries allow a lesser syntactical variability. Thus, in the context of SPARQL micro-services, enforcing a cache strategy on the Web API side should ensure better cache reuse. Our prototype enforces a simple cache strategy where each Web API response is stored in a cache database, indexed with a hash of the Web API query, and annotated with an expiration period that can be configured on a per-micro-service basis. Our live deployment utilizes the MongoDB document store as a cache database, yet using any other database may be achieved with little changes.
Besides, future developments may consist in adapting the caching strategy based on the data expiration information provided by some Web APIs (such as the Expires, Cache-Control, and/or Last-Modified HTTP headers). Docker Deployment. In addition to the code available on GitHub, we have created a Docker image published on Docker Hub (https://hub. docker. com/u/frmichel/): It provides an Apache Web server configured with the SPARQL micro-services described in Section 5. Note that, for the sake of simplicity, we have defined a single image hosting several micro-services. Nevertheless, more in line with common micro-service practices, it would make sense to define one image per service, enabling the independent deployment of each service. As instructed in the GitHub README, a single command is sufficient to deploy this image on a Docker server.
3. macaulaylibrary/getAudioById retrieves audio recordings for a given species identifier from the Macaulay Library (https://www. macaulaylibrary. org/), a scientific media archive related to birds, amphibians, fishes, and mammals. 4. musicbrainz/getSongByName searches the MusicBrainz music information encyclopedia (https: //musicbrainz. org/) for music tunes whose title match a given name with a minimum confidence of 90%. Test Environment. The tests were performed on a CentOS Linux 7. 5 server running on a virtual machine equipped with 4 CPU cores (3. 50 GHz) and 32 GB of RAM. The SPARQL micro-services were served by an Apache 2. 4 Web server. The server also hosted two additional services required for the experimentation: The Corese-KGRAM RDF triple store used to store temporary graphs and the MongoDB document store used as a cache database.
Column "Triples produced" of Table  1  gives the number of triples generated by applying subsequently the JSON-LD profile to the API response and the optional INSERT query (to spawn additional triples). It is interesting to notice that the overhead imposed by the SPARQL micro-service (in orange in Figure  5 ) always remains low, ranging from 25 ms to 80 ms. It accounts for 4. 11% of the total time for Macaulay library's API to 25. 5% for MusicBrainz's API which is by far the fastest of the four APIs. We then performed a second run of the same queries using the cache database. The cache expiration duration was set to several days and a warm-up run was executed to ensure systematic cache hits. Table  2  reports the execution time for each SPARQL micro-service without and with cache, and the last column gives the percentage of time reduction obtained when using the cache.
Not surprisingly, the reduction is substantial since there is no more invocation of the Web APIs, only a document fetch operation from the local MongoDB database. The reduction ranges from 31. 7% for MusicBrainz' API to 91. 5% for Macaulay Library's API. Figure  6  depicts the same measures where the orange part represents the SPARQL micro-service execution with a cache database, while the blue part represents the additional time taken by the cacheless execution.
In chronological order the MusicBrainz micro-service was invoked once, Macaulay Library once, Flickr 27 times and BHL 395 times. We discussed this issue with Virtuoso's developers (Virtuoso GitHub issue: https://github. com/openlink/virtuoso-opensource/issues/724) who could not bring a clear explanation so far. Nevertheless, further tests with two or three SERVICE clauses suggested that each SERVICE clause is invoked one time for each solution retrieved from previously evaluated SERVICE clauses. This ends up with a very inefficient multiplication of the invocations. We also tested another version of Q 1 that consists of a union of the four SERVICE clauses rather than the conjunction thereof. This query should return the same results since all four SERVICE clauses are independent. This however did not change Virtuoso's behavior that kept generating a useless multiplication of the invocations.
org / musicbrainz / getSongByName ? \ name =" , encode_for_uri encode_for_uri encode_for_uri (? species ))) as ? mzbrnz ) SERVICE SERVICE SERVICE ? bhl { ? article s : name ? articleTitle ; s : author ? author. } SERVICE SERVICE SERVICE ? flickr { ? photo s : contentUrl ? img. } SERVICE SERVICE SERVICE ? macaulay { ? audio s : contentUrl ? audioUrl. } SERVICE SERVICE SERVICE ? mzbrnz { [] s : sameAs ? mbzPage ; s : name ? mbzTitle. } } Listing 6. Query Q 2. Invocation of a SPARQL micro-service using a variable endpoint URL: variables ?bhl, ?flickr, ?macaulay and ?mzbrnz are built dynamically using the species name in variable ?species. The evaluation of Q 1 by Corese-KGRAM took an average 3. 66 s without using the cache database, while the four individual invocations sum up to 2. 59 s (2nd column of Table  2 ).
Aggregating Various Types of Data Related to Biological Taxa Many existing data aggregators in the biodiversity domain consolidate data with respect to a certain perspective (species occurrences, life traits, taxonomy etc. ) from multiple sources. Yet, orthogonal approaches lack that which would allow biologists to aggregate and visualize data spanning these different perspectives. To address this need, we have designed an application that provides biologists with a convenient way to get a quick outlook at the various types of data collected by independent biodiversity programs about a given taxon. In a joint initiative with the French National Museum of Natural History, we have produced a dataset called TAXREF-LD  [29] , a Linked Data representation of TAXREF  [30] , the French taxonomic register for fauna, flora, and fungus (https://inpn.
mnhn. fr/programme/referentiel-taxonomiquetaxref?lg=en). It models 236. 000+ biological taxa along with the 509. 000+ scientific names used to refer to the taxa. TAXREF-LD is accessible through a public SPARQL endpoint (TAXREF-LD public SPARQL endpoint: http://taxref. mnhn. fr/sparql), and the URIs of all taxa and scientific names are dereferenceable. In the application we present here, a SPARQL CONSTRUCT query (the full query is available at https://github. com/frmichel/sparql-micro-service/tree/0. 1. 0/demo/query/query. rq) first retrieves from TAXREF-LD the information available about the taxon that bears a given scientific name. Then, it enriches TAXREF-LD's taxon description with data from five SPARQL micro-services: BHL, Flickr, Macaulay Library, and MusicBrainz already described in Section 5, and the additional eol/getTraitsByTaxon service that retrieves life traits related to a taxon's scientific name from the Encyclopedia of Life trait bank  [31].
The RDF graph resulting from this query exhibits URIs identifying each BHL article, each Flickr photo and each Macaulay audio recording. These URIs are built upon the Web API's internal identifier. They are made dereferenceable according to the mechanism we described in Section 4. 2: While the micro-services invoked in the SPARQL query retrieve information by scientific name, complementary micro-services retrieve information by Web API's identifier. To do the wiring, the Web server is configured to rewrite a look up query on one of those URIs into the relevant micro-service invocation. In a next step, the result RDF graph is transformed into an HTML page using the SPARQL Template Transformation Language (STTL)  [32]. For each resource retrieved by SPARQL micro-services (e. g. , a photo, an article), a SPARQL Template query fetches data from the result graph and passes it on to an HTML template tailored for the resource type.
In turn, the latter produces the piece of HTML code necessary to properly display the resource (the code of the STTL transformations is available on GitHub under https://github. com/frmichel/sparql-micro-service/tree/0. 1. 0/demo). For instance, a photo is rendered as one element of a carousel while an audio recording is rendered using an HTML5 audio player. A global template assembles the partial HTML snippets to form the final HTML page. Figure  7  depicts a part of the HTML page generated for species Delphinapterus leucas.
To tackle this issue, the French Museum of Natural History has developed the TAXREF-Web application (https://taxref. mnhn. fr/taxref-web/) enabling biologists to edit biological taxa's information available in TAXREF. The application offers forms not only to edit TAXREF's database, but more importantly to display data collected from other programs, compare it with TAXREF's data and provide biologists with the ability to add, remove or amend data accordingly. To do so, TAXREF-Web's developers have to write a specific piece of code to query each Web API of interest and manually align the data elements within its results with the corresponding data elements within the results of the other Web APIs. For instance, TAXREF's Web API codes the habitat wherein a species lives as an integer (e. g. , 1 stands for marine environment, 2 for fresh water).
By contrast, the World Register of Marine Species (http://www. marinespecies. org) (WoRMS) codes the same information as multiple Boolean fields (e. g. , isMarine, isFreshwater). Therefore, TAXREF-Web's code must carry out a cumbersome alignment to convert from one representation into the other. This approach is time-consuming in terms of development and maintenance, and hardly scales to many more Web APIs. In its current status, the TAXREF-Web application queries the following programs: WoRMS, Fishbase (http://fishbase. org), Index Fungorum (http://www. indexfungorum. org/), Pan-European Species directories Infrastructure (http://www. eu-nomen. eu/pesi/) (PESI), and World Spider Catalogue (https://wsc. nmbe. ch/). Depending on the programs, the Web interface may simply present a link to the program's corresponding Web page, point out a disagreement, or point out a disagreement along with the means for a biologist to update TAXREF accordingly.
Let us assume that we have defined SPARQL micro-services for TAXREF and WoRMS Web APIs (TAXREF's Web API allows querying TAXREF's database; it is exploited by the TAXREF-Web application), whose invocations produce the graphs depicted in Listings 7 and 8 respectively. According to TAXREF, Acetabularia crenulata is a reference (or "accepted") name, whereas according to WoRMS, it is a synonym name and the reference name should be Acetabularia (Acicularia) crenulata instead. Detecting this disagreement can be achieved easily using SPARQL query Q 3 in Listing 9. The query searches solutions where Acetabularia crenulata would have status accepted in TAXREF and a different status in WoRMS. If Q 3 returns a non-empty solution set, then both sources disagree and the solution provides the reference name according to WoRMS.
In turn, the Web application must point out this disagreement and provide the user with a way to accept or dismiss this change. Figure  8  depicts an extract of TAXREF-Web's edition page where this option is denoted by the red button "MAJ REF" (update reference name). A similar SPARQL query (not shown here) can detect a disagreement with respect to the author's name spelling, "J. V. Lamour. " in TAXREF and "J. V. Lamouroux" in WoRMS. The red button "MAJ AUTEUR" (update author) allows to acknowledge this change in TAXREF. Let us finally mention that example query Q 3 may be invoked on the Web server side, as part of the HTML page generation process, as well as on the client side using asynchronous queries processed in JavaScript. An advantage of the latter is to alleviate the load required to generate the page on the server's side.
Hydra, used in conjunction with JSON-LD, forms a basis to build hypermedia-driven Linked Data interfaces  [35]. This basis can be harnessed to turn existing Web APIs into RESTful Linked Data interfaces whose documentation can be interpreted at run time by a generic Hydra client. Our incentive with SPARQL micro-services is to provide client applications with the whole expressiveness of the SPARQL Query language, which would be more difficult to achieve using a Hydra-described REST interface. Closer to our work, Linked REST APIs  [36]  is a framework dedicated to the semantic annotation of Web APIs and the automatic specification of SPARQL query execution plans that invoke these Web APIs. A major difference with our approach is that the framework requires the deployment of a middleware that stores the Web APIs descriptions and their mapping towards domain ontologies, and computes and enacts query execution plans.
(i) SPARQL-Generate is an extension of SPARQL, hence, by definition, it is not supported by engines strictly complying with the SPARQL Query language. By contrast, our vision is that multiple service providers could publish independent SPARQL micro-services, thereby building up an ecosystem of services all complying with standard SPARQL; (ii) SPARQL-Generate offers the advantage that querying remote data sources is performed within a single language. On the one hand, this only requires skills with Semantic Web technologies. On the other hand, this entails that a significant part of the whole process is left to the SPARQL client: Querying the data source while providing necessary arguments, and translating its proprietary vocabulary into RDF triples aligned on common vocabularies. Consequently, as illustrated by authors' examples, the additional syntactic sugar required can make queries considerably cumbersome and difficult to maintain.
We take a different option where this complexity is hidden from the client and handled by the SPARQL micro-service developer. An approach very similar to SPARQL-Generate is proposed in  [38]. It is based on the BIND_API clause, an extension of the SPARQL BIND clause, that binds a set of variables with values extracted from a Web API response. It suffers the same pitfalls as SPARQL-Generate with respect to our goals: The use of non standard SPARQL Query Language and the cumbersome syntactic sugar left to the SPARQL client. ODMTP  [39] , On-Demand Mapping using Triple Patterns, is an attempt to query non-RDF datasets as Triple Pattern Fragments. The authors have implemented a prototype to query Twitter's Web API, that can process triple pattern queries over the whole Twitter's dataset. Conversely, SPARQL micro-services support arbitrary SPARQL queries over restricted fragments of the Web API dataset.
Besides, unlike SPARQL micro-services, ODMTP cannot assign dereferenceable URIs to Web API resources. Nevertheless, ODMTP offers the TPF's paging mechanism that SPARQL micro-services should regard as a valuable extension within future works (see the discussion in Section 8). Our implementation of SPARQL micro-services maps a Web API response to RDF triples in two steps: The response is first translated to JSON-LD, then a SPARQL INSERT or CONSTRUCT query complements the process for cases where JSON-LD is not expressive enough. Alternatively, we could rely on a mapping description language such as RML  [40]  and xR2RML  [41] , but they require the developer to learn the mapping language. By contrast, in our proposition we strove to rely only on existing standards. Let us finally mention the Apache Marmotta project (http://marmotta.
X-ray diffraction imaging: data analysis pipeline 2. 1. Beamline hardware 2. 1. 1. Pilatus3 2M CdTe detector. The ID15a beamline at the ESRF uses mainly a Pilatus3 2M detector with a 1000 mm CdTe sensor, manufactured by Dectris  (Kraft et al. , 2009). The detector is made up of 8 Â 3 Pilatus modules (100 kilopixels each). Unlike silicon-based sensors, there are two Cd-Te wafers bump-bound to every single Pilatus module, with a gap of 3 pixels between the wafers. The gaps between the Pilatus modules are the same as in the silicon-based detectors, i. e. 7 pixels vertically and 17 pixels horizontally. This detector is sold with a detector-PC which is in charge of compressing and saving the images on the network. This detector-PC comes with a 10 Gbit s À1 network card and is directly connected to the data analysis server.
2. 1. 2. The data analysis computer. The data analysis computer (Fig. 2 ) acts as an NFS (network file server) server over RDMA (remote direct memory access) for optimal performance with the detector and is directly connected to the GPFS (general parallel file-system) storage cluster  (Schmuck & Haskin, 2002). This data analysis computer has two Intel Xeon E5-2643 v3 processors, each with six cores and 20 MB of cache, and 128 GB of memory. There are additionally two 10 Gbit network cards, a fast Intel P3700 solid-state drive (SSD) and an Nvidia Titan-X graphics card, all connected on the PCI-express bus.
7. While GPUs targeted by this implementation have thousands of cores, this algorithm remains valid regardless of the number of cores. Our implementation, based on pyOpenCL  (Klo ¨ckner et al. , 2012) , has been validated on different architectures like Nvidia GPUs, integrated graphics processors (Intel Iris) found in laptops and multi-core processors (Intel, AMD and Apple OpenCL drivers). The strength of this approach resides in the limited amount of data to be sent to the GPU memory, which allows decompression and integration to be performed on the device without additional transfer over the PCI-express bus (which is the bottleneck for pyFAI). The performance of this parallel decompression of CBF images on a high-end GPU has been compared with the serial implementation. For large images that do not fit in the cache memory of the processor (typically for the Pilatus 6M images), the speed-up of this GPU version is important (10Â).
Acknowledgements This work has been sponsored by the materials diffraction beamline at  ESRF (ID15a). We would like to thank  Gavin Vaughan  and  Marco Di Michiel  for providing the test data set composed of 1202 images. We would like to thank  V. Armando Sole  ´, head of the Data Analysis Unit and leader of the silx project. Finally, we would like to acknowledge the contribution of all other members of the silx project:  Henri Payno ,  Damien Naudet ,  Pierre Knobel ,  Valentin Valls  and  Pierre Paleo  for the great team work.
For example, Netflix has a Spark cluster of over 8000 machines processing multiple petabytes of data in order to improve the customer experience by providing better recommendations for their streaming services  [5]. On the other hand, high performance computing (HPC) systems recently gained a huge interest as a promising platform for performing fast Big Data processing given their high performance nature  [1, 17]. HPC systems are equipped with lowlatency networks and thousands of nodes with many cores and therefore have the potential to perform fast Big Data processing. For instance, PayPal recently shipped its fraud detection software to HPC systems to be able to detect frauds among millions of transactions in a timely manner  [26]. However, when introducing Big Data processing to HPC systems, one should be aware of the different architectural designs in current Big Data processing and HPC systems.
Big Data processing systems have shared nothing architecture and nodes are equipped with individual disks, thus they can co-locate the data and compute resources on the same machine (i. e. , data-centric paradigm). On the other hand, HPC systems employ a shared architecture (e. g. , parallel file systems)  [19]  which results in separation of data resources from the compute nodes (i. e. , compute-centric paradigm). Figure  1  illustrates these differences in the design of these two systems. These differences in the design of these two systems introduce two major challenges: Big Data applications will face high latencies when performing I/O due to the necessary data transfers between the parallel file system and computation nodes. Moreover, I/O contention (i. e. , performance degradation observed by any single application/task running in contention with other applications/tasks on the same platform  [15, 33] ) is a well-known problem in HPC systems which often detracts the performance of a single-application  from the high performance offered by these systems due to their large sizes and shared architecture  [16, 18, 25, 33].
In response, several efforts have been conducted to leverage Spark for fast Big Data processing on HPC systems. These works have mainly tried to alleviate the high latency problem by focusing on the intermediate data storage (i. e. , map output for batch jobs and temporary output produced between stages for iterative jobs)  [12, 21, 28, 32, 34]. For example, Islam et al. [21]  utilized NVRAM as an intermediate storage layer (i. e. , burst buffer) between compute nodes and Lustre file system  [14]. This brought 24% improvement to the application performance by reducing the latency when reading/writing the intermediate data. However, Big Data applications mostly run in batches and there is a continuous interaction with the parallel file system for reading the input data and writing the output data, thus it is important to study the impact of latency on the performance of Big Data applications by considering the different phases of Big Data applications as input, intermediate and output data.
We find that resulting latency during the data movement between compute nodes and parallel file system can degrade the application performance seriously. Specifically, we show evidence that the high latency of reading the input data and writing the output data to the parallel virtual file system (PVFS)  [27]  have higher impact on performance degradation compared to the intermediate data. -The role of contention on the application performance. Our results show that contention can result in severe performance penalties for Big Data applications on HPC systems due to employing a shared storage system. -An analysis of the impact of the file system specific properties on the application performance. Similar to  [12]  which shows that metadata operations in Lustre file system  [14]  create a bottleneck for Spark applications, we demonstrated that synchronization feature of PVFS  [27] , which can be necessary for providing resilience, can reduce the application performance dramatically by 14x.
The OrangeFS file system (a branch of PVFS2  [27] ) version 2. 8. 3 was deployed on 12 nodes of the parasilo cluster. We set the stripe size which defines the data distribution policy in PVFS (i. e. , analogous to block size in HDFS) to 32 MB in order to have a fair comparison with HDFS. Unless otherwise specified, we disabled the synchronization for PVFS (Sync OFF) which indicates that the incoming data can stay in kernel-provided buffers. We opted for Sync OFF configuration since Spark is also using the memory as a first storage level with HDFS.