Фотопроект26.11.2011. Ханов О.А.Из того, что не вошло в прошлую посылку. Для ФОТО: phtx.txt - короткие тексты для описания фотографий Мне кажется, в описании фото надо еще предусмотреть поле для ссылки на возможный текст или даже на отдельный сайт, посвященный данной фотографии. Содержанием такого текста может быть обсуждению снятого материала - композиция, освещение и т.д. Или это может быть какая-нибудь история, связанная с этой съемкой и т.д. Т.е. оставить поле, которое на практике очень редко будет востребовано. Для человека: mantx.txt - короткие тексты для описания человека (сделал это недавно, поэтому есть только для тех, кого недавно вводил) Аналогично тому, что предлагается для фото, полезно предусмотреть поле для ссылки. Есть у меня еще один файл, в нем - информация только обо мне, поскольку необходима санкция человека на распространение такой информации (если ее нет в открытых источниках). В этом файле: индекс/электронный адрес/адрес личного сайта Для объектов тоже просится (на всякий случай) поле для ссылки. 30.11.2011. С.О. Тут есть еще вопрос - откуда брать имя - из файла, или из базы имен. Сейчас беру из файла, поскольку это "авторское". Но так будет много несвязанных имен в базе фотографий. 01.12.2011. Ханов О.А. "вопрос - откуда брать имя -.." У меня был такой концепт. Вввод происходит как угодно. Программа через "sinfio" пытается найти имя в базе и если находит - присваивает уже существующий индекс. Если нет - дает мне список не обнаруженного. Я ищу вручную, если нахожу - даю индекс, а если нет - даю желаемое написание в левом поле файла "sinfio". По окончании ручного ввода программа находит новые незанятые индексы и присваивает их всем несовпадающим именам, которые находит в поле "желаемое написание", у которых нет индекса. Потом по информации из sinfio ставит вновь полученные индексы в discript фото. Предполагаю, что у тебя начало может быть похожим - что можно, индексируется. А что не получается - вообще не ставить индекс до тех пор, пока не будет проведена процедура "опознание", в которой дается новый индекс и синонимы. После опознания каждого субъекта хорошо бы сразу ставить индекс в discript всех фото, где это написание (и его синонимы) встречаются - чтобы больше "глаза не мозолило". Во всех вторичных выборках, где встречается некое имя, я даю его стандартное написание из базы имен. Т.е. первичное написание у меня остается только в базе описаний фото, но и там оно сопровождается присвоенным индексом. _______ Комментарии к phmans_err. 1. "отсутствует индекс фото" - забыл предупредить, что это демонстрационные файлы, из которых удалил вручную все начало - там были фото без каталога, т.е. нестандартно. Надо было бы исправить, но "руки не дошли" - было проще удалить, чтобы не было вопросов. Тем более, что при открытии файла сразу была видна была именно эта настандартщина, и только много дальше - с каталогами. Потом увидел, что это что-то за собой еще потянуло и, кажется еще что-то удалил, чтобы "было понятнее". Но все это только во вторичных (для меня) текстовых файлах. По той же причине вылезли ошибки в phtx_err 2. Почему "нет псевдонима в sinfio" - не понятно. М.б. из-за прописных букв? В FOXPRO я не различал регистры. 04.12.2011. С.О. Сейчас перерабатываю базу. фотографий, поэтому пока нет смысла загружать описания. Однако, первым пунктом все равно должен идти импорт из твоих баз. Иначе слетят индексы. Поэтому все-таки попробуй научится импортировать свои файлы в базу. Сейчас работает все до пункта "Импорт фотографий из файла "phbas.txt". После импорта будут работать редактор имен и псевдонимов. В принципе, если твои файлы имеют окончательную версию, то можно заняться редакцией. Там есть много опечаток. В файле последний вариант. Не все еще работает., но структуру я менять, наверное, уже не буду. Немного упростил инсталляцию. Теперь для импорта структуры конфигурационный файл никуда не надо переписывать. Просто разворачивай архив, переписывай файлы на их законное место и делай "Импорт текстовых файлов в базу "Memories" "только структура". Завтра отлажу импорт текстовых описаний и запись их обратно (тут сильно изменилось). Потом займусь редакторами таблиц. Потом сделаю черновой просмоторщих. 14.12.2011. С.О. Еще один релиз. Добавил полноценный редактор тегов. Исправил загрузчик тегов. Добавил "аудит" - пока только сброс/установку флагов. Удобно все сбрасывать перед началом работы, а потом по фильтрам смотреть, что правил. Исправил: изменения в таблицах foto теперь работают только в пределах настроенных фильтров (раньше по всей таблице). 21.12.2011 Ханов О.А. - С.О. Времени ни на что не хватает. Попытался нарисовать алгоритм определения родственников. Писал программу года два-три назад, - все забыл, закопался и подумал, что можно отложить на потом. По причинам: - задача формальная, "творческих" усилий не требует, - решена в разных вариантах (в Интернете назойливые предложения со всех сторон), - задача достаточно автономная (добавляется опция). Но кроме вычислений там нужен редактор. Исходный файл -fambas.txt. Конечный (из которого можно рисовать "морду") я перевел в текстовую форму (раньше его не было) и сейчас отправляю (rodst.txt). Между этими файлами должен располагаться тот самый "вычислитель", который у меня есть в FOXе. Исходная информация для вычислений родственников (файл fambas.txt): - ФИО - идентификатор - список ближайших родственников (родители, дети, муж/жена, братья/сестры) с идентификаторами. Остальное раскручивается. Есть две обязательные функции, которые сопровождают редактор: - проверка непротиворечивости вводимого родственного отношения. Т.е. если А есть отец В, то В обязан быть сыном А. - автоматическое присвоение "симметричных" родственных отношений. (Например, после фиксирования записи: С = муж Д, автоматически добавляется строка: Д = жена С). Родственники, конечно, полезны. Но я бы поменял всех родственников на обработку текстов. Эта задача большая и творческая. Интересна тем, что выходит на всяческие Интернет-ресурсы, в том числе на Кайдановский. Если сравнить описания фотографий и текстов, то получится следующее: ФОТО - Название события, зафиксированного в виде изображения - Дата события - Люди (участники) - Место действия - Тэги - Источник (автор) ТЕКСТ (Можно не повторять - все то же самое, но событие фиксируется в виде текста) С текстами я работаю так. Выделяю тематический фрагмент, связанный с конкретным человеком или объектом или тегом, который записывается в отдельный файл. Все эти файлы сопровождаются таблицей описания, где кроме основного признака (ФИО/объект/тэг/дата) указываются все другие признаки ФИО/объект/тэг/дата), которыми можно снабдить фрагмент. Фрагменты для разных признаков могут перекрываться, входить один в другой. (Например, в фрагменте, посвященному человеку могут оказаться еще и описания объектов). Бывают тексты, целиком посвященные одному человеку. В таком случае фрагментом является весь текст. Что не исключает присутствие в нем разных объектов, тэгов и дат. Тексты я размечал вручную - писал (например) ФИО в начале и в конце, сопровождая его соответствующими сиволами (метками). Список меток был такой. Начало фрагмента %? - Тэг %!! - FIO %!1 - Объект %$ - Дата Конец фрагмента: %% - ФИО/объект/тэг/дата Каким здесь должен быть "нормальный" редактор - не знаю. Возможно, надо показывать два окна - одно с текстом, а другое пустое, куда копировать желаемый фрагмент и сопровождать его соответствующим дескриптом. С текстами немного проще - тэги и имена может находить программа. У человека, конечно, это получается лучше. Поэтому хорошо бы обязать автора воспользоваться редактором разметки текста. После разметки HTML-текста я запускал FOX-программу, которая выдергивала фрагменты, составляла таблицы, интегрировала все в общую базу. В итоге каждому человеку, объекту, тэгу, дате сопоставлялись соответствующие фотографии и фрагменты текстов. И все это с перекрестными ссылками. Т.е. концепция была такова, что изображение и фрагмент текста принципиально не различаются - они несут сходную информацию (иногда об одном и том же). Поэтому их описания по форме совпадают. Тексты интересны тем, что уводят в лингвистику, к которой я опять повернулся лицом. А лингвистика почему-то оказалась связанной с космологией. В общем, занятия интересные и полезные для тех, у кого среда обитания - дурдом. 15.12.2011 Ханов О.А - С.О. Общие соображения. Есть редактор фото (ты его сделал летом). Есть редактор описаний и баз данных (сейчас у тебя в работе). Есть "браузер" для просмотра базы данных (файлы HTML, которые сейчас готовит FOX). Далее могут быть два варианта изготовления нового "браузера": 1. Интерактивное общение пользователя с базой данных посредством SQL-запросов (в среде, например, PHP). Кроме стандартных запросов, хорошо бы предоставить возможность пользователю самому сформировать свой запрос. Например, задать ФИО и дату (или объект, тэг, событие и т.д.) - в любых сочетаниях и далее листать альбом по этому набору признаков, по времени вперед/назад. 2. Формируются страницы в HTML (как сейчас, но не FOXом, а PHP). Здесь просмоторщик (браузер) отделен от Базы, что делает его "застывшим", но независимым и очень мобильным. Не исключаю, что могут быть интересны оба варианта и (возможно) второй несложно сделать из первого. ___________________ По родственникам - то, что успел раскопать. 1. Исходная информация - ФИО и ближайшие родственники (родители и дети) с указанием родственных отношений. Полный список вариантов родственных отношений: - отец - мать - сын - дочь - сестра - брат - сводная сестра - сводный брат - муж - жена 2. Поиск ФИО в базе Peoples для определения индекса (если человек есть в базе) или добавление в базу Peoples нового ФИО с новым индексом. Вся информация о родственниках попадает в таблицу FAMBAS со след полями: ФИО1 m/f 1 Индекс ФИО1 ФИО2 Индекс ФИО2 m/f 2 relat = Родственное отношение ФИО2 к ФИО1 maf = Номер родственной линии 3. Проверка непротиворечивости исходных данных. При этом добавляются недописанные строки, которые следуют из введенных данных. (Например, если для ФИО1 и ФИО2 обнаружены родители с одинаковыми индексами, добавляются новые строки (если их нет) с relat = "брат" или "сестра"). 4. Следующая задача - выделить родственные линии. Для этого обнуляется вся колонка maf. Родственные линии начинаются от самых младших ее представителей, которых надо найти в списке. Поиск происходит последовательно, от отца к сыну и заканчивается мужчиной (естественно, самым молодым), у которого в списке не обнаружен сын. Если у этого последнего, самого молодого, есть все-таки дочь, то родственная линия начинается с нее. Далее эта родственная линия проводятся по мужчинам, от молодых к старшим. Всем мужчинам и женщинам, причастным к этой линии записывается одно и то же значение в поле maf. Потом другая программа вычисляет, кто кому приходится бабушкой, племянником, пра-пра.. и т.д. При этом добавляется еще одно поле "status" - число, по которому можно сортировать родственников по старшинству. Всего этого достаточно много и определяется непросто, но однозначно - согласно логике. Программу долго отлаживал, но потом уже к ней не возвращался. На всяк. случай, если все-таки ты будешь погружаться в родственников, отправляю файл FAMBAS, в который теперь вывел поле maf. При изменениях списка все номера этого поля определяются заново, т.е. могут оказаться совсем другими. Правильно ли это, сейчас не могу сказать (надо думать). Не исключаю, что родственные линии при добавлении ранее неизвестных лиц могут сильно изменяться (сливаться или разъединяться). Но это предположение, надо думать. Я не стал думать, и при любых изменениях все переобозначал. Посмотрел еще раз на отправляемый файл, - увидел, что нумерую отрезки родственных линий, которые потом (вероятно) склеиваю. В общем, непросто это. 22.12.2011. С.О. - Ханову О.А. Увидев твой файл, решил поменять концепцию. Все родственные связи раскручиваются от отца и матери. Поэтому достаточно их прописать в таблице имен. Остальное вычисляется. Данная версия требует импорта структуры. 25.12.2011 Ханов О.А. - С.О. По поводу родственников - хорошо! - только отец и мать. Я не заметил, что дети, братья и сестры легко вычисляются. Чем меньше требуется информации на входе, тем лучше. Другие (вычисленные) родственники будут полезны при опознании. АВТОМАТИЧЕСКИ при таком опознании можно отсеивать тех, кто не проходит по возрасту. Другие признаки для автомата - фамилии, имена и прочие, в том числе косвенные. Здесь тоже можно построить некоторую логику. Было бы хорошо опознавать людей без лишних вопросов. При вводе м.б. полезно добавить муж/жена, поскольку (если у них нет детей) кто-то останется за пределами клана. 26.12.2011 Ханов О.А. - С.О. В порядке "обмена опытом". Клиент вводит информацию, которая укладывается в базы (люди, фото, объекты...). Потом из этих баз извлекается вторичная информация - связи (человек и другие люди, человек и объекты, годы и люди и т.д.). Эти списки формируются уже автоматически, без клиента. Но потом я все-таки ввел списки (для событий, групповых фотографий, объектов, коллег...), которые готовит сам клиент. В списке есть: - информация о том, к чему или к кому этот список относится; - ФИО и отношение этого человека к объекту или субъекту списка (например, если коллега, то - должность, если знакомый - то "однокурсник", "сосед", "коллега"... ) - дата (отношения, или ввода информации) - источник информации ... Такие списки собраны в базе spsbas.txt. Тема была новая, еще не очень проработанная. Списки показались полезными, поскольку не для каждого человека есть "материальный след" - фотография или упоминание в тексте. ____________ Одна из интерпретаций концепции выглядит так. Интернетовские поисковики запускают то, что называется "крот". Это программа, которая методично просматривает сайты, извлекает из них полезное для ответов на запросы и погружает эту информацию в свою базу данных. Отвечая на запросы, поисковик смотрит уже не в Интернет, но только в эту базу. - Создаваемую базу я вижу как маленький Интернет с разнообразной информацией. Но база конечна, поэтому можно попытаться восстановить все существующие взаимосвязи и из этого получить информацию новую. Кроме того, здесь информация (обычно) не удаляется, но только уточняется и накапливается. "Свет далекой звезды", несущий подробный рассказ об источнике и его окружении не дает мне покоя. 27.12.2011 Ханов О.А. - Ханову С.О. По поводу псевдонимов. Вижу такие причины появления псевдонимов: а) долго (лениво) писать подробно б) не всегда вспоминается полное ФИО. Но в базе имя надо бы прописать правильно и полностью, это "документ". Псевдоним сохраняется для того, чтобы в следующий раз при вводе можно было бы писать также коротко и даже не пытаться вспомнить полное имя - программа уже поймет, о ком идет речь. Во всех вторичных выборках (т.е. всегда, кроме ввода) причин для употребления псевдонимов не нахожу - одно и тоже внутри надо бы называть одинаково. Более того, (мой) концепт в том, чтобы попытаться опознать одинаковое, названное в разных местах по-разному, и после опознания работать с этим как с одним и тем же. Т.е. псевдоним работает только в интерфейсе человек-машина. Не исключаю, что он может появится не только при вводе, но и при просмотре базы. Например, тетка Галя у меня идет под разными именами - Птицина, Ханова, Чистякова, Иванова, Воробьева, Галя, Г.А. и т.д. Как я ее назвал на каких фото, конечно, не помню. Но один раз в псевдонимах прописал все эти имена, и когда при выборе называю одно из них, хочу получить всю информацию об этом человеке. 29.12.2011. С.О - Ханову О.А. По части концепта. В первом редакторе есть понятие "альбом". Предполагалось, что описываемое фото можно сразу отнести к какой-то группе, и тем самым облегчить выборку. Однако потом мне стало ясно, что одно и тоже фото может быть прикреплено к нескольким альбомам, и сказать заранее, к каким именно - невозможно. Альбом - это надструктура, она не имеет отношение к самому фото. Альбом формируется на основе анализа фотографий. Разные люди из одинаковой базы сделают разные альбомы. Поэтому "альбом" в дальнейшем у меня превратился в "категорию фото". Категория - это какое-то единственное и абсолютное свойство фото. Это может быть: "общее фото", "семейное фото", "дубль", "фото ограниченного просмотра", "фото, исключенное из просмотра" и т.п. (надо подумать). 30.12.2011 Ханов О.А. - С.О. Получилось! Если вставить строку: 
в любой HTML на любом компьютере (подключенному к Интернету), в
соответствующем месте страницы появится одна и таже картинка (цветочки),
размещенная на сервере narod.ru. Более того, я вставил эту строку в HTML-текст
на Кайдановском litsovet.ru, и тоже увидел цветочки. Это значит, что
фотографии могут быть на одном сервере, а управление - на другом. Фотографии
могут быть в Интернете, а редактор и просмоторщик - на домашнем компьютере.
Мне кажется, это расширяет возможности. Конечно было бы хорошо, если бы
наоборот тоже работало - фотографии на домашнем компьютере, а редактор -
на сервере. Но это уже слишком хорошо, чтобы быть правдой.
----------------- "Категории фото", конечно, нужны. Категорию выбирает автор. Здесь можно пофантазировать (сразу подумал о варианте: "Перевести из категории 1 в категория 2 через 5, 10, 20... лет"). Такой вариант был бы особенно интересен для текстов, персонажи которых могут обидеться, а время смывает эмоции. 14.01.2012 Ханов О.А. - С.О. Если Денвер не требует физического перемещения фото (а я этого пока не увидел), можно поговорить о разных реализациях. У меня просьба посмотреть - нет ли принципиальных запретов на предлагаемые здесь "сценарии". 1. Локальная сеть связывает два накопителя и два компьютера. Фото располагаются во всех этих четырех местах. Денвер, база описаний и управление - на одном из компьютеров. Для редактирования и просмотра доступны все 4 источника. 2. Фото загружены на сервер, а редактор и браузер - на домашнем компьютере (делее = "РС"). Особенности такого варианта. 2.1. Архив общедоступный и неизменный. База формируется "в стороне" и никак не изменяет содержание архива. Архив систематизирован по признакам (например, по темам или событиям), в него желающие могут сбрасывать свои фото. Уровень доступа к своим фото ("Категория") устанавливает автор. Т.е. при архиве должны быть средства управления доступом (т.е. часть базы, которая обеспечивает доступ). Кроме доступа (возможно) база выполняет стандартную систематизацию по разделам и обеспечивает интерфейс с пользователем для загрузки фото. 2.2. Редакторов может быть сколько угодно - любой желающий посредством твоей программы может на своем РС сделать свой альбом. Один и тот же архив в разных местах при просмотре будет выглядеть по-разному. 2.3. Архив фотографий неподвижный, а база, управление (и, соответственно, доступ) мобильные. База описаний (без фото) не занимает много места. 3. Фото загружены на сервер, а редактор и браузер располагаются на другом сервере. 3.1. Каждый клиент на втором сервере может организовать свой фотоальбом (т.е. сделать свою базу). Все возможности п.2. сохраняются. Отличие в том, что редактирование и просмотр альбома выполняются через Интернет. 3.2. Кроме частных альбомов автоматически формируется общий альбом, в который входят фото с соответствующим значением параметра "Категория". Вся другая информация о фото берется из соответствующих частных альбомов. Общая база доступна всем, но только для просмотра. 4. /Предполагаю, что этот вариант самый интересный и "денежный"/. База (для управления, редактирования и просмотра фото) выполняется на специальном сервере или на РС (п.2 или п.3). В качестве базы фотографий используются существующие сервисы типа "В контакте", "В кругу друзей" и прочие, которые предлагают услугу "загрузить фото", и которые уже много чего накопили. Сервисов немеренно, в том числе специализированных, фотографических. Мы можем предложить систематизацию этого большого материала. Первичную систематизацию выполняют авторы (твоим редактором), а вторичную (типа п.3.2) мы сделаем сами. Не исключаю, что здесь придется контактировать с держателями сервисов. 16.01.2012. С.О - Ханову О.А. Занимаюсь редактором фотографий, зарегистрированных в базе. Наткнулся на дилемму. Сейчас в редактор выводятся данные из описания "как есть" - т.е. псевдонимы людей и объектов. Данный подход может привести к тому, что у фото, изображающего "Васю, Сашу и Александру" в описании будет 4 псевдонима - "Сосед", "Дебил", "Саша" и "Сашка", которые надо было бы исправить, да непонятно что именно и на что конкретно (на опять псевдоним или все-таки на имя?) Есть подозрение, что выводить-то надо все-таки не псевдонимы, а реальных людей. Но тут возникают вопросы: 1. Это подрывает текущую идеологию фото -- ссылка на псевдоним -- ссылка на персону. 2. Псевдоним становится настолько посередине, что поддержка через него транзитных ссылок становится ненужной - проще сразу сослаться в базу имен. 3. При переорганизации базы "фото -- прямая ссылка на персону" становится вообще непонятно, зачем нужен псевдоним и зачем его хранить? Чисто из прагматических соображений, я прихожу к выводу, что псевдоним следует оставить только для того, чтобы через него присваивать ссылки на оригинальные персоны (объекты) при импорте файлов "ручного ввода" (descript.txt) в базу. Однако при такой "оцифровке" входной информации: а) она будет неоригинальной (не авторской) б) база и текстовые файлы описаний будут расходиться сразу, уже на момент занесения информации в базу. в) обратный экспорт базы в текстовые файлы 100% изменит их содержимое даже в том случае, если по существу ничего не изменилось. И еще. При организации фото-персона (без псевдонима), как пополнять базу псевдонимов? Сейчас организовано так, что любые входные данные попадают в таблицу псевдонимов. Если псевдоним есть, на него делается ссылка, если нет - псевдоним добавляется, и на него делается ссылка. Это логично. Потом на досуге можно привязать добавленные псевдонимы к персонам или сделать для них новые персоны. Данная схема работать не будет. Можно пополнить базу псевдонимов, но на них не сослаться, поскольку требуется ссылка на персону, а на персону не указать, поскольку она может быть еще не привязана к псевдониму. В общем, я в каком-то тупике. Можно найти компромиссное решение - в базу привязок фото к персонам добавить еще поле привязки к псевдониму. Если есть персона, псевдоним =0, если персоны нет, использовать ссылку на псевдоним. Как только у псевдонима появится привязка к персоне - в фото прописывать привязку к персоне и удалять ссылку на псевдоним. Однако это како-то сложно и сильно химично 16.01.2012. Ханов О.А. - С.О. Я вижу две автономные задачи - индивидуальный альбом и система индивидуальных альбомов (альбом общий). Сейчас идет работа по созданию альбома индивидуального. Общий альбом в этой работе может напоминать о себе только тем, что в признаке "категория фото" одно из его значений будет - "доступно всем". Все остальное не имеет (и не должно иметь) большого значения. Объективное основание для этого такое. Готовя свой альбом, я не должен думать о том, кто и как делает то же самое. Потом, просматривая чужие фото, я могу написать к ним свои комментарии, которые попадут в другую, уже общую базу под моим именем наряду с комментариями других. В этой общей базе опять надо будет устанавливать соответствия имен, которые до этого акта будут считаться псевдонимами. Но при таком концепте в индивидуальном альбоме автор не становится "центральной фигурой", он исчезает. Все, что есть в этом альбоме, ему принадлежит. Но это значит, что привязки отдельных элементов к автору не нужны - само их присутствие здесь является такой привязкой. Автор появляется в "общем альбоме", где он уже не один. Но это другая задача, со своими особенностями. _______ По поводу псевдонимов. У меня не было id_псевдонима, я присваивал им id основного (объекта, человека), которые появлялись после опознания. У разных псевдонимов бывали одинаковые id. В предыдущем письме я предлагал неопознанный псевдоним считать самостоятельным объектом/человеком со своим id, который после опознания заменяется на id, существовавший в базе. Пока его не опознали, он остается уникальным человеком, и таковым может остаться, если он впервые попал в эту базу и пребывает в ней только на одном фото. При такой организации в базу людей может попасть явный псевдоним и остаться там навсегда - если кроме "Петька-из-дома-напротив" никакой другой информации о нем не появится. Потом, в общем альбоме его кто-то может опознать и у него появится имя (с примечанием - по версии опознавшего NN). Но это уже "другая история". Там тоже будет вопрос - что считать достоверным - имя по версии А или имя по версии В, если они различаются. Признавать псевдонимы людьми (т.е. сразу давать человеческий ID) полезно в том смысле, что даже без опознания он участвует во всех выборках как равноправный гражданин. А для некоторых опознание и не потребуется. 17.01.2012. С.О. - Ханову О.А. Дополнение, которое вчера забыл отправить: "Псевдоним должен быть привязан к автору описания. Разные авторы могут использовать разные псевдонимы (например - "мама", "папа", "я", "дядя Вова")." Также автор должен быть и у альбомов. У меня получилась такая схема (на примере объектов): 1. В базе привязок объектов к фото добавлено 2 поля - id_объекта и id_псевдонима. 2. При обработке текстовых описаний, извлеченный "объект" ищется в базе объектов Objects, и, если находится, ссылка на него прописывается в базе foto_objects в поле id_объекта. 3. Если объект не найден, его имя заносится в базу псевдонимов Sinobject вместе с id автора описания, а в базу foto_objects пишется ссылка на id_псевдонима. 4. Привязка псевдонима объекта к самому объекту производится вручную. При этом разные авторы имеют непересекающуюся выборку базы псевдонимов (одна и та же вещь может называться ими по разному). Это кажется занудливым мероприятием, но с другой стороны, пока объект не имеет официального названия, он не должен быть доступен для поиска и показа. 5. Найденные авторы складываются в отдельную базу. 6. Данная схема применяется к объектам и людям на фото. Думаю в сторону того, чтобы и работу с тегами сделать через псевдонимы. Во-первых, будет в одном стиле, во-вторых, это не позволит перемешать при оцифровке теги типа "дача", "дом" и т.п. Собственно, центральной фигурой при таком подходе становится автор. Центральной настолько, что уже же начинает казаться, что и текстовое описание одних и тех же фото должно уметь разделяться на авторов. К примеру, Ирка может описать фотографии одним способом, а я - другим. Пока не понимаю, нужно ли это делать. 17.01.2012 Ханов О.А - С.О. Только что прочитал, и согласился со всеми позициями (потом еще прочитаю внимательнее). Как я представляю, - все, что делается сейчас, - это альбом одного автора. У другого автора может быть все другое. Объединить разные альбомы в одну кучу - отдельная задача, которая может что-то заимствовать из индивидуальных альбомов, но что-то будет и совершенно специфическое. Все это еще требует большой проработки и обсуждения на уровне концепции. ________ На вопрос "зачем нужен псевдоним и зачем его хранить?", я бы ответил - только для ввода. Заставить (даже самого себя) что-то вводить - самое трудное в этих занятиях. И при вводе не хочется отвлекаться и вспоминать или искать - как надо правильно записать человека. Как знаю, помню - так и пишу. Отсюда вылезают псевдонимы. Другое место, где они появляются - при просмотре альбома. Иногда нет возможности вводить (или искать в списке) правильное полное имя. Привязав один раз Мотю к Матвею Сергеевичу можно забыть о разночтениях навсегда, вызывать и выводить - то так, то иначе, а результат всегда будет одинаковый. Т.е. псевдонимы нужны для интерфейса, и только для интерфейса. В базе после привязки псевдонима возникает однозначное соответствие, скрепленное (например) идентификатором - одним для разных написаний имени одного человека. Главным станет идентификатор, а имена - дело второстепенное, могут быть любыми. Работу с базой представляю так. Поиск. Главное - идентификатор. Из набора псевдонимов и имен предлагается выбрать нужное. Затем программа читает идентификатор выбранного имени и находит все фото, в которых есть такой идентификатор. Для однообразия работы, еще не привязанным именам можно дать специфический временный идентификатор, который заменяется постоянным после привязки. Как вариант, идентификаторы базы людей (peoples) и идентификаторы имен базы фото (foto_peoples) могут быть разные, но тогда нужна дополнительная база, где будет прописано соответствие идентификаторов двух разных баз (id.peoples - id.foto_peoples), которая пополняется при "опознании". Такой вариант кажется неуклюжим, но впоследствии его аналог будет все-таки востребован, когда потребуется соединить разные альбомы. Там два Иванова Ивана Ивановича могут оказаться разными людьми. Им придется присвоить разные идентификаторы в "верхней базе", не затрагивая идентификаторы разных альбомов (в частные альбомы вторгаться нехорошо). Вижу (минимум) два разных альбома - твой и мой, на которых можно все обкатать. Возможны еще два источника расхождения идентификаторов одного и того же человека - тексты и родственники. Они могут формироваться независимо от фотоальбома, жить "самостоятельно", а потом быть интегрированы. Редактор. Ты его описал достаточно. ("Если псевдоним есть, на него делается ссылка, если нет..."). Пусть до привязки в базе peoples будет столько людей, сколько есть оригинальных (неопознанных) псевдонимов. После опознания они будут потихоньку исчезать. ______ Т.о. при вводе/просмотре всегда сначала определяются идентификаторы выбранного, из которых формируется основной запрос. Работа с базой получается по схеме: тексты для выбора - выбор - определение идентификаторов выбранного - запрос к базе. Не владея в достаточной мере SQL, я не знаю, насколько реальна такая схема с "двухступенчатым запросом", вторая часть которого формируется после исполнения первой части. Вообще, я не совсем уверен, что понимаю все нюансы проблемы. 18.01.2012. С.О. - Ханову О.А. По 1 части: У меня не получается увидеть индивидуальный альбом. Я затыкаюсь в самом начале процесса - в создании описаний. К примеру, я вывалил содержимое камеры в файлы на компьютере. Пришла Ирка, описала фото, используя свой словарный запас, собрала какие-то альбомы, используя свое описание. Потом пришел я и тоже решил сделать пару альбомов, и вдруг неожиданно оказалось, что плохие фото с т.з. Ирки с моей т.з. выглядят нормальными и наоборот. Что к фотографиям привязаны не те теги, которые мне бы хотелось использовать и т.п. Надо переписать какую-то часть описаний, но если я это сделаю, то наврежу Иркиной систематизации. Сейчас задача не решается. Автор описания - один, соответственно и все множества имен, объектов, тегов и т.п. - одни. Необходимо дать возможность описать одну фотографию разными способами. А из этого следует, что для одно фото авторов должно быть не менее 3-х: 1. автор собственно фото (кто держал камеру) 2. автор описания (их может быть несколько) 3. Некто, смотрящий на фото - потенциальный автор описания.Пока не думал, как работать дальше с таким количеством. По 2-й части: С моей точки зрения, id псевдонима действует в пределах автора описания. Итогом обработки все равно должна стать некая конечная персона (fio) - может быть пролезший псевдоним. При объединении альбомов все равно эти персоны превратятся в какое-то подобие псевдонимов, поскольку точность их описания субъективна. Для формирования общей базы каждая персона должна пройти ценз хотя бы для того, чтобы исключить появление в базе 2-х одинаковых персон, описанных немного по разному. 19.01.2012 Ханов О.А. - Ханову С.О. Если делать отдельные базы - фото и их описания, то ситуация должна бы успокоиться - описания изначально разные, альбомы разные и только картинки могут совпадать. Не знаю, насколько допускает это PHP - кажется, есть у него тенденция делать все в одном. Получится большое безобразие, если в каждом описании обязательно должна находиться и сама картинка. Хотелось бы ограничиться только ссылкой, не допуская размножения изображений. Альбомы должны быть разные - мы все видим по-разному. Димины описания одних и тех же сюжетов будут отличаться от твоих, а твои от моих или маминых. Соединиться они могут только в общем альбоме, если не будет на то возражений авторов. Не исключаю, что общие альбомы будут разных уровней - семейный, корпоративный и проч. Т.е. "поверх" одних описаний (не "наряду") могут появиться другие. Описание и фото требуют разделения и для формирования общих альбомов, где хотелось бы оставить только ссылки - на фото и на их разные описания. 09.02.2012 Ханов О.А. - С.О. При задании фильтра просится еще одна кнопка - "начать сначала", которая сбрасывает все предыдущие записи данного фильтра. Иначе надо: а) нажать "минус" и пройтись по всем позициям или б)-сбросить все и набирать заново то, что следует оставить. - Много манипуляций для популярной операции. _______ При работе с чужими ресурсами "названия каталогов и файлов", к сожалению, нужны. Для этого придется (если дойдет "до дела") "контактировать с держателями сервисов". Но здесь нужна от них только информация, а "влезать в системы" совсем не обязательно - нужен только адрес картинки, чтобы ее увидеть. На каждом сервисе, конечно, своя система каталогов и названий. Если нам ее предоставят, то мы передадим необходимую информацию "своим" клиентам, и этого достаточно. Пусть фото остаются там, где они есть сейчас, но описания будут у нас, и у нас будет база всех описаний. (Описания делаем не мы, - сами клиенты). Поверх этой базы можно расположить свой "поисковик-просмоторщик", уже не очень зависимый от клиентов (с учетом "категории фото"). По этой причине делать "систематизатор" в самом "вконтакте" не совсем правильно, да и слишком приближаться к ним не очень хочется. Даже если у них что-то подобное есть, то можно предположить, что это редактор, не база. А если база, то вероятно - в переделах этого ресурса. А хотелось бы "парить высоко над всеми", и всех собирать в единую кучу. Не исключаю, что есть элементы такой системы (например) у YANDEX. Но там все широко, и это - один из сервисов. Мы же можем заявить о специализированном ресурсе. Как вариант (если позволяет такое PHP), по известному адресу снимков можно копировать и сами изображения в нашу базу фото (естественно, автоматически). Адреса снимков мы можем выдернуть из клиентских описаний, хранящихся у нас. Это не обязательно, но так было бы лучше, стабильнее. Кстати, ты показывал на YANDEX мои фото - одно из MAIL.RU, а другое - из PROZA.RU. Это значит, что все, о чем я сейчас вещаю - реально, технических (и юридических) запретов нет. В начало |