dataesr/scientific-paragraphs-categorization huggingface dataset:
Acknowledgments Funding for visualising the first case study, 'Migration in the News, 2010-2012', was provided by the  John Fell Fund  ( Oxford University Press ). Funding for visualising the second case study that covered the 2006-2013 period was provided by the  UK Arts and Humanities Research Council (AHRC)  through the project 'Seeing Data: are good Big Data visualisations possible?' (grant number  AH/L009986/1 ). Helen Kennedy ,  Rosemary Lucy.
INTRODUCTION Cloud computing has transformed the Information Technology (IT) industry  (Armbrust et al. , 2010)  by hosting applications and providing resources (e. g. , CPU and storage) as services on-demand over the Internet  (Zhang et al. , 2010) , offering huge opportunities for the IT industry. Cloud providers, such as Google Cloud Platform (a commercial public cloud) and OpenStack (an open source stack for building public/private clouds), usually offer these services in the form of REST (REpresentational State Transfer)  (Fielding, 2000)  APIs, the de facto standard adopted by many software organisations for publishing their services. In particular, we observe that most of cloud providers, such as Google Cloud Platform or Open-Stack, propose their own proprietary APIs. Conversely, open and standard cloud APIs have also been proposed, such as the Open Cloud Computing Interface (OCCI)  (Nyren et al.
This study presents three main contributions in response to the three open research questions: 1) a tooled approach, called CLOUDLEX, for extracting and analysing REST cloud computing lexicons, 2) a dataset of services, resources, and terms used in the three studied REST APIs, 3) our analysis of this dataset, which represents a first attempt to provide a common REST cloud computing lexicon. The remainder of the paper is organised as follows. Section 2 presents our study: the three studied cloud computing REST APIs, our conceptual model for cloud computing REST APIs, the design and implementation of our CLOUDLEX approach to extract and analyse lexicons from cloud computing REST APIs. Section 3 presents our results, answers the three open research questions, and discusses threats to validity.
In OCCI, each API is specified as an extension of the OCCI core model, such as Infrastructure and Platform extensions. Independently of the name used by cloud providers (product, API, extension), each provider's REST API is conceptually a useful service, e. g. , managing virtual machines, networks, databases, or applications, orchestrating their deployment, controlling their access, etc. The number and contents of these services are extremely heterogeneous for each provider: tens of services in Google Cloud Platform, more than one hundred in OpenStack, and five in OCCI. In our conceptual model, we abstract this diversity of functional services (product, API, extension) under the single concept of Service. Each service of a provider manages a set of computing resources such as virtual machine, storage disk, network, application, etc.
CloudLex Approach Our study is supported by the CLOUDLEX tooled approach composed of four steps illustrated in Figure  1 : Step 1. Collecting documentation The first step of the CLOUDLEX approach consists in manually collecting the documentation of cloud computing providers' REST APIs. The Web site of Google Cloud Platform contains HTML pages documenting all GCP's REST APIs. For instance, the HTML page https://cloud. google. com/compute/docs/reference/latest/ describes all GCP's compute services. Open-Stack's REST APIs are documented with Swagger documents such as http://rackerlabs. github. io/wadl2swagger/openstack/sw agger/dbaas. json. OCCI is specified by a set of PDF documents such as https://redmine. ogf. org/attachments/220/infrastructure. pdf. We analysed the three provider's documentation, searching for pages with API URIs.
The CLOUDLEX toolchain is extensible by design as it could support other cloud provider's APIs, e. g. Amazon Web Services, with its own documentation format by just adding a new parser, as illustrated by Other Parser at the bottom of Figure  1. Each parser identifies Provider, Service, Resource and Action data from a specific provider's documentation, and then feeds the Cloud Dataset, which is the tooled implementation of the CLOUDLEX conceptual model. Table  3  gives an excerpt of the obtained Cloud Dataset. We parsed these API's pages and documents to identify their structure. OpenStack provides a page with Swagger JSON files, from which we extracted directly URIs. As for Google Cloud Platform, which provides HTML documentation pages, we had to develop an HTML parser to extract URIs. Unfor-tunately, OCCI documents do not explicitly list URIs but only give rules about how URIs must be generated by an OCCI implementation.
Then, we added a generator to OCCIWARE STUDIO, which is a modeldriven implementation of OCCI, and ran it to obtain all the URIs for OCCI. At the end of this second step, we get the Cloud Dataset, a dataset with the list of resource URIs with allowed HTTP request methods for each provider's service, as illustrated in Table  3. Step 3. Extracting lexicon The third step of the CLOUDLEX approach consists in automatically extracting the lexicon of each provider from its associated Cloud Dataset. The lexicon of each provider contains the name of all services of this provider, the terms extracted from the path of the uri of all provided resources, and the name of all the actions defined by provided resources. The path of a URI is usually organised in a hierarchical form, which appears as a sequence of segments separated by slashes.
For example, the URI /{project}/zones/{zone_ id}/instances/{instance_id} contains five segments: {project}, zones, {zone_id}, instances, and {instance_id}. We keep all segments not enclosed by braces in the lexicon, e. g. , zones and instances. Segments enclosed by braces, such as {project} and all {*_id}, are identifiers either computed by the cloud provider or freely chosen by the cloud user. For this reason, these identifier segments are not part of the lexicon. We then performed a finegrained analysis of all obtained URIs automatically, parsed the URIs following provider's URI patterns, and extract lexicon terms. These extractions resulted in the Lexicon Dataset, a dataset of terms associated with each API. Step 4. Analysing lexicon The fourth step of the CLOUDLEX approach consists in automatically analysing the lexicons.
Implementing CLOUDLEX Both Cloud and Lexicon Datasets are encoded as CSV (Comma-Separated Values) files. This implementation choice fosters the reusability of our datasets by other researchers and practitioners. CSV files can easily be generated from any programming language and read from any analysis software like Apache OpenOffice or Microsoft Excel spreadsheets. Most of the CLOUDLEX parsers, extractors and analyses are implemented in Python, a dynamic scripting language providing simple libraries to get and parse HTML pages/Swagger files, and read/write CSV files, etc. This implementation choice fosters readability, comprehension and auditability of our parsing, extraction and analysis scripts by other researchers and practitioners. Finally, we used OpenOffice spreadsheet software to produce tables and charts shown in Section 3.
Analysis of the Cloud Dataset Using the tooled approach CLOUDLEX presented in Section 2. 3, we extracted a total of 1,297 URIs from the 142 services of the three cloud providers, as shown in Table  1. The distribution of URIs is 588 for OpenStack (45,34% of all URIs), 505 for GCP (38,94%), and 204 for OCCI (15,53%). The distribution of services is 115 for OpenStack (80,99% of all services), 22 for GCP (15,49%), and 5 for OCCI (3,52%). An excerpt of the whole Cloud Dataset is given in Table  3. The average number of URIs  Table  2  gives the ranking of the top ten biggest services in terms of provided URIs, which are compute for GCP (198 URIs, 15,27% of all URIs), Infrastructure for OCCI (77, 5,94%), Platform for OCCI (45, 3,47%), orchestration-api for OpenStack (39, 3,01%), sql for GCP (38, 2,93%), storage for GCP (36, 2,78%), os-compute-2 for OpenStack (33, 2,54%), Service Level Agreements for OCCI (32, 2,47%), Monitoring for OCCI (26, 2,00%), and Compute Resource Templates Profile for OCCI (24, 1,85%).
RELATED WORK Recently, there is a growing interest in the design quality evaluation of REST APIs. However, to the best of our knowledge, few studies made specifically a lexical evaluation of REST APIs in general, and none in the domain of cloud computing. In related work for the general design quality evaluation of REST APIs, we can cite the research work of Hausenblas  (Hausenblas, 2011) , who studies some widely used RESTful Web APIs in terms of URI space design, resource representations, and hyperlinking support. Rodríguez et al. (Carlos Rodríguez et al. , 2016 ) also evaluated the conformance of good and bad design practices in REST APIs from the perspective of mobile applications. They analysed large data logs of HTTP calls collected from the Internet traffic of mobile applications, identified usage patterns from logs, and compared these patterns with best design practices.
Zhou et al. (Zhou et al. , 2014)  showed how to fix design problems related to the use of REST services in existing Northbound networking APIs in a Software Defined Network and how to design a REST Northbound API in the context of Open-Stack. These previous works made contributions to the design evaluation of REST APIs for general or specific domains, mobile and networking, while we consider the domain of cloud services. Some researchers have dealt with the linguistic aspects of RESTful APIs, in particular in terms of lexicon. For instance, Parrish  (Parrish, 2010)  performs a subjective lexical comparison between two wellknown RESTful APIs, i. e. , Facebook and Twitter. In the comparison, the author specifically focuses on the analysis of verbs and nouns in URIs naming. Palma et al. (Palma et al.
For our second contribution, we shared a full dataset of services, resources, and terms used in the three studied REST APIs. Finally, analysing our dataset, we showed that the three APIs formed a lexicon of 352 different terms (nouns and verbs) to express all provided services, in which there are only 17 shared terms, representing less than 5% (17/352) of terms used simultaneously by two APIs. Thus, the three APIs do not share a common lexicon, and we conclude that there is not a consensus actually on which terms to use on cloud computing systems. However, we found that the cloud computing REST APIs follow, in general, the good lexicon practices for REST APIs. A part of our future work is related to threats to validity presented in Section 3. 5. Mainly, this involves the analysis and contrast of more APIs with more naming practices to cover other possible characteristics.
The "Did You Feel It?" (DYFI?) system of the USGS (please see Appendix A for all institutional abbreviations; other abbreviations are defined in the text) asks questions about nationally and internationally felt earthquakes. The advantage of DYFI? is that macroseismic data are collected systematically over the whole North American continent and worldwide through a well-calibrated algorithm  (Dengler and Dewey, 1998; Worden et al. , 2000). In Europe, however, the situation is more complex: at least 33 seismological institutes in 23 countries and 2 international institutes (EMSC and USGS) manage and maintain their own web-based macroseismic questionnaire (Fig. 1 ; see Appendix A for hyperlinks). Despite this high number of inquiries, only a minority of these national institutes, i. e. BGS, INGV, BCSF, SED, IGN, ROB-BNS, calculate and map intensities from people's submissions online and update a macroseismic map in quasi real time (a small amount of time is still needed to process the data).
The ROB shares its questionnaire with the BNS of the University of Cologne (Germany) to collect transfrontier macroseismic information across the Belgian-German border (ROB-BNS network;  Lecocq et al. , 2009). In the ROB-BNS questionnaire, responses are automatically forwarded to BCSF if an earthquake is located in France, and consequently macroseismic data are shared in real time between these institutes. Another transfrontier collaboration is SISPyr (www. sispyr. eu), in which macroseismic data from IGN and BCSF are shared to create a unique ShakeMap of the Pyrenees. Germany has no organized national inquiry, which results in eight different institutes gathering macroseismic data (Appendix A). Other national inquiries are often known to the local population, but unfortunately the macroseismic maps are not always shown online.
The benefit of having different European inquiries is that every institute has made the inquiry available in its own national language(s) and hence can deal with specifics in their language in the open comment box. However, disadvantages are that (1) people can answer multiple national or international inquiries when they felt an earthquake and (2) the data on the perception of transfrontier-felt seismic events is strongly fragmented across different institutes and countries. Merging databases carries the risk of duplicate entries in the database but, more importantly, also has the risk of merging intensities that result from different questionnaires, countries and intensity calculation algorithms, which will smooth the mean of the merged intensities. Because of this European fragmentation and intensity variability, performing a proper macroseismic assessment of transfrontier-felt earthquakes remains a complex and not straightforward task.
Contemporary transfrontier macroseismic maps are either based on historical reports (e. g. Camelbeeck et al. , 2014; Cara et al. , 2005; Knuts et al. , 2015; Kronrod et al. , 2013)  or on communal reports, such as those used to map the 1992 M L 5. 8 (M w 5. 3) Roermond earthquake (NL;  Haak et al. , 1994)  and the 2003 M L 5. 4 (M w 4. 9) Rambervillers (FR) earthquake  (Cara et al. , 2005). These successful efforts in (historical) macroseismology indicate that a comprehensive method is needed to merge the scattered online macroseismic data; however, in northwest Europe, such a methodology is currently not implemented. Examples of transfrontier macroseismic maps developed from classical inquiries (communal reports and field surveys), e. g. the 2003 M L 5. 4 (M w 4. 9) Rambervillers (FR) and 2004 Waldkirch (DE) earthquakes, all show a good equivalence in intensities at the borders, which justifies merging databases.
Geocoding Because intensity is determined for each ZIP code, ZIP-CIIMs cover irregular shapes on maps causing the intensity locations to be imprecise. In a macroseismic questionnaire, people are asked to provide their ZIP code to generate to ZIP-CIIM, but they are also free to provide their street address. Analysing the address columns in the ROB-BNS (31 929 individual reports since 2002) and BCSF (∼ 80 000 individual reports since 2000) macroseismic databases shows that ∼ 89 and ∼ 76 % of people, respectively, freely give their personal address. Given these high percentages, in this study the respondent's location (address) is first geocoded to its true geographical coordinates to improve the spatial resolution of the macroseismic data and to provide a more realistic spread than in ZIP-CIIMs.
Although many official geocode systems such as postal services, official cadastre plans and governmen- Input addresses are send to a Google ™ JSON API in which addresses are corrected and geocoded. Precision of the geocoded coordinates is quantified by a quality factor. For absent, unrecognized or imprecise (too low-quality) addresses, the geocoded response is not used for grid cell intensity assessment. All geocoded addresses are grouped within 100 km 2 grid cells. Cells with at least three responses are coloured to the mean intensity. tal services provide very accurate locations, these geocoding services usually require an exact and correct address input of the respondent and often cannot deal with abbreviations and typographical mistakes. Exploring the address list in the macroseismic ROB-BNS and KNMI databases shows that people frequently abbreviate their street address to their convenience (e.
g. "av. ", "av", "ave" for "avenue"; "str", "st" for "street"; " • ", "nr", "No. " for house number) and regularly make accidental typographical mistakes. To account for these inconveniences, a straightforward algorithm (Fig. 2 ) was developed to send addresses automatically to a Google ™ JSON API to geocode the data. The free edition of the Google JSON API is currently limited to 2500 address conversions per day which currently limits using Google for real-time geocoding of a large number of responses to large-magnitude earthquakes (unless a business account is bought). We prefer the use of Google above the official services because it corrects addresses with typographical errors and the precision of the geocoded location is weighted by the following four quality factors: 1. rooftop quality: precise location to the street address; 2.
range-interpolated and geometric centre quality: location is as good as the street location; 3. approximate quality: address could not be located; either the ZIP code centre or a community location near the address is returned after geocoding. As the approximate quality is too uncertain to be used, any address that has this quality was rejected from geocoded databases in this study (Fig. 2 ). Depending on the user's needs, different quality factors and thus different subsets of the database can be selected for macroseismic intensity assessment. For a detailed intensity evaluation of a local site, for instance, only the roof top quality could be used to ensure a correct location. After geocoding, we automatically calculate the epicentral distance from the precise location of the observer to the epicentre obtained by instrumental data, which facilitates the evaluation of intensity distance attenuation.
Grid cell intensity analysis The distance decay of a geocoded dataset has a larger scatter than the distance decay of averaged intensities from a ZIP code dataset  (Haase and Park, 2006)  because individual intensities at large distances are not ruled out. To account for this statistical problem,  Wald et al. (1999)  subdivided ZIP codes by regularly sized grids of a few kilometres, i. e. smaller than an average community polygon, for which more realistic intensities can be calculated. In this work, a similar grid cell approach is followed: after geocoding all IDPs, we first structure the model area where the earthquake was perceived by dividing it into 100 km 2 (10 km by 10 km) grid cells and, second, assign an average intensity to the cells. This cell size can be considered as equivalent to a macroseismic data point (MDP), which is used in historical seismology to group IDPs and which on average has the size of a small city, according to the AHEAD (Archive of Historical Earthquake Data) guidelines  (Rovida and Locati, 2015).
Integrating macroseismic databases The 2011 Goch event was widely felt in Germany, Belgium, Luxemburg and the Netherlands. Macroseismic data were collected by the ROB-BNS network, the KNMI in the Netherlands and the NRW-GD in Germany, a network that overlaps with the ROB-BNS network. Felt reports for the 2015 Ramsgate event were collected by the ROB-BNS network for Belgian territory, the BCSF for the French territory and the BGS in the UK. The EMSC and USGS also assembled transfrontier felt witness reports of the two earthquakes (Tables  1  and 2 ). To fully understand the effect of seismic radiation across the national borders of countries where the Goch and Ramsgate earthquakes were perceived, it was crucial to collect and merge all available macroseismic data from these (inter)national agencies.
As the national agencies also collect international macroseismic data, overlap exists in the macroseismic dataset (Fig. 4 ). Macroseismic data were freely avail-able upon request from all institutes, after the personal information was removed. To protect the location of the respondent, the USGS provided a list in which the geographical location coordinates were truncated at two decimal digits. The precision of the response is therefore limited within a range of 1. 11 km, causing some responses to overlap on the map. The NRW-GD also protected the location data up to three decimal digits with a location error of 0. 11 km (Fig. 2 ). Although truncation limits the response precision, it does not pose a problem for intensity analysis as all available macroseismic data are grouped within 100 km 2 cells, which are much larger than the individual location error.
ROB-BNS The questionnaire used by the ROB-BNS network (see  Lecocq et al. , 2009)  is largely based on the standardized questionnaire of  Wald et al. (1999)  using standard statistical procedures and rejections following  Dengler and Dewey (2000). Based on the answers, a decimal community intensity (CDI) value is determined following the computer algorithm of  Wald et al. (1999). In the ROB-BNS database, duplications (same name, address, personal details) were manually deleted. High intensities, i. e. more than three intensity units above the intensity attenuation relation (IAR; see below), at large epicentral distances were deleted. The ROB-BNS database (3294 responses) shows the largest geographical spread, mainly because the questionnaire is provided in four languages (see Appendices A and B) allowing a survey far across the national borders.
A total of 2307 addresses (69 %) of the ROB-BNS database could be geocoded. This rather low percentage is mainly because a large amount of German responses lacked street address information. After floor-level correction 2134 responses (65 %) remained for grid cell intensity analysis (Table  1 ). Floor-level correction affects the grid cell intensities of large cities: Brussels and Verviers in Belgium, and Cologne, Düsseldorf, Wuppertal and Essen in Germany as they all rescaled from intensity III to intensity II. Intensity IV occurs in all cells in an area of 30 km around the epicentre. Maximum CDIs are 4. 4 and 4. 1 in the cells 15 km south and 15 km north of the epicentre, respectively. Epicentral CDI is 3. 7. The ROB-BNS macroseismic distribution is underrepresented northwest of the epicentre in the Netherlands at a larger epicentral distance (Fig.
5 ) with respect to the other institutes. In the affected German area, NRW-GD grid cell intensities are systematically higher (on average a half unit but sometimes more than one unit) than the grid cell intensity of ROB-BNS. Grid cell intensity in Düsseldorf, for example, was rescaled after floor-level correction to CDI 2. 5 in the ROB-BNS database, whereas in the NRW-GD the intensity is CDI 3. 3. There are also many isolated grid cells, sometimes 100 km from the epicentre (e. g. Wuppertal, Dortmund; Fig. 4 ), that still show intensity IV although in the ROB-BNS database intensity III is assigned to these cells or they are even floor-level corrected to intensity II.
Overall, 259 people reported to the EMSC via the thumbnails and 274 via the questionnaires. Plotting individual thumbnail locations on a satellite map shows that the locations are often not geocoded for rooftop quality. Most re-sponses came from the Netherlands and Germany. Because of the low amount of data, dividing the affected area into grid cells results in a fragmented image of the affected area (Fig. 4 ). In the epicentral area, intensity IV is never reached in the results of the thumbnails. This contrasts with the clustered data of the EMSC obtained via the questionnaire, in which intensity V was assigned to the clusters of the epicentral area.