dataesr/scientific-paragraphs-categorization huggingface dataset:
INTRODUCTION The SPARQL W3C recommendation  [5]  defines not only a query language for data represented in RDF, but also the protocol for retrieving the data, including a standardised format for the answers in XML, CSV/TSV and in JSON  [9]. The latter one, in particular, has been introduced with the purpose of easing the consumption of the data by web (and not only) applications, through its complete compatibility with JavaScript. However, the nature of data models between the Web of Data (RDF, graph-oriented) and the Web of Applications (JSON, document-oriented) is very different. In practice, the output of SPARQL endpoints is a set of all possible bindings (of the form <variable, value>) that satisfies the query, which is not handy for efficient client processing. Current habits, expertise and coding technologies for web applications make the manipulation of nested objects easier for developers than the manipulation of triples.
Web developer requirements We describe four different needs that developers face when manipulating SPARQL JSON output: 1. Skip irrelevant metadata. A typical SPARQL output contains a lot of metadata that are usually not useful for web developers. This is the case of the head part that contains the list of variables that one might find in the results. In practice, the developer ignores completely this part and he checks for the availability of a certain property directly in the JSON tree. 2. Reducing and parsing. The value of a property is always wrapped in an object with at least the attributes type (uri or literal) and value, that contain the information. As a consequence, this information is bounded at a deeper level in the JSON structure than the one the developer expects. This makes the manipulation more clumsy.
Transforming the output In this paper, we present a JavaScript module called SPARQL Transformer, with the goal of transforming the JSON output to a chosen structure. The approach relies on a novel query language -based on JSON -that is able to specify both the query and the result structure at the same time. The implementation is strongly inspired by the JSON-LD syntax. This version of JSON defines in its standard some interesting Linked Data possibilities, such as the ability of assigning an URI that identifies an entity (@id), defining its class (@type), declaring the language of a literal (with the couple @language/@value). Nevertheless, SPARQL Transformer is able to generate JSON with any shape, among which JSON-LD occupies a privileged position. Among the two available query syntax (plain JSON and JSON-LD), we will use examples using the JSON-LD one, while the repository README fully explained how to use the JSON one.
RELATED WORK Issues about the usage of SPARQL output in real-life applications have been explored in  [1] , where the proposed solution is specific to the generation of HTML reports. Various works have provided bridges between the Web of Data and the developers. Among these, we can cite grlc, a software for the automatic generation of web API from SPARQL query contained in GitHub repositories  [7]. Wikidata SDK  [6]  addresses the problem of the complexity of the SPARQL JSON output through a precise function 2  that transform the JSON output to a simplified version by reading the variable names. The implementation takes care of the reduction and parsing tasks, but it does not address the problem of merging. The provision to JavaScript developers of an easier way to deal with RDF is also capturing the effort of the W3C RDFJS Community Group 3  , that produced a low level interface specification for the interoperability of RDF data in JavaScript environments  [2].
Their approach tries to preserve the triple format of the information and the graph-oriented model of RDF. The attempt of converting and mapping RDF sources has led to SPARQL Template Transformation Language (STTL)  [3]. This language allows to define transformation templates (as strings) in which the results of the SPARQL query will find place. Moreover, it exposes a significant number of functions, especially when combined with LDScript  [4]. Despite transformation being a goal of STTL, it does neither focus on the conversion to JSON-LD, nor on the merging binding results as exposed in Section 1. The W3C SPARQL Specification itself includes a query format called CONSTRUCT for extracting from the endpoint a set of triples, which is eventually different from its actual content and can also consist in a mapping  [5].
The prototype definition The @graph property (or proto, for plain JSON syntax) contains the prototype of the result as expected by the user. Values in the prototype can start with: • an interrogative point "?" (like ?id or ?city), suggesting that the value should be replaced by the one of the homonym SPARQL variable; • a "$" sign, that identifies the parts that requires to be processed by the software; • any valid value, that will be present in the output as is and which do not depend from the query result. { " @context ": " http : // schema. org /" , " @graph " : [{ " @type ": " City " , " @id ": "? id ", " name " : " $ rdfs : label $ required $ lang : it " , " image ": "$ foaf : depiction $ required " }], "$ where ": [ "? id a dbo : City " , "? id dbo : country dbr : Italy " ], "$ limit ": 100 } Listing 1: A query in the JSON-LD format { " @context ": " http : // schema.
com/foaf/0. 1/". Table  1 : Supported root $-properties query step and have a default values chosen in order to make the developer to retrieve the maximum information. For example, all the values are optional, unless specified as $required. A special role is given to the $var modifier, because it allows to assign a specific SPARQL variable as object (e. g. $var:?myVar), so that it can be addressed in other modifiers. Other possibilities include filtering by language ($lang:it) or sample those values ($sample). As stated before, some properties can have as value a SPARQL variable (e. g. ?id), that will be transferred to the output replaced by its query result value. Also these properties can have modifiers as the previous ones, for example for making them required.
The root $-properties Some root properties -identified by a key starting with a $ -give access to different SPARQL features. They will not be transferred to the output, being considered only at query level. The names of those properties maps exactly to the reserved keywords in SPARQL ($limit, $filter, $groupby, $orderby, etc. ), so that their interpretation is immediate for developers who are familiar with the query language. They often support both a single value or an array. For example, this is the case of $where, that enables to specify WHERE clauses -in the triple format -which will be added to the ones automatically generated by the prototype. Table  1  shows the currently implemented $-properties.
IMPLEMENTATION SPARQL Transformer is a library that receives as input the query in JSON described in Section 3, translates it in a SPARQL query, performs the request to the endpoint and returns a JSON output with the desired shape. Implemented as a JavaScript module, it can run both in the browser and in Node. JS environments. It is made of three parts that work in sequence, as shown in Figure  3. The input is read by the Parser, that has the goal of extracting from it the SPARQL SELECT query and the prototype. The reason for which we rely on SELECT instead of CONSTRUCT is detailed in Section 2. The root $-properties are collected and transformed to match the SPARQL syntax. For the prototype, it requires that for each property: • It reads the assigned SPARQL variable or generates one automatically; • It adds it to the list or variable in the SELECT; • It reads and interprets the modifiers; • If a predicate is declared, it assigns to it the object and the subject, taken from the closest @id; • Considering the previous points, it generates WHERE clauses, FILTERs, etc.
CONCLUSION AND FUTURE WORK The need of easing the manipulation of SPARQL results in web environments led us to define a new strategy of querying the endpoints based on the use of JSON. This strategy found an implementation in a JavaScript module called SPARQL Transformer. This work aims to give a solution to some of the problems that developers are used to face with SPARQL json results. Among them: • Writing a query and the expected output at the same time; • Parsing the values according to the datatype; • Give to the results a different structure than the flat set of <variable, value> items retrieved by default; • Merging the results that describe the same entity; • Map the results to a different vocabulary; • Realise a JSON-LD middleware for RDF data. Considering that it makes use only of JS and JSON, its use cases easily include Node.
JS environments (e. g. , for realising a web API) or directly the browser (for directly retrieving and consuming data coming from the endpoint). SPARQL Transformer is designed to fulfil the most common needs of developers, with the clear limit of the difficulty in getting the same expressiveness of a mature query language as SPARQL. Its implementation covers different features of SPARQL specification, while further ones are foreseen as future work. Further studies will investigate if it would be eventually possible to cover other kind of SPARQL operation, like ASK, INSERT and DELETE. Finally, we plan to better evaluate the library. This goal will be reached in two different ways. On one side, we will try to apply SPARQL Transformer to existing collection of queries, for evaluating its coverage.
In addition, according to the product technical data, the headset seems to have a SLAM and a 3D reconstruction algorithm, but it does not include a gaze tracker. Our system also integrates some interaction abilities through the user's gaze, a problem that is addressed by devices from Tobiipro (?). This paper describes the current state of our project, as well as the main hardware and software components developed. It is organized as follows. In Section 2, a general description of the proposed system is presented. We argue the use of wide angle cameras and present our stereoscopic model in Section ??. The main modules of the system, i. e. , binocular Simultaneous Localization And Mapping (SLAM), Image Generation (IG) and Gaze Tracking (GT), are respectively described in Sections ??, ?? and ??.
The synthesis of these images is performed through a process named Depth Image Based Rendering (DIBR), presented in the sequel. Figure ?? shows a front view of the designed prototype. The VSTHMD lies in the center of the image, while two fish-eye cameras are on the sides. To measure the user's line of sight, a custom micro camera coupled with an infrared lighting system have been designed and inserted into the HMD (Figure  ?? ). This device measures the user's right eye position as well as its gaze direction, so that he/she can interact with the system just by gazing. 2D tags or other camera(s) fixed in the environment can be used to localize the HMD with good performance (accuracy and latency). However, for the system to work in unknown environments, we inte- grated a binocular SLAM that processes the data provided by the embedded stereoscopic sensor.
STEREOSCOPIC LARGE FIELD OF VIEW FOR VSTHMD We use a pair of fish-eye cameras to obtain stereoscopic images of the scene and to allow interaction over the full human FOV. Even if the Oculus FOV is limited to about 110 degrees, we anticipated for future HMDs which will provide wider FOV. As a side benefit, the wide FOV cameras provide more distinguishable features for SLAM. Indeed, when dealing with locally repetitive textures or textureless areas in the environment, a SLAM using traditional small FOV cameras is likely to fail. Contrarily, wide angle cameras allow to keep track of the camera pose by exploiting features located on the borders of the FOV. During our development, a stereo calibration software for fish-eye cameras was supposed to be available in the OpenCV open-source computer vision library but its geometric model is just an extension of the standard pinhole camera model with additional degrees of freedom to account for radial distortions.
This model has proven not to be efficient for real wide angle cameras (FOV over 120 degrees). We decided to use a better fitted model proposed by (?) who open sourced OcamCalib, a Matlab toolbox for omnidirectional (dioptric and catadioptric) camera calibration using this model. We have extended this toolbox to allow the calibration of stereo-vision systems. The used model assumes that the cameras are central systems, i. e. , all the perceived rays intersect at a single point. The model is rotationally symmetrical with respect to the z axis. It maps a 2D point (u, v) in a virtual normalized image plane to a 3D vector P (direction of ray) through a polynomial function f as shown in Equations (??) and (??). The degree of the polynomial can be freely chosen, and a quartic equation model proved to be a good compromise as stated by Scaramuzza and measured in our own experiments.
DIBR The internal structure of the Depth Image Based Rendering (DIBR) module is shown in Figure ??. • The first stage performs the stereo matching on the epipolar rectified images. We use the opensource C++ implementation of Semi Global Block Matching from OpenCV 3. 1. The resulting disparity maps being noisy, a filtering is introduced, as proposed by (?). • The second stage is in charge of 3D warping, i. e. , the projection of images and depth maps on synthetic cameras at distinct poses. To this aim, a 3D point cloud is generated from the depth maps pixels. These points are then rotated, translated and projected to the synthetic cameras so as to render corresponding synthetic images and depth maps. Small holes are generated in the rendered images for multiple reasons: there is no one-to-one pixel correspondence between the input and generated images; the change of viewpoint requires to render parts of the scene that were not observed in the input image.
AR Content Projection Conventional OpenGL projection of textured 3D meshed models is performed to get augmented stereoscopic images. The rendering is done using the Oculus DK2 Software Development Kit which generates suitable camera projections for the two eyes. The SDK also provides a shader program to process the rendered images in order to take into account the chromatic aberrations caused by the low-cost optical system of the device. The synthetic images generated by the DIBR module are used as background while the synthetic depth maps serve to initialize the Z-buffer. As the OpenGL rendering cameras rely on the same geometric models as those of the DIBR, the 3D objects are easily rendered and integrated inside the real environment. The Z-buffer test determines for each rendered pixel whether it is occluded or not by the real scene.
The GT software module is composed of two main parts that process the images from the gaze tracker camera: the first fits an ellipse on the pupil contour and the second deduces the gaze direction from the pupil center (u pc , v pc ). For the gaze direction estimation, we use a polynomial model to compute the pixel (u s , v s ) on the scene camera where the eye is directed to (see equations ?? and ??). Our method for the pupil detection and gaze estimation is similar to that of (?). u s v s = f 1 (u pc , v pc ) f 2 (u pc , v pc ) (4) f i (u pc , v pc ) = a i1 + a i2 u pc + a i3 v pc +a i4 u 2 pc + a i5 v 2 pc + a i6 u pc v pc (5) A calibration must be conducted in order to estimate the parameters (a 11 ,. , a 16 ) and (a 21 ,. , a 26 ). In this preliminary stage, the user must successively look towards nine points homogeneously distributed on the screen.
• Binocular SLAM is used on half resolution images (540x540 pixels) with a maximum limit of 1000 detected and tracked features. The maximum attainable frequency for SLAM alone is about 13 FPS when 3 CPU cores are involved. As the display is done at 60 FPS, a pose computed by SLAM must thus be used several times by the IG module. • The IG stage is relatively time consuming. The entailed OpenCV Semi Global Block Matching CPU implementation itself requires nearly one second for one CPU core to correlate the images. The stereo 3D warping, hole filling and implemented scene analysis (consisting in simple robust plane fitting) stages require negligible time in comparison. The projection of AR content being done by the GPU and the projected model being composed of just a few hundred of textured triangles, its is achieved at high FPS.
We present the Parallel, Forward-Backward with Pruning (PFBP) algorithm for feature selection (FS) for Big Data of high dimensionality. PFBP partitions the data matrix both in terms of rows as well as columns. By employing the concepts of p-values of conditional independence tests and meta-analysis techniques, PFBP relies only on computations local to a partition while minimizing communication costs, thus massively parallelizing computations. Similar techniques for combining local computations are also employed to create the final predictive model. PFBP employs asymptotically sound heuristics to make early, approximate decisions, such as Early Dropping of features from consideration in subsequent iterations, Early Stopping of consideration of features within the same iteration, or Early Return of the winner in each iteration.
PFBP provides asymptotic guarantees of optimality for data distributions faithfully representable by a causal network (Bayesian network or maximal ancestral graph). Empirical analysis confirms a super-linear speedup of the algorithm with increasing sample size, linear scalability with respect to the number of features and processing cores. An extensive comparative evaluation also demonstrates the effectiveness of PFBP against other algorithms in its class. The heuristics presented are general and could potentially be employed to other greedy-type of FS algorithms. An application on simulated Single Nucleotide Polymorphism (SNP) data with 500K samples is provided as a use case.
g. , the Lasso algorithm  (Tibshirani 1996) ] to causally-inspired, non-parametric assumptions, such as faithfulness of the data distribution to a causal model  (Pearl and Verma 1995; Spirtes et al. 2000). Specifically, in the context of Big Data featuring both high dimensionality and/or high sample volume, computations become CPU-intensive as well as and data-intensive and cannot be handled by a single machine. 3 The main challenges arising in this context are (a) how can data be partitioned both horizontally (over samples) and vertically (over features), called hybrid-partitioning, so that computations can be performed locally in each block and combined globally with a minimal communication overhead;  (b)  what heuristics can quickly (e. g. , without the need to go through all samples) and safely (providing theoretical guarantees of correctness) eliminate irrelevant and redundant features.
Hybrid partitioning over both data samples and learned models  (Xing et al. 2016; Lee et al. 2014 ) is an open research issue in Big ML algorithms while safe FS heuristics has been proposed only for sparse Big Data  (Singh et al. 2009; Ramrez-Gallego et al. 2017) , i. e. , for data where a large percentage of values are the same (typically zeros). To address these challenges we introduce the Parallel, Forward-Backward with Pruning (PFBP) algorithm for Big Volume Data. PFBP does not rely on data sparsity and is generally applicable to both dense and sparse datasets; in the future, it could be extended to include optimizations specifically designed for sparse datasets. PFBP is based on statistical tests of conditional independence and it is inspired by statistical causal modeling that represents the joint probability distribution as a causal model and specifically the theory of Bayesian networks and maximal ancestral graphs  (Pearl 2000; Spirtes et al.
2013 Lagani et al. , 2017;; Borboudakis and Tsamardinos 2017). We should also note that all PFBP computations are not bound to specific data-types; by supplying different conditional independence tests PFBP becomes applicable to a wide variety of data types and target variables (continuous, ordinal, nominal, right-censored time-to-event a. k. a. survival analysis, zero inflated, percentage, time-course, repeated measurements, and others; see our R package MXM  (Lagani et al. 2017)  for algorithms that can handle this palette of outcomes by just providing them with different conditional independence tests). Furthermore, PFBP could potentially handle data with non-linear dependencies, as long as an appropriate conditional independence test is provided [e. g. , a kernel-based test  (Zhang et al.
2011)  or the G 2 test for multinomial, discrete data  (Agresti 2002) ]. PFBP is first evaluated on a range of simulated data to assess its scalability properties. The data are simulated from randomly generated Bayesian networks (thus, simulating a rich dependency structure) in order to incorporate a complex dependency structure among the variables and include not only irrelevant features, but also redundant features. PFBP is found to scale super-linearly with the available sample size as its heuristics allow it to make early decisions before examining all available samples. It scales linearly with the number of features and available cores. PFBP is compared on a set of real datasets spanning a range of feature and sample sizes against the main forward-selection algorithms in the literature devised for Big Data architectures.
g. , 45% accuracy of SparkLR versus 85% accuracy for random guessing). In contrast, CombLR is never worse than the trivial model more than 0. 02%. While the focus of the paper is on FS, these results indicate that methods for combining local statistics and models may serve a more general purpose in Big Data analytics. The paper is organized as follows. In Sect. 2 we provide a brief introduction to the basic concepts required to introduce our FS algorithm. The PFBP algorithm is introduced in Sect. 3. In Sect. 4 we explain the heuristics used by PFBP in detail, and show to how to implement them using bootstrap-based tests. Guidelines for setting the hyper-parameter values for the data partitioning used by PFBP are presented in Sect. 5. In Sect. 6 we list some implementation details of PFBP, which are required for a fast and robust implementation.
Intuitively, this can be justified by the fact that everything else being equal (i. e. , sample size, type of test) the p-values of such tests in case of dependence have (on average) the reverse ordering with the conditional association of the variables with T given S. So, the basic variant of the algorithm selects to add (remove) the feature with the lower (higher) p-value in each Forward (Backward) Iteration. The Forward-Backward Selection algorithm using conditional independence tests is summarized in Algorithm 1. We use V D to denote the set of variables contained in dataset D (excluding the target T ). The Pvalue(T , X |S) function performs a conditional independence test of T and X given S and returns a p-value.
Approximating global p-values by combining local p-values using meta-analysis Recall that Forward-Backward Selection uses p-values stemming from conditional independence tests to rank the variables and to select the best one for inclusion (forward Phase) or exclusion (backward Phase). Extending the conditional independence tests to be computed over multiple Data Blocks is not straightforward, and may be computationally inefficient. For conditional independence tests based on regression models (e. g. logistic or Cox regression), a maximum-likelihood estimation over all samples has to be performed, which typically does not have a closed-form solution and thus requires the use of an iterative procedure (e. g. Newton descent). Due to its iterative nature, it results in a high communication cost rendering it computationally inefficient, especially for feature selection purposes on Big Data where numerous models have to be fit at each Iteration.