dataesr/scientific-paragraphs-categorization huggingface dataset:
IMPLEMENTATION AND EVALUATION To evaluate the effectiveness of xR2RML, we have developed an open source prototype implementation available on Github 14. It is developed in Scala and based on Morph-RDB  (Priyatna et al. , 2014) , an R2RML implementation that we have extended to support xR2RML specificities. In a first step, we upgraded Morph-RDB to support xR2RML features in the context of relational databases. This included the support of logical sources, mixed contents (JSON, XML, CSV or TSV data embedded in cells) and RDF collections/containers. In a second step, we developed a connector to the MongoDB document store, to translate MongoDB JSON documents into RDF. A MongoDB shell query string is specified in each triples map logical source (property xrr:query). The connector executes the query and iterates over result documents returned by the database.
Subsequently, results are passed to the xR2RML processor that applies the optional iterator (rml:iterator) and evaluates JSONPath expressions in each xrr:reference and rr:template property of all term maps. The support of RDF collections and containers was validated, in particular in the case of cross-references (referencing object map) that entail a joint query between two JSON documents. Software architecture. The prototype architecture derives from the initial Morph-RDB architecture. To deal with the heterogeneity of databases, Morph follows the object factory design pattern. An abstract runner factory class provides abstract methods to build a runner, the core object that performs the translation of an input database with regards to an xR2RML mapping graph. A concrete runner factory class copes with database specificities through a set of objects: (i) a generic connection wraps a database connection; (ii) a query unfolder builds a concrete query object reflecting each defined triples map; (iii) a data translator runs the query against the database connection and generates triples according to the triples map definitions; (iv) finally, a data materializer writes created triples into a target file according to the chosen RDF serialization.
In the current status we provide two factory implementations: the RDB implementation extends the original Morph-RDB code, while the new MongoDB implementation relies on the MongoDB API and the Jongo API for the management of MongoDB shell queries. In the RDB context, the unfolder builds an SQL query from the table name (logical table 14 https://github. com/frmichel/morph-xr2rml/ definition), named columns (propertiesrr:column and rr:template) and the optional join conditions (referencing object maps). In the MongoDB case, the query string is provided in the mapping. Furthermore, since MongoDB does not support joint queries, the xR2RML processing engine has to perform two queries and join results afterwards. As a result, the unfolder is fairly simple, it checks the query string correctness and returns an appropriate API object.
Evaluation. We evaluated the prototype using two simple databases: a MySQL relational database and a MongoDB database with two collections. In both cases, the data and associated xR2RML mappings were written to cover most mapping situations addressed by xR2RML: strategies for handling multiple RDF terms, JSONPath and XPath expressions, mixed-syntax paths with mixed contents (relational, JSON, XML, CSV/TSV), cross-references, production of RDF collection/containers, management of UTF-8 characters. A dump of both databases as well as the example mappings are available on the same GitHub repository. The current status of the prototype applies the data materialization approach, i. e. RDF data is generated by sequentially applying all triples maps. The query rewriting approach (SPARQL to database specific query rewriting) may be considered in future works as suggested in section 7.
DISCUSSION xR2RML relies on the assumption that databases to translate into RDF provide a declarative query language, such that queries can be expressed directly in a mapping description. This complies with the equivalent assumption of R2RML that all RDBs support ANSI SQL. However this is somehow restrictive. Some NoSQL key-value stores, like Dy-namoDB and Riak, have no declarative query language, instead they provide APIs for usual programming languages to describe queries in an imperative manner. For xR2RML to work with those systems, a query language should be figured out along with a compiler that transforms queries into imperative code. Interestingly, this is already the case of some systems supporting the MapReduce programming model. MapReduce is conventionally supported through APIs for programming languages, however more and more systems now propose an SQL or SQL-like query language on top of a MapReduce framework (e.
g. Apache Hive). Queries are compiled into MapReduce jobs. This approach is often referred to as SQL-on-Hadoop  (Floratou et al. , 2014). To achieve the targeted flexibility, xR2RML comes with features that are applicable independently of the type of database used. Nevertheless, all features should probably not be applied with all kinds of database. For instance, join conditions entail joint queries. Whereas RDBs are optimized to support joins very efficiently, it is not recommended to make cross-references within NoSQL document or extensible column stores, as this may lead to poor performances. Similarly, translating a JSON element into an RDF collection is quite straightforward, but translating the result of an SQL joint query into an RDF collection is likely to be quite inefficient. In other words, because the language makes a mapping possible does not mean that it should be applied regardless of the context (database type, data model, query capabilities).
Consequently, mapping designers should be aware of how databases work in order to write efficient mappings of big databases to RDF. Like R2RML, xR2RML assumes that welldefined domain ontologies exist beforehand, whereof classes and properties will be used to translate a data source into RDF triples. In the context of RDBs, an alternative approach, the Direct Mapping, translates relational data into RDF in a straightforward manner, by converting tables to classes and columns to properties  (Sequeda et al. , 2011; Arenas et al. , 2012). The direct mapping comes up with an ad-hoc ontology that reflects the relational schema. R2RML implementations often provide a tool to automatically generate an R2RML direct mapping from the relational schema (e. g. Morph-RDB (de Medeiros et al. , 2015) ). The same principles could be extended to automatically generate an xR2RML mapping for other types of data source, as long as they comply with a schema: column names in CSV/TSV files and extensible column stores, XSD or DTD for XML data, JSON schema 15 or a JSON-LD 16 description for JSON data.
Nevertheless, such schemas do not necessarily exist, and some databases like the DynamoDB key-value store are schemaless. In such cases, automatically generating an xR2RML direct mapping should involve different methods aimed at learning the database schema from the data itself. More generally, how to automate the generation of xR2RML mappings may become a concern to map large and/or complex schemas. There exists significant work related to schema mapping and matching 15 http://json-schema. org/ 16 http://www. w3. org/TR/json-ld/  (Shvaiko and Euzenat, 2005). For instance, Clio  (Fagin et al. , 2009)  generates a schema mapping based on the discovery of queries over the source and target schemas and a specification of their relationships. Karma  (Knoblock et al. , 2012)  semi-automatic maps structured data sources to existing domain ontologies.
It produces a Global-and-Local-As-View mapping that can be used to translate the data into RDF. xR2RML does not directly address the question of how mappings are written, but can be complementary of approaches like Clio and Karma. In particular, Karma authors suggest that their tool could easily export mapping rules as an R2RML mapping graph. A similar approach could be applied to discover mappings between a non-relational database and domain ontologies, and export the result as an xR2RML mapping graph.
CONCLUSION AND PERSPECTIVES In this paper we have presented xR2RML, a language designed to describe the mapping of various types of databases to RDF, by flexibly adapting to heterogeneous query languages and data models. We have analysed data models of several modern databases as well as the format in which query results are returned, and we have shown that xR2RML can translate any data element within such results into RDF, relying when necessary on existing languages such as XPath and JSONPath. We have illustrated some features of xR2RML such as the generation of RDF collections and containers, and the ability to deal with mixed content, e. g. when a relational table stores data formatted in another syntax like XML, JSON or CSV. Principles of the xR2RML mapping language have been validated in a prototype implementation supporting several RDBs and the MongoDB NoSQL document store.
The development of connectors to other types of database shall be considered based on concrete use cases. Depending on the target system, different optimizations shall be studied, notably regarding the computation of joint queries. Furthermore, the data materialization approach we implemented is effective but it does not scale to big data sets. Dealing with big data sets requires the data to remain in legacy databases, and that translation to RDF be performed on demand through the xR2RML-based rewriting of SPARQL queries into the source database query language. In this regard, existing works related to RDBs should be leveraged  (Priyatna et al. , 2014; Sequeda and Miranker, 2013).
Page "]} ] } Listing 4: Example Database (property rml:logicalSource) extends R2RML logical table and points to the data source (property rml:source): this may be a file on the local file system, or data returned from a web service for instance. A reference formulation (property rml:referenceFormulation) names the syntax used to reference data elements within the logical source. As of today, possible values are ql:JSONPath for JSON data, ql:XPath for XML data, and rr:SQL2008 for relational databases. Data elements are referenced with property.
rml:referenceFormulation ql:JSONPath; rml:iterator Page "]} ] } Listing 4: Example Database (property rml:logicalSource) extends R2RML logical table and points to the data source (property rml:source): this may be a file on the local file system, or data returned from a web service for instance. A reference formulation (property rml:referenceFormulation) names the syntax used to reference data elements within the logical source. As of today, possible values are ql:JSONPath for JSON data, ql:XPath for XML data, and rr:SQL2008 for relational databases. Data elements are referenced with property rml:reference that extends rr:column. Its object is an expression whose syntax matches the reference formulation. Similarly, the definition of property rr:template is extended to allow such reference expressions to be enclosed within curly braces ('{' and '}').
The non-rigid face tracking has been achieved many advances in recent years, but most of empirical experiments are restricted at near-frontal face. This report introduces a robust framework for pose-free tracking of non-rigid face. Our method consists of two phases: training and tracking. In the training phase, a large offline synthesized database is built to train landmark appearance models using linear Support Vector Machine (SVM). In the tracking phase, a two-step approach is proposed: the first step, namely initialization, benefits 2D SIFT matching between the current frame and a set of adaptive keyframes to estimate the rigid parameters. The second step obtains the whole set of parameters (rigid and non-rigid) using a heuristic method via pose-wise SVMs. The combination of these aspects makes our method work robustly up to 90 • of vertical axial rotation.
Moreover, our method appears to be robust even in the presence of fast movements and tracking losses. Comparing to other published algorithms, our method offers a very good compromise of rigid and non-rigid parameter accuracies. This study gives a promising perspective because of the good results in terms of pose estimation (average error is less than 4 o on BUFT dataset) and landmark tracking precision (5. 8 pixel error compared to 6. 8 of one state-of-the-art method on Talking Face video). These results highlight the potential of using synthetic data to track non-rigid face in unconstrained poses.
Their algorithm appears to be robust for tracking landmarks, but unable to recover when tracking is lost. Let us notice that these methods use the synthetic database to train tracking models. A face tracking framework is robust if it can operate with a wide range of pose views, face expression, environmental changes and occlusions, and also have recovering capability. In  (Cascia et al. , 2000; Xiao et al. , 2003) , the authors utilized dynamic templates based on cylinder model in order to handle with lighting and self-occlusion. Local features can be considered  (Saragih et al. , 2011; Xiong and la Torre Frade, 2013) , since local descriptors are not much affected by facial expressions and self-occlusion. In order to have recovering capability, tracking-by-detection or wide baseline matching  (Vacchetti et al.
In this paper, our contribution is two-folds: (i) using a large offline synthetic database to train tracking models, (ii) proposing a two-step tracking approach to track non-rigid face. These points are immediately introduced in more detail. Firstly, a large synthesized database is built to avoid the expensive and timeconsuming manual annotation. To the best of our knowledge, although there were some papers worked with the synthetic data  (Gu and Kanade, 2006; Alonso et al. , 2007; Su et al. , 2009) , our paper is the first study that investigates the large offline synthetic dataset for the free-pose tracking of non-rigid face. Secondly, the tracking approach consists of two steps: a) The first step benefits 2D SIFT matching between the current frame and some preceding-stored keyframes to estimate only rigid parameters.
Model Training From Synthesized Data We consider the synthesized data for the training because of some reasons: (i) Most of available datasets were built for frontal face alignment  (Koestinger et al. , 2011). The others contain profile information such as ALFW  (Koestinger et al. , 2011) , Multi-PIE  (Gross et al. , 2010) , but the range of Pitch or Roll are restricted. In addition, the number of landmarks of frontal and profile faces is different. That makes a gap, how to track from frontal to profile faces (ii) The campaign of ground-truth for building a new dataset is very expensive and (iii) The hidden landmarks could be localized in synthesized dataset, so the gap between frontal and profile tracking could be bridged. The training process is shown in Fig. 2. At first, we select 143 frontal images (143 different subjects) from Multi-PIE.
EXPERIMENTAL RESULTS We adopted the Boston University Face Tracking (BUFT) database of  (Cascia et al. , 2000)  and Localizing 2D coordinate projection of landmarks x k (θ), k = 1,. , n. 3: Looking v = 4 nearest candidates p k from x k (θ) in Ω k. 4: Selecting the candidate p k from v ones that has highest SVM score w k.
Twelve landmarks at corners of eyes, nose and mouth are chosen. The Fig. 4  shows the RMS of our method (red curve), and FaceTracker (blue curve)  (Saragih et al. , 2011)  on the Talking Face video. The vertical axis is the RMS error (in pixel) and the horizontal axis is the frame number. The result shows that even though our method just learned from the synthesized data, what we obtain is comparable to the state-of-the-art method, even more robust. The average precision of the entire video of our method is 5. 8 pixels and Face-Tracker is 6. 8 pixels. VidTimid and Honda/UCSD: The VidTimid is captured in resolution 512x384 pixels at the good office environment. Honda/UCSD dataset at resolution 640x480, is much more challenging than VidTimid that provides a wide range of different poses at different conditions such as face partly occlusion, scale changes, illumination, etc.
The ground-truth of pose or landmarks is unavailable in these databases; hence, they are used for visualizing purpose of the profile tracking. Our framework again demonstrates its capability even in more complex movements of the head. In fact, our method is more robust than FaceTracker in terms of keeping track unloosing and it can recover face quickly without waiting for frontal face reset as FaceTracker. See Fig. 5. Some full videos in paper can be found at here 3 , in which one our own video is also recorded for evaluation. Our method is again more robust on FaceTracker on this video. Although real-time computation is unsustainable (about 5s/frame on Desktop 3. 1GHz, 8G RAM) due to Matlab implementation. In which, the first step is about 3s/frame because of SIFT matching. The C/C++ implementation and the replacement of SIFT 3 http://www.
CONCLUSIONS We presented a robust framework for pose-free tracking of non-rigid face. Our method used the large synthesized dataset rendering from a small set of annotated frontal views. This dataset was divided into groups to train pose-wise linear SVM classifiers. The response map of one landmark is the combination of response maps from three descriptors: intensity, gradient and LBP. Through keeping some candidates from one combined response map, we apply an heuristic method to choose the best one via the constraint of 3D shape model. In addition, the SIFT matching makes our method robust to fast movements and provides a good initial rigid parameters. Through keyframes, our method can do recover the lost tracking quickly without waiting for frontal-view reset. Our method is more robust than one state-of-the-art method in terms of the profile tracking and comparable in landmark tracking.
3) makes robust response maps more robust. Because of large pose variation of the dataset, the pose-wise SVMs are trained as follows. The total rendered images are splitted into 1155 (15(Yaw) × 11(Pitch) × 7(Roll)) pose-wise groups (143 images/group). Each group is used to train 90 pose-wise linear SVMs (30 landmarks × 3 descriptors) in similar manner of (Wang et al. , 2008). So, the total of 103950 classifiers (namely ζ) needs to be trained. In the other words, let us denote C x,y,z ∈ ζ is one classifier that is trained on the specific pose x (∈ 1155 poses), the landmark id y (∈ [1,. , 30]) and the descriptor type z (∈ [intensity, gradient, LBP]).
It has also been extended to support ML polymorphism by implementing the TFF1 format  [5]. Dedukti  [7]  is a proof checker that implements λΠ ≡ , a proof language that has been proposed as a proof standard for proof checking and interoperability. This embedding is used to certify proofs in two different projects: FoCaLiZe  [17] , a programming environment to develop certified programs and based on a functional programming language with object-oriented features, and BWare  [14] , an industrial research project that aims at providing a framework for the automated verification of proof obligations coming from the B method  [1]. The main benefit of Zenon Modulo and Dedukti relies on deduction modulo. Deduction modulo is an extension of first-order logic that allows reasoning modulo a congruence relation over propositions.
Dedukti The λΠ-calculus  [2]  is the simplest Pure Type System featuring dependent types. It is commonly used as a logical framework for encoding logics  [18]. The λΠ-calculus modulo, presented in Fig. 2 , is an extension of the λΠ-calculus with rewriting. The λΠ-calculus modulo (abbreviated as λΠ ≡ ) has successfully been used to encode many logical systems (Coq  [6] , HOL, iProver Modulo  [10] , FoCaLiZe) using shallow embeddings. In λΠ ≡ , conversion goes beyond simple β-equivalence since it is extended by a custom rewrite system. When this rewrite system is both strongly normalizing and confluent, each term gets a unique (up to α-conversion) normal form and both conversion and type-checking become decidable. Dedukti is an implementation of this decision procedure. Burel  [10]  defines two encodings of deduction modulo in Dedukti: a deep encoding |ϕ| in which logical connectives are simply declared as Dedukti constants and a shallow encoding ϕ := prf |ϕ| using a decoding function prf for translating connectives to their impredicative encodings.
Application to FoCaLiZe FoCaLiZe is a framework for specifying, developing and certifying programs. The specification language is first-order logic and proofs can be discharged to Zenon or Zenon Modulo. The FoCaLiZe compiler produces both a regular program written in OCaml and a certificate written either in Coq or in Dedukti (but only the Dedukti output can be used from Zenon Modulo). In FoCaLiZe, specifications usually rely a lot on the primitive type bool so it is important that Zenon Modulo deals with booleans efficiently. In order to prove all propositional tautologies, it is enough to add the following rules for reasoning by case on booleans (together with truth tables of connectives): However, we get a much smaller proof-search space and smaller proofs by adding common algebraic laws as rewrite rules.
The Python programming language in particular has seen a surge in popularity across the sciences, for reasons which include its readability, modularity, and large standard library. The use of Python as a scientific programming language began to increase with the development of numerical libraries for optimized operations on large arrays in the late 1990s, in which an important development was the merging of the competing Numeric and Numarray packages in 2006 to form NumPy  (Oliphant, 2007). As Python and NumPy have gained traction in a given scientific domain, we have seen the emergence of domain-specific ecosystems of open-source Python software developed by scientists. It became clear to us in 2007 that we were on the cusp of an emerging Python in neuroscience ecosystem, particularly in computational neuroscience and neuroimaging, but also in electrophysiological data analysis and in psychophysics.
Two major strengths of Python are its modularity and ability to easily "glue" together different programming languages, which together facilitate the interaction of modular components and their composition into larger systems. This focus on reusable components, which has proven its value in commercial and open-source software development  (Brooks, 1987) , is, we contend, essential for scientific computing in neuroscience, if we are to cope with the increasingly large amounts of data being produced in experimental labs, and if we wish to understand and model the brain in all its complexity. We therefore felt that it was timely and important to raise awareness of the emerging Python in Neuroscience software ecosystem amongst researchers developing Python-based tools, but also in the larger neuroscience community.
Our goals were several-fold: -establish a critical mass for Python use and development in the eyes of the community; -encourage interoperability and collaboration between developers; -expose neuroscientists to the new Python-based tools now available. From this was born the idea for a Research Topic in Frontiers in Neuroinformatics on "Python in Neuroscience" to showcase those projects we were aware of, and to give exposure to projects of which we were not aware. Although it may seem strange at first glance to center a Research Topic around a tool, rather than around a scientific problem, we feel it is justified by the increasingly critical role of scientific programming in neuroscience research, and by the particular strengths of the Python language and the broader Python scientific computing ecosystem.