<figure><img src="image_1.png" /></figure>

HAL
open science

# Eat your own KR: a KR-based approach to index Semantic Web Endpoints and Knowledge Graphs

Pierre Maillot, Catherine Faron, Fabien Gandon, Franck Michel, Pierre Monnin

► To cite this version:

Pierre Maillot, Catherine Faron, Fabien Gandon, Franck Michel, Pierre Monnin. Eat your own KR: a KR-based approach to index Semantic Web Endpoints and Knowledge Graphs. INRIA. 2025. hal-05140375

HAL Id: hal-05140375

https://hal.science/hal-05140375v1

Submitted on 11 Aug 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

Public Domain
# Eat your own KR: a KR-based approach to index Semantic Web Endpoints and Knowledge Graphs

Pierre Maillot¹, Catherine Faron¹, Fabien Gandon¹, Franck Michel¹, Pierre Monnin¹

¹Université Côte d'Azur, Inria, CNRS, I3S, Sophia-Antipolis, France

{first.last}@inria.fr

## Abstract

Over the last decade, knowledge graphs have multiplied, grown, and evolved on the World Wide Web, and the advent of new standards, vocabularies, and application domains has accelerated this trend. IndeGx is a framework leveraging an extensible base of rules to index the content of KGs and the capacities of their SPARQL endpoints. In this article, we show how knowledge representation (KR) and reasoning methods and techniques can be used in a reflexive manner to index and characterize existing knowledge graphs (KG) with respect to their usage of KR methods and techniques. We extended IndeGx with a fully ontology-oriented modeling and processing approach to do so. Using SPARQL rules and an OWL RL ontology of the indexing domain, IndeGx can now build and reason over an index of the contents and characteristics of an open collection of public knowledge graphs. Our extension of the framework relies on a declarative representation of procedural knowledge and collaborative environments (e.g., GitHub) to provide an agile, customizable, and expressive KR approach for building and maintaining such an index of knowledge graphs in the wild. In doing so, we help anyone answer the question of what knowledge is out there in the world *wild* Semantic Web in general, and we also help our community monitor which KR research results are used in practice. In particular, this article provides a snapshot of the state of the Semantic Web regarding supported standard languages, ontology usage, and diverse quality evaluations by applying this method to a collection of over 300 open knowledge graph endpoints.

## 1 Introduction

As of September 2023, the LOD cloud was listing more than 1 300 knowledge graphs (KGs) published according to the Linked Data principles, with more than 16 300 links between them. Such KGs consist of one or several datasets and can be accessed with one or several methods, including via SPARQL endpoints or as dumps. Ontologies and KGs are thus scattered on the web and are accessible in various ways. This growing number of KGs on the web presents an opportunity, as one of the first questions that arises when building a Knowledge Representation (KR) system is identifying existing resources on the web and their overlaps with the KR system being built, for possible reuse. However, due to the scattering and diverse access means of KGs, existing indexing solutions are of limited help in answering this simple, initial question.

Therefore, in this paper, we wish to illustrate how the Knowledge Representation and Reasoning (KRR) technologies and methods can be used successfully to build an enhanced index of the Semantic Web itself. This index can be leveraged to answer some open questions regarding the available KGs, such as: What are their characteristics in terms of content, expressivity, quality, etc.? What are the representation formalisms they use? What are the reasoning features that they support?

In the rest of this paper, we consider KGs published through a SPARQL endpoint (Figure 1). We propose to see an index of KGs as a regular KG of its own, and the problem of indexing KGs in the wild as an application domain for KR. We leverage the models and methods from KRR to support each step of the indexing lifecycle (Figure 2): model and formalize (with ontologies, rules, and KGs), extract and populate KG descriptions, validate and augment the descriptions, infer and enrich the descriptions and, finally, publish the index. Moreover, we set out to do so in the wild with real public KGs, dealing with real open endpoints, real-world data, volumes, heterogeneity in contents and implementations, etc. This work is an extensive extension of the IndeGx framework presented in the journal article (Maillot et al. 2023a), to which we added a model and method (OWL-RL ontology to describe endpoints), which results in an extended available IndeGx KG. In addition, this extension allows us to provide new results on KR usages in LOD datasets.

## 2 Related Works

The indexing of KGs in the wild is a recurrent research subject, with multiple approaches depending on the domains, use cases, and requirements that are considered and,

<figure><img src="image_2.png" /><figcaption>Figure 1: The couples “knowledge graph – endpoint” found on the Web as considered in this paper.</figcaption></figure>
in particular, on the tasks supported by the resulting indexes (e.g., source selection, distributed query planning, distributed caching, and mirroring, etc.).

First and foremost, publishing KGs is generally done by hosting the data online, followed by submitting that source to some index services. Annotations are usually added to the KGs themselves (e.g., using VoID, DCAT, Creative Commons, or Dublin Core vocabularies) to feed such indexes, and these annotations are often generated manually. Notable examples of index services include the LOD cloud<fnref n="1" /> for KGs in general or Linked Open Vocabularies<fnref n="2" /> (Vandenbussche et al. 2017a) for ontologies. The LOD cloud, in particular, is a prominent source of KGs for indexing approaches. However, it is only updated yearly, and its content is not directly accessible as a KG. Yet, most of the approaches to evaluate the KGs in the wild result from a one-shot campaign and often rely on these central indexes of KGs, giving us a snapshot of the wild Semantic Web at a given time.

Among such campaigns, several articles proposed studies on the usage of vocabularies in datasets. (Brinkmann, Primpeli, and Bizer 2023) proposes to extract a collection of statistics on the usage of the Schema.org vocabulary from RDF datasets embedded in Web pages. (Shi et al. 2023) provides insight into the usage of vocabularies available through different data portals. Before them, (Glimm et al. 2012) gave insight into the usage of OWL itself in the KGs of the Semantic Web.

Other initiatives focused on KGs specific characteristics. For example, GeoLOD (Kopsachilis et al. 2020) offers an online index of KGs from the LOD cloud annotated with their geographical coverage. At the same time, (Polleres et al. 2020) surveys the actual availability of the KGs found in the LOD Cloud. All the previously cited approaches either do not interact with KGs directly or download a static dump of the KGs' datasets to treat them locally.

An alternative is to interact with KGs through their SPARQL endpoints. This guarantees that the indexed KGs and their infrastructures are always in their latest version and supports the provision of fresh indicators, the constant monitoring of the KGs and their services, and the study of their evolution over time. Among such approaches, we find several monitoring-specific aspects such as SPARQLES (Vandenbussche et al. 2017b) and YummyData (Yamamoto, Yamaguchi, and Splendiani 2018) that evaluate the support of SPARQL by the endpoints and their general performances.

Our contribution in this paper is based on the IndeGx framework (Maillot et al. 2023a). The IndeGx framework leverages KR and semantics to build, represent, and enrich an index of publicly available knowledge graphs on the Semantic Web.

In (Maillot et al. 2023a), the IndeGx framework is compared to existing approaches. It is shown that IndeGx replicates most of the evaluations used by other approaches. Additionally, using a standard format, the declarative nature of IndeGx rules guarantees its interoperability, extensibility, and versatility. Approaches such as SPARQLES encapsulate their logic in their code, hindering such characteristics natively offered by IndeGx.

The review of the approaches related to IndeGx in (Maillot et al. 2023a) shows that there is a growing interest in the extraction of metadata from KBs for various usages. IndeGx is a transparent and extensible declarative tool to extract metadata based on SPARQL queries, including all the metadata extracted by SPORTAL, SPARQLES, and LOUPE. It also provides original metadata, among which are several statistics on the usage of the namespaces in resource URIs and literal datatypes, the extraction of the timezone of the server, and a few SPARQL features not covered by SPARQLES.

The reproduction, the combination, and the extension of previous initiatives, showed the ability of IndeGx to smoothly integrate new features which makes it suitable for different uses: indexing, monitoring, and exploration. This ability to integrate new features and the transparency of its generation process are key features that distinguish IndeGx from other related approaches.

In this paper, we rely on public SPARQL endpoints to access the KGs and assess them in their latest version and state. In addition, we also use a KG to represent and specify the interaction with each endpoint, the features we want to extract, and the strategies to obtain them. Moreover, the resulting index is itself represented and published as a KG with a public endpoint for access – the circle is complete. In the rest of this paper, we explain how we provide a full-KR approach to representing and performing the indexing KG with a declarative method allowing anyone to contribute to the definition and extraction of the indexed features.

## 3 KRR Approach to Represent and Implement KG Indexing

Several initiatives have integrated KR methods and tools into agile development methodologies to increase the adoption of these methods and tools. For instance, the ACI-MOV methodology (Hannou et al. 2023) supports an agile-oriented and Git-based approach to ontology engineering. In this paper, we extend this trend by proposing an approach based on IndeGx and on web-oriented forge services, such as GitHub, for collaborative and declarative definitions of rules and ontologies (pull requests for evolution, etc.), driving the indexing of KG endpoints in the wild. The collaboratively maintained rules guide a workflow periodically executed to update and publish the index as a dataset and service. In this section, we cover the algorithms, heuristics, and optimizations that we designed to establish an operational index.

### 3.1 Overview of the IndeGx framework

IndeGx takes as input a catalog of SPARQL endpoints and a set of rules. Then, the workflow consists of three steps presented in Figure 2. IndeGx successively applies three processes to each endpoint to create a description. The whole process can be seen as a stratified reasoning approach where each step only depends on the previous ones.

<footnote n="1">¹https://lod-cloud.net/</footnote>

<footnote n="2">²https://lov.linkeddata.es/dataset/lov</footnote>
(Step 1) The **extraction** rules extract information from the endpoint using SPARQL queries. These rules retrieve either existing content or compute information from the endpoint's content, as explained in Section 3.2.

(Step 2) The **augmentation** step applies SPARQL rules to the KG resulting from step (1) to compute new information. As detailed in Section 3.3, these rules are applied locally, avoiding overloading remote SPARQL endpoints.

(Step 3) An OWL RL reasoner performs **inferences** on the KG resulting from Step (3) using a given ontology. It mainly augments this KG with equivalent properties and inferred types as detailed in Section 3.4.

This process results in an RDF KG indexing and describing all the SPARQL endpoints of KGs in the catalog. As explained in Section 3.5, the resulting KG also captures the traces of all the rules executed for its construction, making the whole process trackable and transparent.

On top of the IndeGx framework, KartoGraphI<fnref n="3" /> (Maillot et al. 2022), a Web application that exploits the KG produced by IndeGx to offer various visualizations, including the evolution of the indexed KGs through time, is provided.

Finally, to assist and encourage KG providers to include good-quality metadata in their knowledge graphs, there is an online service called Metadatamatic<fnref n="4" /> (Maillot et al. 2023b), that simplifies the creation of metadata for a dataset through a dynamic form and scripts that reuse the actions defined for IndeGx to extract statistics on the knowledge graphs.

## 3.2 KR for Metadata Extraction in the Wild: Test & Action Rules

The extraction rules in IndeGx are inspired by the test suites, i.e., they comprise a series of *tests* and *actions* applied to each indexed KG and are represented in RDF.

Tests are SPARQL queries sent to characterize the datasets and the endpoint of a KG. They often use the ASK clause to test the presence of a graph pattern in the KG. They are also used to test if an endpoint has the capacity for the application of more complex rules. Examples of tests include checking the availability of an endpoint, checking the support of a given function (e.g., supports the `VALUES` clause to bind a variable to a set of values), or confirming advertised statistics about the base (e.g., the number of triples).

<figure><img src="image_3.png" /><figcaption>Figure 2: Schema of the application of the IndeGx framework.</figcaption></figure>

Actions are SPARQL queries designed to generate a part of a KG's description. Typical actions are SPARQL UPDATE queries designed to extract existing data from the KG's datasets, create new data according to the test result, or update an existing description. Examples of actions include extracting the license asserted in a KG's dataset or computing the number of instances for each class. In the IndeGx framework, the result of one *test* can trigger zero, one, or more *actions*. For instance, if an endpoint supports a specific SPARQL feature (e.g., the `SERVICE` clause), several *actions* based on that feature may be triggered (e.g., attempts to query known endpoints).

```sparql
1 <dataset_description.ttl> a kgi:TestQuery, mf:
    ManifestEntry;
2 dcterms:title "Presence of a Dataset.";
3 # Test query
4 kgi:query """ASK {
5 # $rawEndpointUrl is a keyword
6 # replaced by endpoint URL
7 SERVICE $rawEndpointUrl {
8 # Find a Dataset
9 VALUES ?datasetClass {
10 dcat:Dataset
11 void:Dataset
12 }
13 ?kg a ?datasetClass .
14 }
15 }""";
16 # Actions done if the test is positive
17 kgi:onSuccess (
18 [ mf:action """INSERT {
19 ?kg a dcat:Dataset;
20 ?p ?o .
21 } WHERE {
22 SERVICE $rawEndpointUrl {
23 VALUES ?datasetClass {
24 dcat:Dataset
25 void:Dataset
26 }
27 ?kg a ?datasetClass ;
28 ?p ?o .
29 }
30 }"""
31 ] ).
```

<caption>Listing 1: Test and actions declaration for the extraction of the description of a dataset.</caption>

Listing 1 is an example of a rule for extracting the description of datasets described in a KG. The rule is written in RDF as part of a test suite based on the Manifest and IndeGx vocabulary. The declaration of the test query starts on line 4. This test query checks whether the target KG contains at least one instance of a class *Dataset* (in DCAT or VOID vocabularies). If the result of the test query is *true*, then the actions listed in the list starting on line 16 are applied. In this example rule, a single action applies a SPARQL UPDATE query, as on line 17.

Note that while Listing 1 is an example of a rule for the extraction of the description of a dataset, it has been simplified to fit in this paper. In practice, several adaptations are needed for its application in the wild. Among others, the de-

<footnote n="3">³http://prod-dekalog.inria.fr</footnote>

<footnote n="4">⁴https://wimmics.github.io/voidmatic/</footnote>
scription may be stored in a named graph, making it neces-
sary to search separately in the default and any named graph.
The dataset instance may not be an IRI and thus may re-
quire generating a unique identifier to be stored in the index.
Other optimizations include removing forbidden characters
from IRIs or paginating the query for better performance.

These rules cover not only the extraction of characteris-
tics of contents of KGs but also other characteristics such as
the capabilities of their query engines and reasoners, their
availability, etc. For instance, Listing 2 is a test declaration
in which the capacity of the SPARQL endpoint of a KG is
tested. The result of this test does not depend on the result of
the query declared on line 7. The query is not an ASK query
as in Listing 1. In this case, the test is successful if the re-
mote endpoint returns no errors. This specific test, inspired
by SPARQLES (Vandenbussche et al. 2017b), checks if a
SPARQL endpoint will parse and accept a query containing
the SPARQL 1.1 keywords NOT EXISTS. The query in it-
self has been designed not to have any results as to have the
shortest execution time possible if the server supports the
keywords.

1 @prefix ex: <http://example.org/> .
2 @prefix nonsense: <http://nonsense.com/> .
3 <SELNOTEXISTS.ttl> a kgi:TestQuery, mf:ManifestEntry ;
4 dcterms:title "Support of NOT EXISTS." ;
5 # Test query
6 kgi:query """SELECT * {
7     SERVICE $rawEndpointUrl {
8         { SELECT * WHERE {
9             ?s a ex:something .
10         FILTER NOT EXISTS { ?s ex:property
11             nonsense:1 } }
12     }
13 } """ ;
14 # Action
15 kgi:onSuccess {
16     [ mf:action """INSERT DATA {
17         $rawEndpointUrl sd:feature sparqles:
18             SELNOTEXISTS .
19         } """
20     ] } .

<caption>Listing 2: Test and action declaration for the support of the NOT EXISTS clause.</caption>

3.3 SPARQL Rules for Data Augmentation

The augmentation rules are post-processing rules after the
extraction and pre-processing rules before OWL reasoning.
These rules address the need to curate knowledge obtained
on the open web and for specific data processing (e.g. nu-
merical calculation or string manipulation). SPARQL-based
data augmentation rules add new knowledge to what was
obtained using data extraction rules. They use the same
SPARQL-based declaration as the data extraction rules, and
they can also query an outside source that is different from
the indexed KGs if needed. They complement the data ex-
traction rules by transferring some computationally costly
operations to the infrastructure of IndeGx's KG. They also
perform transformations on the KG under construction that

could not be covered by classical OWL reasoning (e.g. a
numerical computation). Notably, data augmentation rules
can estimate the cardinality of some sets which can then be
used in OWL inferences, or correct low-level errors such as
malformed URIs.

Listing 3 presents an example of a rule that captures a re-
stricted form of equivalence only valid in the context of a
dataset description and for properties used to declare a cre-
ation date. Contrary to Listings 1 and 2, this rule is directly
applied to IndeGx’s KG without sending a query to a re-
mote endpoint. As such, it does not need a test, and the
kgi:DummyTest on line 2 indicates that this rule’s test is
always positive. When describing a Dataset’s creation date,
this rule applies an equivalence between the four properties
listed on lines 14 to 17. This restricted equivalence is out-
side the expressivity of OWL and thus pre-processed at that
step.

1 <creation_date.ttl> a mf:ManifestEntry, kgi:DummyTest;
2 # A "Dummy test" always succeed
3 dcterms:title "Equivalences of creation dates
properties for dataset." ;
4 kgi:onSuccess {
5 [ mf:action """INSERT {
6 ?kg dcterms:created ?o ;
7 schema:dateCreated ?o ;
8 pav:createdOn ?o ;
9 prov:generatedAtTime ?o .
10 } WHERE {
11 ?kg a dcat:Dataset ;
12 ?p ?o .
13 VALUES ?p { dcterms:created schema:
    dateCreated
14 pav:createdOn prov:
    generatedAtTime }
15 }"""
16 ] } .

<caption>Listing 3: Test and action for applying equivalences in the context of a dataset description.</caption>

3.4 OWL RL Ontology of the Index for
Inferences

After the extraction and augmentation rules, OWL RL semantics rules are applied to the graph obtained from the previous steps and the IndeGx ontology. This ontology provides a complementary way to enrich the knowledge graph with logical conclusions, this is useful when querying the index by declaring OWL-based augmentations. The extraction and augmentation rules are challenging to read without good knowledge of SPARQL. Therefore, complementary to these rules, the ontology contains all the augmentation rules that can be represented in OWL, e.g., defining concepts. The OWL definitions introduced in the ontology are typically useful to provide additional dimensions, making it easier to query and analyze the index’s data.

1 kgi:SPARQL11Compliant rdf:type owl:Class ;
2 rdfs:label "SPARQL 1.1 compliant endpoint"@en ;
3 rdfs:comment "indicates that an endpoint complies
    with SPARQL 1.1."@en ;
4 rdfs:isDefinedBy kgi: ;
5 rdfs:subClassOf sd:Service , dcat:Service ;
6 owl:equivalentClass [
7     rdf:type owl:Restriction ;
8     owl:onProperty sd:feature ;
9     owl:hasValue sd:SPARQL11Query
10 ] ,
11 [ rdf:type owl:Class ;
12 owl:intersectionOf (
13     # List of tested SPARQL 1.1 features
14 [ rdf:type owl:Restriction ;
15     owl:onProperty sd:feature ;
16     owl:hasValue sparqles:SELNOTEXISTS
17 ]
18 # ...
19 )
20 ] .

<caption>Listing 4: Declaration of a class that annotates endpoints that are SPARQL 1.1 compliant.</caption>

Listing 4 shows an example of a concept definition using restrictions in description logic to trigger a classification in the KG of the index. This definition will classify any KG's endpoint that has passed the tests, such as the one in Listing 2 that concerns features introduced by SPARQL 1.1, on line 16. It will also annotate the endpoint with the property `sd:feature sd:SPARQL11Query` on lines 8-9, defined by the SPARQL service description W3C recommendation.

## 3.5 A KG of the Index and of the Indexing Process

The sequential application of the extraction rules, augmentation rules, and OWL rules incrementally enriches the data generated by IndeGx. This enables IndeGx to bypass third-party KG limitations, such as timeouts, and produce a high-quality KG containing detailed descriptions of KGs, including knowledge graph contents, query engine capabilities, entailment regimes, customizable quality metrics, non-functional properties (e.g., availability), etc. The resulting graph also includes a declarative representation of the rules themselves that have been used to produce the index and the provenance information of all the generated KG descriptions.

Listing 5 is an example of a rule reusing the declaration of other rules and the traces of the execution of IndeGx. The rule in this example is executed after the data augmentation rules. It aggregates the execution traces of the tests of each rule to obtain the average execution time of a SPARQL query by a given endpoint. The aggregation is performed by the query on line 6. The execution traces are accessible in IndeGx's KG in a dedicated named graph identified in line 8. The traces of the execution of a test are represented using the EARL and PROV-O ontologies between line 10 and line 15.

1 `<execution_time_average.ttl>` a mf:manifestEntry , kgi: DummyTest ;

2 kgi:onSuccess {

3 [ mf:action """INSERT {

4 ?endpointUrl kgi:averageExecutionTime ?averageDuration .

5 } WHERE {
6 { SELECT ?endpointUrl (AVG(?duration) AS ?averageDuration) {
7 # Execution traces are stored in a dedicated graph
8 GRAPH kgi:Logs {
9 kgi:Logs kgi:trace ?testTrace .
10 ?testTrace a prov:Activity ;
11 earl result ?testResult ;
12 earl:subject ?endpointUrl ;
13 prov:startedAtTime ?startTime ;
14 prov:endedAtTime ?结束Time .
15 ?testResult earl:outcome earl:passed .
16 }
17 # Computation of the duration of the query execution
18 BIND ((?结束Time - ?startTime) AS ?duration)
19 } GROUP BY ?endpointUrl }
20 }"""
21 ] ) .

<caption>Listing 5: Test and action declaration for a rule using the trace of the execution of queries to compute the average execution time on a SPARQL endpoint.</caption>

# 4 Experiment: Indexing World “Wild” SPARQL Endpoints

The entire framework with all the rules and knowledge graphs described in the previous section has been implemented and published online<fnref n="5" /> by the authors of (Maillot et al. 2023a) to provide a fully functional public index of KGs available on the web and their characteristics. The resulting KG can be used to identify sources for any application that consumes RDF graphs. It can also be used to provide benchmarks and testbeds and is helpful for KR researchers and domain experts to understand KR practices in the real world “wild” web, providing statistics on the KR primitives, ontologies, and formalisms used in each KG. In the next sections, we illustrate some insights we gained by analyzing the index. Please note that each experiment was done at a different time and that some endpoints may not have been available for all experiments. The reality of KR in the wild is that, by combining several methods and sources, we were able to identify 870 SPARQL endpoints out of which only an average of 300 were available at a given time. Only the endpoints active at the moment of an experiment are considered for that experiment.

## 4.1 The Catalog of Knowledge Sources

The index starts from a catalog of endpoints aggregated from multiple sources, such as Wikidata, the LOD Cloud, search campaigns on search engines, and other monitoring approaches. The catalog available online<fnref n="6" /> contains 870 endpoint URLs, of which, on average, 300 were responsive during each experimentation. Each campaign attempts to obtain a maximum amount of metadata about these endpoints.

<footnote n="5">⁵https://github.com/Wimmics/IndeGx/</footnote>

<footnote n="6">⁶As the catalog contains authorship metadata, the link has been redacted for the review process</footnote>
Using external tools, we retrieved the GPS coordinates of the endpoints' hosting servers as an example of metadata characterizing the catalog. Figure 3 shows the geolocation of the endpoints, and we can see that the endpoints are hosted mainly in Europe, North America, and East Asia. This distribution can be explained by multiple factors, such as the adoption of Semantic Web technologies being pushed unequally worldwide and/or a bias in the sources used to build the catalog. Among other metadata of interest for an endpoint, we can also mention the links between KGs, application domains, etc.

<figure><img src="image_4.png" /><figcaption>Figure 3: Map of the geolocations of the tested endpoints.</figcaption></figure>

## 4.2 Content of Knowledge Sources

One way to characterize the content of a knowledge graph is to identify the vocabularies it uses (e.g. RDFS / OWL ontologies, SKOS thesauri). We use the vocabulary descriptions available in the Linked Open Vocabularies (LOV) Endpoint (Vandenbussche et al. 2017a) and the prefix-namespace registry service Prefix.cc to determine the number of known vocabularies used in each endpoint. Figure 4 shows the graph of endpoints in green and vocabularies in blue in a force layout. The edges indicate that at least one vocabulary element is used in a KG. In the figure, widely used meta-ontologies (such as RDFS and OWL metamodels) and very popular ontologies (such as Schema.org) appear in the middle of a cluster of endpoints. Sparsely used vocabularies appear outside the group, as they are only used in one or two endpoints. The two endpoints that are repositories of vocabularies, namely the mirrors of LOV and the Openlink Uriburner KG, appear surrounded by vocabularies (see the two green nodes surrounded by blue nodes at the bottom of the figure).

Among other indicators of a KG's content, we also have the presence of links to other datasets, the languages used in literals, the size of its datasets in terms of triples, resources, etc.

## 4.3 Provenance of Knowledge

One key characteristic in deciding to (re)use a knowledge source is its provenance. We extract the provenance information available in a KG, taking into account the fact that this information can be described using either the vocabularies recommended by the W3C, such as VoID and DCAT, or a general ontology, such as Schema.org. We designed rules to extract the most frequent ways of declaring

<figure><img src="image_5.png" /><figcaption>Figure 4: Graph of the links between endpoints and the vocabularies they use.</figcaption></figure>

the provenance of KGs. Tables 1 and 2 show the ontological primitives we found in the descriptions of KG's endpoints and their frequency. We can notice, for instance, that for the 106 instances of `void:Dataset`, the access URL of knowledge graphs is given with 3 different properties, i.e. `dcat:downloadURL`, `dcat:accessURL` and `void:hdataDump`, in relatively the same number of KGs. Conversely, the URL of endpoints are pejoratively given using the property `void:sparqlEndpoint` while the `dcat:endpointURL` is only used 26 times. We see that spatial-related information such as `centroid` or `dcat:bbox` and time-related information, such as `dcat:endDate`, are rarely present. Generally, we can expect to find general information in the description of a KG, such as the vocabulary used or the keywords describing the dataset. Still, we can rarely find more specific details. We also see that both DCAT and VoID should be looked for when searching for the description of KGs, along with other more general vocabularies such as DCTerms and PROV-O.

We evaluated the descriptions that were extracted according to two dataset quality measures: FAIRness (Gaignard et al. 2023) and accountability (Andersen et al. 2023). They are different takes on the evaluation of the quality and transparency of datasets. FAIRness, in the FAIR-Checker interpretation, evaluates general metrics such as LOD good practices (e.g. dereferenceability of URIs, minimum number of known vocabularies) or its registration on known websites. By contrast, the accountability checks the conjunction of specific pieces of information, "whatever" the vocabulary. The two measures were implemented as rules in the IndeGx framework and evaluated over 339 endpoints. The results
showed that in 25 endpoints, we could find 80 datasets with enough provenance metadata to compare the two measures. Figure 5 shows the evaluation results in ascending FAIRness score order.

<figure><img src="image_6.png" /><figcaption>Figure 5: FAIRness and accountability scores in ascending FAIRness score order.</figcaption></figure>

<table><caption>Table 1: Number of endpoints using each DCAT & VoID class</caption><thead><tr><td>Class</td><td># endpoints</td></tr></thead><tbody><tr><td>void:Dataset</td><td>106</td></tr><tr><td>dcat:Dataset</td><td>80</td></tr><tr><td>dcat:Distribution</td><td>65</td></tr><tr><td>dcat:Catalog</td><td>46</td></tr><tr><td>void:Linkset</td><td>39</td></tr><tr><td>dcat:Service</td><td>25</td></tr><tr><td>void:DatasetDescription</td><td>19</td></tr><tr><td>dcat:Resource</td><td>18</td></tr><tr><td>dcat:CatalogRecord</td><td>14</td></tr><tr><td>void:TechnicalFeature</td><td>10</td></tr><tr><td>dcat:Role</td><td>6</td></tr><tr><td>dcat:Relationship</td><td>3</td></tr></tbody></table>

## 4.4 Languages and Fragments Used

From a KR perspective, it is interesting to know which language, or which profile or fragment of a language, is effectively used in the wild to formalize and publish knowledge graphs. This shows the adoption and the required reasoning capabilities to exploit each source. We tested the presence of the classes and properties of the most well-known “meta-vocabulary” among 320 endpoints. Each class and property presence was tested with an efficient ASK query. The 320 endpoints tested were taken from the initial catalog and were available during the experiment in April 2024.

For each meta-vocabulary, Figure 6 shows the endpoints containing at least one of their primitives. RDF, RDFS, OWL, and SKOS are well ahead regarding usage. We also see that two endpoints were using none of those meta-vocabularies: one of them only answered the availability test query, and the other used exclusively classes and properties from Schema.org. We indirectly tested the application of basic RDFS entailment among 317 active endpoints. As any resource in a KG with RDFS entailment should be an instance of `rdfs:Resource`, we tested the presence of at least one instance of `rdfs:Resource`. In 265 endpoints,

there was no such triple. This shows that at least 83% of publicly available endpoints do not support basic RDFS entailment.

<figure><img src="image_7.png" /><figcaption>Figure 6: Number of endpoints using each meta-vocabulary</figcaption></figure>

## 4.5 Knowledge Quality Features

To decide the knowledge sources we want to rely on, we often have several criteria for quality and general characteristics that we would like them to meet. In the literature, several criteria have been identified as indicators of the quality of a KG, such as those presented in the survey (Xue and Zou 2022). IndeGx proposes a first set of rules to evaluate KGs according to several existing quality criteria and supports the customization and extensions of this rule set at will.

For instance, best practices for RDF data structuring can be measured using SPARQL queries. They give clear quality indicators for given use cases, such as the proportion of resources with a human-readable label for readability or the proportion of string literals with a language tag. As shown in related works (Maillot et al. 2023a; Maillot et al. 2022), an average of 42% of the resources have no label. The nature of some of those quality indicators depends on the community. For example, using blank nodes and RDF data structures such as lists, sequences, and bags poses problems for some data aggregation methods. However, OWL and SHACL use blank nodes and data structures to define vocabularies. For this reason, the relevance of that indicator depends on the targeted task and the nature of the considered graph.

More generally, the features presented in other sections, such as the presence of provenance information in section 4.3 or the usage of specific vocabularies in section 4.4, are also used as quality measures for a KG in some communities. As the definition of quality depends on the usage of the KG, many characteristics of a KG could be used as a quality factor.

## 4.6 Knowledge Graph System Characteristics

In addition to characterizing the knowledge graphs themselves, the capabilities and limits of the underlying infrastructure, software, and implementation may also be important before establishing a dependency on a knowledge source. For this reason, IndeGx allows us to study not only the content of KGs but also the capacities of their endpoints.
SPARQL queries enable us to test each of the SPARQL features that SPARQL endpoints may support in a manner inspired by SPARQLES (Vandenbussche et al. 2017b). Completion rules can test each feature and annotate the endpoint accordingly. As shown in listing 4, an inference may annotate each endpoint according to the conjunction of features that they support. The results of these tests are published in (redacted for peer review), showing, among others, that more than 60% of the endpoints support most of SPARQL 1.1, and that the SERVICE keyword used for federated queries is the least supported SPARQL feature.

The IndeGx framework also tracks each endpoint's time to answer each query. This enables the computation of a general response time for endpoints, depending on the type of queries sent. Furthermore, repeated indexing through time enables monitoring an endpoint's availability.

In April 2024, we tested the behavior of 317 active SPARQL endpoints to generate two random numbers and of the current date twice in the same query. According to the SPARQL recommendation, two calls to the `RAND` function in the same SPARQL query should return two different results, and two calls to the `NOW` function in the same query should return the same date. The results show that 49% of the endpoints will return the same number when asked for two different random number generations in the same query, and 6% of the endpoints will return two different dates when asked for the current date twice in the same query.

Using a non-standard extension of SPARQL, LDScript (Corby et al. 2021), we also obtained the type of server declared by the SPARQL endpoint in HTTP headers. Figure 7 shows the distribution of the server HTTP header values. Apart from 28.2% of Virtuoso servers and 1% of Apache Fuseki servers, most SPARQL endpoints do not return the kind of SPARQL engines they use, or a front-end web server removes the header. In the detailed values of the headers, there are 31 different versions of Virtuoso servers, 18 versions of Nginx, and 7 Apache server versions.

<figure><img src="image_8.png" /><figcaption>Figure 7: Server HTTP header values for SPARQL endpoints on April 2024.</figcaption></figure>

The differences between endpoints in SPARQL coverage and server version paint a picture of a great diversity of behavior in the KGs available through SPARQL endpoints. Using LDScript also enables IndeGx to detect the usage of

dereferenceable URIs in datasets, among other features.

## 5 Conclusion

In this article, we showed that we can successfully deploy KR formalisms and reasoning means to create an index of online knowledge graphs. We contributed a new open-source KR tool based on the IndeGx framework and a new resource, as the index is a publicly available KG for identifying and accessing all the indexed datasets.

This KR extension of the IndeGx framework enabled new ways to annotate the data retrieved from KGs and enhanced the framework's usability in general.

We also conducted multiple experiments over publicly available KGs with SPARQL endpoints. Each experiment was done with a different use case to demonstrate versatility and provide new insights about the KGs' contents, statuses, and endpoint capabilities. The results of our experiments show a great diversity in the world wild semantic web, in which the type of content, the vocabulary used, the endpoint capabilities, and the general quality of KG can differ significantly. These results can also help us identify KR research opportunities, resources, and challenges.

The metadata retrieved by our approach, and the new insights they brought, constitute critical resources for current active area of research, such as source selection for federated queries or GraphRAG approaches, neuro-symbolic AI approaches requiring specific ontological constructs, and in general for a analysing the state of the data and services available (including, e.g., geographical biases, lack of technological updates). For example, knowing the main triplestores and the specific choices made in their query engine implementation allows us to explain some results obtained in the wild (e.g., different behaviors of the RAND and NOW functions, etc.) and anticipate the impact on any application calling them.

## 6 Acknowledgments

This work is supported by the DeKaloG project, ANR-19-CE23-0014, and the 3IA Côte d'Azur ANR-19-P3IA-0002.

## References

Andersen, J.; Cazalens, S.; Lamarre, P.; and Maillot, P. 2023. A framework to assess knowledge graphs accountability. In *2023 IEEE International Conference on Web Intelligence and Intelligent Agent Technology (WI-IAT)*, 213–220. IEEE.

Brinkmann, A.; Primpeli, A.; and Bizer, C. 2023. The Web Data Commons Schema.org Data Set Series. In *Companion Proceedings of the ACM Web Conference 2023, WWW ’23 Companion, 136–139*. New York, NY, USA: Association for Computing Machinery.

Corby, O.; Faron, C.; Gandon, F.; Graux, D.; and Michel, F. 2021. Beyond Classical SERVICE Clause in Federated SPARQL Queries: Leveraging the Full Potential of URI Parameters. In *Mayo, F. J. D.; Marchiori, M.; and Filipe, J., eds., Proceedings of the 17th International Conference on Web Information Systems and Technologies, WEBIST 2021, October 26-28, 2021, 65–76*. SCITEPRESS.
Gaignard, A.; Rosnet, T.; De Lamotte, F.; Lefort, V.; and Devignes, M.-D. 2023. FAIR-Checker: supporting digital resource findability and reuse with Knowledge Graphs and Semantic Web standards. *Journal of Biomedical Semantics* 14(1):1–14.

Glimm, B.; Hogan, A.; Krötzsch, M.; and Polleres, A. 2012. OWL: Yet to arrive on the Web of Data? *arXiv e-prints* arXiv:1202.0984.

Hannou, F.-Z.; Charpenay, V.; Lefrançois, M.; Roussey, C.; Zimmermann, A.; and Gandon, F. 2023. The ACIMOV Methodology: Agile and Continuous Integration for Modular Ontologies and Vocabularies. In *MK 2023-2nd Workshop on Modular Knowledge associated with FOIS 2023-the 13th International Conference on Formal Ontology in Information Systems*.

Kopsachilis, V.; Vaitis, M.; Mamoulis, N.; and Kotzinos, D. 2020. Recommending Geo-semantically Related Classes for Link Discovery. *Journal on Data Semantics* 9(4):151–177.

Maillot, P.; Corby, O.; Faron, C.; Gandon, F.; and Michel, F. 2022. KartoGraphI: Drawing a Map of Linked Data. In *Extended Semantic Web Conference*. Springer.

Maillot, P.; Corby, O.; Faron, C.; Gandon, F.; and Michel, F. 2023a. IndeGx: A model and a framework for indexing RDF knowledge graphs with SPARQL-based test suits. *Journal of Web Semantics* 76:100775.

Maillot, P.; Corby, O.; Faron, C.; Gandon, F.; and Michel, F. 2023b. Metadatamatic: A Web application to Create a Dataset Description. In *Companion Proceedings of the ACM Web Conference 2023*, 123–126.

Polleres, A.; Kamdar, M. R.; Fernández, J. D.; Tudorache, T.; and Musen, M. A. 2020. A more decentralized vision for Linked Data. *Semantic Web* 11(1):101–113.

Shi, Q.; Wang, J.; Pan, J. Z.; and Cheng, G. 2023. VOYAGE: A Large Collection of Vocabulary Usage in Open RDF Datasets. In Payne, T. R.; Presutti, V.; Qi, G.; Poveda-Villalón, M.; Stoilos, G.; Hollink, L.; Kaoudi, Z.; Cheng, G.; and Li, J., eds., *The Semantic Web – ISWC 2023*, 211–229. Cham: Springer Nature Switzerland.

Vandenbussche, P.-Y.; Atemezing, G. A.; Poveda-Villalón, M.; and Vatant, B. 2017a. Linked Open Vocabularies (LOV): a gateway to reusable semantic vocabularies on the Web. *Semantic Web* 8(3):437–452.

Vandenbussche, P.-Y.; Umbrich, J.; Matteis, L.; Hogan, A.; and Buil-Aranda, C. 2017b. SPARQLES: Monitoring public SPARQL endpoints. *Semantic Web* 8(6):1049–1065.

Xue, B., and Zou, L. 2022. Knowledge Graph Quality Management: A Comprehensive Survey. *IEEE Transactions on Knowledge and Data Engineering* 1–1.

Yamamoto, Y.; Yamaguchi, A.; and Splendiani, A. 2018. YummyData: providing high-quality open life science data. *Database* 2018:bay022.

<table><caption>Table 2: Number of endpoints using each DCAT & VoID property</caption><thead><tr><th>Property</th><th># endpoints</th></tr></thead><tbody><tr><td>void:sparqlEndpoint</td><td>79</td></tr><tr><td>void:vocabulary</td><td>65</td></tr><tr><td>dcat:keyword</td><td>56</td></tr><tr><td>dcat:distribution</td><td>56</td></tr><tr><td>void:triples</td><td>56</td></tr><tr><td>dcat:downloadURL</td><td>50</td></tr><tr><td>dcat:accessURL</td><td>49</td></tr><tr><td>void:dump</td><td>47</td></tr><tr><td>dcat:mediaType</td><td>45</td></tr><tr><td>void:subset</td><td>45</td></tr><tr><td>dcat:theme</td><td>44</td></tr><tr><td>dcat:landingPage</td><td>42</td></tr><tr><td>void:exampleResource</td><td>42</td></tr><tr><td>dcat:dataset</td><td>40</td></tr><tr><td>dcat:contactPoint</td><td>39</td></tr><tr><td>void:uriSpace</td><td>39</td></tr><tr><td>void:inDataset</td><td>38</td></tr><tr><td>void:entities</td><td>36</td></tr><tr><td>void:linkPredicate</td><td>33</td></tr><tr><td>void:classes</td><td>32</td></tr><tr><td>void:distinctSubjects</td><td>28</td></tr><tr><td>void:properties</td><td>27</td></tr><tr><td>void:distinctObjects</td><td>27</td></tr><tr><td>dcat:endpointURL</td><td>26</td></tr><tr><td>void:feature</td><td>26</td></tr><tr><td>void:class</td><td>26</td></tr><tr><td>void:subjectsTarget</td><td>25</td></tr><tr><td>void:objectsTarget</td><td>25</td></tr></tbody></table><table><thead><tr><th>Property</th><th># endpoints</th></tr></thead><tbody><tr><td>void:classPartition</td><td>25</td></tr><tr><td>void:propertyPartition</td><td>24</td></tr><tr><td>void:property</td><td>24</td></tr><tr><td>dcat:servesDataset</td><td>20</td></tr><tr><td>void:uriRegexPattern</td><td>20</td></tr><tr><td>dcat:byteSize</td><td>18</td></tr><tr><td>void:rootResource</td><td>18</td></tr><tr><td>dcat:themeTaxonomy</td><td>15</td></tr><tr><td>void:target</td><td>15</td></tr><tr><td>dcat:accessService</td><td>13</td></tr><tr><td>dcat:temporalResolution</td><td>12</td></tr><tr><td>dcat:startDate</td><td>12</td></tr><tr><td>dcat:record</td><td>11</td></tr><tr><td>dcat:endpointDescription</td><td>11</td></tr><tr><td>dcat:compressFormat</td><td>11</td></tr><tr><td>void:uriLookupEndpoint</td><td>11</td></tr><tr><td>dcat:endDate</td><td>9</td></tr><tr><td>dcat:service</td><td>7</td></tr><tr><td>dcat:packageFormat</td><td>5</td></tr><tr><td>dcat:spatialResolutionInMeters</td><td>4</td></tr><tr><td>dcat:catalog</td><td>4</td></tr><tr><td>dcat:bbox</td><td>4</td></tr><tr><td>void:openSearchDescription</td><td>4</td></tr><tr><td>dcat:qualifiedRelation</td><td>3</td></tr><tr><td>dcat:hadRole</td><td>3</td></tr><tr><td>dcat:centroid</td><td>3</td></tr><tr><td>void:documents</td><td>1</td></tr></tbody></table>