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

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

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

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

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

И така,

Semantic Web

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

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

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

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

Семантичната мрежа е по-скоро системна представа за бъдещето на интернет, отколкото конкретен спонтанен или лобистки тренд, макар че може да отчита и последните. Например, важна характеристика на това, което се нарича Web 2.0, е 'съдържанието, създадено от потребителите'. Това трябва да бъде взето под внимание, в частност, от препоръката на W3C 'Web Annotation Ontology' и инициативата, наречена Solid.

Мъртва ли е семантичната мрежа?

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

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

Въпреки това, технологиите Linked Data получиха разпространение и извън масовия уеб; на това приложение всъщност е посветена книгата. В момента общността Linked Data очаква тези технологии да получат още по-широко приложение благодарение на фиксирането (или провъзгласяването, както някому харесва) от Gartner на такива трендове като Knowledge Graphs и Data Fabric. Искрено се надявам, че успешни ще бъдат не 'велосипедните' реализации на тези концепции, а онези, които имат отношение към разглежданите по-долу стандарти на W3C.

Linked Data

Бернерс-Ли определя Linked Data като 'правилно направен' семантичен уеб: съвкупност от подходи и технологии, позволяващи постигането на крайните му цели. Основните принципи на Linked Data, които Бернерс-Ли изведе са следните.

Принцип 1. Използване на URI за именуване на съществата.

URI са глобални идентификационни знаци на обекти, за разлика от локалните стрингови идентификатори на записи. По-късно най-доброто изразяване на този принцип беше открито в слогана на Google Knowledge Graph «вещи, а не низове».

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

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

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

Тези отделни „слоеве“ на стека технологии, известен също като Semantic Web Layer Cake, ще бъдат описани по-долу.

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

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

RDF

RDF (Resource Description Framework) — формализм за описание на взаимосвързани обекти.

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

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

Примери за запис на литерали (в синтаксиса Turtle, за който ще говорим по-късно): "5.0"^^xsd:float и "five"^^xsd:string. Литералите с тип rdf:langString могат да бъдат снабдени и с езиков таг, в Turtle това се записва така: "five"@en и "пет"@bg.

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

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

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

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

Вероятната причина — желанието неформално да се разбира и превежда на езика на логиката на предикатите от първи ред троицата s p o като нещо подобно , където — предикат, и — константи. Следи от такова разбиране има в документа "LBase: Семантика за езици на семантичната мрежа", който има статус на бележка на работна група W3C. При това разбиране троицата s p [], където [] — празен възел, ще бъде преведен като , където — променлива, но как тогава да се преведе s [] o? Имеющий статус рекомендации W3C документ «RDF 1.1 Семантика" предлага друг начин на превод, но възможността предикатите да бъдат празни възли все пак не се разглежда.

Впрочем, Ману Спорни разрешили.

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

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

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

RDFS

RDFS (RDF Schema) — основен речник за моделиране, въвежда понятията свойство и клас и такива свойства, като 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 е речник за описание и моделиране, но не е език за ограничения (въпреки че официалната спецификация и оставя възможност за подобно използване). Думата «Schema» не трябва да се разбира в същия смисъл, както в израза «XML Schema». Например, :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, включително и чрез използване на механизма property paths (но отново, отделни RDF-хранилища предлагат специализирани разширения за решаване на тези задачи).

SPARQL не разделя презумпцията за откритост на света и следва подхода «negation as failure», в него са възможни такива конструкции, като FILTER NOT EXISTS {…}. Разпределеността на данните се взема под внимание чрез механизма федеративни запитвания.

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

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

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

Съществуват и по-малко функционални начини за организиране на достъп до RDF данни, например, Linked Data Fragments (LDF) и Linked Data Platform (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 — приемането на презумпцията за отворен свят (open world assumption, OWA) и отказът от презумпцията за уникалност на имената (unique name assumption, UNA). По-долу ще видим какво могат да доведат тези принципи и ще се запознаем с някои конструкции на 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, реализация на съответния логически двигател. — По такъв начин продължава RDF-хранилище Stardog.
• Отказ от дедуктивните възможности на OWL в полза на двигатели за правила. — Stardog поддържа SWRL; Jena и GraphDB предлагат собствени езици на правила.
• Отказ от дедуктивните възможности на OWL, използване за моделиране на определено подмножество, близко до RDFS. — Вижте по-подробно по-късно.

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

• Отново, използването за валидиране на конструкции на OWL с семантика на затворен свят и уникалност на имената при наличието на съответен двигател за извеждане.
• Използване SHACL, стандартизиран вече след като списъкът на слоевете в Semantic Web Layer Cake е фиксиран (въпреки че може да се използва и като двигател за правила), или ShEx.
• Осъзнаването, че всичко в крайна сметка се прави чрез SPARQL заявки, създаването на собствен несложен механизъм за валидиране на данни с тях.

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

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

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

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

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

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

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

актуално

В „Точка на кипене“ наскоро се проведе конференция, организирана от асоциацията „Национална база медицински знания“ „Обединение на онтологиите. От теория към практически приложения».

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

актуално

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

През 2008 година се проведе учредителна конференция.

ISO 15926 в крайна сметка се оказа твърде сложен за нефтено-газовата индустрия (и едва ли е намерил по-широко приложение в машиностроенето). Основно на него се наложи вероятно Statoil (Equinor), в Норвегия около него се създадe цяла екосистема. Други се опитват да правят нещо свое. Например, според слуховете, родното Минпечат има намерение да се занимава със създаването на „концептуална онтологична модел на ТЕЦ“, аналогична, вероятно, създадената за електрическите мрежи.

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

актуално

LinkedIn в началото на годината активно изпращаше покани на автора със запитвания от почти всички гиганти на финансовата индустрия, които познава от сериала „Форс-мажори“: Goldman Sachs, JPMorgan Chase и/или Morgan Stanley, Wells Fargo, SWIFT/Visa/Mastercard, Bank of America, Citigroup, ФРС, Deutsche Bank… Вероятно всички търсеха някого, който да изпратят на Knowledge Graph Conference. Успяха да намерят доста хора: финансовите организации заеха всичко сутринта на първия ден.

На HeadHunter обаче нещо интересно се срещаше само при Сбербанк, ставаше дума за „EAV-хранилище с RDF-подобна модел на данни“.

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

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

актуално

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

• публикация на структурирани данни (с основание това може да бъде свързано с Linked Open Data).

актуално

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

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

Препоръчваме също да се запознаете списък с потребителите на RDF хранилище Stardog на сайта на Stardog в раздела "Клиенти".

Както и да е, в гартнеровския "Hype Cycle for Emerging Technologies" за 2016 година "Управление на корпоративна таксономия и онтология" е поставен в средата на спускането в долината на разочарованието с изглед за достигане на "плато на продуктивността" не по-рано от 10 години.

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

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

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

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

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

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

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

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

Научете повече

Подробности за подкрепата на RDF хранилищата на модела LPG могат да се прочетат в предишната статия на Хабра: „Какво се случва с RDF хранилищата сега“. Надявам се, че за Knowledge Graphs и Data Fabric ще бъде написана отделна статия. Заключителният раздел, както е лесно да се разбере, е дописван в бързина, но дори и след половин година, с тези концепции, все още не е много по-ясно.

Литература

1. Halpin, H., Monnin, A. (ред.) (2014). Философска инженерия: Към философия на уеба
2. Allemang, D., Hendler, J. (2011) Семантичен уеб за действащия онтолог (2-ро издание)
3. Staab, S., Studer, R. (ред.) (2009) Наръчник по онтологии (2-ро издание)
4. Wood, D. (ред.). (2011) Свързване на данни от предприятията
5. Keet, M. (2018) Въведение в инженерството на онтологии

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