vit_r | Про целевую аудиторию

1. Мультивариативность имён решается различением IDs, labels, designations, names. Если же речь идёт не о множественности titles, а о разном понимании объектов, то каждый получает собственный набор всех имён-меток-обозначений плюс прописываются разные типы отношений с другими (и отдельная дискуссия о том, какие это отношения). Описки и грамматические ошибки и их исправление -- это типичный вопрос в data governance, так что тоже входит в scope.

Про коллективный труд, скорость и монстра есть прямо две противоречивых тенденции: повышение мощности головы по решению более сложных задач за более долгое время ("класс") и мануфактурная по разделению умственного труда на отдельные операции в разных головах -- но с пониманием того, как это всё будет потом склеиваться ("порядок"). В long term порядок бьёт класс (пример с вебмастером, который заменился дизайнером+верстальщиком+SEO+сисадмином+программистом движка+редактором+контент-менеджером -- это как раз из этой серии). Как всегда в случае двух разнонаправленных сил в каждом конкретном случае есть свой оптимум: некоторые проекты за заданное время нельзя сделать качественно числом человек меньше N ибо проблема скиснет, пока её будут решать, и нельзя сделать качественно числом человек больше M, ибо породят монстра из заплаток на заплатках к решениям друг друга.

4. Мэппинг невозможен в принципе между двумя базами данных, исходящими из разной картины мира. Для того, чтобы не делать ошибок мэппинга, его делают не просто баз друг ко другу, а баз к отдельной RDL. То есть для двух баз есть не один мэппинг, а два мэппинга (каждой из них к RDL). Так что это тоже ситуация предусмотренная постановкой задачи.

Насчёт же "фактов" и "истины", так меня учили, что есть только один вид объективности: это хорошо организованная субъективность. Вот мы такую и попытаемся сделать.

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

1. Мультивариативность имён решается различением IDs, labels, designations, names.

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

Привести этот бардак к единой структуре практически невозможно.

Есть способы и это моделировать. PossibleWorlds, мультивёрсы и т.д. David Lewis рулит.

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

Если не попробуешь, то ничего не получишь. Абстрактных ответов на абстрактные вопросы тут явно недостаточно.

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

Мы софтинку по мэппингу выпускаем на следующей неделе, и начинаем прикручивать к ней веб-интерфейс. Так что у нас вполне себе подход к "практическому решению" для хакатона, а не подход к рассуждениям о существовании способов. Способы команда в лице её разных людей многие знает уже прямо сейчас, всё таки речь идёт о технологическом bleeding edge. Нужно только сосредоточиться и сделать что-то. Ну, и перед тем как сделать (29 марта) подумать. Время ещё есть.

Софтинка, кстати, в предыдущей версии доступна тут: http://techinvestlab.ru/dot15926Editor (где-нибудь в понедельник-вторник мы надеемся, что там появится следующая версия с развитым мэппингом и верификациями). Так что всё стараемся держать не слишком абстрактным, а поближе к коду.

У меня задачи всё-таки не САПРовские, а ближе к естественным языкам.

Насколько я понимаю, для начала придётся писать парсеры к разным анимешным базам, переводить это в единый формат, потом решать задачи fuzzly loogic (с участием иероглифов), а уже после этого обрабатывать.

В принципе, я NLTK к нашей софтинке прикручивал и тексты обрабатывать пробовал: всё работало, ибо Питон. А ещё мы выполнили проект http://www.slideshare.net/vvagr/reference-dataextraction (там тоже была наша софтинка задействована). Так что с естественными языками у нас какой-то небольшой опыт есть.

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

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

Если задействовать fuzzy logic или чего-то подобное (hybrid reasoning: совместные статистический и логический вывод), то у нас в планах такого пока не было, но почему бы и нет (например, для попыток автомагического мэппинга, хотя это было бы чересчур круто на данной стадии этих технологий. Или для верификации).

На нормальную fuzzy logic у меня банально не было времени, потому что мне никто за эти игры не платит. Но, если экстраполировать то, что я делал, проверку надо проводить уже при извлечении данных из каждого нового источника. Причём, она должна быть как на внутреннюю логичность извлекаемых данных, так и на совместимость с уже имеющейся структурой. Всё это сопровождается полуавтоматической корректировкой, причём не в диалоговом, а в пакетном режиме.

В этом случае исправления наиболее дёшевы. Если конфликт попал в результирующую структуру, избавится от него на порядок сложнее.

Да, новые достижения Abbyy интересно было бы пощупать руками. Но задач под это у меня сейчас нет и не предвидится.

А если сдвинуться от манг к другим комиксам, то там можно найти и совсем другие датасеты -- http://www.infochimps.com/datasets/marvel-universe-social-graph

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

Да, это просто пример того, что какая-та работа с подобными данными ведётся, самая разная. Принципиальное решение тут -- что оставлять "в тексте, картинках, видео", а что вытаскивать на уровень явно прописанных отношений.

У меня предложение -- пока просто повторить структуры myanimelist и anidb плюс IMDB (в этих базах существенно разная информация про одно и то же). И даже википедия тут может быть -- но вот её нужно будет парсить, но зато там есть списки эпизодов с кратким содержанием много к чему. А остальное пока не трогать.

Далее дать интерфейс для работы тусовки BigData (то бишь позволить разным людям запускать свои алгоритмы по объединённому и почищенному датасету). И вот тут уже ловить неожиданные аллюзии, кластеризовать и категоризировать и развлекаться всякими иными образами.

Но это нереально всё за один день, нужно аккуратно отщипнуть от этой задачи маленький кусочек.

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

Я приводил много ссылок, и если пройтись по ним, то там я приводил и ссылки на API всех этих баз. Повторю из в http://dot15926.livejournal.com/47671.html

...идеи по тому, откуда и какие борать датасеты (ибо хакатон -- это некоторое развлечение, и вовсе необязательно брать для развлечения инженерные данные):
-- взять наборы данных, для которых заведомо нет ничего "семантиквебового" (например, http://anidb.net с API в http://wiki.anidb.net/w/API где много информации по аниме, но не так много людей и http://myanimelist.net с API в http://myanimelist.net/modules.php?go=api где мало информации по аниме, но много людей плюс есть информация по мангам).
-- онтологии появляются там и тогда, где и когда приходит понимание, что таких источников данных много (например, в wikipedia можно найти информацию по содержанию эпизодов, ещё есть IMDB с технической информацией по формату выпуска, игровые вебсайты с играми, tvtropes.org с использованными тропами и т.д. -- как связать информацию всех этих сайтов?). За основу можно принять какую-то модель предметной области: например, крутую BBC Programmes ontology -- http://www.bbc.co.uk/ontologies/programmes/2009-09-07.shtml (ну, их таких много).

Парсить википедию нужно, ибо я больше нигде не нашёл информацию по эпизодам. Хотя в некоторых базах есть аниматоры и продюсер для каждого эпизода (там удивительно они меняются: конвейер, я удивился насколько разные команды делают отдельные эпизоды даже в небольших сериалах). То есть можно будет потом находить через алгоритмы deep learning "амплуа" для отдельных аниматоров и продюсеров(если связывать эти имена с темами отдельных эпизодов) -- но это я так, шучу.

Я это читал, но API у MyAnimelist выглядит убого, а страница от AniDB просто не открывается. Опыт показывает, что гораздо продуктивнее работать с сырыми базами данных.

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

Я не понимаю, почему страницы от anidb не открываются. Там сразу на странице аниме в поле resources даются ссылки на разные другие базы (так, для Love Hina http://anidb.net/perl-bin/animedb.pl?show=anime&aid=35# это поле даёт Allcinema (http://www.allcinema.net/prog/show_c.php?num_c=159964), ANN (http://www.animenewsnetwork.com/encyclopedia/anime.php?id=168), ANN(2) (http://www.animenewsnetwork.com/encyclopedia/anime.php?id=5639), Official page (jp) (http://www.tv-tokyo.co.jp/lovehina/), Wiki (en) (http://en.wikipedia.org/wiki/Love_Hina), Wiki (jp) (http://ja.wikipedia.org/wiki/%E3%83%A9%E3%83%96%E3%81%B2%E3%81%AA), AnimeNfo (http://www.animenfo.com/animetitle,242,jqhwyg,a.html), Anison (http://anison.info/data/program/3814.html), MAL (http://myanimelist.net/anime/189), MAL(2) (http://myanimelist.net/anime/963), MAL(3) (http://myanimelist.net/anime/3247), VNDB (http://vndb.org/v1383), VNDB(2) (http://vndb.org/v696) -- и там уже и вики английская, и MAL в количестве, и вики японская, бери чего хочешь откуда хочешь. Конечно, и официальная японская страница "просто вебсайта" там тоже есть. Это всё из одного поля на странице, компактненько.

[Сорри, не знаю, как эти ссылки ЖЖ обработает, может чего-нибудь покоцать.]

Не открывается вики с описанием. Впрочем, там базу просто можно взять к себе на машину (http://nzedb.com/index.php?topic=869.0)

У меня не воспроизводится "не открывается вики" (у меня страницы anidb открываются и в FireFox, и в IE -- а других браузеров на машине нету). У меня этот сайт всегда стабильно открывается, я его привожу обычно в пример на лекциях, открываю прямо в онлайне. Там особо интересно по табам побродить: каждая вкладка внутри страницы открывает новый мир.

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

Про целевую аудиторию

Re: Оффтоп

Re: Оффтоп

Re: Оффтоп

Re: Оффтоп

Re: Оффтоп

Re: Оффтоп

Re: Оффтоп

Re: Оффтоп

Re: Оффтоп

Re: Оффтоп

Re: Оффтоп

Re: Оффтоп

Re: Оффтоп

Re: Оффтоп

Re: Оффтоп

Re: Оффтоп

Re: Оффтоп

Re: Оффтоп