dataesr/scientific-paragraphs-categorization huggingface dataset:
Moreover, Fig. S3  describes cell distributions on larger datasets (more than half a million of cells, replicated experiments). It can clearly be seen that the analysis performed with the differential-based approach allows to plot a distribution which is in closer agreement with theory than the classic approach. It is also interesting to note that optical optimizations can allow to further minimize fluorescence variations due to cell positioning in the droplet. In particular, the use of a laser line larger than the flow channel width allows, contrarily to a traditional laser spot, to fully scan the droplet (see Methods section and Figs  S8  and S9 ) and hence help in limiting error counts. It can be assumed that further improved quantifications could be obtained by increasing the signal sampling frequency.
It can also be highlighted that our procedure allows to access information regarding both cell viability and cell proliferation from a same experiment. Proliferation can indeed be inferred from data analysis as cell distribution in droplets can be precisely extracted. In our case, no significant increase was observed following incubation regarding occupational rates of 2 or more cells per droplet. Therefore no proliferation seems to occur in droplet for both the two cell lines. Such a result is consistent with formerly published data obtained with LIF (see ref. 13). This limited proliferation could be explained by the fact that the effective density of 1 cell in a 500 pL droplet is equivalent to ~2 million cells/mL at which cell growth is limited.
In the long-run the data analysis algorithm could be embedded in the LabVIEW FPGA software for real-time analysis and droplet sorting  24. We believe that our procedure improves the quantitativity of droplet-based single-cell studies and provides a clear protocol to assess the survival rate of cells in droplets, a pre-requisite for most cell-based assays. The presented method has clear advantages over traditional cell counting methods such as imaging or flow cytometry. Indeed imaging is only usable with adherent cells and flow cytometry does not allow the screening automation offered through droplet fluorescence coding.
Data acquisition. The photomultiplier tubes (PMT) signals are recorded and converted to 8 bits through the Analog to Digital Converter of the LabVIEW FPGA module. The sampling frequency is adjusted on needs up to 200 kHz. At each acquisition step, both 8 bit PMT value are joined to form a 64 bit word queued in a LabVIEW direct memory access (DMA) first in, first out (FIFO). DMA FIFO enables high bandwidth transfer of data from the Field-programmable gate array (FPGA) to the host computer. Up to four 8 bit signals can be joined in these 64 bit words, so PMT acquisition can be transferred together with other available internal signal, depending on the user need (such as internal machine state, camera synchronization signal, and/or high voltage signal trigger). This usage of a monolithic 64 bits proved to increase robustness against data and/or synchronization loss in comparison to either serial 8 bit entrelacement or usage of parallel DMA FIFO.
On the host computer FIFO elements are dequeued in the main LabVIEW vi. Each 64 bits word is decoded to the four original 8 bits values. These data are then directly streamed to the disk in a Waveform Audio FileFormat (WAV) 8 bit PCM. At this step, care is taken to dequeue data from the FIFO in a timely manner, in order to avoid any data loss. This involves the proper design of the execution structure of the overall LabVIEW vi to prioritize the host computer resources. The use of WAV 8 bit PCM as saving format has several advantages among which: (i) the possibility to record 4 audio tracks simultaneously while keeping synchronization. (ii) the uncompressed nature of the file which implies a lighter load on the central processing unit during recording and no data loss. (iii) the ability to include metadata in the header, such as the sampling frequency (iv) the availability of OpenSource visualization tools (Audacity) and interface library in several analysis language (C, Scilab, MATLAB).
Data analysis. We developed a matlab script to count the number of cells in each droplet. It is composed of three steps. Firstly, the fluorescent signals of droplets (red channel) and cells (green channel) in the time course are filtered and illustrated in a 1D plot (Fig. 1c ). This plot allows to define two thresholds, one for the detection of droplets and another for the detection of cells. The threshold of droplet should be higher than the noise level and lower than the droplets fluorescent level. Second, the droplet-passing time points are selected by applying the threshold of droplets (Supplementary Fig. S1a  and b ). As a last step, the signals of cells in each droplet are located within the droplet occurence dataset (Supplementary Fig. S1c ). Within these sequences, the cell signal (Scell) is filtered by a triangular convolution window of length n with the kernel (1, 2, 3, … n …, 3, 2, 1) (Supplementary Fig.
Acknowledgements We would like to thank  Dr. Loïc MARTIN  for kindly providing the eGFP-transformed E. coli cells. This work was supported by the  Ministère de l′Enseignement Supérieur et de la Recherche , the  Université Paris-Descartes , the  Centre National de la Recherche Scientifique (CNRS)  and the  Institut National de la Santé et de la Recherche Médicale (INSERM). V. Taly acknowledges the  Agence Nationale de la Recherche  ( ANR Chipset , no. ANR-15-CE11-0008-04 ) and the  SIRIC CARPEM  for financial support. H. Lu  acknowledges  SIRIC CARPEM and Région Ile-de-France  for financial support. O. Caen  thanks  ITMO National Cancer Alliance for Life Sciences and Health (AVIESAN, INSERM , no. HAP_2012001 ) and the  Association pour la Recherche sur le Cancer  for fellowships within the  Frontiers in Life Science Ph.
D. program  (FdV). Eleonora Zonta received salary through the  INSERM Physicancer program  (no. PC201423 ). J. -C. B. acknowledges the support from the  ERC  ( FP7/2007-2013/ERC Starting Grant 306385-SofI ) from the  French  state in the frame of the "Investments for the future",  Programme IdEx Bordeaux ,  ANR-10-IDEX-03-02  and of the "Région Aquitaine". We would like to thank  Fluigent  for collaborating with us on the cell encapsulation solutions and  RainDance  for kindly providing us the EAsurfactant.
The benefits of BIM in cost estimating discussed in the preceding paragraph has been achieved partly due to the use of various BIM software packages that enabled accurate modelling of projects thus leading to precise quantity takeoffs (QTO). Some leading software in the field are Navisworks, Autodesk QTO, CostX, Innovaya, iTWO, d-profiler, Vico, ProjectWise Navigator, Bentley ConstrucSim, Balfour Technologies, etc. The process of cost estimation using these software packages can be modelled in Fig. 1. The current cost estimating process as depicted in Fig. 1  has four major short comings. Firstly, some of the cost estimating software do not contain a measurement standard that can be used in cost estimating. This means, potentially there could be lack of consistency in cost estimates produced with BIM software that do not contain measurement standard.
The former assumes names that may not be consistent with other ontological concepts. For example, instances generated automatically from Protégé-OWL assumes its parent class' name, which can be confusing. Partly for the preceding reason, we opted for manual creation of instances. To facilitate understanding, it is recommended and logical to use same names of the building components as in the BIM model. This could be the IFC nomenclature or native BIM software file name. Although, in this case study house, most IFC nomenclature were similar to the Revit native nomenclature. For example, a cavity wall in the Revit is named as Basic Wall Cav 50 100 200 Cladding while the IFC equivalent is Basic Wall:  Cav 50 100 200 Cladding:219191. We re-used IFC nomenclature, although in editing in Protégé-OWL, underscore were used between strings as spaces and double colon are not allowed in Protégé-OWL (see pane I of Fig.
Similarly, all the syntax meanings for SWRL can be found on the link (https://github. com/protegeproject/swrlapi/wiki/ SQWRL#SQWRL_Language_Features). Based on our experience from previous research works (e. g. [6, 4, 8, 48, 44] , the process map for developing SWRL rules is proposed in Fig. 5. The proposed process map facilitates the understanding of the construction of SWRL rules, ensures nothing is missed during rule construction and optimises the chances of the rules to be syntactically and semantically correct. 2. 8 Internal_Doors (?x) ^hasUnitCost(?x, ?a) ^swrlb:-greaterThan(?a, 5000) ?sqwrl:select(?x, ?a) q-1 The first atoms of the antecedent of the SWRL q-1 list internal doors (i. e. 2. 8 Internal_Doors (?x)) and their respective unit costs (i. e. hasUnitCost(?x, ?a)) and then a constraint on the unit costs to be greater than 5000 (units in £ as this will be defined in the ontology editor Protégé-OWL) (i.
The complete ontology The complete ontology is made up of classes, properties, instances and rules. The different components of the ontology are presented in Fig. 6. To facilitate understanding, it is recommended and logical to use same names of the building components as in the BIM model. This could be the IFC nomenclature or native BIM software file name. Although, in this case study house, most IFC nomenclature were similar to the Revit native nomenclature; it might not be the case with other BIM software. For example, a cavity wall in the Revit is named as Basic Wall Cav 50 100 200 Cladding while the IFC equivalent is Basic Wall: Cav 50 100 200 Cladding:219191. with the term IFCBUILDING being at the top concept as earlier explained in Table  1. We opted for IFC nomenclature, although in editing in Protégé-OWL, underscore were used between strings as spaces and double colon are not allowed in Protégé-OWL (see pane I of Fig.
Editing the ontology into a BIM software In order to use the developed ontology in a BIM software, a programme was written to translate the OWL ontology of Fig. 6  to an XML-based ontology. This was done because most BIM software can only read XML based files. The transformation is achieved by using the OWL API to manipulate the OWL ontology file; JDOM to manipulate and create the content of XML and Hermit to reason over the file. To provide more clarity, the specific contributions of OWL API, JDOM and Hermit will be examined in the ensuing paragraphs. The purpose of the OWL API in this transformation process is to parse the OWL file (i. e. the developed ontology) in order to extract the name of each class and transform it to a corresponding String that will be used in the building of the XML file.
Code 1: Parsing of the OWL file The JDOM API is used for building an XML file based on the input OWL file. Although it is possible to convert the OWL file into RDF/ XML format within the Protégé software, the resulted XML file will have a ''. rdf" extension and not an ''. xml" extension. The ''. rdf" extension is not supported in Navisworks. This is corroborated by findings from Karan et al. [28] , that stated that the results of Semantic Web queries are not supported by BIM authoring tools. That is why it is necessary to convert the OWL file into an XML file with the extension ''. xml". The produced XML file must respect a particular structure (which can be read by Navisworks) depicted in Fig. 7. Before building the entire XML, a String containing XML elements is built incrementally by the method printHierarchy(OWLReasoner reasoner, OWLClass clazz, int level) according to the hierarchy in the OWL file.
For syntactic verification, it is important to ensure the ontology is technically consistent and complies with OWL syntax, the intended developed language. For technical consistencies, Pellet 1. 5. 2, an OWL-based reasoners in Protégé-OWL was used. For OWL syntax compliance, the Manchester OWL syntax validator was used. The OWL validator accepts ontologies written in RDF/ XML, OWL/XML, OWL Functional Syntax and Manchester OWL Syntax. After the ontology has been semantically and syntactically verified, it was now validated against what it was intended for. In other words does the ontology do what it was intended for? This is achieved through the employment of a case study. It is important to recall the two main purposes of the developed ontology are an ontology that allows reasoning to be performed and also for QTO to be undertaken for cost estimation.
As can be seen in Fig. 10 , reasoning can be conducted on the full ontology. The transformed ontology was imported into one of the leading BIM software-Navisworks. The importation was successful and the imported ontology was used in performing QTO. The work breakdown structure generated in the 5D software (see C on Fig. 11 ) conforms with what is generally common in practice. Furthermore, the model lengths generated (see D on Fig. 11 ) are exact values of the model prior to being imported into Navisworks. The results from the 5D software was also validated by the same 6 experts through focus group discussion discussed in the second paragraph of this section.
Challenges and lessons learned in the modelling process In the development of this ontology, three major challenges were encountered. Firstly, given spaces are not allowed in concepts or names in Protégé_OWL, it was not possible capturing names of concepts as they appear exactly in NRM 1. For example, in practice the concept ''Fittings, Furnishes and Equipment" will appear as it is but in protégé-OWL, commas(,) and spaces are not allowed. Underscore (_) was therefore used to separate words, such that this Identified constraints in the NRM 1 Model the constraints using axioms and rules Demonstrate the use of the ontologies in reasoning and performing QTOs/cost estimation; Used queries and rules to infer knowledge from the rich ontology Used the transformed ontology in QTOs by mapping the generated quantities from Navisworks Evaluate the ontology whether it is fit for the intended purpose in standard BIM software systems.
Also, the re-use of existing ontologies is crucial in the development of ontologies. To this end, the IFC domain ontology, one of the most important ontology in the construction domain was used. The use of IFC facilitated the abstraction of house components for QTOs and hence cost estimation. Thirdly, the developed ontology was implemented in Protégé-OWL 3. 5, as this tool is one of the leading open source ontology editing tool widely used in the academic community. The fourth activity consisted of checking for consistencies in the ontology using reasoners. It is important to recall that the purposes of the ontology are for performing reasoning for other applications in construction and cost estimation. So after the complete ontology was checked or validated for consistencies and compliance, in the fifth task a code was written and used in transforming the complete ontology for purposes of cost estimation.
In effect two ontologies were obtained-one complete rich ontology that included all ontology concepts and core ontology or catalogue of classes that consisted mostly of NRM 1 concepts. The sixth activity consisted of illustrating examples of reasoning task that can be performed in the complete ontology and QTOs in the core ontology. The reasoning examples were performed in the Protégé-OWL 3. 5 environment while for QTOs and cost estimation the core ontology was exported to Navisworks for QTOs and later on to MS Excel for cost estimation. After these stages both results were validated whether both ontologies met the purposes for which they were developed for. For the reasoning component, the queries from protégé-OWL 3. 5 were compared to the schedules generated from the Revit software and found to be the same.
For the QTOs, the automatic results QTO from Navisworks were compared with real manual computation of quantities using real dimension of the case study house. Both results yielded similar results with very minor insignificant differences. Furthermore, 6 experts were used to validate the core ontology for QTOs. Given we have tested the core ontology on only Navisworks, as part of future study, this ontology will be tested on other BIM software systems such as Autodesk QTO. Also, it is expected that other end-users can adapt or transform the complete ontology in this study to meet their various needs.
Acknowledgements This work was jointly funded by the  Ecole Nationale d'Ingénieurs de Tarbes  through the '' Projet Soutien á la Mobilité Internationale (SMI) 2014 " programme and the  Oxford Brookes University  through the  Central Research Fund. Encouraging interdisciplinary research is amongst the top strategies of the two institutions. The authors gratefully acknowledge the financial support received. Also, this work was conducted using the Protégé resource, which is supported by grant  GM10331601  from the  National Institute of General Medical Sciences  of the  United States National Institutes of Health. The last but not the least, we thank  Mr. George Swann  for producing the model used as a case study in this manuscript. At the time of submission of this article George was a student on the  Quantity Surveying and Commercial Management degree programme in the School of the Built Environment ,  Oxford Brookes University.
Test sets We use benchmark test sets for the task of bilingual lexicon induction to evaluate the performance of our model. The VULIC1000 dataset  (Vulic and Moens, 2016)  comprises 1000 nouns in Spanish, Italian, and Dutch, along with their one-to-one ground-truth word translations in English. We construct a new test set (CROWDTEST) for a larger set of 27 languages from crowdsourced dictionaries  (Pavlick et al. , 2014). For each language, we randomly pick up to 1000 words that have only one English word translation in the crowdsourced dictionary to be the test set for that language. On average, there are 967 test source words with a variety of POS per language. Since different language treats grammatical categories such as tense and number differently (for example, unlike English, tenses are not expressed by specific forms of words in Indonesian (id); rather, they are expressed through context), we make our evaluation on all languages in CROWDTEST generic by treating a predicted English translation of a foreign word as correct as long as it has the same lemma as the gold English translation.
Monolingual Signals for Translation We define cold source words in our experiments as source words that have no associated WIKI translations and fewer than 2 associated WIKI+CROWD translations. For each cold source word f , we predict the score of its translation to each candidate English word e using the auxiliary formulation of xe,f (Equation  2 ). There are two auxiliary signals about the words that we use in our experiments: (1) bilingually informed word embeddings and (2) visual representations. Bilingually Informed Word Embeddings For each language, we learn monolingual embeddings for its words by training a standard monolingual word2vec skipgram model  (Mikolov et al. , 2013b)  on tokenized Wikipedia pages of that language using Gensim  ( Řehůřek and Sojka, 2010). We obtain 100-dimensional word embeddings with 15 epochs, 15 negatives, window size of 5, and cutoff value of 5.
This shows that incorporating more and better signals of translation can improve performance significantly. Evaluating on CROWDTEST, we observe a similar trend over all 27 languages (Figure  5 ). Particularly, we see that BPR W and BPR W+C suffer from the cold start issue where there are too few or no observed translations in the matrix to make accurate predictions. Incorporating auxiliary information in the form of bilingually-informed word embeddings improves the accuracy of the predictions dramatically. For many languages, learning these bilingually-informed word embeddings with non-linear mapping improves accuracy even more. The top accuracy scores achieved by the model vary across languages and seem to be influenced by the amount of data i. e. , Wikipedia tokens and seed lexicons entries available for training.
Acknowledgments This material is based in part on research sponsored by  DARPA  under grant number  HR0011-15-C-0115  (the  LORELEI program ). The U. S. Government is authorized to reproduce and distribute reprints for Governmental purposes. The views and conclusions contained in this publication are those of the authors and should not be interpreted as representing official policies or endorsements of  DARPA  and the  U. S. Government. This work was also supported by the  French National Research Agency  under project  ANR-16-CE33-0013 , and by  Amazon  through the  Amazon Academic Research Awards (AARA) program.
B. IoT-EPI: a joint project initiative to foster a vibrant and sustainable IoT-ecosystem in Europe The seven R&I projects carried out in the ICT30 cluster aims to improve horizontal interoperability and provide viable proofs-of-concept about how existing platforms for connected smart objects can easily, safely, and reliably be integrated for a multiplicity of novel IoT applications. • Interoperable APIs: this topic refers to standardized and open APIs that must cope with the IoT peculiarities and requirements, e. g. to support efficient data publication, consumption and composition of heterogeneous information sources from across various platforms. Those APIs must provide the necessary messaging interfaces, along with generic content description models for IoT data representation. Each project will investigate, adopt (or develop) such open API solutions, although one challenging task amongst the projects will be the convergence towards the use of a common set of standards; • Autonomous reasoning: this topic refers to context-aware and self-adaptation capabilities of the system/ecosystem  [32].
B. Scenario 1: A performance analysis of O-MI/O-DF A first version of the O-MI and O-DF reference implementation has been released  8  and used as foundation of our smart parking system's proof-of-concept. As a complement of this reference implementation, a smart parking emulator and monitoring tool has been developed for both emulating the sensor/actuator events occurring on the field (e. g. , the arrival of a car at a specific parking area. ) andfrom the client side -for visualizing the current state of the parking. Two screenshots of the parking emulator and monitoring tool are shown in Fig. 6. From an implementation perspective, and according to the O-MI/O-DF reference implementation guidelines, it is necessary to develop a software agent that periodically pushes the emulated data to an internal database (internal to the reference implementation).
To this end, a network analyser (Wireshark) has been used to analyze the network traffic considering the smart parking use case, which contains 23 InfoItems in total. At a more concrete level, these 23 InfoItems are read on an incremental basis, i. e. one read request/response including 1 InfoItem (and associated Objects' tree) is performed, then one request/response including 2 InfotItems, and so on. The result of this analysis is given in Fig. 8 , where data load is composed of: • a constant part related to the sum of the Ethernet protocol (26 bytes), the IP and TCP headers (respectively 20 and 32 bytes) for each request/response and their respective acknowledgment (78 bytes in the reference implementation). The transient states of the TCP opening and closing operations have not been considered.