Web Semantic și Linked Data. Corecturi și completări

Vreau să prezint publicului un fragment din această carte recent publicată:

Modelarea ontologică a unei întreprinderi: metode și tehnologii [Text]: monografie / [S. V. Gorșkov, S. S. Kralin, O. I. Muștak și alții; editor responsabil S. V. Gorșkov]. — Ekaterinburg: Editura Universității Urale, 2019. — 234 p.: il., tabele; 20 cm. — Autorii sunt menționați pe spatele paginii de titlu. — Bibliografie la sfârșitul capitolelor. — ISBN 978-5-7996-2580-1: 200 ex.

Scopul publicării acestui fragment pe Habr este cvadruplu:

• Este puțin probabil ca cineva să reușească să ții această carte în mâini, dacă nu este client al respectabilului SergeIndex; nu este deloc disponibil la vânzare.
• În text s-au făcut corecții (care nu sunt evidențiate mai jos) și s-au adus completări care nu sunt foarte compatibile cu formatul unei monografii tipărite: note de actualitate (sub spoilere) și hyperlinkuri.
• Ar fi bine să strângem întrebări și observații, pentru a le lua în considerare la includerea acestui text, într-o formă revizuită, în alte publicații.
• Mulți adepți ai Semantic Web și Linked Data consideră în continuare că cercul lor este atât de restrâns în principal pentru că publicului larg nu i s-a explicat în mod corespunzător cât de grozav este să fii adept al Semantic Web și Linked Data. Autorul fragmentului, deși face parte din acest cerc, nu împărtășește această părere, dar, cu toate acestea, se consideră obligat să facă încă un efort.

Deci,

Semantic Web

Evoluția Internetului poate fi prezentată astfel (sau putem vorbi despre segmentele sale, formate în ordinea menționată mai jos):

1. Documentele pe internet. Tehnologii cheie — Gopher, FTP etc.
   Internetul este o rețea globală pentru schimbul de resurse locale.
2. Internetul documentelor. Tehnologii cheie — HTML și HTTP.
   Natura resurselor prezentate ține cont de caracteristicile mediului de transmitere.
3. Datele pe internet. Tehnologii cheie — REST și SOAP API, XHR etc.
   Era aplicațiilor de internet, consumatorii de resurse nu sunt numai oameni.
4. Internetul datelor. Tehnologii cheie — tehnologiile Linked Data.
   Această a patra etapă, prevăzută de Berners-Lee, creatorul tehnologiilor cheie din a doua etapă și directorul W3C, se numește Semantic Web; tehnologiile Linked Data sunt destinate să facă datele pe web nu doar citibile de mașini, ci și „înțelese de mașini”.

Din cele ce urmează, cititorului îi va deveni clar corespondența conceptelor cheie dintre a doua și a patra etapă:

• URI-urile sunt analogi ai URL-urilor,
• RDF-ul este analogul HTML-ului,
• URI-urile sunt echivalente cu hyperlink-urile HTML în documentele RDF.

Web-ul semantic este mai degrabă o viziune sistemică asupra viitorului internetului, decât o tendință concretă, spontană sau susținută, deși poate lua în considerare și aceste aspecte recente. De exemplu, o caracteristică importantă a ceea ce se numește Web 2.0 este „conținutul creat de utilizatori”. Acest aspect este luat în considerare de recomandarea W3C „Web Annotation Ontology” și inițiativa denumită Solid..

Este mort Web-ul semantic?

Dacă renunțăm la așteptările nerealiste,situația cu web-ul semantic este, în mare parte, similară cu cea a comunismului în epoca socialismului dezvoltat (însă dacă se respectă anumite principii ale lui Lenin, fiecare trebuie să decidă pentru sine). Motoarele de căutare obligă destul de eficient site-urile web să folosească RDFa și JSON-LD și ele însele folosesc tehnologii din familiei celor menționate mai jos (Google Knowledge Graph, Bing Knowledge Graph).

În general, autorul nu poate spune ce împiedică o adoptare mai largă, dar poate oferi opinii bazate pe experiența personală. Există probleme care ar putea fi rezolvate „din cutie” în contextul SW, deși nu sunt foarte răspândite. Ca urmare, cei care se confruntă cu aceste probleme nu au mijloace de constrângere asupra celor capabili să le rezolve, iar asigurarea autoconținută a soluțiilor de către aceștia contravine modelului lor de afaceri. Așadar, continuăm să parsăm HTML-ul și să conectăm API-uri diverse, unul mai rău decât altul.

Totuși, tehnologiile Linked Data s-au răspândit și dincolo de web-ul de masă; aceste aplicații sunt, de fapt, dedicate cărții. În prezent, comunitatea Linked Data așteaptă ca aceste tehnologii să câștige o mai mare popularitate datorită afirmației (sau proclamării, cum îi place fiecăruia) Gartner privind astfel de tendințe precum Graficele de cunoștințe și Materialul de date. Ne dorim să credem că nu „implementările de tip bicicletă” ale acestor concepte vor avea succes, ci cele care sunt relevante pentru standardele W3C discutate mai departe.

Linked Data

Berners-Lee definea Linked Data ca fiind „web-ul semantic realizat corect”: totul este o combinație de abordări și tehnologii care permit atingerea obiectivelor sale finale. Principiile fundamentale ale Linked Data, pe care Berners-Lee le sublinia sunt următoarele.

Principiul 1. Utilizarea URI-urilor pentru denumirea entităților.

URI sunt identificatori globali pentru entități, spre deosebire de identificatorii locali de tip string pentru înregistrări. Ulterior, cea mai bună exprimare a acestui principiu a fost găsită în sloganul Google Knowledge Graph „lucruri, nu stringuri».

Principiul 2. Utilizarea URI în schema HTTP, pentru a putea fi dereferențiate.

Accesând URI-ul, ar trebui să fie posibil să obții ceea ce este semnificat de acest semnificat (aici se poate face o analogie cu denumirea operatorului „*„ în C); mai exact, să obții o anumită reprezentare a acestui semnificat — în funcție de valoarea antetului HTTP Accept:. Poate că, odată cu venirea epocii AR/VR, va fi posibil să obținem însăși resursa, dar acum, cel mai probabil, aceasta va fi un document RDF, rezultatul executării unei interogări SPARQL DESCRIBE.

Principiul 3. Utilizarea standardelor W3C — în special, RDF(S) și SPARQL — în mod special, la dereferențierea URI-urilor.

Aceste „straturi” separate ale stivei tehnologice Linked Data, cunoscută și sub numele de Semantic Web Layer Cake, vor fi descrise de noi mai departe.

Principiul 4. Utilizarea referințelor la alte URI-uri atunci când descriem entitățile.

RDF permite limitarea la o descriere verbală a resursei într-o limbă naturală, iar al patrulea principiu îi îndeamnă pe toți să nu facă acest lucru. Odată cu respectarea generalizată a primului principiu, apare posibilitatea de a face referințe la altele, inclusiv „străine”, în descrierea resursei, motiv pentru care datele sunt numite legate. De fapt, utilizarea URI-urilor, denumite în vocabularul RDFS, este aproape inevitabilă.

RDF

RDF Framework-ul de descriere a resurselor (Resource Description Framework) — un formalism pentru descrierea entităților interconectate.

Despre entități și relațiile lor se fac afirmații de tip „subiect-predicat-obiect”, numite triplete. În cazul cel mai simplu, subiectul, predicatul și obiectul sunt toate URI-uri. Același URI poate ocupa diverse poziții în diverse triplete: poate fi atât subiect, cât și predicat, și obiect; astfel, triplele formează un fel de grafic, numit grafic RDF.

Subiectele și obiectele nu pot fi doar URI-uri, ci și așa-numitele noduri goale, iar obiectele pot fi, de asemenea, literaluri. Literalurile sunt instanțe ale tipurilor primitive, constând dintr-o reprezentare în format string și specificarea tipului.

Exemple de înregistrare a literalelor (în sintaxa Turtle, despre care vom vorbi mai jos): "5.0"^^xsd:float și "cinci"^^xsd:string. Literalurile cu tipul rdf:langString pot fi dotate, de asemenea, cu un tag de limbă, în Turtle, acesta este formulat astfel: "cinci"@en și "cinci"@ro.

Nodurile goale sunt resurse „anonime” fără identificatori globali, despre care, totuși, pot fi făcute afirmații; un fel de variabile existențiale.

Așadar (aceasta este, de fapt, esența RDF):

• subiectul este un URI sau un nod gol,
• predicatul este un URI,
• iar obiectul este un URI, un nod gol sau un literal.

De ce predicatelor nu le pot fi noduri goale?

Motivul probabil este dorința de a înțelege informal și de a traduce în limbajul logicii predicatelor de ordinul întâi tripletul s p o ca fiind ceva asemănător , unde — predicat, și — constante. Urme ale unei astfel de înțelegeri se regăsesc în documentul „LBase: Semantics for Languages of the Semantic Web”, care are statut de notă a grupului de lucru W3C. În acest sens, tripletul s p [], unde [] — nod gol, va fi tradus ca , unde — variabilă, dar cum să traduci atunci s [] o? Имеющий статус рекомендации W3C документ «RDF 1.1 Semantics” propune o altă modalitate de traducere, dar posibilitatea ca predicatele să fie noduri goale nu este niciodată considerată.

Cu toate acestea, Manu Sporni au permis.

RDF este un model abstract. RDF poate fi scris (serializat) în diverse sintaxe: RDF/XML, Turtle (cel mai ușor de citit), JSON-LD, HDT (binar).

Același RDF poate fi serializat în RDF/XML în moduri diferite, de aceea, de exemplu, XML rezultat nu are sens să fie validat folosind XSD sau să încerce extragerea datelor cu ajutorul XPath. La fel, JSON-LD este puțin probabil să satisfacă dorința unui dezvoltator Javascript obișnuit de a lucra cu RDF folosind notația punctată și cea cu paranteze pătrate Javascript (deși JSON-LD se îndreaptă în această direcție, oferind un mecanism framing).

Cele mai multe sintaxe oferă modalități de scurtare a URI-urilor lungi. De exemplu, declarația @prefix rdf: în Turtle va permite apoi scrierea în loc de <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> pur și simplu rdf:type.

RDFS

RDFS (RDF Schema) este dicționarul de bază pentru modelare, introducând conceptele de proprietate și clasă precum și proprietăți precum rdf:type, rdfs:subClassOf, rdfs:domain și rdfs:range. Folosind dicționarul RDFS, pot fi scrise, de exemplu, următoarele expresii corecte:

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 este un dicționar de descriere și modelare, dar nu este un limbaj de restricții (deși specificația oficială și lasă posibilitatea unei astfel de utilizări). Cuvântul „Schema” nu trebuie înțeles în același sens ca în expresia „XML Schema”. De exemplu, :author rdfs:range foaf:Person înseamnă că rdf:type toate valorile proprietății :author — foaf:Person, dar nu înseamnă că acesta trebuie să fie menționat dinainte.

SPARQL

SPARQL (SPARQL Protocol and RDF Query Language) — un limbaj de interogare pentru datele RDF. În cazul simplu, o interogare SPARQL constă într-un set de modele cu care se potrivesc tripletele din graf. Modelele pot conține variabile în pozițiile subiecților, predicatelor și obiectelor.

Interogarea va returna astfel de valori ale variabilelor, pentru care, prin substituție în modele, poate fi obținut un subgraf din RDF-graful interogat (un subset al tripletelor sale). Variabilele cu același nume în diferite modele de triplete trebuie să aibă valori identice.

De exemplu, pentru setul menționat mai sus din șapte axiome RDFS, următoarea interogare va returna rdfs:domain și rdfs:range ca valori ?s și ?p respectiv:

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

Este de remarcat că SPARQL este declarațional și nu este un limbaj de descriere a traversării graficului (totuși, unele depozite RDF oferă modalități de ajustare a planului de executare a interogării). Prin urmare, unele sarcini standard de grafic, cum ar fi găsirea celui mai scurt drum, nu pot fi rezolvate cu SPARQL, inclusiv folosind mecanismul property paths (dar, din nou, unele depozite RDF oferă extensii speciale pentru a rezolva aceste sarcini).

SPARQL nu divide prezumția deschiderii lumii și urmează abordarea „negarea ca eșec”, în care sunt posibile astfel de construcții cum ar fi FILTER NOT EXISTS {…}. Distribuția datelor este luată în considerare prin intermediul mecanismului interogărilor federative.

Un punct de acces SPARQL — un depozit RDF capabil să proceseze interogări SPARQL — nu are echivalente directe din etapa a doua (vezi începutul acestui paragraf). Se poate asemăna cu o bază de date, pe baza căreia au fost generate paginile HTML, dar care este accesibilă din exterior. Punctul de acces SPARQL este mai degrabă un omolog al unui punct de acces API din etapa a treia, dar cu două diferențe principale. În primul rând, există posibilitatea de a combina mai multe interogări „atomice” într-una (ceea ce este considerat o caracteristică cheie a GraphQL), în al doilea rând, acest API este complet autdocumentat (aspect pe care HATEOAS a încercat să-l realizeze).

Observație polemică

RDF – un mod de publicare a datelor pe web, așa că ar trebui să considerăm depozitele RDF ca fiind SGBD documentare. Totuși, pentru că RDF este un grafic, nu un arbore, au rezultat și depozite grafice. Este uimitor că au fost realizate. Cine s-ar fi gândit că vor apărea persoane inteligente care implementează noduri goale. La Codd, aceasta nu a funcționat. Nu a avut succes..

Există și metode mai puțin funcționale de organizare a accesului la datele RDF, de exemplu, Fragmente de date linkuite (LDF) și Platforma de date linkuite (LDP).

OWL

OWL (Limbaj de Ontologie Web) – un formalism pentru reprezentarea cunoștințelor, o variantă sintactică a logicii descriitoare (în tot ceea ce urmează, este corect să se vorbească despre OWL 2, prima versiune OWL a fost bazată pe ).

Conceptelor din logica descriitoare în OWL le corespund clase, rolurile – proprietăți, indivizii își păstrează denumirile anterioare. Axiomele sunt de asemenea denumite axiome.

De exemplu, în așa-numita sintaxă manchesteriană pentru înregistrarea OWL, axioma pe care o cunoaștem deja va fi înregistrată astfel:

Clasă: Uman
Clasă: Părinte
   ClasăEchivalentă: Uman și (inverse hasParent) some Uman
ProprietateObiect: hasParent

Există și alte sintaxe pentru înregistrarea OWL, de exemplu, sintaxa funcțională, utilizată în specificația oficială, și OWL/XML.În plus, OWL poate fi serializat în sintaxa abstractă RDF și ulterior – în oricare dintre sintaxele concrete.

OWL se raportează la RDF într-o manieră duală. Pe de o parte, poate fi considerat un fel de dicționar care extinde RDFS. Pe de altă parte, acesta este un formalism mai puternic, pentru care RDF este doar un format de serializare. Nu toate construcțiile elementare OWL pot fi înregistrate printr-un singur triplet RDF.

În funcție de subsetul de construcții OWL care este permis să fie utilizat, se vorbește despre așa-numitele profiluri OWL.Cele standardizate și cele mai cunoscute sunt OWL EL, OWL RL și OWL QL. Alegerea profilului influențează complexitatea computațională a sarcinilor tipice. Setul complet de construcții OWL, corespunzător , este denumit OWL DL. Uneori, se vorbește și despre OWL Full, în care construcțiile OWL sunt permise să fie utilizate cu toată libertatea caracteristică RDF, fără restricții semantice și computaționale. De exemplu, ceva poate fi atât o clasă, cât și o proprietate. OWL Full este nerezolvabil.

Principiile cheie ale adăugării consecințelor în OWL sunt acceptarea presupunerii lumii deschise (open world assumption, OWA) și renunțarea la presupunerea unicitații numelui (unique name assumption,UNA UNA). Sub următoarele, vom vedea la ce pot conduce aceste principii și ne vom familiariza cu unele structuri OWL.

Să presupunem că ontologia conține următorul fragment (în sintaxa manchester):

Class: manyChildren
   EquivalentTo: Human that hasChild min 3
Individual: John
   Types: Human
   Facts: hasChild Alice, hasChild Bob, hasChild Carol

Se va deduce din cele spuse că John are mulți copii? Renunțarea la UNA va determina motorul de inferență să răspundă negativ la această întrebare, deoarece Alice și Bob pot fi, de fapt, aceeași persoană. Pentru a exista o deducție, va fi necesar să adăugăm o astfel de axioma:

DifferentIndividuals: Alice, Bob, Carol, John

Să presupunem acum că fragmentul ontologiei are următorul aspect (John declarat cu mulți copii, dar având doar doi copii indicați):

Class: manyChildren
   EquivalentTo: Human that hasChild min 3
Individual: John
   Types: Human, manyChildren
   Facts: hasChild Alice, hasChild Bob
DifferentIndividuals: Alice, Bob, Carol, John

Va fi această ontologie contradictorie (ceea ce poate fi interpretat ca o dovadă a invalidității datelor)? Acceptarea OWA va determina motorul de inferență să răspundă negativ: „undeva” în altă parte (în altă ontologie) este posibil să se afirme că Carol este de asemenea copilul lui John.

Pentru a exclude posibilitatea acestui lucru, să adăugăm un nou fapt despre John:

Individual: John
   Facts: hasChild Alice, hasChild Bob, not hasChild Carol

Pentru a exclude apariția altor copii, să spunem că toate valorile proprietății „a avea copil” sunt oameni, dintre care avem patru:

ObjectProperty: hasChild
   Domain: Human
   Сharacteristics: Irreflexive
Class: Human
EquivalentTo: { Alice, Bill, Carol, John }

Acum ontologia va deveni contradictorie, iar motorul de inferență nu va ezita să raporteze acest lucru. Prin ultima din axiome, cumva am „închis” lumea, și observati cum a fost exclusă posibilitatea ca John să fie copilul său.

Legarea datelor întreprinderii

Setul de abordări și tehnologii Linked Data a fost destinat inițial publicării datelor pe web. Utilizarea acestora în medii corporative interne se confruntă cu o serie de dificultăți.

De exemplu, într-un mediu corporativ închis, puterea deductivă a OWL, bazată pe acceptarea OWA și renunțarea la UNA — soluții determinate de caracterul deschis și distribuit al web-ului, se dovedește a fi prea slabă. Și aici sunt posibile următoarele soluții.

• Încărcarea OWL cu semantica, implicând renunțarea la OWA și acceptarea UNA, implementarea unui motor de inferență corespunzător. — Pe acest parcurs merge RDF-stocare Stardog.
• Renunțarea la capacitățile deductive ale OWL în favoarea motoarelor de reguli. — Stardog suportă SWRL; Jena și GraphDB oferă propriile limbaje de reguli.
• Renunțarea la capacitățile deductive ale OWL, utilizarea pentru modelarea unui anumit subset apropiat de RDFS. — Vezi mai departe.

O altă problemă este atenția mai mare, care poate fi acordată în domeniul corporativ problemelor de calitate a datelor și lipsa în stiva Linked Data a instrumentelor de validare a datelor. Iată câteva soluții.

• Din nou, utilizarea pentru validarea construcțiilor OWL cu semantica lumii închise și a unicitații numelui cu un motor de inferență corespunzător.
• Utilizare SHACL, standardizat deja după ce lista straturilor Semantic Web Layer Cake a fost fixată (totuși, poate fi folosit și ca motor de reguli), sau ShEx.
• Conștientizarea faptului că totul se face în cele din urmă prin interogări SPARQL, crearea unui mecanism simplu de validare a datelor folosind aceste interogări.

Cu toate acestea, chiar și o renunțare completă la capacitățile deductive și instrumentele de validare lasă stiva Linked Data fără concurență în sarcini similare cu cele ale web-ului deschis și distribuit — în sarcini de integrare a datelor.

Ce zici de un sistem informațional corporativ obișnuit?

Este posibil, dar, bineînțeles, trebuie să fie clar ce probleme specifice trebuie să rezolve tehnologiile respective. Voi descrie aici reacția tipică a participanților la dezvoltare pentru a arăta cum arată această stivă tehnologică din perspectiva IT-ului convențional. Semănă puțin cu parabola despre elefant:

• Analist de afaceri: RDF este ceva de genul unui model logic stocat direct.
• Analist de sistem: RDF este ca EAV, doar că are o mulțime de indecși și un limbaj de interogare convenabil.
• Dezvoltatorul: ei bine, totul este în spiritul conceptelor de model bogat și low code, am citit recent despre asta.
• Manager de proiect: asta este colapsarea stivei!

Practic, stiva este utilizată cel mai frecvent în sarcini legate de distribuție și heterogenitatea datelor, de exemplu, în construirea sistemelor de tip MDM (Master Data Management) sau DWH (Data Warehouse). Aceste sarcini sunt prezente în fiecare industrie.

În ceea ce privește aplicațiile cu specific industrial, în prezent tehnologiile Linked Data sunt cele mai populare în următoarele industrii.

• tehnologiile biomedicale (unde popularitatea lor pare să fie legată de complexitatea domeniului);

relevant

La "Punctul de fierbere" a avut loc recent o conferință organizată de asociația „Baza Națională de Cunoștințe Medicale" "Unitatea ontologiilor. De la teorie la aplicarea practică».

• fabricarea și exploatarea produselor complexe (inginerie grea, extracția petrolului și gazului; cel mai frecvent vorbim despre standardul ISO 15926);

relevant

Aici, de asemenea, cauza este complexitatea domeniului, când, de exemplu, în etapa upstream, vorbind despre domeniul petrolului și gazelor, contabilitatea simplă trebuie să aibă anumite funcții CAD.

În 2008, a avut loc o conferință inaugurală organizată de Chevron conferință.

ISO 15926 s-a dovedit, în cele din urmă, a fi prea greu pentru domeniul petrolului și gazelor (și cu greu a găsit o aplicare mai mare în inginerie). Parțial, a fost adoptat doar de Statoil (Equinor), iar în Norvegia s-a creat o întreagă ecosistemă. Alte entități încearcă să facă ceva propriu. De exemplu, se zvonește că Ministerul Energiei din țară intenționează să dezvolte un "model conceptual ontologic al sectorului energetic", similar, aparent, cu cel creat pentru energia electrică.

• organizații financiare (chiar și XBRL poate fi considerat o oarecare combinație între SDMX și ontologia RDF Data Cube);

relevant

LinkedIn la începutul anului a bombardat autorul cu oferte de muncă de la aproape toți giganții din industria financiară, despre care știe din serialul „Suits": Goldman Sachs, JPMorgan Chase și/sau Morgan Stanley, Wells Fargo, SWIFT/Visa/Mastercard, Bank of America, Citigroup, Rezerva Federală, Deutsche Bank… Probabil, toți căutau pe cineva pe care să-l trimită la Knowledge Graph Conference. Au reușit să găsească destul de mulți: organizațiile financiare au ocupat întreaga dimineață a primei zile.

Pe HeadHunter, însă, ceva interesant se găsea doar la Sberbank, era vorba despre un "stoc EAV cu un model de date similar RDF".

Probabil, diferența în gradul de afecțiune față de tehnologiile corespunzătoare ale instituțiilor financiare autohtone și celui occidental este determinată de natura transnațională a activității acestora. Se pare că integrarea dincolo de granițele statelor necesită soluții organizaționale și tehnice calitativ diferite.

• sisteme de întrebări și răspunsuri cu aplicare comercială (IBM Watson, Apple Siri, Google Knowledge Graph);

relevant

De exemplu, creatorul Siri, Thomas Gruber, este autorul acelei definiții a ontologiei (în sensul IT) ca „specificație a conceptualizării”. În opinia mea, rearanjarea cuvintelor în această definiție nu îi schimbă sensul, ceea ce poate indica faptul că acesta nu există de fapt.

• publicarea datelor structurate (cu mare temei, aceasta poate fi deja considerată Linked Open Data).

relevant

Cei foarte pasionați de Linked Data sunt așa numiții GLAM: Galerii, Biblioteci, Arhive și Muzee. Aici este suficient să spunem că Biblioteca Congresului promovează BIBFRAME, care oferă o bază pentru viitorul descrierii bibliografice și, desigur, este bazat pe RDF.

Adesea, Wikidata este menționată ca un exemplu de succes în domeniul Linked Open Data — o versiune mașinabilă a Wikipedia, a cărei conținut, spre deosebire de DBPedia, nu este generat prin importul din infoboxurile articolelor, ci este creat mai mult sau mai puțin manual (și ulterior devine sursă de informație pentru aceleași infoboxuri).

Vă recomandăm, de asemenea, să consultați listă utilizatorii depozitului RDF Stardog pe site-ul Stardog, în secțiunea „Clienți”.

Oricum, în ciclul „Hype Cycle for Emerging Technologies” din 2016 „Managementul taxonomiei și ontologiei în întreprindere” este plasat la mijlocul scăderii în valea dezamăgirii, cu perspectiva de a ajunge pe „platoul de productivitate” nu mai devreme de 10 ani.

Conectarea datelor întreprinderii

Prognoze, prognoze, prognoze…

Din interes istoric, am rezumat previziunile Gartner din diferite ani în tabelul de mai jos pentru tehnologiile care ne interesează.

Totuși, deja în „Hype Cycle…” din 2018 a apărut o altă tendință în ascensiune — Grafuri de cunoștințe. A avut loc o oarecare reincarnare: bazele de date grafice, asupra cărora s-a concentrat atenția utilizatorilor și forțele dezvoltatorilor, sub influența cerințelor primelor și a obiceiurilor ultimelor, au început să capete contururi și poziționare față de predecesorii lor competitivi.

Practic fiecare bază de date grafică se declară acum o platformă potrivită pentru construirea unui „graf de cunoștințe” corporativ („linked data” este uneori înlocuit cu „connected data”), dar cât de justificate sunt astfel de pretenții?

Baze de date grafice rămân în continuare asemantice, datele într-o SGBD grafică sunt același siloz de date. Identificatorii de tip string în loc de URI fac ca sarcina de integrare a două SGBD grafice să fie aceeași sarcină de integrare, în timp ce integrarea a două depozite RDF tinde să se reducă pur și simplu la unirea a două grafuri RDF. Un alt aspect al asemanticității este non-reflexivitatea modelului grafic LPG, care face dificilă gestionarea metadatelor utilizând aceeași platformă.

În sfârșit, SGBD-urile grafice nu au motoare de inferență și motoare de reguli. Rezultatele acestor motoare pot fi reproduse prin complexificarea interogărilor, dar acest lucru este posibil chiar și în SQL.

Cu toate acestea, principalele depozite RDF nu au dificultăți în a susține modelul LPG. Cea mai solidă abordare considerată este cea propusă la un moment dat în Blazegraph: modelul RDF*, care combină RDF și LPG.

Află mai multe

Pentru mai multe informații despre suportul depozitelor RDF pentru modelul LPG, puteți citi articolul anterior de pe Habr: „Ce se întâmplă acum cu depozitele RDF”. Sper că despre Knowledge Graphs și Data Fabric va fi scrisă o articolă separată. Secțiunea finală, după cum se poate vedea ușor, a fost scrisă în grabă, totuși, și după șase luni cu aceste concepte, totul nu este mult mai clar.

Literatură

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

Sursa: habr.com