dataesr/scientific-paragraphs-categorization huggingface dataset:
Description of the reported data We compiled a total of 195 papers providing the prevalence of Bb in questing I. ricinus in the period January 2010-June 2017. The reports of this period included a total of 36,894 ticks. The complete dataset of prevalence in questing nymphs, with adequate identification of the Bb species and with a sample size of nymphs above the 10% of the frequency distribution consisted in 1177 records, of which 926 had adequate information about coordinates. A further set of 878 records (years 2000-2010, with geo-references, see Estrada-Peña et al. [16]  Figures  2, 3 , 4 and 5 show the geographical pattern of prevalence of the five species of Bb in questing nymphs for which examined specimens were above the threshold limit, over the period 2000-2017. Figure  6  displays the overview of the prevalence of Bb s.
Discussion This study updates a previous meta-analysis  [16]  on the prevalence of Bb in questing nymphs of I. ricinus in Europe using reports published between 2010 and mid-2017, improving our knowledge of the range of Bb in Europe. The data for the period 2010-2017 (> 36,000 questing nymphs) were updated with data from the period 2000-2009 (> 43,000 questing nymphs). The current study thus represents the largest analysis of the distribution of the pathogen in questing nymphs of I. ricinus in Europe. We used only data from questing nymphs because of the unreliability of reports in ticks collected and processed while feeding; questing nymphs are also the more abundantly collected stage of I. ricinus. This study has obvious limitations that emanate from the structure of the data sources. We could not analyze temporal trends from the reports because of the lack of a coherent background, which should be ideally structured around the same methods.
) has been added to the 2010-2017 dataset. This produced a total of 558 geo-referenced records of B. afzelii, 404 of B. burgdorferi s. s. (only 80 after the year 2010), 552 of B. garinii, 78 of B. lusitaniae, 61 of B. spielmanii, 373 of B. valaisiana, and 29 of B. miyamotoi. Borrelia finlandensis and B. turdi have been reported (2010-2017) only in feeding ticks and/or in host tissues, and these records are therefore not included.
In particular, the latter test is not meant to measure performance, or, to provide a benchmark for comparisons: its purpose is to assess whether the technology is usable, that is, executable on nowadays software platforms and by nowadays programming languages. For instance, a library requiring an obsolete third-party libraries that hinders smooth deployment is considered not usable. Accordingly, each technology is tested either running provided example code, or developing a minimal working example of usage of the API. Section 3 discusses the data collected so as to deliver insights about: (i) the evolution of technologies as they are stemming from a few archetypal models (Fig. 5 ), (ii) the relationships between the selected technologies, as a comparison of their features (Fig. 6 ), and (iii) the main goal and reference scenario of each technology (Fig.
By extending the analysis to all the papers published in the proceedings, instead, out of all the 390 papers published, only 47 (just 12. 05%) -based on authors' inspection of the papers -convey a technological contribution. And, such an estimate is somehow optimistic, since we counted papers just for merely mentioning a technology, with no means to access it-see Table  2   The early days. The first few years of  COORDINATION (1996 COORDINATION ( -2000) )  saw a flourishing of successful technologies: some of the ideas introduced back then are still alive and healthy. For instance, ACLT  [35]  adopted first-order logic terms as Linda tuples, an intuition shared by the µ 2 Log model and its language, MultiBinProlog  [31]. Also, ACLT allowed agents to dynamically program tuple spaces via a specification language, enabling definition of computations to be executed in response to some events generated by interacting processes.
Both features influenced the TuCSoN model and infrastructure  [28] , one of the few technologies to be still actively maintained nowadays. Similarly, the IWIM coordination model and its corresponding language, Manifold  [5] , were introduced back in 1996 and survived until present days by evolving into Reo  [6]. IWIM came by recognising a dichotomy between exogenous and endogenous coordination, and exploiting channel composition as a means to build increasingly complex coordination patterns. Finally, Moses  [4]  was presented to the COORDINATION community as an infrastructure reifying the Low Governed Interaction (LGI) model. The technology is still alive and inspectable from its homepage, even if apparently no longer maintained. Analogously, the Piccola composition language presented in  [2]  clearly relies on a coordination technology which reached stability and robustness, even if it seems to be no longer maintained, too.
k. a. Messengers -can migrate between nodes. Here, coordination is seen as "invocation [of distributed computations] and exchange of data" and it "is managed by groups of Messengers propagating autonomously through the computational network" Blossom  [46]  -a Linda variant focusing on safety, which is provided by supporting a type system for tuples and templates, and a taxonomy of access patterns to tuple spaces, aimed at supporting a sort of "least privilege" principle w. r. t. access rights of client processes Bonita  [84]  -another Linda-like technology -as its successor WCL  [85]  focusing on asynchronous primitives and distribution of tuple spaces, which can also migrate closer to their users Berlinda  [93]  -providing a meta-model -along with a Java implementation -for instantiating different Linda-like models SecOS  [22]  -a Linda variant focusing on security and exploring the exploitation of (a)symmetric key encryption Messengers  [95]  -not to be confused with  [42]  despite its name, which focusses on message exchange by means of migrating actors MJada  [82]  -an extension of the Jada language  [25] , focusing on coordinating concurrent (possibly distributed) Java agents by means of Linda-like tuple spaces with an extended primitive set and object-oriented tuples Clam [86] -a coordination language based on the IWIM model  [5]  Truce  [53]  -a scripting language aimed at describing protocols to which agents must comply by enacting one or more roles CoLaS  [29]  -a model and its corresponding language providing a framework where a number of participants can join interaction groups and play one or more roles within the scope of some coordination protocol.
In particular, CoLaS focuses on the enforcement of coordination rules by validating and constraining participants behaviour The millenials. After year 2000, technologies are less present amongst COOR-DINATION papers, but not necessarily less important. For instance, Reo made its first appearance in 2002  [6] , its name written in Greek (P ω). Reo provides an exogenous way of governing interactions between processes in a concurrent and possibly distributed system. Its strength is due to its sound semantics, enabling researchers to formally verify system evolution, as well as to the availability of software tools. The technology is indeed still alive and actively developed. Recent implementations are more easily available on the web. Out of 22 coordination technologies, just 6 were not found on the web during the survey: OpenSpaces  [38]  -focussing on the harmonisation of the Linda model with the OOP paradigm and, in particular, with the inheritance mechanism Scope [63] -analogously to Lime, it provides multiple distributed tuple spaces cooperating by means of local interactions when some process attempts to access a tuple, thus providing a sort of federated view on the tuple space SpaceTub [94] -successor of Berlinda, it aims at providing a meta-framework where other Linda-like frameworks can be reproduced WikiRecPlay / InFeed [80] -a pair of tools (browser extensions, no longer available) aimed at extracting and manipulating information from web applications to record them and later replay, enabling the definition of sequences of activities that can be synchronised with each other.
The goal here is to augment social software with coordination capabilities. LINC  [58]  -a coordination environment implementing the basic Linda primitivesout, in, rd -in a setting in which each tuple space (called bag) could implement the primitives differently (still preserving semantics), a convenient opportunity when dealing with physical devices (i. e. in the case of deployment to IoT scenarios) or legacy systems (i. e. databases). It provides transactions to alleviate to developers the burden of rolling back actions in the case of failures, and a chemical-reaction model inspired to Gamma  [11]  for enacting reaction rules. Several tools  [59]   All the others are still publicly available, thus further analysed in next section. For instance, the O'Klaim language presented in  [15]  evolved into the X-Klaim project  [16]  which is still alive, even if apparently no longer maintained.
Similar considerations can be made for Limone  [40]  and CRIME  [65] , which both stem from the idea of opportunistic federation of transient tuple spaces introduced by LIME  [66] , and improve it with additional features such as lightweightness and orientation to ambient-programming. Analogously, the CiAN  [88]  model and middleware, targeting the coordination of distributed workflows over M obile Ad-hoc Networks (MANETs), comes with a mature implementation, although no longer maintained. An extension to Session Java  [51]  is proposed in  [68]  to explicitly tackle synchronisation issues such as freedom from deadlock via multi-channel session primitives, Whereas the implementation was discontinued in 2011  4  , the source code is still available from GoogleCode archive. JErlang  [75] , a Java-based implementation of Erlang extended with constructs borrowed from the Join-Calculus  [41] , appears to be no longer maintained too as explicitly stated in its home page  5  , although a couple of implementations are still available and (partially) working.
Also RepliKlaim  [3] , an implementation of Klaim  [19]  aimed at optimising performance and reliability through replication of tuples and tuple spaces, received updates until 2015 as far as we know, thus appears to be discontinued. Likewise, 2015 is the year when both Statelets  [57]  and IIC  [77]  received their last known update: the former is a programming model and language aimed at integrating social context and network effects, derived from social networks analysis, as well as semantic relationships amongst shared artefacts in, i. e. groupware applications, into a single and coherent coordination model, while the latter proposes Interactive Interaction Constraints (IIC) as a novel framework to ground channel-based interaction -à la Reo -upon constraints satisfaction, interpreting the process of coordinating components as the execution of a constraints solver.
Next section briefly focuses on those technologies-that is, coordination technologies that can be actually installed and used nowadays-step §4 in Section 1. 2. -Smrl requires ancient software to run-that is, an old version of Eclipse requiring in turn an ancient version of the Java runtime (1. 4) -CaSPiS  [18]  (or better, JCaSPiS, namely the Java-based implementation of CaSPiS) was not found anywhere-neither in the author personal pages, nor in their account profiles on Github, nor in the web pages of the SENSORIA project mentioned in the paper. Nevertheless, the IMC model and framework allegedly grounding its implementation is still accessible  6. Then we proceeded to download it looking for the CaSPiS code, without success. It is worth to be mentioned, anyway, that the IMC framework code appears to be broken, since compilation fails unless a restricted/deprecated Java API is used  7  , and even in the case of instructing the compiler to allow for it  8 the attempt to run any part of the software failed without informative error messages-just generic Java exceptions.
-LeanProlog is not usable as a coordination technology as defined in Section 1. 2: it is a Prolog engine with low-level mechanisms for handling multithreading, and provides no API for general purpose coordination -Session Java, as explicitly stated in its home page, requires an ancient version of the Java runtime to run, that is, 1. 4 -Statelets is explicitly tagged as being in "pre-alpha" development stage, and, upon inspection, revealed to be only partially developed There is no publicly available code repository, thus no information about latest commits.
Analysis of selected technologies Table  3. Overview of the working coordination technologies presented at COORDINATION. Column "Health" denotes the status of the software, for instance whether it is still actively developed, only in mainteinance mode, or actually discontinued, column "Build" is filled whenever source code is available and denotes whether build steps (i. e. compilation into binaries and dependencies resolution) were successful, column "Deployment" indicates whether the software has been successfully executed. It is worth to emphasise that LINC has been left out since it is part of commercial solutions sold by the Bag-Era company, thus no further inspection of the software was possible. TuCSoN. Although TuCSoN  [28]  appeared at COORDINATION in 1999, its roots date back to the first edition of the conference, as the ACLT model  [35].
TuCSoN is a coordination model adopting Linda as its core but extending it in several ways, such as by adopting nested tuples (expressed as first-order logic terms), adding primitives (i. e. bulk  [83]  and uniform  [60] ), and replacing tuple spaces with tuple centres  [71]  programmable in the ReSpecT language  [70]. It comes with a Java-based implementation providing coordination as a service  [96]  in the form of a Java library providing API and a middleware runtime, especially targeting distributed Java process but open to rational agents implemented in tuProlog  [36]. The TuCSoN middleware is publicly available from its home page  9  , which provides both the binaries (a ready-to-use Java jar file) and a link to the source code repository. From there, also documentation pages are available, in the form of a usage guide and a few tutorials providing insights into specific features.
Finally, a few related sub-projects are therein described too, such as TuCSoN4Jade  [62]  and TuCSoN4Jason  [61] , which are both Java libraries aimed at integrating TuCSoN with Jade  [13]  and Jason  [21]  agent runtimes, respectively, by wrapping TuCSoN services into a more convenient form which best suites those developers accustomed to programming in those platforms. As far as technology is concerned, TuCSoN is still actively developed, being the latest commit in 2017, when also the latest related publication has been produced-an extension to the ReSpecT language and toolchain exploited to program tuple centres in TuCSoN  [27]. Also, it is actively exploited as the infrastructural backbone for other projects -e. g. , the smart home logic-based platform Home Manager  [23]  -and industrial applications-e.
We were able to successfully compile and execute the code: however, no source code is provided, and some poriontof the web page, such as the JavaDoc, are not updated w. r. t. the current Moses implementation. Finally, Moses still bounds to deprecated technologies such as Java Applets, which we believe may hinder its adoption. JErlang. JErlang  [75]  is an extension of the Erlang language for concurrent and distributed programming featuring joins as the basic synchronisation constructas borrowed from the Join-Calculus  [41]. The web page mentioned in the paper 11 is no longer accessible; by searching JErlang and the authors' names on the web, a GitHub repository with the same broken reference popped up 12 , apparently tracking the development history of the JErlang technology. There, however, JErlang is described as an implementation of Erlang/OTP on the JVM.
IIC. Interactive Interaction Constraints (IIC) The IIC software is distributed as a Scala library providing an handy syntax which eases definition of Reo-like connectors. The Scala library source code is distributed by means of a GitHub repository 14 where the latest commit dates back to 2015. The library ships with a SBT configuration, allegedly supporting automatic building. Nevertheless, we were not able to reproduce the compilation process since the provided SBT configuration depends on an ancient SBT version. Therefore, we consider IIC a no longer maintained but still usable fullfledged coordination technology. Reo. Reo was firstly introduced to the COORDINATION community in  [6] , its name in Greek letters (P ω). Similarly to the IWIM model, Reo adopts a paradigm for exogenous coordination of concurrent and possibly distributed software components.
Several technologies are available from the Reo tools homepage 15 , collectively branded as the Extensible Coordination Tools (ECT). They consist of various Eclipse IDE plugins, such as a graphical designer for Reo connectors, and a code generator which automatically converts the graphical description into Java sources in which developers may inject applicative logic. Nevertheless, the generated code comes with no explicit support for distribution. According to their home page, ECT are allegedly compatible with any Eclipse version starting from 3. 6; while we were not able to reproduce its installation in that version (due to a dependency requiring an higher version of Eclipse), we succeeded in installing it on Eclipse version 4. 7 (the latest available), but the code generator appears buggy and unstable -thus hindering further testing -because of several non-informative error messages continuously appearing when trying to use the Reo model designer-which is a required step for code generation.
The ECT source code is available from a Google Code repository 16 -last commit dating back to 2013. In  [78]  a novel implementation is proposed, named Dreams, implemented in Scala and aimed at closing the gap between Reo and distributed systems. Nevertheless, its binary distribution seems unavailable and no documentation is provided describing how to compile or use it, thus we were not able to further test this novel Dreams framework. TripCom. TripCom  [89]  is essentially a departure from the Linda model where the tuple space abstraction is brought towards the Semantic Web vision  [47]  and web-based semantic interoperability in general. The former is achieved by employing the Resource Description Framework (RDF) -that is, a representation of semantic information as a triple "subject-predicate-object" -as the tuple representation language, and by considering tuple spaces as RDF triplets 15 http://reo.
e. Apache Tomcat). Once deployed, the web service is accessible via HTTP -making it is virtually interoperable with any programming language and platform -and can be tested by means of a common web browser. Additionally, the service exposes a WSDL description of the API needed to use it, which implies that a client library (aka stub) may be automatically generated using standard tools for serviceoriented architectures. Nevertheless, this WSDL description is the only form of documentation when it comes to actually interact with the web-service. CiAN. Collaboration in Ad hoc Networks (CiAN)  [88]  is a Workflow Management System (WfMS) enabling users to schedule and execute their custom workflow over MANETs. It comes with a reference architecture and a middleware. The middleware keeps track of the workflow state in a distributed way, and takes into account routing of tasks' input/output data, on top of a dynamic network topology where nodes communication is likely to be opportunistic.
Piccola home page  19  is still available and collects a number of useful resources such as documentation pages and implementation. This comes in two flavours: JPiccola, based on Java, which reached version 3. 7, and SPiccola, based on Smalltalk, which reached version 0. 7. Source code is provided for the Java implementation only, which correctly compiles and executes. Nevertheless, the project appears to be discontinued, given that the last commit on the source repository dates back to 2006. CRIME. CRIME adheres to the Fact Spaces model, a variant of Linda which absorbs transient federation of tuple space from Lime  [66]  for implementing mobile fact spaces-tuple spaces where tuples are logic facts and each tuple space is indeed a logic theory. Federated fact spaces are therefore seen as distributed knowledge bases.
The produced code exploits the Klava library in turn, that is, the Java library implementing the middleware corresponding to the Klaim model. The overall framework explicitly targets code mobility, thus allowing both processes and data to migrate across a network. To do so, X-Klaim and Klava provide a first-class abstraction known as locality. Localities are of two sorts: either physical, such as network nodes identifiers, or logical, such as symbolic references to network nodes having a local semantics. Each locality hosts its own tuple space, and the processes therein interacting. The Linda primitives supported by Klava are always explicitly or implicitly related to the tuple space hosted on a specific locality. Furthermore, processes are provided with primitives enabling them to migrate from a locality to another in a strong manner, that is, along with their execution state.
From there, a. rar archive is provided, containing a version of Klava and the source files implementing RepliKlaim, which can be easily compiled and run successfully. Nevertheless, as stated in the paper describing RepliKlaim, its implementation currently relies on encoding its model in the standard Klaim model, thus, on the practical side the code provided only features examples about how to translate RepliKlaim primitives into Klava. No higher-level API directly providing to developers the replica-oriented operations of RepliKlaim is provided. In other words, there exists no RepliKlaim Java library which can be imported to other java projects in order to exploit its provided coordination services.
Whereas this can be easily attributed to the fundamental difference in the approach to coordination they have -data-driven vs. control-driven, as also emphasised in Fig. 6  on page 23 -it seems odd that nobody tried to somewhat integrate these two extremely successful coordination models, in an attempt to improve the state of art by cherry-picking a few features from both to create a novel, hybrid coordination model  [69] , with "the best of two worlds". To some extent, the TuCSoN model, along with its coordination language, ReSpecT, pursues this path: Re-SpecT in fact can be regarded as a data-driven model because coordination is based on availability of tuples, as in Linda, but, at the same time, coordination policies are enforced by declarative specifications which control the way in which the coordination medium behaves, thus, ultimately, how the coordinated components interact-as typical for control-driven models like IWIM.