dataesr/scientific-paragraphs-categorization huggingface dataset:
coluzzii samples was visualised with the Uniform Manifold Approximation and Projection (UMAP) dimensionality reduction technique, using the software umap-learn v. 0. 3. 10 (McInnes, Healy, & Melville, 2018). For the Ag1000g dataset alone, population variation statistics (nucleotide diversity, Watterson theta, Tajima's D) and pairwise population Hudson's Fst were estimated as implemented in scikit-allel v. 1. 2. 1.
Acknowledgements We thank  Eleanor Drury ,  Silvain Pinaud ,  Frank Jiggins ,  Marie Anice Mureb Sallum ,  Krijn Paaijmans ,  Mara Maquina ,  Nil Rahola ,  Ousman Akone-Ella ,  Marc F. Ngangue ,  Eliana Coelho Real ,  Farah Aida Dahalan ,  Mark Tunnicliff , and  Jacob Baum  for providing us mosquito and parasite samples that helped to validate the panel. The  Wellcome Sanger Institute  is funded by the  Wellcome Trust  (grant no. 206194/Z/17/Z ), which supports M. K. N. L. and D. K. This work was also supported by an  MRC Career Development Award  ( G1100339 ) to M. K. N. L. R. M. W. was supported by  Novartis Foundation  for medical-biological research grant # 18B116  and  Swiss National Science Foundation  grant  PP00P3_170664. D. A. was supported by the  ANR-18-CE35-0002-01 -WILDING.
Data Accessibility Raw sequencing data is available under ENA study ERP126312, Sanger sequencing data is deposited in NCBI GenBank under accessions MW603491-MW603603 (COI) and MW647367-MW647477 (ITS2). Pipelines and analysis code, together with processed amplicon sequences used for species identification and other data are available on GitHub: https://github. com/malariagen/ano-spp.
Equivalence links are the cornerstone of Linked Data and their integration. However, it is not easy to establish and manipulate them, since the Web is always evolving with datasets emerging and disappearing. Inconsistencies may also be present on the Web, leading to erroneous assertions and inferences. We propose a method to identify owl:sameAs relationships of a resource relying on online SPARQL querying of distributed datasets and to correct results using declarative curation rules. We also exploit and inspect the quality of owl:InverseFunctionalProperty and owl:FunctionalProperty relationships, using the definitions given by their schemata, endpoints and a voting approach. We evaluate our method on an existing benchmark and compare to state of the art baselines. We show that a heuristic approach can retrieve high quality equivalence links without requiring the extraction of all the alleged existing equivalence relations.
INTRODUCTION The ability to establish links is key to weaving the Web in general and the semantic Web in particular (Gandon, 2018). But the Web is in constant evolution with resources added and deleted all the time. Linked data, in particular, rely on our ability to establish links between the different datasets on the Web and as such, the detection of equivalence links is a central task. And as the Web evolves, this linking has to evolve with it. Establishing equivalences between resources is also key to data integration use cases to join knowledge graphs with different provenances. More recently this ability to combine such graphs also proved important in machine learning approaches relying on embeddings based on a set of linked graphs to capture the semantics surrounding a concept more accurately and more richly.
In Section 3 we introduce the definition of the equivalence detection task and the vocabulary we used to solve it. Then, in Section 4 we describe how we proceed to obtain information on datasets and their SPARQL endpoints. Section 5 details how we proceed to collect and curate equivalence links. We evaluate the quality of the retrieved equivalent links on a public benchmark, comparing to state of the art baselines, and discuss our results in Section 6. We conclude with some perspectives in Section 7. Surprisingly, there are not so many available services to establish owl:sameAs relationships for a given URI. The sameAs. org (Jaffri et al. , 2008) is one of the pioneers to propose a service of URIs coresolution. The equivalences are collected through different RDF files and SPARQL endpoints chosen by the authors.
Unlike the other works, sameAs. org does not use a curation algorithm for owl:sameAs relationships. The LODsyndesis 3  (Mountantonakis and Tzitzikas, 2018) platform, in addition to providing various services and metrics related to many datasets, also performs coreference resolution. The algorithm introduced by the authors incrementally uses the same identifier for pairs of URIs (linked by the owl:sameAs property) defining the same resource. The authors show that by leveraging content or graph metrics, erroneous equivalence links can be detected. Their approach relies on the data provided by (Schmachtenberg et al. , 2014) that are crawled from the LOD Cloud with LDSpider, 4  on various datasets: Yago, datahub. io, DBpedia v3. 9, Wikidata, Freebase and LinkLion. Unfortunately, the number of coreferences that this service can offer is sometimes limited.
The sameAs. cc dataset accessible through the SPARQL endpoint 5   (Raad et al. , 2020) exploits the LOD-a-Lot dataset (Fernández et al. , 2017) and the Louvain algorithm (Blondel et al. , 2008) for detect-ing communities, an approach that leads them to identify errors between owl:sameAs relations. This approach succeeds in extracting more equivalence links than in the previous work, LODsyndesis (Mountantonakis and Tzitzikas, 2018). Different human annotators evaluated a subset of 200 owl:sameAs relations based on their descriptions to assess the relevance of these relations based on different thresholds of degrees of error. They apply their findings on these thresholds to cluster equivalence links that relate to the former U. S. president Barack Obama. 6  providing a valuable benchmark. One of the disadvantages of using the Louvain algorithm is that it must be run several times on the complete set of alleged equivalences to get the "best clusters" with no ensurance of reaching the global maximum of modularity, as it is a greedy and non-deterministic method.
Our approach differs from previous work in that it is not performed on a locally stored dataset but dynamically and online, on the SPARQL endpoints of many datasets. The list of considered endpoints is open and can be extended at will with new public and private endpoints as well as their description relevant to the application. Moreover, it uses other relations than owl:sameAs to define equivalence relations between different resources since we also rely on the properties owl:InverseFunctionalProperty and owl:FunctionalProperty. We also propose several techniques to curate the equivalences found on the fly and the properties declared as owl:InverseFunctionalProperty and owl:FunctionalProperty. We did this after noticing their definitions on datasets may differ from what was intended by the creators of the ontologies (see Section 5).
Moreover, to ensure portability, distributability, and federability, the algorithm we have written is primarily in SPARQL 1. 1, with calls in SPARQL 1. 0 7 when we contact online SPARQL endpoints. Many endpoints on the Linked Open Data still do not support SPARQL 1. 1, but the functionalities of this language allow us on a local endpoint to process properties of type (inverse) functional as well as to perform curation of owl:sameAs relationships and to provide statistics on the extracted data. We also trace all the steps of the algorithm by the generation of several named graphs and with the help of a small dedicated vocabulary introduced in this section and summarized in Table  1. We use a set of classes and properties to represent the input and output of each iteration. Together with the named graphs they capture the state of each iteration and the provenance of our results.
In the rest of this section, anchors in footnotes refer to labelled functions in the source code. The initialization of the algorithm consists of: 1. identifying datasets and their corresponding SPARQL endpoints and populating the named graph same:N with their description and checking their availability (see Section 4, done with 8 SPARQL queries, 3 of them being used for data cleaning); 8 2. populating the named graph Q 0 with the set S of seed URIs for which we want to obtain equivalent URIs. These seeds URI are typed as same:Target (done with 1 SPARQL query); 9 3. identifying and storing the definitions of owl:InverseFunctionalProperty and owl:FunctionalProperty in the named graph kg:default: in a preselection step the (inverse) functional properties identified from N are placed in the named graph same:Properties alongside with their namespaces to deference them.
If they cannot be dereferenced they are stored in the 7 https://www. w3. org/TR/rdf-sparql-query/ 8 Functions N1 to N3 load information about datasets, CN1 is responsible for data cleaning, A1 is responsible for checking endpoint availability. 9 Function P1 populates Q 0 with seed URIs. named graph same:NotDeferencedProperties to be put to a vote (see the sub-section 5. 1, done with 12 SPARQL queries, 2 of them being run in a loop). 10 This step refers to the block corresponding to the first "if" in algorithm 1. The core of the algorithm (mainly inside the "while" loop of algorithm 1) consists of iterating on a growing collection of named graphs Q i for which at each iteration i: 4. the obtained owl:sameAs are added in a specific named graph with a name based on the endpoint and the iteration in which the owl:sameAs relationship was identified; 1.
11 Function T 1 gets the same:Target resources in Q i-1. 12 Function S1 retrieves owl:sameAs relationships. 13 Function (I)FP1 retrieves the actual instances of (inverse) functional properties and (I)FP2 infers owl:sameAs relationships from them. 14 Function R1 refers to the rule #1 used to detect same:Rotten, respectively R2 refers to the rule #2, RC1 is used to remove relationships ; details in Section 5. 2. The stop condition is that the resources to be explored are exhausted, i. e. , there are no more resources to explore for the current iteration i and Q i is empty. A last check with (c. f. , the rule #2, sub-section 5. 2. 1) is necessary to ensure that there is no relationship between two resources sharing the same authority (resources obtained at i). The pseudo-code of SameLive is represented by the algorithm 1.
EXTRACTION AND INTEGRATION OF ENDPOINTS' INFORMATION The first step is to identify the datasets that can contribute to solving this problem. Various strategies exist for this purpose such as relying on search engines, using previously crawled RDF data (i. e. , using the RFC 8615, 15  etc. ) or even catalogs referencing these datasets. To achieve our means, we rely on famous catalogs listing datasets, using their metadata as well as the URLs for their SPARQL endpoints. These catalogs are regularly updated so we can keep up with the latest updates of the Web of Data. Moreover this approach supports the addition of new catalogs at any time, including private endpoints. However, just because a dataset is referenced in a catalog does not mean it is available. To define if a SPARQL endpoint is available or not, we rely on the EndS ontology (Endpoint Status Ontology)  16  which is an extension of VoiD.
17 We use in particular the property ends:statusIsAvailable. This ontology is involved in the description of the different datasets retrieved from the catalogs detailed in the following sub-sections. For each source we create a distinct named graph and then combine all unduplicated results (i. e. , different SPARQL endpoint URL) into one initial named graph same:N containing all our sources. From the different catalogs we present, we only rely on the asserted availability of endpoints from YummyData. The other catalogs listed here do not have regular updates on this property and we perform the availability ourselves.
voiD store We rely on the voiD store 18  and query it for instances of void:Dataset with their void:sparqlEndpoint to access them. To avoid duplicating entries for a same dataset -as datasets can be referred with several types in the voiD store-or incomplete results we limit ourselves to the extraction of resources of type void:Dataset and we ensure to not retrieve blank nodes. We also check that these resources have a title (property dcterms:title)  19  and, of course, a SPARQL endpoint (property void:sparqlEndpoint). Any doubloon is eliminated (i. e. , datasets using the same SPARQL endpoint), datasets can be represented several times in the voiD store. The retrieval of the information about endpoints and the removal of the doubloons is carried out in two steps to overcome the limitations of the voiD store SPARQL endpoint.
LODCloud The main purpose of the LODCloud 21 website is to provide a diagram of the LOD cloud. The JSON data used to build it are available 22 and we translate selected parts of them in RDF as different data are represented within this JSON document. We first check if a dataset has an entry related to a SPARQL endpoint ("sparql" field) in which case we include it. If we find information about a voiD page, we store this data as well. However, some of the information contained in the lod-cloud is not always up to date: an endpoint 21 https://lod-cloud. net/ 22 https://lod-cloud. net/lod-data. json marked as unavailable may be in fact available at the time of our query and vice-versa. Therefore, before executing our approach we check the availability of the endpoints to avoid waiting unnecessarily for a response from an unavailable endpoint.
YummyData YummyData 23   (Yamamoto et al. , 2018) is a site referencing and monitoring various SPARQL endpoints in the biomedical domain. We first get the URL leading to the SPARQL endpoint of the datasets from the JSON data obtained from their API. Then we check if the datasets have a VoiD annotation ('void' field equal to True) and in such case we remove the suffixes "virtuoso/sparql" or "sparql" from the URLs of the SPARQL endpoints and we add as a new suffix ". well-known/void" to refer to the VoiD page describ-ing the datasets. 24 For instance, to obtain the VoiD page of the Protein Ontology the URL https://sparql. proconsortium. org/virtuoso/sparql becomes https:// sparql. proconsortium. org/. well-known/void). Now that we have described how we retrieve information about SPARQL endpoints, we will get to the heart of the matter by describing the resources needed by the algorithm and some of its key steps.
Collecting true instances of (inverse) functional properties To establish identity, we collect relevant owl:InverseFuntionalProperty and owl:FunctionalProperty that we store in the named graph same:Properties. According to OWL specifications: if a, b, c are three resources, (i)  25  if there exist inverse functional property relations ip(a, b) and ip(c, b) there also exists an equivalence relation owl : sameAs(a, c) and (ii) 26 similarly, if there exist functional property relations f p(a, b) and f p(a, c) there exists an owl : sameAs(b, c) equivalence relation. However, depending on the SPARQL endpoints, the properties' definitions may vary and contain abusive usage of these types or at least usage that should be limited to a local closed world. For instance, rdfs:label is defined as an owl:InverseFunctionalProperty in the National Digital Data Archive of Hungary 27 or agront:isPartOfSubvocabulary 28 is defined as a owl:FunctionalProperty by the LusTRE endpoint.
Initialization We first query all available endpoints (property ends:statusIsAvailable set to true) in the named graph same:N to return their properties of type owl:InverseFunctionalProperty and owl:FunctionalProperty. A filter is performed on the properties defined as blank nodes. Then, these data are stored as RDF* triples (Hartig and Thompson, 2014) in the named graph same:Properties and we keep as information the dataset from which they come with the same:statementInDataset property. These triples are stored in RDF* to record the statements typing properties together with the provenance dataset in which they were found, i. e. : <<foaf:firstName a owl:FunctionalProperty>> same:statementInDataset <http://uriburner. com/> We then perform two types of curation: curation by schema and curation by voting.
For this purpose we declared several properties such as same:nbOfTimesDefinedAsFunctionalProperty and same:inNbOfDatasetWithSchema. By this means, we are able to identify for example the property sparql:endpoint 30 as an owl:InverseFunctionalProperty and the property semsci:CHEMINF 000009 31 as a owl:FunctionalProperty. From the set of curated properties, we can infer owl:sameAs relationships of the same:Target of the current Qi with the available endpoints of same:N.
Protocol, Dataset and Baselines The different experiments were conducted on an HP EliteBook 840 G2, 2. 6 hHz, 16 GB RAM with a virtual environment under Python 3. 8. 5 and the software Corese Semantic Web Factory 34 (Corby and Zucker, 2010) version 4. 1. 6d deployed locally. Corese is used as a local triplestore on which we mainly use SPARQL 1. 1 Query and Update features. We evaluated our approach on the Barack Obama identity links knowledge graph developed by (Raad et al. ,  2020). 35 Regarding the initialization, we declared for our algorithm the target URI dbr:Barack Obama 36 (a same:Target) in the named graph same:Q0. The 34 https://project. inria. fr/corese/ 35 https://github. com/raadjoe/obama-lod-identity-analysis 36 PREFIX dbr: <http://dbpedia. org/resource/> different closures on the Barack Obama entity with which we compare ourselves (with sameAs.
cc (Raad  et al. , 2020), LODsyndesis (Mountantonakis and Tzitzikas, 2018) and sameas. org (Jaffri et al. , 2008)) and our approach, SameLive, are the following: • Ground truth: The manual annotation of the closure of the owl:sameAs extracted from the LOD-a-lot dataset distributed into 8 identity sets (Barack Obama, Obama's Presidency, Obama's Presidential Transition, Obama's Senate Career, Obama's Presidential Centre, Obama's Biography, Obama's Photos, Black President). The undetermined URIs included in the identity cluster about Barack Obama are essentially URIs for which we do not have enough semantics to confidently annotate them. • sameAs 0. 99: Results after removing the relations with an error degree greater than 0. 99 with the method used by sameAs. cc where the error degree is based on the communities resulting from the Louvain algorithm.
As a result, links that have disappeared are not included in our approach. However these are the best baselines as far as we know and our crawling-free online approach still obtains slightly lower results but comparable to the best approach, the sameAs 0. 4 proposed by (Raad et al. , 2020). Moreover, if we focus on the advantages of SameLive, the online na- The SPARQL query we use to detect potential errors eliminates redirect links in a dataset if they are not declared as owl:sameAs in it (or by extension if there is no owl:InverseFunctionProperty or owl:FunctionalProperty relationship in the same dataset). To increase this coverage with our approach, we would have to include specific properties to redirects such as the property dbo:wikiPageRedirects 40 with DBpedia).
Application Evaluation on Specific Use Case The source code of the project and its instructions are available at https://github. com/Wimmics/SameLive and the algorithm vocabulary at https: //ns. inria. fr/same/same. owl. Two modes of the algorithm are available to consider or not the owl:InverseFunctionalProperty and owl:FunctionalProperty. We also performed an evaluation on a real application: the integration of the knowledge graphs obtained from different named entity recognition and linking methods applied to the same corpus. In this type of usecase, to consolidate the knowledge graph and support further processing and visualization, it is important to detect that two URIs extracted by two different annotators are in fact identifying the same resource. We tested our approach on the public dataset CovidOnTheWeb (Michel et al.
CONCLUSION We proposed a method to identify owl:sameAs relationships relying on the online SPARQL querying of distributed datasets and using heuristic rules to correct results. We also exploit and inspect the quality of owl:InverseFunctionalProperty and owl:FunctionalProperty relationships, using the 44 http://ns. inria. fr/covid19/0eadf5a901c0d89fad2c202990056556be103e12 45 e. g. , http://fr. dbpedia. org/resource/Tubule distal and http://fr. dbpedia. org/resource/Rein 46 e. g. , http://dbpedia. org/resource/Coronavirus disease 2019 and http://www. wikidata. org/entity/Q84263196 47 e. g. , http://dbpedia. org/resource/Severe acute respiratory syndrome coronavirus 2 and http://www. wikidata. org/entity/Q82069695 definitions given by endpoints and a voting approach. We show that a heuristic approach can retrieve high quality equivalence links without requiring the extraction of all the alleged existing equivalence relations.
In addition, it is possible to use other algorithms (community detection, similarity function, graph-based metric, etc. ) in addition to/instead of the curation rules we have implemented. Because our algorithm works online this also exposes it to return different results for the same input, for example, if a SPARQL endpoint does not answer. Inversely, our method has the advantage of giving the user the possibility to include or exclude endpoints (public or private) on the fly, and thus to include locally stored datasets as long as a SPARQL endpoint is deployed. It may be interesting to include other dataset catalogs, such as the ones using the CKAN API. 48 Related to this, integrating SPARQL Micro-Services (Michel  et al. , 2018) or other mapping approaches on top of these catalogs would allow us to query them directly with SPARQL instead of manipulating beforehand their data with another language.
The use of such techniques could also help us extend our method to include non-RDF datasets. Extracting owl:InverseFunctionalProperty, owl:FunctionalProperty and owl:sameAs relationships is not enough for some datasets. For instance Wikidata formalizes equivalence relationships with identifiers (typed as external identifier wikibase:ExternalId using wikibase:propertyType 49  ) leveraging URI patterns. Also, although they seem to be rarely used, we intend to study the inclusion of owl:hasKey to have a modular and extensive set in the analysis of equivalence links. In addition we plan to consider redirects -including different scheme component of the URIs such as HTTP/S. All these extensions could be addressed by adding additional rules, some of which could be the result of mining and learning approaches.
Deferencing resources deemed as same:Rotten and comparing them to same:Target with a similarity metric is also a direction to obtain more results. Exploiting the underlying semantics (e. g. , owl:differentFrom, owl:AllDifferent. ) of the resources is also worth exploring. Finally, we intend to follow different leads to improve the performance of our approach in terms of speed, from query optimization (in particular for the owl:InverseFunctionalProperty and owl:FunctionalProperty properties) and further parallel querying. We will also study the software and hardware architecture needed to provide a web service with a caching system. We plan also to further exploit the monitoring capabilities of SPARQL, by using for example the PROV-O ontology 50 to better track the provenance of results, this could be used in particular for owl:sameAs relationships stored in specific named graphs (see Section 3, item 4 in the second list).
Comparison of the owl:sameAs closures on dbr:Barack Obama. Rotten (subtraction of sets O 2 and O 1 on the total of URIs), and 67 new URIs about Barack Obama compared to the LOD-a-Lot dataset. As an example, we identified as same:Rotten URIs coming from URIBurner that include resources of dubious quality such as "The Irishman" on Netflix. 39 11 resources of type same:Rotten are considered as belonging to the identity set of Barack Obama (subtraction of sets O 2 and O 1 on the entity set about Barack Obama).