BOROsolutions продолжает радовать эпистемологии
Оригинал взят у ailev в BOROsolutions продолжает радовать
Метод BORO продолжает развиваться. Основанная на его идеях онтология IDEAS продолжает переваривать DoDAF и MoDAF (что нам не так интересно), но оттуда продолжают вываливаться интересные теоретические работы про связь онтологической хардкорной науки и наколенной программной инженерии. Вот свеженькое: http://www.borosolutions.co.uk/solutions/content/files/2012-07%20-%20Ontology%20meets%20Big%20Data%20-%20Keynote%20-%20ODISE%20IV%20-%20FOIS2012%20-Presentation%20-%20show.ppsx/view (сохранять и смотреть нужно не как .zip, а сразу в PowerPoint, это файл слайдовой презентации -- там какая-то путаница с расширениями).
Я вот всё время думаю мысль, что IT -- это чиста конкректна синтаксическая штука. И если IT-транзакция и/или IT-объекты (типы) криво соответствуют объектам/типам, отражающим предметную область пользователя, то хорошо не будет -- какие бы ухищрения бы ни делались на этом "синтаксическом" уровне. Конечно, если делать BORO на уровне микропрограмм восемью мета-слоями ниже уровня предметной задачи, то это как-то может быть эффективно. Всё IT так делается: "планы внутри планов внутри планов внутри планов". Но ежели предметность (классы/индивиды и отношения, прототипы и делегирования, изменения и события) консистентно представлять и уровнем выше (предмет) и уровнем ниже (архитектура IT) и ещё уровнем ниже (непосредственно поддерживаемые языком программирования сущности), то эффективность вырастет в разы и разы из-за отсутствия многократного многоуровневого перекодирования по ходу вычислений. Ну, типа как сразу сделать железный оптимизирующий процессор для BORO. Как я понимаю вашу эту серию текстов, вы решаете похожую задачу: понимаете в каком-то слое абстракции высокоуровневые концепты и пытаетесь отмэппить их на фичи низкоуровневого языка. Ну, и я о том же, только попробовать попонимать, что там хотя бы на полуровня выше. См. также дискуссию в комментах к http://avlasov.livejournal.com/95743.html
Но ещё выше этого уровня всё одно мэппинг в пользовательские представления (которые по необходимости аристотелевские, скорее всего, причём разные и несовместимые).
Важно, что в этой работе предлагается кроме компьютерного понимания онтологии (разделяемая формализация/концептуализация) явно задействовать компьютерное упоминание эпистемологии -- это кусок онтологии, который известен какой-то отдельной системе, view (в смысле фильтра) на онтологию.
Нужно, нужно время от времени смотреть, что делается в BOROsolution. Вот, например, ещё одна работа 2012 года: http://www.borosolutions.co.uk/research/content/files/2012%20-%20Partridge%20C%20et%20al.%20-%20GUIDELINES%20FOR%20DEVELOPING%20ONTOLOGICAL%20ARCHITECTURES%20IN%20MODELLING%20AND%20SIMULATION.pdf/view -- это онтологические основания для моделирования и имитационного моделирования (modeling and simulation). То есть эта статья может быть рассмотрена как онтологическое напутствие для моделеориентированной системной и организационной инженерии. Про эпистемологию там в самом конце.
Если использовать понятие эпистемологии (что известно какой-то одной системе) и онтологии (разделяемое всеми устройство мира), то можно как-то единообразно изложить федерирование информационных систем: каждая из них имеет свою эпистемологию, но все они имеют общую онтологию, все являются моделью чего-то в нашем мире.
----------------
Оригинал взят у ailev в Освоение ISO 15926
Освоение ISO 15926 по сегодняшнему состоянию требует следующих действий:
1. Понимания, для чего это всё нужно -- и уяснение основных принципов:
а) начинать нужно с чтения книжки Chris Partridge "Business Objects: Re-Engineering for Re-Use), она же "книжка BORO": http://ailev.livejournal.com/938647.html
614 страниц текста, но после них становится понятно, почему плохо моделировать данные объектами и атрибутами, а нужно обращение к факт-ориентированному подходу. Проблемы с этой книжкой в том, что она излагает основы BORO-метода (хотя слово "BORO" не встречается в книжке ни разу), она не использует привычной терминологии -- ни ISO 15926, ни какой-либо другой, она вообще не касается формализмов представления информации (там предлагаются очень элегантные диаграммки, которые больше никем и нигде не используются). Тем не менее, книжка обязательна к прочтению: без нее вам не отбиться от любого первокурсника, который будет не понимать, чем подход ISO 15926 лучше подхода если не реляционных, то объект-ориентированных (объекты с атрибутами вместо таблиц) баз данных -- зачем нужно учить что-то новое, если и старое еще не до конца освоено.
При чтении 7 главы (Physical Bodies as Four-Dimensional Objects) нужно обязательно поглядеть фильм с лекциями Юрия Балашова: http://ailev.livejournal.com/913373.html
б) продолжать нужно чтением книжки FIATECH "An Introduction to ISO 15926" -- http://fiatech.org/images/stories/techprojects/project_deliverables/iso-intro-ver1.pdf
Это 181 страница текста, после которых появляется представление об истории появления ISO 15926 и его возможных применениях.
в) заканчивать понимание основных принципов нужно:
-- чтением книжки Matthew West "Developing High Quality Data Models" (книжка HQDM): http://www.amazon.com/Developing-High-Quality-Data-Models/dp/0123751063 (но вы легко найдёте эту книжку в он-лайн библиотеках, она в электронном виде есть).
408 страниц текста, написанных ведущим разработчиком ISO 15926 уже после выхода стандарта. Это не ISO 15926, а "улучшение части 2 ISO 15926, если бы ее пришлось делать еще раз". Книжка очень кратко пересказывает до страницы 151 приложения рассказанной в книжке BORO теории к моделированию данных (книжка BORO вообще данных не касается, там про другое), затем страницы 151-201 рассказывают, как моделировать самые разные предметы окружающего мира -- организации, продукты, системы и т.д.. Далее до конца книжки идет описание модели данных HQDM и мэппинга ее в ISO 15926-2 (эту модель данных можно безболезненно пропустить).
-- чтением диссертации Andries van Renssen "Gellish. A Generic Extensible Ontological Language": http://repository.tudelft.nl/assets/uuid:de26132b-6f03-41b9-b882-c74b7e34a07d/its_renssen_20050914.pdf
Эти 268 страниц тоже не ISO 15926, и эта книжка также написана одним из соавторов ISO 15926 как "улучшение принятых при создании ISO 15926 решений". Можно, конечно, считать эту книжку "необязательной программой" (тем более, что есть многочисленные идеологические расхождения подхода Gellish и ISO 15926), но там содержится очень много знаний, вполне приложимых к ISO 15926. С учётом того, что большинство людей из сообщества ISO 15926 знакомы с подходом Gellish, эта книжка входит в "культурный минимум" модельера данных.
Итого: для понимания теоретических основ нужно одолеть примерно 1200 страниц текста, это (считая 1 страницу в 3Кзнака) примерно 4тыс. Кзнаков, и если читать за час 30Кзнаков (10 страниц в час), то это работа на 120 часов -- без упражнений и времени на разглядывание картинок и понимание. То есть за месяц по четыре часа в день (хотя и без выходных) вполне можно одолеть, нужно только сосредоточиться.
2. Практика -- ISO 15926 сам по себе
Увы, практика подразумевает обязательное выполнение упражнений -- но упражнений пока нет, их только предстоит разработать
а) нужно освоить ISO 15926 часть 2
Это 241 страница очень насыщенного текста: описание 201 типа, к которым нужно будет относить любую встреченную сущность (entity). Именно этот набор сущностей отличает ISO 15926 от любой другой онтологии -- будь то родственные IDEAS, HQDM, Gellish, или более далёкие CYC и DOLCHE. Это "Отче Наш", это и есть "ключевые слова" языка ISO 15926. Проблема в том, что без знаний из пункта 1 данного учебного плана понять эту часть стандарта невозможно.
б) провести разбирательство с PCA RDL (библиотекой справочных данных POSCCaesar Association, которая должна быть существенно улучшена проектом JORD). Для этого нужно:
-- читать 47 страниц проекта Части 6 (внимание! это еще не стандарт, только проект!) ISO 15926 -- правила ведения RDL, нужные для понимания, откуда что берется в PCA RDL (они также будут полезны для вашей собственной работы: вам же тоже придется разрабатывать корпоративную библиотеку справочных данных).
-- при помощи .15926 Editor разглядывать PCA RDL (см. документацию к этому софту), хотя пользы от этого столько же, сколько от чтения энциклопедии, там ведь порядка 50тыс. сущностей из самых разных предметных областей. Но внимание нужно обращать на общую структуру: как оно устроено хотя бы на верхнем уровне.
Читать Часть 4 не нужно, там просто задавалось начальное содержимое RDL, которое после некоторого развития (некоторые язвят -- замусоривания) привело к появлению PCA RDL в текущем состоянии.
в) Ознакомиться с механизмом шаблонов:
-- читать Часть 7 (механизм шаблонов) -- 126 страниц, без которых с шаблонами не разобраться.
-- увы, нужно читать также и Часть 8 (отображение шаблонов в языке OWL) -- это 58 страниц, которые вроде как предназначены только для программистов, которые пишут реализации ISO 15926, но многие важные для практической работы сведения (например, про пространства имён ISO 15926) приведены именно в этой части стандарта.
г) потратить время на чтение чужих справочных данных ("чтобы научиться писать свои программы/романы, нужно научиться читать чужие"):
-- в качестве обязательного материала (несмотря на то, что у автора этого вебсайта -- тоже одного из соавторов ISO 15926 -- своя точка зрения, не всегда совпадающая с "буквой ISO 15926") -- разбирательство с содержимым вебсайта http://15926.info/
-- можно найти некоторое количество примеров в комплекте поставки .15926 Editor (http://dot15926.livejournal.com/28678.html)
д) прочитать методику ижненерии справочных данных: http://techinvestlab.ru/files/RefDataEng/RefDataEngr_ver_2_25feb11.doc -- 18 страниц, описывающих метод "ISO 15926 Outside"
е) подписаться на дискуссии в комьюнити "ISO 15926" в LinkedIn и почитать их.
Итого: страниц текста всего около 500, но зато много-много разглядывания диаграмм и деревьев со структурированными данными. Времени это займёт много больше, чем чтение первой тысячи страниц -- минимальная оценка тут два месяца.
3. Практическая работа с кем-то из уже разобравшихся в теме:
Увы (или к счастью), ISO 15926 представляет себе фронтир современной мысли по моделированию данных -- и поэтому он во многом дан в устной традиции. Еще не было времени, чтобы выпустить достаточное количество учебных текстов, разработать упражнения. Поэтому важным является общение с носителями традиции: только чтения книжек и стандартов не будет хватать, многое в этих книжках не написано.
То есть начинайте собственный проект моделирования в избранной вами предметной области, но обязательно показывайте свои результаты опытным людям. Вы наверняка будете удивлены, услышав их комментарии к вашим первым работам.
------------------
Оригинал взят у ailev в ISO 15926 outside, inside, offsite
На данный момент в дикой природе можно встретить самые разные методы, использующие ISO 15926:
1. "ISO 15926 outside", или интеграция данных. Библиотека справочных данных при этом строится для того, чтобы наладить мэппинг каких-то проприетарных схем/моделей данных к нейтральной схеме данных. Примеры:
-- архитектура современных PLM, интегрирующих данные САПР (хотя это "Проприетарная схема outside", не верьте заявлениям фирм, что это ISO 15926 -- даже если об этом заявлено в документации. В 1997г. еще не было ISO 15926, поэтому "основанные на snapshot 1997г. схемы" не могут соответствовать Стандарту. Мы тут говорим просто о похожести метода использования библиотеки справочных данных, а не ее соответствии Стандарту).
-- Simantics, в котором воспроизводится архитектура PLM, но при этом четко заявляется, что все обработки делаются в специализированных симуляторах, которые работают каждый в своём формате -- а тамошняя онтология служит только для целей "внешней интеграции". Опять же, онтология simantics ни разу не ISO 155926, но это "проприетарная схема outside".
-- наша методика инженерии справочных данных "ISO 15926 outside" (http://techinvestlab.ru/files/RefDataEng/RefDataEngr_ver_2_25feb11.doc )описывает ровно этот метод.
-- IRING поддерживает ровно этот метод.
Главный критерий: если никаких передач данных нет, то это не "ISO 15926 outside".
Особенность: ISO 15926 целенаправленно делался для поддержки ISO 15926 outside, все остальные методы даже не рассматривались.
2. "ISO 15926 inside", или обработка данных в нейтральном языке. ISO 15926 представляется при этом модульным языком, в котором представляются все данные. Обработка данных ведется в языке ISO 15926 -- ибо всегда есть какие-то вычисления не только для отдельных "приложений" (симуляторов, как в Simantics), но и "между приложениями" (для чего нужно как-то отождествлять данные приложений, используя знание контекста, проводить проверки целостности и т.д.).
Важно отметить, что передача данных тут является вторичной, а главный критерий -- наличие какой-то обработки данных (вычислений, логического вывода, реализации сложных пользовательских запросов, генерации данных и т.д.), находящихся в форме ISO 15926. "Онтологическое программирование" -- это как раз оно.
3. "ISO 15926 offsite", или отсутствие обработки данных. Это использование ISO 15926 как онтологической основы для формализации предметных областей: моделирование стандартов с целью поиска ошибок, формулирование каких-то классификаторов, которые не предназначены затем для машинной обработки, извлечение знаний экспертов "чтобы было", нахождение противоречий в документах и т.д.:
-- моделирование требований (для контроля целостности и непротиворечивости)
-- анализ состава документов (например., используемых нотаций, способов оформления и т.д. для проектной документации в капитальных проектах, или проектах организационного моделирования -- чтобы потом написать по итогам моделирования стандарт оформления документов проекта)
Это использование напоминает известную технику понимания текстов: чтобы разобраться в тексте, нужно перевести его на другой язык. Таким языком выбирается онтологический ISO 15926, заставляющий в ходе онтологического анализа задуматься о многих важных и интересных вопросах, связанных с разбираемым текстом: какова природа поминаемых в тексте или наборе данных объектов?
Главный критерий: нет ни передачи данных, ни обработки данных -- только разработка справочных данных и "подъем в цифру" каких-то не слишком формальных документов. В лучшем случае для результирующих данных ISO 15926 есть проверка целостности, но и это не факт.
-------------
Оригинал взят у ailev в Что нужно для счастья: онтология, лексика, нотация
Последние несколько дней я неоднократно натыкался в самых разных местах на рецепт счастья в описании мира. Успех в моделировании чрезвычайно прост, как 1-2-3:
1. Онтология. Для выражения мира нужны концепты, они отвечают на вопрос "что есть в мире". Другие названия для этой составляющей счастья мировыражения: модель данных, концептуальная схема, схема, метамодель. Онтология критична для обмена знаниями.
Модели хранятся внутри компьютера как онтология, схема. Если вам не нужен доступ к моделям, этого достаточно.
Семантика (значения концептов, увязанных в концептуальную схему) -- это тоже тут. Там, где есть онтология, там можно приписывать слово "семантический".
Без онтологий очень тяжело. Поглядите на вопль комьюнити Business Rules и Complex Event Processing, как им тяжело жить без явной онтологии (особенно онтологии времени): http://intranet.cs.man.ac.uk/ruleML/presentations/keynote1.ppt
2. Лексика. Концепты по большому счету безымянны, а разные люди называют их по-разному в разных языках. Доступ к концептам дает лексика (vocabulary), терминология критична для понимания.
Если вам (а не вашему компьютеру) нужно как-то редактировать ваши модели (или программы -- все равно), то вам потребуется лексика. "Метки", "имена", "идентификаторы", "термины", "названия" -- это все лексика, терминология, словари.
3. Нотация. Чтобы выразить отношения между концептами, вам нужна нотация, синтаксис. Графический или текстовый, или смешанный, или навроде математической нотации, или даже альтернативные нотации для одной и той же модели/программы, используемые для разных случаев.
Нотации дают удобство мыслительных операций для людей. Диаграммы Фейнмана, женевская химическая нотация, арабские цифры вместо римских -- это все были прорывы в выразительности. Нотации неразрывно связаны с концептами и лексикой, они превращают их в язык, на котором можно писать и читать.
Чтобы построить предметно-специфицированный язык (domain-specific language, DSL), вам потребуются:
-- онтология (метамодель, схема)
-- лексика (именно о ней заботятся при локализациях: кому удобно читать-писать по-русски, пусть используют русскую лексику. Кому удобно по-английски -- пусть переключаются на английский, это не должно ни на что влиять)
-- нотация (пусть она будет для этой предметной области привычна. Если вам нужно работать с музыкантами -- пусть это будут ноты на пяти линейках, а если у вас диджеи, то предложите им piano roll).
Проблема в том, что счастья нет:
-- ISO 15926 хорош как онтология, но в нем нет огромного числа важных концептов.
-- SBVR хорош для терминологии, но онтология в нем никудышная.
-- про нотации вообще сказать нечего, полная свобода делать свои собственные ошибки.
Я согласен, что вы можете получить счастье в одном конкретном случае: если вам требуется создавать описания мира, адресующие какой-то один узкий интерес одного заинтересованного лица. Создание одного языка моделирования/программирования поддерживается сегодня огромным количеством инструментария (особенно, если вам неважна интерактивность и вы готовы удовольствоваться "компилятором", при этом оставаясь в рамках текстовой нотации).
Но как только вам потребовалось описывать мир так, чтобы удовлетворить самых разных интересантов, и чтобы эти описания все были связаны между собой и поддерживалась их целостность, да еще и обеспечивалось коллективная работа над этим описанием, да еще объемы этих описаний велики (какая-нибудь нефтяная платформа с находящимся на ней небольшим нефтеперерабатывающим заводом, описанная с точностью, достаточной для ее изготовления), то у вас БОЛЬШИЕ ПРОБЛЕМЫ -- и с онтологией (должна быть одна, хотя в ней будет много-много метамоделей), и с лексиками (их уже будет много) и нотациями (их тоже немало -- десятки, если не сотни).
Нынешние линейки САПРов решают эту задачу "на коленке", все решения глубоко внутрифирменные. Языковые верстаки пытаются вывести решение этой задачи в обычную разработческую рутину.
-----------------
Оригинал взят у ailev в Очередное уточнение для релиза PraxOS 2.3
Ниже -- некоторые переформулировки к общему плану выпуска релиза 2.3 (план был в http://ailev.livejournal.com/766517.html и уточнения в http://community.livejournal.com/praxos/455.html). За прошедшие со времен этого планирования полгода работы шли более-менее по этому плану, но сейчас мы знаем побольше, и можно там и сям по мелочи сформулировать точнее.
PraxOS -- это "ПРАКСеологическая Организационная Система", метод работы с мощными методами организационной инженерии.
-- праксеология означает, что мы опираемся на деятельностный подход (невзирая на огромную путаницу в сегодняшних "праксеологиях" Мизеса, Котарбинского, Монбриаля и прочих авторов, которые обсуждают под этим брендом самые разные понимания деятельности, равно как и авторы деятельностного подхода, которые и вовсе слово "праксеология" не употребляют).
-- организационная система тут является обеспечивающей системой к целевой системы организации.
-- мощный метод: это контринтуитивный метод, масштабируемый на самых разных уровнях работы. Термин взят от Алан Кея (power ideas).
-- организационная инженерия: системно-инженерный (в противовес "обычному инженерному" или "художественно-гуманитарному" или "научному") подход к организациям как целевым системам.
PraxOS описывает не только методы организационной инженерии, он еще и себя самого описывает.
Одним из основных рабочих продуктов метода PraxOS является библиотека типовых методов (Reference Method Library) PraxOS. Тут, конечно, можно еще порассуждать, называть ли эти reference "стандартными", "справочными", "эталонными" или "типовыми". Мы назовем их "типовыми", ибо reference process models -- это типовые описания практик, а у нас по сути то же самое, только сбалансированное описанием продуктов, акторов, языков-нотаций и т.д.. Уйдем от обсуждения терминологии, назвав весь этот "репозиторий методов" просто библиотекой PraxOS, но запомним, что она -- просто часть глобальной RDL ISO 15926. Если есть данные для "насоса", то в глобальной RDL должны быть данные и для "стратегирования", причем как на уровне учебника (существование стратегирования в мире), так и на уровне стандартов (если Минцберга и Голдратта можно считать таковыми), конкретной консультационной фирмы-изготовителя (например, TechInvestLab). У конечных же пользователей (клиентов консультантов) появятся методы-индивиды (онтологическую разницу между методом и его описанием/данными мы пока опустим). Все, как с насосом, только thing другого типа -- "метод -- > метод ситуационной инженерии методов -- > метод ситуационной инженерии методов PraxOS"
Все богатство методов ПраксОСа нужно изложить в каком-то формальном языке (аналоге "системы типов" 15926-2), каковым в методе PraxOS можно на данный момент смело считать ISO 24744 с некоторыми расширениями (пока это "обоснования", но наверняка будут и другие -- продолжаем думать про BPMN 2, DEMO и организационные диаграммы).
Затем нам нужен аналог 15926-4, задающий начальные классы таксономии методов -- и сразу не претендующий на всеохватность. Так, мы должны будем разместить самые общие описания на верху этой таксономии методов, а внизу -- описание фирменных приемов работы PraxOS в готовом для постановки/освоения виде:
1. Методы организационной инженерии (после "/" как это по ISO15288)
-- стратегирование (карты действий и результатов, "бытовое стратегирование") / описание жизненного цикла
-- мегамодель и ontology-based интеграция данных / управление информацией
-- supply chain и организация (REA, DEMO) / agreement processes
-- управленческий учет (throughput accounting) / измерения
-- архитектура сервисов, ответственностей, полномочий (включая архитектуру IT-систем и оргструктуру) / управление инфраструктурой
-- управление проектами и управление портфелем (в том числе СС, LastPlanner, beyond budgeting) / управление проектами и управление портфелем
-- инициирование и проведение организационных изменений (мероприятия активного типа и т.д.) / управление инфраструктурой и управление персоналом
1а. Технические методы (железно-софтовой) инженерии
-- моделеориентированная инженерия требований (в организациях -- это в стратегировании)
-- моделеориентированная инженерия системной архитектуры (в организациях -- архитектура сервисов, ответственностей и полномочий, что для технарей "инфраструктура", то есть обеспечивающая система)
2. Пропедевтика (временные разделы, пока нет специализирующихся на этих методах других библиотек -- ведь PraxOS не про всё на свете, а только про организационную инженерию. Но для освоения методов организационной инженерии нужно еще кое-что знать, "поставить мышление")
-- Методы системного мышления и инженерии (для любых систем, не только для организаций)
-- Методы психической инженерии (ОпенМета. Как бы помягче это назвать, без упомнинания "психики"? Психика-то у всех есть, только слово это табуировано в немедицинских кругах. "Педагог", "наставник" и даже "воспитатель" говорить можно, а "инженер по психике" -- нельзя).
3. Метаметоды
-- методы онтологической работы в ISO 15926
-- методы использования, сопровождения, пополнения, управления конфигурацией рабочих продуктов PraxOS
-- методы учебной работы (социальная сетка, коннективизм и прочие современные теории образования)
Софт PraxOS является инструментом метода (а не рабочим продуктом! Рабочий продукт -- библиотека методов, сделанная с использованием софта PraxOS), реализуется на базе платформы языкоориентированного онтологического программирования .15926 (dot15926) и представляет собой композер (composer -- формовщик, синтезатор, "наборная машина") методов.