Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>а) кому это надо?
Продвинутым пользователям и небольшим организациям ЗХ>б) есть ли что-то похожее, с чем было бы правда УДОБНО работать?
Около года назад пытался найти. Была только одна программа с более-менее качественным интерфейсом и относительно приемлемой функциональностью (как называется, хоть убей, не помню...). При более близком рассмотрении оказалась полным фуфлом.
В свое время набросал небольшой док, по которому собирался написать прогу (для использования внутри конторы, в которой тогда работал). Написано достаточно дурацким языком, но возможно некоторые вещи окажутся полезными. В несколько подредактированном виде:
Проблема.
В компании на протяжении нескольких лет производилось накопление различной технической информации: научных (и околонаучных) книг, журналов, статей, вырезок, спецификаций, исходных кодов, демонстрационных программ. Результатом этой деятельности стало появление архива.
Задача.
Разработка (поиск) программного продукта (далее — электронной библиотеки) позволяющего осуществлять простой доступ ко всем хранящимся и поступающим документам. Для этого требуется решить две основные проблемы: ввести имеющиеся в архиве документы и обеспечить возможность доступа к ним.
Основные ф-ии ЭБ:
1. Ввод документов
2. Индексирование док.
3. Оперативный поиск и отображение док.
4. Управление функционированием ЭБ
Для реализации данных функций в ЭБ должны быть системы ввода, хранения, индексирования, поиска и отображения информации, администрирования.
Самым узким местом здесь является подсистема ввода документов.
Сопутствующие факторы:
1. Большое количество документов которые можно отнести к нескольким категориям
2. Большие объемы поступающей информации
3. Разнородность типов поступающей информации — документы, изображения, видеоизображения, демки и т.д.
4. Разнородность форматов поступающей информации: например для документов — pdf, ps, doc, html, xml. При этом, иногда, к документам отдельно прилагаются дополнительно несколько файлов.
5. Динамичность дисциплин и предметов по которым поступает информация. Некоторые вырождаются в самостоятельные.
6. Различные языки на которых написаны документы (Английский / русский / пр )
7. Документы могут поступать в архиве (rar / zip / tar / … )
Требования предъявляемые к ЭБ:
1. Быстрый и качественный поиск информации
2. Простой ввод поступающей информации
3. Возможность промотра всех документов по теме текущего
4. Безопасное хранение
5. Разграничение доступа
6. Компактность
7. Рассылка оповещений о поступлении новой информации
Пару месяцев назад, вспомнил об этом проекте, даже появилась мысль сделать нечто подобное Правда, раньше весны, руки до него не дойдут.
ЗХ>у меня на винте валяется ок. 3 Гиг ОЧЕНЬ НУЖНОЙ И ПОЛЕЗНОЙ электронной документации. ЗХ>Её КПД близок к 0, поскольку даже если я знаю, что ЭТО ГДЕ-ТО БЫЛО, найти что-нибудь в этой груде все равно очень тяжело
Перегони все в chm, затем вставь в MSDN (поищи по ключевому слову MSDN Integrator)
Здравствуйте, dkey, Вы писали:
ЗХ>>у меня на винте валяется ок. 3 Гиг ОЧЕНЬ НУЖНОЙ И ПОЛЕЗНОЙ электронной документации. ЗХ>>Её КПД близок к 0, поскольку даже если я знаю, что ЭТО ГДЕ-ТО БЫЛО, найти что-нибудь в этой груде все равно очень тяжело
D>Перегони все в chm, затем вставь в MSDN (поищи по ключевому слову MSDN Integrator)
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>в) ваши требования к такой проге (если она вам, конечно, интересна)
Ко всему вышесказанному:
+ Придется решать проблему дублирования документов, когда документ уже есть в базе, но, например, в другом формате.
+ Как-то разруливать вариант, когда получена новая версия имеющегося документа. Помните как в RFC obsoletes/obsoleted by. Проблема эта очень и очень сложная, но при ведении рабочего архива актуальная буквально через месяц использования.
+ Возможность сохранения указателя на конкретный документ в виде текстовой строки, не "Dev/Languages/C++/Addison Wesley — Modern C++ Design Generic Programming and D.pdf", а "0A65AE92BC21". Это также очень нужно для cross-referenc'а в документации.
+ Не только выделения части библиотеки, но и консодидации библиотек. Сюда же репликация. Например, для сценария, когда техническая библиотека должна быть доступна удаленным участникам проекта в том числе в off-line. А если еще поперчить слежением за версиями... веселая в общем фича.
— Не совсем очевидно задуманная монолитность архива. А если архив выложен на ftp и/или в пиринговых сетях? К тому же распаковывать иллюстрированную книжку в .pdf размером метров в 150? Слишком уж сильное ограничение доступности документов в стремлении облегчить себе кодирование :). К тому же сразу стоит закладываться на то, что хранящиеся документы могут быть изменяемыми — то есть открываться для редактирования.
+ Маленький мазок — хотелось бы иметь отстойник, куда за 2-5 кликов можно кинуть док, чтобы потом в воскресенье (через 4 месяца:) все это разрулить по полочкам.
+ Еще фишка — при ненахождении документа в базе по ключевым словам предлагать искать в инете :)
+ А как вам сервер документации, торчащий в инете? 250$ per seat :)
Главное поменьше кибернетики, чтоб услужливая программа не запендюрила нужный документ куда-нибудь на 4-ый уровень в иерархии, как раз в то место, где его искать будут в последнюю очередь. Пользователю надо советовать, но информацией он должен управлять сам.
И еще не уйти в разработку теории всего. Ведь все в нашем мире — суть информация, требующая каталогизации :). Надо грамотно ограничить задачи.
Только вот это уже на 3-4 человека-года :). А шароварная пука, боюсь не будет иметь большого успеха — все-таки надо иметь большую внутреннюю аккуратность, при работе с электронной документацией, просто у каждого существует некая вера в то, что если бы был удобный инструмент, то он-то бы точно помог структурировать несущиеся потоки информации. Думаю, что это на данном этапе развития технологий не так. Помню как совсем недавно в поисках какой-то технической информации обзвонил всех коллег, потом друзей, пока один не поинтересовался — а не искал ли я это в собственной коллекции ебуков (5 гб), ответить мне ему было нечего :) Посмотрел — и действительно нашел там. Так что средство требуется, но...
F>Главное поменьше кибернетики, чтоб услужливая программа не запендюрила нужный документ куда-нибудь на 4-ый уровень в иерархии, как раз в то место, где его искать будут в последнюю очередь. Пользователю надо советовать, но информацией он должен управлять сам.
F>И еще не уйти в разработку теории всего. Ведь все в нашем мире — суть информация, требующая каталогизации :). Надо грамотно ограничить задачи.
F>Только вот это уже на 3-4 человека-года :).
Ты преувеличиваешь
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
У меня была такая мысль сделать описание для своей коллекции дисков, чтобы с обложками и пр.
Но по-моему путь с папками тупиковый. Когда информации много, то удобней локальный поисковик, который все файлы проиндексирует и будет их выдергивать по мере необходимости.
Здравствуйте, Frostbitten, Вы писали:
F>Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>>в) ваши требования к такой проге (если она вам, конечно, интересна)
F>Ко всему вышесказанному: F>+ Придется решать проблему дублирования документов, когда документ уже есть в базе, но, например, в другом формате.
Уже думал об этом, к чему-то определенному пока не пришел.
F>+ Как-то разруливать вариант, когда получена новая версия имеющегося документа. Помните как в RFC obsoletes/obsoleted by. Проблема эта очень и очень сложная, но при ведении рабочего архива актуальная буквально через месяц использования.
Аналогично
F>+ Возможность сохранения указателя на конкретный документ в виде текстовой строки, не "Dev/Languages/C++/Addison Wesley — Modern C++ Design Generic Programming and D.pdf", а "0A65AE92BC21". Это также очень нужно для cross-referenc'а в документации.
Учтено
F>+ Не только выделения части библиотеки, но и консодидации библиотек. Сюда же репликация. Например, для сценария, когда техническая библиотека должна быть доступна удаленным участникам проекта в том числе в off-line. А если еще поперчить слежением за версиями... веселая в общем фича.
Учтено
F>- Не совсем очевидно задуманная монолитность архива. А если архив выложен на ftp и/или в пиринговых сетях? К тому же распаковывать иллюстрированную книжку в .pdf размером метров в 150? Слишком уж сильное ограничение доступности документов в стремлении облегчить себе кодирование :). К тому же сразу стоит закладываться на то, что хранящиеся документы могут быть изменяемыми — то есть открываться для редактирования.
Не совсем понял. Подробней можно? (в смысле, чего не хватает?)
F>+ Маленький мазок — хотелось бы иметь отстойник, куда за 2-5 кликов можно кинуть док, чтобы потом в воскресенье (через 4 месяца:) все это разрулить по полочкам.
Учтено
F>+ Еще фишка — при ненахождении документа в базе по ключевым словам предлагать искать в инете :)
Ну, это скорее маленькая полезная фича, нежели насущная необходимость
F>+ А как вам сервер документации, торчащий в инете? 250$ per seat :)
Есть такая мысль на будущие версии. Пока не шибко серьезная
F>Главное поменьше кибернетики, чтоб услужливая программа не запендюрила нужный документ куда-нибудь на 4-ый уровень в иерархии, как раз в то место, где его искать будут в последнюю очередь. Пользователю надо советовать, но информацией он должен управлять сам.
Учтено
F>И еще не уйти в разработку теории всего. Ведь все в нашем мире — суть информация, требующая каталогизации :). Надо грамотно ограничить задачи.
Чуть было не... Но вовремя одумался
F>Только вот это уже на 3-4 человека-года :).
ладно. вскрытие покажет. спасибо за помосчь
Здравствуйте, Зверёк Харьковский, Вы писали:
F>>- Не совсем очевидно задуманная монолитность архива. ЗХ>Не совсем понял. Подробней можно? (в смысле, чего не хватает?)
Я про то, что совсем неочевидно желание лишить пользователя доступа к _файлам_ документов — слишком большие ограничения — не выложить их, не изменить.
F>>+ А как вам сервер документации, торчащий в инете? 250$ per seat :) ЗХ>Есть такая мысль на будущие версии. Пока не шибко серьезная
:)
Здравствуйте, Frostbitten, Вы писали:
F>Здравствуйте, Зверёк Харьковский, Вы писали:
F>>>- Не совсем очевидно задуманная монолитность архива. ЗХ>>Не совсем понял. Подробней можно? (в смысле, чего не хватает?) F>Я про то, что совсем неочевидно желание лишить пользователя доступа к _файлам_ документов — слишком большие ограничения — не выложить их, не изменить.
В таком случае надо сервис делать, который будет следить за изменениями файлов и автоматически вносить исправления в базу.
F>>>+ А как вам сервер документации, торчащий в инете? 250$ per seat :) ЗХ>>Есть такая мысль на будущие версии. Пока не шибко серьезная F>:)
Здравствуйте, Saltarello, Вы писали:
S>Здравствуйте, DrDred, Вы писали:
DD>>MyBase на www.wjsoft.com — использую, есть почти все, что упомянуто
S>А при больших объёмах информации он сильно тормозит?
честно говоря не знаю, объем информации в ней у меня хранится небольшой
Здравствуйте, Зверёк Харьковский, Вы писали:
DD>>Но самое главное препятствие на пути классификации — это обычная человеческая лень ЗХ>мечтаю сделать автоматическую — тоже ленив. мыслю. но в 1й версии — вряд ли.
А ты, я смотрю, оптимист Чтоб не тратил время зря, скажу, что великие умы сию задачу по сей день не решили. Так-что, ленив, не ленив — по боку. На это нужно гораздо больше времени, чем ты смог бы потратить, если бы не ленился.
Здравствуйте, Gadsky, Вы писали:
G>с возможностью полнотекстового поиска по различным форматам (pdf, html, txt) было бы G>иметь весьма удобно. В общем, чтобы из любой свалки можно было за G>приемлемое время вытянуть нужную вещь.
Ну дык бери любой полнотекстовый индексер — и вперед. Тут ждать не нужно. Их готовых — штук 10 с поддержкой русского, а вообще — не сосчитать. Вон, ссылка на один вверху справа моего сообщения
Ну, и чтоб не рекламироваться в одиночку: diskMETA (еще раз), Ищейка, dtSearch, Yandex.Server, наконец (интересно, кто сможет его настроить за полчаса? Я управился за 20 минут, но знал ключевые слова ).
Решение проблемы полнотекстового поиска не снимает проблемы каталогизации/рубрикации. А когда есть и полнотекст, и каталог, то встает проблема качественного объединения результатов поиска там и там. Те продукты, в которых это получилось — обычно очень успешные, но по трудозатратам это практически равно написанию кластерной поисковой системы с компонентами "классический полнотекст" + "поиск по структурированной информации", где под последней подразумеваются реферативные описания.
Правда, раньше весны, руки до него не дойдут.
практически один в один то, к чему я пришел.
