Извлечение знаний

Извлечение знаний () — создание знаний из структурированных (реляционных баз данных, XML) и неструктурированных источников (тексты, документы, изображения). Полученное знание должно иметь формат, позволяющий компьютерный ввод, и должно представлять знания так, чтобы облегчить логические выводы. Хотя по методике процесс подобен извлечению информации (обработке естественного языка, , NLP) и процессу «Извлечения, Преобразования, Загрузки» (, ETL, для хранилищ данных), главный критерий результата — создание структурированной информации или преобразование в реляционную схему. Это требует либо преобразования существующего формального знания (повторного использования идентификаторов или онтологий), либо генерацией схемы, основанной на исходных данных.

Группа RDB2RDF W3CRDB2RDF Working Group, Website: http://www.w3.org/2001/sw/rdb2rdf/ , charter: http://www.w3.org/2009/08/rdb2rdf-charter , R2RML: RDB в RDF Mapping Language: http://www.w3.org/TR/r2rml/ занимается стандартизацией языка для извлечения среды описания ресурса (, RDF) из реляционной базы данных. Другой популярный пример извлечения знаний — преобразование Википедии в структурированные данные и отображение в существующее знание (см. DBpedia и Freebase).

Обзор После стандартизации языков представления знания, таких как «среда описания ресурса» (, RDF) и «язык описания онтологий» (, OWL), много исследований проводилось в этой области, особенно относительно преобразования реляционной базы данных в RDF, , обнаружения знаний и обучения онтологий. Основной процесс использует традиционные методы извлечения информации и методы «извлечения, преобразования и загрузка» (, ETL), которые преобразуют данные из исходных форматов в структурированные форматы.

Следующие критерии могут быть использованы для попыток категоризации в этой теме (некоторые из них обеспечивают извлечение знаний из реляционных баз данных)LOD2 EU Deliverable 3.1.1 Knowledge Extraction from Structured Sources: Источник Какие данные могут быть обработаны: Текст, Реляционная база данных, XML, CSV Представление Как извлечённые данные могут быть представлены для использования (файл онтологии (объектной модели), семантическая база данных)? Как можно запрашивать информацию из полученного представления? Синхронизация Выполняется ли извлечение знания один раз для получения дампа или результат синхронизируется с источником? Извлечение статическое или динамическое? Записываются ли изменения в результате обратно в источник (двунаправленность)? Повторное использование словаря Позволяет ли средство извлечения повторное использование существующих словарей при извлечении. Например, столбец таблицы 'firstName' может быть отражён в столбец foaf: firstName. Некоторые автоматические подходы не способны к отображению словаря. Автоматизация Степень участия/автоматизации извлечения: Ручной режим, есть GUI, полуавтоматический, автоматический. Необходимость объектной модели предметной области Требуется ли наперёд заданная объектная модель для отображения в неё. Таким образом, либо отображение создаётся, либо схема получается из источника путём ().

Примеры

Связывание именованных сущностей DBpedia Spotlight, , Dandelion dataTXT, Zemanta API, Extractiv и PoolParty Extractor анализируют произвольный текст с помощью , а затем разрешения неоднозначностей путём и связывания найденных сущностей в депозитарий знаний DBpedia (Dandelion dataTXT demo, или DBpedia Spotlight web demo, или PoolParty Extractor Demo).

Президент Обама призвал в среду Конгресс включить расширение налоговых каникул для студентов в пакет экономического стимулирования, утверждая, что эта политика даст более крепкую поддержку.

Так как Президент Обама связан в DBpedia с ресурсом LinkedData, дальнейшая информация может быть извлечена автоматически и Семантический механизм рассуждений может, например, сделать вывод, что упомянутая сущность является неким типом личности (используя FOAF) и президентом США (используя ). Контрпримеры: Методы, которые только распознают сущности и не связывают со статьями в Википедии или другими объектами, не обеспечивают извлечение дальнейших структурированных данных и формального знания.

Преобразование реляционной базы данных в RDF Triplify, D2R Server, Ultrawrap и прредставления RDF являются средствами, которые преобразуют реляционную базу данных в RDF. В течение это процесса эти средства позволяют повторное использование словарей и онтологии в процессе преобразования. Когда преобразуется типичная реляционная таблица с названием users, один столбец (например, name) или группа столбцов (например, first_name и last_name) должны обеспечивать унифицированный идентификатор создаваемой сущности. Обычно используется главный ключ. Любой другой столбец может быть извлечён как связанный с этой сущностью. Затем используются (и повторно используются) свойства с формально определённой семантикой для интерпретации информации. Например, столбец таблицы user, названный marriedTo (женат на/замужем за) может быть определён как семантическое отношение, а столбец homepage (домашняя страница) может быть преобразован в свойство из словаря FOAF с названием foaf: homepage, тем самым квалифицируя его как обратную функциональность. Тогда каждый вход таблицы user может быть сделан экземпляром класса foaf:Person (онтология Население). Кроме того, предметная область (в виде онтологии) может быть создана из status_id путём вручную созданных правил (если status_id равен 2, строка таблицы принадлежит классу Учитель) или (полу-)автоматическими методами (). Ниже приведён пример преобразования:

Name marriedTo homepage status_id Peter Mary http://example.org/Peters_page 1 Claus Eva http://example.org/Claus_page 2 :Peter :marriedTo :Mary . :marriedTo OWL:SymmetricProperty . :Peter foaf:homepage <http://example.org/Peters_page> . :Peter foaf:Person (Физическое лицо). :Peter :Student (Студент). :Claus :Teacher (Учитель).

Извлечение из структурированных источников в RDF

Отображение 1:1 из таблиц/представлений реляционной базы данных в RDF сущности/атрибуты/значения При построении представления реляционной базы данных (РБД, ) стартовой точкой часто служит диаграмма сущность-связь (, ERD). Обычно каждая сущность представлена как таблица базы данных, каждое свойство сущности становится столбцом в этой таблице, а связь между сущностями показывается внешними ключами. Каждая таблица обычно определяет конкретный класс сущностей, а каждый столбец определяет одно из свойств этой сущности. Каждая строка в таблице описывает экземпляр сущности, однозначно определённый главным ключом. Строки таблицы вместе описывают набор сущностей. В эквивалентном RDF представлении того же набора сущности: Каждый столбец в таблице является свойством (то есть предикатом) Каждое значение в столбце является свойством атрибута (то есть является объектом) Каждый ключ строки представляет ID сущности (то есть субъектом) Каждая строка представляет экземпляр сущности Каждая строка (экземпляр сущности) представляется в RDF коллекцией кортежей с общим субъектом (ID сущности).

Таким образом, чтобы выразить эквивалентное представление, основанное на семантике RDF, базовый алгоритм будет выглядеть следующим образом: создаём схему RDF (RDFS) класса для каждой таблицы преобразуем все главные ключи и внешние ключи в IRI идентификаторы назначаем IRI предикат каждому столбцу назначаем rdf: type предикат каждой строке, связывая его с IRI идентификатором RDFS класса Для каждого столбца, не являющегося ни частью главного ключа, ни частью внешнего ключа, строим тройку, содержащую IRI главного ключа в качестве субъекта (подлежащего), IRI столбца в качестве предиката и значения столбца в качестве объекта.

Раннее упоминание базового или прямого отображения можно найти в сравнении Тимом Бернерсом-Ли ER-модели с RDF моделью.

Сложные отображения реляционных баз данных в RDF 1:1 отображение, упомянутое выше представляет старые данные как RDF напрямую, а дополнительная доработка может быть использована для улучшения полноценности вывода RDF соответственно заданному сценарию использования. Как правило, информация теряется в течение преобразования диаграммы сущность-связь (, ERD) в реляционные таблицы (детальное описание можно найти в статье «») и должна быть восстановлена путём обратного проектирования. С концептуальной точки зрения подходы для извлечения могут прийти с двух направлений. Первое направление пытается извлечь или обучить (с помощью машинного обучения) OWL схему из заданной схемы базы данных. Ранние подходы использовали фиксированное количество созданных вручную правил отображения для улучшения 1:1 отображения. Более тщательно разработанные методы использовали эвристические или обучающие алгоритмы для порождения схематической информации (методы частично совпадают с ). В то время как некоторые подходы пытаются извлечь информацию из структуры, присущей SQL схеме (анализируя, например, внешние ключи), другие подходы анализируют содержимое и значения в таблицах для создания концептуальных иерархий (например, столбцы с малым числом значений являются кандидатами стать категориями). Второе направление пытается отобразить схему и её содержимое в существующую онтологию предметной области (см. также «Отображение онтологий»). Часто, однако, подходящая онтология предметной области не существует и её сначала следует создать.

XML Поскольку XML структурирован в виде дерева, любые данные легко представить в формате RDF, который структурирован в виде графа. XML2 RDF является одним примером подхода, который использует пустые узлы RDF и преобразует элементы и атрибуты XML в свойства RDF. Случай, однако, более сложен, чем в случае реляционных баз данных. В реляционных таблицах главный ключ является идеальным кандидатом для субъекта выделенных троек. XML элемент, однако, может быть преобразован — в зависимости о контекста — как субъект, как предикат или как объект тройки. XSLT может быть использован как стандартный язык преобразования для ручного преобразования XML в RDF.

Обзор методов / средств