Knowledge Graph Conference 2025 at Cornell Tech

There is no accepted definition of knowledge graph, but commonly described as a graph having nodes and relations.

Comparison of Graph DB Systems

‘Beyond Relational Systems’ Talk by Semih Salihoğlu

• https://linktr.ee/kuzudb
• https://www.youtube.com/@KuzuDB

Resources are objects that represent:

• entities, e.g. an actual company
• types, e.g. company (a concept)
• properties, e.g. number of employees

RDF uses international resource identifiers (IRIs) – a URL-like object identifier which is composed of a namespace and a local ID.

RDF has literals, e.g. 20, “String”, 01/01/2025.

The information is encoded as triples, i.e. subject, verb/predicate, object tuples

Consider problems inherent in relational systems…

recursive querying/computations difficult

Consider the question: ‘Is Youtube as subsidiary of Alphabet inc?’

In a relational DB we might have a SubsidiaryOf table that associates Youtube with Google, and Google with Alphabet. We cannot answer this question easily in SQL. We are really asking if there is a path from Youtube to Alphabet.

WITH RECURSIVE was not introduced until 1999 (and influenced by datalog) and yields complex queries.

Further, an SQL query will not return paths.

tabluar data is not very natural

Three choices:

• datalog
• property graphs
• RDF

Datalog Solution

Note that Datalog is a declarative logic programming language.

For this solution the data model is relational, but query language is if-then rules (Datalog).

So, SQL + recursion with a different syntax

Solutions:

• LogicBlox
• RelationalAI – see documentation: https://relational.ai/docs/
• RDFOX – RDF but could express some reasoning rules with Datalog
• Soufflé – open source, but allegedly not very good.

Property Graph Systems

These systems are based on neo4j systems. Provide graph modeling, querying, and analytics.

Solutions:

• neo4j
• kùzu - syntax similar to PostgreSQL
• MEMGRAPH
• Amazon Neptune
• TigerGraph

Data model is property graph model.

• nodes and edges
• nodes and edges can have properties

The property graph model is arguably very close to relational model. Cypher-like languages. And, Cypher is a SQL-like language; outputs are tables, but you can return paths.

Introduces node and relationship tables, specified with NODE and REL keywords:

CREATE NODE TABLE IF NOT EXISTS MyTable (id String ...)
CREATE REL TABLE IF NOT EXISTS Role(FROM Table1 TO Table2, ...)

Recursive query example (Is Youtube a subsidiary of Alphabet?):

MATCH p = (a:Company)-[s:SubsidiaryOf*]->(b:Company)
WHERE a.name = "Youtube LLC" AND
      b.name = "Alphabet Inc"
RETURN p

This is just one example…

Advanced features include:

• shortest path queries
• weighted paths
• WALK, TRAIL, ACYCLIC, etc.

Other benefits:

• ranking & centrality algorithms – find important nodes in a graph
• community detection algorithms
• influence maximization algorithms

RDF

RDF stands for resource description framework. Its query language is SPARQL. Your data is heterogeneous and modeling is complex, and you want reasoning – system can do some automatic reasoning.

• nodes and edges as well as type hierarchies
• irregularities in data and connections of objects

Resources are objects that represent:

• entities, e.g. an actual company
• types, e.g. company (a concept)
• properties, e.g. number of employees

RDF uses international resource identifiers (IRIs) – a URL-like object identifier which is composed of a namespace and a local ID.

RDF has literals, e.g. 20, “String”, 01/01/2025.

The information is encoded as triples, i.e. subject, verb/predicate, object tuples

RDF allows for type hierarchies and the notion of a subclass

SPARQL is an SQL-like language used to query RDF databases.

Find all corporations subject to NI45106

SELECT ?c
WHERE {
  ?c rdf:type ?t.
  ?t gc:subjectTo gc:NI45106
}

OWL and RDFS provide ways of doing automatic reasoning

• RDF Core Engine stores records
• Reasoner provides reasoning

RDF standards facilitate basic reasoning & infer new triples in a database – standards include rdf:type and rdf:subClassOf along with inference rules e.g. (x rdf:type A) & (A rdfs:subClass of B) => (x rdf:type B) (if x is type A and type A is a subclass of B then x is type B).

So, we get some inferencing for free.

Consider something even more sophisticated – we have subject that is the relation controls and the relation type along with the object TransitiveProperty:

gc:controls, rdf:type, owl:TransitiveProperty

This gives the effect that if A controls B and B controls C, then A controls C. Note that this inference rule is from owl.

There are many more inference rules such as

• owl:SameAs
• owl:SymmetricProperty
• owl:EquivalentProperty
• rdf:subPropertyOf

Solutions:

• Graphdb
• STARDOG
• OPENLINK VIRTUOSO UNIVERSAL SERVER
• Amazon Neptune
• Altair

GraphRAG Workflow

KùzuDB + Senzing Workshop

This demo highlights traditional NLP workflows including NER (named entity recognition), RE (relation extraction), ER (entity resolution), and EL (entity linking)

Paco Nathan (Senzing) and Prashanth Rao (Kùzu)

github.com/kuzudb/kgc-2025-workshop-high-quality-graphs

docker pull senzing/demo-senzing

Typically a 4:1 ratio between unstructured and structured data…

How can we develop a graph from this data?

KG construction devised as three steps

1. using NLP for information extraction, e.g. entity/relationship extraction, for basic graph construction
2. linking KG with existing structured data
3. KG enhancement, e.g. entity resolution

An important problem is a person whose identity is expressed by many heterogeneous records;

Highlighted algorithms:

• Louvain community algorithm – partitions graph into subgraphs
• degree centrality algorithm – rank entities of interest

Kuzu Demo

Plays well with the python data science ecosystem.

Kuzu can run in the browser (WASM) and on mobile and embedded devices.

Python yfiles used for visualization in a python notebook

g.v()

BAML Demo

https://lu.ma/lvzwsan1

Data.world Demo

Data.world provided an alpha demo for their software with LLM-enhanced functionality.

• relies https://www.github.com/circlemind-ai/fast-graphrag

The demo helped to emphasize the UX-friendly aspects of the software – users can add nodes and edges to the graph through the UI among other things.

Users created an ontology in the UI:

They then fed a corpus providing a description of the business including entities such as customers and employees.

The backend software, in conjunction with the LLM, works to enhance the graph in various ways

Since there are some mistakes, the user must fix them, e.g. add/remove classes, instances, etc.

Graph Neural Networks

Giueseppe Futia

https://github.com/giuseppefutia/klab?tab=readme-ov-file#--unlocking-graph-neural-networks

This talk focuses on learning where your input data is graph data.

How to extract graph-based features for machine learning with NetworkX

https://colab.research.google.com/drive/1ycjxFUqmV9K1UO15969QZvU3IJo3IqCD

• uses Pytorch geometric (PyG)

Graph Representation Learning (GRL) – consistent with representation learning we want to automatically learn the features for the downstream prediction task.

https://medium.com/ai-advances/the-expressive-power-of-gnns-invariance-and-equivariance-101768971cd9

Graph convolutional neural net

https://colab.research.google.com/drive/1dac3u8PBk_oEXvGbQUJWQc8vGDyI6PEh?usp=sharing

GraphSAGE

https://colab.research.google.com/drive/1BGgmyn8SnEBWUnfe9wxNhm06KjD87xNP?usp=sharing

Graph Attention Network (GAT)

https://colab.research.google.com/drive/12lRj9qnGneYrGaueOy3Wi5b3hsaXxLkx?usp=sharing

GNN Applications

Downstream tasks including link prediction (are these nodes connected?) and classification (is this node of type x)

Node classification

https://colab.research.google.com/drive/1D72FAxMUDy8VDJHgWGwwGX57J-iBaxvE?usp=sharing

Link prediction

https://colab.research.google.com/drive/1MsPfrN1yUeRWI3TSH3oiCAVBfcpJx4rF?usp=sharing

G-Retriever

“Chat with your graph”

Key idea is that you incorporate learnable (graph) embeddings that can be updated during training

https://colab.research.google.com/drive/1dJUYq5VbuskVnLeWrZXT4t-jz2vdr5Gl?usp=sharing

Manning Press Knowledge Graphs and LLMs in Action kgconf

Reports of the Death of Knowledge Engineering

Highlights the (awards given to scientists performing secondary analysis of data) and the importance of FAIR Guiding principles for secondary analysis (see: https://www.nature.com/articles/sdata201618)

The FAIR Guiding Principles

• To be Findable:
  • F1. (meta)data are assigned a globally unique and persistent identifier
  • F2. data are described with rich metadata (defined by R1 below)
  • F3. metadata clearly and explicitly include the identifier of the data it describes
  • F4. (meta)data are registered or indexed in a searchable resource
• To be Accessible:
  • A1. (meta)data are retrievable by their identifier using a standardized communications protocol
    • A1.1 the protocol is open, free, and universally implementable
    • A1.2 the protocol allows for an authentication and authorization procedure, where necessary
  • A2. metadata are accessible, even when the data are no longer available
• To be Interoperable:
  • I1. (meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation.
  • I2. (meta)data use vocabularies that follow FAIR principles
  • I3. (meta)data include qualified references to other (meta)data
• To be Reusable:
  • R1. meta(data) are richly described with a plurality of accurate and relevant attributes
    • R1.1. (meta)data are released with a clear and accessible data usage license
    • R1.2. (meta)data are associated with detailed provenance
    • R1.3. (meta)data meet domain-relevant community standards

Highlights problems with NCBI BioSample, e.g. 73% of “Boolean” metadata values not actually true or false

Argues for (1) the use of ontologies to annotate data.

Example: the Gene Expression Omnibus has samples that specify age over thirty ways, e.g. age, AGE, age_years, etc.

See for the world’s most comprehensive repository of biomedical ontologies.

(2) reporting guidelines – ways of structuring the metadata we want to query – see MIAME for an example of this. Essentially, what are the standard attributes of experiments that should be recorded in metadata?

(3) Technology is needed to get there; Stanford is working on:

1. CEDAR Workbench: editor for creating new standards-compliant metadata from ontologies, reporting guidelines
2. CEDAR Metadata Validator: validates metadata against CEDAR templates

Example screenshot with reporting guidelines to select from:

Example guideline:

• CEDAR is connected to BioPortal, so you have access to ontologies to provide standardized values
• these tissues are from the UBERON ontology

Uses JSON-LD under the hood:

{
"@id": "https://repo.metadatacenter.org/template-instances/5cd8592b",
"schema:name": "NCBI BioSample Metadata (liver-8)",
"cell_type": {
"rdfs:label": "hepatocyte",
"@id": "http://purl.obolibrary.org/obo/CL_0000182"
},
"disease": {
"rdfs:label": "hepatocellular carcinoma",
"@id": "http://purl.obolibrary.org/obo/DOID_684"
},
"tissue": {
"rdfs:label": "Hepatic Tissue",
"@id": "http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl#C32735"
},
"sex": {
"rdfs:label": "female",
"@id": "http://purl.obolibrary.org/obo/PATO_0000383"
},
"cell_line": {
"rdfs:label": "HepG2",
"@id": "http://www.ebi.ac.uk/efo/EFO_0001187"
}
}

Dryad platform includes the CEDAR workbench and so does the Open Science Framework App.

The CEDAR metadata validator is able to ingest and validate data from spreadsheets; HuBMAP is trying to identify all the biomarkers in the human body and it is using the validator.

The metadata template ‘unifies’ this approach.

Think about this template as a data structure… derived from a… knowledge graph… [that captures] the beliefs that a particular scientific community has about how it wants its data managed and annotated.

Look into the GOFAIR initiative and its metadata for machines (M4M) workshop – basically, knowledge acquisition from scientists in order to make experiments accessible / intelligible to a third party. What needs to be captured to enable secondary analysis. The results of this are captured in a CEDAR template.

The Netherlands Organization for Health Research and Development has conditioned grants on the adoption of these metadata templates. (see ZonMw) The practical effects are that the data is put in an online repository, the metadata annotated appropriately and accessible; this is all being done in CEDAR.

Beyond GraphRAG: Graph Agents

Peio Popov of Graphwise.ai presented their product which leverages GraphDB.

Tooling

The usual tools for GraphRAG are presented, i.e. full-text search, SPARQL, vector databases, but also graph similarity.

Information is indexed three ways: semantic (relates to an ontology with reasoning), full-text (e.g. keyword), and vector (e.g. similarity, clustering, etc.)

You configure an agent:

Once configured, you can to talk to it:

The notion that you can query using some combination of the three indexes is a powerful paradigm.

Full-text search example with explanation:

You can visualize associated graphs:

Which can, of course, be queried:

• the SPARQL query is generated by the supporting LLM

Querying using a SPARQL query under the hood with a custom schema (NLQ2SPARQL):

• can handle multiple hops, arithmetic

This is perhaps the most challenging kind of query:

But, you are able to debug the query:

What happens if we give it a bad (ambiguous) query?

Using graph similarity to query:

Querying is also possible with GraphQL API.

A variety of connectors are available:

Similarity indexes can be used to store previous queries; in other words, a question answered correctly only needs to be answered once.

Customization

Users can customize the stack, say, by adding Lucene indexes.

Open Questions

• Optimization - What results should be returned?
• How do we combine results returned from different indices, etc?

Choosing an Ontology Talk

• Pete Rivett, Ora Lassila, Margaret Warren
• Contributions from the Data Worthy Collective

• A-box, T-box, etc. are ways to partition your ontology

Some nuances – relations are known as properties in RDF.

RDF was not created specifically to be a graph language, rather it is an ontology language but lends well to graph representation.

How do you choose an ontology?

1. Choosing an existing ontology – saves you from having to do work; outsources expertise and experience; but, verify ontology meets requirements and that you (preferably) have support

• can also extend an existing ontology

2. Creating your own – get help doing this and ensure help is available later

• uses case(s) – try not ‘boil the ocean’ (model everything) because it’s fun
• competency questions – what questions should the ontology be able answer; these can be later formulated using something like SPARQL
  • ‘What are all known whales?’ – this will not work with wikidata/dbpedia because there is no such thing as a ‘whale’ in Linnaean taxonomy; then, if you search cetaceans, you’ll get dolphins and porpoises as well (not what you want)
• ontological commitments – some things might get inferred that are not desirable
• scaling – are you able to handle the number of triples generated

Combining ontologies

There are two chemical ontologies which cannot be merged because one does not distinguish between isotopes. There is at least one solution, which is highly complicated.

• RDFS (Resource Description Format Specification) – standard way of representing information as triples in a web-fedaratable fashion; introduces basic schema constructs such as classes with subclasses, properties with subproperties, and properties can have domains and ranges; – does allow for a reasonable amount of inferencing; one nuance – domains and ranges are not constraints rather they support inferencing, e.g. if you create triple with relation $r$ then you can infer that $h$ is of the domain of $r$ and $t$ is of the range of $r$
• OWL extends RDF schema and adds inferencing capability
• SHACL – allows constraints on nodes (types of properties, which properties are mandatory, etc.), and views on nodes; so, you can you it for constraining your ontology and/or for enhanced querying; one school of thought is that you can get away with just using SHACL to define your ontology.
• SKOS – for taxonomies and thesauruses
• LinkML – may be a hazard that you end up defining a data schema rather than an ontology
• PGSWG – this group is trying to learn from standards such as RDFS to define a standard schema for property graphs, which are fairly unsemantic in principle, but used by Neo4J
• SPARQL – SQL for knowledge graphs; SPARQL can be used in ontologies (specifically in SHACL) to represent more sophisticated constraints
  • GQL (extends Cipher?); GraphQL is not for querying graphs (JSONQL probably a better name), but there is some work on an API to bridge between SPARQL and GraphQL
• DL (Description Logic) Syntax

Consider the problem of inferring a subclass. You have the rule that any B is also an A; if x is an B do you want the inference that x is an A to be stored as another triple (forward-chaining) or do you want that inference to happen at runtime (backward-chaining)?

Description Logic markup provides a way of coding different capabilities (see DL handbook):

• Vocabulary/Taxonomy/Thesaurus Style
  • recall that in a library you might have categories such as Travel, Geography, Economics, etc.
  • there is nuance in the semantics here with a SKOS ontology – depending on the ontology the relation broader may or may not imply subclass is a class
  • SKOS-XL provides the ability to add labels as items in and of themselves that can be managed
• Search Engine Style
  • intermediate reification, e.g. an object between a person and corporation (not widely used, surprising results)

• structured datatypes, e.g. a monetary amount which is a tuple consists of a number and currency, must be made a class in RDFS/OWL
• idDefinedBy can appear redundant when encountered in practice, but it serves to provide a link back to the ontology

• Reasoning-centric Style
  • FIBO (Financial Institute Business Ontology); extensive tests run when changes are made to the ontology
• Philosophical Style – includes academically-driven ontologies; may compromise on practicability
• Accounting Style – called taxonomies, but are semantically stronger

Can you layer additional constraints after having chosen an ontology?

You can; you can do this using SHACL (use shapes) which is an argument for using different URIs for shapes and classes; another way is to have different files representing the same ontology, e.g. basic ontology in one OWL file and then in a different OWL file using same URI different constraints, etc. (this is what FIBO does) – in this case consider avoiding circular imports, e.g. A imports B imports C imports A. Have another look at the ‘Levels of Reasoning’ slide.

With temporality, the concern is do you want to just represent things as they are today or do you want represent things as they were in the past; do you want to represent the whole knowledge graph as a snapshot or are there specific things that you’re focused on, e.g. employment.

Sources

• ←Previous
• Next→