Насчет границ — оно в принципе правильно, а насчет континуума я бы поспорил, но это оффтопик.
Интереснее поговорить о том, что разделить физическое событие и его субъективную интерпретацию получится не всегда. И нужно не всегда. Например, Куликовская битва — на первый взгляд, физическое событие, а начни копать — окажется, что субъективное (на Бородинском сражении это лучше видно). Ну или, по крайней мере, мы нагружаем физическое событие такими субъективными смыслами, что само физическое событие за ними несколько теряется. И нам, с прагматической точки зрения, эти субъективные смыслы гораздо интереснее.
Например, я пишу программу, которая контролирует состояние сложного промышленного оборудования. Сработал датчик: давление в таком-то узле = x1 МПа. Это — вроде бы, физическое событие (об этом далее). Но меня интересует не оно как таковое, а то, что значение превысило критический уровень x0, и теперь это событие для меня называется «Выход за пределы штатного режима работы устройства, несущее риск разрушения его конструкции». Причем эта формулировка взята из какого-нибудь нормативного или регулирующего документа, и я ее не могу изменить. Таким образом, я перехожу из физического контекста в чужой субъективный контекст. И в этом контексте, опять же в соответствии с регламентом, я (ну, то есть программа) должен оповестить дежурную смену, включить аварийный сброс давления, и еще чтобы загорелась красная лампочка под потолком в цехе. Типичный бизнес-процесс, на самом деле. Когда я все это делаю, конкретное значение давления в узле меня уже вообще не волнует.
То есть, вы закончили правильной для меня мыслью — что физический объект обретает прагматической смысл после того, как его интерпретировали; но мне кажется, что разделить физический объект и его смысл мы можем опять-таки только умозрительно и произвольно. Это выводит на тяжелое рассуждение о том, что вообще такое «объективная реальность». На самом простом уровне — понятно, что и «давление x1 МПа» тоже вовсе не физическое событие, а такая же абстракция; что показания датчика, даже не интерпретированные в мегапаскалях, есть лишь абстракция того, что на самом деле происходит в узле; и вообще, начиная о чем-то говорить или думать словами (или даже ощущениями), мы его тут же субъективируем. И нет никакого способа познать или описать «объективную», или «физическую» сторону объекта. И само выделение объектов из окружающего мира столь же субъективно.
Короче говоря, это все возвращает меня к рассуждению о прагматике. Не надо пытаться построить «объективную» или «правильную» модель. Надо построить такую модель, которая поможет мне предотвратить взрыв узла из-за избыточного давления — и этого достаточно.
Насчет события я специально не стал с вами спорить :) В принципе, ваш вывод, что событие есть 4D-объект, временными размерами которого можно пренебречь — правилен, по крайней мере в определенном отношении.
Можно порассуждать на тему того, в каких контекстах вообще нужно (и полезно) понятие события. Этот вопрос напрямую связан со структурой модели, и способом моделирования.
Чаще всего модели выполняются по шагам. Есть состояние A1, выполняется шаг по времени dt, и система оказывается в состоянии A2. Это — дискретное моделирование. В нем есть четкие границы между состояниями, и легче говорить о событиях в чистом виде, привязывая их к шагам моделирования. Такой способ выполнения модели стимулирует модельера придумывать состояния и события (об этом далее).
Но что будет в случае непрерывного моделирования? Например, пусть у нас яркость маяка задана некой математической функцией, той же синусоидой. Тогда мы можем определить значение яркости на любой момент времени, никакого шага dt у такой модели нет. Состояния модели тоже образуют непрерывный континуум. Что будет событием в этой системе? В лучшем случае, можно назвать событиями особые точки кривых, предположим — максимум и минимум светимости маяка. По-моему, это некоторая натяжка. В любом случае, такая трактовка полезна только для наблюдения за моделью, для поиска в ней этих самых событий. Смысл понятия «событие» несколько меняется.
Если у того, что мы хотим назвать событием, ненулевая продолжительность, то это однозначно не событие, а подпроцесс, который можно подвергнуть дальнейшей декомпозиции. С точки зрения строгой логики мы не можем назвать событием «вхождение в атмосферу» (а в житейском смысле — можем). Если мы будем рассматривать давление среды за бортом космического судна как непрерывную функцию (это легко можно сделать), то не будет никакой границы атмосферы. Если мы ее не придумаем произвольно, сказав, что при давлении P0 у нас внезапно началась атмосфера. Но тогда это будет событие, которое произошло только у нас в голове, но никак не в реальности. Его прагматика крайне сомнительна, поскольку по факту нас будет интересовать не словесное определение того, где находится корабль — «в космосе» или «в атмосфере», а значение сопротивления среды его движению, которое от наших слов никак не зависит. Для описания значения сопротивления понятие «вход в атмосферу» не нужно — оно тоже описывается непрерывной функцией. А вот если мы моделируем дискретно, то, чем больше dt (чем грубее модель), тем больше будет интеллектуальный соблазн выделить «вход в атмосферу» как событие.
Если мы говорим не о физическом моделировании, а о моделировании бизнес-процессов, то понятие «событие» часто будет соответствовать моменту поступления информации об изменении внешней среды, или волевым актам участников процесса. Например, я даю распоряжение на покупку чего-либо своему подчиненному. Мое говорение об этом, или написание документа, занимает какое-то время, но с точки зрения БП это совершенно не существенно. И — да — событие привело к изменению состояния: до этого подчиненный был в состоянии idle, после этого перешел в состояние working (с моей точки зрения). Так можно делать, с практической целью, но не вредно помнить о том, что все эти состояния подчиненного есть придуманные нами абстракции. Все это жутко субъективно. Есть хрестоматийный пример о том, что для француза «победитель при Бородино» — Наполеон, а для русского «победитель при Бородино» — Кутузов. Получается, в зависимости от субъекта один и тот же интенсионал соответствует разным экстенсионалам. С моей точки зрения, работник бездельничает, а с его — работает. С моей точки зрения корабль в атмосфере, а с точки зрения зеленых человечков — в космосе. Короче, все это имеет смысл в том случае, если сам результат моделирования, который нас интересует, выражен в тех же терминах, находится в том же самом контексте, в котором мы определяем события. То есть, мы не задаем модели вопрос «В какой момент времени корабль коснется Земли?», а спрашиваем у нее «Когда корабль войдет в атмосферу?». Тогда мы имеем право придумывать любые состояния и события, и оперировать ими, как нам угодно.
Понимание предметной области — и есть моделирование. Мысленное. И оно тоже прагматично.
Грубо говоря, блондинке достаточно представлять автомобиль как черный ящик с двумя педалями и рулем. Автомеханику нужна другая модель автомобиля.
Мне вот еще что кажется важным. Не стоит говорить о методике моделирования, не говоря о ее практическом применении. Из этого может родиться ощущение, что есть более или менее «правильные» методики.
На самом деле есть методики, которые решают конкретный класс задач, и есть методики, которые их не решают (ну или решают, но с избыточными затратами). Появление не решаемых известными средствами классов задач влечет необходимость в развитии методик моделирования.
Говоря о моделировании деятельности предприятия, надо тоже сразу думать о том, как мы будем применять эту модель. Если ее прагматика в том, чтобы распечатать процессы на больших красивых плакатах, повесить в переговорке, и положить в отчет для инвесторов, то подойдет и Aris, и BPMN, все что угодно — никаких проблем.
Если прагматика в том, чтобы на основании модели написать ТЗ на внедрение типовой программной системы, и должностные инструкции для сотрудников — то, скорее всего, тоже указанных нотаций хватит. Более того, применение более совершенных («правильных») методик моделирования будет вредным, так как редкий исполнитель сможет ими воспользоваться.
Если же задача, например, в том, чтобы возложить управление процессом на информационную систему, причем не путем выполнения каких-то заранее запрограммированных или сконфигурированных последовательностей действий, а путем симуляции принятия решений с оценкой их последствий, поиска оптимальных решений в неизвестной заранее ситуации — тогда да, нужна куда более совершенная модель, причем не только самого процесса, но и окружения, в котором он происходит.
Здесь важно не увлечься с широтой и глубиной охвата, в погоне за «правильностью». Рациональный уровень детализации и сложности модели можно посчитать, исходя из ожидаемого экономического эффекта от ее применения, и стоимости создания/поддержки модели. Это и есть критерий приемлемости тех допущений и пренебрежений, которые мы делаем при моделировании.
Сформулирую общий критерий проверки правильности модели процесса с прагматической точки зрения. Фрагмент реальности и его модель связаны отношениями подобия, через которые выражаются те правила, которые заложены в выбранной методике моделирования. Методику мы выбрали исходя из приемлемого для наших задач уровня абстракции, по описанному выше принципу.
У моделируемого процесса есть исходное и конечное состояния. При помощи отношений подобия мы можем «отразить» их в модель. Так вот, если результат протекания процесса в реальном мире, отраженный в модель, и результат протекания модели процесса в самой модели, будут отличаться не более, чем на устраивающую нас величину погрешности — значит, модель пригодна. На диаграмме это можно показать так:
Из этого легко видеть, что модель может быть сколь угодно простой и примитивной. Это нормально, пока она позволяет достигать результата.
Ясно, интересно.
У нас тоже кое-какие данные поступают снаружи, от других систем; поэтому и понадобилось делать контроль на уровне triple store, а не в пользовательском интерфейсе редактора данных. Каждая внешняя система имеет свой пользовательский аккаунт, который разрешает ей вносить изменения только в определенную часть данных — так страхуемся от чужих багов, или злоумышленников с доступом к сторонней системе. Тут все внутри компании, и весьма строго по политике безопасности.
SDShare, насколько я помню, реплицирует данные между несколькими хранилищами в виде, по сути, файлов RDF. У нас не совсем такая ситуация, поскольку данные в семантической форме присутствуют пока только в одной точке — в самом MDM. Для остальных систем MDM выглядит как сервис, т.е. все данные он никогда никому не отдает — только по частям, и чаще всего — в ответ на запрос (или, наоборот, в активном режиме — по подписке).
Кстати, с репликацией и де-факто кластеризацией Triple Store мы тоже наплясались, но это тема, которую я пока не готов раскрывать. Там у нас распределенная архитектура, т.е. сам Triple Store живет на нескольких серверах, хотя снаружи выглядит как одна целостная система.
Проект, где идет в чистом виде сбор информации со сторонних источников, у нас тоже был: http://energopravda.ru
Там, конечно, все проще. Роботы разбирают разные источники, и льют контент в общую базу.
Проблему версионирования решили в рамках другой разработки, скоро доложим на KESW 2014.
По производительности делали кое-какой бенчмарк в прошлом году.
В личку могу поделиться результатами.
CRM и ERP интегрировать можно и нужно. Лично я участвовал в двух таких проектах (будучи подрядчиком со стороны CRM). Без интеграции ценность систем существенно снижается. Пример из жизни: в ERP есть информация об отгрузках клиентам (не просто когда чего и сколько грузилось, а еще и на какой адрес грузополучателя, из чего следует число дней в пути, из чего в свою очередь следует отсрочка платежа). Эта информация необходима, чтобы рассчитать просроченную задолженность, и количество дней просрочки — эти сведения менеджеру необходимо видеть в CRM, когда он общается с клиентом.
Чтобы реализовать такую интеграцию, нужно как минимум синхронизировать справочники клиентов и номенклатуры. Задача расчета задолженности влечет необходимость в синхронизации сведений об отгрузках и платежах. Нельзя просто переносить готовое значение задолженности, рассчитанное для каждого клиента на текущий день — необходимо иметь всю историю взаиморасчетов, чтобы иметь возможность наблюдать динамику задолженности. Условия договоров с клиентом тоже меняются со временем (размер и давность допустимой отсрочки), так что четвертое измерение данных — время — становится еще более важным.
Тем не менее, такие задачи решаются даже вполне тривиальными средствами обмена (если мы говорим о взаимодействии двух систем). А если систем больше, или, как пишет автор, в них слишком сильно отличается структуры информации — милости просим к нам в семантические технологии интеграции.
Получил ответ от разработчиков. Говорят, что сервер онтологий Ontorion будет предоставляться в основном облаке (хотя, видимо, будет возможна и локальная установка при необходимости), и является проприетарным, так что исходный код открывать не будут. Однако, планируют опубликовать его API.
А в рамках какого проекта вы этим занимались, если не секрет? (в смысле, вытаскиванием с естественного русского языка)
У нас сейчас идет проект, в котором, на самом деле, хотелось бы прийти к чему-то подобному. В качестве библиотеки-основы рассматривается JORD RDL, вопрос сейчас стоит в выборе инструмента для работы.
Насчет исходного кода — задам им вопрос.
Общую информацию об Ontorion можно посмотреть здесь: http://www.cognitum.eu/semantics/Ontorion/
Мне они также давали доступ в консоль. У фреймворка есть веб-интерфейс, в котором можно делать все то же самое, что в редакторе.
Выражение is not он понимает.
Насчет дефисов согласен; причем, в одних случаях выражения пишутся без дефисов (is a), в других — с дефисами.
Понятно, что это не вполне естественный язык; главная «фишка», которую я хотел отразить, состоит в том, что с таким редактором гораздо проще работать, скажем, инженеру, который много знает о предметной области, но ничего не знает об онтологиях. Научить такого инженера работать в Protege или TopBraid Composer'е было бы сложнее.
Я знаком с этим стандартом, и являюсь читателем этого сообщества. Тут все далеко не так просто, и на тему отношения нашего подхода и ISO 15926 я также писал отдельную статью. Кстати, в том самом сообществе хватает «критики», а точнее, не совсем разумного противопоставления Semantic Web и ISO 15926. С одной стороны, понятно, что стандарт представляет собой более высокоуровневый подход, с другой — я уверен, что во многих практических применениях наш подход намного рациональнее.
1. Набор триплетов. Буквально сегодня выложил статью об определении оптимального количества информационных объектов и триплетов в пакете
2. Исходящая система определяется в процессе авторизации, дата создания тоже автоматически фиксируется сервером. Но некоторые атрибуты сообщения все же попадают в само сообщение.
3. Пока также передаем, но имеется насущная необходимость разработать режим передачи табличных данных (прежде всего, для первоначальной синхронизации систем) — этим сейчас занимаемся.
Спасибо за интерес к посту! Отвечаю.
1. Обоими способами. Каждая клиентская система обладает только той частью общей онтологии, которая ей нужна. Плюс на сервере есть настройки прав доступа — в визуальном интерфейсе администратор может настроить, какие элементы онтологии будут доступны каким системам (на чтение и на запись). Есть функция выгрузки онтологии с сервера на клиент: сервер передает клиенту часть общей онтологии, отфильтрованную в соответствии с правами доступа.
2. По идее, такие ситуации должны предупреждаться настройкой прав, но если, скажем, две системы имеют право изменять одно и тоже свойство, к примеру телефон клиента, и делают это одновременно — «победит» та, чье сообщение будет позже доставлено серверу. Ее версия значения и будет распространена всем системам.
3. До версионирования пока не добрались, хотя проблема очень актуальна. Производительностью как раз сейчас занимаемся, много что оптимизируем под нее. Надеюсь в ближайшее время написать статью на эту тему.
Интереснее поговорить о том, что разделить физическое событие и его субъективную интерпретацию получится не всегда. И нужно не всегда. Например, Куликовская битва — на первый взгляд, физическое событие, а начни копать — окажется, что субъективное (на Бородинском сражении это лучше видно). Ну или, по крайней мере, мы нагружаем физическое событие такими субъективными смыслами, что само физическое событие за ними несколько теряется. И нам, с прагматической точки зрения, эти субъективные смыслы гораздо интереснее.
Например, я пишу программу, которая контролирует состояние сложного промышленного оборудования. Сработал датчик: давление в таком-то узле = x1 МПа. Это — вроде бы, физическое событие (об этом далее). Но меня интересует не оно как таковое, а то, что значение превысило критический уровень x0, и теперь это событие для меня называется «Выход за пределы штатного режима работы устройства, несущее риск разрушения его конструкции». Причем эта формулировка взята из какого-нибудь нормативного или регулирующего документа, и я ее не могу изменить. Таким образом, я перехожу из физического контекста в чужой субъективный контекст. И в этом контексте, опять же в соответствии с регламентом, я (ну, то есть программа) должен оповестить дежурную смену, включить аварийный сброс давления, и еще чтобы загорелась красная лампочка под потолком в цехе. Типичный бизнес-процесс, на самом деле. Когда я все это делаю, конкретное значение давления в узле меня уже вообще не волнует.
То есть, вы закончили правильной для меня мыслью — что физический объект обретает прагматической смысл после того, как его интерпретировали; но мне кажется, что разделить физический объект и его смысл мы можем опять-таки только умозрительно и произвольно. Это выводит на тяжелое рассуждение о том, что вообще такое «объективная реальность». На самом простом уровне — понятно, что и «давление x1 МПа» тоже вовсе не физическое событие, а такая же абстракция; что показания датчика, даже не интерпретированные в мегапаскалях, есть лишь абстракция того, что на самом деле происходит в узле; и вообще, начиная о чем-то говорить или думать словами (или даже ощущениями), мы его тут же субъективируем. И нет никакого способа познать или описать «объективную», или «физическую» сторону объекта. И само выделение объектов из окружающего мира столь же субъективно.
Короче говоря, это все возвращает меня к рассуждению о прагматике. Не надо пытаться построить «объективную» или «правильную» модель. Надо построить такую модель, которая поможет мне предотвратить взрыв узла из-за избыточного давления — и этого достаточно.
Можно порассуждать на тему того, в каких контекстах вообще нужно (и полезно) понятие события. Этот вопрос напрямую связан со структурой модели, и способом моделирования.
Чаще всего модели выполняются по шагам. Есть состояние A1, выполняется шаг по времени dt, и система оказывается в состоянии A2. Это — дискретное моделирование. В нем есть четкие границы между состояниями, и легче говорить о событиях в чистом виде, привязывая их к шагам моделирования. Такой способ выполнения модели стимулирует модельера придумывать состояния и события (об этом далее).
Но что будет в случае непрерывного моделирования? Например, пусть у нас яркость маяка задана некой математической функцией, той же синусоидой. Тогда мы можем определить значение яркости на любой момент времени, никакого шага dt у такой модели нет. Состояния модели тоже образуют непрерывный континуум. Что будет событием в этой системе? В лучшем случае, можно назвать событиями особые точки кривых, предположим — максимум и минимум светимости маяка. По-моему, это некоторая натяжка. В любом случае, такая трактовка полезна только для наблюдения за моделью, для поиска в ней этих самых событий. Смысл понятия «событие» несколько меняется.
Если у того, что мы хотим назвать событием, ненулевая продолжительность, то это однозначно не событие, а подпроцесс, который можно подвергнуть дальнейшей декомпозиции. С точки зрения строгой логики мы не можем назвать событием «вхождение в атмосферу» (а в житейском смысле — можем). Если мы будем рассматривать давление среды за бортом космического судна как непрерывную функцию (это легко можно сделать), то не будет никакой границы атмосферы. Если мы ее не придумаем произвольно, сказав, что при давлении P0 у нас внезапно началась атмосфера. Но тогда это будет событие, которое произошло только у нас в голове, но никак не в реальности. Его прагматика крайне сомнительна, поскольку по факту нас будет интересовать не словесное определение того, где находится корабль — «в космосе» или «в атмосфере», а значение сопротивления среды его движению, которое от наших слов никак не зависит. Для описания значения сопротивления понятие «вход в атмосферу» не нужно — оно тоже описывается непрерывной функцией. А вот если мы моделируем дискретно, то, чем больше dt (чем грубее модель), тем больше будет интеллектуальный соблазн выделить «вход в атмосферу» как событие.
Если мы говорим не о физическом моделировании, а о моделировании бизнес-процессов, то понятие «событие» часто будет соответствовать моменту поступления информации об изменении внешней среды, или волевым актам участников процесса. Например, я даю распоряжение на покупку чего-либо своему подчиненному. Мое говорение об этом, или написание документа, занимает какое-то время, но с точки зрения БП это совершенно не существенно. И — да — событие привело к изменению состояния: до этого подчиненный был в состоянии idle, после этого перешел в состояние working (с моей точки зрения). Так можно делать, с практической целью, но не вредно помнить о том, что все эти состояния подчиненного есть придуманные нами абстракции. Все это жутко субъективно. Есть хрестоматийный пример о том, что для француза «победитель при Бородино» — Наполеон, а для русского «победитель при Бородино» — Кутузов. Получается, в зависимости от субъекта один и тот же интенсионал соответствует разным экстенсионалам. С моей точки зрения, работник бездельничает, а с его — работает. С моей точки зрения корабль в атмосфере, а с точки зрения зеленых человечков — в космосе. Короче, все это имеет смысл в том случае, если сам результат моделирования, который нас интересует, выражен в тех же терминах, находится в том же самом контексте, в котором мы определяем события. То есть, мы не задаем модели вопрос «В какой момент времени корабль коснется Земли?», а спрашиваем у нее «Когда корабль войдет в атмосферу?». Тогда мы имеем право придумывать любые состояния и события, и оперировать ими, как нам угодно.
Грубо говоря, блондинке достаточно представлять автомобиль как черный ящик с двумя педалями и рулем. Автомеханику нужна другая модель автомобиля.
На самом деле есть методики, которые решают конкретный класс задач, и есть методики, которые их не решают (ну или решают, но с избыточными затратами). Появление не решаемых известными средствами классов задач влечет необходимость в развитии методик моделирования.
Говоря о моделировании деятельности предприятия, надо тоже сразу думать о том, как мы будем применять эту модель. Если ее прагматика в том, чтобы распечатать процессы на больших красивых плакатах, повесить в переговорке, и положить в отчет для инвесторов, то подойдет и Aris, и BPMN, все что угодно — никаких проблем.
Если прагматика в том, чтобы на основании модели написать ТЗ на внедрение типовой программной системы, и должностные инструкции для сотрудников — то, скорее всего, тоже указанных нотаций хватит. Более того, применение более совершенных («правильных») методик моделирования будет вредным, так как редкий исполнитель сможет ими воспользоваться.
Если же задача, например, в том, чтобы возложить управление процессом на информационную систему, причем не путем выполнения каких-то заранее запрограммированных или сконфигурированных последовательностей действий, а путем симуляции принятия решений с оценкой их последствий, поиска оптимальных решений в неизвестной заранее ситуации — тогда да, нужна куда более совершенная модель, причем не только самого процесса, но и окружения, в котором он происходит.
Здесь важно не увлечься с широтой и глубиной охвата, в погоне за «правильностью». Рациональный уровень детализации и сложности модели можно посчитать, исходя из ожидаемого экономического эффекта от ее применения, и стоимости создания/поддержки модели. Это и есть критерий приемлемости тех допущений и пренебрежений, которые мы делаем при моделировании.
Сформулирую общий критерий проверки правильности модели процесса с прагматической точки зрения. Фрагмент реальности и его модель связаны отношениями подобия, через которые выражаются те правила, которые заложены в выбранной методике моделирования. Методику мы выбрали исходя из приемлемого для наших задач уровня абстракции, по описанному выше принципу.
У моделируемого процесса есть исходное и конечное состояния. При помощи отношений подобия мы можем «отразить» их в модель. Так вот, если результат протекания процесса в реальном мире, отраженный в модель, и результат протекания модели процесса в самой модели, будут отличаться не более, чем на устраивающую нас величину погрешности — значит, модель пригодна. На диаграмме это можно показать так:
Из этого легко видеть, что модель может быть сколь угодно простой и примитивной. Это нормально, пока она позволяет достигать результата.
У нас тоже кое-какие данные поступают снаружи, от других систем; поэтому и понадобилось делать контроль на уровне triple store, а не в пользовательском интерфейсе редактора данных. Каждая внешняя система имеет свой пользовательский аккаунт, который разрешает ей вносить изменения только в определенную часть данных — так страхуемся от чужих багов, или злоумышленников с доступом к сторонней системе. Тут все внутри компании, и весьма строго по политике безопасности.
SDShare, насколько я помню, реплицирует данные между несколькими хранилищами в виде, по сути, файлов RDF. У нас не совсем такая ситуация, поскольку данные в семантической форме присутствуют пока только в одной точке — в самом MDM. Для остальных систем MDM выглядит как сервис, т.е. все данные он никогда никому не отдает — только по частям, и чаще всего — в ответ на запрос (или, наоборот, в активном режиме — по подписке).
Кстати, с репликацией и де-факто кластеризацией Triple Store мы тоже наплясались, но это тема, которую я пока не готов раскрывать. Там у нас распределенная архитектура, т.е. сам Triple Store живет на нескольких серверах, хотя снаружи выглядит как одна целостная система.
Проект, где идет в чистом виде сбор информации со сторонних источников, у нас тоже был: http://energopravda.ru
Там, конечно, все проще. Роботы разбирают разные источники, и льют контент в общую базу.
По производительности делали кое-какой бенчмарк в прошлом году.
В личку могу поделиться результатами.
Чтобы реализовать такую интеграцию, нужно как минимум синхронизировать справочники клиентов и номенклатуры. Задача расчета задолженности влечет необходимость в синхронизации сведений об отгрузках и платежах. Нельзя просто переносить готовое значение задолженности, рассчитанное для каждого клиента на текущий день — необходимо иметь всю историю взаиморасчетов, чтобы иметь возможность наблюдать динамику задолженности. Условия договоров с клиентом тоже меняются со временем (размер и давность допустимой отсрочки), так что четвертое измерение данных — время — становится еще более важным.
Тем не менее, такие задачи решаются даже вполне тривиальными средствами обмена (если мы говорим о взаимодействии двух систем). А если систем больше, или, как пишет автор, в них слишком сильно отличается структуры информации — милости просим к нам в семантические технологии интеграции.
У нас сейчас идет проект, в котором, на самом деле, хотелось бы прийти к чему-то подобному. В качестве библиотеки-основы рассматривается JORD RDL, вопрос сейчас стоит в выборе инструмента для работы.
Общую информацию об Ontorion можно посмотреть здесь: http://www.cognitum.eu/semantics/Ontorion/
Мне они также давали доступ в консоль. У фреймворка есть веб-интерфейс, в котором можно делать все то же самое, что в редакторе.
Насчет дефисов согласен; причем, в одних случаях выражения пишутся без дефисов (is a), в других — с дефисами.
Понятно, что это не вполне естественный язык; главная «фишка», которую я хотел отразить, состоит в том, что с таким редактором гораздо проще работать, скажем, инженеру, который много знает о предметной области, но ничего не знает об онтологиях. Научить такого инженера работать в Protege или TopBraid Composer'е было бы сложнее.
2. Исходящая система определяется в процессе авторизации, дата создания тоже автоматически фиксируется сервером. Но некоторые атрибуты сообщения все же попадают в само сообщение.
3. Пока также передаем, но имеется насущная необходимость разработать режим передачи табличных данных (прежде всего, для первоначальной синхронизации систем) — этим сейчас занимаемся.
1. Обоими способами. Каждая клиентская система обладает только той частью общей онтологии, которая ей нужна. Плюс на сервере есть настройки прав доступа — в визуальном интерфейсе администратор может настроить, какие элементы онтологии будут доступны каким системам (на чтение и на запись). Есть функция выгрузки онтологии с сервера на клиент: сервер передает клиенту часть общей онтологии, отфильтрованную в соответствии с правами доступа.
2. По идее, такие ситуации должны предупреждаться настройкой прав, но если, скажем, две системы имеют право изменять одно и тоже свойство, к примеру телефон клиента, и делают это одновременно — «победит» та, чье сообщение будет позже доставлено серверу. Ее версия значения и будет распространена всем системам.
3. До версионирования пока не добрались, хотя проблема очень актуальна. Производительностью как раз сейчас занимаемся, много что оптимизируем под нее. Надеюсь в ближайшее время написать статью на эту тему.