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