Size: a a a

Типы в языках программирования, моделирования, представления знаний и жизни

2019 August 26

M

Maxim in Типы в языках программирования, моделирования, представления знаний и жизни
Обобщение по одному из формализованных векторов обсуждения:

1. Языки программирования — это искусственные формальные (формализованные) языки, созданные для программируемых машин.
2. Деятельность по формализации контента для созданных языков программирования, основывается на естественных языках.
3. Естественные языки неоднородны, и лингвистами различаются принципиально:
— группа естественных аналитических языков;
— группа естественных синтетических языков;
— группа естественных полисинтетических языков;
— и другие.

Т.е. по определению самой лингвистической топологии, представлена существенная разница между этими группами естественных языков. Из чего следует факт того, что деятельность формализации процесса, осуществляющаяся на естественном аналитическом языке, может существенно отличается от деятельности формализации этого же процесса, осуществляющегося на естественном синтетическом языке.

В чем сущностное отличие этих групп естественных языков?
Как так вышло историографически для человека, что существуют эти различные группы естественных языков?

Лингвисты не дают ответ на эти вопросы, их предметная область вне антропологического различия группы естественных синтетических языков и группы естественных аналитических языков. Ведь вопрос не о том, как отличаются группы естественных языков, а о причинах, обосновывающих факт отличия.

Сначала на естественных языках осуществляется формализация контента для языков программирования, затем уже из осуществлённого образуются «триплы», и укладываются в персептроны (нейронные сетки), — и при этом теряется трипловая форма. Т.е. сначала становится неочевидной логика каждого из трех слагаемых одного трипла, а потом, когда учитывается только логика трипла, то сама причинно-следственность осуществления этого трипла становится неочевидной, путем своего представления уже без основания на самой природе трипла. Другими словами, сначала забыли о логике слагаемых трипла, а потом забыли о том что забыли. (Речь о природе слагаемых для триплов, а не о видах полученных триплов.)
А самое примечательное во всем методе «триплов» то, что формализация контента на естественных языках для слагаемых триплов (для формальных языков программирования), вообще осуществляется без учета существенного различия языков, различных групп естественных языков.

Логика именно антропологических причин различия групп естественных языков (но не лингвистического описания фактического различия, - это ведь следствие причин) — цель научно-исследовательской аналитической деятельности, достижение которой необходимо для решения проблем, сформулированных в целеполаганиях этой группы здесь (в телеге).

Очевидное публичное отсутствие здесь (в группе телеги) продолжения обсуждения предполагаемого анализа причин факта отличия групп естественных языков (вектор обсуждения), указывает на недостаток аудитории, — не достаточно необходимых аналитических суждений, по представленному вектору.

Ау, системные аналитики, — системная инженерия — это междисциплинарный (трансдисциплинарный) подход для создания успешных систем ...

Ни кто не ждет здесь чудес в виде глубоких прикладных знаний сразу всех возможных научных дисциплин, но не рационально и нелогично отсутствие самой формализации по этому вектору обсуждения, раз очевидно логическое его представление.
Telegram
Maxim in Типы в языках программирования, моделирования, представления знаний и жизни
1. Языки программирования — это искусственные формальные языки, созданные для программируемых машин.
2. Деятельность по формализации контента для созданных языков программирования, основывается на естественных языках.
3. Естественные языки неоднородны, и лингвистами различаются принципиально:
— группа естественных аналитических языков;
— группа естественных синтетических языков;
— группа естественных полисинтетических языков;
— и другие.

Т.е. по определению самой лингвистической топологии, представлена существенная разница между этими группами естественных языков. Поэтому деятельность формализации процесса, осуществляющаяся на естественном аналитическом языке, существенно отличается от деятельности формализации этого же процесса, осуществляющегося на естественном синтетическом языке.

В чем сущностное отличие этих групп естественных языков?
Как так вышло историографически для человека, что существуют эти различные группы естественных языков?

Лингвисты не дают ответ на эти вопросы, их предметная область вне…
источник

AL

Anatoly Levenchuk in Типы в языках программирования, моделирования, представления знаний и жизни
Konstantin Surkov
Ok, я потратил на чтение максимум времени, который я могу потратить на такое мутное чтиво, не нашёл *ни одного* примера. Так что если у вас есть примеры, надеюсь, что вас не затруднит. Иначе так и запишем, "не смог привести ни одного примера, подтверждающего claim" :)
Про in-the-small и in-the-large
источник

AL

Anatoly Levenchuk in Типы в языках программирования, моделирования, представления знаний и жизни
Konstantin Surkov
БД же не делаются просто так, "потому что время свободное было". Любая БД всегда делается с какой-то целью. А именно, поддержки определённых бизнес-процессов, в широком понимании слова бизнес. И если процессы, которые надо поддержать, включают отпиливание ручки, то БД это поддержит. А если нет, то не поддержит. Где проблема-то?
Проблема в том, что всё время приходится иметь дело с базами данных, которые делали разные люди для разных целей — это очень справедливо написано. Но у какого-то ещё одного человека, нуждающегося в третьей цели часто нет полномочий переписывать эти две базы в ещё одну базу. Это ситуация федерирования информационных систем. Федерация — это когда должны общаться автономные, в том числе автомномно развивающиеся непрерывно системы. Каждую из начальных баз будут продолжать развивать независимо в рамках своей команды и своего дела, и что делать в этом случае тому третьему, которому нужны они обе для его третьего дела? Дальше можно обсуждать, как выйти из этой ситуации. Но реляционные базы не лучший вариант для таких обсуждений.

Опять же, если работает даже большая команда с одним начальником и всё упихивается в огромный реляционный data lake, то в такой команде проблем с реляционкой не возникает, а когда они возникают, то разные оптимизаторы их решают — все проблемы только в скорости. О об общей модели мира там договариваются. А мы говорим не о проблемах в скорости, а о проблемах в моделировании мира. Вот с этим посложней будет — если нет возможности перепроектировать полностью схему реляционок, то что делать?

Люди начинаются мучаться, даже не понимая сути проблемы. Книжка BORO помогает разобраться.

Вообще-то вы первый человек из программирующего (но и не только программирующего) люда, кто не посчитал эту книжку полезной. Мне даже интересно, почему.
источник

KV

Kirill Valyavin in Типы в языках программирования, моделирования, представления знаний и жизни
Anatoly Levenchuk
Проблема в том, что всё время приходится иметь дело с базами данных, которые делали разные люди для разных целей — это очень справедливо написано. Но у какого-то ещё одного человека, нуждающегося в третьей цели часто нет полномочий переписывать эти две базы в ещё одну базу. Это ситуация федерирования информационных систем. Федерация — это когда должны общаться автономные, в том числе автомномно развивающиеся непрерывно системы. Каждую из начальных баз будут продолжать развивать независимо в рамках своей команды и своего дела, и что делать в этом случае тому третьему, которому нужны они обе для его третьего дела? Дальше можно обсуждать, как выйти из этой ситуации. Но реляционные базы не лучший вариант для таких обсуждений.

Опять же, если работает даже большая команда с одним начальником и всё упихивается в огромный реляционный data lake, то в такой команде проблем с реляционкой не возникает, а когда они возникают, то разные оптимизаторы их решают — все проблемы только в скорости. О об общей модели мира там договариваются. А мы говорим не о проблемах в скорости, а о проблемах в моделировании мира. Вот с этим посложней будет — если нет возможности перепроектировать полностью схему реляционок, то что делать?

Люди начинаются мучаться, даже не понимая сути проблемы. Книжка BORO помогает разобраться.

Вообще-то вы первый человек из программирующего (но и не только программирующего) люда, кто не посчитал эту книжку полезной. Мне даже интересно, почему.
Я тоже пытаюсь через неё продраться, очень тяжело
источник

AI

Alex Ivanov in Типы в языках программирования, моделирования, представления знаний и жизни
Konstantin Surkov
Как я уже сказал, БД делается с целью. Разные БД делаются с разными целями. Поэтому, прежде чем федерировать, надо сделать третью базу, структура которой, в общем случае, отличается и от первой, и от второй базы. Теперь пишем ETL, сливаем из первой и второй в третью, и вот она федерация. Альтернатива – делать transformation on the fly, но это обычно приносит больше геморроя in the long run. Потому что это попытка использовать 1 и 2 не с той целью, с которой они проектировались.
А это точно data federation, а не master data?
источник

AI

Alex Ivanov in Типы в языках программирования, моделирования, представления знаний и жизни
Такое впечатление, что с федерируемыми данными до сих пор в основном работают в Linked Data (с приложением к ним rdf и всего остального)
источник

ON

Oleksandr Nikitin in Типы в языках программирования, моделирования, представления знаний и жизни
кстати, а есть какой-то стандарт на 4D linked data?
источник

AI

Alex Ivanov in Типы в языках программирования, моделирования, представления знаний и жизни
Там понемногу идет гармонизация с property graphs через поддержку реификации на уровне триплов http://blog.liu.se/olafhartig/
И накладываемая типизация https://www.w3.org/TR/shacl/ в виде rdf shapes
источник

AZ

Alexey Zakhlestin in Типы в языках программирования, моделирования, представления знаний и жизни
Oleksandr Nikitin
кстати, а есть какой-то стандарт на 4D linked data?
Соль на рану.
Нет нормального стандарта. Есть попытки разной степени неудачности.
источник

AI

Alex Ivanov in Типы в языках программирования, моделирования, представления знаний и жизни
Тут надо различать "наличие стандарта" и "наличие нормального описания" ))) owl вариант в стандарте есть
источник

VK

Val Krylov in Типы в языках программирования, моделирования, представления знаний и жизни
В owl всё плохо с временем и другими модальностями.
источник

AI

Alex Ivanov in Типы в языках программирования, моделирования, представления знаний и жизни
Это да, но никто не мешает надстраивать на уровне RDF или OWL дополнительные машины вывода разной степени мощности, вплоть до HOL
источник

AI

Alex Ivanov in Типы в языках программирования, моделирования, представления знаний и жизни
Для любопытствующих есть еще тест-кейсы ISO15926 от INST https://github.com/usnistgov/iso15926
источник

ON

Oleksandr Nikitin in Типы в языках программирования, моделирования, представления знаний и жизни
возможно-то всё, а вот хочется выразительной нотации, которая уменьшает случайные ошибки и увеличивает наглядность, гибкость etc
источник

AT

Alexander Tchitchigin in Типы в языках программирования, моделирования, представления знаний и жизни
Само по себе-то, наверное, можно, но это всё равно ничего не будет гарантировать, если систематически не проверять в нужное время в нужных местах. Хорошо бы для начала хотя бы определить эти места и времена.
источник

AI

Alex Ivanov in Типы в языках программирования, моделирования, представления знаний и жизни
С точки зрения валидации данных на уровне RDF state of the art — это SHACL Shapes по концепции закрытого мира. Отдельно "накладываемые ограничения" с возможностью расширения (вплоть до императивных конструкций на JS). Отдельные от иерархии классов и отдельно от словарей классов и свойств.
источник

AL

Anatoly Levenchuk in Типы в языках программирования, моделирования, представления знаний и жизни
Alex Ivanov
Тут надо различать "наличие стандарта" и "наличие нормального описания" ))) owl вариант в стандарте есть
Если речь идёт об OWL-ISO15926, то никакого отношения этот OWL к содержанию ISO 15926 не имеет, это там что-то типа "транспортного формата". И нужно сначала выковырять ISO15926 из owl-контейнера, а потом уже делать с тамошними данными какие-то вычисления/вывод.

Есть удобный инструмент для вытаскивания нормального содержания как из OWL-ISO15926, так и просто из OWL. https://github.com/TechInvestLab/dot15926/
источник

AL

Anatoly Levenchuk in Типы в языках программирования, моделирования, представления знаний и жизни
Вообще, тонны материала по ISO15926 и тамошнему инструментарию было в https://dot15926.livejournal.com/

Но пик хайпа там прошёл где-то в 2013-2014 годах, при этом OWL сыграл не последнюю роль в убийстве идеи.
источник

AI

Alex Ivanov in Типы в языках программирования, моделирования, представления знаний и жизни
У нас сейчас идея-фикс (в стадии проверки на прототипе), что уровня RDF + SHACL валидация + кастомные машины вывода — этого достаточно для задач такого класса )))
источник

AI

Alex Ivanov in Типы в языках программирования, моделирования, представления знаний и жизни
На уровне низкоуровневой инфраструктуры по-крайней мере
источник