Объединяем программирование, моделирование, представление знаний
24 августа в 13:11 был создан чат "Типы в языках программирования, моделирования, представления знаний" -- https://t.me/typeslife, и за прошедших четыре дня в него набежало уже 176 любителей поговорить о типах. Ох, и много было наговорено! Текста я туда написал тоже оченьмногабукофф, даже не буду сюда эти тексты копировать. Но сформулирую некоторые выводы.
1. В основе всего должен лежать какой-то "обычный GPL". Под этим "обычным GPL" имеется ввиду современный язык, на котором можно делать eDSL. Например, C# и Julia. Языки, на которых легко программировать, хорошая инфраструктура, приемлемая надёжность кода, надёжность обеспечивается понятностью. Языки, у которых дизайн-цель безопасность (доказательства правильности программ) -- они не подходят, а если для "обычного GPL" потребуется при передаче в production обеспечить безопасность, то ничего не нужно переписывать: просто будут воткнуты дополнительные аннотации и типизация таки будет проверена (средствами языка, или внешним чекером, это неважно), а то и в рантайме поставим дополнительные тесты.
2. Языки представления знаний -- это какая-то формальная машинка для работы с микротеориями. Обычно там какой-то логический движок, FOL плюс какие-то HOL расширения. SQL, SPARQL (забыть: триплы это тупик. Начинать нужно сразу с n-арных предикатов), Datalog и прочая -- вот это оно всё. Но смотреть нужно на CycL как на успешный движок. Другое дело, что языки представления знаний крайне не приспособлены для моделирования. Поэтому хорошо бы реализовать язык представления знаний как eDSL над GPL. И помнить, что язык для знаний -- это полноценный движок/солвер FOL прежде всего. Онтологика это онтология+логика.
И тут ещё важен коммуникационный аспект: идёт обмен моделями разных микротеорий, поэтому не будет хватать "просто базы данных", нужны расширения для документарных форматов (думаем о чём-то типа бинарного варианта JSON-DL). Собственно, по этому пункту максимальное количество непоняток, разночтений, споров -- по сути дела именно тут мой начальный запрос: как встречаются foundational ontology и upper ontology, нужно ли вообще иметь upper ontology, если всё микротеории, и т.д..
Этот язык justy_tylor реализует как компилятор на C# (ему важна совместимость с корпоративной инфраструктурой и сахарность синтаксиса), а для меня важны были бы стыки с deep learning, probabilistic programming и NLU + всякое инженерное моделирование. Это сегодня главным образом Python и проблема двух языков, но конкурентом там потихоньку становится Julia. Поэтому можно думать о том, чтобы сделать eDSL как набор различных разогнанных на GPU FOL/HOL солверов по примеру DifferentialEquations, JuMP и Modia.
3. В языках важна их сахарность (этот тезис подробно развивал justy_tylor). По формальным моделям есть множество "эквивалентностей", но вот людям или удобней, или неудобней какие-то конкретные синтаксисы, а уж что там потом делает компилятор, преобразуя из удобного для хорошей нотации формализма в удобный формализм для быстрых вычислений -- это дело компилятора. Если нужно преобразовавать в триплы, то пусть солвер FOL это преобразует и оптимизирует где-то там внутри себя, а на поверхности должны быть паттерны, n-арные предикаты (я помню весь ужас перехода от триплов к представлению паттернами -- заборы и коровники на много частей стандарта). Язык с плохим синтаксисом и хорошей семантикой проигрывает языку с хорошим синтаксисом и плохой семантикой. Поэтому возможность "нотационных расширений" важна. Среди таких расширений можно назвать Prolog DCG как пример компактности "из ниоткуда" для парсинга (DCG -- https://www.metalevel.at/prolog/dcg или DCTG - http://cmsmcq.com/2004/lgintro.html, и можно поглядеть ещё работы по проекту FONC O-Meta с теми же целями "минимальный язык для парсинга", но там не FOL а хитро понимаемая объект-ориентированность -- http://tinlizzie.org/ometa/), какой-то синтаксис для possible worlds (и тоже в VPRI были работы на эту тему -- http://www.vpri.org/pdf/m2013002_experiments.pdf). Так что языко-ориентированность в том числе и нотационная -- она важна.
4. Ну, и eDSL для моделирования/simulations, всяческих микротеорий -- синтаксис, типы, солвер для модели. Это понятно, это не обсуждается. Пример тут Modia для инженерного моделирования. С этим всё понятно, тут нет особых вопросов.
Итого: нужно смотреть на то, что происходит с языками представления знаний: всякими knowledge graphs до того момента, когда их вливают в нейросетки -- какие там языки представления графа, что там с выводом, как ускоряют вывод. Отдельно алгоритмы, отдельно разгон на GPU -- хотя это связанные вопросы обычно). Последние интервью Дугласа Лената говорят о том, что там продолжается линия на "мы разгоним FOL с HOL над knowledge graphs с микротеориями и прочими хитростями до приемлемых времён, и таки победим всех, ибо common sense и причины таки у нас".
Но иметь какой-то eDSL проект по представлению знаний (солверы FOL-HOL, посаженные на GPU) в Julia, напоминающий JuMP и DifferentialEquations -- это было бы интересно.
Самый большой риск: логические языки все эзотеричны, они ещё более эзотеричны, чем функциональные языки (про Curry-Howard помним, да), и языки представления знаний в классической чисто логической традиции выражения FOL поэтому рискуют быть такими же эзотеричными, как Пролог или CycL сотоварищи. Другое дело, что SQL это и FOL и тьюринг-полный язык, так что необязательно речь идёт о чём-то страшном-страшном. Так что там могут быть "форматы представления FOL" и собственно FOL-солверы. Но это детали.
Всё одно дело мутное. Эти самые вопросы с foundation ontolgy и upper ontology и выражением микротеорий (что нарушает всю "консистентность вывода" в рамках программы -- и нужны средства работы с микротеориями, которых нет в существующих системах типов языков программирования, плюс коммуникационные вопросы по обмену/федерированию знаний в этих микротеориях), похоже, нужно искать таки в языках знаний, а не языках программирования или языках программирования баз данных. И прикручивать болтами к экосистеме deep learning, NLU и прочим пришельцам из вычислительной математики. Так что пока меня не убедили, что в Julia это всё делать бессмысленно. Наоборот.
UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216135078543760
1. В основе всего должен лежать какой-то "обычный GPL". Под этим "обычным GPL" имеется ввиду современный язык, на котором можно делать eDSL. Например, C# и Julia. Языки, на которых легко программировать, хорошая инфраструктура, приемлемая надёжность кода, надёжность обеспечивается понятностью. Языки, у которых дизайн-цель безопасность (доказательства правильности программ) -- они не подходят, а если для "обычного GPL" потребуется при передаче в production обеспечить безопасность, то ничего не нужно переписывать: просто будут воткнуты дополнительные аннотации и типизация таки будет проверена (средствами языка, или внешним чекером, это неважно), а то и в рантайме поставим дополнительные тесты.
2. Языки представления знаний -- это какая-то формальная машинка для работы с микротеориями. Обычно там какой-то логический движок, FOL плюс какие-то HOL расширения. SQL, SPARQL (забыть: триплы это тупик. Начинать нужно сразу с n-арных предикатов), Datalog и прочая -- вот это оно всё. Но смотреть нужно на CycL как на успешный движок. Другое дело, что языки представления знаний крайне не приспособлены для моделирования. Поэтому хорошо бы реализовать язык представления знаний как eDSL над GPL. И помнить, что язык для знаний -- это полноценный движок/солвер FOL прежде всего. Онтологика это онтология+логика.
И тут ещё важен коммуникационный аспект: идёт обмен моделями разных микротеорий, поэтому не будет хватать "просто базы данных", нужны расширения для документарных форматов (думаем о чём-то типа бинарного варианта JSON-DL). Собственно, по этому пункту максимальное количество непоняток, разночтений, споров -- по сути дела именно тут мой начальный запрос: как встречаются foundational ontology и upper ontology, нужно ли вообще иметь upper ontology, если всё микротеории, и т.д..
Этот язык justy_tylor реализует как компилятор на C# (ему важна совместимость с корпоративной инфраструктурой и сахарность синтаксиса), а для меня важны были бы стыки с deep learning, probabilistic programming и NLU + всякое инженерное моделирование. Это сегодня главным образом Python и проблема двух языков, но конкурентом там потихоньку становится Julia. Поэтому можно думать о том, чтобы сделать eDSL как набор различных разогнанных на GPU FOL/HOL солверов по примеру DifferentialEquations, JuMP и Modia.
3. В языках важна их сахарность (этот тезис подробно развивал justy_tylor). По формальным моделям есть множество "эквивалентностей", но вот людям или удобней, или неудобней какие-то конкретные синтаксисы, а уж что там потом делает компилятор, преобразуя из удобного для хорошей нотации формализма в удобный формализм для быстрых вычислений -- это дело компилятора. Если нужно преобразовавать в триплы, то пусть солвер FOL это преобразует и оптимизирует где-то там внутри себя, а на поверхности должны быть паттерны, n-арные предикаты (я помню весь ужас перехода от триплов к представлению паттернами -- заборы и коровники на много частей стандарта). Язык с плохим синтаксисом и хорошей семантикой проигрывает языку с хорошим синтаксисом и плохой семантикой. Поэтому возможность "нотационных расширений" важна. Среди таких расширений можно назвать Prolog DCG как пример компактности "из ниоткуда" для парсинга (DCG -- https://www.metalevel.at/prolog/dcg или DCTG - http://cmsmcq.com/2004/lgintro.html, и можно поглядеть ещё работы по проекту FONC O-Meta с теми же целями "минимальный язык для парсинга", но там не FOL а хитро понимаемая объект-ориентированность -- http://tinlizzie.org/ometa/), какой-то синтаксис для possible worlds (и тоже в VPRI были работы на эту тему -- http://www.vpri.org/pdf/m2013002_experiments.pdf). Так что языко-ориентированность в том числе и нотационная -- она важна.
4. Ну, и eDSL для моделирования/simulations, всяческих микротеорий -- синтаксис, типы, солвер для модели. Это понятно, это не обсуждается. Пример тут Modia для инженерного моделирования. С этим всё понятно, тут нет особых вопросов.
Итого: нужно смотреть на то, что происходит с языками представления знаний: всякими knowledge graphs до того момента, когда их вливают в нейросетки -- какие там языки представления графа, что там с выводом, как ускоряют вывод. Отдельно алгоритмы, отдельно разгон на GPU -- хотя это связанные вопросы обычно). Последние интервью Дугласа Лената говорят о том, что там продолжается линия на "мы разгоним FOL с HOL над knowledge graphs с микротеориями и прочими хитростями до приемлемых времён, и таки победим всех, ибо common sense и причины таки у нас".
Но иметь какой-то eDSL проект по представлению знаний (солверы FOL-HOL, посаженные на GPU) в Julia, напоминающий JuMP и DifferentialEquations -- это было бы интересно.
Самый большой риск: логические языки все эзотеричны, они ещё более эзотеричны, чем функциональные языки (про Curry-Howard помним, да), и языки представления знаний в классической чисто логической традиции выражения FOL поэтому рискуют быть такими же эзотеричными, как Пролог или CycL сотоварищи. Другое дело, что SQL это и FOL и тьюринг-полный язык, так что необязательно речь идёт о чём-то страшном-страшном. Так что там могут быть "форматы представления FOL" и собственно FOL-солверы. Но это детали.
Всё одно дело мутное. Эти самые вопросы с foundation ontolgy и upper ontology и выражением микротеорий (что нарушает всю "консистентность вывода" в рамках программы -- и нужны средства работы с микротеориями, которых нет в существующих системах типов языков программирования, плюс коммуникационные вопросы по обмену/федерированию знаний в этих микротеориях), похоже, нужно искать таки в языках знаний, а не языках программирования или языках программирования баз данных. И прикручивать болтами к экосистеме deep learning, NLU и прочим пришельцам из вычислительной математики. Так что пока меня не убедили, что в Julia это всё делать бессмысленно. Наоборот.
UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216135078543760