Category: наука

Category was added automatically. Read all entries about "наука".

Шаблонные вопросы - некоторая предыстория

Попытка визуально отобразить их впрямую через нотацию части 2 приводит к достаточно странным конструкциям (пример: развертка Figure 11 из части 7):

Collapse )

1) по части 7 стандарта "словесно" шаблон описывается как упорядоченный список троек:
"номер роли - имя роли - тип роли (=ограничение типа накладываемое на сущность)"

в-нотации-части-2 шаблон трактуется как ClassOfMultidimensionalObject, который агрегирует в себе упорядоченный список RoleAndDomain в атрибуте roles (и более никакие атрибуты не используются).
т.е. два элемента тройки (имя роли и индекс) имеют место быть, но последний элемент по этому определению находится непонятно где.

на картинке с fig.11 его пришлось реализовывать в отдельной ветке схемы.

хотя, в общем был возможен, например, такой вариант использования атрибута parameters:
Collapse )
ну или такой предельный вариант в стиле "все одним куском":
Collapse )

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

2) связь составляющих-шаблон-RoleAndDomain с конкретными данным через подразумеваемое-стандартом-отношение-классификации запутывало дело. на картинке выше эту связь пришлось выражать пунктиром.

складывается впечатление, что RoleAndDomain - это как раз одна из особенностей, которые делают примененную в стандарте теорию множеств non-well-founded.

RoleAndDomain - это как-бы-Class, но "как-бы-классифировать" он может любую Thing - от Абстракции и Индивида до ClassOfClass и выше.

концепция level-ов в этом случае страдает (как в примере с fig.165 тут http://dot15926.livejournal.com/26560.html)

3) кроме всего прочего, на данном этапе пришлось пожертвовать явным-отображением-нумерации элементов списка RoleAndDomain.

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

----------

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

Collapse )

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

Collapse )

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

методика его применения, по моему разумению, может быть примерно такой:
Collapse )
flow

Форматы данных ISO 15926

Часто возникает путаница в вопросах, связанных со стандартом ISO 15926:

1. Что именно, и в каких машиночитаемых форматах данных специфицируется в различных частях стандарта.

2. Какие следует использовать форматы для описания иной информации по стандарту ISO 15926, будь то локальные онтологии или каталоги.

3. Как учесть их разнообразие в программных продуктах.

Разберёмся по порядку.

Прошлое.

Следуя традициям ISO/TC184/SC4 каждый следующий стандарт должен опираться на уже стандартизированные ранее решения. Так произошло с ISO 15926 по отношению к ISO 10303. В частности, из ISO 10303 был унаследован язык описаний EXPRESS. Именно на нём было осуществлено формальное описание типов в части второй ISO 15926. С этим описанием можно ознакомиться **здесь**. Присутствуют иерархия типов и указание типов ролей, имена указываются в нижнем регистре с подчёркиваниями, пример: class_of_class_of_individual. Однако, позже EXPRESS сочли менее подходящим для онтологических задач, что связано как с ограниченными возможностями языка, так и с недостатком инструментальных средств. Стандарт ISO 15926 стал разворачиваться в сторону OWL. Даже в "вечно доделывающейся" части 3 сейчас приводятся примеры на EXPRESS и примеры на OWL, параллельно. По факту, поддержка EXPRESS уже не требуется для работы с описаниями стандарта ISO 15926.

Настоящее.

Для возможности работы с распространённым онтологическим инструментарием (в частности, Protege) была выпущена OWL версия описания части 2, с использованием диалекта OWL-DL, за ней последовало описание части 4, а далее и реализация стандартной RDL на базе OWL формата. Список файлов частей 2 и 4 также отдельно указан на https://www.posccaesar.org/wiki/ISO15926inOWL

http://rds.posccaesar.org/2008/02/OWL/ISO-15926-2_2003
Описание иерархии типов и ролей части 2. Этот файл необходимо загружать в систему с поддержкой OWL-DL или распознавать в своё локальное представление во всех тех случаях, когда в программном продукте требуется поддержка ISO 15926. Содержание почти совпадает с описанием в EXPRESS, но содержит отличия, специфичные именно для использования OWL в качестве контейнера. В тои числе, используется иной способ задания имён (CamelCase) и префикс has для ролей, пример: ClassOfClassOfIndividual и hasIndividualDimension. Более подробно: https://www.posccaesar.org/wiki/ISO15926inOWLtranslateEXPRESStoOWL

http://rds.posccaesar.org/2008/07/OWL/ISO-15926-2_2003_annotations
Дополнительный файл, содержит человекочитаемые описания типов части 2 (в виде definition, note и example), взятые напрямую из текста стандарта. Полезен как подсказка пользователю.

http://rds.posccaesar.org/2008/07/OWL/ISO-15926-2_2003_entityMembership
http://rds.posccaesar.org/2008/07/OWL/ISO-15926-2_2003_entityMembershipCandidates
Дополнения с описанием ограничений на entity membership (отношение Classification), что именно связывает *Something* и ClassOf*Something*. Эта информация есть только в OWL и может быть использована как в редакторах, так и в отдельных верификаторах. Более подробно: https://www.posccaesar.org/wiki/ISO15926inOWLPart2EntityMembership

http://rds.posccaesar.org/2008/09/OWL/ISO-15926-2_2003_inverseRoles
http://rds.posccaesar.org/2008/09/OWL/ISO-15926-2_2003_chainedRoles
Некий дополнительный сахар для ручных экспериментов с OWL-DL инструментарием. Новой информации не содержат, в применении не замечены.

http://rds.posccaesar.org/2008/02/OWL/ISO-15926-6_2008_Draft
Заглушка с перечислением пяти аннотаций части 6 нестандартным образом. На практике бесполезна, но на неё ссылается OWL-версия части 4 для обеспечения целостности. Следует сразу отметить разницу кодирования имён свойств: part6:designation в заглушке (и, соответственно, OWL части 4) vs. rdl:hasDesignation в RDL.

http://rds.posccaesar.org/2009/08/OWL/ISO-15926-4_2007
Стандартное OWL представление части 4. Следует отметить:

1. Способ работы с аннотациями части 6 в этом файле отличается от принятого сейчас в RDL, как уже упоминалось выше.

2. Также, в описании части 4 продублированы фрагменты части 2. Одновременно присутствуют "типы части 2 из стандартного OWL части 2" и "типы части 2 из OWL части 4". Вероятно, это делалось под особенности/глюки конкретного инструментария, но на деле может приводить к проблемам софта или неясности для пользователся, поэтому требует отдельного учёта при загрузке части 4.

http://rds.posccaesar.org/2009/08/OWL/ISO-15926-4_2007_NonReifiedRelations
Альтернативное представление части 4. Использованию не подлежит, так как:

1. Может быть автоматически получено из предыдущего, но не наоборот.

2. Приводит к значительной потере информации. В том числе, вместо part6:definition, part6:notes, etc появляются машинно-неразличимые rdfs:comment.

3. Ещё более несовместимо с RDL.

http://rds.posccaesar.org/downloads/PCA-RDL.owl.zip (https://www.posccaesar.org/wiki/Rds)
Здесь представлена стандартная библиотека RDL. Постоянно обновляется. Представляет собой наиболее актуальный пример информации, закодированной по стандарту ISO 15926. При этом:

1. Использует стандартное описание (см. выше) и пространство имён part2 для типов части 2. Пример: part2:ClassOfInanimatedPhysicalObject.

2. Использует своё внутреннее пространство имён для аннотаций части 6. Пример: rdl:hasDefinition.

3. Таким образом, несовместима с пространствами имён и моделью именования как OWL части 4 (см. выше), так и более поздних описаний стандарта части 8 (об этом далее).

Будущее.

Часть 7 (ISO/TS 15926-7:2010) добавляет в стандарт шаблоны (templates) и язык логики первого порядка (FOL), с применением синтаксиса инструментов Prover9 и Mace4, для работы с этими шаблонами. Именование типов (DimensionOfShape) и ролей (hasShape) стилистически совпадает с принятым в OWL. Помимо текста стандарта рекомендуется прочитать статью https://www.posccaesar.org/wiki/IdsAdiTemplateAxiomatizationTools Но следует учесть, что часть 7 не вводит нового OWL-кодирования, и даже примеры на XML и OWL в статье носят характер иллюстративных набросков, на деле вопросом совмещения OWL и шаблонов занимается только часть 8 стандарта.

По адресу https://www.posccaesar.org/wiki/ISO15926inFOL приводятся описания ISO 15926 в FOL.

http://rds.posccaesar.org/2009/06/P9/ISO-15926-2_2003.txt
FOL версия описания типов части 2. Содержит часть информации из OWL версии и может быть получена из неё автоматически. Пригодна для экспериментов с Prover9, а также рекомендуется к прочтению для понимания связи между OWL и FOL. Но для работы с ISO 15926 не подходит, слишком многое потеряно.

http://rds.posccaesar.org/2009/06/P9/ISO-15926-7_2009_intitialTemplateSet.txt (можно не обращать внимания на опечатку "intitial", уж так выложили на сайте)
Аксиомы шаблонов в FOL. Фактически - макросы, так как для описания этих аксиом по стандарту используется очень ограниченное подмножество FOL. В любом инструментарии с поддержкой поднятия/опускания шаблонов придётся загружать этот файл, так как к части 8 прилагается машиночитаемое описание лишь сигнатур шаблонов, а все аксиомы благополучно забыты.

http://rds.posccaesar.org/2009/06/P9/ISO-15926-7_2009_intitialTemplateSet_ISO-15926-2_2003.txt
Копия содержимого двух вышеупомянутых файлов.

Далее появляется долгожданная часть 8 (ISO/TS 15926-8:2010) - описание методов кодирования информации в OWL. Её задача - навести порядок в области машинных представлений. Однако, бардака становится больше.

1. Пространство имён dm (приложение data-model.owl) ещё раз альтернативно задаёт типы части 2, и именно оно используется во всех остальных материалах части 8 вместо уже устоявшегося метода кодирования типов части 2 из http://rds.posccaesar.org/2008/02/OWL/ISO-15926-2_2003 (который применяется как в OWL части 4, так и в RDL). Ключевая разница - в dm нет ролей, часть 8 не работает с понятиями ниже уровня протошаблонов (proto-templates части 7). У dm:Classification отсутствуют роли, только у протошаблона p7tpl:Classification появляются роли hasClassified и hasClassifier.

2. Однако, в исходниках iRingTools есть запросы и заполнения ролей dm:hasClassified и dm:hasClassifier именно для dm:Classification, что идёт в разрез с частью 8. Статус такого применения не обозначен, и в частях/приложениях стандарта оно не встречается.

3. В очередной раз (Annex F) приводится свой альтернативный вариант именования метаданных части 6. Однако, не указывается даже пространство имён для него.

4. Поддерживается сохранение сигнатур шаблонов, но не поддерживается сохранение их аксиом - аксиомы предлагается хранить в неупорядоченных комментариях (rdfs:comment).

5. Пространство имён p7tpl (приложение templates.owl) содержит описания сигнатур всех стандартных шаблонов части 7, но аксиомы шаблонов потеряны (даже в комментариях их нет). Для поддержки поднятия/опускания template statements необходимо использовать внешнюю информацию из http://rds.posccaesar.org/2009/06/P9/ISO-15926-7_2009_intitialTemplateSet.txt

Обобщение.

1. У нас есть пара стандартных вариантов задания типов части 2 в OWL. Первый (part2:*) для работы через экземпляры отношений (часть 4, RDL и всё остальное, созданное до частей 7 и 8). Второй (dm:*) для работы через шаблоны. Однако, второй вариант только перечисляет типы, для нормальных проверок (включая entity membership) в любом случае понадобится информация из первого.

2. Есть минимум четыре способа задания метаданных (annotations:*, part6:*, rdl:*, а также "часть 6 в интерпретации части 8, с неопределённым пространством имён"). Автоматическая конверсия между ними невозможна (нет однозначного соответствия). Только пользовательскими скриптами, когда сам пользователь чётко знает, что может/должна значить в этом конкретном файле эта конкретная аннотация.

3. Есть три основных способа задания информации (исключая метаданные) об экземплярах типов части 2: использующийся при описании части 4, использующийся в сегодняшнем RDL и третий, предлагаемый в части 8. В программном обеспечении требуется раздельная поддержка всех трёх. Автоматическая конверсия между ними возможна, хотя может быть сложна (особенно вычислительно, если требуется опускание template statements). Но это чревато потерей метаданных (см. выше).

4. Часть 8 пока только вводит дополнительные проблемы. Так как не может выразить ни системы типов части 2 (отсутствуют абстрактные типы, entity membership, etc), ни системы шаблонов части 7 (отсутствуют аксиомы шаблонов), ни аннотаций части 6 (Annex F задаёт "общее направление" без чётко определённого пространства имён и списка аннотаций). Как (и в какие сроки) эти проблемы будут решаться, и каким будет "RDL завтрашнего дня на базе части 8" предположить сложно.

Выводы.

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

2. Так как слишком многие use cases по загрузке и сохранению информации (и метаданных) не могут быть заранее учтены автоматическими решениями, то для широкого применения продукта требуется доступ пользователя к низкоуровневому OWL - включая поддержку пользовательских скриптов и запросов, а также отдельное визуальное представление.

3. Порог входа для работы с полным ISO 15926, включая части стандарта и все возможные форматы данных, метаданных, etc, является неоправданно высоким. Поэтому следует сразу учесть возможность разных версий/режимов работы продукта для "моделеров с чёрным поясом" (включая авторов стандарта) и для обычных пользователей в разных предметных областях, которых не волнуют особенности доступа к RDL, но которым важны поставляемые с продуктом готовые библиотеки.
2021 год
  • ailev

Computer science и ontology science как методы решения задач

Понятно, что излагаемое в computer science и ontology science (см. http://community.livejournal.com/dot15926/17474.html) содержание -- это методы, т.е. способы описания мира при помощи формальных языков, подразумевающих какие-то интерпретаторы ("машины") этих языков. Тем не менее, какой-нибудь учебник computer science трудно разложить по привычной структуре метода, которую нам даёт ISO 24744. Ибо излагаемое не требует коллективной деятельности, не имеет инженерной природы (всё инженерное попадает сразу в software engineering и ontology engineering, и там сразу всё становится просто).

Тем не менее, computer science как-то учат. Это значит, что метод как-то передаваем. Какие есть ходы на экспликацию метода из текста-об-устройстве мира?

1. Опереться на то, что задание объекта возможно лишь в терминах операций с ним. Так, ежели учить арифметике, то продукты работы -- числа, системы уравнений. И есть практики сложения, вычитания, решения систем уравнений. Роль -- расчётчик. Инструмент -- калькулятор. Язык теории чисел, нотация математическая. Решение арифметических задач при этом -- это уже инженерия (жизненный цикл задачи: формулирование условия, нахождение архитектуры решения, изготовление решения, верификация, использование решения).

2. Опереться на то, что отмоделированные умения передаются в форме упражнений (http://ailev.livejournal.com/875198.html). Эти упражнения -- и есть практики. Когда эти практики освоены, то метод передан.

Как, например, ввести 4D экстенсионализм как метод обеспечения масштабируемости схемы данных в условиях непрерывного ее пополнения и необходимости сохранять историю изменений (для каждого метода, каждой практики нужно указывать назначение)? В этом методе можно выделить отдельные практики (в этом и есть отличия методики от учебника):

1. Практика "альтернативного времени" для обсуждения истории: "вечные классы", которые имеют "вечных членов", существовавших, существующих и потенциально будущих существовать ("возможные миры") в 4D. Интенсиональное определение 3D классов против экстенсионального определения 4D классов. [например, это важно для разбирательства, какие классы имелись ввиду в стандартах -- там могут обнаружиться интенсионально определенные 3D классы, и их придется переинтерпретировать]. Контрольный вопрос: "сколько членов сейчас в данном классе?", а затем "а сколько членов было? сколько членов будет?" -- ответ скажет, в какой парадигме мыслит вопрошаемый.
2. Практика соорганизации растущего числа предметных знаний (появление всё новых групп и методов описаний): сосуществования уровней реальности, практика power sets (class of class). Особенности классификации и членства. Отличия от специализации.
3. Практика усмотрения activity за отношениями для решения проблемы cardinality для предотвращения потери истории "атрибутов". Заменяемые части как роли в отношениях. Роли как состояния. Проблема переносимых cardinality и потери истории.
4. Практика обсуждения с использованием пространственно-временных диаграмм.
5. Практика использования 6й нормальной формы для максимальной компактификации и предотвращения переписывания непрерывно дополняемой модели данных.

Еще одно отличие методики от учебника: в учебнике правильно было бы говорить, как решается та или иная проблема в онтологической науке в целом. А в данной методике нужно говорить, как решается эта проблема в ISO 15926, и не давать объяснений типа "так же, как в DOLCHE или CYC, но с особенностями такими и сякими" или "согласно воззрениям Гуссерля, только с отличиями тут и тут". Нужно сразу формулировать "как надо", хотя у этого подхода, конечно, есть и недостатки: узкий онтологический специалист будет подобен флюсу, полнота его будет одностороння. Но нам нужно готовить не онтологов-исследователей, а промышленных онтологов.

Так же подробно на более мелкие практики нужно разбивать следующие практики "науки" онтологизирования:
-- практика факт-ориентированного безатрибутного описания, чтобы отразить множественность предметных областей ("что для одного проекта атрибут, то для другого проекта класс": результат проект EPISTLE).
-- практика онтологического (соотносимого с физическим миром) описания, обеспечивающее гарантию договоренности в рамках общей картины мира -- против даталогического (принятого в computer science) манипулирования только символами – отличия от MDM-стандартов и стандартов типа ISO 12006-3.
-- практика использования шаблонов для подъема уровня языка. Выражение в шаблонах против выражения в семантической сети. Использование "только сигнатур" против "полноценных шаблонов с графом подъема-опускния".
-- практика различения понятий (идентифицируемых по URI) и их имён для организации словарей.
-- практика использования трипл-представления данных ISO 15926 для облегчения обработки данных. Особенности использования RDF и OWL для представления семантики (четыре разных типа OWL-файлов для части 2, AnnotationProperties в OWL и xml:lang)
-- практика характеризации через Gellish [в перспективе, не сейчас] для упрощенного применения шаблонной техники ISO 15926

Скорее всего, практика использования 4D системы (в общем виде, а не на примере заменяемого тега в составе железной системы), а также 4D-метода -- это тоже "онтологическая наука", а не онтологическая инженерия или прикладная дисциплина. Это означает, что практики использования .15926O должны рассматриваться в рамках дисциплины "онтологической науки".

А вот "моделирование тега в ходе жизненного цикла установки" -- это уже прикладная дисциплина "характеризация/онтологизация/моделирование инженерных данных".

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

Плюс для освоения каждой практики нужны примеры, плюс обязательны упражнения.
2021 год
  • ailev

Система -- это функция и конструкция, представленные в различных группах описаний

.15926O состоит из нескольких онтолетов:
а) системного подхода -- в котором дается понятие системы и связанные с ней понятия. Предлагается сделать это с опорой на онтолет системы, описанный в приложениях к ISO 15288 и ISO 42010
б) программирования -- которое мы понимаем как информационное моделирование/онтологизирование. Это мы пока подробно не разбирали.
в) метода, которое мы должны будем сделать на базе переформулированного в терминах системного подхода и расширенного обоснованиями ISO 24744 (спасибо Harold Lawson, который указал на то, что описания метода должны быть сформулированы в терминах понятий системного подхода -- и именно это он проталкивает в SEMAT).

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

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

1. Различение у системы внешнего определения (функции) и внутреннего устройства (конструкции). Архитектурное моделирование, как способ показа связи функции с конструкцией -- только модель может определить/показать, как связана функция с конструкцией. Организация -- это организация материала (подсистем), для того, чтобы соответствовать функции (системы). Холон представляет собой единицу, которая вовне представляется функцией в объемлющей системе и сама по себе элемент конструкции.

2. Дискуссия вокруг functional_physical_object, затеянная Hans Teijgeler (http://www.15926.info/ и тред в LinkedIn. По сути, всё сводится к "абстрактному" пониманию "функции" и "материальному" (в пределе -- физическому) пониманию "конструкции".
Вся эта "четырехуровневая архитектура" ISO 15926 (которая не четырехуровневая, и не архитектура) -- это то, как "функция" переходит в "конструкцию" по мере жизненного цикла холона в системе (сначала этот холон определяется функционально все более подробно, а затем становится понятна его конструкция в какой-то момент -- и после этого наступает реализация).
Тут же -- дискуссия о модели системы (описании функции и конструкции системы) и самой "железной" системе (система -- это класс или экземпляр?).
Проблема в том, что в реальной жизни существенно путаются:
а) функция и конструкция -- инженеры и функцию и конструкцию называют одинаковыми именами, после чего регулярно путают в типизации (относят онтологически к не тому классу, после чего удивляются, почему к функции неприменимы операции, которые можно сделать только с конструкцией, и наоборот).
б) класс (чертеж), класс (каталожная деталь) и экземпляр (железная деталь, в том числе установленная на место, обозначенное в чертеже). Например, в каталожной спецификации путаются как элементы функции, так и элементы конструкции ("сборочное описание"), так и элементы, подтверждающие их связь (архитектурное описание, поведенческие модели).
Тем самым, разделение функции и конструкции -- контринтутивно для сегодняшней инженерии (и уж совсем запредельно для не-инженеров).

3. Обсуждение в книжке Jan Dietz "Enterprise Ontology" об "уровнях организации" (когда каждый уровень организации обсуждается в терминах "функции" по отношению к нижележащему -- "конструкции"). Это же обсуждение верно для многих других случаев "уровней организации" (например, веерные матрицы -- физический уровень представляет собой "конструкцию" для "функций" химического уровня. С другой стороны, "конструкции" химического уровня служат организованным материалом для функций генетического уровня и т.д.).

4. Гипотеза: для обсуждения любой системы нужно иметь не менее двух онтолетов -- один для описания ее функциональности, другой для описания ее конструкции. Наличие веерных матриц позволяет сделать гипотезу, что этих онтолетов может быть некоторое количество. Тут нужно указать, что разница между "многоуровневым" функционально-конструктивным и "многоаспектным" по ISO 42010 описанием пока не слишком понятна -- можно ли выразить многоуровневое описание в рамках одного предметно-специфического архитектурного фреймворка, или каждый такой фреймворк работает только на стыке двух ближайших уровней организации системы -- это нужно еще обсуждать.
Тем самым идея многоаспектного описания, сопряженная с понятием системы и ее архитектуры, и идея онтолета как локальной онтологической единицы для какой-то предметной области (как-то соответствует viewpoint из 42010 и language из 24744) -- это близкосвязанные идеи. Так, .15926N должен как-то это учитывать при работе с онтолетами (например, группировать их в рамках каких-то единиц более высокого уровня -- тех же architectural framework).

5. Функция плюс много конструкций, конструкция плюс много функций: модуль (функциональность) против системы (понимаемой тут как конструкция). Это обсуждается в довольно глубокой работе Wim Gielingh по Extended GARM (http://www.15926.info/functional-physical-object/GARM-paper.pdf). Тут же обсуждение "параметризации" как функции и "генерации" конструкции соответствующей функциональной моделью. Тут же понимание функции как design intention и конструкции как design solution.

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

Требуется: разработать компактный высокоуровневый (upper ontology) онтолет, в терминах которого выразимы все вышеприведенные идеи для "системы": многоуровневость организации (холархия), архитектура, функция и конструкция, архитектурное многоаспектное описание и т.д. (гипотеза: многоаспектное описание не удастся выразить без онтолета информатики).

Потом этот онтолет (и связанные с ним контринтуитивные идеи) нужно применить к методу-как-системе ("архитектура метода", "функция метода", "конструкция метода" и т.д.), рабочим-продуктам-как-системе для получения онтолета метода.
Sharge
  • vvagr

Из частной переписки о проблемах онлайновых RDL

Вот копия переписки, продолжать имеет смысл тут.

---------------------------------------------------
vvagr

Коллеги,

Я тут озаботился сличением RDS/WIP и текста Части 2, и чего-то я не понимаю.

Текст Части 2 предписывает иерархию типов, и описывает её на EXPRESS. Например,

5.2.1.1 abstract_object
An abstract_object is a thing that does not exist in space-time.
EXPRESS specification:
*)
ENTITY abstract_object
ABSTRACT SUPERTYPE
SUBTYPE OF(thing);
END_ENTITY;
(*


Однако RDL содержит в качестве типов что-то совсем иное:

http://rdl.rdlfacade.org/data?info=http%3A%2F%2Frdl.rdlfacade.org%2Fdata%23R15718913304

RDS/WIP URI http://rdl.rdlfacade.org/data#R15718913304
Label ISO 15926-4 ABSTRACT OBJECT
Description A thing that does not exist in space-time
Entity Type http://dm.rdlfacade.org/data#ClassOfAbstractObject

Правильная типизация находится в разделе

Specialization

* ISO 15926-4 THING
* ISO 15926-4 CLASS
o ISO 15926-4 ABSTRACT OBJECT
o ISO 15926-4 THING

То есть иерархия типов Части 2 заменена в RDL на иерархию классов и эта иерархия ещё и закольцована?

Кто-нибудь вообще понимает появление в RDL элементов с префиксами ISO-IS 15926-2 и ISO 15926-4 ? По какому принципу они расставлены?

---------------------------------------------------
avalsov

Эти товарищи в какой-то момент решили описать модель 15926 в терминах самой себя :). Ну и включить ее в RDL. Модель 15926 настолько гибка, что это позволяет :).

А для различение этих "понятий" ввели префиксы. Т.е. префикс ISO-IS 15926-2 означает "исходные" entity описанные 15926-2, а ISO 15926-4 - их counterparts в RDL.

---------------------------------------------------
kir_lis

Об этом же подумал.

Но отношения или их отображение запутанно, а может не корректно. Есть ситуации, когда классы ISO-IS 15926-2 являются подклассами ISO 15926-4. Например, "ISO-IS 15926-2 PERIOD IN TIME". Отображается, что ISO 15926-4 THING закольцована. Но если пойти на этот класс - там ничего нет в разделе Specialization и есть комментарий разработчика: "Entity type should have been 'thing', but this is an abstract entity type."

Кажется, что есть ошибки в выводе отношений классов.

---------------------------------------------------
algebraic_brain


Мне, как и Кириллу, кажется, что там ошибки в отображении. Не может понятие из части 2 наследовать от понятия из части 4.

Поэтому лучше обращаться к OWL-ам, которые выложены.

С точки зрения теории: необходимо различать сущность (entity) и инстанс (instance). Сущностей фиксированное число и оно не может быть увеличено: 201 кажется, в части 2. Все остальное инстансы.

В этом смысле удобно продублировать некоторые понятия, например 15926-4, как инстансы. Другое дело, что эту иерархию надо правильно отображать.

Я подразумевал ISO-IS 15926-2 PERIOD IN TIME

http://rdl.rdlfacade.org/data?info=http%3A%2F%2Frdl.rdlfacade.org%2Fdata%23R11049706529

Там явная опечатка, должны быть не 15926-4 указаны в специализации, а 15926-2, и тогда все будет соответствовать части 2.

Если есть одна опечатка - скорее всего есть и другие.

Виктор, судя по всему, Ваш приведенный фрагмент на самом деле должен выглядеть так:

* ISO 15926-4 THING
* ISO 15926-2 CLASS
o ISO 15926-2 ABSTRACT OBJECT
o ISO 15926-2 THING

Тогда все будет более-менее правильно.

Нет, все равно неверно. Короче, нужно смотреть в OWL, а не туда.

---------------------------------------------------
vvagr

> С точки зрения теории: необходимо различать сущность (entity) и инстанс
> (instance). Сущностей фиксированное число и оно не может быть увеличено: 201
> кажется, в части 2. Все остальное инстансы.
>

А я не согласен. Я читаю стандарт так:

Ограничено число Entity types.

Сlasses and instances обязательно относятся к одному из 201 Entity types.

Entity types также являются классами, но это такое "совпадение", чтоли :-) Собственно говоря. с некорректного пересечения этих концептов я и начал этот тред.

---------------------------------------------------
algebraic_brain

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

Отсюда возникает необходимость дупликации в "расширябельную" часть.

Но в отображении явные ошибки.