Семантичен уеб и свързани данни. Поправки и допълнения

Бих искал да представя на обществеността фрагмент от тази наскоро издадена книга:

Онтологично моделиране на предприятие: методи и технологии [Текст]: монография / [С. В. Горшков, С. С. Кралин, О. И. Муштак и др.; изпълнителен редактор С. В. Горшков]. - Екатеринбург: Издателство на Уралския университет, 2019. - 234 с.: ил., табл.; 20 см. – Автор. посочено на задния синигер. с. — Библиография в края на гл. — ISBN 978-5-7996-2580-1: 200 копия.

Целта на публикуването на този фрагмент в Habré е четири:

• Едва ли някой ще може да държи тази книга в ръцете си, ако не е клиент на уважаван SergeIndex; Определено не се продава.
• Направени са корекции в текста (те не са подчертани по-долу) и са направени допълнения, които не са много съвместими с формата на печатна монография: тематични бележки (под спойлери) и хипервръзки.
• искам да събирайте въпроси и коментари, за да ги вземем предвид при включването на този текст в преработен вид в други публикации.
• Много привърженици на семантичния уеб и свързаните данни все още вярват, че кръгът им е толкова тесен, главно защото на широката публика все още не е обяснено правилно колко страхотно е да си привърженик на семантичния уеб и свързаните данни. Авторът на фрагмента, въпреки че принадлежи към този кръг, не е на това мнение, но въпреки това се смята за длъжен да направи нов опит.

По този начин,

Семантична мрежа

Еволюцията на Интернет може да бъде представена по следния начин (или да говорим за неговите сегменти, които са били формирани в реда, посочен по-долу):

1. Документи в интернет. Ключови технологии - Gopher, FTP и др.
   Интернет е глобална мрежа за обмен на местни ресурси.
2. Интернет документи. Ключови технологии са HTML и HTTP.
   Естеството на откритите ресурси отчита характеристиките на тяхната преносна среда.
3. Интернет данни. Ключови технологии - REST и SOAP API, XHR и др.
   Ерата на интернет приложенията, не само хората стават потребители на ресурси.
4. Интернет данни. Ключовите технологии са технологиите за свързани данни.
   Този четвърти етап, предсказан от Бърнърс-Лий, създателят на вторите основни технологии и директор на W3C, се нарича семантичен уеб; Технологиите за свързани данни са предназначени да направят данните в мрежата не само машинно четими, но и „машинно разбираеми“.

От това, което следва, читателят ще разбере съответствието между ключовите понятия на втория и четвъртия етап:

• URL адресите са аналогични на URI,
• аналогът на HTML е RDF,
• HTML хипервръзките са подобни на URI срещания в RDF документи.

Семантичният уеб е по-скоро системна визия за бъдещето на Интернет, отколкото конкретна спонтанна или лобирана тенденция, въпреки че може да ги вземе предвид. Например, важна характеристика на това, което се нарича Web 2.0, се счита за „генерирано от потребителите съдържание“. По-специално, препоръката на W3C е призована да го вземе предвид "Онтология за уеб анотация„и такова начинание като Солиден.

Мъртъв ли е семантичният уеб?

Ако откажете нереалистични очаквания, ситуацията със семантичната мрежа е приблизително същата като при комунизма по времето на развития социализъм (и нека всеки сам прецени дали се спазва лоялността към условните завети на Илич). Търсачки доста успешно принуждават уебсайтовете да използват RDFa и JSON-LD и самите те използват технологии, свързани с описаните по-долу (Google Knowledge Graph, Bing Knowledge Graph).

В общи линии авторът не може да каже какво пречи на по-голямото разпространение, но може да говори въз основа на личен опит. Има проблеми, които могат да бъдат решени „извън кутията“ в условията на SW настъпление, въпреки че те не са много разпространени. В резултат на това тези, които са изправени пред тези задачи, нямат средства за принуда срещу тези, които са в състояние да предоставят решение, докато независимото предоставяне на решение от последните противоречи на техните бизнес модели. Така че ние продължаваме да анализираме HTML и да слепваме заедно различни API, един друг по-скапан.

Технологиите за свързани данни обаче се разпространиха извън масовата мрежа; Книгата всъщност е посветена на тези приложения. Понастоящем общността на Linked Data очаква тези технологии да станат още по-широко разпространени благодарение на записването (или прокламирането, както желаете) от Gartner на тенденции като Графики на знания и Data Fabric. Бих искал да вярвам, че не "велосипедните" реализации на тези концепции ще бъдат успешни, а тези, свързани със стандартите на W3C, обсъдени по-долу.

Свързани данни

Бърнърс-Лий дефинира свързаните данни като семантична мрежа, „направена правилно“: набор от подходи и технологии, които му позволяват да постигне крайните си цели. Основни принципи на свързаните данни Бърнърс-Лий подчертано следното.

Принцип 1. Използване на URI за именуване на обекти.

URI са глобални идентификатори на обекти, за разлика от локалните низови идентификатори за записи. Впоследствие този принцип беше най-добре изразен в слогана на Google Knowledge Graph „неща, а не струни".

Принцип 2. Използване на URI адреси в HTTP схемата, така че да могат да бъдат премахнати.

Чрез позоваване на URI би трябвало да е възможно да се получи означаваното зад това означаващо (аналогията с името на оператора " е ясна тук).*" в C); по-точно, за да получите някакво представяне на това означавано - в зависимост от стойността на HTTP заглавката Accept:. Може би с настъпването на ерата на AR/VR ще бъде възможно да се получи самият ресурс, но засега най-вероятно това ще бъде RDF документ, който е резултат от изпълнение на SPARQL заявка DESCRIBE.

Принцип 3. Използване на стандарти на W3C - предимно RDF(S) и SPARQL - по-специално при дерефериране на URI.

Тези отделни „слоеве“ от технологичния стек за свързани данни, известен също като Семантичен уеб Layer Cake, ще бъдат описани по-долу.

Принцип 4. Използване на препратки към други URI адреси при описване на обекти.

RDF ви позволява да се ограничите до словесно описание на ресурс на естествен език, а четвъртият принцип призовава да не правите това. Ако първият принцип се спазва универсално, става възможно при описание на ресурс да се препраща към други, включително „чужди“, поради което данните се наричат ​​свързани. Всъщност е почти неизбежно да се използват URI, посочени в речника на RDFS.

RDF

RDF (Рамка за описание на ресурси) е формализъм за описание на взаимосвързани обекти.

Изявления от типа "субект-предикат-обект", наречени триплети, се правят за обекти и техните взаимоотношения. В най-простия случай субектът, предикатът и обектът са URI. Един и същи URI може да бъде на различни позиции в различни триплети: да бъде субект, предикат и обект; По този начин триплетите образуват вид графика, наречена RDF графика.

Субектите и обектите могат да бъдат не само URI, но и т.нар празни възли, а обектите също могат да бъдат литерали. Литералите са екземпляри на примитивни типове, състоящи се от низово представяне и индикация за тип.

Примери за писане на литерали (в синтаксиса на Turtle, повече за него по-долу): "5.0"^^xsd:float и "five"^^xsd:string. Литерали с тип rdf:langString може да бъде оборудван и с езиков таг; в Turtle се пише така: "five"@en и "пять"@ru.

Празните възли са „анонимни“ ресурси без глобални идентификатори, за които обаче могат да се правят изявления; вид екзистенциални променливи.

И така (всъщност това е целият смисъл на RDF):

• темата е URI или празен възел,
• предикатът е URI,
• обектът е URI, празен възел или литерал.

Защо предикатите не могат да бъдат празни възли?

Вероятната причина е желанието за неофициално разбиране и превеждане на триплета на езика на предикатната логика от първи ред s p o като нещо подобно Където - предикат, и - константи. Следи от това разбиране има в документа „LBase: Семантика за езици на семантичния уеб“, която има статут на бележка на работна група на W3C. С това разбиране тройката s p []Където [] - празен възел, ще се преведе като Където - променлива, но как тогава да се преведе s [] o? Документ със статус на препоръка на W3C "Семантика на RDF 1.1” предлага друг метод за превод, но все още не разглежда възможността предикатите да бъдат празни възли.

Въпреки това Ману Спорни позволен.

RDF е абстрактен модел. RDF може да бъде написан (сериализиран) в различни синтаксиси: RDF/XML, костенурка (най-четим от човека), JSON-LD, HDT. (двоичен).

Същият RDF може да бъде сериализиран в RDF/XML по различни начини, така че например няма смисъл да валидирате получения XML с помощта на XSD или да се опитвате да извлечете данни с помощта на XPath. По същия начин JSON-LD е малко вероятно да задоволи желанието на средния разработчик на Javascript да работи с RDF, използвайки нотацията с точки и квадратни скоби на Javascript (въпреки че JSON-LD се движи в тази посока, като предлага механизъм рамкиране).

Повечето синтаксиси предлагат начини за съкращаване на дълги URI. Например реклама @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> в Turtle ще ви позволи да пишете вместо това <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> само rdf:type.

RDFS

RDFS (RDF схема) - основен речник за моделиране, въвежда концепциите за свойство и клас и свойства като rdf:type, rdfs:subClassOf, rdfs:domain и rdfs:range. С помощта на RDFS речника, например, могат да бъдат написани следните валидни изрази:

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 е речник за описание и моделиране, но не е език за ограничения (въпреки че официалната спецификация и листа възможност за такова използване). Думата "схема" не трябва да се разбира в същия смисъл като израза "XML схема". Например, :author rdfs:range foaf:Person означава, че rdf:type всички стойности на имотите :author - foaf:Person, но не означава, че това трябва да се каже предварително.

SPARQL

SPARQL (SPARQL Protocol and RDF Query Language) – език за запитване към RDF данни. В прост случай SPARQL заявката е набор от проби, спрямо които се съпоставят триплети от графиката, за която се иска. Моделите могат да съдържат променливи в позиции на субект, предикат и обект.

Заявката ще върне такива променливи стойности, които, когато бъдат заменени в извадките, могат да доведат до подграф на заявената RDF графика (подмножество от нейните триплети). Променливите с едно и също име в различни проби от триплети трябва да имат еднакви стойности.

Например, предвид горния набор от седем RDFS аксиоми, следната заявка ще се върне rdfs:domain и rdfs:range като ценности ?s и ?p съответно:

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

Струва си да се отбележи, че SPARQL е декларативен и не е език за описване на обхождане на графа (обаче някои RDF магазини предлагат начини за коригиране на плана за изпълнение на заявката). Следователно, някои стандартни графични проблеми, например намиране на най-краткия път, не могат да бъдат решени в SPARQL, включително използването на имотни пътища (но, отново, отделните RDF хранилища предлагат специални разширения за решаване на тези проблеми).

SPARQL не споделя презумпцията за отвореност на света и следва подхода „отрицание като провал“, в който възможен дизайни като FILTER NOT EXISTS {…}. Разпределението на данните се взема предвид с помощта на механизма обединени заявки.

SPARQL точката за достъп - RDF хранилище, способно да обработва SPARQL заявки - няма директни аналози от втория етап (вижте началото на този параграф). Може да се оприличи на база данни, въз основа на чието съдържание са генерирани HTML страници, но достъпни отвън. SPARQL точката за достъп е по-аналогична на API точката за достъп от третия етап, но с две основни разлики. Първо, възможно е да се комбинират няколко „атомарни“ заявки в една (което се счита за ключова характеристика на GraphQL), и второ, такъв API е напълно самодокументиращ се (което се опита да постигне HATEOAS).

Полемична забележка

RDF е начин за публикуване на данни в мрежата, така че съхранението на RDF трябва да се счита за СУБД за документи. Вярно, тъй като RDF е графика, а не дърво, те също се оказаха базирани на графики. Удивително е, че изобщо се получи. Кой би предположил, че ще има умни хора, които ще внедрят празни възли. Код е тук не се получи.

Има и по-малко пълнофункционални начини за организиране на достъп до RDF данни, например, Свързани фрагменти от данни (LDF) и Свързана платформа за данни (LDP).

OWL

OWL (Web Ontology Language) - формализъм за представяне на знания, синтактична версия на логиката на описанието (навсякъде по-долу е по-правилно да се каже OWL 2, първата версия на OWL е базирана на ).

Концепциите на описателната логика в OWL съответстват на класове, ролите съответстват на свойства, индивидите запазват предишното си име. Аксиомите се наричат ​​още аксиоми.

Например в т.нар Синтаксис на Манчестър за OWL нотация аксиома, която вече ни е известна ще бъде написана така:

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

Има и други синтаксиси за писане на OWL, като напр функционален синтаксис, използвани в официалната спецификация, и OWL/XML. Освен това OWL може да бъде сериализиран за абстрактен RDF синтаксис и по-нататък - във всеки от специфичните синтаксиси.

OWL има двойна връзка с RDF. От една страна, може да се разглежда като вид речник, който разширява RDFS. От друга страна, това е по-мощен формализъм, за който RDF е просто формат за сериализация. Не всички елементарни OWL конструкции могат да бъдат написани с помощта на един RDF триплет.

В зависимост от това кое подмножество от OWL конструкции е позволено да се използва, те говорят за т.нар OWL профили. Стандартизираните и най-известните са OWL EL, OWL RL и OWL QL. Изборът на профил влияе върху изчислителната сложност на типичните проблеми. Пълен набор от OWL конструкции, съответстващи на , наречен OWL DL. Понякога те също говорят за OWL Full, в който OWL конструкциите могат да се използват с пълната свобода, присъща на RDF, без семантични и изчислителни ограничения . Например, нещо може да бъде както клас, така и свойство. OWL Full не може да се реши.

Ключовите принципи за свързване на последствията в OWL са възприемането на предположението за отворен свят. OWA) и отхвърляне на презумпцията за уникални имена (предположение за уникално име, А). По-долу ще видим докъде могат да доведат тези принципи и ще представим някои конструкции на OWL.

Нека онтологията съдържа следния фрагмент (в синтаксиса на Манчестър):

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

Дали от казаното ще следва, че Йоан има много деца? Отхвърлянето на UNA ще принуди машината за изводи да отговори отрицателно на този въпрос, тъй като Алис и Боб може да са едно и също лице. За да се случи следното е необходимо да се добави следната аксиома:

DifferentIndividuals: Alice, Bob, Carol, John

Нека сега онтологичният фрагмент има следната форма (Джон е обявен за многодетен, но той има само две деца):

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

Ще бъде ли тази онтология непоследователна (което може да се тълкува като доказателство за невалидни данни)? Приемането на OWA ще накара механизма за изводи да отговори отрицателно: „някъде“ другаде (в друга онтология) може да се каже, че Карол също е дете на Джон.

За да изключим възможността за това, нека добавим нов факт за Джон:

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

За да изключим появата на други деца, нека кажем, че всички стойности на имота „имащ дете“ са хора, от които имаме само четирима:

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

Сега онтологията ще стане противоречива, което машината за изводи няма да пропусне да отчете. С последната от аксиомите ние в известен смисъл „затворихме“ света и забележете как се изключва възможността Джон да бъде негово дете.

Свързване на корпоративни данни

Наборът от подходи и технологии за свързани данни първоначално е предназначен за публикуване на данни в мрежата. Използването им във вътрешна корпоративна среда е изправено пред редица трудности.

Например, в затворена корпоративна среда, дедуктивната сила на OWL, основана на приемането на OWA и отхвърлянето на UNA, решения, дължащи се на отворения и разпределен характер на мрежата, е твърде слаба. И тук са възможни следните решения.

• Предоставяне на OWL със семантика, което предполага изоставяне на OWA и приемане на UNA, внедряване на съответния изходен двигател. - По тази пътека върви Stardog RDF съхранение.
• Изоставяне на дедуктивните способности на OWL в полза на двигатели с правила. — Stardog поддържа SWRL; Jena и GraphDB предлагат собствен езици правила
• Отказ от дедуктивните възможности на OWL, използване на едно или друго подмножество, близко до RDFS за моделиране. - Вижте повече за това по-долу.

Друг проблем е по-големият фокус, който корпоративният свят може да има върху проблемите с качеството на данните и липсата на инструменти за валидиране на данни в стека от свързани данни. Резултатите тук са както следва.

• Отново, използвайте за валидиране на OWL конструкции със семантика на затворен свят и уникални имена, ако е наличен подходящ двигател за изводи.
• Употреба SHACLили Шекс.
• Разбиране, че всичко в крайна сметка се прави със SPARQL заявки, създаване на ваш собствен прост механизъм за валидиране на данни, като ги използвате.

Въпреки това, дори пълното отхвърляне на дедуктивните възможности и инструментите за валидиране оставя стека от свързани данни извън конкуренцията в задачи, които са подобни на ландшафта на отворената и разпределена мрежа - в задачите за интегриране на данни.

Какво ще кажете за обикновена корпоративна информационна система?

Това е възможно, но, разбира се, трябва да сте наясно какви точно проблеми ще трябва да решат съответните технологии. Тук ще опиша типична реакция на участниците в разработката, за да покажа как изглежда този технологичен стек от гледна точка на конвенционалните ИТ. Напомня ми малко на притчата за слона:

• Бизнес анализатор: RDF е нещо като директно запаметен логически модел.
• Системен анализатор: RDF е като EAV разширение, само с куп индекси и удобен език за заявки.
• предприемач: добре, всичко това е в духа на концепциите за богат модел и нисък код, четеше наскоро за това.
• Ръководител на проекта: да, същото е свиване на стека!

Практиката показва, че стекът най-често се използва в задачи, свързани с разпределението и разнородността на данните, например при изграждане на системи от клас MDM (Master Data Management) или DWH (Data Warehouse). Такива проблеми съществуват във всяка индустрия.

По отношение на специфични за индустрията приложения, технологиите за свързани данни в момента са най-популярни в следните индустрии.

• биомедицински технологии (където тяхната популярност изглежда е свързана със сложността на областта);

текущ

„Точката на кипене” наскоро беше домакин на конференция, организирана от сдружение „Национална база медицински знания”Комбиниране на онтологии. От теория към практическо приложение".

• производство и експлоатация на сложни продукти (голямо машиностроене, добив на нефт и газ; най-често говорим за стандартни ISO 15926);

текущ

И тук причината е сложността на предметната област, когато например на етапа нагоре по веригата, ако говорим за нефтената и газовата индустрия, простото счетоводство изисква някои CAD функции.

През 2008 г. се проведе представително инсталационно събитие, организирано от Шеврон конференция.

В крайна сметка ISO 15926 изглеждаше малко тежък за нефтената и газовата индустрия (и може би намери по-голямо приложение в машиностроенето). Само Statoil (Equinor) се пристрасти напълно към него; в Норвегия цял екосистема. Други се опитват да направят своето. Например, според слуховете, вътрешното министерство на енергетиката възнамерява да създаде „концептуален онтологичен модел на горивно-енергийния комплекс“, подобно, очевидно, на създаден за електроенергийната индустрия.

• финансови организации (дори XBRL може да се счита за вид хибрид на SDMX и онтологията RDF Data Cube);

текущ

В началото на годината LinkedIn активно спами автора със свободни позиции от почти всички гиганти на финансовата индустрия, които той познава от сериала „Непреодолима сила”: Goldman Sachs, JPMorgan Chase и/или Morgan Stanley, Wells Fargo, SWIFT/Visa/Mastercard, Bank of America, Citigroup, Fed, Deutsche Bank... Вероятно всеки е търсил някого, на когото да изпрати Конференция на Графа на знанието. Доста успяха да намерят: финансовите организации взеха всичко сутринта на първия ден.

В HeadHunter само Sberbank се натъкна на нещо интересно; става дума за „EAV съхранение с RDF-подобен модел на данни“.

Вероятно разликата в степента на любов към съответните технологии на местните и западните финансови институции се дължи на транснационалния характер на дейността на последните. Очевидно трансграничната интеграция изисква качествено различни организационни и технически решения.

• системи за въпроси и отговори с търговски приложения (IBM Watson, Apple Siri, Google Knowledge Graph);

текущ

Между другото, създателят на Siri Томас Грубер е автор на самата дефиниция на онтологията (в ИТ смисъл) като „спецификация на концептуализацията“. Според мен пренареждането на думите в това определение не променя смисъла му, което може би показва, че го няма.

• публикуване на структурирани данни (с по-голямо основание това може да се припише на свързани отворени данни).

текущ

Големи фенове на свързаните данни са така наречените GLAM: галерии, библиотеки, архиви и музеи. Достатъчно е да се каже, че Библиотеката на Конгреса насърчава заместител на MARC21 BIBRAMEКойто осигурява основа за бъдещето на библиографското описание и, разбира се, базирани на RDF.

Wikidata често се цитира като пример за успешен проект в областта на свързаните отворени данни - вид машинно четима версия на Wikipedia, чието съдържание, за разлика от DBPedia, не се генерира чрез импортиране от инфобокети за статии, а е създаден повече или по-малко ръчно (и впоследствие се превръща в източник на информация за същите информационни кутии).

Също така ви препоръчваме да го проверите списък потребители на RDF хранилището на Stardog на уебсайта на Stardog в раздела „Клиенти“.

Както и да е, в Gartner Hype Cycle за нововъзникващи технологии 2016 „Управление на таксономията и онтологията на предприятието“ е поставено в средата на спускане в долината на разочарованието с перспективата за достигане на „плато на производителността“ не по-рано от 10 години.

Свързване на корпоративни данни

Прогнози, прогнози, прогнози...

От исторически интерес, по-долу направих таблица с прогнозите на Gartner за различни години относно технологиите, които ни интересуват.

Година	Технология	Доклад	Позиция	Години до плато
2001	Семантична мрежа	Възникващи технологии	Иновационен тригер	5-10
2006	Корпоративен семантичен уеб	Възникващи технологии	Пик на завишените очаквания	5-10
2012	Семантична мрежа	Голямо количество от данни	Пик на завишените очаквания	> 10
2015	Свързани данни	Разширен анализ и наука за данни	Корито на разочарованието	5-10
2016	Управление на корпоративни онтологии	Възникващи технологии	Корито на разочарованието	> 10
2018	Графики на знания	Възникващи технологии	Иновационен тригер	5-10

Въпреки това, вече в "Хайп цикъл..." 2018 г се появи друга възходяща тенденция - Графиките на знанието. Настъпи известно превъплъщение: графичните СУБД, към които вниманието на потребителите и усилията на разработчиците се оказаха превключени, под влияние на исканията на първите и навиците на вторите, започнаха да приемат контури и позициониране на своите предшественици конкуренти.

Почти всяка графична СУБД вече се обявява за подходяща платформа за изграждане на корпоративна „графа на знания“ („свързаните данни“ понякога се заменят с „свързани данни“), но доколко са оправдани подобни твърдения?

Графичните бази данни все още са асемантични; данните в графовата СУБД са все същият силоз за данни. Идентификаторите на низове вместо URI правят задачата за интегриране на две графични СУБД все още задача за интегриране, докато интегрирането на две RDF хранилища често се свежда до просто сливане на две RDF графики. Друг аспект на асемантичността е нерефлексивността на графичния модел на LPG, което затруднява управлението на метаданни с помощта на същата платформа.

И накрая, графичните СУБД нямат машини за изводи или машини за правила. Резултатите от такива машини могат да бъдат възпроизведени чрез усложняване на заявки, но това е възможно дори в SQL.

Водещите RDF системи за съхранение обаче нямат затруднения да поддържат модела LPG. Най-солидният подход се счита за този, предложен навремето в Blazegraph: RDF* моделът, комбиниращ RDF и LPG.

Още

Можете да прочетете повече за поддръжката на RDF съхранение за LPG модела в предишната статия на Habré: „Какво се случва с RDF хранилището сега“. Надявам се един ден да бъде написана отделна статия за Графиките на знанието и Data Fabric. Последният раздел, както е лесно да се разбере, е написан набързо, но дори шест месеца по-късно всичко не е много по-ясно с тези концепции.

Литература

1. Halpin, H., Monnin, A. (eds.) (2014). Философско инженерство: към философия на мрежата
2. Allemang, D., Hendler, J. (2011) Semantic Web for the Working Ontologist (2-ро изд.)
3. Staab, S., Studer, R. (eds.) (2009) Наръчник за онтологии (2-ро издание)
4. Ууд, Д. (ред.). (2011) Свързване на корпоративни данни
5. Keet, M. (2018) Въведение в онтологичното инженерство

Източник: www.habr.com