Метод и алгоритмы интерпретации неполных высказываний пользователя для управления устройствами Интернета вещей на основе онтологического подхода тема диссертации и автореферата по ВАК РФ 05.13.17, кандидат наук Шилин Иван Андреевич

• Шилин Иван Андреевич
• кандидат наук
• 2019

Оглавление диссертации кандидат наук Шилин Иван Андреевич

Реферат

Synopsis

Введение

Глава 1. Анализ предметной области, постановка цели и задач

исследования

1.1 Естественно-языковые интерфейсы и перспективы их применения в области взаимодействия с электронными устройствами

1.1.1 Концепция устройств Интернета вещей

1.1.2 Обзор языковых и голосовых интерфейсов для

Интернета вещей (IoT)

1.2 Методы и подходы компьютерной лингвистики в задачах разработки естественно-языковых интерфейсов и диалоговых систем

1.2.1 Современное состояние и направления исследований в области вопросно-ответных систем

1.2.2 Формирование запросов и извлечение данных из связанных наборов данных (linked datasets)

1.2.3 Современное состояние исследований в области генерации команд и плана управления устройствами в концепции "Интернет вещей" по пользовательскому запросу на естественном языке

1.3 Современное состояние и основные подходы к разработке диалоговых систем

1.4 Информационная неполнота в системах разговорного

интеллекта и методы обработки неполных команд

1.4.1 Восстановление эллипсиса в высказываниях на

естественном языке

1.4.2 Обработка низкочасточных артефактов как объектов, имеющих неполные (неопределенные /

нерепрезентативные) метаданные

1.4.3 Обработка неполноты во входных данных (вопросах) и ресурсах (графах знаний) в вопросно-ответных системах

1.4.4 Обработка информационной неполноты, возникающая

при агрегировании данных

1.4.5 Использование ошибок для улучшения результатов анализа 84 1.5 Выводы по главе

Глава 2. Разработка алгоритмов и моделей лингвистического анализа и онтологической модели для проведения

эксперимента

2.1 Онтологическое описание устройств, команд и их параметров

2.2 Онтология VoiceloT

2.3 Методы дистрибутивной семантики

2.4 Разработка моделей морфологического и синтаксического

анализа русского языка для библиотеки Stanford CoreNLP

2.4.1 Набор данных для обучения моделей морфологического

и синтаксического анализа русского языка

2.4.2 Сегментация на предложения и токенизация

2.4.3 Морфологический анализ

2.4.4 Синтаксический анализ

2.5 Выводы по главе

Глава 3. Метод и алгоритмы интерпретации неполных высказываний пользователя для управления устройствами Интернета вещей

3.1 Информационная модель представления данных для поиска релевантных команд во множестве альтернативных гипотез

3.2 Описание метода интерпретации неполных высказываний пользователя для управления устройствами Интернета вещей . . 106 3.2.1 Алгоритм классификации типов пользовательских

высказываний

3.2.2 Алгоритм формирования списка гипотез по леммам

3.2.3 Подсчет релевантности гипотезы относительно пользовательского высказывания

3.2.4 Алгоритм поиска сущностей, леммы которых отсутствуют в онтологической базе знаний

3.3 Архитектура программной системы для взаимодействия с устройствами Интернета вещей

3.4 Выводы по главе

Глава 4. Оценка разработанных метода и алгоритмов на

разработанном наборе данных

4.1 Экспериментальный корпус пользовательских высказываний

при взаимодействии с устройствами Интернета вещей

4.1.1 Обзор существующих корпусов для голосового управления Интернетом вещей

4.1.2 Методика сбора и разметки корпуса пользовательских высказываний при взаимодействии с устройствами Интернета вещей

4.2 Оценка точности алгоритма классификации пользовательского высказывания

4.3 Оценка точности метода интерпретации неполных высказываний пользователя для управления устройствами Интернета вещей

4.4 Выводы по главе

Заключение

Список сокращений

Список литературы

Список рисунков

Список таблиц

Приложение А. Сопоставление типа неполноты и

соответствующей задачи обработки естественного языка в системах разговорного интеллекта с компонентами архитектуры разработанной системы

Приложение Б. Текст публикаций

Введение диссертации (часть автореферата) на тему «Метод и алгоритмы интерпретации неполных высказываний пользователя для управления устройствами Интернета вещей на основе онтологического подхода»

Реферат Общая характеристика работы

Актуальность темы. Разнообразие устройств, формирующих Интернет вещей, равно как и их количество и набор выполняемых функций, постоянно растет, что приводит к росту различных способов и интерфейсов управления ими, а также необходимости учета контекста и протоколов взаимодействия между ними при выполнении команд пользователя. С ростом объема данных о работе этих устройств, а также о параметрах выполнения ими различных функций, происходит усложнение пользовательских интерфейсов. Одной из центральных проблем становится интеграция данных различных устройств, а также использование баз знаний и правил, позволяющих произвести интеллектуализацию интерфейсов для Интернета вещей, а также снизить трудоемкость поддержки в актуальном состоянии привычных для пользователя режимов работы голосовых ассистентов и других специализированных информационных систем и интерфейсов управления устройствами.

Разработка голосовых интерфейсов к Интернету вещей является одной из самых актуальных тем в современных научных и промышленных исследованиях, связанных с Интернетом вещей, что подтверждается программами мировых конференций: CES 20181, Conversations 20192 и множеством публикаций [1 6]. При этом одной из ключевых проблем, особенно для таких приложений, как "умный дом" , остается подключение новых устройств к голосовому ассистенту, и обучение его моделей работе с новыми функциями подключенных устройств. В то же время, пользователям необходимо точно знать технические детали об этих устройствах (их названия, названия и параметры команд управления и т.п.), чтобы управлять ими голосом. Эта особенность значительно ограничивает естественность коммуникации и взаимозаменяемость устройств в окружении Интернета вещей.

В настоящее время существуют разработки в области обеспечения взаимодействия с устройствами Интернета вещей на коммуникационном уровне

1См. CES https://www.ces.tech/

2См. Conversations 2019 https://conversationsconference.com/

и на прикладном уровне, где устройства от разных производителей формируют небольшие и обособленные кластеры со своим набором форматов, моделей и стандартов. Тем не менее, по-прежнему существуют и нерешенные задачи. Одной из таких задач является создание механизмов обеспечения семантической интероперабелыюсти на уровне моделей и понятий для поддержки возможности одновременного использования разных типов и моделей устройств от различных производителей. Эта задача может быть успешно решена за счет совмещения методов, используемых в системах разговорного интеллекта, с методами и подходами обеспечения семантической интероперабелыюсти для Интернета вещей. В стремительно развивающихся технологиях и системах разговорного интеллекта (голосовые ассистенты, диалоговые системы, чат-боты) в настоящее время доминируют сквозные (епс1-к)-епс1) архитектуры. Преимуществом сквозных архитектур является скорость разработки и низкая трудоемкость (не требуется разработка моделей предметных областей, правил и алгоритмов диалогового менеджера, алгоритмов порождения ответа и т.п.). Однако, недостатки этого подхода особенно критичны для систем управления Интернетом вещей, т.к.:

1. во-первых, епс1-к)-епс1 диалоговые системы требуют больших обучающих выборок, т.е. использование архитектур этого типа в настоящее время ограничено несколькими предметными областями (см. работу [7]). Применительно к голосовым интерфейсам для Интернета вещей это условие является критичным, т.к. от начала использования новых устройств до получения большой репрезентативной выборки могут пройти годы;

2. во-вторых, для Интернета вещей важна возможность динамического подключения новых типов устройств к системе, что регулярно создает ситуацию, когда для вновь подключенного типа устройств система не может быть дообучена из-за отсутствия данных, что подталкивает к включению алгоритмов обеспечения семантической интероперабелыюсти в стек технологий;

3. в-третьих, входные данные, получаемые от пользователя, и метаданные, генерируемые для них с помощью языковых моделей, лингвистических ресурсов и семантических моделей, в большинстве случаев бывают неполными (зашумленными, нечеткими, фрагментарными, невалидиру-

и

емыми), что вызывает необходимость включения методов и алгоритмов обработки информационной неполноты в систему.

В системах голосового управления Интернетом вещей, информационная неполнота является неизбежным атрибутом, так как она может возникать в результате работы любого из алгоритмов или модулей системы, в особенности, естественно-языкового интерфейса. Неполными могут быть: 1) входные данные (фрагментарные и незаконченные высказывания) и их структура, например, синтаксическая, 2) данные о работе устройств (например, при ошибках передачи данных, сбоях в работе устройства, пропуски в показаниях устройств), 3) модели предметной области, 4) ресурсы, 5) любые метаданные, генерируемые внутри системы, например, лингвистическая разметка. Все это делает неэффективным прямое сопоставление пользовательского высказывания реакции системы для исчерпывающей идентификации соответствующей реакции системы.

Использование онтологического подхода делает возможным интеграцию и взаимное обогащение описанных данных, что позволяет получить более целостную картину для интерпретации пользовательских высказываний.

В диссертационной работе рассматривается информационная неполнота, возникающая в компонентах понимания естественного языка в составе систем разговорного интеллекта (вопросно-ответных систем, диалоговых систем, голосовых интерфейсов и др.) для управления устройствами Интернета вещей. В частности, рассматриваются задачи обработки эллиптических синтаксических структур, фрагментарных запросов, восстановления неполноты моделей и ресурсов, используемых алгоритмами, накопленных ошибок, модулями конвейера обработки данных, обработки при отсутствии достаточного контекста и т.д. Перечисленные выше задачи и влияние отдельных алгоритмов на качество работы компонента понимания естественного языка делает актуальным разработку методов и алгоритмов интерпретации пользовательских высказываний, позволяющих использовать онтологические модели предметных областей при взаимодействии с устройствами системы на естественном языке и обрабатывать возникающую на разных уровнях архитектуры информационную неполноту, а также создание средств (информационных моделей), позволяющих обнаружить, оценить и обработать неполноту разных типов для отдельного высказывания.

Целью диссертационной работы является повышение точности интерпретации высказываний пользователя для управления устройствами Интернета вещей за счет формирования и оценки гипотез о релевантности управляющих действий на основе онтологического подхода и методов обработки естественного языка.

Для достижения поставленной цели необходимо было решить следующие задачи:

1. Проанализировать существующие подходы и системы, позволяющие пользователю взаимодействовать с устройствами Интернета вещей на естественном языке.

2. Проанализировать существующие типы информационной неполноты в системах разговорного интеллекта для управления устройствами Интернета вещей.

3. Разработать модель представления данных, описывающих пользовательское высказывание, и метаданных, генерируемых разработанными методом и алгоритмами.

4. Разработать методику по сбору и разметке корпуса пользовательских высказываний при взаимодействии с устройствами Интернета вещей, позволяющую описывать как эксплицитное, так и имплицитное содержание высказываний пользователя.

5. Разработать метод интерпретации неполных высказываний пользователя для управления устройствами Интернета вещей.

6. Разработать архитектуру системы, позволяющую реализовать и оценить точность разработанных метода и алгоритмов.

7. Выполнить сбор и разметку экспериментального корпуса пользовательских высказываний к устройствам Интернета вещей, используя разработанную методику.

8. Провести экспериментальные исследования для определения точности разработанных метода и алгоритмов и сравнения полученных результатов с существующими методами.

Объект исследования. Пользовательские высказывания при взаимодействии с устройствами Интернета вещей.

Предмет исследования. Метод и алгоритмы интерпретации высказываний пользователя, в том числе неполных, для управления устройствами Интернета вещей.

Методы исследования. Для решения указанных задач использовались методы математической статистики и теории вероятностей, машинного обучения, методы языкового моделирования с помощью нейронных сетей, методы контекстного восстановления информационной неполноты, методы синтаксического анализа и обработки синтаксических деревьев, методы автоматической обработки естественного языка.

Научная новизна. Задачи интерпретации пользовательских высказываний для взаимодействия с устройствами Интернета вещей рассмотрены в рамках единой концепции, предполагающей представление исходных и формируемых данных в виде единой модели. Разработанные в диссертационной работе метод и алгоритмы позволяют решить проблемы разнородности описаний устройств Интернета вещей, неполноты пользовательских высказываний, ограниченности исходных данных. При этом разработаны:

1. Информационная модель для описания и оценки неопределенности входных данных, метаданных к ним и генерируемых с помощью онтологической модели гипотез управляющих действий, позволяющая оценивать и восстанавливать информационную неполноту, вносимую ошибками распознавания и аннотирования пользовательского высказывания и связанную с ограниченностью семантических ресурсов и онтологической модели.

2. Методика по сбору и разметке корпуса пользовательских высказываний при взаимодействии с устройствами Интернета вещей, позволяющая описывать как эксплицитное, так и имплицитное содержание высказываний пользователя на основе выделенных признакового пространства описания высказываний пользователя и типов состояний системы.

3. Метод интерпретации высказываний пользователя, в т.ч. неполных, для управления устройствами Интернета вещей, позволяющий повысить точность при выборе управляющих действий системы, соответствующих высказыванию пользователя, за счет формирования и оценки гипотез на основе онтологического описания и использования векторных представлений.

Научные положения, выносимые на защиту:

1. Показано, что информационная модель для описания и оценки неопределенности входных данных, метаданных к ним и гипотез управляющих действий, генерируемых с помощью онтологической модели,

позволяет описать все данные и метаданные, используемые в системе, и выполнить подсчет релевантности найденных гипотез управляющих действия для пользовательского высказывания.

2. Показано, что разработанная методика по сбору и разметке корпуса пользовательских высказываний при взаимодействии с устройствами Интернета вещей позволяет описать как эксплицитное, так и имплицитное содержание высказываний пользователя на основе разработанного признакового пространства описания высказываний пользователя и типов состояний системы.

3. Экспериментально подтверждается, что метод интерпретации неполных высказываний пользователя для управления устройствами Интернета вещей позволяет повысить точность при выборе управляющих действий системы, соответствующих высказыванию пользователя.

Практическая значимость. Разработаны и опубликованы в открытом доступе в сети Интернет модели морфологического и синтаксического анализа русского языка для библиотеки Stanford CoreNLP и корпус пользовательских высказываний при взаимодействии с устройствами Интернета вещей.

Область применения полученных результатов включает системы взаимодействия пользователя с устройствами Интернета вещей, такие как умный дом, умное производство и т.д., системы разговорного интеллекта, такие как диалоговые системы и голосовые интерфейсы.

Достоверность. Достоверность научных положений, результатов и выводов, представленных в настоящей диссертационной работе, подтверждается корректной и обоснованной постановкой задач, успешным представлением основных положений в докладах на ведущих международных конференциях и результатами экспериментальных исследований.

Внедрение результатов работы. Результаты дисссертационной работы использовались при проведении прикладных научных исследований:

— НИР №718546 "Управление киберфизическими системами", Университет ИТМО, 01.01.2018 - 31.12.2019.

— НИР №218770 "Разработка золотого стандарта для обучения и тестирования алгоритмов извлечения знаний из технической документации по компонентам электрических автомобилей", Университет ИТМО, 15.02.2018 - 15.06.2018.

Результаты работы также были внедрены в учебный процесс Университета ИТМО по дисциплинам «Автоматическая обработка естественного языка в информационных системах» и «Онтологии и представление знаний».

Апробация работы. Результаты работы были представлены на пнут-ривузовских, всероссийских и международных конференциях: XLVII научной и учебно-методической конференции Университета ИТМО (Санкт-Петербург, 2018); VII и VIII всероссийском конгрессе молодых учёных (Санкт-Петербург, 2018-2019); 20th International Conference on Speech and Computer (SPECOM) (Leipzig, Germany, 2018); International Conference on Knowledge Engineering and Semantic Web (Szczecin, Poland, 2017); Proceedings of the 19th Conference of Open Innovations Association FRUCT (Jyväskylä, Finland, 2016); Proceedings of the 18th Conference of Open Innovations Association FRUCT (Санкт-Петербург, Россия, 2016); International Conference on Knowledge Engineering and Semantic Web (Москва, Россия, 2015). Кроме того, тема и результаты исследования были представлена на конкурсах грантов Правительства Санкт-Петербурга в 2018 и в 2019 годах, гда автор вошёл в число победителей конкурса грантов 2018 и 2019 годов для студентов вузов, расположенных на территории Санкт-Петербурга, аспирантов вузов, отраслевых и академических институтов, расположенных на территории Санкт-Петербурга.

Личный вклад автора. Автором лично проведен анализ существующих подходов и систем, позволяющих пользователю взаимодействовать с устройствами Интернета вещей на естественном языке, анализ существующих типов неполноты, возникающих при обработке пользовательских высказываний в системах взаимодействия с устройствами Интернета вещей. На основе проведенного анализа разработана модель представления данных, методика по сбору и разметке данных (корпуса) пользовательских высказываний при взаимодействии с устройствами Интернета вещей и метод интерпретации неполных высказываний пользователя для управления устройствами Интернета вещей. Автором лично выполнена реализация разработанных метода и алгоритмов и оценка полученных результатов. Подготовка основных публикаций проводилась с соавторами, при этом вклад автора был одним из основных.

Публикации. Основные результаты по теме научно-квалификационной работы изложены в 12 публикациях. Из них 1 издана в журналах, рекомендованных ВАК, 8 опубликованы в изданиях, индексируемых в базе цитирования

Бсорпн. Также имеется 2 свидетельства о государственной регистрации программ для ЭВМ.

Структура и объем диссертации. Диссертация состоит из введения, четырех глав, заключения и приложения. Полный объем диссертации составляет 275 страниц текста с 15 рисунками и 11 таблицами. Список литературы содержит 124 наименования.

Содержание работы

Во введении обоснована актуальность проводимых исследований в рамках диссертационной работы. Сформулированы цель, постав л еные задачи, научная новизна и положения, выносимые на защиту.

В первой главе проанализированы предметная область Интернета вещей (см. 1.1.1), системы разговорного интеллекта (см. 1.3), методы компьютерной лингвистики для разработки вопросно-ответных систем и генерации формальных запросов (см. 1.3), а также точка их пересечения - голосовые интерфейсы для взаимодействия с Интернетом вещей (см. 1.1.1).

Методы и алгоритмы анализа текста и понимания естественного языка в системах, обсуждаемые в пунктах 1.2-1.3, могут методологически незначительно варьироваться в зависимости от задачи и типа естественно-языкового интерфейса и реализации конкретного конвейера (pipeline). Так, в символьных (когнитивистских) архитектурах любая задача автоматической обработки естественного языка решается как задача обработки символьных последовательностей и преобразования одних формальных моделей в другие. В настоящее время (при современных объемах данных) эта задача выглядит как управление неструктурированными данными, аннотациями и метаданными к ним, в качестве примера можно привести проект Apache UIMA3, программное обеспечение для лингвистического анализа естественного языка NLTK4, GATE0, Stanford CoreNLP6.

3См. Apache UIMA https://uima.apache.org/

4См. Natural Language Toolkit https://www.nltk.org/

°Cm. General Architecture for Text Engineering https://gate.ac.uk/

6Cm. Stanford CoreNLP https://stanfordnlp.github.io/CoreNLP/

Таким образом, для прикладных задач анализа текста и при разработке модулей понимания естественного языка в системах искусственного интеллекта этап лингвистического анализа часто сводится к аннотированию входного текста с помощью существующих библиотек и семантических ресурсов, что позволяет получить метаданные (разметку), которые будут использоваться в качестве признаков алгоритмами машинного обучения, продукционными правилами в системах поддержки принятия решений и т.д.

Такой подход к обработке текста является типовым для задачи извлечения фактов, вопросно-ответных систем, некоторых диалоговых систем. В аналитическом обзоре существующих семантических вопросно-ответных систем (БС^А) [8], разработанных с 2010 по 2015 год, были выделены основные проблемы, возникающих в БС^А: несловарная лексика, омонимия, многоязычие, сложные запросы, распределенные знания, вопросы, относящиеся к процедурной, временной и пространственной информации. Наибольшие трудности вызывает проблема с обработкой лексики, отсутствующей в словаре системы, напрямую связанная с информационной неполнотой. В мультимодальных диалоговых системах, системах аналитики спонтанной речи и других компонентах понимания речи в когнитивных архитектурах требуется более глубокая обработка входного текста, а лингвистические анализаторы (например, синтаксический) переоценивают гипотезы, используя данные других модулей (например, компьютерного зрения для распознавания жестов и эмоций).

Однако, до сих пор в подавляющем большинстве систем голосового управления в Интернете вещей обработка текста сводится к обеспечению качественного распознавания речи с последующим поиском ключевых слов-триггеров. Этого может быть достаточно для обработки высказываний пользователя, которые примитивны и синтаксически, и семантически, но существует множество пользовательских высказываний, которые не могут быть преобразованы в формальные запросы путем простого поиска слов-триггеров, например, неполные высказывания, предполагающие аналитическую обработку информации системой, высказываний, предполагающие поиск и интеграцию гетерогенных данных, синтаксически сложные запросы. Кроме того, методы поиска ключевых слов и сущностей не позволяют обрабатывать имплицитное содержание высказываний [9 13]. Несколько лет назад высказывалась идея, что интеллектуальное окружение должно иметь компоненты, отвечающие за понимание

естественного языка, сопоставимые по глубине обработки языка с диалоговыми системами [14].

Раздел 1.4 посвящен обсуждению типов информационной неполноты, возникающей в интеллектуальных и когнитивных системах.

В работе рассматривается задача обработки информационной неполноты на уровне обработки данных и выделяются ее типы, связанные с искажением данных (ошибками), и типы, связанные с отсутствием данных (незнанием): Неполнота, связанная с ошибкой (искажением):

1. Ошибки генерации, распознавания, декодирования, передачи, слияния, аннотирования данных (уровень обработки данных, см. в п. 1.4.4);

2. Низкое качество результатов информационного поиска из-за различий структурных моделей предметных областей у агента/системы и модели фоновых знаний у источника данных. Классическим примером является несовпадение "научной" и "наивной" картин мира (научная картина мира воплощается в информационных моделях, наивная - консервируется и транслируется естественным языком), в настоящее время также "реинкарнировались" поверхностные (соттопнепне) графы знаний в противовес предметным онтологиям как информационным моделям предметных областей (уровень обработки данных, см. обсуждение в п. 1.4.3);

Неполнота, связанная с незнанием (отсутствием):

3. Отсутствие доступа к данным и/или ограничения на объем хранимых / передаваемых данных (коммуникационный уровень, системный уровень);

4. Отсутствие метаданных, релевантных для работы алгоритма (например, отсутствие аннотаций (тегов), входящих в признаковое пространство алгоритма классификации или расчета метрик качества работы системы). Эта причина способствует росту кумулятивной неполноты, увеличивающейся на каждом этапе обработки результатов, поступивших из предыдущих модулей конвейера (уровень обработки данных, см. обсуждение в п. 1.4.2);

5. "Сенсорная" неполнота, которая особенно актуальна для мультимо-дальных и когнитивных систем: источник данных и система обладают несопоставимыми средствами восприятия (например, команды отдаются пользователем с использованием ЕЯ и жестов), а система умеет

анализировать только ЕЯ, из-за отсутствия модуля компьютерного зрения у нее возникают проблемы с референцией и пониманием высказываний (коммуникационный уровень);

6. Системная неполнота, например, вызванная системным сбоем устройства-сенсора (системный уровень);

7. Неполнота как имманентное свойство источника или средства порождения данных (человеческая коммуникация и естественный язык), (уровень внешнего окружения, см. обсуждение в п. 1.4.1, 1.4.5).

В 1.4.1-1.4.5 рассмотрены мировые исследования, связанные с обработкой перечисленных выше типов информационной неполноты в неструктурированных данных, ресурсах и системах, возникающих на уровне обработки данных. Предложенные в диссертации методы обработки информационной неполноты изложены в главе 3 и приложении А.

Во второй главе были рассмотрены онтологии, в том числе SSN, SAREF, IoT-Lite, SemloT, позволяющие описать устройство, команды и их параметры (раздел 2.1). По результатам анализа данных онтологий разработана онтология VoiceloT, позволяющая описать основные классы и свойства устройств, их команд и параметров, необходимых для естественно-языкового взаимодействия (раздел 2.2). Визуализация фрагмента описания устройства при помощи рассмотренных и разработанной онтологий представлена на рисунке Р.1.

В разделе 2.3 описаны существующие методы дистрибутивной семантики. Модели обученных векторных представлений чувствительны как к данным, так и к методу и его программной реализации, что может способствовать сохранению в конвейере обработки данных разнородных методов семантического анализа текста. В задачах, решаемых в настоящей работе, используется ставший классическим метод обучения векторных представлений, предложенный Т.Миколовым в работе [15], и программный код проекта word2vec [16]. Модель векторных представлений word2vec была обучена с помощью архитектуры Skip-gram, использующей текущее слово для предсказания окружающих его слов, на корпусе Aranea Russicum Maius' (данный корпус содержит 1,200,001,91 токе-нов). Единицей словаря была выбрана словоформа.

1 См. http://aranea.juls.savba.sk/aranea_about/index.html

Рисунок Р.1: Фрагмент онтологического описания устройства Интернета вещей в онтологии VoiceloT

В разделе 2.4 описаны модели морфологического и синтаксического анализа русского языка для библиотеки Stanford CoreNLP. Разработанные модели были описаны и опубликованы в открытом доступе8.

В третьей главе описываются информационная модель представления данных для поиска релевантных гипотез и использующий ее метод интерпретации неполных высказываний пользователя для управления устройствами Интернета вещей.

В разделе 3.1 описывается информационная модель, описывающая внутреннее состояние модуля понимания естественного языка и семантику пользовательских высказываний, которая задается кортежем по формуле (1).

М = (ТА, HYP, SIM)

(1)

где:

ТА (text annotation) - уровень описания аннотаций высказывания пользователя,

HYP (hypothesis) - уровень описания гипотез, формализующих семантику высказывания пользователя при выбранной онтологической модели / онтологической базе знаний,

?См. Stanford CoreNLP Model Zoo https://stanfordnlp.github.io/CoreNLP/model-zoo.html

— SIM (similarity) - уровень описания семантических связей и семантических эквивалентов токенов в высказывании пользователя в соответствии с выбранными дистрибутивно-семантическими (векторные представления) и формально-семантическими (WordNet[17], компонентный анализ) моделями.

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

Список литературы диссертационного исследования кандидат наук Шилин Иван Андреевич, 2019 год

Литература

1. Zheng J., Chapman W.W., Crowley R.S., Savova G.K. Coreference resolution: A review of general methodologies and applications in the clinical domain // Journal of Biomedical Informatics. - 2011. - V. 44. - P. 1113-1122.

2. McCarthy JF, Lehnert WG. Using decision trees for coreference resolution // Proceedings of the 14th International Joint Conference on Artificial Intelligence. - 1995. - P. 1050-1055.

3. Yang X., Su J., Zhou G., Tan C.L. An NP-cluster based approach to coreference resolution // COLING '04: Proceedings of the 20th International Conference on Computational Linguistics.

- 2004. - P. 226-232.

4. Clark K., Manning C.D. Improving Coreference Resolution by Learning Entity-Level Distributed Representations // Association for Computational Linguistics Proceedings. - 2016.

- V. 1. - P. 643-653.

5. Toldova S., Ionov M. Coreference Resolution for Russian: The Impact of Semantic Features // Computational Linguistics and Intellectual Technologies. International Conference «Dialog 2017» Proceedings. - 2017. - P. 339-349.

Путинцева Алина Александровна

Год рождения: 1994

Университет ИТМО, факультет программной инженерии и компьютерной техники, кафедра информатики и прикладной математики, студент группы № P4217

Направление подготовки: 09.04.04 - Программная инженерия e-mail: [e-mail]

Шилин Иван Андреевич

Год рождения: 1992

Университет ИТМО, факультет программной инженерии и компьютерной техники, кафедра информатики и прикладной математики, аспирант, ассистент e-mail: [e-mail]

УДК 004.912

ОБЗОР ПОДХОДОВ К ВОССТАНОВЛЕНИЮ ЭЛЛИПТИЧЕСКИХ КОНСТРУКЦИЙ В ЕСТЕСТВЕННОМ ЯЗЫКЕ (НА МАТЕРИАЛЕ РУССКОГО ЯЗЫКА)

Путинцева А.А., Шилин И.А. Научный руководитель - к.филолог.н., доцент Ковригина Л.Ю.

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

Автоматическая обработка текстов на естественном языке сопряжена с рядом трудностей и нетривиальных задач. В особенности это характерно для текстов, полученных в результате актов спонтанной устной речи.

Данная работа посвящена автоматическому восстановлению эллипсиса - фигуры речи, подразумевающей пропуск элемента высказывания в случаях, когда это не искажает смысл высказывания и не затрудняет его восприятие [1]. Решение этой задачи необходимо для корректной интерпретации обрабатываемого текста и является одним из начальных этапов работы с ним.

Присутствие эллипсиса в речи обусловлено, с одной стороны, стремлением к экономии языковых средств, времени и усилий: во многих случаях мысль может быть выражена в сокращенной форме и оставаться при этом понятной для слушателя [2, 3]. С другой стороны, акт спонтанной речи, как правило, сопровождается использованием невербальных средств коммуникации (жестов, мимики и т.д.), и информационная нагрузка перераспределяется между каналами общения [4], что, в свою очередь, устраняет необходимость максимальной полноты вербального изложения информации.

Пример предложения, содержащего эллипсис: «Он пьет зеленый чай, а я пью черный (чай) из Англии».

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

тот же прием - восстановление из контекста. При этом восстановление разных видов эллипсиса подразумевает привлечение различных видов контекста, а сложность поставленной задачи варьируется в зависимости от вида контекста.

Автоматическое восстановление эллипсиса возможно при наличии в тексте (корпусе текстов) морфологической и синтаксической разметки. Под разметкой понимается дополнительная информация о единицах корпуса, описывающая их свойства и связи друг с другом.

В рамках данной работы рассмотрено восстановление контекстуального эллипсиса -эллипсиса, подразумевающего отсылку к другим элементам текста.

Существуют различные подходы к разметке контекстуального эллипсиса:

- в национальном корпусе русского языка (подкорпус СинТагРус) и системе морфо-синтаксического анализа Treeton в синтаксических деревьях вводятся вспомогательные вершины, заменяющие пропущенные элементы;

- в Хельсинкском аннотированном корпусе русского языка наличие эллипсиса является характеристикой клаузы в целом.

В данной работе за основу были взяты положения стандарта Universal Dependencies [5], которые можно резюмировать следующим образом:

- если исключенная вершина синтаксического дерева не имеет исходящих дуг (зависимых вершин), никакая дополнительная разметка не осуществляется;

- если исключенная вершина имеет исходящие дуги (зависимые вершины), одна из вершин принимает на себя роль пропущенного элемента.

Пример разметки предложения, содержащего эллипсис, проиллюстрирован на рис. 1.

Рис. 1. Пример замещения исключенной вершины одной из зависимых

Для решения задачи восстановления контекстуального эллипсиса предложен подход, основанный на предположении, что зависимости, возникающие при замещении опускаемой вершины, имеют гораздо меньшую частоту встречаемости. Тогда малое значение относительной частоты встречаемости совокупности «вершина - зависимость - зависимое слово» в корпусе может быть признаком наличия эллипсиса на данном участке синтаксического дерева (рис. 2).

NOUN ^ ADJ

а б

Рис. 2. Пример часто (а) и редко (б) встречающейся структуры «вершина - зависимость -

зависимое слово»

Общий алгоритм восстановления эллипсиса выглядит следующим образом:

1. используя синтаксически размеченный корпус, получить статистику встречаемости всех присутствующих в нем совокупностей «вершина - зависимость - зависимое слово»;

2. подобрать граничное значение, определяющее, является ли совокупность «вершина -зависимость - зависимое слово» редко встречающейся;

3. сравнить частоту встречаемости каждой совокупности «вершина - зависимость -зависимое слово» анализируемого предложения с граничным значением и выделить редкие совокупности;

4. для каждой совокупности, полученной на шаге 3, используя контекст анализируемого предложения/соседних предложений :

- подобрать POS-тэг для вспомогательного узла таким образом, чтобы частота встречаемости отношения между вершиной и ним была максимально возможной

(рис. 3):

Рис. 3. Подбор POS-тэга для вспомогательного узла

- подобрать отношение между вспомогательным узлом и зависимым словом таким образом, чтобы его частота встречаемости была максимально возможной (рис. 4):

Рис. 4. Подбор отношения между вспомогательным узлом и зависимым словом

Реализация описанного алгоритма и ее тестирование на предложениях, содержащих эллипсис именной группы, подтвердила высказанное в начале данной работы предположение о возможности выявления и восстановления некоторых видов эллипсиса на основании значения относительной частоты встречаемости отношений в корпусе.

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

Литература

1. Розенталь Д.Э., Теленкова М.А. Словарь-справочник лингвистических терминов: пособие для учителя. - 3-е изд., испр. и доп. - М.: Просвещение, 1985. - 357 с.

2. Богданова-Бегларян Н.В. Еще раз о законе экономии в повседневной спонтанной речи // Коммуникативные исследования. - 2014. - № 1. - С. 241-251.

3. McShane M., Babkin P. Automatic Ellipsis Resolution: Recovering Covert Information from Text [Электронный ресурс]. - Режим доступа: https://pdfs.semanticscholar.org/2f89/340bb02792d0c9c4c6b87e9edba7ed948322.pdf (дата обращения: 22.02.2017).

4. Касаева З.В. Об основных чертах устной спонтанной речи (Общие замечания) // Вестник Московского государственного областного университета. Серия «Русская филология». -2014. - № 2. - С. 60-68.

5. Other Constructions // Universal Dependencies [Электронный ресурс]. - Режим доступа: http://universaldependencies.org/u/overview/specific-syntax.html (дата обращения: 12.03.2018).

One Remote Control to Command Them all! Building a Hypermedia API for ESP8266-Based Devices

Alexey Andreev, Daniil Garayzuev, Maxim Kolchin, Nikita Chursin, Ivan Shilin

ITMO University Saint Petersburg, Russia

{a_andreev, garayzuev} @corp.ifmo.ru, [e-mail], {chursin.nikita, shilinivan}@corp.ifmo.ru

Abstract—Lack of commonly accepted standards for the connected devices' APIs caused the situation when each manufacturer creates its own mobile application to control their devices. We propose an approach to the design of a self-descriptive CoAP-based API using Hydra Core Vocabulary (http://hydra-cg.com) which allows to create an adaptive mobile application to control any device. In this paper we describe the approach, evaluate it on two exemplified devices build using ESP8266 Wi-Fi module and describe the architecture of a mobile application controlling these devices.

I. Introduction

ESP8266 is a Wi-Fi module which become very popular because of its price that even more lowered the barrier to start building Internet of Things devices. Such module is a good way for hobbyists to create a useful device for their homes. But since humans still can't talk to devices in its language they need to use a more human-friendly interface. Therefore hobbyists also have to spend sometime to create a mobile (or web) interface for each device. We show in this work how to even more lower the barrier using simple guidelines to design the device API so any device could be commanded by a single mobile application.

To achieve the desired goal to control any connected device through a single user interface, two requirements should be met:

• First of all, a device and a commander should be able to communicate through a commonly supported way. That is to use the same communication protocol, e.g. HTTP, MQTT, CoAP, etc.

• Secondly, they should be able interpret each others' messages. It means that they need to use a common message model and vocabulary.

In this work we show how both requirements could be met by using a standard communication protocol, a standard messaging model and a commonly shared vocabulary. Once the requirements are met by a connected device, we're able to command it through a single user interface.

A. Related work

Heterogeneous devices are devices which use different network, communication and application protocols. The existence of such devices is mainly caused by the lack of commonly

agreed standards. To command them, a commander should support all the protocols used by the devices at home. It can be achieved by using a middleware layer which implements all the protocols and provides a unified API to the devices. Such approach is employed in works [1], [2], where for each protocol a separate adapter is created.

In this paper instead of creating an adapter for each device in the commander, we assume that the devices use the same protocol, message model and vocabulary. This allows to get rid of a middleware between devices and the commander, but still use the same interface to command functionally different devices.

Our work is inspired by the approach proposed in [3] which describes a way for implementing a Web API following all REST principles [4]. This approach was already employed in the project called SmallHydra [9]. SmallHydra is a C++ library for the ESP8266 Wi-Fi module using Arduino libraries and an asynchronous HTTP server to provide a Hypermedia API.

B. Structure

Section II describes the requirements which our approach should met for building devices and a mobile application. Overview of the approach is presented in Section in. Section IV presents the architecture of a mobile application which is able to control any devices following the described requirements. Case study described in Section V presents examples ESP8266-based devices and a mobile application implementing the suggested approach. And Section VI concludes our work.

II. Requirements

The requirements we are providing for the device server and the client are needed for implementing dynamically generated user interface. This interface could visualise and interact with the device without additional changes in the client and the device based on reasoning of the semantically annotated description of the data.

Below are the requirements we impose on the API for connected devices:

R1 Device discovery mechanism, is needed to provide a way

to automatically discover available connected devices. It

should be possible to find a new device at the local network

ISSN 2305-7254

by request or such device should notify the commander about itself.

R2 Model-Instance representation. Since devices has limited resources there should be a way to refer a commander to additional information on Internet or local network. This information should describe a device model, common characteristics, supported functionality, etc. R3 Authentication support is required to authenticate access to device's data and controls. Request packet should contain hashed concatenated login and password strings. Basic authentication is needed to regulate access in secured network for administration and working with private resources.

R4 Publish/Subscribe pattern should be implemented to support the mechanism when a commander is notified about new data, such as new observation or state of the device's control. The pattern allows to subscribe for a resource and get updates once their appear. R5 On-demand configuration mode. A possibility to configure a device through a public API is not always a good idea, because in that case it's vulnerable to different attacks. Therefore it'd be better to allow it be configured only if a user has a physical access to the device. R6 Sleeping nodes support: is a requirement to support devices that could not be directly discovered at any time due to their sleep modes. This requirement makes possible to provide permanent access to impermanent resources via registration and updating device's data at the additional permanent proxy server.

III. Overview of the approach

Our approach is a set of guidelines that the developer of an ESP8266-based device should follow, so he or she could use the mobile application to command it.

A. Device software guidelines

To satisfy defined requirements The Constrained Application Protocol (CoAP) was selected [5]. CoAP is a specialised web transfer protocol working upon UDP (but could support TCP, SMS or any other channels and packets standards). CoAP is binary protocol and designed for use with constrained nodes and constrained networks in the Internet of Things. Observe option is standardised too and discovery and resource directory are in progress of standardisation, so draft version is used. CoAP is also using the RFC 6690 Constrained RESTful Environments (CoRE) Link format to describe the access to the resources.

To provide access to devices which are sleeping most of the time, several methods are provided. First of all, there is a configurable system parameter for every device, that could contain predefined system URI that could gather the data from the updating resources constantly and could be changed during initialisation or wake-up cycles. Secondly, support of the Resource Directory CoRE standard draft[10] is provided where Resource Directory resource could be registered at permanent client. Such resource directory is recognisable automatically in local network by any device and could register and update information about inpermanent devices to provide unified access to them.

Every device is executing CoAP server logic. CoAP server is building correct answers for the requests for some resources and also support subscribing to them and is recognisable in local network via GET-requests to "/.well-known/core"-resource.

Private resources requires basic authorisation option in normal mode. Fig. 1 represents interaction between device with the CoAP server and clients.

Fig. 1. Device's interaction diagram

This logic could also be represented upon the HTTP or some other protocol similar to SmallHydra project. But, according to Senior IT Architect at IBM India [11], HTTP for Internet of Things embedded devices is a lot slower, less reliable and uses more battery. CoAP fits the defined requirements best at the moment.

We have selected Arduino libraries for the ESP8266 platform, because they're compiling directly to binary firmware for the device with the native C++ SDK [13]. Prepared Arduino-based solution could be simply ported to other Arduino-compatible devices with enough resources, such as ESP32 or Arduino Nano and the communication modem could be changed too without changing other parts of the solution. Fig. 2 describes firmware model. CoAP Arduino server is implemented from scratch due to lack of functionality in other C-based implementations.

imPort , Arduino

ESP8266 import

Device Firmware

1

Espressif ESP8266 SDK

-i m port--

import

1 1

MiniCoAP library Hyper-Media Resources libraries

Arduino DHT sensor library Arduino other library

Fig. 2. Device's model diagram

Every resource of the device is independent and handled by the server. Server's implementation class diagram is represented at Fig. 3. MiniCoAP server is our CoAP server for Arduino-based devices with observe option and basic authentication support.

Fig. 3. Server's class diagram

According to the defined requirements, resources should be annotated and provide model-instance representation. Transfer protocol is not enough, so semantics is defined at the next chapter.

B. Device design guidelines

To met the requirement R5 the device should implement a way to physically switch to the configuration mode. Since ESP8266 module can work as a Wi-Fi node as well as a Wi-Fi access point, we suggest to use the access point mode as the configuration mode. The mode should be switched by pressing a hardware button on a device.

When a user presses the button, the device should switch to the Wi-Fi access point mode (in the documentation for ESP8266 it's called "SoftAP mode") and create it's own local network. Then a user should be able to connect to the network with a smart phone or computer and interact with the configuration API. The guidelines for the API is listed in Section m-D.

Algorithm 1 presents a code snippet that shows how to switch to the configuration mode.

Algorithm 1 Switching to the configuration mode isButtonPressed = digitalRead(BUTTON PIN); if (isButtonPressed) {

if (WiFi.getMode() != WIFI AP) { WiFi.mode(WIFI_AP);

WiFi.softAP(SOFT_AP_SSID, SOFT_AP_PASS);

}

}

Others should have access only to the public API of a device. The public API provides access to device's measurements and controls. The guidelines are listed in Section HI-C.

C. Device Public API Guidelines

Mobile application will be able to communicate with a device only if it describes itself. Such descriptions should include characteristics of a device (e.g. location, label, identifier, etc.) and operations it supports. Our approach is based on using JSON-LD [17] as the messaging model and Hydra Core [7],

Schema [15] and partially Semantic Sensor Networks [8] as vocabularies for describing the APIs of ESP8266-devices.

The description of a device should consist of several parts:

• The Well-Known Core - it's the main resource (/.well-known/core) described in RFC5785 [16] specification. It lists all the resources supported by the API. The Device Resource should have property rt set to http://schema.org/EntryPoint which means that the resource is the entry point of the API.

• API Documentation - contains the definition of the device model, its supported properties and operations, types of supported links to other resources. To simplify the development of the API Documentation an external context were prepared, it available on https://w3id.org/semiot/ device/commoncontext#. Examples of the documentation are in Algorithm 2 and 3.

• Device Resource - describes the device itself as an instance of the device model defined in the API Documentation. It may have links to actions and values. Examples are in Algorithm 4 and 5.

• Value Resource - describes the latest value provided by the device. It may be an observation, measurement, etc. It should be an observable resource.

• Action Resource - describes the result of an action performed by the device. E.g. switched on/off a lamp. It may support the POST requests to activate the action. It should be an observable resource.

API Documentation can be stored on the device or available on Internet, so the mobile application could download it. To define the API Documentation, Hydra Core and Schema.org vocabularies are used.

D. Device configuration API guidelines

The configuration API is similar to the public one, it reuses the API Documentation and has a single resource /config which should support GET and PUT operations. In Algorithm 6 the configuration of the Temperature Sensor is presented.

IV. Architecture of the mobile application

Architecture of the mobile application is based on Hydra API. The mobile application communicates with devices using CoAP protocol and gets a description of the devices from an external documents. This approach allows to change the information about device without interfering in his work, it is useful, for example, for extending of the supported languages in the description of the device or edit the available properties. Also this approach allows to create adaptive application that will change the displayed information depending on each device properties. It also simplifies configuring available device, for example, impose a the string length limit of the field or accepted characters range and so on without being attached to any particular field or type of the actual device.

The architecture of application was built by using this approach and is presented on Fig. 4. As can be seen from this figure, when new device is being added and configured, the device configuration module is refereed and this module invokes the configuration subsystem. This subsystem requests the configuration data from the device and builds page which

Algorithm 2 API Documentation of the Temperature Sensor

API_

{

"@context": [

"https://w3id.Org/semiot/device/commoncontext#", { "doc": "http://external/doc#" }

],

"@id": "doc:ApiDocumentation", 0 "@type": "ApiDocumentation", 0: "supportedClass": [

{ "@id": "doc:TempDevice", "subClassOf': "Device", "supportedProperty": { "property": "location", "writable": "true", "label": "Location"

"supportedProperty": { "property": "label", "writable": "false", "label": "Label"

"supportedOperation": { "method": "PUT", "expects": "doc:TempDevice", "returns": "doc:TempDevice"

}

}.

{ "@id": "doc:temperature", "@type": "Link",

"range": { "@id": "doc:TemperatureValue", "subClassOf': "QuantitativeValue", "label": "Temperature (C)"

}

}

]

}

is displaying to the user. Displayed fields have a certain type, such as text or numeric, and the description of them. But it depends on the received configuration data. If any limiting data such as the maximum number of input characters or numeric range are specified, it is also taken into account in constructing these fields.

The data display subsystem is used to show the information from the device. It consists of a data acquisition module and building forms module for the final displaying to the user. Building forms module requests the description of the device that is located in the external document and pre-determines the type of data (observations or operations). Depending on the type invokes a special module for constructing the necessary forms. The required information for such a construction is also taken from the description of the device, on the basis of received information an application determines what data is used and the display format. For example, the possible ways to work with them (for example, where to send requests for changing the status of the device and which settings are necessary for the transmission) are determined for the operations. At the same time the data acquisition module determines the type of the device (active or sleeping) and

Algorithm 3 API Documentation of the Lamp API

1

@context": [

"https://w3id.Org/semiot/device/commoncontext#",

{ "doc": "http://external/doc#" }

"@id": "doc:ApiDocumentation", @type": "ApiDocumentation", 0: "supportedClass": [

{"@id": "doc:LampDevice", "subClassOf': "Device", "supportedProperty": { "property": "location", "writable": "true",

"label": {"@value": "Location", "@language": "en"} }.

"supportedProperty": { "property": "label", "writable": "false",

"label": {"@value": "Label", "@language": "en"}

}.

"supportedOperation": { "method": "PUT", "expects": "doc:LampDevice", "returns": "doc:LampDevice"

}

}.

{"@id": "doc:shineAction", "@type": "Link", "range": "ControlAction", "supportedOperation": { "method": "GET", "returns": "ControlAction"

"supportedOperation": { "method": "POST', "expects": "doc:TurnOnAction"

"supportedOperation": { "method": "POST", "expects": "doc:TurnOffAction"

}

}.

{"@id": "doc:TurnOnAction", "subClassOf': "ControlAction", "label": {"@value": "Turn on", "(»language": "en"}, "supportedProperty": { "@type": "PropertyValueSpecification", "property": "doc:brightness", "label": {"@value": "Brightness", "@language":

"en"},

"valueRequired": "false", "defaultValue": "50", "minValue": "0", "maxValue": "100"

}

}.

{"@id": "doc:TurnOffAction", "subClassOf': "ControlAction", "label": {"@value": "Turn off', "@language": "en"}

}

]

}

Algorithm 4 Device Resource of the Temperature Sensor

1

" @context": "http://externaI/doc#",

"@id": "coap://l. 1.1.1/",

"@type": "TempDevice",

"identifier": "e9704",

"label": "Temperature Device",

"location": {"@type": "Place", "label": "1010"},

"temperature": "/temperatureValue"

j_

Algorithm 5 Device Resource of the Lamp

1

" @context": "http://external/doc#", "@id": "coap://l. 1.1.1/", "@type": "LampDevice",

"label": {"@value": "Lamp #1010", "@language": "en"}, "identifier": "e9704",

"location": {"@type": "Place", "label": "1010"}, "shineAction": "/shine"

}

depending on these data requests information from the local store or send the request directly to the device.

The module for receiving data from the sleeping device is a service job and it's run in the background. When the device wakes up, it transmits data with the state to the mobile application and this module, when the module has received it and saves it in the local store for future access.

For building a mobile application is based on the architecture that was described above, need to provide user interaction with the above modules, as well as to implement these modules. Processes were analysed for the design of subsystems and we compiled data flow diagrams.

The diagram which is presented on Fig. 5, shows the display of all available devices which are connected to current Wi-Fi network. Sleeping devices had transmitted data on this network are also displayed. For displaying all devices run a query to a local data store to get out die received data from the sleeping devices. Also broadcast CoAP request was sent to the network. All devices that are received this query return their id and label. Then a list of available devices are created and returned to the user.

Fig. 6 shows a diagram of adding a new device. To do this, the user connects to a device's Wi-Fi network. Once

Algorithm 6 The configuration of the Temperature sensor 1

" @context": "http://external/doc#", "@id": "/config",

"@type": "Configuration", "wifiName": "wifi-network", "wifiPassword": "password", "username": "superuser", "password": "strongpass", "deviceName": "My Device"

}

Fig. 4. Architecture of the mobile application

Fig. 5. Data Flow Diagram. Show list of devices

Fig. 6. Data Flow Diagram. Configuration

connected, the GET request was sent to the CoAP for obtaining configuration data from the device. The response to this query contains available for configuration data, such as network name and password which the device should be connected after it had been configured, the label of the device, and so on., as well as limiting the field data, for example, the maximum length of the string, and so on. Once the user page is generated with the configuration data, and the user can edit them. When the user saves them, then a part of the data from the device is saved locally (data such as the username and password for future access to a private device resources, its id) and sent PUT request with the data on the device.

Fig. 7. Data Flow Diagram. Show device information

On Fig 7 presented a model that using for viewing an information from device. Page with such data, are generated based on the description of the device. The description is a response for request which is sent to an external document containing this description. Authentication data is requested from local storage for this device to be able to request information from private resources. After that device's entrypoint URI is requested by making a GET request to / . we 11-known/core. URI, having http: //schema.org/EntryPoint type is a sought-for entrypoint. Next, the GET request is done to entrypoint URI, there are obtained data on the external URL of the document describing the relative address and device resources. The document with describing the device stores a description for all operations are possible with this device, and measured them evidence (if present). Further, the GET request is performed to CoAP resource. Response to this request contains information on the latest operation and/or the last observation. Since this resource is associated with the description of the device, the data associated with the mapping.

To perform operation on the device fields with property are generated based on description (if they are presented). After user starts a operation execution then the appropriate CoAP-method are sent.

V. Case study

Here we are describing specific devices and mobile application, corresponding provided approach and characterises details of the implementation.

We have implemented two independent separated devices: temperature sensor and bulb lamp actuator. Both of them are based on Espressif ESP8266 system on chip controller, which have a Wi-Fi modem.

Temperature device is based on ESP8266 Wi-Fi module and DHT22 digital temperature and humidity sensor. Bulb lamp actuator is based on ESP8266 Wi-Fi module and digital voltage relay. Temperature device is represented in Fig. 8.

Fig. 8. Temperature ESP8266-based device

Every device is recognisable at the local network by the standard / .we 11 -known/core resource. All available devices could be found and controlled by the client via multicast request or via recognisable server containing Resource Directory resource.

The GET multicast request with the / . well-known/core?rt=core. rd request URI message will not be ignored only by resource directory because it is qualified by the query string.

The resource type of the / root URI is marked as http://schema.org/EntryPoint at the /.well-known/core answer to provide Entry Point link for the client. Root resource contains main information about the device as a system. The example of the answer description is provided at Algorithms 5 and 4. PUT-request is also supported for configuration according to the defined requirements.

Root resource description directs us to the external documentation resource that could be shared between different devices. Examples of the answer for the GET request for the temperature and lamp devices are provided in Algorithms 2 and 3.

All sensitive resources' methods could be private. Configuration resource /configis private too. It only available for GET and PUT requests in configuration mode or in normal mode with the correct basic authentication credentials.

Additional CoAP option with number 40 is provided during the research. The option pay load should contain SHA-1 hash from concatenated login and password strings to provide authorisation. Config resource request provided on Fig. 6. Software Wi-Fi Access point's SSID for initial configuration is based on the chip identifier and the password is standard

and the same for the devices. CoAP headers is minimal and JSON payload could be compressed with the MessagePack solution [12] for about 50% to maximise the transfer rate.

Mobile application is based on the Android SDK. The solution is available at public project repository [14].

VI. Conclusion

In this paper we showed how to build a mobile application which dynamically generates its user interface based on the self-descriptive API of connected devices. The guidelines for building connected devices with self-descriptive API are presented.

In case study we applied the guidelines in two devices and found them useful and appropriate for these types of devices. If believe that the similar approach can be applied for MQTT and similar protocols.

Acknowledgment

This work has been supported by the Ministry of Education and Science of the Russian Federation (Grant #RFMEFI57514X0101).

References

[1] J.E. Kim, G. Boulos, J. Yackovich "Seamless Integration of Heterogeneous Devices and Access Control in Smart Homes" in Proc. of 8th International Conference on Intelligent Environments (IE), 2012, pp. 206-213

[2] P. Desai, A. Sheth, P. Anantharam "Semantic Gateway as a Service Architecture for IoT Interoperability" in Proc of IEEE International Conference on Mobile Services, 2015, pp. 313-319

[3] M. Lanthaler, and C. Giitl, "Hydra: A Vocabulary for Hypermedia-Driven Web APIs", LDOW, vol.996, 2013

[4] R.T. Fielding "Architectural Styles and the Design of Network-based Software Architectures", PhD thesis, University of California, 2000

[5] Bormann, C., Castellani, A. P., Shelby, Z. "CoAP: An application protocol for billions of tiny internet nodes", IEEE Internet Computing, vol. 16(2), 62, 2012.

[6] Ankolekar, Anupriya, et al. "DAML-S: Web service description for the semantic web." International Semantic Web Conference. Springer Berlin Heidelberg, 2002.

[7] Lanthaler M. "Creating 3rd Generation Web APIs with Hydra" Proceedings of the 22nd International Conference on World Wide Web, 2013, pp. 3538.

[8] M. Compton, P. Baraaghi, L. Bermudez, R. Garca-Castro, O. Corcho, S. Cox, et al., 'The SSN ontology of the W3C semantic sensor network incubator group', Web Semantics: Science, Services and Agents on the World Wide Web, vol. 17, December 2012, pp. 25-32.

[9] GitHub, A small Hydra library for the ESP8266 using the ES-PAsyncWebServer, Web: https://github.com/bergos/smallhydra.

[10] IETF Tools, CoRE Resource Directory Draft 8, Web: https://tools.ietf. org/html/draft-ietf-core-resource-directory-08.

[11] IBM developerWorks, Why HTTP is not enough for the Internet of Things, Web: https://www.ibm.com/developerworks/community/blogs/ mobileblog/entry/why_http_is_not_enough_for_the_internet_of_things.

[12] MessagePack, It's like JSON. But fast and small. Arduino C implementation, Web: http://msgpack.org/.

[13] GitHub, ESP8266 core for Arduino, Web: https://github.com/esp8266/ Arduino.

[14] GitHub, SemloT project, Web:https://github.com/semiotproject

[15] Schema.org, Web: http://schema.org

[16] RFC 5785 - Defining Weil-Known Uniform Resource Identifiers (URIs), Web: https://tools.ietf.org/html/rfc5785

[17] JSON-LD 1.1 - A JSON-based Serialization for Linked Data, Web: http://json-ld.org/spec/latest/json-ld/