Shapes for Sharing between Graph Data Spaces - and Epistemic Querying of RDF-Star

Data spaces in distributed environments should be allowed to evolve in agile ways providing data space owners with large flexibility about which data they store. Agility and heterogeneity, however, jeopardize data exchanges because representations may build on varying ontologies and data consumers may not rely on the semantic correctness of their queries in the context of semantically heterogeneous, evolving data spaces. Graph data spaces are one example of a powerful model for representing and querying data whose semantics may change over time. To assert and enforce conditions on individual graph data spaces, shape languages (e.g SHACL) have been developed. We investigate the question of how querying and programming can be guarded by reasoning over SHACL constraints in a distributed setting and we sketch a picture of how a future landscape based on semantically heterogeneous data spaces might look like.

1. KI – Institute for Artificial Intelligence Shapes for Sharing between Graph Data Spaces  Steffen Staab @ ststaab https:// www.ki.uni-stuttgart.de https:// semanux.com https:// southampton.ac.uk / research / institutes-centres /web-internet- science

2. Physical Spaces Product Product design Development environment virtual car for programming Human electronic health records Infrastructure (rail)roads, power grid, … Purposes Document Communicate Simulate Diagnose/ maintain Predict Plan KG-A KG-B KG-C Digital Spaces 2.5.2024 2

3. Knowledge Graphs as distributed, connected data spaces use cases from AEC and factory operation SHACL Constraints as Programming Contracts Contracts from Composed Data Spaces Epistemic Querying 3 Plan for my talk 2.5.2024

4. 1 Knowledge Graphs as distributed , connected data spaces

5. many stakeholders many tools work in parallel, no waterfall mutual dependencies code as agent https://vimeo.com/372594657 DFG Cluster of Excellence Integrated Computational Design and Construction 2.5.2024 5

6. many stakeholders many tools work in parallel, no waterfall mutual dependencies code as agent https://vimeo.com/372594657 DFG Cluster of Excellence Integrated Computational Design and Construction 2.5.2024 6

7. https:// pixabay.com /de/users/peggy_marco-1553824/ KG-S Simul structural engineering KG-A Design architectural design KG-C Constr construction customer requirements acoustic engineering electrical engineering ventilation fire containment plumbing …. many stakeholders many tools work in parallel, no waterfall mutual dependencies 2.5.2024 7 [CAAD Futures 2023] Collaboration with architects Happold, London

8. 8 Data Spaces for Architecture, Engineering, Construction [CAAD Futures 2023] Collaboration with architects Happold, London https://www.intcdc.uni-stuttgart.de/ 2.5.2024

9. Codependencies in the Design Process & between Data Spaces Architect plans building with walls (W23), columns (C42), rooftop, etc. Structure engineer checks the loads, suggests structures, e.g. beams Acoustic engineer feeds back issues Architect may change the shape of column C42 move column C42 9 KG-S Simul structural engineering KG-A Design architectural design Is C42 still the same column for the architect? for the acoustic engineer? for the structure engineer?

10. Data Needs in Collaborative Research Center: Circular Factory https://www.sfb1574.kit.edu/ Product Production Co-Design Knowledge Graph contains knowledge about design, production and product including plans , sensor measurements and intra- logistics 2.5.2024 10

11. manuelle Re-/ De-/Montagezelle Targeted Circular Factory Shopfloor Linear Z Z Bei Re- De- Montagezelle Slashes eingefügt

12. 2.5.2024 12 Hierarchical Views of Ontologies in the Circular Factory (1) Kern- ontologie Produkt Ressource Prozess Winkel- schleifer Stellmotor Mobiler Assistent Transformer- zelle Entwicklung

13. Hierarchical Views of Ontologies in the Circular Factory (2) om:Scale Winkelschleifer Units of Measurement Ontology Produkt om:Unit om:RatioScale om:PrefixedUnit „ NaN “^^ xsd:double Geometric Objects Ontology {„type“ : “Polygon“} ^^ gobj:geometricJSONLiteral {„type“ : “ Pointcloud “} ^^ gobj:geometricJSONLiteral ws:Winkelschleifer core:Produkt inst:Winkelschl42 rdf:type {...:{...}} rdf:type om:cm rdfs:subclassOf Uncertain Measurements Ontology {„type“ : “ Gauss “} ^^ unc:uncertainPointValue core:Gestalt core:hatGestalt inst:Gestalt42

14. KG 1 KG 2 KG 3 App A App B App C 2.5.2024 14 Data spaces in the Infrastructure in Architecture, Engineering, and Construction (AEC) in Circular Factory

15. KG 1 KG 2 KG 3 App A App B App C 2.5.2024 15 Common Characteristics KG nodes must be agile Data & data structures are evolving Data owners unaware what others need Co-dependencies between KGs Most data not of interest to others Data consumers must be able to rely on information by others (linked data navigation not an option) Core Idea Formulate “contracts” for querying using SHACL

16. 2 SHACL Constraints as Programming Contracts

17. KG 1 KG 2 KG 3 App A App B App C Can my app B work on my KG2? 2.5.2024 17

18. Example: How old are the students? Query for all students , access age Query fails during evaluation let students = query { SELECT ?x WHERE {?x a Student . } } for student in students do printfn „%A“ ( student. age )                                       [ESOP17,ISWC19] 18

19. Example: How old are the students? let students = query { SELECT ?x WHERE {?x a Student. } } for student in students do printfn „%A“ ( student.age ) Should we use this relation on this signifier ? Depends on: Conceptualization of data source Querying of data source Software code                                       19

20. Closed-world conceptualization of classes and relations SHACL – SHApes Constraint Language SHACL shapes are integrity constraints Namespaces omitted for brevity : StudentShape a : NodeShape ; : targetClass :Student; : class :Person; : property [ : path : studiesAt ; : minCount 1; : class :University; ]. : PersonShape a : NodeShape ; : targetClass :Person; : property [ : path : name ; : minCount 1; : datatype xsd:string ; ]. 20

21. Closed-world conceptualization of code (1) Type checking discovers (potential) run-time errors let students = query { SELECT ?x WHERE {?x a Student. } } for student in students do printfn „%A“ ( student.age ) Set of all students ( StudentShape ) One value of StudentShape set Not allowed since when considering all conceptually possible RDF graphs   21

22. Closed-world conceptualization of code (2) Access: matrNr No error during evaluation Unsafe : Rejected by type checking, conceptualization not guaranteed let students = query { SELECT ?x WHERE {?x a Student. } } for student in students do printfn „%A“ ( student. matrNr )                                       22

23. Closed-world conceptualization of code (3) Query for: matrNr T ype safe access: matrNr inferred to be given for all values of student let students = query { SELECT ?x WHERE {?x matrNr ?y. } } for student in students do printfn „%A“ ( student . matrNr )                                       [ESOP17,ISWC19] 23

24. Use available SHACL constraints Infer additional SHACL constraints from queries Type check using inference Determine type safety let students = query { SELECT ?x WHERE {?x a Student. } } for student in students do printfn „%A“ (student.name) Query shape (2) including StudentShape (1) One value of StudentShape set and in all possible graphs   Inference (3) [ESOP17,ISWC19] 24

25. 3 Contracts from Composed Data Spaces

26. KG 1 KG 2 KG 3 App A App B App C Scenario: Can my app B work on the KG2 view of KG1? 2.5.2024 26

27. 2.5.2024 27 Mapping between data spaces 27 KG 1 KG 2 App B view 2.5.2024

28. 2.5.2024 28 Contract formulated by Shapes   KG 1 KG 2 App B

29. 2.5.2024 29 From Shapes to Shapes [Web2024]

30. 2.5.2024 30 From Shapes to Shapes: A New Contract for Any Input [Web2024]

31. 2.5.2024 31 Example Query [Web2024]

32. 2.5.2024 32 Example   [Web2024]

33. 2.5.2024 33 Implications for Bindings arising from and   [Web2024]

34. 2.5.2024 34 Implied   [Web2024]

35. 2.5.2024 35 Namespaces for Concepts and Variables [Web2024]

36. Tracing Query Concepts (and Relations) S in = { :Person 1 ⊑ :Agent } q = CONSTRUCT { ?x a :Person 3 . ?y a :Agent } WHERE { ?x a :Person 2 . ?y a :Agent } S out = { :Person 3 ⊑ :Agent } Are concepts : Person 1 : Person 2 : Person 3 the same? 36 Yes! 2.5.2024 [Web2024]

37. Tracing Query Concepts (and Relations) S in = { :Person 1 ⊑ :Agent } q = CONSTRUCT { ?x a :Person 3 . ?y a :Agent } WHERE { ?x a :Person 2 . ?x a :Teacher . ?y a :Agent } S out = { :Person 3 ⊑ :Agent } Are concepts : Person 1 : Person 2 : Person 3 still the same? 37 NO! Hard problem even for restricted query and constraint languages 2.5.2024 [Web2024]

38. 2.5.2024 38 Encode Constraints in Description Logics

39. 2.5.2024 39 Enumerate candidate elements of and check  

40. 2.5.2024 40 A Provably Sound but Incomplete Algorithm [Web2024]

41. 4 Epistemic Querying

42. KG 1 KG 2 App A App B App C Scenario: What is B‘s overall view of KGs 1,2,3? 2.5.2024 42 KG 3

43. 2.5.2024 43 Who is Alice? Alice is a PhD Student, advised by Professor Bob KG 1 University 1 KG 2 University 2 Alice is a Postdoc, working with Professor Carol Alice a Person . <Bob> believesToBeTrue << Alice a PhDStudent >> . <Carol> believesToBeTrue << Alice a Postdoc >> . eSPARQL to the rescue! [Pan 2024]

44. 2.5.2024 44 Who is Alice? Alice is a PhD Student, advised by Professor Bob KG 1 University 1 KG 2 University 2 Alice is a Postdoc, working with Professor Carol Alice a Person . <Bob> believesToBeTrue << Alice a PhDStudent >> . <Carol> believesToBeTrue << Alice a Postdoc >> . SELECT ?student FROM BELIEFS <Bob> WHERE {   ?student a < PhDStudent > } SELECT ?student FROM BELIEFS <Carol> WHERE {   ?student a < PhDStudent > } SELECT ?student WHERE {   ?student a < PhDStudent > } <Alice> : Unknown <Alice> : True <Alice> : Unknown [Pan 2024]

45. 2.5.2024 45 Conflicted Beliefs <Alice> a Person . <Denis> believesToBeFalse << Alice a GoodStudent >> . <Bob> believesToBeTrue << Alice a GoodStudent >> . <Carol> believesToBeUnknown << Alice a GoodStudent >> . SELECT ?student FROM BELIEFS ?x WHERE {   ?student a < GoodStudent > } SELECT ?student FROM BELIEFS <Bob> WHERE {   ?student a < GoodStudent > } <Alice> : Conflicted <Alice> : True SELECT ?student FROM BELIEFS <Denis> WHERE {   ?student a < GoodStudent > } <Alice> : False [Pan 2024]

46. 2.5.2024 46 Who is conflicted with Bob? <Alice> a Person . <Denis> believesToBeFalse << Alice a GoodStudent >> . <Bob> believesToBeTrue << Alice a GoodStudent >> . <Carol> believesToBeUnknown << Alice a GoodStudent >> . SELECT ?x FROM BELIEFS ( <Bob> ?x ) WHERE {   ?student a < GoodStudent >   FILTER ( stateIs (CONFLICTED)) } <Denis> : True <Carol> : False [Pan 2024]

47. 2.5.2024 47 Formalization via Bilattice   Key messages Distinguish between unknown and false Map AND and OR to one of the two lattices Make sure that all truth value assignments can be finitely encoded [Pan 2024]

48. 5 Conclusion

49. Constraints for shared understanding SHACL as ”data contracts” between knowledge graph and software code between different knowledge graphs (stakeholders) Epistemic querying on RDF-star with well-defined semantics for SPARQL-star 49 Summary 2.5.2024