dataesr/scientific-paragraphs-categorization huggingface dataset:
Target class content. Human UniProtKB accession counts An interaction is only considered part of GtoImmuPdb where both the target and ligand are tagged as relevant to immunopharmacology. The table shows just under one quarter of all the curated interactions in GtoPdb involve targets and ligands of immunological relevance (we are still in the process of identifying these so it is likely to increase). The table includes a comparison to the figures from the 2016 update (5), and a breakdown for the GtoImmuPdb dataset. Categories are not mutually exclusive and targets and ligands can fall into more than one, therefore totals are not the sum of all other rows. 7TM receptors* 395 395 (0) Nuclear hormone receptors 48 48 (0) Catalytic receptors 239 243 (+4) Ligand-gated ion channels 84 81 (-3) Voltage-gated ion channels 141 144 (+3) Other ion channels 47 49 (+2) Transporters 508 509 (+1) Enzymes (all) 1164 1184 (+20) Kinases 539 546 (+7) Proteases 240 243 (+3) Other proteins 135 174 (+39) Total number of targets 2761 2834 (+73) 420** B.
** Thirty-five targets are tagged in GtoImmuPdb but have no Human UniProtKB accession. Thirty-four of these are complexes (only subunits have UniProtKB accessions, and 1 that only has a mouse accession). *** Primary target indicates the dominant Molecular Mechanism of Action (MMOA) **** 501)ubMed (https://www. ncbi. nlm. nih. gov/pubmed/)abstracts. Curated databases such as GtoPdb and ChEMBL(21)extract these parameters into a database format which facilitates findability and re-use. We have introduced interactive charts to summarize ligand activity at targets and compare pharmacological parameters across species. The bioactivity visualization tool uses data from GtoPdb and ChEMBL to present box plots summarising reported activities for a ligand at different targets. The charts show various pharmacological parameters expressed as -log 10.
Similarly,  [Rasiwasia and Vasconcelos (2009) ] used co-clustering to model scenes. We have presented here with a very brief survey demonstrating the diversity of co-clustering applications. Unfortunately, many of the algorithms developed above for co-clustering are suitable in that particular context only and cannot be considered as generic framework. Here, we take the opportunity to emphasize on the fact that the algorithms used in our software can be more or less adopted in most or all the above context. In practice, several softwares exist for block clustering such as Bicat  [Barkow, Bleuler, Prelic, Zimmermann, and Zitzler (2006) ], biclust  [Kaiser and Leisch (2008) ], BiGGEsTS  [Goncalves, Madeira, and Oliveira (2009) ], or refer to  [Madeira and Oliveira (2004) ] for a review. In this paper, we introduce our R  [R Development Core Team (2008) ] package blockcluster, which provides a bridge between a newly developed C++ library and the R statistical computing environment.
The R package blockcluster allows to estimate the parameters of the co-clustering models  [Govaert and Nadif (2003) ] for binary, contingency and continuous data. This package is unique from the point of view of generative models it implements (latent blocks), the used algorithms (BEM, BCEM) and, apart from that, special attention has been given to design the library for handling very huge data sets in reasonable time. The R package is already available on CRAN at http://cran. r-project. org/web/packages/blockcluster/index. html. The rest of the article is organized as follows. In Section 2, we give the mathematical foundation (without going into detailed proofs) of latent block models for binary, contingency and continuous data-sets. In Section 3, we elaborate various details of blockcluster package and illustrate its usage with the help of various examples.
If not, one may need to increase these values. In practice, it is better to increment 'nbxem' as it could lead to better (stable) results without compromising too much the running time. In the package blockcluster, we have a function called cocluststrategy 1 which allow to set the values of various input parameters including 'nbxem' and 'nbtry'. In the following example, we get an object defaultstrategy of S4 class strategy by calling the function cocluststrategy without any arguments and then we called the overloaded function summary to see various default values. 1 This function is also use to set all other input parameters like number of iterations and tolerance values. They are not described here explicitly for the sake of brevity. We refer our readers to the package documentation for details.
Hence we can apply the model 'pik_rhol_unknown' available in our package for contingency (Poisson Family) datasets with unknown row and column effects. Table  5  shows the confusion matrix and compare our results with classical bipartite spectral graph partitioning algorithm of  [Dhillon (2001) ] where we have obtained 100 percent correct classification. Figure  6  depicts the 2 × 2 checkerboard pattern in the data matrix, hence confirming the more frequent occurrence of particular set of words in one document and vice-versa. Please note that the data matrix images are extremely sparse (data points almost invisible) and have been processed using simple image processing tools for visualization purpose only. [Dhillon (2001) ] (a), and Results using blockcluster (b). The difference in number of Cranfield documents is because we made use of the readymade data extracted from the documents and there are two less documents data in the same.
Appendices A. The core library: Structure and usage In this paper we have given detailed analysis on the usage of R package blockcluster to estimate parameters of latent block models, but behind the scenes the kernel (computational) part lies in the C++ core library 2. Our purpose to put this section is only to briefly introduce the kernel part and partly for developers who might be interested in integrating the library with their own codes, but we highly recommend to use only the R package blockcluster for research purposes as lot of utilities are absent in the C++ codes for instance the graphics part.
Introduction Database management systems (DBMS) emerged as a flexible and cost-effective solution to information organization, maintenance and access problems found in organizations (e. g. , business, academia and government). DBMS addressed these problems under the following conditions: (i) with models and long-term reliable data storage capabilities; (ii) providing retrieval and manipulation facilities for stored data for multiple concurrent users or transactions  [40]. The concept of data model (most notably the relational models like the one proposed by Codd  [29] ; and the object-oriented data models  [8] ; Cattell and Barry  [25] ), the Structured Query Language (SQL, Melton and Simon  [81] ), and the concept of transaction (Gray and Reuter  [57] ) are crucial ingredients of successful data management in current enterprises.
Today, the data management market is dominated by major object-relational database management systems (OR-DBMS) like Oracle, 1 DB2, 2 or SQLServer. 3 These systems arose from decades of corporate and academic research pioneered by the creators of System R  [6]  and Ingres  [97]. Since their emergence, innovations and extensions have been proposed to enhance DBMS in power, usability, and spectrum of applications (see Fig. 1 ). The introduction of the relational model  [29] , prevalent today, addressed the shortcomings of earlier data models. Subsequent data models, in turn, were relegated or became complementary to the relational model. Further developments focused on transaction processing and on extending DBMS to support new types of data (e. g. , spatial, multimedia, etc. ), data analysis techniques and systems (e.
g. , data warehouses, OLAP systems, data mining). The evolution of data models and the consolidation of distributed systems made it possible to develop mediation infrastructures  [109]  that enable transparent access to multiple data sources through querying, navigation and management facilities. Examples of such systems are multi-databases, data warehouses, Web portals deployed on Internet/Intranets, polyglot persistence solutions  [78]. Common issues tackled by such systems are (i) how to handle diversity of data representations and semantics? (ii) how to provide a global view of the structure of the information system while respecting access and management constraints? (iii) how to ensure data quality (i. e. , freshness, consistency, completeness, correctness)? Besides, the Web of data has led to Web-based DBMS and XML data management systems serving as pivot models for integrating data and documents (e.
g. , active XML). The emergence of the Web marked a turning point, since the attention turned to vast amounts of new data outside of the control of a single DBMS. This resulted in an increased use of data integration techniques and exchange data formats such as XML. However, despite its recent development, the Web itself has experienced significant evolution, resulting in a feedback loop between database and Web technologies, whereby both depart from their traditional dwellings into new application domains. Figure  2  depicts the major shifts in the use of the Web. A first phase saw the Web as a mean to facilitate communication between people, in the spirit of traditional media and mainly through email. Afterward, the WWW made available vast amounts of information in the form of HTML documents, which can be regarded as people-tomachines communication.
By partitioning the input data among multiple processors and memories, an operator can often be split into many independent operators, each working on a part of the data. This partitioned data and execution leads to partitioned parallelism that can exploit available computing resources. In this context, we can identify three major aspects that involve database and Web technologies, and that are crucial for satisfying the new information access requirements of users: (i) a large number of heterogeneous data sources accessible via standardized interfaces, which we refer to as data services (e. g. , Facebook, Twitter); (ii) computational resources supported by various platforms that are also publicly available through standardized interfaces, which we call computation services (e. g. , hash Amazon E3C service); (iii) mobile devices that can both generate data and be used to process and display data on behalf of the user.
From Monolithic to Customizable DBMS Architectures Different kinds of architectures serve different purposes. The ANSI/SPARC  [1]  architecture (Fig. 3 ) that characterizes classic database management systems (relational, object oriented, XML) deployed on client-server architectures has evolved in parallel to the advances resulting from new application requirements, data volumes, and data models. The 3-level-schema architecture reflects the different levels of abstraction of data in a database system distinguishing: (i) the external schemata that users work with, (ii) the internal integrated schema of the entire database; (iii) the physical schema determining the storage and the organization of databases on secondary storage. The structure of a monolithic DBMS shown in Fig. 4  shows three key components of the system: the storage manager, the transaction manager, and the schema manager.
During the last twenty years, in order to better match the evolution of user and application needs, many extensions have been proposed to enhance the DBMS functions. In order to meet all new requirements, DBMS were extended to include new functionalities. Extensible and personalizable database systems  [22]  were an attempt to ease the construction of DBMS by exploiting software reusability  [51] , and proposing a general core that can be customized or extended, or even used to generate some DBMS parts. Trade-offs between modularity and efficiency, granularity of services, and the number of inter-service relationships result in DBMS designs which lack customizability. 7 A study of the standard task-oriented architecture of DBMS can be useful to determine their viability in new environments and for new applications.
OODBMS: Relaxing Data Management and Program Independence The first evolution of DBMS is when the object-oriented (OO) paradigm emerged, and the logic and physical levels started to approach for providing efficient ways of dealing with persistent objects. Together with the OO paradigm emergence, it was possible to develop applications requiring databases that could handle very complex data, that could evolve gracefully, and that could provide the high-performance dictated by interactive systems. Database applications could be programmed with an OO language, and then object persistence was managed by an Object-Oriented DBMS (OODBMS). The OODBMS manifesto  [8]  stated that persistence should be orthogonal, i. e. , each object, independent of its type, is allowed to become persistent as such (i.
e. , without explicit translation). Persistence should also be implicit: the user should not have to explicitly move or copy data to make it persistent. This implied also that transparency was enforced regarding secondary storage management (index management, data clustering, data buffering, access path selection and query optimization). Extensible database systems  [22]  allowed new parts such as abstract data types or index structures to be added to the system. Enhancing DBMS with new Abstract Data Type (ADT) or index structures was pioneered in the Ingres/Postgres systems  [77, 99, 100]. Ingres supports the definition of new ADTs, including operators. References to other tuples can be expressed through queries (i. e. , the data type postquel), but otherwise ADTs, and their associated relations, still had to be in first normal form.
Component-Oriented DBMS: Personalizing Data Management Component aware  [43, 47, 72, 84, 85, 88, 102]  was a paradigm to address reusability, separation of concerns (i. e. , separation of functional from non-functional concerns) and ease of construction. 10 Component-based systems are built by putting components together to form new software systems. Systems constructed by composition can be modified or extended by replacing or adding new components (Fig. 5 ). Approaches to extend and customize DBMS adopted the component-oriented paradigm for designing at least the customizable modules of the architecture, as components. Plug-in components are added to functionally complete DBMS and fulfill specialized needs. The components of component database management systems (CDBMS) are families of base and abstract data types or implementations of some DBMS function, such as new index structures.
Database Middleware Another way of addressing DBMS ''componentization'' was to provide database middlewares. Such middlewares leave data items under the control of their original (external) management systems while integrating them into a common DBMS-style framework. External systems exhibit, in many cases, different capabilities, such as query languages with varying power or no querying facilities at all. The different data stores might also have different data models (i. e. , different data definition and structuring means), or no explicit data model at all. The goal of graceful integration is achieved through componentization. The architecture introduces a common (intermediate) format into which the local data formats can be translated. Specific components perform this kind of translation.
Besides, common interfaces and protocols define how the database middleware system and the components should interact (e. g. , in order to retrieve data from a data store). These components (called wrappers) are also able to transform requests issued via these interfaces (e. g. , queries) into requests understandable by the external system. In other words, these components implement the functionality needed to access data managed by the external data store. Examples of this approach include Disco [104], Garlic  [92] , OLE DB  [15] [16] [17] , Tsimmis  [49] , Harmony  [91]  (which implemented the CORBA query service), and Sybase Adaptive Server Enterprise  [86]. Sybase allows access to external data stores, in Sybase called specialty data stores, and other types of database systems. ADEMS  [21, 32]  proposes mediation cooperative components or services that can broker and integrate data coming from heterogeneous sources.
Configuring and Unbundling Data Management Configurable DBMS rely on unbundled DBMS tasks that can be mixed and matched to obtain database support (see Fig. 6 ). The difference lies in the possibility of adapting functions (called services) implementations to new requirements or in defining new services whenever needed. Configurable DBMS also consider services as unbundled representations of DBMS tasks. However, the models underlying the various services, and defining the semantics of the corresponding DBMS parts can now, in addition, be customized. Components for the same DBMS task can vary not only in their implementations for the same standardized interface, but also in their interfaces for the same task. DBMS implementors select (or construct new) components implementing the desired functionality, and obtain a DBMS by assembling the selected components.
GENESIS  [12, 13]  is a transformational approach that supports the implementation of data models as a sequence of layers. The interface of each layer defines its notions of files, records, and links between files. Transformations themselves are collected in libraries, so that they can be reused for future layer implementations. Another transformational approach that uses specification constructs similar to those of Acta  [28]  has been described by  [50]. EXODUS  [23]  applies the idea of a toolkit for specific parts of the DBMS. A library is provided for access methods. While the library initially contains type-independent access methods such as B-trees, grid files, and linear hashing, it can also be extended with new methods. Other examples are the Open OODB (Open Object-Oriented Database) approach  [14, 108] , Trent  [70]  for the construction of transaction managers (mainly, transaction structures and concurrency control) and '' ala carte''  [42]  for the construction of heterogeneous DBMS.
One problem in any toolkit approach is the consistency (or compatibility) of reused components. Generation approaches instead support the specification of (parts of) a DBMS functionality and the generation of DBMS components based on those specifications. A programmer defines a model (e. g. , an optimizer, a data model, or a transaction model), which is given as input to a generator. The generator then automatically creates a software component that implements the specified model based on some implementation base (e. g. , a storage manager or kernel in the case of data model software generation). An example of a generator system is the EXODUS query-optimizer generator  [55]. Volcano  [56] , the successor of the EXODUS optimizer generator, also falls into the group of generator systems. Volcano has been used to build the optimizer for Open OODB  [14].
Other frameworks for building query optimizers are the ones described in  [89] , Cascades  [54] , and EROC (Extensible Reusable Optimization Components)  [80]  and  [34, 107]. Framboise  [46]  and ODAS  [33, 105]  are frameworks for layering active database functionality on top of passive DBMS. However, customization at a finer granularity (i. e. , the components forming the DBMS) is expensive. Such customization is cost-effective if changes were localized without compromising the system performance. Such performance can be ensured through closely woven components, i. e. , both modularity and efficiency need to be preserved.
Service-Oriented DBMS Today the DBMS architecture has evolved to the notion of service-based infrastructure where services 12 are adapted and coordinated for implementing ad hoc data management functions (storage, fragmentation, replication, analysis, decision making, data mining). These functions are adapted and tuned for managing huge distributed multiform multimedia data collections. Applications can extend the functionality of DBMS through specific tasks that have to be provided by the data management systems, these tasks are called services, and allow interoperability between DBMS and other applications  [52]. Subasu et al. [101]  proposes a database architecture on the principles of service-oriented architecture (SOA) as a system capable of handling different data types, being able to provide methods for adding new database features (see Fig.
7 ). The service-based data management system (SBDMS) architecture borrows the architectural levels from Ha ¨rder  [62] , and includes new features and advantages introduced by SOA into the field of database architecture. It is organized into functional layers that each with specialized services for specific tasks. Storage services work on the byte level, in very close collaboration with file management functions of the operating system. These services have to handle the physical specifications of each non-volatile device. In addition, they provide services for updating existing data and finding stored data, propagating information from the Access Services Layer to the physical level. Since different data types require different storage optimizations, special services are created to supply their particular functional needs.
This layer is equivalent to the first and second layer of the five layer architecture presented by Ha ¨rder and Reuter  [62, 65]. Access services is in charge of the physical data representations of data records and provides access path structures like B-trees. It provides more complex access paths, mappings, particular extensions for special data models, that are represented in the Storage Services Layer. Moreover, it is responsible for sorting record sets, navigating through logical record structures, making joins, and similar higher-level operations. This layer represents a key factor to database performance. The Access Services Layer has functions that are comparable to those in the third and fourth layer as presented by Ha ¨rder and Reuter  [62, 65]. Data services provide data represented in logical structures like tables or views.
These are data structures without any procedural interface to the underlying database. The Data Service Layer can be mapped to the Non-Procedural and Algebraic Access level in the architecture by Ha ¨rder and Reuter  [62, 65]. Extension services users can design tailored extensions for example, creating new services or reusing existing ones from any available service from the other layers. These extensions help to manage different data types like XML files or streaming data. In this layer, users can integrate application-specific services in order to provide specific data types or specific functionalities needed by their applications (e. g. , for optimization purposes). A service-based DBMS externalizes the functions of the different systems layers, and enables the programming of personalized data management as a service systems.
They make it possible to couple the data model characteristics with well adapted management functions that can themselves be programmed in an ad hoc manner. The DBMS remains a general purpose system that can be personalized, thanks to service composition, to provide ad hoc data management. It is then possible to have services deployed in architectures that make them available to applications in a simple way (e. g. , cluster, cloud). Fig. 7  Service-oriented DBMS  [101]  12 Services in the SOA approach are software elements accessible through a well defined interface without requiring any knowledge on their implementation. SOAs can be implemented through a wide range of technologies like RPC, RMI, CORBA, COM, and Web services, not making any restrictions on the implementation protocols. In general, services can communicate using an arbitrary protocol, for example, they can use a file system to send data between their interfaces.