Semantic Web e Linked Data. Correzioni e integrazioni

Voglio presentare al pubblico un estratto di questo libro recentemente pubblicato:

Modellazione ontologica dell'impresa: metodi e tecnologie [Testo]: monografia / [S. V. Gorškov, S. S. Kralin, O. I. Muštak e altri; redattore responsabile S. V. Gorškov]. — Ekaterinburg: Editore dell'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 esemplari.

L'obiettivo della pubblicazione di questo estratto su Habr è quadruplo:

• È improbabile che qualcuno possa tenere questo libro tra le mani, a meno che non sia cliente di un rispettabile SergeIndex; non è assolutamente in vendita.
• Il testo è stato corretto (le modifiche non sono evidenziate di seguito) e sono state aggiunte integrazioni non molto compatibili con il formato della monografia stampata: note tempestive (sotto spoiler) e collegamenti ipertestuali.
• Si desidera raccogliere domande e osservazioni, per tenerne conto nell'inclusione di questo testo in una forma rielaborata in altre pubblicazioni.
• Molti sostenitori del Semantic Web e dei Linked Data ritengono ancora che il loro ambito sia così ristretto principalmente perché al grande pubblico non è ancora spiegato adeguatamente quanto sia fantastico essere un sostenitore del Semantic Web e dei Linked Data. L'autore dell'estratto, sebbene appartenga a questo gruppo, non condivide questa opinione, ma si sente comunque obbligato a fare un ulteriore tentativo.

Quindi,

Semantic Web

L'evoluzione di Internet può essere presentata nel seguente modo (o si può parlare dei suoi segmenti, formatisi nell'ordine indicato di seguito):

1. Documenti su internet. Tecnologie chiave: Gopher, FTP e simili.
   Internet è una rete globale per lo scambio di risorse locali.
2. Documenti di internet. Tecnologie chiave: HTML e HTTP.
   La natura delle risorse esposte tiene conto delle peculiarità del loro trasferimento.
3. Dati su internet. Tecnologie chiave: REST e SOAP API, XHR e così via.
   L'era delle applicazioni web, i consumatori delle risorse non sono solo le persone.
4. Internet dei dati. Tecnologie chiave: tecnologie Linked Data.
   Questa quarta fase, prevista da Berners-Lee, creatore delle tecnologie chiave della seconda fase e direttore del W3C, è chiamata Semantic Web; le tecnologie Linked Data sono destinate a rendere i dati sul web non solo leggibili dalle macchine, ma anche "comprensibili dalle macchine".

Dalla lettura successiva, il lettore comprenderà la corrispondenza tra i concetti chiave della seconda e della quarta fase:

• gli URI sono analoghi agli URL,
• l'analogon dell'HTML è il RDF,
• le ipertesti HTML corrispondono alle occorrenze di URI nei documenti RDF.

Il Semantic Web è più una visione sistemica del futuro di Internet che una tendenza spontanea o sponsorizzata, sebbene possa considerare anche queste ultime. Ad esempio, una caratteristica importante di ciò che si definisce Web 2.0 è il "contenuto generato dagli utenti". Questo è, in particolare, ciò che la raccomandazione W3C "Web Annotation Ontology" e iniziative come Solid.

Il Semantic Web è morto?

Se lasciamo da parte le aspettative irrealistiche, la situazione del web semantico è simile a quella del comunismo ai tempi del socialismo sviluppato (e se si mantiene la fedeltà ai precetti di Lenin, ognuno può decidere da solo). I motori di ricerca costringono piuttosto efficacemente i siti web ad utilizzare RDFa e JSON-LD e utilizzano essi stessi tecnologie simili a quelle descritte in seguito (Google Knowledge Graph, Bing Knowledge Graph).

In generale, l'autore non può dire cosa ostacoli una maggiore diffusione, ma può esprimere il suo parere basato sull'esperienza personale. Ci sono compiti che sarebbero stati risolti "out of the box" nel caso di attuazione del SW, sebbene non siano molto comuni. Di conseguenza, coloro a cui questi compiti sono inculcati non hanno mezzi per costringere chi può fornire la soluzione, mentre la fornitura autonoma della soluzione da parte di questi ultimi contrasta con i loro modelli di business. Quindi continuiamo a fare il parsing dell'HTML e a concatenare diverse API, una peggiore dell'altra.

Tuttavia, le tecnologie dei Linked Data si sono diffuse anche oltre il web di massa; la presente opera è dedicata a tali applicazioni. Attualmente, la comunità dei Linked Data si aspetta che queste tecnologie trovino una diffusione ancora maggiore grazie alla conferma (o proclamazione, come piace a qualcuno) da parte di Gartner di tendenze come Knowledge Graphs e Data Fabric. Ci si augura che abbiano successo non le implementazioni "fai da te" di questi concetti, ma quelle legate agli standard W3C che saranno esaminati in seguito.

Linked Data

Berners-Lee definiva i Linked Data come il "web semantico ben fatto": un insieme di approcci e tecnologie che permettono di raggiungere i suoi obiettivi finali. I principi fondamentali dei Linked Data enunciati da Berners-Lee sono i seguenti.

Principio 1. Utilizzare URI per nominare entità.

Gli URI sono identificatori globali di entità in contrapposizione agli identificatori di record basati su stringhe locali. Successivamente, la migliore espressione di questo principio è stata trovata nello slogan di Google Knowledge Graph «cose, non stringhe».

Principio 2. L'uso degli URI nello schema HTTP, in modo che possano essere dereferenziati.

Rivolgendosi a un URI, dovrebbe essere possibile ottenere il significato dietro questo significante (qui l'analogia con il nome dell'operatore «*» in C); più precisamente, ottenere una certa rappresentazione di quel significato - a seconda del valore dell'intestazione HTTP Accept:. Forse, con l'arrivo dell'era AR/VR, sarà possibile ottenere la risorsa stessa, mentre ora, molto probabilmente, sarà un documento RDF risultante dall'esecuzione di una query SPARQL DESCRIVI.

Principio 3. L'uso degli standard W3C - in primo luogo, RDF(S) e SPARQL - in particolare, durante il dereferenziamento degli URI.

Questi singoli «strati» del stack tecnologico dei Linked Data, noto anche come Semantic Web Layer Cake, saranno descritti successivamente.

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

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, diventa possibile fare riferimento a altre risorse, comprese quelle «estranee», il che porta ai dati ad essere chiamati collegati. In effetti, è quasi inevitabile l'uso di URI nominati nel vocabolario RDFS.

RDF

RDF (Resource Description Framework) - un formalismo per la descrizione di entità interconnesse.

Di entità e delle loro interrelazioni vengono formulate affermazioni di tipo «soggetto-predicato-oggetto», chiamate triplette. Nel caso più semplice sia il soggetto, sia il predicato, sia l'oggetto sono URI. Lo stesso URI può trovarsi in diverse posizioni in diverse triplette: 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 quelli che vengono definiti nodi vuoti, e gli oggetti possono essere anche litera. Le litere sono istanze di tipi primitivi, costituite da una rappresentazione stringa e dall'indicazione del tipo.

Esempi di scrittura delle litere (in sintassi Turtle, di cui parleremo più avanti): "5.0"^^xsd:float e "cinque"^^xsd:string. Le litere con tipo rdf:langString possono essere dotate anche di un tag linguistico, che in Turtle si scrive così: "cinque"@en e "cinque"@it.

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

Quindi (in questo, in fondo, sta tutta l'essenza di RDF):

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

Perché i predicati non possono essere nodi vuoti?

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

Tuttavia, Manu Sporni ha permesso.

RDF è un modello astratto. RDF può essere registrato (serializzato) in vari sintassi: 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, l'XML risultante è senza senso da validare con XSD o cercare di estrarre dati con XPath. Allo stesso modo, JSON-LD difficilmente soddisferà il desiderio di un normale sviluppatore Javascript di lavorare con RDF utilizzando la notazione puntuale e quadra Javascript (anche se JSON-LD sta progredendo in questa direzione, offrendo un meccanismo di framing.).

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

RDFS

RDFS (RDF Schema) è un vocabolario di base per la modellazione, introduce concetti di proprietà e classe e proprietà quali rdf:type, rdfs:subClassOf, rdfs:domain e rdfs:range. Tramite il vocabolario RDFS possono essere registrate, ad esempio, le seguenti espressioni 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 di descrizione e modellazione, ma non è un linguaggio di vincoli (anche se la specifica ufficiale e lascia) la possibilità di tale utilizzo). La parola «Schema» non deve essere intesa nello stesso senso dell'espressione «XML Schema». Ad esempio, :author rdfs:range foaf:Person significa che rdf:type di tutti i valori della proprietà :author — foaf:Person, ma non significa che questo debba essere dichiarato in anticipo.

SPARQL

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

La query restituirà tali valori delle variabili, in cui la sostituzione nei pattern può dar luogo a un sottografi del grafo RDF interrogato (sottoinsieme dei suoi tripli). Le variabili con lo stesso nome nei diversi pattern dei tripli devono avere gli stessi valori.

Ad esempio, nel set di sette assiomi RDFS sopra riportato, 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 .
}

Vale la pena notare che SPARQL è dichiarativo e non è un linguaggio per la descrizione dell'attraversamento del grafo (tuttavia, alcuni archivi RDF offrono modi per modificare il piano di esecuzione della query). Pertanto, alcune operazioni standard sui grafi, come la ricerca del percorso più breve, non possono essere risolte in SPARQL, incluso l'uso del meccanismo property paths (ma, ancora una volta, alcuni archivi RDF offrono estensioni speciali per risolvere tali problemi).

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

Il punto di accesso SPARQL — un archivio RDF in grado di gestire query SPARQL — non ha analoghi diretti della seconda fase (vedi l'inizio di questo paragrafo). Può essere paragonato a un database, sulla base del quale sono state generate pagine HTML, ma accessibile dall'esterno. Il punto di accesso SPARQL è più simile a un punto di accesso API della terza fase, tuttavia con due principali differenze. In primo luogo, esiste la possibilità di combinare più query «atomiche» in una (cosa considerata una caratteristica fondamentale di GraphQL), in secondo luogo, tale API è completamente auto-documentata (cosa che HATEOAS ha cercato di raggiungere).

Osservazione polemica

RDF è un modo di pubblicare dati sul web, quindi i repository RDF dovrebbero essere considerati come DBMS documentali. Tuttavia, poiché RDF è un grafo e non un albero, sono anche risultati essere grafici. È sorprendente che siano addirittura emersi. Chi avrebbe mai pensato che ci sarebbero stati dei geni in grado di implementare i nodi vuoti. Codda qui non ci è riuscito..

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

OWL

OWL (Web Ontology Language) è un formalismo per la rappresentazione delle conoscenze, una variante sintattica della logica descrittiva (è più corretto parlare di OWL 2, la prima versione di OWL era basata su ).

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

Ad esempio, nella cosiddetta sintassi manchesteriana per scrivere OWL, l'assioma a noi noto verrà scritto così:

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

Ci sono anche altre sintassi per scrivere OWL, ad esempio, la 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 concrete.

OWL in relazione a RDF ha un duplice aspetto. Dalla sua parte, può essere considerato come una sorta di dizionario che espande RDFS. D'altra parte, questo è un formalismo più potente per il quale RDF è solo un formato di serializzazione. Non tutte le costruzioni elementari di OWL possono essere scritte tramite un singolo triplet RDF.

A seconda di quale sottoinsieme di costruzioni OWL è consentito utilizzare, si parla dei cosiddetti profili OWL.I profili standardizzati e più noti sono OWL EL, OWL RL e OWL QL. La scelta del profilo influisce sulla complessità computazionale dei problemi tipici. L'insieme completo delle costruzioni OWL, corrispondente , è chiamato OWL DL. A volte si parla anche di OWL Full, in cui le costruzioni di OWL possono essere utilizzate con la totale libertà caratteristica di RDF, senza limitazioni semantiche e computazionali. Ad esempio, qualcosa può essere sia una classe che una proprietà. OWL Full non è risolvibile.

I principi chiave dell'inferenza in OWL sono l'accettazione dell'assunzione del mondo aperto (open world assumption, OWA) e il rifiuto dell'assunzione di unicità dei nomi (unique name assumption, UNA). Di seguito vedremo a cosa possono portare questi principi e ci familiarizzeremo con alcune costruzioni 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

Deriverà da quanto detto che John ha molti figli? L'abbandono di UNA porterà il motore di inferenza a rispondere negativamente a questa domanda, poiché Alice e Bob potrebbero tranquillamente essere la stessa persona. Affinché l'inferenza si verifichi, sarà necessario aggiungere un assioma come il seguente:

DifferentIndividuals: Alice, Bob, Carol, John

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

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

Questa ontologia sarà contraddittoria (che può essere interpretata come una prova di invalidità dei dati)? L'accettazione di OWA porterà il motore di inferenza a rispondere negativamente: "da qualche parte" (in un'altra ontologia) potrebbe benissimo essere detto che Carol è anch'essa figlia di John.

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

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

Per escludere la comparsa di altri figli, diciamo che tutti i valori della proprietà "avere un bambino" sono persone, delle quali abbiamo solo quattro:

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

Ora l'ontologia diventerà contraddittoria, come non mancherà di far sapere il motore di inferenza. Con l'ultima delle assioma in un certo senso abbiamo "chiuso" il mondo, e notate come è stata esclusa la possibilità che John sia figlio di se stesso.

Collegare i Dati Aziendali

Un insieme di approcci e tecnologie Linked Data è stato originariamente progettato per la pubblicazione dei dati sul web. L'uso in ambienti aziendali interni presenta una serie di difficoltà.

Ad esempio, in un ambiente aziendale chiuso, la forza deduttiva di OWL, fondata sull'accettazione di OWA e il rifiuto di UNA — scelte determinate dalla natura aperta e distribuita del web — si dimostra troppo debole. E qui si possono trovare le seguenti soluzioni.

• Dotare OWL di semantica, che implica il rifiuto di OWA e l'accettazione di UNA, realizzazione di un motore di inferenza adeguato. — Su questa strada si procede RDF-store Stardog.
• Rifiuto delle capacità deduttive di OWL a favore dei motori di regole. — Stardog supporta SWRL; Jena e GraphDB offrono linguaggi di regole. Rifiuto delle capacità deduttive di OWL, utilizzando per la modellazione un sottoinsieme specifico simile a RDFS. — Vedi di seguito.
• Un altro problema è la maggiore attenzione che nel mondo aziendale è possibile dedicare ai problemi di qualità dei dati e la mancanza di strumenti di validazione dei dati nello stack Linked Data. Le soluzioni qui sono le seguenti.

Ancora una volta, l'utilizzo per la validazione delle costruzioni OWL con semantica del mondo chiuso e unicità dei nomi in presenza di un motore di inferenza adeguato.

• SHACL
• Utilizzo , standardizzato dopo che l'elenco dei livelli del Semantic Web Layer Cake era stato definito (tuttavia, può essere utilizzato anche come motore di regole), oppureShEx Consapevolezza che alla fine tutto viene fatto tramite query SPARQL, creazione di un meccanismo semplice di validazione dei dati utilizzando tali query..
• Tuttavia, anche il completo rifiuto delle capacità deduttive e degli strumenti di validazione lascia lo stack Linked Data senza concorrenza nelle attività simili a quelle del web aperto e distribuito—nell'integrazione dei dati.

Cosa dire di un normale sistema informativo aziendale?

È possibile, ma bisogna, naturalmente, rendersi conto di quali problemi specifici dovranno essere risolti dalle tecnologie pertinenti. Qui descriverò la reazione tipica dei partecipanti allo sviluppo, per mostrare com'è questo stack tecnologico dal punto di vista dell'IT convenzionale. Ricorda un po' la parabola dell'elefante:

Business analyst

• : RDF è qualcosa di tipo un modello logico conservato direttamente.Analista di sistema
• : RDF è come, solo con un sacco di indici e un linguaggio di query comodo. EAV: beh, è tutto nello spirito delle concetti di rich model e low code,
• Sviluppatoreho letto recentemente su questo. : ma questo è
• Responsabile del progettocollapsing the stack La pratica mostra che lo stack è utilizzato più frequentemente in attività legate alla distribuzione e alla eterogeneità dei dati, ad esempio nella costruzione di sistemi di tipo MDM (Master Data Management) o DWH (Data Warehouse). Queste esigenze sono presenti in qualsiasi settore.!

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

Per quanto riguarda le applicazioni specifiche del settore, attualmente le tecnologie Linked Data sono più popolari nei seguenti settori.

• tecnologie biomediche (dove la loro popolarità sembra essere legata alla complessità dell'area tematica);

attuale

Recentemente, presso il "Punto di Ebollizione", si è tenuta una conferenza organizzata dall'associazione "Banca Nazionale delle Conoscenze Mediche" "Integrazione delle ontologie. Dalla teoria all'applicazione pratica».

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

attuale

Qui la causa è anche la complessità dell'area tematica, quando, ad esempio, nella fase upstream, se parliamo del settore petrolifero e del gas, è necessario avere alcune funzioni CAD di un semplice sistema di contabilità.

Nel 2008 si è tenuta una conferenza di avvio rappresentativa organizzata dalla Chevron conferenza.

L'ISO 15926 si è alla fine rivelato piuttosto pesante per il settore petrolifero e del gas (e a malapena ha trovato una maggiore applicazione nell'ingegneria meccanica). Solo Statoil (Equinor) lo ha adottato seriamente, in Norvegia si è formata un'intera ecosistema. Gli altri cercano di fare qualcosa di proprio. Ad esempio, secondo voci, il Ministero dell'Energia nazionale intende lavorare alla creazione di un "modello ontologico concettuale del settore energetico", simile, a quanto pare, creato per l'energia elettrica.

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

attuale

LinkedIn all'inizio dell'anno ha attivamente inviato messaggi agli autori delle offerte di lavoro di 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, FED, Deutsche Bank… Probabilmente, tutti cercavano qualcuno da inviare alla Knowledge Graph Conference. Molti sono riusciti a trovare: le organizzazioni finanziarie hanno occupato tutto la mattina del primo giorno.

Su HeadHunter, invece, c'era qualcosa di interessante solo presso Sberbank, si parlava di "archivio EAV con modello dati simile a RDF".

Probabilmente, la differenza nella misura dell'interesse per le tecnologie corrispondenti tra le istituzioni finanziarie nazionali e occidentali è dovuta alla natura transnazionale delle ultime. A quanto pare, le integrazioni che attraversano i confini nazionali richiedono soluzioni organizzative e tecniche di qualità diversa.

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

attuale

A proposito, il creatore di Siri, Thomas Gruber, è l'autore della definizione di ontologia (in senso IT) come «specifica di concettualizzazione». A mio avviso, il riordino delle parole in questa definizione non ne cambia il senso, il che potrebbe suggerire che in essa non ci sia nulla.

• pubblicazione di dati strutturati (con una base solida, questo potrebbe già essere attribuito a Linked Open Data).

attuale

Grandi sostenitori dei Linked Data sono i cosiddetti GLAM: Gallerie, Biblioteche, Archivi e Musei. Qui basta dire che, in sostituzione di MARC21, la Biblioteca del Congresso promuove 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, si menziona Wikidata: una sorta di versione leggibile dalle macchine di Wikipedia, il cui contenuto, a differenza di DBPedia, non è generato tramite importazione dalle infobox degli articoli, ma creato più o meno manualmente (e successivamente diventa fonte di informazioni per le stesse infobox).

Raccomandiamo anche di dare un'occhiata la lista agli utenti dello storage RDF Stardog sul sito di Stardog nella sezione «Customers».

Comunque sia, nel rapporto di Gartner «Hype Cycle for Emerging Technologies» del 2016 la «Gestione della Tassonomia e dell'Ontologia Aziendale» è collocata in mezzo al calo verso la valle della delusione, con la prospettiva di raggiungere il «livello di produttività» non prima di 10 anni.

Collegare i Dati Aziendali

Previsioni, previsioni, previsioni...

Per interesse storico, ho riassunto in una tabella qui sotto le previsioni di Gartner di vari anni sui tecnologie che ci interessano.

Tuttavia, già nel «Hype Cycle...» del 2018 è emerso un altro trend in crescita: i Knowledge Graphs. Si è verificata una sorta di reincarnazione: i database grafici, su cui si sono concentrati l'attenzione degli utenti e gli sforzi degli sviluppatori, sotto l'influenza delle richieste dei primi e delle abitudini dei secondi, hanno iniziato a prendere forma e a posizionarsi rispetto ai loro predecessori concorrenti.

Praticamente ogni database grafico ora si dichiara una piattaforma adatta per costruire un «graph di conoscenza» aziendale («linked data» a volte è sostituito da «connected data»), ma quanto sono giustificati tali pretese?

I database a grafo rimangono assemantici, i dati in un DBMS a grafo sono comunque silo di dati. Gli identificatori di stringa al posto degli URI rendono l'integrazione di due DBMS a grafo la medesima sfida di integrazione, mentre l'integrazione di due repository RDF spesso si riduce semplicemente alla fusione di due grafi RDF. Un altro aspetto dell'assemanicità è la non riflessività del modello grafico LPG, che rende difficile la gestione dei metadati utilizzando la stessa piattaforma.

Infine, i DBMS a grafo non dispongono di motori inferenziali e di motori per le regole. I risultati di tali motori possono essere riprodotti tramite la complessità delle query, ma ciò è possibile anche in SQL.

Tuttavia, i principali repository RDF non hanno difficoltà a supportare il modello LPG. L'approccio considerato più solido è quello proposto tempo fa in Blazegraph: il modello RDF*, che unisce RDF e LPG.

Scopri di più

Per ulteriori dettagli sul supporto del modello LPG da parte dei repository RDF, si può leggere il 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. La sezione finale, come si può facilmente capire, è stata scritta in fretta, e dopotutto, anche dopo sei mesi con questi concetti, non è molto più chiaro.

Letteratura

1. Halpin, H., Monnin, A. (a cura di) (2014). Filosofia dell'Ingegneria: Verso una Filosofia del Web
2. Allemang, D., Hendler, J. (2011) Semantic Web for the Working Ontologist (2a ed.)
3. Staab, S., Studer, R. (a cura di) (2009) Manuale sulle Ontologie (2a ed.)
4. Wood, D. (a cura di). (2011) Linking Enterprise Data
5. Keet, M. (2018) Un'Introduzione all'Ingegneria delle Ontologie

Fonte: habr.com