§1. КОНСИЛИУМ

 Новая тема  |  Наверх  |  Перейти к теме  |  Искать  |  Вход   Следующая тема  |  Предыдущая тема 
 Обсуждение идеи Базы Данных
Автор: С.Нечаев (---.uninet.ee)
Дата:   29-05-04 14:59

Независимо от масштаба любого исторического изыскания, рано или поздно исследователь сталкивается с необходимостью построения цепочек последовательных событий. База знаний, которой он пользуется при этом, всегда имеет ограниченный объем. Но даже при наличии большого объема данных, они не всегда пригодны для получения репрезентативных выборок, так как недостаточно или хаотично структурированы.
С другой стороны, попытки создания любительских баз данных, посвященных исторической тематике, предпринимались много раз, в том числе были и удачные. Однако объем таких баз всегда ограничивается возможностями ввода информации, в первую очередь, и ограниченностью доступа к источникам во-вторую. Базы данных профессиональные, создаваемые различными научными организациями, как правило закрыты для свободного доступа, поэтому их приспособленность для хронологического анализа оценить трудно. Это конечно не означает, что они непригодны для использования, просто нам, «любителям» истории, до них не так просто добраться.

Поэтому родилась идея создать общедоступную базу данных, которая может оказаться хорошим подспорьем для цивилизационных и исторических исследований, независимо от традиционной или альтернативной ориентации исследователей.
Такая база данных должна содержать сведения о представляющих интерес событиях, их версиях и датировках, а также ряд других полезных аттрибутов. Концептуальная модель данных описана в подветке, здесь же хотелось бы остановиться на сценариях работы такой БД. Все сценарии предполагают работу через интернет.

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

Сценарий ввода информации.
После регистрации и входа в систему вы получаете форму ввода информации. Можно завести как новое событие, так и добавить версию к существующему в базе. Можно добавить связь между событиями, и т.д. После ввода информация посылается в БД, где окажется общедоступгной после авторизации записи «экспертом».
Авторизация мне кажется необходима для того, чтобы БД не засорялась графоманами или вредителями, а скорее всего для того, чтобы не перегружать базу одинаковыми по сущемству сообщениями.

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

Естественно, в ходе проектирования реального портала сценарии могут дополниться какими-то дополнительными действиями и возможностями, но укрупненно это все.
Критика, мнения, и предложения приветствуются.

еще не спето столько песен ...

 
 Концептуальная модель ДБ
Автор: С.Нечаев (---.uninet.ee)
Дата:   29-05-04 15:02

Модель БД.
Концептуальная модель БД приведена в упрощенном (текстовом) виде для облегчения обсуждения и возможности примеров. К примерам прошу относиться именно как к примерам - они все вымышлены.

Основная сущность базы данных – событие.
Примеры событий:
ID_события event
240 Тридентский собор
241 Появление "Книги пап"
242 Изготовление и продажа древних рукописей как бизнес
243 Открытие летописи Саксона Грамматика
Название события может быть и более развернутым, однако не лдолжно содержать датировок и «канвы», то есть не должно содержать оценок.

Аттрибуты события:
Тип события. Это справочник, позволяющий структурировать события по группам.
Пример справочника типы события:
id_datatype data_type
1 цивилизационное
2 историческое
3 историографическое
4 социальное
5 лингвистическое
6 технологическое
7 научное
8 не определено
Географический регион. Справочник, отражающий регионы, как современные, так и исторические (Левант, Месопотамия и т.п.)
Пример справочника регионов
Country_ID название_региона
1 Не определен
2 Англия
3 Юго-Восточная Европа
4 Европа
5 Латинский Рим
6 Африка
7 Греция
8 Левант
9 Египет
10 Всемирный
11 Западная Европа
Служебный атрибут – автор записи.
Связанное событие – внутрення ссылка БД на другое событие, связанное с текущим.

Сущность Версия события.
Состоит из датировки, ее обоснования,описания версии, ссылок на источники и иллюстрации, оценки достоверности.
Аттрибут датировка. Вносится только год от РХ, при этом даты до нашей эры вносятся как отрицательные. Может быть связан с сущностью Период.
Допуск плюс, допуск минус – аттрибуты, характеризующие точность датировки в годах.
Обоснование датировки – тектовое описание обоснования.
Описание версии – более подробное описание события, может включать в себя и авторские оценки версии.
Источник – ссылка на источник. Пополняемый справочник.Обязательный параметр.
Ссылка – интернет ссылка на подробное описание версии.
Оценка достоверности – величина от 0 до 1, выражающая вероятность того, что текущая версия и является наиболее адекватой интерпретацией события. Субъективный параметр, однако необходимый для хоть какой-то ранжировки множества версий. Способ оценки - это наиболее спорный вопрос всей концепции. Однозначного ответа нет, проект – при внесении любой новой версии ей присваивается значений 0.5. Дальше, исходя из неивестного на сегодня критерия, оценки меняются.
Тип датировки – если датировка предложена ТИ, то ТИ, если нет – пусто. Аттрибут для справки.
Иллюстрации – графический файл с иллюстрацией.

Сущность период.
Состоит из названия, комментария, начала и конца периода, ссылки на источник.
Начало и окончание периода ввносятся как годы.
Эта сущность может играть роль вспомогательного аттрибута при поиске по датам (например, период Среднего Царства) или для обозначения растянутых по времени событий, имеющих общую связь – например 30-летняя война - тогда периодом можно объединить множество событий.

Пример события и связанных с ним версий:

ID_события event
295 Постройка большого египетского сфинкса в Гизе

год: D + D - P обоснование Описание Источник Тип
1500 100 -300 0.5 рассуждения о христианских символах Построена по технологии обкладывания естественной скалы бетоном и камнем. Носовский, Фоменко
-3500 500 500 0.4 По совпадению эпох постройки пирамид и сфинкса Построена древними по неизвестной технологии для возвеличивания божества Источник 1 ТИ
-7000 1000 1000 0.1 по наличию следов затопления Построена неизвестными пришельцами до некоего потопа, поднявшнго уровень воды на десятки метров. Источник 2 ТИ

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

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

еще не спето столько песен ...

 
 Re: knowledge tree
Автор: вечный жид (---.cpe.net.cable.rogers.com)
Дата:   29-05-04 15:39

идея неплохая и давно "в воздухе".
Но я бы отталкивался не от "желаемого содержания", а от существующего формата.
Есть форум - главая площадка ПЦ, а реальный формат.
Также как есть дерево ответов, надо завести дерево знания.
Самые интересные ветки форума вешать на это дерево модератору по темам, источникам, регионам, КСТАТИ НЕ ТОЛЬКО ЗА НХ, НО И ПРОТИВ.
Да еще и улучшить поиск.
Так информация будет концентрироваться по значимости и самонакапливаться.
И кого больше веток на "дереве", тому можно считать более высокий рейтинг автоматом.
А публикуемый рейтинг (рядом с кличкой) подстигнет активность и остановит смену кличек.

Я бы завел еще функциональность голосования. Если модераторы сами не могут понять , что "водяной обезьяне" не место на сайте, им надо подсказывать.

 
 Одно другому не мешает, а помогает
Автор: Сергей Нечаев (---.uninet.ee)
Дата:   29-05-04 16:01

Событийная БД никак и не подменяет базу знаний. Ее смысл в том, что информация структурирована, а потому легко обрабатываема и и обощаема. А в записях такой БД никто не мешает хранить ссылки дерево знаний. Я например часто использую ссыдки именно на ветки этого форума.
Что касается голосования, то тут я за. Рейтинг может подстегивать.
Однако определение достоверности версии голосованием - это конечно нет. Тут большинство не критерий.
Так что и дерево знаний необходимо, и структурироваенная БД тоже. Как их совместить, точнее связать - давайте обсуждать.

 
 Re: Одно другому не мешает, а помогает
Автор: вечный жид (---.cpe.net.cable.rogers.com)
Дата:   29-05-04 18:56

самое главное - опирайтесь на производственные реалии :

- есть пару программистов на php + mySQL
- нет финансирования и не будет

 
 Re: Концептуальная модель ДБ
Автор: Консерватор (---.kcsystema.ru)
Дата:   31-05-04 12:51

Уважаемый С.Нечаев!
А почему основной сущностью БД Вы выбрали событие?
Мне думается, основной сущностью (точнее, неким суперклассом) должен быть все же источник. Классами источников могут быть письменные источники, легенды, здания и сооружения, предметы и пр. Между экземплярами классов могут существовать самые разные отношения, формализуемые, например, с помощью UML. Об атрибутике классов можно договориться позже, в процессе накопления данных.
В этом случае реконструируемое событие (гипотеза, вариант) будет производным от имеющихся источников, что мне представляется более логичным.
С уважением,
К.

 
 Re: Концептуальная модель ДБ
Автор: Edgeways (194.186.114.---)
Дата:   31-05-04 13:34

Есть нюанс.
Описание источников тоже имеет практически все аттрибуты описания события: датировка, обоснование, источник сведений и т.д.
Можно даж воспользоваться формулировкой про то, что разделение описаний событий и описаний источников -- ложная дихотомия. ;))



Сообщение отредактировано (31-мая-04 13:39)

 
 Re: Одно другому не мешает, а помогает
Автор: Edgeways (194.186.114.---)
Дата:   31-05-04 13:41

> есть пару программистов на php + mySQL

Уже есть ? Или это фигура речи ?

Просто одно дело, если уже можно общаться на уровне разработки интерфейсов и структур данных, и другое, если сначала придётся таки выкраивать время на экcперименты с alter table.



Сообщение отредактировано (31-мая-04 17:04)

 
 Re: Концептуальная модель ДБ
Автор: Консерватор (---.kcsystema.ru)
Дата:   31-05-04 14:42

Уважаемый Еджвэйс!
Позвольте с Вами не согласиться. Опираясь на источники, мы остаемся в рамках реальности, и, с той или иной степенью вероятности, можем реконструировать событие. Если же мы исходим из события, то находимся в области гипотез и предположений (без источников мы ничего не можем сказать о том, имело место данное событие или нет). В последнем случае подбор источников будет весьма тенденциозным.
С уважением,
К.

 
 Re: Концептуальная модель ДБ
Автор: Edgeways (194.186.114.---)
Дата:   31-05-04 15:03

Не вижу принципиального различия, уважаемый Консерватор.
Если выстроена логическая цепочка логических атомов, при том, что стартовой точкой выбрано описание источника, от которого есть связи к описываемым в нём логическим атомам, то связную обработку оных атомов возможно представить довольно непротиворечиво.

 
 Re: Концептуальная модель ДБ
Автор: Консерватор (---.kcsystema.ru)
Дата:   31-05-04 15:26

Уважаемый Еджвэйс!
Принципиальное различие в том, что, в отличие от событий, источники реально существуют и их можно достаточно единообразно описать (имеется в виду выделение общих атрибутов).
Я не очень понимаю, что Вы имеете в виду под термином «логический этом». Если это историческое событие, а логическая цепочка – последовательность событий, логически вытекающих одно из другого, то наличие базы источников может служить мощным средством верификации любого звена построенной цепочки и, следовательно, предлагаемой исторической реконструкции.
С уважением,
К.

 
 Re: Концептуальная модель ДБ
Автор: Edgeways (---.dialup.primorye.ru)
Дата:   31-05-04 17:00

Уважаемый Консерватор,
С точки зрения реализации логических связей между сущностями -- не существенна реальность существования источников. Для интерпретации -- да. Для реализации БД -- нет.

Если Вам не трудно, приведите, пожалуйста, пример единообразного описания нескольких источников, "имеется в виду выделение общих атрибутов". Собственно, именно на приводимых примерах можно выяснить, что же чем является, и чем представляется.

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

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



Сообщение отредактировано (31-мая-04 17:17)

 
 Re: мысли
Автор: d-te (---.motorola.com)
Дата:   31-05-04 18:03



С продвинутыми тулами забыли уже что БД бывают сетевыми, иерархическими и табличными(реляционными). Иерархия не может полностью отразить взаимосвязи реального мира - реальный мир сложнее. Сетевая может отразить, грубо говоря это и-нет, большая помойка, где для того чтобы найти нужное необходимо перебрать горы мусора( к счастью есть поисковики ).
Табличная (это где SQL) наиболее употребима.
Там нет термина "логический атом". Есть аттрибут. Есть экземпляр аттрибута. И есть ключевой аттрибут. Практика показывает, что не понимая что есть ключевой аттрибут в схеме отношений, ни каким тулом делу не поможешь. Даже супер-пупер УМЛ-ем. Я не говорю что база данных обязательно должна быть в 3й нормальной форме или там в БНФ. Говорится про то что изначальный бардак является однозначным противопоказанием для достижения успеха.

Событие не может быть ключом хотя очень хочется.

Между прочим источник тоже не может быть им, это может быть копия источника ( несколько ключевых атрибутов - отражающих предисторию источника). Но и тогда дело не сдвинется, imho.

Формально аттрибутировать событие можно.
Но только существующее. Например затмение это ключ ( аттрибутируется полной датой и географией ) и к нему можно привязать все подходящие описания выуженные из источников. Далее эти связи поддаются анализу ( например на противоречивость: описание в источнике не может описывать два затмения )

Но как только заводим два фантомное события являющееся отражением одного - все -появились записи-дубликаты в БД со всеми вытекающими (будет новая ТИ с теми же проблемами).

Вобщем помозговать надо, спецов настоящих поспрашать(аналитиков а не программеров).

 
 Re: мысли
Автор: Foster (195.170.203.---)
Дата:   31-05-04 18:29

d-te Написал:
> Формально аттрибутировать событие можно.
> Но только существующее. Например затмение это ключ (
> аттрибутируется полной датой и географией ) и к нему можно
> привязать все подходящие описания выуженные из источников.
> Далее эти связи поддаются анализу ( например на
> противоречивость: описание в источнике не может описывать два
> затмения )

Может, ИМХО.

> Но как только заводим два фантомное события являющееся
> отражением одного - все -появились записи-дубликаты в БД со
> всеми вытекающими (будет новая ТИ с теми же проблемами).

Некорректно. Я-то по наивности думаю, что установление фантомности является целью, а Вы помещаете его в предпосылки. Вот укажите два события, а потом, доказав их фантомность, свяжите их соответствующим отношением.

Вообще, странно, сначала сведя модель всей истории к одному "ключу" сетовать на невозможность адекватного ее отражения. :)

В принципе, схема может быть приблизительно такая:

- источники, как классы экземпляров
- экземпляры источников - объекты класса источников
- классы событий
- события, как объекты, атрибутирующие источники (или экземпляры(?))
- атрибуты источников
- атрибуты экземпляров
- атрибуты событий
- история источников(?)
- история экземпляров
- отношения источников
- отношения событий

Хотя способа формализовать атрибуты источников так, что бы можно было оценивать их (содержания) взаимную временную и пространственную локализацию (а без этого трудно сопоставлять описываемые ими события), я не вижу. :(

 
 Re: мысли
Автор: d-te (---.motorola.com)
Дата:   31-05-04 20:19

Foster Написал:

> d-te Написал:
> > Формально аттрибутировать событие можно.
> > Но только существующее. Например затмение это ключ (
> > аттрибутируется полной датой и географией ) и к нему можно
> > привязать все подходящие описания выуженные из источников.
> > Далее эти связи поддаются анализу ( например на
> > противоречивость: описание в источнике не может описывать два
> > затмения )
>
> Может, ИМХО.

Наложение?
Ну я бы в модели это запретил, тоже имхо.

>
> > Но как только заводим два фантомное события являющееся
> > отражением одного - все -появились записи-дубликаты в БД со
> > всеми вытекающими (будет новая ТИ с теми же проблемами).
>
> Некорректно. Я-то по наивности думаю, что установление
> фантомности является целью, а Вы помещаете его в предпосылки.
> Вот укажите два события, а потом, доказав их
> фантомность, свяжите их соответствующим отношением.

Доказывать будете руками и элиминировать дубликаты тоже. А в идеале система должна расставить дубликатные связи(возможные).

Вводя фантомное событие Вы априорно уже приняли решение об этом событии. Это опять ТИ и в этом проблема. Нет ну можно смягчить заведя аттрибут условности - но тогда ТИ-шников к базе подпускать нельзя - везде будет 100% :-)

>
> Вообще, странно, сначала сведя модель всей истории к одному
> "ключу" сетовать на невозможность адекватного ее отражения. :)

Хотя бы к одному!.
А то даже одного не видно.

> В принципе, схема может быть приблизительно такая:
опять юэмель он же для моделей0прототипов - ключ, ключ надо :-)
иначе бардак0хаос.

> - источники, как классы экземпляров
классообразующий признак?
источник меняется во времени(издания) и пространстве(языки).
Думаю что работать нужно с копией источника.
И это не экземпляр - просто доступная копия издание перевод, например.
Еще источники наследуют друг друга и мы не знаем какая редакция первична...

> - экземпляры источников - объекты класса источников
> - классы событий
> - события, как объекты, атрибутирующие источники (или
> экземпляры(?))

> - атрибуты источников
> - атрибуты экземпляров
> - атрибуты событий
> - история источников(?)
> - история экземпляров
> - отношения источников
> - отношения событий
>
> Хотя способа формализовать атрибуты источников так, что бы
> можно было оценивать их (содержания) взаимную временную и
> пространственную локализацию (а без этого трудно сопоставлять
> описываемые ими события), я не вижу. :(

Формализовывать надо события, наверно.
А источники вбивать как есть.

 
 Re: мысли
Автор: Edgeways (194.186.114.---)
Дата:   01-06-04 03:57

Всё именно так. С одним уточнением от К.Пруткова, про флюс. Привязка (привычка) к технологически-ориентированному образу мысли отягощает.

Давайте разберём вот что, без ТНФов и УМЛей, без дефинизмов, на пальцах, голой логикой, объекты предметной области.
Навскидку:
- что такое событие,
- что такое источник,
- что такое упоминание события в источнике,
- что такое цитирование источника в другом источнике,
- что такое перевод источника с одного языка на другой,
- что такое датировка события,
- что такое датировка источника,
- что такое датировка цитирования/перевода источника.
Сколько сущностей на самом деле перечислено ? Сколько сущностей не перечислено ? Каких ?

 
 Re: Концептуальная модель ДБ
Автор: Консерватор (---.kcsystema.ru)
Дата:   01-06-04 09:08

Уважаемый Еджвэйс!
Все исторические источники для начала можно разделить на два больших класса: материальные и нематериальные. Для определенности остановимся на материальных источниках. Их, в свою очередь, можно разбить на две группы: письменные и прочие. Впоследствии класс прочих источников может быть подвержен дальнейшей детализации. Каждый материальный источник был когда-то обнаружен, поэтому некоторая группа его атрибутов должна нести информацию о «характеристиках обнаружения» (прошу прощения за подобный радиолокационный термин) – предполагаемая или точная дата обнаружения, пространственно-географическая локализация, лицо или организация, обнаружившая источник и пр. Кроме того, материальный источник имеет какой-то носитель – материал или набор материалов, использованных для его изготовления. Следующая группа атрибутов относится к технологии изготовления источника и его назначению. Перечисленные атрибуты относятся к описательной характеристике источника. В состав содержательной характеристики я бы включил следующие атрибуты: упоминаемые исторические персонажи, упоминаемые исторические события, упоминаемую датировку исторических событий и их географическую локализацию, а также упоминаемые источники. За исключением названия источника все остальные атрибуты представляют собой ссылки на соответствующие справочники. Помимо связи с источниками справочники должны иметь связи между собой. Таким образом можно отобразить, к примеру, участие того или иного исторического персонажа в том или ином историческом событии. Такую связь удобно реализовать с помощью кросс-таблицы, каждая запись которой содержит ссылки на пару справочников и источник, подтверждающий наличие связи.
По-моему, получается достаточно целостная и непротиворечивая структура.
С уважением,
К.

 
 Re: мысли
Автор: Консерватор (---.kcsystema.ru)
Дата:   01-06-04 10:06

Уважаемый Еджвэйс!
Попробую навскидку ответить на Ваши вопросы.
Событие - то, что произошло, то или иное значительное явление, факт общественной, личной жизни (Ожегов). Примеры: рождение, смерть, битва, съезд и т.д.
Источник – любой материальный или нематериальный объект, несущий информацию о событии;
Упоминание события в источнике – возможность извлечения из источника информации о событии;
Цитирование источника в другом источнике - возможность извлечения из источника информации о другом источнике;
Перевод источника с одного языка на другой – примерно то же, что и цитирование, но менее строгое;
Датировка события – временной период, в течение которого происходит событие согласно указанию источника;
Датировка источника – временной период в течение которого источник мог быть изготовлен;
Датировка цитирования/перевода источника - временной период в течение которого мог быть изготовлен источник с цитатой/переводом;
Таким образом, перечислены следующие сущности: событие, источник, временной период.
Из важных сущностей не указаны исторический персонаж и географическая локализация (место происхождения события, место обнаружения или нахождения источника). Возможно, нелишними будут и такие сущности как материал источника, технология изготовления, этническая принадлежность (язык), Кроме того, неполно и неявно указаны связи между сущностями.
С уважением,
К.

 
 Re: Концептуальная модель ДБ
Автор: Edgeways (194.186.114.---)
Дата:   01-06-04 10:40

A. Все исторические источники для начала можно разделить на два больших класса: материальные и нематериальные. Для определенности остановимся на материальных источниках.

Ок. Описание нематериальных источников не трогаем.


B. Их, в свою очередь, можно разбить на две группы: письменные и прочие. Впоследствии класс прочих источников может быть подвержен дальнейшей детализации.

Т.е. (пока) рассматриваем письменные.


D. Каждый материальный источник был когда-то обнаружен, поэтому некоторая группа его атрибутов должна нести информацию о «характеристиках обнаружения» (прошу прощения за подобный радиолокационный термин) – предполагаемая или точная дата обнаружения, пространственно-географическая локализация, лицо или организация, обнаружившая источник и пр.

Обнаружен, а не написан. Т.е. для письменных источников это именно дата обнаружения, введения в оборот. Так ?

Дата -- это вопрос интересный. "Стандарт" от РХ или, так сказать, исходная дата, с возможностью эры диоклетиана, сотворения мира, первой республики и т.д.


E. Кроме того, материальный источник имеет какой-то носитель – материал или набор материалов, использованных для его изготовления. Следующая группа атрибутов относится к технологии изготовления источника и его назначению.

Для письменных источников это набор типа "доска", "бумага", "береста", "папирус", "пергамент", "камень", "бетон", "глина" (...) ?


F. Перечисленные атрибуты относятся к описательной характеристике источника.


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

1. Мне видится так, что перекрёстные ссылки с упоминаемыми сущностями несколько уравнивают роли всех "упоминаемых": смысл подобных связей в том, чтоб иметь возможность
- по данному источнику найти всех упоминаемых,
- по упоминаемому -- персонажу, событию или другому источнику -- найти все упоминания о них в источниках.
Так ? (Можно предложить это в качестве одной из промежуточных задач, которые формируют требования к системе.)

2. Упоминание другого источника в качестве... (экое масло..) ..."поставщика" (Во! ;)) данных устанавливает зависимость от него. Вполне вероятно, что нас это (пока) не интересует.

3. Т.о. логически источник является неким "контейнером", содержащим ссылки на другие источники (0 или более), персонажей (0 или более), события (соответственно..).

4. Географическая локализация -- это свойство упоминаемых событий, наряду с датой (учитывая комментарий про дату в пункте D.).


H. Помимо связи с источниками справочники должны иметь связи между собой. Таким образом можно отобразить, к примеру, участие того или иного исторического персонажа в том или ином историческом событии. Такую связь удобно реализовать с помощью кросс-таблицы, каждая запись которой содержит ссылки на пару справочников и источник, подтверждающий наличие связи.

Про таблицу я пока не берусь судить. А вот задачу "участия персонажа" -- это прошу развернуть на примере.


Вопрос сбоку. "Упоминаемые события" это сущность того же порядка, что и "обнаружение источника" или не стоит притягивать одно к другому ?

 
 Re: Концептуальная модель ДБ
Автор: Консерватор (---.kcsystema.ru)
Дата:   01-06-04 12:28

Edgeways Написал:

> Обнаружен, а не написан. Т.е. для письменных источников это
> именно дата обнаружения, введения в оборот. Так ?

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

> Дата -- это вопрос интересный. "Стандарт" от РХ или, так
> сказать, исходная дата, с возможностью эры диоклетиана,
> сотворения мира, первой республики и т.д.

Момент действительно интересный. Предлагаю следующее решение. Если дата указана в источнике, то в БД она должна храниться в таком же виде, как и в источнике. Таким образом, мы приходим к необходимости формирования «справочника первичных дат». Параллельно необходимо иметь современную хронологическую шкалу, также оформленную в виде справочника. Поскольку у сторонников «Новой хронологии» имеются большие претензии к правилам соответствия датировок в разных системах, указанное соответствие можно реализовать путем введения связи между справочником первичных дат и современной хронологической шкалой, но с обязательным указанием источника, данную связь устанавливающего. В частности, подобным источником может быть чье-либо мнение (пример нематериального источника).

> Для письменных источников это набор типа "доска", "бумага",
> "береста", "папирус", "пергамент", "камень", "бетон", "глина"
> (...) ?

Да, в первом приближении. В дальнейшем этот набор можно будет существенно расширить и углубить.

> 1. Мне видится так, что перекрёстные ссылки с упоминаемыми
> сущностями несколько уравнивают роли всех "упоминаемых": смысл
> подобных связей в том, чтоб иметь возможность
> - по данному источнику найти всех упоминаемых,
> - по упоминаемому -- персонажу, событию или другому источнику
> -- найти все упоминания о них в источниках.
> Так ? (Можно предложить это в качестве одной из промежуточных
> задач, которые формируют требования к системе.)

Почти так. Ничто не мешает нам в данной структуре выбрать, к примеру, всех исторических персонажей, принимавших участие в событии, или все события, в которых принмал участие персонаж. Причем любая выборка будет подкреплена источниками. Впрочем для построения какой-либо реконструкции всегда можно использовать «неизвестный источник» или чье-либо мнение в качестве источника.

> 2. Упоминание другого источника в качестве... (экое масло..)
> ..."поставщика" (Во! ;)) данных устанавливает
> зависимость от него. Вполне вероятно, что нас это (пока)
> не интересует.
>

В данном случае под «источником» я имел в виду не только письменный источник (хотя и для него отношение использования мне представляется важным), но и любой материальный объект, дошедший до наших дней.

> 3. Т.о. логически источник является неким "контейнером",
> содержащим ссылки на другие источники (0 или более), персонажей
> (0 или более), события (соответственно..).

Все правильно.

> 4. Географическая локализация -- это свойство
> упоминаемых событий, наряду с датой (учитывая
> комментарий про дату в пункте D.).

К географической локализации предлагаю подходить так же, как к дате, то есть использовать «справочник первичных географических названий» и современный справочник географических названий. Связь между указанными справочниками аналогична связи между справочниками дат. Подобный же подход можно использовать и для исторических персонажей.

> Про таблицу я пока не берусь судить. А вот задачу "участия
> персонажа" -- это прошу развернуть на примере.

Пример. Читаем в Лаврентьевской летописи: «В лѣт ҂s҃ . у҃ еı҃ . [907] Иде Ѡлегъ на Грекы».
Источник – Лаврентьевская летопись.
Событие – Поход на греков.
Персонаж – Олег.
Участие Олега в походе на греков отражается в виде связи между соответствующими экземплярами сущностей «Событие» и «Персонаж».Связь имеет ссылку на экземпляр сущности «Источник» - Лаврентьевская летопись.

> Вопрос сбоку. "Упоминаемые события" это сущность того же
> порядка, что и "обнаружение источника" или не стоит притягивать
> одно к другому ?
Мне кажется, это сущности одного порядка («Событие»), но привязаны они будут к разным источникам.
С уважением,
К.

 
 Re: мысли
Автор: Foster (195.170.203.---)
Дата:   01-06-04 17:50

d-te Написал:

> Foster Написал:
> Наложение?
> Ну я бы в модели это запретил, тоже имхо.

Думаю, просто появятся отношения с двумя "разными" событиями других источников.

> > Некорректно. Я-то по наивности думаю, что установление
> > фантомности является целью, а Вы помещаете его в предпосылки.
> > Вот укажите два события, а потом, доказав их
> > фантомность, свяжите их соответствующим отношением.
> Доказывать будете руками и элиминировать дубликаты тоже. А в
> идеале система должна расставить дубликатные связи(возможные).
> Вводя фантомное событие Вы априорно уже приняли решение об этом

Неправда. Есть источник, есть описанное в нем событие. Есть другой источник, и в нем описано некое событие. То, что это одно и тоже событие в глобальном историческом масштабе должно доказываться. И только так. Поэтому и в базе событий должно быть два.

> событии. Это опять ТИ и в этом проблема. Нет ну можно смягчить
> заведя аттрибут условности - но тогда ТИ-шников к базе
> подпускать нельзя - везде будет 100% :-)

Это не ТИ. Если хочется сделать что-то полезное, а наработанным данным недоверяете, надо начать "с нуля", то есть провести весь анализ заново. А то вместо одной априорности Вы предлагаете другую.

> > В принципе, схема может быть приблизительно такая:
> опять юэмель он же для моделей0прототипов - ключ, ключ надо
> :-)
> иначе бардак0хаос.

Что Вы понимаете под ключом в данном контексте?

> > - источники, как классы экземпляров
> классообразующий признак?
> источник меняется во времени(издания) и пространстве(языки).
> Думаю что работать нужно с копией источника.
> И это не экземпляр - просто доступная копия издание перевод,
> например.
> Еще источники наследуют друг друга и мы не знаем какая редакция
> первична...

Есть источник - например ПВЛ. Это класс. А списки этой летописи - экземпляры класса. Какие-то атрибуты имеет смысл привязать к источнику-классу, какие-то к экземплярам.

 
 Re: Концептуальная модель ДБ
Автор: Foster (195.170.203.---)
Дата:   01-06-04 18:01

Консерватор Написал:
> Момент действительно интересный. Предлагаю следующее решение.
> Если дата указана в источнике, то в БД она должна храниться в
> таком же виде, как и в источнике. Таким образом, мы приходим к
> необходимости формирования «справочника первичных дат».

Думаю, что первичной должна быть локальная (относительная) дата источника. Распространенный пример - счет от сотворения мира в каждом источнике может быть свой. Да и от РХ, следовательно, принимаем одну из дат источника за ноль и остальные даты только от нее - типа, пятнадцатый год от нулевой даты летописи. И атрибут источника - его обозначения дат и дата нуля отсчета в системе источника.
Кроме того, систем датирования в источнике может быть несколько, следовательно каждое событие может иметь несколько дат - по одной на каждую систему летоисчисления.
Интервал дат может быть полезен, если будет учитываться дата с точностью до месяцев, тогда, из-за указаний типа "в тот же год" нужно указывать доверительный интервал.

 
 Дискуссия Edgeways - Консерватор
Автор: Сергей Нечаев (---.uninet.ee)
Дата:   01-06-04 23:33

Замечательная разгорелась дискуссия!
Хочу заметить, что в вашем споре не хватает определения цели построения БД. Как я понимаю из хода дискуссии, вы пытаетесь построить модель БД, которая позволит определять фантомы, повторы и прочие взаимоотношения версий событий, включая персонажи. То есть фактически проектируете систему искусственного интеллекта.
Я же ставил перед собой значительно более скромную задачу - просто систематизацию накопленных знаний. В моей концепции выводы должен делать исследователь, база лишь готовит для него структуророванный материал.
Ваша точка зрения чрезвычайно любопытна, и иллюстрирует тот факт, что модель действительно надо обсуждать. И чем точнее она будет проговорена, тем больше пользы будет от конечного результата.
Прошу вас определиться (высказаться) по поводу цели создания такой БД - в зависимости от постановки задачи можно прийти к достаточно разным концептуальным моделям.

 
 Re: определения цели
Автор: Edgeways (194.186.114.---)
Дата:   02-06-04 04:44

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

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

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

 
 Re: собственная дата источника
Автор: Edgeways (194.186.114.---)
Дата:   02-06-04 05:03

Т.е. получается, что дата оказыватся довольно самостоятельной сущностью, которой требуется довольно развитая поддержка. Надо подумать...

А вот по этому поводу --
"Кроме того, систем датирования в источнике может быть несколько, следовательно каждое событие может иметь несколько дат - по одной на каждую систему летоисчисления."
-- Вы не могли бы привести наглядный пример ? А лучше несколько.

 
 Re: Концептуальная модель ДБ
Автор: Консерватор (---.kcsystema.ru)
Дата:   02-06-04 09:31

Уважаемый Фостер!
По поводу даты не совсем согласен с Вами. Считаю, что в БД ее надо хранить точно также, как она прописана в источнике, но предусмотреть связь между ней и современной хронологической шкалой, которая, в свою очередь, должна опираться на источник, обосновывающий пересчет. Если в источнике прописано "...в третье лето княжения Владимира...", то первичную дату и следует записать именно в виде этой фразы. К сожалению, ошибки в пересчете относительной даты в абсолютную не такая уж редкая вещь. В частности, наличие повторов в ряде древнерусских летописей (повторение одних и тех же событий под разными годами) связано именно с этой ошибкой. Мне думается, что разработчикам БД не стоит брать на себя ответственность за правильность конвертации даты.
Использование интервала дат вместо одной даты мне представляется более гибким. Если нам известна точная дата события, то дата его начала будет просто совпадать с датой окончания, если же точная дата неизвестна, то без интервала просто не обойтись.
С уважением,
К.

 
 Re: собственная дата источника
Автор: Foster (195.170.203.---)
Дата:   02-06-04 10:26

Edgeways Написал:

> Т.е. получается, что дата оказыватся довольно самостоятельной
> сущностью, которой требуется довольно развитая поддержка. Надо
> подумать...

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

> "Кроме того, систем датирования в источнике может быть
> несколько, следовательно каждое событие может иметь несколько
> дат - по одной на каждую систему летоисчисления."

> -- Вы не могли бы привести наглядный пример ? А лучше
> несколько.

Один пример могу - "Альмагест" Птолемея. "После Набонассара", "год Филадельфа", "год после смерти Александра". К тому же, мелькали на форуме примеры источников, оперирующих эрами от сотворения мира и от РХ одновременно.

Как программист, не могу пройти мимо фактов, которые могут существенно повлиять на структуру.

 
 Re: Концептуальная модель ДБ
Автор: Foster (195.170.203.---)
Дата:   02-06-04 10:43

Консерватор Написал:

> Уважаемый Фостер!
> По поводу даты не совсем согласен с Вами. Считаю, что в БД ее
> надо хранить точно также, как она прописана в источнике, но
> предусмотреть связь между ней и современной хронологической
> шкалой, которая, в свою очередь, должна опираться на источник,
> обосновывающий пересчет. Если в источнике прописано "...в
> третье лето княжения Владимира...", то первичную дату и следует
> записать именно в виде этой фразы.

Запись даты в виде фразы не формализуется. Ее надо приводить. Как комментарий - пусть.
Более того, в другом источнике дата воскняжения Владимира может быть смещена относительно данного, да и априори нельзя сказать, тот же ли это Владимир или другой следовательно точки отсчета независимы.
За один из нулей берется, например, дата воскняжения Владимира, без первоначальной привязки к какой-либо внешней хронологической шкале и событию приписывается дата 3. Т.е. моя система дат лишь формализация Вашей.

> К сожалению, ошибки в
> пересчете относительной даты в абсолютную не такая уж редкая
> вещь. В частности, наличие повторов в ряде древнерусских
> летописей (повторение одних и тех же событий под разными
> годами) связано именно с этой ошибкой. Мне думается, что
> разработчикам БД не стоит брать на себя ответственность за
> правильность конвертации даты.

Разработчики базы должны обеспечить настраиваемость и масштабируемость, а так же корректную реализацию бизнес-правил, которые им зададут. Так что последней Вашей фразы не понял.

> Использование интервала дат вместо одной даты мне
> представляется более гибким. Если нам известна точная дата
> события, то дата его начала будет просто совпадать с датой
> окончания, если же точная дата неизвестна, то без интервала
> просто не обойтись.

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

 
 Re: Дискуссия Edgeways - Консерватор
Автор: Консерватор (---.kcsystema.ru)
Дата:   02-06-04 10:46

Сергей Нечаев Написал:

> Хочу заметить, что в вашем споре не хватает определения цели
> построения БД. Как я понимаю из хода дискуссии, вы пытаетесь
> построить модель БД, которая позволит определять фантомы,
> повторы и прочие взаимоотношения версий событий, включая
> персонажи. То есть фактически проектируете систему
> искусственного интеллекта.
> Я же ставил перед собой значительно более скромную задачу -
> просто систематизацию накопленных знаний. В моей концепции
> выводы должен делать исследователь, база лишь готовит для него
> структуророванный материал.

Уважаемый Сергей Нечаев!
Полностью согласен с Вами, в том, что основная цель БД – подготовка для исследователя структурированного материала. Мои предложения по концептуальной модели БД также направлены к этой цели. Я убежден, что все первичные данные, загружаемые в базу, должны быть авторизованы, иначе база в достаточно скором времени превратится в помойку. Именно поэтому я такое большое внимание уделяю источнику и именно его считаю основной сущностью модели. Только из источника мы получаем информацию о событиях и персонажах, на основе которой создаются исторические реконструкции. Не могу в этой связи не привести цитату из оаботы известного историка Я.С.Лурье «О некоторых принципах критики источников»: «…История устанавливает не то, что могло произойти в прошлом, а то, что с достаточной (хотя, возможно, и неоднозначной) достоверностью вытекает из исторических источников…».
Естественно, разные источники вызывают разную степень доверия, поэтому некоторая часть модели должна служить для хранения описательных характеристик источника. По этим характеристикам пользователь всегда сможет определить, в какой степени источник заслуживает доверия.
Содержательную часть письменных источников я предлагаю структурировать в максимально приближенном к первоисточнику виде, в противном случае в базу будут внесены субъективно интерпретированные (а по сути, искаженные) данные. Примером структуризации может служить выделение из источника данных о персонажах, событиях, географических и хронологических данных и пр.
Важнейшую роль в проектируемой БД должны сыграть отношения, связывающие перечисленные выше структурные элементы. Каждое отношение представляет собой элемент исторической реконструкции (интерпретации), поэтому оно тоже должно быть авторизовано источником.
Оговорюсь, что я предлагаю в концептуальной модели несколько расширить понятие «источник» и включить в него, помимо прочего, элемент «здравого смысла», то есть мнение авторизованного пользователя.
Таким образом, мы получаем БД, в которой хранятся не только данные источников, но и авторизованные исторические реконструкции (гипотезы).
С уважением,
К.

 
 Re: Дискуссия Edgeways - Консерватор
Автор: Foster (195.170.203.---)
Дата:   02-06-04 10:57

Сергей Нечаев Написал:
> Я же ставил перед собой значительно более скромную задачу -
> просто систематизацию накопленных знаний. В моей концепции
> выводы должен делать исследователь, база лишь готовит для него
> структуророванный материал.

Так это и есть главная задача. Правильно структурированные данные позволяют проводить над ними практически любые действия. То есть использовать такую базу можно будет в любом направлении - хоть сторонником НХ, хоть представителем ТХ.

Практически, это означает, что структура первоначальных данных должна быть как можно более подробной и не должна содержать интерпретационных результатов.

 
 Re: Концептуальная модель ДБ
Автор: Консерватор (---.kcsystema.ru)
Дата:   02-06-04 11:11

Foster Написал:

> Запись даты в виде фразы не формализуется. Ее надо приводить.
> Как комментарий - пусть.
> Более того, в другом источнике дата воскняжения Владимира может
> быть смещена относительно данного, да и априори нельзя
> сказать, тот же ли это Владимир или другой следовательно точки
> отсчета независимы.
> За один из нулей берется, например, дата воскняжения Владимира,
> без первоначальной привязки к какой-либо внешней
> хронологической шкале и событию приписывается дата 3. Т.е. моя
> система дат лишь формализация Вашей.

Уважаемый Фостер!
Не слишком ли много у Вас получится точек начала отсчета? Что же касается формализации, то она легко обеспечивается введением связи с современной хронологической шкалой. Поскольку данная связь субъективна и зависит от той или иной интерпретации записи в источнике, то она должна иметь ссылку на источник, обосновывающий данную интерпретацию. Именно отсутствие обоснования я имел в виду, говоря об ответственности за правильность конвертации даты.

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

Под интервалом дат я имею в виду две даты, одна из которых соответствует началу интервала, а вторая – его окончанию.

С уважением,
К.

 
 Re: Концептуальная модель ДБ
Автор: Foster (195.170.203.---)
Дата:   02-06-04 11:40

Консерватор Написал:
> Не слишком ли много у Вас получится точек начала отсчета? Что

Сколько реально существует, столько и будет.

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

Именно, что субъективна. Зачем Вам база, если Вы уже знаете, на какой год от РХ приходится дата "третье лето княжения Владимира"? Т.е. Вы предлагаете базу современных исторических представлений, а я думаю, что речь должна идти о базе фактов, к которым привязка воскняжения Владимира не относится.
А вот в качестве гипотезы отношение нуля дат источника к принятому летоисчислению, по которому нынешний год имеет номер 2004, может быть внесено уже в интерпретационную часть базы. И уже там может быть интервал лет.

> обосновывающий данную интерпретацию. Именно отсутствие
> обоснования я имел в виду, говоря об ответственности за
> правильность конвертации даты.

> Под интервалом дат я имею в виду две даты, одна из которых
> соответствует началу интервала, а вторая – его окончанию.

Итервалы чего - даты в источнике или даты привязки к современной шкале?

 
 Re: Концептуальная модель ДБ
Автор: Консерватор (---.kcsystema.ru)
Дата:   02-06-04 12:36

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

\\Итервалы чего - даты в источнике или даты привязки к современной шкале?\\

Конечно даты современной шкалы, а связи источника (точнее, описываемого в источнике события) с этими датами будут соответствовать тем или иным гипотезам.
С уважением,
К.

 
 Re: мысли
Автор: d-te (---.motorola.com)
Дата:   02-06-04 13:21


> Что Вы понимаете под ключом в данном контексте?
Вот определение: http://www.citforum.ru/database/dblearn/dblearn03.shtml#03

В данном контексте: если появляется дубликат события, то аттрибут события перестает быть ключевым, а база перестает быть во второй нормальной форме( примитивно - номер нормальной формы есть мера упорядоченности) и переходит в более бардачное состояние.

> > > Некорректно. Я-то по наивности думаю, что установление
> > > фантомности является целью, а Вы помещаете его в
> предпосылки.
> > > Вот укажите два события, а потом, доказав их
> > > фантомность, свяжите их соответствующим отношением.
> > Доказывать будете руками и элиминировать дубликаты тоже. А в
> > идеале система должна расставить дубликатные
> связи(возможные).
> > Вводя фантомное событие Вы априорно уже приняли решение об
> этом
>
> Неправда. Есть источник, есть описанное в нем событие. Есть
> другой источник, и в нем описано некое событие. То, что это
> одно и тоже событие в глобальном историческом масштабе должно
> доказываться. И только так. Поэтому и в базе событий должно
> быть два.

Вот есть некие иностранные свидетельства о битве на Руси. По времени отождествлены с куликовской. Сколько событий будем заводить?
И заново ведь отождествлять придется. В ручную. Одно дело массив историков в ручную работает, другое дело найти столько добровольцев :-)
Нет это должно происходить автоматически.


> > событии. Это опять ТИ и в этом проблема. Нет ну можно
> смягчить
> > заведя аттрибут условности - но тогда ТИ-шников к базе
> > подпускать нельзя - везде будет 100% :-)
>
> Это не ТИ. Если хочется сделать что-то полезное, а наработанным
> данным недоверяете, надо начать "с нуля", то есть провести весь
> анализ заново. А то вместо одной априорности Вы предлагаете
> другую.

и с нуля и вручную. нереализуемо.
Вы предполагаете, что такую работу несколько энтузиастов выполнит лучше чем на порядки большее число профессионалов :-) Так не бывает :-(
А вот что можно – воспользоваться форой современности.
Компьютер может сравнится с сотнями профессионалов – но только при умелом использовании. Нельзя игнорировать научные базовые принципы (при поделке на UML – можно, а здесь нельзя)



> > > - источники, как классы экземпляров
> > классообразующий признак?
> > источник меняется во времени(издания) и пространстве(языки).
> > Думаю что работать нужно с копией источника.
> > И это не экземпляр - просто доступная копия издание перевод,
> > например.
> > Еще источники наследуют друг друга и мы не знаем какая
> редакция
> > первична...
>
> Есть источник - например ПВЛ. Это класс. А списки этой летописи
> - экземпляры класса. Какие-то атрибуты имеет смысл привязать к
> источнику-классу, какие-то к экземплярам.

Ваш класс - это терминология из имплементации а не дизайна. Под классобразующим признаком я имел ввиду несколько другое. ( попробуем категореобразующий признак )

 
 Re: мысли
Автор: Foster (195.170.203.---)
Дата:   02-06-04 15:29

d-te Написал:
> > Что Вы понимаете под ключом в данном контексте?
> В данном контексте: если появляется дубликат события, то
> аттрибут события перестает быть ключевым, а база перестает быть
> во второй нормальной форме( примитивно - номер нормальной формы
> есть мера упорядоченности) и переходит в более бардачное
> состояние.

Если совпадают ВСЕ атрибуты событий, то это одно событие, хотя, формально, если они описаны в разных источниках, то как минимум один атрибут уже не совпадает. Только, если бы все описания одного события совпадали, чего б мы тут тогда делали?
А если Вам нужна нормальная форма - заведите уникальный ID.

> > Неправда. Есть источник, есть описанное в нем событие. Есть
> > другой источник, и в нем описано некое событие. То, что это
> > одно и тоже событие в глобальном историческом масштабе должно
> > доказываться. И только так. Поэтому и в базе событий должно
> > быть два.
> Вот есть некие иностранные свидетельства о битве на Руси. По
> времени отождествлены с куликовской. Сколько событий будем
> заводить?

На каждый источник - одно событие. Отождествление времени - интерпретация, следовательно, не факт. Отождествление событий - интерпретация, следовательно, не факт.

> И заново ведь отождествлять придется. В ручную. Одно дело
> массив историков в ручную работает, другое дело найти столько
> добровольцев :-)
> Нет это должно происходить автоматически.

Вот и формализуйте атрибуты (если это возможно), введите события (по факту), а потом по формальным признакам (если таковые найдутся) осуществите поиск дубликатов. Тогда, и только тогда, выяснится, одно это событие или нет. И не надо ставить телегу впереди лошади.

> > Это не ТИ. Если хочется сделать что-то полезное, а
> наработанным
> > данным недоверяете, надо начать "с нуля", то есть провести
> весь
> > анализ заново. А то вместо одной априорности Вы предлагаете
> > другую.
> и с нуля и вручную. нереализуемо.
> Вы предполагаете, что такую работу несколько энтузиастов
> выполнит лучше чем на порядки большее число профессионалов :-)
> Так не бывает :-(

Тогда не беритесь. Доверяете работе профессионалов - заводите интерпретационную базу с традиционными привязками и пользуйтесь ею. Только ничего нового по этой базе сделать у Вас не получится - обычная энциклопедия. Стоило ли огород городить, да еще на новопарадигмальном форуме.

> А вот что можно – воспользоваться форой современности.
> Компьютер может сравнится с сотнями профессионалов – но только
> при умелом использовании. Нельзя игнорировать научные базовые
> принципы (при поделке на UML – можно, а здесь нельзя)

Составление энциклопедии мне лично не интересно.

> > Есть источник - например ПВЛ. Это класс. А списки этой
> летописи
> > - экземпляры класса. Какие-то атрибуты имеет смысл привязать
> к
> > источнику-классу, какие-то к экземплярам.
> Ваш класс - это терминология из имплементации а не дизайна. Под
> классобразующим признаком я имел ввиду несколько другое. (
> попробуем категореобразующий признак )

Насчет реализации или дизайна - не факт. Иметь ПВЛ как самостоятельный объект, абстрагируясь от ее списков, может быть удобно пользователю на определенном этапе работы, детализируя по мере необходимости.
Или Вы имеете термин "класс"? Здесь этот термин ничего общего с классами объектных языков программирования не имеет. Кроме самой общей идеи классификации.

 
 Re: Концептуальная модель ДБ
Автор: Foster (195.170.203.---)
Дата:   02-06-04 15:33

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

Ну и в чем наши расхождения? Только в том, что я формализовал понятие "дата как в источнике", да разбил базу на две идеологически различные части - фактологическую и версионную (интерпретационную).

> \\Итервалы чего - даты в источнике или даты привязки к
> современной шкале?\\
> Конечно даты современной шкалы, а связи источника (точнее,
> описываемого в источнике события) с этими датами будут
> соответствовать тем или иным гипотезам.

Об том и речь.

 
 Re: Концептуальная модель ДБ
Автор: Консерватор (---.kcsystema.ru)
Дата:   02-06-04 15:51

Foster Написал:

>
> Ну и в чем наши расхождения? Только в том, что я формализовал
> понятие "дата как в источнике", да разбил базу на две
> идеологически различные части - фактологическую и версионную
> (интерпретационную).
>
Уважаемый Фостер!
Похоже, принципиальных расхождений действительно нет.
С уважением,
К.

 
 Re: мысли
Автор: d-te (---.motorola.com)
Дата:   02-06-04 18:13

Foster Написал:

> d-te Написал:
> > > Что Вы понимаете под ключом в данном контексте?
> > В данном контексте: если появляется дубликат события, то
> > аттрибут события перестает быть ключевым, а база перестает
> быть
> > во второй нормальной форме( примитивно - номер нормальной
> формы
> > есть мера упорядоченности) и переходит в более бардачное
> > состояние.
>
> Если совпадают ВСЕ атрибуты событий, то это одно событие, хотя,
> формально, если они описаны в разных источниках, то как минимум
> один атрибут уже не совпадает. Только, если бы все описания
> одного события совпадали, чего б мы тут тогда делали?
> А если Вам нужна нормальная форма - заведите уникальный ID.

нормальная форма не нужна сама по себе. Это всего лишь показатель будущего успеха/неуспеха.
ID - это залечить и не спроектировать- сам по себе ничего не меняет. Нужна естественность – натуральность подхода.
>
> > > Неправда. Есть источник, есть описанное в нем событие. Есть
> > > другой источник, и в нем описано некое событие. То, что это
> > > одно и тоже событие в глобальном историческом масштабе
> должно
> > > доказываться. И только так. Поэтому и в базе событий должно
> > > быть два.
> > Вот есть некие иностранные свидетельства о битве на Руси. По
> > времени отождествлены с куликовской. Сколько событий будем
> > заводить?
>
> На каждый источник - одно событие. Отождествление времени -
> интерпретация, следовательно, не факт. Отождествление событий -
> интерпретация, следовательно, не факт.

объемы представляете ?

> > И заново ведь отождествлять придется. В ручную. Одно дело
> > массив историков в ручную работает, другое дело найти столько
> > добровольцев :-)
> > Нет это должно происходить автоматически.
>
> Вот и формализуйте атрибуты (если это возможно), введите
> события (по факту), а потом по формальным признакам
> (если таковые найдутся) осуществите поиск дубликатов. Тогда, и
> только тогда, выяснится, одно это событие или нет. И не надо
> ставить телегу впереди лошади.

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


> Тогда не беритесь. Доверяете работе профессионалов - заводите
ну прочитал презентацию - не увидел базовых принципов - обнаружил что уровень мой - решил встрять - потрепаться :-)

 
 Re: фактологическую и версионную
Автор: Edgeways (---.dialup.primorye.ru)
Дата:   02-06-04 18:41

Раз уж вы уже в консенсусе, то прошу сформулировать, что такое фактологическая часть (с тремя примерами) и версионная (с тремя примерами).

Вопрос сбоку.
Если дата сама по себе это временной интервал от некой реперной точки, а точнее -- от реперного события, то не отразить ли дату отношением к хранимой в БД сущности "событие" ? Какие плюсы-минусы ?

Есть тут момент. Единственность объекта "событие"в БД ("вокняжение Владимира") и ссылки двух независимых дат на "2 года" от оного "вокняжения Владимира" и на "10 лет" от "вокняжения Владимира" -- не означают того, что они действительно (реально, конкретно..) отталкиваются от одной реперной точки. Только от одинакового описания реперной точки, единственность же самой точки является интерпретацией. Как в случае с датой от сотворения мира.

Итого вариант.
"Дата" связана с реперным "событием" и обосновывается "источником". Реализация выделенными сущностями.
Есть альтернативы ?

 
 Re: мысли
Автор: Foster (195.170.203.---)
Дата:   02-06-04 19:46

d-te Написал:
> > А если Вам нужна нормальная форма - заведите уникальный ID.
> нормальная форма не нужна сама по себе. Это всего лишь
> показатель будущего успеха/неуспеха.
> ID - это залечить и не спроектировать- сам по себе ничего не
> меняет. Нужна естественность – натуральность подхода.

Естественность подхода - моделирование в терминах и сущностях наиболее близких к предметной области. Разбор идеи ключа из атрибутов - ниже.

> > На каждый источник - одно событие. Отождествление времени -
> > интерпретация, следовательно, не факт. Отождествление событий
> >- интерпретация, следовательно, не факт.
> объемы представляете ?

А кому легко? Цитирую себя же "Вам евроремонт или петь научиться?".

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

Кто сказал, что события дубликаты? Где в Вашей схеме процесс (пусть в виде смены состояния) опознания дубликатов? Если речь явно идет о нечеткой логике. Если можно говорить только некоем доверительном интервале, о вероятности совпадения. Если у описания события в разных источниках может даже быть разный состав активных атрибутов. Какой, к черту, ключ.

Конечно, было бы красиво - вводим событие - а база в ответ "Опа, а такое событие уже есть" - и сливает его в одно, только "это фантастика". Не будет такого. Тем более для новохронологических дубликатов.
Остается только на основе введенных фактических данных строить множественные(?) непротиворечивые гипотезы - систему отношений событий, как надстройку над фактическими данными, задавая критерии сопоставления событий. Критерии непротиворечивости тоже могут быть нечеткими и, к сожалению, разными.
И никто не мешает Вам строить гипотезы на лету, только зачем они нужны такие, основанные не на полном массиве источников? Только ресурсы занимать. Ведь только одно событие в такой схеме, особенно на первых порах, может поменять выводы с точностью наоборот.

> > Тогда не беритесь. Доверяете работе профессионалов - заводите
> ну прочитал презентацию - не увидел базовых принципов -
> обнаружил что уровень мой - решил встрять - потрепаться :-)

Базовых принципов исторической науки? Или Вы не поняли что я веду речь не о БД, а о противопоставлении ТХ - НХ? Или я не понял, презентацию чего Вы прочитали?

 
 Re: фактологическую и версионную
Автор: Foster (195.170.203.---)
Дата:   02-06-04 20:06

Edgeways Написал:

> Раз уж вы уже в консенсусе, то прошу сформулировать, что такое
> фактологическая часть (с тремя примерами) и версионная (с тремя
> примерами).

Три примера - это слишком, одного за глаза.
Возьмем то же "вокняжение Владимира" (как оно хоть правильно пишется-то, а?).
Фактологическая часть - нуль отсчета, к примеру, вокняжение, дата события - 3 года от точки отсчета, имя Владимир.
Версионная - отнесение нуля отсчета к периоду от A до Б лет от РХ, события от А+2 до Б+4 от РХ (числа "от балды" - типа учет разницы в точке начала года), имя - Улайтимур (с вариантами!) какой-нибудь, вместо вокняжения - венчание на царство.

> Вопрос сбоку.
> Если дата сама по себе это временной интервал от некой реперной
> точки, а точнее -- от реперного события, то не отразить ли дату
> отношением к хранимой в БД сущности "событие" ? Какие
> плюсы-минусы ?

Дата - более или мене точное значение от реперной точки. Интервал - ее интерпретация.

> Есть тут момент. Единственность объекта "событие"в БД
> ("вокняжение Владимира") и ссылки двух независимых дат на "2
> года" от оного "вокняжения Владимира" и на "10 лет" от
> "вокняжения Владимира" -- не означают того, что они
> действительно (реально, конкретно..) отталкиваются от одной
> реперной точки. Только от одинакового описания реперной
> точки, единственность же самой точки является
> интерпретацией. Как в случае с датой от сотворения мира.

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

> Итого вариант.
> "Дата" связана с реперным "событием" и обосновывается
> "источником". Реализация выделенными сущностями.
> Есть альтернативы ?

Слишком общая фраза, чтобы комментировать. В такой постановке это не расходится с тем, что я высказал в своем исходном постинге.

 
 Диапазон дат
Автор: Сергей Нечаев. (---.uninet.ee)
Дата:   02-06-04 22:34

В исходном примере модели у даты есть два атрибута - допуск+ и допуск-.
Фактически это и есть интервал достоверности. Пример: Такая-сякая война: дата 202 год, допуск + 20 допуск - 15. То есть рассматриваемое событие происходило между 187 и 222 годами, скорее всего в 202 году. При организации выборки в диапазоне 210 -230 годы при условии "по точной дате" событие в выборку не попадет, при условии "С учетом допуска дат" - попадет.

 
 База фактов не получится
Автор: Сергей Нечаев. (---.uninet.ee)
Дата:   02-06-04 22:45

>а я думаю, что речь должна идти о базе фактов, к которым привязка воскняжения Владимира не относится.

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

>А вот в качестве гипотезы отношение нуля дат источника к принятому летоисчислению, по которому нынешний год имеет номер 2004, может

Вот это как раз и есть версия. Одна из многих.

 
 Re: Сетевая структура - не помойка.
Автор: Покровский Станислав (---.catv.ext.ru)
Дата:   03-06-04 01:13

Для моего предложения является существенным то, что за время функционирования Интернета выявилась интересная особенность. Из любого узла паутины можно прийти в любой другой узел через незначительное количество связей. Это же отражает работу мозга. Каждое понятие вызывает цепочку ассоциаций, через которые можно пройти от любого понятия к любому.

Но узлы в Инете и понятия в мозгу - неравнозначны.
От одних узлов идут множественные связи, от других - единичные. Но связи обязательно есть. Если бы их не было, то узлы и понятия не имели бы права на существование.

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

С другой стороны события, факты, понятия, имеющие наиболее массовые связи с другими событиями, объектами, понятиями, - представляются ключевыми, т.е. показывают, что проверка и датироровка именно этих событий, фактов, понятий, материальных свидетельств является ключевой для датировки и осмысления всего исторического процесса.
Это, кстати, отражает и ход дискуссий на форуме. Дискуссии сплетаются около отдельных понятий, фактов, представляющихся ключевыми: пирамиды, крестовые походы, Китайская стена, латинский язык, Христос...

Представляется, что подобная нейронная сеть и должна стать моделью для построения БД.

Вводится слово, событие, понятие, год, имя и т.д. Вокруг него выстраивается ПОПОЛНЯЕМАЯ система исторических ассоциаций.
Типа:
Узел - ВАВИЛОН.
Ассоциации: кирпич, Месопотамия, Тигр, Евфрат, клинопись, Навуходоносор, градус, глиняные таблички, жрец, пшеница, вавилонская башня, Геродот, Николо Макиавелли, Ирак, Александр Македонский, столица,...

Т.е. вносится любое понятие из любого источника, связанное с Вавилоном. От Вавилона к каждому понятию идет линия связи. Которая не сама по себе, она тоже является объектом(узлом) сети. И имеет свое описание. Если связь с Вавилоном какого-либо объекта множественная, то, значит, каждый факт источниковой или археологической информации яваляется линией связи. Все связи регистрируются и считаются. Пользователь, попытавшийся взять слово Вавилон и другое какое-то слово, видит на экране, что с Месопотамией Вавилон связывает 325, например, зарегистрированных в сети упоминаний. А унего на руках еще одно. Он пытается внести свой источник. Сеть отзывается: источник новый. Зарегистрирован. Или "взят на контроль экспертной группой". Или "источник уже зарегистрирован".

И так далее. Но сами эти источники - тоже не просто упоминания. Они сами являются объектами-узлами сети. Которые тоже имеют свои связи с прочими источниками, фактами, понятиями.

Связи должны иметь диалектическую структуру. Бесспорные. Типа Гагарин - СССР. И связи сомнительные: типа мнений. Т.е. такая-то археологическая находка, про которую достоверно известно, что найдена в 6 км от Джанкоя, в захоронении, соседствует с останками коня, сама - железная, но ПРИПИСЫВАЕТСЯ такому-то веку, приписывается такому-то народу. Т.е. и век, и народ, которому приписывается находка - тоже попадают в базу. Но их связи с данной находкой относятся к другому классу достоверности.

То, что Тит Ливий упомянул Ганнибала - факт бесспорный.
А вот связь Ганнибал - Каны - сомнительная. Это мнение, описание, которое не более, чем описание.

Нас интересуют в БД не сами факты, а их связанность и преимущественные типы связей с событиями, описываемыми историей.

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

Вот только сколько нужно для этого памяти? И какой мощности должны быть серверы, связывающие множество компьютеров в эту сеть. Как бы не помощнее структуры всего Интернета.

 
 Re: Базa Данных с 14 века
Автор: шумах (---.cinci.rr.com)
Дата:   03-06-04 01:24


Идея хорошая.

При условии если база данных будет идти с 14 века.Древней 14 века - информация к истории имеет литературное отношение.
Начинать с 14 века необходимо оттого,что существует 100 летний сдвиг между 14 и 15 веком.Информация 14 века помогает восстановить,что было в 15 в.

Отдельный раздел необходим ереси и религиозные направления.Здесь уже от царя Панька.Это информация позволит реконструировать вторую половину 15 века - первую половину 17 века.

Шумах

 
 Re: фактологическую и версионную
Автор: Edgeways (194.186.114.---)
Дата:   03-06-04 07:49

Про фактологическую и версионную -- понятно.

Не сразу понял про "как правильно пишется" :) - в смысле вокняжение или воcкняжение? А бог его знает, написал не задумываясь, рефлекторно исходя из самых общих соображений.

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

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

>>"Дата" связана с реперным "событием" и обосновывается "источником". Реализация выделенными сущностями.

>Слишком общая фраза, чтобы комментировать.

Смысл фразы вот в чём. "Дата" реализуется как набор:
- кол-во лет (или может чего другого),
- связь с реперным событием, т.е. связь с конкретной сущностью "событие", от которого ведётся отсчёт кол-ва лет; это может быть выделенное общее событие типа "Р.Х." или "Сотворение мира",
- связь с источником, обосновывающим И цифры кол-ва лет, И выбор реперного "события" -- точки отсчёта.
Так понятней ? Одно число (с размерностью) и две связи.

Смысл в том, что именно эта пара ссылок "от чего считать" и "кто сказал, почему так" и устанавливает собственно дату. У одного источника сотворение мира может быть одно, у другого -- другое.

 
 Re: База фактов не получится
Автор: Foster (195.170.203.---)
Дата:   03-06-04 10:10

Сергей Нечаев. Написал:
> >а я думаю, что речь должна идти о базе фактов, к которым
> привязка воскняжения Владимира не относится.
> Так ведь нет никаких фактов. Есть интерпретация источника, то

Есть факт: в летописи X описано событие с атрибутами A, B, C, D... "И отмахнуться от этого факта невозможно."

> есть версия события. И она всегда субъективна - так устроена
> история. Поэтому мне кажется не надо мудрствовать с множеством
> точек отсчета. Вносим событие - " воскняжение Владимира",
> пишем первую версию - дата от РХ по источнику (если она
> персчитанная, то в описании обоснования датировки описываем как
> была пересчитана), вносими следующую версию, с другой датой по
> другому источнику, с обоснованием по источнику и т.д.

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

> >А вот в качестве гипотезы отношение нуля дат источника к
> принятому летоисчислению, по которому нынешний год имеет номер
> 2004, может
> Вот это как раз и есть версия. Одна из многих.

Это не версия - это факт. Мы сейчас живем в 2004 году считая от некоторой условно принятой точки отсчета. Христос мог получить земное воплощение и 10000 лет назад и 100, однако то, что сегодня 2004 год это не отменит.

 
 Re: Сетевая структура - не помойка.
Автор: Foster (195.170.203.---)
Дата:   03-06-04 11:44

Если в событии указывать ключевые слова, то получится схема:
событие (упоминание Вавилона) - источник (где упомянут Вавилон) - событие (упоминание кирпича в том же источнике) - источник (где упомянут кирпич) - ... ad infinitum.

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

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

 
 Re: фактологическую и версионную
Автор: Консерватор (---.kcsystema.ru)
Дата:   03-06-04 13:17

Уважаемый Еджвэйс!
Прошу прощения за столь поздний ответ (к сожалению, мои домашние обстоятельства не очень способствуют общению через Интернет), поэтому постараюсь учесть, по возможности, мнения остальных участников дискуссии.
Важным и интересным мне представляется мнение Станислава Покровского о принципах построения сетевой БД. Правда, я не являюсь специалистом в области сетевых баз данных и вряд-ли буду полезен в случае выбора сетевой модели. С другой стороны, считаю себя неплохим специалистом по реляционным базам, и все мои предложения относятся именно к реляционной модели.
По поводу консенсуса. Речь шла о согласовании базовых принципов формирования БД, и один из этих базовых принципов Вы совершенно правильно отметили – разделение базы на две части: фактологическую и интерпретационную (мне этот термин представляется более предпочтительным, чем «версионная»). Против способа такого деления Фостер тоже, вроде бы, не возражает: фактическую часть составляют сущности, интерпретационную – связи между сущностями. Множественность подобных связей и их «окраска» путем отсылки на источник в какой-то степени перекликается и с сетевым подходом Станислава Покровского. Собственно на этом консенсус заканчивается и начинается рутинная работа по структурированию фактологической части.
Пример Фостера мне не очень понравился, он все-таки пытается внести элемент интерпретации в фактологическую часть. Вернемся к записи в источнике "...в третье лето княжения Владимира...". Что имел в виду автор? Он просто сопоставил некоторое событие современной ему хронологической шкале. Фостер предлагает отнести к фактологической части всю хронологическую шкалу автора источника (точнее, свою интерпретацию шкалы автора), хотя речь идет только об одном конкретном показании этой шкалы. Впрочем, этот момент не представляется мне сильно принципиальным на данном этапе обсуждения.
Как я уже сказал выше, к фактологической части БД предлагается отнести сущности – источник, персонаж, событие, географическую и хронологическую локализацию (безусловно, указанных сущностей недостаточно, но на начальном этапе обсуждения ими можно ограничиться). Для примера возьмем следующее собщение:
«В год 6529 (1021). Пришел Брячислав, сын Изяслава, внук Владимира, на Новгород, и взял Новгород, и, захватив новгородцев и имущество их, пошел к Полоцку снова.»
Для полной структуризации данного сообщения введем еще одну сущность (помимо указанных) – степень родства. Таким образом, имеем:
Источник: Повесть временных лет в переводе Д.С.Лихачева (далее – ПВЛ).
Персонаж: Брячислав.
Персонаж: Изяслав.
Персонаж: Владимир.
Событие: Поход на ...
Событие: Взятие …
Событие: Возвращение в …
Географическая локализация: Новгород.
Географическая локализация: Полоцк.
Хронологическая локализация: В год 6529.
Современная хронологическая шкала: 1021.
Степень родства: сын.
Степень родства: внук.
На этом фактологическая часть данных сообщения заканчивается. Переходим к интерпретационной:
Связь между событием «поход на …» и географической локализацией «Новгород» со ссылкой на источник «ПВЛ».
Связь между событием «взятие …» и географической локализацией «Новгород» со ссылкой на источник «ПВЛ».
Связь между событием «возвращение в …» и географической локализацией «Полоцк» со ссылкой на источник «ПВЛ».
Связь между отношением «поход на Новгород» и хронологической локализацией «В год 6529» со ссылкой на источник «ПВЛ».
Связь между отношением «взятие Новгорода» и хронологической локализацией «В год 6529» со ссылкой на источник «ПВЛ».
Связь между отношением «возвращение в Полоцк» и хронологической локализацией «В год 6529» со ссылкой на источник «ПВЛ».
Связь между отношением «поход на Новгород» и персонажем Брячислав со ссылкой на источник «ПВЛ».
Связь между отношением «взятие Новгорода» и персонажем Брячислав со ссылкой на источник «ПВЛ»..
Связь между отношением «возвращение в Полоцк» и персонажем Брячислав со ссылкой на источник «ПВЛ».
Связь между персонажем Брячислав и персонажем Изяслав со ссылкой на источник «ПВЛ» и на степень родства «сын».
Связь между персонажем Брячислав и персонажем Владимир со ссылкой на источник «ПВЛ» и на степень родства «внук».
Таким образом, мы получаем некоторую интерпретацию исторического события, отраженную в ПВЛ. Связь между указанным в используемом издании годом современной хронологической шкалы и первичной хронологической локализацией уже не относится к интерпретации ПВЛ и должна иметь ссылку на иной источник (например, мнение Д.С.Лихачева).
Получается довольно громоздко, но не думаю, что другие подходы будут существенно проще.
С уважением,
К.

 
 Re: фактологическую и версионную
Автор: Консерватор (---.kcsystema.ru)
Дата:   03-06-04 13:21

Уважаемый Фостер!
К сожалению не имею возможности ответить Вам подробнее. Собственно большая часть моего ответа Еджвэйсу посвящена Вам, хотелось бы узнать о Вашей реакции.
С уважением,
К.

 
 Re: Диапазон дат
Автор: Консерватор (---.kcsystema.ru)
Дата:   03-06-04 13:31

Уважаемый С.Нечаев!
Вопрос, конечно, не принципиальный. Ваш подход предполагает использование для датирования трех дат, две из которых определяют границы интервала допуска, а третья - наиболее вероятное значение. Думаю, что третья дата относится, скорее, к области интерпретации, но принципиальных возражений против ее использования у меня нет.
С уважением,
К.

 
 Re: фактологическую и версионную
Автор: Foster (195.170.203.---)
Дата:   03-06-04 13:48

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

А как иначе? Фактом является только относительное расположение на временной оси двух событий. Пытаясь внести сюда ЛЮБУЮ абсолютныю датировку (датировка относительно настоящего времени является абсолютной!) Вы автоматически вносите интерпретацию, об которую потом будете постоянно спотыкаться.

> ограничиться). Для примера возьмем следующее собщение:
> «В год 6529 (1021). Пришел Брячислав, сын Изяслава, внук
> Владимира, на Новгород, и взял Новгород, и, захватив
> новгородцев и имущество их, пошел к Полоцку снова.»

> Хронологическая локализация: В год 6529.
> Современная хронологическая шкала: 1021.


Если (1021) - пометка издателя/комментатора, то это, сами понимаете, не факт.
Если это пометка летописная, то:

Хронологическая локализация:
1) В год 6529 (предположительно от сотворения мира, предположительно по христианскому летоисчислению и ПО ЛОКАЛИЗАЦИИ СМ АВТОРОМ)
2) 1021 (предположительно год, предположительно от РХ и ПО ЛОКАЛИЗАЦИИ РХ АВТОРОМ)
3) Перевод реперных дат по источнику: 1(СМ) - 2(РХ) = 5508 (если дат несколько, может быть нечеткая формула: в одном месте одна разница, в другом - другая).

Вот и все факты. Я бы сомневался в том, что 1021 это дата, но не буду ;).
Кстати, написание было "арабскими" цифрами или кирилицей? Впрочем, хоть что-то надо считать твердо установленным :(.

Отметьте ("ПО ЛОКАЛИЗАЦИИ АВТОРА" в базе это может только подразумеваться), методологически точка сотворения мира здесь не связана с сотворением мира в другом источнике. В качестве гипотезы мы можем предположить, что она не сильно отличается от аналогичных в культурологическом плане, но это гипотеза и здесь ей не место.

 
 Re: фактологическую и версионную
Автор: Консерватор (---.kcsystema.ru)
Дата:   03-06-04 14:48

Foster Написал:

> А как иначе? Фактом является только относительное расположение
> на временной оси двух событий. Пытаясь внести сюда ЛЮБУЮ
> абсолютныю датировку (датировка относительно настоящего времени
> является абсолютной!) Вы автоматически вносите интерпретацию,
> об которую потом будете постоянно спотыкаться.

Уважаемый Фостер!
В том-то и дело, что в фактологической части остается только запись источника, а сопоставление ее с современной хронологической шкалой реализуется с помощью связи и, естественно, лежит в области интерпретаций.


> Если (1021) - пометка издателя/комментатора, то это, сами
> понимаете, не факт.
> Если это пометка летописная, то:
>
> Хронологическая локализация:
> 1) В год 6529 (предположительно от сотворения мира,
> предположительно по христианскому летоисчислению и ПО
> ЛОКАЛИЗАЦИИ СМ АВТОРОМ)
> 2) 1021 (предположительно год, предположительно от РХ и ПО
> ЛОКАЛИЗАЦИИ РХ АВТОРОМ)
> 3) Перевод реперных дат по источнику: 1(СМ) - 2(РХ) = 5508
> (если дат несколько, может быть нечеткая формула: в одном месте
> одна разница, в другом - другая).
>
> Вот и все факты. Я бы сомневался в том, что 1021 это дата, но
> не буду ;).
> Кстати, написание было "арабскими" цифрами или кирилицей?
> Впрочем, хоть что-то надо считать твердо установленным :(.

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

С уважением,
К.

 
 Re: Сетевая структура - не помойка.
Автор: Сергей Нечаев (62.65.43.---)
Дата:   03-06-04 14:50

Уважаемый Станислав Покровский!

Ваш подход чрезвычайно интересен. Однако есть в нем небольшой перегиб: вы пытаетесь построить не БД, а модель мозга! Задача несомненно достойная, но трудно выполнимая, особенно в рамках проекта.

Если потребность в такой базе (сравнимой по вашим словам с Интернетом) ограничивается выявлением узлов фальсификаций, которые "Мы .... и так их знаем, но интересно увидеть картинки..." то цель и средство ее достижения трудно сопоставимы.

С уважением



 
 Re: Сетевая структура - не помойка.
Автор: Покровский Станислав (---.dialup.mtu-net.ru)
Дата:   03-06-04 15:55

Вы знаете, выяснение фальсификаций или каких-то отдельных моментов - не есть самоцель. Самоцель - построение БД, способной к саморазвитию.

Так вот, модель мозга тем хороша, что она позволяет безболезненно наращивать БД по мере ее популяризации - подключением в систему все новых и новых участников, вводящих в БД все новые и новые сведения и ассоциативные связи. Любые иные базы данных связаны с пострением иерархии. И сепарацией информации по разделам, модель мозга позволяет избавиться от иерархии на стадии ввода данных и создания БД. А потом вводить РАЗРЕЗЫ по характеристикам. Возможно, не в первый год-два, но через пять - когда у программистов руки дойдут. А база остается при этом базой.

 
 Re: фактологическую и версионную
Автор: Foster (195.170.203.---)
Дата:   03-06-04 15:58

Консерватор Написал:
> Foster Написал:
> > А как иначе? Фактом является только относительное
> расположение
> > на временной оси двух событий. Пытаясь внести сюда ЛЮБУЮ
> > абсолютныю датировку (датировка относительно настоящего
> времени
> > является абсолютной!) Вы автоматически вносите интерпретацию,
> > об которую потом будете постоянно спотыкаться.
> В том-то и дело, что в фактологической части остается только
> запись источника, а сопоставление ее с современной
> хронологической шкалой реализуется с помощью связи и,
> естественно, лежит в области интерпретаций.

Вот это я и хочу сказать, просто призываю Вас - считать фактом только материальное свидетельство. В базу виде фактов надо вводить источники, причем не только письменные. Вся проблема в том, чтобы их формализовать, причем способом, максимально адекватным оригиналу.
А Вы дату от РХ по современной шкале постоянно притягиваете к фактам. В фактологической части могут быть связи только внутри одного источника. Кроме, может быть, фактов общего происхождения источников - найдены, например, в одном месте.

Все, что ниже будем считать промежуточным подведением итогов обсуждения.

 
 Объем базы. Какой он?
Автор: Сергей Нечаев. (---.uninet.ee)
Дата:   03-06-04 22:08

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

Попробуем оценить объем базы данных.
При ограниченном (если хотите - упрощенном) подходе он конечен: число событий и датировок ограничено. Не могу точно определить конечный объем БД, но можно оценить скорость прироста объема записей (смотри ниже).
При вашем подходе (несомненно интересном) объем бесконечен, так как бесконечно число связей и ассоциаций.
Перейдем к расчетам темпов заполнения.

Участников проекта сегодня порядка 250 (активно пишуших), читающих всего в 4 раза больше. Ввод одной полной (или почти полной) записи с разбором ее на составляющие с моделью "сетевой структуры" - минимум 2 часа. Предположим, что "энтузиастичность" участников проекта подчиняется обычным закономерностям распределений в человеческом обществе: 20% от их числа будут активно вносить 80% всей информации (принцип Парето).
И будут они вносить по 1 записи в две недели (это для них все-таки хобби, а не работа). Мы получим годовой прирост объема базы в 26*250 / 5= 1 300 записей. Оставшиеся 80% внесут еще 20% записей, и будет у нас окончательная цифра 1625 записей. Авторизация записи тоже возьмет достаточно времени, пока не могу оценить сколько (нужен пример). При конечном объеме, приближающемся к бесконечности, процесс вечен. Ожидать резкого увеличения числа участников не приходится - так называемые традики не втянутся, потому что конечная цель базы противоречит их принципам. Потому что ваш постулат об обнаружении фальсификаций им не интересен, да и вообще он делает базу однобокой. Другой ваш постулат "Самоцель - построение БД, способной к саморазвитию." тоже может мало кого привлечь, кроме трудоголиков.

При наполнении базы с иерархической структурой, с ясно очерченными сущностями, можно надеяться на сотрудничество сторонников традиционной истории, так как такая БД послужит хорошим подспорьем и в их работе. Да и скорость заполнения базы несколько повыситься: можно предположить, что разбор и внесение одной записи составит до 30 минут, что в принципе может довести годовой объем прироста до 4 - 5 тысяч записей. Тоже не бог весть как много, но объем конечен, и это дает надежду достичь значимого результата в обозримом будущем.

С другой стороны, может мой пессимизм и необоснован. Ваша идея с мозгом очень красива, если еще найти способы ее осуществить ...
Давайте обсуждать дальше.

с уважением

 
 Re: Обсуждение идеи Базы Данных
Автор: Edgeways (194.186.114.---)
Дата:   07-06-04 11:16

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

А вот я бы хотел попросить уважаемых участников таки привести набор данных, которые можно было бы хранить в рекомой базе данных. Именно данных, т.е. берём строки из источника, читаем, выделяем сущности, выписываем из в столбик, нумеруем, подписываем их свойства, ссылаясь на уже выписанные (или нижепоследующие) сущности.
Затем уже -- набор операций, которые с этими данными можно производить.

Это раз.

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

Это два.

Заниматься этим можно, скооперировавшись по принципу наличия каких-либо ресурсов -- руки, знания, навыки -- всё что может пригодиться и будет совместимо с прочими ресурсами. Логично вынести рабочее общение на что-то более удобное и уместное, почту, к примеру.

Это три.

В любом случае, я собираюсь выкроить время на отработку (пока одного) минимального прототипа до "живого состояния".



Сообщение отредактировано (07-июн-04 11:19)

 
 Итоги первого этапа на новой ветке
Автор: Сергей Нечаев (62.65.43.---)
Дата:   07-06-04 20:01

Друзья, итоги в отдельной ветке "Первый итог обсуждения концептуальной модели БД." предлагаю там дальше договориться о площадке дискуссии.

 Список форумов  |  Вид деревом   Следующая тема  |  Предыдущая тема 


 Эта тема закрыта 

phorum.org