dataesr/scientific-paragraphs-categorization huggingface dataset:
The use of the UNA to detect errors in identity graphs is an inconsistencybased approach. This idea has been explored in  [12, 19]. Despite that UNA is a well-defined definition in relational database theory (a. k. a. Unique Name Axiom)  [18] , the lack of an agreed-upon definition of UNA in semantic web leads to different conclusions. The primitive adaption of UNA in semantic web postulates that any two ground terms with distinct names are non-identical  [12]. In the scope of integrated knowledge graphs, Valdestilhas et al. [19]  formalise this as any two URIs in the same knowledge base cannot refer to the same thing in the real world. We name this definition naive UNA, or nUNA for short. In practice, an integrated knowledge graph violates the nUNA if at least one of its connected components (from the identity graph) has two entities from the same source.
This helps the detection of spurious links. Note that removing the links between ex:Holland, Texas and ex:Holland and ex-fr:Pays-Bas results in three connected components, which are correct but still violate the nUNA. De Melo  [12]  points out that the Semantic Web is very different from traditional closed scenarios because multiple parties can publish data about the same entity using different identifiers. Thus, they propose to use a quasi-unique name constraint (quasi UNA, or qUNA) for entities: they use the namespace of an IRI as its source of provenance, with a focus on 6 major hubs including DBLP, DBpedia, FreeBase, GeoNames, MusicBrainz, and UniProt. This definition also takes into account some exceptions: two DBpedia entities from the same dataset/source do not violate the UNA if one redirects to the other, or either is a dead node (those that can no longer be resolved).
The iUNA When examining the data in the LOD Cloud, we note that identity links are often used to connect the same entity in different language, versions or encodings. Therefore, we propose our own definition of the UNA, which we call the internal UNA (iUNA), to take these differences into account. Our iUNA definition assumes that two different IRIs e1 and e2 within the same namespace should refer to distinct real-world entities only when: a) they are in the same knowledge base according to a certain provenance information, b) they don't satisfy any of the following exceptions: 8. if e 1 redirects to e 2 (or vice versa), or both redirect to the same location, 3. if at least one of e 1 and e 2 is a dead node, not found, unresolvable, redirects until reaching some error or has a timeout error while resolving.
We therefore propose two additional means for the estimation of provenance of an entity e. Table  1  provides a comparison of the three UNA definitions. Explicit sources: an explicit source of e is the object in any triple with subject e and predicate rdfs:isDefinedBy (or any equivalent or sub-properties). Implicit label-like sources: an implicit label-like source of e is the RDF file containing triples where e is the subject and rdfs:label (or any of its equivalent or sub-properties) is the predicate. Implicit comment-like sources: an implicit comment-like source of e is the RDF file containing triples where e is the subject and rdfs:comment (or any of its equivalent or sub-properties) is the predicate. We use the http://sameas. cc dataset  [4] , which provides the transitive closure of 558 million distinct owl:sameAs statements.
The goal is to maximise the sum of weights over all soft clauses while satisfying all the hard clauses. Note that if an SMT solver fails to get an optimal solution within the timeout, it will return the best sub-optimal solution (line 21). The edge (s, t) remains if and only if I s equals I t in the model m (line 22). The weighting scheme w consists of a series of functions that map clauses to weights: w = (f G , f R , f E , f P ). We used the training dataset to fine-tune the weighting scheme. For a soft clause c e corresponding to an edge e, the weight is f G (c e ) + f R (c e ) + f E (c e ) + f P (c e ). The first weighting scheme w 1 consists of four functions: f G assigns the clause of each edge in the F ∪ B a weight of 5, the rest 0; Similarly, f P assignes the clauses corresponding to pairs in P a weight of 2.
Implementation We used the networkx Python package  12  for the computation of the connected components and the minimum spanning forests. For the manual annotation of the entities, we used ANNit  13. We used the implementation of the Leiden algorithm and the Louvain algorithm in CDlib  14. As for SMT solver, we employed Z3  15 and used its Python binding  [5]. We published all the code as an open source project  16. All our experiments were conducted on the LOD Labs machine. It has 32 64-bit Intel Xeon CPUs (E5-2630 v3 @ 2. 40GHz) with a RAM of 264GB.
Since our evaluation confirms the superiority of the communities detected using the Leiden algorithm compared to Louvain, it is also reasonable to quest how far the results can be improved if MetaLink uses Leiden's outputs for calculating its error degree. The identity graph we study contains a large number of connected components of size two, as well as two very large connected components. The biggest CC in this dataset has 177,794 entities and 2,849,426 edges (No. 4073). The second biggest has 21,191 entities and 101,269 edges (No. 142063). The rest are significantly smaller with no more than 5076 nodes. Some past attempts using SMT solvers have also discovered the bottleneck in scalability  [20, 21]. Our analysis shows that removing the disambiguation entities can help reduce the size of connected components.
Identification and selection of systematic reviews and data extraction The study protocol was prospectively registered in the International prospective register of systematic reviews (PROSPERO, https://www. crd. york. ac. uk/PROSPERO, registration number CRD42022316273). We sought to identify all relevant published systematic reviews including randomized controlled trials or observational studies evaluating DOACs in relation to any comparator in patients treated for VTE during the acute and/or extended phase of anticoagulation, including patients receiving acute treatment for VTE in the context of cancer. A literature search was performed on PubMed from inception to January 31, 2022 using keywords and medical subject headings terms with no restrictions on language or publication period. Initially, the search was not restricted to the treatment of VTE to include systematic reviews addressing several indications.
The full electronic search equation is presented in Appendix Table  1. One of the authors (C. C. ) screened the titles and abstracts of publications for possible inclusion. Then, two of the authors (C. C. and P. B. ) independently screened the full-text articles and discrepancies between reviewers being resolved by discussion. To be eligible, the systematic reviews had to meet the following criteria: (1) include randomized controlled trials or observational studies;  (2)  evaluate DOACs in relation to any comparator (active standard treatment: vitamin-K antagonists, aspirin, or low-molecular-weight heparin; nonactive treatment: placebo or control; or other DOACs); and (3) include patients treated for an acute VTE during the acute or extended phase of anticoagulation. Pairwise (individual patient data or aggregated data) and network meta-analyses were included.
Systematic reviews including only one study assessing DOACs in acute VTE patients were excluded. To characterize replication, only full-text articles were included in this review. Data were independently extracted by two of the authors (C. C. and P. B. ). In the event of discrepancies between reviewers, a consensus was reached by discussion. The following data were extracted from each systematic review: publication details (author names, year of publication, journal, free-access journal, and impact factor of the journal), details of the meta-analysis (pairwise or network design, statistical model, registration, number of studies included, names and designs of the studies included, treatments, and method used to assess the risk of bias of the included studies [tool used and use of this tool to assess the effect of bias on the results]), and citations of previous systematic reviews in the field.
Quality assessment of the systematic reviews Two authors (C. C. and P. B. ) independently assessed the risk of bias of the systematic reviews according to the Risk Of Bias In Systematic reviews (ROBIS) tool; discrepancies between reviewers being resolved by discussion. Using this tool, the assessment of the risk of bias of the systematic reviews was accomplished in two phases: (1) identification of concerns regarding the review process and (2) appraisal of the overall risk of bias  [29]. Phase 1 covered four domains: study eligibility criteria, study identification and selection, data collection and study appraisal, and synthesis and findings. Each of the four domains was subjectively assessed as having a low, unclear, or high risk of bias, based on the questions specified in the tool. In the second phase, the overall risk of bias of the systematic reviews was assessed as low, unclear, or high, based on assessment of the four domains in phase 1.
0%) were published in a free-access format compared to 42. 3% and 45. 2% of the original systematic reviews and excessive replications, respectively. A protocol of the systematic review had been registered in 46. 1%, 27. 6%, and 19. 3% of the original reviews, conceptual replications, and excessive replications, respectively, mainly in the PROSPERO database. A quarter of the excessive replications indicated protocol registration within 10 days before submission of the systematic review for publication, compared to 2 months for original systematic reviews and 3 months for conceptual replications. Twenty (64. 5%) excessive replications had assessed the risk of bias of the studies included, compared with more than 70% in the original systematic reviews and conceptual replications. No overlap in authorship with other systematic reviews was observed in 14 (45.
Finally, assessment of the quality of the methodology and results of redundant systematic reviews and meta-analyses is crucial to ensure that these do not convey misleading, inaccurate, or biased information. Our overview has some limitations. First, we performed an umbrella review and restricted our search to a single database. Although the list of systematic reviews indexed by PubMed is comprehensive, we may have missed some additional published and unpublished systematic reviews. The extent of replication is therefore potentially even more than that we describe here. A second limitation is that we based our analysis of replication on the date of registration of the protocol whenever possible, but otherwise on the date of publication of the systematic reviews (online or in printed issues) without considering the delay in editorial and publication procedures.
6) North America 10 (38. 5) 28 (32. 2) 11 (35. 5) Asia 5 (19. 2) 22 (25. 3) 2 (6. 4) Other 1 (3. 8) 3 (3. 4) 2 (6. 4) Design of the included studies RCTs only 23 (88. 5) 72 (82. 8) 30 (96. 8) Observational studies only 0 (0. 0) 3 (3. 4) 1 (3. 2) RCTs and observational studies 3 (11. 5) 12 (13. 8) 0 (0. 0) Assessment of the risk of bias of the included studies 20 (76. 9) 65 (74. 7) 20 (64. 5) Descriptive (table/figure) 16 52 16 Analysis according to risk of bias 4 13 4 Registration of the protocol 12 (46. 1) 24 (27. 6) 6 (19. 3) PROSPERO 10 22 5 Cochrane database 2 1 0 Open Science Framework 0 1 1 Median time (IQR) from registration to submission 2. 6 (2. 2e3. 2) 5. 8 (3. 1e8. 7) 0. 4 (0. 3e12. 7) of the publication (mo) No overlap in authorship 7 (26. 9) 35 (40. 2) 14 (45. 2) Risk of bias of the systematic reviews (ROBIS tool) Low 7 (26.
A second one is the fact that Software Heritage provides a common infrastructure catering to the needs of a variety of stakeholders, ranging from industry to academia and from cultural heritage to public administrations. As a consequence, funding comes from a diverse group of sponsors, ranging from IT companies to public institutions. Finally, an extra layer of archival security is provided by a network of independent international mirrors that maintain each a full copy of the archive. 2 We recall here a few key properties that set Software Heritage apart from other scholarly infrastructures: • Software Heritage proactively archives all software, making it possible to store and reference any piece of publicly available software relevant to a research result, independently from any specific field of endeavor, and even when the author(s) did not take any step to have it archived  [1, 12] ; • Software Heritage stores source code with its development history in a uniform data structure, a Merkle Directed Acyclic Graph (DAG)  [32] , which allows to provide uniform, intrinsic identifiers for tens of billions archived software artifacts, independently of the version control system (VCS) or package distribution technology used by software developers  [15].
Choosing a data structure that minimizes duplication is better for long-term preservation and the ability to identify easily code reuse and duplication. This is the choice made by Software Heritage. Its data model is a Direct Acyclic Graph (DAG) that leverages classical ideas from content addressable storage and Merkle trees  [32] , which we recall briefly here. As shown in Fig. 2. 2, the Software Heritage DAG is organized in five logical layers, which we describe below from bottom to top. Directories are associative lists mapping names to directory entries and associated metadata (e. g. , permissions). Each entry can point to content objects ("file entries"), revisions ("revision entries," e. g. , to represent git submodules or subversion externals), or other directories ("directory entries").
The combination of core SWHIDs and qualifiers provides a powerful means of referring in a research article all source code artefacts of interest. By keeping all the development history in a single global Merkle DAG, Software Heritage offers unique opportunities for massive analysis of the software development landscape. By archiving and referencing all the publicly available source code, the archive also constitutes the ideal place to preserve research software artifacts and offers powerful mechanisms to enhance research articles with precise references to relevant fragments of source code and contributes an essential building block to the software pillar of Open Science.
Large Open Datasets for Empirical Software Engineering The availability of large amounts of source code that came with the growing adoption of open source and collaborative development has attracted the interest of software engineering researchers since the beginning of the 2000s and opened the way to large-scale empirical software engineering studies and a dedicated conference, Mining Software Repositories. Several shared concerns emerged over time in this area, and we recall here some of the ones that are relevant for the discussion in this chapter. One issue is the significant overhead involved in the systematic extraction of relevant data from the publicly available repositories and their analysis for testing research hypotheses. Building a very large-scale dataset containing massive amounts of source code with its version control history is a complex undertaking and requires significant resources, as shown in seminal work by Mockus in 2009  [34].
The lack of a common infrastructure spawned a proliferation of ad hoc pipelines for collecting and organizing source code with its version control history, a duplication of efforts that were subtracted to the time available to perform the intended research and hindered their reusability. A few initiatives were born with the intention of improving this unsatisfactory state of affairs: Boa  [17]  provides selected datasets (the largest and most recent one at the time of writing consists of about eight million GitHub repositories sampled in October 2019) and a dedicated domain specific language to perform efficient queries on them, while World of Code  [31]  collects git repositories on a large scale and maintains dedicated data structures that ease their analysis. The complexity of addressing the variety of existing code hosting platforms and version control systems resulted in focusing only on subsets of the most popular ones, in particular the GitHub forge and the git version control system, which raises another issue: the risk of introducing bias in the results.
In the rest of this section, we briefly describe the datasets that Software Heritage curates and maintains to the benefit of other researchers in the field of empirical software engineering. Before detailing the available datasets, we recall that building and maintaining the Software Heritage infrastructure that is instrumental to build them is a multimillion dollar undertaking. We are making significant efforts to reduce the burden on the prospective users, by providing dumps at regular intervals that help with reproducibility and making them directly available on public clouds like AWS. Researchers can then either run their queries directly on the cloud, paying only the compute time, or download them for exploiting them on their own infrastructure. To give an idea of the associated costs for researchers, SQL queries on the graph datasets described in Sect.
2. 2. 1. 1 can be performed using Amazon Athena for approximately 5$ per Terabyte scanned at the time of writing. For example, an SQL query to get the 4 topmost commit verb stems from over two billion revisions scans approximately 100 Gigabytes of data and provides the user with the answer in less than a minute, for a total cost of approximately 50 cents, a minimal fraction of the cost one would incur to set up an on-premise solution. When SQL queries are not enough (typically when a graph traversal is needed), the cost of a cloud solution may quickly become significant, and it may become more interesting to set up an on-premise solution. The full compressed graph dataset can be exploited using medium range server grade machines that are accessible for less than 10,000 dollars.
The Software Heritage Datasets The entire content of the Software Heritage archive is publicly available to researchers interested in conducting empirical experiments on it. At the simplest level, the content of the archive can be browsed interactively using the Web user interface at https://archive. softwareheritage. org/ and accessed programmatically using the Web API documented at https://archive. softwareheritage. org/api/. These access paths, however, are not really suitable for large-scale experiments due to protocol overheads and rate limitations enforced to avoid depleting archive resources. To address this, several curated datasets are regularly extracted from the archive and made available to researchers in ways suitable for mass analysis.
The Software Heritage Graph Dataset Consider the data model discussed in Sect. 2. 1. 1. The entire archive graph is exported periodically as the Software Heritage Graph Dataset  [38]. Note the word "graph" in there, which characterizes this particular dataset and denotes that only the graph is included in the dataset, up to the content of its leave nodes, excluded (for size reasons). This dataset is suitable for analyzing source code metadata, including commit information, filenames, software provenance, code reuse, etc. , but not for textual analyses of archived source code, as that is stored in graph leaves (see the blob dataset below for how to analyze actual code). The data model of the graph dataset is a relational representation of the archive Merkle DAG, with one "table" for each type of node: blobs, directories, commits, releases, and snapshots.
Each table entry is associated with several attributes, such as multiple checksums for blobs, filenames and attributes for directories, commit messages and timestamps for commits, etc. The full schema is documented at https://docs. softwareheritage. org/devel/swh-dataset/graph/schema. html. In practical terms, the dataset is distributed as a set of Apache ORC files for each table, suitable for loading into scale-out columnar-oriented data processing frameworks such as Spark and Hadoop. The ORC files can be downloaded from the public Amazon S3 bucket s3://softwareheritage/graph/. At the time of writing, the most recent dataset export has timestamp 2022-12-07, so, for example, the first ORC files of the commit table are: The current version of the dataset contains metadata for 13 billion source code files, ten billion directories, 2.
7 billion commits, 35 million releases, and 200 million VCS snapshots, coming from 189 M software origins. The total size of the dataset is 11 TiB, which makes it unpractical for use on personal machines, as opposed to research clusters. For that reason, hosted versions of the dataset are also available on Amazon Athena and Azure Databricks. The former can be queried using the Presto distributed SQL engine without having to download the dataset locally. For example, the following query will return the most common first word stems used in commit messages across more than 2. 7 billion commits in just a few seconds: More complex queries and examples can be found in previous work  [38]. For more details about using the graph dataset, we refer the reader to its technical documentation at https://docs.
softwareheritage. org/devel/swh-dataset/graph/. In addition to the research highlights presented later in this chapter, the Software Heritage graph dataset has been used as subject of study for the 2020 edition of the MSR (Mining Software Repositories) mining challenge, where students and young researchers in software repository mining have used it to solve the most interesting mining problems they could think of. To facilitate their task "teaser" datasets -data samples with exactly the same shape of the full dataset, but much smaller-have also been produced and can be used by researchers to understand how the dataset works before attacking its full scale. For example, the popular-3k-python teaser contains a subset of 2. 197 popular repositories tagged as implemented in Python and being popular according to various metrics (e.
Accessing Source Code Files All source code files archived by Software Heritage are spread across multiple copies and also mirrored to the public Amazon S3 bucket www. s3:// softwareheritage/content/s3://softwareheritage/content/. From there, individual files can be retrieved, possibly massively and in parallel, based on their SHA1 checksums. Starting from SWHIDs, one can obtain SHA1 checksums using the content table of the graph dataset and then access the associated content as follows: 1 $ aws s3 cp s3://softwareheritage/content/\ 2 8624bcdae55baeef00cd11d5dfcfa60f68710a02.
License Dataset In addition to datasets that correspond to the actual content of the archive, i. e. , source code artifacts as encountered among public code, it is also possible to curate derived datasets extracted from Software Heritage for the specific use cases or fields of endeavors. As of today one notable example of such a derived dataset is the license blob dataset, available at https://annex. softwareheritage. org/public/dataset/licenseblobs/ and described in  [51]. It consists of the largest known dataset of the complete texts of free/open-source software (FOSS) license variants. To assemble it, the authors collected from the Software Heritage archive all versions of files whose names are commonly used to convey licensing terms to software users and developers, e. g. , COPYRIGHT, LICENSE, etc.