msgbartop
Блог для общения группы товарищей, объединенных идеями удобного управления знаниями, интеграции wiki и онтологий
msgbarbottom

27 Ноя 09 Фасетный поиск по Wikipedia/DBPedia

В конце сентября был запущен фасетный поиск на данных, которые DBPedia извлекла из Википедии. Проект делался совместно с немецкой поисковой компанией Neofine и находится здесь: http://dbpedia.neofonie.de/browse/.
Таким образом, теперь для ответа на вопросы типа «Какие ученые родились в России в период с 1900 по 1910 год» нам не нужно знать SPARQL, а достаточно использовать соответствующие фильтры в интерфейсе поисковика от DBPedia и Neofine: http://dbpedia.neofonie.de/browse/rdf-type:Scientist/personBirthDate-year~:1900~1910/personBirthPlace:Russian%20Empire/ (обратите внимание на человеко-читаемые урлы, в которых можно увидеть названия свойств и концептов из RDF представления DBPedia).

В фильтрах есть контекстные подсказки, благодаря которым для задания запроса необязательно знать терминологию онтологии DBPedia.

Существенных недостатков пока обнаружено несколько:

  • Данные требуют унификации.  В списке стран, например, можно обнаружить и Russian Empire и Russia, и мы получаем разные результаты для этих случаев: http://dbpedia.neofonie.de/browse/rdf-type:Scientist/personBirthDate-year~:1900~1910/personBirthPlace:Russian%20Empire/ и http://dbpedia.neofonie.de/browse/rdf-type:Scientist/personBirthDate-year~:1900~1910/personBirthPlace:Russia/. Понятно, что авторы английской Википедии использовали разные названия для страны, но если при чтении текста это было некритично, то при использовании в процессе вывода становится серьезной проблемой
  • Пока есть поддержка только английской версии энциклопедии. Будем надеяться, что в скором времени фасетный поиск будет реализован также для русского и других языков.

Несмотря на это, фасетный поиск по Wikipedia/DBPedia был назван немецким правительством одной из 365 самых инновационных идей в Германии.

Метки: , , , , ,

08 Ноя 09 Впечатления от открытой лекции Криса Мессины: Identity is the Platform в Петербурге

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

Сказав пару слов о своей карьере, Крис перешел к анализу представления персональной информации в web, а также о проблеме хранения и ценности данных пользователей в социальных сетях и о проблеме разнородности и несовместимости веб-сервисов.  Как справедливо отметил Крис, сегодня Интернет – это не сеть документов, а сеть людей, соответственно и технологии должны быть ориентированы на представление людей в сети. Основная борьба на этом направлении развертывается между Facebook Connect и OpenID. Именно второй технологии, являющейся открытой альтернативой первой, и была посвящена основная часть лекции. Крис привел примеры сервисов и компаний, которые уже используют OpenID, среди которых Google, Yahoo!, WordPress и др. Другой удивительный пример – это правительство Эстонии, которое выдало смарт-карты с OpenID и запустило сервис openid.ee для своих граждан. Такие же планы вынашивает и правительство США. Далее Крис рассмотрел различные аспекты того, каким образом личность может быть «платформой» в Интернете. В частности, речь шла о специальных сервисах, которые позволяют удостовериться, что за каким-либо акаунтом стоит реальный человек. Другим аспектом является использование более интеллектуальных фильтров и агентов пользователя, первым из которых, кстати, был навязчивый помощник MS Office, увы отрезанный от сети и поэтому бесполезный. Качество работы современных пользовательских агентов зависит напрямую от количества пользователей, пользующихся тем или иным сервисом. Поэтому очень важным является возможность передачи пользовательского «капитала данных» от одного сервиса к другому. Еще одним аспектом является множественность личностей, которыми Вы захотите воспользоваться в различных контекстах. Наконец, важной представляется ценность самих пользовательских данных, которая не должна зависеть от функций того или иного сервиса, а только от активности их владельца.

Посмотреть видеозапись лекции можно тут, а слайды к лекции здесь.

Спасибо организаторам лекции за это интересное мероприятие.

08 Окт 09 Открытая лекция Криса Мессины: Identity is the Platform в Петербурге.

В понедельник, 12 октября, в ИТМО с открытой лекцией выступит Крис Мессина (Chris Messina). Идеолог Open Web, один из создателей баркемпа расскажет о том, какое будущее ждет открытые форматы в Интернете и социальные сети. Это не будет лекция в классическом понимании. Крис – профессиональный спикер на международных конференциях и встреча будет проходить в формате доклада и дискуссионной панели.

Место и время проведения: 12 октября в 18:00 по адресу Кронверкский просп., 49
(СПб ГУ ИТМО).

Сайт мероприятия: http://nevacamp.com/ru/messina-talk

08 Июл 09 SEMANTIC WEB for the WORKING ONTOLOGIST (Dean Allemang, Jim Hendler). Часть 2 – Архитектура Semantic Web приложений.

Semantic Web for Working Ontologist (Dean Allemang, Jim Hendler)

Обложка книги

Первая часть обзора книги

В этой части обзора книги мы расскажем о видении авторами архитектуры Semantic Web приложений, хранилищах RDF, движках запросов RDF, SPARQL, микроформатах, RDFa и GRDDL.

Можно выделить следующие типы компонентов, составляющие Semantic Web приложение:

· RDF Parser/Serializer — тут все понятно. Например, можно использовать java-библиотеку Jena от HP.

· RDF хранилище (RDF Store) аналог базы данных для хранения RDF-троек и запросов к ним. В дополнение к обычным функциям баз данных RDF хранилище имеет возможность сливать данные из разных источников, используя URI для идентификации одинаковых объектов.

· Движок запросов RDF (RDF Query Engine). Позволяет получать информацию из хранилища RDF посредством структурированных запросов.

Источники данных для RDF

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

Способы извлечения RDF информации из HTML-страничек можно классифицировать следующим образом:

  • Автор документа потратил дополнительное время и аннотировал HTML метаинформацией. Возможны три варианта реализации аннотаций:
    • RDFa (ссылка на словарь с терминологией есть прямо в файле)
    • Микроформаты (стандартный жестко заданный словарь для метаинформации, например hReview).
    • GRDDL (наложение указанного в файле XSL шаблона на сам HTML файл приводит к получению RDF файла, для этого исходный файл должен быть валидным XHTML документом). В этом случае можно, например, воспользоваться GRDDL Scraper.

      Недавно у вебмастеров появился стимул использовать семантическое аннотирование, требующее от них существенных дополнительных усилий: Google, вслед за Yahoo, теперь также индексирует и использует микроформаты и RDFa.

  • Если RDF метаданных в документе нет. В этом случае можно воспользоваться специальным инструментом, который называют scraper (дословный перевод на русский язык – «скребок»). В нем можно задать отношения полей исходного документа (если, конечно, данные в нем хорошо структурированы, например, задаются в таблице) и в итоге после настройки и запуска инструмента из странички можно будет получить RDF файл. Примеры таких инструментов: RDF Web Scraper и Solvent от MIT, последний из которых выполнен в виде плагина к Firefox (правда себе я поставить не смог, т.к. с версией 3.0.11 он оказался не совместим:( ).

RDF хранилище (RDF Store)

Фундаментальное отличие RDF хранилища от реляционной базы данных заключается в возможности автоматически сопоставлять две различные записи из разных источников, если они относятся к одному объекту. Благодаря гибкости модели данных RDF эта процедура четко определена: любые два ресурса с одним URI будут считаться эквивалентными в итоговом наборе данных.

Существуют различные реализации RDF хранилищ: от самых простых в виде таблички с тремя колонками (для subject, predicate и object) до коробочных решений от вендоров. Для качественной реализации последних нужно решить проблемы эффективных индексов для строковых данных URI. Серьезные провайдеры RDF хранилищ дифференцируют свои предложения в зависимости от масштабируемости и эффективности индексации.

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

Движки запросов RDF (RDF Query Engines) и SPARQL

Обычно доступ к RDF хранилищу обеспечивается с помощью языка запросов, и в этом смысле оно похоже на реляционную базу данных или XML хранилище. В ранние годы стандарта RDF существовало несколько разных языков запросов, поддерживаемых каким-либо RDF-продуктом или open-source проектом. На основе общности этих языков W3C стандартизовал язык запросов SPARQL.

Базу SPARQL запроса составляют шаблоны троек. Шаблон тройки выглядит как обычная RDF тройка, но может еще содержать переменные на месте ресурсов на любой из трех поизиций (subject, predicate, object). Переменные обозначаются специальным символом «?» перед именем.

Примеры валидных шаблонов троек:

    ?w lit:wrote lit:KingLear.
    lit:Shakespeare ?r lit:KingLear.
    lit:Shakespeare lit:wrote ?p.

Обозначают эти шаблоны следующее:

Кто написал Короля Лир?
Какое отношение связывает Шекспира и Короля Лир?
Что написал Шекспир?

Т.к. набор RDF троек можно рассматривать как граф, более интересным будет запрос, определяющий шаблон графа в виде набора шаблонов троек, где одинаковые переменные соответствуют одному и тому же ресурсу. Граф заключается в фигурные скобки:

    {?person bio:livedIn ?place.
    ?place geo:isIn geo:England.
    ?person lit:wrote lit:KingLear.}

Неформально эти запросы спрашивают:

«Найти человека, который жил в месте, которое находится в Англии и который также написал Короля Лир».

В SPARQL есть не только SELECT запросы, но CONSTRUCT запросы, которые на основе двух графовых шаблонов позволяют строить новый граф. Понять, зачем это нужно, проще на следующем примере: допустим, у нас есть утверждение из Википедии о том, что Шекспир написал «Гамлета», которое в RDF будет выглядеть так:

    q:n1 rdf:subject lit:Shakespeare;
    rdf:predicate lit:wrote;
    rdf:object lit:Hamlet.

Отношение самой Википедии к этому утверждению выглядит так:

    web:Wikipedia m:says q:n1.

Причем, это не равнозначно утверждению:

    lit:Shakespeare lit:wrote lit:Hamlet.

т.к. то, что Википедия это утверждает, еще необязательно значит, что мы верим в том, что Шекспир написал «Гамлета».

С помощью следующей конструкции SPARQL мы можем выбрать все реификации утверждений (reified statements, т.е. утверждения об утверждениях; дословный перевод reification на русский: овеществле́ние; материализа́ция), которые декларируются в Википедии:

    CONSTRUCT {?s ?p ?o}
    WHERE {?r rdf:subject ?s.
    ?r rdf:predicate ?p.
    ?r rdf:object ?o.
    web:Wikipedia m:says ?r.}

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

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

Стоит отметить, что в качестве источников информации для SPARQL запросов могут использоваться не только RDF хранилища. В этом случае нужен какой-то специальный код, который будет конвертировать возвращаемую информацию в форму, требуемую для SPARQL запроса. Такие приложения называются SPARQL endpoints, они используются все чаще и чаще и дают возможность предоставлять информацию для Semantic Web ресурсов, владеющих  данными в форматах, отличных от RDF.

Сравнение с реляционными запросами

В специальном случае, когда RDF хранилище реализовано в виде одной таблицы в реляционной базе данных, любой SPARQL запрос можно быть представлен в виде SQL запроса с self-join к этой таблице. Поэтому некоторые разработчики предпочитают при такой реализации работать со хорошо знакомыми им SQL запросами. Oracle пошел немного другим путем и предлагает для SQL разработчиков свое RDF расширение SQL, оптимизированное для графовых запросов. Синтаксис этого языка больше похож на SPARQL, но сильно итегрирован с table/join структурой SQL.

Приложения RDF

В качестве типичных примеров RDF приложений можно привести следующие:

  • Интеграция с календарем — показываем встречи разных людей и команд на одном календаре
  • Интеграция с картами — местоположения интересных мест, собранных с разных веб-сайтов, электронных таблиц и баз данных на одной карте
  • Аннотации — вместо обычных тэгов к информации используем тэги c URI (например, сервис социальных закладок Faviki)
  • Управление контентом — создание единого индекса информационных ресурсов (документов, электронных таблиц, веб-страниц, баз данных и т.п.), которые доступны в нескольких хранилищах контента.

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

Интеграция данных (Data federation).

Отделение стратегии интегрирования данных от операционных задач приложений, когда ему не нужно знать, откуда именно происходит конкретная RDF-тройка позволяет одному запросу бесшовно оперировать с несколькими источниками данных. Это существенно отличает приложения RDF от приложений с базами данных: например, в случае, когда приложение использует 2 базы от разных вендоров (Oracle и mySql, например), мы не можем написать один SQL-запрос для выбора продуктов и цен на них, если данные об именах продуктов хранятся в одной базе, а цены другой (в случае 2-х баз Oracle это было бы возможно, т.к. можно сделать db link). Нам в этом случае нужно делать 2 выборки и писать код, который их объединяет. В случае использования SPARQL это не так, нам нужен один запрос и подключение к RDF хранилищу обоих источников данных. Таким образом, интегрирование с новыми источниками данных не повлияет на запросы самого приложения, а, следовательно, мы получаем возможность создавать более устойчивые и гибкие решения.

Reblog this post [with Zemanta]

Метки: , , , , , ,

16 Май 09 SEMANTIC WEB for the WORKING ONTOLOGIST (Dean Allemang, Jim Hendler). Часть 1.

Semantic Web for Working Ontologist (Dean Allemang, Jim Hendler)

Креативная обложка, символизирующая динамичную водоносную систему

Однозначный must read и просто увлекательное чтиво для всех, кто интересуется Semantic Web и представлением и обработкой знаний, в том числе и с помощью онтологий. Ничего подобного по уровню изложения и осмысленности по данной тематике мне пока не встречалось. Авторы концентрируются на реальных примерах моделирования, задают правильные вопросы и разжевывают для читатели все узкие места так, что даже самые сложные вещи начинают казаться простыми и очевидными (ИМХО, признак высочайшего профессионализма).

В книге много мыслей, способствующих появлению глубокого понимания Semantic Web, его стандартов и принципов моделирования. Наиболее яркие и запомнившиеся из них приведены ниже.

Зачем нам нужен Semantic Web?

Первая глава посвящена целиком вопросу: что такое Semantic Web и зачем он нам? Представим себе такой пример: мы хотим поехать в национальный парк отдыхать и у нас есть любимая сеть отелей, в которой мы любим отдыхать, т.к. у нас там есть большая скидка для постоянных клиентов. На сайте национального парка мы видим, что отель нашей сети находится в его окрестностях, но, заходя на сайт сети отелей, мы не можем отыскать этот отель и забронировать номер, т.к. его там по какой-то причине больше нет. Остается только расстраиваться из-за этой несогласованности данных.

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

В один прекрасный день из газет вы узнаете о том, что International Astronomical Union (IAU) принял решение о том, что Плутон, который до 2006 года считался планетой, следует относить к новой категории «карликовая планета». Вы устремляетесь на сайт и видите, что на странице про Плутон его уже относят к карликовой планете. Но когда вы открываете страницу со списком всех планет, оказывается, что Плутон все еще находится там.

Проблема в обоих примерах в том, что представление данных неконсистенто и рассихронизовано.

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

Semantic Web идет дальше этих решений и предоставляет инфраструктуру для связывания данных не только в рамках определенных приложений, но и во всей распределенной Сети с помощью глобальных идентификаторов ресурсов (URI). Когда сеть отелей публикует информацию о местоположении отелей, она публикует не только ее представление для человека, но и ее кодирование в машиночитаемой форме. Модель, которая используется для представления этой сети распределенных данных называется Resource Description Framework (RDF).

Для понимания принципов проектирования Semantic Web, Dean Allemang и Jim Hendler приводят следующие три особенности распределенной сети данных:

  • Слоган «Кто угодно может сказать что угодно о чем угодно (АAА slogan Anyone can say Anythingabout Any topic). Данные не управляются из одного большого датацентра, и любой человек может выразить свои знания о сущностях таким образом, чтобы они могли объединяться с информацией из других источников. Это способствует так  называемому сетевому эффекту (network effect), когда каждый новый присоединившийся к сети человек приносит еще дополнительный смысл и способствует его экспоненциальному росту.
  • Предположение о неуникальном именовании объектов (Nonunique Naming Assumption). Т.е. есть два объекта с различными именами могут быть одинаковыми (например, одна из карликовых планет UB313 известна также под именем Xena).
  • Предположение об открытости мира (Open World Assumption). Следствие ААА слогана. Мы практически не можем в рамках Sematnic Web делать утверждения вида «существует ровно девять планет», т.к. могут открыться факты, о которых мы еще не знаем.

Последнее предположение перекликается с теоремой Гёделя о неполноте, и это дает основания предположить, что в рамках Semantic Web рождается новая сетевая логика – основа будущего виртуального мира.

Средства моделирования в Semantic Web

Три принципа распределенной сети данных создают окружение для эффективного обмена информацией. Но такой стиль сбора информации может привести к информационному хаосу и конфликтам. Задача инфраструктуры Semantic Web поддержать переход из этого хаотического состояния в такое, в котором возможен продуктивный обмен информацией, кооперация и сотрудничество. Делается это с помощью моделирования – процесса организации информации для использования комьюнити. Модель предоставляет для этого три решения: общую схему для коммуникации между людьми, средства для объяснения выводов, структуру для управления разными точками зрения.

Semantic Web предлагает несколько инструментов моделирования отличающихся уровнем выразительности. Чем выше уровень выразительности, тем, как правило, сложнее модель, но и тем выше ее информативность. Для примера рассмотрим три модели молекулы воды H2O:

Различные представления молекулы воды H20

Различные представления молекулы воды

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

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

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

Ниже представлены языки Semantic Web от менее выразительных к более выразительным:

  • RDF — The Resource Description Framework. Основа всех моделей Semantic Web. Позволяет формулировать утверждения о чем угодно (с помощью троек subject-predicate-object) и составлять из них единую модель. RDF рекомендован W3C c 2003 года.
  • RDFS The RDF Schema language. RDFS – это язык, обладающий достаточной выразительностью для описания базовых понятий общности и изменчивости хорошо известных из объектных языков и других систем классов – а именно классов, подклассов и свойств. RDFS рекомендован W3C c 2003 года.
  • RDFS-Plus. RDFS-Plus является более выразительным, чем RDFS, подмножеством OWL, но при этом не обладающий сложностью OWL. Позволяет описывать способы использования определенные свойства и отношений между ними. Стандарта RDFS-Plus пока нет, но есть понимание, что что-то между RDFS и OWL может быть значимым для индустрии.
  • OWLWeb Ontology Language. OWL привносит в Semantic Web выразительность логики. Он позволяет описывать детальные ограничения между классами, сущностями и свойствами. OWL рекомендован W3C c 2003 года.

Моделирование в RDF

Допустим, у нас есть большая таблица базы данных. Мы не хотим держать ее на одной машине, а хотим, чтобы информация из нее располагалась где угодно в сети, чтобы любой человек мог добавлять туда новые данные (ААА слоган), но при этом всю доступную информацию можно было корректно объединять. В RDF это можно сделать, преобразовав таблицу в набор троек: subject-predicate-object, где subject – сущность, описываемая в таблице (если таблица содержит описания продуктов, то для продукта с ID=1 это может быть Product1), predicate – колонка в таблице (например, Manufacturer), object – значение соответствующей ячейки в таблице. После этого следует добавить тройки с утверждениями о совпадающем типе всех сущностей продуктов вида: Product1-rdf:type-Product

Использование URI в качестве глобального идентификатора позволяет понять, когда два человека где угодно в мире говорят об одной сущности. Важно, что URL является частным случаем URI, если удается разыменовать его в конкретный протокол, сервер, порт и имя файла, чтобы получить файл или позицию в нем в глобальной сети. Для моделирования это не очень принципиально, т.к. от URI необходима только глобальная уникальность, но это позволяет участвовать моделям в глобальной инфраструктуре Сети. Например, URI свойства подкласса http://www.w3.org/2000/01/rdf-schema#subClassOf (rdfs:subClassOf) является также URL, по которому можно прочитать спецификацию этого свойства.

RDF также позволяет делать утверждения об утверждениях (reification). Например, так будет выглядеть утверждение, о том, что Википедии сказано, что Шекспир написал «Гамлета»:

q:n1 rdf:subject lit:Shakespeare ;
    rdf:predicate lit:wrote ;
    rdf:object lit:Hamlet .

web:Wikipedia m:says q:n1

Причем, это совершенно не означает того, что верно утверждение, что Шекспир написал «Гамлета», т.к. мы можем не доверять информации из Википедии.

Важную роль в RDF играют bnodes (blank nodes), благодаря которым мы можем делать утверждения о тех вещах, про которые мы знаем, что они существуют, но не можем их идентифицировать.  Например, мы знаем, что на 78-й сонет Шекспира вдохновила неизвестная англичанка. В N3 это будет выглядеть так:

lit:Sonnet78 lit:hasInspiration [ a :Woman;
    bio:livedIn :England] .

Заметьте, что эта запись вполне читабельна, несмотря на то, что написана на формальном языке.

На этом пока все. В следующих частях мы напишем про то, как авторы книги видят архитектуру Semantic Web приложений, RDFS-Plus (SKOS и FOAF) и моделирование на OWL.

P.S. Сервис bookfinder.com подскажет, где заказать «SEMANTIC WEB for the WORKING ONTOLOGIST». С доставкой в Россию будет дешевле.

Reblog this post [with Zemanta]

Метки: , , , , , ,

07 Апр 09 Кто и что пишет про управление знаниями по-русски

Среди литературы, посвященной проблеме управления знаниями, найдется с десяток книг российских авторов. Однако при цитировании большей популярностью пользуются их западные коллеги. Справедливо ли это? Данный обзор поможет дать ответ на этот вопрос. Итак, делаем запрос «управление знаниями» в интернет-магазине. В результате получаем приблизительно вот такой список:

  1. Мильнер Б. Управление знаниями. Эволюция и революция в организации. М. Инфра-М. 2003.
  2. Лабоцкий В.  Управление знаниями. Технологии, методы и средства представления, извлечения и измерения знаний. Современная школа. 2006.
  3. Дресвянников В. А. Построение системы управления знаниями на предприятии. КноРус. 2006.
  4. Мильнер Б.З., Румянцева З.П. и др. Управление знаниями в корпорациях. Дело. 2006.
  5. Лабоцкий В. Управление знаниями: технологии, методы и средства представления, извлечения и измерения знаний. Учебное пособие. БГЭУ. 2006.
  6. Баранчеев В.П.  Управление знаниями в инновационной сфере. Учебник для ВУЗов. ЦЭМ. 2007.
  7. Гапоненко А.Л., Орлова Т.М.  Управление знаниями. Как превратить знания в капитал. Эксмо. 2008. 
  8. Мариничева М. К. Управление знаниями на 100%: Путеводитель для практиков. Альпина Бизнес Букс. 2008.
  9. Дресвянников В.А. Управление знаниями организации. КноРус. 2008.

Список получился не такой уж и большой. Конечно, есть еще книги, содержащие отдельные главы, посвященные управлению знаниями и множество статей. Но в данном обзоре мы ограничимся только теми изданиями, которые целиком посвящены этой теме. Открывает список труд Бориса Захаровича Мильнера. Очевидно, это и есть первая крупная публикация по УЗ, написанная на русском языке. Так что следующий пост будет посвящен этому автору. К тому же книги Борса Захаровича удалось приобрести без проблем.

22 Мар 09 Сравнение популярности редакторов онтологий

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

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

Выбор онтологических редакторов и методика исследования

Неплохой список редакторов онтологий для старта есть в википедии. Для каждого редактора, использовался запрос следующего вида: "<название редактора>" ontology editor". В некоторых случаях в скобках ниже указаны результаты для более корректного запроса. Таким образом, для редакторов с не уникальными именами отсекались результаты поиска, не имеющие никакого отношения к онтологиям.

Упоминаемость онтологических редакторов в интернете

В итоге получились такие результаты (индекс Google за 21.03.2009):

  1. Protégé – 45 500
  2. OntoEdit – 16 800
  3. Altova SemanticWorks – 8 700 (запрос SemanticWorks ontology editor – 9220)
  4. Ontolingua – 7620
  5. KAON – 6130
  6. JOE (Java Ontology Editor) – 22 600 (joe java ontology editor ontology editor – 5930)
  7. SWOOP – 4 800
  8. OilEd (больше не поддерживается, раньше находился по адресу http://oiled.man.ac.uk/) - 4310
  9. TopBraid Composer - 1 090 (просто TopBraid ontology editor – 4280)
  10. DOME – 3060
  11. Chimaera – 1460
  12. OBO-Edit – 1340
  13. СMapTools - 1210
  14. WebODE - 1030
  15. OntoSaurus – 568
  16. LinKFactory (похоже, больше этот продукт не поддерживается, раньше был по адресу http://www.landcglobal.com/pages/products.php) - 394
  17. Knoodl – 223
  18. Synaptica – 143
  19. Model Futures OWL Editor – 130
  20. KADS22 – 41

Из этих данных, безусловно нельзя напрямую делать выводы о популярности редакторов в настоящее время. Например, появление KAON в группе лидеров связано с тем, что инструмент KAON OIModeler был одним из первых визуальных редакторов онтологий еще в 2004 году, когда хороших средств создания онтология было мало. А в 2005 году его перестали поддерживать и развивать. Т.е. по умоминаемости сложно сделать вывод о текущей популярности инструмента.

Интерес пользователей поисковых систем к редакторам онтологий

Для некоторых, упомянутых выше редакторов онтологий из получившегося рейтинга можно узнать интерес пользователей в поисковых системах. В сервисе подсказки ключевых слов Google Adwords (был выбран тип соответствия «широкое») получились следующие результаты по количеству запросов пользователей за последние 12 месяцев:

  1. СMapTools - 2 400 (что интересно, из них 1 300 запросов за февраль)
  2. TopBraid Composer (запрос TopBraid) – 1 600
  3. Synaptica - 720
  4. OntoEdit - 480
  5. LinKFactory – 391
  6. Altova SemanticWorks - 320
  7. WebODE - 260
  8. OBO-Edit - 260
  9. Ontolingua - 210
  10. OntoSaurus - 91
  11. Knoodl - 91

Как мы видим, тут данные достаточно сильно отличаются от упоминаемости, особенно выделяется большой интерес к TopBraid Composer и динамика возрастания интереса к СMapTools.

Какой же онторедактор самый популярный?

С первым местом вопросов никаких нет – это однозначно Protégé. С последующими местами ничего не ясно, но, как мне кажется, дальше должна быть группа в составе двух классных коммерческих редакторов – TopBraid Composer и Altova SemanticWorks. Думаю, очень популярным станет бесплатный СMapTools  (хотя относится он немного к другому классу: это редактор concept maps и topic maps, он не умеет сохранять свои проекты в формате owl). OntoEdit, на мой взгляд, не должен обгонять по используемости упоминаемые выше редакторы, т.к. у него даже нет бесплатной триальной версии.

А чем пользуетесь вы?

Метки: , , , , ,

11 Мар 09 Как создать правильную онтологию. Часть I

Об онтологиях написано много, и используются они достаточно широко, поэтому вопросы о том, что такое онтологии и зачем они нужны, будем считать очевидными. Тем не менее, сам процесс создания онтологий связан с рядом проблем: с чего начать создание онтологии, как определить, что онтология действительно содержит нужные знания, насколько хорошо составлена онтология, и можно ли ее улучшить? Если требуется разработать онтологию для какой-либо сложной предметной области, то успех начинания будет зависеть от того, знаете ли Вы ответы на эти вопросы, особенно, если над разработкой онтологии работают несколько человек. Стоит также помнить, что одна из главных целей создания онтологии — это обеспечение возможности «автоматических рассуждений», а, следовательно, знания, содержащиеся в онтологии, должны быть явными и формализованными.

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

  • таксономия — ведущее отношение «категоризация» или «классификация» (subsumption) — «kind-of» («is-a»);
  • партономия — ведущее отношение «составная часть», «компонента» (meronymy) — «part-of» («consists», «has part»).

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

После того, как определен тип онтологии, вводятся остальные компоненты (классы, атрибуты, экземпляры, правила, ограничения, аксиомы и т.д.). Однако в любой иерархии понятий рано или поздно возникает необходимость использования абстракций, и здесь могут возникнуть определенные сложности и противоречия. Самый простой способ избежать этих проблем — это использовать стандартные онтологии верхнего уровня или общие онтологии (upper ontology). Эти онтологии являются, своего рода, шаблонами или моделями, применимыми для создания на их основе множества прикладных или специализированных онтологий (domain-specific ontology). Общие онтологии содержат базовый глоссарий (тезаурус), в терминах которого могут быть описаны понятия и объекты предметной области. Ниже приведены наиболее известные общие онтологии.

Cyc (производное от «encyclopedia») — это всеобъемлющая (comprehensive) онтология, разрабатываемая с 1985 года компанией Cycorp, Inc. База знаний Cyc разделена на микротеории (Mt), коллекции концепций и фактов принадлежащих одной конкретной области знаний. В отличие от полной базы знаний, всякая микротеория должна быть свободной от противоречий. Микротеории могут быть организованы в иерархию и наследоваться одна от другой.

Basic Formal Ontology (BFO), разработанная Barry Smith, состоит из серии «подонтологий» различного уровня детализации. Онтологии разделены на две разновидности:  SNAP (snapshot)-онтологии, описывающие сущности (например, трехмерные объекты), и SPAN-онтологии, описывающие происходящие во времени процессы. Т. о. BFO представляет собой единую инфраструктуру для работы с трех- и четырехмерными описаниями действительности. Между двумя типами онтологий определены отношения, позволяющие использовать BFO для работы  как со статическими/пространственными (static/spatial), так и с динамическими/временными (dynamic/temporal) объектами и понятиями.

DOLCE — Descriptive Ontology for Linguistic and Cognitive Engineering, разработанная Nicola Guarino в лаборатории прикладных онтологий (Laboratory for Applied Ontology), представляет собой первый модуль из библиотеки WonderWeb. DOLCE предоставляет ясный когнитивный базис, нацеленный на описание лежащих в основе естественного языка и здравого смысла онтологических категорий. Пожалуй, DOLCE неплохое начало для большинства прикладных задач.

DnS (Descriptions and Situations), разработанная Aldo Gangemi в той же лаборатории (LOA, Rome), является конструктивистской (constructivist) онтологией, расширяющей описательные возможности DOLCE. DnS не накладывает ограничений на тип постулируемых сущностей и отношений ни с точки зрения спецификации предметной области, ни с точки зрения общей онтологии (верхнего уровня). Текущая OWL-реализация DnS включает DOLCE в качестве базового словаря верхнего уровня.

Как DOLCE, так и DnS в основном предназначены для работы с социальными сущностями, такими как организации, коллективы, планы, нормы и информационные объекты.

General Formal Ontology (GFO), разработанная Heinrich Herre и исследовательской группой Onto-Med, является реалистической (realistic) онтологией, интегрирующей процессы и объекты. Эта онтология включает как таксономические иерархии, так и их аксиоматизацию. К особенностям GFO относятся, среди прочего, учет сохраняемости (persistence) и временной модели (time model). Различие между типами endurants (objects) и perdurants (processes) определено в GFO с помощью специальной категории persistant. Для временной модели используются такие примитивы GFO, как интервалы (time intervals) и наследуемые временные пределы (time boundaries).

IDEAS, разработанная IDEAS Group, является экстенсиональной (extensional) 4D онтологией высшего порядка (higher-order). В основе данной онтологии лежит методология BORO. IDEAS не предназначена для использования в рассуждениях или выводе; ее назначение — построение точных моделей бизнеса.

Suggested Upper Merged Ontology (SUMO) — это еще один проект по созданию всеобъемлющей (comprehensive) свободной онтологии. Проектом руководит Adam Pease. В рамках проекта разработаны многочисленные специализированные (прикладные) онтологии. Также SUMO снабжена множеством ссылок на WordNet.

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

Метки:

10 Фев 09 Семантические запросы с помощью DBPedia

DBPedia – замечательный проект, который нацелен на извлечение структурированной информации из wikipedia и предоставление доступа всем желающим к этой информации с помощью SPARQL-запросов. Ребята пропарсили сниппеты из wikipedia (ту структурированную информацию, которую вы видите справа на многих страницах энциклопедии) и сделали из этого свою базу знаний, где хранят RDF-тройки: subject-predicate-object (например: wikipedia-url-www.wikipedia.org).
Как можно получить доступ к этой базе знаний можно посмотреть тут: http://wiki.dbpedia.org/OnlineAccess.
В качестве примера использования расскажу о способе узнать всех детей всех президентов России. Для этого для начала нам нужно сделать следующее:

  1. Понять, как же в DBPedia называется свойство «Президент России». Для этого мы идем на страницу Дмитрия Анатольевича Медведева и находим внизу категорию «Президенты России». Радуемся, что у этой категории есть англоязычная версия (иначе, к сожалению, мы не смогли бы выполнить наш SPARQL-запрос) - http://en.wikipedia.org/wiki/Category:Presidents_of_the_Russian_Federation. Этой странице, как и любой странице в англоязычной wikipedia, однозначно можно сопоставить страницу в DBPedia - http://dbpedia.org/page/Category:Presidents_of_the_Russian_Federation. Этот адрес и пригодится нам при написании SPARQL-запроса.
  2. На странице http://dbpedia.org/page/Dmitry_Medvedev находим название отношения «дети»:  »dbpprop:children«.
  3. Составляем SPARQL-запрос, получающий детей президентов России:
    SELECT ?president, $child WHERE {
    ?president skos:subject <http://dbpedia.org/resource/Category:Presidents_of_the_Russian_Federation> .
    ?president dbpedia2:children $child .
    }
  4. Выполняем наш запрос в интерфейсе SNORQL от DBPedia (в нем уже проставлены правильные пространства имен): http://dbpedia.org/snorql/?query=SELECT+%3Fpresident%2C+%24child+WHERE+{%0D%0A++%3Fpresident+skos%3Asubject+%3Chttp%3A%2F%2Fdbpedia.org%2Fresource%2FCategory%3APresidents_of_the_Russian_Federation%3E+.%0D%0A++%3Fpresident+dbpedia2%3Achildren+%24child+.%0D%0A++}

Как мы видим, wikipedia пока содержит мало информации о детях российских президентов. Немного лучше обстоит дело с американскими правителями: http://dbpedia.org/snorql/?query=SELECT+%3Fpresident%2C+%24child+WHERE+{%0D%0A++%3Fpresident+skos%3Asubject+%3Chttp%3A%2F%2Fdbpedia.org%2Fresource%2FCategory%3APresidents_of_the_United_States%3E+.%0D%0A++%3Fpresident+dbpedia2%3Achildren+%24child+.%0D%0A++}

Для заинтересовавшихся, еще несколько статей про DBPedia:

Метки: , , ,

26 Янв 09 Букович У., Уилльямс Р. Управление знаниями: руководство к действию

Авторы этой книги Уэнди Букович и Руфь Уилльямс входят в группу управления интеллектуальными активами компании PricewaterhouseCoopers. Полученный опыт позволили им разработать организационные методы извлечения дохода от интеллектуального капитала. Г-жа Букович также внесла существенный вклад в развитие дисциплины «Управление интеллектуальными ресурсами» в рамках проектов Global Best Practices KnowledgeSpace (компания Arthur Andersen), Knowledge Imperative Symposium, симпозиум по измерению и учету интеллектуального капитала (Организация экономического сотрудничества и развития – OECD), исследования нематериальных источников дохода (фонд Brookings Institution). Г-жа Уилльямс руководила новаторскими исследованиями в области процессов жизнедеятельности сетевых сообществ в компаниях Motorola, Shell Oil, Kaiser-Permanente, Ford Motor Company, Sun Microsystems. До этого Руфь работала в группе исследований нового поколения в Arthur Andersen. Разнообразный практический опыт авторов определяет направленность и стиль изложения книги: пошаговый план действий по управлению интеллектуальными активами организации с большим количеством примеров на все случаи жизни.
Авторы построили содержание руководства в соответствии со структурой процессов управления знаниями, отражающей два направления деятельности, существующих одновременно:

  1. Тактические процессы – повседневное использование знаний в ответ на требования или возможности, предоставляемые рынком.
  2. Стратегические процессы – формирование интеллектуального капитала, отвечающего стратегическим целям компании.

К первой группе процессов относятся поиск, использование, обучение, распространение. Ко второй – оценка, создание и поддержание, ликвидация активов. В каждой главе, посвященной одному из процессов, содержится Введение, Инструкции, Задачи и План действий. Также предлагается набор методик для диагностики процессов управления знаниями в Вашей организации.

Получение информации. Описана актуальная проблема современности: среди массивов несвязной информации трудно найти «зерна» данных, действительно нужных для дела. Увеличение объемов информации создает перегрузки. Новые технологии позволяют справиться с этой проблемой, обеспечивая баланс между методами поиска «выталкивания» (push) и «вытягивания» (pull). Также предлагается привлекать пользователей к разработке средств навигации, правильному составлению информационных запросов, созданию структур повторного использования знаний, привлечению менеджеров знаний и профессиональных сообществ для получения нужных сведений.

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

Обучение. Процессы «обучения» и «обмена знаниями» как средство формирования конкурентных преимуществ сравнительно новое явление в организациях. Задача организации – найти способы встроить обучение в рабочий процесс. Необходимо быстро переходить от одного процесса к другому. Создание «корпоративной памяти», хранящей опыт успехов и неудач может повысить эффективность будущих проектов.

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

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

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

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

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

Метки: , , ,