dataesr/scientific-paragraphs-categorization huggingface dataset:
ACKNOWLEDGMENTS We thank the anonymous reviewers for the insightful comments that helped improving this paper. Experiments presented in this paper were carried out using the Grid'5000 testbed, supported by a scientific interest group hosted by Inria and including  CNRS ,  RENATER  and several Universities as well as other organizations (see https://www. grid5000. fr). The presented work was developed within the  EEXCESS  project funded by the  EU   Seventh Framework Program , grant agreement number  600601.
Currently, vast amounts of geospatial information are offered through OGC's services. However this information has limited formal semantics. The most common method to search for a dataset consists in matching keywords to metadata elements. By adding semantics to available descriptions we could use modern inference and reasoning mechanisms currently available in the Semantic Web. In this paper we present a novel architecture currently in development in which we use state of the art triplestores as the backend of a CSW service. In our approach, each metadata record is considered an instance of a given class in a domain ontology. Our architecture also adds a spatial dataset of features with toponym values. These additions allow us to provide advance searches based on 1) Instance to class matching, 2) Class to class subsuming relationships, 3) Spatial relationships resulting from comparing the bounding box of a metadata record with our toponym spatial dataset.
The Spatial Data Infrastructure has a service oriented architecture. In such infrastructure, functionalities such as storage and data search are carried out through Web services. The typical work flow involves: 1) The discovery of a data source, 2) The download of relevant geo spatial data, 3) The use of appropriate analytical methods and 4) The visualization of the results on a suitable map. In order to integrate our work with the SDI we need to find and retrieve pertinent online datasets. OGC has introduced a standard for catalogue services called CSW. A server implementing this standard has access to a metadata repository. It allows the search of spatial data or web services using open criteria (i. e. free text as a search in a search engine) or using more specific criteria (title, coordinate system, data type, etc.
). Servers implementing CSW are also able to: synchronize their content with other catalogues, add, modify or delete metadata records. They are also able to harvest metadata from other OGC services  [4]. Like other OGC standards CSW implements OWS Common, which describes basic features shared by all of them. These common elements are basic parameters and data structures used in the request or response from web service operations. The standardization proposed through OWS Common serves as support for the interoperability of OGC web services  [5]. Our broad goal is to implement smart queries using data repositories available in the SDI. The use of the different services involved in a SDI raise several semantic challenges. Most semantic problems arise due to the lack of significant content descriptions.
As a consequence the resulting ambiguities are then propagated throughout the process of data  [6]. The discovery of datasets is currently done though OGC CSW. However the search of records is done using a string matching process, not considering the semantics of the metadata information  [7]. Greatly improved results would be obtained if catalogue services are able to use the hierarchical relationships between elements and concepts achieving in this way semantic interoperability  [8]. Fortunately, nowadays there are tools in the field of semantic web, like Sesame, Jena, SPARQL/GeoSPARQL and diverse triplestores, that offer storage, query and retrieval capabilities of information with semantic annotations. In this paper we present our work on the storage and retrieval of metadata records using a triplestore.
Related Research Catalogues are a core component of the Spatial Data Infrastructure. The most used catalogue specification is the one proposed by the OGC: CSW. A service implementing CSW handles descriptions of datasets and services, formatted as ISO 19115:2003. The descriptions include information regarding the extent, quality, spatial and temporal characteristics as well as the distribution rights of a given dataset. A CSW service handles its requests and responses using the HTTP protocol using the GET and POST method  [8]. Previous researchers have identified limitations on traditional CSW services. The string matching process as the only query option is mentioned in  [9]  [7] and  [8]. In these works authors explore options to add semantic capabilities to CSW overcoming this limitation.
In  [8]  the author describes the CSW limitations by evaluating GeoNetwork, a popular open source CSW implementation. The author identifies three ways in which it is possible to add semantic annotations to the CSW: 1) By associating keywords to concepts using the getCapabilities response. 2) By adding a link in the GeoNetwork client interface to a ontology browser. In this way the user instead of using keywords, would be able to utilize the hierarchical structure to identify the topic that best suits her interest. 3) Adding ontologies as an extension package using ebRIM. The author concludes that the third option is the most suitable. Yue et al. (2006)  extend the ebRIM CSW specification by: 1) adding new classes based on existing ebRIM classes; and 2) adding Slots to existing classes, thus creating new attributes.
As a result they are able to store richer metadata records in the catalogue. The authors identified two possible options to implement a search functionality: 1) create an external component without further modification of the CSW schemas; 2) modify the CSW adding semantic functionalities to the existing CSW schemas. In this research they choose for the first option  [9]. Yue et al. (2011)  extends this work, adding further development in the field of geoservices  [7]. A different approach is used by  [10]. In this research the goal is to provide access to data stored in CSW as Linked Data. In order to achieve this goal the authors developed CSW2LD, a middle layer on top of a conventional CSW based server. It allows the server to mimic other Linked Data sources and publish metadata records.
CSW2LD wraps the following CSW requests: GetCapabilities, GetRecords and GetRecordById. A very interesting work in progress is described in  [11]. This is a website describing a proposal by a team from the GeoNetwork developer community. The authors intend to perform a major change in GeoNetwork, allowing it to store metadata as RDF facts stored in a RDF repository. They intent to use SPARQL/GeoSPARQL to retrieve data. The website describe technical characteristics of GeoNetwork and mentions fields that require work in order to implement the project. Currently the constraints that filter the search are encoded using an OGC standard based on CQL  [12]   [13]. As indicated in  [11]  a CSW implementation that uses a triplestore needs to map the constraints to SPARQL/GeoSPARQL which are current W3C recommendations  [14] [15].
However there is scarce research on this topic. By the time we wrote this paper, there was no further development in this project and the website was last updated by the end of October of 2012. In the next section we describe how we deal with some of the challenges already identified by previous researchers. The complete implementation of the CSW standard is not a trivial task. By implementing the whole standard, a CSW would be able to manage a wide range of elements for metadata records and respond to the queries using multiple formats. However the number of queryable elements that must be implemented in a service of this nature is small. A CSW must implement query operations to at least the 15 classic Dublin Core metadata terms. It should also be able to respond to queries using the csw:SummaryRecord format  [16].
Implementation In order to provide semantic capabilities to catalogue, we decided to develop a proof of concept CSW implementation using only the minimum elements and operations. Figure  1A  depicts the architecture we are using. We use a Parliament triplestore as our data repository connected to a Java servlet. Our servlet transforms 1) requests from clients into queries processable by the triplestore, and 2) the triplestore response into a xml document that follows the csw:SummaryRecord format. Our goal is to implement a CSW able to:1) Retrieve records based on an ontology class taxonomy; and 2) Retrieve records based on spatial relationships with elements with toponym values (For instance records located within the element known as "Burgundy"). In order to take advantage of the spatial capabilities of our triplestore we must use geo:SpatialObject as a superclass and geo:Feature as its immediate subclass.
Then we are able to use spatial operators in all the instances of the class geo:Feature and its subclasses   Knowledge stored in domain ontologies can be used by creating subclasses of MetadataRecord. The knowledge represented in the relationships between the classes can easily be added to the queries. We propose to map each metadata record as an instance of a given domain ontology class. To achieve this goal, we plan to harvest keywords from existing metadata elements, such as keywords, abstract, title, etc, and use this information to find the most suitable class based on specifications of the domain ontology. We propose to use a method based on research conducted by  Werner et al. (2012)   [17]. This part of the system is still in development. Figure  1B  depicts a dummy ontology with a taxonomy of classes.
Using the dummy ontology, if the user requests for metadata records of class C, due to the class relationship, the system would also return instances of classes E, F, and G. The metadata records in our research were created by harvesting a set WFS services. We use a custom made tool, developed with Java. Our tool submits a GetCapabilities request to a WFS, and parses the response in order to identify relevant elements. Currently we harvest the following elements: a) provider Name, b) contact individual name, c) contact position name, d) type Name, e) abstract, f) keywords, g) default spatial representation system, h) the URL of the GetFeatures request, and i) the bounding box of the dataset. Being this a proof of concept application we considered these to be enough elements. To feed our ontology with toponymic elements we are importing datasets available in vector format.
We want to use global datasets of administrative units (Countries, provinces, states, etc. ). Brigham et al. (2011) evaluated three global datasets: 1) GAUL, developed by FAO and the European Commision, 2) GADM, developed by the University of California, Berkeley and the International Rice Research Institute, and 3) UNSALB, developed by the United Nations Geographic Information Group. They concluded that GAUL showed better completeness and accuracy  [18]. We intended to use the GAUL dataset for evaluation purposes. However, by the time of writing this paper, our request was still on process. In the meantime we are using an alternative provided by Esri and DeLorme Publishing Company, Inc. under a Creative Commons Attribution-Noncommercial-Share Alike 3. 0 United States License. This dataset depicts the subnational and national boundaries updated with 2011 information  [19].
We plan to update our toponym dataset as soon as a better dataset is available. The most used CSW request is GetRecords. A typical request includes a set of pairs of the form (parameter=value). The CSW server filters out results that do not meet the criteria specified in the parameter constraint. These constraints are encoded using OGC compliant syntax based on CQL. In our implementation we submit GetRecords requests. Our server application parses the request and extracts the value for the constraint. We encode our constraint using a subset of the OGC specification, to which we have added elements to describe instanceOf relationships. The user can link multiple constraints using the operator AND. We also allow the use of an optional boolean element NOT, to indicate that elements matching certain criteria, should be removed from query results.
Our servlet reads the constraint and maps it to suitable SPARQL/GeoSPARQL syntax. The mapping is done using a Java application developed by us. Currently our application supports the following predicates: -PropertyIsInstanceOf To constrain the class membership. This is a custom property, not included in the OGC specification. -PropertyIsEqualTo To compare queryable metadata elements to text strings. -PropertyIsLike To make partial comparisons between queryable metadata elements and text strings. -Within To specify that the bounding box of the metadata record must be inside a given toponym unit. -Intersect The bounding box of the metadata record should intersect the geometry of the toponym unit. -DWithin To define a buffer zone around a given toponym unit and compare it with the bounding box of a metadata record.
FILTER(regex(?literal_keyword,"water","i")) } The maping of the second condition requires further processing. abc:MetadataRecord is linked to dc:description by the property abc:hasDescription, which itself is linked to abc:keyword through the property abc:haskeyword. This element itself is linked to a literal that contains the string containing the keyword. We use the function regex() to search for the word water as a substring of the keywords. We use geo:asWKT to represent the geometry of the selected metadata records. The namespace tu: links to an ontology containing our toponym elements. The filter Within is interpreted by the servlet as an spatial operation between the bounding box of the metadata record and the geometry of toponym unit. After obtaining the wkt literal representation of the geometry, the spatial comparisons are obtained using the funtion geof:sfWithin inside the FILTER.
Conclusions In this paper we are implementing a basic catalogue, so we are not dealing with the real spatial features (streets, roads, etc. ). However by using an external domain ontology and having the URL of the WFS GetFeatures request, we are able to easily identify a dataset and add it to a smart query. Our research shows that mapping between OGC filter specification and SPARQL is not complicated. However, in order to take advantage of additional elements such as a domain ontology and toponym units, it would be necessary to develop a graphic interface on the client application, to reduce syntax errors. The triple store implements its own SPARQL endpoint allowing users to directly access the metadata information bypassing the CSW. However, most of the human users would prefer a CSW interface.
Example 1. Metadata records corresponding to ontology domain class A. The namespace abc: links to our implemented ontology. Class xyz:A is part of our Dummy ontology, and is a subclass of abc:MetadataRecord. The results of this query will include the instances of xyz:A as well as instances of all its subclasses. Metadata records corresponding to ontology domain class B, that include the word water among their keywords. <PropertyIsInstanceOf> <PropertyName>a</PropertyName> <OntClass>xyz:A</OntClass> </PropertyIsInstanceOf> SELECT ?metadatarecord WHERE { ?metadataRecord a abc:MetadataRecord. ?metadataRecord a xyz:A. } Example 2. <and> <PropertyIsInstanceOf> <PropertyName>a</PropertyName> <OntClass>xyz:B</OntClass> </PropertyIsInstanceOf> <PropertyIsLike wildCard="*" singleChar="#" escapeChar="!"> <PropertyName>abc:keyword</PropertyName> <Literal>water</Literal> </PropertyIsLike> </and> SELECT ?metadatarecord WHERE { ?metadataRecord a abc:MetadataRecord.
Example 3. Retrieve metadata records that are members of ontology domain class C. The bounding boxes of the records should be located within the toponym unit France. <and> <PropertyIsInstanceOf> <PropertyName>a</PropertyName> <OntClass>xyz:C</OntClass> </PropertyIsInstanceOf> <Within> <PropertyName>geo:asWKT</PropertyName> <ToponymUnit>tu:France</ToponymUnit> </Within> </and> SELECT ?metadatarecord WHERE { ?metadataRecord a abc:MetadataRecord. ?metadataRecord a xyz:C. ?metadataRecord geo:hasGeometry ?boundingbox. ?boundingbox geo:asWKT ?boundingbox_wkt. tu:France geo:hasGeometry ?France_geometry. ?France_geometry geo:asWKT ?France_wkt. FILTER(geof:sfWithin(?boundingbox_wkt,?France_wkt)) }.
ON/OFF sources to generate realistic throughputs W. Willinger proposed in  (Willinger et al. , 1997)  to generate data following packet-train models, i. e. with strictly alternating, independent and identically distributed ON-and OFF-periods and proved that these ON/OFF sources generate data similar to experimental measurements on real networks. A source corresponds to one network flow. The flow is associated with a source and destination couple and also with data, transmitted as a set of packets called a train of packets. In our case, we use the transport protocols TCP and UDP. The data stream is thus exchanged as a set of IP packets. The source is associated to a departure time and a duration time. The departure time of any source is computed with the departure time of the preceding source plus a random duration.
Traffic replay tools Some software enables the user to replay previously captured network traffics. This is done in two steps. Firstly, the user captures data on the networks he wants to reproduce. This can be done with tools called "sniffers" such as the reference tool Wireshark  (Wireshark, 2013)  and its background application "dumpcap"  (Dumpcap, 2013) , a command-line tool called up internally by Wireshark. Secondly, he needs to replay the captured traces, i. e. by retransmitting the sniffed packets in the same order, and separated with the same delays as these measured during the capture (cf. the "tcpreplay" (note 1) tool for instance). Harpoon (note 2) is another existing Open Source flow-level traffic generator, but this tool requires the user to define flow per flow the data weight he wants to transmit on the network.
This drawback affects most of methodologies based on studies using only one TCP flow. We can cite, for example, when the tester uses an SSH or an FTP connection to transmit a big file and consequently to artificially load the network. Figure  2c  illustrates such a measure of throughput with iperf generating a TCP flow. We can see, from a first qualitative point of view, that the throughput generated by iperf is nearly constant and predictable, contrary to the throughput of an Internet capture (in figure  2a ) and the throughput generated by our tool Sourceonoff (in figure  2b ). Iperf may be configured to transfer multiple TCP streams; in this case the program starts the different flows simultaneously at the beginning of the program. This behavior is not realistic: resources are shared fairly from the beginning, whereas in Internet later flows are penalized at their start by the flows already established.
The SourcesOnOff tool We did not find in the state of the art we performed any tool to generate data flows based on exact ON/OFF sources. This is why we developed this one in C language and validated it with the Debian Operating System. The tool we propose is free and Open Source, under the General Public License v3 (GPLv3 (GPL, 2013)). Source code can be downloaded at http://www. recherche. enac. fr/~avaret/sourcesonoff. Initially developed for Debian-based systems, the 10 source files with 3,000 lines of code are compiled with the GNU C Compiler (gcc, with GCC (GCC, 2013)) and with the pedantic option. It is not POSIX-compatible because we use intensively the (long long) 64 bit-integer type and the (long double) float type for mathematical computations. Moreover, the tool uses certain Linux-specific functions (e.
g. the epoll() system call) and so it should not be easily portable on non-Linux based systems, such as Microsoft Windows® or Mac OSX®. This software is linked with the real-time (-lrt) and the mathematical (-lm) libraries. The binary is between 84kB (32 bit version) and 111kB (64 bit version). Multiplying factors enables users to convert the randomly generated values into Bytes (for Don distributions), nanoseconds (for Doff distributions) and their multiples (kB, MB, GB, us, ms, s…). Distributions may be bounded by minimum and maximum user-defined values. For instance, the program may be limited to 1 GB per flow in order to avoid any traffic generation problems. It can be useful to set up heavy-tailed distributions. Indeed, most of them produce very high values such as 1e+44, but it is often problematic in practice: we cannot transmit a flow of 1e+44 bytes in our networks.
Our tool enforces user-defined minimum and maximum values for the generated random numbers, by increasing values lower than the minimum boundary and decreasing values greater than the maximum boundary. An additional pseudo-distribution is available: the Constant distribution. In this case, all generated values are equal to a user-defined constant. This method enables the user to generate a more predicting behavior. For example, if the user calls the program for UDP flows with a Don distribution constant to 1kB and with a Doff distribution constant to 1 ms, the program will send each millisecond a datagram with 1024 bytes of data (note that this behavior is similar to iperf behavior in UDP mode). A parameter called "turn number" enables the user to limit the number of flows: the program will start "turn" flows then wait for termination of all flows and quit.
Different sets of sources may run simultaneously, each set is associated with independent Don and Doff distributions and parameters. For instance, a set of sources may be defined to load the network with TCP streams and another set to generate UDP datagrams. The process forks itself to provide TCP and UDP data simultaneously. Each task uses the epoll() primitive to perform the management of thousand of flows if necessary. This primitive reduces the portability of the software to only Linux systems and should be replaced with the POSIX-compatible select() primitive in a future tool release. Contrary to programs like iperf, this tool is only intended to generate data. It was not developed to provide itself advanced statistics on the network: we use our tool to generate background traffic and additional passive and active measurement tools to evaluate network performances and collect statistics (note 4).
REMIP and RENATER networks are our links to the Internet. Thus, we captured all data from our LAN to Internet and all associated responses. We captured a set of 9 millions of IPv4 packets, mostly TCP data (97. 7% of TCP, 2. 2% of UDP and 0. 1% of ICMP), during 10 hours between 8:00AM and 6:00PM, Tuesday the 29th of January, 2013. We expected to generate simultaneously TCP sources and UDP sources with our tool SourcesOnOff. However, UDP datagrams are negligible in our case (less than 2. 5% of our traffic in packet numbers, less than 0. 5% of our traffic in bytes), so we replayed only TCP sources. We will finally just model and reproduce the TCP traffic in our study case (section 4 will explain it). We used the tool tcpdump  (Tcpdump, 2013)  to capture the raw packets and then the tool ipsumdump (IPsumDump, 2013) to ensure the anonymity.
For instance, the script we wrote to optimize Weibull shape parameter tests all Weibull values between 0. 01 and 10. 00 with a step of 0. 01. For each of the 10. 000 candidate values, we measured the distance between the network trace values and an equivalent number of values following the Weibull distribution with the candidate shape. We then select the shape value with the minimum distance, in the 10. 000 computed correlations. It is now mandatory to explain how this distance assessment is computed. For this purpose, we used the Bayesian Information Criterion which is introduced in the next subsection. We are thus capable of combining the different values of the traffic to generate by considering in the SourcesOnOff tool those different distributions. The next step of the generation process is to quantify the statistical distance that exists between our original data and the data generated by our tool.