dataesr/scientific-paragraphs-categorization huggingface dataset:
Materials and methods To address the issue of including individual cell description into an agent-based model, we adapted, merged and expanded two existing open source software tools. The first one, PhysiCell  (Ghaffarizadeh et al. , 2018) , focuses on the evolution of a multicellular system (particularly tumours) by simulating the dynamics of a population of cells under specific constraints, in 2 D or in 3 D. The second one, MaBoSS  (Stoll et al. , 2012 (Stoll et al. , , 2017)) , defines a continuous-time Markov process on the state transition graph of a Boolean model. Note that a state transition graph is a graph which encompasses all possible transitions between model states, and a model state is a vector which captures the activity of all the nodes of the model. MaBoSS estimates the probability of visiting reachable states of the model.
PhysiCell PhysiCell is an open source agent-based software with minimal dependencies. To improve computational efficiency, it simulates off-lattice position and volume but not morphology; where needed, cell morphology is approximated as a soft sphere. The code is parallelized using OpenMP when possible, allowing the simulation of thousands of cells for several days in a reasonable time (a few hours), and simulations of 10 5 to 10 6 cells can be run over several days. An efficient implementation of the diffusion of environmental entities (oxygen, glucose, growth factors, etc. ) and their interaction with the cells (uptake, secretion, etc. ) is also provided by PhysiCell's BioFVM module  (Ghaffarizadeh et al. , 2016). Beyond secretion and uptake of diffusing substrates, PhysiCell has implemented key phenotypic behaviours: cell volumetric growth, adhesion, repulsion, directed and random motility, cell cycle progression and death processes.
PhysiBoSS PhysiBoSS integrates these two software frameworks to obtain a detailed description of each cell's behaviour and how an alteration in a cell can affect the whole population. There are three main parts in the PhysiBoSS structure: • BioFVM module handles the simulation of one or more diffusing environmental entities  (Ghaffarizadeh et al. , 2016). It simulates diffusion, degradation and release of diffusible entities in the extracellular space, including extracellular matrix (ECM) (Fig. 1 , green). Space is discretised in a voxel mesh containing information of the local density of the modelled diffusing entities (oxygen, glucose, growth factors, etc. ); • PhysiCell core handles the representation of the cells' mechanics  (Ghaffarizadeh et al. , 2018)  and key phenotypic behaviours.
A cell is represented as a soft sphere with two radii: cellular and nuclear. It can move and interact with neighbouring objects, divide, and change its properties according to specific conditions (Fig. 1 , blue); • MaBoSS core computes the solutions of a logical model representing the dynamics of a network of intracellular events  (Stoll et al. , 2012). This module gathers its input conditions from the PhysiCell core evaluation (e. g. presence of neighbours or of growth factors, etc. ) and retrieves outputs that correspond to cell fates in PhysiCell core (e. g. forming adhesions, migrating, or dying). The logical model and parameter descriptions are defined in two files following MaBoSS standard, so any MaBoSS model can be directly used in PhysiBoSS, provided that its inputs and outputs are integrated in the agent-based part (Fig.
Numerical implementation The main core of the software is adapted from PhysiCell, and the MaBoSS module is compiled as a linked external library. PhysiBoSS is written in Cþþ with minimal external dependencies. PhysiBoSS uses one executable file reading an associated specific parameter file. This structure is convenient to generate numerous simulations with different parameters/configurations. Three executables are provided: The details for preparing, executing and visualizing a simulation can be found in detail in Supplementary File S1 and scripts are provided on the GitHub repository to automate them, along with stepby-step examples with all the necessary files. The computational time required for one individual run is strongly sensitive to its parameters, such as time/space steps, number of cells, diffusing entities, etc.
, 2013) , or as passive spheres  (Drasdo and Ho ¨hme, 2005). The choice for these different representations is strongly dependent on the biological question: a discrete ECM representation can be enough, while in other cases, it is necessary to model the deformation, softening, hardening or degradation of the ECM. This choice is also often a compromise between computational cost and the desired level of precision. PhysiBoSS proposes two ways of implementing ECM modelling: the first representation is to use ECM as passive spheres (Fig. 2A ) that can be pushed by other spheres or active cells depending on a friction coefficient. Cells can also degrade (or reinforce) these passive spheres upon contact with user-defined rates, by decreasing (or increasing) the radius of the passive spheres. The advantage of this implementation is that it integrates well within PhysiCell code structure and is not highly expensive computationally.
(2018). Additionally, we will extend its representation of the extracellular matrix, so that users can choose different modes of implementation according to the biological questions. Indeed, PhysiBoSS will be modified so as to offer different levels of representations from a very abstract representation (as currently possible as a field or passive spheres), to a more realistic representation (e. g. filamentous environment, which could be done by introducing a finite element mesh for the ECM, as suggested in  Ghaffarizadeh et al. , 2018). Finally, another direction could be to combine MaBoSS with other agent-based modelling software, to allow for different frameworks (e. g. Cellular Potts, vertex model) according to the biological question of interest. PhysiBoSS is available on GitHub (https://github.
com/sysbiocurie/PhysiBoSS), under the BSD 3-clause license, with its own DOI (10. 5281/zenodo. 1194827). PhysiBoSS is compatible with most Unix systems and a Docker image (https://hub. docker. com/r/gletort/ physiboss/) allows one to run PhysiBoSS on incompatible systems. We provide in the repository the source code of PhysiBoSS, several scripts to facilitate its use, reproducible examples (with all necessary files), and extended documentation on its wiki.
Funding This work received funding from the  European Union   Horizon 2020 research and innovation program  (grant agreement No  668858 ,  PrECISE  project). It is part of the  Chemotaxis  project, funded by ' Programme HTE'  from  ITMO Cancer , in collaboration with  ITMO BCDE and ITMO Technologies pour la santefrom the 'alliance nationale pour les sciences de la vie et de la sante (AVIESAN )' with  Institut National du Cancer and Inserm in the framework of Plan Cancer. AM was partly funded by  INVADE grant  from  ITMO Cancer. PM and RH were partly supported by the  Breast Cancer Research Foundation  and the  Jayne Koskinas Ted Giovanis Foundation for Health and Policy.
The CENDARI infrastructure is a research supporting platform designed to provide tools for transnational historical research, focusing on two topics: Medieval culture and World War I. It exposes to the end users modern web-based tools relying on a sophisticated infrastructure to collect, enrich, annotate, and search through large document corpora. Supporting researchers in their daily work is a novel concern for infrastructures. We describe how we gathered requirements through multiple methods to understand the historians' needs and derive an abstract workflow to support them. We then outline the tools we have built, tying their technical descriptions to the user requirements. The main tools are the Note Taking Environment and its faceted search capabilities, the Data Integration platform including the Data API, supporting semantic enrichment through entity recognition, and the environment supporting the software development processes throughout the project to keep both technical partners and researchers in the loop.
CENDARI integrates online available resources initially curated by cultural heritage institutions with the explicit goal of integrating them into the infrastructure to support the research process. Researchers from the project visited these institutions and negotiated data sharing agreements. For archivists, an Archival Directory was implemented, which allows the description of material based on the international Encoded Archival Description (EAD) standard (http: -The use of participatory design sessions as a method to collect users' needs, -The design of the infrastructure as a research support tool, -The deep integration of multiple resources through a data integration and enrichment process to further support the researchers' workflow. CENDARI has generated several benefits and outcomes: -An integrated system to conduct the early stages of historical research, -A catalogue of hidden archives in Europe (more than 5,000 curated institutional and archival descriptions with special attention given to archives without own digital presence), -A rich set of Archival Research Guides to help and guide historians by providing transnational access to information  [Edmond et al.
there was little point asking them what they needed, because they would not know, or their opinion about how a resource functioned, because they would not care. It was also assumed that technical experts were the people who knew what digital resources should look like. their opinion was the one that counted, since they understood the details of programming, databases, XML and website building. The plan, then, was to provide good resources for users, tell them what to do and wait for them to adopt digital humanities methods". Digital humanities has since then changed perceptions and we can now see a number of projects adopting participatory design to learn about users and their requirements  [Mattern et al. 2015; Wessels et al. 2015; Visconti 2016 ].
Iterative Approach and Support Technologies The software development in the project was carried out by adopting agile development methods. The software components were developed in short iterative release cycles and direct user feedback was encouraged and incorporated. The software is released as open source and the code is hosted on and maintained through GitHub  [CENGitHub 2016 ]. Where possible CENDARI used the existing solutions provided by DARIAH, such as the JIRA (https://www. atlassian. com/software/jira) ticketing system. Researchers who contacted relevant institutions for inclusion of their holdings into the platform used it to support and document the workflow from the first contact through negotiations and agreements for data sharing, to the final ingestion. Following the positive experience of historians using the tool, JIRA remained the obvious choice for bug and issue tracking during the software development.
To implement this infrastructure, a modular approach was undertaken. In using existing tools and services, we were able to offer many tools for some of the major features. At the same time, several important parts of the infrastructure (see Fig. 3 ) were developed especially for CENDARI. At the data persistence level we take a polyglot approach: relational databases such as PostgreSQL (http://www. postgresql. org) and MySQL (https://www. mysql. com/) for most web-based tools, ElasticSearch for our faceted search, and the Virtuoso (http://virtuoso. openlinksw. com) triple store to manage generated semantic data and and triples created by the NTE. In the application layer, the central data exchange and processing is carried out by the Data API, a component implemented within the project (see Section 6.
2). The data is stored in the Repository, based on CKAN and can be accessed through a web browser. Within the project, several extensions to CKAN were developed to support the data harvesting and user authentication mechanisms. The development of the Data API and the Litef Conductor focused on providing specific data services required for the project. Several user applications in CENDARI support the historian's workflows (see 3. 3): the NTE, the Archival Directory [CENArch 2015] and the Pineapple Resource Browser Tool (https://resources. cendari. dariah. eu/). The NTE, described in detail in Section 5, combines access to the faceted search and the repository data with individual research data. The NTE is an adaptation and extension of the EditorsNotes system (http://editorsnotes. org). The Archival Directory, based on the AtoM software, is used for manual creation and curation of archival descriptions.
Technologies The NTE implements a client-server architecture, the client side relying on modern web technologies (HTML5, JavaScript, D3. js), and the server on the Django web framework (https://djangoproject. com/). Faceted browsing and search functionalities are implemented using ElasticSearch, which unifies the exploration of all resources provided by the project. Django provides a rich ecosystem of extensions that we experimented with to support e. g. ElasticSearch and authentication. As we needed a tight integration to communicate precisely between services, we resorted to implementing our own Django extensions for faceted-search support, indexing and searching with ElasticSearch, access to semantic web platforms, and support for very large images through an image server. Although the principles behind all these services are well-known, the implementation is always unexpectedly difficult and time-consuming when it comes to interoperability and large datasets.
Searching over many projects multiplies the number. Furthermore, CENDARI also provides reference datasets such as DBPedia that defines millions of locations and dates. Therefore, our faceted search relies on ElasticSearch aggregation mechanisms, returning ranges and aggregates. Locations are returned as geohash identifiers with a count of matches in each geohash area, which enables visualising results quickly at any zoom level. Dates are also returned as intervals with the number of documents for the specified interval. The NTE fulfils its role of editor, image viewer, and search interface at scale. It currently serves about 3 millions entities and approximately 800,000 documents with a latency around 1-10 seconds depending on the number of users and complexity of the search queries.
Incremental Approach to Data Integration Data in CENDARI originate from archives, libraries, research institutions, researchers or other types of contributors of original content including data created in CENDARI. They have the following characteristics in common: variety of data licenses and usage policies; heterogeneous formats, conventions or standards used to structure data; multilinguality and diverse granularity and content quality. In addition, initial prospects suggested that CENDARI would have to accommodate data beyond just the textual and include audio and video materials, thus building an infrastructure with high tolerance for such heterogeneity. This scenery leads to the term data soup, defined as "a hearty mixture of objects, descriptions, sources and XML formats, database exports, PDF files and RDF-formatted data"  [Edmond et al.
The results of the processing and their log are stored in the file-system and available via the Data API in read-only mode. For each data processing service Litef implements a small plug-in, an indexer, which informs Litef about the types of resources it is interested in and the type of result it produces. This is a simple concept, but is expressive enough to define even complex processing flows. The plugin-based indexing architecture ensures that the system can be extended with new processing services, either to support additional formats, or to perform other specific data processing in the future. 6. 2. 2 Plain-Text Indexing, Metadata Extraction, Indexing for Search. Common processing steps for most of the resources are plain-text extraction and metadata extraction. These have been integrated in Litef as a standalone Java library named TikaExtensions (https://github.
2005]. The concepts in the ontologies also made use of MACS  [Clavel-Merrin 2004]  to facilitate multilingual access to the resources for English, German and French. Transformed ontologies form a large part of the KB, along with the data automatically generated by the DIP. Data can be browsed and searched through Pineapple, providing a unified view over transformed ontologies, the semantic data extracted from heterogeneous archival resources and, medieval manuscript ontologies, including visual navigation through the text and the structure of the medieval manuscripts. As an example, for an entry about "Somme", Pineapple will deliver entries from DBpedia, WWI Linked Open Data (http://www. ldf. fi/dataset/ww1lod/)), and Encyclopedia 1914-1918 (https://docs. cendari. dariah. eu/user/ pineapple.
DISCUSSION The goal of the CENDARI project was to support historical researchers in their daily work. All the infrastructure described has been designed with that goal in mind. This goal is relatively original in the digital humanities landscape and required a lot of experiments and a complicated infrastructure. Although the goal has been reached technically, we only know at the end of the project what the essential components needed are and the capabilities and digital literacy of historians in general. We try to summarise here the positive outcomes of the project and some of the pitfalls. It is very clear at the end of the project that historians benefit immensely from supporting tools such as the one offered by CENDARI. Data management at the historian level has become a technical nightmare without proper support.
As discussed in Section 3, CENDARI benefited from the feedback offered by historians to express their workflows and needs; to our knowledge, they were never explicitly stated before in such a constructive way. Even if our workflow does not support all the research steps performed by historians, it supports a large portion of them. The infrastructure to support faceted search and semantic enrichment is very complex. Is it worth the effort when large companies such as Google and Microsoft are investing in search engines? Our answer is positive: historians need more specific support than what search engines currently offer. It may sound like a banality, but here is the right place to state that not all data is digital; rather the opposite is true if cultural heritage is being taken into account.
Unique historical data exists only in paper format. The largest part of historical material is neither digitised nor available via metadata. While search engines are targeted at modern-life resources, historians want information on past time-ranges. They also have to deal with places that changed their name or even disappeared. Modern search tools are not meant for these goals and should be supplemented by more focused tools like the ones we designed. Our ingestion and enrichment tools are complex because they need to deal with multiple types of data, and extract useful information out of them in order to be usable by historians. Offering a faceted search engine is very useful to historians because it helps them contextualise the search results through time, location, etc. However, extracting good quality entities has a cost that explains the complexity of CENDARI.
In addition to the automatic extraction of entities from existing documents and data, it is now clear that a large portion of archive and library data will never get digitised, as acknowledged by all the institutions that the CENDARI project interacted with. Therefore, CENDARI has decided to use the data gathered by researchers as historical resource; we believe that this decision is essential to better support historical research in general. We believe that the "political" decision to keep the historians' notes private by default but to publish the tagged entities publicly is an effective way to spread and share historical knowledge with little risk of disclosing historians' work. We realised that there is a tension between the capabilities technology can provide and the digital training of historians to understand and use these capabilities.
4, allowed us to perform short iterations, allowing code deployments to production in mere hours before evaluation workshops. But conversely this added additional complexity at every step. On the other hand, some level of simplification is always needed to reach a new target audience, such as historian researchers. Early integration of the infrastructural components is essential to ensure timely feedback and reduce friction later, but in a setup of By mixing agile methods and long term planning, CENDARI built a reproducible infrastructure that has since been taken over by DARIAH in an effort to ensure its sustainability and availability for future use by historians and scholars from other disciplines alike.
To achieve a cross-domain level of interoperability of data and services, however, syntactic conformance and semantic data per se are not sufficient. Enabling tools for researchers to structure their knowledge and map it across different domains calls for joint efforts in the domain modelling, technical implementation across research infrastructures, training and communication with researchers and strong research community participation. Could a medieval archaeologist working with e. g. ARIADNE (http://www. ariadne-infrastructure. eu/) benefit from CENDARI? Our answer is positive, but we are aware that, additional service-level integration or semantic-data level and ontology developments alignment would be needed for flawless user experience. The infrastructure built by the CENDARI project does not support several steps of classical hermeneutic interpretation which is typical for historians.
ACKNOWLEDGMENTS The research leading to these results has received funding from the European Union Seventh Framework Programme  ([FP7/2007 -2013 ] [FP7/2007 -2011] ) under grant agreement n°284432. We are thankful to all CENDARI data providers who contributed with their content and made it available for research. We would like to express our sincere gratitude to all CENDARI partners for their great contributions to the development and setup of the infrastructure. The fusion of researchers, archivists, librarians and IT experts had made the CENDARI project a unique learning experience for all of us.
In our approach, the platoon leaders (the vehicles at the head of the trains) periodically send announcement messages that make their way through the sequences of L1VNs along the routes they are going to follow. Those L1VNs thus learn about the current length, position, and route of the platoon. Thereby, they can update the PSI of the corresponding intersection, with entries containing a timestamp, platoon ID, an estimated times of arrival of the platoon to successive intersections. The estimations are made according to an exponentially weighted moving average (EWMA) of the transit times along the road segments, which are readily measured by the VaNetLayer and VNIBR down in the protocol stack, for the two possible directions (If no data is received for some road segment for a relatively long time, the L1VN assumes that it is empty and the transit time is estimated from the length and a speed close to the maximum allowed).