Category: образование

Category was added automatically. Read all entries about "образование".

2021 год
  • ailev

Схема интеллектуального акта

Я считаю, что есть три стадии жизненного цикла интеллектуального акта (happy path, чему учат в школе, а не "включая всю экзотику, озарения и исключения, которые можно встретить в жизни).

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

Я бы назвал это "пониманием" -- сюда, конечно, входят все эти "ага!" и "озарения".

2. Формальные (по правилам) вывод, рассуждение, вычисления: расчёт по численной модели/формулам, применение консистентной теории, нахождение максимума/оптимума, дискретная математика и прочая логика. Солверы, оптимизаторы, виртуальные машины, процессоры.

Думание и использование озарений -- это тут.

3. Объяснение (деформализация, демоделирование): метафоризация, нарративизация, диалог, интерфейс, визуализация и т.д.: перевод вычисленного в те описания, из которых делалась формализация шага 1.

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

Ничего не мешает использовать второе для первого, или первое для второго, и вместе первое и второе для третьего. Но я бы их различал.

Объять необъятное невозможно. Пока мы в .15926 проекте концентрируемся на крохотном кусочке: представлении общего формального знания, получаемого мэппингом нескольких формальных знаний в общее представление (общая онтологическая/семантическая репрезентация, а не общая синтаксическая репрезентация). Но само по себе это бессмысленно, это 1/3 часть дела. Переводчик с языка на язык бесполезен, если переведённое затем никто не использует. Справочные данные (теория, опыт) бессмысленны, если нет вычислений с ними, если нет отождествления объектов реального мира на соответствие им. Мало перевести какие-то текстовые данные в "формальный вид", нужно ещё суметь организовать какое-то вычисление над этими данными. Если никто не вычисляет, то бессмысленно было преобразовывать.

Какой-то гарантией осмысленности является переброс данных между двумя вычислимыми моделями: тогда распознавание сущностей предметной области одного моделера в данных предметной области другого моделера полезно, в одном из этих моделеров/вычислителей может быть проведено рассуждение над данными другого моделера/вычислителя. Ежели задача ставится просто "преобразвать текст в формальное представление", то хорошего не будет. А вот ежели "выдрать из текста всё то, что кушается таким-то моделером/программой планирования/САПР/PLM", то вполне.

Тем самым первым шагом может являться получение справочных данных (мета-модели) для какого-то вычислительного софта (где есть солверы и/или оптимизаторы, "думалки"). Затем только формулирование задачи по выдёргиванию из текстов информации для этих солверов.

Кстати, так же поступают всяческие Siri. Они из текстов выдёргивают информацию отнюдь не всю возможную, а только нужную для запуска того небольшого числа солверов/оптимизаторов/движков/интерфейсов поиска, который есть в телефоне. Больше информации вытаскивать бессмысленно, ибо над ней никто не будет затем думать.

Это замечание, заметим, противоречит постановке задачи "преобразовать требования (ТЗ или стандарта) в ISO 15926", ибо выдирать из текста нужно только те требования, которые потом можно будет как-то проверить в известном CAD/PLM софте. А если их просто "преобразовать и затем хранить" -- то это бессмысленное преобразование, информационное загрязнение окружающей среды.

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

То есть пока "нашими" темами являются:
-- паттерны (архитектурные, онтологические и любые другие)
-- аналогии (Хофштадтер) и прототипы (Лакофф), меры семантической близости, VAE (от ViviMind)
-- метафоры и блендинг
-- извлечение фактов в компьютерной лингвистике

Но действуем мы только в том случае, когда виден солвер, которому мы скормим результаты. Ибо (по Витгеншнейну) смысл объектов в их употреблении. Если мы производим объекты, которые потом не употребляем, то они бессмысленны.

Так что на некоторое время паттерны -- это наше всё, нельзя объять необъятное. "Распознаём паттерны, делаем мэппинги. Онтология своя, моделеры/солверы/оптимизаторы заказчика, информация третьих лиц". Лужу, паяю, ЭВМ починяю...

См. также про эпистемологию в http://dot15926.livejournal.com/38046.html. Слоган может выглядеть так: "Мэппинги из эпистемологий третьих лиц в эпистемологию заказчика. Хорошую онтологию имеем свою".
Sharge
  • vvagr

Курс обучения ISO 15926

Провёл курс обучения ISO 15926.

Заняло 3 дня подряд по 7 часов в день.

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

Программа:

День 1

1. Модели данных, применение в интеграции данных, критерии качества моделей.

2. Концептуальные модели. Онтологии.

3. Сущности и атрибуты, субстанциональная пардигма.

4. Объектная парадигма. Безатрибутная модель.

5. Отношения, реификация.

6. Время. 3D и 4D.

7. Экстенсионализм, физический и функциональный объект, мереология.

8. Классы, типы.

10. Жизненный цикл.

11. Общее введение в ISO 15926.
- архитектура моделей
- справочные данные
- архитектура интеграции
- история
- части стандарта
- организации, проекты и планы

День 2

1. Языки диаграмм.

2. Концептуальная модель части 2. Обзор 201 типа, примеры моделирования. (Реальный охват - около 70% раздела 4 части 2, в зависимости от предполагаемого проекта слушателей 30% им ненужного отбрасывается)

День 3.

1. Повторение элементов концептуальной модели.

2. Части 4 и 6. Табличное представление, метаданные.

3. Часть 7. Стандарт в FOL, шаблоны.

4. Семантический веб, часть 8. Идентификация справочных данных.

5. Сопоставление представлений информации по стандарту: табличное, диаграмное, FOL, XML, RDF/OWL

6. SPARQL, архитектура интеграции данных iRING.

7. Демонстрация работы с RDL через веб-интерфейсы и через .15926 Editor.

8. Практика редактирования данных в .15926 Editor.

9. Обзор источников дальнейшей информации.

Требования к участникам:

Базовый английский и начальные сведения по теории множеств, математической логике, языкам разметки данных (в объёме представлений о структуре HTML).

Итог курса - слушатели знакомы с основной терминологией, не пугаются сложных слов и картинок стандарта, знают, куда смотреть в поисках информации о моделировании, умеют разбирать простые модели по диаграммам, построили с помощью лектора одну простую модель из своей предметной области, знают, как пользоваться простыми инструментами.

Надо, конечно, добиваться того, чтобы слушатели умели построить диаграмму модели, описать в таблице и построить шаблоны, а потом записать их экземпляры. Туда и будем развивать упражнения. На RDF/OWL в трёхдневный курс упражнений не будет.
2021 год
  • ailev

Data governance platform

Почитал я http://www.collibra.com/products-and-solutions/products/business-semantics-glossary -- и подумал, что наш софт онтологического программирования с его архитектурным пайплайном readers-builder--scanner-writers по состоянию на сегодня очень смахивает как раз на эту самую data governance platform (http://www.collibra.com/products-and-solutions/data-governance/define). У Collibra всё реализовано на SBVR, как я понимаю, а у нас всё крутится вокруг ISO 15926. Ну и функций, понятно, у Collibra в разы больше -- но прихват функций от версии к версии ведь дело наживное, да?

Это я продолжаю линию разговора про поддержку софтом .15926 не только спецификаций оборудования, P&ID диаграмм да 3D для разных железяк, но и PraxOS с его ОргЛаном (http://praxos.livejournal.com/12907.html, а массовый переход тусовки enterprise architecture к разговору об онтологии -- см. http://ailev.livejournal.com/951732.html).

Интересно, кому продаёт свой софт Collibra, и в каких количествах. Gartner сказал в мае 2011, что она Cool Vendor in Enterprise Information Management (http://www.collibra.com/news/collibra-named-gartner-cool-vendor-enterprise-information-management).

Как я понимаю, онтологическое программирование само по себе -- это просто инструментализация data governance.

У меня была гипотеза, что знаменитый слоган "программа = алгоритм + данные" был очень криво отражен в образовательных программах. Поэтому программистов теоретически тренировали главным образом в алгоритмике (на школьном алгоритмическом языке, на ассемблере MIX, и т.д.), моделирование данных отдали на откуп курсам management information systems (ибо там было много баз данных), а всякие "архитектурные паттерны объектного программирования" ввиду полного отсутствия теоретической поддержки отдали из computer science в software engineering. А всего-то нужно учить в школьном курсе информатики не только алгоритмике, но и онтологизированию/моделированию данных.

Но это самое моделирование данных плохо осознаётся как отдельная дисциплина. Поэтому отдельного софта на эту тему практически нет, нет базовой школьной подготовки, а теория маргинальна. Вот data governance платформа и воспринимается как что-то свежее, новое, интересное. А должна она быть рутинной и старинной и существовать в десятой версии с тремя сервис-паками, как реляционная СУБД или компилятор Си. Но нет, это до сих пор terra incognita.

Нужно будет поразмышлять на эту тему: data governance, data integration, data quality, algorithm governance, algorithm integration, algorithm quality, как этому всему учить, и причем тут онтологическое программирование -- когда данные готовы к употреблению ими разными алгоритмами, а алгоритмы готовы работать с разными данными...