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

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

Онтологично моделиране на предприятието: методи и технологии [Текст]: монография / [С. В. Горшков, С. С. Кралин, О. И. Муштак и др.; отговорен редактор С. В. Горшков]. — Екатеринбург: Изд-во Уралския университет, 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.
   Тази четвърта фаза, прогнозиранa от Бернерс-Ли, създателя на ключовите технологии на втората и директор на 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, едното по-гадно от другото.

Въпреки това, технологиите на свързаните данни са се разпространили и извън масовия уеб; на това приложение на книгата, всъщност, е посветена. В момента общността на свързаните данни очаква, че тези технологии ще получат още по-широко разпространение благодарение на фиксирането (или обявяването, както на кого му харесва) от Gartner на такива тенденции като Knowledge Graphs и 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.

Тези отделни «слоеве» на технологичния стек Linked Data, известен също като 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: Semantics for Languages of the Semantic Web", който има статут на бележка на работната група W3C. При такова разбиране тройката s p [], където [] — празен възел, ще бъде преведена като , където — променлива, но как тогава да се преведе s [] o? Имеющий статус рекомендации W3C документ «RDF 1.1 Semanticsпредлага друг начин на превод, но възможността предикатите да бъдат празни възли все пак не се разглежда.

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

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 Протокол и RDF Език на Запитвания) — език за запитвания към 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 не разделя презумпцията за откритост на света и следва подхода „отрицание като провал“, в него са възможни такива конструкции, като 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. — Вижте за това по-долу.

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

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

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

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

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

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

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

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

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

актуално

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

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

актуално

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

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

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, Федер Reserve, Deutsche Bank… Вероятно, всички търсеха, кого могат да изпратят на Конференция за графа на знанието. На много хора им успя да намерят работа: финансовите организации запълниха целия сутрин на първия ден.

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

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

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

актуално

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

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

актуално

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

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

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

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

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

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

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

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

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

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

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

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

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

Повече информация относно поддръжката на модела LPG от RDF хранилищата можете да прочетете в предишната статия на Хабра: «Какво се случва с 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