dataesr/scientific-paragraphs-categorization huggingface dataset:
C Organization responsible for the database To get access to the information in the database, it is fundamental to know the organization responsible for the data. This is mainly connected to the organization of the database (see previous point). • National authority: one or more national public authorities collect data and maintain the database. • Regional authority: one or more regional public authorities collect data and maintain the database. • Private company: one or more private companies collect data and maintain the database. • Semi-public company: one or more semi-public companies collect data and maintain the database.
G Connection with other databases and other uses The database is connected to the information source, e. g. , spatial data infrastructure: Yes/No Following a brief presentation to set the scene on the database's overview, information is presented in more detail in the following dedicated subsections: (Section 3. 1) Eurostat, (Section 3. 2) building stock observatory (BSO), (Section 3. 3) energy performance certificate (EPC) registers, (Section 3. 4) building energy performance data platforms outcomes of European projects. Eurostat  [5]  is an official directorate-general of the European Commission (EC) with the main responsibility to provide statistical information to the institutions of the European Union (EU) and to promote the harmonization of statistical methods across its MS through the European Statistics System (ESS).
Eurostat statistics are open data available on its website; they are hierarchically ordered in a navigation tree with tables distinguished from multi-dimensional datasets from which the statistics are extracted via an interactive tool. Building stock observatory (BSO) it the official and centralized database on the building's stock for the European area. The Observatory was developed for the European Commission by the Buildings Performance Institute Europe (BPIE) in collaboration with ECN, Ecofys, Enerdata, and SEVEn, as well as national project partners  [6]. BSO contains a database, a data mapper, and factsheets. BPIE began collecting facts and figures on the European building stock in 2010 in the context of preparing its major study of Europe's buildings  [7]. In 2012, the information gathered was made available in the data hub portal (by BPIE) including technical data on building performance.
The platform, no longer available, offered country statistics on building's monitoring of the EU directive implementation  [8]. The data hubs were used as a basis to design the BSO; currently, the BSO is managed by the RICS organization (Royal Institution of Chartered Surveyors). The energy performance certificate (EPC) was established in 2002 with the EPBD  [9]  and its implementation process has been remarked in 2010  [10]  to stimulate the creation of an independent register, often at local level. Databases collecting data from EPCs are the main source regarding the energy performance of the EU building stock. Unfortunately, some European countries do not have central databases, and where they do, they are not usually public access  [11]. Finally, in Section 3. 4, a selection of platforms related to buildings' energy performance data realized within European researches (mainly belonging to the 7th Framework Programme funded European Research and Technological Development FP7 and Horizon 2020 Framework Programme for Research and Innovation), are presented and analyzed considered as a valuable sources for both the overview of the available knowledge.
D Data collection Eurostat data contains several indicators on the EU-28 and the Eurozone, the member states and their partners. The database of Eurostat contains always the latest version of the datasets meaning that there is no versioning on the data. Datasets are updated twice a day, at 11:00 and at 23:00, in case new data are available or because of structural change. It is possible to access the datasets through SDMX Web Services as well as Json and Unicode Web Services.
E Data quality Eurostat performs data validation by verifying whether data are in accordance with certain basic criteria that serve to assess the plausibility of the given data. In the target business process, validation rules are jointly designed and agreed upon at the level of each statistical domain's working group. The resulting validation rules are documented using common cross-domain standards, with clear validation responsibilities assigned to the different groups participating in the production process of European statistics. The European Statistical System (ESS) oversees the data validation workflow.
The Building Stock Observatory (BSO) Database The EU BSO is an EC initiative to monitor the energy performance of buildings across Europe. The purpose of the EU BSO is to (i) provide a snapshot of the energy performance of the EU building stock, by providing high-quality data from all MSs in a consistent and comparable manner and (ii) set a framework/methodology for the continuous monitoring of the building stock. The BSO primary driver is to provide a clear understanding of the effectiveness of EU policy measures and mechanisms to enhance energy efficiency in Europe  [12]. BSO analysis results are presented in Table  3. Table  3. BSO analysis by criteria defined in Table  1.
B Organization of the database The BSO includes more than 250 indicators grouped in the following thematic areas: Topic 1. 1, building stock-NZEB and new construction; Topic 1. 2, energy needs; Topic 1. 3, fuel supply mix; Topic 2, technical system; Topic 3, certification; Topic 4, financing; Topic 5, fuel poverty and social aspects; Topic 6, building code. A future topic is comfort. The BSO is designed to contain a wide variety of information in different formats (e. g. , averages or totals), units (e. g. , counts, shares or data-specific units) and aggregation levels (e. g. , per building type, per energy source or per year) covering six main topic areas. Due to such details and the variety of the information, each data field has some properties to consider for data gap management unique to each indicator.
D Data collection The data collection for the BSO has been conducted mainly using data from Eurostat and from EU funded projects. Other data were collected by the consortium partners in collaboration with 20 national partners with the scope to gather specific data from each member state. In the original iteration of the EU BSO, numerous EU Projects were employed to populate approximately 4% of the entire database. However, those projects are finished and no longer collecting data, which consequently means that, the indicators-within the EU BSO that were originally populated through these projects-will not be updated with the latest data.
E Data quality The most used sources were the EU projects (around 40%) and official international or national statistics (around 39%), followed by expert assumptions and calculation provided by the national project partners and the consortium supported around 25% of the collected data. The EU BSO faces a serious amount of persistent data gaps. Some energy efficiency indicators present in the EU BSO have no data whatsoever. Currently, the EU BSO has 13% of its indicators populated with data. Of this 13%, 8. 4% of the populated data are sourced regularly from high quality and reliable sources, i. e. , Eurostat, Odyssee-Mure, and various National Statistical databases.
B Organization of the database An excel file was developed which consists of two tables with constant and variable input data. In parallel, a webtool was developed which enables an online calculation according to the TABULA method (TABULA WebTool). Each partner has its own division of building typology according to the needs of the national experts in the different application fields. The TABULA Data Structure is divided into: parameters for classification (country, region, construction year class, Building Size Class), reference area, calculation method building, boundary conditions, thermal envelope, U-values, consideration of thermal bridging, calculation method supply system, and delivered energy/fuel.
ExcEED The ExcEED H2020 project (presented in a nutshell in Table  9 ) responds to the need for transparency and comparability of building energy performance calculations. The ExcEED platform gathers, categorizes, visualizes, and benchmarks multiple building data coming from building monitoring systems, projects, other EU and not-EU databases, as well as from indoor environmental quality (IEQ) surveys. The ExcEED platform collects measured quantitative (i. e. , primary energy consumption, total heated floor area, etc. ) and qualitative building data (i. e. , occupant comfort), then uses key performance indicators to benchmark the energy efficiency of the building. ExcEED analysis results are presented in Table  10.
B Organization of the database ExcEED database is organized in 27 Key Performance Indicators (KPIs). The KPIs are organized in six categories: renewable energy, environment, technology, indoor environmental quality, electric energy, thermal energy. There are two main databases, the first one in which all the data coming from buildings are collected and used for the visualization of KPIs and the second one is mainly used to collect post-processing data used to cluster and benchmark the building.
Data Model Structure: Inputs, Outputs and Data Flow of the ALDREN BRP After the identification of the dataset available on existing building stock for non-residential typology (more info available also in Annex a) and an EPC and other voluntary certification scheme available on the market and products and building components, the research work focuses on the definition of a data model to capitalize all those building information. The data-information-knowledge-wisdom hierarchy (DIKW), referred to variously as the "Information Hierarchy" or the "Knowledge Pyramid" is one of the fundamental, widely recognized and taken-for-granted models in the information and knowledge literatures. The hierarchy is used to contextualize data, information, knowledge, and sometimes wisdom, with respect to one another and to identify and describe the processes involved in the transformation of an entity at a lower level in the hierarchy (e.
It is a model to look at various ways of extracting insights and value from all sorts of data: big data, small data, smart data, etc. In the literature, one the most known DIKW hierarchy definition is Ackoff's  [25] , which clearly explains that each of the higher types in the hierarchy includes the categories that fall below it. The DIKW model is quite linear and expresses a logical consequence of steps and stages with information being a contextualized 'progression' of data as it gains meaning. In Figure  1 , the traditional DIKW model has been interpreted and adapted to describe the ALDREN approach. The D-step foresees the data collection within existing databases (i. e. , European Building Stock, product databases, European projects outcomes databases, etc. ) with the purpose of identifying the main data layers (such as technologies, standards, policies, buildings components, market trends, The D-step foresees the data collection within existing databases (i.
e. , European Building Stock, product databases, European projects outcomes databases, etc. ) with the purpose of identifying the main data layers (such as technologies, standards, policies, buildings components, market trends, etc. ) necessary for the definition of the ALDREN BRP data model. The action to reach the following I-step is data clustering: information is defined as data that is given a context or data that have been organized into a structure  [26]. The fundamental principle is the refining process applied to the data, which then they evolve into information and they possess a meaningful purpose or value. Within the ALDREN approach, the clustering action has been conducted referring to the six tasks of the WP2 for the consolidation and adaptation of a European Voluntary Certification Scheme (EVCS) based on a common language.
The K-step is reached adopting rules and actors into all information clustered in the previous steps. For the ALDREN approach, this corresponds to a selection of overall indicators per topic from the raw data of each respective database. The ALDREN methodology, within this step, comprehends also an additional added value, all the overall indicators per topic are collected and linked into a unique storage: the digital version of the ALDREN BRP. The fourth step is arguably the most elusive of all these four elements and concepts. Wisdom is the highest level of abstraction, with vision foresight and the ability to see beyond the horizon. The Awad and Ghaziri's definition of wisdom  [27]  is well suited to the W-step of the ALDREN approach, providing a vision foresight with the ability to communicate with core indicators-derived from the raw data of the first step-the path to follow per a specific non-residential building, the so called ALDREN renovation roadmap, and describing clearly "when, where and how renovate" buildings to reach the NZEB target (Figure  2 ).
The ALDREN BuildLog is characterized by a different level of information (LoI) to facilitate the data flow along the process and the data comprehension according to the user's expertise or needs. This concept has been represented in Figure  3  through a transposition of the traditional Russian masterpiece: the "matryoshka". Each doll represents a dataset level, and this infographic underlines the importance that no one indicator will be lost, nesting one inside the other; however, from the bigger (all raw data) to the smallest (core indicators) matryoshka, a selection from the previous LoI will be performed. The four dolls correspond to the LoI that structure the ALDREN approach and to which the different users could have access according to their needs and expertise. The big doll corresponds to the higher LoI a sort of "data lake" which contains all the information needed along the process.
the importance that no one indicator will be lost, nesting one inside the other; however, from the bigger (all raw data) to the smallest (core indicators) matryoshka, a selection from the previous LoI will be performed. The four dolls correspond to the LoI that structure the ALDREN approach and to which the different users could have access according to their needs and expertise. The big doll corresponds to the higher LoI a sort of "data lake" which contains all the information needed along the process. Referring to the traditional DKIW method and starting from the first step, the ALDREN database contains all six distinct databases developed within each single task of the WP2 project: energy rating and target (Task 2. 2), energy verification (Task 2. 3), comfort and well-being (Task 2. 4), cost, value and risk (Task 2.
5), building picture (Task 2. 6. 2), and documentation and BIM (Task 2. 6. 3). Each database contains dedicated indicators, and methodology according to their respective protocols, but at the same time they are joined into a unique one, the ALDREN database, through a common language (Task 2. 6. 1) and some typical characteristics of a DB (i. e. , database format, access, system connection, data upload, etc. ) fundamental to make this repository a useful instrument.
2. Each module and its respective protocol has been developed with a common language to reach different target groups of the renovation chain and to facilitate communication between them. 3. The indicators and parameters for each ALDREN BRP module has been selected referring to an agreed and valuable source (i. e. , BSO, EPC, VCS, EU standards) in order to facilitate the compliancy of the methods to the already existing procedures. 4. The ALDREN BRP will contain both-the actual (as it is) and the future (after renovation)pictures of the building with the aim to become a non-static repository for the entire life of the building, complementary to the mandatory EPC. Referring to the traditional DKIW method and starting from the first step, the ALDREN database contains all six distinct databases developed within each single task of the WP2 project: energy rating and target (Task 2.
2), energy verification (Task 2. 3), comfort and well-being (Task 2. 4), cost, value and risk (Task 2. 5), building picture (Task 2. 6. 2), and documentation and BIM (Task 2. 6. 3). Each database contains dedicated indicators, and methodology according to their respective protocols, but at the same time they are joined into a unique one, the ALDREN database, through a common language (Task 2. 6. 1) and some typical characteristics of a DB (i. e. , database format, access, system connection, data upload, etc. ) fundamental to make this repository a useful instrument.
3. The indicators and parameters for each ALDREN BRP module has been selected referring to an agreed and valuable source (i. e. , BSO, EPC, VCS, EU standards) in order to facilitate the compliancy of the methods to the already existing procedures. 4. The ALDREN BRP will contain both-the actual (as it is) and the future (after renovation)-pictures of the building with the aim to become a non-static repository for the entire life of the building, complementary to the mandatory EPC. In this framework and keeping in mind the above listed key points, the ALDREN Building Renovation Passport has been developed to become a coherent element in a common EU solution: an instrument complementary to the EPC (ALDREN EVC), that can stimulate cost-effective renovations in the form of long-term, step-by-step renovation roadmap for a specific building based on quality criteria and following an energy audit (ALDREN BuildLog) and outlining relevant measures and renovation actions RenoMap, as suggested by Directive 2018/844/EU Art 19a.
The ALDREN BRP is composed by the two called elements: the ALDREN BuildLog and the ALDREN RenoMap, both composed by respective modules to be completed along the ALDREN approach. Figure  4  represents the data flow of the ALDREN approach that lead to the ALDREN BRP creation. The whole ALDREN approach foresees three main phases that could be defined with a similarity to the computer science-back-end, middleware, and front-end. The whole amount of raw data collected at the beginning of the process are joined into the ALDREN database and this corresponds to the higher LoI (back-end). Then continuing the path, in the middleware a first selection of data is performed to structure the whole spreadsheets of the ALDREN BRP digital version. The lowest LoI (front-end) is represented by the paper version of the ALDREN BRP.
The possibility of having different versions of the BRP derived from the purpose to avoid the creation of a static instrument and to permit the comprehension of the data to different target groups in function of their needs and expertise. The experts who that will be trained to apply the ALDREN approach will start the application of the approach using the excel file, having access to all the indicators collected since the databases, applying the respective protocols to manually insert the overall indicators into the excel worksheets. At the current project development, the final passage foresees the possibility of having both a paper and digital version. This user-friendly format has been chosen to increase the accessibility and feasibility of maintaining the data updates over time. Further options (i.
Conclusions The BRP has been structured as a supporting tool for MSs to achieve higher and deeper renovation rates considering environmental, comfort, and economic performance all linked to specific renovation processes. The ALDREN Building Renovation Passport has the role of showing clearly to the owner and/or investor a clear picture of the current state of the building (ALDREN BuildLog), providing precise technical/economic information of future steps (ALDREN RenoMap) towards low energy consumption and high IAQ (Indoor air quality). The common language, on which the ALDREN BRP is based, allows comparing different buildings and projects over the lifetime and also gives a solid basis to communicate between owners, investors, maintenance people, and tenants, and to set targets and milestones based on the life time of the building and to follow subsequent targets.
Data collection Data collection have been performed by distinct TABULA partners in according to national needs. E Data quality Data acquisition and transformation is susceptible to faults or data non availability and its directly dependent to the determination of the thermal envelope area and the conditioned floor area. F Data query TABULA WebTool supports query: all fields of the database can be queried. G Connection with other databases and other uses YES. It follows up on the previous EU projects DATAMINE (2006-2008).
D Data collection Data collection have been performed by distinct TABULA partners in according to national needs. E Data quality Data acquisition and transformation is susceptible to faults or data non availability and its directly dependent to the determination of the thermal envelope area and the conditioned floor area. F Data query TABULA WebTool supports query: all fields of the database can be queried. G Connection with other databases and other uses YES. It follows up on the previous EU projects DATAMINE (2006-2008).
1 ools used System modelling was achieved using decomposition into components using the classical B syntax and structuring mechanisms (e. g. , including or extending machines). The validation was done using the ProB animator and model checker  [2] , along with custom visualisations developed in JavaFX and Tcl/Tk. The final prototype was executed using the ProB animation engine, controlled by ProB Java API along with Java and C code to interface with the various trackside components at runtime.
Distinctive features The complete principles HL3 specification was modelled in a formal language. We uncovered several dozen important issues with the existing principles HL3 specification, leading to multiple changes which found their way into two new, updated versions of the reference document  [1]. Note that the parts of the model shown in this paper and the issues that are discussed are based on version 1A of the HL3 specification. The formal B model was executed without code generation, as illustrated in Fig. 2. It was run in real time using the ProB interpreter alongside either Thales simulators or real trains and interlockings. To our knowledge, this is the first time that a formal model was used at runtime as a prototype for a safety critical system. There are other uses of formal models as prototypes (see, e.
It is maybe less known that Atelier-B also supports an Event-B dialect. Another less known fact is that one can also make use of classical B for systems modelling, using B's inclusion mechanism to decompose a system into components. This is what we have done in this paper, and justify our choice later in Sect. 7. 2. In this paper we mainly use the animator and model checker ProB  [2] , which supports both classical B and Event-B, and also has support for the Atelier-B dialect of Event-B. ProB also provides a few extensions to the core B language, which have not yet made their way into rodin or Atelier-B. In this paper we have used some of these extensions and also explain why we have done so.