Форум ИГШ (НЕАКТИВЕН!!!)

Начинаю эту тему здесь, поскольку "Курилка" в данный момент "самое уютное помещение" ФИГШ. При необходимости перетащим.

Суть в следующем:

1. Полагаем деятельность идеального голема эквивалентной документообороту внутри оного
2. Структуру документов, циркулирующих внутри, полагаем заданной формальными правилами
3. Алгоритмы обработки документов, полагаем заданными формальными правилами

Такой подход (схожий с идеологией, например Пролога), позволяет моделировать идеальный голем и даже предпринять попытку создания реального голема самофункционирующего.

Функции нереализуемые идеальным големом выносятся наружу и решаются человеческими структурами ГПР-1 или ГПР-3.

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

Задача весьма техническая, потому я несколько сомневаюсь в её жизнеспособности на ФИГШ.

так зачем задавать структуру документов? голем уже поселился в проектировщике? ))

Структура документа - это элемент программирования голема.

Конечная задача - "безлюдный голем".

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

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

да! Да1 ДА!!!! Хотя бы поиск. Уже немало.
Ох. Это уже уровень XML. Я сейчас бьюсь об это самое. Хотя бы формальное описание файловой структуры, допускающее машинный поиск.

В данном случае, на первом этапе я бы абстрагировался от конкретной реализации (XML, файловая система). Речь идёт о подходе к автоматизации "с другой стороны".

Главная проблема при автоматизации големной деятельности - человеческий фактор.
Спрашивается, что будет, если построить голема на бесчеловечной "элементной базе"?

Здесь, у меня есть такое видение понятия "документ".

Документ представляет собой набор полей и списков.
При этом типы полей предельно ограничены:
- строка
- число
- номер элемента списка (внешнего списка)
- другой документ
ВСЁ!

Списки состоят из полей одного типа. Так например, таблица передаётся как список документов, где каждый документ = 1 строке.

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

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

В структуру документа лезть не надо. Довольно эффекта документа: приводит ли он к увеличению числа подчинённых того или иного элемента голема. Если приводит, то документ пересылается к исполнению туда, где его могут исполнить, если нет, то как повезёт. Структура голема есть организационная структура.

Нам нужно моделирование работы голема.
Как я сказал:
"Конечная задача - полноценный бесчеловечный голем".

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

А какие элементы автоматизации доступны?

Что подразумевается под "элементами автоматизации"?

Хм. 

Угу. Мы не можем на данном уровне развития IT создать полноценную автоматизацию управленческой деятельности. Для этого сначала нужен ИИ.
Но можно поставить задачу иначе - что получится, если исходно создавать голема без применения человеческих "элементов"?

А нафига?

Ну, системы без человеческих элементов бывают. Всякие экспертные системы например.

2Monster
а) Из любопытства
б) Из возможности получить интересное подопытное жЫвотное

2Чибрикин
а) Не уверен, что можно на базе такой системы строить экспертную систему, но инструмент для обнаружения и разрешения противоречий в "100 правила" голема - можно
б) В данном случае, мы получим не просто "нечто в ящике", мы получим, условно говоря, "железного командира", эдакую квинтэссенцию бессознательного голема

Хорошо, давайте по сути. Вот предполагаемая модель документа системы:


Документ представляет собой набор полей и списков.
Типы полей:
- строка
- число
- номер элемента списка (внешнего списка)
- другой документ (ссылка)

Списки состоят из полей одного типа. Так например, таблица передаётся как список документов, где каждый документ = 1 строке.


У кого есть принципиальные замечания? Кто может описать документ, не передаваемы документом такой структуры?

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

можно ск

Ага. Там сцылко на документ. У вас серверилка не сломаецца кросс-таблицы рисовать?

Дело в том, что при любой работе с текстовой информацией, мы упираемся в наличие двух форматов данных, несводимых друг-к-другу:
- таблицы
- деревья

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

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

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

2Одинец

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

В общем это если и проблема, то не концептуальная.

Если я не совсем забыл благословенный язык цэ, то...

1. string (char*, возможно, char[N]?)
2. float (double и т.п.)
3. void *
4. Какой-то внешний указатель/сцылко.

Зачем это?

а чем собственно не угодил XML?


неа. главная проблема голема - несооветствие объема ОЗУ объему поступающей информации... алгоритмы кэширования...


= строка кодированная в base64


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

1. По типам, форматам и т.п...У меня есть "что" против XML Но к теме это не относится. Возможно XML и будет хорошим вариантом. Тоже самое относится к base64 - это всё хорошо, но пока это частности, не имеющие принципиального значения. Давайте не будем обсуждать конкретную техническую реализацию. Это всё потом.
А сейчас:

Строка - это цепочка символов произвольной длины.
Число - это произвольное число. Для нас важно, что есть поле в котором можно держать любое число. Наверное надо сказать "скаляр".
Номер элемента - я имел в виду enum, т.е. указание на значение из возможных.
Ссылка на внешний документ - это скорее HTML`ьная ссылка. Но опять же не заморачиваемся - просто поле, указывающее на какой-то документ.

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

3. Запрет на операции со строками. Поясняю почему. Голем, обрабатывающий информацию, её не понимает. Любая строка текста поступившая голему в отдельном поле, по сути является элементом "алфавита". Правка его, ни малейшего смысла не имеет, вспомните бессмертное "Не я прошу! Оный просит!" Имеет смысл сравнение, поиск в списках, добавление к списку, удаление из списка. Любые операции, производимые големом над строкой в поле, определяются не содержимым поля, а правилами обработки данного поля!!! Посему единственное действие, которое имеет смысл в отношении содержания строки - это некая нормализация, для упрощения поисковых операций.
Что касается "жрать и не срать", то существуют две стандартные големные процедуры - уничтожение документов и отправка их в архив. Так что всё с этим в полном порядке.

Хм. Вообще-то вопрос "нафига?" означал "что этот голем будет делать?". А пока в топике все мысли бегают забавные такие, как курицы с отрубленными головами.

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