dataesr/scientific-paragraphs-categorization huggingface dataset:
In order to resolve discrepancies, target constraints are formulated, and a schema is proposed. Each source is scrutinized by a "meta-analysis"  [10, 11] , in order to identify what may conflict the constraints. Then public datasets are inputted in a fusion process, following Bloch  [12] , which more precisely is an asymmetric revision, as in Benferhat et al. [13] , in a background similar to Reichgelt  [14]. Issues raised by VGI have been addressed, e. g. , by Johnson and Iizuka  [15]  successfully combining OpenStreetMap features and Landsat image classification; by Younghoon et al. [16]  integrating several crowdsourcing sets in a single graph,or possibly developing collaborative platform such as FeatureHub  [17] ; or multiple platforms as in Juhász et al. [18]. The specific goal assigned to VGI in this paper is to gather data for revising some already geocoded gares (whose quality is questioned), and mostly for integrating more gares, not recorded in public datasets.
Next, Section 3 describes several ways in querying various VGI sources, mostly about gares on secondary lignes (e. g. , the popular rural tramways in France, between WWI and WWII). The last opportunity to resolve failed geocoding issues, is to exploit remote-sensing images, old aerial photographs, and contemporary or 20th-century maps. Issues of enacting data quality within a data collection process have been addressed by Vasseur et al. [25] , who evaluates the quality in the context of a target use, and  [26, 27] , two reviews about quality control in crowdsourcing, by  Daniel et al. and Senaratne et al. The mix of manual and software steps presented above, combines into what we name the computer-assisted reconstruction procedure (CARP). Finally, the resulting CARP dataset is cleaned up by an assisted data quality control.
Target Notation and Generic Step-by-Step Approach for Collecting Values The overall objective is to gather as many gares as possible that have ever existed. Therefore, the process starts with an initial dataset, then grow it, in a logical consistent way, by adding complementary or supplementary information from more available data. To add a gare, means to create a node and to fill in attribute data step by step (Table  1 ), starting with the knowledge that a gare named label belongs to the ligne identified by num. In general, information about a ligne contains a list of the gares in between origin and terminus, which allows to set km values in correct order, although approximate in kilometers.
Attribute insee, is either given or derived from geometry of gare and,commune. Attributes capa, info are merely informative (voidable). The baseline goal is to build a dataset, compliant with the above target constraints. Constraints are flexible enough for semi-structured VGI (Section 3), while allowing consistency checking at every stage, for every source, and for the result as well. Connectivity is not explicit in that model, but can be retrieved from the existence of several couples (num, uic) for a same uic, which denotes a "junction-gare", or by the explicit identification of a fork between 2 lignes (see Discussion and Appendix B).
Public Open Data Sources, and the Information Revision Problem In a project it is customary to define a baseline, which encompasses: goal, constraints (listed above), resources (listed below), estimated cost (time to target goal). Baseline resources are versions (2020, 2017, 2014) of a public datasets originating from SNCF-Réseau (French national operator) [30], somewhat similar to the target schema. Baseline cost is the cost per gare times the number of expected gares. The cost for one gare, depends on the steps outlined in Table  1. The number of expected gares, has not been found in the literature: for instance Auphan  [31]  estimates the maximum length of the network at 70,000 km in 1920, but does notmention a number of gares or communes impacted at that time. An estimation can use length and density of the network, e.
Description of the Available Public and Administrative Sources The public datasets that provide gare and node information (no explicit difference), are listed in Table  2 , with data schema, version, and availability. The public datasets about communes and lignes, listed in Table  3 , are used for joining information (insee, num) and for display purposes. The various Sncf versions provide scarce metadata  [28] , only about their lineage: how to check if a dataset complies with the target constraints? the only way is to perform a "metaanalysis", a technique using "individual participant data" (IPD-MA), mainly developed in medicine  [9, 10]. The math behind meta-analysis uses variance-covariance matrices. In this application, "individual participants" are nodes of gares, and data are qualitative: hence, only equality can be checked, leading to true/false values.
Therefore mathematics boils down to simple counts of items sharing equal attribute values. The meta-analysis is applied directly on the individual items of each dataset, and proves useful in the subsequent fusion. Counting single attribute occurrences performs anunivariate meta-analysis, counting joint occurrences by a couple of attributes performs a multivariate meta-analysis. This subsection is devoted to detailing what issues are revealed by the meta-analysis, helping to design the steps of a fusion approach. For aquick read, skip directly to Section 2. 4 to discover the fusion, and return later to understanding the reasons why.
Conclusion of the Meta-Analysis The meta-analysis has been applied to the two main public datasets providing gare information: the result is a better understanding of what data must be handled, which helps designing a fusion approach to merging data from 2014 and 2017. In particular, it helps in understanding that the "toponymy-patter" and the "fork-pattern" constitute hurdles in the fusion process, and will require additional information from external VGI sources. The meta-analysis can be used as a quality control tool at any time at any stage of the reconstruction process, and will be used to control the result (Section 4). Concerning Sncf2014 and Sncf2017, some metadata can be summarized (Table  6 ). METADATASncf2014: { "mime":"csv", "year":"2014", "nbfeatures":6442, "schema#": {"label":6442, "num":6442, "nature":6442, "geometry":6442}, ( 1 ) "unos#": {"label":6098, "num":593},"duos#"{"num-label":6436} ( 2 ) } METADATASncf2017: { "mime":"geojson", "year":"2017", "nbfeatures":7702, "schema#": {"label":7702, "uic":7702, "num":7702, "km":7702, "capa":7702, "geometry":6812}, "unos#": {"label":6813, "uic":6817, "num":734} } ( 1 ) notation schema# stands for: count of all occurrences of properties.
Combining the Available Sources: The Fusion/Revision Problem Versions Sncf2014 and Sncf2014 probably have a same origin, then evolved separately. Sncf2017 has more attributes, notably the km, and uic, and a few more geocoded features (6812 versus 6442) although we do notknow which version would provide the best quality. The expectation is that Sncf2014 and Sncf2017, either confirm each other on some nodes, or add up unique nodes (Figure  3 ). The relational approach, although natural with tabular-like datasets, has been refuted by the meta-analysis, which revealed that 1525nodes have poor or no geometry, and that label is not a reliable attribute. Let's consider instead the fusion approach, following Bloch  [12] :.
DEFINITION. Fusion of information consists of combining information originating from several sources in order to improve decision making. More precisely, let usconsider the context of Revision, or reverse-Updating  [13]  for we aim at reconstructing the past. Revising Sncf2017 by Sncf2014, means to compute (, ) in order to undertake "pairing"  (2014) with a  (2017), then merging  attributes with those of , or "impairing" , if no  fits, then adding  into Sncf2017, after some conversion. All "impaired"  of Sncf2017 remain unchanged. Following Bloch, three steps are required: measure, decision, combination. The relational approach, although natural with tabular-like datasets, has been refuted by the meta-analysis, which revealed that 1525nodes have poor or no geometry, and that label is not a reliable attribute.
Knowledge Representation and Measure of Similarity Consider a declarative approach based on the notion of neighborhood V(x) of a node x, and a measure of membership to that neighborhood:|y∈V(x)|, degree of similarity of another node y to x. The meta-analysis tells us that, once duplicates and ambiguities are solved, a dataset is complying with the target constraints, and has an attribute space into which to de-fine "neighborhoods", and to build a "similarity" measure (Table  7 ), which is a function OK : (x, y) → [0, 1] , where 0 can be interpreted as false and 1 as true. Table  7. The similarity measures membership to V(x). Dissimilarity measures non membership. |y∈V(x)| = |similarNumLabel(x,y)-normalizedShortDistance(x,y)| (a) similarNumLabel(x, y): (num(y) = num(x)) ∧ (slug(label(y)) = slug(label(x))) → 1 or 0 (b) normalizedShortDistance(x, y): let d = distanceGreatCircleInMeter(geometry(y), geometry(x)); if (d ≤ D 1 ) → 1; elseif (D 1 < d ≤ D 2 ) → (D 2 -d)/(D 2 -D 1 ); elseif (d > D 2 ) → 0 (c) |y/ ∈V(x)|: |¬similarNumLabel(x,y)-normalizedGreatDistance(x,y)| (a) ¬similarNumLabel(x, y): (num(y) = num(x)) ∨ (slug(label(y)) = slug(label(x))) → 1 or 0 (b) normalizedGreatDistance(x, y): let d = distanceGreatCircleInMeter(geometry(y), geometry(x)); if (D 4 ≤ d) → 1; elseif (D 3 < d ≤ D 4 ) → (D 4 -d)/(D 4 -D 3 ); elseif (D 3 > d) → 0 (c) Let usdescribe that similarity/dissimilarity measure components: to form a pair of "closest nodes", using the GreatCircle algorithm, whose precision is sufficient in this application, in the range [0, 100 km].
Fusion Combination, Integration, Revision and Conclusion The last fusion step is to make a single "fused" node from a node pair, that is choosing appropriate values for every attribute, e. g. , best coordinates?, or to convert into the attribute schema of the other dataset. The fusion-combination of 2014 attributes concerns: nature: which can be translated into a capa value (though losing some specificity). -geometry: the maximal distance being D 2 , use 2017 coordinates; -info: add approximation info about geometry (depending on dist). The integration of 2017 nodesis straightforward. The integration of 2014 nodesis more difficult, concerning: geometry: straightforward, use 2014 coordinates; -nature: translate into a capa value (rather easy); -km: seek for the closest 2 nodeson the same ligne, then interpolate a value; -uic: build a unique code using numand km; -info: add uncertainty info about km and uic.
The revised dataset is the new "baseline-resource" for the rest of this work. It complies with target constraints (see metadata: Table  10 ). Quality information is added whenever an approximation is made. METADATASncf2014: { "mime":"csv", "year":"2014", "nbfeatures":6442, "sch#": {"label". :6442, "closest":6442, "fusable":6189, "integrable":33} } METADATASncf2017: { "url":"g2017", "mime":"geojson", "year":"2017", "nbfeatures":7702, "sch#": {"label". :7702, "closest":6984, "fusable":6415, "integrable":41, "coordinates":6984} } Overall conclusion before Section 3: The important information after the fusion is that: - -6489 nodes have been qualified; -1532 nodes (label-num-km) -i. e. ,: about 950 garescan be confronted to VGI and remote sensing imagery for setting a controlled geometry.
Materials and Methods Part 2: Voluntary Geographic Information (VGI) Data Integration and Control So far, the revision process has yield an important and consistent dataset, complying with target constraints (unique code, revised label, correct km,. ), plus some quality information. However, the target horizon, amounts to twice as manynodes. Doubling up the total, starting by investigating the 1532 nodesleft behind, then discovering thousands more "forgotten" gares, and further improving the overall quality are the challenges that we ask the VGI to help us overcome. This section investigates Wikipedia, focusing on its semantic aspect, which makes profit of the UIC ontology (Section 3. 1), then investigates various VGI sources, developing some helpers to integratesparse data from less structured and less semantic web data, and it takes advantage of the aerial pictures archives made publicly available by the French IGN.
The wikiCoordinates routine (Annex) is an asynchronous code that must be used in a "Promise" (technology to awaiting answer, provided by most computing languages). In case of a "missing"result, we can query the API with "label" as commune toponym, for quite often a gare is labeled by its commune name. However the gare can be somewhat far from the center. For instance, with Martigues (Figure  6 ), the distance is 5. 3 km (great-circle distance). Therefore, coordinates obtained by that means provides only a rough positioning, which may help when using remote-sensing imagery. The wikiCoordinates routine is used for improving the "revised" dataset, when several location compete for one label, for instance, in the case of Saintes (Section 2. 3), the distance between the duplicates was 348 m, and the answer of wikiCoordinates is: Query:"Gare de Saintes" → geometry:[-0.
Extracting Semantic Information Using Wikipedia's Infobox The Wikipedia API-v2 provides much richer information from an "ontology-driven" Infobox  [22]. The wikiCoordinates routine is used for improving the "revised" dataset, when several location compete for one label, for instance, in the case of Saintes (Section 2. 3), the distance between the duplicates was 348 m, and the answer of wikiCoordinates is: Query:"Gare de Saintes" → geometry:[-0. 617596,45. 748672], Quality:"good" That result is removing the uncertainty.
Simple Lists of gares in Plain Text It is not easy to automate a detection, but the result proves useful in obtaining a list of gares along a same ligne: • manual: copy-paste the text into a string constant; • software: check if that ligne is already documented, or add a new ligne number num. The routine stationsAlongLine (Annex) is used in parsing the example of (Figure  11 ). This has been used with source Traver and a few lignes from cdfFR (Table  13 ).
Simple Lists of gares in Plain Text It is not easy to automate a detection, but the result proves useful in obtaining a list of gares along a same ligne: • manual: copy-paste the text into a string constant; • software: check if that ligne is already documented, or add a new ligne number num. The routine stationsAlongLine (Annex) is used in parsing the example of (Figure  11 ). Parsing the text extracted from one page of Archef provides an ordered list of gares, from origin to terminus, a length, creates the lignenum, and two dates for its lifetime. Parsing the text extracted from one page of Archef provides an ordered list of gares, from origin to terminus, a length, creates the lignenum, and two dates for its lifetime.
Remote-Sensing Information for the Assisted Visual Geocoding of Gares If the direct geocoding of a gare (wikiCoordinates) has failed, the last opportunity is to visually inspect maps or aerial pictures to locate that gare, in a way similar to  [35]  with land-cover. For geocoding a gare, there is a two-step procedure: • (1) software: use a geocoder API (e. g. , Google), querying coordinates for: French word "gare" + label. For instance, with Cardet (Gard), we can try a few query variants (Table  14 ). It is impossible to know which query will give the best answer (distance data have been added in Table  14 , only after visual inspection);.
Therefore, the different steps of the procedure can be summarized as: Therefore, the different steps of the procedure can be summarized as: • software: generate URI using routine checkToponymAt; • visual: start with an intermediate zoom (e. g. , z = 16) and focus on the section where the line is expected to reach the commune (e. g. , SW corner); • visual: inspect map-aerial photo combinations, focus on road-rail intersections; • manual: input back coordinates into geometry of the gare. Adding more automation is beyond the scope of this study. The care brought to this task, must insure a high quality, for it will be very difficult to detect errors later.
Dual Use of the Website RemonterLeTemps: (b) Visual Reverse-Geocoding To show where a geometry points to in aerial or map representation at a given date: • software: generate URI using routine checkGeocodeAt (Annex), cross-check with a geocoder, to get commune name; • visual: start with a high zoom (e. g. ,  19 ), and inspect map-aerial photo combinations, zoom-out to get neighbor toponyms (railway terminology may appear); • manual: confirm, or infirm, the quality of the information for that node.
The Reconstruted Network (CARP) The Computer-Assisted Reconstruction Procedure -CARP-data result from the fusion (Section 4. 2. 1) and from the VGI integration (Section 4. 2. 2). So far, as of January 2021:the CARP dataset contains about 10,900 nodes, accounting for about 9100 different gares (about 100 in neighbor countries), 450 fork nodes, and 68 border-crossing nodes. The problem is to find the right zoom level, which displays the street name. Note: to the same query: "Chemin de la Gare, Cardet", the Google geocoder answers a location 563 m (more South), versus 50 m with the IGN geocoder. In that particular case, we have the visual result exactly at the crossing with the road.
The Reconstruted Network (CARP) The Computer-Assisted Reconstruction Procedure -CARP-data result from the fusion (Section 4. 2. 1) and from the VGI integration (Section 4. 2. 2). So far, as of January 2021: the CARP dataset contains about 10,900 nodes, accounting for about 9100 different gares (about 100 in neighbor countries), 450 fork nodes, and 68 border-crossing nodes. The meta-analysis appliedto CARP, has helped in understanding more discrepancies (systematic bias rather than arbitrary errors): 1. label disparity due to change between dates: the toponym-pattern (Appendix B. 1); 2. geometry deviation, due to network evolution and "fork-pattern" (Appendix B. 2). The CARP tries to restore the evolution of the data as best as possible, and to bring additional corrections wherever identified.
• Meta-analysis (Figure  18 ): production of metadata, counting missing attributes, checking constraints (e. g. , uniqueness), correction of ambiguities and duplicates, possibly completing some geometry, per-node addition of quality information; • Three-steps fusion: similarity-measure, fusion-decision, attribute-combination (Figure  19 ), whichyields the revised dataset (=6489 nodes), plus dataset of remaining undecidednodes, i. e. ,: no geometry (718), or too uncertain (250 in 2014, 564 in 2017); • Quest for geometry of undecided nodes (Figure  20 ), using Wikipedia or any direct geocoder, to get gare coordinates: it helped to integrate about 400 additional nodes; • Visual inspection of Remote Sensing / old maps, for final improvements: it gave about 600 additional nodes originally in public datasets but without geometry (Figure  21 ).
All gares are sorted by ligne, and by km increasing order: it allows a simple routine to convert these sequences into a line-string, plotted as dotted red lines that approximate the disused lignes: no extra information is added. The Region Bretagne has been thoroughly processed: the CARP data represent almost 100% of what has ever existed. Region Provence is almost complete as well. The CARP dataset is deposited, under open license, on the data. gouv. fr website. The format is geojson. Periodic revisions will bring additional data until full completion. The meta-analysis appliedto CARP, has helped in understanding more discrepancies (systematic bias rather than arbitrary errors): 1. label disparity due to change between dates: the toponym-pattern (Appendix B. 1); 2. geometry deviation, due to network evolution and "fork-pattern" (Appendix B.
2). The CARP tries to restore the evolution of the data as best as possible, and to bring additional corrections wherever identified. • Meta-analysis (Figure  18 ): production of metadata, counting missing attributes, checking constraints (e. g. , uniqueness), correction of ambiguities and duplicates, possibly completing some geometry, per-node addition of quality information; • Three-steps fusion: similarity-measure, fusion-decision, attribute-combination (Figure  19 ), whichyields the revised dataset (=6489 nodes), plus dataset of remaining undecidednodes, i. e. ,: no geometry (718), or too uncertain (250 in 2014, 564 in 2017);.
• Quest for geometry of undecided nodes (Figure  20 ), using Wikipedia or any direct geocoder, to get gare coordinates: it helped to integrate about 400 additional nodes; • Visual inspection of Remote Sensing/old maps, for final improvements: it gave about 600 additional nodes originally in public datasets but without geometry (Figure  21 ). Only the last step (Figure  21 ) is "manual/visual", although assisted by some direct or reverse geocoding, depending on what is available first (toponym, or closest geometry). Only the last step (Figure  21 ) is "manual/visual", although assisted by some direct or reverse geocoding, depending on what is available first (toponym, or closest geometry). Only the last step (Figure  21 ) is "manual/visual", although assisted by some direct or reverse geocoding, depending on what is available first (toponym, or closest geometry).
Addition of New Lignesand Gares, from VGI A gare exists only if a ligne exists to which that gare belongs. Most of the 'secondary' lignes are not recorded in public datasets, and have no official num code. VGI has recorded many of them. Depending on what can be found, various routines may apply. Figures  22  and 23  sketch the three steps of a possible full software chain: (a) from a ligne: list of nodes (routines executed on the server): f[i] = {"label":"l", "num":"n", "km":"k", "info":". "}, "geometry":null; (b) for each node: ask a geocoder, as in Figure  20 , or visual inspection as in Figure  21:  f[i]. geometry = {"type":"Point", "coordinates":[lon,lat]}; (c) for each node with geometry (Figure  23  (a) from a ligne: list of nodes (routines executed on the server): f[i] = {"label":"l", "num":"n", "km":"k", "info":"…"}, "geometry":null; (b) for each node: ask a geocoder, as in Figure  20 , or visual inspection as in Figure  21 : The dataset built at this step is named "CARP-VGI".
(a) from a ligne: list of nodes (routines executed on the server): f[i] = {"label":"l", "num":"n", "km":"k", "info":"…"}, "geometry":null; (b) for each node: ask a geocoder, as in Figure  20 , or visual inspection as in Figure  21 : The dataset built at this step is named "CARP-VGI". a gare has a label, a num, and a km, identifying it and the ligne to which it belongs; 2. all gares sharing the same num, have their km in strict increasing order, from the gare tagged origin to the gare tagged terminus, what means at least two gares per ligne; 3. a gare with an inseecommune code, has its geometry-point inside the geometry-polygon of that commune; every gare located in France can receive an inseecommune code; 4. a garelabel is consistent with its communenom and insee. Quite often a label is the name of an existing commune (sometimes 2 communes names).
Theoretical Issues in Building a Comprehensive Dataset from Internet Sources The problem of building a dataset from the vast amount of information available on the Internet has been theorized, noticeably in the medical sector, for instance by Sreenivasaiah et al. [36] , which lists four categories of a total 11 issues for integrating information. This present work is confronted with at these categories. These four issues are very critical in geographic information in general, because geography by itself is a reservoir of very strong constraints, which must be consistent with all other constraints: e. g. , linear referencing, digraph connectivity, etc. whichhas been studied extensively for decades, leading to the definition of standards by INSPIRE or OGC  [28, 29] , or implementations as in OSM  [37].