dataesr/scientific-paragraphs-categorization huggingface dataset:
Managing the co-evolution of the DW requires identifying the source of changes and predicting the impact of changes at any design level. In this process, the usage of ontologies in DW design impacts all the design phases  [4]. The cited approaches used the ontology schema. Ontologies were first introduced in DW design to facilitate the process of integrating sources, by exploiting their sharing and descriptive characteristics  [5]. The use of ontologies was then extended to different design levels: they have been used for analyzing users' requirements  [6] , for facilitating the definition of DW schema  [7] [8] [9] [10] , for automating the ETL process  [11, 12] , and for documenting the integration process  [13]. Semantic databases, which are sources containing their own ontology schema and data, have been involved in DW design as candidate sources  [14].
(4) Include links to other URIs, so that they can discover more things. Linked data principles provide guidelines on how to use standardized Web technologies to set data-level links between data from different sources  [15]. Over the last three years, an increasing number of data providers have begun to adopt the linked data principles, creating a global data space containing billions of assertions about geographic locations, scientific publications, media, clinical trials, etc. [15]. We identify two main types of approaches that combine LOD and OLAP. The first category OLAP2LOD deals with multidimensional data published in the web as linked data, usually based on the RDF Data Cube vocabulary (QB) (https://www. w3. org/TR/vocab-data-cube/) recommendations. This category of approaches aims to achieve business analytics at the web scale, and different studies have been proposed to manage issues related to such analysis (e.
g. , query management and optimization issues)  [16, 17]. The second category of approaches follows a LOD2OLAP approach that manages the incorporation of LOD in the existing DW environment. Such approaches deal with the issue of opening the DW frontiers to external data like LOD. Our approach follows this second category. Two main solutions have been proposed for the co-habitation between LOD in the DW environment that can be made before or during querying. In before querying solutions, the cohabitation can be made at the schema level or at the ETL level. Concerning the first category, the consideration of LOD is proposed for several purposes, such as reparation of missing information in internal sources as done in  [18] , or the unification of cubes-the internal relational cube translated into RDF data, with RDF cube defined from the LOD as proposed in  [19].
The ETL process was not considered in both studies. The second category of approaches handle this issue like  [20]  which proposes an incremental fetching and storing of LOD and other external resources on-demand. An ETL process is defined to load external data. Motivated by the fact that some external sources have a limited time access, a process determines the set of extractions from external data that cover the missing information with a minimum cost. Deb Nath et al. [21]  propose a programmable semantic ETL framework focusing on the integration of external LOD datasets. Internal relational resources are then linked to external resources by calculating similarity measures. Kämpgen and Harth  [22]  propose an approach to interpret linked data as a multidimensional model and to automatically load the data into the DW.
This approach does not consider internal sources. In the studies presented, the DW is generally considered as operational, except in the work of  [23]  which proposes an approach to construct a DW from scratch, considering both internal and LOD sources using a common ETL process. In during querying solutions, we can cite the work of  [24] , which proposes an OLAP (on-line analytical processing) framework taking as inputs raw data from relational databases and semantic web data of different formats. A set of specialized OLAP operators is defined for use in queries. These operators can operate over multiple semantic sources and merge the outputs. Saad et al. [25]  formalize a multidimensional model in terms of RDF data structures following a conceptual constellation model. Conventional OLAP operations are then translated into SPARQL queries to fulfill the target requirements.
Kämpgen et al. [26]  define common OLAP operations on input linked data modeled using the QB (https://www. w3. org/TR/vocab-data-cube/) vocabulary. A set of OLAP queries are transformed into SPARQL queries to analyze the cube. Results are propagated to OLAP clients. The cited studies generally focus on specific design issues (multidimensional identification, LOD remote time access, LOD schema definition, ETL). These studies illustrate the variety of scenarios proposed for incorporating LOD sources. Contrary to internal sources, LOD sources can be integrated in the DW system at different steps of its design cycle (requirements, ETL, physical schema). This consolidates the solution of the co-evolution approach we are proposing in this paper, which considers the DW as an ecosystem composed of interrelated artifacts.
Romero et al. [40]  proposed to manage the evolution of a mediator integration system using ontologies as intermediary schema. Unlike DW systems, mediators do not manage ETL or the persistency of integrated data. Jovanovic et al. [41]  present a semi-automatic method for managing the evolution of events occurring on requirements. Their approach uses a domain ontology to automatically explore relationships between concepts. These studies do not consider semantic datasets (neither internal nor external sources), and no study considers the evolution of design artifacts and their correlations. Even if these studies use ontologies, they consider them as intermediate schema to unify the sources and the target DW.
For example, for LOD sources, the schema and instances are stored using the same graph-based representation. LOD representations are based on the RDF language (Resource Description Framework: https://www. w3. org/RDF/). RDF is a set of 4-tuple < s, o, p, g > forming an RDF quad, where its subject s has the property p, and the value of that property is the object o, and the graph label is g. Note that the graph label g can be omitted, in which case the triples are considered as part of the default graph of the RDF data-set. Examples of statements from our case study are: (Student#1, follows, Course#1), (Student#1, type, Student), (Student, subClassOf, Person). Note that DL formalism also captures the knowledge of conventional conceptual schemas of relational databases like Entity/Relationship (ER) or Unified Modeling Language (UML) class diagram  [46] , which makes our representation generic for conventional internal sources and external sources.
We followed a meta-modeling approach for the definition of this traceability model. The ontology meta-model (class OntologyResource) of the DW is connected to the traceability model as presented in Figure  3  (upper part). This figure is illustrated using Protege editor, where the ontology meta-model is extended with the traceability model described. The ontology illustrated in this figure is a fragment of Lehigh University BenchMark (LUBM) benchmark ontology that will be used in the case study section. The adoption of a meta-modeling approach is explained by the fact that traceability data are considered as meta-data. Additionally, this makes the approach independent of any particular modeling technique. Note that the DBMS may keep track of meta-data and some ETL tools also keep track of the ETL processes, but it is achieved at the physical level and is not centralized in a single model.
Evolution Management Approach Our general proposed approach is illustrated in Figure  4. The approach identifies the changes of LOD datasets and their impact on the DW constructs at different design levels. Two main types of changes are identified for LOD sources  [16, 49] : simple and complex changes. Simple changes (addition, deletion, and modification of triples) are meant to capture fine-grained evolution events. Complex changes are defined on top of simple changes to capture more coarse-grained changes (e. g. , schema changes, groupings of triple additions). Because it is unrealistic to capture all possible evolution types of complex changes that can be defined, simple changes can be considered as a "default" set of changes for describing evolution types  [49]. For each of the above events, the approach manages co-evolution by annotating DW constructs (DWO fragment) affected by the event and by applying the changes.
We propose a co-evolution management approach that follows these steps: 1. Parsing the input files: The LOD datasets that we analyzed and their different versions reflecting evolution events are available as ntriples files. Note that the files can be available in other formats serializing RDF data (e. g. , N3 and Turtle). Our approach first considers a parser that analyses the input files (i. e. , ntriple files of changes). The files concerning each type of change (add, delete, modify) are provided separately. The files can be visualized by the designer using Protege editor. In these files, the set of changes concerning the dataset and those concerning the schema are declared without distinction as triples. This first step of our approach aims to semantically define the set of changes by distinguishing the data from schema changes.
For example, the "add" file can include (American_Journal_of_Business, academicDiscipline, Business) as a triple of type instance addition and (publisher, type, Property) as a property addition. Because such triples are not intuitive enough for human designers, our approach parses the files in order to identify the concepts and all their instances that are concerned by the changes. This identification is achieved using a java script that reads the files using the OWL API (http://owlcs. github. io/owlapi/). The result of this parsing is a set of changes that belong to the space of potential events comprising the Cartesian product of two sub-spaces: the space of hypothetical actions (addition, deletion, and modification) over the space of resources of the LOD knowledge base (Concept, Role, and Instance).
The rule is formalized in Semantic Web Rule Language (SWRL) as follows: Source(?T1, ?X), Source(?T2, ?Y), Target(?T1, ?Y), Target(?T2, ?Z) -> Target(?T1,?Z). In this rule, Source(?T, ?X) (resp. Target(?T,?Y)) defines that a trace link T has design element X as source (resp. element Y as target). Source or target elements can be any TraceElement, that is, any instance of the meta-concepts extending the ontology meta-model as illustrated in Figure  3  (DWO concepts, requirement concepts, ETL concepts, etc. ). The algorithm relies on the results of an ontological reasoner (we used Pellet reasoner) to get inferred trace links. The impact of the evolution event is thus propagated to all design constructs of the concepts impacted by the change (Algorithm 1, lines 3-4). This final subset of a concept impacted by the change is consequently identified by including both its immediate and its transitive consumers.
If the event requires adding instances Inst, the approach first identifies the set of classes C, such as (Inst rdf:type C). The class is described in the input file if it is well-formed, otherwise it is possible to retrieve it from the SPARQL endpoint of the LOD dataset. Then, the same process as described previously is achieved: the ETL processes involved, the set of classes of DWO, and the set of requirements concerned by the change are identified as traces. The ETL processes identified are re-executed to load the new instances. Modification events may concern the schema level (concepts and role) or the instance level. The modification of concepts and roles requires the identification of traces concerning the ETL processes, the set of DWO concepts, and the set of requirements. The concept/role modified is updated in these traces.
(iii) Event in ETL processes: An evolution event in the ETL process may concern any ETL activity (input, output, or ETL operator) performed by the designer. All types of events require the re-execution of the new/modified ETL process. This can be achieved in two ways: (i) the re-execution of the ETL process concerned. Each ETL scenario is coded as PL\SQL stored procedures in the DBMS (Oracle in our case). (ii) The use of the Protege Plugin for Oracle Database (https://protegewiki. stanford. edu/ wiki/Protege_4_Plugin_for_Oracle_Database), which provides the ability to view, edit, and save ontologies in Oracle Database with Protege Desktop (Figure  5 ). This approach can be more suitable, as it provides a visualization tool associated to traces. Note that this option may not be available for all semantic DBMSs, which do not provide plugins for ontology editors.
dbpedia. org/), Yago (https://www. mpi-inf. mpg. de/departments/databases-and-information-systems/research/ yago-naga/yago/), Scholarlydata (http://www. scholarlydata. org/dumps/), and Thomson Reuters (https://permid. org/download) LOD. We used the 14 queries of LUBM to express requirements. We defined ETL processes for each DW concept from an internal source and from at least one LOD source. The LOD datasets are usually available as ntriples files. DBpedia extracts structured information from Wikipedia, interlinks it with other LOD, and freely publishes the results on the Web using Linked Data and SPARQL. DBpedia release processes are heavy-weight, and releases are sometimes based on data that are several months old. DBpedia-Live solves this problem by providing a live synchronization method based on the update stream of Wikipedia.
The set of changes are provided as ntriples files (http://live. dbpedia. org/changesets/) that we considered as input files to test our approach. We considered 60 files (20 files for addition events, 20 for deletion, and 20 files for modification events) chosen so that they included concepts defined in Univ-Bench ontology. The distribution of events in these files is almost 80% events related to instances and 20% related to schema changes. In order to balance the set of events, we considered Bdpedia and other LOD (Yago, Scholarlydata and Thomson Reuters) by downloading datasets (ntriples) related to the University domain (e. g. , Author, AcademicJournal, AcademicPress, ResearchProject, Book) matching with Univ-Bench conceptualization, that we considered as triples randomly concerned by the three types of events (addition/deletion/modification).
For instance, we considered the AcademicPress concept and its instances, downloaded from Yago LOD as a new concept enriching the hierarchy of Organization concept of Univ-Bench ontology (schema addition event). All the steps of our approach were implemented in a Java script that uses OWL API for interacting with the ontology and the LOD. We implemented this minimal prototype only for defining the input sources and running the propagating and evolution algorithms. We used Protege editor to visualize the DWO and Oracle Database Management System (RDF Semantic Graph 12c version (https://docs. oracle. com/database/121/RDFRM/title. htm)) to implement the DW (Figure  7 ). The first experiment shows the amount of triples (inserted, deleted, or modified) in the DW after applying the approach for change management.
Conclusions Building a DW with internal and external data published in LOD formats requires managing the evolution of DWs that deal with "open world" sources and their specific characteristics. We proposed and implemented a co-evolution management approach that identifies the impact of changes semantically, for all design stages of the DW. Our approach relies on a coherent maintenance of traces. The goal of the approach is to provide a complete and semantic view of the real impact of the evolution event on the DW. Our approach was tested using different LOD, LUBM benchmark, Protege editor to visualize the impact of changes, and Oracle semantic DBMS to implement the DW. Our future research will include: (i) automatic detection of the most relevant changes in LOD that can be synchronously triggered in the DW.
Acknowledgments: This research work was carried out thanks to the support of the  European Union  through the  PLAIBDE (Plateforme Intégrée Big-Data pour les Données Entreprise ) project of the  Program FEDER-FSE  (http://www. europe-en-poitou-charentes. eu/Les-projets-soutenus-en-Poitou-Charentes/Travaux-derecherche-pour-la-creation-d-une-Plateforme-integree-Big-Data-pour-les-donnees-entreprise-PLAIBDE-PC470) of Nouvelle Aquitaine region. The FEDER- PLAIBDE  project is directed by the lead manager of aYaline (https://www. ayaline. com/)company, and the laboratories partners: L3i (http://l3i. univ-larochelle. fr /)laboratory of La Rochelle University (France)  and  LIAS laboratory of ENSMA (France).
Acknowledgments. We would like to thank  Anupam Gupta  for several useful examples and enlightening discussions. We would like to thank  Jochen Könemann  for pointing out a connection between the alternating stock size problem and the optimization version of the gasoline puzzle. We would also like to thank  Tamás Kis  for pointing out related papers on scheduling problems. Part of this work was done during the trimester program on Combinatorial Optimization at the  Hausdorff Institute for Mathematics in Bonn  and we would like to thank  HIM  for their organization and hospitality during the program.
, 2016). For sites with sea walls a centrally positioned transect perpendicular to each defence section is chosen to simulate the flood hazard for each of the different defence designs  (Prime et al. , 2015a). An example set-up is shown in Fig. 2 , where the sea wall provides protection to the local community behind. For sites where the 1DH models have been used to incorporate wave impact the wave direction is always assumed to be directly onshore to generate the worst case scenario. Where observations are limited to within the last decade (e. g. , wave monitoring) or where only waves or water levels are monitored, archived data from climate modelling systems can be utilized to lengthen the datasets. The longer the data record the greater the confidence in the extreme value analysis. This research has used the European Centre for Medium-Range Weather Forecasts (ECMWF) 30-year wave ECWAM cycle 41R1 model data to lengthen the wave records.
These numerical data are validated against existing wave observations prior to use in the analysis. For the UK energy sector, events ranging from typical (1:1 year return period) to extreme (1:10,000 year return period) conditions are considered. The joint probability analysis is performed using JOIN-SEA  (Hawkes and Gouldby, 1998). This software uses the generalised Pareto distribution (GPD) model and simultaneous records of significant wave height (H s ) and water level (WL) at the time of the observed high water. In most cases the combined observational record covered a period of the order of a decade, the limitation often being related to the deployment of the wave buoy. For each return level a range of wave-water level conditions are generated. These cover conditions that transition from lower WL and higher H s to higher WL and lower H s.
The conditions that pose greatest flood hazard along the probability curves are selected from an ensemble of 1DH storm impact simulations that generate a range of inflow conditions to impose into LISFLOOD-FP  (Prime et al. , 2016). This generates the database of flood maps behind the DST. In this respect, the DST operates as a look-up table. Once the required wave-water level combination has been ascertained a storm tide is created to force the offshore model boundary. The storm tide comprises a spring tide and a surge curve, available for all UK Class A tide gauge locations from the EA  (McMillan et al. , 2011). The surge curve is used to scale the tide such that the total high WL reaches the required extreme value. The time-varying water levels are combined with the required wave conditions within the 1DH storm impact model.
Although the H s is kept constant, a JONSWAP (Joint North Sea Wave Observation Project) spectrum is applied to create a time-varying wave field. This approach represents the worst-case scenario as the wave conditions maintain the desired extreme value for the duration of the simulation, a complete tidal cycle. An appropriate peak wave period (T p ) is selected from the wave data for each H s. At many sites around the UK there is a bimodal wave climate related to the wind sea and swell wave components. For each wave condition the longest T p associated with each H s is used to simulate the highest wave runup levels. Future sea-level projections are incorporated into the still water level of each event to take into consideration sea-level rise and explore future change in the inundation hazard.
Surveys Storm surveys over a tidal cycle were used to assess the response of different coastal systems and identify features that make them resilient or resistant to storm impact. During an event pre-, during and post-storm topographic data were collected (using a dGPS on a staff pole at low tide) alongside in-situ measurements and remote sensing observations. The in-situ instruments (e. g. , Fig. 3 ) were deployed pre-storm and retrieved after the storm. These included two low water scaffold rigs with pressure transducers and current meters together with five scaffold tubes with pressure transducers deployed alongshore at equal spacing (< 1 km) on the intertidal terrace. These instruments recorded the wave and tide elevations and the current velocities during the storm. Remote sensing techniques included a tower with two video cameras and a second tower with a laser-scanner.
This system continuously monitors beach topography within a few kilometres of the radar for the entire duration of the deployment, which can then potentially update intertidal bathymetry and waterline levels in near real-time. Study sites are shown in Fig. 4. A previous application to the Dee estuary, northwest England, has demonstrated the capability of the radar to monitor complex geomorphological environments  (Bird et al. , 2017b). The tidal range in this estuary is in excess of 10 m on high spring tides. The morphology is very complex and includes large areas of intertidal sandflats, subtidal channels, mud banks, saltmarshes and rock outcrops. Using a 2. 5 m radar antenna intertidal topography was derived with a 3 m spatial resolution over a 4 km range from the radar. Comparison with LiDAR showed radar-based system was able to derive the major features of the topography including complex channels and bedforms with a vertical accuracy of +/-20 cm (although limitations with the LiDAR data should also be acknowledged in any error analysis)  (Bell et al.
, 2016). This surveying system therefore provides advanced warning of adverse morphological change, volumetric information on sediment movements (especially useful for monitoring beach nourishment schemes or identifying erosion hotspots), bedform migration and broad-scale indications of a beach system health. Following the development of this rapidly deployable remote-sensing survey platform (Rapidar), planned winter deployments at sites of critical energy infrastructure (2017-18 for Minsmere, E coast UK, and 2018-19 for Dungeness, SE coast UK) will collect data to assess longer-term resilience of these sites. These will also be complemented by additional storm surveys to assess the response of these coastal systems to a winter season. This will help to identify and assess the role of shoreline response and morphological evolution within flood hazard assessments, enabling better understanding of some of the uncertainty surrounding modelled flood maps.
Acknowledgements This research was funded through the  ESPRC-funded ARCC   ARCoES  project ( EPSRC EP/I035390/1 ),  NERC -funded project " Sandscaping for Mitigating Coastal Flood and Erosion Risk to Energy Infrastructure on Gravel Shorelines: a case study approach " ( NE/M008061/1 ), and the  EPSRC IAA  ( Impact Acceleration Account) scheme , which funded the project ' Use of Sandscaping.