Semantic Web och Linked Data. Korrigeringar och tillägg

Jag vill presentera ett avsnitt från denna nyligen utgivna bok:

Ontologisk modellering av företag: metoder och teknologier [Text]: monografi / [S. V. Gorshkov, S. S. Kralin, O. I. Mushtak m.fl.; ansvarig redaktör S. V. Gorshkov]. — Jekaterinburg: Ural universitet förlag, 2019. — 234 s.: ill., tabeller; 20 cm. — Författarna är angivna på baksidan av titelbladet. — Bibliografi i slutet av kapitlen. — ISBN 978-5-7996-2580-1: 200 ex.

Syftet med att publicera detta avsnitt på Habr är mångfacetterat:

• Det är osannolikt att någon kommer att kunna hålla den här boken i handen om man inte är kund till den respektabla SergeIndex; den finns absolut inte till försäljning.
• Texten har ändrats (de nedan anges inte på något sätt) och innehåller tillägg som inte riktigt är förenliga med formatet för tryckta monografier: aktuella kommentarer (under spoilrar) och hyperlänkar.
• Jag skulle vilja samla frågor och kommentarer, för att ta hänsyn till dem vid inkluderingen av denna text i en reviderad form i andra publikationer.
• Många förespråkare av Semantic Web och Linked Data anser fortfarande att deras krets är så snäv huvudsakligen för att den breda allmänheten fortfarande inte har fått en ordentlig förklaring av hur fantastiskt det är att vara förespråkare av Semantic Web och Linked Data. Författaren av avsnittet, även om han tillhör denna krets, delar inte denna uppfattning, men anser sig ändå skyldig att göra ytterligare ett försök.

Så,

Semantic Web

Utvecklingen av internet kan beskrivas som följer (eller man kan tala om dess segment som har formats i den angivna ordningen):

1. Dokument på internet. Nyckelteknologier — Gopher, FTP m.fl.
   Internet är ett globalt nätverk för utbyte av lokala resurser.
2. Internet av dokument. Nyckelteknologier — HTML och HTTP.
   Karaktären av de resurser som ställs ut tar hänsyn till egenskaperna hos den miljö de överförs i.
3. Data på internet. Nyckelteknologier — REST och SOAP API, XHR osv.
   Epoken av internetapplikationer, vars konsumenter av resurser inte bara är människor.
4. Internet av data. Nyckelteknologier — teknologier för Linked Data.
   Detta fjärde steg, som förutsägs av Berners-Lee, skaparen av nyckelteknologierna för det andra och direktör för W3C, kallas Semantic Web; teknologier för Linked Data syftar till att göra data på webben inte bara maskinläsbara utan också 'maskinförståeliga'.

Av det som följer kommer läsaren att förstå överensstämmelsen mellan nyckelbegreppen i det andra och fjärde steget:

• URL motsvarar URI,
• HTML motsvarar RDF,
• HTML-länkar motsvarar URI-förekomster i RDF-dokument.

Semantic Web är snarare en systemisk vision av framtidens internet än en specifik impulsiv eller lobbad trend, även om det kan ta hänsyn till dessa senare. Till exempel betraktas "användarskapat innehåll" som en viktig egenskap hos det som kallas Web 2.0. Det är syftet med, bland annat, W3C:s rekommendation "Web Annotation Ontology" och en sådan initiativ som Solid.

Är Semantic Web dött?

Om man avstår från orealistiska förväntningar, är situationen med det semantiska webben ungefär densamma som med kommunismen under utvecklat socialismen (och om man verkligen ska följa de hypotetiska buden av Illich, får var och en avgöra själv). Sökmaskiner lyckas ganska bra tvinga webbplatser att använda RDFa och JSON-LD och använder själva teknologier som är besläktade med de som beskrivs nedan (Google Knowledge Graph, Bing Knowledge Graph).

I allmänna termer kan författaren inte säga vad som hindrar en större spridning, men kan yttra sig baserat på personlig erfarenhet. Det finns uppgifter som skulle lösas "ur lådan" under omständigheterna av SW, även om de inte är särskilt vanliga. Följaktligen har de som ställs inför dessa problem inga medel att tvångsmässigt påverka dem som kan erbjuda lösningen, och att förse sig själva med lösningen av dessa senare motverkar deras affärsmodeller. Så vi fortsätter att avläsa HTML och sammanfoga olika API:er, en i sin tur sämre.

Trots detta har Linked Data-teknologierna spridits även utanför det massiva webben; dessa tillämpningar ägnas så att säga i boken. För närvarande förväntar sig Linked Data-gemenskapen att dessa teknologier kommer att få ännu större spridning tack vare att Gartner har bekräftat (eller proklamerat, vad man nu föredrar) sådana trender som Knowledge Graphs och Data Fabric. Man hoppas att inte "cykel"-implementationer av dessa koncept kommer att få framgång, utan sådana som är relaterade till de standarder som W3C behandlar.

Linked Data

Berners-Lee definierade Linked Data som ett "välgjort" semantiskt web: en uppsättning tillvägagångssätt och teknologier för att nå dess slutmål. De grundläggande principerna för Linked Data som Berners-Lee framhöll följande.

Princip 1. Användning av URI för att namnge enheter.

URI är globala identifierare av entiteter till skillnad från lokala strängidentifierare för poster. Det bästa uttrycket för denna princip återfinns senare i Googles Knowledge Graph-slogan «things, not strings».

Princip 2. Att använda URI i HTTP-schemat så att de kan derefereras.

Genom att hänvisa till en URI bör det vara möjligt att få tag på det som representeras av detta betydelsebärande (den här analogin kan förstås med namnet på operatören «*» i C); närmare bestämt, att få en viss representation av denna betydelse - beroende på värdet av HTTP-huvudet Accept:. Kanske, med uppkomsten av AR/VR-eran kan man få tillgång till själva resursen; hittills kommer det förmodligen att vara ett RDF-dokument, som är resultatet av att köra en SPARQL-fråga. DESCRIBE.

Princip 3. Att använda W3C-standarder - framför allt RDF(S) och SPARQL - specifikt vid dereferens av URI.

Dessa separata "lager" i Linked Data-teknologisteget, som också är känt som Semantic Web Layer Cake, kommer att beskrivas längre fram.

Princip 4. Att använda referenser till andra URI vid beskrivning av entiteter.

RDF tillåter att man kan begränsa sig till en verbal beskrivning av en resurs på ett naturligt språk, men den fjärde principen uppmanar till att inte göra detta. Med allmän respekt för den första principen öppnas möjligheten att vid beskrivning av en resurs referera till andra, inklusive "främmande", vilket är anledningen till att data kallas länkade. Faktum är att användningen av URI, som namnges i RDFS-ordlistan, är nästan oundviklig.

RDF

RDF (Resource Description Framework) - ett formellt system för att beskriva sammanlänkade entiteter.

Om entiteter och deras relationer görs påståenden av typen "subjekt-predikat-objekt", som kallas tripletter. I enklaste fall kan subjekt, predikat och objekt vara URI. Den samma URI kan stå i olika positioner i olika tripletter: vara både subjekt, predikat och objekt; därmed bildar tripletterna en slags graf, som kallas RDF-graf.

Subjekt och objekt kan vara inte bara URI, utan också så kallade tomma noder, och objekt kan dessutom vara literalvärden. Literalvärden är instanser av primitiva typer, bestående av en strängrepresentation och en typangivelse.

Exempel på notation av literalvärden (i Turtle-syntax, som beskrivs nedan): "5.0"^^xsd:float och "five"^^xsd:string. Literalvärden av typen rdf:langString kan dessutom förses med en språktagg, vilket i Turtle skrivs sådan här: "five"@en och "fem"@ru.

Tomma noder är "anonyma" resurser utan globala identifierare, om vilka dock påståenden kan göras; en slags existentiella variabler.

Så (detta är i själva verket hela essensen av RDF):

• subjektet är en URI eller tom nod,
• predikatet är en URI,
• objektet är en URI, tom nod eller litteral.

Varför kan inte predikat bli tomma noder?

En trolig anledning är viljan att informellt förstå och översätta till språket för första ordningens predikatlogik triplet s p o som något liknande , där — predikat, och — konstanter. Spår av denna förståelse finns i dokumentet "LBase: Semantics for Languages of the Semantic Web", vilket har status som notering för W3C:s arbetsgrupp. Med detta förstående kommer triplet s p [], där [] — tom nod, att översättas som , där — variabel, men hur ska man då översätta s [] o? Имеющий статус рекомендации W3C документ «RDF 1.1 Semantics» erbjuder ett annat sätt att översätta, men möjligheten för predikat att vara tomma noder övervägs fortfarande inte.

Förresten, Manu Sporni har tillåtit.

RDF — en abstrakt modell. RDF kan skrivas (serialiseras) i olika syntaxer: RDF/XML, Turtle (den mest läsbara), JSON-LD, HDT (binär).

Det samma RDF kan serialiseras i RDF/XML på olika sätt, varför det, till exempel, är meningslöst att validera den resulterande XML med XSD eller att försöka extrahera data med XPath. På samma sätt är JSON-LD osannolikt att tillfredsställa den vanliga Javascript-utvecklaren som vill arbeta med RDF med hjälp av punkt- och fyrkantig notering i Javascript (även om JSON-LD rör sig i den riktningen, och erbjuder en mekanism för framing).

De flesta syntaxer erbjuder sätt att förkorta långa URI:er. Till exempel, deklarationen @prefix rdf: i Turtle tillåter att man sedan kan skriva istället för <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> enkel rdf:type.

RDFS

RDFS (RDF Schema) — en basordbok för modellering, introducerar begrepp om egenskaper och klasser samt sådana egenskaper som rdf:type, rdfs:subClassOf, rdfs:domain och rdfs:range. Med hjälp av RDFS-ordboken kan följande korrekta uttryck skrivas:

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 är en ordbok för beskrivning och modellering, men är inte ett språk för begränsningar (även om den officiella specifikationen och lämnar möjligheten till en sådan användning). Ordet "Schema" bör inte förstås i samma mening som i uttrycket "XML Schema". Till exempel, :author rdfs:range foaf:Person betyder att rdf:type alla värden för egenskapen :author — foaf:Person, men innebär inte att detta ska anges i förväg.

SPARQL

SPARQL (SPARQL-protokoll och RDF-frågespråk) — ett frågespråk för RDF-data. I sin enklaste form utgör en SPARQL-fråga en uppsättning mönster som matchas mot tripplarna i den frågade grafen. Mönstren kan ha variabler i positionerna för subjekt, predikat och objekt.

Frågan kommer att returnera sådana värden för variablerna, vid insättning av vilka i mönstren kan man få en undergraf av den frågade RDF-grafen (en delmängd av dess tripplar). Variabler med samma namn i olika mönster av tripplar bör ha samma värden.

Till exempel, utifrån den ovan nämnda uppsättningen av sju RDFS-axiom, kommer följande fråga att returnera rdfs:domain och rdfs:range som värden ?s och ?p respektive:

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

Det är värt att notera att SPARQL är deklarativ och inte är ett språk för att beskriva genomgång av grafen (även om vissa RDF-lager erbjuder sätt att justera frågans exekveringsplan). Därför kan vissa standardgrafuppgifter, till exempel att hitta den kortaste vägen, inte lösas med SPARQL, inte ens med mekanismen property paths (men, som sagt, vissa RDF-lager erbjuder speciella tillägg för att lösa dessa uppgifter).

SPARQL delar inte den öppna världens antagande och följer metoden "negation as failure", i den är möjliga sådana konstruktioner som FILTER NOT EXISTS {…}. Datafördelningen beaktas med hjälp av mekanismen federativa frågor.

En SPARQL-slutpunkt — ett RDF-lager som kan hantera SPARQL-frågor — har inga direkta motsvarigheter från den andra etappen (se början av detta avsnitt). Den kan liknas vid en databas, baserat på vars innehåll HTML-sidor genererades, men tillgänglig utanför. SPARQL-slutpunkten är snarare en liknelse till en API-slutpunkt från den tredje etappen, men med två huvudsakliga skillnader. För det första, finns det möjlighet att kombinera flera "atomiska" frågor till en (vilket anses vara en nyckelfunktion i GraphQL), för det andra, är en sådan API helt själv-dokumenterad (vilket HATEOAS försökte uppnå).

Polemiskt påpekande

RDF är en metod för att publicera data på webben, så RDF-lager bör betraktas som dokumentdatabaser. Men eftersom RDF är en graf och inte ett träd, blir de också grafbaserade. Det är överraskande att de överhuvudtaget uppstod. Vem skulle ha trott att det skulle finnas smarta personer som implementerar blandnoder. Hos Codd lyckades det inte han.

Det finns även mindre fullfungerande sätt att organisera åtkomst till RDF-data, till exempel Linked Data Fragments (LDF) och Linked Data Platform (LDP).

OWL

OWL (Web Ontology Language) är en formalisering av kunskapsrepresentation, en syntaktisk variant av beskrivande logik (det är mer korrekt att kalla det OWL 2 nedan, den första versionen av OWL grundades på ).

Koncept av beskrivande logik motsvaras av klasser, roller motsvarar egenskaper, individer behåller sina tidigare namn. Axiomen kallas också axiomer.

Till exempel, i det så kallade Manchester-syntaxen för att skriva OWL kommer den redan kända axiomen att skrivas så här: Class: Human Class: Parent EquivalentClass: Human and (inverse hasParent) some Human ObjectProperty: hasParent

Det finns även andra syntaxer för att skriva OWL, till exempel

funktionell syntax , som används i den officiella specifikationen, ochOWL/XML . Dessutom kan OWL serialiserasi abstrakt RDF-syntax och sedan i vilken konkret syntax som helst. OWL har ett dubbelt förhållande till RDF. Å ena sidan kan det ses som en slags ordbok som utökar RDFS. Å andra sidan är det en kraftfullare formalisering för vilken RDF bara är ett serialiseringsformat. Inte alla elementära konstruktioner i OWL kan skrivas med en enda RDF-triplett.

Beroende på vilket delmängd av konstruktioner i OWL som är tillåtna, talar man om så kallade

OWL-profiler. De standardiserade och mest kända är OWL EL, OWL RL och OWL QL. Valet av profil påverkar den beräkningsmässiga komplexiteten av typiska uppgifter. Den fullständiga uppsättningen av OWL-konstruktioner kallasOWL DL. Ibland talar man också om OWL Full, där konstruktioner av OWL får användas med full frihet, som är egen för RDF, utan semantiska och beräkningsmässiga begränsningar. Till exempel kan något vara både en klass och en egenskap. OWL Full är odefinierbar. De nyckelprinciper för att dra slutsatser i OWL är antagandet om öppen värld (open world assumption,

OWA ) och avvisandet av antagandet om unika namn (unique name assumption,UNA )). Nedan ska vi se vad dessa principer kan leda till och bekanta oss med vissa OWL-konstruktioner.

Anta att ontologin innehåller följande fragment (i Manchester-syntax):

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

Följer det av det som sagts att John har många barn? Avvisandet av UNA kommer att få slutledningsmotorn att svara nej på denna fråga, eftersom Alice och Bob mycket väl kan vara samma person. För att en följd ska gälla krävs det att en sådan axiom läggs till:

DifferentIndividuals: Alice, Bob, Carol, John

Anta nu att ontologifragmente ser ut som följer (John har deklarerats som flerbarnsförälder, men han har angivits endast med två barn):

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

Kommer denna ontologi att vara motsägelsefull (vilket kan tolkas som ett bevis på ogiltiga data)? Antagandet av OWA kommer att få slutledningsmotorn att svara negativt: "någonstans" i en annan ontologi kan det mycket väl stå att Carol också är Johns barn.

För att utesluta denna möjlighet lägger vi till en ny fakta om John:

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

För att utesluta förekomsten av andra barn, låt oss säga att alla värden av egenskapen "ha barn" är de människor vi har totalt fyra av:

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

Nu kommer ontologin att bli motsägelsefull, vilket slutledningsmotorn inte kommer att misslyckas med att rapportera. Med den senaste axiomen har vi på något sätt "stängt" världen och notera hur möjligheten att John är sitt eget barn utesluts.

Länkande företagsdata

En uppsättning tillvägagångssätt och teknologier för Linked Data var ursprungligen avsedda för publicering av data på webben. Att använda dem i en intern företagsmiljö stöter på flera svårigheter.

Till exempel visar sig den deduktiva kraften hos OWL, baserad på antagandet av OWA och avvisandet av UNA — lösningar som beror på webbens öppna och distribuerade natur — vara för svag i en sluten företagsmiljö. Här är möjliga utvägar.

• Att ge OWL semantik som innefattar avvisande av OWA och godkännande av UNA, implementering av en motsvarande slutledningsmotor. — På detta sätt går RDF-lagringslösningen Stardog.
• Avstående från deduktiva möjligheter i OWL till förmån för regelmotorer. — Stardog stödjer SWRL; Jena och GraphDB erbjuder egna språk för regler.
• Avstående från deduktiva möjligheter i OWL, användning för att modellera en viss delmängd nära RDFS. — Se mer om detta nedan.

Ett annat problem är det större fokus som möjligtvis kan läggas på datakvalitetsproblem i företagssvärlden, och avsaknaden av verktyg för datavalidering i Linked Data-stacken. Möjligheterna här är följande.

• Återigen, användning för validering av OWL-konstruktioner med slutenvärldens semantik och unikhet av namn förutsatt att motsvarande slutmotor finns.
• Användning SHACL, standardiserad efter att lagren i Semantic Web Layer Cake har fastställts (dock kan den även användas som en regelmotor), eller ShEx.
• Medvetenhet om att allt i slutändan görs med SPARQL-frågor, skapa en egen enkel datavalideringsmekanism med dess hjälp.

Trots detta lämnar en total avståelse från deduktiva möjligheter och valideringsverktyg Linked Data-stacken oemotståndlig i uppgifter som har en liknande karaktär som en öppen och distribuerad webb — i dataintegrationsuppgifter.

Hur är det med ett vanligt företags informationssystem?

Det är möjligt, men man bör absolut vara medveten om vilka problem de relevanta teknologierna behöver lösa. Jag kommer att beskriva en typisk reaktion från utvecklingsdeltagarna för att visa hur denna teknologistack ser ut ur ett konventionellt IT-perspektiv. Det påminner lite om sagan om elefanten:

• Affärsanalytiker: RDF är något slags direkt lagrad logisk modell.
• Systemanalytiker: RDF är som EAV, bara med massor av index och ett bekvämt frågespråk.
• Utvecklare: ja, det är allt i linje med koncepten rich model och low code, läste nyligen om detta.
• Projektledare: ja, det är som collapsing the stack!

Erfarenhet visar att stacken oftast används i uppgifter relaterade till distribution och heterogen data, till exempel vid byggande av system av klass MDM (Master Data Management) eller DWH (Data Warehouse). Sådana uppgifter finns inom alla branscher.

När det gäller tillämpningar med branschspecifik karaktär är Linked Data-teknologier just nu mest populära inom följande branscher.

• biomedicinsk teknik (där dess popularitet tydligen är kopplad till komplexiteten i ämnesområdet);

aktuell

Nyligen hölls i "Kokpunkten" en konferens som organiserades av föreningen "Nationell medicinsk kunskapsdatabas" "Sammanställning av ontologier. Från teori till praktisk tillämpning».

• tillverkning och drift av komplexa produkter (stort maskinkonstruktion, olje- och gasutvinning; det handlar oftast om standarden ISO 15926);

aktuell

Här är också orsaken komplexiteten i ämnesområdet, när man t.ex. i upstream-fasen, i olje- och gasbranschen, enkelt redovisande behöver vissa CAD-funktioner.

År 2008 hölls en representativ installationskonferens organiserad av Chevron konferens.

ISO 15926 visade sig i slutändan vara rätt tung för olje- och gasindustrin (och trots allt fick den mer tillämpning inom maskinkonstruktion). Endast Statoil (Equinor) har haft en betydande förankring kring den i Norge, där en hel ekosystem. Andra försöker göra något eget. Till exempel, enligt rykten, avser det ryska energiministeriet att skapa en "konceptuell ontologisk modell för energisektorn", som tydligen liknar den som skapades för elenergisektorn.

• finansiella organisationer (även XBRL kan betraktas som en form av hybrid mellan SDMX och RDF Datakub);

aktuell

LinkedIn spammade i början av året aktivt författaren med jobb från näst intill alla giganter inom finanssektorn, som han känner till från TV-serien "Suits": Goldman Sachs, JPMorgan Chase och/eller Morgan Stanley, Wells Fargo, SWIFT/Visa/Mastercard, Bank of America, Citigroup, Federal Reserve, Deutsche Bank… Troligtvis letade alla efter någon som kunde skickas till Knowledge Graph Conference. Många lyckades hitta det: finansorganisationerna tog över hela förmiddagen den första dagen.

På HeadHunter dök något intressant upp endast hos Sberbank, där det handlade om "EAV-lager med en RDF-liknande datamodell".

Troligtvis beror skillnaden i graden av kärlek till relevanta teknologier mellan inhemska och västerländska finansiella institutioner på den transnationella karaktären hos de senare. Det verkar som om integrationer över statsgränser kräver kvalitativt olika organisatoriska och tekniska lösningar.

• fråge-svarssystem med kommersiell tillämpning (IBM Watson, Apple Siri, Google Knowledge Graph);

aktuell

För övrigt är skaparen av Siri, Thomas Gruber, författaren till den definition av ontologi (i IT-sammanhang) som beskriver det som "specifikation av konceptualisering". Enligt min mening förändrar inte omkastningen av ord i denna definition dess betydelse, vilket möjligen tyder på att den inte finns där.

• publicering av strukturerade data (detta kan med god grund hänvisas till Linked Open Data).

aktuell

Stora entusiaster av Linked Data är de så kallade GLAM: Gallerier, Bibliotek, Arkiv och Museer. Här kan det räcka att säga att Biblioteket i Kongressen främjar BIBFRAME, som ger en grund för framtiden för bibliografisk beskrivning och, självklart, är baserad på RDF.

Ofta nämns Wikidata som ett exempel på ett framgångsrikt projekt inom Linked Open Data – en typ av maskinläsbar version av Wikipedia, vars innehåll, i motsats till DBPedia, inte genereras genom att importera från infoboxar i artiklar, utan skapas mer eller mindre manuellt (och senare blir en informationskälla för samma infoboxar).

Vi rekommenderar också att bekanta sig med listan användarna av RDF-lagret Stardog på Stardogs webbplats i avsnittet "Customers".

Hur som helst, i Gartners "Hype Cycle for Emerging Technologies" 2016 "Enterprise Taxonomy and Ontology Management" placeras mitt ute i dalen av besvikelser med utsikter att nå "produktivitetens platå" om inte tidigare än om 10 år.

Connecting Enterprise Data

Prognoser, prognoser, prognoser...

Av historiskt intresse sammanställde jag följande tabell över Gartners prognoser från olika år angående de teknologier som intresserar oss.

Å andra sidan, redan i "Hype Cycle..." 2018 framträdde en annan uppåtgående trend – Knowledge Graphs. Det skedde en slags reinkarnation: grafdatabaser, som fick användarnas och utvecklarnas fokus, började ta form och positionera sig i relation till sina föregångare och konkurrenter.

Nästan varje grafdatabas utger sig nu för att vara en lämplig plattform för att bygga företags "kunskapsgraf" ("linked data" ersätts ibland med "connected data"), men hur berättigade är sådana anspråk?

Grafdatabaser är fortfarande asemaniska, data i grafdatabasen är fortfarande samma datasilon. Strängidentifierare istället för URI gör integrering av två grafdatabaser till samma utmaning som innan, medan integrering av två RDF-lager ofta reduceras till att bara kombinera två RDF-grafer. En annan aspekt av asemaniskhet är den icke-reflexiva grafmodellen LPG, vilket gör hantering av metadata med samma plattform svår.

Slutligen saknar grafdatabaser utförande- och reglermotorer. Resultaten från sådana motorer kan återskapas genom att komplicera förfrågningarna, men det är möjligt även i SQL.

Ledande RDF-lager har dock inga problem med att stödja LPG-modellen. Den mest solida ansatsen anses vara den som en gång föreslogs av Blazegraph: RDF*-modellen som kombinerar RDF och LPG.

Läs mer

Mer om stödet från RDF-lager för LPG-modellen kan läsas i den tidigare artikeln på Habré: "Vad som händer med RDF-lager just nu". För Knowledge Graphs och Data Fabric hoppas jag att en separat artikel en dag kommer att skrivas. Slutsatskapitlet, som man lätt kan förstå, skrevs hastigt, och även efter sex månader är dessa koncept inte mycket klarare.

Litteratur

1. Halpin, H., Monnin, A. (red.) (2014). Filosofisk Ingenjörskonst: Mot en Filosofi för Webben
2. Allemang, D., Hendler, J. (2011) Semantisk Web för den Arbetsande Ontologen (2:a uppl.)
3. Staab, S., Studer, R. (red.) (2009) Handbok om Ontologier (2:a uppl.)
4. Wood, D. (red.). (2011) Länka Företagsdata
5. Keet, M. (2018) En Introduktion till Ontologisk Ingenjörskonst

Källa: habr.com