# A Knowledge Graph Framework to Support Life Cycle Assessment for Sustainable Decision-Making
## 2 Theoretical Foundations and Related Works
### Knowledge Graphs
Formally, an LPG is defined as follows [26; 27]:  
\[\mathcal{G}_{LPG}=(V,E,\Sigma,L,P)\]  
it contains the following:  
* \(V\) is a finite set of vertices (representing entities, concepts, or objects). * \(E\subseteq V\times V\) is a finite set of directed edges (representing relationships between entities). * \(\Sigma\) is a finite set of labels. * \(L:V\cup E\rightarrow\mathcal{P}(\Sigma)\) is a labeling function assigning one or more labels from \(\Sigma\) to each vertex or edge (\(\mathcal{P}(\Sigma)\), and it denotes the power set of \(\Sigma\)). * \(P:(V\cup E)\times K\to D\) is a partial function that assigns properties, where \(K\) is a set of property keys, and \(D\) is a domain of data values (e.g., strings, integers, and floats). If \(P(x,k)\) is defined for some \(x\in V\cup E\) and \(k\in K\), then \(P(x,k)\in D\). An LPG also has the following characteristics:  
1. Each vertex, \(v\in V\), represents an entity, object, or concept. A vertex may have zero, one, or multiple labels indicating its type or category: \(L(v)\subseteq\Sigma\). 2. Each edge, \(e\in E\), is a directed relationship between vertices \((v_{i},v_{j})\), and may have zero, one, or multiple labels: \(L(e)\subseteq\Sigma\). Labels typically denote the semantic role of the relationship (e.g., _isPartOf, producedBy_). 3. Both vertices and edges may have properties, defined as key-value pairs. For a vertex, \(v\in V\), or an edge, \(e\in E\), and a key, \(k\in K\), \(P(v,k)\) or \(P(e,k)\) returns a literal value in \(D\) if defined. For example, a node representing a product might have properties like weight = 5.3 (in kilograms) and material = \"steel\". The construction of KGs can follow manual or automated approaches, depending on the requirements for precision, scalability, and domain specificity. Manual construction is commonly used when expert knowledge and accuracy are prioritized. The process begins with the identification of entities and relationships, often achieved through a thorough analysis of the domain literature, expert interviews, or existing databases. Ontology management tools, such as Protege, are frequently used to model and store this knowledge. Competency questions, which define the requirements for the knowledge graph, are formulated and later translated into SPARQL queries to validate the graph's structure. To ensure quality and consistency, tests based on these queries, encapsulated as SHACL constraints, are conducted. This process ensures that the resulting knowledge graph aligns closely with the specified domain requirements, although it remains time-consuming and resource-intensive [28]. In contrast, automated approaches significantly improve efficiency and scalability. These methods begin with data acquisition from diverse sources, including structured databases and unstructured textual data. Techniques such as named entity recognition (NER) and relation extraction, supported by machine learning models like BERT-BiLSTM-CRF, are employed to identify entities and relationships [29]. Automated systems integrate information from multiple data sources, often employing semantic similarity measures or pre-trained language models to ensure accuracy. Large frameworks such as SAC-KG leverage advanced natural language processing algorithms and large language models to construct and validate knowledge graphs with minimal human intervention. Furthermore, manually curated existing databases are integrated into automated pipelines to enrich and expand the knowledge base [30]. The creation of knowledge graphs, whether manual or automated, involves tools and frameworks that streamline the process. For manual construction, ontology editing platforms such as Protege and Neo4] provide structured environments for managing knowledge. Automated toolkits, such as GraphGen4 Code, enable the extraction and modeling of knowledge directly from large datasets, including codebases and documentation.