#  Validating ChatGPT Facts through
RDF Knowledge Graphs and Sentence Similarity

Michalis Mountantonakis and Yannis Tzitzikas<EMAIL_ADDRESS>FORTH-ICS and Computer Science Department, University of CreteGreece

###### Abstract.

Since ChatGPT offers detailed responses without justifications, and erroneous
facts even for popular persons, events and places, in this paper we present a
novel pipeline that retrieves the response of ChatGPT in RDF and tries to
validate the ChatGPT facts using one or more RDF Knowledge Graphs (KGs). To
this end we leverage DBpedia and LODsyndesis (an aggregated Knowledge Graph
that contains 2 billion triples from 400 RDF KGs of many domains) and short
sentence embeddings, and introduce an algorithm that returns the more relevant
triple(s) accompanied by their provenance and a confidence score. This enables
the validation of ChatGPT responses and their enrichment with justifications
and provenance. To evaluate this service (such services in general), we create
an evaluation benchmark that includes 2,000 ChatGPT facts; specifically 1,000
facts for famous Greek Persons, 500 facts for popular Greek Places, and 500
facts for Events related to Greece. The facts were manually labelled
(approximately 73% of ChatGPT facts were correct and 27% of facts were
erroneous). The results are promising; indicatively for the whole benchmark,
we managed to verify the 85.3% of the correct facts of ChatGPT and to find the
correct answer for the 58.0% of the erroneous ChatGPT facts.

Fact Validation, ChatGPT, Knowledge Graphs, Embeddings

††copyright: rightsretained††doi: ††isbn: XXXXXXXXXXXX

##  1\. Introduction

ChatGPT is a novel Artificial Intelligence (AI) chatbox (OpenAI, 2021), which
is built on GPT-3.5 and GPT-4 families of large language models (LLMs) (Brown
et al., 2020), and provides detailed responses and human-like answers across
many domains of knowledge. However, as it is also stated in its webpage,
“ChatGPT may produce inaccurate information about people, places, or facts"
(van Dis et al., 2023),  and it has “limited knowledge of world and events
after 2021".

Figure 1. The key notion of Combining ChatGPT with RDF KGs.

One challenge, as shown in Fig. 1, is how to combine ChatGPT which has been
trained by using data from web sources (such as Wikipedia, books and news
articles), with popular RDF KGs (Knowledge Graphs (Hogan et al., 2021)
expressed in RDF111https://www.w3.org/RDF/). The objective is to enable the
validation of ChatGPT responses and their enrichment with justifications and
provenance information, given the high quality of information of RDF KGs and
that most of them are updated either periodically or continuously (Färber et
al., 2018). Another challenge is how to enable the evaluation of the mentioned
process, given that there are no available such benchmarks, i.e., benchmarks
containing ChatGPT facts that can be validated through RDF KGs (lower side of
Fig. 1).

ChatGPT can be used for producing RDF triples, e.g. see the examples of Fig.
2, however, in many cases it produces erroneous facts and URIs (Mountantonakis
and Tzitzikas, 2023b), without giving any evidence about the provenance of
provided information.  In particular, there are several ways to ask about RDF
N-triples (Beckett, 2014). Although in many cases the triples are exactly the
same as in DBpedia there are several problematic cases that can occur and some
of them are described below. First, the triple can be valid syntactically but
the denoted fact can be erroneous or inaccurate, e.g., see the case of the
birth date of the painter “El Greco" or the mountain of “Naxos" island in Fig.
2. Second, the fact can be correct and the URIs valid, however, ChatGPT can
fail to produce the correct URIs for the subject, predicate or object, e.g.,
see that in some cases the Object URI is a disambiguation page. Third, the
fact can be correct, but one or more URIs can be invalid or not the
appropriate one, e.g., in Fig. 2, the predicates dbo:occupation and
dbo:highestMountain are returned from ChatGPT, however for the corresponding
triples in DBpedia, the predicates gold:hypernym and dbp:highestMount are
used. Finally, there are cases where the literals are not exactly the same,
different formats are used for the literals (e.g., see the birth date in the
text-based prompt), and literals are used instead of URIs (or the opposite),
e.g., for the last fact of Fig. 2, the corresponding triple in DBpedia
contains the literal “Mt. Zeus" instead of dbr:Zas.

Figure 2. ChatGPT responses in RDF format using DBpedia Model and Common
Errors

To combine ChatGPT with KGs,  we need to tackle the aforementioned ChatGPT
limitations. This raises the following research questions (RQs):

$\bullet$ RQ1: How to check the validity of ChatGPT facts by using RDF KGs for
validating the correct ChatGPT facts and for finding the correct answer for
its erroneous facts?

$\bullet$ RQ2: Is it effective to use several KGs (e.g., through LODsyndesis
(Mountantonakis, 2021)) for checking the validity of facts instead of using
only DBpedia, given that more facts can be validated through the complementary
information, however more conflicts can occur (e.g., in case of contradicting
and outdated data from KGs)?

As regards our contribution, we propose a novel pipeline that receives as
input a ChatGPT response in RDF format and tries to find the most similar fact
in a KG for enabling the validation of any ChatGPT fact. For performing this
process, we use two different KGs, i.e., DBpedia (Lehmann et al., 2015) and
LODsyndesis (Mountantonakis, 2021) (it contains 400 RDF KGs including
DBpedia). The proposed algorithm sends SPARQL queries and REST requests for
retrieving candidate similar triples and creates short sentence embeddings for
finding the most similar triple to each ChatGPT fact according to the cosine
similarity score of vectors. Concerning the evaluation, we have created a
benchmark containing 2,000 facts from ChatGPT, for a list of i) famous Greek
Persons (from the Ancient and Modern era), ii) popular Greek Places, including
Cities, Islands, Lakes, Mountains and Heritage Sites, and iii) Events related
to Greece, such as Battles, Sport Events, Earthquakes and Elections. Moreover,
we have manually labelled the ChatGPT facts as correct or erroneous
(approximately 26% of ChatGPT facts were erroneous) and we provide an
experimental evaluation by comparing the effectiveness and efficiency of using
one or more KGs for validation. As regards the results, indicatively, by using
LODsyndesis we managed to verify $92.2\%$ of the correct ChatGPT facts for
Persons, $77.1\%$ for Places, and $76.3\%$ for Events, whereas we found the
correct answer for the $57.4\%$ of the erroneous ChatGPT facts for Persons,
$49.1\%$ for Places and $68.2\%$ for Events.

Figure 3. A scenario showing a use case that exploits the presented Fact
Checking approach

Moreover, we have created a demo web application with name GPToLODS, which is
available online222https://demos.isl.ics.forth.gr/GPToLODS/. Through this
website, one can have access to both a fact checking service (Mountantonakis
and Tzitzikas, 2023a) that exploits the pipeline of this paper, and also to an
annotation and enrichment service (Mountantonakis and Tzitzikas, 2023b).
Concerning the use cases that are related to the mentioned approach
(Mountantonakis and Tzitzikas, 2023a), the most important are the following:
(a) QA and Fact Validation, and (b) Relation Extraction and Triples
Generation, even for texts including facts that are not part of a KG.
Indicatively, for the first use case, we present in Fig. 3 a scenario
including all the services of GPToLODS, whereas all the use cases are
presented in an online video333https://www.youtube.com/watch?v=5DW1d37aPMc.

In particular, the user (who is not required to be familiar with RDF) asks a
question in natural text (see the example in Fig. 3), e.g., “Which was the
birth place of Odysseas Elytis?" (a Nobel Prize-winning Greek poet), and the
annotation and enrichment service of GPToLODS, returns the ChatGPT response
with annotations, images and links to RDF KGs (upper side of Fig. 3). The user
can validate the information by using the fact checking service. In
particular, the returned textual ChatGPT response is converted to triples by
sending to ChatGPT the following prompt: “Give me facts using RDF N-triples
and DBpedia format for the text: The birthplace of Odysseas Elytis was
Heraklion, Crete, Greece" (see the lower left part of Fig. 3). Afterwards, the
facts are retrieved from ChatGPT, and they are validated by using the pipeline
of this paper and the selected KG(s). Finally, the user can see the
corresponding facts from the KG(s) and their provenance (in the lower right
side of Fig. 3 we confirmed the fact from DBpedia).

Concerning the novelty, to the best of our knowledge, this is the first work
trying to validate the facts of ChatGPT by using one or more RDF KGs, whereas
it also offers an evaluation benchmark for fact checking over ChatGPT with
2,000 facts.

The rest of this paper is organized as follows: §2 discusses the background
and the related work, §3 introduces the proposed process by showing all the
steps and the algorithm for finding relevant facts. Moreover, §4 presents the
evaluation benchmark and statistics, whereas §5 presents the experimental
evaluation over the benchmark. Finally, §6 concludes the paper and discusses
future directions.

##  2\. Background & Related Work

This section discusses the background (see §2.1) and the related work (see
§2.2).

###  2.1. Background

An RDF triple, is a triple the form subject-predicate-object
$\langle$s,p,o$\rangle$ that belongs to the set of all possible triples
$\mathcal{T}$, defined as
$\mathcal{T}$=$(\mbox{$\mathcal{U}$}\cup\mbox{$\mathcal{B}\mathcal{N}$})\times(\mbox{$\mathcal{U}$})\times(\mbox{$\mathcal{U}$}\cup\mbox{$\mathcal{B}\mathcal{N}$}\cup\mbox{$\mathcal{L}$})$,
where $\mathcal{U}$, $\mathcal{B}\mathcal{N}$ and $\mathcal{L}$ denote the
sets of URIs, blank nodes and literals, respectively. A KG (e.g., DBpedia or
LODsyndesis) is essentially a subset $T_{KG}$ of $\mathcal{T}$.

We shall use $[x]$ to denote the class of equivalence of an element $x$
($x\in\mbox{$\mathcal{U}$}$ or $x\in\mbox{$\mathcal{L}$}$). Specifically, two
or more URIs (resources, properties or RDF classes) belong in the same class
of equivalence if they refer to the same real world entity (as inferred by the
owl:sameAs), property or class, whereas two or more literals are equal, if
they use exactly the same string. Moreover, we define that two triples
$t=\langle s,p,o\rangle,t^{\prime}=\langle
s^{\prime},p^{\prime},o^{\prime}\rangle$ are equivalent when it holds that
$[s]\equiv[s^{\prime}],~{}[p]\equiv[p^{\prime}],[o]\equiv[o^{\prime}]$. An
example of equivalent triples between two KGs, say DBpedia and Wikidata
follows: $\langle$dbo:Aristotle,dbo:birthDate,“384 BC"$\rangle$ and
$\langle$wkd:Q868,wkp:P569,“384 BC"$\rangle$, since it holds that
$\langle$dbp:Aristotle,owl:sameAs, wkd:Q868$\rangle$, $\langle$dbo:birthDate,
owl:equiv- alentProperty, wkp:P569$\rangle$ and they use the same literal as
object, i.e., “384 BC". Finally, we define all the triples of an entity $e$ in
a $KG$ as follows: $T_{KG}(e)=\\{\langle s,p,o\rangle\in
T_{KG}~{}|~{}[s]\equiv e~{}or~{}[o]\equiv e\\}$.

####  2.1.1. DBpedia and LODsyndesis KG.

In this paper, we use both DBpedia (Lehmann et al., 2015) and LODsyndesis KG
(Mountantonakis, 2021; Mountantonakis and Tzitzikas, 2020) for enabling the
validation of ChatGPT facts. LODsyndesis is an Aggregated Knowledge Graph that
contains 2 billion triples from 400 RDF KGs of many domains (including cross-
domain KGs like DBpedia, Wikidata (Vrandečić and Krötzsch, 2014), YAGO (Rebele
et al., 2016), geographical KGs like GeoNames (Geonames, [n. d.]), etc.). In
particular, LODsyndesis has computed the transitive and symmetric closure of
45 million equivalence relationships, including owl:sameAs,
owl:equivalentProperty and owl:equivalentClass relationships, and it has
indexed the contents of the 400 RDF KGs, by preserving their provenance. Due
to the precomputed closure, it enables the retrieval of equivalent triples to
a given triple, which is quite important given that for a fact of ChatGPT, it
is possible to find in the KG a semantically equivalent triple and not the
exact one.

###  2.2. Related Work

Here, we focus on approaches that combine ChatGPT and KGs, fact checking using
RDF KGs and embeddings over RDF triples. Finally, we provide a comparison and
we mention the novelty of the proposed approach.

####  2.2.1. A. ChatGPT and Knowledge Graphs (KGs).

First, (Omar et al., 2023) provides a comparison for the Question Answering
task, showing that ChatGPT can have high precision in popular domains but very
low precision in unseen domains. In (González-Gallardo et al., 2023), the
authors evaluated ChatGPT in a named identification task over historical
documents, whereas in (Hoes et al., 2023) ChatGPT facts about politics were
manually validated. Moreover, (Ontotext, 2023) mentions the importance of
providing solutions that combine ChatGPT and RDF KGs, e.g., for improving its
accuracy.  In (Tan et al., 2023), the authors compared the performance of
ChatGPT and traditional models based on Knowledge Bases on 8 complex Question
Answering datasets. Regarding the key results, ChatGPT achieved better results
compared to the best traditional models for old datasets, however, it was
worse for the current state-of-the-art datasets. In addition, (Yang et al.,
2023) reviews studies on enhancing PLMs with KGs, and proposes to enhance LLMs
with KGs by developing KG-enhanced large language models (KGLLMs), however, an
evaluation has not been yet conducted.

Furthermore, the author in (Vassiliou et al., 2023) exploited ChatGPT for
summarizing RDF KGs by using a ChatGPT constructed classifier, whereas (Shi et
al., 2023) proposed an interpretable text classification framework, which can
extract refined and structural knowledge from natural text through a KG
extraction task, by utilizing ChatGPT. In (Trajanoska et al., 2023), a Natural
Language Processing method that exploits ChatGPT was presented for enabling
the construction of a KG on the topic of sustainability using raw documents.
Moreover, in (Luo et al., 2023) the authors proposed a Large Language Model
based rule generator for mining logical rules over KGs. In (Yao et al., 2023)
a framework which can be used for KG completion by exploiting ChatGPT is
presented, by considering triples in KGs as text sequences.

Concerning our past work, (Mountantonakis and Tzitzikas, 2023b) presents an
approach where the response of ChatGPT is annotated by using popular Entity
Recognition tools, and each entity is enriched with more statistics and links
to LODsyndesis, whereas (Mountantonakis and Tzitzikas, 2023a) presents a demo
application that exploits the fact checking approach that is described in this
paper, for enabling the real validation of ChatGPT facts.

####  2.2.2. B. Fact Checking by using KGs.

There is a high trend for automated fact checking approaches by using both
textual sources and KGs (Zeng et al., 2021). Concerning approaches over KGs,
(Dong et al., 2015) used Freebase as a gold standard, for identifying the true
values for facts extracted from web pages. Also, DBpedia KG was used in
(Ciampaglia et al., 2015) for performing fact checking using simple network
models and by using input both natural text (from Wikipedia) and structured
data. Furthermore, in (Shiralkar et al., 2017), DBpedia was also used in an
unsupervised network-flow based approach for validating statements, whereas
(Vedula and Parthasarathy, 2021) provides a pipeline for explainable fact
checking through structured and unstructured data. Moreover, (Maliaroudakis et
al., 2021) offers a Web service and API that links natural text to a KG of
fact-checked claims whereas (Huynh and Papotti, 2019) presents a benchmark for
comparing and evaluating fact checking algorithms over KGs.

####  2.2.3. C. Embeddings using RDF Triples (focusing on Fact Checking).

There are many approaches that create embeddings from RDF Triples (or/and
paths) for several tasks (Portisch et al., 2022), including finding similar
entities (Ristoski et al., 2019; Mountantonakis and Tzitzikas, 2019) and link
prediction (Portisch et al., 2022; Biswas, 2020). Concerning fact checking
approaches over RDF, (da Silva et al., 2021) proposed a path-based approach
that creates KG embeddings, whereas (Qudus et al., 2022) introduces a hybrid
approach which uses both text and KG embeddings by using DBpedia. Also, in
(Pister and Atemezing, 2019; Ammar and Celebi, 2019) embeddings from RDF
triples were used for fact validation for a Semantic Web Challenge, whereas
(Huang et al., 2022) leverages noisy data from web pages and prior knowledge
from KGs (using KG embeddings) for checking the veracity of data. Finally,
there are available several evaluation benchmarks for fact checking that are
based on popular KGs like DBpedia and Freebase, e.g., (Gerber et al., 2015;
Huynh and Papotti, 2018).

####  2.2.4. Comparison and Novelty.

First, compared to approaches over ChatGPT, we mainly focus on enabling the
validation of ChatGPT facts, and not on tasks like Entity Recognition
(Mountantonakis and Tzitzikas, 2023b) and Question Answering (Omar et al.,
2023), or only on performing a manual fact checking evaluation (e.g., (Hoes et
al., 2023)). Regarding fact checking, we focus on ChatGPT responses and not on
data from textual sources (e.g., (Dong et al., 2015; Huang et al., 2022)),
whereas we provide an approach that combines both SPARQL queries and the
creation of embeddings from multiple RDF datasets (through LODsyndesis KG),
instead of using a single one like DBpedia (e.g., (Ciampaglia et al., 2015;
Shiralkar et al., 2017)). Moreover, our benchmark contains data from ChatGPT
and not from other types of sources (Gerber et al., 2015; Huynh and Papotti,
2018). Finally, compared to our previous work, in (Mountantonakis and
Tzitzikas, 2023a) we presented a fact checking service that exploits the
approach that is described in this paper, however, in that demo paper we
neither provide details about the algorithm nor an experimental evaluation.

Regarding the novelty, to the best of our knowledge, this is the first work
that a) validates at real time the facts of ChatGPT by using multiple RDF KGs
and short sentence embeddings, and by returning the provenance for each fact,
and b) offers a benchmark for fact checking over ChatGPT and RDF KGs, and
manually annotated results for facts about real persons, places and events.

Figure 4. The Steps of the Proposed Approach and external tools/APIs

##  3\. The Steps of the Approach

The steps of the process (depicted in Fig. 4) are the following: 1) send a
prompt in ChatGPT by asking for RDF triples either from a given response or by
asking ChatGPT for facts using the desired format, 2) receive the response as
RDF triples, 3) for each fact find the most relevant triple(s) according to
three rules by using short sentence embeddings, and rank them in descending
order according to their cosine similarity score with the vector of the
desired fact and 4) produce the $K$ most similar triples (and their
provenance) with their score. The running example of Fig. 5 shows a real
response from ChatGPT, the candidate triples for each fact and the K=1 most
relevant triple. In particular, the first fact is correct and the triple
exists in the KG, the second is inaccurate and the KG contains the same
entity-predicate pair and finally the third is correct, however, the correct
triple in DBpedia uses different URIs for the predicate and the object. Below
we describe each step in detail.

###  3.1. Step 1. Send a Prompt to ChatGPT

We list 3 key ways to create RDF N-triples (Beckett, 2014) through ChatGPT.

$\bullet$ Entity-based Prompt. One can write this prompt: “Give me facts about
entity $e$ using RDF N-triples and X format", where $e$ is the name of the
entity and X can be the DBpedia format, and it will return the corresponding
triples. Such a real case is shown in the upper side of Fig. 2.

$\bullet$ Text-based Prompt. One can write this prompt: “Give me facts using
RDF N-triples and X format for the text Y", where Y can be any text, such as
the response of ChatGPT. An example is shown in the middle side of Fig. 2.

$\bullet$ Question-based Prompt. One can write the following prompt: “Give me
facts using RDF N-triples and X format about the question $q$", where $q$ can
be any question, e.g., see the lower side of Fig. 2.

###  3.2. Step 2. Retrieve the Facts from ChatGPT in RDF format

The next step is to collect all the triples from the ChatGPT response, and to
analyze each one. In particular, let $T_{GPT}$ be all the triples from a
ChatGPT response. For each $t_{gpt}=\langle e,p,o\rangle\in T_{GPT}$, we try
finding either the same (or an equivalent) triple, a triple with the same
subject-predicate or subject-object, or the most similar triple, to a given
KG, as it is described in Alg. 1.

Figure 5. Running Example by using a real response from the ChatGPT

Input: A fact $t^{gpt}=\langle e,p,o\rangle$ from ChatGPT, and a Knowledge
Graph $KG$, and a Sentence Similarity model, denoted by $sentenceModel$

Output: The top-$K$ most similar triples of KG to $t^{gpt}$

1 $cand(t^{gpt})\leftarrow\emptyset$

2

// Execution of Rules for Finding Candidates

3 if  _$\exists~{}t^{\prime}\in T_{KG}(e)~{}s.t.~{}t^{gpt}\equiv t^{\prime}$_
then // Rule A.

4 $cand(t^{gpt})\leftarrow\\{t^{\prime}\\}$ // Same or Equivalent Triple found

5 else if  _$\exists~{}t^{\prime}=\langle e,p^{\prime},o^{\prime}\rangle\in
T_{KG}(e)~{}s.t.~{}[p^{\prime}]=[p]~{}or~{}[o^{\prime}]=[o]$_ then // Rule B.

6 $cand(t^{gpt})\leftarrow\\{t^{\prime}=\langle
e,p^{\prime},o^{\prime}\rangle\in
T_{KG}(e)~{}|~{}[p^{\prime}]=[p]~{}or~{}[o^{\prime}]=[o]\\}$ // All the same
Subject-Predicate and Subject-Object Pairs are candidates

7 else // Rule C.

8 $cand(t^{gpt})\leftarrow T_{KG}(e)$ // All the Triples about $e$ are
Candidates

9

// Create the vector for the ChatGPT fact

10 $t^{gpt}_{c}\leftarrow convert(t^{gpt})$ // Performing Conversions for the
URIs

11 $\vec{t^{gpt}_{c}}\leftarrow sentenceModel.encode(t^{gpt}_{c})$ // Vector
for the ChatGPT fact

12

13forall  _$t^{\prime}\in cand(t^{gpt})$_ do // for each candidate triple

14 $t^{\prime}_{c}\leftarrow convert(t^{\prime})$ // Performing Conversions
for the URIs

15 $\vec{t^{\prime}_{c}}\leftarrow sentenceModel.encode(t^{\prime}_{c})$ //
Create the vector for each candidate by using sentence embeddings

16
$\cos(\vec{t^{gpt}_{c}},\vec{t^{\prime}_{c}})\leftarrow{{\vec{t^{gpt}_{c}}}\cdot{\vec{t^{\prime}_{c}}}\over\|{\vec{t^{gpt}_{c}}}\|\|{\vec{t^{\prime}_{c}}}\|}$
// Computation of Cosine Similarity

// Sort the top-$K$ similar triples w.r.t. to the cosine similarity

17 $t_{best}\leftarrow
arg_{t^{\prime}}max~{}\\{\cos(\vec{t^{gpt}_{c}},\vec{t^{\prime}_{c}})~{}|~{}t^{\prime}\in
cand(t^{gpt})\\}$ // Most Similar fact(s)

18 return $t_{best}$, $cos(\vec{t^{gpt}_{c}},\vec{t_{best}})$ // Return the
most similar fact(s) and their similarity score

Algorithm 1 Finding the most similar fact(s) for Validation

###  3.3. Step 3. Algorithm for Finding the most similar facts to each ChatGPT
facts by using RDF KG(s)

The input of Alg. 1 is a ChatGPT fact $t^{gpt}$, the KG that will be used,
e.g., DBpedia or LODsyndesis, and the embeddings model that will be used.

####  3.3.1. Step 3.1. The Rules for Finding Candidate Triples.

First, we collect all the candidate triples, i.e., $cand(t^{gpt})$ according
to three rules (lines 1-7), which are also shown in Fig. 4 and in the running
example of Fig. 5.

Rule A. Search for the same or equivalent triple. We search in the KGs if the
same (or an equivalent) triple of $t^{gpt}$ exists, i.e., if
$\exists~{}t^{\prime}\in T_{KG}(e)~{}s.t.~{}t^{\prime}\equiv t^{gpt}$. In this
case, $cand(t^{gpt})$ contains the single triple $t^{\prime}$ (lines 2-3).

How the Rule is Executed? For checking Rule A, we send an ASK SPARQL query to
DBpedia SPARQL endpoint (Lehmann et al., 2015) (i.e., when DBpedia KG is
used), or a request to the online Fact Checking Service of LODsyndesis REST
API 444https://demos.isl.ics.forth.gr/lodsyndesis/rest-api.

Rule B. Search for the same Subject-Predicate (SP) or Subject-Object (SO). We
search for finding triples that have either the same Subject-Predicate (SP) or
the Same Subject-Object (SO) Pair, we collect all of them and we use them as
candidates, i.e., see lines 4-5 in Alg. 1.

How the Rule is Executed? For collecting the candidates of Rule B, for the
case of DBpedia we can send two SPARQL SELECT queries, i.e., one with fixed
subject-predicate and one with fixed subject-object. On the contrary, for the
case of LODsyndesis, we can send two requests to its Fact Checking service.

Rule C. Retrieve All Triples of $e$ as Candidates. If the previous two rules
fail, we use all the triples of the subject $e$ of $t^{gpt}$ (where $e$ occurs
either as a subject or as an object), i.e., $cand(t^{gpt})=T_{KG}(e)$ (see
lines 6-7 of Alg. 1).

How the Rule is Executed? For collecting the candidates, we either send a
SELECT SPARQL query for retrieving all the facts for the entity $e$, or a REST
request to the “allFacts" service of LODsyndesis REST API.

####  3.3.2. Step 3.2 Creating the Embeddings.

For the next steps (lines 8-13 of Alg. 1), we create a vector for both the
$t^{gpt}$ and each $t^{gpt}\in cand(t^{gpt})$.

Short Sentence Embeddings. Since each triple is a short statement, and given
the detected problems from ChatGPT (see Fig. 2), e.g., different predicates,
literals instead of URIs, wrong and invalid URIs, including properties, etc.,
we decided to use sentence similarity models. Indeed, “Sentence Similarity is
the task of determining how similar two texts are, by converting input texts
into vectors (embeddings) that capture semantic information and calculate how
close (similar) they are between
them"555https://huggingface.co/tasks/sentence-similarity. Here, we use the
most popular Sentence Similarity model from huggingface, called “sentence-
transformers/all-MiniLM-L6-v2" (Face, 2023), which “maps sentences and
paragraphs to a 384 dimensional dense". The objective is to measure how
similar each candidate triple is with the fact $t^{gpt}$ in terms of their
semantic meaning. However, such models need to process natural text and not
triples, thereby, some URI conversions are needed.

Conversions for URIs. For the URIs of $t^{gpt}$ and of each $t^{\prime}\in
cand(t^{gpt})$, we perform some conversions, i.e., we remove the prefixes and
the special characters from the URIs such as the underscore “_". Moreover, in
several cases, capital letters are used for distinguishing two or more words,
e.g., dbo:associatedBand, and in such cases we split the words when a capital
letter is identified, e.g., the previous will be converted to “associated
Band". On the contrary, for the URIs whose suffix is not human-readable (e.g.,
Wikidata), we replace the URIs with their labels. As an example, the triple
“dbr:El_Greco, dbo:artist dbr:View_of_Toledo", will be converted to “El Greco
artist View of Toledo", however, we also keep the initial triple and its
provenance (i.e., for returning it as the final output).

Part |  Description of Entities that we asked ChatGPT | Facts |  Correct Facts (percentage) |  Erroneous Facts (percentage) |  Unique URIs (dereferencable) |  Unique Properties (dereferencable)
---|---|---|---|---|---|---
Greek Persons |  From the Great Greeks List | 1000 |  812 (81.2%) |  188 (18.8%) |  525 (472) |  109 (85)
Greek Places |  Heritage Sites, Cities, Islands, Lakes, Mountains | 500 |  319 (63.8%) |  181 (36.2%) |  219 (177) |  85 (56)
Greek Events |  Battles, Sports, Earthquakes, Elections | 500 |  330 (66.0%) |  170 (34.0%) |  237 (204) |  140 (49)
Total |  - | 2000 |  1461 (73.05%) |  539 (26.95%) |  981 (853) |  334 (190)
Table 1. The Evaluation Benchmark and Statistics

Creation of Vectors for the Converted Triples.  Concerning the creation of
embeddings, we give as input the converted KG triples to the "sentence-
transformers/all-MiniLML6-v2” model; first we create the vector for the
converted ChatGPT fact $t^{gpt}_{c}$, i.e., we create $\vec{t^{gpt}_{c}}$
(lines 8-9). Afterwards, for each $t^{\prime}\in cand(t^{gpt})$, we create a
vector for its converted version, i.e., $\vec{t^{\prime}_{c}}$ (lines 10-12).
At the end, each converted triple has been encoded to a vector of 384
dimensions. The motivation is to use these vectors to find the top-K triples
with same/similar meaning to each ChatGPT fact (according to their vectors’
cosine similarity), even if ChatGPT used different URIs/Literals compared to
the KG triples.

####  3.3.3. Step 3.3 Computation of their Cosine Similarity with triple
$t^{gpt}$.

For each $t^{\prime}$ we compute the cosine similarity with the triple
$t^{gpt}$ (line 13). We selected to use cosine similarity, since it is has
been successfully (and widely) used for RDF similarity-based approaches based
on embeddings (e.g., see (Chatzakis et al., 2021; Ristoski et al., 2019)). The
cosine similarity ranges from -1 (i.e., the two vectors are exactly opposite)
to 1 (i.e., the two vectors are exactly the same, thereby the triples are
equivalent).

###  3.4. Step 4. Return the top $K$ similar triples (and provenance).

The last step is to sort the candidate triples according to their cosine
similarity, for returning the top-$k$ results (i.e., see lines 14-15). Apart
from the best triple(s), we return the cosine similarity score and the
provenance of each triple. Concerning the value of $K$, some suggested values
are $1,3,5$. Certainly, in some cases we have only one candidate, e.g., always
in cases when Rule A is followed (e.g., see the example of Fig. 5), and in
many cases either one or a few candidates, i.e., when Rule B is executed
(e.g., see the example of Fig. 5). On the contrary, for the rule C, we always
have a larger number of candidates, since we compute the similarity between
$t^{gpt}$ and all the triples of the entity, e.g., see the example of Fig. 5.
In that case, we successfully verified the ChatGPT fact, although the KG used
a different predicate and object URI for expressing the same real fact.
Finally, we should mention that the proposed pipeline spots the more similar
facts of the KGs and provides the provenance of these facts, offering to the
user a kind of support for the returned facts. This functioning mode does not
presuppose having KGs with no conflicting values.

###  3.5. Time and Space Complexity of Alg. 1.

In the worst case, we need to iterate over all the triples $T_{KG}(e)$ for the
subject $e$ of the fact $t^{gpt}$, i.e., for creating the vector of each
candidate and to compute its cosine similarity. Then we need to sort them
according to their similarity score thereby the time complexity is
$O(n*log(n))$, where $n$ refers to $T_{KG}(e)$ in our case. On the contrary,
we load in memory the sentence similarity model, and we keep in memory all the
candidate triples and their cosine similarity score, thereby the space
complexity is $O(n+m)$ ($n$ refers to $T_{KG}(e)$, and $m$ to the size of the
sentence similarity model).

ID |  Predicate of Fact from ChatGPT |  Total Facts |  Corr. Facts |  Erron. Facts
---|---|---|---|---
1 |  dbo:occupation |  102 |  97 |  5
2 |  dbo:birthDate |  90 |  60 |  30
3 |  rdf:type |  85 |  85 |  0
4 |  dbo:deathDate |  83 |  63 |  20
5 |  dbo:birthPlace |  78 |  61 |  17
6 |  dbo:nationality |  74 |  74 |  0
7 |  dbo:deathPlace |  69 |  63 |  6
8 |  dbo:influenced |  33 |  19 |  14
9 |  dbo:notableWork |  21 |  17 |  4
10 |  dbo:field |  20 |  17 |  3
Table 2. Top-10 Most Used Predicates for Greek Persons

ID |  Predicate of Fact from ChatGPT |  Total Facts |  Corr. Facts |  Erron. Facts
---|---|---|---|---
1 |  rdf:type |  56 |  56 |  0
2 |  dbo:country |  51 |  51 |  0
3 |  dbo:elevation |  36 |  11 |  25
4 |  dbo:location |  21 |  20 |  1
5 |  dbo:population |  19 |  4 |  15
6 |  dbo:areaTotal |  19 |  0 |  19
7 |  dbo:timeZone |  17 |  17 |  0
8 |  dbo:settlement |  17 |  14 |  3
9 |  dbo:locatedIn |  15 |  15 |  0
10 |  dbo:length |  14 |  1 |  13
Table 3. Top-10 Most Used Predicates for Greek Places

ID |  Predicate of Fact from ChatGPT |  Total Facts |  Corr. Facts |  Erron Facts
---|---|---|---|---
1 |  dbo:date |  52 |  29 |  23
2 |  dbo:commander |  27 |  3 |  24
3 |  dbo:result |  20 |  14 |  6
4 |  rdf:type |  19 |  19 |  0
5 |  dbo:country |  18 |  18 |  0
6 |  dbo:magnitude |  15 |  7 |  8
7 |  dbo:casualties |  14 |  6 |  8
8 |  dbo:depth |  13 |  2 |  11
9 |  dbo:place |  11 |  10 |  1
10 |  dbo:combatant |  10 |  9 |  1
Table 4. Top-10 Most Used Predicates for Events related to Greece

ID |  ChatGPT fact |  Top Fact (LODsyndesis) |  Annotation |  Rule Used
---|---|---|---|---
1 |  dbr:Aristophanes dbo:genre dbr:Comedy |  dbr:Aristophanes wkd:P136 dbr:Comedy |  C1. Correct & Validated |  A (equivalent triple)
2 |  dbr:Georgios_Papanikolaou dbo:knownFor "Pap test" |  dbr:Georgios_Papanikolaou dbo:knownFor dbr:Pap_Smear |  C1. Correct & Validated |  B (same predicate)
3 |  dbo:Aristophanes dbo:notableWorks dbr:Lysistrata |  dbo:Aristophanes dbo:author dbr:Lysistrata |  C1. Correct & Validated |  B (same object)
4 |  dbr:Pericles dbo:office dbr:Strategos |  dbr:Pericles yago:rank "Strategos" |  C1. Correct & Validated |  C (most similar triple)
5 |  dbr:Papadiamantis dbo:notableWork dbr:The_Murderess |  dbr:Papadiamantis rdf:type dbo:Writer |  C2. Correct w/o Validation |  C (most similar triples)
6 |  dbr:Georgios_Papanikolaou dbo:birthDate "1886-05-13" |  dbr:Georgios_Papanikolaou dbo:birthDate "1883-05-13" |  C3. Erroneous & Validated |  B (same predicate)
7 |  dbr:Mikis_Theodorakis dbo:activeYears "1949" |  dbr:Mikis_Theodorakis dbo:yearsActive "1943" |  C3. Erroneous & Validated |  C (most similar triples)
8 |  dbr:Charilaos_Florakis dbo:child dbr:Artemis_Floraki |  dbr:Charilaos_Florakis yago:familyName “florakis" |  C4. Erroneous w/o Validation |  C (most similar triples)
Table 5. Real Examples of Labels (Annotations) from the Evaluation Benchmark

##  4\. Benchmark for ChatGPT Facts & RDF Knowledge Graphs

ChatGPT was recently released, and to the best of our knowledge there is not
any available collection of facts produced from ChatGPT. For this reason, we
decided to create a benchmark and make it publicly available, enabling anyone
to use it for obtaining comparative results. In principle, one could use an
external dataset too, however that would not guarantee that ChatGPT has
information about such facts, and thus it would not be suitable for validating
the facts returned by ChatGPT. Concerning the benchmark,  we collected a list
of famous Greek Persons, Places and Events666We selected facts that are
related to Greece for facilitating the manual evaluation, since both authors
are from Greece. For the Persons, we used the list of the 100 Greatest Greeks
of all time (Great Greeks, [n. d.]), including persons from different eras
(Ancient and Modern era) and disciplines (leaders, artists, etc.). For the
Places, we used a list of famous heritage sites and islands, and the largest
cities, lakes and mountains. Finally, for the Events, we used a list of
battles, sports events, earthquakes and elections.

###  4.1. Collections of Facts from ChatGPT and Manual Annotation.

For each entity, we send the following requests to ChatGPT (using
“gpt-3.5-turbo") as follows: “Give me facts in RDF N-Triples format for entity
$e$ using DBpedia format", where $e$ is replaced by the name of the person
(like Aristotle), of the place (like Santorini) or of the event (like 2004
Summer Olympics). The resulting benchmark contains 2,000 facts as it can be
seen in Table 1, which also shows some statistics about the benchmark.

Then, we collected and manually labelled the facts of ChatGPT as correct or
erroneous (annotation conducted in Summer 2023). We manually annotated as:

$\bullet$ Correct Facts, the ChatGPT facts that can be verified from online
sources by searching on the web (e.g., Wikipedia, DBpedia, Wikidata, etc.).

$\bullet$ Erroneous Facts (including inaccurate ones, e.g., small differences
in numbers), the ChatGPT facts where we found the correct answer on the web
(and it was a different one) or/and facts that cannot be verified from online
sources, i.e., we did not find any evidence.

###  4.2. Statistics over the Benchmark.

Table 1 introduces the collection by showing the number of facts, how many of
them were correct or erroneous, the number of unique URIs and properties and
whether the produced triples contain dereferencable URIs. As we can see, the
facts for the people were more accurate compared to the Places, i.e., for the
people approximately 1 out of 5 facts was erroneous, whereas for the Places
and Events, approximately 1 out of 3. Concerning URIs describing resources,
90% for Persons, 80% for Places and 86% of Events are dereferencable, whereas
for Properties, the corresponding percentages are 77% for Persons, 66% of
Places and only 35% for Events. For measuring whether a URI is dereferencable,
we send an ASK query to DBpedia for checking if exists at least one triple
including the desired URI (resource or property).

###  4.3. Most Frequent Predicates, Correct and Erroneous ChatGPT Facts

Concerning the most frequent predicates, for the Persons, i.e., see Table 4,
they mainly describe general information such as the occupation of persons,
their birth/death date and birth/death place and others. Concerning the
erroneous facts, they were mainly facts related to numbers and dates, such as
“birth/death dates", but also some other ones like “birth and death place" of
a person. Concerning other frequent erroneous cases, they include the
predicates “influenced", “education" and "child". On the contrary, several
correct facts were indicatively about the “type", “nationality", ‘notable
works" and “fields" of a person.

Regarding the Places (see Table 4), the most erroneous ChatGPT facts contain
numbers, e.g., “elevation", “population", “areaTotal", “length", “width",
“depth", whereas it also failed in many cases to find the “major" of specific
cities. On the contrary, ChatGPT responses were more accurate for properties
like the “type", “location", “country" and “timeZone". Concerning the
different types of places, the most erroneous facts were for Lakes (55%
erroneous), and the most correct ones for Cities (79% were correct).

Concerning the Events (Table 4), there were several erroneous ChatGPT facts
for the “commanders" of battles and again for facts including dates and
numbers, e.g., “date", “magnitude", “casualties", “depth", etc. On the
contrary, the information was more accurate for characteristics like “place",
“country", and “type". As regards the different types of Events, the most
erroneous facts were about “battles" (43% were erroneous) and the most correct
ones for the events about elections (73% were correct).

Finally, concerning other inaccurate general cases, they include “owl:sameAs"
relationships to RDF KGs that use identifiers for their URIs (e.g., Wikidata),
and properties with identifiers as values, e.g., “wikiPageRevisionID".

Collection and KG |  % of Correct ChatGPT facts that Validated from KG (C1) |  % of Correct ChatGPT facts w/o Validation from KG (C2) |  % of Erroneous ChatGPT facts that Validated from KG (C3) |  % of Erroneous ChatGPT facts w/o Validation from KG (C4)
---|---|---|---|---
All Facts (using DBpedia) |  79.1% |  20.9% |  55.4% |  44.6%
All Facts (using LODsyndesis) |  85.3% |  14.7% |  58.0% |  32.0%
Persons (using DBpedia) |  82.5% |  17.5% |  52.1% |  47.9%
Persons (using LODsyndesis) |  92.2% |  7.8% |  57.4% |  42.6%
Places (using DBpedia) |  74.6% |  25.4% |  46.9% |  53.1%
Places (using LODsyndesis) |  77.1% |  22.9% |  49.1% |  50.9%
Events (using DBpedia) |  75.1% |  24.9% |  68.2% |  31.8%
Events (using LODsyndesis) |  76.3% |  23.7% |  68.2% |  31.8%
Table 6. Overall Percentages for the whole benchmark and specific parts of the
benchmark

###  4.4. Pages for Evaluation Benchmark, Source Code and Web Application.

The source code (python), the evaluation benchmark, including its initial and
its human labelled version, statistics and the experimental results (which are
presented in §5) are available in a github
page777https://github.com/mountanton/GPToLODS_FactChecking. Moreover, the web
application, where one can also validate any ChatGPT fact (including any of
the facts of the presented benchmark), is also available
online888https://demos.isl.ics.forth.gr/GPToLODS/.

##  5\. Experimental Evaluation

Here, we use the evaluation benchmark of §4, for evaluating mainly the
effectiveness of the proposed approach; we also evaluate the efficiency of the
approach. Our target is also to compare the performance of using only a single
KG, i.e., DBpedia versus more KGs, i.e., LODsyndesis (where DBpedia is also
included). For performing the experiments we used a Backend Python 3 Google
Compute Engine from Google Colab with 12.7 GB RAM and 107.7 GB disk space.

###  5.1. The Process, Manual Labelling & Metrics

For each fact of the benchmark, we find the $K=3$ most similar triples. We
decided to use $K=3$, since in many cases the top-1 result can be correct but
not the desired one, especially for multi-valued predicates. For instance, in
an erroneous fact saying that the birth place of a person is the city of
“Thessaloniki", the algorithm returned as the top similar fact from DBpedia
that his birth place is “Greece" and as a second similar that is the city of
“Larissa". Although both triples are correct, the second is the desired one
for the mentioned case (i.e., city of Larissa belongs to Greece). However,
remind that when Rule A is used, there is only one result, whereas when rule B
is used, the algorithm (when $K=3$) can return either 1, 2 or 3 results. For
providing accurate results, we manually annotated each pair of a ChatGPT
triple and the returned answer(s) of the used KG. We cross-checked the
annotations and we decided to use only non-ambiguous facts; in rare cases
where the authors failed to agree on ambiguous facts, the mentioned facts (of
the benchmark) were replaced by new non-ambiguous facts. The 4 categories are
listed below:

$\bullet$ C1.Correct & Validated: Correct in ChatGPT and validated from the
KG, even by using a different predicate and object, i.e., see the IDs 1-4 in
Table 5. For example, for ID 1, the triples are equivalent since both
“dbo:genre" and “wkd:P136" refer to the characteristic “genre".

$\bullet$ C2.Correct w/o Validation: Correct in ChatGPT, but not validated
from the KG (maybe the KG did not contain the fact or Alg. 1 failed to find
it), e.g., in ID 5 of Table 5 the fact is correct, however, the KG does not
include it.

$\bullet$ C3. Erroneous & Validated: Erroneous in ChatGPT, but the KG provided
the correct answer for the same real fact, e.g., see the IDs 6-7 in Table 5.

$\bullet$ C4.Erroneous w/o Validation: Erroneous in ChatGPT and the KG failed
to provide the correct answer (maybe the KG did not contain the fact or
included an erroneous value for the fact, and cases where the algorithm failed
to find it), e.g., suppose that for some persons can produce facts that they
had children (although they did not). For instance, see the ID 8 in Table 5,
where the fact is incorrect, however, LODsyndesis does not include a relevant
fact, since the greek politician “Charilaos Florakis" did not have children.

Metrics. We count the number of facts of each category, by using i) only
DBpedia and ii) LODsyndesis. The goal is to evaluate the RQ1, i.e., we expect
to observe high numbers for C1 and C3 (i.e., the KG(s) provided the correct
answer) and low numbers for C2 and C4 (i.e., the KG(s) failed to find the
correct answer), and the RQ2, i.e., we expect better results by using multiple
RDF KGs.

Note. We should note that for (some very few) facts, where in the top-$3$
triples we found contradicting values from many KGs (e.g., for the population
of a place), we labelled them as not validated (categories C2 and C4).

###  5.2. Overall Evaluation

Table 6 shows the percentages by using either only DBpedia or LODsyndesis, for
all the facts of the benchmark, and for each of the parts of the benchmark
(Persons, Places, Events). Concerning the whole benchmark, by using
LODsyndesis, we managed to validate 85.3% of the correct ChatGPT facts (+6.2%
compared to DBpedia) and to find the correct answer for the 58.0% of erroneous
ChatGPT facts (+2.6% compared to DBpedia).

Rule |  C1. Correct and Validated |  C2. Correct w/o Validation |  C3. Erroneous and Validated |  C4. Erroneous w/o Validation |  Total
---|---|---|---|---|---
A. Same/Equivalent Triple |  571 |  0 |  0 |  0 |  571
B. Same Subject Predicate |  217 |  37 |  238 |  35 |  524
B. Same Subject Object |  212 |  29 |  4 |  12 |  257
C. Most Similar Triples |  249 |  149 |  71 |  179 |  648
Total |  1246 |  215 |  313 |  226 |  2000
Table 7. Analysis of Results (based on Rules) for the whole benchmark Using LODsyndesis Rule |  C1. Correct and Validated |  C2. Correct w/o Validation |  C3. Erroneous and Validated |  C4. Erroneous w/o Validation |  Total
---|---|---|---|---|---
A. Same/Equivalent Triple |  441 |  0 |  0 |  0 |  441
B. Same Subject Predicate |  202 |  48 |  232 |  19 |  501
B. Same Subject Object |  178 |  37 |  2 |  11 |  228
C. Most Similar Triples |  335 |  220 |  65 |  210 |  830
Total |  1156 |  305 |  299 |  240 |  2000
Table 8. Analysis of Results (based on Rules) for the whole benchmark Using
DBpedia

Analysis of Rules and Labelled Results . In Table 7 we analyze the results by
using LODsyndesis for the three rules. When rule A was executed all the facts
were correct, whereas for rule B, in most of the cases, when we found the same
SO, the ChatGPT facts were correct. On the contrary, when we found the same
SP, in many cases the fact was erroneous. Indeed, from the 313 erroneous facts
that we found the correct answer, 238 of them were verified by using the
mentioned rule. Finally, concerning Rule C, in several cases we found the
correct answer (categories C1 and C3), however, it was also the most frequent
rule when we failed to find the correct answer (i.e., approximately in 50% of
cases when that rule executed, we failed to find the correct answer in the
KG). Regarding DBpedia, the results are presented in Table 8. In that case, we
can see that Rule A executed less times and Rule C more times compared to
LODsyndesis KG.

Figure 6. Cosine Similarity and Annotations for the whole Benchmark using
LODsyndesis Figure 7. Cosine Similarity and Annotations for the whole
Benchmark using DBpedia

Cosine Similarity and Annotations. Fig. 6 and Fig. 7 depicts the number of
ChatGPT facts with respect to their category and the cosine similarity score
of the relevant triple in the KG (returned by the algorithm), for LODsyndesis
and DBpedia respectively. In both cases, we can see that for high cosine
similarity scores, most facts were validated (see categories C1 and C3),
whereas for low cosine similarity scores (between the ChatGPT fact and the
fact from the KG) less facts were verified. It is worth noting that in some
cases, a fact in the KG was correct and in ChatGPT erroneous (i.e. Category
C3), however, their similarity was very high, e.g., for similar numbers, dates
and places.

Collection Parts. As regards the specific collection parts, which are
explained in the following subsections, we can observe in Table 6 that we
managed to verify more correct facts for the Persons collection compared to
the other ones, especially by using LODsyndesis KG. The main reason is that
for the Persons collections, we found information from more KGs in LODsyndesis
compared to Places and Events.

Figure 8. Evaluation Results for Persons for all the categories of ChatGPT
facts (manually annotated)

Figure 9. Percentage of Rules Executed for Persons for both KGs

Figure 10. Evaluation Results for Places for all the categories of ChatGPT
facts (manually annotated)

Figure 11. Percentage of Rules Executed for Places for both KGs

Figure 12. Evaluation Results for Events for all the categories of ChatGPT
facts (manually annotated)

Figure 13. Percentage of Rules Executed for Events for both KGs

###  5.3. Validation of Facts for Persons

As we can see in Fig. 9 we managed to validate 748 correct facts (out of 812)
by using LODsyndesis, i.e., 92.2% of the correct ChatGPT facts, whereas by
using only DBpedia, we validated 670 correct facts, i.e., 82.5%. As regards
the erroneous ChatGPT facts, we validated (i.e, we found the correct answer)
108 (out of 188) facts by using LODsyndesis, i.e., 57.4%, and 98 erroneous
facts by using only DBpedia, i.e., 52.1%. By using LODsyndesis we managed to
validate more facts, since some facts that are not described in DBpedia, were
found in other popular KGs such as Wikidata (Vrandečić and Krötzsch, 2014),
YAGO (Rebele et al., 2016) and Freebase (Bollacker et al., 2008). This can be
explained through Fig. 9, which shows the percentage of rules that were
executed for each KG. In particular, by using LODsyndesis in 41.5% of cases we
found the same or equivalent triple (due to the precomputed closure), whereas
the corresponding percentage for DBpedia was 29.3%. Moreover, by using
LODsyndesis in 36.1% of cases we found at least the same SP or SO Pair and
only in 22.4% of cases the rule C executed. On the contrary, for DBpedia, in
34.9% of cases we found the same SP or SO Pair, and in 35.8% of cases the rule
C executed.

###  5.4. Validation of Facts for Places

For this collection, the results are shown in Fig. 11. Concerning the correct
facts we managed to verify 238 (out of 319) by using DBpedia, i.e., 74.6%, and
246 of them by using LODsyndesis, i.e., 77.1%. For the erroneous facts, we
verified 85 (out of 181) through DBpedia (i.e., 46.9%) and 89 of them using
LODsyndesis (i.e., 49.1%). In that case, the difference is low, since less KGs
(apart from DBpedia) that are included in LODsyndesis provided data for Places
(compared to the Persons collection). Concerning the executed rules (see Fig
11) for this collection we found less equivalent triples and SP or SO Pairs,
thereby, Rule C was executed more times compared to the Persons.

###  5.5. Validation of Facts for Events

For this collection, the results are shown in Fig. 13. Similarly to Places,
the difference between using only DBpedia and LODsyndesis is quite small
compared to the Persons, i.e., by using LODsyndesis we verified only 4 more
correct ChatGPT facts compared to using only DBpedia. On the contrary, it is
worth noting that we managed to find the correct answer to a high percentage
of erroneous ChatGPT facts compared to Persons and Places. As regards the
rules (see Fig 13), we did not find several equivalent triples, and in most
cases the Rules B and C were executed. The main reason is that compared to
Persons and Places, only a small percentage of properties (returned by
ChatGPT) were dereferencable (i.e., see the last column of Table 1).

Figure 14. Average Execution Time for each Rule and KG for the whole benchmark

Figure 15. Average Execution Time for each KG and each part of the evaluation
benchmark

###  5.6. Discussion and Limitations

Concerning the RQs, we verified most of the ChatGPT facts by using the
proposed pipeline (i.e., RQ1), whereas by using multiple KGs we observed
better results (i.e., RQ2), especially for the entities that belong to
Persons. For the correct ChatGPT facts, in most cases (i.e., 85.3%) we
validated the facts from the KG(s).  As regards erroneous ChatGPT facts that
Alg. 1 found the correct answer (i.e., 58.0 %), they mainly include facts
about the birth/death date or place of a person, education of persons, facts
concerning the predicate influenced, the elevation of places, the major of
cities, commanders of battles and others.

On the contrary, for cases where we failed to find the correct answer in the
KG(s), either for correct ChatGPT facts (i.e., 14.7% of cases) or for
erroneous ChatGPT facts (i.e., 37.4 % of cases) the most common problems
follow: a) the answer was included in large literals (e.g., abstracts), and
the similarity score with such triples and the desired fact was low, b)
predicates with very similar suffix, e.g., “population",“populationTotal",
“populationAsOf", c) contradicting values among KGs (by using LODsyndesis),
and d) incompleteness issues, i.e., cases where the KG(s) did not contain the
fact, such as awards, missing birth date and place, intensity of earthquakes,
the currency of a given city/island and notable work of persons.

For overcoming such limitations, a possible research direction could be to
provide an extended version of Alg. 1, i) for supporting text extraction from
large literals (e.g., through Question Answering techniques), ii) for
resolving the conflicts between different KGs (e.g., for predicates and
objects) and iii) for performing web search using a search engine (for
tackling incompleteness issues).

###  5.7. Efficiency Results

Here, we provide efficiency measurements for evaluating the execution time i)
for each rule and ii) for each different part of the evaluation benchmark, by
using both KGs.

First, Fig. 15 shows the average execution time per rule for both KGs. As we
can see, by using DBpedia it is quite fast to find the corresponding triples
when Rules A and B are executed, since we just send some SPARQL queries. On
the contrary, for Rule C, the execution time is much higher, since it also
includes the creation of the embeddings. On the contrary, by using
LODsyndesis, more time is needed for all the rules, since i) its REST API is
not so fast compared to the DBpedia SPARQL Endpoint and ii) it contains more
triples for the same entities.

Second, Fig. 15 shows the average execution time for validating the ChatGPT
facts, by using a) DBpedia and b) LODsyndesis. Specifically, for the Persons
the average execution time per fact was lower, since the rule C, which is the
most time consuming one, was executed more times for the Places and Events
collection. For the whole benchmark, it was more than 2$\times$ faster to use
only DBpedia, since it contains a smaller number of triples for each entity,
compared to LODsyndesis (on average 3.5 sec versus 7.9 sec). Concerning the
total time, by using DBpedia we needed 45 min for all the 1,000 facts for
Persons, 29 min for the 500 facts about Places and 45 min for the 500 facts
about Events. On the contrary, for LODsyndesis the corresponding time was 125
min for the Persons, 70 min for the Places, and 71 min for the Events.

##  6\. Concluding Remarks

Since ChatGPT offers detailed responses without evidence, and erroneous facts
even for popular persons, events and places, in this paper we presented a
novel pipeline that retrieves the response of ChatGPT in RDF format (in
N-triples format by using the DBpedia ontology) and tries to validate the
ChatGPT facts using one or more RDF Knowledge Graphs (KGs). For performing
this task, we exploited DBpedia and LODsyndesis KG (which includes 400 RDF
KGs), and we proposed an algorithm that is based on embeddings and short
sentence similarity metrics. Moreover, we presented a web application that
exploits the proposed pipeline and use cases, including QA and Fact
Validation, and Relation Extraction and Triples Generation.

Afterwards, we created an evaluation benchmark including 2,000 facts derived
from ChatGPT for famous Greek persons, places and events, which were manually
labelled; approximately 73% of ChatGPT facts were correct and 27% of facts
were erroneous. Concerning the results, by using LODsyndesis we verified 85.3%
of the correct ChatGPT facts (+6.2% more compared to using only DBpedia). For
the erroneous facts, we found the correct answer in 58.0% of facts through
LODsyndesis (+2.6% versus DBpedia). Regarding the efficiency, for validating
each ChatGPT fact, we needed on average 3.5 sec by using DBpedia and 7.9 sec
by using LODsyndesis.

Generally, we believe that such services for validation will be necessary for
numerous applications that exploit Large Language Models (LLMs). Therefore, as
a future work, we plan to i) further extend the benchmark with more entities,
facts and domains, from ChatGPT and other LLMs, ii) propose methods for
automating the annotation/evaluation of ChatGPT facts, iii) extend the
algorithm for supporting answer extraction from large literals and web search,
iv) use/evaluate more sentence similarity models, and v) to evaluate the
pipeline in responses of other LLMs such as Google Bard (Google, 2023) or
newer versions of ChatGPT.

## References

  * (1)
  * Ammar and Celebi (2019) Ammar Ammar and Remzi Celebi. 2019.  Fact Validation with Knowledge Graph Embeddings.. In _ISWC (Satellites)_. 125–128.
  * Beckett (2014) David Beckett. 2014\.  RDF 1.1 N-triples.  _URL: https://www. w3. org/TR/n-triples_ (2014).
  * Biswas (2020) Russa Biswas. 2020\.  Embedding based link prediction for knowledge graph completion. In _Proceedings of the 29th ACM International Conference on Information & Knowledge Management_. 3221–3224.
  * Bollacker et al. (2008) Kurt Bollacker, Colin Evans, Praveen Paritosh, Tim Sturge, and Jamie Taylor. 2008.  Freebase: a collaboratively created graph database for structuring human knowledge. In _Proceedings of the 2008 ACM SIGMOD international conference on Management of data_. 1247–1250.
  * Brown et al. (2020) Tom Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared D Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, et al. 2020\.  Language models are few-shot learners.  _Advances in neural information processing systems_ 33 (2020), 1877–1901.
  * Chatzakis et al. (2021) Manos Chatzakis, Michalis Mountantonakis, and Yannis Tzitzikas. 2021\.  RDFSIM: similarity-based browsing over dbpedia using embeddings.  _Information_ 12, 11 (2021), 440.
  * Ciampaglia et al. (2015) Giovanni Luca Ciampaglia, Prashant Shiralkar, Luis M Rocha, Johan Bollen, Filippo Menczer, and Alessandro Flammini. 2015.  Computational fact checking from knowledge networks.  _PloS one_ 10, 6 (2015), e0128193.
  * da Silva et al. (2021) Ana Alexandra Morim da Silva, Michael Röder, and Axel-Cyrille Ngonga Ngomo. 2021\.  Using compositional embeddings for fact checking. In _The Semantic Web–ISWC 2021: 20th International Semantic Web Conference, ISWC 2021, Virtual Event, October 24–28, 2021, Proceedings 20_. Springer, 270–286.
  * Dong et al. (2015) Xin Luna Dong, Evgeniy Gabrilovich, Kevin Murphy, Van Dang, Wilko Horn, Camillo Lugaresi, Shaohua Sun, and Wei Zhang. 2015\.  Knowledge-based trust: Estimating the trustworthiness of web sources.  _arXiv preprint arXiv:1502.03519_ (2015).
  * Face (2023) Hugging Face. 2023\.  sentence-transformers/all-MiniLM-L6-v2.  https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2/ [Accessed: (September, 4, 2023)].
  * Färber et al. (2018) Michael Färber, Frederic Bartscherer, Carsten Menne, and Achim Rettinger. 2018.  Linked data quality of dbpedia, freebase, opencyc, wikidata, and yago.  _Semantic Web_ 9, 1 (2018), 77–129.
  * Geonames ([n. d.]) Geonames. [n. d.].  GeoNames geographical database.  http://www.geonames.org/.  Accessed: September, 4, 2023.
  * Gerber et al. (2015) Daniel Gerber, Diego Esteves, Jens Lehmann, Lorenz Bühmann, Ricardo Usbeck, Axel-Cyrille Ngonga Ngomo, and René Speck. 2015.  Defacto—temporal and multilingual deep fact validation.  _Journal of Web Semantics_ 35 (2015), 85–101.
  * González-Gallardo et al. (2023) Carlos-Emiliano González-Gallardo, Emanuela Boros, Nancy Girdhar, Ahmed Hamdi, Jose G Moreno, and Antoine Doucet. 2023.  Yes but.. Can ChatGPT Identify Entities in Historical Documents?  _arXiv preprint arXiv:2303.17322_ (2023).
  * Google (2023) Google. 2023.  _Google Bard_.  Accessed: September 4, 2023.
  * Great Greeks ([n. d.]) Great Greeks. [n. d.].  Great Greeks.  https://en.wikipedia.org/wiki/Great_Greeks.  Accessed: September, 4, 2023.
  * Hoes et al. (2023) Emma Hoes, Sacha Altay, and Juan Bermeo. 2023.  Using ChatGPT to Fight Misinformation: ChatGPT Nails 72% of 12,000 Verified Claims.  (2023).
  * Hogan et al. (2021) Aidan Hogan, Eva Blomqvist, Michael Cochez, Claudia d’Amato, Gerard de Melo, Claudio Gutierrez, Sabrina Kirrane, José Emilio Labra Gayo, Roberto Navigli, Sebastian Neumaier, et al. 2021\.  Knowledge graphs.  _ACM Computing Surveys (CSUR)_ 54, 4 (2021), 1–37.
  * Huang et al. (2022) Jiacheng Huang, Yao Zhao, Wei Hu, Zhen Ning, Qijin Chen, Xiaoxia Qiu, Chengfu Huo, and Weijun Ren. 2022.  Trustworthy knowledge graph completion based on multi-sourced noisy data. In _Proceedings of the ACM Web Conference 2022_. 956–965.
  * Huynh and Papotti (2018) Viet-Phi Huynh and Paolo Papotti. 2018.  Towards a benchmark for fact checking with knowledge bases. In _Companion Proceedings of the The Web Conference 2018_. 1595–1598.
  * Huynh and Papotti (2019) Viet-Phi Huynh and Paolo Papotti. 2019.  Buckle: Evaluating fact checking algorithms built on knowledge bases.  _Proceedings of the VLDB Endowment_ 12, 12 (2019), 1798–1801.
  * Lehmann et al. (2015) Jens Lehmann, Robert Isele, Max Jakob, Anja Jentzsch, Dimitris Kontokostas, et al. 2015\.  Dbpedia–a large-scale, multilingual knowledge base extracted from wikipedia.  _Semantic web_ 6, 2 (2015), 167–195.
  * Luo et al. (2023) Linhao Luo, Jiaxin Ju, Bo Xiong, Yuan-Fang Li, Gholamreza Haffari, and Shirui Pan. 2023\.  ChatRule: Mining Logical Rules with Large Language Models for Knowledge Graph Reasoning.  _arXiv preprint arXiv:2309.01538_ (2023).
  * Maliaroudakis et al. (2021) Evangelos Maliaroudakis, Katarina Boland, Stefan Dietze, Konstantin Todorov, Yannis Tzitzikas, and Pavlos Fafalios. 2021.  ClaimLinker: Linking text to a knowledge graph of fact-checked claims. In _Companion Proceedings of the Web Conference 2021_. 669–672.
  * Mountantonakis (2021) Michalis Mountantonakis. 2021\.  _Services for Connecting and Integrating Big Numbers of Linked Datasets_. Vol. 50.  IOS Press.
  * Mountantonakis and Tzitzikas (2019) Michalis Mountantonakis and Yannis Tzitzikas. 2019.  Knowledge graph embeddings over hundreds of linked datasets. In _Metadata and Semantic Research: 13th International Conference, MTSR 2019, Rome, Italy, October 28–31, 2019, Revised Selected Papers_. Springer, 150–162.
  * Mountantonakis and Tzitzikas (2020) Michalis Mountantonakis and Yannis Tzitzikas. 2020.  Content-based union and complement metrics for dataset search over RDF knowledge graphs.  _ACM JDIQ_ 12, 2 (2020), 1–31.
  * Mountantonakis and Tzitzikas (2023a) Michalis Mountantonakis and Yannis Tzitzikas. 2023a.  Real-Time Validation of ChatGPT facts using RDF Knowledge Graphs.  _ISWC Demo Paper_ (2023).
  * Mountantonakis and Tzitzikas (2023b) Michalis Mountantonakis and Yannis Tzitzikas. 2023b.  Using Multiple RDF Knowledge Graphs for Enriching ChatGPT Responses.  _arXiv preprint arXiv:2304.05774_ (2023).
  * Omar et al. (2023) Reham Omar, Omij Mangukiya, Panos Kalnis, and Essam Mansour. 2023.  ChatGPT versus Traditional Question Answering for Knowledge Graphs: Current Status and Future Directions Towards Knowledge Graph Chatbots.  _arXiv preprint arXiv:2302.06466_ (2023).
  * Ontotext (2023) Ontotext. 2023.  Why should you combine ChatGPT with Knowledge Graphs?  https://www.ontotext.com/blog/why-should-you-combine-chatgpt-with-knowledge-graphs/ [accessed: (September, 4, 2023)].
  * OpenAI (2021) OpenAI. 2021.  _ChatGPT_.  Accessed: March 21, 2023.
  * Pister and Atemezing (2019) Alexis Pister and Ghislain Auguste Atemezing. 2019\.  Knowledge Graph Embedding for Triples Fact Validation.. In _ISWC (Satellites)_. 21–24.
  * Portisch et al. (2022) Jan Portisch, Nicolas Heist, and Heiko Paulheim. 2022\.  Knowledge graph embedding for data mining vs. knowledge graph embedding for link prediction–two sides of the same coin?  _Semantic Web_ 13, 3 (2022), 399–422.
  * Qudus et al. (2022) Umair Qudus, Michael Röder, Muhammad Saleem, and Axel-Cyrille Ngonga Ngomo. 2022\.  HybridFC: A Hybrid Fact-Checking Approach for Knowledge Graphs. In _The Semantic Web–ISWC 2022: 21st International Semantic Web Conference, Virtual Event, October 23–27, 2022, Proceedings_. Springer, 462–480.
  * Rebele et al. (2016) Thomas Rebele, Fabian Suchanek, Johannes Hoffart, Joanna Biega, Erdal Kuzey, and Gerhard Weikum. 2016.  YAGO: A multilingual knowledge base from wikipedia, wordnet, and geonames. In _The Semantic Web–ISWC 2016: 15th International Semantic Web Conference, Kobe, Japan, October 17–21, 2016, Proceedings, Part II 15_. Springer, 177–185.
  * Ristoski et al. (2019) Petar Ristoski, Jessica Rosati, Tommaso Di Noia, Renato De Leone, and Heiko Paulheim. 2019\.  RDF2Vec: RDF graph embeddings and their applications.  _Semantic Web_ 10, 4 (2019), 721–752.
  * Shi et al. (2023) Yucheng Shi, Hehuan Ma, Wenliang Zhong, Gengchen Mai, Xiang Li, Tianming Liu, and Junzhou Huang. 2023.  ChatGraph: Interpretable Text Classification by Converting ChatGPT Knowledge to Graphs.  _arXiv preprint arXiv:2305.03513_ (2023).
  * Shiralkar et al. (2017) Prashant Shiralkar, Alessandro Flammini, Filippo Menczer, and Giovanni Luca Ciampaglia. 2017\.  Finding streams in knowledge graphs to support fact checking. In _2017 IEEE International Conference on Data Mining (ICDM)_. IEEE, 859–864.
  * Tan et al. (2023) Yiming Tan, Dehai Min, Yu Li, Wenbo Li, Nan Hu, Yongrui Chen, and Guilin Qi. 2023\.  Evaluation of ChatGPT as a question answering system for answering complex questions.  _arXiv preprint arXiv:2303.07992_ (2023).
  * Trajanoska et al. (2023) Milena Trajanoska, Riste Stojanov, and Dimitar Trajanov. 2023\.  Enhancing Knowledge Graph Construction Using Large Language Models.  _arXiv preprint arXiv:2305.04676_ (2023).
  * van Dis et al. (2023) Eva AM van Dis, Johan Bollen, Willem Zuidema, Robert van Rooij, and Claudi L Bockting. 2023\.  ChatGPT: five priorities for research.  _Nature_ 614, 7947 (2023), 224–226.
  * Vassiliou et al. (2023) Giannis Vassiliou, Nikolaos Papadakis, and Haridimos Kondylakis. 2023.  SummaryGPT: Leveraging ChatGPT for Summarizing Knowledge Graphs.  _ESCW_ (2023).
  * Vedula and Parthasarathy (2021) Nikhita Vedula and Srinivasan Parthasarathy. 2021.  Face-keg: Fact checking explained using knowledge graphs. In _Proceedings of the 14th ACM International Conference on Web Search and Data Mining_. 526–534.
  * Vrandečić and Krötzsch (2014) Denny Vrandečić and Markus Krötzsch. 2014.  Wikidata: a free collaborative knowledgebase.  _Commun. ACM_ 57, 10 (2014), 78–85.
  * Yang et al. (2023) Linyao Yang, Hongyang Chen, Zhao Li, Xiao Ding, and Xindong Wu. 2023.  ChatGPT is not Enough: Enhancing Large Language Models with Knowledge Graphs for Fact-aware Language Modeling.  _arXiv preprint arXiv:2306.11489_ (2023).
  * Yao et al. (2023) Liang Yao, Jiazhen Peng, Chengsheng Mao, and Yuan Luo. 2023\.  Exploring Large Language Models for Knowledge Graph Completion.  _arXiv preprint arXiv:2308.13916_ (2023).
  * Zeng et al. (2021) Xia Zeng, Amani S Abumansour, and Arkaitz Zubiaga. 2021\.  Automated fact-checking: A survey.  _Language and Linguistics Compass_ 15, 10 (2021), e12438.