Вот окрошка из разных мыслей после мероприятия:
1. Сначала скажите, что вы будете с этими данными делать, затем вам будет понятно, какие данные вам нужны. Нет данных без их использования, нет объектов без операций: онтология без эпистемологии не существует.
2. Всех волнует "ISO 15926 inside" -- ибо представление знаний общего вида в мешке не утаишь. Сконцентрировать разговор именно на интеграции данных и "ISO 15926 outside" представляется затруднительным.
3. Ровно потому, что применений рассматривается слишком много, до сих пор нет инструмента -- "технологически зависимой части". Впрочем, нет и тьюториалов по "технологически независимой части". Через год все должно уже быть, но это который уже подряд "следующий год". Такое впечатление, что технологии уже понятны, и дело только за тем, чтобы "бизнес-рискнуть" с вложениями. Пока рискует главным образом Bentley, остальное все внутрифирменное или сырое (как iRing).
4. Мы (TechInvestLab) для себя выделяем следующие интересные применения:
4.1. конкретный синтаксис против абстрактного / технолого-независимая часть против технологозависимой (презентационные уровни, language workbenches, DSL как конкретный синтаксис и OIM как абстрактный синтаксис). Это все браузер/редактор/аквизитор (от knowledge acquisition, см. http://ailev.livejournal.com/400816.html -- первый такой софт я делал еще в 1988 году, и как раз для реального производства, причем в атомной промышленности! Двадцать лет я этим для атомщиков занимаюсь, никак успокоиться не могу...).
4.2. обучение стеку технологий ISO 15926 (включая обучение онтологическому инжинирингу), технологии как методы работы, и далее вся цепочка к situational method engineering. Ибо учить нужно не только "вообще", но и для конкретного инженерного контекста. Не нужно и говорить, что знания о методах неплохо бы представить в формате ISO 15926, "чтобы два раза не вставать".
4.3. выпуск стандартов и технических регламентов (госрегулирование) одновременно в текстовой части и в виде части RDL, чтобы далее обеспечить простоту обеспечения compliance. Стандартизация и моделирование стандартов: с одной стороны RDL (которая ведется, например, национальным органом стандартизации) прирастает и дает возможность быстро и однозначно реализовывать софт, а с другой стороны необходимость моделирования стандарта дает обратную связь разработчикам стандарта и пресекает попытки протащить в стандарт противоречия и двусмысленности.
5. Удивительно, но про шаблоны даже после разъяснений понимает не так уж много людей -- особенно про то, как понимается слово Gellish/Джеллиш (поясняю: Дженерал инжиниринг лэнгвидж, поэтому Джеллиш, а не Геллиш. А еще я считаю правильным и уместным перевод на русский, данный
blogstats: "Аццкий"), представленное во всех презентациях и связанное с будущей Частью 11 Стандарта:а) шаблоны -- это ровно то, как устроена "таблица Джеллиш", прячущая в одном "молекулярном отношении" таблицы на много столбцов двенадцать "атомарных отношений"-триплетов. Поэтому самое подробное описание того, как устроены шаблоны можно прочитать в книжке http://repository.tudelft.nl/file/313741/306185 -- только не ожидать при этом, что описание будет обобщено для "любых таблиц" с представленных в этой книжке канонических таблиц "расширенного представления триплета". "Поднятие" шаблонов -- это как раз табличное представление, а "опускание" -- это погружение их в виде триплетов в хранилище, с раскрытием типа макроподстановки. Опять же, читать нужно с осторожностью, ибо примеры даются с использованием RDL Gellish, а не RDL ISO 15926
б) насчет собственно RDL Gellish (который лежит тут: http://sourceforge.net/projects/gellish) мнения разделились -- одни люди (Онно Паап) считают, что это зло и должно быть оставлено в покое, а брать нужно только "табличное представление" (т.е. шаблоны как способ компактной записи множества триплетов), а другие (Ян Глединнинг) считают, что вполне возможна конвергенция этих абсолютно разных RDL -- ISO 15926 и Gellish, ибо модели данных там в каком-то смысле "похожи" (основная часть моделирована из одних и тех же стандартов).
6. Нужно обратить особое внимание на концепцию "производственного" и "непроизводственного" использования ISO 15926. Ибо инженеры свободно используют уже имеющийся RDL, понимая, что вся их работа -- сплошной "грязный хак". А всякие чистюли типа нас по факту ориентированы на "непроизводственное использование" -- которое крайне важно, чтобы через пару лет не обнаружить себя в центре помойки данных, непригодных к дальнейшему использованию, но которое (как и поддержка любой инфраструктуры, включая уборку помещения) слабо связано с немедленным принесением пользы.
7. Всю работу по интеграции данных лучше давать под именем "управление конфигурацией" (включая кодировку, "tags"). И
8. Во всех документах разделять "технология-зависимую часть" (читай: вендор-зависимую, со всей политической возней вокруг) и "технология-независимую часть" (читай: концептуальную, опирающуюся только на стандарты).