dataesr/scientific-paragraphs-categorization huggingface dataset:
Such hypotheses are in turn continuously challenged and updated by new discoveries, and there is no way to provide a truly definitive answer. Primary sources may also be wrong or misleading. Modern geocoding tools are not geared towards dealing with these ambiguities. Finally, available historical sources for the weaving of a gazetteer are sparse (both spatially and temporally), heterogeneous, and complex. We believe all these specificities call for a dedicated approach. Similar observations have already been made in the context of archival data by the UK National Archives, for example  [6]. Large historical event gazetteers already exist  [7, 8]  and provide an important basis to the development of the reference dataset. More specifically, the classic steps we have identified in geocoding for a historical source are first to establish a reference gazetteer for addresses (associating standardized textual addresses with coordinates), and then to determine the input standardized textual addresses within this gazetteer (geocoding).
Theoretically speaking, this whole process is very akin to a simple database join where the key would be the standardized textual address. However, this methodology does not take into account the historical dimension, and requires both standardized and complete gazetteers. For instance,  [2]  pinpoint a reference gazetteer of "CSD" (census subdivision) for each year in the historical period of interest. Geocoding is then completed separately for each year, with a simple CSD match. [9]  introduce more detailed address gazetteers (which go so far as to provide street numbers). However, since the work was still in progress at the time the article was written, it gives no details on the geocoding process. [10]  present work pertaining to several historical periods, and for each one, comprises a gazetteer of standardized addresses.
Extracting information from maps Once the historical maps have been georeferenced and temporalized, their cartographic objects can be extracted to produce geohistorical objects. The most common way to extract information from maps is by human action with a classic GIS software (e. g. QGIS). However, each historical map of Paris contains a large amount of information to be extracted (e. g. thousands of street names, even more building numbers, etc. ). A first solution would therefore be to use computer vision and machine learning methods to create automatic extraction tools. These tools can process the whole map in a few hours. Regrettably, such tools are difficult to design, are very specific to each historical map, and may produce low quality results (see Figure  1 ). Collaborative approaches have recently shown to be very efficient for building large geographical databases in a relatively short period of time (OSM 8  , NYPL  9  ).
Methods Based on historical sources and historical maps, we extract geographical features which are then gathered into several gazetteers. These (geo) historical features are modelled in a generic way (geohistorical objects) into a Relational Database Management System (RDBMS). Geocoding an input historical address is finding the geohistorical object in the gazetteers that best matches this historical address. We propose a matching process relying on several distances (temporal, textual, spatial, etc. ) which can be customised by the user. Lastly the results can be displayed via a web mapping interface over current or historical maps, and further checked and edited collaboratively. Any edit creates a duplicate of the original geohistorical object from the gazetteer, which is then added as another geohistorical source (user contributed).
Building historical gazetteers Our approach for building a historical gazetteer follows these steps: 1. a historical map is scanned, 2. scans are georeferenced using hand picked control points, 3. historical work allows for the estimation of temporal information and spatial precision of the map, 4. road names and axis geometry are extracted from the scan (manually or automatically), 5. building numbers are extracted from the scan (manually or automatically), 6. in some cases, building numbers can be generated from the available data (e. g. road starting and ending building number), 7. normalised names are created from historical names (dealing with abbreviations, etc. ), 8. geohistorical objects are created.
Extracting geo-historical information from maps The whole process is carefully designed and explained in detail in  [30]  (A work on modelling historical geospatial information, from the source qualification to georeferencing to analysis and data extraction, associated with optimization methods to create and exploit spatio-temporal street graphs (linkage between historical information). Geohistorical objects are then extracted from the referenced historical maps, mostly manually (in a collaborative way), or with the help of computer vision techniques. The main advantage is that for a given moment in time we can have several conflicting snapshots that coexist. This is essential, as solving these conflicts may not be possible, and reporting these several conflicting geocoding results to historians may help appreciate the results.
Modelling geohistorical objects Geohistorical data is extremely diverse, both in terms of historical sources and of how the sources were dealt with by historians. As such, historians use complex tailored models. We do not aim at modelling every geohistorical data in its own specificity and complexity. Instead, we propose to model the bare minimal common properties of all geohistorical objects, and offer mechanisms in order for this model to be easily extended and tailored to the specificities of the data. To define the bare minimal model, we start from the very nature of a geohistorical object: both a historical object and a geospatial object. The extension mechanism is provided via a database-object oriented design using table inheritance, and is packaged into a PostgresSQL extension  10.
A database of geohistorical objects We define a conceptual schema for geohistorical objects, which is based on two names, a source, a capture process, fuzzy dates and a geometry. This delineates the core of a generic geohistorical object. Yet this geohistorical object model is easily extendible using the table inheritance mechanism, an object-oriented design mechanism available in PostgreSQL (see Figure  5 ). The concept of table inheritance is simple, although slightly dissimilar to classic object-oriented inheritance. When a table child is created as inheriting from a table parent, child will at least feature the columns of parent, but can also contain other columns (provided there be no name/type collision). In our case, this means that a table of geohistorical objects will inherit from the main geohistorical object table, i.
Database architecture for geocoding Again, we use the PostgreSQL table inheritance mechanism. To this end, we create two tables dedicated to geocoding. Gazetteers tables which will be used in geocoding must inherit from these two tables. Table "precise_localisation" is for geohistorical objects corresponding to postal addresses, e. g. "12 rue du Temple, Paris". Table "rough_localisation" is for road axis, neighbourhood and other coarse urban objects. We chose to have two separate tables for ease of use and performance. Geocoding queries are then performed on the two parent tables, but thanks to inheritance, these parent tables virtually contain all the gazetteers tables containing the actual geohistorical objects, as illustrated in Figure  6.
Collaborative editing of geohistorical objects The geocoding approach we have presented in the previous section works inside a PostgreSQL database. Given an input address and fuzzy date, plus a set of parameters, it returns the geohistorical objects that best matches the input. Yet the geocoding results are only as good as the gazetteers used (at best). The geohistorical objects within the gazetteers may be spatially imprecise, mistakenly named or simply missing. Given that the volume of geohistorical objects is large (for Paris, approximately 50 k building numbers per historical map), we created a collaborative platform which facilitates geocoding, result visualisation and geospatial object editing when necessary. To this end, we created a dedicated web application in order for collaborative edits to be made without having to install specific tools.
Architecture The heart of the architecture is a PostgreSQL database server, which contains the geohistorical object gazetteers to be used for geocoding as well as the geocoding function. A web server can geocode addresses and return results via a REST API. However, the web server has another option wherein the results are not returned, but instead written in a result table along with a random unique identifier (RUID). The RUID is then the key that allows the display and editing of the results. To this end, a geoserver can access (read and edit) the result table via the WFS-T protocol. A web application based on Leaflet then acts as a user interface to display and edit the results via the geoserver.
Interface for batch geocoding via CSV files. In our experience, historians often work with spreadsheet files, where each line will be a potential historical object, along with an address and a date. To facilitate the geocoding of these addresses, we propose a User Interface which reads Coma Separated (CSV) files (a standard spreadsheet format) and geocode the address and date they contain. This interface is built around the PapaParse  14 Javascript framework. The geocoding results can then either be downloaded as a CSV file, or displayed and edited in a web application. Interface for display and edit of results. The most complex interface we propose is based on the Leaflet 15 Javascript framework. There, the user can geocode an address, or use an address which has already been geocoded via the RUID mechanism (see Section 3.
Results Several experiments are performed to validate our approach. First, the geohistorical model is used to integrate objects extracted from historical maps from the 19 th century for the city of Paris, and the current OpenStreetMap road axis and building numbers for Paris city surroundings. Road axis, building numbers, and neighbourhoods are successfully integrated to the geocoder sources. Multiscale geocoding of dozens of thousand of historical addresses is then performed. Addresses are extracted manually by historians and extracted automatically through an automatic process. For one of the datasets, a historian manually corrects the automated geocoding results, so as to evaluate the quality of our method. Last, the collaborative editing of geohistorical objects is evaluated in two scenarios: analysis (several results for one address), and edit (efficiency of check/edit top results for several addresses).
Other geohistorical sources The presented system accepts any data that conforms to the previously introduced geohistorical object model. As such, we also introduce data from OpenStreetMap, dated from 2016. As a comparison,  [35]  use uniquely current data to geocode medival places. We use the version of the data which has been transformed to be used by the Nominatim geocoder. Custom scripts extract road axis and building numbers, which are then converted into a geohistorical object table. Spatial precision is estimated after a short analysis of the positioning of a few Paris addresses. Using Open Street Map addresses highlights several of the possibilities the proposed method has to offer. First, our geocoder can work seamlessly with historical and modern data. The user can choose which type of data to use by placing more or less importance on temporal distance.
Geocoding of Historical datasets One of the end goal of our geocoding tool is to be useful for historians. Therefore, we contacted several historians working on 19 th century Paris. They had been collecting historical textual addresses associated to a person or business for their own research, by manually browsing hundreds of archive documents. Overall, the collected textual addresses are of good quality (being hand collected), although they sometimes contain errors and abbreviations. We imported their data into the geocoding server and geocoded the provided addresses (i. e. associated matching geohistorical objects from the gazetteers). Figure  12  shows an extract of the thousands of geocoded addresses, while table  1  gives an overview of the number of successes and timing. The Belle Epoque dataset is different from the previous one because it has been automatically extracted from directories of Paris financial societies between 1871 and 1910.
3 to 0. 5 (over 1). For one of the data sets (Textile 1 and 2), the historian manually corrected the positions of the geocoding results (i. e. the positions the goecoding associated to input textual addresses). The corrected positions now form a ground truth dataset (associating textual addresses and corrected positions). We geocode this ground-truth dataset again and analyse the results, namely to try and understand the accuracy of the geocoder.
Using the web application, we geocode the address "10 rue de Vaugirard, Paris" for the date 1840, and ask for the top 3 results, as shown in part one of illustration 14. A matching building number geohistorical object exists in the three gazetteers extracted from the three maps. Based on the results, we can safely assume that this building number has not changed during the last 2 centuries. 4. 4. 2. Use case 2: batch geocoding of 30 addresses and check/edit In this use case, a regular user is to check/correct 30 random addresses from the Jacoubet map using the web application. The task is performed quickly, checking and editing each address is a matter of seconds. The main time consuming task is the loading of the background historical map, due to unfortunate hardware limitations. The edit speed seems to be on par with a desktop based editing solution (using QGIS).
Using external resources from the Web of data as new sources Beside features representing address points and streets, georeferenced features of other types could be benefit from the geocoding service. As a matter of fact, people often refer to places of interest, such as famous buildings, monuments like statues or fountains or even identified neighbourhoods to describe their position in space. We are thus considering adding data about places of interest to improve our geocoding service. Like the data used to build the geocoder, this data could be gathered from ancient maps. It may also originate from existing gazetteers and knowledge bases published on the Web of data, such as DBpedia  19  , Yago  20  , the Getty Thesaurus of Geographical Names 21  or the gazetteer of place names published by the French National Library  22.
Diversity in geohistorical object natures In this article, several types of geohistorical objects were used for geocoding: building numbers, streets axis, neighbourhoods. Other datasets were investigated as well, such as the city limits collaboratively extracted from the Cassini maps by the Geo Historical Data project  [32]. In fact, a compiled version of city limits (GeoPeuple project  [38] ) from 1793 to 2010, created by EHESS, has also been tested. But building cadastres could also be integrated so as to have a building layout associated to an address rather than a point, which would solve an old problem of address points. Indeed, there is currently no consensus as to where a building number address point should be positioned: on the entry door, on the letter box, etc. In some cases, there is more precise data available, providing the layout of apartments in buildings, which is very exciting.
Named Entity Linking As previously mentioned in section 5. 1, people often refer to place names to describe their position in space. The task of retrieving place names in a gazetteer or in a knowledge base, also known as (Spatial) Named Entity Linking or toponym resolution, is a widely used way of disambiguating mentions of spatial named entities extracted from texts by means of natural language processing approaches for information retrieval, information extraction or document indexing purposes  [39]. As we plan to upgrade our geohistorical database with data about places of interest, we also have to adapt our geocoding service in order to make it retrieve reference data stored in the database and corresponding to place names mentions proposed by the users. Spatial Named Entity Linking implies solving issues related to places names inherent ambiguity  [40] , such as the fact that a place may have several names or the fact that several places may be designated by the same name.
Analysis tool of the cartographic sources content It is interesting to look at which historical sources were the most used for geocoding, although the historical sources are chosen based on a complex ranking function. If we take the example of the over 10k geocoded addresses from the "Artists accommodations" dataset, we could expect all of the results to be drawn from the Jacoubet map, as the dataset is between 1793 and 1836, and the Jacoubet map is also in this range. Yet, analysing the results shows that if Jacoubet was used for 80% of the addresses, Alphand was used for 15%, although the map was issued 30 years after Jacoubet. More surprisingly, the OpenStreetMap current data is still used for 5% of addresses, although it is about 2 centuries older than the dataset. Similar analyses of other datasets show that all maps are always used, with of course a focus on the temporally closest map.
Interestingly, these results are in agreement with similar work as presented in  [44] , chapter 4, where a prototype of multi-temporal geocoding is proposed. The approach shows that for different datasets, all references maps (Jacoubet, Alphand and BDAdresse (2010)) are used, with proportions depending on the parameters at play and the weight of each criteria. We think that these results are explained by the fact that historical maps miss some information, contain errors, and do not have the same geographical coverage.
Cross-referencing historical maps One way to improve quality of available historical data is to use advanced cross-referencing. Indeed, the process of linking and merging similar data from heterogeneous datasets, which is called data conflation, enables to transfer information from one feature to the another, and may thus bring additional knowledge about data imperfections without using ground truth data which are non-existent for geohistorical data. For instance,  [44, 45]  proposed an aggregated spatio-temporal graph to merge and confront historical road networks. This process can reduce data heterogeneity and allow the detection of aberrations such as toponymic or numbering errors, as well as doubtful temporal trajectories of objects such as short disappearances, thereby leading to better data quality.
Scalability The main design choice of our geocoding architecture is to use a flat model for the address (an address is any set of characters), as opposed to current geocoders which are highly hierarchical (an address refers to a street, which refers to a neighbourhood, etc. ). This modelling choice allows for the necessary freedom for incomplete historical data, but also comes with a trade-off regarding scaling capabilities. Indeed, for strongly hierarchical data, it is possible to have separate databases for each city for instance, thus preventing one database to grow too much, and ensuring a nice scaling capability. However, this is not the case with our architecture. By using database indexes, we can theoretically guarantee a fast geocoding time for up to few dozen millions geohistorical objects used as sources.
The main bottleneck in this case is not the temporal aspect (it relies on PostGIS geometry, which enable multiple theoretical solution for scaling), but the textual aspects (i. e. the address string itself). To scale over dozens of millions of addresses, specific architectures may be used to deal with the text search, for instance distributed database (database sharing), in a way that resembles the current software Elastic Search. We stress however that given the current available amount of historical sources, such a scaling problem should not be an issue before a long time.
Conclusion This article tackles the historical geocoding problem. As shown throughout the article, the historical aspects bring major complications to the geocoding problem. The main difficulties come from the nature of historical data (uncertainty, fuzzy date, precision, sparseness), which prevents the use of current-address geocoding methods based on strong hierarchical modelling. Instead, we propose a historical geocoding system based on a sound geohistorical object model. This model is designed to cover the minimal features, and, thanks to its genericness, modularity, and open source nature, can easily be extended to fit other historical sources. Geohistorical objects from several historical sources have been integrated into the database and coherently georeferenced and edited to form gazetteers.
Geocoding an address at a given time is a matter of finding the best matching geohistorical object in the gazetteers, if any. Our simple, coherent, historical geocoding system has been tested on several real-life datasets collected by historians and can be easily used for other places/times/types of localisations. Diverse historical sources covering two centuries for the city of Paris have been integrated into the geocoder. The proposed geocoder is able to localise a large percentage of addresses at a fast pace (about 200ms per address). Finally, the article describes a prototype of web-based User Interface which demonstrates the interest of collaborative editing of address localisation, and helps historians and other digital humanities researchers use geocoding services.
Manually collected dataset South Americans: Collection of South America immigrants living in Paris in 1926, manually input from census, collected by Elena Monges (EHESS). Textile: Collection of professionals of textile industry in Paris, manually input from the "Almanachs du Commerce de Paris", from 1793 to 1845, collected by Carole Aubé (EHESS). Artists accommodations: Textual addresses of artist studios and artists accommodations between 1791 and 1831, collected by Isabelle Hostein (EHESS) to study their impact on Paris' development. Health administrators: Addresses of public health and hygiene administrators in Paris between 1807 and 1919 ([36]), collected by Maurizio Gribaudi and Jacques Magaud (INED-EHESS).
4. 2. 1. 21 Manually collected dataset South Americans: Collection of South America immigrants living in Paris in 1926, manually input from census, collected by Elena Monges (EHESS). Textile: Collection of professionals of textile industry in Paris, manually input from the "Almanachs du Commerce de Paris", from 1793 to 1845, collected by Carole Aubé (EHESS). Artists accommodations: Textual addresses of artist studios and artists accommodations between 1791 and 1831, collected by Isabelle Hostein (EHESS) to study their impact on Paris' development. Health administrators: Addresses of public health and hygiene administrators in Paris between 1807 and 1919 ([36]), collected by Maurizio Gribaudi and Jacques Magaud (INED-EHESS).
In particular, the five re-qualification actions have been analyzed and compared in order to rank them from the best to the worst. The data concerning the actions as well as the performance criteria and their interaction effects come from two previous investigations carried out by the authors involved in the present research. The first study by  Bottero et al. (2014)  proposed the use of the Choquet integral to compare the alternative reuse actions for the abandoned quarry taking into account synergies (mutual-strengthening) and redundancies (mutual-weakening) among criteria. The second study, recently carried out by  Bottero et al. (2015) , adopted an extension of the Electre III method proposed by  Figueira et al. (2009)  to model multiple interaction effects between criteria and tested it using the abandoned quarry re-qualification problem.