dataesr/scientific-paragraphs-categorization huggingface dataset:
Related work on Semantic Sensor Web Several research efforts have addressed the bridge between linked (sensor) data and the Sensor Web. We will now describe some of these works briefly. Patni et al. [9]  present a framework for publishing the sensor data on the Linked Open Data Cloud. The proposed framework converts raw sensor observations to RDF and links with other datasets on the LOD. Le Phuoc et al. [10]  describe SensorMasher, an infrastructure that makes sensor available following the linked open data principles and enables the integration of such data into mashups. SensorMasher allows users to semantically describe raw sensor readings, then the descriptions can be exploited in mashups. Page et al. [8]  present a prototype API for exposing data from Channel Coastal Observatory in the UK.
AEMET Data Sources Among all of the data made available in the FTP server from AEMET, we have focused on surface meteorological observing stations, and more precisely in measurements taken in ten minute interval times  2. The data are recorded in several points in the Spanish geography and can be represented as a set of variables, for observaciones_diezminutales/ instance temperature or pressure, on points in a map. A full description of the variables considered is included as part of the ontology used  3. These stations belong to the Regional Basic Synoptic Network (RBSN) in Spain operated by AEMET, in accordance with the World Meteorological Organization 4  (WMO). The stations are globally identified by a code and have to accomplish strict quality controls. Their data are used to feed meteorological models and to draw up climate studies.
AEMET has around 250 automatic weather stations of this network, registering pressure, temperature, humidity, precipitation and wind data every 10 minutes. Data from the different stations are provided in CSV files, compressed with gzip, updated every hour and kept for seven days. This means, every hour six new files are added, corresponding with periods of ten minutes, and every day a new folder is created to store the files for that day. AEMET data are stored in comma separated values and are available online for public download and reuse. The name of each file in this site follows the naming convention "yyyymmddhhmm_datos. csv". This allows processing directly a set of specific files without parsing (or even downloading) all of them just to check which files are relevant for a specific time range.
For example, the filename "201102121900 _datos. csv" means the data are from the year 2011, the month of February, on the day 12 at 19:00h. When looking inside the files we can see some data about the stations, as the position or ID, with one row for each station. In the same row we find data for the observations of a specific station, having each column the ID of the observation type and the value recorded.
TBox URIs As mentioned before, the base URI scheme for TBox elements is http://aemet. linkeddata. es/ontology/, to which the concept local name or local ID is appended. In order to assign names to the different elements, two kind of elements have been diferentiated: classes and properties, including both OWL object and datatype properties. The naming of each kind of element abide by different conventions: -Classes: The camel case style has been followed starting with upper case, using English names. -Properties: The camel case style has been followed starting with lower case, using English names. Class and property labels have been added in two different languages (Spanish and English). The main motivation behind this decision is that such natural language descriptions associated to ontologies have proven to be of major importance, not only to ontology users but also to assist in tasks such as ontology mapping, information extraction, ontology verbalization and, even more relevant to the goal of the AEMET Linked Data initiative, in the development of Linked Data applications.
ABox URIs If the aim of the presented work and its associated data is to provide a meaningful set of interconnected assertions and relationships, special attention must be paid to the unique identification of such sets of assertions. In other words, it is important to carefully assign identifiers (URIs) to the resources within the generated dataset and to ensure that every distinct real-world object gets its "unique" URI. The rationale behind this is to mitigate issues such as co-reference, described in  [7]  as "the problem of ensuring that two different entities do not share the same identifier, and conversely identifying when two identifiers refer to the same entity" or the instance unification problem described in  [4]  and analysed in  [1]. In this sense, throughout the development of the present work a series of decisions have been made in order to preserve the integrity and semantics of the data.
The first decision regarding ABox URIs was to use Patterned URIs 9 , as described in "Linked Data Patterns". Such solution, by adding the class name to the base URI, mitigates co-reference problems between two distinct individuals of different type and same local ID, while enabling URIs to be algorithmically constructed in consumer applications, by following a simple and clear pattern. The second decision was to use Natural keys 10 whenever the source data allowed to, or in other words when the source group of resources already had a unique identifier. This is the case of the synoptic weather stations and their unique identifier: INDSINOP. The usage of the aforementioned patterns also facilitates the linking process to and from other datasets in the LOD cloud as the URIs structure they provide helps disambiguation and separation of resource classes, making easier for data users and engineers to make statements about the resources having some sort of certainty about the resources identities.
RDF Generation RDF has been generated with ad hoc Python scripts. These scripts are executed in two processing steps, integrating with ease the generation of RDF and tasks as crawling the FTP server where the CSV files are located. The generated RDF is stored in Virtuoso  11  , which integrates with Pubby 12  for the publication of the results and makes them available for humans as well as computers. Both processing steps are described below. The first step generates the information about the automatic stations, which is static, and thus needs to be executed only once. Even if the script is executed just once, developing a script to generate this information takes shorter than doing it manually. The number of stations is 784 and the time required to develop the script less than one hour. Having a script does also provide a better maintainability for future changes than manually generating the RDF, which is something usual in an evolutionary prototype context.
The second step generates the information about the observations on a regular basis, keeping the data updated. The observations are obtained by crawling the FTP server from AEMET. When new files are added or old files are modified, these are downloaded and processed. The process is very similar to the previous script and as far as has been observed it may be generalizable when using plain text files to generate RDF. Both steps use templates that contain the RDF to be generated, in this case expressed using the N3 notation. The fields of these templates are obtained from the files processed and the instantiated templates are written to the RDF files. The main limitation of the approach is that there is no validation for the templates, thus may not be a convenient solution for those not accustomed to coding in computer languages.
Related Ontologies for modeling Weather and Phenomena In order to reuse existing ontologies, we have searched for ontologies in the domain of meteorology using two popular ontology-oriented Semantic Search Engines (SSE), Watson  13  and Swoogle 14. Our search has been based on the following three functional requirements: (i) Language (the ontology should be in English or Spanish), (ii) interoperability (the ontology should be implemented in a Semantic Web language (OWL or RDF(S))) and (iii) usability (the ontology should be easy to analyse and reuse). The search operation has been performed using the following set of keywords, considering the structure of the AEMET dataset : weather -forecast -temperature -phenomena -pressure -wind -stations location and visibility. -Weather ontology (WO) 15  In Table  2  the URIs of the relevant ontologies obtained after the searching operation are listed.
Exploitation The potential uses and exploitation triggered by the availability of the dataset online have been studied by the group, analyzing how it could be useful for different kinds of users in the Web. This section describes how the observations can be retrieved and filtered through SPARQL queries to the endpoint, that otherwise would require users to spend much time regarding downloading and processing the public files in AEMET's home page. It also describes the resulting application using those queries, designed for browsing and visualizing the contents of the dataset.
The geographical information allows to associate the information with the specific point in the map where it should be displayed, while the temporal dimension allows creating graphics with the evolution of that specific value during a period of time. More specific visualizations could be used, as colorings for the map or iso-lines are innumerable. The approach taken takes very few assumptions on data and is hence more general while keeping maintainability, being possible to add new visualizations for different types of data. However, the true potential for the published dataset shows off when combining it with other available datasets in Linked Data. The first potential use is with the geolinkeddata dataset  [5]  with all the geospatial information that it contains (ranging from airports or rivers to villages and provinces).
As an example, the next query would retrieve all the stations located in a province along with their label: select * where { SERVICE<http://aemet. linkeddata. es/sparql> { ?s <http://aemet. linkeddata. es/ontology/isLocatedIn> ?provincia } SERVICE<http://geo. linkeddata. es/sparql>{ ?provincia <http://www. w3. org/2000/01/rdf-schema#label> ?label. ?provincia <http://www. w3. org/1999/02/22-rdf-syntaxns#type> <http://geo. linkeddata. es/ontology/Provincia> } } The query could be modified easily to provide the measurements from the weather stations close to a lake, river, beach, etc. This is one of the main advantages of Linked Data. The integration with other datasets, thanks to the semantics provided by the links, is to some extent automatic. Reusing the data is easier as well, as compared with other formats, which should offer equivalent semantics and have a purpose as general as Linked Data to provide the same advantages in such a broad domain.
Conclusions In this paper we have presented the process followed to transform some of the public meteorological data from AEMET resources into Linked Data. To do so, we have reused ontologies like the time ontology and the SSN ontology, which are widely used in other sys-tems, and we have shown how to retrieve the data, create and update the triples automatically, and show the data in a generic visualizer that considers the geoposition of that data. This process has followed an agile approach, and it could be easily adapted to other datasets with similar data, like sensor networks, or in other domains, as far as the focus is set on the geographical component of the data. This is because the assumptions made on the properties of the data presented are very few, as are the assumptions regarding the source format.
For the former, the spatial nature of the data allows the map visualization, and the temporal nature of it allows to show the evolution through time graphically. For the latter, anything that can be parsed in a similar way to a. csv file can be processed similarly, since the scripts have been built to be generalizable. Finding the right spot between automation and freedom is still an open line of research. The advantages for the regular user may not be obvious, as it is the development time invested to reach results that may look similar, but by using semantic technologies and well established standards the development time is reduced, and the products obtained are more easily maintainable and reusable. Other systems can consume this data and offer visualizations, aggregations, reason over it, etc.
Once the data has been extracted and is offered as Linked Data, applications that use Linked Data can instantly benefit from it. Besides, it allows using the data instantly without having to browse, download and read all the. csvs published daily by AEMET, providing a much more convenient access to the same information. Moreover, the advantages of publishing the dataset as linked data allows modularity and reusability, for example less time would be required for the development of applications based on this data (as we have already shown with the visualizer). Finally, the ontology we used to model the data can be aligned with other ontologies (time, ssn, etc. ). By complying with well established standards interoperability is enhanced, for instance within other sensor networks and applications using these ontologies, and the linking in other domains, such as medical, geographical, biological, etc.
Observations and data reduction The star δ Scorpii was observed in June 2012 during two half-nights with the VLTI 1. 6m auxiliary telescopes (AT) using the AMBER beam recombiner  (Petrov et al. 2007 ). The observations were carried out using high spectral resolution mode (R=12000) centered on either Brγ or He i (2. 06 µm) for each of the two half-nights. In order to enhance the signalover-noise ratio (S/N) by enabling longer exposure time, the fringe tracker FINITO was also used. The star HD 139663 (D = 2. 133 ± 0. 147 mas,  Lafrasse et al. 2010 ) was used as an interferometric calibrator. The data were reduced using the standard AMBER data reduction software amdlib v3. 0. 3b1 (see  Tatulli et al. 2007 and Chelli et al. 2009  for detailed information on the AMBER data reduction). The average-raw complex visibility and closure phase was determined using the standard method, i.
Qualitative comparison of the 2010 and 2012 data The Brγ and He i absolute visibility show a strong variability with an amplitude of about 0. 2. Assuming that the binary separation at the epoch of the observations should be 90. 8 mas with a position angle (PA) of 156. 08 o , according to Paper I orbital parameters, these variations are compatible both in terms of amplitude and frequency with the binary modulation. However, the accuracy of the absolute visibility of VLTI/AMBER data taken in HR mode is not sufficient to significantly refine the orbital parameters. The differential visibilities and phases, closure phase, and line profile from the 2010 Brγ observation are plotted in Fig. 2. In the same figure, one single Brγ 2012 observation with similar projected baselines is overplotted. The full 2012 dataset for Brγ and He i emission lines is presented in Fig.
(2012) , the major modifications occurred near the periastron. Thus, the observed asymmetry cannot originate from a one-arm oscillation as proposed by  Okazaki (1997) , but must stem from tidal effects induced by δ Scorpii's companion. However, according to available spectroscopic data and our 2012 observations, the disk asymmetry seems to be "frozen" since the periastron. Finally, long-term spectroscopic and interferometric follow-up are needed to understand both the nature of the inhomogeneity after the periastron and its link with the tidal effects of the companion. Brγ differential visibilities differential phases, and closure phases He I differential visibilities differential phases, and closure phases Fig. 3. The full dataset for δ Sorpii 2012 VLTI/AMBER observations. The red lines represents the VLTI/AMBER data, and the green ones, the best-fit symetric kinematic model.
Acknowledgements. The  Programme National de Physique Stellaire (PNPS)  and the  Institut National en Sciences de l'Univers (INSU)  are acknowledged for their financial supports. A. Meilland acknowledge financial support from the  University of Western Ontario. The authors would like to thank  ESO  staff for their help to make the observations a success and more particularly  J-B Lebouquin  and  F. Rantakyro.
Conclusion The polynomial derivation height that we have proved in the last section can be reconsidered in the following way. The example of a GRS working in O(n k ) can be used as a clock. Then, since each transition of a (non-size increasing) Turing-Machine can be easily simulated by graph rewriting, we can state that any PTIME-predicate can be simulated by a lexicographically weighted GRS (up to a polynomial reduction). Since lexicographically weighted confluent GRS can be computed in polynomial time (each rewriting step can be simulated in linear time), it becomes clear that lexicographically weighted GRSs actually characterize PTIME. This provides a precise description of the computational content of the method. We have implemented a software -called GREW (grew. loria. fr)-based on the Graph Rewriting definition presented in this article.
Background: Many models have been proposed to detect copy number alterations in chromosomal copy number profiles, but it is usually not obvious to decide which is most effective for a given data set. Furthermore, most methods have a smoothing parameter that determines the number of breakpoints and must be chosen using various heuristics. Results: We present three contributions for copy number profile smoothing model selection. First, we propose to select the model and degree of smoothness that maximizes agreement with visual breakpoint region annotations. Second, we develop cross-validation procedures to estimate the error of the trained models. Third, we apply these methods to compare 17 smoothing models on a new database of 575 annotated neuroblastoma copy number profiles, which we make available as a public benchmark for testing new algorithms.
In contrast, this paper takes the opposite view and assumes that the expert interpretation of the biologist is the gold standard which a model should attain. The first contribution of this paper is a smoothing model training protocol based on this assumption. In practice, visualization tools such as VAMP are used to plot the normalized microarray signals against genomic position for interpretation by an expert biologist looking for CNAs  [16]. Then the biologist plots a model and varies its smoothness parameter, until the model seems to capture all the visible breakpoints the data. In this article, we make this model training protocol concrete by using an annotation database to encode the expert's interpretation. The particular type of annotations that we propose are counts of breakpoints in genomic regions.
By visual inspection of the noisy signal, it is not obvious to locate the exact location of a breakpoint, but it is easy to determine whether or not a region contains a breakpoint. So rather than defining annotations in terms of precise breakpoint locations, we instead define them in terms of regions. For every region, we record the number of breakpoints that an expert expects in that region. These annotated regions can then be used to select an appropriate model, as shown in Figures  1  and 2. We note that using databases of visual annotations is not a new idea, and has been used successfully for object recognition in photos and cell phenotype recognition in microscopy  [17, 18]. In array CGH analysis, some models can incorporate prior knowledge of locations of CNAs  [19] , but no models have been specifically designed to exploit visual breakpoint annotations.
Our second contribution is a protocol to estimate the breakpoint detection ability of the trained smoothing models on real data. In the Methods section, we propose to estimate the false positive and false negative rates of the trained models using cross-validation. This provides a quantitative criterion for deciding which smoothing algorithms are appropriate breakpoint detectors for which data. The third contribution of this paper is a systematic, quantitative comparison of the accuracy of 17 common smoothing algorithms on a new database of 575 annotated neuroblastoma copy number profiles, which we give in the Results section. There are several publications which attempt to assess the accuracy of smoothing algorithms, and these methods fall into 2 categories: simulations and low-throughput experiments.
sd. For the local models trained on single profiles, many smoothing parameters attain the minimum. So we use the protocol described in the "Selecting the optimal degree of smoothness" section to select the best value, shown as a black dot. different number of breakpoints in each copy number profile. To summarize, this article describes a quantitative method for DNA copy number profile smoothing model selection. First, an expert examines scatterplots of the data, and encodes her interpretation of the breakpoint locations in a database of annotated regions. To repeat, the annotations represent an expert's interpretation, not the biological truth in the tumor samples, which is unknown. We treat the annotated regions as a gold standard, and compare them to the breakpoints detected by 17 existing models.
Results and discussion The 17 smoothing models described in the Algorithms section were applied to 575 neuroblastoma copy number profiles, described in the Data section. After fitting the models, we used breakpoint annotations to quantify the accuracy of each model. We constructed 2 annotation databases based on 2 different experts' interpretations of the same 575 profiles (Table  1 ). The "original" annotations were created by typing 0 or 1 in a 6-column spreadsheet after systematic inspection of the same 6 regions on each profile. The "detailed" annotations were constructed by using GUIs which allow zooming and direct annotation on the plotted profiles. The 2 annotation data sets are mostly consistent, but the detailed annotations provide more precise breakpoint locations (Figure  3 ). For both annotation databases, we calculated the global and local error curves E global (λ) and E local i (λ), which quantify how many breakpoint annotations disagree with the model breakpoints.
Among global models, cghseg. k and pelt. n exhibit the smallest training error The global model is defined as the smoothness parameter λ that minimizes the global error E global (λ), which is the total number of incorrect annotations over all profiles. Training error curves for cghseg. k, pelt. n, flsa. norm, and dnacopy. sd are shown in Figure  2. An ideal global model For the two annotation data sets (columns), we show the annotation protocol, counts of annotated profiles and chromosomes, and counts of annotations. would have zero annotation error E global ( λ) = 0 for some smoothness parameter λ. However, none of the global models that we examined achieved zero training error in either of the two annotation databases. The best global models were the equivalent cghseg. k and pelt. n models, which achieved the minimum error of 2.
Among local models, cghseg. k and pelt. n exhibit the smallest training error Since there is no global model that agrees with all of the annotations in either database, we fit local models with profile-specific smoothness parameters λi. For every profile i, the local model is defined as the smoothness parameter λi that minimizes the local error E local i (λ), the number of incorrect annotations on profile i. As shown in Figure  2 , the local model fits the annotations at least as well as the global model: E local i ( λi ) ≤ E local i ( λ). However, the local model does not necessarily attain zero error. For example, Figure  2  shows that dnacopy. sd does not detect a breakpoint in profile i = 362 even at the smallest parameter value, corresponding to the model with the most breakpoints.