Обсуждение

Замечательная программа, но я в ней опять ничего не понял. Сколько раз пытался изучить этот формат, читать стандарт... Так и ниасилил ни разу. Кроме ощущения, что не про то пишут, ничего не помню. Надеялся хоть какую-то статейку найти понятную в справке, но опять тщетно. Игрушка для каких-то гиков, говорящих на каком-то тарабарском языке. Или я тупой, или проект не взлетит.

А что значит "проект взлетит" -- для исследовательского проекта? Софт этот на самом фронтире соответствующей предметной области, реализует огромный стек технологий. Самоучкой на этом фронтире не просто сработать. Для ISO 15926 есть форумы, проходят скайп-созвоны по три-четыре в неделю. Вот когда-то рекомендованный нами порядок чтения литературы (обратите внимание, стандарт и формат там отнюдь не главное, не их первых нужно читать): http://levenchuk.com/2012/10/01/iso-15926-self-education-sequence/ Ну, и нужно ещё понять, для чего вы хотите использовать софтину. Если поразбираться со сложными моделями данных в промышленных масштабах, то вполне можно её использовать. Если "просто поиграться" на игрушечных данных, то овчинка выделки не стоит: это как потратить время на обучение работы с экскаватором для рытья трёхметровой траншеи. Да, три метра это многовато для ручной работы самому, но учиться на экскаваторщика заведомо дольше.

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

У всех свои проблемы. Например, если вам нужно описывать оборудование, то на 10тыс. видов оборудования (это легко!) вам потребуется завести 10тыс. реляционных табличек для их описания, что уже не просто. Плюс добавьте сюда справочник на пару тысяч единиц измерений, десяток классификаторов, ни один из которых не должен стать главным, и необходимость описывать ситуации в помещением конкретного оборудования с серийным номером в позиции на принципиальной схеме с обозначениями. Модель данных становится суперкучерявой, врукопашную не управиться. В малом или среднем предприятии интеграция обычно может быть сделана на коленке, и не то что трипл-стора, там и MySQL будет много. "Моделирование бизнеса" я не понимаю, о чём речь (ибо бизнес моделируют на каком-нибудь ArchiMate, но у вас тут вроде как про трипл-стор говорится, и я не пойму, зачем он вам). Из нашей софтинки к вашему трипл-стору вполне можно подключиться, что-нибудь на SPARQL оттуда спросить. Только непонятно, зачем. Мы в версии 2 постараемся существенно избавиться от громоздкости, ибо через большой стек стандартов и впрямь тяжело прорваться. И чтобы никаких трипл-сторов не было на поверхности. Основная идея -- это чтобы люди говорили "на псевдокоде", а компьютер потом с использованием справочных данных выводил из этого "псевдокода" нормальные детальные данные, а хоть и в том же трипл-сторе. Ну, и зафиксировать язык описания уровня того же ArchiMate, только с некоторыми дополнительными плюшками. На ArchiMate, например, по определению нельзя описывать оборудование (только данные о нём), а мы постараемся сделать так, чтобы и оборудование тоже можно было описать. Впрочем, я эти планы описывал уже, мы как раз сегодня начали всё это плотно обсуждать. И будем делать небольшой прототип. Так что под разные задачи всегда будут разные инструменты, это мне кажется естественным.

Дык это и в малом бизнесе те же проблемы. Куча справочников в которые пихаются одни и те же данные в разных разрезах. Гляньте для примера на ту же 1с - любая стандартная конфа содержит 2-3 тыщи таблиц в клубок на вполне промышленных субд и с вполне реальными тормозами. И все это гуано глючит неимоверно, криво и неудобно до жути. Может это и не 10 тыщ таблиц, но тоже головная боль. Вот поэтому и триплстор взяли. Чтобы не дублировать данные и упростить модель. И чтобы на будущее расширять. Потому что знаем как это бывает - потянешь за одно, а вытянешь всё (уже тянется). Или придется наводить мосты интеграционные, что само по себе криво, тормозно и глючно. И плюс еще триплстор выбран чтобы изменения быстро в модель данных вносить, и чтобы четырехмерность на уровне полей поддерживать, и чтобы готовые инструменты проектирования пользовать... Да и просто поучиться интересно, мечты опять же. А просто смоделировать по типу нарисовать картинки - это мне не пойдет. Я тоже туда хочу еще реальные данные запихнуть и запросами их дергать.

Ну, у нас сейчас ведущая идея о том, чтобы именно такой трипл-стор снабдить приличным языком запросов для содержательного поиска -- а не SPARQL. Не удивлюсь, если это окажется SysMoLan, который мы хотим одновременно сделать и языком описания данных, и языком запросов (паттерны дают такую возможность) -- моделировать-то нужно разные системы, в том числе и предпринятия )) Пока вы рассказываете про "семантику". Наш же Editor позволяет идти немного дальше и работать с онтологиями (различения vvagr постарался описать в http://techinvestlab.ru/ISO15926OntologAndSemantic). Мы ведём сейчас разговоры с одним из разработчиков трипл-стора (вдесятеро более быстрого, чем другие), не добавит ли он к нему наш язык запросов вместо SPARQL. А если этот язык запросов окажется языком моделирования системы, то всё вполне может получиться. Но для этого нужно было года три разбираться с текущим нашим редактором и иметь наработки в традиционном стеке семантического веба, чтобы понимать все возможные грабли этого подхода. Мы нахлебались с излишней реификацией в отношениях, и сейчас пытаемся её угномить. Если получится -- мы в дамках. Будем писать паттерны навроде (далее сугубо рабочая версия, никакого отношения не имеющая к реальной ситуации, но позволяющая понять, о чём идёт речь): pump((part((impeller impeller((whole((pump pump.impeller((diameter((200 pump.impeller((diameter((UOM((millimetre pump.impeller((diameter((value((200 pump((composition((part((impeller p-101((composition2((part((Imp-202 composition2((start_date(("20.07.2014" Сравните с тем же OWL, там сложней всё будет выражаться. А глубоко внизу триплы, куда ж без них. Хотя и тут есть идеи.

Во-первых, у вас какое-то другое понятие слова "онтология". Вы, как я понял, считаете, что онтология - это стандартный подробный классификатор. А вот если вы спросите питерских семантиквебберов, то там ваши онтологии (по крайней мере которые в примерах), онтологиями считать не будут. Онтология - это связи, логика и констрайнты. Это сложная модель, а не просто классификатор. Во-вторых, OWL никто не будет смотреть в тёртлах, N3 и тем более в XML. Их будут смотреть в графических редакторах. А уж как они там писать на диск будут - это дело десятое и неинтересное. Заставить юзера вводить данные текстом, даже с автокомплитом, даже на полуестественном языке - это фантастика. В-третьих, без логики там в принципе на реальных данных не обойтись. Это все равно что программировать без отладки. В теории, конечно, можно, на практике - лажа (потому как ошибок проектирования навалом). И это основная проблема, потому как логика - основная причина тормозов. Там и сейчас приходится только в дизайн-тайме ее запускать, грузить куда-нибудь где выведет (причем, не ризонером даже, а не пойми какой полуспаркловской фичей). Спасает то, что наши реальные данные пока не так часто обновляются. А мотивацию переделать спаркл я, честно говоря, не понял. Зачем? PS. Капчи какие-то кошмарные стали.

Почему вы вычитали про "классификатор"? Типы и отношения - это как минимум. А вот что она должна быть стандартная - это всё более существенный вопрос. Онтология должна быть разделяемой, и даже самая лучшая логическая модель с констрейнтами, разработанная одним очень умным программистом для одного проекта - это не вполне онтология.

Я бы сказал что 15926 это не то что не для мелкого и среднего бизнеса, а скорее для сверхкрупного (интеграция кучи крупных бизнесов, инфраструктура для оного). Т.е. онтологии они конечно везде можно применять, независимо от крупности и независимо от бизнесности, но конкретно 15926 проработан под понятно какую специфику. Я тут имею в виду не столько онтологическую специфику, сколько сам подход к стандартизации, который весьма громоздкий. Наверное, когда будут зрелые тулзы, будет легче, но в целом я бы все равно ожидал тот же pain in the ass как и в случае скажем с EJB всякими. Энтерпрайзность она и есть энтерпрайзность, на каждую концепцию нужно сделать десяток ритуалов (с описаниями в хмл файлах). Уж про логический вывод в контексте энтерпрайзности и поминать страшно.

Много чего написали, постараюсь хотя бы упомянуть направления для ответов. Отношения часть целое (крыльчатка часть насоса) это холархии, а не классификации. Composition, а не Classification (и не Specialisation, кстати тоже). Для того, чтобы мне так уверенно отвечать, нужно иметь как раз (разделяемую многими, общую) онтологию -- знать, что кроме классификаций есть ещё примерно 3500 тысяч основных отношений, встрачающихся в инженерии, из них 500 более-менее основных (это исследовалось для предметной области инженерии в проекте Gellish). Констрейнты можно задавать не только логически, но и функционально. Карри-Ховард, всё такое. Логический язык очень плохо поддерживает работу с последовательностями, там работается сразу со множествами. Это тяжело для инженерии и для менеджмента. Более того, в работу логических алгоритмов тяжело вставлять моменты интерактивности (диалоги с пользователем, ожидания отвалившихся на 200ms удалённых серверов и т.д.). Поэтому мы тут пойдём другим путём. Именно поэтому логические языки в мире в загоне, а функциональные (как шаг к декларативности) хоть как-то, но выживают. Вообще, и логические языки выживают только "фортраноподобные", такие как Prolog, в котором большая часть функциональности -- это управление оптимизацией логического вывода, и поэтому все отмечают его "наполовину императивность". Для работы с онтологиями совершенно необязательно иметь именно OWL и логику. Это подробно обсуждается самими онтологами (тот же John Sowa считает OWL и шаг к обязательной decidability -- это ошибочные шаги для большинства в сообществе прикладных онтологов. Выразительность требуется всем, а вот логическая вычислимость -- немногим). Дискуссия о преимуществах логического и текстового представления для языков сошла в последние годы на нет: требуются оба. С одной стороны, топология задач лучше видна на графах, а с большими объемами нужно работать на текстах -- плюс порождаем-то мы в других программах именно тексты, они нужны, чтобы не только человек мог работать с этими данными. Примером такого для строгих языков служит Modelica, там предписан способ связи визуальных моделей и текстового их содержания. Мы пойдём именно таким путём: основная работа с текстами, но есть и возможность визуальной работы с получающимися моделями. Кстати, в текущей версии .15926 Editor у нас псевдографическое представление (специального вида редактируемые деревья: что-то среднее между полнографическим и текстовым представлениями). Юзер должен вводить данные не на полуестественном языке, а на естественном языке. А потом парсер должен переспрашивать, ежели чего не понял. И делать огромную интеллектуальную работу, восстанавливая контекст. Но это ещё некоторое будущее. Мы хотим прорваться через другое, не через controlled english (то есть не через синтаксис похожести высказываний на языке на обычный текст). Мы хотим прорваться через особенности выражения мысли человека в инженерных "псевдокодах". Чтобы человек мог сказать "поток высотой 18 см" и компьютер его не поправил, что "поток это activity, а у activity нет высоты", а вывел сам "поток это activity, но вы имели ввиду system component/FunctionalPhysicalObject, реализующий эту activity". Вот это одна из основных целей, и паттерны позволяют надеяться, что её можно попытаться достигнуть -- просто закодировав паттерны типичных инженерных высказываний. В работах по инженерии требований есть моделеры требований, которые имеют уже порядка 3000 лингвистических паттернов для выражения требований. Вот и мы пойдём таким путём, только для этих лингвистических паттернов представим форму фиксации модельного знания, гарантированно укладывающуюся в общие данные.

Причин тормозов очень много, поэтому мы сразу планируем работать с оптимизаторами: у них трипл-стор от десяти до сотни раз побыстрей будет трипл-сторов других поставщиков. А отказ от SPARQL в пользу нашего языка позволит и этот показатель поднять: SPARQL сам по себе даёт существенный overhead. Плюс перемещать часть логической работы от работы с сервером данных к работе в самом приложении (приложение знает свои данные, поэтому может предложить вместо "типовых" алгоритмов более быстрые алгоритмы для известного вида данных). Так что с этим мы тоже работаем. Текущие трипл-сторы по производительности уже сравнимы с SQL базами, но начиная с 5 джойнтов уже опережают их. Так что мы с вами одинаково понимаем проблемы, но по-разному оцениваем их. Плюс мы как-то намечаем пути решения этих проблем, для чего и ведём наши исследования. Намеренно не давал тут ссылок, ибо материала по всем этим пунктам немеренно, утонем. Про капчи: по неизвестному мне алгоритму капчи некоторым людям тут показываются, а некоторым нет (и это не зависит ни от настроек, ни от френдования). У СУПа там с этими капчами стоит какой-то загадочный интеллект. Но полгода назад спам в комментах почти прекратился. Разве что пару раз в неделю спам в комментах приходит, а не по двадцать-тридцать раз за день ;-) Как я понял, чем больше популярность вашего собственного блога, тем реже вы видите чужие капчи.

Логический вывод поминать страшно, но верификации на данных ISO 15926 мы начали делать. Остальные как-то с этим не справляются. Очередной шаг в нашей разработке связан как раз с тем, что мы всю эту монструозность хорошо осознали, и теперь начнём её искоренять планомерно. Как я понимаю, зло в реификациях. Они должны быть! OWL зло, ибо их не позволяет! Но они не должны быть всегда, они должны даваться пользователю только тогда, когда это действительно нужно, а не по умолчанию. Нужны мощные средства подъема уровня языка, и при поднятии уровня языка нужно уметь подключать справочные данные (как это делают люди: говорят они коротко, а непонятки решают привлечением контекста -- вычислений становится больше, но зато коммуникация короче). Мы будем экономить коммуникацию, а не вычисления. Вычисления подтянутся, никуда не денутся.

Ну подход у вас интересный конечно, возможно удастся что-то типа инфа сделать (iii.ru). Я сам в эту тему смотрю, но пока только смотрю - там много очень важных вещей не готово с моей точки зрения (а без них не взлетит), и делать я это если когда и буду, то скорее всего на других рельсах. Делать логику функциональным подходом - это для меня, честно говоря, новая тема. Ни разу не встречал. Но делать ее надо по-любому. Хоть тушкой, хоть чучелкой, а выводить надо. Для примера. У нас хотя и небольшая задачка (примерно 21 тысяча триплетов), но из них 12,5 тысяч выводится автоматом. Да, не обычным ризонером (там в композере какая-то своя приблуда на основе спаркла или SPIN, я так и не понял). Может, она конечно выводит далеко не все, согласен. Сложную многоступенчатую логику с отрицаниями и проверкой условий тяжко вывести (а мы ее и не делали, вернее делали, но уже спарклом при запросах). Но хотя бы на каком-то уровне, хотя бы RDFS, оно должно присутствовать. Иначе забивать кучу данных ручками - это какой-то мазохизм будет. А чтобы выводить хотя бы так, нужны констрайнты и непротиворечивость. Вот это имхо должно делаться в дизайн-тайме без ввода индивидов на полупустых классах (отладка). Иначе не выйдет - разработать модель данных (эту правильную онтологию в моем понимании) нереально будет.

Да я и не питаю особой надежды на 15926. Какой-то он перегруженный, не про то и непонятный. А без логического вывода я как-то не хочу пользовать онтологии. Иначе весь смысл теряется.

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

Джон Сова, конечно, умный дядька, и он верно говорит про текущее состояние ризонеров с открытым миром - тормозно. Соглаен, на реальных данных тормозно. Но другого варианта-то нету! Куда деваться-то?

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

Эта вики неправа в определении. Это определение было дано Tom Gruber примерно в таком виде, но потом его уточнили -- добавили, что концептуализация должна быть разделяемой (shared). А теперь ещё один процесс идёт: пометка "в информатике" начинает сниматься, и информатики говорят о более-менее общем с философскими логиками понимании проблемы. Плюс именно логическая парадигма представления онтологии сейчас наиболее распространена (особенно логикой всего-навсего первого порядка), но не единственна (так, есть работы и по представлению онтологии в терминах теории категорий, чтобы уж совсем в другую предметную область пальцем ткнуть -- там даже Карри-Ховард не поможет сказать, что "это та же логика, только в профиль"). Кстати, John Sowa "онтологии" на OWL не считает онтологиями, ибо упор там сделан на синтаксис (как говорить), а не на структуру мира ("о чем говорить"). И постоянно подчёркивает, что семантиквебовцы и лингвисты это одна и та же банда, а вот онтологи -- другая. Так что с его точки зрения вы наблюдали спор двух школ лингвистов, онтологов там не было. Мэтью Вест любит сказать, что ISO 15926 это онтология, а вот DOLCHE это не онтология -- ибо понятия в ней представляют не вещи, а "как говорить о вещах". Конечно, в реальной работе нужно учитывать оба аспекта проблемы: и о чём говорим, и как говорим.

Где именно "там"? Что касается википедии, то лучше смотреть первоисточники. http://semanticweb.org/wiki/Ontology An ontology is a formal specification of a shared conceptualization Tom Gruber Shared - это ключевое слово, а про объективное и субъективное - пусть спорят.

Под термином "онтология" понимают: 1) Некие античные философские направления. 2) Практики data modeling, созданные под влиянием (1) в двадцатом веке и далее. 3) Практики database modeling, применяемые семантиквебовцами. Обычно ограничиваются "хранить в триплсторе и рисовать схему в OWL вместо SQL". Анатолий рассуждает о data modeling (2), у вас же семантиквебовское (3).