Future request ScrapBook

Для работы с информацией, которая может быть отображена в браузере я использую расширение Firefox
ScrapBook. Работать (искать/извлекать) удобно по сравнению горками файлов в разных папках сохраняемых браузером, важный бонус все содержимое сохраняется так как я его вижу, за редким исключением.
Зачем нужно структурировано работать с информацией сохраняемой локально из web смотри в блоге Сергея Орлика Средства Web 2.0 внутри предприятия - кому это надо?

Словарь, для устранения разногласий при чтении:

• Элемент - хранимая сущность в scrapbook, наиболее важный это сохраняемая копия документа с указанием URL и связанная с папкой файлами документа (захватываемый документ всегда переименовывается в index.html, если охраняемый документ не принадлежит типу text/html то файл index.html содержит редирект на сохраненную копию файла в папке).
• Каталог - элемент для группировки других элементов scrapbook
• Папка - поддиректория в директории data - каталога multiscrapbook

К сожалению, при работе со scrapbook не хватает некоторых функций:

1. Может быть реализовано на существующей базе кода:
   
   1. Система сложной фильтрации, отбор элементов более чем по одному критерию, в идеале булевый язык запросов с группировкой скобками и операторами поиска значений над атрибутами. Панель поиска (минимум быстрого) должна давать возможность просмотра краткой версии результатов поиска с переходом по клику к записи в scrapbook'е. Проблема "полноценного" полнотекстового поиска должны решаться внешним приложением, может быть интегрированным в scrapbook.
   2. * Виртуальные каталоги на основе сохранных запросов.
   3. * "Двух оконная лесопилка" для упорядочивания содержимого, очень не хватает возможности быстрой сортировки большого числа элементов без перетаскивания или открытия инструмента переместить.
   4. * Поиск по именам и атрибутам каталогов.
   5. Экспорт отдельного каталога вместе с подкаталогами или любого отобранного набора элементов для просмотра любым браузером, вместе с страницей навигации по экспортированным элементам (существующая функция позволяет создать навигацию по всему набору элементов scrapbook).
   6. * Ссылки на любой элемент scrapbook - локальный протокол - в принципе бантик, но нужен для комментирования элементов.
   7. * Удаление и/или перемещение групп каталогов.
   8. Экспорт отобранных элементов с запаковкой в zip (можно реализовать как плагин к scrapbook).
   9. Экспорт элементов в директории, названные не по содержимому тега title сохраненных документов, а по id элемента, с сохранением в index.dat структуры связей с каталогами. Восстановление при импорте элемента и структуры каталогов которым он принадлежал, возможно с созданием недостающих каталогов.
   10. * Группировка элементов по запросу, хранение версий страниц - механизм может быть реализован за счет виртуальных каталогов, расширенных ссылкой на элемент открываемый по умолчанию при выполнении операции "Открыть" для каталога.
   11. * Сравнение элементов элементами в текущем или другом scrapbook'ке по атрибутам и/или содержимому.
   12. * Работа с дублями элементов - минимум индикация, максимум предложение создать версию при сохранении или не сохранять. Дубль определяется на основании URL или редактированием запроса пользователем. Совсем идеальный вариант поиск дубля в multiscrapbook.
   13. Слияние/ объединение двух scrapbook'ов с сохранением структуры каталогов.
   14. * Принадлежность элемента более чем одному каталогу
   15. * Отмена удаления с восстановлением структуры принадлежности каталогу. Понадобится функция очистки корзинки.
   16. Экспорт структуры каталогов в другой scrapbook.
2. Требует перехода на хранение данных в БД, сохраненные версии страниц продолжают храниться в папках с дублированием метаданных в файле index.dat (пункты выше, отмеченные * будет проще реализовывать при хранении данных в БД):
   
   1. Переход от хранения структуры ссылок на папки элемента в RDF на БД, например SQLite. Дает повышение быстродействия и само документирования структуры хранения. Для удобства можно сохранить интерфейс работы с RDF triples. Недостаток, при сбое сложнее восстановиться чем при хранении в файле RDF, но если хранить дублирующуюся информацию в файле index.dat каждого элемента, то возможно запустить процедуру автоматического восстановления с потерей настроек scrapbook.
   2. Иерархическая система хранения папок. Работать с содержимым в файловой системы Multiscrapbook когда в папке накапливается много сохраненных ссылок становится сложно (в рабочей папке сейчас 5560 подпапок).
   3. Работа с рубрикатором - фасетная классификация элементов - мульти иерархия каталогов/рубрик - ключевые слова к каталогам/рубрикам, наличие функций ведения АПУ.
   4. Ограниченный вариант счастья наступит, если интегрировать в scrapbook систему управления библиографией, типа Zotero, но без ограничений присущих подобным системам (см не написанный пост).
1. Для реализации требуется дополнительной серверной платформа:
2. Публикация на сервере и совместная работа с одним scrapbook нескольких пользователей.
3. Персистентный идентификатор элемента.