Открыты исходники проекта BeAware

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

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

Итак, прошу любить и жаловать: http://code.google.com/p/beaware/

Изменение структуры онтологии в BeAware

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

Список открытых вопросов по структуре онтологии:
1. Сейчас событие "музыкальный концерт" является наследником "развлекательного события". Однако, на мой взгляд, концерты классической музыки претендуют на звание культурного события. В рамках текущего подхода, когда корневыми событиями (корневыми в визуальном плане: все события являются наследниками базового класса Event) являются события, относящиеся к какой-либо сфере жизни, было бы логично выделить класс "концерт классической музыки" и сделать его подклассом "культурного события". Однако мне кажется, что такой подход будет путать пользователей (и концерты классической музыки будут по ошибке создаваться как экземпляры "музыкального концерта"), поэтому решение этой проблемы пока под вопросом.
2. У события "Театр" есть свойство "вид театрального искусства" (не придумал более лаконичного лейбла). Стоит ли оставить это так, или лучше выделить оперу, баллет и т. д. в подклассы класса "Театр"? С одной стороны, это загромоздит онтологию, с другой, - текущая реализация не позволит нам в будущем добавить дополнительные свойства, например, для балета (технически-то сможем, но юзабилити такого решения представляется мне сомнительным).
3. Есть ли какая-то стандартизированная классификация наук? Текущая иерархия для свойства "вид науки" взята из английской википедии, но, во-первых, она довольно куцая, а во-вторых, слабо коррелирует с классификацией, принятой на постсоветском пространстве.
4. Не приложу ума, куда разместить событие "выставка" (exhibition). Выставки бывают разные: картин, собак, IT (софт, железо, игры) и т. д.
5. У меня есть большой соблазн создать корневую категорию IT. Пока я с ним успешно борюсь... но встает более серьезный вопрос: по каким критериям выделять корневые события?

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

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

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

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


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

RDF vs. неRDF на примере геоданных в контексте BeAware

Одной из исходный целей создания BeAware было попробовать с пользой применить технологии из стека Semantic Web (на фоне разочарования от трехлетнего внедрения семантики туда, где она, по большому счету, не нужна). Предлагаю рассмотреть вопрос актуальности применения RDF-массивов Linked Data по сравнению с другими формами представления данных.

На текущий момент в формате Linked Data опубликовано огромное число массивов данных. Интересно, что для большинства из них исходной является реляционная форма представления, и два крупнейших массива геоданных: GeoNames и LinkedGeoData, не являются исключениями. Так, GeoNames ежедневно публикуется в виде CSV-дампов, которые отлично ложатся на реляционную модель, а LinkedGeoData является RDF-представлением данных OpenStreetMap, которые доступны в разных неRDF форматах. Встает вопрос: какую пользу мы можем извлечь за счет перевода данных в RDF? Я не буду останавливаться на теоретических аспектах этого вопроса (предполагается, что читатель с ними знаком), а опишу конкретные юзкейсы, которые стали/станут нам доступны за счет использования RDF.

Начнем с небольшого введения в то, как мы докатились до такой жизни пришли к идее совместного использования двух таких разных массивов геоданных в одном проекте: GeoNames для поиска городов (и вышележащих сущностей), а LinkedGeoData - для поиска объектов внутри города.

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

Итак, решение принято: используем GeoNames для первого "измерения" места проведения события - города. Однако вопрос, что использовать: реляционное или RDF представление, все еще был актуальным. В ходе одного из обсуждений в гуглгруппе GeoNames Prateek Jain дал мне ссылку на научную работу, соавтором которой он является. Эта статья открыла мне глаза на довольно очевидную вещь: как можно играюче обрабатывать транзитивные иерархии GeoNames-сущностей (например, город->район->область->страна) за счет движка логического вывода. Действительно, вряд ли какое-то средство справится с этим лучше, чем заточенный под подобного рода задачи движок логического вывода (бай-бай, рекурсивные SQL-запросы).

Еще одним аргументом за RDF-версию GeoNames была возможность интеграции с геополитической онтологией. На текущий момент, в GeoNames не представлены объединения стран вроде Евросоюза (хотя работа в этом направлении ведется), а мы планируем реализовать геофильтрацию по подобным сущностям. А в геополитической онтологии уже содержатся Country Groups - надо лишь реализовать маппинг к странам GeoNames.

Выбор между LinkedGeoData и "чистым" OpenStreetMap тоже был не из сложных.

Во-первых, ввиду того, что LinkedGeoData ориентирован не на показ карт, а на обработку запросов, LinkedGeoData поставляется не только в полной версии, но и в урезанной - LinkedGeoData Elements. Урезанная версия не содержит малоинтересные объекты (хайвеи, висячие элементы и др.) и содержит в 25 раз меньше триплетов. Для нашего скромного бюджета - то, что доктор прописал (хороший хостинг 3 миллиардов триплетов полной версии LinkedGeoData обошелся бы недешево). Этот пункт не имеет отношения ни к семантике, ни к RDF и, возможно, подобные урезанные массивы публикуются и для "чистого" OpenStreetMap (хотя мне не попадались). Но это лишь подчеркивает, что у массивов из Linked Data могут быть и чисто технические, выходящие за рамки семантики преимущества.

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

Мы рассмотрели преимущества использования RDF-массивов GeoNames и LinkedGeoData по отдельности. Однако название Linked Data как бы намекает на то, что дополнительные плюсы должны проявляться при интеграции массивов. К сожалению, на текущий момент маппинга между LinkedGeoData и GeoNames нет. Однако когда он все же будет разработан (такой пункт значится в todo-листе разработчиков LinkedGeoData), для нас откроется несколько полезных юзкейсов. Ниже приведу один пример.

Каждая сущность как в GeoNames, так и в LinkedGeoData снабжается координатами (широтой и долготой). Для городов (да и для других объектов с большой площадью) координаты, насколько я могу судить, не имеют какой-либо семантики (например, можно было бы предположить, что это координаты здания городской администрации): это просто координаты внутри города. Так вот в GeoNames и LinkedGeoData эти координаты частенько отличаются. Отличие в координатах, как правило, не очень большое, но достаточное для того, чтобы наступить на следующие грабли. В OpenStreetMap рядом с этими координатами прописывается название города. Когда в форме добавления нового места вы выбираете город, на карте устанавливается точка из GeoNames (ведь поиск городов осуществляется при помощи GeoNames), при этом название города на карте не видно (по крайней мере при используемом по умолчанию масштабе). Имея же маппинг GeoNames+LinkedGeoData, мы сможем подгружать для GeoNames-городов координаты из LinkedGeoData.

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

Текущее положение дел в проекте BeAware

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

Начнем с сердца проекта - онтологии.

На мой взгляд, онтология BeAware должна удовлетворять следующим критерям:
1. Быть дружелюбной к пользователю. Этот пункт не случайно на первом месте. Мы создаем не академическое приложение, а поэтому нельзя допустить, чтобы пользоваться сайтом могли лишь обладатели степени PHD Оксфордского Университета.
2. Одним из конкурентных преимуществ семантических технологий является возможность логического вывода, поэтому считаю, что онтология должна максимально эффективно (эффективно для пользователя, опять же) его использовать. Сейчас работа движка логического вывода проявляется, например, при поиске всех развлекательных событий (сколько бы нижележащих уровней иерархии ни было) или научных конференций по всем гуманитарным наукам. Лучше, чем ничего... но эта сторона онтологии еще явно требует доработки.
3. Онтология должна быть обобщением основных типов событий, происходящих в мире.

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

Список открытых вопросов по структуре онтологии:
1. Сейчас событие "музыкальный концерт" является наследником "развлекательного события". Однако, на мой взгляд, концерты классической музыки претендуют на звание культурного события. В рамках текущего подхода, когда корневыми событиями (корневыми в визуальном плане: все события являются наследниками базового класса Event) являются события, относящиеся к какой-либо сфере жизни, было бы логично выделить класс "концерт классической музыки" и сделать его подклассом "культурного события". Однако мне кажется, что такой подход будет путать пользователей (и концерты классической музыки будут по ошибке создаваться как экземпляры "музыкального концерта"), поэтому решение этой проблемы пока под вопросом.
2. У события "Театр" есть свойство "вид театрального искусства" (не придумал более лаконичного лейбла). Стоит ли оставить это так, или лучше выделить оперу, баллет и т. д. в подклассы класса "Театр"? С одной стороны, это загромоздит онтологию, с другой, - текущая реализация не позволит нам в будущем добавить дополнительные свойства, например, для балета (технически-то сможем, но юзабилити такого решения представляется мне сомнительным).
3. Есть ли какая-то стандартизированная классификация наук? Текущая иерархия для свойства "вид науки" взята из английской википедии, но, во-первых, она довольно куцая, а во-вторых, слабо коррелирует с классификацией, принятой на постсоветском пространстве.
4. Не приложу ума, куда разместить событие "выставка" (exhibition). Выставки бывают разные: картин, собак, IT (софт, железо, игры) и т. д.
5. У меня есть большой соблазн создать корневую категорию IT. Пока я с ним успешно борюсь... но встает более серьезный вопрос: по каким критериям выделять корневые события?

Перейдем ко второму пункту сегодняшнего поста - к обзору геоданных и их применения в BeAware.

Итак, каждое событие привязывается к определенному месту, где:
Место = Город (GeoNames) + [Объект (LinkedGeoData)], где объект - опциональный параметр.

Сначала предлагаю обсудить, как можно использовать привязку каждого события к GeoNames. Итак, имеем следующие исходные данные:
1. У каждого события есть URI из RDF-массива GeoNames
2. GeoNames построен на транзитивной иерархии (например, вот (http://ws.geonames.org/hierarchy?geonameId=1489425) иерархия для Томска: Томск->Томская область->Российская федерация->Европа->Земля). Причем количество и названия элементов иерархии меняются от страны к стране.
3. Движок логического вывода Virtuoso может играючи обрабатывать транзитивность, определяя принадлежность события, к тому или иному уровню иерархии.

Раз все так хорошо, почему у нас реализована лишь фильтрация по городам и странам? Дело в том, что мы пока не нашли красивого user-friendly решения. Я вижу два варианта реализации гибкой фильтрации (под гибкой я имею в виду фильтрацию, которая использует иерархию GeoNames в полной мере):
1. На базе существующего решения. Просто убираем ограничение поиска лишь по странам и городам - пользователь сможет найти и районы, и области, и республики и т. д. Но это будет полный бардак. Сейчас при поиске сущности вручную прописывается, является ли она городом или страной. Однако при гибком подходе мы можем прописать лишь GeoNames feature code (http://www.geonames.org/statistics/total.html), но это очень недружелюбно к пользователю.
2. Пользователь может вводить только города, но рядом с соответствующим фильтру городом отображается вышележащая иерархия (элементы которой можно выбрать наравне с городом). В этом случае засчет визуальности иерархии отчасти решается проблема первого подхода, но при этом рождается новая: пользователю нужно знать город в том регионе, который он хочет выбрать.

Ни один из вариантов мне не нравится но, вероятно, один из них придется реализовать. Что думаете на сей счет?

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

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

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

Довольно логичным решением было бы использовать интерфейс, базирующийся на поиске по имени/адресу объекта. Однако в этом случае пользователь может по ошибке выбрать объект, не находящийся в выбранном им городе. Кстати, этой проблемы не лишен и текущий интерфейс. Пользователь может выбрать город, затем увести карту куда угодно и выбрать объект в другой части света. Проверить принадлежность координат к городу довольно сложно, учитывая, что города постоянно растут. По крайней мере мне не известен ни один сервис, предоставляющий такую информацию. Может, у военных попросить... :) В качестве обходного пути я вижу следующее решение. Для каждого города у нас есть координаты его условного центра (просто некоторая точка внутри города). Также у нас есть некоторый объект (у которого тоже есть координаты). Мы можем рассчитать расстояние между этими точками и разделить его на население города (здесь предполагается, что размер города находится в прямой зависимости от его населения). Если это нормированное значение превышает некоторый порог, мы либо выдаем предупреждающее сообщение пользователю, либо отдаем событие на премодерацию. Что скажете?

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

Запущена альфа-версия проекта BeAware

Все началось несколько месяцев назад, когда в поисках информации о конференции я посетил не один каталог событий, однако ни один из них меня не порадовал: отсутствие удобного поиска (что при большом наполнениии превращает сайт в мусорку), недостаток интеграции с геоданными и другие огрехи подтолкнули меня к идеи реализации собственной площадки событий. При этом, пожалуй, самым серьезным мотиватором стал потенциал применения в этом проекте технологий из стека Semantic Web (а такой проект я подыскивал уже давно). Объединившись с Ефимовым Александром, мы приступили к работе над проектом BeAware.

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

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

После того, как выбран тип события, необходимо задать место его проведения. Можно либо выбрать уже ранее отмеченное место (здесь ничего интересного), либо добавить новое:
Место - это, прежде всего, город (используется GeoNames)। Однако, выбрав город, можно задать и конкретный объект в нем (используется массив LinkedGeoData, который, в свою очередь, базируется на OpenStreetMap). Между выбором города есть промежуточный этап выбора типа объекта, который помогает отфильтровать объекты (кстати, здесь ненавязчиво используется логический вывод, например, при выборе всех типов зданий).
После того как место выбрано, перед нам открываются остальные свойства события (их список варьируется в зависимости от типа события):
Заполняем их - и событие создано.

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

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

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

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

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

Во-вторых, будет улучшена геофильтрация. Это просто нелепо иметь в руках GeoNames+LinkedGeoData+Движок_логического_вывода и выжать из всего этого лишь фильтрацию по городам и странам. Постараемся существенно улучшить этот компонент.

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

В-четвертых, добавим RDFa-разметку.

В-пятых, интегрируем MusicBrainz для музыкальных концертов.

В-шестых, предлагайте свои идеи - мы не оставим их без внимания :)

До запуска беты наши основные приоритеты - функционал и юзабилити, после - популяризация.

P. S. Спасибо ребятам из компании "Соционика" за помощь с дизайном и версткой.
PP. S. Отдельное "спасибо" хабрачеловеку LeeMiller. Взявшись за разработку дизайна и верстки BeAware, он начал за здравие, но после получения предоплаты его как будто подменили. В течение полутора месяцев он кормил нас "завтрками" и враньем на любой вкус, а в результате сорвал нам все сроки (особенно если учесть, что его мы искали после того, как нас кинул предыдущий дизайнер: видимо, была черная полоса). Я, быть может, и забил бы на эту ситуацию, но LeeMiller проигнорировал мои сообщения о том, что было бы неплохо вернуть предоплату - а значит это уже не халатное отношение к работе, а мошенничество. Уважаемый LeeMiller, в ваших интересах прислушаться к моим сообщениям раньше, чем мы не доберемся с постами о BeAware на Хабр.

Semantic Web, Web of Data, Linked Data и агенты в двух абзацах

Оригинал:

According to (Berners-Lee, 2000, pp.191) "The first step is putting data on the Web in a form that machines can naturally understand, or converting it to that form. This creates what I call a Semantic Web - a web of data that can be processed directly or indirectly by machines". Therefore, while the Semantic Web, or Web of Data, is the goal or the end result of this process, Linked Data provides the means to reach that goal.

By publishing Linked Data, numerous individuals and groups have contributed to the building of a Web of Data, which can lower the barrier to reuse, integration and application of data from multiple, distributed and heterogeneous sources. Over time, with Linked Data as a foundation, some of the more sophisticated proposals associated with the Semantic Web vision, such as intelligent agents, may become a reality.

Вольный перевод:

Согласно (Бернерс-Ли, 2000, стр. 191), "Первый шаг - размещение в сети информации в форме, которую могли бы легко понимать компьютеры, или перевод существующей информации в такую форму." Поэтому, если Semantic Web, или Web of Data, - конечная цель, то Linked Data является средством достижения этой цели.

Размещая Linked Data, люди и сообщества делают вклад в создание Web of Data, который снизит сложность интеграции и использования данных из распределенных разнородных источников. Базируясь на Linked Data, со временем некоторые более сложные концепции Semantic Web (например, интеллектуальные агенты) могут стать реальностью.

Взято отсюда.

Обзор высокопроизводительных SAIL-решений

Около полугода назад, я уже сравнивал семантические фреймворки и ризонеры. Если на том этапе для меня важнее был выбор удобного фреймворка, нежели производительность, безопасность и т. д. (и выбор пал на OWLAPI+Pellet), то сейчас нашему проекту нужен высокопроизводительный ризонер с хранилищем в виде базы данных. Посему предлагаю рассмотреть и по возможности сравнить доступные на рынке SAIL-решения (Storage And Inference Layer).

Разделю хранилища на две группы: независимые (назовем их standalone) и являющиеся частью комплексных семантико-ориентированных enterprise-систем (для краткости дальше они будут именоваться PESSS-хранилища - Part of Enterprise Semantic System Store).

Сначала рассмотрим первую группу.

Standalone-хранилища

AllegroGraph

Официальный сайт: http://www.franz.com/agraph/allegrograph/
Цена: Бесплатно до 50 миллионов триплетов. При превышении лимита: Developer Edition: $4195 за процессор, Enterprise Edition: $34995 за процессор; академическая скидка - 50%. RacerPro продается отдельно; стоимость его лицензии можно узнать на официальном сайте (цены примерно того же порядка).
Поддерживаемые фреймворки: Jena, Sesame, Clojure
Архитектура:

Описание:
AllegroGraph разрабатывает фирма Franz Inc., которая широко известна благодаря таким продуктам, как TopBraid Composer (редактор онтологий), RacerPro (OWL DL ризонер) и др.

Поддерживает 2 основных типа вывода:
1. RDFS++
Уж как только не называют "RDFS плюс немного OWL"... На сей раз имеются в виду следующие предикаты: rdf:type, rdfs:subClassOf, rdfs:range, rdfs:domain, rdfs:subpropertyof, owl:sameAs, owl:inverseOf, owl:TransitiveProperty, owl:hasValue.
2. RacerPro
AllegroGraph интегрирован с еще одним ризонером Franz Inc. - RacerPro, который имеет выразительность OWL DL. Обсуждение OWL DL ризонеров в некоторой степени выходит за рамки сегодняшней статьи (ибо высокопроизводительными их пока назвать сложно), однако мы еще коснемся RacerPro при обсуждении PelletDb.

Итак, AllegroGraph является RDF-хранилищем с поддержкой двух ризонеров с полярными характеристиками. Впечатляет.

Franz Inc. также разрабатывает проект AGWebView, который, как несложно догадаться из названия, представляет собой Web-интерфейс для AllegroGraph.

BigOWLIM

Официальный сайт: http://www.ontotext.com/owlim/big/
Цена: 700 евро за каждое процессорное ядро
Поддерживаемые фреймворки: Sesame
Архитектура: Реализует SAIL для Sesame
Описание:
BigOWLIM имеет выразительность "RDFS with most of OWL Lite" (здесь подробнее), которая чуть шире выразительности ризонера RDFS++ AllegroGraph.

Разработчики OWLIM не скромничают и заявляют, что "BigOWLIM is the most scalable and efficient RDF Database!"

Интересно было бы сравнить производительность BigOWLIM с AllegroGraph RDFS++, но сделать это не так просто, ибо ризонеры базируются на разных принципах: static и dynamic materialization соответственно. Разобраться в различиях поможет описание RDFS++ dynamic materialzation (кстати, в видео идет сравнение с OWLIM). Итак, в теории AllegroGraph RDFS++ должен
1. быстрее загружать онтологии (ибо при этом ему не нужно делать вывод)
2. абсолютно безболезненно переживать модификацию онтологии
3. дольше выполнять запросы (ибо каждый запрос требует выполнения логического вывода).

От теории перейдем к практике и сравним результаты теста LUBM(8k) (информация взята отсюда и отсюда) при использовании сопоставимых конфигураций:

• BigOWLIM: Core i7 940 (2.93GHz, quad-core, HT), 12GB (DDR3), 3x320GB 7.2krpm, RAID 0


• AllegroGraph: Quad 1.8GHz AMD64 Opteron 884, with 16Gb of memory running Fedora 8

Все с ног на голову.

AllegroGraph показал в два раза худшее время загрузки (и это при том, что BigOWLIM во время загрузки еще и вывод делает). Так как у тестовой конфигурации AllegroGraph отсутствовала информация о дисковой подсистеме, пришлось восполнить этот пробел при помощи службы поддержки. Оказалось, использовались 2 обычных Sata диска, не объединенных в RAID (что равносильно одному диску). Если учесть преимущество на этапе загрузки в скорости тройного RAID 0 (используемого для тестирования BigOWLIM) против обычного диска, все встает на свои места.

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

Подведем итоги локального сравнения.

В теории все звучит предельно ясно: чем более динамично меняется онтология, тем лучше себя показывает dynamic materialization; и наоборот. На практике же не все так однозначно: многое решают нюансы реализации.

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

PelletDb

Официальный сайт: http://clarkparsia.com/pelletdb
Цена: EULA-лицензия на PelletDb - 2495$ + лицензия на Pellet (если ваш проект распространяется по GPL, Pellet бесплатен) EULA 4995$ за сервер + лицензия Oracle Enterprise.
Поддерживаемые фреймворки: Jena
Архитектура: Взаимодействует с Oracle Enterpise при помощи Jena Oracle Adaptor
Описание:
Сомневался, в какую категорию поместить PelletDb. С одной стороны, что может быть "более enterprise", чем Oracle, с другой, - категория PESSS подразумевает семантико-ориентированность enterprise-системы. А в Oracle реализовано лишь хранилище с ризонером да SPARQL-endpoint. Я посчитал, что этого недостаточно для попадания в категорию PESSS. Кроме того, при таком раскладе в обоих категориях по три продукта :) В любом случае, это не принципиально.

Совсем "свеженький" продукт (релиз состоялся 1 декабря текущего года), реализующий для Oralce Enterprise логический вывод с выразительностью OWL DL.

Работает PelletDb следующим образом:
1. При помощи Jena Oracle Adaptor загружает из Oralce триплеты
2. Делает полный вывод
3. Загружает выведенные триплеты обратно в Oracle

Вырисовываются два существенных минуса такого подхода:
1. Для вывода вся модель должна быть в памяти. Это существенно снижает целесообразность использования PelletDb в enterpise-проектах (а жесткая привязка к Oracle Enterprise диктует использование PelletDb именно в этом секторе). Конечно же, разработчики учли этот "нюанс", поэтому PelletDb поддерживает (подробности в pelletdb whitepaper) режим вывода только схемы (=TBox). При этом в результате мы получим ABox, выведенный ризонером Oracle, и TBox, выведенный PelletDb.
2. Если "классический" Pellet делает вывод динамически, то PelletDb, очевидно, делает его статически. Полный OWL DL вывод - это очень медленно. Здесь бы пригодился динамический вывод... но используемая архитектура его не предполагает. В этом отношении интереснее смотрится связка RacerPro (OWL DL ризонер, который мы упоминали выше) и AllegroGraph. Ведь это продукты одной фирмы, а значит у них больше гибкости в вопросе интеграции.

<Лирическое отсупление на тему RacerPro>

В RacerPro можно выделить два режима работы.

В первом режиме происходит inmemory-вывод, который влечет за собой ограничение на размер ABox (аналогичен первому режиму PelletDb). В качестве решения можно отказаться от вывода ABox при помощи RacerPro, положившись на RDFS++ ризонер AllegroGraph (аналогично второму режиму PelletDb). Есть еще альтернативное решение, которое предполагает разбиение ABox на независимые части, которые выводились бы отдельно друг от друга. Пока это можно сделать только вручную, но уже в будущей версии для этого будет специальный API, а в более далекой перспективе обещают реализовать автоматический алгоритм разбиения ABox.

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

</Лирическое отступление на тему RacerPro>

В целом PelletDb выглядит слишком узконаправленным: он заточен не только под Oracle Enterprise, но еще, по сути, под вывод лишь TBox. А ведь стоит недешево. Хотя, с другой стороны, "Everything is better with Bluetooth Oracle" :)

PESSS-хранилища

Virtuoso

Официальный сайт: virtuoso.openlinksw.com
Цена: Virtuoso Open Source Edition бесплатна. На нее распространяется ограничение соединения с внешними базами данных, отсутствие поддержки репликации и Virtual Database. Цену на подходящую вам конфигурацию коммерческой версии можно узнать на официальном сайте, выбрав Virtuoso Universal Server.

Поддерживаемые фреймворки: Jena, Sesame, Redland, Linq2Rdf, dotnetRDF
Архитектура:

Описание:
Virtuoso - очень мощный Enterprise-продукт фирмы OpenLink, которая специализируется на разработке RDBMS Middleware.

В состав Virtuoso входит одно из самых производительных и масштабируемых (например, сейчас в этом LOD-хранилище числится более 9 гигаквад) RDF-хранилищ, снабженных изощренной SPARQL-endpoint с поддержкой RDF Views. RDF Views - это реализация RDBMS2RDF, позволяющая динамически работать с реляционными данными через SPARQL (незаменимая возможность для проектов, ориентированных на интеграцию данных).

Выразительность встроенного ризонера довольно скромная: поддерживаются rdfs:subClassOf, rdfs:subPropertyOf, owl:equivalentClass, owl:equivalentProperty и owl:sameAs.

Отдельного упоминания стоит обилие качественной документации по Virtuoso.

OpenAnzo

Официальный сайт: http://www.openanzo.org/
Цена: Бесплатно (Eclipse Public License -v 1.0)
Описание:
OpenAnzo представляет собой RDF-хранилище с широким спектром семантического middleware, которое включает поддержку распределенных сервисов, работу в оффлайн, версионирование, ограничение доступа и т. д.

Одна из концепций данного проекта - ориентация на сервисы. Так, например, упомянутое выше RDF-хранилище, именуемое Anzo Store, не является хранилищем в привычном понимании этого слова. Anzo Store - это data-source-сервис, реализующий хранение триплетов в реляционных СУБД. Другой пример использования сервисов - синхронизация информации, реализованная при помощи сервисов репликации и уведомлений.

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

Предоставляется клиентский API для Java, .NET и JavaScript.

В целом, очень интересный Open Source проект с широким enterprise-функционалом.

Semantics.Server

Официальный сайт: http://www.intellidimension.com/products/semantics-server/
Цена: В зависимости от версии: например, Standard Edition License - 10000$, Enterprise Edition License - 15000$ + лицензия Microsoft SQL Server.
Описание:
Одна из немногих семантических разработок на .NET. Причем не просто на .NET, а в тесном сотрудничестве с Microsoft.

Semantics.Server представляет собой целый ряд средств, включая свой фреймворк, OWL Full ризонер и хранилище на базе SQL Server. Особенно хотелось бы отметить следующие возможности:
1. Объединение реляционных и семантических данных при помощи T-SQL (в отличие от Virtuoso RDF Views, другие СУБД не поддерживаются)
2. Распределение одного RDF-графа на множество серверов.

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

Также серьезным недостатком Semantics.Server является ограниченная поддержка других (помимо SQL Server) СУБД. Хотя работа в этом направлении ведется:

"Yes, it only works with SQL Server at the moment using out of the box components (you could write a custom datasource component to connect to any external source of data). We do expect to support access to additional relational stores using our SQL Datasource, but have no timeline for that right now."

Заключение

Пожалуй откажусь от идеи делать выводы уровня must live/must die касательно вышеописанных продуктов: уж слишком они все разные.

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

Перевод книги "Semantic Web Programming"

Около полугода назад я пытался добиться перевода книги "SEMANTIC WEB for the WORKING ONTOLOGIST" (об этом я писал здесь и здесь). Насколько мне известно, процесс заглох на этапе переговоров между издательствами.

На этот раз сложилась обратная ситуация: к семантическому сообществу с инициативой публикации перевода одной из книг по тематике Semantic Web обратился Виктор Штонда, генеральный директор издательства "Диалектика". В блоге Виктора Вы можете найти пост с обсуждением данного вопроса. Так что если Вас интересует перевод, - не стесняйтесь, присоединяйтесь к обсуждению :)

P. S. Название поста обусловлено тем, что на данный момент наиболее вероятен перевод именно книги "Semantic Web Programming" (о которой я, кстати, недавно писал).

Обзор книги "Semantic Web Programming"

Некоторое время назад в моих руках оказалась книга Semantic Web Programming (за что большое спасибо моему научному руководителю). На днях я ее дочитал - спешу поделиться впечатлением.

"Semantic Web Programming" - первая на моей памяти книга, которая, во-первых, рассматривает так много языков, средств и технологий Semantic Web, а во-вторых, целиком ориентирована на практическое их применение. На мой взгляд, это делает данную книгу незаменимым чтивом (в первую очередь, для новичков Semantic Web): такая подборка материалов дорогого стоит.

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

Содержание книги условно разбито на четыре части.

Первая (главы 1-2) "Introducing Semantic Web Programming" и вторая (главы 3-7) "Foundations of Semantic Web Programming" части носят теоретический характер (хотя и здесь авторы стараются приводить примеры, не давая читателю забыть о практической направленности книги). Первая часть предлагает читателю вводный обзор Semantic Web, а вторая рассматривает основные языки и технологии (RDF, OWL, SPARQL, SWRL). Опытные деятели Semantic Web могут смело пропустить эти две части, сделав исключение лишь для 5-й главы (в которой рассматриваются семантические фреймворки, их компоненты, а также примеры реализаций).

Третья часть "Building Semantic Web Applications" (главы 8-11) рассматривает подходы к использованию Semantic Web в реальных приложениях. Глава 8 представляет собой обзор семантического фреймворка Jena (в книге основной акцент сделан именно на этот фреймворк). Последующие 3 главы (9, 10 и 11) описывают три очень важные проблемы (и способы их решения): combining information (рассматривается доступ к разнородным источникам данных, преобразование XML в RDF, доступ к реляционным СУБД при помощи SPARQL), aligning information (описывается объединение онтологий при помощи OWL, SWRL, XSLT, RDFS и кода) и sharing information (разговор идет о микроформатах, eRDF и RDFa, который в виду последних событий стал особенно актуален).

Четвертая часть "Expanding Semantic Web Programming" (главы 12-15) раскрывает некоторые тонкие моменты (глава 12 - использование семантических сервисов; глава 13 - хранение в онтологиях пространственных и временных значений), подводит итоги (глава 14 - patterns and best practices) и описывает ближайшие перспективы (глава 15 - moving forward).

В целом, на мой взгляд, книга "Semantic Web Programming" просто обязана стать бестселлером (в круге интересующихся Semantic Web, естественно), и ее можно смело ставить в один ряд с "SEMANTIC WEB for the WORKING ONTOLOGIST". Очень радует появление в последнее время достойных книг по тематике Semantic Web. Такие книги снижают входной барьер и расширяют круг интересующихся данной тематикой, что в конечном счете способствует дальнейшему развитию Semantic Web.

Сравнительный анализ фреймворков для работы с онтологиями под .NET и Java

Ни для кого не секрет, что львиная доля проектов, связанных с Semantic Web, разрабатывается на Java. Фреймворки для работы с семантическими онтологиями не являются исключением: все основные проекты (Jena, OWL API, Sesame и т. д.) написаны именно на Java. Единственным серьезным представителем, использующим .NET, является фирма Intellidimension с продуктами RDF Gateway и Semantics.SDK.

В этой статье опишу свой опыт работы с вышеуказанными фреймворками и поделюсь результатами тестирования.

Вступление

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

Перед погружением в технические детали скажу пару слов о фреймворке от Intellidimension (как наименее известном продукте для Java-ориентированного сообщества). В отличие от остальных рассматриваемых в этой статье фреймворков, которые являются OpenSource-проектами, RDF Gateway и Semantics.SDK распространяются с закрытыми исходными кодами и стоят достаточно приличных денег. Так, один лишь RDF Gateway 3.0 Enterprise стоит 10000$ (хотя версия 2.0 стоила «всего» 2000$). К слову, использованные при тестировании ризонеры - Pellet и Owlim - тоже не бесплатны: Pellet распространяется по dual license, а Owlim предлагает бесплатно лишь версию, работающую в памяти; версия, работающая с хранилищем, стоит 700 евро за каждое используемое процессорное ядро.

Тестирование

Передо мной стояла задача подобрать фреймворк для реализации проекта под .NET, поэтому Java-проекты в чистом виде меня не интересовали (изначально я даже не планировал их тестирование). Необходимо было выбрать средство interop’а между Java и .NET. Мой выбор пал на ikvm.net, который позволяет конвертировать jar’ы в .NET dll. Получив .NET-версию Jena, OWL API и Sesame, я принялся за их тестирование. Однако тестирование было бы неполным, если бы не содержало результатов тестирования Java-фреймворков в их родной среде. Таким образом, в тестировании участвуют: Intellidimension Semantics.SDK 1.0, OWL API 2.2.0+Pellet 2.0rc5 (как под Java, так и под .NET), Jena 2.5.7+Pellet2.0rc5 (как под Java, так и под .NET) и отчасти Sesame 2.24+SwiftOwlim 3.0b9.

Из первоначального тестирования пришлось исключить Sesame ввиду отличающейся от Semantic SDK и Pellet политики логического вывода в Owlim (Owlim - основной ризонер, используемый в связке с Sesame). Так, Pellet и Semantic SDK нацелены на вывод во время запроса (query-time reasoning), хотя и включают средства заблаговременного вывода; Owlim же нацелен на полный логический вывод (full materialization). Об этом мы еще поговорим в разделе «Общая информация о ризонерах».

В качестве тестовой была выбрана онтология Thesaurus 09.02d института NCI. Правда, в чистом виде она содержит ряд противоречивостей (inconsistency). После общения со службой поддержки противоречивости были выявлены. Я использовал модифицированную версию 09.02d (которую Вы можете скачать с моего dropbox’а), хотя сейчас уже доступна версия 09.04d, в которой данных противоречивостей нет.

Для тестирования была смоделирована следующая ситуация:
1. Сначала онтология из файла загружалась в модель;
2. Затем к этой модели последовательно выполнялось 3 SparQL-запроса (тексты запросов можно скачать здесь).

Сначала рассмотрим результаты тестирования первого этапа:
Несмотря на то, что .NET/ikvm-фреймворки медленнее своих Java-собратьев в 2-3 раза, они оказались быстрее Intellidimension.

В плане работы с памятью .NET оставил более приятное впечатление. Сборщик мусора в Java требует указания максимального объема оперативной памяти, который может быть выделен под кучу (параметр Xmx); .NET же использует более логичную, на мой взгляд, политику: он потребляет столько памяти, сколько ему нужно (если только не задано ограничение). Ограничение через Xmx - очень старый "баг", который, к сожалению, до сих пор не пофикшен. В качестве решения предлагается просто задавать Xmx с запасом (если, конечно, объем оперативной памяти позволяет), однако в этом случае (тестирование велось с Xmx:12g) сборщик мусора особенно себя не утруждает (что мы и видим по результатам тестирования). Можно пойти другим путем - подбирать минимальное значение Xmx для конкретных входных данных (правда, рискуя напороться на OutOfMemoryException). Таким образом можно приблизить объем потребляемой JVM памяти к аналогичным показателям CLR (пусть и с некоторыми дополнительными потерями производительности на более частые сборки мусора).

Касательно ограничения на максимальный объем используемой памяти произошел довольно курьезный случай. После успешной загрузки онтологии Thesaurus при помощи конвертированного в .NET OWL API, я решил открыть эту онтологию в Protége (который базируется на той же версии OWL API) для ознакомления с ее структурой. Однако вместо дерева концептов и экземпляров я получил OutOfMemoryException (при том, что свободной памяти было предостаточно). И хотя увеличение значения атрибута Xmx разрешило проблему, такая несамостоятельность сборщика мусора в Java не радует. Курьезность ситуации заключается в том, что несмотря на то, что Java-приложение не запускается в родной среде (без танцев с JVM), после конвертации в .NET при помощи ikvm оно работает.

Теперь перейдем ко второму пункту тестирования - выполнению SPARQL-запросов. К сожалению, на этом этапе придется оставить за бортом лидера первого теста - OWL API. Дело в том, что интерфейс OWL API, который реализуют ризонеры, не содержит методов для выполнения SPARQL-запросов. Связано это с тем, что SPARQL создавался как язык запросов к RDF-графам (и с OWL он не очень дружит), а OWL API, как нетрудно догадаться по названию, ориентирован именно на OWL. Сейчас идет работа над стандартом SPARQL-DL и, возможно, его поддержка будет реализована в одной из следующих версий OWL API. На данный момент остается лишь использовать class expressions, которые позволяют писать запросы с использованием манчестерского синтаксиса. Class expressions - это, конечно, не SPARQL… но для большинства задач их достаточно.

Итак, результаты тестирования:
Сначала прокомментирую прочерки в графе Intellidimension. С момента запуска тестового приложения прошло 6 часов, процесс весил порядка 6Гб, а результата все не было. Ждать дольше у меня не хватило терпения. Вынужден засчитать Semantics.SDK техническое поражение. Справедливости ради стоит отметить, что с более мелкими онтологиями Semantics.SDK справляется: и вывод делает, и запросы обрабатывает… правда, сравнивая результаты с Jena+Pellet, могу с уверенностью заявить, что Semantics.SDK не всегда выдает полный результат.

Pellet же справился с выводом за вполне разумное время (запросы были не из легких) и, как и на первом этапе тестирования, .NET/ikvm-фреймворк выглядит предпочтительнее Intellidimension.

На этом этап тестирования закончен. Подводя итоги, можно сказать, что победителем стала система Jena+Pellet, а приз авторских симпатий достается OWL API+Pellet.

Общая информация о ризонерах

В целом, существует два подхода к реализации логического вывода: на базе правил (с использованием алгоритмов forward-chaining и/или backward-chaining) и на базе семантического табло (semantic tableau). На базе правил реализованы Semantics.SDK и Owlim, а на базе семантического табло - Pellet.

Насколько я могу судить, rule-based ризонеры выгодно использовать для языков с низкой выразительностью, а ризонеры на базе семантического табло - для языков с высокой выразительностью. Если Pellet (OWL-DL) и Owlim (OWL-Tiny) подтверждают это наблюдение (находясь по разные стороны баррикады), то Semantics.SDK (OWL-FULL) является исключением (и судя по тестам производительности, ничего хорошего в этом исключении нет).

Рассмотрим диаграмму c официального сайта Owlim:
Как видим, Owlim поддерживает лишь OWL Tiny. Именно эта особенность позволяет ему добиться очень высокой производительности.

Owlim - единственный (из рассмотренных) ризонер, который поддерживает многопоточный вывод. Тем самым Owlim реализует преимущество rule-based систем перед семантическим табло - возможность распараллеливания (алгоритмов распараллеливания процесса построения семантического табло пока нет). Разработчики Semantics.SDK утверждают, что их вывод тоже распараллеливается… но в trial-версии это не реализовано (на мой взгляд, не самое удачное ограничение для trial-версии). Просьба выделить мне краткосрочную лицензию для тестирования осталась без ответа, поэтому приходится верить разработчикам на слово.

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

Заключение

В этой статье акцент сделан на производительности, однако при выборе семантического фреймворка для того или иного проекта акцент нужно, в первую очередь, делать на функционале (поддержка (нереляционного) хранилища, поддержка OWL2 и т. д.). Обсуждение этих вопросов выходит за рамки данной статьи (да и не настолько хорошо я знаком с каждым из фреймворков, чтобы делать такой анализ). В отношении функциональности я хотел было похвалить продукты от Intellidimension: связка RDFGateway и Semantics.SDK представляет собой очень мощный фреймворк, аналогов которому в мире Java нет… но выкрутасы их ризонера охладили мои чувства к этому фреймворку.

P. S. Огромное спасибо за ликбез, оказанный в ходе написания статьи, Клинову Павлу.
PP. S. Статья также опубликована на shcherbak.net и на Хабре. Контент там тот же, а комменты (равно как и сообщество) совершенно разные - советую пролистать.

SEMANTIC WEB for the WORKING ONTOLOGIST. Часть 2

Сегодня мы опять поговорим о замечательной книге "Semantic Web for the Working Ontologist", и о ее нелегкой судьбе на земле русской.
Как же развивались события с момента публикации предыдущего поста?

В комментариях к кросспосту на Хабре Дмитрий Уланов пригласил меня в группу webofdata. В дальнейшем основное общение проходило в этой ветке.
Примерно через неделю, списавшись с Дином Алемангом, я узнал, что запросов на перевод пришло очень мало. Совместно с подписчиками webofdata решили, что ждать милости от Morgan-Kaufmann не стоит - нужно самим связываться с российскими издательствами. После уведомления избранных издательств о существовании такой замечательной книги, оставалось только ждать...
Пока ждали, рассматривали альтернативные варианты: создание закрытого перевода на translated.by, публикация обзоров глав книги на Хабре и т. д. Однако 1-го марта я с удивлением обнаружил на мыле очень радостную весеннюю новость: Дин Алеманг писал о том, что издательство Morgan-Kaufmann начало переговоры с российским издательством. Цитирую Дина:

I have received a number of emails showing interest in a Russian
edition of Working Ontologist. Thanks to everyone who has sent me
letters of support - Morgan-Kaufmann is exploring possibilities with a
Russian publisher to produce a translation. We'll keep our fingers
crossed! Of course, anyone who knows the publishing industry knows
that such a project typically takes a year to a year and a half before
the book is actually available. So do keep your fingers crossed, but
don't hold your breath!

Это было очень неожиданно. Время шло, новостей не было... и я уже почти перестал надеяться. К слову, удивлен был не только я :)

В письме Дин предложил выступить в качестве моего протеже при выборе переводчика. Связано это было с тем, что в одном из первых писем, я писал Дину о том, что участвую в любительском переводе его книги для внутренних целей одной организации. Меня смутило это предложение (ведь я программист, а не переводчик)... и в итоге я отказался от этого предложения (с подробностями можно ознакомиться на webofdata). К счастью, Полина Медведкова, одна из подписчиц webofdata, изъявила желание заняться переводом. Это просто замечательно: ведь для перевода столь узкоспециализированной книги недостаточно хорошего знания английского, нужно разбираться в технологиях Semantic Web. Поэтому я с удовольствием порекомендовал Дину Алемангу Полину в качестве переводчика.

Будем надеяться, что издательства таки договорятся, а переводчиком выберут Полину. Удачи тебе, Полина! :)

Во второй части поста я хотел бы поговорить о будущем книги.
Читая отзывы о книге на Amazon, увидел лишь один относительно негативный комментарий:

There is a great need for a book like this, and the authors are well-credentialed, but unfortunately, this book is more like an introduction than a craftsman's resource. It reads like a first draft with typos, belabored repetitive text, and some odd examples. There is almost no discussion of internationalization, security, performance, or tricky basic types such as dates, times, or currency. More discussion of SPARQL would have been useful, as well as discussion of what should go in the model vs. what should be queried out. The chapter "Good and Bad Modeling Practices" was a particular let-down. A sharp, thoughtful, deeper book on this topic would really help the field.

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

A second edition (with new material) is a lot of work both for us and the publisher.
Our current plan is to write some new chapters an pre-publish them on the web, for eventual inclusion in a second edition. I am working on the SPARQL chapter now. I am not yet convinced of the industrial relevance of RuleML or even OWL 2.0, but we will treat those in the same manner.
Of course, if I find the time to do all this . . . .

Но что-то мне подсказывает, что второму изданию быть ;)

SEMANTIC WEB for the WORKING ONTOLOGIST

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

Сегодня я хотел бы поговорить о литературе по Web 3.0, точнее об одном из лучших ее представителей - книге "SEMANTIC WEB for the WORKING ONTOLOGIST".
Начну издалека. Я по совместительству работаю в лаборатории семантических знаний Томского Политехнического Университета. Не так давно научный руководитель порекомендовал нам эту книгу, дав ей очень лестную оценку.
Чем больше я читал эту книгу, тем сильнее она мне нравилась (особенно на фоне многих других материалов по этой тематике). Мне стало интересно, не готовится ли перевод этой книги на русский язык. Меня вполне устраивает английская версия (я по ряду причин окончательно и бесповоротно перешел на чтение технической литературы исключительно на английском), но, думаю, российскому сообществу такая книга бы не помешала: ведь если уж на английском по Semantic Web мало толковой литературы, то на русском ее еще меньше.
Списавшись с Dean Allemang, одним из авторов книги, выяснил, что русского перевода пока не планируются, однако уже есть корейский. К слову, знатоки корейского языка могут приобрести переведенное издание вот здесь :) Однако Dean подчеркнул, что он был бы рад, если бы удалось организовать перевод книги и на русский язык. Он поделился информацией о том, что подтолкнуло издательство сотрудничать с корейской стороной. Цитата из переписки:

Here’s how we can start. If you can collect some statements from people in Russia (e.g., University Professors, industry leaders, influential leaders of thought) that argue why there is a market for a Russian translation, I can send these to my publisher. If that argument is convincing, then they might take on the project.

В результате переписки в Daen'ом, было принято решение попробовать организовать сбор запросов на русский перевод. Еще одна цитата:

The letters should identify the sender – preferably someone of standing in a Russian University, Industry or Government.

A statement about why he or she thinks that a Russian translation will have a large market. Some example reasons: A professor intends to use it in a university course, or perhaps a large government project will be using (or even just investigating) Semantic Web as a fundamental technology. In industry, a statement about the importance of Semantic Web technology in Russian industry, and the need for consistent education on the subject.

In short, any statement that will convince the publisher that there is a good chance that the book will sell well in Russian.

Вкратце, нужно отправить на e-mail dallemang@topquadrant.com письмо на английском языке, содержащее запрос на русский перевод. Особенно приветствуются письма от профессоров и лидеров индустрии.

Скептикам подобный подход может показаться бредовым. Полностью поддерживаю эту точку зрения :)
На мой взгляд, такие сложности связаны с издательством (у гигантов, вроде Appress, Manning, Microsoft Press и т. д. процесс перевода налажен куда лучше). Скажите, слышали ли вы о переведенных книгах издательства "Morgan Kaufmann"? Лично мне не попадались. Хотя по главной странице издательства такого не скажешь: у них есть представительства по всему свету. Странно...
Может, дело в том, что издательство не видит в этой книге бестселлер. Конечно, книга достаточно узкоспециализированная, но отзывы о ней исключительно положительные. Приведу пару отзывов:

"The Missing Link: Hendler and Allemang's new book is exactly what our industry is looking for. We have many introductory books, and some compilations of papers but very little to help a practitioner move up their experience curve from novice to journeyman ontologist. The book is very readable; the examples are plentiful and easily understandable. I've already been recommending students and clients pre-order this book" - David McComb, President, Semantic Arts, Inc. www.semanticarts.com

"This is by far the best introduction to the semantic web currently available, from a practitioner's point of view. There are meaty examples that move beyond the theory and hype. You will get a clear understanding of what RDF, RDF Schema and OWL are all about - both in terms of what they are and how to use them. You will learn a variety of hard-nosed and hard-won practical guidelines gained from years of experience building and deploying ontologies "in the trenches"? Semantic Web for the Working Ontologist fills a much needed gap in the literature. It represents an impressive collection and synthesis of a wide variety of sources that have hitherto been scattered among academic books and papers, W3C working group notes, talks, blogs and email discussion groups. I expect to refer to this book often." - Dr. Michael Uschold, Internationally recognized expert in ontologies and semantic web technologies both in academia and industry.

Неплохо, не правда ли?
Если мне удалось Вас убедить, пожалуйста, отправьте письмо Dean'у. Глядишь, что-нибудь из этого и выйдет...
P. S. На официальном сайте книги для российского перевода создан специальный раздел, в котором планируется общее обсуждение (но постить там запросы на перевод не стоит).
PP. S. Кросспост этой статьи с целью привлечения большей аудитории размещен на Хабре.