Ну, это такой термин из среды разработчиков игрушек -- как правило, абсолютно коммерчески неуспешное изделие, которое, тем не менее, очень хочется сделать. Что-то типа вещи для себя и узкого круга понимающих.
У большинства более-менее старых программистов, я думаю, такая "game of dream" есть, но они её не делают потому, что понимают, что успех она будет иметь только у них лично (ну, может ещё у нескольких друзей).
Вот примерно так...

Можно в двух словах -- что за игра?

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

Не, для меня это вообще не игра -- я просто термин использовал.
Для меня это БД/каталогизатор для хранения персональной информации, на который я всё никак времени не выкрою...

Хм, да. Это было бы общественно-полезное занятие.

И в среде опенсорса можно было бы сразу отыскать поддержку.
Даже может быть что что-то подобное уже делается.
Например я встречал такую вот штуку
Greenstone is a suite of open-source software for building and distributing digital library collections.
www.greenstone.org/

Вообще. Интересно тогда, какие есть идеи по этому поводу? Потому как сам бывало о таком мыслил, но ничего нетривиального что-то не придумалось.

Greenstone я знаю давно, хорошая штука, идейный (и кодовый) наследник mg (Managing Gigabytes). Но здесь вопрос в сочетании свойств, которые есть у разных систем каталогизации по отдельности, но чтоб вместе -- я такого не встречал.

Интересно.
А можно более подробно об этих свойствах?
Других размышлениях по поводу?

ИМХО, такую штуку было бы логичнее сделать как он-лайн сервис.
Возможности расширения\улучшения в одном месте.
И самое главное -- польза от конвергенции информации от разных людей.

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

\\то всё напечатать и слегка отсортировать нужно.

Ок. будем ждать.

\\Ни в коем случае -- получается привязка к сети плюс возможность пропадания информации.

А чем плоха "привязка к сети"? и что значит "пропадание информации"?
Распределенные сервисы на основе профессиональных датацетров ИМХО гораздо надежнее чем любое пользовательское железо.

> А чем плоха "привязка к сети"?
Тем, что сеть есть далеко не везде.

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

\\Тем, что сеть есть далеко не везде.

Учитывая прогресс в этом направлении...
Тем более что никто не запрещает эту информацию кешировать локально.

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

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

> Но согласитесь, что подобные "утраты" в случае сетевой среды гораздо менее серьозны и сложны, чем случай например с застирванной флешкой на стороне одинокого пользователя. ;)

Здесь можно спорить. Но, в любом случае, концепция "The game of dream" подразумевает инструмент, удобный лично мне.
А начавшийся у нас диалог наглядно (хоть и в миниатюре) показывает, что происходит, когда "The game of dream" приносят к продуктоводу; в конечном итоге от концепта, как правило, остаются рожки да ножки, вполне вписывающиеся в термин "типовая штамповка". ;)
(Что интересно, каждый пункт такого диалога вполне верен и разумен, но в конечном итоге получается "слушацте свои "Валенки!"" :) )

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

Никуда от этого не дется.
Разве что начать придумывать свой язык программирования... или, еще дальше, свою архитектуру компьютера.

Так она, как правило именно "никуда не идёт" (а в тех редких случаях, когда идёт, обычно проваливается на рынке). Вопрос-то был, что бы я делал, если бы мне не нужно было зарабатывать на жизнь. :) (Что не отменяет того факта, что от этой "концепции" ИМХО можно вполне отломить востребованный кусок и сделать его нормальным продуктом.)

А ЯП свои я писал, работа такая ибо... :)

Примерный список того, что я хочу в этом инструменте:

Хранить данные разных типов; извлекать из них метаинформацию, если есть
Сквозная индексация текстов и возможность нечёткого поиска (а также поиска по регэкспрам)
Поддержка тагов, комментариев и виртуальных каталогов
Внесённые в БД документы должны копироваться в её внутреннее хранилище
Перекрёстные ссылки между документами а также между комментариями
Мультиплатформенность win/linux, желательно нативная, а не java
Работа с диска, и с readonly носителя (в гостевом режиме и с использованием дискового кеша)
Возможность слияния двух БД с (выборочным) объединением информации
Возможность записать выделенную коллекцию, как отдельную БД (с формированием замыкания по ссылкам или без)
Виртуальные страницы из имеющихся данных (типа view в SQL)
Возможность частичного или полного шифрования информации
Возможность оценки доверия в материалу (ручной и вычисленной)
Массовое редактирование тагов
Указание нескольких документов, как версий одного

Плюс нормальный пользовательский интерфейс...

:)

по некоторым пунктам уже реализации есть, тот же Гринстоун

некоторые же достаточно экзотичны
например

\\ Виртуальные страницы из имеющихся данных (типа view в SQL)

зачем это?
кроме случаев когда данные действительно табличные

\\ Хранить данные разных типов; извлекать из них метаинформацию, если есть

Что имеется здесь в виду под типом? Тип документа?

Других не держим! :)

> зачем это?
Затем же, зачем и view -- для динамической аггрегации.

> Что имеется здесь в виду под типом? Тип документа?
Да

П.С. 15. Изначальная приспособленность системы к ленивому разбору материала -- материал сначала добавляется, а потом уж сортируется/тагируется/комментируется мелкими порциями.

таким образом сортировка не будет делатся никогда :)
тогда уже лучше сразу включать в разработку ИИ-сортрировщика :))

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