dataesr/scientific-paragraphs-categorization huggingface dataset:
Contributions. We make the following contributions: (1) an analysis of the requirements for property graph schemas; (2) a proposal for a flexible, agile, usable, and expressive formalism called PG-Schema that fulfills these requirements; (3) full syntax and semantics of PG-Schema, making the proposal easy to incorporate into both standards and systems; (4) a parser for PG-Schema  [9] ; (5) a detailed analysis of schemas in other structured and semi-structured data models and practical graph database systems, as well as their comparison with PG-Schema. Our contributions impact the following audiences: (a) graph database standards committee members, who can build upon our recommendations for upcoming features, (b) graph database vendors, who can use our framework as a guideline to incorporate schemas in their systems, and (c) researchers, who can use a concrete model of schemas for property graphs as a basis for further investigation.
Property Graphs and Database Schemas Beyond the ubiquity of applications that focus on graph-structured data and graph analytics, the popularity of graph databases is also generally attributed to the following factors  [34, 35, 43, 46]. Agility. Thanks to its proximity to conceptual data models, the property graph data model allows for an efficient translation from domain concepts to database items. This facilitates high responsiveness i. e. , the ability to quickly and reliably adapt to emerging organizational and domain needs, which is often achieved with iterative and incremental software development processes. Flexibility. Graph databases are aligned with an iterative and incremental development methodology because they do not require a rigid schema-based data governance mechanism, but rather favor test-driven development, which embraces the additive nature of graphs.
The data does not need to be modeled in exhaustive detail in advance but rather new kinds of objects and relationships can emerge naturally as new domain needs are addressed by evolving applications. Database schemas have a number of important functions that can be split into two general categories  [12]. Descriptive function. Schemas provide a key to understanding the semantics of the data stored in a database. More precisely, a schema allows to construct a (mental) map between real-world information and structured data used to represent it. This knowledge is essential for any user and application that wishes to access and potentially modify the information stored in a database. Prescriptive function. A schema is a contract between the database and its users that provides guarantees for reading from the database and limits the possible data manipulations that write to the database.
To ensure that the contract is respected, a mandatory schema can be enforced by the database management system. Our primary objective is to develop a schema formalism for property graph databases that can effectively serve both descriptive and prescriptive roles, while also facilitating and possibly enhancing the strengths of property graph databases. Additionally, we aim at a formalism which enforces correct data modeling practices through its syntax. First, however, we discuss the meaning of two fundamental terms that are essential for defining schemas but are often confused.
Types and Constraints The notions of type and constraint are two main building blocks in virtually any database schema formalism. When used sensibly, they enable the division of schematic information into self-contained fragments that correspond to real-world classes of objects (types) and pieces of knowledge about them (constraints). In general, there is no clear distinction between types and constraints, e. g. , data value types are often considered as implicit (domain) constraints. We employ the following nomenclature throughout the paper. Type is a property that is assigned to elements (data values, nodes, edges) of a property graph database. Types group together similar elements that represent the same kind of real-world object and/or that share common properties, e. g. , the set of applicable operations and the types of their results.
Constraint is a closed formula over a vocabulary that permits quantification over elements of the same type. The purpose of constraints is to impose limitations and to express semantic information about real-world objects. Both types and constraints impose limitations (and provide guarantees) but types are of local nature while constraints are more global. More precisely, checking that an element has a given type should require only inspecting the element itself and possibly the immediately incident elements. On the other hand, validating constraints may require inspecting numerous database elements that need not even be directly connected. Consequently, types are typically verified statically whereas constraints are dynamically verified.
Requirements Property Graph Types. The descriptive function of schemas can be particularly beneficial to the agility of property graph databases. Indeed, agility requires a good grasp of the correspondence between database objects and real-world entities, which is precisely the descriptive function of schemas. To communicate this correspondence efficiently, schemas should allow and even encourage a use of types that is consistent with how information about real-world objects is normally/typically divided into nodes, edges, and properties of a property graph database. Nodes are used to represent individual objects with all their attributes stored as node properties. R1 Node types. Schemas must allow defining types for nodes that specify their labels and properties. Edges are used to represent relationships between objects of given kinds, and therefore should additionally specify node types of their endpoints.
R2 Edge types. Schemas must allow defining types for edges that specify their labels and properties as well as the types of incident nodes. Naturally, schemas must also allow a great degree of expressiveness when describing the content of nodes and edges, i. e. , sets of properties and their values. R3 Content types. Schemas must support a practical repertoire of data types in content types. Property Graph Constraints. To further ensure that schemas can properly fulfill the descriptive role and strengthen the agility of property graph databases, we additionally consider the data modeling power that a suitable schema formalism should have. We deliberately target minimal data modeling capabilities and as a reference point we take the most basic variant of Entity-Relationship (ER) diagrams (see Section 5), as the ultimate lower bound in the expressiveness of conceptual modelling languages.
PG-SCHEMA Most existing data definition languages for relational and semistructured data consist of two parts: types, which define the basic topological structure of the data, and constraints, which define data integrity. Likewise, PG-Schema consists of two parts. The first part, PG-Types, describes the shape of data and the types of its components such as nodes and edges, reflecting and extending work on SQL/PGQ schemas  [2, 26] , Graph DDL in the openCypher Morpheus project for Apache Spark  [36] , and GQL graph types  [1, 51]. 3  It specifies • node types, describing the allowed combinations of labels and contents; • edge types, describing the allowed combinations of labels, contents, and endpoint types; and • graph types, describing the types of nodes and edges present in the graph. The second part describes constraints imposed on the typed data.
Here, we propose a slight extension of the existing proposal called PG-Keys  [5] , which specifies integrity constraints such as keys and participation constraints, much like openCypher constraints  [44]. This section starts with a guided tour of PG-Types; the full syntax can be found in Figure  3  and a parser is available on Zenodo  [9]  (with a third-party web alternative  [56] ). We then define their semantics formally, provide a validation algorithm, and explain how PG-Types interact with PG-Keys.
One can control whether types are open or closed by setting additionalProperties to True or False. Fields are optional by default, but can be marked as mandatory through the required construct. Range constraints (RC) are limited to numerical values and strings. Field values support (CPT), as they can encode nested objects and arrays. Key constraints (KC) are not supported and cardinality constraints (CC) specify bounds for arrays. Finally, as the schema is itself a JSON object, it allows introspection (IS). Existing graph technologies. We now discuss the extent to which type, constraints, and schema features are supported in several state-of-the-art graph schema languages and systems. Type features, such as union and intersection types (UIT), type hierarchies (TH), and abstract types (AT), are supported by GraphQL, and JSON Schema.
These capabilities are also found in SQL-based systems, such as OrientDB/SQL, and in systems able to leverage JSON Schema, such as ArangoDB and AgensGraph. The strongly-typed TypeDB database has a rich type system that also offers subtyping for entities, relations, and attributes/properties. While other considered systems cannot directly handle TH, some can emulate it through multi-labels by adding all the intended parent types of a node as its additional labels. Nevertheless, this is problematic for validation, as one cannot ensure that all subtypes have been assigned the correct label. Note that most examined technologies only implement closed types (OCT), except ArangoDB and OrientDB, in which also open types are possible, and Neo4j, which considers types open and, hence, extensible, by default.
Nodes and edges can be enriched with element properties (EP) in all surveyed graph technologies, and in AgensGraph these can be defined using JSON objects. Such properties are optional by default in AgensGraph, ArangoDB, DataStax, JanusGraph, Neo4j, and Sparksee, though users can define mandatory constraints to enforce them being non-nullable. In Nebula Graph, users can specify, when designing their schema, whether null-valued attributes are allowed, while in TypeDB these are not supported. Finally, the (MOP) feature is present in SQL-based technologies. Most reviewed graph languages and system also allow for (CPT), although specific restrictions sometimes apply. For example, in Neo4j, complex property values can only be homogeneous lists of simple types and byte arrays, despite the latter not being first-class Cypher data types.
AgensGraph draws its support for (CPT) from openCypher and JSON, while in Sparksee, multi-valued properties can only be defined using array attributes, using all but the String and Text data types. In addition, range constraints (RC) can be specified for any data type, in SQL-based technologies, and for numerical values and strings, in systems that build on JSON Schema or that provide regular expressions, such as TypeDB. Regarding constraint features, we remark that key constraints are available in all reviewed graph schema languages except GQL. At a system level, AgensGraph, Neo4j, and Sparksee support node uniqueness constraints, disallowing the same property values from appearing in more than one node of a given label or type, while ArangoDB enables specifying uniqueItems for arrays, thanks to JSON Schema.
In JanusGraph and Sparksee, the schema is defined through their specific APIs and there is no formal account of their schema validation mechanisms. Concerning introspection (IS), all reviewed systems support it either directly, through the query language itself, or indirectly, via a management API (like in JanusGraph and Sparksee). Finally, the only reviewed system that natively supports (SPFX) is OrientDB/SQL, which has schema-first, schema-less, and explicit schema-hybrid modes. Partial conformance is possible in all systems that are not exclusively schema-first or that do not have native schema mechanisms, like ArangoDB, which relies on JSON Schema. PG-Schema. Like SQL/PGQ and GQL, PG-Schema views a set of node and edge types as the core of a graph database schema. The support for type features is essentially complete, as discussed in Section 4, except that (CPT) and (RC), as well as (UIT) and (TH) for properties, are delegated to the property type system.
While concrete property types have been used in examples, PG-Schema deliberately leaves the choice of the property type system open, which allows it to function as an embedded language in both GQL and SQL/PGQ, offering suitable property type features. In Section 5. 3 we discuss how some of these features could be supported directly in PG-Schema. In terms of constraint features, PG-Schema is also quite comprehensive. As discussed in Section 4. 4, it supports not only (KC) and (MP), but also denial constraints and uniqueness constraints. In Section 5. 3 we discuss an extension to support general cardinality constraints (CC) that fits well with the support for (KC) and (MP). Important design principles for PG-Schema were to preserve the spirit of schemas in SQL/PGQ and graph types in GQL, keeping node and edge types locally verifiable, while at the same time offering a powerful mechanism to express constraints.
The language thus supports a wide-range of capabilities, largely absent from the state-of-the-art schema languages and systems we have reviewed. Finally, PG-Schema is easily extensible with further features, such as range constraints, complex data types, content type combinators, and advanced cardinalities. Looking Ahead. In addition to the impact on standardization efforts, this is an opportunity for graph database vendors to increase functionality and support current and future customer demands. Our work also provides a basis for future research by the academic community. Finally, this successful high-impact academia-industry collaboration model is one we hope will be replicated by other communities at large, in data management and beyond.
ACKNOWLEDGMENTS We thank all  LDBC PGSWG  members for the discussions around property graph schemas. Renzo Angles was supported by  ANID Millennium Science Initiative Program , Code  ICN17_002  and  ANID FONDECYT Chile  through grant  1221727. Angela Bonifati  and  Leonid Libkin  were supported by  ANR-21-CE48-0015 VeriGraph. Leonid Libkin  was supported by a  Leverhulme Trust   Research fellowship  and  EPSRC  grant  S003800. Wim Martens  was supported by  ANR  project  EQUUS   ANR-19-CE48-0019 ; funded by the  Deutsche Forschungsgemeinschaft (DFG, German Research Foundation)  -project number  431183758. Filip Murlak  was supported by  NCN  grant  2018/30/E/ST6/00042. Domagoj Vrgoč was supported by  ANID Millennium Science Initiative Program , Code  ICN17_002  and  ANID Fondecyt Regular  project  1221799.
This work is devoted to Wire Arc Additive Manufacturing processing. The question of automatic generation of robot trajectories is mainly addressed. An in-house slicer was rst developed. Once the part to be manufactured has been designed and converted into STL format, the slicer allows automatic generation of successive vertices de ning the part contours and corresponding robot trajectories. Automatic generation of the robot program is then performed including displacement instructions written in KRL language (case of KUKA robots), as well as commands related to the CMT welding device. The different steps in the o ine programming pre-treatment process are rst described. In a second step, two distinct parts with increasing degrees of complexity were printed using the corresponding o ine programming tool.
As preliminary part of the work, an in-house o ine programming (OLP) software was developed in order to generate automatically the command les of the robot/welder system from the CAD le of the part to build. Up to now, the case of shell type parts was considered, since it presents several applications especially in the objective of parts weight reduction. The objective of the present work is thus to show the different steps of the OLP software (i. e. , STL le, slicer, trajectories, and robot/welding device command les). The present solution is certainly very similar in comparison with that developed by Schmitz two years ago  [5, 7]. The rst step concerns the choice of a CAD package to import or draw the part to be printed by WAAM. In our work, it was decided to work with free software products only, so that FreeCAD was selected.
FreeCAD [ 14 ] is a free and open source CAD software. It allows using solid modeling, functional modeling, as well as surface modeling. In addition, it allows exporting the designed parts in STL ASCII format, which is quite easy to read with any programming language, such as C. Figure  1  shows the typical structure of an ASCII STL le. All triangular faces are de ned individually from the Cartesian coordinates of three vertices. It is thus easy to read such le and to de ne the three edges connecting the vertices. In principle, only one other face is connected to each edge (i. e. , only two faces share a common edge). It is also easy to calculate the coordinates of the two vertices de ning the intersection with a horizontal plane (if it exists). Finally, intersection of a horizontal plane with a solid de ned in a STL le, consists in connected edges forming at least one closed polygon (possibly several ones).
e. , 15x2 +2x3). Slicing of this part with horizontal planes results in a series of polygons composed 10 edges (1 intermediate vertex along each straight edge of the pentagon). Direct in-situ coding of the robot program required to print this part would be quite complex. On the contrary, the OLP tool allows generating the corresponding list of instructions in less than one second, once the SLT le is produced. With the OLP tool there are only few parameters to adjust, such as the name of the STL le to consider and the number of slices (or height between successive slices). In addition, the generated list of instructions is always free of bugs once the program has been tested and validated. Once back on the real robot cell, only the POSREF position must to be de ned by learning. It corresponds to the position at which the part will be printed.
e. , square to circular transition, followed by a circular to square transition). The dimensions of the bottom and top square sections are 80x80 mm, whereas the diameter of the circular part at mid height is 60 mm. The total height of the part is 150 mm. This part is thus much more complex, including nonplanar curved surfaces. The corresponding STL le is composed of 1940 triangular faces, but the OLP program remains e cient as well. Figure  10  shows the resulting robot trajectories including connecting edges between successive slices, used to alternate the position of the starting point for each weld bead. The resulting number of vertices, edges and displacement instructions in the robot le is as high as 7155 for this example. Figure  11  shows the printed part after brushing. It has no major aws and is ready for machining of functional surfaces.
Conclusions The aim of the present study was to illustrate the capacities of our in-house OLP (O ine Programming) tool, allowing providing directly the list of instructions of the robot program required to manufacture a part by WAAM, from the CAD le of the corresponding part in STL format. The functionalities of this tool are certainly very similar to those of the tool developed by Schmitz 2 years ago. Nevertheless, additional information, advices and examples were provided. This tool produces very clean les and applies always the same method, which reinforces the robustness and interest of the method. The case of a deposition process managed by a KUKA robot was considered, so that the OLP tool provides the suitable list of instructions in KRL format. Of course, all robot manufacturers have their own input language.
(2022)  on "Application of CFD plug-ins integrated into urban and building design platforms for performance simulations: A literature review". Our objectives are to secure a CFD simulation tool that can: • Be coupled with other simulations relating to the urban microclimate • Deliver reliable and accurate results • Handle diverset scales within urban and architectural design • Be easily customizable to suit specific project requirements The Rhino modeling software, with its plug-in platform Grasshopper, provides a wide range of CFD plug-ins that have been developed in Open Source. This ensures their continual development and expansion over time  (McNeel, 2010). As a result, we have chosen to work with one of the tools available within Grasshopper. The main options include Butterfly from Ladybug Tools, Swift, Eddy3D, proceduralCS, ixCube CFD, GH_Wind, WS-Snake and FlowDesigner.
, 2017)  is the most widely used plugin on Grasshopper, accounting for approximately40% simulations on this platform. In recent years, numerous studies have validated the simulation capabilities of Ladybug tools  (Sun et al. , 2020; De Luca et al. , 2019; Ibrahim et al. , 2021)  across various scales and with various microclimatic parameters. This validates our choice to opt for Grasshopper in 2023. Among the CFD plugins available on Grasshopper, Butterfly has been extensively used for wind pattern analysis in medium-density urban environments. Many studies published recently employ multi-criteria simulations using Butterfly and other components of Ladybug Tool. (Chronis et al. , 2017; Elwy et al. , 2018; Ibrahim et al. , 2021; Loh and Bhiwapurkar, 2022 ). It's important to note that Ladybug Tools supports flexible coupling between Butterfly and other validated simulation modules, such as EnergyPlus/OpenStudio  (Roudsari et al.
Notably, in Figure  5 , there is evidence of wind recirculation behind the measurement points, primarily moving in a northward direction. Therefore, it is strongly recommended to ensure the accurate representation of the immediate context by generously expanding the radius of the simulation domain. Achieving this may necessitate multiple simulations. Visualization of the results in software such as Rhino enables a quick assessment of the contextual influence before delving into a thorough analysis of the result values. In our specific case, the buildings have a height of 5. 8 meters and are situated within a radius of approximately 60 meters around the street of interest in Morphology 4. Compared to the study conducted by Naboni in 2019, which employed a radius of 150 meters for 40-meter-high buildings, our approach covers a larger influence area.
, 2014) , it would be interesting to incorporate these effects in a case study where wind speeds measured in the urban context are very low. These three elements represent significant avenues for improving result precision. Regarding simulation time, it is essential to focus on refinement. Further analysis on the required areas of refinement should be conducted. Several software uses automatic meshing processes which could be introduced in Butterfly  (Ma et al. , 2019; Mirzaei et al. , 2021).
This validation step is able to reject records that are considered invalid or merged. The full workflow has been used to process over two million pages of Quebec parish registers from the 19-20th centuries. On a sample comprising 65% of registers, 3. 2 million acts were recognized. Verification of the birth and death acts from this sample shows that 74% of them are considered complete and valid. These records will be integrated into the BALSAC database and linked together to recreate family and genealogical relations at large scale.
tion of Quebec civil registers and their integration in the database. These developments are part of an initiative supported by the Canadian Foundation for Innovation aimed at creating i-BALSAC, an infrastructure for the study of the Quebec population through a joint genealogical, genomic and geographic approach. This project, which will be completed in 2023, has three main components: the integration of demographic, genetic and geographical data, the development of statistical and mapping tools to enhance exploitation of the data, and the setting up of a web portal for access.