Chciałbym zaprezentować społeczeństwu fragment tej niedawno wydanej książki:
Modelowanie ontologiczne przedsiębiorstwa: metody i technologie [Tekst]: monografia / [S. W. Gorszkow, S. S. Kralin, O. I. Mushtak i inni; redaktor naczelny S.V. Gorszkow]. - Jekaterynburg: Wydawnictwo Uniwersytetu Ural, 2019. - 234 s.: il., tabela; 20 cm - Autor. wskazany na plecach. Z. — Bibliografia na końcu rozdz. — ISBN 978-5-7996-2580-1: 200 egzemplarzy.
Cel umieszczenia tego fragmentu na Habré jest czterokrotny:
- Jest mało prawdopodobne, że ktokolwiek będzie mógł trzymać tę książkę w swoich rękach, jeśli nie jest szanowanym klientem ; Na pewno nie jest w sprzedaży.
- W tekście dokonano poprawek (nie są one wyróżnione poniżej) oraz uzupełnień, które nie są zbyt zgodne z formatem monografii drukowanej: przypisy tematyczne (pod spoilerami) i hiperłącza.
- Chcę zbieraj pytania i komentarze, aby uwzględnić je przy włączaniu tego tekstu w zmienionej formie do innych publikacji.
- Wielu zwolenników sieci semantycznej i powiązanych danych nadal uważa, że ich krąg jest tak wąski, głównie dlatego, że ogółowi społeczeństwa nie wyjaśniono jeszcze właściwie, jak wspaniale jest być zwolennikiem sieci semantycznej i powiązanych danych. Autor fragmentu, choć należy do tego kręgu, nie podziela tej opinii, niemniej jednak czuje się zobowiązany do podjęcia kolejnej próby.
W ten sposób
Semantic Web
Ewolucję Internetu można przedstawić następująco (lub porozmawiać o jego segmentach, które ukształtowały się w kolejności wskazanej poniżej):
- Dokumenty w Internecie. Kluczowe technologie - Gopher, FTP itp.
Internet jest globalną siecią wymiany lokalnych zasobów. - Dokumenty internetowe. Kluczowe technologie to HTML i HTTP.
Charakter odsłoniętych zasobów uwzględnia charakterystykę ich medium transmisyjnego. - Dane internetowe. Kluczowe technologie - REST i SOAP API, XHR itp.
W epoce aplikacji internetowych nie tylko ludzie stają się konsumentami zasobów. - Dane internetowe. Kluczowe technologie to technologie Linked Data.
Ten czwarty etap, przewidziany przez Bernersa-Lee, twórcę drugiej podstawowej technologii i dyrektora W3C, nazywany jest siecią semantyczną; Technologie Linked Data zaprojektowano tak, aby dane w Internecie były nie tylko czytelne dla maszyn, ale także „zrozumiałe dla maszyn”.
Z tego, co następuje, czytelnik zrozumie zgodność pomiędzy kluczowymi koncepcjami drugiego i czwartego etapu:
- Adresy URL są analogiczne do identyfikatorów URI,
- analogiem HTML jest RDF,
- Hiperłącza HTML są podobne do wystąpień URI w dokumentach RDF.
Sieć semantyczna jest bardziej systemową wizją przyszłości Internetu niż konkretnym trendem spontanicznym czy lobbowanym, choć może te ostatnie uwzględniać. Na przykład za ważną cechę tak zwanego Web 2.0 uważa się „treści generowane przez użytkowników”. W szczególności wzywa się do uwzględnienia zalecenia W3C: „„i takie przedsięwzięcie jak .
Czy sieć semantyczna umarła?
Jeśli odmówisz , sytuacja z siecią semantyczną jest mniej więcej taka sama jak z komunizmem w czasach rozwiniętego socjalizmu (a czy przestrzegana jest wierność warunkowym nakazom Iljicza, niech każdy zdecyduje sam). Wyszukiwarki zmuszają strony internetowe do korzystania z RDFa i JSON-LD, a same korzystają z technologii pokrewnych opisanym poniżej (Google Knowledge Graph, Bing Knowledge Graph).
Ogólnie rzecz biorąc, autor nie jest w stanie powiedzieć, co stoi na przeszkodzie większemu rozprzestrzenianiu się, ale może wypowiadać się na podstawie własnego doświadczenia. Istnieją problemy, które można rozwiązać „od razu po wyjęciu z pudełka” w warunkach ofensywy SW, choć nie są one zbyt powszechne. W rezultacie ci, którzy stoją przed tymi zadaniami, nie mają możliwości stosowania przymusu wobec tych, którzy są w stanie zapewnić rozwiązanie, a samodzielne dostarczenie rozwiązania przez tych ostatnich jest sprzeczne z ich modelami biznesowymi. Kontynuujemy więc analizowanie kodu HTML i sklejanie różnych interfejsów API, coraz bardziej beznadziejnie.
Jednakże technologie Linked Data rozprzestrzeniły się poza główny nurt Internetu; Książka właściwie jest poświęcona tym aplikacjom. Obecnie społeczność Linked Data spodziewa się, że technologie te staną się jeszcze bardziej powszechne dzięki rejestrowaniu (lub ogłaszaniu przez Gartnera, jak kto woli) takich trendów jak: Wykresy wiedzy и Tkanina danych. Chciałbym wierzyć, że sukcesem nie będą „rowerowe” wdrożenia tych koncepcji, ale te związane ze standardami W3C omówione poniżej.
Połączone dane
Berners-Lee zdefiniował Linked Data jako sieć semantyczną „zrobioną dobrze”: zestaw podejść i technologii, które pozwalają jej osiągnąć ostateczne cele. Podstawowe zasady Linked Data Berners-Lee następujące.
Zasada 1. Używanie identyfikatorów URI do nazywania jednostek.
Identyfikatory URI to globalne identyfikatory jednostek, w przeciwieństwie do lokalnych identyfikatorów ciągu dla wpisów. Następnie zasadę tę najlepiej wyraziło hasło Grafu Wiedzy Google „".
Zasada 2. Używanie identyfikatorów URI w schemacie HTTP, aby można było je usunąć.
Odnosząc się do identyfikatora URI, powinno być możliwe uzyskanie znaku znajdującego się za tym znacznikiem (analogia z nazwą operatora „jest tutaj jasna).*" w C); dokładniej, aby uzyskać jakąś reprezentację tego oznaczenia - w zależności od wartości nagłówka HTTP Accept:. Być może wraz z nadejściem ery AR/VR możliwe będzie pozyskanie samego zasobu, jednak na razie najprawdopodobniej będzie to dokument RDF, będący efektem wykonania zapytania SPARQL DESCRIBE.
Zasada 3. Stosowanie standardów W3C - przede wszystkim RDF(S) i SPARQL - w szczególności podczas wyłuskiwania identyfikatorów URI.
Te poszczególne „warstwy” stosu technologii Linked Data, znane również jako , zostanie opisane poniżej.
Zasada 4. Użycie odniesień do innych identyfikatorów URI podczas opisywania jednostek.
RDF pozwala ograniczyć się do werbalnego opisu zasobu w języku naturalnym, a czwarta zasada nakazuje tego nie robić. Przy powszechnym przestrzeganiu pierwszej zasady możliwe staje się przy opisie zasobu odwoływanie się do innych, w tym także „obcych”, dlatego dane nazywa się powiązanymi. W rzeczywistości używanie identyfikatorów URI wymienionych w słowniku RDFS jest prawie nieuniknione.
RDF
(Resource Opis Framework) to formalizm służący do opisywania powiązanych ze sobą bytów.
Instrukcje typu „podmiot-orzeczenie-obiekt”, zwane trójkami, tworzone są na temat bytów i ich relacji. W najprostszym przypadku podmiot, predykat i obiekt są identyfikatorami URI. Ten sam identyfikator URI może znajdować się na różnych pozycjach w różnych trójkach: być podmiotem, orzeczeniem i dopełnieniem; Zatem trojaczki tworzą rodzaj wykresu zwanego wykresem RDF.
Podmiotami i obiektami mogą być nie tylko URI, ale także tzw puste węzły, i obiekty też mogą być literały. Literały są instancjami typów pierwotnych składającymi się z reprezentacji łańcuchowej i wskazania typu.
Przykłady pisania literałów (w składni Turtle’a, więcej o tym poniżej): "5.0"^^xsd:float и "five"^^xsd:string. Literały z typem rdf:langString może być również wyposażony w znacznik języka; w Turtle jest to zapisane w ten sposób: "five"@en и "пять"@ru.
Puste węzły to zasoby „anonimowe” pozbawione globalnych identyfikatorów, o których można jednak wypowiadać się; rodzaj zmiennych egzystencjalnych.
Zatem (właściwie to jest cały sens RDF):
- podmiotem jest URI lub pusty węzeł,
- predykatem jest URI,
- obiekt jest identyfikatorem URI, pustym węzłem lub literałem.
Dlaczego predykaty nie mogą być pustymi węzłami?
Prawdopodobną przyczyną jest chęć nieformalnego zrozumienia i przetłumaczenia trójki na język logiki predykatów pierwszego rzędu s p o jak coś takiego 
Gdzie - orzeczenie, и - stałe. Ślady tego zrozumienia znajdują się w dokumencie „", który ma status notatki grupy roboczej W3C. Z tym zrozumieniem, trójka s p []Gdzie [] - pusty węzeł, zostanie przetłumaczony jako Gdzie - zmienna, ale jak wtedy przetłumaczyć s [] o? Dokument ze statusem rekomendacji W3C „” oferuje inną metodę tłumaczenia, ale nadal nie uwzględnia możliwości, że predykaty są pustymi węzłami.
Jednakże Manu Sporni .
RDF jest modelem abstrakcyjnym. RDF można zapisać (serializować) w różnych składniach: , (najbardziej czytelny dla człowieka), , (dwójkowy).
Ten sam plik RDF można serializować do formatu RDF/XML na różne sposoby, więc na przykład nie ma sensu sprawdzanie poprawności wynikowego kodu XML za pomocą XSD lub próba wyodrębnienia danych za pomocą XPath. Podobnie jest mało prawdopodobne, aby JSON-LD zaspokoił chęć przeciętnego programisty Javascript do pracy z RDF przy użyciu notacji JavaScript z kropkami i nawiasami kwadratowymi (chociaż JSON-LD podąża w tym kierunku, oferując mechanizm ).
Większość składni oferuje sposoby skracania długich identyfikatorów URI. Na przykład reklama @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> w Turtle pozwoli ci zamiast tego pisać <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> po prostu rdf:type.
RDFS
(Schemat RDF) – podstawowe słownictwo związane z modelowaniem, wprowadza pojęcia właściwości i klasy oraz właściwości takie jak rdf:type, rdfs:subClassOf, rdfs:domain и rdfs:range. Używając na przykład słownika RDFS, można zapisać następujące prawidłowe wyrażenia:
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 to słownik opisu i modelowania, ale nie jest językiem ograniczeń (chociaż oficjalna specyfikacja i możliwość takiego wykorzystania). Słowa „Schemat” nie należy rozumieć w tym samym znaczeniu, co wyrażenie „Schemat XML”. Na przykład, :author rdfs:range foaf:Person Oznacza to, że rdf:type wszystkie wartości nieruchomości :author - foaf:Person, ale nie oznacza, że należy to powiedzieć z góry.
SPARQL
(SPARQL Protocol i RDF Query Language) - język służący do wykonywania zapytań o dane RDF. W prostym przypadku zapytanie SPARQL to zbiór próbek, do których dopasowywane są trójki grafu, którego dotyczy zapytanie. Wzorce mogą zawierać zmienne w pozycjach podmiotu, orzeczenia i obiektu.
Zapytanie zwróci takie wartości zmiennych, które po podstawieniu do próbek mogą skutkować powstaniem podgrafu badanego grafu RDF (podzbiór jego trójek). Zmienne o tej samej nazwie w różnych próbkach trójek muszą mieć te same wartości.
Na przykład, biorąc pod uwagę powyższy zestaw siedmiu aksjomatów RDFS, zwróci następujące zapytanie rdfs:domain и rdfs:range jako wartości ?s и ?p odpowiednio:
SELECT * WHERE {
?s ?p rdfs:Class .
?p ?p rdf:Property .
}Warto zauważyć, że SPARQL ma charakter deklaratywny i nie jest językiem opisującym przechodzenie przez graf (jednak niektóre repozytoria RDF oferują możliwości dostosowania planu wykonania zapytania). Dlatego też niektórych standardowych problemów grafowych, na przykład znalezienia najkrótszej ścieżki, nie da się rozwiązać w SPARQL, włączając w to użycie metody (ale znowu poszczególne repozytoria RDF oferują specjalne rozszerzenia rozwiązujące te problemy).
SPARQL nie podziela założenia otwartości świata i kieruje się podejściem „negacja jako porażka”, w którym projekty takie jak FILTER NOT EXISTS {…}. Rozkład danych uwzględniany jest przy pomocy mechanizmu .
Punkt dostępowy SPARQL – pamięć RDF zdolna do przetwarzania zapytań SPARQL – nie ma bezpośrednich odpowiedników z drugiego etapu (patrz początek tego akapitu). Można ją porównać do bazy danych, na podstawie której wygenerowano strony HTML, ale dostępnej z zewnątrz. Punkt dostępowy SPARQL jest bardziej analogiczny do punktu dostępowego API z trzeciego etapu, ale ma dwie główne różnice. Po pierwsze, możliwe jest połączenie kilku „atomowych” zapytań w jedno (co jest uważane za kluczową cechę GraphQL), a po drugie, takie API jest całkowicie samodokumentujące (co starał się osiągnąć HATEOAS).
Uwaga polemiczna
RDF to sposób publikowania danych w Internecie, dlatego przechowywanie RDF należy uznać za DBMS dokumentów. To prawda, ponieważ RDF jest wykresem, a nie drzewem, okazały się również oparte na grafach. To niesamowite, że w ogóle się udało. Kto by pomyślał, że znajdą się mądrzy ludzie, którzy zaimplementują puste węzły. Codd tu jest .
Istnieją również mniej w pełni funkcjonalne sposoby organizacji dostępu do danych RDF, na przykład (LDF) i (LDP).
OWL
(Web Ontology Language) - formalizm reprezentacji wiedzy, syntaktyczna wersja logiki opisu (wszędzie poniżej bardziej poprawne jest określenie OWL 2, na którym bazowała pierwsza wersja OWL ).
Pojęcia logiki opisowej w OWL odpowiadają klasom, role odpowiadają właściwościom, jednostki zachowują swoją poprzednią nazwę. Aksjomaty nazywane są także aksjomatami.
Na przykład w tzw dla notacji OWL jest to już nam znany aksjomat zostanie napisane w ten sposób:
Class: Human
Class: Parent
EquivalentClass: Human and (inverse hasParent) some Human
ObjectProperty: hasParentIstnieją inne składnie do pisania OWL-a, takie jak , użyte w oficjalnej specyfikacji, oraz . Dodatkowo OWL może być serializowany i dalej - w dowolnej określonej składni.
OWL ma podwójną relację z RDF. Z jednej strony można go uznać za rodzaj słownika rozszerzającego RDFS. Z drugiej strony jest to potężniejszy formalizm, dla którego RDF jest po prostu formatem serializacji. Nie wszystkie elementarne konstrukcje OWL można zapisać przy użyciu pojedynczej trójki RDF.
W zależności od tego, który podzbiór konstrukcji OWL jest dozwolony, mówi się o tzw . Znormalizowane i najbardziej znane to OWL EL, OWL RL i OWL QL. Wybór profilu wpływa na złożoność obliczeniową typowych problemów. Kompletny zestaw konstrukcji OWL odpowiadających , zwany OWL DL. Czasami mówi się także o OWL Full, w którym konstrukcje OWL mogą być używane z pełną swobodą właściwą RDF, bez ograniczeń semantycznych i obliczeniowych . Na przykład coś może być zarówno klasą, jak i właściwością. OWL Full jest nierozstrzygalny.
Kluczowymi zasadami dołączania konsekwencji w OWL jest przyjęcie założenia otwartego świata. ) i odrzucenie założenia o unikalności nazw (założenie o unikalnej nazwie, ). Poniżej zobaczymy dokąd mogą prowadzić te zasady i wprowadzimy pewne konstrukcje OWL.
Niech ontologia zawiera następujący fragment (w składni Manchesteru):
Class: manyChildren
EquivalentTo: Human that hasChild min 3
Individual: John
Types: Human
Facts: hasChild Alice, hasChild Bob, hasChild CarolCzy z tego, co zostało powiedziane, wynika, że Jan ma wiele dzieci? Odrzucenie UNA zmusi silnik wnioskowania do udzielenia odpowiedzi przeczącej na to pytanie, ponieważ Alicja i Bob mogą równie dobrze być tą samą osobą. Aby zaistniała sytuacja, należy dodać następujący aksjomat:
DifferentIndividuals: Alice, Bob, Carol, JohnNiech teraz fragment ontologii przyjmie następującą postać (Jan deklaruje się, że ma wiele dzieci, ale ma tylko dwoje dzieci):
Class: manyChildren
EquivalentTo: Human that hasChild min 3
Individual: John
Types: Human, manyChildren
Facts: hasChild Alice, hasChild Bob
DifferentIndividuals: Alice, Bob, Carol, JohnCzy ta ontologia będzie niespójna (co można zinterpretować jako dowód na nieprawidłowe dane)? Zaakceptowanie OWA spowoduje, że silnik wnioskowania zareaguje negatywnie: „gdzieś” gdzie indziej (w innej ontologii) można śmiało powiedzieć, że Carol jest także dzieckiem Johna.
Aby wykluczyć taką możliwość, dodajmy nowy fakt na temat Jana:
Individual: John
Facts: hasChild Alice, hasChild Bob, not hasChild CarolAby wykluczyć pojawienie się innych dzieci, powiedzmy, że wszystkimi wartościami majątku „posiadanie dziecka” są ludzie, których mamy tylko cztery:
ObjectProperty: hasChild
Domain: Human
Сharacteristics: Irreflexive
Class: Human
EquivalentTo: { Alice, Bill, Carol, John }Teraz ontologia stanie się sprzeczna, czego silnik wnioskowania nie ominie. Ostatnim z aksjomatów w pewnym sensie „zamknęliśmy” świat i zauważyliśmy, jak wykluczona jest możliwość, aby Jan był jego własnym dzieckiem.
Łączenie danych przedsiębiorstwa
Zestaw podejść i technologii Linked Data był pierwotnie przeznaczony do publikowania danych w Internecie. Ich użycie w wewnętrznym środowisku korporacyjnym napotyka szereg trudności.
Na przykład w zamkniętym środowisku korporacyjnym siła dedukcyjna OWL oparta na przyjęciu OWA i odrzuceniu decyzji UNA wynikających z otwartego i rozproszonego charakteru sieci jest zbyt słaba. I tutaj możliwe są następujące rozwiązania.
- Wyposażenie OWL w semantykę, co oznacza porzucenie OWA i przyjęcie UNA, wdrożenie odpowiedniego silnika wyjściowego. - Tą ścieżką Magazyn Stardog RDF.
- Porzucenie możliwości dedukcyjnych OWL na rzecz silników reguł. — Wspiera Stardog ; Oferta Jena i GraphDB zasady
- Odmowa dedukcyjnych możliwości OWL, wykorzystanie tego czy innego podzbioru zbliżonego do RDFS do modelowania. - Więcej na ten temat poniżej.
Inną kwestią jest większe skupienie się świata korporacji na kwestiach związanych z jakością danych oraz brak narzędzi do sprawdzania poprawności danych w stosie połączonych danych. Dane wyjściowe są następujące.
- Ponownie użyj do walidacji konstrukcji OWL z semantyką zamkniętego świata i unikalnymi nazwami, jeśli dostępny jest odpowiedni silnik wnioskowania.
- Używać , ustandaryzowany po naprawieniu listy warstw Semantic Web Layer Cake (jednak może być również używany jako silnik reguł), lub .
- Zrozumienie, że ostatecznie wszystko odbywa się za pomocą zapytań SPARQL i stworzenie przy ich pomocy własnego, prostego mechanizmu walidacji danych.
Jednak nawet całkowite odrzucenie możliwości dedukcyjnych i narzędzi walidacyjnych pozostawia stos Linked Data poza konkurencją w zadaniach podobnych do otwartej i rozproszonej sieci - w zadaniach integracji danych.
A co ze zwykłym systemem informacyjnym przedsiębiorstwa?
Jest to możliwe, ale należy oczywiście mieć świadomość, jakie problemy będą musiały rozwiązać odpowiednie technologie. Opiszę tutaj typową reakcję uczestników rozwoju, aby pokazać, jak ten stos technologii wygląda z punktu widzenia konwencjonalnego IT. Przypomina mi trochę przypowieść o słoniu:
- Analityk Biznesowy: RDF to coś w rodzaju bezpośrednio przechowywanego modelu logicznego.
- Analityk systemów: RDF jest jak , tylko z dużą liczbą indeksów i wygodnym językiem zapytań.
- Wywoływacz: cóż, to wszystko w duchu koncepcji bogatego modelu i niskiego kodu, ostatnio o tym.
- Kierownik projektu: tak, to samo !
Praktyka pokazuje, że stos najczęściej wykorzystywany jest w zadaniach związanych z dystrybucją i heterogenicznością danych, np. przy budowie systemów klasy MDM (Master Data Management) czy DWH (Data Warehouse). Takie problemy istnieją w każdej branży.
Jeśli chodzi o zastosowania branżowe, technologie Linked Data są obecnie najpopularniejsze w następujących branżach.
- technologie biomedyczne (gdzie ich popularność wydaje się być związana ze złożonością dziedziny);
aktualny
W „Punkcie Wrzenia” odbyła się niedawno konferencja zorganizowana przez stowarzyszenie „Krajowa Baza Wiedzy Medycznej” „".
- produkcja i eksploatacja złożonych produktów (duża inżynieria mechaniczna, wydobycie ropy i gazu; najczęściej mówimy o standardzie );
aktualny
Tutaj także powodem jest złożoność tematyki, gdy np. na etapie upstream, jeśli mówimy o przemyśle naftowo-gazowym, prosta księgowość wymaga pewnych funkcji CAD.
W 2008 roku odbyła się reprezentatywna impreza instalacyjna zorganizowana przez firmę Chevron .
Ostatecznie ISO 15926 wydało się nieco trudne dla przemysłu naftowego i gazowego (i prawdopodobnie znalazło większe zastosowanie w inżynierii mechanicznej). Dopiero Statoil (Equinor) całkowicie się od tego uzależnił, w Norwegii całość . Inni próbują robić swoje. Na przykład, według plotek, krajowe Ministerstwo Energii zamierza stworzyć „koncepcyjny model ontologiczny kompleksu paliwowo-energetycznego”, najwyraźniej podobny do .
- organizacje finansowe (nawet XBRL można uznać za swego rodzaju hybrydę ontologii SDMX i RDF Data Cube);
aktualny
Na początku roku LinkedIn aktywnie spamował autora ofertami pracy niemal wszystkich gigantów branży finansowej, których zna z serialu „Siła wyższa”: Goldman Sachs, JPMorgan Chase i/lub Morgan Stanley, Wells Fargo, SWIFT/Visa/Mastercard, Bank of America, Citigroup, Fed, Deutsche Bank... Pewnie każdy szukał kogoś, do kogo mógłby wysłać . Całkiem sporo udało się znaleźć: organizacje finansowe zabrały wszystko .
W HeadHunter tylko Sberbank natknął się na coś interesującego; chodziło o „pamięć masową EAV z modelem danych podobnym do RDF”.
Prawdopodobnie różnica w stopniu zamiłowania do odpowiednich technologii krajowych i zachodnich instytucji finansowych wynika z ponadnarodowego charakteru działalności tych ostatnich. Najwyraźniej integracja ponad granicami państw wymaga jakościowo odmiennych rozwiązań organizacyjnych i technicznych.
- systemy pytanie-odpowiedź z aplikacjami komercyjnymi (IBM Watson, Apple Siri, Google Knowledge Graph);
aktualny
Notabene twórca Siri, Thomas Gruber, jest autorem samej definicji ontologii (w sensie informatycznym) jako „specyfikacji konceptualizacji”. Moim zdaniem przestawianie słów w tej definicji nie zmienia jej znaczenia, co być może wskazuje, że jej w ogóle nie ma.
- publikacja danych strukturalnych (z większym uzasadnieniem można to przypisać Linked Open Data).
aktualny
Wielkimi fanami Linked Data są tzw. GLAM: Galerie, Biblioteki, Archiwa i Muzea. Dość powiedzieć, że Biblioteka Kongresu promuje zamiennik MARC21 Który stanowi podstawę przyszłego opisu bibliograficznego i oczywiście w oparciu o RDF.
Wikidane są często przytaczane jako przykład udanego projektu z zakresu Linked Open Data – swego rodzaju czytelnej maszynowo wersji Wikipedii, której treść w przeciwieństwie do DBPedia nie jest generowana poprzez import z infoboksów artykułów, ale jest tworzony mniej więcej ręcznie (i później staje się źródłem informacji dla tych samych infoboksów).
Polecamy również to sprawdzić użytkowników magazynu Stardog RDF na stronie internetowej Stardog w zakładce „Klienci”.
Tak czy inaczej, w Gartner „Zarządzanie taksonomią i ontologią przedsiębiorstw” znajduje się w środku zejścia w dolinę rozczarowań z perspektywą osiągnięcia „plateau produktywności” nie wcześniej niż za 10 lat.
Łączenie danych przedsiębiorstwa
Prognozy, prognozy, prognozy...
Ze względów historycznych zestawiłem poniżej prognozy Gartnera na różne lata dotyczące interesujących nas technologii.
| Rok | Технология | Zgłoś | Stanowisko | Lata do plateau |
|---|---|---|---|---|
| 2001 | Semantic Web | Nowe technologie | Wyzwalacze innowacji | 5-10 |
| 2006 | Korporacyjna sieć semantyczna | Nowe technologie | Szczyt napompowanych oczekiwań | 5-10 |
| 2012 | Semantic Web | Big Data | Szczyt napompowanych oczekiwań | > 10 |
| 2015 | Połączone dane | Zaawansowana analityka i nauka o danych | Koryto rozczarowania | 5-10 |
| 2016 | Zarządzanie ontologią przedsiębiorstwa | Nowe technologie | Koryto rozczarowania | > 10 |
| 2018 | Wykresy wiedzy | Nowe technologie | Wyzwalacze innowacji | 5-10 |
Jednak już w pojawił się kolejny trend wzrostowy – Grafy Wiedzy. Nastąpiła pewna reinkarnacja: grafowe systemy DBMS, na które zwrócono uwagę użytkowników i wysiłki programistów, pod wpływem żądań tych pierwszych i przyzwyczajeń tych drugich, zaczęły nabierać konturów i pozycjonowania swoich poprzednich konkurentów.
Prawie każdy graf DBMS deklaruje się obecnie jako odpowiednia platforma do budowania korporacyjnego „grafu wiedzy” („połączone dane” są czasami zastępowane przez „połączone dane”), ale na ile uzasadnione są takie twierdzenia?
Grafowe bazy danych są nadal asemantyczne; dane w grafowym systemie DBMS to wciąż ten sam silos danych. Identyfikatory łańcuchowe zamiast identyfikatorów URI sprawiają, że integracja dwóch grafowych systemów DBMS nadal jest zadaniem integracyjnym, podczas gdy integracja dwóch składnic RDF często sprowadza się do prostego połączenia dwóch wykresów RDF. Innym aspektem asemantyczności jest brak refleksyjności modelu wykresu LPG, co utrudnia zarządzanie metadanymi przy użyciu tej samej platformy.
Wreszcie grafowe systemy DBMS nie mają silników wnioskowania ani silników reguł. Wyniki takich silników można odtworzyć poprzez skomplikowanie zapytań, ale jest to możliwe nawet w SQL.
Jednak wiodące systemy magazynowania RDF bez problemu obsługują model LPG. Za najbardziej solidne podejście uważa się to, które zaproponowano kiedyś w Blazegraph: model RDF*, łączący RDF i LPG.
Szczegółowo
Więcej o obsłudze magazynowania RDF dla modelu LPG przeczytacie w poprzednim artykule na Habré: . Mam nadzieję, że pewnego dnia powstanie osobny artykuł na temat Grafów Wiedzy i Data Fabric. Ostatnia część, jak łatwo zrozumieć, została napisana w pośpiechu, jednak nawet sześć miesięcy później w przypadku tych koncepcji nie wszystko jest dużo jaśniejsze.
literatura
- Halpin, H., Monnin, A. (red.) (2014). Inżynieria filozoficzna: w stronę filozofii sieci
- Allemang, D., Hendler, J. (2011) Sieć semantyczna dla pracującego ontologa (wyd. 2)
- Staab, S., Studer, R. (red.) (2009) Handbook on Ontologies (wyd. 2)
- Drewno, D. (red.). (2011) Łączenie danych przedsiębiorstwa
- Keet, M. (2018) Wprowadzenie do inżynierii ontologii
Źródło: www.habr.com