Semantic Web e Linked Data. Correzioni e integrazioni

Vorrei presentare al pubblico un estratto di questo recente libro:

Modellazione ontologica dell'azienda: metodi e tecnologie [Testo]: monografia / [S. V. Gorshkov, S. S. Kralin, O. I. Mushtak e altri; redattore responsabile S. V. Gorshkov]. — Ekaterinburg: Editore Università degli Urali, 2019. — 234 p.: ill., tabelle; 20 cm. — Gli autori sono indicati sul retro della copertina. — Bibliografia alla fine dei capitoli. — ISBN 978-5-7996-2580-1: 200 copie.

Lo scopo di questo estratto su Habr è quadruplo:

• È difficile che qualcuno possa tenere in mano questo libro se non è un cliente rispettabile di SergeIndex; non è in vendita assolutamente.
• Il testo è stato corretto (le correzioni non sono evidenziate) e sono stati aggiunti elementi poco compatibili con il formato della monografia cartacea: note tempestive (sotto le spoiler) e hyperlink.
• Si desidera raccoltare domande e osservazioni, per poterle considerare nell'inclusione di questo testo in una versione rielaborata in altre pubblicazioni.
• Molti sostenitori del Semantic Web e dei Linked Data ritengono ancora che il loro cerchio sia così ristretto principalmente perché al grande pubblico non è ancora stata spiegata in modo chiaro quanto sia fantastico essere un sostenitore del Semantic Web e dei Linked Data. L'autore di questo frammento, pur essendo parte di questo gruppo, non la pensa così, ma comunque si sente in dovere di fare un altro tentativo.

Quindi,

Semantic Web

L'evoluzione di Internet può essere descritta nel seguente modo (o si possono considerare i suoi segmenti, formatisi nell'ordine indicato qui sotto):

1. Documenti su Internet. Le tecnologie chiave sono Gopher, FTP, ecc.
   Internet è una rete globale per lo scambio di risorse locali.
2. Internet dei documenti. Le tecnologie chiave sono HTML e HTTP.
   La natura delle risorse fornite tiene conto delle caratteristiche dell'ambiente in cui vengono trasmesse.
3. Dati su Internet. Le tecnologie chiave sono REST e SOAP API, XHR, ecc.
   L'era delle applicazioni web, in cui i consumatori delle risorse non sono solo gli esseri umani.
4. Internet dei dati. Le tecnologie chiave sono le tecnologie dei Linked Data.
   Questo quarto stadio, previsto da Berners-Lee, creatore delle tecnologie chiave del web e direttore del W3C, è conosciuto come Web Semantico; le tecnologie Linked Data hanno lo scopo di rendere i dati sul web non solo leggibili dalle macchine, ma anche "comprensibili".

Dalla lettura successiva, sarà chiaro al lettore il rapporto tra i concetti chiave del secondo e del quarto stadio:

• gli URI sono l'analogo degli URL,
• l'RDF è l'analogo dell'HTML,
• le occorrenze di URI nei documenti RDF sono analoghe ai collegamenti ipertestuali HTML.

Il Web Semantico è più una visione sistematica del futuro di Internet piuttosto che una tendenza casuale o di lobby, anche se può tener conto di queste ultime. Ad esempio, una caratteristica importante di ciò che viene definito Web 2.0 è considerato il "contenuto generato dagli utenti". A tale scopo, si propone, tra l'altro, la raccomandazione W3C "Ontology di Annotazione Web" e iniziative come Solid.

Il Web Semantico è morto?

Se si rinuncia a aspettative irrealistiche, la situazione del web semantico è abbastanza simile a quella del comunismo nei tempi del socialismo maturo (e se si mantenga fedeltà ai precetti di Lenin, ognuno decida per sé). I motori di ricerca hanno avuto un successo abbastanza buono obbligano i siti web a utilizzare RDFa e JSON-LD e usano tecnologie correlate a quelle descritte di seguito (Google Knowledge Graph, Bing Knowledge Graph).

In linea generale, l'autore non può affermare cosa ostacoli una maggiore diffusione, ma può esprimere un parere basato sulla propria esperienza personale. Ci sono compiti che sarebbero risolvibili 'out of the box' in situazioni di SW, anche se non sono molto comuni. Di conseguenza, chi deve affrontare questi compiti non ha mezzi di costrizione nei confronti di coloro che possono fornire una soluzione; garantirsi autonomamente una soluzione da parte di questi ultimi contraddice i loro modelli di business. Quindi continuiamo a estrarre HTML e a combinare varie API, una più scadente dell'altra.

Tuttavia, le tecnologie Linked Data hanno trovato applicazione anche oltre il web di massa; a queste applicazioni è dedicato il libro. Attualmente, la comunità Linked Data si aspetta che queste tecnologie ottengano una diffusione ancora maggiore grazie all'affermazione (o proclamazione, come piace a ciascuno) da parte di Gartner di tendenze come Knowledge Graphs e Data Fabric. Si spera che il successo non arrivi da implementazioni «bici» di questi concetti, ma da quelli relativi agli standard W3C considerati successivamente.

Linked Data

Berners-Lee ha definito il Linked Data come un web semantico «ben fatto»: un insieme di approcci e tecnologie che consente di raggiungere i suoi obiettivi finali. I principi fondamentali del Linked Data definiti da Berners-Lee sono i seguenti.

Principio 1. Utilizzo degli URI per nominare entità.

Gli URI sono identificatori globali delle entità, a differenza degli identificatori locali delle stringhe delle registrazioni. In seguito, l'espressione migliore di questo principio è stata trovata nello slogan di Google Knowledge Graph «things, not strings».

Principio 2. Utilizzo degli URI nello schema HTTP, in modo che possano essere dereferenziati.

Accedendo all'URI, dovrebbe essere possibile ottenere il significato dietro questo significante (qui è chiara l'analogia con il nome dell'operatore «*» in C); più precisamente, ottenere una certa rappresentazione di questo significato - a seconda del valore dell'intestazione HTTP Accept:. Con l'arrivo dell'era AR/VR, potrebbe essere possibile accedere alla risorsa stessa, ma per ora, probabilmente, si tratterà di un documento RDF risultante dall'esecuzione di una query SPARQL. DESCRIBE.

Principio 3. L'uso degli standard W3C — in particolare, RDF(S) e SPARQL — è fondamentale, soprattutto per la dereferenziazione degli URI.

Questi diversi "livelli" dello stack tecnologico Linked Data, noto anche come Semantic Web Layer Cake, saranno descritti di seguito.

Principio 4. L'uso di riferimenti ad altri URI nella descrizione delle entità è essenziale.

RDF consente di limitarsi a una descrizione verbale della risorsa in linguaggio naturale, e il quarto principio invita a non farlo. Con il rispetto universale del primo principio, si apre la possibilità di riferirsi ad altre risorse, comprese quelle "esterne", motivo per cui i dati vengono definiti collegati. È praticamente inevitabile l'uso di URI nominati nel vocabolario RDFS.

RDF

RDF (Resource Description Framework) — è un formalismo per descrivere entità interconnesse.

Le affermazioni riguardo a entità e le loro relazioni sono del tipo "soggetto-predicato-oggetto", noti come triplette. Nel caso più semplice, soggetto, predicato e oggetto sono tutti URI. Lo stesso URI può trovarsi in diverse posizioni nelle varie triplette: può essere sia soggetto, che predicato, che oggetto; in questo modo, le triplette formano una sorta di grafo, chiamato grafo RDF.

I soggetti e gli oggetti possono essere non solo URI, ma anche così detti nodi vuoti, e gli oggetti possono essere anche literal. I literal sono istanze di tipi primitivi, composte da una rappresentazione testuale e da un'indicazione di tipo.

Esempi di scrittura di literal (in sintassi Turtle, di cui parleremo più avanti): "5.0"^^xsd:float e "five"^^xsd:string. I literal di tipo rdf:langString possono essere accompagnati anche da un tag linguistico, in Turtle si scrive così: "five"@en e "пять"@ru.

I nodi vuoti sono risorse "anonime" senza identificatori globali, su cui possono essere tuttavia fatte affermazioni; una sorta di variabili esistenziali.

Quindi (in questo sta, in effetti, tutta la sostanza dell'RDF):

• il soggetto è un URI o un nodo vuoto,
• il predicato è un URI,
• l'oggetto è un URI, un nodo vuoto o un literal.

Perché i predicati non possono essere nodi vuoti?

La probabile ragione è il desiderio di comprendere e tradurre informalmente in linguaggio della logica dei predicati di primo ordine i triplet s p o come qualcosa di simile a , dove — un predicato, e — costanti. Tracce di tale comprensione si trovano nel documento «LBase: Semantics for Languages of the Semantic Web», che ha lo status di nota del gruppo di lavoro W3C. Con tale comprensione, il triplet s p [], dove [] — un nodo vuoto, sarà tradotto come , dove — una variabile, ma come tradurre allora s [] o? Имеющий статус рекомендации W3C документ «Le Semantiche RDF 1.1» propone un altro modo di tradurre, ma la possibilità che i predicati siano nodi vuoti non viene comunque considerata.

Tuttavia, Manu Sporni ha autorizzato.

RDF — è un modello astratto. L'RDF può essere registrato (serializzato) in vari formati: RDF/XML, Turtle (il più leggibile per gli esseri umani), JSON-LD, HDT (binario).

Lo stesso RDF può essere serializzato in RDF/XML in vari modi; quindi, ad esempio, è privo di senso validare l'XML risultante con XSD o cercare di estrarre dati usando XPath. Allo stesso modo, JSON-LD difficilmente soddisferà il desiderio di un comune sviluppatore Javascript di lavorare con RDF utilizzando la notazione puntuale e le parentesi quadre di Javascript (anche se JSON-LD si sta muovendo in questa direzione, offrendo un meccanismo di framing).

La maggior parte delle sintassi offre modalità per abbreviare URI lunghi. Ad esempio, la dichiarazione @prefix rdf: in Turtle permetterà poi di scrivere invece <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> solo rdf:type.

RDFS

RDFS (RDF Schema) — un vocabolario fondamentale per la modellazione, introduce i concetti di proprietà e classe e proprietà come rdf:type, rdfs:subClassOf, rdfs:domain e rdfs:range. Con il vocabolario RDFS possono essere scritte, ad esempio, le seguenti affermazioni valide:

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 è un vocabolario per la descrizione e la modellazione, ma non è un linguaggio di vincoli (anche se la specifica ufficiale e lascia la possibilità di un uso simile). La parola «Schema» non deve essere intesa nello stesso senso in cui è utilizzata nell'espressione «XML Schema». Ad esempio, :author rdfs:range foaf:Person significa che rdf:type tutti i valori della proprietà :author — sono foaf:Person, ma non implica che questo debba essere dichiarato in anticipo.

SPARQL

SPARQL (SPARQL Protocol and RDF Query Language) è un linguaggio di interrogazione per i dati RDF. In un caso semplice, una query SPARQL consiste in un insieme di modelli, con cui vengono confrontati i tripli del grafo interrogato. Nei modelli, le posizioni di soggetti, predicati e oggetti possono contenere variabili.

La query restituirà i valori di tali variabili, che, se sostituite nei modelli, possono generare un sotto-grafo del grafo RDF interrogato (un sottoinsieme dei suoi tripli). Le variabili con lo stesso nome nei diversi modelli di triplet devono avere valori identici.

Ad esempio, sulla base del set di sette assiomi RDFS sopra menzionato, la seguente query restituirà rdfs:domain e rdfs:range come valori ?s e ?p rispettivamente:

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

È importante notare che SPARQL è dichiarativo e non è un linguaggio per la descrizione della navigazione nei grafi (tuttavia, alcuni archivi RDF offrono modi per modificare il piano di esecuzione della query). Pertanto, alcune attività standard sui grafi, come la ricerca del percorso più breve, non possono essere risolte con SPARQL, nemmeno sfruttando il meccanismo property paths (ma, d'altra parte, alcuni archivi RDF offrono estensioni speciali per risolvere questi problemi).

SPARQL non condivide la presunzione di apertura del mondo e segue l'approccio del «negation as failure», in esso sono possibili costruzioni come FILTER NOT EXISTS {…}. La distribuzione dei dati è presa in considerazione tramite il meccanismo di query federate.

Il punto di accesso SPARQL è un archivio RDF in grado di elaborare query SPARQL, senza equivalenti diretti dalla seconda fase (vedi l'inizio di questo paragrafo). Può essere paragonato a un database, la cui contenuto genera pagine HTML, ma accessibile esternamente. Il punto di accesso SPARQL è simile a un punto di accesso API della terza fase, sebbene con due differenze principali. In primo luogo, è possibile unire più richieste 'atomiche' in una (che è considerata una caratteristica chiave di GraphQL); in secondo luogo, tale API è completamente auto-documentata (che era l'obiettivo di HATEOAS).

Osservazione polemica

L'RDF è un modo per pubblicare dati sul web, quindi gli archivi RDF dovrebbero essere considerati come sistemi di gestione di documenti. Tuttavia, poiché l'RDF è un grafo e non un albero, risultano anche grafici. È sorprendente che siano stati realizzati. Chi avrebbe mai pensato che ci sarebbero stati dei geni in grado di realizzare i nodi vuoti? Coddy non ci è riuscito. non ce l'ha fatta.

Ci sono anche modi meno funzionali di organizzare l'accesso ai dati RDF, come ad esempio Linked Data Fragments (LDF) e Linked Data Platform (LDP).

OWL

OWL (Web Ontology Language) — un formalismo di rappresentazione della conoscenza, una variazione sintattica della logica descrittiva (è più corretto parlare di OWL 2, la prima versione di OWL si basava su ).

I concetti delle logiche descrittive in OWL corrispondono a classi, i ruoli — a proprietà, gli individui mantengono il loro nome originale. Anche le assiomi sono chiamate assiomi.

Ad esempio, nel cosiddetto sintassi manchesteriana l'assioma a noi già noto sarà scritto così:

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

Esistono anche altre sintassi per registrare OWL, ad esempio, sintassi funzionale, utilizzata nella specifica ufficiale, e OWL/XML. Inoltre, OWL può essere serializzato in sintassi astratta RDF e successivamente — in una qualsiasi delle sintassi specifiche.

OWL ha un duplice rapporto con RDF. Da un lato, può essere visto come un dizionario, che espande RDFS. Dall'altro lato, è un formalismo più potente, per il quale RDF è solo un formato di serializzazione. Non tutte le strutture elementari di OWL possono essere registrate tramite un singolo tripletto RDF.

A seconda del sottoinsieme di costrutti OWL consentito, si parla di profili OWL. I più standardizzati e noti sono OWL EL, OWL RL e OWL QL. La scelta del profilo influisce sulla complessità computazionale dei compiti tipici. L'insieme completo dei costrutti OWL, corrispondente a , è chiamato OWL DL. A volte si parla anche di OWL Full, in cui i costrutti OWL possono essere utilizzati con piena libertà, tipica di RDF, senza restrizioni semantiche e computazionali . Ad esempio, qualcosa può essere sia una classe che una proprietà. OWL Full è indecidibile.

I principi chiave dell'unione delle conclusioni in OWL sono l'adozione della presunzione di mondo aperto (open world assumption, OWA) e il rifiuto della presunzione di unicità dei nomi (unique name assumption, UNA). Di seguito vedremo a cosa possono portare questi principi e ci familiarizzeremo con alcuni costrutti OWL.

Supponiamo che l'ontologia contenga il seguente frammento (in sintassi manchester):

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

Si deduciamo da quanto detto che John ha molti figli? Il rifiuto di UNA costringerà il motore di inferenza a rispondere negativamente a questa domanda, poiché Alice e Bob potrebbero benissimo essere la stessa persona. Affinché ci sia una deduzione, sarà necessario aggiungere un assioma:

IndividuiDifferenti: Alice, Bob, Carol, John

Supponiamo ora che il frammento dell'ontologia abbia il seguente aspetto (John è dichiarato con molti figli, ma ha solo due bambini indicati):

Classe: moltiFigli
   EquivalenteA: Umano che haFigli min 3
Individuo: John
   Tipi: Umano, moltiFigli
   Fatti: haFiglio Alice, haFiglio Bob
IndividuiDifferenti: Alice, Bob, Carol, John

Questa ontologia sarà contraddittoria (cosa che può essere interpretata come un'indicazione di invalidità dei dati)? L'adozione di OWA costringerà il motore di inferenza a rispondere negativamente: «Altrove» (in un'altra ontologia) potrebbe benissimo essere detto che Carol è anche un figlio di John.

Per escludere questa possibilità, aggiungiamo un nuovo fatto su John:

Individuo: John
   Fatti: haFiglio Alice, haFiglio Bob, non haFiglio Carol

Per escludere la comparsa di altri figli, diciamo che tutti i valori della proprietà «avere un figlio» sono persone, e noi ne abbiamo solo quattro:

ProprietàOggetto: haFiglio
   Dominio: Umano
   Caratteristiche: Irriflessiva
Classe: Umano
EquivalenteA: { Alice, Bill, Carol, John }

Ora l'ontologia diventerà contraddittoria, come il motore di inferenza non mancherà di segnalare. L'ultima delle assiomi ha in qualche modo "chiuso" il mondo, e nota come sia stata esclusa la possibilità che John sia suo stesso bambino.

Collegamento dei dati aziendali

Il set di approcci e tecnologie Linked Data è stato originariamente progettato per la pubblicazione dei dati sul web. Il loro utilizzo all'interno di un ambiente aziendale incontra diverse difficoltà.

Ad esempio, in un ambiente aziendale chiuso la potenza deduttiva di OWL risulta troppo debole, basata sull'accettazione dell'OWA e sul rifiuto dell'UNA — decisioni influenzate dalla natura aperta e distribuita del web. E qui si presentano le seguenti soluzioni.

• Attribuire a OWL una semantica, che implica il rifiuto dell'OWA e l'accettazione dell'UNA, e implementare un motore di inferenza corrispondente. — Si procede lungo questo percorso è il deposito RDF Stardog.
• Rifiuto delle capacità deduttive di OWL a favore dei motori di regole. — Stardog supporta SWRL; Jena e GraphDB offrono i propri linguaggi di regole.
• Rifiuto delle capacità deduttive di OWL, utilizzando per modellare un sottoinsieme specifico, simile a RDFS. — Vedi a riguardo in seguito.

Un altro problema è l'attenzione maggiore che nel mondo aziendale può essere dedicata ai problemi di qualità dei dati, e la mancanza nel stack Linked Data di strumenti per la validazione dei dati. Le uscite qui sono le seguenti.

• Ancora una volta, l'uso di costrutti OWL per la validazione con la semantica del mondo chiuso e l'unicità dei nomi in presenza di un motore di inferenza appropriato.
• L'utilizzo di SHACL, standardizzato già dopo che l'elenco dei layer del Semantic Web Layer Cake è stato fissato (tuttavia, può essere utilizzato anche come motore di regole), oppure ShEx.
• La consapevolezza che tutto viene infine realizzato tramite query SPARQL, la creazione di un semplice meccanismo di validazione dei dati utilizzandole.

Tuttavia, anche una totale rinuncia alle capacità deduttive e agli strumenti di validazione lascia lo stack Linked Data senza competizione in compiti paesaggisticamente simili a quelli del web aperto e distribuito — nelle attività di integrazione dei dati.

Che ne dici di un normale sistema informativo aziendale?

È possibile, ma è importante tenere presente quali problemi devono essere risolti dalle tecnologie appropriate. Descriverò qui una reazione tipica degli sviluppatori per mostrare come appare questo stack tecnologico dalla prospettiva di un IT convenzionale. Ricorda un po' la favola dell'elefante:

• Analista di business: RDF è qualcosa di simile a un modello logico memorizzato direttamente.
• Analista di sistema: RDF è come EAV, solo con una serie di indici e un linguaggio di query comodo.
• Sviluppatore: beh, è tutto nello spirito dei concetti di rich model e low code, ho letto recentemente su questo.
• Responsabile di progetto: ma questo è collapsing the stack!

La pratica dimostra che lo stack viene usato più frequentemente in compiti legati alla distribuzione e all'eterogeneità dei dati, come nella creazione di sistemi di tipo MDM (Master Data Management) o DWH (Data Warehouse). Compiti del genere si trovano in ogni settore.

Per quanto riguarda le applicazioni con specificità settoriale, attualmente le tecnologie Linked Data sono più popolari nei seguenti settori.

• biotecnologie (dove la loro popolarità è evidentemente legata alla complessità dell'argomento);

attuale

Recentemente si è tenuta alla «Punto di Ebollizione» una conferenza organizzata dall'associazione «Base Nazionale delle Conoscenze Mediche» "Unione delle ontologie. Dalla teoria all'applicazione pratica».

• produzione e funzionamento di prodotti complessi (grandi ingegneria meccanica, estrazione di petrolio e gas; si parla più spesso dello standard ISO 15926);

attuale

Anche qui la causa è la complessità del campo soggettivo, quando, ad esempio, nella fase upstream, parlando del settore petrolifero e del gas, è necessario avere determinate funzioni CAD per una contabilità semplice.

Nel 2008 si è tenuta la conferenza inaugurale rappresentativa organizzata dalla Chevron conferenza.

L'ISO 15926 si è rivelato piuttosto complesso per il settore petrolifero e del gas (e ha trovato applicazione per lo più nell'ingegneria meccanica). È stata adottata solo da Statoil (Equinor), in Norvegia si è sviluppato intorno a essa un intero ecosistema. Gli altri cercano di fare qualcosa di proprio. Per esempio, si vocifera che il Ministero dell'Energia nazionale intenda creare un'"ontologia concettuale per il settore energetico", simile, a quanto pare, a quella creata per l'energia elettrica.

• organizzazioni finanziarie (persino l'XBRL può essere visto come una sorta di ibrido tra SDMX e ontologia RDF Data Cube);

attuale

LinkedIn all'inizio dell'anno ha attivamente spammato l'autore con offerte di lavoro da quasi tutti i giganti dell'industria finanziaria, che conosce grazie alla serie 'Suits': Goldman Sachs, JPMorgan Chase e/o Morgan Stanley, Wells Fargo, SWIFT/Visa/Mastercard, Bank of America, Citigroup, la Fed, Deutsche Bank… Probabilmente, tutti cercavano qualcuno da inviare a Knowledge Graph Conference. Molti sono riusciti a trovare: le organizzazioni finanziarie hanno occupato tutto il mattino del primo giorno.

Su HeadHunter, invece, qualcosa di interessante si trovava solo da Sberbank, si parlava di 'una soluzione EAV con un modello di dati simile a RDF'.

Probabilmente, la differenza nel grado di affetto per le relative tecnologie tra le istituzioni finanziarie nazionali e quelle occidentali è dovuta al carattere transnazionale delle ultime. È evidente che le integrazioni attraverso i confini nazionali richiedono soluzioni organizzative e tecniche qualitativamente diverse.

• sistemi di domande e risposte con applicazioni commerciali (IBM Watson, Apple Siri, Google Knowledge Graph);

attuale

A proposito, il creatore di Siri, Thomas Gruber, è l'autore di quella definizione di ontologia (nel senso IT) come "specifica di concettualizzazione". A mio avviso, la ristrutturazione delle parole in questa definizione non altera il suo significato, il che potrebbe suggerire che non ce ne sia affatto.

• pubblicazione di dati strutturati (con una forte base, questo può già essere riferito ai Linked Open Data).

attuale

I grandi sostenitori dei Linked Data sono i cosiddetti GLAM: Gallerie, Biblioteche, Archivi e Musei. Basta dire che, in sostituzione di MARC21, la Biblioteca del Congresso sta promuovendo BIBFRAME, che fornisce una base per il futuro della descrizione bibliografica e, naturalmente, si basa su RDF.

Spesso, come esempio di progetto di successo nel campo dei Linked Open Data, viene citato Wikidata: una sorta di versione leggibile dalle macchine di Wikipedia, il cui contenuto, a differenza di DBPedia, non è generato mediante importazione dai riquadri delle voci, ma è creato più o meno manualmente (e in seguito diventa fonte di informazione per quegli stessi riquadri).

Consigliamo anche di dare un'occhiata lista agli utenti del repository RDF Stardog sul sito di Stardog nella sezione "Clients".

In ogni caso, nel rapporto di Gartner "Hype Cycle for Emerging Technologies" del 2016 «Enterprise Taxonomy and Ontology Management» si trova nel mezzo della discesa nella valle della delusione, con la prospettiva di arrivare al «piano di produttività» non prima di dieci anni.

Collegamento dei Dati Aziendali

Previsioni, previsioni, previsioni…

Per interesse storico, ho riassunto nella tabella sottostante le previsioni di Gartner di diversi anni riguardo le tecnologie che ci interessano.

Tuttavia, già nel «Hype Cycle…» del 2018 è emerso un altro trend ascendente: i Knowledge Graphs. C'è stata una sorta di reincarnazione: i DBMS grafici, su cui è cambiata l'attenzione degli utenti e l'impegno degli sviluppatori, hanno iniziato a delinearsi e a posizionarsi come i loro predecessori concorrenti, influenzati dalle esigenze dei primi e dalle abitudini dei secondi.

Praticamente ogni DBMS grafico ora si proclama una piattaforma adatta per la costruzione del «grafico della conoscenza» aziendale («linked data» è talvolta sostituito da «connected data»), ma fino a che punto sono giustificate tali pretese?

Le basi di dati a grafo rimangono assemantiche; i dati in un DBMS a grafo sono tutti ancora silo di dati. Identificatori basati su stringhe invece di URI rendono compito dell'integrazione di due DBMS a grafo lo stesso compito di integrazione, mentre l'integrazione di due repository RDF spesso si riduce semplicemente a unire due grafi RDF. Un altro aspetto dell'assemanticità è la non riflessività del modello LPG a grafo, che rende difficile gestire i metadati utilizzando la stessa piattaforma.

Infine, i DBMS a grafo non dispongono di motori di inferenza e motori di regole. I risultati di tali motori possono essere riprodotti complicando le query, ma ciò è possibile anche in SQL.

Tuttavia, i principali repository RDF non incontrano difficoltà nel supportare il modello LPG. Il più solido è considerato l'approccio proposto un tempo in Blazegraph: il modello RDF*, che unisce RDF e LPG.

Scopri di più

Ulteriori informazioni sul supporto dei repository RDF per il modello LPG possono essere letti nel precedente articolo su Habr: «Cosa sta succedendo attualmente con i repository RDF». Spero che un giorno venga scritta un articolo separato su Knowledge Graphs e Data Fabric. L'ultimo paragrafo, come è facile capire, è stato scritto di fretta e, d'altra parte, anche dopo sei mesi con queste concezioni, non è molto più chiaro.

Letteratura

1. Halpin, H., Monnin, A. (eds.) (2014). Filosofia dell'Ingegneria: Verso una Filosofia del Web
2. Allemang, D., Hendler, J. (2011) Semantic Web per il Lavoratore Ontologo (2a ed.)
3. Staab, S., Studer, R. (eds.) (2009) Manuale di Ontologie (2a ed.)
4. Wood, D. (ed.). (2011) Collegare i Dati Aziendali
5. Keet, M. (2018) Un'Introduzione all'Ingegneria Ontologica

Fonte: habr.com