Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Sinclair, Вы писали:

А>....skipped....
S>>Так что вот остановился я и призадумался. Может, ну ее — эту строгую типизацию?

А>Вот что пришло в голову.
Это был я, а не Аноним

Здравствуйте, Sinclair, Вы писали:

S>1. Отслеживать ход расследования. Ну типа дело начато тем-то, ответственным назначен такой-то, передано тому-то в связи с тем-то и т.п. Типичный workflow processing.
Кстати какой workflow? Потому-что если он явно "продвинутый" тогда он может упереться в слабоструктурированные данные ...

S>3. Могучая поисковая енжина. С таким интеллектом, чтобы пользоваться ей мог даже сержант ГИБДД. Ну типа повводили мы данных, а система нам и говорит "ага, мои любезные, хочу вам подсказать, что аналогичный случай имел место в городе Одесса. В связи с чем рекомендую обратить внимание на...". Причем не только не требуя от пользователя нудного указания условий поиска, а лучше и вообще безо всякой инициативы.
По каким принципам выявляются совпадения? Наверное имеет смысл составить табличку соответсвий при подобном поиске!
Идея сводиться к тому чтобы попытаться выйти на какой-то обозримый набор структурированной информации, через предметную область ....

S>4. Отслеживать статистику по расследованиям — ну там типа среднее время закрытия дела, средний процент возврата ущерба, общая сумма ущерба по сравнению с аналогичным периодом прошлого года и т.п.
Итак, список структурированных сущностей и аттрибув всё растёт и растёт

S>Начинаем проектировать. Ага, сущностей-то — всего ничего: дело, персона, улика, да прочий материал.
А как-же те самые улики о которых речь ниже ... вот их-то как-раз немерено

S>В общем мораль такая: что-то не очень у меня выходит нарисовать строго типизированную модель.

S>А главное — не факт, что это надо!
S>С точки зрения п.2, фиксация любой структуры — это
S>а) наличие нуднейшей формы, в которой большинство полей не заполняются никогда
S>б) нехватка полей для ввода какой-то информации, которую мы не предусмотрели.
И ещё проблема на основе какой информации формировать форму? или при добавлении аттрибута к какому-то типу улики делать очередной релиз

S>Таким образом, возникает острое желание заменить это моделью, в которой с любым объектом можно проассоциировать любые именованные атрибуты. Атрибут соответственно может быть либо скаляром, либо вектором. При этом скаляр может быть значением, а может быть и ссылкой.
вот мы и подобрались к самому интересному
S>В общем, чистый джаваскрипт.
не совсем понял причём здесь JavaScript но у фиг с ним ...

S>Однако смущает меня три вопроса:
S>1. Как нам приделать к этому персистенс? Не будет ли "однотабличная" модель, в которой свалены все кусочки данных (objectID, attributeName, attributeValue), слишком медленной?
ни в коем случае ... ужас какой-то !!!
S>2. Как насчет пункта 3?
S>В идеале, система должна выводить "все преступления с таким же почерком". На практике, надо искать
S>а) похожих людей (сходство по любому атрибуту)
S>б) похожие места (в смысле адреса)
S>в) похожие улики (типа поддельный чек выписанный на тот же банк, или там еще что)
S>Вот мне и интересно, есть ли опыт практического решения подобных задач для слабоструктурированных данных (окромя как за.кинуть вообще все в full-text engine, а дальше нехай враги разбираются)
ага, уже занялись структурированием ...


S>Так что вот остановился я и призадумался. Может, ну ее — эту строгую типизацию?
Какой-то странный вывод? Ну допустим выкинули мы строгую типизацию ... и чё дальше?

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

Факты:
1. Есть некоторый набор элементов которые не подвержены изменению структуры
2. Есть наоборот которые очень часто изменяются
3. Нужен поиск, более детально это конструктор поисковых запросов, а в идеале аналитическая система или что-то в этом роде
4. И с этим нужно как-то работать

Если попробовать создать метоописание для данных объектов?
Тоесть в реляционке имеется табличка "Элементы" (ID, Имя, Описание, ...)
Имеется табличка "Аттрибуты" (ID, ID Элемента, Имя, Описание, Тип значения, Размерность, Индексированно, Уникально, и т.д. ...)

Соответсвенно для каждого "Элемента" (в твоём случае это в основном улика, насколько я понимаю) есть некоторый набор аттрибутов ...
Какждый Элемент имеет физическое отражение в БД в виде таблицы, соответственно Аттрибуты имеют отражение в БД как столбцы соответствующей таблицы ...

Добавление новой записи в таблицу Аттрибутов влечёт за собой добавление столбца в соответсвующую таблицу БД
При добавление записи в Таблицу Элементы создаётся новая таблица в БД ...

Тем самым у тебя имеется как сама метамодель данных, так и её структурированное представление в реляционной модели ...
Естественно под всё это нужен дизайнер (или конструктор в зависимости от семантических наклонностей , это так лирическое отступление)

Прикручивать аналитическую систему к структурированным данных оно гораздо приятнее !!!

Здравствуйте, s.ts, Вы писали:

ST>Блокировочник ?
Угу. MS SQL 2000 с перспективой перейти на 2005.

Здравствуйте, Леон, Вы писали:

Л>Здравствуйте, Sinclair, Вы писали:

Л>Кстати какой workflow? Потому-что если он явно "продвинутый" тогда он может упереться в слабоструктурированные данные ...
А вот хрен его знает. С одной стороны, вроде бы описали простой, но в описании упомянуто "настраиваемый". В жизни не поверю, что они захотят что-то там настраивать. Так что скорее всего речь идет именно о передаче дела из одних рук в другие. Статусов пока известно всего два — дело открыто и дело закрыто.

Л>По каким принципам выявляются совпадения?
Хороший вопрос. Вот именно это нам и предстоит изобрести. Ясна проблема — информация, доступная в настоящее время, разрознена. Это замедляет расследования. Поэтому надо самим придумать способ поиска похожих сущностей.
Л>Наверное имеет смысл составить табличку соответсвий при подобном поиске!
Это я не очень понял. Ты имеешь в виду сохранение результатов поиска вместе с делом?
Л>Идея сводиться к тому чтобы попытаться выйти на какой-то обозримый набор структурированной информации, через предметную область ....
Так вот пакость-то в том, что основную часть структуры я уже выписал. А все остальное — прикладной материал.
Л>Итак, список структурированных сущностей и аттрибув всё растёт и растёт
Ага.
Л>А как-же те самые улики о которых речь ниже ... вот их-то как-раз немерено
Вот как только мы переходим от абстрактной улики к ее конкретным типам возникает та самая немерянность.
S>>б) нехватка полей для ввода какой-то информации, которую мы не предусмотрели.
Л>И ещё проблема на основе какой информации формировать форму? или при добавлении аттрибута к какому-то типу улики делать очередной релиз
Ага. Тоже трабл.
Л>не совсем понял причём здесь JavaScript но у фиг с ним ...
А там классов нет. Есть только прототипы. И к любому объекту можно приклеить любой атрибут. При этом есть некоторые прототипы, выданные сразу при запуске.
S>>Вот мне и интересно, есть ли опыт практического решения подобных задач для слабоструктурированных данных (окромя как за.кинуть вообще все в full-text engine, а дальше нехай враги разбираются)
Л>ага, уже занялись структурированием ...
Это ты full-text назщываешь структурированием?

Л>Факты:
Л>1. Есть некоторый набор элементов которые не подвержены изменению структуры
Да.
Л>2. Есть наоборот которые очень часто изменяются
Да.
Л>3. Нужен поиск, более детально это конструктор поисковых запросов, а в идеале аналитическая система или что-то в этом роде
Ну, я не знаю насчет конструктора. Конструктор тут ребята уже сделали. Я бы их уволил. Этим конструктором и человек с высшим образованием-то пользоваться не сможет. Если это не MS in CS.
Л>Если попробовать создать метоописание для данных объектов?
Элемент у тебя — класс или объект?
Л>Тоесть в реляционке имеется табличка "Элементы" (ID, Имя, Описание, ...)

Л>Имеется табличка "Аттрибуты" (ID, ID Элемента, Имя, Описание, Тип значения, Размерность, Индексированно, Уникально, и т.д. ...)

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

Л>Прикручивать аналитическую систему к структурированным данных оно гораздо приятнее !!!
Это да. Но вот ты фактически предложил перевалить структурирование данных на пользователей. Знаешь, я человек скромный, но если сейчас я не могу провести это структурирование, то и пользователи потом точно не смогут.

Здравствуйте, lkurts, Вы писали:

L>Это был я, а не Аноним
Спасибо за ответ. Но я так понял, что Active Directory — строгоструктурированная схема. И основное ее отличие от SQL в том, что она иерархическая.

Здравствуйте, a_b_orlov, Вы писали:

__>Мне думается, что стоит рассмотреть вариант обработки и хранения простого текста. Возможно, стоит выделить еще несколько сущностей (физическое лицо, юридическое лицо, документ, адрес). Остальную информацию хранить в виде текста. В GUI следует предусмотреть возможность пользователю выделять фрагменты текста — ключевые понятия.
Идея классная. Мне нравится.
__>Кроме того, дать возможность классифицировать весь текст по категориям, задаваемым пользователем. Это даст возможность, как полнотекстового поиска, так и быстрого поиска по ключевым словам.
Хм, ты не мог бы пояснить, что ты понимаешь под классификацией по категориям?
__>Сценарий работы пользователя примерно такой: создается дело с четкой атрибутикой (дата, номер …). К нему цепляются эти самые тексты. Прямо в процессе ввода текста — поиск по ключевым словам, которые пользователь выделяет в тексте.
Я это прямо так себе это представляю: рраз правой кнопкой на выделенном — а там менюшечка "Пометить как >" и тут подменю со списком атрибутов. Вот только атрибутов-то у нас может быть очень много... Надо как-то показать наиболее вероятные.
__>В качестве поисковой машины следует использовать что-то вроде Яндекса.
Т.е. Fulltext. Хм. Интересная идея, но имхо не очень реалистичная. Потому как доступный для использования полнотекстовик плохо работает с "ключевыми словами".
__>После ввода текста его можно опционально классифицировать по категориям. Для упрощения работы с ключевыми понятиями можно в редакторе текста предусмотреть шаблоны, в которых можно сделать специальные подсказки, на что следует обратить внимание при составлении документа. Из разметки шаблона можно вытащить атрибуты сущностей адрес, документ и пр.
__>Кроме того, если Ваш клиент милиция (прокуратура, таможня…) или выходцы из нее, то Вы столкнетесь еще и с ужасающей безграмотностью. Поэтому в качестве основного инструмента предлагаю использовать уже знакомый им Word со встроенной проверкой грамотности.
Вот это ты в самую точку угадал! Spellchecker был отдельной строкой потребован в ТЗ с самого начала!

Здравствуйте, Victor Repetsky, Вы писали:

VR>Здравствуйте, s.ts, Вы писали:

ST>>УСХ (универсальная структура хранения) тормозить будет нещадно. Пробовали. Но на оракле.
VR>Работаю с полицейскими системами с 97 года, другие подходы кроме усниверсального не работают.
VR>Каждый месяц могут требоватся новые атрибуты.
VR>Как правильно сказал господин Merle, и как было сказано в исходном посте,
VR>нужна метабаза и аттрибуты (деталировка).
VR>При правильной реализации ничего не тормозит. На Оракле. Пробовали
VR>Пример сущности лицо:
VR>таблица установочный данных: ид, фио, дата, место рождения, пол;
VR>таблица деталировки: ид лица, тип атрибута, занчение атрибута (несколько типов).
VR>Преимущество в том что атрибуты можно добавлять в рантайме,
VR>на скорости поиска это не сказывается. Кроме того можно задавать
VR>множественные атрибуты и почти все что можно придумать туда ложится.
О, вот это очень похоже на то, как я себе это представляю. Особенно про множественность — там почти все может быть множественным. Адреса, имена, телефоны...
А классификацию вы как-то вводили? Т.е. возможность одним взмахом руки добавить целый набор взаимосвязанных атрибутов в сущность?

Здравствуйте, Sinclair, Вы писали:

Л>>По каким принципам выявляются совпадения?
S>Хороший вопрос. Вот именно это нам и предстоит изобрести. Ясна проблема — информация, доступная в настоящее время, разрознена. Это замедляет расследования. Поэтому надо самим придумать способ поиска похожих сущностей.
А если управлять связями? Выделять их в группы, накладывать на них общие правила? И искать уже на оснолве этой информации?

Л>>Наверное имеет смысл составить табличку соответсвий при подобном поиске!
S>Это я не очень понял. Ты имеешь в виду сохранение результатов поиска вместе с делом?
Нет. Это ис предыдушего абзаца, имелось ввиду: выявить по какому принципу (набору аттрибутов) идёт соответсвие при поиске. Тоесть Номер клеше, соотноситься с диапазоном номеров денежных купюр, номером корр счёта, куда были ушли деньги и т.п. (пример абстрактный)

Л>>А как-же те самые улики о которых речь ниже ... вот их-то как-раз немерено
S>Вот как только мы переходим от абстрактной улики к ее конкретным типам возникает та самая немерянность.

Л>>не совсем понял причём здесь JavaScript но у фиг с ним ...
S>А там классов нет. Есть только прототипы. И к любому объекту можно приклеить любой атрибут. При этом есть некоторые прототипы, выданные сразу при запуске.
Всё, теперь понял!

Л>>ага, уже занялись структурированием ...
S>Это ты full-text назщываешь структурированием?
Нет!


S>Ну, я не знаю насчет конструктора. Конструктор тут ребята уже сделали. Я бы их уволил. Этим конструктором и человек с высшим образованием-то пользоваться не сможет. Если это не MS in CS.
Л>>Если попробовать создать метоописание для данных объектов?
S>Элемент у тебя — класс или объект?

Л>>Добавление новой записи в таблицу Аттрибутов влечёт за собой добавление столбца в соответсвующую таблицу БД
Л>>При добавление записи в Таблицу Элементы создаётся новая таблица в БД ...
S>Не, тогда эти две таблицы нафиг не уперлись. В СУБД такие уже есть.
Не совсем, СУБД хранит только нужную для её работы информацию, я же предполагал хранить в этих таблицах свою метаинформацию.

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

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

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


Л>>Прикручивать аналитическую систему к структурированным данных оно гораздо приятнее !!!
S>Это да. Но вот ты фактически предложил перевалить структурирование данных на пользователей. Знаешь, я человек скромный, но если сейчас я не могу провести это структурирование, то и пользователи потом точно не смогут.

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

А насколько пользователь будет ориентироваться в системе уже зависит от того какой доступный будет интерфейс!

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

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

S>>Не, тогда эти две таблицы нафиг не уперлись. В СУБД такие уже есть.
Л>Не совсем, СУБД хранит только нужную для её работы информацию, я же предполагал хранить в этих таблицах свою метаинформацию.
Это, конечно, вопрос исключительно технический и сейчас его обсуждать смысла нет, но я тебе намекну что практически все современные DBMS позволяют хранить свою метаинформацию. Хоть и ограниченную.
Л>Если пользователи не хотят тратить время на поддержание системы, тогда вопрос: а она им нужна? или просто будет полезна?
Ну как тебе сказать. Конечно, им не нужна эта система. Я тебе открою тайну — большинство существующих сегодня видов человеческой деятельности могут жить безо всякой автоматизации. Причина ее внедрения — повышение производительности труда. Никто не будет пользоваться системой, которая экономит полчаса времени в день, и требует еще часа на обслуживание.

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

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

Л>По собственному опыту могу сказать, пользователей очень трудно заставить делать что-то чего они не понимают, но ЭТО ВОЗМОЖНО ...
Л>Обычный человек просто не видит взаимосвязи между тем что ему нужно сделать и тем что ему для этого нужно сделать ...
Вот лично я по своему опыту могу сказать, что если пользователя приходится заставлять сделать что-то, что ему неинтересно, то эффективность такой системы будет стремиться к нулю. Наша задаче не в том, чтобы навязать беззащинтым пользователям наши гири на шею. А в том, чтобы сделать систему, в которой им комфортно работать. По идее, система должна помочь людям с более низкой квалификацией выполнять свою работу. А не потребовать от них дополнительного обучения.
Л>А насколько пользователь будет ориентироваться в системе уже зависит от того какой доступный будет интерфейс!
Интерфейс — всего лишь отражение бизнес-процессов. Сколь бы ни был он красив и удобен, наличие дополнительного звена в цепочке как минимум на порядок сократит частоту использования данной возможности, а также как минимум на сутки задержит выполнение атомарного действия.
Л>Можно воспользоваться такими сценариями как "Запрос на добавление аттрибута", когда пользователь просто опишет тот аттрибут который ему ещё необходим, а уже продвинутый пользователь, который не просто чайник, изменит структуру класса ...
Я тебе как краевед скажу — не бывает продвинутых пользователей. Все пользователи — одинаковые. Надо сделать так, чтобы самый задвинутый пользователь мог успешно пользоваться системой. Без посторонней помощи. Я тебя уверяю — у них и по регламенту хватает головняка с согласованиями и запросами. А если мы еще и свою бюрократию им предложим — все, труба.

Здравствуйте, Sinclair, Вы писали:

S>Я боюсь, что если дать вводить произвольные атрибуты, то мы никаких сопоставлений сделать не сможем. Типа у одного подозреваемого GivenName/Surname, а у другого — FirstName/LastName.
Как раз это -- не очень страшная проблема. Ведь наверняка есть справочник атрибутов, из которого выбирают, и в который вводят новые, если не смогли найти нужные существующие. Делаем имя атрибута из справочника ссылкой на "настоящий" атрибут. Если дать возможность "объединять" атрибуты, т.е. исправлять ошибки дублирования атрибутов в справочнике, то сразу жизнь станет легче. При объединении оба имени остаются, но значение "настоящего" атрибута переписывается для одного из них, чтобы оба имени ссылались на один "настоящий". Это потребует некоторых дополнительных усилий в начале наполнения базы, зато потом уже не будет разницы: GivenName или FirstName. Кто как хочет, тот так и называет, а внутри это одно и то же.

Вот попалось на глаза — по-моему, близко к теме
http://www.osp.ru/os/2004/08/028_print.htm

Здравствуйте, bkat, Вы писали:

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

Здравствуйте, Victor Repetsky, Вы писали:

VR>При правильной реализации ничего не тормозит. На Оракле. Пробовали

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

Здравствуйте, Sinclair, Вы писали:

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


Л>>Если пользователи не хотят тратить время на поддержание системы, тогда вопрос: а она им нужна? или просто будет полезна?
S>Ну как тебе сказать. Конечно, им не нужна эта система. Я тебе открою тайну — большинство существующих сегодня видов человеческой деятельности могут жить безо всякой автоматизации. Причина ее внедрения — повышение производительности труда. Никто не будет пользоваться системой, которая экономит полчаса времени в день, и требует еще часа на обслуживание.
ХА! Удивил! Так задача же в том чтобы найти эту самую золотую середину ... (моё мнение)

Л>>Попробуй проследить кто является инициатором изменения структуры? Как я понял это инициирует именно пользователь, естественно с команды своего начальника, хотя возможно и по собственному усмотрению.
S>Там нет никакого изменения структуры. Вот наш следователь пытается приобщить к делу документ. Ему не надо для этого никакой команды начальника. У него уже есть команда — найти и вернуть как можно больше из причиненного ущерба. Предположим, что этот документ — доверенность на право управления автомобилем. В системе раньше никогда не было таких документов. Если речь идет о каком-то изменении структуры, тем более с команды начальника, то скорее всего эта доверенность так и останется тифф-файлом. А следователь банально сядет на телефон и начнет искать в старом стиле.
S>Нужна возможность добавить к этой доверенности метаатрибуты — имя доверителя, имя доверяющего, данные на автомобиль. Безо всякого изменения структуры чего-либо. И система должна сама рассказать о том, что
Так система же сама не догадается что это доверенность и что у неё есть эти аттрибуты, значит кто-то когда-то должен эту информацию ввести ...

S>- доверитель проходил однажды свидетелем по делу о подделке документов
S>- данный автомобиль служил залогом под выдачу кредита
S>- доверенное лицо имеет задолженность перед банком
Это как-раз те самые возможные взаимосвязи между аттрибутами классов ... их естественно нужно описывать ...

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

Л>>По собственному опыту могу сказать, пользователей очень трудно заставить делать что-то чего они не понимают, но ЭТО ВОЗМОЖНО ...
Л>>Обычный человек просто не видит взаимосвязи между тем что ему нужно сделать и тем что ему для этого нужно сделать ...
S>Вот лично я по своему опыту могу сказать, что если пользователя приходится заставлять сделать что-то, что ему неинтересно, то эффективность такой системы будет стремиться к нулю. Наша задаче не в том, чтобы навязать беззащинтым пользователям наши гири на шею. А в том, чтобы сделать систему, в которой им комфортно работать. По идее, система должна помочь людям с более низкой квалификацией выполнять свою работу. А не потребовать от них дополнительного обучения.
Так если процитировать твой же ответ что: "Система им не нужна", то получается ты ломаешь голову над тем чтобы придумать систему, которая заведома не интересна пользователю ...
Это скорее не твоя проблема, а тех кто её заказывал ...

S>Я тебе как краевед скажу — не бывает продвинутых пользователей. Все пользователи — одинаковые. Надо сделать так, чтобы самый задвинутый пользователь мог успешно пользоваться системой. Без посторонней помощи. Я тебя уверяю — у них и по регламенту хватает головняка с согласованиями и запросами. А если мы еще и свою бюрократию им предложим — все, труба.

Тогда получается что любая система где есть workflow — это бюрократия По сути, наверное, так оно и есть ...

Просто резюмирую получаем:

1. Систему заказали
2. Предъявили требования из разряда "Система ДОЛЖНА додумывать всё сама"
3. В идеале, хотят ввести одну цифру и получиь результат анализа этой цифры по каким-то правилам
3.1 При этом правила вводить никто не хочет
4. Пользователи спокойно могут обойтись без автоматизации, тоесть не видят явных плюсов в её внедрении

Соответсвенно проект кажется утопичным, потому что помоему это из разряда: "ХОЧУ ВСЁ! И НИЧЕГО ПРИ ЭТОМ НЕ ДЕЛАТЬ!"

А кстати кто-нибудь оценивал проект с точки зрения рисков? не просто програмерский взгляд на задачу, а мнение именно эксперта по оценке проектов?
Если нет то наверное стоит это сделать

Здравствуйте, cvoronin, Вы писали:

C>Вот попалось на глаза — по-моему, близко к теме
C>http://www.osp.ru/os/2004/08/028_print.htm
Да, очень близко. К сожалению, иначе как рекламой IBM Content Manager эту статью не назовешь.

Здравствуйте, Леон, Вы писали:

Л>Тогдла какой-то парадокс: Всё изменяется, а изменять при этом ничего не хочется! Если ситема должна догадываться это уже искуственный интелект
Неверно. Не хочется выполнять лишних действий.

Л>ХА! Удивил! Так задача же в том чтобы найти эту самую золотую середину ... (моё мнение)
Лучше найти серебряный край. Zero effort administration. Например, в соответствии с этой концепцией построен MS SQL. Да, там при желании есть за что покрутить. Но он, в отличие от многих других систем, способен функционировать годами без вмешательства DBA. И при этом вполне успешно справляться с нагрузкой.
Л>Так система же сама не догадается что это доверенность и что у неё есть эти аттрибуты, значит кто-то когда-то должен эту информацию ввести ...
Да, должен. Но мы должнгы дать эту возможность именно тому человеку, который держит в руках доверенность. Безо всяких служебных записок "Главному админу новой системы. Для выполнения следственных мероприятий по делу №... прошу обеспечить представление в системе данных о документах типа "доверенность", описание структуры документа в ISDEF прилагаю..."
Л>Это как-раз те самые возможные взаимосвязи между аттрибутами классов ... их естественно нужно описывать ...
Неа. Хочу решение, при котором их не надо описывать. Потому, что иначе мы будем иметь экспоненциальный взрыв возможного количества взаимосвязей, и никто просто не будет все это руками вводить.
S>>Нереально. Этим мы создадим узкое место в системе, а также потребуем у заказчика изменения штатной структуры.
Л>По моему, не факт, что нужно будет изменять штатную структуру. Относительно узкого места, ничего сказать не могу, это субъективный фактор конкретного заказчика.
Ничего субъективного тут нет. Как только мы вводим штатную единицу "продвинутого пользователя", то через него начинают проходить все запросы. И если он тормозит, то весь бизнес встал. Требовать от заказчика поднимать уровень рядовых пользователей — самоубийство. Наймут более компетентных девелоперов.
Л>Так если процитировать твой же ответ что: "Система им не нужна", то получается ты ломаешь голову над тем чтобы придумать систему, которая заведома не интересна пользователю ...
Л>Это скорее не твоя проблема, а тех кто её заказывал ...
Нет. Им не нужна система ради системы. У них до хрена своей работы есть, чтобы еще и техобслуживанием заниматься.
Л>Тогда получается что любая система где есть workflow — это бюрократия По сути, наверное, так оно и есть ...
Нет, просто есть "натуральный" workflow, а есть "искусственный". Вот получение менеджером отчета о прибылях для выступления на совете директоров — это натуральный воркфлов, а обращение к айти отделу за дотачиванием кода генератора отчета — это искусственный. Вот этого воркфлов быть вообше не должно.

Л>1. Систему заказали
Л>2. Предъявили требования из разряда "Система ДОЛЖНА додумывать всё сама"
Нет, не предъявили. Описали проблему.
Л>3. В идеале, хотят ввести одну цифру и получиь результат анализа этой цифры по каким-то правилам
Примерно так.
Л> 3.1 При этом правила вводить никто не хочет
Естественно! Потому что этих правил — больше чем цифр.
Л>4. Пользователи спокойно могут обойтись без автоматизации, тоесть не видят явных плюсов в её внедрении
Они не увидят плюсов во внедрении системы, которая потребует от них больше времени и усилий на выполнение той же работы.
Л>Соответсвенно проект кажется утопичным, потому что помоему это из разряда: "ХОЧУ ВСЁ! И НИЧЕГО ПРИ ЭТОМ НЕ ДЕЛАТЬ!"
Ну мне вот интуитивно кажется, что все должно получиться именно так.
Ну вот к примеру амазон предлагает посетителю к каждой книге еще и related и frequently bought together. Я тебя уверяю — если бы они потребовали от менеджеров руками указывать, какая книга к какой относится, и какие книги часто покупают вместе, то оба списка были бы пусты. Потому, что при жалкой тысяче наименований потенциальных пар "схожа с..." будет миллион. Предлагаю в качестве домашнего задания оценить трудозатраты на заполнение такой базы.
Л>А кстати кто-нибудь оценивал проект с точки зрения рисков? не просто програмерский взгляд на задачу, а мнение именно эксперта по оценке проектов?
Я не в курсе. Но до выяснения основных требований и предполагаемой архитектуры все разговоры о рисках — спекуляция.

Здравствуйте, Sinclair, Вы писали:

Интересное решение ...
коментарии ниже ...

S>Здравствуйте, a_b_orlov, Вы писали:

__>>Сценарий работы пользователя примерно такой: создается дело с четкой атрибутикой (дата, номер …). К нему цепляются эти самые тексты. Прямо в процессе ввода текста — поиск по ключевым словам, которые пользователь выделяет в тексте.
S>Я это прямо так себе это представляю: рраз правой кнопкой на выделенном — а там менюшечка "Пометить как >" и тут подменю со списком атрибутов. Вот только атрибутов-то у нас может быть очень много... Надо как-то показать наиболее вероятные.
Если базовой платформой ввода сделать MS Word, тогда имеет смысл покапать такую технологию на Smart Tags и Smart Documents ..
презентацию можно посмотреть здесь Новые средства разработки в Microsoft Office System 2003 для автоматизации бизнес-процессов. ...

Здравствуйте, cvoronin, Вы писали:

C>Вот попалось на глаза — по-моему, близко к теме
C>http://www.osp.ru/os/2004/08/028_print.htm

Я внедрял IBM CM в гос. архиве, это чистой воды Content Management система с очень большим дополнительным функционалом, основной плюс которой это способность работать с терабайтами данных ...

Относительно неструктурированности: в CM есть понятие ItemType это фактически класс, прежде чем создавать экземпляры ты декларируешь структуру этого класса. После того как создан хотябы один экземпляр класса (ItemType'а) ты можешь только добавить новый атрибут и больше ничего ...
Вся метаинформация храниться в DB2 ...

Здравствуйте, s.ts, Вы писали:

b>> Речь не о самой ЭС, а о том, как в них могут быть представлены знания и
b>> данные. Это как раз тебе и могло бы пригодится.
b>> Проблемы с представлением и использованием
b>> противоречивых и неполных данных — это классика в ЭС.

ST>Кстати, накидай плиз ссылок на это.
Питер Джексон. Введение в экспертные системы. — М.: Издательский дом "Вильямс", 2001.
Есть в электронном виде здесь.

Здравствуйте, Sinclair, Вы писали:

S>А классификацию вы как-то вводили? Т.е. возможность одним взмахом руки добавить целый набор взаимосвязанных атрибутов в сущность?

Не совсем понял про классификацию. Групповые аттрибуты поддерживаются. Для редактирования метаинформации сделан специальный пользовательский интерфейс.
Для всех связей используется таблица связей (опять же для возможности добавлять типы связей между сущностями в рантайм).
Еще делали спейциальный интрефейс для редактирования/просмотра сущностей и их связей в визуальном режиме — сущности как иконки, связи как стрелочки (наряду с умными запросами — очень мощное средство).
Проблему с ошибками в фамилиях и поиском лиц решали специальными алгоритмами.
Наиболее сложная часть системы — обработка метаинформации.
Вообще посмотри на какие-нибудь существующее системы (даже если они ужасны и написаны на фоксе, по крайней мере лучше можно понять
задачу и ее осбенности).
Слышал что неплохая есть в AviComp (http://www.avicomp.ru/rus/tais/projects.php).
Есть еще Сипол (к сожалению нашел только упоминание http://www.computerra.ru/offline/1997/182/382/?print).
Нашу могу показать если будешь в Киеве .

Всего хорошего.
Виктор.