dataesr/scientific-paragraphs-categorization huggingface dataset:
II. RELATED WORK Simulation is the lightest approach to observe how opportunistic networking protocols or applications can perform at runtime. General-purpose discrete event network simulators such as ns-2  [7] , ns-3  [8] , OMNeT++  [9] , QualNet  [10]  or Riverbed Modeler  [11]  include modules that can simulate the mobility of nodes in a wireless network. Most of these simulators implement standard wireless MAC layers (e. g. , IEEE 802. 11, 802. 15. 1, 802. 15. 4), and they can optionally simulate physical phenomena observed on the wireless medium, such as shadowing, free space path loss, fading, co-channel interference, etc. Because of its ease of use, the simulator ONE  [12] ,  [13]  has become the tool of choice for simulating opportunistic networks. It supports a variety of mobility models, and contact or mobility traces such as those available in the CRAWDAD database  [14]  can be imported with little effort.
III. THE LEPTON EMULATION PLATFORM LEPTON is implemented as Java code, and it is distributed under the terms of the GNU General Public License. Its prime function is to simulate the mobility of nodes in an opportunistic network while conducting transmissions between these nodes based on their relative positions. Being an emulator rather than a simulator, LEPTON drives the communication between full-featured instances of an OppNet system, each instance determining the behaviour of one node during the simulation. In the remainder of this paper we will use the term System Node (SN) to refer to an instance of the OppNet system. SNs are not a part of LEPTON, but of the system under evaluation. An SN is typically composed of application code combined with communication middleware, which itself requires to run on top of a standard protocol stack.
A. General architecture Every LEPTON's experiment involves the network emulator and System Nodes (SNs), as shown in Fig. 3. The SNs are not part of LEPTON: they are implementations of the system to be tested (more details in Section IV). The emulator itself is structured in two main parts: a simulation engine and a software hub. The simulation engine determines if any pair of nodes should be considered as neighbours at any specific time during an experimentation run. The software hub plays approximately the same role as a switched hub in an Ethernet LAN: it relays every message it receives from an SN to its destination, and to that destination only. Yet in order to decide whether this destination is indeed accessible, the hub must consult the simulation engine.
B. The simulation engine The role of the simulation engine is to model the wireless network as a dynamic graph, whose nodes represent SNs, and whose edges represent radio links between SNs. The implementation of this dynamic graph in the simulation engine relies on facilities offered in the GraphStream library  [28] , which provides elaborate data types and algorithms for dynamic graph modelling, analysis, and visualization. The simulation engine is also responsible for driving the dynamics of the graph according to a given mobility model, or based on mobility and/or contact traces. Several traditional mobility models (Random Waypoint, Levy Walk, Map-based mobility, etc. ) have already been implemented for LEPTON, and new models can be included as and when needed. A manual mobility model is available, that is especially useful in demo sessions.
C. The software hub In a real mobile network, neighbour SNs can exchange messages directly with one another. When running an experiment with LEPTON, each message sent by an SN must be directed through the software hub. Interfacing an existing opportunistic system with LEPTON therefore requires: 1) Making sure that all SNs explicitly redirect their traffic to the software hub, which from their viewpoint will be seen as some kind of a proxy. 2) Developing an appropriate software hub for that system, and making sure that this hub will consult the simulation engine in order to decide what to do about each message received. The first requirement is usually easy to meet. Instead of sending beacons to a multicast group, and gossiping with peers through unicast communication, each SN must redirect its transmissions explicitly to the software hub.
F. Additional tools In addition to the simulation engine and the software hub, LEPTON comes with a set of tools that can be used either when preparing an experiment, or after an experiment has been conducted. This toolset notably includes format converters to manipulate traces, as well as programs that can be used to analyze a mobility scenario. Input and output of trace sets: Mobility or contact trace sets such as those available in the CRAWDAD database  [14]  can be converted to the DGS file format used by LEPTON. Converters are notably available for trace sets that use the file formats defined for well-known simulators (e. g. , ONE, Legion), but ad hoc converters can also be devised for trace sets that use exotic formats. Sometimes the trace set considered as input contains information about both node mobility and radio contacts, but sometimes it only contains information about node mobility.
IV. INTEGRATING OPPORTUNISTIC SYSTEMS WITH LEPTON Wireless network emulation with LEPTON is expected to be an excellent way to validate the code of a full-featured opportunistic system, as well as a way to compare the performances observed with different systems in similar conditions. In order to confirm this expectation, two existing systems have been tested using LEPTON, using the same mobility scenario and the same application scenario. These two systems were chosen for three reasons: 1) because they can both support content-based networking  3  , that is, a model where information flows towards interested receivers rather than towards specifically set destinations; 2) because the two systems use a similar communication pattern, as they rely on UDP beaconing for neighbour discovery, and on TCP sessions for the gossiping; and 3) because they have originally been designed and implemented by two different research groups, targeting different kinds of hardware, so they may require slightly different adaptations in order to interface with LEPTON.
In DoDWAN's gossiping algorithm, though, special attention has been paid to avoiding any unnecessary transmission between neighbour hosts, while ensuring maximal reactivity to connectivity changes observed on the wireless channel. DoDWAN is most commonly used with Wi-Fi interfaces running in either managed or ad hoc mode. Over the last few years it has also been tested with a variety of alternative wireless technologies, such as Bluetooth, XBee, and VHF battlefield radios used in military tactical networks  [39]. Integration of DoDWAN with LEPTON: Since DoDWAN can rely on different kinds of wireless technologies, no assumption is made about the format of the addresses used to identify mobile hosts at data link or network level. Indeed, assuming that a node is always identified by an IP address would be contrived when running for example with Bluetooth or XBee radio modules.
DoDWAN's implementation therefore assumes that each wireless host is identified by a unique identifier, expressed as a character string. This identifier is embedded in the beacons used for neighbour discovery, and in the messages used in gossiping transactions. Developing a software hub capable of receiving and forwarding traffic for DoDWAN nodes, based on the templates presented in Section III-C, is therefore straightforward. Besides, no modification of DoDWAN's source code is required to redirect all transmissions to this software hub. This is because the configuration file that determines how a DoDWAN node should interact with peer nodes is quite flexible. For example the IP addresses and port numbers used for the beaconing and gossiping services are defined in that configuration file (assuming IP is used), so redirecting all transmissions to a software hub only requires changing that file.
These codes are executed by any node that receives a bundle, in order to decide what neighbours the bundle should be forwarded to, if it should be dropped instead, and the priority it must receive. The system has been implemented in C++, and it is distributed with libraries that allow the development of DTN applications in C, Java, or Python. Active-DTN was designed to demonstrate the feasibility of this paradigm of bundles that carry executable codes, and to obtain data from low-scale field experiments. Several such experiments have been run successfully on the Autonomous University of Barcelona (UAB) campus, involving up to 10 Raspberry Pi nodes that were carried either by pedestrians, bus shuttles, cars, and a drone. Integration of aDTN with LEPTON: By default aDTN uses UDP multicast for neighbour discovery and TCP sessions for the transfer of bundles between neighbour nodes.
The main difference with DoDWAN with that respect is that a transient TCP session is established whenever a bundle must be transferred between two aDTN nodes, while a single TCP session is maintained between two DoDWAN nodes as long as these nodes are neighbours. The software hub needed to interface aDTN with LEPTON simulation engine was developed by making small adaptations to the templates presented in Section III-C. Additionally, as aDTN is not as configurable as DoDWAN, the code of the aDTN system had to be slightly modified, so that an aDTN node could redirect the messages to the software hub. First of all, the neighbour Discovery module was modified so this module could listen to a UDP socket bound to a unicast address, rather than to a multicast address. Conversely, the beacons sent through that socket are addressed to the hub, rather than to a multicast group.
A. Scenario considered for both simulation and emulation runs Mobility scenario: For this evaluation we used mobility traces available in the CRAWDAD database  [14] , in the kth/walkers dataset  [43]. This dataset includes mobility traces that have been produced using the Legion Studio simulator  [44] , for both an outdoor scenario (pedestrians in the Östermalm area of central Stockholm) and an indoor scenario (pedestrians in a two-level subway station)  [45]. We selected the subway scenario, that comes pre-defined with Legion Studio, and that models a train platform connected via escalators to the upper entry-level (see Fig. 8 ). Pedestrians can arrive from several entry points of the subway station, or when trains arrive at the platforms. They can likewise leave the station through an exit point, or by boarding a train.
For our evaluation, we only considered the 10-meter range. Since the kth/walkers dataset only provides information about nodes positions, one of the programs available in LEPTON's toolset was used to precalculate radio contacts, thus producing a DGS file containing both nodes positions and radio contacts. Application scenario: Besides the mobility scenario, we have defined the following simple topic-based application scenario (topic-based messaging can be considered as the simplest form of content-based networking). The messages produced during the experiment will pertain to five different topics, numbered 0 to 4, each message about a single topic. Each mobile node is assumed to be interested in only one topic, and is thus willing to receive and forward only messages about that topic. The population of mobile nodes is thus split into five distinct groups, each group including all nodes that share an interest for the same topic.
7% of the potential receivers). This was not unexpected. The reason is that, although DoDWAN uses a publish/subscribe strategy based on topics of interest, while aDTN uses mobile code to make routing decisions, in the described application scenario both systems operate using the very same logic. Therefore, both systems take the same routing decisions and, when facing the same situation, they both forward or deliver the messages to the same nodes. Besides, since processing time and buffer management are not accounted for in a discrete event-based simulator (because time "stops" when a node has to make a decision, and only transmission delays are considered) there is nothing that differentiates one OppNet system from the other from the simulator's point of view. Other metrics: One of the advantages of using a simulator is that it makes it easy to collect global statistics of certain metrics.
This topic remains out of the scope of this paper, though, since our main objective here is simply to demonstrate how fully-implemented opportunistic systems can run in an emulated environment, thanks to the LEPTON platform, producing a wealth of results that can then be analyzed at a very fine grain. Considerations about LEPTON's resource consumption: Experiments based on the subway scenario have been run on a cluster composed of 20 cluster nodes (each node including 2 "6-core" Xeon L5640 processors), interconnected via a Gigabit Ethernet LAN, each cluster node running Linux. In practice, only five nodes of the cluster were used during our experiments. One of these nodes ran the LEPTON emulator (i. e. , simulation engine plus the appropriate software hub), and the other four nodes ran instances of the OppNet system considered, which were created dynamically at runtime and interacted via the hub.
Indeed, a 2. 6 seconds radio contact occurred between two smartphones, shortly before the completion of the field experiment. These two smartphones failed to exploit this very short contact, and thus failed to achieve the last two message transfers. During the emulation runs, though, these message transfers did not fail, hence the slight (less than 0. 1%) discrepancy in the number of receive events between field data and emulation data. Figure  19  shows the average message delivery delays obtained in all four datasets. The similitude between the four curves confirms that LEPTON's behaviour is stable, and that it mimics real conditions satisfactorily. Based on these results, and despite the minor differences discussed above, we consider that the overall similarity between field results and emulation results demonstrates that LEPTON is apt at replaying accurately field scenarios in emulation mode.
Nonlinearities due to drag loads are modelled exactly. These modelling choices are adequate to simulate structures with minimal changes of configuration, such as top tensioned risers or taut mooring lines in deep water, for which lateral deflections are about two orders of magnitude smaller than the structure's length. The structural damping matrix is of the form C = α 1 M + α 2 K (Rayleigh damping) where α 1 is chosen to be null. In that case, the damping ratio associated to a vibration mode with circular frequency ω i is λ i = ω i α 2 /2. The model is implemented as a MATLAB R class named fixedFreeCableSegment. The verification of this class is presented in A. It is also shown how the eigenmodes of the taut polyester mooring differs from those of a string, due to the combined effects of elasticity, varying tension, and oblique configuration, which would be inconvenient to represent in a purely analytical model.
Also, nested LHS can be used  Blatman and Sudret (2010) , to sequentially add samples to E, while ensuring that the updated set E contain samples still distributed according to f Θ (θ). The distribution of ϕ can be estimated from E (see Figure  9 ), and in Figure  10 , the realization of Θ leading to the median value of ϕ 1 is shown for illustration. Based on this initial set E and on the associated values of ϕ, the PCE model φ in (1) is established by using a degree-adaptive sparse PCE, based on least-angle regression (LARS,  Blatman and Sudret (2011) ), implemented in the UQLab software  Marelli and Sudret (2014, 2017). These two references may be consulted by the interested reader for more details on the theoretical and practical aspects of PCE identification. The values of E[ϕ(Θ)] and Var[ϕ(Θ)] can then be evaluated from (  3 ) and (  4 ): E[ φ1 (Θ)] = 1.
Web APIs are a prominent source of machine-readable information that remains insufficiently connected to the Web of Data. To enable automatic combination of Linked Data (LD) interfaces and Web APIs, we present the SPARQL Micro-Service architecture. A SPARQL micro-service is a lightweight SPARQL endpoint that provides access to a small, resource-centric, virtual graph, while dynamically assigning stable, dereferenceable URIs to Web API resources that do not have URIs in the first place. We believe that the emergence of an ecosystem of SPARQL micro-services could enable LD-based applications to glean pieces of data from a wealth of distributed, scalable and reliable services from independent providers. We describe an experimentation where we dynamically augment biodiversity-related LD resources with data from Flickr, MusicBrainz and the Macauley scientific media library.
Introduction Web APIs are commonly used to enable HTTP-based, machine-processable access to all sorts of data. Similarly, Linked Data (LD) seek the publication of machine-readable data on the Web while connecting related resources accross datasets. Several approaches have been proposed to bridge these two worlds, based on bespoke wrappers, SPARQL extensions or RESTful APIs. Until now however, several challenges hinder the definition of standard approaches to enable automatic reconciliation of LD and Web APIs. Firstly, Web APIs usually rely on proprietary vocabularies documented in Web pages meant for developers but hardly machine-readable. Secondly, on-the-fly SPARQL querying of non-RDF data sources proves to be difficult, as attested by the many works on SPARQL-based access to legacy databases.
The SPARQL Micro-Service architecture aims to address this issue. The term micro-service refers to an increasingly popular architectural style where an application consists of a collection of lightweight, loosely-coupled, fine-grained services that are deployed independently  [2]. They improve applications modularity thereby speeding up the development, testing and deployment process. Leveraging these principles may help in the design of modular LD-based applications structured as a collection of services such as RDF stores, SPARQL endpoints, SPARQL micro-services or other services based on LD REST APIs for instance. A SPARQL micro-service is a lightweight method to query a Web API using SPARQL. It provides access to a small RDF graph describing the targeted resources from the data available at the API, while dynamically assigning dereferenceable URIs to Web API resources that do not have URIs beforehand.
SPARQL Micro-Services Principles A SPARQL micro-service S µ is a wrapper of a Web API service S w. It complies with the SPARQL Query Language and protocol, and accepts a set Arg w of arguments that are specific to S w. These arguments are passed to S µ as parameters on the HTTP query string, e. g. "http://hostname/sparql?param=value". S µ evaluates a SPARQL query Q against an RDF graph that it builds at runtime as follows: it invokes the Web API service S w with the arguments in Arg w , translates the response into RDF triples (in an implementation-dependent manner), evaluates Q against these triples and returns the result to the client. The semantics of a SPARQL micro-service differs from that of a standard SPARQL endpoint insofar as the SPARQL protocol treats a service URL as a black box, i.
Gene annotation We annotated the cytochromes P450 using the 12X. 2 version of the assembly of the Vitis vinifera cv PN40024 genome (  [9, 36] , https://urgi. versailles. inra. fr/Species/Vitis/Data-Sequences/ Genome-sequences). Four publically available datasets of cytochromes P450 were used to perform similarity searches in the PN40024 genome. 947 protein sequences of grape P450s were downloaded from the NCBI Protein database (http://www. ncbi. nlm. nih. gov/protein, Feb 2014). Three datasets were downloaded from David Nelson's website (http://drnelson. uthsc. edu/CytochromeP450. html, Feb 2014), which stores manually curated annotations of cytochromes P450 for many species: 702 P450 protein sequences of Vitis vinifera cv Pinot Noir clone ENTAV115 (28, http://drnelson. uthsc. edu/vitis. htm); 416 P450 protein sequences of Vitis vinifera cv PN40024 from the 8x assembly version of the genome (10, http://drnelson.
uthsc. edu/Vitis. additionalP450s. htm); and 288 P450 protein sequences of Arabidopsis thaliana (35, http://drnelson. uthsc. edu/Arabidopsis. Blast. file. html). Using these four datasets, we expected to be as exhaustive as possible in the cytochromes P450 similarly search of the PN40024 genome. The four datasets were masked for repeat sequences using the online tool "Repeat Masking" from Censor (http://www. girinst. org/censor/index. php). The four masked datasets were used to perform four independent TBLASTN analyses  [37]  against the PN40024 12X. 2 sequence with an e-value cutoff of 1e-3. The TBLASTN outputs were parsed using a homemade script. The hits from the three grape datasets were kept if they were at least 50 amino acids long with at least 70% sequence identity. The hits from the Arabidopsis dataset were kept if they were at least 50 amino acids long with an identity percentage of at least 50%.
The software Exonerate (version 2. 2. 0, build October 2008,  [38] ) was used to predict gene structures using the protein2genome parameter and the same cutoff of sequence identity as above. A homemade script was used to reformat the output files from exonerate into files in the gff format. These gff files were imported to the Artemis genome browser  [39]  to perform the manual curation of the structures suggested by Exonerate. The parsed hits identified through TBLASTN were used to improve or to complete the Exonerate annotations. Every annotation starting with a start codon, ending with a stop codon and with correct exon-intron borders (GT-AG or sometimes GC-AG) was considered as a complete "gene". Every annotation showing this gene structure (start and stop codons, correct exon-intron borders) but with a single point mutation creating a frameshift, a premature stop codon or a wrong exon-intron border was considered as a "putative pseudogene" also marked "pseudogene?" because it may result from a mistake in the genome assembly.
Every annotation interrupted by a gap in the genomic sequence or including one was considered as a "partial" annotation. All the other annotations with wrong gene structure but showing a significant similarity level with a cytochrome P450 from one of the four datasets were annotated as "pseudogenes". The genome annotation V1 stored in Grape Genome Database hosted at CRIBI (  [40] ; http://genomes. cribi. unipd. it/DATA/GFF/V1. phase. gff3) and a set of expertized and functional grape cytochromes P450 were used to guide the manual curation. To validate the gene structure, two transcript datasets were used. First, the Vitis vinifera unigene set build #15 from the NCBI database was downloaded (ftp://ftp. ncbi. nih. gov/repository/ UniGene/Vitis_vinifera/Vvi. seq. uniq. gz). The 32, 193  unigenes were mapped on the PN40024 12X.
2 sequence using GMAP version 2013-11-27  [41]  using the default parameters except for the format parameter which was set to "gff3_match_cdna". The second transcript dataset was locally assembled using six RNA-Seq experiments (  [42] , SRR519450, SRR519456, SRR520380 and SRR520385;  [43] , all four samples;  [44] , SRR493740-SRR493746;  [45] , SRR866544, SRR866570, SRR866571 and SRR866576;  [46] , SRR522472, SRR522477 and SRR522478; and four RNA-Seq datasets submitted in the frame of this study. The software Tophat2 v2. 0. 11 [47]  was used to map the RNA-Seq reads against the PN40024 12X. 2 sequence using the following parameters: -p 5 -N 5-read-edit-dist 5. The software Cufflinks v2. 2. 1  [48]  was used to assemble the transcripts from all the RNA-Seq experiments. First the cufflinks command was used with the -p 5 parameter and then the cuffmerge command with the -p 15 parameter and using the fasta file of the PN40024 12X.