Воистину пятничный баг

Я сейчас занимаюсь разработкой модуля видеонаблюдения за спящими пациентами (ибо в сфере медицины сна) под .NET при помощи libvlc (ядра небезызвестного плеера VLC). И все бы ничего, но иногда VLC конфликтовал с Windows, в результате чего возникал BSOD (Blue Screen Of Death). В скором времени я набрел на топик на форуме VLC с описанием этой проблемы. Если отбросить технические детали (по ссылке их предоставлено сполна), то проблема решалась установкой для заданного ключа реестра значения IMMLoad из 1 в 0. Сказано-сделано: установление ключа интегрированого в инсталлятор - бага пофикшена.

Однако некоторое время спустя тестеры очень расстроили меня сообщением о том, что они снова воспроизвели BSOD (тестеры у нас классные, меня сам факт расстроил). Трудно описать мое удивление, когда в реестре я обнаружил значение LoadIMM (похож на IMMLoad, правда?), выставленное в 1. Меняем на 0 - и все опять хорошо. Я очень люблю симметрию, но такой подставы не оценил :)

Оказывается, на разных версиях Windows используется либо IMMLoad, либо LoadIMM (с очень высокой вероятностью, делают они одно и то же). Мы с коллегами немного по-пятничному пофантазировали на тему того, что значений может оказаться больше (хотя я очень надеюсь, что это не так):



Приятных вам выходных!

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

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

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

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

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

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

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

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

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

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

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


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