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