dataesr/scientific-paragraphs-categorization huggingface dataset:
The process of building design is currently undergoing some major changes. In an attempt to mitigate climate change, the design of more sustainable building is advocated by the UK government. Furthermore, standalone design methods are being replaced with the concept of Building Information Modelling (BIM). The adoption of BIM has been documented to result in many benefits, which range from time to cost savings. During the initial planning stages, building performance simulation (BPS) can be used to inform design decisions. Data can be exchanged between BIM and BPS tools using data transfer schemas such as the Industry Foundation Classes (IFC). The IFC schema lacks an energy domain, and as a result, an extension is proposed in this paper. This contains energy concepts from a BPS tool called Passive House Planning Package (PHPP).
There are many rules to verify if a space floor area can be added to the overall TFA, and building element areas are based on external dimensions of the building envelope. For example, the wall area may include the ground floor depth. To the authors' knowledge, there is no published research supporting interaction between IFC and PHPP. This paper proposes a system called PassivBIM, whose purpose is to compile geometric and building fabric data from BIM authoring tools and to couple this with energy related information from PHPP. By combining this information in an independent Java based environment, energy performance calculations may be processed and post processed, opening up the possibility for rapid design optimisation routines. A similar IFC compliant tool which generates partial input data has been proposed by Gupta et al  [29] , but it's aim is to facilitate PV design.
In addition, PassivBIM facilitates the automated transfer of data from a BIM tool to PHPP, thus providing a robust and time saving method of data entry for the purposes of Passivhaus design and certification. The methodology is validated using existing certified Passivhaus buildings in two locations. The first study focuses on buildings from the Hannover Kronsberg project  [30]. The second is a detached house in Wales called Larch House. One of the main challenges in implementing the PassivBIM system was the extraction and processing of geometrical data from an IFC file. The resulting objectoriented building design tool PassivBIM can process input from IFC files, PHPP and user input. The IFC files are generated with a BIM tool called Autodesk Revit Architecture  [31]. IFC input has been identified as an important user requirement in the past, along with the opportunity to model design alternatives  [32].
This ability to store multiple design alternatives in the same IFC file will therefore be addressed by the PassivBIM IFC extension. PassivBIM creates a link between BIM-based tools and PHPP, as well as having the potential to perform independent third party optimization routines, which can inform users of optimised design possibilities. The next section contains a brief overview of the interoperability between BIM and energy tools. This is followed by an overview of the geometrical data needed for the PHPP heating energy demand calculation. The PassivBIM methodology is then described in more detail. The case studies used are then detailed. Finally, the importance of the results is discussed and conclusions are drawn upon the PassivBIM tool.
BIM is a good candidate as a base from which data could be extracted to different domains  [35] , such as daylighting or energy  [36]. BIM is also an opportunity to hold data centrally, thereby avoiding data redundancy and repetition. Designers could improve their building iteratively as changes to a building would influence for example energy demand in real time. However, research into the interoperability of BIM and BPS tools reveals many, as yet unresolved, issues  [26] ,  [37] ,  [38]. These indicate that data is often transferred using the IFC schema and the gbXML schema. The advantage of the gbXML schema is that it is supported by many BIM and energy tools  [38]. However, the IFC schema has been identified as the "only public, non-proprietary and well developed data model for buildings and architecture existing today"  [39].
It has a wider scope than gbXML, which is seen as an important factor  [40]. Previous research has identified six stages of an ideal workflow from BIM to energy tools  [41, p. 36]. These stages are:  (1)  defining the location of the building so it can be linked with weather data; (2) defining the geometry, constructions and materials and space types of a building; (3) assigning spaces as thermal zones; (4) assigning occupant, appliance and lighting loads to spaces;  (5)  defining in detail the HVAC system and its components;  (6)  running an energy simulation. The PassivBIM system focuses on developing the second stage in the transfer from a BIM tool to PHPP. This stage is an active research area  [42] , with early efforts including the creation of data schemas such as COMBINE  [43]. Lawrence Berkeley National Laboratory (LBNL) has developed several IFC transformation utilities, such as the 'Space Boundary Tool', formally known as the 'Geometry Simplification Tool'  [33] , which translates geometry from IFC compatible CAD tools to EnergyPlus input data files (IDF)  [44].
An XML template tool is used to extract non-geometrical data from MsExcel (i. e. the PHPP file) to an XML file, which can be read directly by the PassivBIM Java tool. Once geometrical data is processed and the performance of the building design has been evaluated and optimized the data is inserted back into PHPP directly using the PassivBIM Java tool. Alternatively, it may also be exported as an XML file. The ability to export into an XML file is automatically available due to the process of generating Java classes from XSD schemas. These exported files are illustrated in the data flow diagram as they are considered to have the potential to support collaboration. They can be uploaded onto an online XML database, and accessed by, for example, various project partners. This is a useful feature for multi-disciplinary project collaboration, as the size and content of the XML file can be chosen by the user since they have a choice of which entities (and inherently which sub entities) are exported.
A number of attempts at 'roundtripping' in Revit and in another IFC visualisation tool called IFC "demo viewer" (exporting a file and trying to import it back into Revit) showed the software was not ready to be used as a validation tool of the consistency and accurateness demanded by IFC files. Errors encountered involved: building elements loosing geometrical data, custom made windows loosing transparency and walls not ending at the roof. The methodology to create the PassivBIM Java tool consists of the following steps: 1) Extending the IFC schema with an energy domain. The energy balance equations used in this extension all originate from PHPP, and the structure of the extension is based on the existing IFC structural analysis domain. More details on the extension can be found in section 5.
1. 2) Using the extension used to extract data from PHPP. This is based on a template document set up in MsExcel which takes data from a PHPP document (via Visual Basic macros) and exports it as an XML file which can then be read by PassivBIM. More details can be found in section 5. 2. 3) Generating a tool based on the extended schema in the Java programming language. This tool imports all the data necessary to perform a simplified PHPP heating demand calculation, performs the calculation and then offers the user some optimisation capabilities. More details can be found in section 5. 3, which include details of how it reads IFC and XML files, and inserts data into PHPP.
IFC Energy Extension There are many versions of the IFC schema, and the one extended in this project is the IFC 2x3 TC1. The IFC schema is available in both the EXPRESS and XML language. The XML version, IfcXML, is an XSD schema that is extensible without the need to edit the original schema. As the IFC schema is complex, and not all of it is necessary to describe certain exchanges of information, subsets of the schema can be exchanged using a 'Model View Definition' (MVD)  [49]. One example of a MVD documented by BLIS Consortium  [49]  describes the data exchanged from 'Architectural Design to Building Energy Analysis'. An input file which adheres to this MVD could be used as an input file to PassivBIM. The project cannot claim however to be compliant overall with any existing MVD, as its objective is to extend the current schema and thus it will be inherently incompatible with any existing MVD.
The simplified extension was then reused to generate Java classes using software called Liquid XML Studio 2011. These classes contain algorithms that can read the exported XML documents from the XML Template. Once transferred the data stored in the Java classes is accessible to the main PassivBIM Java tool. A macro was then designed and added to the XML Template document, which allows data to be extracted from an existing PHPP file and loaded into the XML Template document. This data contains important information about the thermal transfer properties of individual construction elements (which is currently not available in the IFC schema). Once extracted this data can be exported into a XML file, which can be read by PassivBIM and used to calculate the buildings heat demand. This process relies inherently upon data such as U -values and thermal bridge lengths having been entered into a PHPP document by a competent user (such as an architect or Passivhaus designer).
Currently these functions are limited and characteristic value limits need to be manually applied when constrained outputs are used to back-calculate input parameter thresholds. The optimization calculation routines need to be extended to enable multivariate optimization and master planning utilities. These could include functions ranging in simplicity from a shading optimisation functions to a combined multi parametric/multivariate and transient time series optimisation against pre-selected data. An IFC exportation ability could also be developed, which would send files to an online database. This would support collaboration between different project stakeholders. The development of a user-friendly interface needs to be addressed. Finally, the energy analysis extension could be used to develop an 'Architectural Design to Passivhaus' MVD in order to limit the introduction of errors caused by inconsistent IFC file generation.
C) Decision making After calculating the global trust value , that relies on [-1, 1], each node i will classify trust into three states as follows: ( , ) = : , 1 ≥ , ≥ 1 : , 1 ≥ , ≥ 2 (7) : , 2 ≥ , ≥ -1 where 2 < 1 < 1 and 1 , 2 are a threshold that can be tuned according to the system and security requirements to determine the node's status. Since these values depend on network and security requirements, it will be set accordingly. According to the trust state, each node can make a decision to cooperate or noncooperate with the interacted node in the considered operation. 4  Performance evaluation In this section, we present results of our simulations showing the effectiveness of our trust model. MATLAB software is used as simulation tool to assess the performance of our model. A comparative study between O 2 Trust, RFSN  [9]  and Retrust  [12]  is given.
Besides all works on Collaborative Information Systems ensuring interoperability between several exogenous IS, let us note one initiative. Federated Information System  [15]  is the evolution of federated database system which is a multi-database system in which every node in the federation maintains its autonomy on the data. A set of export schemas (derived from local schemas) through which the data is made available to other specific nodes are the underlying working principle. The way information is exchanged is interesting but the SIS approach is more global and not limited to a given context. Instead of exporting internal IS database models, SIS rely on messaging between SIS according to a given protocol ideally without considering IS internals. Moreover, the unicity of a person, an organization is again not considered.
The information that connects genotypes and phenotypes is essentially embedded in research articles written in natural language. To facilitate access to this knowledge, we constructed a framework for the curation of the scientific literature studying the molecular mechanisms that control leaf growth and development in Arabidopsis thaliana (Arabidopsis). Standard structured statements, called relations, were designed to capture diverse data types, including phenotypes and gene expression linked to genotype description, growth conditions, genetic and molecular interactions, and details about molecular entities. Relations were then annotated from the literature, defining the relevant terms according to standard biomedical ontologies. This curation process was supported by a dedicated graphical user interface, called Leaf Knowtator.
A total of 283 primary research articles were curated by a community of annotators, yielding 9947 relations monitored for consistency and over 12,500 references to Arabidopsis genes. This information was converted into a relational database (KnownLeaf) and merged with other public Arabidopsis resources relative to transcriptional networks, protein-protein interaction, gene co-expression, and additional molecular annotations. Within KnownLeaf, leaf phenotype data can be searched together with molecular data originating either from this curation initiative or from external public resources. Finally, we built a network (LeafNet) with a portion of the KnownLeaf database content to graphically represent the leaf phenotype relations in a molecular context, offering an intuitive starting point for knowledge mining.
Introduction An increasing number of research papers are published every year containing vast amounts of scientific data. It is therefore difficult to rigorously monitor even a subset of these publications for a topic of particular interest. With the publication process becoming essentially digital, the scientific community now develops tools to capture aspects of published information into databases that can be queried by researchers to reveal previously veiled gene or protein functions  [1]. Much effort has been devoted to the development of automatic text mining, a field supported by a growing community, with some initiatives focused on the processing of plant-related textual data  [2] [3] [4] [5] [6] [7]. However, most advanced text mining methods are not generic enough to be applied to a novel domain without additional work or to provide the level of detail required for specific studies.
A complimentary approach to text mining is the creation of high-quality datasets through the manual curation of primary research articles. In this context, specific nuggets of information are extracted with a rich and controlled vocabulary, compatible with algorithmic processing to identify valued relationships  [8, 9]. One of the most challenging tasks is to transform free text descriptions of complex phenotypes into structured statements linked to corresponding genotypes. Phenotype/genotype datasets are extremely valuable because they summarize current knowledge, they may reveal unknown biological mechanisms, and they facilitate the comparative analysis of functional studies across species  [1, 10, 11]. As part of the AGRON-OMICS project, we created a standard framework to collect various types of information about Arabidopsis leaf growth (Fig.
1 ). Special attention was paid to gather phenotype data with the corresponding genotypes and additional parameters that characterize them as described in primary research papers. The components of our integrated system include (1) lists of selected ontology terms,  (2)  relationships between different types of entities expressed in a constrained structure, (3) a customized curation interface, (4) a semi-automated quality control pipeline, (5) a relational database capturing the collected data, and  (6)  an integrated network summarizing data curated within this project together with pre-existing knowledge. Information from 283 articles was compiled by multiple curators and the quality of the dataset was assessed for consistency. The workflow was designed in such a way as to fully support future text mining methods to be built on top of this data collection.
Annotation software and files The Leaf Knowtator annotation interface was built with the software Protégé version 3. 3. 1 (http://protege. cim3. net/download/ old-releases/3. 3. 1/full/) and the Knowtator plug-in version 1. 9 beta (http://sourceforge. net/projects/knowtator/files/Knowtator/ knowtator-1. 9-beta2/). The program is available for various operating systems including Windows, Mac OS X, AIX, Solaris, Linux, HP-UX, any Unix platform and other Java-enabled platforms. Protégé Fig. 1. Annotation workflow. Primary research papers were selected based on phenotypes, genes or interactions of interest. The full text html and pdf files were converted into a text format and imported into the Leaf Knowtator platform for manual annotation (. pont and. pins files contain domain classes and instances, respectively; the Protégé pprj project file identifies these files) The resulting data were exported from the Protégé software into individual XML files for each paper.
These files were processed with dedicated in-house scripts for two distinct purposes. First, a quality control algorithm automatically detected predefined errors made during curation. Based on the output analytical text logs, the annotators corrected common inconsistencies within the Leaf Knowtator environment. The quality assessment and correction steps could be repeated until properly amended data files were obtained. Second, the corrected XMLs were parsed and flattened into the MySQL table embodying the KnownLeaf database. requires Java 1. 5 or a later version installed (http://www. java. com/ en/download/index. jsp). Relations and corresponding slots were manually implemented with the Protégé/Knowtator tools. Ontology libraries were imported from publicly available onlice resources (Table  S2 ).
Databases The MySQL database server (v5. x series) was used throughout together with the MySQL WorkBench graphical client tool. The annotations created by each curator were exported from Leaf Knowtator to produce one XML file per article, with a self-contained representation of the annotations consistent with the Protégé-Knowtator data-model, together with meta-data. Annotated phrases link to annotated classes, themselves compositions of slots associated with values (the ontology terms) through internally generated string identifiers. This complex network of classes and pointers was transformed with Perl ("knowta-tor2table. pl") into (1) tables in which each row represents a straight link between an annotated class, the corresponding text phrase and the assigned ontology terms or collection of terms, and (2) records to view each annotation as a collection of key value pairs.
These tables and records were queried and viewed to identify missing or inconsistent annotations and to track progress. The annotation tables were parsed into a MySQL relational database form with a Perl script ("PhenotypesEtc. pl"). The table knowtator represents the input tabular format with an autoincrement numeric row identifier ("id"). The table knowtator agi holds references to AGI codes and has the id as a foreign key. The table knowtator papers holds bibliographic information resolved by PubMed identifier with NCBI's efetch tool (http://eutils. ncbi. nlm. nih. gov/entrez/eutils/efetch. fcgi), together with the id as a foreign key, and the curator names per paper. In addition to data mining, this MySQL database served to generate summaries about content and to track the curation progress and the incremental growth of the data at a fine-grained level.
Additional publicly available sources of knowledge, such as gene and protein information (TAIR), protein-protein interactions, the Arabidopsis regulatory network (AGRIS AtRegNet) and the gene co-expression network (ATTED-II), were downloaded and parsed with Perl into a database format for uploading. These data and resources can be conveniently joined, filtered and summarized with structured query language (SQL). The database stored routines user get knowtator edges for cytoscape and user get knowtator nodes for cytoscape encode the filtering and joining functionality to develop the Cytoscape network files. Cytoscape version 2. 8. 3 was used throughout. The database and Perl scripts can be downloaded at www. agronomics. ethz. ch together with instructions on how to install the tables and data on an instance of the MySQL database server.
Data collection Our first objective was to design and implement a framework to collect information about genes reported to be involved in leaf development (Fig. 1 ). We focused on phenotypes resulting from genetic alterations, but additional relevant relations were also captured, such as genetic interactions and protein-protein interactions (Table  1 ). Our annotation effort was focused on a specific subdomain of the available knowledge by imposing the following restrictions. (1) Data were acquired solely on the model organism Arabidopsis thaliana, because it offers the richest body of literature describing the molecular and genetic control of plant development. This initial choice does not preclude the later inclusion of articles describing gene functions and leaf phenotypes in other plant species, in particular major crops.
(2) Statements were recorded if they referred to leaves, cotyledons, meristems, or the apical part of an embryo. (3) Text curation was limited to the Results sections of primary research articles, excluding the Introduction, Discussion and Supplemental data sections, to include actual data but avoid repetitions. For the same reasons, review articles were not taken into consideration. The annotation of research articles was completed in two successive phases. The KnownLeaf system was initially developed on the basis of 174 publications curated by the reference annotator, a Full references in Table  S1. to define the main principles of the process and to establish the annotation structure (Table  S1 ). This initial set of articles was selected because they reported notable progress in the field of leaf growth and development, and described the function of key genes in relation with relevant mutant phenotypes.
Structure of the relations Relations are defined in terms of specific parcels of data ("slots"), each containing a different type of information. A slot has a selfexplanatory name such as 'Plant part' or 'Growth condition', can be linked to the corresponding words in the article text, and contains a single value to enable a seamless import of recorded relations into relational databases. In most cases, the data in a slot is a structured ontology term (see next section). However, some slots allow for free-text entries when a relevant ontology is not available or not detailed or extensive enough, such as the description of the experimental methodology. The structure of the ten relation categories is provided in Table  S3. For clarity, slot names are hereafter italicized and underlined. The principle of the annotation method is illustrated with a particular Phenotype relation in Table  2.