<?xml version="1.0" encoding="UTF-8"?>
<TEI xml:space="preserve" xmlns="http://www.tei-c.org/ns/1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.tei-c.org/ns/1.0 https://raw.githubusercontent.com/kermitt2/grobid/master/grobid-home/schemas/xsd/Grobid.xsd"
 xmlns:xlink="http://www.w3.org/1999/xlink">
	<teiHeader xml:lang="en">
		<fileDesc>
			<titleStmt>
				<title level="a" type="main">Towards SHACL-based Knowledge Graph Transformation of Visual Domain Knowledge</title>
			</titleStmt>
			<publicationStmt>
				<publisher/>
				<availability status="unknown"><licence/></availability>
			</publicationStmt>
			<sourceDesc>
				<biblStruct>
					<analytic>
						<author>
							<persName><forename type="first">Stefan</forename><surname>Bischof</surname></persName>
							<affiliation key="aff0">
								<orgName type="institution">Siemens AG Österreich</orgName>
								<address>
									<settlement>Vienna</settlement>
									<country key="AT">Austria</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Erwin</forename><surname>Filtz</surname></persName>
							<affiliation key="aff0">
								<orgName type="institution">Siemens AG Österreich</orgName>
								<address>
									<settlement>Vienna</settlement>
									<country key="AT">Austria</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Josiane</forename><forename type="middle">Xavier</forename><surname>Parreira</surname></persName>
							<affiliation key="aff0">
								<orgName type="institution">Siemens AG Österreich</orgName>
								<address>
									<settlement>Vienna</settlement>
									<country key="AT">Austria</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Simon</forename><surname>Steyskal</surname></persName>
							<affiliation key="aff0">
								<orgName type="institution">Siemens AG Österreich</orgName>
								<address>
									<settlement>Vienna</settlement>
									<country key="AT">Austria</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Michael</forename><surname>Baumgart</surname></persName>
							<affiliation key="aff1">
								<orgName type="department">Center for Vision, Automation &amp; Control</orgName>
								<orgName type="institution">AIT Austrian Institute of Technology GmbH</orgName>
								<address>
									<settlement>Vienna</settlement>
									<country key="AT">Austria</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">David</forename><surname>Gruber</surname></persName>
							<affiliation key="aff1">
								<orgName type="department">Center for Vision, Automation &amp; Control</orgName>
								<orgName type="institution">AIT Austrian Institute of Technology GmbH</orgName>
								<address>
									<settlement>Vienna</settlement>
									<country key="AT">Austria</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Maximilian</forename><surname>Liebetreu</surname></persName>
							<affiliation key="aff1">
								<orgName type="department">Center for Vision, Automation &amp; Control</orgName>
								<orgName type="institution">AIT Austrian Institute of Technology GmbH</orgName>
								<address>
									<settlement>Vienna</settlement>
									<country key="AT">Austria</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Florian</forename><surname>Rötzer</surname></persName>
							<affiliation key="aff1">
								<orgName type="department">Center for Vision, Automation &amp; Control</orgName>
								<orgName type="institution">AIT Austrian Institute of Technology GmbH</orgName>
								<address>
									<settlement>Vienna</settlement>
									<country key="AT">Austria</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Stephan</forename><surname>Strommer</surname></persName>
							<affiliation key="aff1">
								<orgName type="department">Center for Vision, Automation &amp; Control</orgName>
								<orgName type="institution">AIT Austrian Institute of Technology GmbH</orgName>
								<address>
									<settlement>Vienna</settlement>
									<country key="AT">Austria</country>
								</address>
							</affiliation>
						</author>
						<title level="a" type="main">Towards SHACL-based Knowledge Graph Transformation of Visual Domain Knowledge</title>
					</analytic>
					<monogr>
						<idno type="ISSN">1613-0073</idno>
					</monogr>
					<idno type="MD5">A415E75E30DFCDC35E7DC9804F1FC11E</idno>
				</biblStruct>
			</sourceDesc>
		</fileDesc>
		<encodingDesc>
			<appInfo>
				<application version="0.7.2" ident="GROBID" when="2025-04-23T18:46+0000">
					<desc>GROBID - A machine learning software for extracting information from scholarly documents</desc>
					<ref target="https://github.com/kermitt2/grobid"/>
				</application>
			</appInfo>
		</encodingDesc>
		<profileDesc>
			<textClass>
				<keywords>
					<term>Knowledge Graphs</term>
					<term>Infinity Maps</term>
					<term>RDF</term>
					<term>SHACL</term>
					<term>Semantic Web</term>
				</keywords>
			</textClass>
			<abstract>
<div xmlns="http://www.tei-c.org/ns/1.0"><p>Effective knowledge representation plays a pivotal role in harnessing the full potential of domain-specific information. Through tools like Infinity Maps, domain knowledge can be easily captured in a visual manner. However, translating these visually intuitive representations to formal, machine-processable formats often necessitates expert knowledge, thereby creating a significant barrier between domain experts and knowledge engineers. While domain experts possess deep understanding of their respective domains, they often lack the formalisation skills required to transform this knowledge into machinereadable formats. Conversely, knowledge engineers can design and implement sophisticated knowledge graphs, but may not have access to the domain-specific expertise necessary for effective knowledge representation. To address this challenge, we propose a novel approach that leverages SHACL (Shape Constraint Language) rules to transform visual domain knowledge expressed as Infinity Maps into knowledge graphs. Our method enables domain experts to define their knowledge structures using familiar Infinity Map representations, which are then transformed into standardised knowledge graphs compliant with the SHACL standard.</p></div>
			</abstract>
		</profileDesc>
	</teiHeader>
	<text xml:lang="en">
		<body>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1.">Introduction and Motivation</head><p>The setup and optimisation of industrial production processes, such as, for example, highpressure die casting, heavily rely on the expert knowledge and experience of a few individuals within a company. Consequently, domain knowledge often remains personal property rather than a shared company asset, creating a dependency on specific personnel. Despite companies' quality management standards, this valuable knowledge is frequently undocumented and undigitised, making it inaccessible to the broader workforce. This lack of effective knowledge management and transfer hinders resource-efficient, green production of advanced products,</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>SEMANTICS 2024</head><p>bischof.stefan@siemens.com (S. Bischof); erwin.filtz@siemens.com (E. Filtz); josiane.parreira@siemens.com (J. X. Parreira); simon.steyskal@siemens.com (S. Steyskal); michael.baumgart@ait.ac.at (M. Baumgart); david.gruber@ait.ac.at (D. Gruber); maximilian.liebetreu@ait.ac.at (M. Liebetreu); florian.roetzer@ait.ac.at (F. Rötzer); stephan.strommer@ait.ac.at (S. Strommer) 0000-0001-9521-8907 (S. Bischof); 0000-0003-3445-0504 (E. Filtz); 0000-0002-3050-159X (J. X. Parreira); 0000-0002-5183-2486 (S. Steyskal); 0009-0009-6776-4404 (M. Baumgart); 0000-0002-7544-5632 (D. Gruber); 0000-0001-8374-8476 (M. Liebetreu); 0000-0003-2661-5575 (F. Rötzer); 0009-0009-9349-9683 (S. Strommer) such as complex die-casting parts, especially in times of skilled labour shortages. It has therefore become a pressing issue for industries to find a low-threshold, minimal-effort way for experts to digitise and share their knowledge, making it machine-readable, accessible and usable also for non-domain experts. A toolchain that achieves this goal should include a highly accessible tool for experts to document their domain knowledge. Examples of such tools are Conceptboard<ref type="foot" target="#foot_0">1</ref> , Microsoft Whiteboard<ref type="foot" target="#foot_1">2</ref> , and Infinity Maps <ref type="bibr" target="#b2">3</ref> .</p><p>In the present paper, we will use Infinity Maps due to their rich JSON exporting capabilities. Additionally, a technology and/or database that is able to store knowledge in a structured form is of utter importance. In our case, the output of the toolchain is a knowledge graph (KG) in RDF format. The envisaged toolchain is outlined in Fig. <ref type="figure" target="#fig_0">1</ref>.</p><p>Contribution. We design a transformation pipeline from Infinity Maps to a structured RDF graph, based on the SHACL standard<ref type="foot" target="#foot_3">4</ref> . Features include: (i) The authors of an Infinity Map are free to dump a mixture of structured and unstructured knowledge and data into each Map. (ii) Authors do not require any technical understanding of the KG that will be produced. (iii) By employing SHACL, authors of an Infinity Map receive automated assistance in structuring the domain knowledge for computational processing. (iv) Using SHACL, the generated KG is guaranteed to conform to the requirements of any ontologies applied to the graph.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.">From Domain Knowledge to Knowledge Graph</head><p>Step 1: Visual modelling by schema. The first step in our pipeline is to organise and gain an overview of all available expert and domain knowledge, which comes in various formats like PNG, PDF, CSV files, emails, and interviews. Infinity Maps excels in visualising and organising this unstructured information. It allows the creation and connection of cards into tree-like hierarchies, a feature we use extensively to efficiently manage and structure our knowledge base. Once an overview on all available knowledge sources has been attained, Infinity Maps can also be used to combine and organise what information was learned from these sources. To this end, we designed a loose schema based on the gathered information and visually modelled this domain knowledge accordingly.</p><p>Remark. The availability of visual tools for structured KG creation is limited. This is unsurprising: KGs are a comparatively novel concept, and while they have had a lot of success in recent years, most success stories originate from fields and applications that create such KGs automatically from other forms of structured databases, with the main challenge being leveraging the information contained within (triple prediction for recommender systems, etc.) [1, 2, 3]. However, in industrial production domains, the degree of digitisation is often surprisingly low, with knowledge being available in hand-written form, separate documents, literature, and the minds of experts and operators drawing from said literature and their own experience. Structuring this knowledge in any form, but particularly in an explainable way and one that can be easily and efficiently queried, is a vital step towards leveraging all available knowledge to optimise processes and products.</p><p>Step 2: Visual modelling by ontology. In the later stages of visual modelling, we developed an ontology for the envisaged KG, thereby clarifying the modelling guidelines. We utilised tags and tree-like hierarchies within Infinity Maps to denote relationships between entities and label cards accordingly. These tags and hierarchical logic subsequently guides the transformation process from Infinity Maps to the KG.</p><p>A significant drawback of Infinity Maps is the absence of dynamic links between cards. Although each card has a unique URL and can be referenced via hyperlinks, these links are static text and can easily break during the Map authoring process. To maintain simplicity for human readability, we opted to cross-reference tagged cards by ensuring that each combination of card label and tag remains unique throughout the entire Infinity Maps project.</p><p>Due to this limitation in dynamic linking, we anticipate the appearance of duplicate entities and errors in triplets when converting from Infinity Maps to a KG. This necessitates additional constraints and rules for a successful transformation.</p><p>Step 3: Transformation by constraints. Infinity Maps allows exporting each Map to JSON format. We transform these JSON structures to a KG using Python code and shapes implemented in SHACL. This procedure is described in much more detail in Section 3.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Closing the loop.</head><p>From the KG, new domain knowledge can be gained by experts. Any new knowledge can be added to the Infinity Maps and the KG itself, thereby closing the loop. An overview of the entire pipeline is given in Fig. <ref type="figure" target="#fig_0">1</ref>.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.">SHACL-based Transformation Framework</head><p>The Shapes Constraint Language (SHACL), is a W3C recommendation designed for validating RDF graphs against a set of SHACL shapes, i.e. the constraints the to-be-validated RDF graph has to adhere to. Such constraints can include (but are not limited to), e.g., checking existence of particular properties, data types, value ranges, and relationships between nodes 5 . Using SHACL, one can ensure that the data conforms to the expected structure and semantics, enabling reliable data integration and interoperability.</p><p>Additionally, we utilise SHACL Rules 6 to facilitate the transformation of raw data (i.e., the Infinity Maps JSON exports) into a structured, and semantically enriched representation that aligns with predefined ontologies and the domain understanding as provided by the domain experts.</p><p>5 SHACL Core Components: https://www.w3.org/TR/shacl/#core-components 6 SHACL Rules were introduced as part of the SHACL Advanced Features Note: https://www.w3.org/TR/shacl-af.  ex:FH9d47H93gf a dg:KPI, im:Node ; rdfs:label "Schließkraft Err" ; im:child ex:LnrDTfHTHqF ; im:id "FH9d47H93gf" ; im:parent ex:99dqJd2rjLb ; im:tag ex:Jj3qLGjGhGp ; im:title "Schließkraft Fehler" .</p><p>ex:LnrDTfHTHqF a im:Node ; rdfs:label "Abhängigkeiten" ; im:child ex:P2jBpjh8RjM, ex:Qbd7rnb ; im:id "LnrDTfHTHqF" ; im:parent ex:FH9d47H93gf ; im:title "Abhängigkeiten" .</p><p>ex:P2jBpjh8RjM a dg:Quantity, im:Node ; rdfs:label "Schließkraft Err (Gießen)" ; im:id "P2jBpjh8RjM" ; im:parent ex:LnrDTfHTHqF ; im:tag ex:BLJD8RqhTrd ; im:title "Schließkraft Err (Gießen)" .</p><p>Listing 1: KPI that has a Quantity as dependency.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.1">Handling Infinity Maps Data</head><p>As shown in Fig. <ref type="figure" target="#fig_2">2</ref>, an Infinity Maps JSON export follows a very basic structure. At its core, each Infinity Map is represented as a JSON object with three main elements: nodes, edges, and tags. Where nodes represent all nodes in the Map, edges all edges between nodes, and tags are all tags used in the Map. As depicted in Listing 1, each node has a unique identifier, a title, and optionally a reference to its parent node, and a list of references to any of its child nodes. Each edge has a source and target node, and a name. Each tag has a unique identifier and a title 7 . </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.2">Enrichment with</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Conclusion and Future Work</head><p>In this paper, we presented a novel approach that enables domain experts to model their knowledge using an easy and intuitive visual representation, which is then exported as JSON, and afterwards transformed into a semantically enriched KG representation using SHACL. Future work will focus on integration of additional SHACL rules as well as evaluation of the transformation process on different real-world use cases.</p></div><figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_0"><head>Figure 1 :</head><label>1</label><figDesc>Figure 1: Transformation of domain knowledge to knowledge graph using visual modelling with Infinity Maps and SHACL.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_2"><head>Figure 2 :</head><label>2</label><figDesc>Figure 2: Excerpt of an Infinity Maps JSON export.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_0"><head>Domain-Specific SHACL Rules Based</head><label></label><figDesc>on modeling guidelines specified by the process/domain experts, we define SHACL rules that capture the unique semantics and requirements of the domain. For example, one of the guidelines states that relations are represented by chaining at least two parent-child relationships between a starting entity and one or more target entities, where a relation contains exactly one node in its path that defines the type of the relation. The SHACL rule in Listing 2 captures this by searching for paths starting from a set of focus nodes of type dg:Quantity, traversing through one or more im:child relationships to intermediate nodes ? p, and finally reaching target entities ? mid. Using the VALUES clause, we define the properties to be used based on the labels of the intermediate nodes. For example, for the example triples in Listing 1, the following triple would be generated: ex:FH9d47H93gf dg:has_dependency ex:P2jBpjh8RjM . :prefixes &lt;http://siemens.com/dgassist/enrichment&gt; . SHACL Rule for creating relations based on guidelines provided by domain experts.</figDesc><table><row><cell>enr:QuantityRule a sh:SPARQLRule ;</cell></row><row><cell>sh:construct """</cell></row><row><cell>CONSTRUCT {</cell></row><row><cell>$this ?rel ?mid .</cell></row><row><cell>} WHERE {</cell></row><row><cell>$this im:child ?typ .</cell></row><row><cell>?typ rdfs:label ?l ; im:child* ?p .</cell></row><row><cell>?p im:child ?mid .</cell></row><row><cell>?mid im:tag ?tag ; a ?target .</cell></row><row><cell>VALUES (?l ?rel ?target) {</cell></row><row><cell>( "Abhängigkeiten" dg:has_dependency dg:Quantity)</cell></row><row><cell>( "Messung" dg:has_measurement dg:Signal)</cell></row><row><cell>}</cell></row><row><cell>}""" ;</cell></row><row><cell>sh:condition [ # evaluate rule only if focus node is a dg:Quantity</cell></row><row><cell>sh:property [</cell></row><row><cell>sh:path rdf:type ;</cell></row><row><cell>sh:hasValue dg:Quantity ;</cell></row><row><cell>] ;</cell></row><row><cell>] ; shListing 2:</cell></row></table></figure>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="1" xml:id="foot_0">Conceptboard: https://conceptboard.com/</note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="2" xml:id="foot_1">Microsoft Whiteboard: https://www.microsoft.com/en-us/microsoft-365/microsoft-whiteboard</note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="3" xml:id="foot_2">Infinity Maps: https://infinitymaps.io/</note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="4" xml:id="foot_3">SHACL: https://www.w3.org/TR/shacl</note>
		</body>
		<back>

			<div type="acknowledgement">
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Acknowledgments</head><p>This work was conducted within the Austrian research project DG Assist (FFG project number: FO999899053). This project is funded by the Federal Ministry for Climate Protection, Environment, Energy, Mobility, Innovation and Technology, BMK, and is carried out as part of the Production of the Future programme.</p></div>
			</div>

			<div type="references">

				<listBibl>

<biblStruct xml:id="b0">
	<analytic>
		<title level="a" type="main">Knowledge graphs</title>
		<author>
			<persName><forename type="first">A</forename><surname>Hogan</surname></persName>
		</author>
		<idno type="DOI">10.1145/3447772</idno>
		<ptr target="https://doi.org/10.1145/3447772.doi:10.1145/3447772" />
	</analytic>
	<monogr>
		<title level="j">ACM Comput. Surv</title>
		<imprint>
			<biblScope unit="volume">54</biblScope>
			<date type="published" when="2021">2021</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b1">
	<analytic>
		<title level="a" type="main">A survey on knowledge graph-based recommender systems</title>
		<author>
			<persName><forename type="first">J</forename><surname>Liu</surname></persName>
		</author>
		<author>
			<persName><forename type="first">L</forename><surname>Duan</surname></persName>
		</author>
		<idno type="DOI">10.1109/IAEAC50856.2021.9390863</idno>
	</analytic>
	<monogr>
		<title level="m">IEEE 5th Advanced Information Technology, Electronic and Automation Control Conference (IAEAC)</title>
				<imprint>
			<date type="published" when="2021">2021. 2021</date>
			<biblScope unit="page" from="2450" to="2453" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b2">
	<analytic>
		<title level="a" type="main">Industry-scale knowledge graphs: lessons and challenges</title>
		<author>
			<persName><forename type="first">N</forename><surname>Noy</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Y</forename><surname>Gao</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Jain</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Narayanan</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Patterson</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Taylor</surname></persName>
		</author>
		<idno type="DOI">10.1145/3331166</idno>
		<ptr target="https://doi.org/10.1145/3331166.doi:10.1145/3331166" />
	</analytic>
	<monogr>
		<title level="j">Commun. ACM</title>
		<imprint>
			<biblScope unit="volume">62</biblScope>
			<biblScope unit="page" from="36" to="43" />
			<date type="published" when="2019">2019</date>
		</imprint>
	</monogr>
</biblStruct>

				</listBibl>
			</div>
		</back>
	</text>
</TEI>
