English for Knowledge Graph Engineers: Graph Databases and Semantic Web Vocabulary (англійською)

Графи знань живлять деякі з найскладніших систем в технології - Google’s Knowledge Graph, Amazon’s product graph, LinkedIn’s economic graph. Інженери, які працюють в цій області, говорять точним гібридним словником, що складається з теорії баз даних, формальної логіки і веб-стандартів. Без неї, дискусії про онтології, висновки, і розв’язування сутностей звучать непроникно.

Фундаментальна база даних

** База даних графів ** зберігає дані як мережу ** вузлів ** (суб’єктів — людина, продукт, компанія) і ** країв ** (відносини між суб’єктами — “WORKS_AT”, “PURCHASED”, “LOCATED_IN”). Як вузли, так і краї можуть мати властивості — атрибути ключ-значення, такі як назва, дата або ціна.

Ребра можуть бути направленими (відношення має напрямок: Осіб A ПІДТРИМУЄ Осіб B) або ненаправленими (відношення є симетричним: Осіб A_ПІДТРИМУЄ_Осібу B). Кожен вузол або ребро може мати метку, яка визначає його тип — (:Person), (:Product), [:PURCHASED].

** Cipher ** — мова запиту, яку використовує Neo4j. Його синтаксис розроблений так, щоб виглядати як ASCII-образ графа: MATCH (p:Person)-[:WORKS_AT]->(c:Company) WHERE c.name = 'Acme' RETURN p.name. Інженери часто кажуть: * “Напишіть запит Cypher, щоб знайти всіх клієнтів, які купили у того ж продавця, що і цей клієнт, протягом останніх 30 днів.” *

** Gremlin ** — це мова пересування графів, яку використовують бази даних, сумісні з Apache TinkerPop (наприклад, Amazon Neptune і JanusGraph). Він використовує плавний, крок-заснований стиль: g.V().hasLabel('person').out('knows').values('name').

RDF і семантичний веб

** RDF (Resource Description Framework) ** — це стандарт W3C для представлення знань як ** триплетів **: суб’ єкт- предикат- об’ єкт. Кожна тривалість робить одне твердження про світ: (dbr:London, dbo:country, dbr:United_Kingdom). Збірка RDF-троїць утворює графік знань.

** SPARQL ** — це мова запиту для даних RDF, аналогічна SQL для реляційних баз даних. Інженери кажуть: “Запустити запит SPARQL проти кінцевої точки Wikidata, щоб видобути всі хімічні сполуки з молекулярною вагою понад 500 дальтонів.”

** Онтологія ** є формальною, машинно- зчитуваною специфікацією концепцій і взаємозв’ язків між ними. ** OWL (Web Ontology Language) ** є стандартом W3C для написання онтологій. Resoner це програмний компонент, який використовує правила, визначені в онтології, щоб вивести нові факти з існуючих даних — наприклад, виводячи, що кіт є ссавцем, якщо онтологія визначає «cat subClassOf mammal» і дані стверджують «Whiskers is a cat.»

Семантична мережа — це бачення Тіма Бернерса-Лі мережі пов’ язаних, машинно-читальних даних. Пов’ язані дані — це практика публікації структурованих даних у мережі за допомогою URI і RDF, так що набори даних можуть бути з’ єднані через межі організацій. Schema.org — це спільний словник (легка онтологія), який використовується веб-сайтами для анотації їх HTML-контенту для пошукових систем.

Інженерно-технічна справа в практиці

** Розв’ язання сутностей ** (також називається ** поєднанням записів ** або ** дедуплікацією **) є процесом визначення, коли два різні записи даних посилаються на одну й ту ж сутність реального світу. На графі знань ви можете бачити « Apple Inc. » і « Apple Computer Company » як окремі вузли, які слід об’ єднати. Інженери кажуть: * “Конвейєр розв’язання сутностей генерує занадто багато хибних позитивних результатів - нам потрібно затягнути стратегію блокування ключів.” *

** Вбудовування графів знань ** — це метод представлення вузлів і ребер як щільних векторів у неперервному просторі (вбудовування), що надає змогу моделям ML обґрунтовувати графік — для передбачення зв’ язків, класифікації об’ єктів і пошуку подібності. Методи включають TransE, DistMult і RotatE.

Поширені фрази з інженерних обговорень:

• “Онтологія не моделює це співвідношення — нам потрібно буде розширити схему перед введенням цього джерела даних.”
• “Розумник виводить занадто багато неправдивих тройок — онтологія має занадто широку аксіому.”
• “Ми потребуємо відомостей про походження кожного трикутникового числа на рівні стовпчика — з якої системи воно походить і коли.”

Наступні кроки

Досліджуйте кінцеву точку SPARQL Wikidata (query.wikidata.org) і виконуйте простий запит — він має інтерактивний редактор з прикладами. Напишіть запит у SPARQL, а потім описайте його дії у одному або двох реченнях англійською мовою, використовуючи словник з цієї статті. Переклад з англійської мови на код — це основна вміння, яку розблокує цей словник.

Національні мови: рідна мова для ненаціональних меншин

Багато розробників, які вивчають професійну англійську, особливо ті, хто вступає в такі галузі, як інженерія Knowledge Graph, стикаються з тонкими відмінностями у фразуваннях і очікуваннях. Це не просто про те, щоб знати визначення слів; це про те, як ці слова використовуються в конкретному технічному контексті - і розуміння немовлених припущень, які часто супроводжують їх. Розглянемо деякі типові пастки і як до них підійти.

Однією з найчастіших проблем є тенденція до надмірного пояснення при описі технічного рішення. Рецензенти, особливо старші, цінують коротке спілкування. Докладне пояснення, наприклад, «Гаразд, ми використовуємо RDF-тройки для представлення відносин між об’єктами в нашому графі знань, які потім запитуються за допомогою SPARQL для отримання інформації на основі онтологічних визначень, які ми встановили», може зустрітися з коротким коментарем: «Розгляньте спрощення опису - зосередьтеся на * тому, що * ви досягли і * чому * це вигідно. » Ефективнішим підходом буде: «Цей запит ефективно отримує дані про покупки клієнтів за допомогою чіткого представлення RDF. Використання FILTER клаузул покращує продуктивність.” Різниця полягає в тому, що пріоритет наданий ясності, а не вичерпним деталям. Аналогічно, при написанні описів PR, уникайте жаргонних висловлювань, якщо це абсолютно не потрібно. Замість цього, сформулюйте свої зміни з точки зору їх впливу - “Оновлено онтологію продукту, щоб включити “стійкі матеріали” як ключовий атрибут”, є набагато більш впливовою, ніж “Змінена схема для включення семантично збагачення.”

Інша проблема виникає з різних культурних підходів до неоднозначності. У деяких культурах, прямо стверджуючи невизначеність («Я не впевнений, чи це спрацює»), може бути сприйнято негативно. У технічних обговореннях, однак, визначення потенційних проблем проактивно - “Давайте спочатку перевіримо це з меншим набором даних, щоб перевірити продуктивність запиту” - цінується як демонстрація ретельності і зменшення ризику. Не бійтеся фраз типу “може” або “ми повинні розслідувати”, але завжди вставляйте їх у план дій. Крім того, пам’ятайте про рівень формальності при взаємодії на платформах, таких як Slack. Хоча неформальна розмова між колегами є нормальною, формальна комунікація у каналах, присвячених документації або перегляду коду, вимагає більш відшліфованої мови. Швидке повідомлення, наприклад, «Виявлення шифрового запиту» може здатися різким; «Я оновив запит product_sales, щоб оптимізувати для швидшого отримання даних про продажі» звучить набагато професійніше і демонструє глибше розуміння основної проблеми.

Нарешті, зверніть увагу на термінологію. Хоча основні концепції — RDF, онтології, SPARQL — є універсальними, їх застосування може трохи відрізнятися залежно від конкретного інструмента або бази даних, що використовується. Зрозуміти нюанси того, як ці терміни використовуються в рамках певної екосистеми, є ключовим для ефективного спілкування і співпраці.

MATCH (p:Product {name: 'Laptop'})-[:HAS_FEATURE]->(f:Feature {name: 'High Performance'})
RETURN p, f

Цей запит Cypher демонструє отримання властивостей продукту за допомогою бази даних графів, що є звичайним завданням у інженерії графів знань, і показує практичне застосування семантичного словника у запитуванні даних. Клаузула MATCH визначає шаблон для пошуку - вузол Продукт з назвою “Ноутбук”, з’єднаний з вузлом Функція з назвою “Висока продуктивність” через відношення ‘HAS_FEATURE’. Інструкція RETURN вказує, яку інформацію потрібно отримати, надаючи короткий і фокусований набір результатів. Цей приклад підкреслює силу графічних баз даних у представленні складних відносин і ефективному запиті на них.