Knowledge Graphs: Today's triples just ain't enough

Knowledge hypergraphs are garnering a lot of attention – and deservedly so.? You can find my two previous posts on knowledge hypergraphs and on more adaptive conceptualizations for hypergraphs as well as Kurt Cagle 's focused and more practically minded pieces on Hypergraphs and RDF , on Named Graphs (one kind of hypergraph), and most recently on Rethinking Hypergraphs . Now Cohen Reuven has released a detailed, thought-provoking pair of posts on Hypergraph Prompting along with his github repo. I'm particularly interested in his Unified Semantic Network Representation (scroll down to the second part of this link ) – because it's one of the few pieces that start to struggle with the nitty-gritty of how to define and represent a range of useful triple types.? Dave Duggal chimes in here with the insight that we want to look for places where the (knowledge hyper-) graph is mediating the relationships between all participating elements (no bus, no stack, a completely horizontal architecture).?

Three things stand out for me from these readings and my constant discussions with AI entrepreneurs.??

One is that we are clearly evolving toward knowledge graphs as a platform not only for storing facts and for bridging input data with domain knowledge but also for a semantically explicit control layer that mediates across inputs, system functions, and output generation.? This will become much clearer when we re-"discover" the GOFAI technique of embedding not only literals but also procedures in graph nodes – so we'll have graphs of procedural knowledge as well as of static facts. Instead of a static literal value like 6,000 kgs for a triple like (elephant, hasWeight, 6,000 kgs), we might have a function as object in triples like (elephant, hasWeight, average(select weight from table in db where entityType = 'elephant')) to get constantly up-to-date values. A knowledge-graph map of the modularity and composability of services and data products is one example of this "knowledge graph as a platform for orchestration" approach.

The second is that the currently very common kludge where strings or text snippets implement graph nodes (instead of concepts as arrays or graphs of explicit, reusable features) is easy to grok and yields quick prototyping for jazzy POCs. But innovators beware:? to me it's clear that this stopgap text-only tactic is ultimately throwaway work:? it's so easy to implement similarity of string context (in an ad hoc embedding space) as a surrogate for meaning – what I want to call mirage semantics (when you try to pin the meaning down, it evaporates) – that these POCs will be extremely difficult to validate, impossible to differentiate from other such systems (therefore difficult to sell or invest in), and will in the end not deliver the "knowledge" or reasoning that many use cases require.??

A third observation is that many people seem to be working in a semantic vacuum. They have excellent product development and coding skills as well as a good understanding of syntactic standards or metalanguages.? But it's been so long since semantics was a systematic part of anyone's computer science training that they're groping for ways to understand what it means. They often have no clear idea of what a semantics- or knowledge-based application will look like, either in theory or in practice.?

The fundamental but indistinct-to-many distinction between meaningful for the human user and meaningful for the algorithm is blocking AI's progress in a very big way.

This is where I'm trying to help: by discussing the relevance and details of key concepts in semantics and epistemology for AI development and innovation.

Beyond Knowledge Graphs

Let's take a step back to add more context. Representing and storing knowledge in the form of head-relation-tail triples makes perfect sense when you're starting from data and database tables. In most settings, data already comes in a variant of triple format:? the row-column-value or entity-attribute-value notation of spreadsheets in which the literal <value> of attribute <column> describes an entity <row>.? Re-representing table data in knowledge graphs enables much clearer, reusable, and manipulable semantics by adding explicit attributes and structure (i.e., additional relations) to the assumed-to-be-independent database column names. The most common examples of this semantic enrichment are taxonomies that document the relations between column names or between values in a particular column – so they enable more, and more structured, options for aggregation in modeling.

But when you're starting from other knowledge sources – like unstructured text, standard procedures, or practical experience –, then triples alone are no longer sufficient.? In most sentences, for example, there are more than two entities (which appear as nouns) linked by relations expressed with order (the blue bottle; bottle – hasColor – blue), with markers like prepositions (cut with a knife; cut – instrument – knife), or with other linguistic mechanisms. The most common case in which triple notation fails is in representing knowledge about events, as in sentences like Steve sold Ali his car for $1000 or Affix screw 17a to hole 22f with nut and washer.?

To represent, store, and leverage this kind of event knowledge at scale, we need to go beyond simple graphs and create knowledge hypergraphs – structures of concepts in which a single conceptual relation (like selling) involves more than two entity or literal concept nodes. A hypergraph, then, is equivalent to a connected neighborhood of a graph (i.e., a sub-graph) that includes multiple nodes and a single focused relation.?

Types of Hypergraphs

Part of the innovator's problem is that talking about hypergraphs in general won't take us very far.? There are easily thousands of types of hypergraphs and ways to build them. Without identifying their attributes and internal structure, we can't understand these different types and subtypes well enough to articulate rules, principles, or even guidelines about how to build, deploy, and validate them.?

Similarly, we know from Science that we make progress when we can identify coherent new categories of entities, the attributes that systematically differentiate them, and the category-specific rules or generalizations that describe them in increasing detail.? We measure progress by an increase in the number of types and subtypes that we can document, rather than by how many individual instances we can find. So for progress in AI we too will need to define families or templates for different types and subtypes of hypergraphs.

One key subtype of knowledge hypergraph is the event. Events were exhaustively investigated in the knowledge representation literature of GOFAI – because researchers invested significant effort to discover how to represent unstructured textual knowledge in a structured, coherent form that could support symbolic reasoning. There were many approaches and proposals (see Helbig, 2006 for a detailed review) for developing a standard vocabulary of explicit, reusable relations to link concepts (semantic roles, thematic roles, or case relations) and of concept types and subtypes (ontologies). In the end, these efforts failed to reach a workable consensus on a shared metalanguage for representing knowledge in hypergraphs and many researchers moved on to other topics. More recent work , however, suggests that we can learn correspondences between different sets of relations, so adoption of a single, unified standard may not be necessary – as long as the different relations are well documented.

GOFAI researchers left behind, however, a rich literature on how to define many of the roles and relations that we need to leverage for building today's knowledge graphs and hypergraphs:? Frederiksen (1975) offered a particularly well-defined, detailed, and complete account of events and other kinds of knowledge hypergraphs (which he called propositions) that can save us today the effort of re-inventing a whole bunch of wheels.

Event Hypergraphs

Events are conceptual structures that denote changes of some attributes over time and the involvement of multiple entities. They are particularly useful in developing digital twins that model steps or procedures in manufacturing and for representing knowledge from text.? In selling events, for one example, ownership of some artifact changes and a seller, product, buyer, and amount of money are involved – moreover, in sentences we routinely specify the time and place of events, along with additional details. Triples simply don't offer enough affordances to represent and store all of this information in a systematic, reusable way.??

In the case of event hypergraphs, then, the relation that connects multiple nodes is a conceptual event, a change.? Within event hypergraphs, we use a distinct subtype of relation (often called a semantic role, thematic role, or case relation) to represent in more detail the different relations between the participating entities and the event – inside the hypergraph.?

It is common practice to build hypergraph templates:? i.e., a relation with a collection of its most common roles – but with typed, uninstantiated variables for the nodes. Templates are to hypergraphs as categories are to entities:? they define essential components and characteristics for reuse over many instances. Hypergraph templates are particularly useful subgraphs:? they represent what are the most common entities, how they are related to the event, and what we know to expect so that when people describe them in incomplete or incoherent sentences, we can identify the issues to add or adapt the input using this prior knowledge. The templates, then, capture both general and specific domain knowledge that we can use for principled inference and knowledge graph completion.

Given a selling event, for example, we know a lot about its internal structure -- even if it is our lay definition of selling. Sales organizations will have more specialized, more detailed definitions for their concepts of selling events – and will use them for training, for tracking, and for evaluation.? For us non-specialists, things are pretty simple. In Steve sold Ali his car for $1000, there is someone who initiates the event – the AGENT (Steve) – and there is the OBJECT of sale (the car changes one or more of its attributes). There is a different person (it's anomalous to sell to yourself) – the RECIPIENT (Ali) and there are a couple of subevents:? the AGENT transfersOwnership of the OBJECT (not mentioned) and the RECIPIENT pays PRICE ($1000). Our knowledge of selling events also includes things like afterwards RECIPIENT no longer has the money, the AGENT no longer owns the car, and that all of this can happen in different ways on different days at different times. A specialist's concept of selling is likely to include more detailed information like sales circle, stakeholders, terms, conditions, legal representatives, process milestones, customer satisfaction, etc.

So a template for a generic selling hypergraph will include a coherent collection of triples centered around an event concept – a subgraph – which in a more compact notation might look like this:

sell AGENT:__1___, OBJECT:__3___, RECIPIENT:__2___

pay AGENT: ___2__, OBJECT: 3_, RECIPIENT: ___1__

transfer AGENT: ___1__, OBJECT: title, RECIPIENT: ___2__?

In other words, a hypergraph for our simple concept of selling includes both semantic roles like AGENT, OBJECT, and RECIPIENT and it also includes subevents (indicated here with indentation) like paying and transfering.? The slots are cross-indexed with digits to show that the same entity can appear in different places or roles in different subevents. Each instance of a selling event will have different entities in each of the semantic roles and we can document the attributes that are specific to each entity as part of the template, e.g., AGENTs are usually human, OBJECTs are usually inanimate, etc. Hypergraph templates, then, can be more or less detailed and provide a mechanism to define and deploy complex concepts.

Both our sentences and our knowledge are mostly incomplete. Hypergraph templates provide a mechanism for managing and improving both of them.

• When processing a wide range of incomplete, degraded, or incoherent inputs, a template helps us identify missing information and can trigger additional inferences to complete it.?
• When generating sentences, a template ensures completeness and coherence of the information and guides the sentence syntax.?
• When learning to expand our knowledge, we can guide attention to gathering information about entities or subevents that are missing from or underspecified in our current hypergraph templates.??

Unclear notions of semantics are blocking progress in AI. Many researchers and developers are not making the fundamental distinction between meaningful for the human user (concepts characterized with with only-human-readable labels, descriptions, or definitions) and meaningful for the algorithm (concepts characterized with features of their components and characteristics). The concepts and conceptual structures that we need to represent knowledge and support reasoning go beyond simple subject-predicate-object triples. Triples simply won't do the trick: we also need templates and instances of hypergraphs.