dataesr/scientific-paragraphs-categorization huggingface dataset:
A country refers to an entity identified with a COW name (cf. Technical Appendix). This is the major difference with Barbieri's approach which considered only sovereign states as reporting or partner entities. We have developed a standardization process that resulted in the division by 2. 8 of the total number of entities referenced in the first version of the database (from 4144 to 1459) (cf. Technical Appendix). Data from the original sources reproduced in the database are quoted in many different currencies. These quotes are unusable for comparison purposes without an apposite series of exchange rates. We looked for a comprehensive database, which would include all relevant currencies' exchange rate for the period of investigation. Barbieri for her part faced the same problem and she explains how she eventually decided to build up her own exchange rates  (Barbieri, Keshk,and Pollins 2008, 15-16).
However, her base only covers the post-1870 period and a more limited range of countries than in the present database. In addition, a number of individual flows for a given year are expressed in currencies different from those identified in the RICardo database from the original source. For instance, the Barbieri database provides total trade flows for Argentine, Chile and Columbia in gold pesos. In the sources we consulted, Argentine trade flows were expressed in Pesos Fuertes, Chilean trade in Pesos and Columbian in Piastres. It was impossible to reconstruct the various exchange rates Barbieri applied to the original figures and we decided to assemble our own base of exchange rates for the world's countries from the beginning of the nineteenth century. 13 The different steps of this operation are described in the Technical Appendix.
The database structure We have created a relational database (Figure  1 ) that represents all the cleaning and aggregation decisions adopted to provide a usable database. Information on 'entities', 'currencies', and 'sources' appears in specific tables that are linked to the core 'flows' table. Once isolated each type of information is cleaned: the various expressions used in the sources that refer to the same word are reduced to a standardized expression. Extra metadata have been added to the normalized version to complement original information (for example exchange rate to currency). The first version of the database was created and managed under Microsoft Access. When we considered the creation of a web application, we converted it into SQLite format. This conversion process was motivated by the web application technological constraints.
The 'flows' table Each trade flow is characterized by the following information: -source: reference of this flow -flow: value of the flow in the original currency -unit: unit of the flow value expressed as a multiplier -currency: original currency name (refers to the currencies table) -year: year of the flow -reporting: the entity which reports the flow in its statistics (refers to the entity_names table) -partner: the trade partner of the flow (refers to the entity_names table) -export-import 14 : specifies whether the flow is an import or an export. -special_general: indicates if the flow is of special or general trade or unspecified. -species_bullions: the code is S when trade data include species and bullions; NS when the source indicates that they are not included; null when there is no indication in the source.
-transport_type: when indicated in the source, specifies if the merchandise was transported by land, sea, river. -statistical_period: specified when the corresponding year is not a standard civil year. Two more metadata fields have been coded to identify some complex cases. The partner_sum field is 1 when the flow to and from the partner entity represents a sum of flows and 0 in other cases. Some sources indicate the sum of bilateral flows and such data have been included in the database. This is, for instance, the case of British-Australian trade until 1913. In the dataset we find UK trade with Western Australia, South Australia, Victoria, New South Wales, Queensland and Tasmania in addition to UK trade with Australia (total). The world_trade_type has been added to differentiate three types of total trade corresponding to entity partner RICname 'World' -Total_estimated: data are extracted from sources that only provide countries' total trade.
Those data include: re-estimations of a country's total trade over a long period of time (for example Belgium or the Netherlands); data collected from the Mitchell's International Historical Statistics volumes; or data coming from the American Statistical Abstract of Foreign Countries. National publications of historical statistics are also tagged as 'estimated' as they only supply series of country's total trade. -Total_reporting: in this case, data are extracted from sources that provide countries' total and bilateral trade. The reporting entity type may be: a 'country' with an associated COW code (cf. Technical Appendix); a 'city/part of' a country for which there is no total trade data in the base for the selected year; a 'group' or a 'colonial area' referring to many countries for which there is no total trade in the database for the selected years.
-Total_subreporting: data are extracted from sources that provide countries' total and bilateral trade. The reporting entity type is a 'country', a 'city/part of' a country or a 'group' of countries. It is dependent on a larger country for which the database provides total trade data the selected year. This code is used to eliminate duplicates in the calculus of total trade aggregates. For example: total trade of Danzig (country, COW code = 291) over 1834-1866 (irregular) is coded as total_subreporting not to be added to Germany's total trade over these years; in the same manner, Lisbon & Porto's (group) total trade in 1840 is coded as total_subreporting not to be added to Portugal's total trade this year; total trade of Bahia (city/part of) over 1831-1874 is coded as total_subreporting not to be added to Brazil's total trade.
The 'Sources' and 'source_types' tables The sources table lists all the sources contained in the database. A detailed reference to the original document allows the user to check the work of transcription. It is also a way of inviting the user to suggest better alternative sources. The source_types table then classifies the whole set of sources according to three categories: 1. 'primary' sources are compilations of customs returns published by national agencies; 2. 'secondary' sources include: either international compilations of trade primary sources which were in bygone days devised by individuals and government agencies and are today a function of international organisations, or national compilations of national statistics that include foreign trade statistics (mainly statistical yearbooks); 3.
'estimation' sources are works that only provide country's total trade. They include re-estimations of long-term series of a country's total trade, compilations of historical series of world countries' total trade, or national publications of historical statistics. As described in this section, we use a relational database to support and document the data cleaning process. Its structure has been designed to allow the best transparency about the choices made. In order to simplify future data updates (correcting errors or adding new data), the relational database can be exported as a series of Comma Separated Value (CSV) tables under a versioncontrolled tool (git) which allows us to keep track of every change.
RIC visualizations To foster the use of the RICardo database, we have developed a web application where the user can explore the dataset through data visualizations  (Girard et al. 2016). It is a pioneering work that aims at experimenting new ways of exploiting historical trade statistics and opening access to such data to a broader public, beyond the boundaries of academic circles. We hope that this project will contribute to illustrating the invaluable interest of working with historical data series. The database, available in open-access 15 , will be publicly released in 2017 upon the start of an international conference marking the two-hundredth anniversary of the publication of David Ricardo's Principles. Here is a presentation of the exploration interface. It offers four levels of entry from global to local.
Metadata view The metadata view provides an overview of all the information available in the database. A first visualization reports the number of flows by year. Annual variation is a reflection of either an increase in the number of reporting entities or in the number of partner countries by reporting entity, that can be due to the sources used. The visualization below is built around a detailed reporting/year matrix where the user can find six variables for each reporting/year: -World partner: as there are different ways of calculating world trade series, it specifies what type of 'world' (estimated, reported, sum) is used to calculate the world_best guess (cf. 'world view' below); -Number of partners: information on the total number of partners by reporting/year is synthesized by graduated color.
World view The world view focuses on total trade data. Its purpose is to provide an estimation of world exports and imports over the long run and to compare the relative share of countries in world trade over a selected period. When creating this view, we were confronted with two sorts of problems. The first one is the variation in the number of reporting entities which constitute the world. It must be emphasized that the "world trade" curves depicted in this view aggregate a variable number of reporting entities from year to year. This number is indicated in a bar chart. The user also has the opportunity of estimating homogeneous world trade series by downloading an appropriate dataset. The second problem relates to the different ways of estimating total trade. It has been pointed out that different types of total trade can be differentiated in the RICardo database.
Total_estimated emanates from sources that only provide total trade data. Total_as reported coincides with the 'Total' line appearing in trade statistics. Total_sum partner is total trade as obtained from the addition of all partner entities available in the database. Total_best_guess selects the "best" available data for a reporting/year on a priority basis: Total_estimated is first chosen; if not available, Total_as reported; and the latter option is Total_sum partner. As mentioned above, it is planned to enrich this comparison with the inclusion of Total_FedericoTena series, which are the most elaborated estimations of total trade to this day.
Bilateral view The purpose of this view is to interrogate a pair of reporting countries by using a representation of their mirror flows. As outlined above, one of the strengths of the RICardo database is the possible existence of two data for one bilateral flow. However, for a number of reasons given in a preceding section, the two recordings are rarely equal. Thanks to the calculation of an indicator (Dedinger 2012, 1050-1053), the bilateral view provides a visualization of the discrepancy between mirror flows and of its fluctuations over the selected period. A significant deviation between Austrian and British trade statistics between 1895 and 1913 has been pointed out by  (Don 1968 ). This can be easily verified by looking at the Anglo-Austrian country pair from the two bilateral points of view.
Conclusion Describing the various phases of our work from the first conception to its final outcome, it is intended to provide the reader/user with a better knowledge of historical trade statistics and a guide to use the RICardo database. The creation of this innovative tool was made possible thanks to a close collaboration between researchers with complementary expertise and we would like to perpetuate this spirit of cooperation by openly sharing our work and inviting the user to contribute to the development of the project. It is hoped that the RICardo project can serve a variety of purposes, scientific as well as educational. In the scientific arena, RICardo can help to renew research on trade history in at least three different ways. The analysis of trade globalization -causes or effects -can be revisited thanks to extended trade data series.
In a first experiment using an earlier version of the RICardo database,  (Accominotti and Flandreau 2008 ) put into question the economic impact of the wave of bilateral trade treaties -the so-called "Cobden-Chevalier network" -that spread over Europe after the signature of the Cobden-Chevalier Treaty in 1860 and challenge the conventional view that it was at the root of the nineteenth-century trade liberalization. Furthermore, the database may encourage research on trade globalization in fields that tend to be abandoned by economic historians, particularly quantitative studies of a country's trade history. Finally, the RICardo database can be a good instrument to help move the secular debate on the reliability of trade statistics. The online publication of the base is a significant achievement but it does not put an end to the project.
A -The ''entities' tables The non-normalized dataset contained thousands of different entity names, which had to be standardized in order to obtain coherent series of data over the whole period. The most frequent cases of variation were: the same entity appears for the same year under different names in different publications; the same entity changes names during the period under consideration; the trading entity does not correspond to an internationally recognized state but describes a locality or a limited section thereof; the trading entity is not defined precisely. Here are the main steps followed in the standardization operation: Cleaning the entity names The first task has consisted in reformatting the names of reporting and partner entities, the outcome of which appears in the Entity_names table.
RICname entities The RICname is in English. It is partly established after the COW project country list as we explain below. Each RICname is identified by a number of three variables: type, continent, COW code: -the 'type' variable indicates if the entity is: a city/part of a country, a colonial area, a country, a geographical area, or a group of countries. -the 'continent' column indicates where the (reporting or partner) entity is located. When the entity is a 'group' or a 'geographical area' corresponding to a multiple of entities located on different continents, it is identified by the continent 'World'. The five major continents (Africa, America, Asia, Europe, Oceania) are present in the database plus "continents" pertaining to sea areas (Adriatic, Antarctic, Atlantic Ocean, Baltic, Mediterranean, Pacific).
Turkey, when non-specified in Europe or in Asia, has been located in Asia; Russia/USSR, when non-specified in Europe or in Asia, has been located in Europe. The user can change these options if necessary. The 'country' type RICname is defined by referring to the Correlates of War (COW) project. Each RICardo entity that is referenced in the COW list is identified as a 'country' type and is given a COW code. The COW project, initiated in 1963 by American political scientists, has collected quantitative information about armed conflicts in the post-Napoleonic period and resulted into the constitution of several databases, two of which are concerned with the definition and inventory of state entities. 16 Thus, the State System Membership List contains the list of all entities which have enjoyed the internationally recognized status of sovereign state as of 1815.
17 The Colonial/Dependency Contiguity Data variable identifies every contiguity situation (land or river boundaries, or bodies of water) of political entities of the international system (sovereign states, colonies and dependencies) and leads to drawing up a subsidiary list of colonies and dependencies belonging to sovereign states. A ciphered code is attributed to each of these entities with dates of changes of political status. All this information (including entity name and code, political status, and relevant time periods) is a 50 odd-page document entitled Entities. pdf; that served as a basis to define the name and code of each 'country' type RICname. For those entities, which do not show up in the COW database -i. e. 'city/part of', 'colonial area', and 'geographical area' -new English entity names have been created without a numerical code.
Furthermore, new entity names and new codes have been created for three 'countries' that are not included in the COW database: Kingdom of Sardinia (325S): created in 1720, this political entity (assimilated to Italy/325 in the COW list) consisted, before the unification of Italian states in 1861, of Savoy, Piedmont (Turin), Aosta, Nice and the island of Sardinia. Prussia (255P) and Germany (Zollverein) (255Z): Prussia is assimilated to Germany/255 in the COW list. But before the foundation of the German empire (1871), several German entities appear in the RICardo list of partner names -Prussia, German states, Germany and German Zollvereinwhich do not correspond to similar territories. Thus, new country names have been created for Prussia and the German Zollverein (which may be considered as an economic union).
Insert Table 2 here B -Currency conversion The conversion of the values expressed in many different currencies was carried out in two successive steps: 1. Drawing a conversion table exhibiting standardized currency names; 2. Drawing a corresponding table for each currency's exchange rate to the British pound in any given year. Our Exchange Rate table includes all the relevant exchange rates necessary for converting the original quotations into pound sterling. This is an arbitrary choice, but the pound sterling estimates can in turn be easily converted into US dollars or French francs with the appropriate converters. The ' currencies ' table Before dealing with arithmetic, it was necessary to standardize the currency names found in the original database in order to link each currency to a single entity for a selected period.
Insert Table 3 here The ' exchange_rates ' table In the French Annales du commerce extérieur and the British Statistical Abstract for the Foreign Countries, flows are quoted either in national currency and/or in francs or pounds. When the original figures expressed in national currency were converted, the exchange rate used was always based on the gold parity. By contrast, when the information was available, we have used current exchange rates. When it was not, the gold parity was used. For this purpose the main sources tapped were: Annales du Commerce extérieur, Statistical Abstract for the Foreign Countries, the Währungen der Welt collection, 18 the Montevideo-Oxford Latin American Economic History Data Base (http://www. lac. ox. ac. uk/moxlad-database), Statesman's Yearbook. For the US dollar-pound exchange rate, the current exchange rate given in  (Denzel 2010 ) has been preferred except during the years 1862-64 for which the dollar-sterling parity is used.
From the list of standardized currency names, corresponding exchange rates in pound sterling (NCU per £) have been added on an annual basis with the mention of the original source in the Exchange Rate table. This table includes ca. 15000 exchange rate quotations. Each row refers through the source field to the sources table which lists the complete reference to sources used. Despite this relative wealth of information, this particular database is liable to be supplemented when need be. This Exchange Rate table will be made available for download with the rest of the database in 2017.
Interconnection architecture of a micro-grid platform is often changed according to necessary experiment. This information should be communicated to the partner platforms. Classical approaches, consisting of exchange separated measured dynamic values, demand prior manual communication of interconnection architecture to partners. It becomes a time-consuming task when there are many partners with difference in their data formulation or when there is a change in system topology or a reconfiguration of system interconnection. It is possible to easily exchange this kind of topology information in recent information models, using object oriented approaches, such as IEC 61850, CIM or eventually the OPC UA abstract data model. The standard-based configuration of each micro-grid platform is therefore the key perquisite for a successful and secure interoperability.
In this paper, we propose a SCADA architecture considering the possibilities of integrating Open Platform Communication (OPC) within cloud and PaaS to provide OPC based SCADA applications. Due to the timely restriction of critical SCADA functions in the electrical grid (protection, real time control, etc. ), only selected non-critical SCADA functions (back-up, data historian, etc. ) are accessible to partners from the private cloud. The critical SCADA tasks functionality remains under control of local server. CIM/XML/RDF is selected as the mean for model exchanges. We will give some insights to the usage of CIM over OPC UA, serving in the context of interoperability of micro-grid platforms. OPC gateway is proposed as conversion between the old OPC Distributed Common Object Model (DCOM) protocol and Simple Object Access Protocol (SOAP) for cloud.
Therefore, the chosen communication protocol for interoperability of microgrid platforms should be able to handle the classical SCADA functionalities and also to do WAN communication. The legacy Open Platform Communication (OPC) protocol 2 is widely accepted in industrial and research platforms and provides a certain degree of interoperability within the local network. To extend the functionalities beyond the local network and to reach interoperability among different platforms, the OPC Unified Architecture (OPC UA) has been developed and standardized (IEC 62541  [45] ). The OPC UA comes up with an abstract data and information model -the address space -which is adapted to the domain of application. In the electrical domain, CIM provides the necessary information and semantics to develop the according UA address space.
On the other hand, OPC UA provides the necessities to make CIM applicable in term of communication of data payloads  [46] , the capacity to generalize measured data into model and to communicate beyond the local network. The OPC UA plays also the role of a gateway, to converse the legacy DCOM protocols, popularly used in local OPC-based application, to XML and SOAP, adapted for the communication inter-platforms. This combination of CIM and OPC UA allows the provision of OPC-based applications (EMS, HMI and SCADA) in the PaaS delivery model and brings CIM semantic to the OPC UA communication-a final brick to the proposed architecture.
OPC unified architecture OPC UA is developed by the OPC foundation  3  as successor to the classic OPC protocol. OPC UA maintains the server-clientarchitecture, but replaces the three different OPC servers (Data access-DA, Alarms and Events-AE and Historical Data Access-HDA) with only one OPC Unified Architecture server, which simplifies semantics and overall implementation  [18]. OPC UA also provides the platform for interoperability among the existing OPC specifications beyond local network, using web services. OPC UA is standardized by the IEC 62541 standard series  [45]. OPC and OPC UA are used for the exchange of real-time plant data among control devices. OPC specifications are based on Microsoft Distribution Component Object Model (DCOM) to provide a certain degree of interoperability among devices from different vendors.