dataesr/scientific-paragraphs-categorization huggingface dataset:
Choice of RDF Store The requirements discussed in Sect. 3. 4 severely limited the possible alternatives for the selection of an RDF store. Most of the distributed RDF stores that were mature and had good scalability were only available under commercial licenses. The only open-sourced distributed mature RDF stores that are released a free-to-use license are 4store and Bigdata, which show comparable performance results in internal BSBM tests run on the prototype hardware. Based on the observations presented in this section, a choice was made to integrate 4store as a storage option in the RedSIB software.
Implementation and Evaluation As motivated from previous sections, 4store was identified as the only viable addition to the array of RDF storage options for the Smart-M3 platform and the RDF store was subsequently integrated as a storage option in the RedSIB software during a two month time period. This section presents a rough overview of the integration of 4store into the RedSIB software. This presentation is followed by an evaluation of the implementation in comparison to the default RDF storage option in RedSIB. 4store Integration into Smart-M3. As the RedSIB software almost exclusively uses the Redland libraries for handling all its storage needs, it was a natural choice to integrate 4store to the RedSIB software through the Redland storage library. An overview of the logical structure on how the integration of 4store into Smart-M3 was accomplished is outlined in Fig.
3. The additions that were created are: the 4store C front end, which serves as an interface to the functions in the 4store front end; the 4store Model/Storage inside the Redland storage library, which is used to perform database operations on the 4store back end; and the 4store Query module inside the Redland storage library, which is used to evaluate SPARQL queries on the 4store back ends. 4store C Front End. At the start of the implementation, the only interfaces available for accessing the 4store back ends was either through a HTTPS front end [10] or through a command line front end. As these interfaces are not suitable to be used in the Redland storage library, the first point of action was to create a separate 4store front end with C bindings. The aim with the new front end was to support the functionality of both the 4store Model/Storage module and the 4store Query module.
A list of the functionality that the 4store C front end should support is presented below: -creation of connections to 4store back ends -addition of individual triples -bulk insertion of triples -removal of individual triples -removal of entire named graphs -evaluation of SPARQL queries The front end was implemented as a Linux shared library. The shared library was based on, unrelated to the work done towards this chapter, work done by the Perl Community during a Perl Hackathon event in London 2012. The original library had the functionality of supporting basic triple matching operations and was aimed to be an addition to the Trine framework  [11]. As the syntax for RDF::Trine is very similar to that of the Redland storage API, most of the work performed in the original library could be used directly with only minor modifications.
The additions made especially for the librdf integration consisted of functionality for adding and removing triples and performing SPARQL queries on 4store back ends. Transactional support was not included as it is not yet supported in 4store, but it could be added to the 4store C front end if the support for it was added to the 4store software in the future. Integration of 4store into the Redland Libraries. After the appropriate functionality had been added to the 4store C front end, the integration of 4store into the librdf library was started. First the 4store Model/Storage module was integrated and when it was completed, the integration of the 4store Query module followed. 4store uses the Raptor  [16]  library to parse and serialize RDF data and the RASQAL  [17]  library to parse SPARQL queries that both are part of the Redland library collection.
A more in-depth description of the modules and their functionality can be found in an article by Dave Beckett released in 2001  [23]. For simplicity purposes, the Model and the Storage modules are treated as a single module in this work. Model/Storage modules inside librdf give a limited number of functions that can be called from applications to perform actions on the underlying storage. The functions can be grouped based on their functionality into actions that are related to the creation, initialization and closing of connections to the underlying storage module, the addition and removal of statements to and from the storage module, fetching of triples from the storage using triple matching patterns and the optional transactional and statement context-related functionality. The 4store Model/Storage module was implemented in a similar fashion to the respective Virtuoso Model/Storage module.
The functions provided in the Model/Storage module are transformed into the appropriate 4store C front end operations that ensure that the relevant actions are performed in the 4store knowledge base. 4store Query Module. The librdf has an internal query handler module in librdf for query processing and an external query module for using the RDF stores own query engine. The librdf internal query processing in librdf is performed by translating the SPARQL query into corresponding RASQAL statements that can be evaluated on the storage module. The functionality of the internal query processing only encompassed a limited set of the SPARQL language with most of the SPARQL 1. 1 features yet to be implemented at the moment. For native RDF stores that implement their own query engine, the internal query processing in librdf can be considerer to be rather inefficient as a result of fact that the query optimization of the query engine in librdf is done based on the in-data structures of the embedded storage modules.
LUBM Experiment Setup. The test queries ware performed on the Smart-M3 system using data generated with the LUBM data generator using options for 1 and 10 universities. The LUBM dataset size for one university option consists of approximately 100K triples and the dataset for the ten universities option consists of approximately 1,2 million triples. The 14 text queries from the LUMB test suite was then performed on the Smart-M3 system with the BDB and 4store storage options through the Smart-M3 Python KPI interface.
LUBM Experiment Results. The results from the benchmark are displayed in Figs. 4  and 5  below. Missing from the figure are the results from the BDB option as they could not be produced with that storage option. Even with the smaller dataset, none of the queries could successfully be performed when the BDB storage was used. As can be noted in Figs. 4  and 5  above, the query execution times are not that affected by the number of 4store back end nodes that are used in small to moderately sized datasets. The main advantage of the distributed 4store knowledge base is that it makes the system as a whole capable of storing larger datasets. The inability of the Smart-M3 system with the BDB storage option to produce results even with the smallest dataset clearly points out the limitations of the query capabilities for the default storage option in the Smart-M3.
The implementation of the Smart-M3 query modules can take SPARQL queries and execute them without any major overhead compared to running the queries directly through the other 4store front end. SPARQL UPDATE operations were not implemented in the 4store query module in librdf as the knowledge base modification operations that are already present in the librdf storage module were considered sufficient to serve the needs of the smart space. As can be noted from the experiment results, the 4store storage option in Smart-M3 can serve significantly larger dataset sizes than the default storage option of the Berkeley DB. With regards to this, the 4store storage option in Smart-M3 can be considered successful. An unanticipated flaw detected in 4store during the implementation was that the inserting of individual triples is a highly inefficient process compared to the bulk insertion of triples.
Further characterization of novel viruses Several viruses for which a near complete genome (at least the complete coding regions) could be identified were selected for further phylogenetic analysis. The names and abbreviations of the novel viruses and their taxonomic annotation by DIAMOND and KronaTools are shown in Table  2. Furthermore, the obtained viral genome length and accession number of each species identified in this study as well as the name, genome length, and accession number of their most closely related reference genomes are shown in Additional file 6. Interestingly, several of these viruses were identified in both 2016 and 2017, as well as in both locations (Fig. 4 , Additional file 7).
Mononegavirales-related viruses Aedes aegypti anpheviruses (AANV) identified in both Ae. aegypti samples of 2016 and 2017 had 99% aa identity with the reference in GenBank. In addition, we identified two distantly related Guadeloupe mosquito mononega-like viruses (GMMLV) in the unusual mosquito (Ab-AAF-1-3). These GMMLV1 and GMMLV2 sequences had 37% and 52% amino acid similarity with Culex mononega-like virus 2 (CMLV2), respectively. In the phylogenetic tree, GMMLV1 is located in a new clade, which was more distant from GMMLV2 and CMLV2 (Fig. 5d ).
bidens cox1 genes (as did all the true Ae. aegypti samples), suggesting that this mosquito belonged to a mosquito species whose cox1 gene was not present in databases. In addition, the cox1 genes of two fungi (Microbotryum lychnidis-dioicae and Pleurotus ostreatus) were also detected at low levels in Cx. quinquefasciatus. The cox1, gyrB, and recA genes of endosymbiotic bacteria Wolbachia sp. strain wPip were all found to be prevalent in Cx. quinquefasciatus samples and pools. Specifically, the sample PB-CQF-1-5 also possessed the marker genes of Chromobacterium violaceum and Cupriavidus taiwanensis, which are abundant components of the soil and water in tropical and subtropical regions  [31, 32] , and were therefore bacteria likely obtained from the environment.
Twenty-four bacteriophage contigs were significantly correlated with the marker genes of Wolbachia sp. strain wPip and Cx. quinquefasciatus. Additionally, the three contigs classified as the L, M, and S segments of a member of the Cystoviridae, an additional 7403 bp contig as well as cox1 genes of Cx. quinquefasciatus clustered together. This suggested that the potential bacterial host of this phage was symbiotic in Cx. quinquefasciatus. Unfortunately, no bacterial marker genes could be detected, which might be due to the fact that no genomic DNA of this bacterium survived our procedures, or its marker genes are not present in databases. One of the natural hosts of Cystoviridae are members of the Pseudomonas genus (https://viralzone. expasy. org/165), commonly found in gut microbes of malaria mosquitoes  [33] , which suggests the potential existence of Pseudomonas bacteria in Cx.
quinquefasciatus. To further substantiate the prokaryotic host prediction of these phage genomic contigs, we used WIsH  [34] , a program that predicts the prokaryotic host of genomic phage contigs based on trained Markov models and kmer frequencies. From their benchmark results, WIsH predicts hosts for 90% of the phage sequences (> 3kbp) with 80% accuracy at the genus level at a p value threshold of 0. 001  [34]. Among the 33 phage contigs (from Fig. 7b ), 16 contigs had a p value lower than 0. 001 and all their predicted hosts belonged to the genus Wolbachia (Additional file 11), consistent with the correlation analysis (Fig. 7b ). The WIsH-predicted host of the other eight contigs (which were correlated with Wolbachia marker genes in Fig. 7b ), were also predicted to belong to the genus Wolbachia with higher p values ranging from 0.
Since our study was designed for virome analysis, only the (small) bacteria whose genomic DNA survived the NetoVIR protocol could be identified through marker gene detection. Due to the lack of the bacterial genomes from our samples, the WIsH prediction can only run on the selected bacterial genomes from database, which will fail to predict the host of novel phage sequences if the host bacterium is not present in the bacterial dataset. The three phage contigs of Cystoviridae (Fig. 7b ) whose natural host is the genus Pseudomonas (https://viralzone. expasy. org/165) had highest log-likelihood with Pseudomonas savastanoi among the tested 37 bacterial genomes, but the p values were only around 0. 4 (Additional file 11), which suggests that the genome of the host Pseudomonas strain (or another bacterium) present in our mosquito samples is rather divergent compared to those in the database.
Bioinformatic analysis of eukaryotic virome and phageome The obtained raw paired-end reads were trimmed for quality and adapters using Trimmomatic  [62]. Reads mapping to a set of contaminating contigs known to be present in the negative controls (contamination of reagents) were removed using BWA  [63]  and the remaining reads are de novo assembled into contigs using SPAdes  [64]. Contigs from all pools longer than 500 bp were clustered to remove redundancy at 95% nucleotide identity over 80% of the length using Cluster-Genomes (https://bitbucket. org/MAVERICLab/dockerclustergenomes). These non-redundant (nr) contigs collection was classified using DIAMOND  [65]  against the nr database on sensitive mode for taxonomic annotation. KronaTools  [66]  were used to parse the output file of DIAMOND, which found the least common ancestor of the best 25 DIAMOND hits (based on BLASTx score) for each contig.
All contigs annotated as eukaryotic virus were extracted using an in-house python script. Bacteriophages were identified using combined approaches including BLASTn  [67] , DIAMOND, as well as Meta-Phinder2 (ANI ≥ 10%)  [68]  and VirSorter (category 1 and 2)  [69]. Hmmsearch against the Prokaryotic Virus Orthologous Groups (pVOGs), eggNOG-mapper, and PfamScan were further used to confirm the bacteriophage contigs identified by MetaPhinder2 and VirSorter. The contigs without pVOGs hits or phage-associated proteins/domains were classified to bacteriophage to be confirmed (bacteriophageTBC). Individual pool magnitudes were obtained by mapping trimmed and decontaminated reads to the nr contigs collection using BBMap (https:// github. com/BioInfoTools/BBMap). Abundance tables for eukaryotic viruses and bacteriophages were extracted respectively and further used for ecological analysis in R with the ggplot2  [70] , phyloseq  [71] , metagenome-Seq  [72] , microbiomeSeq (https://github.
Virus identification and phylogenetic analysis ORF Finder was used to identify ORFs in the obtained eukaryotic viral contigs, and contigs believed to represent the complete coding capacity of a viral genome were selected  [74]. To identify different variants of these viruses in the individual samples, the trimmed and decontaminated reads of individual samples and pools were mapped to those selected genomes (Table  2 ). Amino acid sequences of RdRp or PB1 were used to determine the evolutionary history of the discovered viruses together with appropriate reference strains from GenBank. Alignments of the viral RdRp or PB1 were performed with MAFFT v7. 222  [75]  using the E-INS-I algorithm. Ambiguously aligned regions were then removed by trimAl v1. 2  [76]  using automated trimming heuristic, which is optimized for maximum likelihood (ML) phylogenetic tree reconstruction.
The best-fit model of amino acid substitution was subsequently determined by ProtTest v3. 4. 2  [77]. ML phylogenetic trees are constructed by PhyML v3. 1  [78] , employing the bestfit substitution model and Subtree Pruning and Regrafting (SPR) as tree topology improvement algorithm. Branch supports were computed by approximate likelihood ratio test (aLRT) with SH-like support as implemented in PhyML. Phylogenetic trees were drawn from the PhyML results with FigTree v1. 4. 3 (https://github. com/rambaut/figtree/releases).
Prevalence of core viruses Seventy-two Ae. aegypti and 24 Cx. quinquefasciatus individuals collected in 2017 (Table  3 ) were used to determine the prevalence of a selection of highly abundant viruses. These viruses were Phasi charoenlike phasivirus (PCLPV), Guadeloupe mosquito virus (GMV), Guadeloupe Aedes aegypti totivirus (GAATV), Aedes aegypti anphevirus (AANV), Guadeloupe Culex rhabdovirus (GCRV), and Guadeloupe Culex tymo-like virus (GCTLV). The specific primers and probes of each virus (Additional file 10)were designed from the alignment of all nearly complete genomes recovered from NGS data using GenScript Real-time PCR (TaqMan) Primer Design (https://www. genscript. com/tools/real-time-pcr-tagman-primer-design-tool). Viral RNA was isolated from individual mosquitoes, eluted in 60 μl elution buffer (QIAGEN Viral RNA mini kit) and subsequently tested for each virus by qRT-PCR in duplicate.
Marker genes detection and correlation analysis All cytochrome c oxidase I (cox1), DNA gyrase subunit B (gyrB), and recombinase A protein (recA) genes were downloaded from NCBI, and then the redundant and cox1 genes of mammals were removed. The trimmed and decontaminated reads of individual pools were mapped against each gene database using BBMap. The mapped read numbers were normalized for the reads per kilobase million (RPKM). Briefly, total number of reads in a sample are divided by 1,000,000 resulting in a "per million" scaling factor. The mapped read counts are divided by the "per million" scaling factor to get the RPM and then RPM values are divided by the length of the gene to give the RPKM value. The marker genes whose sum RPKM value across all samples was higher than 0. 001 were shown in the heatmap (Fig.
7a ) and further used for the correlation analysis (Fig. 7b ). The relative abundance of the 33 phage contigs (longer than 1500 bp), bacterial and mosquito marker genes in each sample were calculated by dividing the reads number mapped to contigs or genes to total reads number of each sample. The bacterial marker genes included the recA, gyrB, and cox1 genes of Chromobacterium violaceum, Cupriavidus taiwanensis, Wolbachia endosymbiont of Culex quinquefasciatus Pel wPip strain, Wolbachia endosymbiont of Drosophila melanogaster, and Wolbachia endosymbiont of Drosophila simulans wNo. Then the abundance table was used for correlation analysis with the corrplot package  [79]. A matrix of Pearson's r rank correlation coefficients was computed for all possible pairs of bacteriophage contigs and marker genes.
Acknowledgements We thank  Christelle Delannay  and  Lyza Hery  for their contribution in the sampling campaigns. CS was funded by  China Scholarship Council (CSC). LB was funded by  FWO (Research Foundation Flanders ). KCY was funded by the  Interfaculty Council for the Development Cooperation (IRO)  from the  KU Leuven. LD was funded by a research grant of  FWO.
Availability of data and materials The raw sequencing datasets for the current study are available in the NCBI Sequence Read Archive (SRA) repository, under the Bioproject with accession code PRJNA515586 (www. ncbi. nlm. nih. gov/bioproject/515586). Sequence files, metadata, and R script used for analysis in this study have been deposited in Figshare (https://figshare. com/projects/Guadeloupe_mosquito_ virome/67049).
METHODOLOGY The aim of this paper is to define what circular PSSs are (considering the five dimensions of sustainability). Additionally, it seeks to determine a definition of 'territory', as well as the territorial/ local resources that are tailored to be used in the design and development of circular PSS strategies. At the same time, this paper identifies the current approaches for integrating territory in the design and implementation of PSS. A literature review analysis was conducted using the research model represented in Figure  1. The key words used for defining search strings were entered in databases such as Scopus, Web of Science and Google Scholar for relevant scholarly (peer-reviewed) publications. In addition, relevant articles were identified through references cited in the articles identified in the search.
Two examples are the MEPSS tool (MEPSS tool, no date) which is a PSS design software that integrates a local approach through the empowering/ valorising of local resources guidelines, and the PSS business model toolkit from  Jégou F. et al. (2013) , which utilizes a territorial approach to innovate local solutions for cities and involve the needs of various stakeholders. From these results we can conclude that the local and territorial scales are vital in the design and development of PSS strategies, as they foster self-sustaining territories, thereby reinforcing the local economy and relations within actors both in-and outside the territory. The integration of the territorial scale generates a more dynamic flow of local resources and enhances the identification of key stakeholders that can collaborate to design innovative ways to satisfy the needs of the local system.
To allow members of the HCI community to create trace figures with Esquisse, it is released as a free open-source 5  add-on for the 3D modelling software Blender  [14]. The remainder of the paper is structured as follows. After presenting a taxonomy of illustrative figures for HCI scientific contribution, we discuss the existing workflows for creating trace figures. We then describe details of Esquisse's interaction techniques and its implementation, before discussing the evaluation and figures created by participants.
Model-based Methods While producing trace figure is a common practice, especially for HCI researchers, surprisingly little work has been devoted to ease the production of such materials. The most commonly used method remains manual photo-tracing  [9, 33]  which can be described as follows. First, users stage the situation they want to illustrate using physical devices and other people standing in as actors, and take a photo of it. Then, they transfer this photo to a computer or a tablet, and open it as a background layer in an image editing software. Third, they sketch traces on top of the photo using their favourite input device and graphics editing software (usually Inkscape or Adobe Illustrator). Once the sketch is complete, they may add visuals such as overlaying an interface over a display or adding arrows, texts or contact points.
Esquisse Workflow and Interaction To use Esquisse the user starts Blender with the Esquisse add-on 10  previously installed. We chose Blender as it is a free and cross-platform software widely used to model, animate and render 3D scenes. However, as a complete 3D modelling environment, Blender provides controls with many degrees of freedom that are not needed for illustration production, which is why we overrode most default controls with simpler interaction techniques specifically implemented for Esquisse. These techniques are located in a dedicated panel located on the left side of the Blender interface (see Figure  2 , left). To create a vector graphics illustration with Esquisse, users stage a 3D scene using one of the pre-existing templates as starting point or manually adding 3D objects to the scene.
For objects featuring a screen (e. g. a smartphone) they can optionally load an external file with a screenshot image of the interface, which gets automatically rendered as part of the screen of the selected device. They then position and align the objects using the specific interaction techniques of Esquisse built to ease the manipulation of articulated objects (and in particular simplifying the modification of hand postures), but they can still use default Blender controls if they prefer. Next they orient the viewport to the desired point of view. If wanted, they can add a stroboscopic effect to illustrate the motion of a finger, for example. Last they render the scene to create the trace figure as a vector-based SVG file. Optionally, they can tweak or add graphical elements using any vector graphics editing software like Inkscape or Illustrator.