Evidence graph w schema.org — typy, relacje i błędy, które unieważniają całość

Artykuł 4 z toru Evidence Graph ← Typologia dowodów

Trzy poprzednie artykuły zbudowały teorię: definicję, metodę pomiaru, typologię dowodów. Ten artykuł schodzi do implementacji — jak zapisać graf dowodów w danych strukturalnych, żeby maszyny mogły go odczytać bez interpretacji.

Schema.org nie ma typu EvidenceGraph i nie potrzebuje go mieć. Graf dowodów składa się z istniejących typów i relacji, użytych konsekwentnie. Cała robota polega na trzech rzeczach: stabilnej encji, właściwych relacjach i spójności między domenami. Oraz na unikaniu czterech błędów, z których każdy unieważnia resztę.

Fundament: encja z trwałym identyfikatorem

Wszystko w grafie dowodów wisi na jednym elemencie: kanonicznym opisie encji z trwałym @id.

@id w JSON-LD to identyfikator węzła — adres, pod którym encja „mieszka” w grafie. Bez niego każde wystąpienie organizacji w danych strukturalnych jest osobnym, anonimowym obiektem; z nim wszystkie wystąpienia — na wszystkich stronach i domenach — wskazują ten sam węzeł.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://studio.ifox.pl/#organization",
  "name": "Studio iFOX",
  "url": "https://studio.ifox.pl",
  "description": "Studio tworzące strony internetowe gotowe na agenty AI.",
  "sameAs": [
    "https://webflux.pl/#organization",
    "https://cyberflux.pl/#organization"
  ],
  "knowsAbout": [
    "agent-readiness",
    "AI visibility",
    "dane strukturalne",
    "Model Context Protocol"
  ]
}

Zasady dla @id: format URL z fragmentem (#organization to konwencja), stabilność (raz wybrany, nigdy nie zmieniany) i użycie tego samego @id w każdym miejscu, gdzie encja występuje. Odwołanie do encji w innym bloku nie powtarza całego opisu — wskazuje węzeł:

{ "author": { "@id": "https://studio.ifox.pl/#organization" } }

To jest różnica między grafem a zbiorem niepowiązanych deklaracji: relacje łączą identyfikatory, nie napisy. Model, który widzi to samo @id w dziesięciu miejscach, widzi jedną encję z dziesięcioma powiązaniami. Model, który widzi dziesięć razy nazwę „Studio iFOX” w luźnych blokach — widzi dziesięć napisów.

Relacje atrybucyjne: pięć właściwości, które robią całą pracę

author / publisher — atrybucja treści własnych. Każdy artykuł, case study i raport w ekosystemie powinien wskazywać encję jako autora lub wydawcę — przez @id, nie przez sam napis z nazwą. To najprostsza i najczęściej pomijana relacja: treść „przecież wiadomo czyja” jest dla maszyny treścią niczyją.

subjectOf — odwrotność atrybucji: encja wskazuje materiały, których jest tematem. Idealna do spinania encji z dowodami opisanymi gdzie indziej — case study na webflux.pl, wzmianka w branżowym portalu, nagranie z konferencji:

{
  "@id": "https://studio.ifox.pl/#organization",
  "subjectOf": [
    { "@type": "Article", "@id": "https://webflux.pl/agentic-web/cyberflux-pl-jako-case-study-agent-readiness/#article" }
  ]
}

sameAs — spinanie tożsamości między domenami i profilami. Uwaga na semantykę: sameAs mówi „to jest ta sama encja”, nie „to jest powiązana encja”. Serwisy ekosystemu prowadzone przez ten sam podmiot to różne encje jednego właściciela — nie ta sama encja. Do tego służy para parentOrganization / memberOf:

{
  "@type": "Organization",
  "@id": "https://webflux.pl/#organization",
  "name": "WebFlux.pl",
  "parentOrganization": { "@id": "https://studio.ifox.pl/#organization" }
}

Pomylenie sameAs z parentOrganization to deklarowanie maszynom, że serwis edukacyjny i studio to dosłownie jeden byt — co przy pierwszej niespójności (inna nazwa, inny adres) podważa wiarygodność całego grafu.

isBasedOn — relacja, którą warto znać, bo obsługuje najsilniejszy typ dowodu z poprzedniego artykułu: niezależną replikację. Gdy ktoś osiąga wynik według publicznej wiedzy encji, opis tego przypadku może wskazać źródło metody:

{
  "@type": "Article",
  "headline": "bdaudyt.pl — co zobaczył agent na stronie, którą zbudował biegły rewident",
  "about": { "@type": "WebSite", "url": "https://bdaudyt.pl" },
  "isBasedOn": "https://webflux.pl/agent-readiness-czy-twoja-strona-jest-zrozumiala-dla-ai/",
  "author": { "@id": "https://studio.ifox.pl/#organization" }
}

isBasedOn w dokumentacji replikacji mówi maszynie dokładnie to, co replikacja dowodzi: ten wynik powstał na bazie tamtej wiedzy.

mentions / about — powiązania tematyczne: o czym treść jest (about — temat główny) i co wymienia (mentions — odniesienia). Porządkują konsumpcję: pomagają modelom łączyć materiały encji z pytaniami merytorycznymi ze strony A testu dwustronnego.

Wzorce dla trzech typów dowodów

Typologia z poprzedniego artykułu przekłada się na typy schema.org wprost.

Przed/po z metodologią — Article (lub TechArticle) z kompletem: author przez @id, about wskazujący przedmiot wdrożenia, datePublished, a w treści metryki z jednostkami. Schema nie zastąpi metodologii w tekście — sygnalizuje typ i atrybucję, sprawdzalność musi być w treści.

Benchmark — Dataset dla danych, Report lub Article dla opracowania, creator przez @id, measurementTechnique dla metody:

{
  "@type": "Dataset",
  "name": "Polski Raport AI-Readiness 2026",
  "description": "Wyniki badania 165 polskich stron własnym crawlerem. Średnia: 47,5/100.",
  "creator": { "@id": "https://studio.ifox.pl/#organization" },
  "measurementTechnique": "Agent-crawler w Go, punktacja sześciowarstwowa, metodologia opisana w raporcie",
  "datePublished": "2026-05-08"
}

Działający artefakt — SoftwareApplication lub WebApplication z provider / author przez @id i url prowadzącym do działającego narzędzia. Artefakt bez linku do użycia jest deklaracją o artefakcie.

Cztery błędy, które unieważniają graf

Błąd 1: encja bez @id albo z różnymi @id. Najczęstszy i najbardziej kosztowny. Każda strona generuje własny anonimowy blok Organization, wtyczki SEO dokładają swoje, a ta sama firma występuje w grafie jako pięć różnych obiektów o podobnych nazwach. Wynik: relacje nie sumują się do niczego. Diagnoza: wyszukać wszystkie bloki JSON-LD w ekosystemie i sprawdzić, czy encja ma jeden identyfikator.

Błąd 2: pusty lub bezm typowy JSON-LD. Blok danych strukturalnych bez zdefiniowanych typów — obecny, poprawny składniowo i informacyjnie martwy. To dokładnie ten błąd, który audyt sześciowarstwowy wykrywa jako niską wartość Structured Data mimo „obecności schema”: dane są, znaczenia nie ma. Gorsze niż brak bloku, bo sugeruje maszynom, że to wszystko, co encja ma do powiedzenia.

Błąd 3: schema niezgodna z treścią. Dane strukturalne deklarują coś, czego treść strony nie potwierdza — inne nazwy, inne relacje, dowody opisane w JSON-LD i nieistniejące w tekście. Modele czytają obie warstwy; rozjazd między nimi nie jest neutralny, jest sygnałem niewiarygodności. Zasada: schema opisuje treść, nigdy jej nie uzupełnia.

Błąd 4: sameAs jednostronne lub donikąd. Deklaracja tożsamości działa, gdy da się ją potwierdzić po drugiej stronie. sameAs wskazujący profil, który nie istnieje, nie wspomina encji albo nie odwzajemnia powiązania, jest ogniwem, którego nie da się domknąć. Między własnymi domenami powiązania powinny być wzajemne: studio wskazuje serwisy (subOrganization lub sameAs do właściwych węzłów), serwisy wskazują studio (parentOrganization).

Walidacja i kolejność wdrożenia

Narzędzia: validator.schema.org (poprawność składni i typów), test wyników z rozszerzonymi danymi Google (jak widzi to najważniejszy konsument), oraz — najprostsze i najbardziej pomijane — ręczne wyszukanie wszystkich bloków application/ld+json w źródłach stron ekosystemu i przeczytanie ich obok siebie. Większość błędów 1 i 4 widać gołym okiem przy tej lekturze.

Kolejność wdrożenia, od fundamentu:

1. Kanoniczny opis encji z @id na stronie głównej podmiotu — jeden, kompletny, z knowsAbout.
2. Ten sam @id w author / publisher / creator wszystkich treści własnych, na wszystkich domenach.
3. Struktura ekosystemu: parentOrganization / subOrganization między serwisami, wzajemnie.
4. subjectOf na encji — spięcie istniejących dowodów: case studies, raportów, wzmianek.
5. Wzorce typów dla dowodów: Dataset dla benchmarków, isBasedOn dla replikacji, SoftwareApplication dla narzędzi.

Punkty 1–3 to szkielet i warunek sensowności reszty. Punkty 4–5 to właściwy graf dowodów. Wdrażanie w odwrotnej kolejności — dekorowanie dowodów schemą bez stabilnej encji — produkuje dobrze opisane węzły niepodłączone do niczego.

W następnym artykule toru: cała teoria na jednym żywym przypadku — pięć dowodów, które modele czytały i których nie przypisywały, naprawa grafu krok po kroku i pomiar przed/po, dokumentowany publicznie.

Pojęcia ze słownika: Evidence Graph · Schema Density · AI Visibility Audit · Sześć warstw AI-readiness · AI-Readiness Score