\documentclass{article}

\usepackage{graphicx} % Required for inserting images
\usepackage{float}
\usepackage{titlesec}
\usepackage{url}
\usepackage{datetime2}
\usepackage{geometry}
\usepackage{tikz}
\usepackage{longtable}
\geometry{margin=1.20in}


\DTMsetdatestyle{mmddyyyy}

\graphicspath{ {./images/} }
\date{\today}
\setcounter{secnumdepth}{4}
\setcounter{tocdepth}{4}
\author{Daniel Gaugler\thanks{Master of Engineering Candidate, Department of Computer Science, Virginia Tech, danielg19@vt.edu} \and Ashish Aggarwal \thanks{Master of Engineering Candidate, Department of Computer Science, Virginia Tech, ashish1702@vt.edu} \and Instructor: Dr. Edward Fox\thanks{Professor, Department of Computer Science, Virginia Tech, fox@vt.edu} \and Mentor: Satvik Chekuri\thanks{Doctoral Student, Department of Computer Science, Virginia Tech, satvikchekuri@vt.edu}}
\title{Information Storage and Retrieval - CS5604 \\ Final Report \\ Team 1 (Knowledge Graphs)}


\begin{document}
\maketitle
\vfill
\begin{center}
       \includegraphics[scale=0.8]{VTSymbol.png}
            
       Department of Computer Science\\
       Virginia Polytechnic Institute and State University\\
       Blacksburg, Virginia, 24061 \\
\end{center}
% \begin{titlepage}
%    \begin{center}
%        % \vspace*{1cm}

%        % \huge
       

%        % \Large
%        % \vspace{0.5cm}
%        %  Team 1 (Knowledge Graphs)\\
%        %  Submitted On: \today
        

%        % \vspace{0.8cm}
            
%        % Instructed by Professor Edward A. Fox \\
%        %  Guided by Satvik Chekuri
            
%        \vfill
     

            
%    \end{center}
% \end{titlepage}
\thispagestyle{empty}
\pagebreak

\pagenumbering{roman}
\tableofcontents
\clearpage
\section{Abstract}

\quad
This project presents an ontological framework designed to enhance the utility of Electronic Theses and Dissertations (ETDs) by transforming them into a semantically enriched Knowledge Graph representation. The central technical approach leverages widely accepted standards such as the Resource Description Framework (RDF) and the Web Ontology Language (OWL) to convert ETD metadata into machine-readable RDF triples, each associated with unique Uniform Resource Identifiers (URIs). RDF schema and OWL ontologies are used to explicitly define the classes, properties, and relationships of entities within the ETD domain. By constructing a structured ETD Knowledge Graph, we enable the encoding of rich semantics and interconnections between entities based on these predefined ontologies. A major innovative aspect of this framework is the integration of semantic search capabilities that allow for complex contextual queries by capitalizing on the inherent graph structure. This search functionality relies on the standards-based SPARQL Protocol and RDF Query Language (SPARQL). The query processing mechanism employs graph traversal algorithms, which empower users to perform in-depth exploratory searches, unveiling non-obvious insights and connections from the Knowledge Graph. Our project commenced by analyzing a corpus of roughly 200 ETDs to comprehend the structure and relationships within the constituent components of an ETD. Utilizing this study, we compiled 76 predicates, 7 objects, and 37 subjects which comprehensively encompass the relationships within the ETD in a top-down and bottom-up ontology. The total number of triples generated for the 200 ETDs was roughly 95,000. This brings the average number of triples per ETD to around 600. Based upon this ontology, we process the ETDs which we ingest in an XML format to generate and persist the RDF triples within the Virtuoso database. We provide a SPARQL query interface which is utilized to execute heterogeneous queries upon the repository of this ETD data. To empower our data pipeline and back-end system, we harnessed modern technological architectures including event-driven programming, Representational State Transfer (REST) APIs, version control, web technologies, and Agile methodologies. To harness ancillary metadata for the URIs stored within the Knowledge Graphs, we architected a URI resolution microservice which integrates seamlessly with the central PostgreSQL database. To ensure scalability, our framework utilizes dockerized methodologies, which are deployed within the cloud ecosystem of Virginia Tech that leverages distributed computing techniques. This configuration enables the processing of RDF graphs, even when dealing with very large ETD datasets. The cluster infrastructure is equipped with horizontal scalability, ensuring that it can efficiently handle growing Knowledge Graphs and increasing query workloads. In this context, the OpenLink Virtuoso graph database is utilized to efficiently store and index the ontology-based entities and their relationships. To automate the data pipeline and achieve scalability for data storage in Virtuoso, we aim to use Kafka’s event based architecture. We have laid down the groundwork in terms of design but its implementation could not be completed this semester due to complications within other teams. We also discuss, as part of future work, extensions related to the doctoral plans of Satvik Chekuri. To effectively represent ETDs and capture semantic information, the KG should reflect both intra- and inter-document entity-entity relations. The KG structure, as a directed heterogeneous graph with domain-related semantics, addresses the limitations of transformer models in handling long documents. We propose building an entity-based KG for a document collection by extracting entity-related triples using improved OpenIE and NER methods, enriching the graph for improved coverage and performance in downstream tasks.



% In summary, this semantic ETD analytical framework marks a step forward in augmenting structured data enrichment. By transforming ETDs into a standards-based ontological representation, it unlocks new analytical potential and provides valuable contextual insights from scholarly documents published by various institutions in a multitude of domains. The integrated semantic search via SPARQL and customized REST APIs deliver powerful capabilities for exploring, analyzing, and harnessing enriched ETD data at scale, making this a cutting-edge advancement in the field of digital scholarship.

\clearpage



\section{Tables and Figures}
\listoftables


% \clearpage


% \cleardoublepage
% % \phantomsection
% \addcontentsline{toc}{chapter}{\listfigurename}



\listoffigures

\clearpage
\pagenumbering{arabic}

\pagebreak

\section{Overview}

\qquad The significance of theses and dissertations cannot be overstated, as they encapsulate invaluable research contributions. Electronic Theses and Dissertations (ETDs) have become a prominent mode of submission, with over 39,000 ETDs curated and preserved within VTechWorks. Initially, these documents existed solely in hard copy form, presenting challenges in preservation and accessibility. Virginia Tech pioneered electronic submission on January 1, 1997 by becoming the inaugural university to mandate electronic submission of theses and dissertations, marking a new era in digital archiving. This forward-looking policy allowed students to submit their research in diverse digital formats, including PDFs.

In the past two decades, universities across the nation have adopted digital repositories for Electronic Theses and Dissertations (ETDs). This widespread adoption has resulted in a vast and diverse collection of ETDs that are readily accessible in digital formats. This enhanced accessibility has ushered in a transformative era for researchers, graduate students, and knowledge seekers, breaking down geographical barriers. Our research initiative aims to extend the global reach of students' research efforts, overcoming the constraints of traditional archival practices. It is a paradigm shift that empowers academics to leverage the digital landscape for a revolutionary advancement in scholarly exploration and understanding. Semantically searchable ETDs will grant scholars the ability to not only access these documents but also to formulate and perform precise and targeted searches within this extensive ETD repository stored in the form of Knowledge Graphs that unlock unseen insights.

This endeavor seeks to democratize access to ETD data by constructing Knowledge Graphs that interconnect ETD metadata, preserving their intricate relationships with other elements within the ETD corpus. The integration of semantic enrichment for this largely textual data aims to facilitate seamless navigation for readers, users, researchers, and educators. For instance, the Knowledge Graph will establish links between figures and their corresponding captions, as well as between chapters and the figures, tables, and chapters nested within them. 


\subsection{Work Completed}

\qquad We initiated our project by selecting Virtuoso as our database solution due to its extensive functionality and open-source nature. Concurrently, we explored various APIs for integration. Our Subject Matter Expert, Satvik Chekuri, compiled a list of relevant objects, subjects, and predicates, which laid the groundwork for our project.

We began by setting up the framework for uploading RDF triples into Virtuoso, enabling structured storage and retrieval of semantically enriched data. Simultaneously, we used a temporary JSON conversion to bridge the gap between the original XML format and Virtuoso. We then proceeded to convert this JSON data into RDF triples in the desired N3 Format \cite{n3format}. This conversion was executed using the Python programming language and suitable public packages, like RDFLib \cite{rdflib}, representing a step in the population of our Knowledge Graph.

With this architecture and leveraging the available 200 ETDs, we constructed an initial version of our Knowledge Graph, which we were able to query via SPARQL. This solution has been hosted on the Endeavour cluster, with an
%publicly accessible 
endpoint for ease of access. Additionally, we conducted research to determine a suitable structure for Unified Resource Identifiers (URIs). These URIs are integral to our efforts to make enriched ETD content accessible through web pages.

During our discussions on potential use cases and queries our system may encounter, we refined our ontology. This refinement involved updating existing values and introducing new predicates, particularly focusing on addressing the bottom-up hierarchy and relationships within the ETD dataset.

These milestones represent significant progress in our goal of transforming ETD data into a structured and semantically enriched format.


\subsection{Scope of Further Work}

\qquad With the above work completed, we set out a list of future work that is necessary to achieve a fully functional service.

\begin{itemize}
  % \item \textbf{RDF Transformation}
  % \begin{itemize}
  %   \item Assign updated URIs to the graph nodes representing ETD metadata.
  %   \item Automate the conversion of extracted metadata into RDF format.
  % \end{itemize}
  
  \item \textbf{Triple Insertion}
  \begin{itemize}
    \item Automate the population of the Virtuoso database utilizing OpenLink APIs.
  \end{itemize}
  
  \item \textbf{Knowledge Graph Construction}
  \begin{itemize}
    \item Populate the graph with final persistent Object IDs.
  \end{itemize}
  
  \item \textbf{Semantic Search}
  \begin{itemize}
    \item Identify more example SPARQL queries.
  \end{itemize}

    \item \textbf{URI resolution Service}
  \begin{itemize}
    \item Integrate with the PostgreSQL database.
    \item Finalise UI for displaying the content.
  \end{itemize}
  
  % \item \textbf{Deployment}
  % \begin{itemize}
  %   \item Deploy a Dockerized version of the triples conversion script to the \textit{Endeavour} cluster.
  %   \item Deploy the Dockerized version of URI resolution microservice to the \textit{Endeavour} cluster.
  %   \item Write test cases for both the services.
  %   \item Enable CI/CD.
  % \end{itemize}
\end{itemize}

\pagebreak

\section{Literature Review}

\subsection{Knowledge Graph}

\qquad Knowledge Graphs, with their representation of information as nodes denoting entities and edges signifying relationships, have evolved as a pivotal paradigm in information organization and retrieval. This approach has garnered widespread applications across various domains, including semantic search, data integration, and knowledge representation \cite{bollacker2008}. The creation and maintenance of Google's Knowledge Graph, one of the largest and most comprehensive Knowledge Graphs to date, has not only revolutionized web search but has also laid the foundation for numerous applications that capitalize on this rich source of interconnected information \cite{google2012}.

Wikipedia, a cornerstone in the digital dissemination of knowledge, has played a pioneering role in the development of Knowledge Graphs. The Wikimedia Foundation's Wikidata project, an integral part of the Wikimedia ecosystem, serves as a centralized repository of structured data that powers Knowledge Graphs for Wikipedia and beyond. Wikidata encapsulates a wealth of information, including entities, their attributes, and interrelationships. This structured data forms the backbone of Wikipedia's Knowledge Graph, allowing for the seamless integration of diverse information across a multitude of topics \cite{vrandecic2014}. The Knowledge Graph enriches the browsing experience for Wikipedia users by providing contextual information, connections between topics, and additional insights into related subjects. This resource has not only enhanced the depth and breadth of information available on Wikipedia but has also become a valuable asset for a myriad of applications across the academic, research, and information retrieval domains \cite{wikimedia}.

In addition to its querying capabilities, Virtuoso incorporates a full-text search engine, which enables efficient text-based searches within RDF data. This feature is particularly crucial for applications reliant on text search functionality. The database's automatic metadata extraction streamlines data organization and indexing, enhancing search capabilities and enabling users to extract insights from a wide range of diverse data sources. Virtuoso's support for standard APIs such as JDBC, ODBC, and OLE DB ensures its compatibility with a broad spectrum of applications and development environments. Lastly, its built-in support for geospatial data provides advanced spatial query and analysis capabilities, a key asset for applications that rely on location-based data for decision-making and analysis \cite{bollacker2008}.

Furthermore, research efforts have focused on Knowledge Graph embeddings and representation learning. These approaches aim to embed entities and relationships into continuous vector spaces, facilitating machine learning applications on Knowledge Graphs. Techniques like TransE, DistMult, and ComplEx have shown promise in tasks such as link prediction and entity classification \cite{hubert2022knowledge}. The database's data virtualization capabilities are another strong feature, allowing users to access and query data from diverse sources, including external RDF datasets and web services, as though they were part of a unified database. This capability simplifies and streamlines data integration processes, particularly in contexts where multiple data sources need to be harmonized.

In previous years of this project the team planned to implement the knowledge graph as we have. It's important to note the entire structure of the overall system as well. Our Knowledge Graph and its application only comprises a small part of a much larger digital library system for storing and retrieving ETDs. The services in this digital library cover ingesting, storing, curating, analyzing, classifying, summarizing, topic modeling,  searching,  recommending, and interacting with ETDs and other elements/objects \cite{chekuri_jcdl_2023}. It's also worth noting that the knowledge graph has been worked on in years prior to the start of our project \cite{weedon}.


\subsection{Querying RDF Triple Databases}

\qquad RDF serves as the foundational data model for Knowledge Graphs, representing information in the form of subject-predicate-object triples. The subject-predicate-object triples represent two entities and the relationship they have with one another. Concurrently, the querying of RDF (Resource Description Framework) triple databases has garnered significant attention. RDF databases, exemplified by Virtuoso and Blazegraph, have played instrumental roles in efficiently storing and querying such interconnected data \cite{auer2007}.

In this context, SPARQL (SPARQL Protocol and RDF Query Language) standards have played a pivotal role. SPARQL provides a powerful and expressive query language tailored for RDF data, enabling precise retrieval of information from Knowledge Graphs \cite{harris2013}. Moreover, studies have focused on optimizing SPARQL query performance, exploring techniques such as query rewriting, caching, and indexing strategies to enhance efficiency \cite{hartig2017}.

In summary, the interplay between Knowledge Graphs and querying RDF triple databases constitutes a rich area of research with extensive applications across various domains. The development of large-scale Knowledge Graphs, advancements in querying techniques, and the integration with natural language processing and machine learning have collectively contributed to the growth and impact of this field.


\pagebreak

\section{Requirements}

\subsection{MVP Requirements}

The following gives baseline requirements for our system, also referred to as the minimum viable product:

\begin{itemize}
  \item Convert the ETD XMLs received from Team 3 into RDF triples. Store each relationship as a top down triple and a bottom up triple. 
  \begin{itemize}
         \item Store triples top down: higher elements point down to objects contained within them.  
          \begin{itemize}
         \item ETD $\rightarrow$ has chapter $\rightarrow$ chapter.
         \item Chapter $\rightarrow$ has figure $\rightarrow$ figure.
       \end{itemize}
         \item Store triples bottom up: elements point up to the objects that contain them.  
         \begin{itemize}
         \item Chapter $\rightarrow$ chapter of $\rightarrow$ ETD.
         \item Figure $\rightarrow$ figure of $\rightarrow$ Chapter.
       \end{itemize}
       \end{itemize}
  \item Insert RDF Triples into RDF database - Virtuoso.
  \item Search the digital objects in the Knowledge Graph
  \begin{itemize}
         \item Perform a search using SPARQL to retrieve all records matching the subject and predicate of the query.
         \item Perform a SPARQL search that retrieves all records related to the subject in any way. 
       \end{itemize}
\end{itemize}

The goal of the MVP is to enable users to view the semantic location of an object in an ETD. It is the function of the Knowledge Graph to ensure that this feature is possible. By storing the RDF triples of every objects within every ETD we can display all closely related objects to a given subject by performing a simple search. Because of the nature of Knowledge Graphs and RDF triples we will be able to show the user the nature and relationship of each related object. 

\subsection{Stretch Goals}

The following is a list of the stretch goals associated with the project. These are features or functionality that we wished to add but were unable to complete based on the available bandwidth.

\begin{itemize}
  \item Provide a UI for directly querying the Knowledge Graph.
  \item Provide support for Question Answering.
  \item Complement Elasticsearch by enabling the use of more specialized queries.
  \item Connect ETD Knowledge Graphs to one another based off reference and citation to form an interconnected Knowledge Graph of all ETDs.
  \item Extend the Knowledge Graphs with triples that arise from running Named Entity Recognition (NER) on the text within an ETD.
\end{itemize}

\pagebreak

\section{Design}

\subsection{Approach}


\begin{figure}[H]
\centering
\includegraphics[scale=0.55]{HighLevelDesignFigure.png}
\caption{High Level Design for the Service}
\label{fig:HLD}
\end{figure}



\qquad 
Overall our approach as displayed in Figure \ref{fig:HLD} has five distinct parts: RDF Transformation, Triple Insertion, Knowledge Graph Construction, SPARQL Querying, and Deployment.  The process begins with RDF transformation, where extracted metadata undergoes conversion into RDF format, establishing a structured representation. Every node representing Electronic Thesis or Dissertation (ETD) metadata is assigned a unique Uniform Resource Identifier (URI), enabling identification and retrieval within the RDF Knowledge Graph. In addition to this, every predicate, which is a value representing the relationship between objects, is also represented by a URI, helping to add structure and uniformity to relationships between nodes. Subsequently, the RDF database is populated with ETD Knowledge Graph triples, forming the foundational structure. These triples establish meaningful connections between nodes, culminating in the construction of a comprehensive Knowledge Graph. As examined later, relationships between nodes are precisely defined and structured, emphasizing important associations, such as those between documents and their respective chapters or figures, providing a contextual framework.

The development of SPARQL queries tailored to the specific RDF-based Knowledge Graph constitutes the next phase, facilitating precise information retrieval. A query is implemented to interpret SPARQL and RDF-based queries, ensuring a seamless search experience. This search leverages the Knowledge Graph to deliver contextually relevant search results, employing techniques for meaningful extraction. It allows users to search over the contents of every ETD to find objects by their object ID. Additionally, APIs are designed to enable seamless integration with external systems, facilitating easy interaction with the system. Finally, the solution is deployed to Endeavour, a cluster environment provided by the Department of Computer Science  at Virginia Tech. This approach combines RDF transformation, Knowledge Graph construction, and SPARQL querying to provide information retrieval from intricate data, providing a tool-set for extracting insights from the ETDs.

\subsection{Knowledge Graph}

% \subsubsection{Virtuoso}

% \qquad In our project we chose to use the open source RDF Database Virtuoso by OpenLink Software \cite{Virtuoso}. OpenLink's Virtuoso RDF database stands out with its array of distinct advantages over other RDF databases, positioning it as a preferred choice for numerous applications. Notably, Virtuoso boasts a flexible data model accommodating both relational and graph data representations, thus offering versatility in data handling and querying. Its high-performance SPARQL query engine is optimized to efficiently handle complex queries, even with substantial datasets, ensuring reliable information retrieval from the RDF database. This capability enhances the system's capacity to manage and process large-scale RDF datasets effectively. Moreover, Virtuoso integrates with SQL, empowering users to execute hybrid queries that seamlessly combine RDF and relational data. This integration deepens the system's querying capabilities, enabling users to query based upon several different criteria. 

% In our project we will upload the objects and relationships that are generated from the ETDs to Virtuoso, which will store them in a Knowledge Graph. This graph database will contain all the objects and relationships of every ETD in the system and will be query-able by the user through an endpoint on the endeavour cluster. The data from the ETDs will be uploaded in the form of Triples. These triples will retain the relationships between objects in an ETD allowing them to fully represent the semantic representation of each ETD. The triples use the resource description framework to establish structure and uniformity across the Knowledge Graph and ensure a that the graph is easily query-able by the user. 

\subsubsection{Resource Description Framework (RDF)}

\qquad RDF serves as a comprehensive framework for representing interconnected data. At its core, it employs URIs to denote nodes and edges within a graph. In the context of this project, RDF statements are utilized to describe and exchange metadata, specifically pertaining to Electronic Theses or Dissertations (ETDs). This framework is particularly valuable in scenarios involving large amounts of complex data, providing a means to parse it into a semantically searchable form. By modeling the data within an ETD -- encompassing both the document's metadata and its intricate relationships with chapters, tables, figures, and more -- as a Knowledge Graph, we can subsequently store it in the RDF database. This knowledge-driven approach enhances search functionality by yielding results with heightened relevance compared to conventional text-based searches. Moreover, this methodology helps us to effectively conduct searches over digital objects.

\subsubsection{RDF Triple}

\qquad RDF triples are the basic building blocks of data in the Semantic Web \cite{hitzler}. They provide a simple way to represent information in a machine-readable format. 

$\vspace{0.1cm}$

\begin{figure}[H]
\centering
\includegraphics[scale=0.735]{TripleSimpleExample.png}
\caption{Representation of an RDF Triple}
\label{fig:method}
\end{figure}

Each RDF triple consists of three parts (as demonstrated by Figure 2):
\begin{itemize}
  \item Subject: This represents the resource being described. In other words the subject is what the information is about. It is stored as a URI (Uniform Resource Identifier) in our system. 
  \item Predicate: This represents the property or relationship between the subject and the object. Like the subject, it is represented by a URI within our system. The predicate defines the kind of information being expressed such as \textit{title\_of}, \textit{chapter\_of}, \textit{cited\_by}, etc.
  \item Object: This represents the value of the property or relationship. It can be a URI or a literal value (like a string or a number). The object is what the subject's property is related to.
\end{itemize}


For our project we will process each ETD and generate RDF triples for all the data contained within it. This includes storing the chapter, figures, tables, abstracts, etc. of an ETD along with their relationships to other elements. In our approach to generating these RDF triples, we will build two sets of triples for each ETD we process. 
The basic reason for this is that the Knowledge Graph is directed, with each arc having a single direction. 

\begin{figure}[H]
\centering
\includegraphics[scale=0.45]{RDFExampleGood2.PNG}
\caption{Example Representation of a Top-Down RDF Triple}
\label{fig:method}
\end{figure}


The first set of triples will follow a top-down hierarchy with respect to how an ETD is organised. The ETD node will be the parent node and all subsections will be related child nodes. This means objects like chapter, author, and other entities will be connected to an ETD by the predicates ``hasChapter" and ``hasAuthor" (as demonstrated in Figure 3). It also means that because objects like a chapter have other objects inside it, then there must also be triples generated for these objects with the chapter as the subject of the triple. 


\begin{figure}[H]
\centering
\includegraphics[scale=0.45]{RDFExampleGood1.PNG}
\caption{Example Representation of a Bottom-Up RDF Triple}
\label{fig:method}
\end{figure}


The second set of triples will follow a bottom-up approach (see Figure 4). This approach lets figures, sections, paragraphs and other leaf nodes point back to their chapters and ETDs. This means that objects like chapter and abstract will now be in the subject position of an RDF triple and would connect to the ETD by the predicates ``ChapterOf" and ``AbstractOf". The objects contained within chapters and other objects would also be stored as the subject in the RDF triples connecting to the chapter or other object that contains them by the appropriate predicate. It is also important to note that because all subjects are stored as URIs and the bottom-up approach to the RDF triples essentially flips the triples to now store the objects of the top-down approach as subjects, then we must store objects as URIs as well. This only applies to objects where we wish for the leaf-node to be query-able and thus need a bottom-up triple as well. Certain objects, that are only stored as objects in the triples, are still stored as text and are only present in the top-down approach because it is not necessary to support the reverse query on these objects.   

The reason we must build the Knowledge Graph with two types of RDF triples is to support additional SPARQL queries. Generally, SPARQL queries can search two ways: subject only or subject plus predicate. Subject only means the query will return all triples where the given subject is present regardless of predicate. If this query were performed on a chapter for instance, the query would return all sections, paragraphs, figures, etc. where the given chapter was the subject of the triple. The subject plus predicate query would be used to search for specific objects located within chapters and ETDs. For example a query could be created to return all chapters of a given ETD by searching with the ETD as the subject and the predicate as ``hasChapter". With these two queries we can search for general connections for each subject as well as specific relationships it has. 

The problem arises when we try to query leaf nodes. For example say you wanted to see the chapter that a given paragraph is a part of. With only a top-down approach to the Knowledge Graph, this would be impossible to query. Since the paragraph only appears in the top-down triples as an object, we cannot search for it by subject only or subject and predicate. Thus the solution was to build a second set of RDF triple schema to help perform every query we could possibly need to. With the bottom-up approach to triples the leaf nodes are now stored in the subject column and can point to the objects they are contained within. This makes all possible connections query-able. 
In essence, we are adding inverse arcs so we are able to go in the reverse direction for a directed arc.


\subsubsection{ETD Graph Representation}


\begin{figure}[H]
\centering
\includegraphics[scale=0.12]{Bottom-Up_RDF_Schema_Draft.png}
\caption{Top-Down Knowledge Graph Representation for an ETD}
\label{fig:topdownrep}
\end{figure}


\qquad In the context of metadata-based triples, represented by Figure \ref{fig:topdownrep}, the subject pertains to any element within the Electronic Theses or Dissertations (ETDs) framework, encompassing entities such as equations, chapters, sections, tables, and more. The object, in turn, encompasses attributes or properties of the subject. For instance, a figure might possess objects like a file path and a corresponding caption. The predicate serves to establish the relationship between the subject and its attributes, denoted by expressions like ``hasSection/hasTable/hasChapter". When it comes to querying RDF data, SPARQL stands as the preeminent language. It necessitates the specification of a series of triple patterns, against which the data must align in one or more graphs. Each constituent of the triple is uniquely identified by a Uniform Resource Identifier (URI), which, in this scenario, references the generated URI that when clicked will open the browser to display the selected entity by retrieving the digital object from where it is stored.

\subsection{URI Resolution}

\subsubsection{Overview}

\qquad As mentioned, we seek to provide the user a capability to select any URI in the Knowledge Graph to see the entity it represents displayed in the browser. Since the Knowledge Graph design for our project uses URIs to store the subject, predicate, and, in some cases, the object, we must create a service to resolve the URIs that are stored as triples. When the user queries our Knowledge Graph the query will return with the triples that matched the desired search. The user should then be able to click on any URI to view it. This means that when a URI is clicked by a user it will be a valid URI in the browser and the page will show the element that the URI represents. If the user selects a URI for a figure, then the browser should show the image of the figure. If the user selects the URI of an entire ETD then the entire ETD should be displayed in the browser. In order to achieve this we must query the PostgreSQL database to retrieve the contents of the element. This feat requires the URIs to retain information that allows the URI resolver to understand what table must be queried and the key to query it with. Thus a complex schema for the URIs of the RDF triples becomes necessary because of the many different cases to handle. 


\subsubsection{URI Resolution Schema}


\qquad The first problem we encounter is that in order to query the PostgreSQL database we need a valid key for an object stored there. The current solution, as this is a working schema, is to store the object ID directly in the URI so it can be retrieved by the URI resolver when querying the PostgreSQL database. This solution requires the URI to store both the appropriate table for an entity and the appropriate key.  

\begin{figure}[H]
\centering
\includegraphics[scale=0.42]{VirtuosoTopDownExample.PNG}
\caption{RDF Triple URI Example for ETD's Chapter}
\label{fig:method}
\end{figure}

As shown by Figure 6, both the subject and object columns contain the database ID for the entries they represent. It is also worth noting that the predicate is also stored as a URI. When this URI is clicked by the user it will display simple information about the predicate and what relationship it portrays. 

This solution works great for every object that has its own key in the PostgreSQL database such as chapters, paragraphs, and ETDs. However there are metadata values in the database such as author, title, and other metadata elements that do not contain their own key. Rather they are stored in a separate table called ETD metadata. The working solution we have to retrieve these from the PostgreSQL database is to add a path in the URI.

\begin{figure}[H]
\centering
\includegraphics[scale=0.41]{VirtuosoHasAuthorExample.PNG}
\caption{RDF Triple URI Example for Author}
\label{fig:method}
\end{figure}

Figure 7 shows an RDF triple that represents the relationship between an ETD and its author. The difference between the author URI and a normal object URI is that the author of an ETD is not stored as its own object, but rather is stored in the metadata table. Thus from looking at the author URI the URI resolver must be able to determine that this is a metadata value and not an object. This is accomplished by including the ``/etd/" and ``/meta/" paths in the URI. After this the URI resolver knows that it is working with metadata, so it looks for the ID of the ETD and the metadata value we seek to query for. This retrieval technique would require a query to retrieve the correct metadata table and a query to retrieve title from this metadata table, with the title being eventually displayed on the browser. 


%add more here about URIs for figures: must go thru the file system, and for other ETDs that need a path in the URI 

\subsection{Querying the Knowledge Graph}

\qquad Originally, we had intended to work with Team 6 to create a UI page for the Knowledge Graph or at least incorporate its components into other pages. However due to the small size and limited scope of both of our teams we have pivoted to building a system to generate the full Knowledge Graph for all 500,000 ETDs, and allowing the user to directly query the graph. To query the Knowledge Graph there is a Docker image of Virtuoso running on the Endeavour cluster. This allows users to directly query the contents of the Knowledge Graph. The queries use SPARQL, which as previously stated is a query language for querying and manipulating data stored in Resource Description Framework (RDF) format. The user will simply add filters to refine the query in order to retrieve the triples and URIs the user seeks. 

\begin{figure}[H]
\centering
\includegraphics[scale=0.43]{VirtuosoQueryExample.PNG}
\caption{SPARQL Query Example}
\label{fig:SPARQL_Query_Example}
\end{figure}

Figure 8 is an example of how the querying on the Knowledge Graph works. The user first selects all the elements they want to display. If they want to see subject, predicate, and object then they should add ``SELECT ?subject ?predicate ?object" as is demonstrated in Figure 8. If the user only seeks to see the URI of the object, then they would simply add ``SELECT ?object". Secondly, the user is able to focus on filtering the query to find the information they seek. In Figure 8, the query is filtering for the subject and predicate. The values of the subject are being filtered by the ID of a specific ETD, and the value of the predicate is being filtered by the relationship ``hasChapter". Thus this query will return  all of the chapters of the specific ETD represented by the ID that was provided.

\begin{table}[ht]
\centering
\includegraphics[scale=0.43]{VirtuosoQueryResult.PNG}
\caption{RDF Triple Table of SPARQL Query Result}
\label{table:SPARQL_Query_Result}
\end{table}

Table 1 shows the result of the query. The subjects are all equal to the URI of the ETD that was provided, and all the predicates are equal to the URI of the ``hasChapter" predicate. Thus all the objects in this example are the URIs of the chapters contained within this ETD. Consequently, the user is able to view every chapter of the ETD. 

\subsection{Data Schema}

\subsubsection{ETD Metadata}

Table 2 includes a list of all possible value types for the metadata and objects of an ETD.

\begin{longtable}{|p{3cm}|p{8.5cm}|p{3cm}|}
    \hline
    \textbf{Word} & \textbf{Definition} & \textbf{Database} \\
    \hline
    \endhead % Header for subsequent pages
    Abstract & The abstract text for the ETD. & Metadata Table \\
    \hline
    Abstract General & The general abstract text for the ETD. This represents the abstract in terms so that the general public could understand. & Objects Table \\
    \hline
    Acknowledgement & The text of the acknowledgments given by the author in the ETD. & Metadata Table \\
    \hline
    Algorithm & An algorithm that appears in the ETD. & Objects Table \\
    \hline
    Author & The name of the author of the ETD. & Metadata Table \\
    \hline
    Chapter Summary & The summary of a chapter in an ETD. This is a value generated by the summarization model developed by Team 4. & Objects Table \\
    \hline
    Chapter Title & The title of a chapter in an ETD. & Objects Table \\
    \hline
    Cited Author & Any cited authors that appear in a given ETD. This means authors who are included in the bibliography section of an ETD. & Metadata Table \\
    \hline
    Committee Chair & The name of the chair of the committee. & Metadata Table \\
    \hline
    Committee Member & The list of committee members and their respective positions (advisor, co-advisor, etc.) that review the ETD. & Metadata Table \\
    \hline
    Date & The date that the ETD was published. & Metadata Table \\
    \hline
    Dedication text & The text of the dedications given by the ETD author. & Metadata Table \\
    \hline
    Degree & The degree of the author of the ETD. & Metadata Table\\
    \hline
    Department & The department to which the ETD was submitted. & Metadata Table \\
    \hline
    Equation & An equation that appears in an ETD. & Objects Table \\
    \hline
    Equation Number & The number assigned to a given equation in an ETD based on the sequential order. & Objects Table \\
    \hline
    Figure & A figure that appears in an ETD. & Objects Table \\
    \hline
    Figure Caption & The caption of a figure that appears in the ETD; it often provides background that describes the meaning of the figure. & Objects Table \\
    \hline
    Footnote & A footnote included in the ETD. & Metadata Table \\
    \hline
    Language & The language of the ETD. & Metadata Table \\
    \hline
    List of Contents Heading & The list of contents heading (e.g., ``Table of Contents'' or ``List of Figures'') of the ETD. & Objects Table \\
    \hline
    List of Contents Text & The actual text stored in the list of contents in the ETD. & Objects Table \\
    \hline
    Page Number & The page number of a page within the ETD. This will be used to relate figures, chapters, and other objects based on what page they appear on in the ETD. & Not Stored \\
    \hline
    Paragraph & The text of a paragraph within an ETD. & Objects Table \\
    \hline
    Reference Text & The text form of the references that were referenced in the ETD. & Metadata Table \\
    \hline
    Rights & The copyright and access rights of an ETD. & Metadata Table \\
    \hline
    Section & The text of a section within an ETD. & Objects Table \\
    \hline
    Sponsoring Agency & An agency or entity which is providing or intends to provide financing, e.g., in the form of grants, for a given ETD. & Metadata Table \\
    \hline
    Subject/Keywords & The keywords from the ETD, useful to get an idea of what the ETD is about. & Objects Table \\
    \hline
    Table & A table that appears in the ETD. & Objects Table \\
    \hline
    Table Caption & The caption of the table that appears in an ETD; it often provides background that describes the contents of the table. & Objects Table \\
    \hline
    Title & The title of the ETD. & Metadata Table \\
    \hline
    Topic Label & The topic label is a generated label that represents the topic the object relates to. The topic label will be generated for both chapters and overall ETDs, by Team 3. & Objects Table \\
    \hline
    University & The university to which the ETD was submitted. & Metadata Table \\
    \hline
    University Location & The location of the university where the ETD was submitted/uploaded to. & Not Stored \\
    \hline
    URI & The Uniform Resource Identifier of the ETD. & Metadata Table \\
    \hline
    \caption{Definitions in the ETD Knowledge Graph}
    \label{tab:etd_definitions}
\end{longtable}
    % \caption{RDF Top-Down Schema for the Knowledge Graph}
    % \label{tab:etd_knowledge_graph}

\subsubsection{RDF Triple Schema}

\qquad With all these possible value types for an ETD object there are a large number of possible relationships between different objects.
%The following tables represent 
Tables 3 and 4 list
all possible Subject, Predicate, and Object types that can be stored as an RDF triple within our system for both the top-down approach and the bottom-up approach, respectively.


%Forward table

\begin{table}[ht]
\centering
\begin{tabular}{|c|c|c|}
\hline
\textbf{Subject} & \textbf{Predicate} & \textbf{Object} \\
\hline
Chapter & classifiedAs & Classification Label \\
\hline
Chapter & hasAlgorithm & Algorithm \\
\hline
Chapter & hasEquation & Equation \\
\hline
Chapter& hasFigure & Figure \\
\hline
Chapter& hasPart & Footnote \\
\hline
Chapter& hasPart & Paragraph \\
\hline
Chapter & hasPart & Section \\
\hline
Chapter & hasSummary & Chapter Summary \\
\hline
Chapter & hasTable & Table \\
\hline
Chapter & hasTopic & Topic Label \\
\hline
Equation & hasPart & Equation Number \\
\hline
ETD & academicAdvisor & Committee Chair \\
\hline
ETD & academicDiscipline & Department \\
\hline
ETD & citedAuthor & Cited Author \\
\hline
ETD & dedicatedTo & Dedication Text \\
\hline
ETD & degreeType & Degree \\
\hline
ETD & hasAbstract & Abstract \\
\hline
ETD & hasAbstractGeneral & Abstract General \\
\hline
ETD & hasAcknowledgement & Acknowledgement \\
\hline
ETD & hasAuthor & Author \\
\hline
ETD & hasChapter & Chapter \\
\hline
ETD & hasCited & Reference Text \\
\hline
ETD & hasContents & List of Contents Heading \\
\hline
ETD & hasEquation & Equation \\
\hline
ETD & hasKeyword & Subject/Keywords \\
\hline
ETD & hasRights & Rights \\
\hline
ETD & hasTitle & Title \\
\hline
ETD & hasTopic & Topic Label \\
\hline
ETD & identifier & URI \\
\hline
ETD & issuedDate & Date \\
\hline
ETD & publishedBy & University \\
\hline
ETD & supportedBy & Sponsoring Agency \\
\hline
ETD & writtenIn & Language \\
\hline
Figure & hasCaption & Figure Caption \\
\hline
List of Contents Heading & hasPart & List of Contents Text \\
\hline
Table & hasCaption & Table Caption \\
\hline
University & location & University Location \\
\hline
\end{tabular}
\caption{RDF Top-Down Schema for the Knowledge Graph}
\label{tab:etd_knowledge_graph}
\end{table}



%Backward table


\begin{table}[ht]
\centering
\begin{tabular}{|c|c|c|}
\hline
\textbf{Subject} & \textbf{Predicate} & \textbf{Object} \\
\hline
Abstract & abstractOf & ETD \\
\hline
Abstract General & abstractOf & ETD \\
\hline
Acknowledgement & acknowledgementOf & ETD \\
\hline
Algorithm & algorithmOf & Chapter \\
\hline
Author & authorOf & ETD \\
\hline
Chapter Summary & summaryOf & Chapter \\
\hline
Chapter & partOf & ETD \\
\hline
Classification Label & classificationOf & Chapter \\
\hline
Committee Chair & advisorOf & ETD \\
\hline
Committee Member & committeeOf & ETD \\
\hline
Dedication Text & dedicatedBy & ETD \\
\hline
Equation & equationOf & Chapter \\
\hline
Equation Number & partOf & Equation \\
\hline
Figure & figureOf & Chapter \\
\hline
Figure Caption & captionOf & Figure \\
\hline
Footnote & partOf & Chapter \\
\hline
List of Contents Heading & contentsOf & ETD \\
\hline
List of Contents Text & partOf & List of Contents Heading \\
\hline
Paragraph & partOf & Chapter\\
\hline
Rights & rightsOf & ETD \\
\hline
Section & partOf & Chapter \\
\hline
Table & tableOf & Chapter  \\
\hline
Table Caption & captionOf & Table \\
\hline
Title & titleOf & ETD \\
\hline
Topic Label & topicOf & Chapter \\
\hline
Topic Label & topicOf & ETD \\
\hline
University & hasPublished & ETD \\
\hline
\end{tabular}
\caption{RDF Bottom-Up Schema in the ETD Knowledge Graph}
\label{tab:etd_knowledge_graph}
\end{table}






\clearpage

\subsection{Tools}

Below is a list of the tools we use in this project:

\begin{itemize}
    \item Programming Languages - We use Python and JavaScript to write our services. The XML to RDF triple conversion service is developed in Python and the URI resolution service is developed in JavaScript's server-side runtime environment, Node.js.
    \item CI/CD - Docker \cite{Docker} is used to containerize our services and we utilise GitLab's DevOps platform to develop integration and deployment pipelines. It is intended to modularize our work and provide an easy interface for future work to build off of.
    \item Inter-Service Communication - Kafka \cite{Kafka} can be used for fetching XML of any new processed ETD, and lead to use of RESTful APIs for experimenters of other microservices to consume them.
    \item Database - Apart from Virtuoso, PostgreSQL \cite{PostgreSQL} is used as the database to store the ETD metadata and objects. For storing figures and images each row has a column that points to a location in the file system where the digital format is stored.
    \item Graph DB - Virtuoso \cite{Virtuoso} is used to store and query the generated RDF triples. This database would store the relations between the subjects and objects that the object detection team, Team 3, identifies.
\end{itemize}


\pagebreak

\section{Implementation}

\subsection{Overview}

\qquad Our project's technical implementation centers around the creation of an extensive Knowledge Graph and the generation of RDF triples to represent a comprehensive collection of ETD metadata, facilitating queries via the SPARQL language. Our approach adopts an event-driven architecture with inter-service communication.

The initial step in our (Team 1) workflow involves accessing processed XMLs containing ETD metadata, which are provided by Team 3. This process was initially envisioned to be initiated by listening to a Kafka Consumer that subscribes to Team 5's Kafka Topic responsible for an XML file publication, generated through ETD Object Detection algorithms maintained by Team 3. The Kafka cluster was to be centrally deployed by Team 5 and Team 3 would've sent data to the respective Kafka Topic whenever a new ETD was processed. However, due to complications in other teams, this architecture could not be implemented within the desired time-frame. We had to manually ingest XML files received from Team 3. This means Team 3 would email or otherwise send us a zipped folder containing the XMLs. We would place them in a directory that the script would then read from. The XML files produced contain the complete ETD information along with unique object IDs that Team 3 generates using the PostgreSQL database. We lay the groundwork for future researchers to automate this asynchronous data pipeline.

Once we acquire an XML file, a Python script is employed for systematic conversion into JSON format and the subsequent generation of RDF triples for the specified ETD. These triples are encoded in the N3 RDF format utilizing Python packages, and encompass both the top-down and bottom-up predicate ontology. These RDF triples are then uploaded into our RDF database using SPARQL's INSERT functionality, accessible through RESTful APIs via SPARQLWrapper. SPARQLWrapper is a simple Python package around the SPARQL service that helps in RESTfully executing queries.

Upon successful insertion of RDF triples, Virtuoso internally orchestrates the creation and update of graphs, abstracting this process from the end user. It ultimately furnishes a SPARQL endpoint, enabling the retrieval of specific relationship types associated with a given subject entity. This query interface is indispensable for supporting the visualization component in the front end, assisting users in locating objects within an ETD.

Our efforts align with those of Team 2, responsible for core search functionality utilizing Elasticsearch in the backend. By persisting semantic linked data, we aim to augment users' search capabilities, facilitating specialized analysis, insights, and visualizations. Within the scope of the current implementation, our Knowledge Graph system is not directly invoked by end users via the frontend interface that Team 6 has constructed. Instead, it is utilized through a
%publicly hosted 
SPARQL interface. Through this default Virtuoso interface (see Figure \ref{fig:SPARQL-iterface}), users can query the Knowledge Graph with flexibility. 

% While the current implementation exposes this SPARQL interface publicly, it will be privatized and made accessible solely to users registered on our platform.

%image for default interface
\begin{figure}[H]
\centering
\includegraphics[scale=0.3]{images/sparql_portal.png}
\caption{Default Virtuoso SPARQL Interface}
\label{fig:SPARQL-iterface}
\end{figure}

The responses of SPARQL queries contain de-referenceable URIs, see Table \ref{table:SPARQL_Query_Result}, that users can click to retrieve additional related information. Our system furnishes these linked, clickable URIs within the SPARQL interface by implementing a URI resolver microservice. This is developed using a representational state transfer (REST) architecture and acts as an independent backend service. It utilizes configurable business logic to resolve URIs based on extracted path parameters from the incoming API request. The microservice is containerized using Docker to enable portability and scalability. To enrich the response payload, the microservice interacts with various relational tables in Team 5's PostgreSQL database. The microservice response consists of static hypertext markup language (HTML) and cascading style sheets (CSS) content rendered as web pages.
See Figure \ref{fig:uri-resolution-webpage}, giving the result as seen in the user's browser. The HTML is configured for accessibility using semantic tags.

%image for default endpoint
\begin{figure}[H]
\centering
\includegraphics[scale=0.4]{images/uri_resolution.png}
\caption{URI resolution service response for ``abstract" predicate search of ETD with id 12345}
\label{fig:uri-resolution-webpage}
\end{figure}


Python and JavaScript are our primary programming languages for this project. Each microservice and their modules will be leveraging both standard libraries and external packages. Docker will be used for containerization to ensure consistent deployment across various environments. We planned to harness Kafka for efficient inter-service communication, optimizing data retrieval and integration processes. This implementation strategy aims to create a robust system capable of efficiently processing and extracting meaningful insights from ETD metadata, contributing to the overall success of the project.

\subsection{List of Milestones and Deliverables}

The following is a comprehensive list of milestones and deliverables in the project.

\begin{itemize}
    \item Virtuoso Image Running   
        \begin{itemize}
            \item Find Virtuoso's open source image on Dockerhub.
            \item Instantiate this image on our local system and the Endeavour cluster and achieve Virtuoso's functionality.
        \end{itemize}
    \item Script to convert JSON to RDF Triples.
        \begin{itemize}
            \item Finalize RDF Schema.
        \end{itemize}
    \item Upload/Insert RDF Triples into Virtuoso.
        \begin{itemize}
            \item Integrate with SPARQLWrapper to INSERT data in Virtuoso programmatically.
            % \item Determine if this process should be done per ETD or must be performed in batches.
        \end{itemize}
    \item Receive data
        \begin{itemize}
            \item Plan to integrate with Kafka Topic of Team 3 and consume data in an asynchronous manner.
            \item Process a sample dataset provided by Team 3.
        \end{itemize}
    \item Define example queries for the Knowledge Graph
        \begin{itemize}
            \item Determine SPARQL examples for querying RDF triples.
            \item Perform searches retrieving relevant objects related to a subject.
            \item Perform semantic search query to retrieve specific relationship types and objects.
        \end{itemize}
\end{itemize}

\subsection{Timeline}

\qquad
%The following table demonstrates 
Table 5 gives
the assignments of each task involved in the implementation as well as the timeline for the deliverables.

\begin{table}[h]
\centering
\begin{tabular}{|c|c|c|c|}
\hline
\textbf{Tasks} & \textbf{Assignee} & \textbf{Status} & \textbf{Due Date} \\
\hline
Virtuoso Image Running & Ashish Aggarwal & Done & Oct 3 \\
\hline
Manual Script to convert JSON to RDF Triples  & Daniel Gaugler & Done & Oct 3 \\
\hline
Predicate Ontology & Satvik Chekuri & Done & Oct 10\\
\hline
Manual Upload/Insert RDF Triples into Virtuoso  & Whole Team & Done & Oct 19\\
\hline
Automate Script to convert JSON to RDF Triples  & Daniel Gaugler & Called Off & Oct 25 \\
\hline
Automate Upload/Insert RDF Triples into Virtuoso  & Whole Team & Done & Nov 1 \\
\hline
Design URI resolution service & Whole Team & Done & Nov 1\\
\hline
Integrate with Kafka instance  & Whole Team & Called Off & Nov 5\\
\hline
Implement URI resolution service & Whole Team & Done & Nov 15\\
\hline
Write test cases for both services & Whole Team & Done & Nov 20\\
\hline
Implement CI/CD to both services & Whole Team & Done & Nov 20\\
\hline
\end{tabular}
\caption{Task Assignments, Status and Due Dates}
\label{tab:task_assignments}
\end{table}

% \begin{table}[h]
% \centering
% \begin{tabular}{|c|c|}
% \hline
% Output & Due Date \\
% \hline
% Support ingestion and storage of ETD objects & Oct 19\\
% \hline
% Support depth search over RDF triples  & Oct 28 \\
% \hline
% Support semantic query over RDF triples & Oct 28 \\
% \hline
% \end{tabular}
% \caption{Project Outputs}
% \label{tab:milestones}
% \end{table}


\pagebreak

\section{Future Work}

\subsection{Securing the SPARQL Endpoint}
The current SPARQL endpoint
%, \url{https://virtuoso.endeavour.cs.vt.edu/sparql}, 
allows open, public access without authentication or usage restrictions. This poses risks of denial-of-service attacks or unauthorized data mining. It is urgent that future work should implement access controls and query analysis to secure the endpoint. Possible security measures include VPN-restricted or SSO enabled access, allowing only authorized users and processes to query. The end goal should be an enterprise-grade endpoint with authentication, optimized querying, and protections against threats. This robustness will prove critical as dataset scale and user loads grow over time.

\subsection{Expanding the ETD Dataset}
%As of this writing, t
The Virtuoso database contains 200 XML records serving as dummy data for testing purposes. The next critical step is integrating the full dataset of 500,000 enriched ETD records that will enable more robust testing and analysis. Structuring and mapping this data properly within Virtuoso is an essential task for future researchers. Establishing standardized processes for ongoing data integration as new ETDs are published should also be a priority.

\subsection{Implementing Automated Data Pipelines}
While the current process relies on manual uploading of XML files, introducing automated pipelines using Kafka for data transfer would improve reliability and efficiency. The initial design had been laid, but full Kafka integration proved infeasible due to delays with other system components. Future efforts should focus on completing this integration to allow seamless transfer of new ETD records from upstream processing into the Virtuoso database. Creating this pipeline is key for scaling up the system.

\subsection{Connecting the Search and SPARQL Interfaces}
To improve the overall user experience, the semantic SPARQL query features would ideally integrate with the search and discovery interface via the unified web interface that Team 6 developed. This would empower users with a single portal to access the full capabilities of the system. The design process should emphasize usability and leverage SPARQL to underpin advanced search functionalities. Thorough user testing will help ensure the interface design is intuitive for researchers while providing the full richness of the underlying Linked Data.

\subsection{Knowledge Graph of Entities from ETDs}

The future work outlined here closely follows the methodology in \cite{satvik_dc_jcdl}.

We have built a proof-of-concept of a Knowledge Graph capturing the structure of ETDs and their elements using ~200 ETD XMLs. To efficiently aid the ETDs with downstream tasks such as summarization, search, and QA, the KG must build a suitable
representation of the ETDs, capturing semantic information. The representation should include a
structure reflecting the intra- and inter-document entity-entity relations.
The Knowledge Graph structure, as a directed heterogeneous graph with domain related semantics, must accommodate what has
been extracted from ETDs. This
is essential, since transformer based models mostly excel in short, single documents, not dealing
with long documents (due to attention limitations). The ETD KG should fill this gap, aiding
downstream tasks through a graph representation of the entities and relations extracted from the
ETDs, with both in-document and distant document relations connecting entities.

We propose to build the entity-based KG for a
collection of documents by first extracting entity-related triples using improved methods for OpenIE and NER \cite{jehangir_ner_survey} for the
different entities and relations. 
Triples will yield node-edge-node additions to the graph, with entities as nodes.
This graph will be extended and enriched using entities from all of the ETDs. This will have an impact on the coverage and performance of KGs in downstream tasks such as search and question-answering by including entity-related triples extracted from various text-based elements in the ETDs.


\pagebreak

\section{User Manual}

 \qquad This user manual will guide you through the process of querying our Knowledge Graph using the SPARQL query language. The application allows you to search for records based on the subject or predicate and retrieve detailed information about the matches.

\subsection{Accessing the Query Interface}

\begin{itemize}
    \item Open the application in your preferred web browser.
    \item Navigate to \textit{https://virtuoso.endeavour.cs.vt.edu/sparql}
    \item The page should display a large text box for users to enter their queries.
\end{itemize}

\subsection{Querying for Records}

 In the query input box, enter your SPARQL query. Example queries are provided for reference. Figure \ref{fig:queryex1} displays an example query that retrieves all triples related to a specific subject. In this case the subject is an ETD with the ID ``6384228". Figure \ref{fig:queryex2} displays a query for all triples with a given predicate. The predicate in question is ``hasChapter", so the query will return every triple for every chapter of every ETD. Figure \ref{fig:queryex3} displays a query that filters by both subject and predicate.

\begin{figure}[ht]
    \centering
    \includegraphics[width=0.95\textwidth]{VirtuosoQueryExampleSubject.PNG}
    \caption{Retrieve all triples related to a specific subject.}
    \label{fig:queryex1}
\end{figure}

\begin{figure}[ht]
    \centering
    \includegraphics[width=0.95\textwidth]{VirtuosoQueryExamplePredicate.PNG}
    \caption{Retrieve all triples related to a specific predicate.}
    \label{fig:queryex2}
\end{figure}


\begin{figure}[H]
    \centering
    \includegraphics[width=0.95\textwidth]{images/VirtuosoQueryExampleBoth.PNG}
    \caption{Retrieve all triples related to a specific subject and predicate.}
    \label{fig:queryex3}  
\end{figure}

Click the ``Execute Query" button to submit your query. The application will return a list of RDF triples that match your query.

\subsection{Viewing Details of a Record}

In the query results, each triple is represented with Subject, Predicate, and Object URIs. After pressing the execute query button the user will automatically be taken to a page displaying all the triples that match the query. An example of this is given in Figure \ref{fig:queryresult}. This figure shows the results of the query shown in Figure \ref{fig:queryex3}.   

\begin{figure}[ht]
    \centering
    \includegraphics[width=1.0\textwidth]{VirtuosoQueryResult.PNG}
    \caption{Results of the query that filters for both predicate and subject.}
     \label{fig:queryresult} 
\end{figure}

From here the user is able to click on the URI of a record to view detailed information about that object. Figure \ref{fig:uriresolutionex} displays an example of the URI resolution service displaying an abstract of an ETD.

\begin{figure}[H]
    \centering
    \includegraphics[width=1.0\textwidth]{uri_resolution.png}
    \caption{Clicking on the Subject URI to view details.}
     \label{fig:uriresolutionex} 
\end{figure}






\pagebreak


\section{Developer Manual}

\subsection{URI Resolution Service}
This is a Node.js and Express.js based Web service hosted on the Endeavour cluster. The domain name for the service is \url{https://etdkb.endeavour.cs.vt.edu}. There are 3 routes in this service.
\begin{enumerate}
    \item v1/etd/:etdId/meta/:metaProp
    \begin{itemize}
        \item Params: ETD ID and metadata value to fetch.
        \item This route fetches data based on the ETD ID from the metadata table of PostgreSQL database hosted by Team 5.
    \end{itemize}
        \item v1/objects/:objectId
    \begin{itemize}
        \item Params: Object ID of the object
        \item This route fetches data based on the Object ID from the Objects table of the PostgreSQL database hosted by Team 5.
    \end{itemize}
        \item v1/predicate/:predicateName
    \begin{itemize}
        \item Params: Bottom-up or Top-down predicate name.
        \item This route fetches data based on the predicate name from a JSON file stored in this service's server.
    \end{itemize}
\end{enumerate}

To run it locally, 
\begin{itemize}
    \item make sure you have Node.js and NPM installed on your computer,
    \item \textit{git clone} the repo,
    \item run \textit{npm i} from the terminal, and
    \item run \textit{npm start} from the terminal. This would start the local server on port 3000, \textit{localhost:3000}.
\end{itemize}
 Using a tool like Postman, the above mentioned routes can be invoked. To run test cases, use the command \textit{npm test} from the terminal.

The errors for this service are logged into Team 2's Elasticsearch index. To search the logs in their index, have the \textit{User} parameter as \textit{kg-uri-app-logs}. The index.js file of our URI resolution service has the implementation for POSTing logs. Currently, only the global error logs are sent to the Elaticsearch index, but this functionality can be extended to other log types too. More details on accessing logs, searching logs, and Kibana access can be found in the report of Team 2.


\subsection{ETD Processing and Triple Generation Script}


\begin{figure}[H]
    \centering
    \includegraphics[width=1.0\textwidth]{KnowledgeGraphFigure.PNG}
    \caption{High-level view of XML Schema.}
     \label{fig:xmlschema} 
\end{figure}



\qquad The ETD processing and triple generation script is designed to convert XML files representing Electronic Theses and Dissertations (ETDs) into dictionaries and generate triples from these dictionaries. The schema for the XML files is displayed in Figure \ref{fig:xmlschema}. Every XML has a front, which contains metadata values like Title, Author, and Date. The XML files also contain a body section. This body section contains all the chapters of an ETD. Within the chapters are the multiple sections that make up a chapter. Within these sections are objects like figures, tables, and paragraphs. All these objects must be extracted from where they are contained and have triples generated for their relationships. It is currently designed for local processing, with future plans to host it on the Endeavour cluster and read ETDs from a Kafka topic. The script follows these key steps:

\begin{enumerate}
  \item \textbf{XML to Dictionary Conversion:} The script parses through each XML file in the provided collection of ETDs, converting the XML structure into Python dictionaries to capture the hierarchical relationships and attributes of each element.

  \item \textbf{Triple Generation Methods:} For each object encountered in the XML files, the script generates triples using specific methods tailored to each object type. These methods accommodate variations in triple structures for different types of ETD-related entities, such as chapters, sections, figures, tables, and metadata.

  \item \textbf{Metadata Triple Generation:} In addition to object-specific triple generation methods, there is a general method to handle the metadata of the ETD. This method extracts relevant information, such as title, author, date, university, and other metadata, and generates triples accordingly.

  \item \textbf{Local Execution:} Currently, the script is designed to run locally, processing the entire collection of XML files in a batch, providing a quick way to generate triples for analysis.

  \item \textbf{Future Work: Kafka Integration:} The script has future plans to be hosted on the Endeavour cluster and read ETDs one at a time from a Kafka topic. This enhancement would allow for real-time processing and integration into a larger data pipeline.
\end{enumerate}

\subsubsection{Analysis Script}

In addition to the ETD processing script, there is an analysis script designed to examine the generated triples and derive insights from the ETD data. The results of the analysis script include information about the count of certain predicates and patterns within the ETDs, facilitating a deeper understanding of the content and structure of the academic documents. The results of the analysis script are displayed in Table 6. 

\begin{table}[H]
\centering
\begin{tabular}{|l|r|}
\hline
\textbf{Term} & \textbf{Count} \\
\hline
abstractOf & 145 \\
algorithmOf & 143 \\
authorOf & 158 \\
captionOf & 6777 \\
chapterOf & 1403 \\
committeeOf & 138 \\
degreeType & 156 \\
equationOf & 5891 \\
figureOf & 4895 \\
hasAbstract & 145 \\
hasAuthor & 158 \\
hasCaption & 6777 \\
hasChapter & 1403 \\
hasCommittee & 138 \\
hasContents & 475 \\
hasEquation & 5891 \\
hasAlgorithm & 143 \\
hasFigure & 4895 \\
hasPart & 42609 \\
hasPublished & 133 \\
hasTable & 1882 \\
issuedDate & 146 \\
partOf & 8534 \\
publishedBy & 133 \\
hasTitle & 156 \\
titleOf & 156 \\
tableOf & 1882 \\
\hline
\end{tabular}
\caption{Predicate Term Counts}
\label{tab:term-counts}
\end{table}


\subsubsection{Usage}

\begin{enumerate}
  \item \textbf{Local Execution:}
    \begin{enumerate}
      \item Ensure Python is installed on your machine.
      \item Install the necessary dependencies by running \texttt{pip install -r requirements.txt}.
      \item Execute the script using the command \texttt{python etd\_processing\_script.py}.
    \end{enumerate}

  \item \textbf{Future Deployment:}
    For future deployment on the Endeavour cluster, additional configuration steps and dependencies may be required. Consult the deployment documentation for the specific environment.
\end{enumerate}

The ETD processing and triple generation script, along with the analysis script, provides a foundation for extracting valuable information from ETDs. Future development efforts should focus on hosting the code on the Endeavour cluster and integrating it with Kafka for a scalable and real-time processing solution.


\subsection{Virtuoso Database}
The Virtuoso image used for this project is available at \url{https://hub.docker.com/r/openlink/virtuoso-opensource-7}. The configuration of this image required a username and password which is available with our SME, Satvik Chekuri. We were helped with this configuration by Team 5 when they deployed the image on Endeavour. The admin console is hosted at \url{https://virtuoso.endeavour.cs.vt.edu} and uses the same set of username and password as above.

\subsection{CI/CD}
To enable continuous integration and deployment we are utilising the DevOps functionality of our version control tool, GitLab. Team 5 has spearheaded this setup for our team.
\subsubsection{URI Resolution Service}
The first step in enabling CI/CD is Dockerizing the application. The Docker file is added in the root of the code directory. Figure \ref{fig:docker-uri} shows the Docker configuration used for this service.

\begin{figure}[H]
\centering
\includegraphics[scale=0.55]{images/docker_uri.png}
\caption{Docker file for URI Resolution Service}
\label{fig:docker-uri}
\end{figure}

The second step is to write the GitLab \textit{.gitlab-ci.yml} file. This file is automatically detected by the GitLab Agents responsible for running CI/CD. The stages in this file are run sequentially and the pipeline auto-triggers whenever a commit is pushed to the \textit{master} branch. Figure \ref{fig:yaml-uri-res} shows the YAML configuration for this service.

\begin{figure}[H]
\centering
\includegraphics[scale=0.95]{images/yaml-uri-res.png}
\caption{YAML file for URI Resolution Service}
\label{fig:yaml-uri-res}
\end{figure}
\pagebreak

\section{Bibliography}

\begin{thebibliography}{9}

\bibitem{auer2007}
Auer, S., Bizer, C., Kobilarov, G., Lehmann, J., Cyganiak, R., \& Ives, Z. (2007).
\textit{DBpedia: A nucleus for a web of open data.}
In The Semantic Web (pp. 722-735). Springer, Berlin, Heidelberg.

\bibitem{bollacker2008}
Bollacker, K., Evans, C., Paritosh, P., Sturge, T., \& Taylor, J. (2008).
\textit{Freebase: A collaboratively created graph database for structuring human knowledge.}
In Proceedings of the 2008 ACM SIGMOD international conference on Management of data (pp. 1247-1250).

\bibitem{google2012}
Google. (2012).
\textit{Introducing the Knowledge Graph: Things, not Strings [Blog post].}
Retrieved from \url{https://googleblog.blogspot.com/2012/05/introducing-knowledge-graph-things-not.html}, 
 accessed on October 1, 2023.

\bibitem{harris2013}
Harris, S., \& Lamb, A. (2013).
\textit{SPARQL 1.1 Query Language. W3C Recommendation 21 March 2013.}
Retrieved from \url{https://www.w3.org/TR/sparql11-query/}, accessed on October 1, 2023.

\bibitem{hartig2017}
Hartig, O. (2017).
\textit{Foundations of an alternative approach to reification in RDF.}
arXiv preprint arXiv:1708.01894.

\bibitem{huang2016}
Huang, Z., Xu, W., \& Yu, K. (2016).
\textit{Bidirectional LSTM-CRF models for sequence tagging.}
arXiv preprint arXiv:1508.01991.

\bibitem{vrandecic2014}
Vrandečić, D., \& Krötzsch, M. (2014).
\textit{Wikidata: A free collaborative knowledgebase.}
Communications of the ACM, 57(10), 78-85.

\bibitem{wikimedia}
Wikimedia Foundation. (2023).
\textit{Wikidata: The Free Knowledge Base.}
Retrieved from \url{https://www.wikidata.org/}, accessed on October 1, 2023.

\bibitem{hubert2022knowledge}
Nicolas Hubert, Pierre Monnin, Armelle Brun, and Davy Monticolo.
\textit{Knowledge Graph Embeddings for Link Prediction: Beware of Semantics!}
In \textit{DL4KG@ISWC 2022: Workshop on Deep Learning for Knowledge Graphs, held as part of ISWC 2022: the 21st International Semantic Web Conference}, Oct. 2022, Virtual, China.
\url{https://hal.archives-ouvertes.fr/hal-03787512}


\bibitem{Docker}
Docker Inc. 2023.
\textit{Docker}.  
Retrieved from \url{https://www.docker.com/}, accessed on November 7, 2023.

\bibitem{Kafka}
Apache Software Foundation. 2023.
\textit{Apache Kafka}.  
Retrieved from \url{https://kafka.apache.org/}, accessed on November 7, 2023.

\bibitem{PostgreSQL}
 The PostgreSQL Global Development Group. 2023. 
\textit{PostgreSQL}.  
Retrieved from \url{https://www.postgresql.org/}, accessed on November 7, 2023.

\bibitem{Virtuoso}
OpenLink Virtuoso Universal Server Documentation Team. 2023. 
\textit{Virtuoso}.   
Retrieved from \url{https://virtuoso.openlinksw.com/}, accessed on November 7, 2023.

\bibitem{n3format}
Tim Berners-Lee,
Dan Connolly. 2023. 
\textit{N3 RDF Format}. 
Retrieved from \url{https://www.w3.org/TeamSubmission/n3/#:~:text=The%20Resource%20Description%20Framework%20(%20RDF,is%20a%20superset%20of%20RDF}, accessed on November 7, 2023.

\bibitem{rdflib}
 RDFLib Team.  2023. 
\textit{RDFLib}.
\textit{RDFLib Documentation}. 
Retrieved from \url{https://rdflib.readthedocs.io/en/stable/}, accessed on November 7, 2023.

\bibitem{satvik_dc_jcdl}
Satvik Chekuri.
\textit{Hierarchical Knowledge Graph for Long Documents and their Elements}.
In \textit{Doctoral Consortium held June 2023 as part of  ACM/IEEE JCDL, Santa Fe, New Mexico, USA.} To appear, 2023 presentation.


\bibitem{hitzler}
Pascal Hitzler. (2021).
\textit{A Review of the Semantic Web Field.
}
In \textit{Proceedings
of ACM, New York, NY, USA. \url{https://doi.org/10.1145/3397512}
}

\bibitem{jehangir_ner_survey}
Basra Jehangir, Saravanan Radhakrishnan, Rahul Agarwal.
\textit{A survey on Named Entity Recognition — datasets, tools, and methodologies}.
\textit{Natural Language Processing Journal}, Volume 3, 2023, 100017.
ISSN 2949-7191.
\url{https://doi.org/10.1016/j.nlp.2023.100017}.
(https://www.sciencedirect.com/science/article/pii/S2949719123000146).

\bibitem{chekuri_jcdl_2023}
Satvik Chekuri, Prashant Chandrasekar, Bipasha Banerjee, Sung Hee Park, Nila Masrourisaadat, Aman Ahuja, William A. Ingram, and Edward Fox.
\textit{Integrated Digital Library System for Long Documents and their Elements}.
In \textit{Proceedings of the 23rd ACM/IEEE-CS Joint Conference on Digital Libraries (JCDL 2023)}, nominated for Best Student Paper, pages 13-24, DOI: 10.1109/JCDL57899.2023.00012, 2023.

\bibitem{weedon}
Daniel B. Weedon,
Daniel Olsen. 2021.
\textit{Knowledge Graphs}.
In \textit{CS 4624: Multimedia, Hypertext, and Information Access}, Virginia Tech team project, Blacksburg, VA, \url{http://hdl.handle.net/10919/103271}



\end{thebibliography}

\end{document}
