---
title: "A Knowledge Graph That Google and AI Understand — Blackbook"
description: "How we built blackbook.dk as one knowledge graph: fixed @ids, schema generated from the CMS and honest provenance. A technical walkthrough with code."
canonical_url: https://www.blackbook.dk/en/journal/knowledge-graph-with-schema/
md_url: https://www.blackbook.dk/en/journal/knowledge-graph-with-schema/index.md
language: en
last_updated: 2026-11-01
---

# A Knowledge Graph That Google and AI Understand — Blackbook

How we built blackbook.dk as one knowledge graph: fixed @ids, schema generated from the CMS and honest provenance. A technical walkthrough with code.

> Alternate (Danish): https://www.blackbook.dk/journal/knowledge-graph-med-schema/index.md
> Author: Jeppe Sloth Carlsen — Senior Product Designer & Creative Technologist (https://www.blackbook.dk/en/about/)
> Author ID: https://www.blackbook.dk/#person-jeppe
> Publisher ID: https://www.blackbook.dk/#organization
> Topics: knowledge graph, schema markup, structured data, JSON-LD, LLMO
> Part of: Blackbook — digital design agency, Copenhagen (https://www.blackbook.dk/en/)
> Published: 2026-11-01
> LLM reference: https://www.blackbook.dk/llms.txt
> Full reference: https://www.blackbook.dk/llms-full.txt
> Markdown sitemap: https://www.blackbook.dk/sitemap.md
> Preferred citation URL: https://www.blackbook.dk/en/journal/knowledge-graph-with-schema/

## Journal — A Knowledge Graph That Google and AI Understand

- Knowledge Graph – interactive network of design work, projects, skills and employments

Most websites have a little schema. An Organization snippet on the homepage, maybe some Article markup on the blog – copied from a guide, written by hand and then forgotten. It works, but it doesn't tell machines very much. They get isolated fact cards, not a connected description of who is behind the site, what they do, and how it all fits together.

Blackbook.dk is built differently. The entire site is one knowledge graph: a person, a company, a brand, services, case studies, images, videos and articles – all of them entities with fixed addresses that point to each other. When this article was written in November 2026, the 300 pages in the sitemap carried roughly 37,000 schema nodes between them, spread across 39 types and 740 entities with their own @id. Not one of them is written by hand.

Here's how it works – and what we learned along the way.

## One data layer, three outputs

Every piece of content on the site lives once, as structured data in Sanity CMS. A case study isn't a page; it's a document with typed relations to services, areas of expertise, roles and images. The same data layer generates three things: the visual page, the schema graph, and the AI agent that answers questions in the chat.

That's the whole secret. When schema is generated from the same data as the page, the two can never drift apart. If we fix a title, a description or a service on a case study, the graph is updated on the next build. There is no schema file that someone has to remember to maintain.

Compare that with the typical approach: an SEO plugin that generates standard markup from the page title and description. It gives you a baseline, but the plugin can't tell a case study from an article, doesn't know who made what, and can't see the relationships between pieces of content. A knowledge graph needs a content model that already knows those relationships. Schema is simply the way you express them.

## @id is the backbone

The most important building block in a knowledge graph isn't the types – it's the identities. In schema.org terms that's the @id: a fixed URI that says "this is exactly this thing". When two nodes carry the same @id, a machine knows they describe the same entity – even if they sit on different pages.

Blackbook has three fixed anchors: the person, the organisation and the website. They live as constants in the code, with a comment saying they must never change:

**lib/jsonld.ts**

```typescript
// ─── Stable @id URIs — never change these ───
export const PERSON_ID = `${SITE_URL}/#person-jeppe`
export const ORG_ID    = `${SITE_URL}/#organization`
export const SITE_ID   = `${SITE_URL}/#website`
```

Everything else references them instead of repeating them. A case study doesn't say "made by Jeppe Sloth Carlsen, Senior Product Designer, Copenhagen …" – it simply points to the person's @id. The person is described in one place, and every other node points there. That's the difference between a stack of business cards and a network.

Here's what a case study looks like in the graph, simplified:

**CreativeWork (simplified)**

```json
{
  "@type": "CreativeWork",
  "@id": "https://www.blackbook.dk/portfolio/<case>/#work",
  "creator":   { "@id": "https://www.blackbook.dk/#person-jeppe" },
  "publisher": { "@id": "https://www.blackbook.dk/#organization" },
  "isPartOf":  { "@id": "https://www.blackbook.dk/#website" },
  "about": [
    { "@type": "Thing", "@id": "https://www.blackbook.dk/services/ux-product-design/#service" }
  ]
}
```

Notice the about property. The case study doesn't point to a loose topic, but to the same @id that the service page uses for its Service node. So the case study and the service are connected in the graph itself – not just through a link in the HTML.

## Every page carries the whole identity

The core – person, organisation, website and brand – is on every page through the shared layout. Wherever a crawler lands, it meets the same identity with the same anchors. On top of that, each page type adds its own nodes: a case study adds the work, its images and its videos. A service page adds Service and Offer. The About page adds experience, roles and awards. The median was around 100 nodes per page; the About page was the heaviest, with more than 400.

That sounds like a lot, but none of it is decoration. Every node answers a concrete question that a search engine or a language model would otherwise have to guess: Who made this? When? For whom? Which discipline does it belong to? Can the image be reused?

## What the graph describes

**The person.** Name, title, languages, experience and expertise via knowsAbout – plus occupations coded to the official O*NET-SOC standard, so "Senior Product Designer" isn't just a string of text but a recognised job category.

**The organisation.** Blackbook is both an Organization and a LocalBusiness: address, coordinates, opening hours, a contact point in Danish and English, founding year and founder – as an @id, of course.

**The services.** Each service is a Service node with a fixed @id, collected in an OfferCatalog under the organisation. These are what the case studies point to.

**The work.** Each case study is a CreativeWork with a creator, publisher, year, topics and images. The images are ImageObjects with credit, copyright and licence, so Google can show them as licensable in image search.

**The content and the structure.** Articles, videos, breadcrumbs, lists and the main navigation are all described, so machines can see how the site is organised – not just its individual pages.

## sameAs: identity across the web

A knowledge graph on your own domain is powerful, but it is still a claim. sameAs turns it into an anchor. The person and organisation nodes link to the profiles that describe the same entities elsewhere: LinkedIn, Behance, Dribbble, Vimeo, YouTube, GitHub and agency directories. The message is: the person described here is the same one described there.

We've been deliberate about what the graph should strengthen: Blackbook and Jeppe – the person, the company, the brand and the expertise. Clients appear on the case studies as the organisation the work was made for. They are context, not the centre of gravity.

## Honest provenance

One of the more unusual choices in the graph is about copyright. Some of the case studies in the portfolio were made while Jeppe was employed elsewhere. Blackbook shows the work, but didn't produce it – so the graph mustn't claim it did. Those case studies get no copyrightHolder. Instead, the organisation that produced the work is credited through producer. Awards follow the same rule: an award won for work at an employer belongs to the person, not to the company.

It's a small detail, but an important one. A knowledge graph is only worth something if machines can trust it. Overstate things in one place and you undermine the whole thing.

## One work, two languages

The site exists in Danish and English, and that's a classic schema trap. If the Danish and English versions of a case study each get their own @id, machines see two different works. That's why every work, service and article uses a language-neutral @id based on the Danish slug, while url and mainEntityOfPage point to the localised page. The result is one entity with two language representations that merge in the graph instead of competing.

## Why it matters more for AI than for Google

Google uses only a fraction of schema.org for rich results – breadcrumbs, videos, image licences and the like. The rest is read, but not visibly rewarded. That's why most sites stop at whatever Google shows off.

Language models work differently. When an AI crawler reads a page, structured data is the fastest route to unambiguous facts – who, what, where and when – without having to interpret layout and marketing copy. A connected knowledge graph gives the model a map of the entire company, no matter which page it starts on.

We can see it in the traffic. The AI crawlers from the major language models visit the site every day, and they don't stop at the homepage – they work systematically through case studies, services and articles. Every one of those pages tells the same consistent story about who Blackbook is and what Blackbook does.

The graph is therefore one layer in a bigger strategy. Together with llms.txt and markdown versions of every page, it's what we call [LLMO](https://www.blackbook.dk/en/services/llmo/): making a website readable for the models that increasingly answer the question "who should we choose?".

## What we learned

**Types are not the goal.** It's tempting to count types. But ten types that don't connect are worth less than five that do. Don't ask "which types are we missing?" – ask "what question can a machine still not answer about us?".

**Weight is a real cost.** Structured data is HTML, and HTML has to be downloaded. As the services overview grew, every service description appeared twice – in the Service description and in an FAQ block. We removed the FAQ block, because Google no longer shows FAQ results for ordinary sites, and kept the descriptions. Cut what carries no information – never what does.

**Rich text must become plain text.** Content from a CMS is often formatted text with blocks and marks. Dropped straight into schema, machines get objects instead of sentences. Every description is converted to plain text before it goes into the graph.

**No loose ends.** Every reference to an @id must point to a node that actually exists. A reference into nothing is worse than no reference at all – it promises a connection that isn't there.

## See the graph for yourself

You can look at Blackbook's graph right now. Paste any page into the Schema Markup Validator at validator.schema.org, or fetch it from the terminal:

**Terminal**

```bash
curl -s https://www.blackbook.dk/ \
  | grep -o '<script type="application/ld+json">[^<]*</script>' \
  | sed 's/<[^>]*>//g' \
  | jq -c '."@graph"[]? | {"@type", "@id"}'
```

The first line of the output is the person, then the organisation, the website and the brand – the same four anchors that everything else on the site points to.

Want to know how readable your own site is for AI? Run it through our [free scan](https://www.blackbook.dk/en/scan/). And if you'd like a knowledge graph built into your own site, read more about [schema as a service](https://www.blackbook.dk/en/services/schema/).

## More

- [Journal](https://www.blackbook.dk/en/journal/)

## About Blackbook

Blackbook is a Copenhagen digital agency blending creativity and technology across UX, branding, websites and eCommerce.

Areas of expertise:

- [Apps & Products](https://www.blackbook.dk/en/area/apps-products/index.md)
- [Brand & Campaigns](https://www.blackbook.dk/en/area/brand-campaigns/index.md)
- [Websites & eCommerce](https://www.blackbook.dk/en/area/websites-ecommerce/index.md)

Key figures:

- 250+ Digital projects
- 150+ Clients
- 15+ Fortune 500
- 5+ Top 100 Brands
- 25+ Years experience

## Site

[Home](https://www.blackbook.dk/en/index.md)
[Portfolio](https://www.blackbook.dk/en/portfolio/index.md)
[About](https://www.blackbook.dk/en/about/index.md)
[Services](https://www.blackbook.dk/en/services/index.md)
[Experience](https://www.blackbook.dk/en/experience/index.md)
[Recognition](https://www.blackbook.dk/en/awards/index.md)
[Contact](https://www.blackbook.dk/en/contact/index.md)
[CV](https://www.blackbook.dk/en/cv/index.md)
[Journal](https://www.blackbook.dk/en/journal/index.md)

Blackbook · Jerichausgade 7 · 1777 Copenhagen · (+45) 31 10 79 13 · [jeppe@blackbook.dk](mailto:jeppe@blackbook.dk)