dataesr/scientific-paragraphs-categorization huggingface dataset:
Instance and Resource Extraction From the extracted metadata we are able to identify all the resources associated with that dataset. They can have various types like a SPARQL endpoint, API, file, visualization, etc. However, before extracting the resource instance(s) we perform the following steps: -Resource metadata validation and enrichment: Check the resource attached metadata values. Similar to the dataset metadata, each resource should include information about its mimetype, name, description, format, valid de-referenceable URL, size, type and provenance. The validation process issues an HTTP request to the resource and automatically fills up various missing information when possible, like the mimetype and size by extracting them from the HTTP response header. However, missing fields like name and description that needs manual input are marked as missing and will appear in the generated summary report.
10 http://demo. ckan. org/api/3/action/package show?id=adur district spending. -Format validation: Validate specific resource formats against a liter or a validator. For example, node-csv  11  for CSV files and n3 12 to validate N3 and Turtle RDF serializations. Considering that certain datasets contain large amounts of resources and the limited computation power of some machines on which the framework might run on, a sampler module can be introduced to execute various sample-based strategies detailed as they were found to generate accurate results even with comparably small sample size of 10 %. These strategies introduced in  [12]  are: -Random Sampling: Randomly selects resource instances. -Weighted Sampling: Weighs each resources as the ratio of the number of datatype properties used to define a resource over the maximum number of datatype properties over all the datasets resources.
Profile Validation A dataset profile should include descriptive information about the data examined. In our framework, we have identified three main categories of profiling information. However, the extensibility of our framework allows for additional profiling techniques to be plugged in easily (i. e. a quality profiling module reflecting the dataset quality). In this paper, we focus on the task of metadata profiling. Metadata validation process identifies missing information and the ability to automatically correct them. Each set of metadata (general, access, ownership and provenance) is validated and corrected automatically when possible. Each profiler task has a set of metadata fields to check against. The validation process check if each field is defined and if the value assigned is valid.
There exist many special validation steps for various fields. For example, the email addresses and urls should be validated to ensure that the value entered is syntactically correct. In addition to that, for urls, we issue an HTTP HEAD request in order to check if that URL is reachable. We also use the information contained in a valid content-header response to extract, compare and correct some resources metadata values like mimetype and size. From our experiments, we found out that datasets' license information is noisy. The license names if found are not standardized. For example, Creative Commons CCZero can be also CC0 or CCZero. Moreover, the license URI if found and if de-referenceable can point to different reference knowledge bases e. g. , http://opendefinition. org. To overcome this issue, we have manually created a mapping file standardizing the set of possible license names and the reference knowledge base  13.
Profile and Report Generation The validation process highlights the missing information and presents them in a human readable report. The report can be automatically sent to the dataset maintainer email if exists in the metadata. In addition to the generated report, the enhanced profiles are represented in JSON using the CKAN data model and are publicly available  15. Data portal administrators need an overall knowledge of the portal datasets and their properties. Our framework has the ability to generate numerous reports of all the datasets by passing formatted queries. There are two main sets of aggregation tasks that can be run: -Aggregating meta-field values: Passing a string that corresponds to a valid field in the metadata. The field can be flat like license title (aggregates all the license titles used in the portal or in a specific group) or nested like resource>resource type (aggregates all the resources types for all the datasets).
Such reports are important to have an overview of the possible values used for each metadata field. -Aggregating key:object meta-field values: Passing two meta-field values separated by a colon : e. g. , resources>resource type:resources>name. These reports are important as you can aggregate the information needed when also having the set of values associated to it printed. For example, the meta-field value query resource>resource type run against the LODCloud group will result in an array containing [f ile, api, documentation. ] values. These are all the resource types used to describe all the datasets of the group. However, to be able to know also what are the datasets containing resources corresponding to each type, we issue a key:object meta-field query resource>resource type:name. The result will be a JSON object having the resource type as the key and an array of corresponding datasets titles that has a resource of that type.
Experiments and Evaluation In this section, we provide the experiments and evaluation of the proposed framework. All the experiments are reproducible by our tool and their results are available in its Github repository. A CKAN dataset metadata describes four main sections in addition to the core dataset's properties. These sections are: -Resources: The distributable parts containing the actual raw data. They can come in various formats (JSON, XML, RDF, etc. ) and can be downloaded or accessed directly (REST API, SPARQL endpoint). -Tags: Provide descriptive knowledge on the dataset content and structure. They are used mainly to facilitate search and reuse. -Groups: A dataset can belong to one or more group that share common semantics. A group can be seen as a cluster or a curation of datasets based on shared categories or themes.
-Organizations: A dataset can belong to one or more organization controlled by a set of users. Organizations are different from groups as they are not constructed by shared semantics or properties, but solely on their association to a specific administration party. Each of these sections contains a set of metadata corresponding to one or more type (general, access, ownership and provenance). For example, a dataset resource will have general information such as the resource name, access information such the resource url and provenance information such as date. The framework generates a report aggregating all the problems in all these sections, fixing field values when possible. Errors can be the result of missing metadata fields, undefined field values or field value errors (e. g. unreachable URL or incorrect email addresses).
Experimental Setup We ran our tool on two CKAN-based data portals. The first one is datahub. io targeting specifically the LOD cloud group. The current state of the LOD cloud report  [27]  indicates that the LOD cloud contains 1014 datasets. They were harvested via a LDSpider crawler  [16]  seeded with 560 thousands URIs. Roomba, on the other hand, fetches datasets hosted in data portals where datasets have attached relevant metadata. As a result, we relied on the information provided by the Datahub CKAN API. Examining the tags available, we found two candidate groups. The first one tagged with "lodcloud" returned 259 datasets, while the second one tagged with "lod" returned only 75 datasets. After manually examining the two lists, we found out the datasets grouped with the tag "lodcloud" are the correct ones.
To qualify other CKAN-based portals for the experiments, we use http://dataportals. org/ which contains a comprehensive list of Open Data portals from around the world. In the end, we chose the Amsterdam data portal  16. The portal was commissioned in 2012 by the Amsterdam Economic Board Open Data Exchange (ODE) and covers a wide range of information domains (energy, economy, education, urban development, etc. ) about Amsterdam metropolitan region. We ran the Roomba instance and resource extractors in order to cache the metadata files for these datasets locally and ran the validation process. The experiments were executed on a 2. 6 Ghz Intel Core i7 processor with 16 GB of DDR3 memory machine. The approximate execution time alongside the summary of the datasets' properties are presented in Table  1.
Profiling Correctness To measure profile correctness, we need to make sure that the issues reported by Roomba are valid on the dataset, group and portal levels. On the dataset level, we choose three datasets from both the LOD Cloud and the Amsterdam data portal. The datasets details are shown in Table  2. To measure the profiling correctness on the groups level, we selected four groups from the Amsterdam data portal containing a total of 25 datasets. The choice was made to cover groups in various domains that contain a moderate number of datasets that can be checked manually (between 3-9 datasets). Table  3  summarizes the groups chosen for the evaluation. After running Roomba and examining the results on the selected datasets and groups, we found out that our framework provides 100 % correct results on the individual dataset level and on the aggregation level over groups.
Since our portal level aggregation is extended from the group aggregation, we can infer that the portal level aggregation also produces complete correct profiles. However, the lack of a standard way to create and manage collections of datasets was the source of some errors when comparing the results from these two portals. For example, in Datahub, we noticed that all the datasets groups information were missing, while in the Amsterdam Open Data portal, all the organisation information was missing. Although the error detection is correct, the overlap in the usage of group and organization can give a false indication about the metadata quality.
Profiling Completeness We analyzed the completeness of our framework by manually constructing a set of profiles that act as a golden standard. These profiles cover the range of uncommon problems that can occur in a certain dataset  17. These errors are: -Incorrect mimetype or size for resources; -Invalid number of tags or resources defined; -Check if the license information can be normalized via the license id or the license title as well as the normalization result; -Syntactically invalid author email or maintainer email. After running our framework at each of these profiles, we measured the completeness and correctness of the results. We found out that our framework covers indeed all the metadata problems that can be found in a CKAN standard model correctly.
Conclusion and Future Work In this paper, we proposed a scalable automatic approach for extracting, validating, correcting and generating descriptive linked dataset profiles. This approach applies several techniques in order to check the validity of the metadata provided and to generate descriptive and statistical information for a particular dataset or for an entire data portal. Based on our experiments running the tool on the LOD cloud, we discovered that the general state of the datasets needs attention as most of them lack informative access information and their resources suffer low availability. These two metrics are of high importance for enterprises looking to integrate and use external linked data. It has been noticed that the issues surrounding metadata quality affect directly dataset search as data portals rely on such information to power their search index.
We noted the need for tools that are able to identify various issues in this metadata and correct them automatically. We evaluated our framework manually against two prominent data portals and proved that we can automatically scale the validation of datasets metadata profiles completely and correctly. As part of our future work, we plan to introduce workflows that will be able to correct the rest of the metadata either automatically or through intuitive manually-driven interfaces. We also plan to integrate statistical and topical profilers to be able to generate full comprehensive profiles. We also intend to suggest a ranked standard metadata model that will help generate more accurate and scored metadata quality profiles. We also plan to run this tool on various CKAN-based data portals, schedule periodic reports to monitor the evolvement of datasets metadata.
However, they suggested from visual inspection that the articles with highest citation rates scored intermediate levels of interdisciplinarity, implying an inverted U-shape relationship between interdisciplinarity and citation impact. Levitt and Thelwal  [47]  found that number of citation to multidisciplinary journals (those related to more than one disciplinary category in the database) were roughly 50% less than monodisciplinary articles. This correlation was found using Scopus as data source and only for a limited number of disciplines in the natural sciences. When the analysis was focused on the social sciences neither in Scopus nor WoS were significant correlations found between the level of interdisciplinarity and the citation impact. A study conducted by Larivière and Gingras  [48]  analysing all articles included in the WoS in 2000, did not find a clear correlation between the proportion of citations to other disciplines (their indicator of interdisciplinarity) and the citations received.
Acknowledgments This paper was presented in the Atlanta Science and Innovation Policy Conference in September 2011 and published in the DRUID 2013 Conference. We thank  Carlos Benito Amat ,  Dominik Hartmann ,  Alan Porter ,  Andy Stirling  and particularly  Ludo Waltman  for fruitful discussions. We are grateful to  Jian Wang  for sending us an unpublished working paper (now [61]) when we were finishing this manuscript. Alfredo Yegros  and  Ismael Rafols  acknowledge support from the  US National Science Foundation  (Award # 1064146  -" Revealing Innovation Pathways: Hybrid Science Maps for Technology Assessment and Foresight "). Ismael Rafols  is also supported with an  EC Marie Curie Integration Grant. The findings and observations.
the  Institute for Global Studies (FMSH-Paris) , the  Franco-Swedish Program on Economics and Philosophy (FMSH-Risksbankens Jubileumsfond) , and the  ANR  project  EquiRisk ,  Grant  #  ANR-12-INEG-0006-01. The authors thank audiences in Paris (FMSH and CES), Boston (SSCW congress) and at the  Kiel Institute for the World Economy (IfW Centenary Conference)  for their reactions and comments.
Sequencing the human genome began in 1994, and 10 years of work were necessary in order to provide a nearly complete sequence. Nowadays, NGS technologies allow sequencing of a whole human genome in a few days. This deluge of data challenges scientists in many ways, as they are faced with data management issues and analysis and visualization drawbacks due to the limitations of current bioinformatics tools. In this paper, we describe how the NGS Big Data revolution changes the way of managing and analysing data. We present how biologists are confronted with abundance of methods, tools, and data formats. To overcome these problems, focus on Big Data Information Technology innovations from web and business intelligence. We underline the interest of NoSQL databases, which are much more efficient than relational databases.
Introduction The revolution that next-generation sequencing (NGS)  [1]  brought about in biological sciences includes an enormous leap in the amount of data generated that needs to be stored and analysed in new ways. Storage and analysis have become critical questions. Efficient visualization methods are also needed so that the human mind can comprehend some of the rules that apply to "omics" data, be they genomics, transcriptomics, or other data from high-throughput experiments. In this paper, we aim to describe how the data have evolved, with a particular focus on DNA and RNA data and how biologists are confronted with an abundance of methods, "in-house" software, or community-developed tools, and with a variety of formats of data and databases. Many such methods imply that the biologist, to some extent, becomes proficient in some aspects of computing, and this has been a hurdle that some cannot bypass.
Furthermore, some biologists, who have not been trained in information technology (IT), underestimate the expertise and time needed to set up analysis tools, to calculate results, and to imagine visualization methods that are useful to the biologist. During the first decade of this century, an early step in the simplification of the use of bioinformatics was the development of workflow management software that allows the integration of multiple bioinformatics tools  [2, 3]. Their implementation made automatization and large-scale handling of data processing possible. Nonetheless, despite their efficacy, these tools do not provide satisfying solutions for the avalanche of NGS data now available. Indeed, since these tools are merely "containers" that standardize access to bioinformatics software, they cannot surpass the current limits of these types of software, which are not yet adapted to Big Data.
There is, therefore, still a need for new, interactive tools for scientists working in large projects involving different laboratories. The future, as data will continue to grow in size and complexity, lies in online analysis and storage for collaborative work, with methods that allow high interactivity with data for analysis and visualization. In this review, we will focus on IT solutions that have emerged for management and analysis of Big Data from other fields of knowledge, such as web and Business Intelligence. These have shown their usefulness in bioinformatics, and, although we are still in the early stages, they have been used in several projects, as we will describe in this review. The main points we will develop are, first, the management of data using NoSQL databases, which are much more efficient at handling Big Data than traditional databases.
They are also more flexible with regards to the integration of new data, than data models, which are the basis of relational databases. The second point we will focus on concerns the problem of loss of interactivity due to the processing time of Big Data analyses. This means that alternative hypotheses cannot be realistically tested. We will describe the emergence of answers from the Business Intelligence field that allow the processing of Big Data in real time. We will also present the case of the Amadea platform, whose interface is reminiscent of software for workflow management but is a high-performance environment for data management and analysis. Finally, we will discuss visualization tools for NGS data, and the important constraints due to the sheer size of the data. Genome Browsers are the current standard, but new tools are needed in order to be able to create in real-time graphics with web interfaces.
The GOLD database shows the dramatic increase in the number of genome sequences available thanks to these new technologies  [15] , (ii) rare variant discovery by whole genome resequencing or targeted sequencing, (iii) alternative splicing and sequence variation  [16] , (iv) ChIP-Seq  [17] , (v) transcriptome profiling of cells, tissues or organisms, (vi) identification of epigenetic markers for disease diagnosis, (vii) many more applications (for a review, see  [18] ). Such massive use of NGS technologies now generates huge amounts of data. This impressive increase of data allows new questions to be asked but also poses a number of technological and methodological challenges, as quoted many years ago in  [19]. These are real bioinformatics challenges ranging from questions dealing with informatics (e.
Bioinformatics Drawbacks Publication in scientific journals is often subjected to the obligation for the authors to provide the produced data in a specific form for the scientific community  [20]. For instance, protein structures are deposited in the Protein DataBank in standardized PDB format  [21]  and protein sequences in GenBank  [22]. Numerous databases have been created in relation with the major ones. The fact that classical formats as pdb, fasta, or others have been created has helped tremendously the achievement of many studies. Nonetheless, each new development has generated an impressive number of formats, without commonly accepted standards. Available tools are often not compatible and, thus, data has to undergo numerous transformations. A very representative example is the evolution of the PDB format, originally developed in the 1970s  [21] ; in the 1990s, crystallographers proposed an "improved" version named mmCIF  [23].
The majority of users considered that it involved too many major modifications, and, as a result, it was almost never used, and new developments were done mostly with the original PDB format. Nonetheless, the original PDB format is not applicable to large complexes which are composed of many thousands of residues and base pairs, and new formats named PDBx/mmCIF will finally replace the old PDB files in 2016. This is a typical example of how bioinformatics approaches have not evolved as fast as the technology for which they are useful. Concerning sequences, in the early 2000s, bioinformatics analyses focused on a gene or a dozen genes at most, and researchers had 227 databases  [24]  to obtain information about their subject of study. For these analyses, every scientist was developing small scripts and used a well-known and widespread spreadsheet software to have an overall view of their data.
Thus, the tool that was naturally chosen was the relational database. The major problem with this type of data structuring is that an a priori model of the data is required, and this, in effect, freezes them. We will see this in more detail in Section 5. 1. 1. In biology, concepts and technologies evolve very quickly, and new data formats appear frequently, forcing scientists to reconsider the structure of their data regularly. Heterogeneity is also characteristic of biological data. Every institution and every machine manufacturer has developed its own data format, making unification of data even harder. This justifies even more that researchers should be knowledgeable in programming languages, in order to use existing scripts or create new ones that parse the data and extract interesting information.
g. , Mat-Lab), some being usable with Windows, and another only with Linux, each one with a specific (and different) format  [28]. For some, we were not able to use them, even though we are proficient in bioinformatics. In addition, the number of databases available to scientists has increased sharply from 227 databases in 2004 to 1557 in 2014  [29]. Many of these databases are novel; many have disappeared for different reasons, despite efforts by some researchers to facilitate archiving of small databases  [30]. Here is the current problem which any researcher faces: how to effectively manage the heterogeneity of formats and data sources, tools, and how to extract relevant and reliable information  [31].