Category: общество

Category was added automatically. Read all entries about "общество".

2019
  • ailev

Хакатон по оценке онтологий

Продолжается Ontology Summit 2013 (ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2013). Мой доклад про методологию инженерии справочных данных ISO 15926 был в прошлый четверг (аудио и ссылка на слайды -- http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2013_02_07), в слайдах есть и скриншот нашего .15926 Editor.

Очередная тамошняя идея -- это провести хакатон (hackathon) или онтологическую клинику (ontology clinic) в рамках темы этого саммита, ontology evaluation (а именно -- верификация, валидация, выбор, оценка качества онтологий).

Хакатон (ontology hachathon) -- это когда люди собираются очно (иногда и виртуально) и день-два кодят программы по работе с онтологиями. Ontology clinic -- это когда люди пытаются что-то сделать с онтологией (например, провести какую-то её оценку: измерить качество, верифицировать, валидировать, выбрать).

Есть предложение провести такой хакатон/клинику и у нас, на русском языке. Мы (TechInvestLab) предоставим офис, чай, консультации для участников. Результаты будут доступны всем. Содержанием этого хакатона/клиники могло бы быть выполнение мини-проектов:

-- написание расширений к .15926 Editor по оценке онтологий (тут огромное поле для идей даёт сессия с описанием множества технологий и наборов метрик по оценке онтологий: http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2013_01_31).

-- оценка (взаимные консультации, ontology peer review, а также использование написанных тут же специальных расширений) для каких-то справочных данных ISO 15926, которые привезут с собой участники. А если не привезут, то мы будем делать оценку JORD RDL (благо наш софт позволяет работать с этой библиотекой быстро).

-- оценка соответствия (compliance) представления справочных данных (предоставленных участниками хакатона/клиники) Стандарту.

По традиции (а традиции есть -- погуглите ontology hackathon) число мест ограничивается, иногда берутся оргвзносы (думаю, мы пока это делать не будем), на самом мероприятии не только кодируют, прогоняют тесты и удавливают баги, но и проводят брейнстормы, обмен опытом, тьюториалы и т.д. Результаты обычно публикуются в Сети (в нашем случае они будут доведены и до участников Ontology Summit -- а для этого хакатона там есть и специальный список рассылки, в том числе в котором обсуждаются работы по их собственному репозиторию онтологий OOR: http://ontolog.cim3.net/forum/ontolog-dev/2013-02/index.html, подписка-отписка тут: http://ontolog.cim3.net/mailman/listinfo/ontolog-dev/).

Мы готовы принять очно 15 человек в нашем офисе и ещё 20 человек по скайпу+mikogo.com (то есть устроить virtureal event).

Чаще всего эти хакатоны и клиники идут пару выходных дней. Как нам лучше сорганизоваться: один или два дня? В будни или таки в выходные? Сколько желающих поработать в Москве, и сколько удалённо? Что нужно было бы обязательно иметь в программе мероприятия? В феврале проводить, или через месяц, в марте? Нужно ли о чём-то предварительно договариваться через интернет "на берегу", или делать всё в классической манере хакатона: решить всё на утреннем очно-виртуальном общем совещании в день мероприятия? Отпишитесь по этим вопросом тут в комментах, плиз.
2019
  • ailev

Закон ОМа: описание [практики] постановки [метода] инженерии схемы данных жизненного цикла

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

Связь онтолета (как онтологического описания -- и дальше я традиционно не буду различать онтологию и онтологическое описание, метод и описание метода) и описания метода проявляется очень просто: каждый объект, помянутый в методе, должен быть типизирован. Под "типизацией" я имею ввиду не только классификацию его к понятиям Части 2, но и к понятиям расширенной онтолетом Части 4.

Тут есть свои:

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

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

В ISO 15288 декларирование типа вылезает в заголовки. Так, все 25 processes этого стандарта имеют намеренное решение тип (process) включить в заголовок с именем конкретной практики, но в оглавлении это выглядит совершенно избыточным (так, я снял эту типизацию в переводе -- а сейчас вновь задумался, не вернуть ли её). Другой пример из стандартов ISO 15288 -- это рекомендация добавлять тип "система", когда подчеркивается использование системного подхода, например, вместо "самолёт" говорить "система самолёт". Я с этой рекомендацией не соглашаюсь обычно ("всё есть системы, так зачем это каждый раз говорить?"), но сегодня в очередной раз задумался над пользой принудительной типизации.

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

Компромиссным вариантом является "декларирование типа" -- как в языках программирования, типизация показывается явно при первом употреблении объекта. В моём вчерашнем постинге я использовал такой подход к типизации, указывая "практики дисциплины" (заодно указав и отношение композиции дисцилины из практик, и тип "практики" для списка индивидуальных практик дисциплин, и указав тип "дисциплина" для индивидуальных методов типа "Инженерия схемы данных жизненного цикла"). Ежели идти дальше, то для типов нужно указать, из какого онтолета они пришли -- "практика" пришла в явном виде из ISO 24744 (там это process), а "дисциплина" -- путем обобщения разных наборов практик (что отражалось в различных "дисциплинах системной инженерии" -- "дисциплина инженерии требований", "дисциплина инженерии системной архитектуры"). Тут я просто обобщил "практику" вверх до "дисциплины" (а не только вниз до уровня "мероприятия" и "дела", как это делается в онтолете ISO 24774).

Пример с дисциплиной (вновь введенное понятие), практикой (использующейся как в ISO 24744, так и в ISO 24744), мероприятием (использующимся только в 24774 для более мелких практик) и делом (использующимся опять таки как мельчайшая единица как в ISO 24744 и ISO 24774) показывает, что нам не обойтись для моделирования метода собственным онтолетом, который должен входить в .15926O.

Но это не даёт ответа на вопрос, как рэндерить эту типизацию. В отдельном постинге (http://community.livejournal.com/dot15926/16745.html) я выполню упражнение по описанию/рендерингу/представлению практики постановки метода инженерии схемы данных жизненного цикла (которая, по идее, должна быть "специализацией" практики "постановка метода" в дисциплине "ситуационная инженерия методов" -- примерно в том же смысле, в котором мы говорим о "специализации шаблонов").

В качестве упражнения: опустим типы из ISO 24744/24774 в предыдущем предложении -- смысл ведь не изменится! "В отдельном постинге (http://community.livejournal.com/dot15926/16745.html) я выполню упражнение по описанию постановки инженерии схемы данных жизненного цикла (которая, по идее, должна быть специализацией постановки в ситуационной инженерии методов -- примерно в том же смысле, в котором мы говорим о "специализации шаблонов")". Интересно, сколько людей сочтет "более понятным" типизированный вариант, а сколько нетипизированный?

Этот пример также даст понимание, как может выглядеть описание (рендеринг) методологии в части описания практик (я, правда, не понимаю, правильно ли публиковать это в dot15926, ибо речь идет явно об организационной практике -- а тогда это должно идти в praxos. Типичный пример двойной классификации). Обратите внимание, что многие формулировки и типы в этом примере предписаны ISO 24774 (практики, мероприятия, способ нумерации и т.д.), но существенно также используется типизация по ISO 24744 (даже слово "метод" -- это тоже тип к "инженерии схемы данных", наряду с "продуктами работ") -- но не думаю, что требуется как-то специально обозначать эти пространства имён. Всякие объяснения выбранной терминологии тоже опущены (так, "инженерия схема данных" подразумевает прохождение целевой системы схемы данных по полному жизненному циклу -- от замысла и определения пользовательских потребностей до валидации и эксплуатации. "Разработка" же обычно ассоциируется с более коротким жизненным циклом проекта, заканчивающимся на проектировании -- невзирая на совпадение "проектирования" и "изготовления" для информационных продуктов). "Многоуровневые типизации" и "буквальные типизации" (типа "шаблон практики постановки..." -- чтобы показать, что тип "постановки метода инженерии" в ISO 24744 будет не "process", а "ProcessKind", или использование "метод" как обозначение того целого из практик-продуктов-организации, что подлежит постановке) я старался не использовать. Интересно было бы получить замечания, где дополнительная типизация была бы полезна и уместна (а где, наоброт, осталась лишняя). В целом, "остаточная типизация" следует ISO 24774, как ее можно обнаружить в ISO 15288, взятом за образец предлагаемого описания/рендеринга. Заодно в качестве побочного эффекта мы получаем текст "процессного стандарта", выполнение которого можно проверять по ISO 15504 (SPICE), ибо такой текст читается как "описание типового процесса" (reference process model) в смысле этого стандарта оценки соответствия.