Чем больше в логике возможных значений, тем сложнее с ней работать, алгоритмы логического вывода тоже становятся сложнее. Думаю, что «абсурдная» логика была бы удобна, если в явном виде нужно работать с утверждениями, противоречащими друг другу. На практике в области разработки ПО в большистве случаев достаточно двоичной логики.
Что касается семантики стойких моделей, то утверждения p ← not q и q ← not p рассматриваются не как абсурдные, а как дополняющие друг друга. Оператор отрицания в Stable model semantics понимается так же утверждения по умолчанию в Default logic. То есть
not q понимается не как безусловное отрицание, а как некое дополнительное подтверждение остальных правил, которое имеет смысл, только если оно согласуется с ними.
Например, в
male(X) ← person(X) AND NOT female(X)
female(X) ← person(X) AND NOT male(X)
NOT female(X) и NOT male(X) это дополнительные утверждения, которые можно отбросить, если они противоречат остальным правилам. Т.е., если мы знаем, что male(alex) истинно, то not female(alex) можно проигнорировать. И эти правила трансформируются в утверждения, что все люди по умолчанию мужчины, кроме тех, про кого точно известно, что они женщины (так же и наоборот).
Да, если логику высшего порядка использовать необдуманно, то можно легко выстрелить себе в ногу. Как с точки зрения запутанности кода, так и производительности.
Я предполагаю, что логика высшего порядка будет полезна в тех случах когда нужно определить общие отношения между понятиями, не привязываясь к их имени. Например, родитель-потомок, больше-меньше, геометрические отношения, отношения во времени и т.п. В большинстве случаев такие отношения будут использоваться не сами по себе, а совместно с другими понятиями. Например, отношение ParentRel можно использовать для поиска каких-нибудь вложенных элементов: concept NestedElements (parent = e1, child = e2) from Element e1, ParentRel r(parent = e1, child = e2), Element e2 where ...
Сначала будет найдет элемент e1, это позволит связать название понятия в отношении ParentRel с «Element», а затем найти все вложенные элементы и отфильтровать нужные из них. Также это отношение можно применить и к другим понятиям, например, к иерархиям подразделений в компании. На мой взгляд, к дополнительной сложности, запутанности и излишнему росту связей подобные конструкции приводить не должны.
Это можно считать аналогом generic классов в ООП модели. В которой, например, контейнеры списков можно применить к любому одержимому не привязываясь к конкретным его классам.
Если же в таком отношении имя родительского понятия на момент вызова будет неопределно, то это будет аналогом запроса к схеме данных. Будут найдены все понятия, удовлетворяющие заданным условиям.
Я бы копал в сторону среды исполнения, которая должна сама находить противоречия в модели.
Да, пока этой задачей я не занимался. Но это интересная тема. Надеюсь, я когда-нибудь смогу до нее добраться.
Соглашусь с вами, что искать в Библии толкование современной физики будет не продуктивно. Это не ее тема. Библия это книга в первую очередь о взаимоотношениях Бога и людей, о морали, добре и зле, ценностях, смысле жизни.
Но не соглашусь, что Библия весьма примитивная книга. Это очень сложная и целостная книга с глубоким смыслом. Ее составные части писались в разное время разными людьми, но при этом они имеют общий сюжет, очень тесно связаны между собой, базируются на нескольких основных идеях, и в каждой книге эти общие идеи раскрываются по своему.
closed/open world assumption — это предположение о полноте или неполноте данных, из которого делается вывод о семантике оператора отрицания. Если данные полны, то булево отрицание можно расширить до «отрицания как отказ», т.е. высказывание считается ложным не только, если ложность можно вывести в явном виде, но и если о нем ничего не известно.
LinkedData вцелом (как коллекция взаимосвязанных наборов данных в WEB) изначально задумывалась как неполная. Те же статьи в википедии постоянно дополняются и расширяются. Поэтому к этим данным нельзя применять операцию «отрицание как отказ». Т.е. можно посчитать атрибуты, проверить, есть ли они или нет. Но нельзя из отсутствия атрибута сделать вывод о его ложности.
Но в то же время какие-то отдельные частные наборы данных могут быть и полными. Они так-же могут быть описаны с помощью RDF или OWL. Мы можем решить, что этот набор данных полон, все что в нем не описано — не существует, и к нему можно применять другую логику вывода, включающую отрицание как отказ. Могут быть и гибридные наборы данных, часть их полна, часть — нет.
И здесь очень просто добавлять новые данные: все, что не указано в виде предиката над объектами — это false, в литературе это известно, как Closed-world assumption.
LinkedData и Semantic WEB строятся на предположении об открытости мира. Данные в WEB не полны. Если данных в системе нет, то они могут быть в другом месте, или вообще еще не оцифрованы. Если в WikiData не указан рост и вес Дугласа, то из этого нельзя сделать вывод, что он не обладает этими характеристиками.
А вот большинство реляционных баз данных как раз придерживаются предположения о закрытости мира. Если в базе данных авиакомпании нет записи о авиарейсе, то обычно делается вывод, что такой авиарейс компания не обслуживает.
Спасибо! Посмотрю. Графический интерфейс был бы полезен во многих сферах применения семантических сетей. Я тоже планировал создать в будущем графический интерфейс для своего проекта, но пока еще не добрался до этого.
Очень интересный проект! Когда я начинал свой проект, мои цели были похожими. Меня интересовало создание агента, который смог бы выполнить инструкции, записанные на естественном языке. Я начал с вопроса, как объединить декларативные определения с императивными командами. Но постепенно в процессе экспериментов сместился в область мульти-парадигменного программирования.
Обосновывающая информация обычно хранится в confluence, jira, wiki. Проблема в том, что программисты обычно ленятся что-то писать без крайней необходимости. Их сложно будет убедить продублировать документацию в коде. Но вот связать код с документацией и таск трекерами могло бы иметь смысл. Иногда найти нужную страницу в wiki — довольно нетривиальная задача.
Проективная информация имеет довольно короткое время жизни — пока идет работа над задачей. Думаю, что в большинства случаев будет достаточно простых комментариев. Хотя, возможно, какие-то специальные комментарии-пометки IDE могла бы распознавать и обрабатывать.
В идеале хотелось бы так. Но на практике создать язык, который был бы одновременно универсальным, абстрактным, гибким, удобным и быстрым, пока никому не удалось. В каждой нише свой язык описания знаний.
Ваш пример похож на OWL, который применяется для создания больших онтологий. В нем есть и свойства, и инверсия свойств, и классы, и пересечения и объединения класов.
Ну а я нацелен на интеграцию данных, работу со слабоструктурированными данными, моделирование в ООП стиле, где будет удобным явное описание структур.
Также можно вставлять ссылки на документацию, wiki, задачи в тасктрекере, результаты код ревью, комментарии разработчиков…
Можно в стиле аннотаций это сделать.
Но реализовать это лучше на уровне IDE. Во-первых, не будет привязки к конкретному языку, а во-вторых, все эти дополнительные конструкции потребуют удобных GUI элементов.
Да, мне эта тема тоже интересна.
Проблема в том, что языки программирования формальны, они недопускают неоднозначности. Грубо говоря, есть только один жестко заданный путь исполнения программы.
А естественные языки неоднозначны. Ингда одно и то же предложение можно понять разными способами. И опыт и здравый смысл позволяет оценить правильность того или иного варианта.
Было бы интересно найти способ сблизить формальные и неформальные языки. Это открыло бы очень много новых возможностей по автоматизации программирования и тестирования, различным компьютерным помощникам и т.п.
Да, безусловно. Каждая составляющая может быть выучена за несколько раз. Я с этим не спорю. Но каждая составляющая в свою очередь разбивается на свои составляющие и так далее. Такое «дерево» составляющих будет высоким и ветвистым. Если просуммировать все повторения, требуемые для его построения, то получится большое число.
А, например, чтобы запомнить, что как выглядит мама друга из детского садика? Для этого нужно сначала понаблюдать за своей мамой, понять, что этот человек именно мама, понять как ведет себя мама в отличии от остальных членов семьи. Потом понаблюдать, как ведет себя другая женщина с товарищем по детскому садику и сделать вывод, что она его мама.
Это я и назвал огромным опытом. Это не только повторение наблюдений, но и их систематизация.
Чтобы запомнить последовательность звуков особо изощренный интеллект не нужен. Гораздо сложнее понять смысл слов в зависимости от контекста. Тут без повторного использования уже знакомых слов никак не обойтись.
Ребенок способен обучаться на нескольких примерах, потому что его обучение базируется на огромном объеме уже накопленных знаний, которые он способен повторно использовать. Чтобы научиться разпознавать львов, достаточно выделить те особенности, которые отличают их от остальных животных. Грубо говоря, лев — это большой кот с гривой. А искусственным нейросетям приходится каждый раз учиться с нуля. Текущие архитектуры не способны научившись распознавать один объект использовать эти знания для распознавания следующих.
Так что, возможно, способность накапливать и повторно использовать знания это есть священный грааль искусственного интеллекта, который еще предстоит найти.
not q понимается не как безусловное отрицание, а как некое дополнительное подтверждение остальных правил, которое имеет смысл, только если оно согласуется с ними.
Например, в
male(X) ← person(X) AND NOT female(X)
female(X) ← person(X) AND NOT male(X)
NOT female(X) и NOT male(X) это дополнительные утверждения, которые можно отбросить, если они противоречат остальным правилам. Т.е., если мы знаем, что male(alex) истинно, то not female(alex) можно проигнорировать. И эти правила трансформируются в утверждения, что все люди по умолчанию мужчины, кроме тех, про кого точно известно, что они женщины (так же и наоборот).
Я предполагаю, что логика высшего порядка будет полезна в тех случах когда нужно определить общие отношения между понятиями, не привязываясь к их имени. Например, родитель-потомок, больше-меньше, геометрические отношения, отношения во времени и т.п. В большинстве случаев такие отношения будут использоваться не сами по себе, а совместно с другими понятиями. Например, отношение ParentRel можно использовать для поиска каких-нибудь вложенных элементов:
concept NestedElements (parent = e1, child = e2) from Element e1, ParentRel r(parent = e1, child = e2), Element e2 where ...Сначала будет найдет элемент e1, это позволит связать название понятия в отношении ParentRel с «Element», а затем найти все вложенные элементы и отфильтровать нужные из них. Также это отношение можно применить и к другим понятиям, например, к иерархиям подразделений в компании. На мой взгляд, к дополнительной сложности, запутанности и излишнему росту связей подобные конструкции приводить не должны.
Это можно считать аналогом generic классов в ООП модели. В которой, например, контейнеры списков можно применить к любому одержимому не привязываясь к конкретным его классам.
Если же в таком отношении имя родительского понятия на момент вызова будет неопределно, то это будет аналогом запроса к схеме данных. Будут найдены все понятия, удовлетворяющие заданным условиям.
Да, пока этой задачей я не занимался. Но это интересная тема. Надеюсь, я когда-нибудь смогу до нее добраться.
Но не соглашусь, что Библия весьма примитивная книга. Это очень сложная и целостная книга с глубоким смыслом. Ее составные части писались в разное время разными людьми, но при этом они имеют общий сюжет, очень тесно связаны между собой, базируются на нескольких основных идеях, и в каждой книге эти общие идеи раскрываются по своему.
LinkedData вцелом (как коллекция взаимосвязанных наборов данных в WEB) изначально задумывалась как неполная. Те же статьи в википедии постоянно дополняются и расширяются. Поэтому к этим данным нельзя применять операцию «отрицание как отказ». Т.е. можно посчитать атрибуты, проверить, есть ли они или нет. Но нельзя из отсутствия атрибута сделать вывод о его ложности.
Но в то же время какие-то отдельные частные наборы данных могут быть и полными. Они так-же могут быть описаны с помощью RDF или OWL. Мы можем решить, что этот набор данных полон, все что в нем не описано — не существует, и к нему можно применять другую логику вывода, включающую отрицание как отказ. Могут быть и гибридные наборы данных, часть их полна, часть — нет.
LinkedData и Semantic WEB строятся на предположении об открытости мира. Данные в WEB не полны. Если данных в системе нет, то они могут быть в другом месте, или вообще еще не оцифрованы. Если в WikiData не указан рост и вес Дугласа, то из этого нельзя сделать вывод, что он не обладает этими характеристиками.
А вот большинство реляционных баз данных как раз придерживаются предположения о закрытости мира. Если в базе данных авиакомпании нет записи о авиарейсе, то обычно делается вывод, что такой авиарейс компания не обслуживает.
Проективная информация имеет довольно короткое время жизни — пока идет работа над задачей. Думаю, что в большинства случаев будет достаточно простых комментариев. Хотя, возможно, какие-то специальные комментарии-пометки IDE могла бы распознавать и обрабатывать.
Ваш пример похож на OWL, который применяется для создания больших онтологий. В нем есть и свойства, и инверсия свойств, и классы, и пересечения и объединения класов.
Ну а я нацелен на интеграцию данных, работу со слабоструктурированными данными, моделирование в ООП стиле, где будет удобным явное описание структур.
Можно в стиле аннотаций это сделать.
Но реализовать это лучше на уровне IDE. Во-первых, не будет привязки к конкретному языку, а во-вторых, все эти дополнительные конструкции потребуют удобных GUI элементов.
Проблема в том, что языки программирования формальны, они недопускают неоднозначности. Грубо говоря, есть только один жестко заданный путь исполнения программы.
А естественные языки неоднозначны. Ингда одно и то же предложение можно понять разными способами. И опыт и здравый смысл позволяет оценить правильность того или иного варианта.
Было бы интересно найти способ сблизить формальные и неформальные языки. Это открыло бы очень много новых возможностей по автоматизации программирования и тестирования, различным компьютерным помощникам и т.п.
Это я и назвал огромным опытом. Это не только повторение наблюдений, но и их систематизация.
Так что, возможно, способность накапливать и повторно использовать знания это есть священный грааль искусственного интеллекта, который еще предстоит найти.