?

Log in

No account? Create an account

Previous Entry Share Next Entry
Освоение ISO 15926
2011
ailev wrote in dot15926
Освоение 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 представляет себе фронтир современной мысли по моделированию данных -- и поэтому он во многом дан в устной традиции. Еще не было времени, чтобы выпустить достаточное количество учебных текстов, разработать упражнения. Поэтому важным является общение с носителями традиции: только чтения книжек и стандартов не будет хватать, многое в этих книжках не написано.

То есть начинайте собственный проект моделирования в избранной вами предметной области, но обязательно показывайте свои результаты опытным людям. Вы наверняка будете удивлены, услышав их комментарии к вашим первым работам.

  • 1
Отдельное спасибо. Если прямо сказать, то несколько раз пытался вникнуть в это ваше ИСО (через разные какие-то тексты)и нифига не понял (видимо не с того конца или не в том настроении начинал). Не знаю, буду осваивать или нет, но то, что такой текст есть уже хорошо (а вдруг...).

А ты прочти хотя бы первую книжку. Кушниренко про неё, кстати, сказал: "в третьем классе это узнавать еще рановато, а в ВУЗе -- уже поздно". ;-)

А в ВУЗе уже поздно

Ну у меня ВУЗовское повыветривалось так, что мне наверно уже можно :)

В новогодние выходные, пожалуй и займусь.

Я прочитал основную часть BORO -- до момента когда он начинает разбираться со знаками для разных объектов. Очень благодарен вам, Анатолий, за эту наводку. Книга действительно расставляет многие вещи на другие места и становится понятны ваши упоминания 4D экстенционализма и много прочего. И про моделирование мира в данных думаешь уже тогда совсем по-другому.

Не нахожу упоминания о "Practical Guide for ISO 15926 Modeling", который так рекламируется в "An Introduction to ISO 15926". Видимо, на то есть причина. Какая, если не секрет?

Этот ужас, летящий на крыльях ночи, можно найти тут: http://iringug.org/wiki/index.php?title=Beginners_Guide_to_ISO_15926_Modeling -- далеко не готово, очень спорно. То есть пусть напишут что-нибудь путное, тогда можно давать ссылку.

При прочтении "An Introduction to ISO 15926" у меня сложилось впечатление, что есть Beginner's Guide и Practical Guide.
Сейчас начал разбираться.
Оказывается есть и зачаточное состояние Practical Guide (https://www.posccaesar.org/wiki/ISO15926Primer_CurrentEvents_Education), озаглавленный "Practical Guide to ISO 16927 Modeling". Реально оно сводится к ссылкам на Introduction и Beginner's Guide.
Ну и бардак.

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

книжка BORO опирается на object-oriented methodology. Gellish, судя по всему, тоже это активно использует.
А есть что-нибудь НЕ object-oriented для представления знаний (и описания процессов)?

Не судите по словам, обращайте внимание на суть дела: книжка BORO, Gellish и ISO 15926 используют факт-ориентированный подход. Книжка BORO при этом говорит про "объекты", но это совсем не объекты из объект-ориентированного программирования (которые имеют атрибуты). Это другие объекты, о которых нам известны факты об отношениях между этими объектами.

Почитайте подробней книжку BORO, разберитесь с тамошними идеями. Там как раз серьезная критика подхода ООП.

4D+экстенсионализм+модальный реализм

часто в Вашем, Анатолий, журнале нахожу ссылки на HQDM и принятые Уэстом подходы - 4D,экстенсионализм и модальный реализм. Там много вопросов по ходу дела возникает, но вот один из застрявших в голове: если мы принимаем 4D экстенсионализм, то для идентификации класса нужно тупо указать на все объекты, в этот класс входящие (не подразумевая никакой "объединительной идеи", никакого предиката, кроме "является членом класса ..."). С другой стороны, модальный реализм говорит об онтологическом равноправии бесконечного множества возможных миров. Не могу понять расписываемой Уэстом выгоды от совмещения этих подходов - ведь, чтобы определить класс, нам нужно указать все объекты, не только нашего мира, но и всех остальных. А в них же вообще непонятно, в "каком виде" эти объекты есть, если есть вообще (к примеру, на кого надо указывать для зачисления в класс "Человек" через пару тыщ лет или в мирах?). В тех мирах, по-моему, проще было бы с интенсиональным определением класса... Не подскажете, что я упускаю в умопостроениях?

Re: 4D+экстенсионализм+модальный реализм

Указывать ничего не нужно! У нас же концепция "открытого мира": если что-то не указано, то это не означает, что оно не входит в класс. Так что фраза "красный -- это все красные предметы, которые были, есть или будут" не требует явного перечисления этих красных предметов. Человек из 3019 года -- в 4D он есть, просто его временной экстент (аналог пространственных экстентов -- длины, ширины, высоты) сейчас недоступен. Но это не значит, что мы не можем об этом человеке делать какие-то утверждения "в вечном времени".

я, видимо, тогда неверно понял экстенсионализм. Потому как фразу "класс, включающий все красные предметы" я без сомнений отнес бы к интенсиональному определению класса и с таким определением я как раз проблем в возможных мирах не вижу.

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

По "книжке BORO" есть вопрос. Отношения там принципиально рассматриваются, как не имеющие временной протяженности, а раз и навсегда имеющиеся?

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

Статья в википедии тоже не дает явного ответ на вопрос "имеют ли отношения протяженность во времени" - судя по блок-схеме, для них ответ на вопрос "does it have spatial and temporal extent" отрицательный, но все портит союз and - ведь и spatial extent у отношений нет.

Как правильно поступить в таком случае?

Отношения не имеют временной протяжённости. Вернее сказать, она к ним неприменима. Отношения - это наборы 4D объектов.

Описанная Вами проблема в 4D решается крайне просто - отношение "доверения" связывет не полные объекты "Иван Иванович", "внук" и "Жигули", а их темпоральные части.

То есть выделяются четырёхмерные отрезки мировых линий Ивана Ивановича, внука и Жигулей от момента выдачи доверенности и на три года. Этим объектам присваиваются отдельные имена (идентификаторы). И именно они входят в отношение.

В формализме с которым мы работаем, ISO 15926, полный объект называется Whole Life Individual, a отношение, связывающее весь объект "Иван Иванович" с объектом "Иван Иванович 2000-2002 гг." (в границах от 01.01.2000 до 01.01.2003) называется Temporal Whole Part, полная темпоральная часть, то есть в указанный период у "Иван Иванович" нет иных частей, кроме "Иван Иванович 2000-2002 гг."

То есть всякий "четырехмерный" объект может "произвольно" нарезаться на части вдоль временной координаты и эти части связываются с самим объектом с помощью специального отношения?

У Партриджа "сущностная" и "субстанциальная" модели (надеюсь, я правильно перевожу термины и не придумываю Джонов Баптистов) критикуются за то, что для представления, скажем, отношений или изменений нобходимо вводить какие-то "фиктивные" сущности (возвращаясь к автомобильной теме и "сущностному" бумажному документообороту - это соответственно свидельство о регистрации и ПТС, точнее, записи в последнем). Как мне кажется, "трюк" с нарезанием четырехмерного объекта на временнЫе части - это именно "трюк" с фиктивными объектами, свидетельствующий о некоторой неадекватности модели в сложных ситуациях (хотя какие они сложные? ежедневно с ними сталкиваемся). Впрочем, в других моделях время не рассматривается вообще.

Грубо говоря, количество объектов, которое понадобится использовать для хранения-передачи информации, останется неизменным. Но логическая стройность и последовательность построений могут отличаться. ъ

Преимуществом 4D является то, что для определения новых сущностей для разговоров о времени используются уже имеющиеся понятия с известной семантикой, с неким "физическим" смыслом - часть, целое, граница и т.п.

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

То есть различия на уровне "мета", а на уровне данных число объектов сравнимо. Но если уровень "мета" проще, то и интерпретация объектов данных проще, меньше будет разночтений при интерпретации разными людьми.

Забудем пока о времени. Возьмем "сущностную" модель, например. Нарисуем ER-диаграмму для двух сущностей - "предмет собственности" и "владелец". Отношение "владеет" в данном случае - "многие ко многим" (так как есть и долевая собственность). Если нам захочется перейти к таблицам реляционной БД (вот и сущностная модель), то возникнет еще одна таблица, которая представляет это отношение. Можно сказать, что эта таблица "фиктивная", представляющая что-то несуществующее в природе (так как отношения из ER-модели при переходе к "сущностной" испарились). А можно сказать, что речь в этой таблице идет об объектах, которые можно назвать "Свидетельство о регистрации права собственности" - и они прекрасно ложатся в "сущностную" парадигму. Говоря вашими словами, при таком взгляде на построенные таблицы - "для разговоров об отношениях используются уже имеющиеся понятия" - становится непонятно, зачем вводится логическая модель (она в BORO характеризуется, как не имеющая проблем с представлением отношений).

Возможно, и со временем ситуация такая же - только более удобной модели пока не придумано.

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

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

классификация или специализация

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

В HQDM было пару абзацев про выбор "специализация или классификация", но смысл сводился к тому, что все зависит от контекста того или иного проекта. Я так понял, что специализация лучше с точки зрения re-use, а классификация - с точки зрения гибкости(можно изменять состав классов без изменения структуры метаданных, просто записями в таблице). Это так? И не появилось ли в развитие этого довольно общего правила каких-то эвристик, помогающих сделать более адекватный выбор в конкретной ситуации? (Типа, если для множества объектов свойство неотделимо и действует whole life, то из него делаем генерализирующий класс. Или какие-то зависимости от особенностей физической реализации или требований к использованию/поддержке)

Re: классификация или специализация

Попробуйте прочитать дискуссию http://www.linkedin.com/groupItem?view=&gid=2547763&type=member&item=194565841 (там приводятся контрольные вопросы, позволяющие различить эти отношения в конкретных трудных случаях).

Вообще, с этими отношениями "мета" всё значительно хуже (см., например, слайд 8 diversity of meta concepts в http://jtc1sc32.org/doc/N1751-1800/32N1764-WG2-Tutorial-OnMOF-forSC32.ppt -- там описывается объект-ориентированный MOF, но в ISO 15926 все эти же содержательные проблемы всплывают, никуда от них не деться).

Edited at 2013-01-07 01:43 pm (UTC)

Между прочим, найти книгу HQDM в открытом доступе в online библиотеках не удалось. Может не знаю, где искать. Искал в гугле по названию и автору, добавляя: "pdf", "download", "torrent". Попадаются только сайты-мусорки с рекламой, с уже битыми или заведомо ложными ссылками на аплоадеры.

Поищите файл hqdm-book.pdf у себя на диске. У вас он точно есть ;-)

А как CIDOC CRM относится ко всему етому?

Там есть "event-based approach" который кажется подобен 4Д.
Я много работал с CIDOC CRM с музейными данными.

(Извините за ошибки, я болгар и русской клавиатуры нету)

Не всё, что связано с моделированием во времени (моделирование событий, процессов, изменений и т.д.) является 4D онтологическим моделированием. Если в CIDOC CRM есть понятие TemporalWholePart (ну, или хотя бы TemporalPart), то тогда там 4D онтология. Если нет -- то 3D онтология.

Я крайне рекомендую выполнить пункт 1а по чтению литературы, прочесть книжку Криса Партриджа. Там это всё подробненько разъяснено.

  • 1