dataesr/scientific-paragraphs-categorization huggingface dataset:
Data Application Layer The data application layer provides applications that allow users to extract value from data. For example, a data lake may provide an interactive query system to do descriptive and predictive analytics. It may also provide tools to produce reports and visualize data. In ArchaeoDAL's implementation, we use a Web-based notebook, Apache Zeppelin 10  , as the front end. Zeppelin connects to the data analytics engine Apache Spark that can run a complex directed acyclic graph of tasks for processing data. Our notebook interface supports various languages and their associated Application Programming Interfaces (APIs), e. g. , R, Python, Java, Scala and SQL. It provides a default data visualization system that can be enriched by Python or R libraries. ArchaeoDAL also provides a web interface that helps users download, upload or delete data.
Metadata Model. In ArchaeoDAL, we adopt goldMEDAL  [13] , which is modeled at the conceptual (formal description), logical (graph model) and physical (various implementations) levels. goldMEDAL features four main metadata concepts (Figure  3 ): 1) data entities, i. e. , basic data units such as spreadsheet tables or textual documents; 2) groupings that bring together data entities w. r. t. common properties in groups; 3) links that associate either data entities or groups with each other; and 4) processes, i. e. , transformations applied to data entities that produce new data entities. All concepts bear metadata, which make goldMEDAL the most generic metadata model in the literature, to the best of our knowledge. However, we encountered a problem of terminology variation when creating metadata.
goldMEDAL does indeed not provide explicit guidance for metadata creation. This can lead to consistency and efficiency problems. For example, when users create data entities, they have their own way of defining attributes, i. e. , key/value pairs that describe the basic properties of data. Without a universal guideline or template, every user can invent his own way. The number, name and type of attributes can be different. As a result, without explicit guidelines or templates, it may become quite difficult to retrieve or search metadata. Thus, we enrich goldMEDAL with a new concept, data entity type, which explicitly defines the number, names and types of the attributes in a data entity. All data entity types form a type system that specifies how metadata describe data inside the lake. Since each and every data lake has specific requirements on how to represent data to fulfill domainspecific requirements, metadata must contain adequate attributes.
Thus, we need to design a domain-specific type system for each domain. For example, in the HyperThesau project, users need not only semantic metadata to understand the content of data, but also geographical metadata to know where archaeological objects are discovered. As a result, the type system is quite different from other domains. In sum, the benefits of having a data entity type system include: 1) consistency, a universal definition of metadata can avoid terminology variations that may cause data retrieval problems; 2) flexibility, a domain-specific type system helps define specific metadata for requirements in each use case; 3) efficiency, with a given metadata type system, it is easy to write and implement search queries. Because we know in advance the names and types of all metadata attributes, we can filter data with metadata predicates such as _ > 10/02/2016.
Thesaurus Modeling. Although thesauri, ontologies and taxonomies can definitely be modeled with goldMEDAL, its specifications do not provide details on how to conceptually and logically model such semantic resources, while we especially need to manage thesauri in the HyperThesau project. A thesaurus consists of a set of categories and terms that help regroup data. A category may have one and only one parent. A category without a parent is called the root category. A category may have one or more children. The child of a category is called subcategory or term. A term is a special type of category that has no child but must have a parent category. A term may have relationships with other terms (related words, synonyms, antonyms, etc. ). Fortunately, categories and terms can easily be modeled as data entities and structured with labeled links, with labels defined as link metadata.
Data Security Layer The data security layer provides tools to ensure data security. It should ensure the user's authenticity, data confidentiality and integrity. ArchaeoDAL's implementation orchestrates more than twenty tools and frameworks, most of which have their own authentication system. If we used their default authentication systems, a given user could have twenty login and password pairs. But even if a user decided to use the same login and password for all services, s/he would have to change it twenty times in case of need. To avoid this, we have deployed an OpenLDAP server as a centralized authentication server. All services connect to the centralized authentication server to check user login and password. The access control system consists of two parts. First, we need to control the access to each service.
For example, when a user wants to create a new thesaurus, Atlas needs to check whether this user has the right to. Second, we need to control the access to data in the lake. A user may access data via different tools and the authorization answer of these tools must be uniform. We use Apache Ranger  12  to set security policy rules for each service. For data access control, we implement a role-based access control (RBAC) system by using the Hadoop group mapping service. Data security is enforced by combining the three systems. For example, a user wants to view data from a table stored in Hive. S/he uses his/her login and password to connect to the Zeppelin notebook. This login and password are checked by the OpenLDAP server. After login, s/he runs a SQL query that is then submitted to Hive.
Resource Manager Layer As data lakes may involve many servers working together, the resource manager layer is responsible for negotiating resources and scheduling tasks on each server. This layer is optional, because a reasonably small data lake may be implemented on one server only. As ArchaeoDAL rests on a distributed storage and computation framework, a resource manager layer is mandatory. We use YARN  15  , since this resource manager can not only manage the resources in a cluster, but also schedule jobs.
Communication Layer The communication layer provides tools that allow other layers, e. g. , data application, data security and data governance, to communicate with each other. It must provide both synchronous and asynchronous communication capability. For example, a data transformation generates new metadata that are registered by the data governance layer. Metadata registration should not block the data transformation process. Therefore, the data insights and governance layers require asynchronous communication. However, when a user wants to visualize data, the data application and security layers require synchronous communication, since it is not desirable to have a user read data before the security layer authorizes the access. ArchaeoDAL's implementation uses Apache Kafka, which provides a unified, high-throughput, low-latency platform for handling real-time data feeds.
ArchaeoDAL's Deployment We have deployed ArchaeoDAL's implementation in a self-hosted cloud. The current platform is a cluster containing 6 virtual machines, each having 4 virtual cores, 16 GB of RAM and 1 TB of disk space. We use Ambari 16  to manage and monitor the virtual machines and installed tools. The current platform allows users to ingest, store, clean, transform, analyze, visualize and share data by using different tools and frameworks. ArchaeodAL already hosts the data of two archaeological research facilities, i. e. , Bibracte 17 and Artefacts 18. Artefacts currently amounts to 20,475 records and 180,478 inventoried archaeological objects. Bibracte currently contains 114 excavation site reports that contain 30,106 excavation units and 83,328 inventoried objects. We have imported a thesaurus developed by our partner researchers from the Maison de l'Orient et de la Méditerranée 19  , who study ancient societies in all their aspects, from prehistory to the medieval world, in the Mediterranean countries, the Near and Middle-East territories.
Heterogeneous Archaeological Data Analysis In this first example, we show how to analyze heterogeneous archaeological data, how to generate relevant metadata during data ingestion and transformation, and how to organize data flexibly via the metadata management system. The Artefacts dataset consists of a SQL database of 32 tables and a set of files that stores detailed object descriptions as semi-structured data. This dataset inventories 180,478 objects. The data management system is implemented with Apache Atlas (Section 3. 7. 3) and provides three ways to ingest metadata: 1) pre-coded atlas hook (script), 2) self-developed atlas hook and 3) REpresentational State Transfer (REST) API.
Structured Data Ingestion and Metadata Generation. To import data from a SQL database, we use a hook dedicated to Sqoop that can generate the metadata of the imported data and ingest them automatically. A new database is created in ArchaeoDAL and its metadata is generated and inserted into the Atlas instance (Figure  4 ). Figure  5  shows an example of table metadata inside Artefacts. 4. 1. 2 Semi-structured Data Ingestion and Metadata Generation. We provide three ways to ingest semi-structured data. The simplest way is to use Ambari's Web interface (Figure  6 ). The second way is to use the HDFS command-line client. The third way is to use a data ingestion tool. ArchaeoDAL provides a tool called Flume. The Flume agent can monitor any file system of any computer. When a file is created on the monitored file system, the Flume agent will upload it to ArchaeoDAL automatically.
6 " name " : " object -1 6 8. txt " , 7 " path " : " hdfs : // lin 0 2. udl. org : 9 0 0 0 / HyperThesau / Artefacts " , 8 " user " : " pliu " , 9 " group " : " artefacts " , 10 " creation_time " : " 2 0 2 0 -1 2 -2 9 " , 11 " owner " : " pliu " , 12 " numberOfReplicas " : 0 , We also developed an Atlas API in Python 21  to allow data engineers to generate and insert metadata into Atlas more easily. As Amazon S3 is the most popular cloud storage, we also developed an Atlas S3 hook 22.
Data Transformation and Metadata Generation for Data Lineage Tracing. Once Artefacts data are ingested into ArchaeoDAL, let us imagine that an archaeologist wants to link the detailed description of objects (stored in table objects) with their discovery and storage locations. The first step is to convert the semi-structured object descriptions into structured data. We developed a simple Spark Extract, Transform and Load (ETL) script for this sake. Then, we save the output structured data into Hive tables location (discovery location) and musee (the museum where objects are stored). Eventually, we join the three tables into a new table called ob-jects_origin that contains the objects' descriptions and their discovery and storage locations. Thereafter, objects_origin's metadata can be gathered into Atlas with the help of the default Hive hook 23  and a Spark hook developed by Hortonworks 24.
Data Indexing and Search through thesauri As mentioned in Section 3. 7. 2, thesauri are important metadata for project HyperThesau. As an example, we import a thesaurus This thesaurus is mainly used to index the inventoried archaeological objects of Artefacts. Its basic building blocks are terms that can be grouped by categories (Figure  11 ). We can associate any data entity with any term. A data entity can be associated with multiple terms. After we index a data entity with a term, we can search data by using the terms of a thesaurus. For example, we have a database table called bibliographie and a file called 204docannexe. csv that contains information about shields. Suppose we need to associate these two data entities with the term bouclier (shield in French). After indexing, we can click on the term bouclier to find all data associated with this term (Figure  12 ).
CONCLUSION AND FUTURE WORKS In this article, we first introduce the need of archaeologists for software platforms that can host, process and share new, voluminous and heterogeneous archaeological data. Data lakes looking like a viable solution, we examine different existing data lake solutions and conclude that they are not generic, flexible nor complete enough to fulfill project HyperThesau's requirements. layer. Yet, one of our collaborators could easily replace HDFS by Amazon S3. In Section 4. 1. 4, we demonstrate how to organize data flexibly, which many existing solutions  [1, 5, 6, 15]  do not allow. In Section 4. 1. 4, we also demonstrate that ArchaeoDAL can gather metadata automatically during the full data lifecycle. Eventually, many features of ArchaeoDAL are very hard to demonstrate in a paper.
VI. 1. Detector Modeling and Particle Identification Particle objects considered throughout the analysis are defined using the ATLAS configuration card available p j T > 25 GeV, |η j | < 4. 5, nj ≥ 2, Qµ 1 × Qµ 2 = 1, M (j1, j2) > 700 GeV Signal Region Cuts p µ 1 T , p µ 2 T > 300 GeV from the Delphes repository. In the results that follow the ATLAS card was modified to construct jet candidates from hadronic activity using the anti-k T sequential clustering algorithm with a distance parameter R = 0. 4. This value is more widely used in recent ATLAS data analyses than the default value of R = 0. 6. All the other parameters in the configuration card, which include particle identification and mis-tagging efficiencies as well as the fiducial geometry definition, are left unchanged. As summarized in section III.
Cleared samples were imaged by light sheet microscopy (LSM) that allows large 3D visualization in intact samples  [10]. Since confocal microscopy can also be used on cleared tissues, we also performed complementary analysis with this imaging technique. For 3D image processing, we developed a standardized methodology to extract 3D quantitative data with the open source software ImageJ. Capillary network structure was characterized with nine parameters divided in two types:  (1)  global parameters related to the overall structure of the vascular system (vascular density, fractal dimension, number of segments, total length, number and percentage of node), and (2) architectural parameters related to the structure of each segment of the vascular system (length, diameter, and tortuosity). Comparisons between the left (LV) and right (RV) ventricles and the septum (S) were made, as no comparative information about mouse physiological coronary capillaries regarding the different parts of the heart was found in the literature.
Shrinkage Measurement The iDISCO+ technique has been shown to generate a shrinkage of the tissues  [10]. On each sample, the shrinkage was estimated from two orthogonal 2D-images taken before and after clearing. Length (l), width (w), and thickness (t) were measured using ImageJ/Fiji software. These measurements were used to calculate an estimated heart volume, considered as an ellipsoid, thanks to the following equation: Cardiac Volume = 4 3 × π × l 2 × w 2 × t 2 The shrinkage percentage was calculated for the length, the width, the thickness, and the ellipsoidal volume as the ratio of each parameter value after and before optical clearing on the parameter value before optical clearing.
Confocal Microscopy On one heart, both global parameters and architectural parameters of the LV capillary network were calculated from images obtained by confocal microscopy, in order to be compared with the values obtained in the same LV heart from images obtained by light sheet microscopy. A 3D image of the capillary network and the architectural parameter curves obtained from confocal microscopy are given in Figure  4. Data obtained from both imaging methods are given in Table  5.
g. , the geostrophic balance. This constitutes another topic of research development for the PKF, facilitated by the use of symbolic exploration. Note that the expectation operator as introduced here can be used to compute Reynolds equations encountered in turbulence. This opens new perspectives for the use of SymPKF for other applications that could be interesting, especially for automatic code generation. O. Pannekoucke and P. Arbogast: SymPKF (v1. 0) Appendix A: Splitting for the computation of the parametric dynamics In this section we show that using a splitting strategy is possible for the design of the parametric dynamics. For this, it is enough to show that given dynamics written as ∂ t X = f 1 (X ) + f 2 (X ), (A1) the dynamics of the error, the variance, the metric, and the aspect all write as a sum of trends depending on each process f 1 and f 2.
Participants We contacted 860 people registered in the iEtD database. The project team sent introductory emails and two reminders in the summer of 2017. Eighty-one registrants responded to these emails (9. 5% response rate), and 61 (7%) were excluded as they did not complete an entire framework for a real group decision context or for educational purposes. Twenty participants were considered iEtD users and were invited to the interviews. Eight participants agreed to be interviewed. Participants worked in international or national organizations that developed guidelines (e. g. World Health Organization, Australian Health and Medical Research Council). Participants used the iEtD mostly for guideline development, but also for educational purposes (i. e. , training workshops of panels). Two participants reported expertise in both the GRADE approach and the iEtD; two attended workshops before starting to use the iEtD, and four did not receive any training.
This paper focuses on a numerical approach to finding the p-y curves for laterally loaded piles. The Drucker-Prager plastic model is employed and implemented within a finite element MATLAB code. The pre-and post-processing code for Gmsh and related numerical tools are established as well. The p-y curve results from this new approach have been validated and compared to the typical design equations of API (American Petroleum Institute) and Matlock. The validation reveals that the code leads to lower p-y curves than the API and Matlock equations when the horizontal displacement is less than 0. 35 times the diameter of the pile (B). A sensitivity analysis of the number of elements and the interface thickness is presented. The results indicate that the obtained p-y curves are independent of the two factors.
It is more flexible and less time consuming to analyze the p-y characteristics by using the finite element method than the full-scale in-situ tests. This paper aims to construct p-y curves that take into account the properties of the interface between the soil and the concrete pile as characterized via the experimental campaign of interface direct shear test in the laboratory. To do this, the Drucker-Prager constitutive model is adopted to describe irreversible (plastic) strains occurring at the interface between the surrounding soil and the concrete pile. The Drucker-Prager constitutive law is then implemented into a two-dimensional finite element (FE) code within a MATLAB environment that was initially developed by Bonnet and Frangi  [12]  and Bonnet et al. [13]. A 2-D problem describing the effect of a transversal displacement applied to a pile section has been simulated.
Drucker-Prager Model The Drucker-Prager (DP) model  [26]  for the soil is implemented using the following MATLAB code, which performs the numerical simulation for calculating the p-y curves. The DP yield criterion is defined as  [27] : f = 2 3 q -(A -Bp 1 ) = 0 (6) where p 1 is the mean normal stress, σ 1 is the major principal stress, σ 2 is the principal stress, and σ 3 is the minor principal stress. A and B are related to the cohesion c and friction angle ϕ in the Mohr-Coulomb (MC) criterion; q is the second invariant of the deviatoric stress  [27] : q = 3J 2 = 1 √ 2 (σ 1 -σ 2 ) 2 + (σ 2 -σ 3 ) 2 + (σ 1 -σ 3 ) 2 (7) As the Drucker-Prager model is represented in the stress plane by a cone with a circular cross section, it is possible to relate it to the Mohr-Coulomb model considering the section of the MC pyramid to be inscribed or circumscribed to the DP cone.
MATLAB Code The MATLAB FE code was originally developed by Bonnet and Frangi  [12]. Further improvements have been implemented in GeM (École Centrale de Nantes). The Drucker-Prager constitutive model has been implemented within the MATLAB FE code that considers the non-associate and associate flow rule. Although the code started from the relatively simple DP model, more complicated constitutive laws can be developed based on this primary work. The pre-and post-processing phases are performed with the freely available code Gmsh  [35]. The link between the MATLAB FE code and the pre-and post-processing code for Gmsh, and several specific numerical tools, has been established as well.
Validation To validate the calculation of the p-y curves, interface test results of soil consisting of 55% clay and concrete plate are selected as input parameters and the corresponding p-y curves are traced and compared with different design methods (API and Matlock). A total of 11,390 T3 elements are used, and the interface width is equal to 5 mm. The properties of the interface, the soil, and the pile are given in Table  2. The concrete pile is considered a rigid material with a Young's modulus of 33 GPa (Table  2 ). The pile is loaded by stepwise loading (horizontal displacement) with increments of 0. 002 m in the MATLAB code. The lateral capacity (p) of the pile is calculated by integrating the normal and tangential stresses along the circumference of the pile (or of the soil-pile interface).
The results are presented in terms of normalized p-y curves (Figure  4 ) using the shear strength of the soil and the pile diameter (see also  [20, 37] ). More specifically, in this study, the soil is isotropic normally consolidated and the interface behavior is characterized by a direct shear test in drained condition, hence the critical drained interface shear strength (s d ) of the interface and the pile diameter B are used to normalize p so as to obtain the lateral bearing capacity factor p/(s d B), i. e. , the N p in Equation (  1 ). The horizontal displacement is normalized by the pile diameter B. The p-y curves calculated by the MATLAB code with DP model on the circular geometry are compared to the ones computed from the API and Matlock equations in Figure  4. The p-y curves from the DP model are lower than the API curve when the horizontal displacement is less than 0.
35B (Figure  4 ). This indicates that at this horizontal displacement range (y < 0. 35B) a smaller reaction force is mobilized by the DP model than the API model. The curve from the DP model is higher than that from the API when horizontal displacement is larger than 0. 35B. From 0 to 0. 4B, the MATLAB curve presents a similar shape to the Matlock curve, but with lower normalized p (Figure  4 ). The two curves become closer with increasing horizontal displacement. At y = 0. 4B, the normalized p from the DP model in the MATLAB code stays between the API and Matlock values. The normalized p calculated from the MATLAB code is 8. 58, which is 0. 5 higher than the one of API (8. 08) and 0. 4 lower than the one from the Matlock empirical calculation (8. 98), see Figure  4. As the horizontal displacement goes up to 0.