Retrieve (and leverage) the inner graph behind the data
 invted keynote

Ioana Manolescu

<figure><img src="image_1.png" /></figure>

To cite this version:

Ioana Manolescu. Retrieve (and leverage) the inner graph behind the data (invited keynote). ISWC 2024 - International Semantic Web Conference, Nov 2024, Hanover, Maryland, United States. hal-05363480

HAL Id: hal-05363480

https://inria.hal.science/hal-05363480v1

Submitted on 13 Nov 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>
Retrieve (and Leverage) the Inner Graph Behind the Data

loana Manolescu

CEDAR team, Inria and Institut Polytechnique de Paris, France
ioana.manolescu@inria.fr, @ioanamanol

ISWC 2024
1. Motivation: Data management for investigative journalism

2. CONNECTIONLENS: Graph-based integration of heterogeneous data

* So that journalists do not have to know about data models

3. ABSTRA: Finding the Entity-Relationship conceptual model in a dataset of any model

* This automatizes the discovery of connections between Named Entities in the dataset

* ... and leads to transforming the data into Property Graphs!

4. Ongoing work and perspectives
# Part I

## Motivation: Investigative Journalism
# Why journalism?

* I was born in communist Romania, then a dictatorship.

Estimated victims 1945-1989: 500.000 to 2M
# Why journalism?

* I was born in communist Romania, then a dictatorship.
  Estimated victims 1945-1989: 500.000 to 2M

* Fall of communism in Romania: 1000+ dead, 3000+ wounded.
  No one has been tried / convicted for that.

<figure><img src="image_3.png" /></figure>
# Why journalism?

* I was born in communist Romania, then a dictatorship. Estimated victims 1945-1989: 500.000 to 2M

* Fall of communism in Romania: 1000+ dead, 3000+ wounded.
No one has been tried / convicted for that.

<figure><img src="image_4.png" /></figure>

**Functional free press** is an important ingredient for **democracy**

* To debate and express dissent

* To analyze and expose society's functioning

Research projects since 2015 with Le Monde, **radiofrance** [7, 8]

<figure><img src="image_5.png" /></figure>
Journalists vs. the data

* As the world goes digital, journalists stand to gain enormously from **leveraging digital data**
Journalists vs. the data

* As the world goes digital, journalists stand to gain enormously from leveraging digital data

* They need to work with the **data they can get their hands on** (Open, or shared by sources, or...)

* Traditionally, PDFs/HTML that they would read

* Increasingly, there are also (semi-)structured datasets

* Heterogeneous data!

<figure><img src="image_6.png" /></figure>
Journalists vs. the data

* As the world goes digital, journalists stand to gain enormously from leveraging digital data

* They need to work with the **data they can get their hands on** (Open, or shared by sources, or...)

* Traditionally, PDFs/HTML that they would read

* Increasingly, there are also (semi-)structured datasets

* Heterogeneous data!

<figure><img src="image_7.png" /></figure>

Paradise Papers:

* Relational database (register of off-shore companies)

* PDFs (contracts stating who represents whom, addresses, lawyers...)

* Emails
# Data model heterogeneity

## Models and strengths:

* Tables CSV, relational (most mature; most regular ⇒ optimization)

* Trees JSON, XML, K-V: Web content, structured documents, data exchange

* Graphs RDF: Open Data; PGs: possibly better suited in business contexts
# Data model heterogeneity

## Models and strengths:

- Tables CSV, relational (most mature; most regular ⇒ optimization)

- Trees JSON, XML, K-V: Web content, structured documents, data exchange

- Graphs RDF: Open Data; PGs: possibly better suited in business contexts

## Support:

<table><thead><tr><th></th><th>Tables</th><th>XML</th><th>JSON</th><th>KV</th><th>RDF</th><th>PGs</th></tr></thead><tbody><tr><td>Relational databases</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td></tr><tr><td>XML databases</td><td></td><td>✓</td><td></td><td></td><td></td><td></td></tr><tr><td>JSON databases</td><td></td><td></td><td>✓</td><td>✓</td><td></td><td></td></tr><tr><td>KV stores</td><td></td><td></td><td></td><td>✓</td><td></td><td></td></tr><tr><td>RDF databases</td><td></td><td></td><td></td><td></td><td>✓</td><td>✓</td></tr><tr><td>PG databases</td><td></td><td></td><td></td><td></td><td>✓</td><td>✓</td></tr></tbody></table>
Data model fashions

<figure><img src="image_8.png" /></figure>

Credit: http://databasearchitects.blogspot.com/2023/02/five-decades-of-database-research.html
# Data heterogeneity: how to live with it?

**Data integration:** leverage data from several stores (sources)

* Sources may have different data models, schemas, ontologies, query processing capabilities

* Sources may be distributed

**Data integration approaches**

* **Mediator**: global schema, logically connected to the local schemas (possibly w/ ontologies); many sites, single schema

* **Warehousing**: all data in a single site, single schema (typically, relational)

* **Data lake**: all data in a single site, no single schema
# Data heterogeneity: how to live with it?

**Data integration:** leverage data from several stores (sources)

* Sources may have different data models, schemas, ontologies, query processing capabilities

* Sources may be distributed

**Data integration approaches**

* **Mediator**: global schema, logically connected to the local schemas (possibly w/ ontologies); many sites, single schema

* **Warehousing**: all data in a single site, single schema (typically, relational)

* **Data lake**: all data in a single site, no single schema
# Data heterogeneity: how to live with it?

**Data integration:** leverage data from several stores (sources)

* Sources may have different data models, schemas, ontologies, query processing capabilities

* Sources may be distributed

**Data integration approaches**

* **Mediator**: global schema, logically connected to the local schemas (possibly w/ ontologies); many sites, single schema

* **Warehousing**: all data in a single site, single schema (typically, relational)

* **Data lake**: all data in a single site, no single schema

This talk

① Lake-style integration under graph data model

② Finding interesting connections in integrated graphs

③ Making sense of heterogeneous data graphs
Making sense of heterogeneous data for journalism

* Application domain changes frequently/cold start: news cycle, or investigation topic.

* Journalists use whatever data they can get their hands on. Different data models (+ text, Office, etc.)

<figure><img src="image_9.png" /></figure>

<figure><img src="image_10.png" /></figure>

<figure><img src="image_11.png" /></figure>

Employee
id: 1
name: Alice
salary: 3000

since: 1/1/23
friend

Employee, Temp
id: 1
name: Bob
salary: 2500
email: b@cc.com

* Journalists are familiar with text and documents > spreadsheet ≫ anything else

* Data producers often **uncollaborative** ⇒ documentation, schema missing
Making sense of heterogeneous data for journalism

* Application domain changes frequently/cold start: news cycle, or investigation topic.

* Journalists use whatever data they can get their hands on. Different data models (+ text, Office, etc.)

<figure><img src="image_12.png" /></figure>

<figure><img src="image_13.png" /></figure>

<figure><img src="image_14.png" /></figure>

Employee
id: 1
name: Alice
salary: 3000

since: 1/1/23
friend

Employee, Temp
id: 1
name: Bob
salary: 2500
email: b@cc.com

* Journalists are familiar with text and documents > spreadsheet ≫ anything else

* Data producers often **uncollaborative** ⇒ documentation, schema missing

* Data understanding conditions even the earliest stages of journalistic work!
Part II

CONNECTIONLENS: Graph-Based Heterogeneous Data
Integration

Joint work with O. Balalau, A. Anadiotis, M. Mohanty (Inria), H. Galhardas (INESC), and
many others
ConnectionLens: integrating data into graphs [4]

1. Focus on (semi)structured data formats: RDBs, CSV, JSON, XML, RDF, PGs, ...

2. Enrich the graph with Named Entities extracted from each text (value) node.

<figure><img src="image_15.png" /></figure>

Papers and code: https://team.inria.fr/cedar/connectionlens/
# Relational data conversion to a graph

Relational model (also CSV): tables

<table><caption>Employees</caption><thead><tr><td>ID</td><td>name</td><td>company</td></tr></thead><tbody><tr><td>1</td><td>Alice</td><td>3</td></tr><tr><td>2</td><td>Bob</td><td>3</td></tr></tbody></table>

<table><caption>Companies</caption><thead><tr><td>ID</td><td>name</td><td>city</td></tr></thead><tbody><tr><td>3</td><td>IBM</td><td>Paris</td></tr></tbody></table>

<figure><img src="image_16.png" /></figure>
# XML documents: mostly trees

XML elements may have **attributes**

`<Employees>`

`<employee id="e1" friend="e2">`

`<name>Alice</name>`

`<salary>3000€</salary>`

`</employee>`

`<employee id="e2">`

`<name>Bob</name>`

`<salary>2500€</salary>`

`<email>b@c.com</email>`

`</employee>`

`</Employees>`

<figure><img src="image_17.png" /></figure>
# XML documents: mostly trees

A schema (Document Type Description or XML Schema) may state that `id` is a PK, and `friend` is a FK

`<Employees>`

`<employee id="e1" friend="e2">`

`<name>Alice</name>`

`<salary>3000€</salary>`

`</employee>`

`<employee id="e2">`

`<name>Bob</name>`

`<salary>2500€</salary>`

`<email>b@c.com</email>`

`</employee>`

`</Employees>`

<figure><img src="image_18.png" /></figure>
# JSON documents: trees

Structured in: maps (objects) [] and arrays (lists) {}

```json
[
  {
    "id": "1",
    "name": "Alice",
    "salary": "3000",
    "promoted": ["01/2020", "06/2022"]},
  {
    "id": "2",
    "name": "Bob",
    "salary": "2500"},
]
```

## JavaScript Object Notation

<figure><img src="image_19.png" /></figure>
# RDF: Describing resources with properties, types, and ontologies

W3C standard for data interchange. Sample graph and (minimalistic) ontology:

<figure><img src="image_20.png" /></figure>

* http://emp.org/Temp rdfs:subclassOf http://emp.org/Employee

* http://emp.org/salary rdf:domain http://emp.org/Employee
# Property graphs

Unlike RDF nodes, PG nodes **contain their attributes**.

Nodes can have zero or more **labels**. Relationships can also have attributes.

Industry first (Neo4J), then research, then standards [1, 18]

<table><tr><td><strong>Employee</strong></td></tr><tr><td>id: 1</td></tr><tr><td>name: Alice</td></tr><tr><td>salary: 3000</td></tr></table>

since: 1/1/23

friend

Employee, Temp

id: 1

name: Bob

salary: 2500

email: b@c.com
Property graphs transformed in ConnectionLens

<figure><img src="image_21.png" /></figure>
# Entity extraction

Extract **Named Entities (NEs)** from any text field originating from any data model

* **Pattern-based** for: emails, URIs, hashtags, ...

* Using **language models** for People, Locations, Organizations

* Used Flask EN model, trained a Flask FR model [4]

* Prompted ChatGPT4 [13], Gemma2 [19]
# Entity extraction

Extract **Named Entities (NEs)** from any text field originating from any data model

* **Pattern-based** for: emails, URIs, hashtags, ...

* Using **language models** for People, Locations, Organizations

* Used Flask EN model, trained a Flask FR model [4]

* Prompted ChatGPT4 [13], Gemma2 [19]

Disambiguate NEs in their context against a KG
# Entity extraction

Extract **Named Entities (NEs)** from any text field originating from any data model

* **Pattern-based** for: emails, URIs, hashtags, ...

* Using **language models** for People, Locations, Organizations

* Used Flask EN model, trained a Flask FR model [4]

* Prompted ChatGPT4 [13], Gemma2 [19]

Disambiguate NEs in their context against a KG

For each distinct entity, we add to the graph one **entity node**, with an incoming **extraction edge** from each node in which it has been found

<figure><img src="image_22.png" /></figure>

Entities may lead to **connections across datasets!** (and more connections within)
# Sample graph: conflicts of interest in the biomedical domain [2]

Application proposed by S. Horel, Le Monde

<figure><img src="image_23.png" /></figure>
Sample graph: conflicts of interest in the biomedical domain [2]

<figure><img src="image_24.png" /></figure>

<figure><img src="image_25.png" /></figure>
# Sample graph: conflicts of interest in the biomedical domain [2]

* PubMed publication notices (XML)

* PDF articles → JSON

* HTML: a Web crawl of media articles on health topics

<table><caption>**Table 3: Statistics on Conflict of Interest application graph.**</caption><thead><tr><th>|N|</th><th>|E|</th><th>|N|</th><th>|N<sub>P</sub>|</th><th>|N<sub>O</sub>|</th><th>|N<sub>L</sub>|</th></tr></thead><tbody><tr><td>XML</td><td>32,028,429</td><td>19,851,904</td><td>1,483,631</td><td>584,734</td><td>126,629</td></tr><tr><td>JSON</td><td>1,025,307</td><td>432,303</td><td>75,297</td><td>7,320</td><td>4,139</td></tr><tr><td>HTML</td><td>246,636</td><td>185,479</td><td>3,726</td><td>7,227</td><td>320</td></tr><tr><td>Total</td><td>33,300,372</td><td>20,469,686</td><td>1,562,654</td><td>665,167</td><td>131,088</td></tr></tbody></table>
# Building ConnectionLens graphs [4]

NE extraction time and disambiguation dominate.

<figure><img src="image_26.png" /><figcaption>Figure 6: Graph construction time (seconds).</figcaption></figure>
# Building ConnectionLens graphs [4]

To reduce NE extraction time: caching, parallelization (batching), GPU

Also: learning when not to extract [16]

<figure><img src="image_27.png" /><figcaption>Figure 7: YAGO loading time (minutes) using Flair.</figcaption></figure>
# Keyword search in ConnectionLens graphs

**Keyword search:** given *k* keywords, find minimal connecting trees, each tree containing one node matching each keyword
NP-hard problem (Group Steiner Trees)
Results usually ranked based on a tree score

Efficient keyword search algorithms [3, 5], suited to any connection score

* Multi-thread parallelism [3]

* Algorithmic optimizations [5]

* Complete for $k \le 3$

* Guaranteed to find a large family of solutions for arbitrary $k$ [5]

<figure><img src="image_28.png" /></figure>
# Integrating keyword search into a graph query language [5]

* SPARQL allows verifying the presence of paths (regex) between two variables

* GQL allows verifying the presence of arbitrary paths, with many flexible options

* We add the ability to (1) return (2) paths or trees.

How are the US entrepreneurs, French entrepreneurs and French politicians related?

MATCH

(x WHERE x.type=entrepreneur)-[a:citizenOf]->(b: USA),
(y WHERE y.type=entrepreneur)-[c:citizenOf]->(d: France),
(z WHERE z.type=politician)-[e:citizenOf]->(f: France),
(x, y, z, w)

RETURN w

<figure><img src="image_29.png" /></figure>
# Integrating keyword search into a graph query language [5]

MATCH

(x WHERE x.type=entrepreneur)-[a:citizenOf]->(b: USA),
(y WHERE y.type=entrepreneur)-[c:citizenOf]->(d: France),
(z WHERE z.type=politician)-[e:citizenOf]->(f: France), (x, y, z, w)

RETURN w

<table><thead><tr><th>x</th><th>y</th><th>z</th><th>w</th></tr></thead><tbody><tr><td>Bob</td><td>Alice</td><td>Elon</td><td></td></tr><tr><td>Carole</td><td>Doug</td><td>Falcon</td><td></td></tr><tr><td>Carole</td><td>Alice</td><td>Falcon</td><td>....</td></tr><tr><td>...</td><td>...</td><td>...</td><td>...</td></tr></tbody></table>

<figure><img src="image_30.png" /></figure>

https://gitlab.inria.fr/cedar/extended-graph-querying
Unfortunately, journalists don't like such views of the data!

<figure><img src="image_31.png" /></figure>

ConnectionLens

Database: graph

Import

About

<figure><img src="image_32.png" /></figure>
Journalists prefer simpler views over ConnectionLens graphs

<figure><img src="image_33.png" /></figure>
Towards data abstraction

* Non-technical users need help figuring out **what a dataset contains!** ABSTRA (see next)

* Then, explore the data by:

* Automatically identifying **interesting entity paths**: PATHWAYS [11, 13]

* Abstraction-based GUI that enables formulating queries: CONNECTIONSTUDIO [9]

<figure><img src="image_34.png" /></figure>
# Part III

## ABSTRA: Abstracting Data of Any Model

Joint work with Nelly Barret (Inria), Prajna Upadhyay (Inria, now IIT Khanpur)
# How to help journalists understand heterogeneous data

Focus on (semi)structured data formats: RDBs, CSV, JSON, XML, RDF, PGs, ...

## Core principles

<figure><img src="image_35.png" /></figure>

- Hide data model details.
# How to help journalists understand heterogeneous data

Focus on (semi)structured data formats: RDBs, CSV, JSON, XML, RDF, PGs, ...

## Core principles

1. Hide data model details.

2. Any application dataset contains some **entities** connected by some **relationships**. Find and (graphically) show these!
# How to help journalists understand heterogeneous data

Focus on (semi)structured data formats: RDBs, CSV, JSON, XML, RDF, PGs, ...

## Core principles

1. Hide data model details.

2. Any application dataset contains some **entities** connected by some **relationships**. Find and (graphically) show these!

* Entities may have **nested** structure
# How to help journalists understand heterogeneous data

Focus on (semi)structured data formats: RDBs, CSV, JSON, XML, RDF, PGs, ...

## Core principles

1. Hide data model details.

2. Any application dataset contains some **entities** connected by some **relationships**. Find and (graphically) show these!

* Entities may have **nested** structure

3. Let users control **how much information** they want.

**ABSTRA** project [12, 14, 15]. Code and (many) examples:

https://team.inria.fr/cedar/projects/abstra/
Sample abstraction of an XMark XML document

<figure><img src="image_36.png" /></figure>

Application benchmark: online auctions site

3M nodes, 80 different labels, on 124 labeled paths
Abstraction of NASA RDF graph

<figure><img src="image_37.png" /></figure>
# Dataset abstraction stages

1. Turn any dataset into a ConnectionLens graph

2. Normalize the graph: all edges become unlabeled

3. Summarize the graph: equivalent nodes grouped in collections

4. Identify (nested) entities:

* Select some collections as entity roots

* Determine each entity's boundaries

5. Classify entities: assign a human-understandable name

6. Identify relationships between entities
Data graph summarization: which groups of nodes are equivalent?

Reverse each data model's guidelines for representing "similar things":

**Relations** all nodes representing tuples of the same table
# Data graph summarization: which groups of nodes are equivalent?

Reverse each data model's guidelines for representing "similar things":

**Relations** all nodes representing tuples of the same table

**CSV** all nodes representing rows
# Data graph summarization: which groups of nodes are equivalent?

Reverse each data model's guidelines for representing "similar things":

* Relations all nodes representing tuples of the same table

* CSV all nodes representing rows

* XML all XML elements w/ same name
# Data graph summarization: which groups of nodes are equivalent?

Reverse each data model's guidelines for representing "similar things":

* **Relations** all nodes representing tuples of the same table

* **CSV** all nodes representing rows

* **XML** all XML elements w/ same name

* **JSON** all nodes on the same path from the root
# Data graph summarization: which groups of nodes are equivalent?

Reverse each data model's guidelines for representing "similar things":

* **Relations** all nodes representing tuples of the same table

* **CSV** all nodes representing rows

* **XML** all XML elements w/ same name

* **JSON** all nodes on the same path from the root

* **RDF** assumed saturated: (i) typed nodes are equivalent if they have the same set of types; (ii) untyped nodes are grouped according to a flexible notion of property *cliques* [21]
# Data graph summarization: which groups of nodes are equivalent?

Reverse each data model's guidelines for representing "similar things":

* **Relations** all nodes representing tuples of the same table

* **CSV** all nodes representing rows

* **XML** all XML elements w/ same name

* **JSON** all nodes on the same path from the root

* **RDF** assumed saturated: (i) typed nodes are equivalent if they have the same set of types; (ii) untyped nodes are grouped according to a flexible notion of property *cliques* [21]

* **PGs** after conversion, similar to RDF

**And:** for all $x_1 \equiv x_2$ and label $a$, if $x_1 \stackrel{a}{\to} y_1$, $x_2 \stackrel{a}{\to} y_2$ and $y_1, y_2$ are leaves, then $y_1 \equiv y_2$.
# Graph summarization result: collection graph

Each set of equivalent nodes is a *collection*; collections make up the *collections graph*

<figure><img src="image_38.png" /></figure>

Red edges form cycles
`year#` is the collection of values of the nodes in the year collection
# From the collection graph to entities and relationships

<figure><img src="image_39.png" /></figure>

We need to:

* Select some collections as **entity roots**;

* For each entity root, determine the collections in its **boundary**;

* Until we identify *k* entities and/or *f*% of the data is reflected in the returned entities.

* Turn remaining paths between entity roots into **relationships**
Which collections make good entity roots?

<figure><img src="image_40.png" /></figure>
Which collections make good entity roots?

* Must contain more than one node

<figure><img src="image_41.png" /></figure>
Which collections make good entity roots?

* Must contain more than one node

* Should be value-rich ⇒ **backward data weight propagation**

<figure><img src="image_42.png" /></figure>
Which collections make good entity roots?

<figure><img src="image_43.png" /></figure>

* Must contain more than one node

* Should be value-rich ⇒ **backward data weight propagation**

* Compute **PageRank** on the **inverse collection graph**: nodes with many descendant attributes are favored
Which collections make good entity roots?

<figure><img src="image_44.png" /></figure>

* Must contain more than one node

* Should be value-rich ⇒ **backward data weight propagation**

* Compute **PageRank** on the **inverse collection graph**: nodes with many descendant attributes are favored

* Pick the highest-rank collection as the **root** of the next selected entity
## Which collections make good entity roots?

<figure><img src="image_45.png" /></figure>

* Must contain more than one node

* Should be value-rich ⇒ **backward data weight propagation**

* Compute **PageRank** on the **inverse collection graph**: nodes with many descendant attributes are favored

* Pick the highest-rank collection as the **root of the next selected entity**
  Assume **paper** is selected.
What to include in an entity boundary?

In the **boundary of the entity rooted in c**, we include any other collection $c'$

<figure><img src="image_46.png" /></figure>
What to include in an entity boundary?

<figure><img src="image_47.png" /></figure>

In the **boundary of the entity rooted in** *c*, we
include any other collection *c*′

* Such that there is a **path** *c* ~ *c*′ with no in-cycle edges
What to include in an entity boundary?

<figure><img src="image_48.png" /></figure>

In the **boundary of the entity rooted in** *c*, we
include any other collection *c*′

* Such that there is a **path** $c \sim c'$ with no in-cycle edges

* And along this path, each edge $c_i \rightarrow c_j$ satisfies:

* Each node in $c_i$ has at most one child in $c_j$; and/or

* At least x% of the nodes in $c_j$ have a parent in $c_i$.
What to include in an entity boundary?

<figure><img src="image_49.png" /></figure>

In the **boundary of the entity rooted in c**, we
include any other collection $c'$

* Such that there is a **path** $c \sim c'$ with no in-cycle edges

* And along this path, each edge $c_i \rightarrow c_j$ satisfies:

* Each node in $c_i$ has at most one child in $c_j$; and/or

* At least x% of the nodes in $c_j$ have a parent in $c_i$.

The **paper** entity includes: year, abstract, title (allowing in-cycle edges: all the collections)
# Finding the relationships

<figure><img src="image_50.png" /></figure>

* For each $c_1$, root of entity $e_1$

* For each path $c_1 \sim c_2$ where $c_2$ is the root of $e_2$

* Create a relationship $e_1 \to e_2$ with the labels on the path
# Classifying entities

**Goal:** compute for each entity a human-understandable label

## Ingredients

* Vocabulary of common classes and properties (from open Knowledge Graphs)

* GitTables: table and column names from GitHub

## Method

1. Identify KG classes strongly related to People, Location, Organization (manual)

2. Leverage NEs (P/L/O) extracted from name, description etc. attributes to propose type(s) ($\alpha$) for the parent of such attribute.

3. Compare the labels of entity root nodes with class and table names (Word2Vec) ($\beta$)]

4. Compare the labels of attributes of entity root nodes, with names of properties, and of GitTables columns ($\gamma$)

5. Assign a type through majority vote ($\alpha, \beta, \gamma$)
# NEs and their connections are interesting

In journalism but not only, entities such as Person, Location, Organization, Date etc. often structure our thinking about information: who? what? where? when?

ConnectionLens: find connections between node sets

* Fine granularity (node level)

* Must know what to look for

PathWays [12, 11, 13]: find the paths which connect entities of specific types.

* Aka *metapaths*, focused on extracted entities

* E.g., in conflict of interest scenario:

* People are affiliated with Organizations

* People have Conflicts of Interest with Organizations

* People co-author papers, etc.

* Coarse granularity (dataset level); users can then select paths and compute their graph-level instances.
# Sample entity paths identified by PathWays

## Result

Sort queries by length

Sort queries by number of associated data paths

Hide/show queries without associated data paths

<figure><img src="image_51.png" /></figure>

► Name#val — Name — Author — AuthorList — PubmedArticle — CoiStatement — CoiStatement#val (860 data paths)

<table><thead><tr><th>ID</th><th>Name#val ^ ▼<br>P<br>☐</th><th>Name ^ ▼<br>☐</th><th>Author ^ ▼<br>☐</th><th>AuthorList ^ ▼<br>☐</th><th>PubmedArticle ^ ▼<br>☐</th><th>CoiStatement ^ ▼<br>☐</th><th>CoiStatement#val ^ ▼<br>☐</th></tr></thead><tbody><tr><td>2901</td><td><span style="background-color: #F5B042;">Giampiero Mazzaglia</span></td><td>Name</td><td>Author</td><td>AuthorList</td><td>PubmedArticle</td><td>CoiStatement</td><td><span style="background-color: #F5B042;">...</span> <span style="background-color: #F5B042;">...</span></td></tr><tr><td>2931</td><td><span style="background-color: #F5B042;">Giampiero Mazzaglia</span></td><td>Name</td><td>Author</td><td>AuthorList</td><td>PubmedArticle</td><td>CoiStatement</td><td><span style="background-color: #F5B042;">...</span> <span style="background-color: #F5B042;">...</span></td></tr><tr><td>5531</td><td><span style="background-color: #F5B042;">Paolo Angelo Cortesi</span></td><td>Name</td><td>Author</td><td>AuthorList</td><td>PubmedArticle</td><td>CoiStatement</td><td><span style="background-color: #F5B042;">...</span> <span style="background-color: #F5B042;">...</span></td></tr><tr><td>5561</td><td><span style="background-color: #F5B042;">Paolo Angelo Cortesi</span></td><td>Name</td><td>Author</td><td>AuthorList</td><td>PubmedArticle</td><td>CoiStatement</td><td><span style="background-color: #F5B042;">...</span> <span style="background-color: #F5B042;">...</span></td></tr></tbody></table>

► CoiStatement#val — CoiStatement — PubmedArticle — AuthorList — Author — Affiliation — Affiliation#val (480 data paths)

► Name#val — Name — Author — AuthorList — PubmedArticle — ArticleTitle — ArticleTitle#val (8 data paths)

► Name#val — Name — Author — Affiliation — Affiliation#val (71 data paths)
# Identifying interesting paths in PathWays

* PathWays removes the need to code path-specific interfaces!

* Challenges:

<figure><img src="image_52.png" /></figure>

Prune spurious paths due to NE extraction errors:
use signal from the whole graph

<figure><img src="image_53.png" /></figure>

Rank paths according to edge strengths

<figure><img src="image_54.png" /></figure>

Efficiently compute instances of metapaths:
multi-query optimization [13]

<figure><img src="image_55.png" /></figure>
# Part IV

## Conclusion and perspectives
# Summary

* Data heterogeneity remains a reality due to preference or availability. No ideal data model.

* Data model heterogeneity is a big hurdle for non-expert users.

* CONNECTIONLENS: integrate data of heterogeneous models into a graph, densified by NE connections; keyword search; automatic NE path recommendation [11, 13]

* ABSTRA: View application datasets as entities and relationships, regardless of original data model [15]

## Ongoing/perspectives

* Use Abstra to transform any dataset into a Property Graph [10]

* Leverage this for **interactive data exploration** (w/ T. Bouganim and E. Pietriga) [17]

* Exploration of **very large corpora of heterogeneous datasets** as E-R graphs
This research aligns with many communities' efforts (data management, Semantic Web, NLP, Computer Vision...) to make data easy to discover, understand, use, e.g., [6, 20] and many more

* Not all data is RDF; try to serve all types.

* Available LLMs of increasing quality leveraged to exploit trusted data

* The presence of NEs can be used to improve Open Relation Extraction performance [22]

* Work with journalists! Democratic debate needs them well-equipped to analyze the data.
[1] GQL (graph query language) standard, ISO/IEC 39075:2024.
https://www.iso.org/standard/76120.html, 2024.

[2] Angelos-Christos Anadiotis, Oana Balalau, Théo Bouganim, Francesco Chimienti, Helena Galhardas, Mhd Yamen Haddad, Stéphane Horel, Ioana Manolescu, and Youssr Youssef.
Empowering Investigative Journalism with Graph-based Heterogeneous Data Management.
Bulletin of the Technical Committee on Data Engineering, September 2021.

[3] Angelos-Christos Anadiotis, Oana Balalau, Théo Bouganim, Francesco Chimienti, Helena Galhardas, Mhd Yamen Haddad, Stéphane Horel, Ioana Manolescu, and Youssr Youssef.
Empowering Investigative Journalism with Graph-based Heterogeneous Data Management.
Bulletin of the Technical Committee on Data Engineering, September 2021.

[4] Angelos Christos Anadiotis, Oana Balalau, Catarina Conceicao, Helena Galhardas, Mhd Yamen Haddad, Ioana Manolescu, Tayeb Merabti, and Jingmao You.
Graph integration of structured, semistructured and unstructured data for data journalism.
Information Systems, 104, 2022.

[5] Angelos Christos Anadiotis, Ioana Manolescu, and Madhulika Mohanty.
Integrating Connection Search in Graph Queries.
In ICDE 2023 - 39th IEEE International Conference on Data Engineering, Anaheim (CA), United States, April 2023.

[6] Simran Arora, Brandon Yang, Sabri Eyuboglu, Avanika Narayan, Andrew Hojel, Immanuel Trummer, and Christopher Ré.
Language models enable simple systems for generating structured views of heterogeneous data lakes, 2023.

[7] Oana Balalau, Simon Ebel, Helena Galhardas, Théo Galizzi, and Ioana Manolescu.
STaR: Space and Time-aware Statistic Query Answering.
In CIKM 2024 - 33rd ACM International Conference on Information and Knowledge Management, Boise, Idaho, United States, October 2024.
References II

[8] Oana Balalau, Simon Ebel, Théo Galizzi, Ioana Manolescu, Quentin Massonnat, Antoine Deiana, Emilie Gautreau, Antoine Krempf, Thomas Pontillon, Gérald Roux, and Joanna Yakin.

Statistical Claim Checking: StatCheck in Action (demonstration).

In CIKM 2022 - 31st ACM International Conference on Information and Knowledge Management, Atlanta / Hybrid, United States, October 2022.

[9] Nelly Barret, Simon Ebel, Théo Galizzi, Ioana Manolescu, and Madhulika Mohanty.

User-friendly exploration of highly heterogeneous data lakes.

In CoopIS 2023 - International Conference on Cooperative Information Systems, Groningen, Netherlands, October 2023.

[10] Nelly Barret, Tudor Enache, Ioana Manolescu, and Madhulika Mohanty.

Finding the PG schema of any (semi)structured dataset: a tale of graphs and abstraction.

In SEAGraph - 3rd Workshop on Search, Exploration, and Analysis in Heterogeneous Datastores - 40th IEEE International Conference on Data Engineering (ICDE 2024), Utrecht, Netherlands, May 2024.

[11] Nelly Barret, Antoine Gauquier, Jia Jean Law, and Ioana Manolescu.

Exploring heterogeneous data graphs through their entity paths.

In ADBIS, 2023.

[12] Nelly Barret, Antoine Gauquier, Jia Jean Law, and Ioana Manolescu.

Pathways: entity-focused exploration of heterogeneous data graphs (demonstration).

In ESWC, 2023.

[13] Nelly Barret, Antoine Gauquier, Jia-Jean Law, and Ioana Manolescu.

Finding meaningful paths in heterogeneous graphs with PathWays.

Information Systems, 127:102463, January 2025.
[14] Nelly Barret, Ioana Manolescu, and Prajna Upadhyay.
Abstra: toward generic abstractions for data of any model (demonstration).
In CIKM, 2022.

[15] Nelly Barret, Ioana Manolescu, and Prajna Upadhyay.
Computing generic abstractions from application datasets.
In EDBT, 2024.

[16] Théo Bouganim, Ioana Manolescu, and Helena Galhardas.
Efficiently Identifying Disguised Missing Values in Heterogeneous, Text-Rich Data.
In Transactions on Large-Scale Data- and Knowledge-Centered Systems LI, volume 13410 of Lecture Notes in Computer Science, pages 97–118. Springer
Berlin Heidelberg, October 2022.

[17] Théo Bouganim, Ioana Manolescu, and Emmanuel Pietriga.
A Unified Visual Exploration Framework for (Semi-)structured Data.
In BigVis 2024 - 7th International Workshop on Big Data Visual Exploration and Analytics (VLDB 2024), Guangzhou, China, August 2024. VLDB.

[18] Alin Deutsch, Nadime Francis, Alastair Green, Keith Hare, Bei Li, Leonid Libkin, et al.
Graph pattern matching in GQL and SQL/PGQ.
In SIGMOD, 2022.

[19] Minh Hoang Duong and Ioana Manolescu.
Named entity extraction in connectionlens based on large language models.
Junior Data Science and Engineering Conference, 2024.
[20] Camila Díaz, Jocelyn Dunstan, Lorena Etcheverry, Antonia Fonck, Alejandro Grez, Domingo Mery, Juan Reutter, and Hugo Rojas. Automatic knowledge-graph creation from historical documents: The chilean dictatorship as a case study. In LLM-KBC workshop in conjunction with ISWC, 2024.

[21] François Goasdoué, Pawel Guzewicz, and Ioana Manolescu. RDF graph summarization for first-sight structure discovery. The VLDB Journal, 29(5), April 2020.

[22] Prajna Upadhyay, Oana Balalau, and Ioana Manolescu. Open Information Extraction with Entity Focused Constraints. In EACL, Dubrovnik, Croatia, May 2023.