Ontologia, taksonomia i model danych prostym językiem

Taksonomia porządkuje pojęcia w kategorie, model danych mówi, jak je zapisać, a ontologia wyjaśnia, co znaczą i jak są ze sobą powiązane. Graf wiedzy pokazuje konkretne fakty zapisane według takich zasad. Dla małej firmy to nie musi oznaczać nowego systemu. Pierwszą korzyścią bywa zwykłe uzgodnienie, czy „klient” oznacza osobę z CRM, firmę z faktury czy kupującego z zamówienia.

Ten tekst jest wejściem do filaru ontologii firmy. W każdym wyjaśnieniu użyję tego samego, hipotetycznego MŚP: firmy przyjmującej zamówienia na urządzenia i obsługującej je po sprzedaży. Dzięki temu łatwiej zobaczyć różnicę między pojęciem, kategorią, rekordem i działaniem.

Słownik: jakich słów używa firma?

Słownik pojęć zapisuje definicje używane przez ludzi. „Klient” może oznaczać firmę, z którą podpisano umowę. „Kontakt” to człowiek, z którym rozmawiamy. „Zamówienie potwierdzone” to takie, dla którego uzgodniono cenę i termin. Dobra definicja ma właściciela, przykłady i wyjątki. Jeśli działy nie zgadzają się co do znaczenia słowa, program nie rozstrzygnie sporu samym importem danych.

Zacznij właśnie tu, gdy dwa raporty o „liczbie klientów” dają różne wyniki. Nie potrzebujesz jeszcze bazy grafowej. Potrzebujesz odpowiedzi na pytanie: kogo liczymy i według jakiego zdarzenia?

Taksonomia: do której kategorii coś należy?

Taksonomia układa pojęcia w grupy. Firma może dzielić zgłoszenia na „serwis”, „reklamacja” i „pytanie o produkt”, a serwis na „awaria” oraz „przegląd”. To pomaga filtrować sprawy, przypisywać odpowiedzialność i przeszukiwać dokumenty. Kategoria „reklamacja” nie mówi jednak sama, jakiej dostawy dotyczy sprawa, jaki jest termin odpowiedzi ani kto zatwierdza zwrot.

W praktyce kategorie nie zawsze tworzą czyste drzewo. Zgłoszenie może dotyczyć jednocześnie awarii i reklamacji. Warto ustalić, czy klasyfikacja ma jeden obowiązkowy typ, czy kilka etykiet. Standard SKOS pokazuje, jak zapisywać relacje typu „pojęcie szersze”, „węższe” i „powiązane”; jego użycie nie jest warunkiem zrobienia pierwszej listy kategorii.

Model danych: w jakiej postaci to zapisujemy?

Model danych opisuje strukturę zapisu. W bazie może być tabela orders z polami order_id, customer_id i status, a osobna tabela customers. Diagram ERD pokazuje klucze i powiązania w takiej bazie. To niezbędne do budowy aplikacji, lecz nazwa kolumny status nie wyjaśnia pracownikowi, czy zamówienie zostało przyjęte, opłacone czy przekazane do produkcji.

Model danych może być relacyjny, dokumentowy lub grafowy. „Model” nie oznacza jednej technologii. Jeśli chcesz przejść od istniejących tabel do wspólnych pojęć między CRM i ERP, zobacz poradnik od ERD do ontologii.

Ontologia: co istnieje i co oznaczają relacje?

Ontologia określa typy obiektów, ich właściwości, relacje oraz istotne ograniczenia. W naszym przykładzie: klient składa zamówienie, zamówienie dotyczy produktu, serwis obsługuje urządzenie. Te czasowniki mają znaczenie. Relacja „serwis obsługuje urządzenie” nie znaczy jeszcze, że serwis „jest właścicielem urządzenia”.

Ontologia może też rozróżnić datę obiecaną klientowi od daty planowanej wewnętrznie. Może wskazać, że każde potwierdzone zamówienie musi mieć właściciela procesu. Sama definicja nie egzekwuje jednak reguły: aplikacja musi ją wdrożyć, a dane trzeba sprawdzić. Formalne narzędzia, takie jak OWL 2 i SHACL, pomagają opisywać pojęcia i walidować graf RDF, ale MŚP może zacząć od czytelnego modelu i testów w obecnych systemach.

Graf wiedzy: jakie są konkretne powiązania?

Ontologia mówi, że klient może złożyć zamówienie. Graf wiedzy zawiera już konkretny fakt: „Klient K17 złożył zamówienie Z52”, wraz ze źródłem i datą. Inny fakt łączy Z52 z urządzeniem U8. To pozwala przejść od urządzenia do zamówienia, klienta i zgłoszeń serwisowych. Graf jest użyteczny, gdy te ścieżki są ważniejsze niż pojedyncze rekordy.

Graf nie musi od razu żyć w specjalnej bazie. Gdy relacji jest mało i pytania są przewidywalne, SQL może wystarczyć. Gdy ścieżek i typów powiązań przybywa, warto sprawdzić ontologię i bazy grafowe dla MŚP. Odpowiedź zależy od zadania, danych, uprawnień i kosztu utrzymania.

Jeśli chcesz zobaczyć większy, konkretny model biznesowy, przejdź do pierwszego odcinka Katalogu ontologii dla MŚP: Klient 360. Pokazuje polskie encje i relacje oraz ich interaktywny graf.

A czym jest „graf kontekstu” dla agenta AI?

To nazwa używana dla wycinka faktów, relacji i historii potrzebnych do konkretnego zadania agenta. Przed przygotowaniem odpowiedzi o reklamacji agent może dostać dane klienta, właściwe zamówienie, obowiązującą wersję warunków i wcześniejsze decyzje. Kontekst nie jest synonimem całej ontologii: ontologia opisuje zasady, a kontekst zawiera potrzebne w danej chwili fakty. Nazwy te bywają używane różnie przez dostawców, więc w projekcie trzeba zapisać własną definicję. Inspiracją do takiego rozdzielenia jest przegląd pojęć Response42.

Agent nie powinien sam wybierać dowolnych rekordów tylko dlatego, że są powiązane. Aplikacja ma pobierać dane zgodnie z prawami użytkownika, zachować źródła i odrzucić nieaktualne wersje. Graf kontekstu może poprawić nawigację po danych, ale nie zastępuje kontroli dostępu i oceny poprawności odpowiedzi.

Jedno zamówienie w pięciu ujęciach

Ujęcie	Przykład	Do czego służy
Słownik	„Potwierdzone” = cena i termin zaakceptowane przez obie strony	Wspólna definicja
Taksonomia	Zgłoszenie → serwis → awaria	Grupowanie i wyszukiwanie
Model danych	orders.status, orders.customer_id	Poprawny zapis w aplikacji
Ontologia	Zamówienie dotyczy urządzenia; klient składa zamówienie	Znaczenie i reguły relacji
Graf wiedzy	K17 → Z52 → U8 → zgłoszenie S4	Odpowiedź o konkretnej sprawie

Nie trzeba wdrażać wszystkiego naraz. Jeśli problemem są sporne nazwy, zacznij od słownika. Jeśli pliki trudno znaleźć, uporządkuj kategorie. Jeśli raporty z kilku systemów przeczą sobie, przejdź do mapowania pojęć i źródeł. Jeśli agent ma odpowiadać na pytania o złożone zależności, przetestuj graf na ograniczonej próbce. Nazwij decyzję, którą chcesz poprawić, zanim nazwiesz narzędzie.

Jeżeli firma nie wie, które definicje i źródła są wiążące, następnym krokiem jest mapa danych i wiedzy. Uporządkowanie pojęć można włączyć do zakresu audytu i mapy danych, gdy jest potrzebne do konkretnego procesu.