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

Прежде, чем строить умные диаграммы и рисовать связи, я, обычно, собираю большую кучу "досье" на все переменные согласно Kimball «Data Warehouse Toolkit». (То есть, каждое поле во всех базах, источниках информации и интерфейсах анализируется и описывается.) Делаю это просто во FreeMind (0.9, так как новая версия мне не понравилась), а потом тасую и раскидываю по целевым схемам. После чего уже начинаю играться с красивыми тулами и говорить умные слова.

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

DWH Variable (в данном случае Anime Information Variable)

Abbrev
Как показала практика, короткие сокращения полезны. Особенно на картинках. Обычно можно взять имя или обозначение из исходной системы. Если они не очень уродские.
Description
Имя ни о чём не говорит, так что обязательно надо написать, что понял во время анализа.
Name
В отличие от сокращения имя может быть настолько длинным, насколько нужно. Чаще всего, нужно.
Semantics
Для DWH это "Table"
Fact
Для DWH дальше идёт описания числовых и нечисловых фактов. Для целей семантики тут, наверно, надо брать варианты Relation и Quantity. То есть, всякие служебные вещи, не интересные для семантики, но полезные для обработки исходных систем: прямые и текствовые ссылки, счётные вещи и внутренние идентификаторы.
pro
Тут идут замечания, почему это именно факт.
contra
И почему это может быть не так. (На начальном этапе перекидывать из категории в категорию приходится достаточно часто.)
(Дальше идут заморочки для DWH, которые тут не интересны)
type
В данном случае можно ограничиться просто text/number/link. Можно расширять и углублять. Главное, чтобы было обозримо и удобно.
Dimension
Принадлежность к Dimension Table для DWH. В данном случае просто поле в базе данных или элемент в записи, который несёт семантическое значение. На первом этапе пофиг, если набраны "Имя персонажа", "Имя главного героя", "Имя антогониста" и т.д. Главное - описать то, что можно найти в источнике. Всё структурирование, построение иерархий и отбраковка мусора начинаются на втором этапе.
pro
contra
Hierarchical
В принципе, это опять DWH, но может оказаться полезным.
no
yes
parent
child
changes
Этот блок сейчас не интересен.
Degenerate Dimension
Опять DWH. В задаче хакатона будет соответствовать всяким ID баз данных, адресам сайтов и т.п.
pro
contra
Documentation
UML модели, документы и пр. Этот пункт можно опустить. Всё равно у анимешных баз документация странная.
Source
Откуда и как вытаскиваем
system
by who
how
Тут всё возможное. От прикидок и теорий до regexp и SQL. Полезно оставлять все варианты, даже явно странные. Потом будет сделано что-то правильное. Тут же только предположеня о том, как вынуть значения.
Sample values
Разнообразные примеры. От простейших до явных ошибок, которых в реальных системах попадается дофига. Естественно, не "побольше - побольше", а чтобы можно было обсуждать, не влезая в дебри исходных систем.
Content
Source
Когда мы придём к власти, за незаполнение этого поля виновные будут получать канделябром. Иначе дофига времени убивается, если в анализе нужны уточнения, и не понятно, откуда взялись примеры и нет ли в них ошибок.
Comment
used in
Это про то, зачем и как переменную в исходной системе используют. В данном контексте тоже не интересно.
systems
interfaces
и так далее
В принципе, я сначала заполняю такие описания на каждую переменную, потом начинаю думать, а уже потом трясти пальму. (У учёных принято наоборот, так что не знаю, насколько такой метод подойдёт для хакатона.)