Category: финансы

Category was added automatically. Read all entries about "финансы".

Психологическая практика для ЦБ

Проработана книга Общая психодиагностика. - СПб.: Изд-во «Речь», 2000. -440 стр. как базовый ввод в относительно современные психодиагностические методики.
Весьма примечателен акцент книги на статистическом аппарате для достижения высокой достоверности психодиагностических методик (что важно, поскольку в психологии много проблем с достоверностью). Для процедур Форсированной Выгрузки применение психодиагностических методик кажется необходимым с целью повышения эффективности извлечения информации из выгружаемого и его окружения.

Терминология ЦБ

Дисклеймер: данный пост является сведением вместе описаний основных "составных частей" ЦБ в известных источников.

Поскольку плохо при каждой разработке велосипедов вводит собственную терминологию, следует обойти распространённые сейчас ключевые для ЦБ понятия.
Пройдёмся в хронологическом порядке:
Концепция Memex Ванневана Буша как системы захвата, хранения и доступа к информации, с которой человек работает, если интерпретировать эту концепцию очень широко - соответствует по описанию прикладному ЦБ ("расширитель памяти", практическое использование захваченных данных). А понятие Lifelog как захват (максимально больного количества) данных на протяжении жизни - соответствует этапу захвата данных, он у меня фигурирует как первый этап ЦБ. Понятие Whole Brain Emulation (WBE) является наиболее "официальным" и научным термином загрузки сознания (и правильно является), загрузка является главной целью ЦБ, с помощью гипотетических процедур восстановления модели личности из захваченных данных (у меня это фигурирует как второй этап ЦБ), эти процедуры методологически являются решением обратной задачи (для этого была временно введена аббревиатура Solving Reverse Problem of WBE - SRP WBE) эмуляции мозга (получение модели мозга из данных поведения), поскольку сама задача WBE является получением (данных) поведения из модели мозга. Более официальная и более научная форма loosely-copuled off-loading, LCOL как одна из возможных технологий загруки, проработанная нейробиологом и апологетом загрузки Рэндалом Кёнэ.

Таким образом ЦБ является одной из вариантов загрузки;
первый этап ЦБ - захват данных - это Lifelog;
второй этам ЦБ - восстановление личности, SRP WBE - это LCOL;
практическое применение ЦБ - вспомогательная память - реализация концепции Memex;

Ещё следует обратить внимание на некоторых людей: Стив Мэнн позиционируется как пионер в разработке Lifelog и носимых компьютеров, а Гордон Белл (судя по информации он всё ещё жив, несмотря на возраст) как разработчик реализации системы, подобной Memex - MyLifeBits, экспериментатор в Lifelog и популяризатор идей и практик прикладного ЦБ, описанных книге Your Life, Uploaded и даже теоретического применения ЦБ по прямому назначению.

Пост следует перевести на английский язык.

Этическая проблема сохранения

Дисклеймер: содержание данного текста не выходит за рамки личного мнения.

В пограничных кругах сторонников крионики (и других, более редких методов) совсем не редка ситуация сопротивления, неприятия сохранения со стороны их родственников: когда близкий криониста отказывается от сохранения, по множеству причин (в основной массе состоящих из "стандартных" аргументов против крионики и идеологическом непринятии борьбы со смертью). Это иногда называют проблемой сопротивляющихся родственников - грубо говоря, в ней и состоит этическая дилемма: с одной стороны умирающего родственника нужно спасать, с другой нарушается его воля и желание; с одной стороны он плохой крионист, раз не убедил близкого, а с другой близкий человек сам сделал свой выбор.
Конечно, реальная ситуация включает в себя и экономическую составляющую: крионические организации экономически заинтересованы в криоконтрактах, крионирующие заинтересованы в крионировании, хотя и не заинтересованы в криоконтракте (из-за малого масштаба крионической технической базы удельная стоимость крионирования, точнее - хранения, весьма высока), но на это согласие или несогласие крионируемого тут почти ничего не меняет, т.к. крионирование в обход сопротивления сложнее больше организационно, чем финансово.
Следует рассмотреть этическую проблему подробнее:
Близкий хочет уйти, крионист хочет не дать ему уйти;
Аргумент близкого: "я был ознакомлен со всем, что ты описал - иммортализм, ТГ, крио- и т.д. я не хочу/я вам не верю/я сделал свой выбор/это всё не сработает/будет война/всё пропадёт, оставьте меня".
Контраргумент состоит только в том, что близкий явно не воспринял, что нет никаких внятных обоснований того, что лучше умирать.
Аргумент близкого: "...я вижу... я сделал свой выбор, оставьте меня, <любой аргумент о ненадобности продолжения жизни>!"
Контраргумент состоит в том, что сопротивление и аргументы о пресыщении происходят от угасания личности по причине старения мозга.
Дальнейшие барьеры для понимания ещё более сложны для обхода в стареющем мозге, вспоминается Хейвортс со словами "они умерли не от инфаркта и инсульта, они были убиты собственными предрассудками и суеверями".
Так что-же? Человек активно сопротивляется, даже будучи поставленным перед всеми фактами - "да, я всё это вижу, просто оставьте меня с моими предрассудками и всё." И понятно что для очень многих цена криосохранения является неприемлемой, особенно для людей с доходом 8000р/мес, участвующих в содержании семьи, экономящих на спичках и горячей воде. Такие люди готовы пожертвовать собой ради того, чтобы на них просто столько не спускали, даже будучи ещё во вполне трезвом уме.
Так, всё-таки, что-же? Почему не правильно "пусть все, кто хочет жить - будут жить, а кто не хочет жить - не будет жить, каждый получит то, что хочет и все будут счастливы"? А насколько правильно осчастливливать насильно (не переходя к "крысе с электродом") ? Почему нужно сопротивляться обоснованному конечному отказу, особенно когда все участники понимают о его экономической стороне?
добавлю о себя здесь ещё только то, что если уж экономить - то по-крупному, даже на обрядовой части. Но вы увеличиваете число и сложность моих задач.

Никуда не годится, так недопустимо

Дисклеймер: это пост крайнего негодования

Кошмар, даже не буду называть кто и на что расходует свои умения и ресурсы:




Это всё есть реальное физическое подтверждение того, что совершенно реально и не супер-сложно собрать такую систему устройств, какую нужно себе. В нашем случае весь Компьютеризированный Сенсорный Костюм хорошо укладывается по всем своим модулям и соединениям.
Нет, отсутствуют подходящие решения для ЦБ; да, они могут быть созданы нами.

Практическая применимость форсированной выгрузки

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

Но у протокола всплывает очевидный практический аспект: данные с форсированной выгрузки могут использоваться и для "здорового" (т.е. не умирающего без криоконтракта) человека просто как внешняя память. Отличительная черта данных форсированной выгрузки по сравнению с данными ЦБ архива (что такое - здесь) - их очень высокое содержание сведений высокого уровня, если разбивать по иерархии психологии (деление изложено здесь, под номерами 5 и 6), когда в ЦБ-архиве основной объём данных это захват потоков с органов чувств и всякие артефакты). Высокая плотность и большой объём высокоуровневых сведений получаются за счёт того, что человек в речи напрямую излагает воспоминания, мысли, ассоциации, образы, сложные образы, чувства и практически ничего другого, также при захвате (съемке видео или записи голоса) мал паразитный трафик, при обычном-же разговоре с кем-то, например, многое в потоке является внешними шумами, паузами, собеседниками, ограничена тема, редко нужны высокоуровневые психологические "конструкты". Именно высокая плотность высокоуровневой информации, которая представляет очень большую ценность как для самого субъекта (в смысле, если он ещё жив и хочет использовать эти данные), так и для восстановления субъекта. Но вернёмся к сегодняшним техническим моментам:
Краткая суть протокола для терминальных людей: человеку демонстрируется знакомый ему артефакт (например, фотография) и он рассказывает свои воспоминания, связанные с этим артефактом. В результате порождается массив данных записи речи/видео изложения воспоминаний и последовательность артефактов (изображения и, желательно, что-то machine redable для связи с самими артефактами). Вариация протокола для нетерминальных субъектов: артефакты нужны как затравки к ассоциативным сетям памяти, их применение не обязательно; и без артефактов может быть нормально извлечён значительный блок связанных воспоминаний - например, сесть и написать очень подробный отчёт в свободной форме с добавлением своих мыслей и мнения  о каком-то событии, периоде времени или теме. На выходе формируется текстовая база.
Переходим непосредственно к data processing (как-нибудь на ней, как большей важности внутренней части ЦБ по сравнению со внешней стороной будет сделан специальный пост). Почти единственное, что разумно выполнить с массивом аудиозаписей - это распознать речь, сейчас это активно развивается и для автоматизированного распознавания речи (особенно для качественно записанной) на большом объёме данных статус технологии - "почти работает" и до формирования текстовых raw data с верным распознаванием большей части текста счёт идёт на уже менее чем на года. Грубые распознавания могут быть выполнены уже с имеющимися коммерческими или экспериментальными продуктами, с течением времени качество распознавания будет расти, также может подключиться и извлечение дополнительных данных, в роде эмоций говорящего и интонации. Для обработки текстовых данных (в случае применения при выгрузке текстового "метода" минуется стадия распознавания речи, хотя никто не мешает использовать дублирование) применяется text mining, хорошо развитый на данный момент, переходящий на сложную работу с естественным языками и позволяющий делать впечатляющие вещи. Для применения его в разных случаях разработаны и разрабатываются разные инструменты, как коммерческие, так и OpenSource (в том числе на Python и R ...эй, подождите, я-же... OH, SHI~ ).  В данном случае необходимы выделения ключевых смысловых "участников" текста и построение сети связности (хотя это очень сложный вопрос - что необходимо, он требует и конкретизации задачи, и оценок путей её решения и т.д., потому пока это только необоснованные предположения). Для ЦБ как внешней памяти (основное применение ЦБ для нетерминальных людей) raw text data должна быть переведена в некую ассоциативную базу данных с распознанными "узлами" каких-то ключевых образов и ассоциативынми "связями". Да данный момент с ассоциативными БД всё сложно, с симуляторами человеческой памяти тоже всё сложно, но такие вещи как кластерный анализ, могут приблизиться требуемому к функционалу.

Юзаем BEDTools

Набор программ для всяческих манипуляций с выравниваниями ридов и аннотациями, используются общепринятые форматы выравниваний - SAM/BAM, форматы аннотаций - GFF/BED/VCF (и BEDPE - Paired-End BED, поддерживающий разъединённую аннотацию). Не забываем про референсный геном в FASTA. Фокус работы стоит на элементах аннотаций - features. Что такое features - это метка, описание чего-то на сиквенсе, адрес: хромосома, начало, конец, цепь и разные текстово-числовые атрибуты, составляющие содержание.
Координаты в BED нулевые, zero-based для начала и one-based для конца features, потому координаты "0\t1" это первый нуклеотид, следует помнить что GFF и VCF используют one-based координаты. Заголовки поддерживаются - инструменты игнорируют первую строку если она начинается с #, browser и track. Пакет поддедживает сжатые файлы. Некоторые инструменты поддеживают "расщеплённые" BAM выравнивания (с -N в CIGAR строке) и блочные BED аннотации (типа BED12), для этого нужен специальный флаг -split.

Компоненты программного пакета умеют:
intersectBed - возвращать пересекающиеся features из двух файлов BED/GFF/VCF/BAM.
windowBed - возвращать пересекающиеся features из двух файлов того-же набора с некоторым окном близости.
closestBed - возвращать ближайшие features для каждого элемента в BED/GFF/VCF.
coverageBed - строить суммарную глубину и ширину покрытия features в файле BED/GFF и BAM относительно других features.
genomeCoverageBed - строить гистограмму покрытия генома, применяется для анализа reads coverage.
pairToBed - возвращать пересечения элементов между BEDPE файлом и BED/GFF/VCF/BAM.
pairToPair - возвращать пересечения элементов между двумя BEDPE файлами.
bedToBam - преобразовывать BED/GFF/VCF в BAM.
bedToIgv - делать в пакетном режиме скриншоны из IGV ждя каждого интервала в файле BED/GFF/VCF.
bed12ToBed6 - конвертировать между BED12 форматом и BED6.
substractBed - удалять пересекающиеся интервалы features.
mergeBed - сливать пересекающиеся features в одни features.
fastaFromBed - извлекать наборы сиквенсов на основе файлов аннотаций BED/GFF.
maskFastaFromBed - скрывать блоки FASTA файла на основе файла BED/GFF.
shuffleBed - перемешивать положения features по геному.
slopBed - корректировать (?*) features по запрашиваемому числу пар оснований.
sortBed - сортировать BED/GFF файл.
linksBed - строить HTML линки из BED/GFF файла.
complementBed - возвращать интервалы, не покрытые features на основе файла аннотаций.
overlap - вычислять величины перекрывания (положительные величины) или расстояния (отрицательные величины) между features.
groupBy - группировать features.
unionBedGraph - сливать множество bedgraph файлов в один с учётом coverage и пр.
annotateBed - аннотировать пересечения одного файла аннотаций между многими другими.

Формат BED: минимальный 3-столбчатый формат, опционально расшиярем до 12ти. 1 колонка - хромосома или контиг, 2 - старт в 0-координатах, 3 - конец в 1-координатах. Первые три обязательные, составляют формат BED3, остальные опциональны. 4 - имя, 5 - score, 6 - цепь, 7 и 8 - начало и конец субсиквенса, 9 - RGB маркировка, 10 - число блоков, 11 - размер блока, 12 - список блоков. Дополнительные колонки игнирируются, но не отбрасыватются bedtools, могут быть вариаци и в формате записи и порядке колонок. Распространены форматы BED3, BED4, BED5, BED6 и BED12.
Формат BEDPE: минимальный 6-столбчатый формат, часто расширяем до 10 и далее. 1 колонка - первая хромосома (. если неизвестно), 2 - первый старт  в 0-координатах (-1 если неизвестно), 3 - первый конец в 1-координатах (-1 если неизвестно), 4 - вторая хромосома (. если неизвестно), 5 - второй старт, 6 - второй конец. 7 - опциональное имя, 8 - score, 9 и 10 - цепи на первой и второй хромосомах.

Общий синтаксис базируется на вводе двух файлов через параметры -a и -b, когда файл один, он вводится через -i. Помним что файл 2 загружается в память.

intersectBed берёт 2 файла -a и -b (могут быть метки -abam для формата bam первого файла), он выводит в формате bed. Можно задать ввод с потока ввода в пайплане через "файл" stdin. При использовании первого файла как BAM -abam вывод переключается на BAM формат, для переключения вывода обратно в bed надо добавить метку -bed. Есть опция вывода в несжатый BAM -ubam.  Вывод прост, но не слишком информативен: каждый элемент аннотации - какое-то пересечение features из первого файла (именуется по названию этого features из 1 файла), размечается начало и конец пересечения, каждое пересечение - новый объект, потому один features из файла 1 может дать много пересечений. Инструмен хорош для разметки снипов из 1 по генам в 2, выведутся только значимые снипы. Получение не пересекающихся с -b features из -a ставится флаг -v. Можно выводить целиковый элемент из 1 для каждого пересечения -wa, флаг -wb выводит присоединённым к пересечениям набором колонок оригинальные пересекаемые элементы из 2 (BEDPE или BED12). -wo выводит в дополнение к этому ещё величину пересечения, -wao вводит к этому, но без величины пересечения, и висящие (нули по 2 хромосоме) элементы. Вывод элементов файла 1, которые хоть как-то пересекаются, без доп. инфы -u, вывод числа попадений совпадений для каждой записи -c. Количественные параметры -f и -r, влияют на -wb, -wo, -wao, -u, -c, -v. -f минимальная величина пересечения, дефолт 1E-9 (1нт, видимо меряется в мегабазах), -r мера общности функций, доля минимального совпадения для ОБОИХ функций (50% 1 от 2 И 50% 2 от 1). -split включает расщеплённый BAM или BED12, кратно - подавляет совпадение с интронами из второго в первом файле. Многие параметры комбинируются, но это очень усложняет интерпретацию вывода.

bamToBed преобразует BAM файл в BED6/12/PE формат. -i файл.bam, или -i stdin остальное опционально. -bedpe или -bed12 выводит в указанных форматах. -ed использует расстояние редактирования в поле BED score вместо стандартного качества картирования, -tag использует указанный числовой тег из BAM файла, -color использует указанное значение цвета вместо полного красного, -split указательно расщеплённого BAM.

windowBed детектирует соседние элементы между двумя файлами как intersectBed, но круче. Ввод такой-же: -a и -b файлы, -abam если нужно (и -bed/-ubam). -w величина окна, -l и -r левое и правое окно отдельно, -sw задать правое и левое окна как определяемые цепью, -sm выводить только совпадении цепей в 1 и 2, -u выводить элементы 1 просто только если хоть что-то пересекается вообще. -c выводить число пересечений с учётом ограничений -f. Флаг -v работает также.

closestBed ищет ближайшие элементы между двумя файлами, поддерживает BED/GFF/VCF. -s отключение учёта цепей, -d задание дистанции, -t контроль вывода: all (дефолт) вывод всех, которые в окне, first первый элемент, встречающийся в 2, last - последний элемент, встречающийся в 2.

subtractBed вычитает пересекающиеся между двумя BED/GFF/VCF файлами области, возвращает только неперекрывающиеся их фрагменты. -f минимальная величина перекрывания, дефолт 1Е-9 (1нт) а очень высокие значения будут давать оригинальные элементы 1, -s отключение контроля цепей.
mergeBed сливает в 2 или 1 файлах пересекающиеся, по дефолту дистанция (-d) слияния 0, можно отключить различение цепей (-s), нет именования, но можно через ; выводить имена сливаемых (флаг -nms). -n выводить число актов слияния на новый элемент.

coverageBed составляет оценку покрытия элементов из файла аннотаций 2 по файлу1 , для 1 поддерживается BAM (-abam), есть поддержка -split. Выводятся элементы 2 с 4 доп. колонками: 1 - число пересёкших элемент элементов из 1, 2 - число пар оснований с ненулевым покрытием, 3 - длина элемента, 4 - доля пар оснований с ненулевым покрытием. -s включает учёт цепей (отключён по дефолту), -hist перводит режим вычислений в 1 - глубину покрытия, 2 - число покрытых оснований, 3 - длину элемента, 4 - долю покрытия и добавляет суммарную гистограмму по блокам в виде доп. элементов. Флаг -d включает вывод покрытия для каждой позиции в 2 в 1-координатах в виде пары столбцов - координата и покрытие.

genomeCoverageBed строит гистограмму покрытия генома элементами (функциями или ридами). Ввод -i BED -g genome.tab, BED должен быть сортирован по хромосомам (сортировка sort -k1,1 сойдёт), genome.tab файл с длинами хромосом. Поддерживается ввод BAM (-ibam) и -split. Стандартный вывод даёт набор строк с 1 - хромосома, 2- глубина покрытия, 3 - число оснований с таким покрытием в хромосоме, 4 - размер хромосомы, 5 - доля оснований в ней с такм покрытием + такой-же набор строк для всего генома в целом. Максимальное ограничение покрытия -max представляет величины покрытия более этого значения равными этому значению. Режим -d выдаёт трёхстолбчатый вывод с хромосомой, координатой и величиной покрытия.

fastaFromBed извлекает последовательности из генома по файлам аннотаций. Стандартный ввод -fi in.fa -bed file.bed -fo out.fa. -name использует имя из BED вместо стандартного имени Хромосома:начало-конец, -tab переводит fasta вывод в табулированный формат, -s включение учёта цепей.

maskFastaFromBed скрывает в fasta файле аннотирование последовательности. Стандартно -fi in.fa -bed file.bed -fo out.fa. -soft включение мягкого скрывания вместо дефолтного жёсткого.

shuffleBed генерит рандомный разброс элементов по геному. Стандартно -i BED/GFF/VCF -g genome.tab. Ставит на элементы случайные хромосомы и координаты, -chrom фиксирует хромосомы. Исключение регионов куда нельзя случайно класть элементы -excl BED/GFF/VCF, -seed контролирование псевдослучайного набора.
slopBed расширяет размер каждого элемента, ограничиваясь длиной хромосомы. На входе -i BED/GFF/VCF -g genome.tab -b N / -l N1 -r N2. Удлинение на b, -l и -r для разных концов, -s включает учёт ориентации для l/r.

sortBed сортирует BED/GFF/VCF файл по основным параметрам. -i file.bed, параметры сортировки: -sizeA возрастание размера элемента, -sizeD убывание размера, -chrThenSizeA сначала по хромосомам, потом по возрастанию размера, -chrThenSizeD сначала по хромосомам, потом по убыванию размера, -chrThenScoreA по хромосомам, потом по возрастанию score, -chrThenScoreD по хромосомам, потом по убыванию score. Заявлено что грамотная сортировка sort работает быстрее и экономнее.

linksBed создаёт HTML файл с линками на UCSC браузер (локальный или глобальный). -i file.bed > file.html. -base задаёт базу данных, дефолтная http://genome.ucsc.edu -org задаёт организм, дефолт человек. -db сборка генома, дефолт hg18.
complementBed выводит интервалы генома, не покрытие какими-либо элементами. -i file.bed -g genome.tab. Нет дополнительных параметров.

bedToBam конвертирует файл аннотаций BED/GFF/VCF в BAM. -i file.bed -g genome.tab > file.bam. Задать параметр качества картирования -mapq N заместо дефолтного 255, использовать несжатый BAM -ubam, -bed12 - ввод в блочном BED, вывод в расщеплённом BAM.

overlap вычисляет длину перекрывающегося фрагмента или расстояние между элементами в одной строке ввода, применяется для анализа данных от других программ BEDTools. -i file.bed/stdin -cols (номера колонок в файлах ввода). Номера - старт1,конец1,старт2,конец2.

bedToIgv пишет пакетный скрипт для IGV. -i file.bed > script.batch. Путь для изображений задаётся -path, дефолт ./ , -sess индикатор новой сессии, по дефолту нет (чтобы загрузить самим что надо и настроить как надо). -sort сортировка BAM в изображении, по дефолту ничего, можно по base, position, quality, sample, readGroup. -clps схлопнуть риды, по дефолту нет, -name использовать имя из имени (столбец 4) для каждого снимка, по дефолту местоположение. -slop величина фланков в изображении по краям features. -img формат изображения, дефолт png, можно eps и svg.

bed12ToBed6 преобразует файл блочный bed12 в bed6, расщепляя блоки на наборы отдельных элементов.

gropuBy - займусь потом.

unionBedGraph объединяет много bedgraph файлов в один файл для сравнения покрытия и других параметров. Стандартно -i file1.bg file2bg... > file.bg. -hedaer печатает заголовок хромосомы, старт, конец и имена файлов. -names задаваемые имена значащих столбцов заместо имён файлов на вводе, -empty выводить пустые области, требует -g genome.tab. -filter TEXT вывод пустых значений как текста, по дефолту 0, можно задать N/A, -/- или что угодно. -examples - показать подробное применение в примерах. Программа работает и с нечисловыми данными.

annotateBed вычисляет какой-либо параметр покрытия для элементов файла аннотаций по набору других файлов аннотаций. Ввод -i BED/GFF/VCF -files (список файлов). Добавить заголовок -names, выведутся и стандартные имена столбцов. -counts вычислять число попавших элементов каждого типа заместо дефолтной доли покрытия, -both выводить и долю, и число. -s включить различение цепей.

Чем полезно ЦБ сейчас

 
Текущая польза от практики захвата всего

Бэкап всего нужного

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

Цифровой бэкап реальных объектов

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

Цифровая "супер-память"

Фото увиденных объектов, записи услышанного, видеозаписи событий и данные координат GPS-трекера - (относительно) высокоточные и стабильно зафиксированные воспоминания на внешних носителях с неограниченной возможностью показа и передачи. При оптимизации инструментов просмотра может служить мощными шпаргалками для собственной памяти. Спектр применений широк, хоть это и достаточно трудоёмко: серьёзный перепросмотр нужен для подробного запоминания и понимания чего-либо, для подробного анализа и отслеживания, как источник вдохновения и т.д. Практика показывает, что при перепросмотре можно узнать много нового) В личном опыте использовалось и немало: начиная от развлекалова - перепросмотр фото- и записей с разных сборищь (польза - подъём настроения, вспоминание проихсодившего, его переинтерпретация, узнавание пропущенных подробностей, сбор компрометирующей информации, целевой монтаж и т.д.), заканчивая усиленным запоминанием (мною были записаны все спецкурсы, перепрослушивание записей стало мощным инструментом к пониманию и запоминанию информации к экзаменам). В каком-то смысле это успокоительная шпаргалка для памяти - когда есть работающий диктофон -- не нервничаешь, что что-то не услышишь, пропустишь и забудешь (иногда просто не слушаешь - если понадобится, то перепрослушаешь всё равно). У архива "цифровой памяти" есть особенность, которую может и не видно сразу: с течением времени и оптимизацией с исправлением ошибок общее качество архива растёт и с ростом навыков обработки информации можно извлекать из архива всё больше полезного. Показательный пример: виртуальный пародийно-пародийный музыкальный коллектив не существует, но на основе ЦБшного архива собрано свыше 0,5Гб треков и 1Гб видеоклипов.

Доказательная база, "кэш" и "чёрный ящик"

В редких случаях при сочетании удачных обстоятельств цифровой бэкап может служить доказательно-оправдательной базой, либо в случае мелких разногласий - когда не требуется подтверждение суда о достоверности, либо в очень серьёзных - когда суд подтверждает достоверность данных из архива. Возвращение на землю и пытка для окружающих - неопровержимая аргументация в споре против аргумента "я этого не говорил!" путём включения диктофонной записи на участке произношения этого оппонентом. Близкой к этому является и шпаргалка для памяти - голосовой кэш: перепрослушивание для лучшего запоминания только-кто прозвучавших слов, особенно это полезно для инструкций. Из опыта - несколько случаев использования с пользой было. Аналогичная польза от записи телефонных разговоров очевидна. К тому-же работающее устройство записи (не очень важно чего) может служить "чёрным ящиком" на случай критических событий, вроде попадания в аварию в транспорте. А самый радикальный и мощный метод создания цифрового бэкапа - система постоянного видеонаблюдения даёт приемущества системы видеонаблюдения)

ЦБ - собственно, для чего на практике?

Что-же такое ЦБ - по началу пришлось разбираться весьма долго, поскольку очень много ссылок на термин, а подробное описание трудно найти, а если найти - оно размыто и в разных местах написано по-разному. Долго искал -- но удалось сформировать связанное понятие что это и для чего, по этой причине частично и решил описать сий термин. Собственно, значит он сохранение в цифровом виде данных о человеке - как можно ближе относящихся к личности, к памяти. Информация о том, как он думает/думал и он знает/знал. Дальше вопрос разделяется на несколько частей:

1) Классификация используемой информации - условно (читай - отсебячина, но зато верно) можно разделить на прямую (точнее квази-прямую) и косвенную. Прямая - непосредственно используемая/использованная/сгенерированная информация, долговременная память. Правильнее говорить - аналог долговременной памяти, суррогат - поскольку пока не представляется возможным непосредственное считывание такой информации из мозга. Типами такой информации являются а) аналоги с органов чувств (аудио-, видео-записи, фотографии виденного) и близкое к ним (ну например там GPS-трекинг) и б) коммуникативная информация - не привязанная прямо к органам чувств, во всяком случае мало теряющая при абстракции от них (история переписок по электронной почте/IM/всякой хрени - ведь необязательно определять переписку по почте как то, что человек видел, сидя за компом, на мониторе -- достаточно просто собственно текста с логами). В общем постоянная долговременная память на внешних носителях.
Косвенная - мета-информация о человеке, о его личности и о его поступках. Совсем коряво можно разделить как направленную и ненаправленную. Направленная - результаты специально выполняемых, например, тестов для составления модели личности или характеристик человека. Сюда-же можно причислить сторонние описания человека. Ненаправленная - косвенно содержащаяся, информация о самих поступках, которая характеризует логику и мышление человека, косвенно описывает работу личности.
2) Для чего всё это нужно - вопрос опять разделяется на 3,5 темы радикально отличающейся важности.
Причина первая, самая реальная, прагматичная и исполнимая сейчас: внешняя долговременная память. Чтобы помнить всё и никогда не забывать, точно хранить и иметь возможность передать без искажений. Сложность тут только технически-временнАя - когда/как всё это обрабатывать, чтобы самому знать что есть) Замечание: тут используется практически только прямая информация. Нужно это бывает для всего подряд и придумывать ничего не надо, чтобы примеры привести.
Причина вторая - ТГшная. Построение ИИ на основе и прямой и косвенной информации, создание модели личности-источника. Создание копии или продолжения человека в виртуальном виде. Акцент на том, что тут становится весьма важной косвенная информация, как основа для ключевых алгоритмов действия ИИ. Дело вполне реально представляемое и реальзуемое в относительно недалёком будущем, ибо есть "не более чем" написаниее ИИ довольно стандартного типа (тип "человек", коих много).
Причина третья - труЪ-ТГ -- комбинирует 1 и 2: построение, как было названо где-то, сверх-личности на неважно каком носителе (либо чисто виртуально, либо на реально-вируальной основе постсингулярных технологий) как объединённого с ИИ из п2 и личностью-источником. Принципиально не много различий с п2, но дело более суровых технологий -- впрочем псто не о том.
Причина третья с половиной - УГ-труЪ-ТГ -- пункт 2 или 3 (в смысле с бОльшим физическим воплощением) с целью восстановления человека, или совсем умершего, или с сильно повреждённым крионированием мозгом (в общем у Эттингера это частично описано). Использование всех видов информации о человеке для максимально полного восстановления его личности после повреждения (низкокачественное крионирование) или гибели (некрионирования, уничтожения тела или смерти до появления технологий сохранения). По сути - мера отчаяния, попытка BackUp'a. Соответственно, страховка - повышение качества восстановления после крионирования (компенсация возможных повреждений информации в мозге) И шанс быть восстановленным хотя-бы частично после полного уничтожения или сбоя крионирования. Дело постсингулярных технологий, в некоторых случаях может быть и нереализуемых вовсе (крупномасштабные квантовые вычисления, например - см. работы Соловьёва со ссылками).
3) Методы реализации: по сути уже описаны в теме 1 - тотальная запись человека (ношение аудиовидеорекордеров), протоколирование и архивирование коммуникационной информации (история переписок, например), протоколирование результатов тестов человека и т.п.

Суммарно, бОльшая часть - это дело будущего, граничащего с фантастикой (обсуждение именно границ -- давайте оставим за прелелами этого псто))))) ), меньшая часть - весьма интересная и прагматичная штука. Кстати сказать, о ЦБ я думал ещё в конце школы, когда ещё не знал про ТГ, тогда-же и применял на крупных событиях (побольше фотографий и ношение диктофона). Мне было надо в таких случаях иметь доскональную запись происходивших событий. И несколько раз себя оно оправдывало (молчу про необходимость в спорах доказывать что человек тогда-то сказал именно то-то, а не что-то иное). В менее нужных ситуациях (соответственно, более ТГ - т.к. более широко использовалось) впервые было использовано чисто JFL , и весьма себя оправдало. Потом я с удивлением увидел знакомую идею, котрая была названа ЦБ и планируется использоваться для воссоздания личности (!) - о таком я по началу не думал.
В общем, сейчас это можно использовать только как внешную долговременную память. Подразумевается, что её можно эффективно использовать.

Вот и возникает первый вопрос - что лучше всего (читай - какое ПО на компе) использовать для максимально удобного и эффективного способа хранения/структуризации/просмотра материалов с максимально возможным использованием? Нечто вроде такой супер-мультимедиабиблиотеки с распределением по времени и объединением разных форматов в работе (одновременное использование и фото и видео и аудио и времени и координат, если те есть). В совсем пределе - интеграция с почтой, телефонией и ещё фиг знает чем придумать, а то собственный мультимедиаархив себя уже исчерпывает.
Что можно порекомендовать?

Второй вопрос - технический. На что всё писать. В принципе, тут вопросов меньше -- архивирование всякой там почты не есть проблема, а всю возможную сейчас мультимедиаинформацию можно записывать на портативные недорогостоящие камеры. Но возникает конкретный вопрос удобства - точнее очень конкретная необходимость (по многим причинам) в устройстве конкретного типа. Может быть такое существует:
надеваемая, желательно на башку, компактная аудио-видео-фото-записывающая фигня со своей памятью и аккумулятором. Совсем желательно -- для повышения функциональности, оправдания в ношении и уменьшении палева -- скомбинированная с наушниками/гарнитурой. В пределе - замаскированная под гарнитуру, в т.ч. и BT -- опять-же оно может таковым являться по совместительству. Технические требования -- работа сколько-то часов в режиме записи видео- , аудио- , видеоаудио- и как фото- . Подразумевается удобное управление, т.е. не тыкание в девайс (в башку) пальцами - как вариант или отведённый далеко под руку/в карман/за пазуху мини-пульт с 4 кнопками , или труЪ - привод (хотя-бы одной кнопки) мимикой в местах крепления (размещение чувств. элемента много какого типа, тут выбора немало), чтобы - например, сфоткать почти со скоростью обращённого взгляда, чтобы не тянуться руками до кнопок/башки (миллион раз такое было надо). В общем такой гипотетический девайс не сильно отличается от китайских (Данилиных) наушников за 5к р, а по удобству весьма круте, потому и стоимость его должна быть не сильно выше. Может такое и есть, но если что-то разработет (задача - по сути в дизайне) -- то тот крут.
Что можно порекомендовать?