dataesr/scientific-paragraphs-categorization huggingface dataset:
For 62 features, the change led back to the previous version's name. This reflects a disagreement between contributors. • 202 subway stations had no name tag in the first version and the names were added over time. • 140 OSM subway stations changed name over two days (i. e. , 2008-05-14 and 2008-05-15). This case can be either due to an automatic process that has been run on OSM subway stations, or a contributor or contributors made all these changes over a couple of days, in order to standardize the dataset. • A similar case occurred in 2013 when 168 subway stations changed name during one day (i. e. , 2013-11-24). In this case, one hypothesis is that the new changes come from the transportation office, which released its data as open data in 2012.
• For 62 features, the change led back to the previous version's name. This reflects a disagreement between contributors. • 202 subway stations had no name tag in the first version and the names were added over time. • 140 OSM subway stations changed name over two days (i. e. , 2008-05-14 and 2008-05-15). This case can be either due to an automatic process that has been run on OSM subway stations, or a contributor or contributors made all these changes over a couple of days, in order to standardize the dataset. • A similar case occurred in 2013 when 168 subway stations changed name during one day (i. e. , 2013-11-24). In this case, one hypothesis is that the new changes come from the transportation office, which released its data as open data in 2012.
Lebeaupin The initial conditions for potential temperature and salinity are taken from the Medatlas  (MEDAR-Group, 2002). The freshwater inflow from rivers is prescribed by a climatology taken from the RivDis database  (Vörösmarty et al. , 1996)  with seasonal variations calibrated for each river by  Beuvier et al. (2010 ) based on Ludwig et al. (2009). In this context, the Black Sea is considered as a river for which climatological monthly values are calculated from a dataset of  Stanev and Peneva (2002). The water exchange with the Atlantic Ocean is parameterised using a buffer zone west of the Strait of Gibraltar with a thermohaline relaxation to the World Ocean Atlas data of  Levitus et al. (2005). Hordoir et al. (2013) ,  Dieterich et al. (2013)  and  Pham et al. (2014)  adapted the NEMO version 3.
These processes are activated optionally and are not considered in the present study. A full description of the model equations and input datasets is provided in  Oleson et al. (2010)  (for CLM4. 0) and  Oleson et al. (2013) (for CLM4. 5 ). An offline evaluation of CLM4. 0 surface fluxes and hydrology at the global scale is provided by  Lawrence et al. (2011). CLM is developed as part of the Community Earth System Model (CESM)  (Collins et al. , 2006; Dickinson et al. , 2006)  but it has been also coupled to other global (NorESM) or regional  (Steiner et al. , 2005 (Steiner et al. , , 2009;; Kumar et al. , 2008)  climate models. In particular, an earlier version of CLM (CLM3. 5) has been coupled to CCLM  (Davin et al. , 2011; Davin and Seneviratne, 2012 ) using a "sub-routine" approach for the coupling.
B5 VEG3D Figure  12  shows the flow diagram of VEG3D for the coupled system. In a first step the oas_veg3d_init subroutine is called in order to initialise the MPI communication for the coupling. Afterwards, the model set-up is specified by reading the VEG3D namelist and by loading external landuse and soil datasets. The definition of the grid and the coupling fields is done in oas_veg3d_define. The main program includes two time loops. In the first time loop vegetation parameters are calculated for every simulated day. In the second loop (over the model time steps) the coupling fields from CCLM are received via OASIS3-MCT in receive_fld_2cos at every coupling time step. Using these updated fields the energy balance of the canopy for the current time level t n is solved iteratively and based on this the latent and sensible heat fluxes are calculated.
To address the above challenges, we developed SWoTSuite by combining few existing tools  [1, 4] , which is a complete toolkit for developing end-to-end SWoT application. More specifically, the objectives of this work is as follows: • Providing automation at different phases of application development life-cycle. Our toolkit provides a set of high-level modeling languages to specify each development concern and abstracts the heterogeneity related complexity. It integrates code generation, task-mapping, and linking techniques. Code generation supports the application development phase by producing a programming framework that allows stakeholders to focus on the application logic, while our mapping and linking techniques together support the deployment phase by producing device-specific code to result in a distributed system collaboratively hosted by individual devices.
This layer consists of the following components to deduce new knowledge from IoT data provided by the Physical layer: -Semantic annotator. It takes data from IoT devices and converts sensors metadata in a unified description to provide further reasoning in order to overcome heterogeneity issues. The sensor metadata is semantically annotated according to the M3 taxonomy  [3]  that is an extension of W3C Semantic Sensor Network (SSN) ontology. -Persistent storage. It stores the M3 ontologies & datasets, M3 rules, pre-written M3 compatible SPARQL queries, and unified sensor data received from the annotator. SWoTSuite uses a triple store to keep M3 ontologies, M3 datasets, and sensor data. M3 rules and SPARQL queries are stored as files. -Knowledge manager. It reuses, combines, and updates domain-specific knowledge in the persistent storage.
We have been building datasets to reuse domain-specific knowledge (called as Linked Open Vocabularies for the Internet of Things (LOV4IoT)), which provides domain ontologies, datasets, and rules that could be reused to design crossdomain SWoT applications. -Reasoning engine. It infers new knowledge using a Jena inference engine and M3 rules that are extracted from LOV4IoT and redesigned to be compliant with the M3 taxonomy. -Query engine. The query engine is implemented using ARQ, a SPARQL processor for Jena. It loads the M3 ontologies & datasets, new knowledge derived using the reasoning engine, and executes SPARQL queries to provide suggestions. Application layer: creating new applications. It builds meaningful IoT application on top of suggestions provided by the virtualization layer. The interaction of this layer with Virtualization layer is optional.
More specifically, the application layer could be directly fuelled by the physical layer depends on application requirements. IoTSuite. IoTSuite  [1, 5]  creates necessary infrastructure that enables SWoT applications. It takes high-level specifications as input, parses them and generates code that can be deployed on IoT sensors (e. g. , temperature sensor, transportation devices) at the physical layer and IoT actuators (e. g. , heater) and user interface devices (e. g. , smart phone, dashboard) at the application layer. IoTSuite takes the following high-level specifications: (1) Domain includes specification of resources, which includes tags, sensors, actuators, and storage and third party web services. (2) Architecture consists of specification of computational services and interaction among them.
Application Scenario Consider a real world scenario, where Alice a smart home owner, has a complete home automation system installed in her house. The home automation system is capable of performing various daily tasks automatically such as controlling heating system, lights, and burglar alarm system. The home automation system is designed, developed and deployed using IoTSuite. Alice also owns a smart car, which is well equipped with modern sensing technologies and a smart car supporting software (developed using IoTSuite) is also available for communication among various sensors within car as well as with external sources of information. Both the home automation and smart car applications are performing their required tasks within the specified domain of each application. Now, consider a scenario, where both applications could leverage from data and information collected from each of these two applications as well external information sources.
Application Development using SWoTSuite Our SWoTSuite demo consists of the following steps: Step 1: Generating deployment ready packages for devices. This step of our demo is -how developers specify high-level specifications, compile them, and generate packages that can be deployed on devices at the physical layer and application layer. SWoTSuite provides an eclipse plugin 1  with an editor support to write these specifications. Figure  2  shows various editor features such as syntax coloring, error checking, auto completions, re-factoring, codefolding, and outline view. Step 2: Annotating sensor data. This step of our demonstration is to show annotation process. It takes sensor data from the physical layer and transforms it into a unified description such as RDF/XML. Listing 1 illustrates a code snippet of temperature measurement in senML format from a temperature sensor.
It shows sensed temperature value along with meta information such as unit of measurement, sensor name, and other information. Step 3: Generating an appropriate template. This step of our demo is -generating appropriate template files that are required to build a SWoT application. This step extracts information such as sensor name and its domain from the annotated RDF/XML data and generates template files. The template consists of ontologies, datasets, rules, and SPARQL queries that are required to build a SWoT application. Step 4: Executing reasoning engine. This step is to demonstrate the reasoning process of SWoTSuite. It deduces new knowledge from annotated IoT data using Linked Open  Rules available in the persistent storage. Listing 2 shows a rule example from the home-automation domain.
A rule is "if room temperature is less than 25 • C, then low temperature in the room". This rule deduces a condition based on the value from temperature sensor. Moreover, developers are guided through Java code in Eclipse IDE to load rules. Figure  4  illustrates a small code snippet to load the rules into Jena reasoning engine. 1 <senml bn="urn:thermometer:uuid:87e4fae-a8a6-79a-9 abe-011c5043481d"><en="temperature" t=" 1392815153153" u="Cel" v="67"/> 2 <e n="temperature" t="1411376379709" u="Cel" v="21"/ > 3 <e n="temperature" t="1411376392603" u="Cel" v="0"/> 4 </senml>  ?deduceUri m3:hasRecommendation ?suggestUri.
SenML/XML home temperature sensor data ?measurement rdf:type m3: RoomTemperature) Jena rule to deduce high level informationStep 5: Executing the query engine. This step is to show -how SWoTSuite generates suggestions. The query engine loads the M3 ontologies & datasets, annotated data generated at Step 2 and suggestions derived at Step 4 and SPARQL queries. Listing 3 illustrates the code snippet of a SPARQL query for the scenario in Section 3. 1. This query derives recommendations over M3 ontologies, domainspecific home automation and car datasets.
ACKNOWLEDGMENTS This work is partially funded by a bilateral research convention with ENGIE Research & Development, the  ANR   14-CE24-0029   OpenSensingCity  project  2  and institutional collaboration supported by the  Horizon   2020 Programme European project  " Federated Interoperable Semantic IoT/cloud Testbeds and Applications" (FIESTA-IoT ) from the  European Union  with the Grant Agreement No. CNECT-ICT-643943 ,  Science Foundation Ireland (SFI)  under grant No. SFI/12/RC/228 ,  EU   FP7 CityPulse Project  under grant No. 603095 3  and  French ANR  project DataTweet 4.
Listing 1 : 1 2 [LowTemperature: 3 ( 4 (Listing 2 : 11342 SenML/XML home temperature sensor data ?measurement rdf:type m3: RoomTemperature) Jena rule to deduce high level informationStep 5: Executing the query engine. This step is to show -how SWoTSuite generates suggestions. The query engine loads the M3 ontologies & datasets, annotated data generated at Step 2 and suggestions derived at Step 4 and SPARQL queries. Listing 3 illustrates the code snippet of a SPARQL query for the scenario in Section 3. 1. This query derives recommendations over M3 ontologies, domainspecific home automation and car datasets.
Semantic-based and cross-domain IoT/WoT Application Services Clients REST MQTT Tourism: Naturopathy: Transport: Weather & Safety Weather & Activities Healthcare & Weather & Food Weather & Smart Home Application Layer devices Generate Deployment ready packages for Actuators And User Interfaces Internet & Web Suggestions Web Services Domain Specification Query LOV4IoT Engine SPARQL Queries Ontologies Semantic IoT Data + Inferred Knowledge dataset Architecture Specification IoTSuite Rule-based Reasoning Engine Knowledge Manager Compiler Persistence Storage TripleStore Deducing New Deployment Specification Knowledge (Virtualization) SPARQL Queries Rules Semantic IoT data Ontologies DataSets User Interface Generate Specification Deployment ready packages for Sensing Semantic Annotator devices and IoT Gateways IoT Data IoT Data IoT Gateway IoT Gateway t 39°C fog lamp temp 102°F temperature 39°C Smart Home CoAP XMPP MQTT Devices Accessing Things Devices Transportation Weather Forecasting Devices Healthcare Devices (Physical).
"  2  Over the next thirty years, IBM and Busa created the Index Thomisticus project, the world's first sizable machine-readable corpus, containing, among an array of other related texts, an index verborum of all 118 works of Aquinas, totaling approximately 11 million words. 3 The project required an administrative and organizational staff that was unprecedented for a humanities research initiative at that time, as Aquinas's entire oeuvre had to be digitized onto punch cards (and later magnetic tapes), which were the primary data carriers in use in the middle of the twentieth century. Over the years, Busa would hire large numbers of young, local, female typists for this specialized task (see cover of this issue). Once, I was told by father Busa that he was used to choosing young women for punching cards on purpose, because they were more careful than men.
(We should remember that some libraries do not even allow visitors to inspect multiple physical items at the same time!) Institutions such as the Schoenberg Institute for Manuscript Studies lead the way in this respect, with its visionary director Will Noel being honored as a White House Champion of Change in 2013 for his commitment to open science. 18 xcellent examples of enriched digital libraries include the Online Froissart (where high-resolution facsimiles often are accompanied by transcriptions and historical information)  19  or Monasterium. net, a virtual archive that offers centralized access to over five hundred thousand primary diplomatic sources, such as charters, from more than one hundred European archives. 20 Equally representative is the database and interface supporting the DigiPal project, which won the Medieval Academy's first Digital Humanities Prize in the spring of 2017 (see the contribution to this supplement about this platform for the paleographic study of English manuscripts by the project's principal investigator, Peter A.
The Spatial Turn The strategic use of digital mapping is an offshoot of visualization, one that is often directed toward graphic analysis of location, ownership, and distribution within geographic boundaries. Data sets providing greater access to larger spatial data sets have enhanced research in this area. For example, Harvard's Digital Atlas of Roman and Medieval Civilizations (DARMC) app provides GIS maps and geodatabases that are openly available and searchable online. 40 The Digitized Medieval Manuscripts app (DMMapp) provides original map resources online, 41 while the Digital Mappaemundi allows for searching between medieval maps and textual sources. 42 eographic Information System (GIS) technologies provide ways to map and compare spatial data. 43 For example, GIS has been used to investigate the history of medieval rural and urban landscapes.
With electronic publication, supplying the primary data also means that future scholars will not need to go through a cumbersome and error-prone digitization process. The use of version-management platforms, such as GitHub (http://github. com), are helpful in this respect, because they allow scholars-and their peersto keep track of, comment on, and distinguish among versions of the work in real time. Thus prepublication feedback can be taken into account by scholars, and minor postpublication corrections need not wait until the next print edition to be integrated. The ease with which digital scholarly work in medieval studies can be modified over time makes it more fluid than print formats. Umberto Eco was but one among many contemporary thinkers to link the instability of modern electronic resources to the medieval transmission culture of texts.
S12 The Digital Middle Ages Speculum 92/S1 (October 2017) medium that struggles with the well-known phenomenon of "dead links" that naturally compromises the citability of sources. The citability of both scholarship and data sources is an obvious "teething issue" of DH and therefore an important concern in many projects. 58 And so is the durability: books are not copied and distributed as easily as digital files, but we have books that are still usable after centuries, while computer files can become unreadable in a decade as operating systems, storage formats, encodings, and application software go out of fashion. In many cases, the fragility of a digital edition lies not only in the data, but also in the application we use to interact with the data. For example, a digital concordance may have practical advantages over a paper one, but only as long as it is not locked into a hardware or software environment that has gone out of fashion.
Intellectual property rights, economic costs, and privacy issues also stand in the way of the naïve realization of the ambitious goal of a completely open medieval studies. 59 The entire Patrologia Latina, for instance, can today be found in digitized versions online. While the quality of such freely available texts is generally lowerthey abound in OCR errors-than what can be found in established subscription databases such as Brepols's Library of Latin Texts (http://www. brepolis. net/), it is an interesting, but also worrying, development that the mere "availability" of a particular text version is rapidly becoming a selection criterion that rivals the age-old importance attached to the criterion of quality. 60 Many digital humanities venues already require scholars to submit their source data together with their papers, which is impossible in the case of copyrighted editions.
These essays were later brought together and commented on in Franco Moretti, Distant Reading (London, 2013). 67 Relevant references for these terms include Matthew Jockers, Macroanalysis: Digital Methods and Literary History (Lincoln, 2013); Stephen Ramsay, Reading Machines: Toward an Algorithmic Criticism (Lincoln, 2011); Thomas Crombez, "Het onbehagen in de digitale cultuur: De opkomst van Digital Humanities," Meta: Het Vlaamse tijdschrift voor bibliotheek en archief 4 (2013): 8-13. 68 All software used for this exercise is made available on https://github. com/mikekestemont /panorama.
Because of the ambiguous nature of human language, such an automatic enrichment of the material will naturally yield many errors, especially in the case of the OCR-entered data with its unstable spellings, but it nevertheless already offers many possibilities for creatively querying the corpus. One interesting question might be which medieval dates have been most frequently mentioned in Speculum over the years. For this, we traced the cumulative frequency of all numbers in the data set that had been marked as a date in the named entity column and that fell in the "medieval" range of 500-1500. In the scatter plot in Fig. 2 , we plot the twenty-five dates with the highest cumulative frequency in the corpus as a function of their coefficient of variation over the documents in the corpus, to keep track of their dispersion over the material.
S33 Speculum 92/S1 (October 2017) post, "Who You Calling Untheoretical?," Jean Bauer quoted Susan Smulyan, who shouted on one occasion, "The database is the theory!"  82  While the presence of higher-level theoretical and methodological debates is not open to question, the relationship between traditional and nontraditional schools in medieval studies merits a closer look here. Scholars in digital humanities typically justify their existence through an active affiliation with older humanities disciplines 83 -in fact, one could say that it is primarily this affiliation that separates the digital humanities from computer science. In medieval studies, too, the link between traditional and digital practitioners is crucial if the medieval field is to advance as a whole. Importantly, this requires a mutual interest from both parties and a fundamental willingness to learn from one another, while not neglecting the rich tradition of medievalist scholarship.
Congurations and Transitions Let T be the set of instants t representing the execution time of the system where t 0 is the instant of the rst conguration. The XaaS conguration at instant t is denoted by c t and includes all running nodes (e. g. , PMs/VMs, Software Components, Databases, etc. ), organized in a DAG. CST R c t denotes the set of constraints of conguration c t. The property satisf y(cstr, t) is veried at t if and only if the constraint cstr ∈ CST R c t is met at instant t. The system is consistent (consistent(c t )), at instant t, if and only if ∀cstr ∈ CST R c t satisf y(cstr, t). Finally, function H(c t ) gives the score of conguration c at instant t, meaning that the higher this value, the better the conguration is (e. g. , in terms of balance between costs and revenues). We discretize the time T by the application of a transition function f on c t such that c t+1 = f (c t ).
e. , monitored from the running system); and the tier response time, which is calculated based on the workload attribute and the amount of resources allocated to each worker associated to the concerned Tier. More precisely, we dene the response time as a function of the amount of CPU and RAM currently allocated to the successor Worker nodes. • the type W orker represents a replicated component of a given tier (e. g. , application, database, etc. ). It has three attributes corresponding to the currently allocated CPU and RAM; and specifying precisely which tier the worker belongs to so as to avoid the constraint solver to link a worker to a dierent tier (e. g. , App-Worker1 to TierDB).
Experimental Testbed We implemented the Analysis component of the AM by using the Java-based constraint solver Choco  (Prud'homme et al. , 2014). The experimentation simulates the interaction with the real world, i. e. , the role of the components Monitor and Executor depicted in Figure  1. This simulation has been conducted on a single processor machine with an Intel Core i5-6200U CPU (2. 30GHz) and 6GB of RAM Memory running Linux 4. 4. We rely on the XML language to specify the initial conguration of our IaaS system. The snapshot of the running IaaS system conguration (the initial as well as the ones associated to each instant t ∈ T ) is stored in a le. At each simulated event, this le was modied to apply consequences of the event over the conguration. After each modication due to an event, we activated the AM to propagate the modication on the whole system and to ensure that the conguration meets all the imposed constraints.