dataesr/scientific-paragraphs-categorization huggingface dataset:
Now, let us see how we applied this generic approach to our specific case. First, note that each domain (Banking and Automotive) is treated separately, since a user belongs to only one domain. Regarding the languages (English and Spanish), we considered two approaches: processing all tweets at once without any regard for the language (called Joint in the rest of the article) and treating the languages separately then combining the corresponding classes or ranking (Separated ). The process itself is two-stepped. Our first step consists in determining which tweets to analyze for each user. We tested two different strategies: 1) use all the tweets provided by RepLab (strategy All ) ; and 2) select only the most relevant tweets (strategy Artex ). The latter consists in extracting only the 10% most informative tweets the user published.
Regarding the decision strategy used for BoT, summing (Sum) the votes improves the performance com- pared to simply counting them (Count). This effect is more or less marked depending on the the way the languages are treated: no effect for Joint, strong effect for Separated. The domain also affects this improvement, which is much smaller for Banking than for Automotive. This could indicate users behave differently, in terms of how they redact tweets, depending on their domain. This would be consistent with our assumption regarding the use of different terminology by influential users of distinct activity domains. The tweet selection step (approach Artex ) affects differently the BoT and UaD methods. For the former, there is an increase in performance, compared to using all available tweets (approach All ).
Compared to the classification results, the performances of the BoT and UaD methods are tighter, but the latter still dominate the former, though. Again, both methods get better results when the languages are treated separately (approach Separated ). The BoT method still appear to perform better when using the Sum decision strategy (instead of Count). Including the tweet selection step (Artex ) showed no significant performance changes, be it in terms of increase or decrease. This means describing a user based on the vocabulary he uses over all his tweets retains the information necessary to rank his influence level. Our results indicate that influential users from a specific domain behave differently and write in a particular manner compared to other users. In other words, Influencers are characterized by a certain editorial behavior.
For bilingual users, as observed for the classification task, separating their tweets in order to process the languages separately led to improvements in the ranking performance. This suggests that words originating from one language get a different meaning when used in the context of the other language. Ramírez-de-la-Rosa et al. [62]  were able to take advantage of certain scalar features to feed SVM-based classifiers in order to tackle the classification task, while RepLab participants such as the LyS  [73]  and UNED_ORM  [51]  groups did the same for the ranking task. However, we were not able to obtain any results when using the same classification tools and similar features (no convergence). The large variety of descriptors that can be considered for each feature may explain this difference: a wrong descriptor choice is quite sufficient to mislead the training process.
Conclusion In this article, we have focused on the problem of user characterization on Twitter, and more particularly on the features used in the literature to perform such a classification. We first investigated a wide range of features coming from different research domains (mainly Social Network Analaysis, Natural Language processing and Information Retrieval), before proposing a new typology of features. We then tackled the problem of identifying and ranking real-life Influencers (a. k. a. offline influencers) based on Twitter-related data, as specified by the Re-pLab 2014 challenge. For this experimental part, we can highlight two main results. First, we showed that classical SNA features used to detect spammers, social capitalists or users influential on Twitter, do not give any relevant result on this problem.
Our second result is the proposal of an NLP approach consisting in representing a user under various forms of bags-of-words, which led to a much better performance than all state-of-the-art methods (both content-based and -independent). From our result, we can suppose the way a user writes his tweets is related to his real-life influence, at least for the studied domains. This would confirm assumptions previously expressed in the literature regarding the fact users from specific domains behave and write in their own specific way. It is important to highlight the fact our experimental results are valid only for the considered dataset. This means they are restricted to the domains it describes (Automotive and Banking), and are only as good as the manual annotation of the data. In RepLab 2014  [3] , the organizers were not able to conclude on significant differences between participants (and features or methods used) due to the small number of considered domains.
INTRODUCTION In the area of Big Data, NoSQL systems have attracted interest as mean for implementing multidimensional data warehouses  (Chevalier et al, 2015a) ,  (Chevalier et al, 2015b) ,  (Mior, 2014) ,  (Dede et al, 2013) ,  (Schindler, 2012). The proposed approaches mainly rely on two specific classes of NoSQL systems, namely document-oriented systems  (Chevalier et al, 2015a)  and column oriented systems  (Chevalier et al, 2015b) ,  (Dede et al, 2013). In this paper, we study further document-oriented systems in the context of data warehousing. In contrast to Relational Database Management Systems (RDBMS), document-oriented systems,and many other NoSQL systems, are famous for horizontal scaling, elasticity, data availability, and schema flexibility. They can accommodate heterogeneous data (not all conforming to one data model); they provide richer structures (arrays, nesting…) and they offer different options for data processing including map-reduce and aggregation pipelines.
In these settings, it becomes interesting to investigate for new opportunities for data warehousing. On one hand, we can exploit scalability and flexibility for large-scale deployment. On the other hand, we can accommodate heterogeneous data and consider mapping to new data models. In this setting, document-oriented systems become natural candidates for implementing data warehouses. In this paper, we consider four possible mappings of the multidimensional conceptual model into document logical models. This includes simple models that are analogous to relational database models using normalization and denormalization. We also consider models that use specific features of the document-oriented system such as nesting and schema flexibility. We instantiate a data warehouse using each of the models and we compare each instantiation with each other on different axes including: data loading, querying, and OLAP cuboid computation.
RELATED WORK Multidimensional databases are mostly implemented using RDBMS technologies  (Chaudhuri et al, 1997) ,  (Kimball, 2013). Considerable research has focused on the translation of data warehousing concepts into relational logical level  (Bosworth et al, 1995) ,  (Colliat et al, 1996) , (called R-OLAP). Mapping rules are used to convert structures of the conceptual level (facts, dimensions and hierarchies) into a logical model based on relations  (Ravat, et al, 2006). There is an increasing attention towards the implementation of data warehouses with NoSQL systems  (Chevalier et al, 2015a) ,  (Zhao et al, 2014) ,  (Dehdouh et al, 2014) ,  (Cuzzocrea et al, 2013). In  (Zhao et al, 2014) , the authors implement a data warehouse into a column-oriented store (HBase). They show how to instantiate efficiently OLAP cuboids with MapReduce-like functions.
Experimental Setup The experimental setup is briefly introduced and then detailed in the next paragraphs. We generate 4 datasets according to the SSB+, Star schema benchmark  (Chevalier et al, 2015c) ,  (Oneil et al, 2009) , which is itself a derived from the TPC-H benchmark. TPC-H is a reference benchmark for decision support systems. The benchmark is extended to generate data compatible to our document models (M0, M1, M2, M3). Data is loaded in MongoDB v2. 6, a popular document-oriented system. On each dataset, we issue sets of OLAP queries and we compute OLAP cuboids on different combinations of dimensions. Experiments are done in single-node and a distributed 3-nodes cluster setting. For comparative reasons, we also load two datasets in PostgresSQL v8. 4, a popular RDBMS. In this case, dataset data corresponds to a flat model (M0) and a star-like normalized model (M2), that we name respectively R0 and R2.
Experiments in PostgreSQL are done in a singlenode setting. Data. We generate data using an extended version of the Start Schema Benchmark denoted SSB+  (Chevalier et al, 2015c) ,  (Oneil et al, 2009). The benchmark models a simple product retail reality. The SSB+ benchmark models a simple product retail reality. It contains one fact "LineOrder" and 4 dimensions "Customer", "Supplier", "Part" and "Date". We generate data using an extended version of the Start Schema Benchmark SSB  (Oneil et al, 2009)  because it is the only data warehousing benchmark that has been adapted to NoSQL systems. The extended version is part of our previous work (Blind3). It makes possible to generates raw data directly as JSON which is the preferable data format for data loading in MongoDB. We use improve scaling factor issues that have been reported.
In our experiments we use different scale factors (sf) such as sf=1, sf=10 and sf=25 in our experiments. In the extended version, the scale factor sf=1 corresponds to approximately 10 7 records for the LineOrder fact, for sf=10 we have approximately 10x10 7 records and so on. Settings/Hardware/Software. The experiments have been done in two different settings: single-node architecture and a cluster of 3 physical nodes. Each node is a Unix machine (CentOs) with 4 core-i5 CPU, 8GB RAM, 2TB disks, 1Gb/s network. The cluster is composed of 3 nodes, each being a worker node and one node acts also as dispatcher. Each node has a MongoDB v. 3. 0 running. In MongoDB terminology, this setup corresponds to 3 shards (one per machine). One machine also acts as configuration server and client.
We observe data loading is significantly slower in a distributed setting than on a single machine. For instance, model M0 data (sf=1) loads for 1306s on a single cluster, while it needs 4246s in a distributed setting. This is mainly due to penalization related to network data transfer. Indeed, MongoDB balances data load i. e. it tries to distribute equally data across all shards implying more network communication. Querying. We test each instantiation (on 4 data models) on 3 sets of OLAP queries (QS1, QS2, QS3). To do so, we use the SSB benchmark query generator that generates 3 query variants per set. The query complexity increases from QS1 to QS3. QS1 queries filter on one dimension and aggregate all data; QS2 queries filter data on 2 dimensions and group data on one dimension; and QS3 queries filter data on 3 dimensions and group data on 2 dimensions.
In Table  3  and 4 , we show query execution times on all query variants with scale factor sf=1, all models, in two settings (single node and cluster). For the queries with 3 variants, results are averaged (arithmetic mean). In Table  3 , we can compare averaged execution times per query and model in the single node setting. In Table  4 , we can compare execution times in the distributed (cluster) setting. We observe that for some queries some models work better and for others some other models work better. We would have expected queries to run faster on models M0 and M1 because data is in a denormalized fashion (no joins needed). This is surprisingly not the case. Query execution times are comparable across all models and sometimes queries run faster for models M2 and M3. This is partly because we could optimize queries choosing from the MongoDB rich palette: aggregation pipeline, map/reduce, simple queries and procedures.
For M2 and M3, we need to join data from more than one document at a time. When we do not write the most efficient MongoDB query and/or when we join all data needed for the query before any filtering, execution times can be significantly higher. Instead we apply filters before joins and then we use the aggregation pipeline , map/reduce functions, simple queries or procedures. We also observed the SSB queries had high selectivity. We could filter most records before needing any join. To test selectivity impact, we tested querying performance on another query Q4 that is obtained by modifying one of the queries from QS1 to be more selective. On this new query set we have about 500000 facts after filtering. We observe that query execution on data with models M0 and M1 is lower about 20-30%. Meanwhile, on data with models M2 and M3 query execution is respectively about 5-15 times slower.
OLAP Cuboids with Documents OLAP Cuboid. It is common in OLAP applications to pre-compute analysis cuboids that aggregate fact measures on different dimension combinations. In our example (SSB dataset), there are 4 dimensions C: Customer, S: Supplier, D: Date and P: Part. In Figure  3 , we show all possible dimension combinations. Data can be analyzed on no dimension (all), 1 dimension, 2 dimensions or 3 dimensions or 4 dimensions. Cuboid names are given with dimension initials, e. g. CSP stands for cuboid on Customer, Supplier and Part. In Figure  3 , we show for illustration purposes the computation time for a complete lattice in M0. In this case, we compute lower level cuboids from the cuboid just on top to make things faster. In Table  2  we show the average time needed to compute an OLAP cuboid of x dimensions (x can be 3, 2, 1, 0, i.
Document-oriented Data Warehouses versus Relational Data Warehouses In this section, we compare loading times and querying between data warehouse instantiations on document-oriented and relational databases. In document-oriented systems, we consider the data model M0, because it performs better than the others. In the relational database, we consider two models R0 and R2 mentioned earlier. For R0, data is denormalized, everything is stored in one table: fact and dimension data. For R2, data is stored in a starlike schema i. e. the fact data is stored in one table and each dimension data is stored in a separate table. Loading. First of all, we observe that relational databases demand for much less memory than document-oriented systems. Precisely, for scale factor sf=1, we need 15GB for data model M0 in MongoDB.
Instead we need respectively 4. 2GB and 1. 2GB for data models R0 and R2 in PostgreSQL. This is easily explained. Document-oriented systems repeat field names on every document and specifically in MongoDB data types are also stored. To store data with flat models we need about 4 times more space, due to data redundancy. The same proportions are also observed on loading times. Querying. We first compare query performance on the 4 query sets defined earlier (QS1, QS2, QS3, Q4) on a single node. We observe immmediately that queries run significantly faster on PostgreSQL (20 to 100 times). This is partly due to the relatively high selectivity of the considered queries. Almost all data fits in memory. In addition, we considered OLAP queries that correspond to the computation of OLAP cuboids. These queries are computationally more expensive than the queries considered previously (QS1, QS2, QS3, Q4).
More precisely, we consider here the generation of OLAP cuboids on combinations of 3 dimensions. We call this query set QS5. Average execution times on all query sets are shown in Table  5. We observe that the situation is reversed on this query set. Query execution times are comparable to each other. Queries run faster on MongoDB with data model R0 (singlenode) than on PostgresSQL. Queries run fastest on PostgreSQL with data model R2. MongoDB is faster if we consider the distributed setting. On these queries we have to keep in memory much more data than for queries in QS1, QS2, QS3 and QS4. Indeed, on the query sets QS1, QS2, QS3 and QS4 the amount of data to be processed is reduced by filters (equivalent of SQL where instructions). Then data is grouped on fewer dimensions (0 to 2). The result is fewer data to be kept in memory and fewer output records.
CONCLUSIONS In this paper, we have studied the instantiation of data warehouses with document-oriented systems. For this purpose, we formalized and analyzed four logical models. Our study shows weaknesses and strengths across the models. We also compare the best performing data warehouse instantiation in document-oriented systems with 2 instantiations in relational database. Depending on queries and data warehouse usage, we observe that the ideal model differs. Some models require less disk space, more precisely M2 and M3. This is due to the redundancy of data in models M0 and M1 that is avoided with models M2 and M3. For highly selective queries, we observe no ideal model. Queries run sometimes faster on one model and sometimes on another. The situation changes fast when queries are less selective.
On data with models M2 and M3, we observe that querying suffers from joins. For queries that are poorly selective, we observe a significant impact on query execution times making these models non-recommendable. We also compare instantiations of data warehouses on a document-oriented system with a relational system. Results show that RDBMS is faster on querying raw data. But performance slows down quickly when data does not fit on main memory. Instead, the analysed document-oriented system is shown more robust i. e. it does not have significant performance drop-off with scale increase. As well, it is shown to benefit from distribution. This is a clear advantage with respect to RDBMS that do not scale well horizontally; they have a lower maximum database size than NoSQL systems. In the near future, we are currently studying another document-oriented system and some columnoriented systems with the same objective.
In addition to basic functionality, it contains pose estimation and face frontalisation algorithms. With the tools presented in this paper, we aim to close two gaps. First, by offering different model resolution levels and fast fitting functionality, we enable the use of a 3D Morphable Model in time-critical applications like tracking. Second, the software library makes it easy for the community to adopt the 3D Morphable Face Model in their research, and it offers a public place for collaboration.
In 2009, Vetter et al. published the Basel Face Model (BFM,  (Paysan et al. , 2009) ) to spur research with Morphable Models. It surpassed existing models  (Sarkar, 2005; Blanz and Vetter, 1999)  by the accuracy of the scanner used and the quality of the registration algorithm, and their multi-segment face model, along with fitting results and various metadata, can be obtained after signing a licence agreement. While this led to some adoption by other research groups (e. g. (van Rootseler et al. , 2012; Aldrian and Smith, 2013) ), the adoption is still limited. Additionally, while the BFM provides the model, they only provide fitting results for limited databases and do not provide algorithms to apply the model to novel images. With the model and software framework published in this paper, we aim to go one step further and make our model available as well as a lightweight fitting framework promoting the use of the model.
This paper introduces the Surrey Face Model (SFM), a multi-resolution 3D Morphable Face Model. The model consists of three different resolution levels of shape and colour, a pose-invariant image texture representation and metadata such as landmark point information. The model is available freely for non-commercial purposes. Alongside the model, we present a library to interface with the model and perform basic pose and shape fitting. The main focus of the software is its ease of use and interoperability with the popular OpenCV library. The library is open source, available under Apache License, Version 2. 0, and actively developed on GitHub, creating a public place for exchange and contributions. In addition to the full 3DMM being available via the University, we release a low-resolution shape-only model distributed within the software.
In contrast to the Basel Face Model, we offer the models at lower resolutions as well, which are much more practical for many applications. We focus on ease of use of the framework for vision tasks such as face tracking, pose estimation and face frontalisation, and hope to further pave the way to make 3DMMs more widely adopted. Table  1  summarises how the different parts are available. The contributions of this work are threefold. First, we present the Surrey Face Model, a multi-resolution 3D Morphable Face Model that we make available to the public for non-commercial purposes. Second, we present a lightweight open-source Morphable Model software framework written in modern C++ that is designed with simplicity and ease of integration as its primary goals. Lastly, we make a low resolution shape model available together with the software to allow an immediate start with the framework.
3D Scan Data The Surrey Face Model is built using a number of high-resolution 3D scans that were acquired at our lab. The scans were captured using a 3dMDface 2  camera system that consists of two structured light projectors, 4 infrared cameras that capture the light pattern and are used to reconstruct the 3D shape, and two RGB cameras recording a high-resolution face texture. Half the cameras record the face from the left side, the other half from the right side, resulting in a 180 • view of the face. The images are acquired under uniform illumination to ensure that the model texture is representative of face skin albedo only. The 3dMDface software reconstructs a textured 3D mesh from this information. These scans can then be brought into dense correspondence using a 3D to 3D registration algorithm, in our case the Iterative Multi-resolution Dense 3D Registration (IMDR) method  (Tena et al.
Shape and Colour Model The shape and colour PCA models are built using aforementioned 169 registered scans. Of the resulting PCA basis matrix, we keep 63 shape eigenvectors and 132 colour eigenvectors so that 99% of the original variation of the data is preserved after reconstruction. To analyse the variations in the face model, we can visualise the directions of largest variance in the PCA space by taking the formula in Equation 2 and setting a specific α i to a fixed value while setting all others to zero. The resulting face mesh S can then be rendered. Figure  4  shows the mean of the model Along with the model, we publish annotations of the most commonly used facial landmark points for all resolution levels. When using the model, it is useful to have a standardised and known set of the location (i.
SOFTWARE FRAMEWORK The Surrey Face Model is accompanied by an open source software framework that is available on GitHub under Apache License, Version 2. 0. It is a lightweight and cross-platform header-only library built using modern C++, which makes it very flexible, easy to use and simple to include into existing software. The library requires no other dependency than applications developed using it linking to OpenCV-core. The software framework includes a low-resolution shape-only model (sfm shape 3448) to facilitate immediate use. This section will first give a brief introduction about the core functionality of the framework and then present the pose and landmark fitting algorithms included in the software and a basic use case example. The library, low-resolution shape model, example applications and a complete documentation are available at https://github.