Semantic Web i Linked Data. Poprawki i uzupełnienia

Chcę przedstawić fragment tej niedawno wydanej książki:

Modelowanie ontologiczne przedsiębiorstwa: metody i technologie [Tekst]: monografia / [S. W. Gorszkow, S. S. Kralin, O. I. Musztak i in.; redaktor odpowiedzialny S. W. Gorszkow]. — Jekaterynburg: Wyd. Ural Uniwersytetu, 2019. — 234 s.: il., tabl.; 20 cm. — Autorzy podani na odwrocie tyt. s. — Bibliografia na końcu rozdz. — ISBN 978-5-7996-2580-1: 200 egz.

Celem zamieszczenia tego fragmentu na Habra jest czwórka:

• Mało kto zdoła trzymać tę książkę w rękach, jeśli nie jest klientem szanowanego SergeIndex; na pewno nie jest dostępna w sprzedaży.
• W tekście wprowadzono poprawki (poniżej nie są one w żaden sposób wyróżnione) oraz dodano uzupełnienia, które nie są zbyt kompatybilne z formatem drukowanej monografii: aktualne przypisy (pod spoilerami) oraz hiperlącza.
• Chcę zgromadzić pytania i uwagi, aby wziąć je pod uwagę przy włączeniu tego tekstu w przetworzonej wersji do innych publikacji.
• Wielu zwolenników Semantic Web i Linked Data wciąż uważa, że ich krąg jest tak wąski głównie dlatego, że szerokiej publiczności wciąż dobrze nie wyjaśniono, jak wspaniale jest być zwolennikiem Semantic Web i Linked Data. Autor fragmentu, choć do tego kręgu należy, nie podziela tego zdania, ale mimo to czuje się zobowiązany do podjęcia jeszcze jednej próby.

Otóż

Semantic Web

Ewolucję Internetu można przedstawić w następujący sposób (lub mówić o jego segmentach, które formowały się w wskazanym poniżej porządku):

1. Dokumenty w internecie. Kluczowe technologie — Gopher, FTP itp.
   Internet jest globalną siecią wymiany lokalnych zasobów.
2. Internet dokumentów. Kluczowe technologie — HTML i HTTP.
   Charakter wystawionych zasobów uwzględnia cechy środowiska ich transmisji.
3. Dane w internecie. Kluczowe technologie — REST i SOAP API, XHR itp.
   Era aplikacji internetowych, konsumentami zasobów stają się nie tylko ludzie.
4. Internet danych. Kluczowe technologie — technologie Linked Data.
   Ten czwarty etap, przewidywany przez Bernersa-Lee, twórcę kluczowych technologii drugiego oraz dyrektora W3C, nazywa się Semantic Web; technologie Linked Data mają na celu uczynienie danych w sieci nie tylko czytelnymi dla maszyn, ale też „rozumianymi przez maszyny”.

Z dalszej lektury czytelnik zrozumie zgodność kluczowych pojęć drugiego i czwartego etapu:

• analogami URL są URI,
• analogiem HTML jest RDF,
• HTML-hiperłącza odpowiadają wpisom URI w dokumentach RDF.

Web Semantyczny to raczej systemowe spojrzenie na przyszłość internetu niż konkretny, spontaniczny lub lobbingowy trend, chociaż może uwzględniać i te ostatnie. Na przykład ważną cechą, która jest nazywana Web 2.0, jest 'tworzone przez użytkowników treści'. Umożliwia to, w szczególności, rekomendacja W3C 'Web Annotation Ontology' oraz takie przedsięwzięcie jak Solid.

Czy Semantic Web jest martwy?

Jeśli zrezygnować z nierealistycznych oczekiwań,sytuacja z semantycznym webem jest mniej więcej taka sama, jak z komunizmem w czasach rozwiniętego socjalizmu (a czy będzie przestrzegana wierność warunkowym przymierzeniom Illicha, niech każdy decyduje sam). Wyszukiwarki dość skutecznie przymuszają strony internetowe do korzystania z RDFa i JSON-LD oraz same wykorzystują technologie pokrewne do opisywanych poniżej (Google Knowledge Graph, Bing Knowledge Graph).

Ogólnie autor nie może powiedzieć, co przeszkadza większemu rozpowszechnieniu, ale może wypowiedzieć się na podstawie osobistych doświadczeń. Problemy, które mogłyby być rozwiązywane 'z pudełka' w warunkach wystąpienia SW, istnieją, choć nie są bardzo masowe. W związku z tym, ci, przed którymi te problemy stoją, nie mają środków przymusu wobec tych, którzy mogą zapewnić rozwiązanie, samodzielne zapewnienie rozwiązania przez tych ostatnich jest sprzeczne z ich modelami biznesowymi. Tak więc kontynuujemy parsowanie HTML i łączenie różnych API, jedno mniej wygodne od drugiego.

Jednak technologie Linked Data zyskały popularność również poza masowym webem; to im poświęcona jest ta książka. Obecnie społeczność Linked Data oczekuje, że te technologie zyskają jeszcze większą popularność dzięki potwierdzeniu (lub ogłoszeniu, jak kto woli) przez Gartnera takich trendów jak Knowledge Graphs i Data Fabric. Chciałoby się wierzyć, że sukces odniosą nie 'rowerowe' realizacje tych koncepcji, ale te, które mają związek z omawianymi poniżej standardami W3C.

Linked Data

Berners-Lee definiował Linked Data jako 'dobrze zrobiony' semantyczny web: zbiór podejść i technologii, które pozwalają osiągnąć jego końcowe cele. Podstawowe zasady Linked Data Berners-Lee wyróżniał następujące.

Zasada 1. Używanie URI do nazywania bytów.

URI są globalnymi identyfikatorami bytów w przeciwieństwie do lokalnych identyfikatorów ciągów rekordów. Z czasem najlepsze wyrażenie tej zasady znalazło się w haśle Google Knowledge Graph „rzeczy, a nie ciągi».

Zasada 2. Użycie URI w schemacie HTTP, aby można je było dereferencjonować.

Odwołując się do URI, powinno być możliwe uzyskanie oznaczanego, stojącego za tym oznaczającym (tutaj analogia z nazwą operatora „*” w C); dokładniej, uzyskanie pewnego wyobrażenia o tym oznaczanym — w zależności od wartości nagłówka HTTP Accept:. Być może, z nadejściem epoki AR/VR będzie można uzyskać sam zasób, jak na razie prawdopodobnie to będzie dokument RDF, będący wynikiem wykonania zapytania SPARQL DESCRIBE.

Zasada 3. Użycie standardów W3C — w szczególności RDF(S) i SPARQL — przy dereferencjonowaniu URI.

Te oddzielne „warstwy” stosu technologii Linked Data, znane również jako Semantic Web Layer Cake, zostaną opisane dalej.

Zasada 4. Użycie przy opisie bytów odniesień do innych URI.

RDF pozwala ograniczyć się do werbalnego opisu zasobu w języku naturalnym, a czwarta zasada wzywa do tego, aby tego nie robić. Przy powszechnym przestrzeganiu pierwszej zasady możliwe jest odniesienie się do innych, w tym „obcych”, każąc danym stać się powiązanymi. W rzeczywistości niemal nieuchronne jest użycie URI, które są wymienione w słowniku RDFS.

RDF

RDF (Resource Description Framework) — formalizm opisu wzajemnie powiązanych bytów.

O bytach i ich wzajemnych relacjach sformułowane są twierdzenia w postaci „podmiot-predykat-obiekt”, nazywane tripletem. W najprostszej postaci podmiotem, predykatem i obiektem mogą być URI. Ten sam URI może znajdować się w różnych triplecie w różnych pozycjach: być podmiotem, predykatem i obiektem; tym samym trójce tworzą swego rodzaju graf, nazywany grafem RDF.

Podmioty i obiekty mogą być nie tylko URI, ale także tzw. pustymi węzłami, a obiekty mogą być również literałami. Literały to instancje typów prymitywnych, składające się z reprezentacji ciągowej i wskazania typu.

Przykłady zapisu literałów (w składni Turtle, o której później): "5.0"^^xsd:float i "five"^^xsd:string. Literały z typem rdf:langString mogą być dodatkowo wyposażone w znacznik językowy, w Turtle zapisuje się to tak: "five"@en i "pięć"@ru.

Puste węzły to "anonimowe" zasoby bez globalnych identyfikatorów, o których jednak można formułować stwierdzenia; rodzaj egzystycznych zmiennych.

Zatem (w tym leży cała istota RDF):

• subiekt to URI lub pusty węzeł,
• predykat to URI,
• obiekt to URI, pusty węzeł lub literał.

Dlaczego predykaty nie mogą być pustymi węzłami?

Prawdopodobną przyczyną jest chęć nieformalnego rozumienia i tłumaczenia na język logiki predykatów pierwszego rzędu trójek s p o jako coś w rodzaju , gdzie — predykat, i — stałe. Ślady takiego zrozumienia można znaleźć w dokumencie „LBase: Semantics for Languages of the Semantic Web”, który ma status notatki grupy roboczej W3C. Przy takim rozumieniu trójka s p [], gdzie [] — pusty węzeł, zostanie przetłumaczona jako , gdzie — zmienna, ale jak wtedy przetłumaczyć s [] o? Имеющий статус рекомендации W3C документ «RDF 1.1 Semantics” oferuje inny sposób tłumaczenia, jednak możliwość predykatów jako pustych węzłów wciąż nie jest rozważana.

Przy czym, Manu Sporni zezwolili.

RDF to abstrakcyjny model. RDF może być zapisane (serializowane) w różnych składniach: RDF/XML, Turtle (najbardziej czytelny dla ludzi), JSON-LD, HDT (binarne).

Ten sam RDF może być serializowany w RDF/XML na różne sposoby, dlatego na przykład, uzyskany XML nie ma sensu walidować za pomocą XSD ani próbować wyodrębniać dane za pomocą XPath. Podobnie JSON-LD raczej nie spełni pragnienia przeciętnego programisty Javascript do pracy z RDF z wykorzystaniem notacji kropkowej i kwadratowej (chociaż JSON-LD zmierza w tym kierunku, oferując mechanizm framingu).

Większość składni oferuje sposoby skracania długich URI. Na przykład, deklaracja @prefix rdf: w Turtle pozwoli później pisać zamiast <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> po prostu rdf:type.

RDFS

RDFS (RDF Schema) to podstawowy słownik modelowania, wprowadza pojęcia właściwości i klasy oraz takie właściwości jak rdf:type, rdfs:subClassOf, rdfs:domain i rdfs:range. Dzięki słownikowi RDFS można zapisać na przykład następujące poprawne stwierdzenia:

rdf:type         rdf:type         rdf:Property .
rdf:Property     rdf:type         rdfs:Class .
rdfs:Class       rdfs:subClassOf  rdfs:Resource .
rdfs:subClassOf  rdfs:domain      rdfs:Class .
rdfs:domain      rdfs:domain      rdf:Property .
rdfs:domain      rdfs:range       rdfs:Class .
rdfs:label       rdfs:range       rdfs:Literal .

RDFS jest słownikiem opisu i modelowania, ale nie jest językiem ograniczeń (choć oficjalna specyfikacja i pozostawia możliwość takiego użycia). Słowo „Schema” nie powinno być rozumiane w tym samym sensie co w wyrażeniu „XML Schema”. Na przykład, :author rdfs:range foaf:Person oznacza, że rdf:type wszystkich wartości właściwości :author — foaf:Person, ale nie oznacza, że należy o tym mówić z góry.

SPARQL

SPARQL (SPARQL Protocol and RDF Query Language) — język zapytań do danych RDF. W najprostszym przypadku zapytanie SPARQL stanowi zestaw wzorców, z którymi porównywane są trójki w badanym grafie. Wzorce mogą zawierać zmienne w pozycjach podmiotów, predykatów i obiektów.

Zapytanie zwróci takie wartości zmiennych, dla których podstawienie ich do wzorców może dać podgraf badanego grafu RDF (podzbiór jego trójek). Zmienne o tej samej nazwie w różnych wzorcach trójek muszą mieć jednocześnie te same wartości.

Na przykład, na powyższym zestawie siedmiu aksjomatów RDFS następujące zapytanie zwróci rdfs:domain i rdfs:range jako wartości ?s i ?p odpowiednio:

SELECT * WHERE {
 ?s ?p rdfs:Class .
 ?p ?p rdf:Property .
}

Warto zauważyć, że SPARQL jest deklaratywny i nie jest językiem opisu przeszukiwania grafu (chociaż niektóre przechowalnie RDF oferują sposoby na modyfikację planu wykonania zapytania). Dlatego niektóre standardowe zadania grafowe, takie jak wyszukiwanie najkrótszej ścieżki, nie mogą być rozwiązane w SPARQL, w tym przy użyciu mechanizmu property paths (ale znowu, niektóre przechowalnie RDF oferują specjalne rozszerzenia do rozwiązania tych zadań).

SPARQL nie zakłada otwartości świata i podąża za podejściem „negacja jako porażka”, w nim możliwe są takie konstrukcje jak FILTER NOT EXISTS {…}. Rozproszenie danych uwzględnia się za pomocą mechanizmu zapytania federacyjne.

Serwis SPARQL — zasób RDF zdolny do przetwarzania zapytań SPARQL — nie ma bezpośrednich odpowiedników z drugiego etapu (zob. początek tego paragrafu). Można go porównać do bazy danych, na podstawie zawartości której generowane były strony HTML, ale dostępnej na zewnątrz. Serwis SPARQL jest raczej analogią do interfejsu API z trzeciego etapu, jednak z dwoma głównymi różnicami. Po pierwsze, istnieje możliwość łączenia kilku „atomowych” zapytań w jedno (co uważa się za kluczową cechę GraphQL), po drugie, taki interfejs API jest całkowicie autodokumentujący (czego starał się osiągnąć HATEOAS).

Uwagi polemiczne

RDF — sposób publikacji danych w sieci, dlatego należy traktować magazyny RDF jako dokumentowe bazy danych. Prawda, że RDF to graf, a nie drzewo, więc zyskały również charakter grafowy. Zadziwiające, że w ogóle powstały. Kto by pomyślał, że znajdą się mądrzy ludzie, którzy zrealizują blank nodes. U Codda się to nie udało. Nie wyszło..

Są też mniej funkcjonalne sposoby organizacji dostępu do danych RDF, na przykład, Linked Data Fragments (LDF) oraz Linked Data Platform (LDP).

OWL

OWL (Web Ontology Language) — formalizm reprezentacji wiedzy, syntaktyczna wersja logiki opisowej (później poprawniej mówić OWL 2, pierwsza wersja OWL była oparta na ).

Konceptom logik opisowych w OWL odpowiadają klasy, rolom — właściwości, indywidua zachowują swoje wcześniejsze nazwy. Aksjomaty nazywane są również aksjomatami.

Na przykład, w tzw. szyfrowaniu manchesterskim zapisywanie OWL już znanej nam aksjomaty będzie zapisane w ten sposób:

Class: Human
Class: Parent
   EquivalentClass: Human and (inverse hasParent) some Human
ObjectProperty: hasParent

Istnieją także inne składnie do zapisu OWL, na przykład, składnia funkcjonalna, używana w oficjalnej specyfikacji, oraz OWL/XML.Oprócz tego, OWL może być serializowany w abstrakcyjnej składni RDF i następnie — w dowolnej z konkretnych składni.

OWL w odniesieniu do RDF występuje w podwójnym odniesieniu. Z jednej strony, można go traktować jako pewien słownik, rozszerzający RDFS. Z drugiej strony, to bardziej potężny formalizm, dla którego RDF jest jedynie formatem serializacji. Nie wszystkie elementarne konstrukcje OWL można zapisać za pomocą pojedynczego RDF-triple.

W zależności od tego, jakie podzbiory konstrukcji OWL są dozwolone, mówi się o tzw. profilach OWL.Standardowe i najbardziej znane to OWL EL, OWL RL i OWL QL. Wybór profilu wpływa na złożoność obliczeniową typowych zadań. Pełny zestaw konstrukcji OWL, odpowiadający , nazywa się OWL DL. Czasem mówi się także o OWL Full, w którym konstrukcje OWL można stosować z pełną swobodą, charakterystyczną dla RDF, bez semantycznych i obliczeniowych ograniczeń. Na przykład, coś może być zarówno klasą, jak i właściwością. OWL Full jest nierozwiązywalny.

Kluczowe zasady wnioskowania w OWL to przyjęcie założenia otwartego świata (open world assumption, OWA) oraz odmowa przyjęcia założenia unikalności nazw (unique name assumption, UNA). Poniżej zobaczymy, do czego mogą prowadzić te zasady, i zapoznamy się z niektórymi konstrukcjami OWL.

Niech ontologia zawiera następujący fragment (w składni manchesterskiej):

Klasa: manyChildren
   Równoważne: Człowiek, który maDziecko min 3
Indywidualność: John
   Typy: Człowiek
   Fakty: maDziecko Alice, maDziecko Bob, maDziecko Carol

Czy z powyższego wynika, że John ma wiele dzieci? Odstąpienie od UNA sprawi, że silnik wnioskowania odpowie na to pytanie negatywnie, ponieważ Alice i Bob mogą być tą samą osobą. Aby wnioskowanie miało miejsce, należy dodać taką aksjomat:

RóżneOsoby: Alice, Bob, Carol, John

Niech teraz fragment ontologii ma następujący kształt (John ogłoszony jako mający wiele dzieci, ale wskazano tylko dwoje):

Klasa: manyChildren
   Równoważne: Człowiek, który maDziecko min 3
Indywidualność: John
   Typy: Człowiek, manyChildren
   Fakty: maDziecko Alice, maDziecko Bob
RóżneOsoby: Alice, Bob, Carol, John

Czy ta ontologia będzie sprzeczna (co można interpretować jako dowód nieważności danych)? Przyjęcie OWA sprawi, że silnik wnioskowania odpowie negatywnie: «gdzieś» jeszcze (w innej ontologii) może być powiedziane, że Carol również jest dzieckiem Johna.

Aby wykluczyć tę możliwość, dodajemy nowy fakt o Johnie:

Indywidualność: John
   Fakty: maDziecko Alice, maDziecko Bob, nie maDziecko Carol

Aby wykluczyć pojawienie się innych dzieci, powiedzmy, że wszystkie wartości właściwości «mieć dziecko» — to ludzie, których mamy w sumie czterech:

WłaściwośćObiektowa: maDziecko
   Zakres: Człowiek
   Cechy: Irrefleksyjne
Klasa: Człowiek
Równoważne: { Alice, Bill, Carol, John }

Teraz ontologia stanie się sprzeczna, o czym silnik wnioskowania nie zawaha się poinformować. Ostatnią z aksjomatów w pewnym sensie «zamknęliśmy» świat, i zwróć uwagę, w jaki sposób wykluczyliśmy możliwość, że John jest jednym z siebie.

Łączenie danych przedsiębiorstwa

Zestaw podejść i technologii Linked Data pierwotnie przeznaczony był do publikacji danych w sieci. Ich wykorzystanie w środowisku korporacyjnym napotyka szereg trudności.

Na przykład, w zamkniętym środowisku korporacyjnym siła dedukcyjna OWL, oparta na przyjęciu OWA i odstąpieniu od UNA — decyzjach uwarunkowanych otwartym i rozproszonym charakterem internetu — okazuje się zbyt słaba. I tutaj możliwe są następujące wyjścia.

• Nadanie OWL semantyki, co sugeruje odstąpienie od OWA i przyjęcie UNA, wdrożenie odpowiedniego silnika wnioskowania. — Tą drogą idzie RDF-magazyn Stardog.
• Rezygnacja z możliwości dedukcyjnych OWL na rzecz silników reguł. — Stardog wspiera SWRL; Jena i GraphDB oferują własne języki reguł.
• Rezygnacja z możliwości dedukcyjnych OWL, wykorzystanie do modelowania odpowiedniego podzbioru, bliskiego RDFS. — Zobacz więcej na ten temat dalej.

Inny problem to większa uwaga, jaką w świecie korporacyjnym można poświęcić problemom jakości danych oraz brak w stosie Linked Data narzędzi do walidacji danych. Wyjścia są następujące.

• Ponownie, wykorzystanie do walidacji konstrukcji OWL z semantyką zamkniętego świata i unikalności nazw przy odpowiednim silniku wnioskowania.
• Użycie SHACL, standaryzowanego już po tym, jak lista warstw Semantic Web Layer Cake została ustalona (zresztą, może być też używany jako silnik reguł), lub ShEx.
• Świadomość, że wszystko ostatecznie dokonuje się za pomocą zapytań SPARQL, tworzenie własnego prostego mechanizmu walidacji danych z ich wykorzystaniem.

Jednakże nawet całkowita rezygnacja z możliwości dedukcyjnych i narzędzi walidacji pozostawia stos Linked Data bezkonkurencyjnym w zadaniach, które są krajobrazowo podobne do otwartego i rozproszonego webu — w zadaniach integracji danych.

Co ze zwykłym systemem informacyjnym w firmie?

To możliwe, ale należy oczywiście mieć świadomość, jakie dokładnie problemy muszą rozwiązać odpowiednie technologie. Opiszę tutaj typową reakcję uczestników rozwoju, aby pokazać, jak wygląda ten technologiczny stos z perspektywy konwencjonalnego IT. Trochę przypomina to przypowieść o słoniu:

• Analityk biznesowy: RDF to coś w rodzaju bezpośrednio przechowywanej modelu logicznego.
• Analityk systemowy: RDF to jak EAV, tylko z mnóstwem indeksów i wygodnym językiem zapytań.
• Programista: no, to wszystko w duchu koncepcji rich model i low code, czytałem ostatnio o tym.
• Kierownik projektu: tak to jest collapsing the stack!

Praktyka pokazuje, że stos najczęściej używany jest w zadaniach związanych z rozproszeniem i heterogenicznością danych, na przykład przy budowie systemów klasy MDM (Master Data Management) lub DWH (Data Warehouse). Takie zadania występują w każdej branży.

Jeśli chodzi o zastosowania z branżową specyfiką, obecnie technologie Linked Data są najbardziej popularne w następujących branżach.

• technologie biomedyczne (gdzie ich popularność jest ponoć związana z złożonością tematu);

aktualny

W "Punkcie Wrzenia" niedawno odbyła się konferencja "Integracja ontologii. Od teorii do praktycznego zastosowania».

• produkcja i eksploatacja skomplikowanych produktów (wielkie budownictwo maszynowe, wydobycie ropy i gazu; najczęściej mowa o standardzie ISO 15926);

aktualny

Również tutaj przyczyną jest złożoność tematu, kiedy, na przykład, na etapie upstream, mówiąc o branży naftowej i gazowej, zwykła bilansowanie powinna mieć pewne funkcje CAD.

W 2008 roku odbyła się zorganizowana przez Chevron reprezentacyjna konferencja konferencja.

ISO 15926 w końcu okazał się zbyt skomplikowany dla branży naftowej i gazowej (i ledwie znalazł zastosowanie w budownictwie maszynowym). Oprócz Statoil (Equinor), która w Norwegii wokół niego zbudowała całą ekosystem. Inni próbują stworzyć coś własnego. Na przykład, podobno krajowe Ministerstwo Energii planuje zająć się stworzeniem "koncepcyjnego modelu ontologicznego sektora energetycznego", podobnego, przypuszczalnie, stworzonemu dla energetyki.

• instytucje finansowe (nawet XBRL można traktować jako pewien hybrydowy SDMX i ontologię RDF Data Cube);

aktualny

LinkedIn na początku roku aktywnie wysyłał autorowi oferty pracy z prawie wszystkich gigantów branży finansowej, których zna z serialu "Suits": Goldman Sachs, JPMorgan Chase i/lub Morgan Stanley, Wells Fargo, SWIFT/Visa/Mastercard, Bank of America, Citigroup, Fed, Deutsche Bank… Prawdopodobnie wszyscy szukali kogoś, kogo można by wysłać na Konferencję Knowledge Graph. Udało się to wielu: instytucje finansowe zająły cały poranek pierwszego dnia.

Na HeadHunterze natomiast coś interesującego pojawiło się tylko w Sberbanku, chodziło o „EAV-magazyn z danymi w modelu podobnym do RDF”.

Prawdopodobnie różnica w stopniu akceptacji odpowiednich technologii przez krajowe i zachodnie instytucje finansowe wynika z transnarodowego charakteru ich działalności. Prawdopodobnie integracja przez granice państwowe wymaga jakościowo różnych rozwiązań organizacyjnych i technicznych.

• systemy pytanie-odpowiedź, mające zastosowanie komercyjne (IBM Watson, Apple Siri, Google Knowledge Graph);

aktualny

A propos, twórca Siri, Thomas Gruber, jest autorem tego samego określenia ontologii (w znaczeniu IT) jako "specyfikacji konceptualizacji". Moim zdaniem, zmiana kolejności słów w tej definicji nie zmienia jej znaczenia, co być może świadczy o tym, że po prostu go nie ma.

• publikacja danych strukturalnych (z dużym uzasadnieniem można to już odnieść do Linked Open Data).

aktualny

Wielcy miłośnicy Linked Data — tzw. GLAM: Galerie, Biblioteki, Archiwa i Muzea. Wystarczy powiedzieć, że na zastąpienie MARC21 Biblioteka Kongresu promuje BIBFRAME, który daje podstawę na przyszłość opisu bibliograficznego i, oczywiście, opiera się na RDF.

Często jako przykład udanego projektu w dziedzinie Linked Open Data podaje się Wikidata — swoistą maszynowo czytelną wersję Wikipedii, której zawartość, w przeciwieństwie do DBPedia, nie jest generowana przez import z infoboksów artykułów, lecz tworzona mniej więcej ręcznie (a następnie staje się źródłem informacji dla tych samych infoboksów).

Zalecamy również do zapoznania się lista użytkowników magazynu RDF Stardog na stronie Stardog w sekcji „Klienci”.

Cokolwiek to jest, w badaniach Gartnera „Hype Cycle for Emerging Technologies” z 2016 roku „Zarządzanie taksonomią i ontologią przedsiębiorstw” umieszczono w połowie opadania w dolinę rozczarowania z perspektywą wyjścia na „płaskowyż wydajności” nie wcześniej niż za 10 lat.

Łączenie danych przedsiębiorstwa

Prognozy, prognozy, prognozy…

Z historycznego punktu widzenia zestawiałem w poniższej tabeli prognozy Gartnera z różnych lat dotyczące interesujących nas technologii.

Jednak już w „Hype Cycle…” z 2018 roku pojawił się inny rosnący trend — Grafy wiedzy. Nastąpiła pewna reinkarnacja: grafowe bazy danych, na których skupiło się zainteresowanie użytkowników i siły deweloperów, pod wpływem potrzeb pierwszych i przyzwyczajeń drugich zaczęły zyskiwać kształt i pozycjonowanie swoich poprzedników-konkurentów.

Praktycznie każda grafowa baza danych teraz ogłasza się odpowiednią platformą do budowy korporacyjnego "grafu wiedzy" ("linked data" czasami zastępowane jest przez "connected data"), ale na ile takie roszczenia są uzasadnione?

Bazy danych grafowych wciąż są asemantyczne, a dane w grafowej bazie danych to wciąż ten sam silo z danymi. Identyfikatory tekstowe zamiast URI utrudniają integrację dwóch baz danych grafowych, podczas gdy integracja dwóch magazynów RDF często sprowadza się jedynie do połączenia dwóch grafów RDF. Innym aspektem asemantyczności jest nierefleksyjność modelu LPG, co komplikuje zarządzanie metadanymi przy użyciu tej samej platformy.

Ostatecznie, grafowe bazy danych nie posiadają silników wnioskowania i silników reguł. Wyniki działania takich silników mogą być odtworzone przez skomplikowanie zapytań, ale jest to możliwe nawet w SQL.

Jednak czołowe magazyny RDF nie mają trudności w obsłudze modelu LPG. Najbardziej renomowanym podejściem jest to zaproponowane niegdyś w Blazegraph: model RDF*, łączący RDF i LPG.

Dowiedz się więcej

Więcej na temat wsparcia modeli LPG w magazynach RDF można przeczytać w poprzednim artykule na Habrze: „Co się teraz dzieje z magazynami RDF”. Mam nadzieję, że o Knowledge Graphs i Data Fabric zostanie kiedyś napisana osobna статья. Ostatnia część, jak łatwo zrozumieć, była pisana w pośpiechu, a mimo upływu pół roku z tymi koncepcjami wcale nie jest dużo jaśniej.

Literatura

1. Halpin, H., Monnin, A. (red.) (2014). Philosophical Engineering: Toward a Philosophy of the Web
2. Allemang, D., Hendler, J. (2011) Semantic Web for the Working Ontologist (2 wyd.)
3. Staab, S., Studer, R. (red.) (2009) Handbook on Ontologies (2 wyd.)
4. Wood, D. (red.). (2011) Linking Enterprise Data
5. Keet, M. (2018) An Introduction to Ontology Engineering

Źródło: habr.com