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). То есть эта статья может быть рассмотрена как онтологическое напутствие для моделеориентированной системной и организационной инженерии. Про эпистемологию там в самом конце.
Если использовать понятие эпистемологии (что известно какой-то одной системе) и онтологии (разделяемое всеми устройство мира), то можно как-то единообразно изложить федерирование информационных систем: каждая из них имеет свою эпистемологию, но все они имеют общую онтологию, все являются моделью чего-то в нашем мире.
Я вот всё время думаю мысль, что 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). То есть эта статья может быть рассмотрена как онтологическое напутствие для моделеориентированной системной и организационной инженерии. Про эпистемологию там в самом конце.
Если использовать понятие эпистемологии (что известно какой-то одной системе) и онтологии (разделяемое всеми устройство мира), то можно как-то единообразно изложить федерирование информационных систем: каждая из них имеет свою эпистемологию, но все они имеют общую онтологию, все являются моделью чего-то в нашем мире.