Обсуждение

среди "проверенных на кошках" разбиений эээ десигнаторов на простейшие подвиды, есть например такой: "денотатор" - именует вещь ( "Джек Лондон" ) ~ 15926-шное Definition; "десигнатор" - описывает вещь ( автор "Смока Беллью" ) ~ 15926-шное Description; "коннотатор" - описывает с какими другими вещами эта вещь ассоциируется ("Север,Море,Аляска,Золото,Снег") - не имеет тамочки адекватного представления... P.S. слово stack, кстати, очень смешное в плане того что, вроде бы, нативные-англоговорящие и пиджин-англоговорящие понимают его существенно по-разному. вернее, вторые не вполне осознают, почему-же-именно первые обзывает нечто именно этим словом.

У меня system designator не разбивается на подвиды, он у меня из ISO 81346. Наиболее близкое к этому: TAG IDENTIFICATION CODE : DocumentDefinition (An identification code for a 'functional_physical_object'). The code could consist of characters only, numbers only or a combination of characters and numbers (i.e. an alphanumeric code). TAG NAME : DocumentDefinition (A code intended to reference an item.) Typically it a concatenation of information according to a company specific rule. For example a concatenation of a code for an equipment type, a process unit number and a sequence number of the equipment within that unit. А обсуждавшиеся метки-лейблы, сведённые до уровня комментария это похоже на TAG DESCRIPTION : DocumentDefinition (A description of a 'functional_physical_object').

Если требуется поддержка разных картин мира, то нужен расширяемый язык программирования. В этом направлении можно сделать много хорошего, ещё далеко до потолка развития. Если же делать что-то лишь для единственного представления (ISO 81346 + ISO 15926 + something), то достаточно кубиков DSL. Но это сразу потолок. Потому что картинки могут быть приятнее, чем в предыдущих охапках стандартов, но для интеграции данных (с чем-то не из заранее-прибитого-гвоздями) понадобится полноценный язык, где возможно равноценное представление различных views.

Я ж не возражаю против языка программирования, если он сделан особым образом. Вон, в Лиспе это и программа и данные. Ну и тут можно так же. Но обычно модели вычислений при этом оказываются заумными, я помню попытки сделать модель вычислений для ISO 15926 на заре наших занятий этим. Традиционный ход сегодня -- это разделение языка данных и языка обработки/запросов, а потом языка обработки/запросов и языка мэппинга, все с разными именами но "из одной семьи". Как собрать всё это в один язык я не очень понимаю пока. Но я точно знаю, что хотел бы писать =1 "Pump"<<10 атмосфер так, чтобы компьютер меня понимал. Чтобы компьютер меня понимал, безусловно, язык должен быть расширяем. Я пока вижу только что-то типа макрорасширения на паттернах (grammarware) в части именно расширяемости языка. А вот обработки (помимо расширения языка) должны обеспечиваться самые разные, необязательно на "запросной" или даже "мэпперной" части этого языка. Я не понимаю, как это сделать. В принципе, даже UML расширяемый сделали на базе MOF и стереотипов, и недоразумения типа SysML и SyM (SysML и Modelica в одном флаконе) являются стандартными его расширениями.Расширение языков данных сейчас общее место. Но мы же говорим не о расширении только языка данных, но и о приделывании к нему какой-то модели вычислений. Это уже не так просто -- я поэтому и говорю о том, чтобы при таком приделывании сохранить возможность моделирования, а не только возможность обработки моделей (возможность описания мира, а не только обработки этих описаний).

Смотря как смотреть. Схемы и алгоритмы не похожи на простые табличные "Pump давление 10 атмосфер". Но когда у нас составные идентификации (как по разностандартным неймспейсам, так и по "f x y" вроде Cyc) и различные модальности (давление 10 атмосфер в момент времени T, при условии C, по сведениям из документа D), то получаются... тоже алгоритмы. Алгоритмы описания кусочков мира.

Я не возражаю, что алгоритмы. Только для алгоритмов обычно задаётся модель вычислений -- "выполнитель". Исполнитель это тот, кто знает что-то про кусочек мира. Его дёргает выполнитель, сверяясь с программой. Поэтому нельзя определять только программу. Нужно определять их всех (в том числе понимая, что выполнителя и исполнителя можно подменять при той же программе -- так, компилирование программы это такое особое её выполнение, а расчёт по ней -- ещё одно выполнение, но уже другого рода, с другим выполнителем).

И такие же выполнители для описаний Pump. Одни интегрируют данные в АСУТП, другие облегчают подбор оборудования, etc.

Ну да. Теперь нужно понять, как это указывать. Тут много вариантов: -- ассоциативный (каждый фрагмент кода сам призывает доступных исполнителей) -- есть внешняя по отношению к тексту на языке команда "выполнить X c выполнителем Y" (где X паттерн в данных, а Y функция. То бишь функциональный "снаружи", командная строка) -- выполнение как-то указывается в тексте на языке (язык выполняемый функционально "изнутри" -- так, в процедурных языках где-то есть main proc и известно, что управление вначале будет передано туда, а там уж можно как-то обрабатывать ситуацию "изнутри". Framework)

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

На таком общем уровне всё ОК, осталось теперь понять только, как это может быть реализовано в конкретном языке. Ибо даже такая общая вещь как 2 + 2 в разных языках реализуется ох как по-разному. Так и эти "отношения между A и B", тем более в таком огромном количестве вариантов и по такому поводу как оценка/вычисление/трансформация/поиск/мэппинг.

Поддерживаться должны все случаи. Что-то из коробки, что-то "можете написать свою библиотеку". И только затем на множестве доступных решений появляются свои good practices. Выбор которых зависит не только от качественных, но и от количественных характеристик каждого рассматриваемого проекта.

"Лучше быть здоровым и богатым, чем бедным и больным". Я полностью со всем согласен, но на таком уровне конкретизации можно только написать, что "и чтобы текст был хорошо читаем" или "и поддерживались разные парадигмы вычислений" и т.д.. Мы за всё хорошее и против всего плохого, а детали определим позднее.

Детали сразу. Но не из good practices для насосов. А начиная с человека, с общекультурных (по возможности) когнитивных особенностей.