goingmeta and what a repository of live stream sessions actually contains

A monthly live stream with a repository as its handout

The project describes itself as the code and resources used in the Going Meta sessions, and the sessions are live streams that run on the first Tuesday of each month at 4pm BST, 11am ET, 8am PT, 3pm CEST and 8:30pm IST, streaming on Twitch and YouTube Live. The stated purpose of the repository is to share all resources used in the sessions so that viewers can try them and give feedback.

That framing matters more than it might look. This is a handout repository attached to a broadcast series, not a software project with a release process. There are no GitHub releases, the primary language recorded for the repository is Jupyter Notebook, and the licence is not one that GitHub can classify. The last push was on 2026-08-05, so the archives are still being added to.

The homepage is goingmeta.live, and the contents of the repository are organised by session, with directories named session01 through session49 and a separate future_sessions directory. Two numbers in that sequence are absent, session37 and session47, which suggests those sessions did not produce a folder rather than that the files were deleted as part of a cleanup.

The season table is the index of what was covered

Each session is listed in a table with a broadcast date, a title, tags, a link to the recording and a link to the code directory. Season 1 runs from February 2022 to April 2024, and the tags are the fastest way to see the subject area of a session.

The early sessions are about the fundamentals of the graph and semantic stack: Cypher and SPARQL on the British Library catalog, semantic search as a worked example, controlling the shape of a graph with SHACL, ontology based reasoning, ontology driven knowledge graph construction, ontology learning from graph data, generating natural language from a knowledge graph by annotating ontologies, common RDF integration patterns, and SPARQL based integrations.

Later sessions move into tooling and delivery: importing RDF into AuraDB with Python and RDFLib, creating virtual graphs over external data with SQL and APOC, taxonomy reconciliation, building a semantic data app with Streamlit and Protege, semantic similarity metrics in taxonomies, and a session on RDF-ing between OpenAI and Neo4j. The 2023 set closes with graph migrations from triple stores to Neo4j, ontology versioning in Neo4j, a recap episode, vector-based and graph-based semantic search, and two retrieval augmented generation sessions, one introducing the pattern and one on advanced patterns.

The 2024 entries continue in the same direction: ontology driven RAG patterns with LangChain, using LLMs for automated knowledge graph construction, unpicking the data.world benchmark on the role of knowledge graphs in LLM question answering over relational data, and building a reflection agent with LangGraph.

What is in a session directory is not documented in the README

The README is an index, not a manual. It lists sessions, titles, tags, recording links and code links, and stops partway through the second season's 2024 table, where the entry for the second session is cut off after its date.

What the repository does not do is tell you how to run any of it. There is no dependency file described, no environment specification, no database setup instructions and no statement of which Neo4j version, which Python version or which Neo4j plugins the notebooks expect. The session titles carry strong hints, since APOC appears in the tags of more than one session and n10s appears alongside data quality work, but the details of what a given notebook connects to are inside the notebook.

This is the practical constraint on using the repository. You are given a folder of notebooks that were working on a particular machine on a particular day, with a particular database, and the only documentation of that environment is the code itself. Expect to read each notebook top to bottom before you can adapt it, and expect to have to supply your own database, credentials and libraries.

The repository is also plainly a chronological record. Sessions on SPARQL integrations and data quality come before sessions on LangChain and LangGraph, and the later sessions assume concepts introduced much earlier. Reading it in order is more useful than searching for a single folder, and the tags make it possible to build a path through the archive if you only care about one thread.

The topic drift tells you what the field was doing in real time

Read as a sequence, the tags are a record of how the subject moved. Season 1 opens with graph query languages and standards, moves to ontology reasoning and construction, then to pipelines and integrations, and only in late 2023 reaches vector indexes, embeddings and retrieval augmented generation. Season 2 starts with using ontologies to guide knowledge graph creation from unstructured data, marked as a session without code, and continues with the LLM and RAG sessions.

Several sessions are explicitly about reconciling worlds rather than building one. There is taxonomy reconciliation, RDF-ing between OpenAI and Neo4j, common RDF integration patterns, and a session on unpicking a benchmark on the role of knowledge graphs in LLM question answering over relational data, tagged with R2RML and a semantic layer. That last one is the most interesting to a sceptic, because a session whose purpose is to take a benchmark apart is doing something different from the promotional sessions around it.

A few sessions are about operating graph software rather than querying it: ontology versioning in Neo4j, an unsupervised KG construction session with Prefect orchestration, and a session on controlling the shape of a graph with SHACL. The last of these is the clearest statement of the graph data quality idea in the archive, and it is a session about constraints rather than about queries.

What this repository is not, and where the wrong tool starts

The first wrong assumption is that goingmeta is a library. It is not on the package index, it has no module name, and importing it into a project is not a thing you can do. If your requirement is a component for a knowledge graph or RAG application, this repository will not supply one.

The second wrong assumption is that the code is current. Each session is a snapshot from its broadcast date, and the last of them is from 2024, while the repository itself was pushed to on 2026-08-05. The topic that moves fastest in the archive, LLM and RAG tooling, is exactly the topic where a 2024 notebook is most likely to be behind current practice.

The third is treating a notebook as a specification. The sessions are demonstrations with recorded broadcast timings, and a notebook that runs end to end in front of a live audience is a demonstration of an idea, not a hardened pipeline. There is no error handling to speak of, no test suite described, and no configuration layer.

The real alternative is not another repository but a different relationship with the sessions. The recordings are public and each session has a timestamped link, so the video is the primary source and the code is the supporting artefact. Someone who wants to understand how a particular Neo4j or RAG pattern was demonstrated can watch the segment and use the notebook as a starting point, rather than treating the notebook as a deliverable. For a team that needs production behaviour, the honest comparison is against a maintained library with a release process, and this archive does not compete with one on that axis.

Licensing and reuse are the open questions

The repository records no recognisable licence, so there is no stated grant of reuse rights for the code, the notebooks or the diagrams. The README points to the sessions, the recordings and the code directories, and invites feedback, but it does not state terms of use.

That is a genuine constraint on adoption rather than a technical one. If you are reading these notebooks to learn a pattern, that is straightforward. If you plan to copy a notebook, a query or a modelling approach into a commercial codebase, the absence of a licence file means you have no permission from the author, and asking is the only way to get it. The repository owner is the person to ask.

Attribution is a separate matter. Every session links a recording, so a talk about what a session taught is easy to credit. The code carries no such statement, and the notebooks are the more valuable artefact in practice, so the question is worth raising early rather than after a notebook has been adapted into a pipeline.

On maintenance, the useful observation is what the repository is and is not tracking. There is no version, no changelog, no release tag and no issue tracker described in the README. The archive grows when sessions are broadcast, and the directory listing shows the seasons continuing well past the table that the README currently displays.

Editorial conclusion

goingmeta suits an engineer who wants working reference code for a specific graph or RAG pattern and is willing to read the notebook to understand the data model it assumes. It does not suit a team looking for a dependency to add to a project, because nothing here is packaged for that and the repository records no licence, so check with whoever owns the code before copying it into a product. Before you rely on any session, read the notebook end to end rather than the session title, and confirm the Neo4j and Python dependencies it assumes match your own stack.

Frequently asked questions

Official sources

1. Issues
2. jbarrasa/goingmeta on GitHub
3. Project website
4. README