serge_gorshkov


Сергей Горшков - о бизнесе в сфере ИТ

о семантической интеграции, программировании, управлении...


Previous Entry Share Next Entry
Онтологическое моделирование в 6 классе
serge_gorshkov
Два месяца ничего не писал - пора возвращаться с каникул :) Первый осенний пост имеет к этому прямое отношение. Мой сын пошел в 6 класс, и я, конечно, первым делом открыл учебник информатики (авторы - Босова Л.Л. и Босова А.Ю.). Открыл - и был поражен: половина учебника посвящена моделированию, которое - с некоторой натяжкой - можно назвать онтологическим! Я на своем семинаре начинаю примерно с этого же (кстати, в этом году буду и студентам читать онтологическое моделирование).

В первом же параграфе вводятся понятия "объект" и "множество", дальше речь идет про отношения между множествами (с кругами Эйлера), классификацию, процессы восприятия и концептуализацию, а наповал меня убил параграф под названием "информационные модели на графах". OMG, я преисполнен гордости за нашу школу! По всем предметам бы так...

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

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

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

  • "Береза у колодца" - это, вообще, имя? На мой взгляд, "у колодца" - это значение признака (при них далее), а выносить значение признака в имя есть плохой тон. Ладно, березы не передвигаются, а вот "собака у колодца" будет совсем плохим именем. Никаких пояснений на эту тему не дается.

  • С философской точки зрения то, что здесь названо "именем" (выражение "столичный европейский город" приводится как пример имени множества) можно считать интенсионалом, т.к. все приведенные примеры описывают некую идею, которой соответствует конкретный объект или множество объектов. А "имя" в собственном смысле - это знак, символ, ярлык, и вот это понятие нигде не вводится. Таким образом, интенсионал и символ слиты в одно, что позже обязательно читателя запутает.

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

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



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

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



Вот тут уже хочется материться. На основании каких гр...ых признаков классифицированы эти объекты??? В этом горе-классификаторе перемешана куча оснований классификации. Впрочем, у нас и в ГОСТах такие классификаторы, и в жизни сплошь и рядом... Вот ведь высказали хорошую идею про то, что классифицировать надо не абы как, а по каким-то основаниям, и тут же все испортили.
Ну и до кучи уж оказывается, что классы и множества - это разные вещи.

На этом остановлюсь. Дальше в учебнике так и идет - хорошие и правильные мысли вперемешку с запутыванием. Если еще представить, как это все будут толковать учителя, в меру своего понимания - бррр, страшно. Я сам по диплому учитель физики и информатики, учителей видел много, так что хорошо знаю, о чем говорю :)

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

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


>> ... при присвоении имени нужно стремиться к тому, чтобы "у всех объектов множества имена были разными". Оставим в стороне ехидный вопрос "какого множества?" и обратим внимание на то, что это больше смахивает на идентификатор, а не на имя. Разность семантики имени и идентификатора, думаю, объяснять не надо.

Надо. Это же проблема нахождения качественного естественного ключа, особенно который был бы уникален для всех объектов, а не просто для большинства.


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

Естественные ключи для различения объектов ведь только по набору признаков и могут формироваться. А признаки - они всегда изменчивы (берёзу, например, пересадить могут) . Хороший тон - это что, суррогатные ключи?


>> "береза" хорошее имя для класса, но плохое - для объекта, даже если он один у нас в моделируемой области

Я уже запомнил, что для класса хорошее имя "березы", поэтому "береза" - неплохо для объекта.


>> С философской точки зрения ... Таким образом, интенсионал и символ слиты в одно, что позже обязательно читателя запутает.

По-моему, очень мало и редко где нужно их различать. Когда возникнет необходимость, подросший читатель разберется в разнице между интенсионалом, символом, экстенсионалом. Это действительно больше в области философии, чем информатики.


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

Это скорее модальная логика. Бегающие объекты - это те кто бегают, или те кто должен бегать, или те кто может бегать? Собака бегает - это признак, а вот она остановилась и уже не признак?


>> Из объяснения становится понятно, что под свойствами понимаются, переходя на привычный мне язык, как свойства-литералы (температура, размер), так и свойства-связи (цвет, материал). Только это разделение в учебнике не дается. Про отношения между объектами речь идет дальше, и они описываются совершенно по-другому. А то, что "материал" объекта - это никак не литерал, а свойство-связь, ибо любой материал тоже есть объект или множество, не говорится ничего.

Всё не так однозначно. Если "материал" объекта условно выбирается из справочника материалов, то вполне себе может быть литералом. Он становится объектом или множеством только если нас начинают интересовать его собственные признаки и отношения. При этом он переходит из категории reference data в категорию master data.


>> Вообще, множества и объекты постоянно путаются, несмотря на то, что в начале было благонамеренно заявлено их различие.

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


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

А как нарисовать "дом вообще"? Схема на рис.11 подходит как для (почти) любого дома из множества домов, так и для конкретного дома. Для "дома вообще" я бы указал что некоторые элементы могут быть опциональны, а некоторые сочетаются или наоборот несовместимы между собой, а также указал что дополнительно могут быть любые другие элементы по желанию. Я такую схему называю шаблоном типового дома.

Мы тут обсудили с Максимом Мирошниченко и выяснили природу моего разрыва в сознании при чтении учебника :)

Его авторы в глубине души думают в терминах ООП, где класс - это шаблон для создания объектов, обладающих атрибутами и методами. Но в тексте они эти классы зачем-то называют множествами, хотя множества - это совсем другое. Это про класс в OWL можно сказать, что он описывает множество.

Про естественные ключи, имена и идентификаторы. Я лично считаю хорошим тоном не значащие уникальные идентификаторы типа guid. Конечно, шестиклассникам про это не надо говорить.
Имя может быть совершенно любым, не обязано быть уникальным. Мы прекрасно знаем, что люди часто одно и то же называют разными именами, или наоборот - одним именем называют разное, и в принципе как-то понимают друг друга. То есть здорово было бы придумать для всего уникальные имена, но на практике так сделать точно не получится. Да и унифицировать контексты разных людей тоже не получится.
А естественные ключи вообще коварная штука: сегодня он естественный и уникальный, а завтра что-то изменилось в мире - и он потерял уникальность. Или для меня он естественный, а для кого-то не очень, т.к. у этого другого иной взгляд на свойства, из которых я решил формировать ключ. В общем, особой прагматики в них я не вижу, а потенциальные проблемы - вижу.

Про слово "береза" как имя для объекта - тут вообще бездна. Тут можно долго рассуждать, но я скажу только, что указанием числа (березЫ или березА) точно не отделаться для различения объекта и множества.

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

Про материал и свойства-связи бы поспорил, но понимаю, что тут есть исторически сформировавшиеся парадигмы: например, довольно искусственное деление на мастер-данные и НСИ. С точки зрения OWL, (не-)обладание собственными свойствами не является основанием для того, чтобы моделировать нечто как индивидуальный объект, а не класс. В смысле, что могут быть индивидами и объекты, не имеющие вообще ничего, кроме идентификатора.

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

"Дом вообще" я бы нарисовал схематически, без текстур и деталей. И да - подчеркнул бы, что это шаблон (возможно - нарисовав рядом конкретный дом, который ему соответствует).


Пока ООП в мейнстриме, пусть уже лучше в его русле думают. Гради Буч и Шлеер с Меллором ведь не пытались никого одурачить. А то что терминология у программистов не бьется с математической, так это не такая трагедия, как её выставляет Максим ;-)
В ООП-рограммировании ведь проблема с реализацией множеств. Андрей Сергеев неплохо это показал в статье http://www.ritba.ru/modeling-programming
А отличия класса от множества действительно зависят от парадигмы моделирования.

GUID это и есть суррогатный ключ. Он нужен при программировании, но в информатике (особенно детской) моделирование происходит не в программной среде, а скорее в голове и на бумаге, где не обеспечивается удобства генерации таких ключей. Не зря ведь ходят шутки про программистов, называющих обычные вещи и близкое окружение (кошку, например) машинными литерами-идентификаторами. Человеку нужно различать объекты между собой, а уж каким способом происходит это различение, уже не так важно.
У guid-ов есть большой минус - они способствуют тому, что каждый автор модели или БД начинает выделять свои уникальные идентификаторы для тех объектов, классов, признаков и т.д, которые до него уже по-своему проидентифицировал другой автор. И когда наступает пора сопоставить их между собой, то суррогатные ключи только мешают, навязывая решение по ручному ведению перекодировочной таблицы таких идентификаторов. А если пользоваться естественными ключами, при всех их недостатках, то сопоставление начинается делаться на правилах, которые отражают суть предметной области и явно показывают различия в подходах моделирования разных авторов. Так что прагматика здесь есть, только не для программистов, а именно для информатиков.
И вообще, кто сказал что естественный ключ должен быть всегда уникальным ;-) Кодд хорошо рассуждал на эту тему - см. раздел 4 в его статье http://www.osp.ru/text/print/article/13031513.html?isPdf=1

Указание множественного числа действительно не всегда отличает объект от множества/класса. Например "любая берёза из этого парка" - это что?

С методом run() в ООП тоже не всё просто. Его ведь могут включить в класс, но никогда не вызывать. Думаю, самая главная модальность здесь - предназначение, а уже обязательства/возможности/действия/поведение определяются полной таблицей переходов из одного состояния в другое.

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

Абсолютно согласен, что понятие контекста - это то, чего не хватает всем парадигмам моделирования, и вводить его надо чем раньше тем лучше. В лингвистике Лакофф очень хорошо показал наличие контекста по-умолчанию, а Болдачев по этому поводу давал дельные предложения https://habrahabr.ru/post/276271/

"Дом вообще" из учебника именно для вас содержит текстуры и детали, а для какого-нибудь инженера-строителя не содержит никакой конкретики. Спросите у сына, что он думает по этому поводу? ;-)

Edited at 2016-09-09 04:38 pm (UTC)

Вот у меня есть ощущение, что ООП пора выходить из мейнстрима. По большому счету все хорошее, что можно было с его помощью сделать - уже сделано, и дальше эта парадигма только тормозит развитие. Надо бы переходить к моделе-ориентированному программированию. До людей эта идея нелегко доходит, но многих думающих ИТшников мне удалось в этом убедить :)

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

Да еще и проблема выделения объектов к этому же относится: я вижу три объекта, а кто-то их объединяет в один. Тут естественные ключи точно не помогут, а в случае с суррогатными ключами вполне можно этот факт отразить.

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

За ссылки спасибо :)



Приведу пример "немного плохого" общеупотребимого естественного ключа, из своей производственной практики. Объектов мастер-данных у нас несколько десятков тысяч, и абсолютное большинство их (порядка N=90%) уникально идентифицируются парой атрибутов A (строковый литерал) и B (ссылка на reference data, которые для госорганов являются уже master data). Так вот оставшееся меньшинство объектов (около 10%=100%-N) уже не уникально идентифицируются парой A+B. Это меньшинство отличается от большинства особым значением атрибута X=x1 (где x1 - одно из допустимых значений x1,x2,x3,...). И вот объекты этого меньшинства уникально идентифицируются уже не парой, а большим количеством атрибутов A+B+C+D+..., причём доп.атрибуты C,D,... отсутствуют у объектов из большинства (N).
Получается такая схема ключа: IF X==x1 THEN KEY in (A,B,C,D,...) ELSE KEY in (A,B)
Если разбить полный домен объектов мастер-данных на два (N и 100%-N), то можно считать у каждого из них уже "хороший" естественный ключ ;-)


Edited at 2016-09-11 07:13 am (UTC)

А как в логической парадигме решаются проблемы объединения ограниченных множеств в более полное? Конкатенацией owl-файлов здесь не обойтись.

>> "Дом вообще" я бы нарисовал схематически, без текстур и деталей. И да - подчеркнул бы, что это шаблон (возможно - нарисовав рядом конкретный дом, который ему соответствует).

Были попытки даже создать тестовый язык описания таких шаблонов https://projects.info.unamur.be/tvl/ https://projects.info.unamur.be/tvl/files/PloneMeeting-Draft-Parsed-v1.tvl https://pure.fundp.ac.be/ws/files/1064069/70765.pdf
Интересно, а в OWL такое выразимо?

>> В этом горе-классификаторе перемешана куча оснований классификации. Впрочем, у нас и в ГОСТах такие классификаторы, и в жизни сплошь и рядом... Вот ведь высказали хорошую идею про то, что классифицировать надо не абы как, а по каким-то основаниям, и тут же все испортили.

Иллюстрация конечно неудачная, потому что не подписаны сами основания классификации, которые в реальных объектах действительно накладываются друг на друга весьма причудливым способом, что даже специалист не всегда с ходу отличит фасету от иерархии и от группировки частей в целое. Неплохим примером классификации является Приложение 2 к ГОСТ 17398—72 по насосам.

Боюсь что свойства, определяемые списками значений - для них абсолютно отдельная вещь, и они просто не поймут наше объяснение про свойства-связи. Drop-down list, и всё тут. Какие отношения? :-(

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

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

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

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

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



Дай лучше ссылку, видео не показывает.

https://www.youtube.com/watch?v=mppP6OLlSVA
Где-то с 1:00 по 2:20.

  • 1
?

Log in

No account? Create an account