Обсуждение

Здесь хорошие переводы на русский лекций и книг по теории категорий (для программистов тоже) и гомотопическую теорию типов.

/// В языках программирования ровно оно: foundational ontology без каких-то внятных онтологических посылок. Типы, и всё. Холст, на котором рисовать, никаких предположений, что там будет рисоваться, какой мир. /// NB:: ИМХО смотреть надо не на языки-сами-по-себе, а на языки плюс бибилиотеки/фреймворки/экосистемы.

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

Да они и ворд не знают. Отступы пробелами делают. При попытке разъяснить орфан-контроль (что и зачем) впадают в сопор, как курица от нарисованной мелом линии. Людей, собравших свои библиотеки стилей, я за 25 лет встретил душ пять или шесть (я такую себе делал для документооборота по фирме - кадры, общее руководство еtс). Если бы вместо WYSIWYG всем секретиссам выдали LaTex, мир был бы другим. Хотя старый WordPerfect с синхронной прокруткой двух окон был очень удобен для проф.переводчиков.

+100500 Справедливости ради, Microsoft Word тоже с незапамятных времён и до сих пор имеет эту функцию (Synchronous Scrolling), причём со всякими плюшками: https://support.office.com/en-us/article/view-and-compare-documents-side-by-side-52445547-7c07-475b-bb1d-22a98175ef04. А ГуглоДок со своей невозможностью создавать стили дополнительно сильно подкосил "менеджерш из эскорта"...

Типы в теории типов и программировании определяются наборами операций, которые к ним применимы. В онтологиях классы определяются свойствами объектов. Немного разный подход.

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

/// Справедливости ради, Microsoft Word тоже с незапамятных времён и до сих пор имеет эту функцию (Synchronous Scrolling), причём со всякими плюшками: /// Когда я сравнивал поведение, MSWord сразу уходил в корзину. Фишка в том, что тот старый WP синхрил прокрутку не по строкам/символам/страницам ("графически"), а по предложениям/абзацам/разделам (ещё и видимо цеплялся за одинаковые слова) — именно то что нужно для переводов длинных текстов, когда версии на разных языках могут [по ходу работы] иметь в разы различающиеся объёмы фрагментов: из-за языковых эффектов языка и самого процесса перевода (подстрочник->набросок->черновик->перфект). MSW так почему-то не делал, по кр. мере в версиях вплоть до 2000, хотя иногда вроде как типа пытался (апофения, да;). Впрочем, если он делал это так же, как Visio "оптимизирует" линки при перемещении графем в более или менее навороченной диаграмме, то лучше ничего не делать. Я вот давно ношусь с задумкой сделать сложный server-side web-инструмент, в котором будет компонент типа Visio, так за autoplacement графич объектов мне даже думать страшно. Хотя тот же MindManager справляется на твёрдую четвёрку с плюсом. Или даже пятёрку с минусом.

/// Ну, и онтологии нужны не сами по себе, а чтобы вычислять над ними. Те же самые операции. /// Кстати, а кто-нибудь в вашей тусовке составлял список этих самых операций? Ну типа "вот есть гиперграф, и вот нужны операции: 1) поиск максимально похожего подграфа; … для чего нужна операция … 2) вычисление разницы (дифференциала) между подграфами; … а ещё нужна хитрая операция … 3) "как развернуть/переподключить под-подграф в подграфе, чтобы он стал максимально похожим/конгруэнтным другому подграфу". Я не просто так интересуюсь ;) Правда, перечисленные хотелки больше относятся не к "чистым" древовидным онтологиям "Исаак родил Иакова", а к описаниям опредмеченных POV-based сцен ("Things+Affordances"), но это неважно.

Вот такое сложное на сервере уже сделали, хотя и десктопный вариант тоже есть, равно как и SDK для всех желающих: https://www.yworks.com/ Офис хорош не просто каждым своим инструментом (конечно, отдельные фичи были хороши и у других инструментом), но прежде всего совместимостью: он офис, а не набор отдельных инструментов. Вот это и есть killer feature -- то, что это офис, а не набор рисовалок, редакторов и прочих электронных таблиц.

Вы поглядите хотя бы документацию нашего редактора онтологий https://github.com/TechInvestLab/dot15926/ -- конечно, в части операций хотелось бы сделать не хуже. Там были ответы на то, как могли бы выглядеть предложенные вами операции для работы с графами в стиле WYSIWYG revisions, как с правками в ворде. И, конечно, питон-консоль для всего того, что ещё не имеет своих кнопок )))

/// прежде всего совместимостью: он офис, а не набор отдельных инструментов /// … хотя это просто реализация OLE /// *** killer feature *** /// Про killer соглашусь — у меня после вёрсток всяких диссеров (на заказ — негром подрабатывал) в MSO97 по сей день привычка хранить ленту версий/редакций через каждые несколько минут, и после каждой рискованной операции типа подгонки диаграммы или перемещения сносок по тексту. Что в 97 ворде было НЕглючное — никто не знает. Глючили все без исключений функции. Начиная с 2002 вроде более или менее без кошмаров, но мелкие глюки лезут постоянно. Оно несложно — нажал Ctrl+S и скопировал файлик с суффиксом YYYY.MM.DD.hhmm Иногда бывает полезно и сейчас. Когда обстраиваю нормальную боевую инфраструктуру, то весь workspace храню на сервере с zfs или btrfs с cron-snapshots каждые 2--5 минут.

/// *** yWorks *** /// Это рисовалка, у меня другая задача. Грубо говоря, диаграмма не как "просто рисунок", а как динамический фронтенд/интерфейс к мат.модели. В Визио есть UML программный VBA-модуль, это где-то на пол-пути к моей задаче.

А на чём таки триплеты обломались? Вроде с ними всё Ок, тока туго заходят и в инструменты, и в мозги. Примерно так же туго, как и 4Д экстенты...

/// Вы поглядите хотя бы документацию нашего редактора онтологий /// Немного не о том. Вы говорите об инструменте для гомосапиенса (я понимаю, что движок можно прибиндить к любой проге). Я говорю о backend'е даже не класса СУБД, только графовой, … а о специфическом вычислительном ядре — одной из опорных технологий AGI. Главная фича — умение работать с "гештальтами", огромными фрагментами гиперграфов; … и как с единым "жёстким" целым, … и как с эластичной/нечёткой структурой, … и как с гипотетическим комплексом — предметом манипуляций с его внутренностями. /* NB:: Гомосапиенсы обычно визуализируют в психологическое-2D, с трудом в 2.5D, а этого мало. AGI должна быть пофигу «топологическая» сложность гиперграфа, как-то так */

/// А на чём таки триплеты обломались? /// А разве обломались? Триплеты — это "буквы". А нас интересуют не буквы и не слова, и даже не высказывания, а не побоюсь этого слова, дискурсы.

Авторы того документа с arxiv сравнивают именно философские подходы, например, упоминая отсутствие temporal parts в философском 3D, но игнорируя то, что в 3D моделировании баз данных temporal parts применяются (но только там, где они есть в предметке, а не как в 4D "для всего"). В принципе, за прошедшие с нашей .15926-движухи годы я ни разу не видел успешного применения подхода 4D (выделение темпоральных частей и их реификация, как в ISO 15926) или подхода 3D+1 (реификация отдельных фактов, как в Gellish) на практике. Кому нужны лишние джойны и медленные запросы к базе данных? Никому. Поэтому используется 3D с прошивкой времени прямо в факты под конкретные задачи, благо с появлением фич из temporal databases в SQL:2011 это стало ещё немного удобнее. И в рамках отдельных микротеорий это самый правильный подход. Что же касается интеграции данных, используемых разными микротеориями/системами, то здесь лучше ставить время как модальность над множествами (и множествами множеств) фактов ((at_time "2019-08-19 ...": факт1, факт2, ...), (at_time "2019-08-19 ...": (possibly: факт3), факт4, ...)) и хранить/передавать такие датасеты цельными документами. Это компактно и не требует изменений схемы самих фактов в случаях "выяснилось, что данное свойство меняется со временем" или "теперь необходимо хранить информацию с нескольких viewpoints".

/// Поэтому используется 3D с прошивкой времени прямо в факты под конкретные задачи /// Оно хорошо когда нужно время-как-абсолютная-координата (а-ля UTC), а для времени-как-фазы (вложенные/повторяющиеся процессы) это адЪ.

А в чём проблема? Хоть фаза, хоть viewpoint - в 3D это плюс одно поле к существующей таблице. А в подходах 4D или 3D+1 - плюс ещё одна таблица.

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