Pull to refresh
2
Бен Keкстон@ru7701

User

3
Subscribers
Send message

Да, глубина проблемы в этом. Иначе и впрямь, как было сказано в первом коменте, было бы достаточно поменять наше отношение к формальностям - токсичным высказваниям. Корпорации справились бы.
Если машина настолько тупа, что оскорбляет без причин, то получается она без причин и убьёт??

Как вообще у ИИ дела с законами робототехники? В фокусе пока только тест Тьюринга и количество ДТП с беспилотниками.

Сегодня — нет. Но завтра, возможно, будет альтернатива.

Ок, по факту так.


Ну очевидно же — вопреки соответствующей специфике текущих бизнесов.

Да, тут можно вспомнить идею гугла "каждый пятый день кодте что хотите". Ну не знаю. Условно, день в неделю — ничего.


А чего такого невообразимого в простом человеческом желании комфорта?

Это вы у бизнеса спросите, что такого сложного учитывать простые ПЕРСОНАЛЬНЫЕ желания людей. ) На самом деле реально сложно, но стало проще (см. про экосистемы).


И где есть такие бизнесы, которые реально учитывают персональные хотелки? Пустозвонную декларации про «персональный подход» не предлагать. Так же как и включение в приложения пункта меню «настройки».

А их пока и нет. Но появление экосистем ситуацию меняет, т.к. хотя бы ВОЗМОЖНОСТЬ персонализации с ходу есть — банки, чаты, курьеры и соц.сети знают нас лично. И теперь лишь вопрос времени — обогащение этой инфы "покупательскими" подробностями. Например, Сбер выдав мне кредит на машину может перепродать инфу о ней бизнесам своей экосистемы. Если среди них окажется автосервис, я могу рассчитывать получить соответствующее умное предложение.


И, соответственно, ИТ автосервиса теперь должен уметь отслеживать и "продажно" реагировать на эти тригеры. Думается им не обойтись без освоения Semantic Tech в целом и Data-Centric в частности — я на это ставлю.


Языки программирования не имеют отношения к бизнесу. Бизнес использует результат работы программиста, который, в свою очередь, использует языки программирования.

Да понятно, конечно связь не прямая. Но если кодерам раз за разом будут ставиться принципиально новые задачи и инструменты им придется выбирать раз за разом новые. Вот так бизнес и убьет. Ну ладно, не бизнес, а принципиально новая бизнес-ситуация.


Опять мимо. Жизнь есть штука сложная, составленная из миллионов компонентов. Миллион компонентов никуда не денется. Хотя нектороые отомрут, да.

Верно, в 99% случаев изменения бизнес-ландшафта не могут подставить миллионы компонентов. Но нам повезло — речь идет о 1%. Смена парадигм. Она не каждый год и даже не каждое столетие происходит. Угроза нависла именно над "миллионами".


И не стоит обращаться к личному опыту — это вот только год как пошло. Пока, считай, еще никого и не коснулось.

Мечтателям и творцам сегодня одна дорога — в рабы к гуглам.
… готов к компромиссам? Не с гуглами, а с такими же людьми.

Не ясно, так одна дорога в рабы или есть альтернативная дорога компромиссов с людьми? Если первое, то как же тогда родится что-то объективно не соответствующее специфике текущих бизнесов? Если второе, так вроде автор и не против критики. Даже как раз ее запрашивает.


Вообще, идея оочень актуальная. Современные клиенты сейчас переворачивают традиционные бизнесы с ног на голову. Требуют невообразимое — учитывать свои персональные хотелки! Представьте, под клиента в таком смысле последний раз подстраивались сотни лет назад ублажая дворян. Но то были 0,01% избранных. А сейчас нужно облизать каждого владельца лопаты — жуткие 20% населения земли! Бизнесам одним не справиться, и они лезут в экосистемы. Хуже того, в суперапы. Лезут не образно, а всем своим бизнес-кодом. И это совершенно новое. Это то, что убъет одни языки и родит новые ныне неведомые. Одно только понятно — они будут значительно декларативными, ибо в этом и суть захода: бизнесы теперь декларируются у экосистем. Вы поймите, ВСЯ старая ИТ-жизнь — коту под хвост!


Если кто-нибудь думает, что жизнь устаканилась и власть гуглов хоть сколько-нибудь перманентна, то, ну что же, для них видимо есть важные новости. Все только начинается.

Пока архитекторы, программисты и подрядчики выполняют свои задачи, продуктолог формирует тарифы, готовит комплект документации по продукту — sales kit и маркетинговые материалы по продукту (включая контент для сайта). Может совместно с маркетологом составлять план продвижения продукта.
Sales kit — это в том числе ТЗ (в смысле Technical Assignment). А кто его составляет? Если не продакт, то он такого напродает! А если он, то времени на маркетинг пойди найди. Как это разруливать?
Вот еще такая мама: ASUS N3050T.
Спасибо автору — не догадывался, что нужно замыкать зеленый-черный.
Ага, содержание слегка не дотягивает заголовка. Методы программирования, зарплаты, обучение, деловая мода… это все форма. А ожидаешь, ну хоть немного содержания. Фиг с ним, что кодит наивный студент — вопрос ведь в том ЧТО он получает на выходе, какую архитектуру организует и почему именно ее.
Автор строит красивый замок на песке, но ближайшая сильная волна смоет его.
Шикарно. Тема обработки бизнес-логики представляется самой пикантной и многообещающей во всей этой эпопее. Ну на данном этапе. Не зря её во главу угла ставят как основатель Stardog, так и новички из TerminusDB.
С нетерпением ожидаем итоговую часть.
Увы, так. По текущему состоянию даже в предельном случае идеальной оцифровки в RDF даже и бизнес-логики на выходе получается не более чем крутая экспертная система. Это несколько обескураживает, но деваться некуда. Надежда (не хочется про религиозное «вера») помогает, но не более. Впрочем, и без нее задача построения идеальной корпоративной экспертки очень мотивирует.
Не безызвестный онтологам А.Левенчук писал тут недавно что, «мышление происходит в мозгах+экзокортексах, и происходит оно обычно при письме». Т.е. пишу — значит мыслю, генерирую знание. Но если так, то получается мышление тесно связано с языком в целом и его грамматикой в частности. А грамматика — это уже почти RDF: подлежащее, сказуемое, дополнение. Еще бы в модель добавить определение с обстоятельством и был бы полный набор (готовлю под это «формуляр» — соответствующий стиль использования RDF). Итого, по этой цепочке выходит, что есть что-то мыслительное в SemanticWeb.

Да, триплсторы без потерь транслируются в реляционки. Т.е., как ни крути, автор прав. Но только на данный момент. RDF — перспективный знаниевый бульон в силу моделирования языковой грамматики. И как жизнь появилась из бульона аминокислот, так и генерация нового знания может появиться скорее именно здесь — в rdf-котле. Нужно еще подключать какую-то хитрую вычислительную обработку, но питательная основа первична.
Насчет «отказаться от RDF» я конечно поспешил (спасибо группе — посвятили). Но, что важнее, присутствует прогресс.
Можно, наверное, выделить две серии корневых изменений:

1) Named graph + LinkedData (2014-2015)

2) RDF* + Knowledge graphs (2018-2019)

Так вот, думаю, накатывает новая (Бог любит троицу?). Об этом могут свидетельствовать подвижки внутри гигантов: построение экосистемы данных (Сбербанк). И мне еще кажется недооцененной идея прикреплять к триплам id (как это вроде есть в Stardog). RDF* — хорошо, но не достаточно.
Да, не вооруженным глазом видно, SemanticWeb ищет спасительные соломинки — то JSON-LD, то теперь GraphQL. И напрашивается реакция: чем смотреть по сторонам, не лучше ли разобраться в себе, хорошенько покопаться в модели. Возможно пора уже заменить RDF на что-то более практичное ради успеха триплсторов.

Спасибо за ссылку на группу. Давно искал более-менее живое общение на тему SW.
I. GraphQL для доступа к RDF

Этот тренд усиливается с каждым месяцем. Как минимум, два спеца и целая DBMS выразили поддержку только с конца года...



Кажется утверждается MultiAPI для MultiDBMS. GraphQL так хорош?
Это очень похоже на ситуацию с аналитикой семилетней давности. Отрасль радостно приняла колончатые базы как практичную вещь, при этом понимая, что кубы все равно лучше. Любим одних, женимся на других?
Есть мысль, что в этом разговоре слишком уж много сводится к личности специалиста. А где-же автоматизация его деятельности? Никто не мучается вопросом откуда взяться бухгалтерам или даже продавцам. Потому как первых на 70% страхует 1С, а вторых на 30% CRM. Да любую офисную позицию поддерживает какая-то Management-система… кроме продакта.
Да, есть PIM, но их функционал сейчас просто ничтожен.
И вишенка на этом пироге — кажется именно продуктовику и нужны наибольшие вычисления, т.к. при сегодняшнем клиентском трафике вручную выдумывать продукт — это безумие.
В тенденции «Повсеместное применение BI» можно было бы еще упомянуть появление колонных баз данных и соответствующих гибридных СУБД. Они позволили получить аналитику не заморачиваясь с спец-хранилищами и кубами. Это ведь революция в аналитике! Такие штуки как clickhouse вообще доступны даже SMB.
Впрочем, конечно на конкретной задаче поддержки работы ОС плюсы RAM-дисков могут не сказаться. Тут нет частой перезаписи массы файлов. Это и было видно на примере тех тонкачей, даже без всяких PCIe.
Да, как бы ни были устойчивы современные SSD, ресурс есть ресурс. Если задачи связаны с частой записью на диск, то RAM-диск уместен.
Скорость замерял вчера: запись массива файлов в RAM идет на 50% быстрее, чем в мой GIGABYTE M.2 PCIe SSD. Это весьма заметно и приятно.
В далеком 2008-ом админил сетку на 30 тонких клиентов и настроил там LTSP/Ubuntu. Т.е. ОС и проги грузились целиком в ОЗУ машинок по сети. И было на тех тонкачах по 2Gb ОЗУ. Работало отлично, но я бы не сказал, что работа ОС из ОЗУ как-то её ускоряла.
Ок. Возможно такая критика RDF не обоснована и модель жизнеспособна для своих, в том числе бизнес-целей. Надо признать, впечатляет и то как активно энтузиасты продвигают RDF-СУБД наподобие GraphDB. Плюс, конечно нужно вспомнить, что «графовая семья» включает в себя не только RDF, но и LPG — моделью данных Neo4j. У второй тоже своя востребованная на рынке правда. Просто очень надеюсь, что в семье найдется место и для чего-то нового.
Думается автор заглавного коммента имел ввиду, что среди терминов RDFS главным был rdf:type который цепляет экземпляры к классам. Отсюда, если в подлежащем трипла оказывается какой-то из классифицированных экземпляров, то соответствующий класс становится там обстоятельством. А по поводу именованных графов общепринято мнение, что это способ учесть контексты предложений, чем в языке часто занимаются определения.

На самом деле, не столь уж и важно верны ли эти догадки насчет нововведений RDF. Основной посыл другой: модель изначально не пыталась реализовать что-то вроде определений и обстоятельств, чем обрекла себя на статус академической игрушки.

Есть планы сие исправить.
В обычных языках обстоятельства и определения тоже не обязательны. Ни в одном из случаев. «Маша села в машину. Эта машина отражается красным цветом.»… Все только за счет подлежащих, сказуемых и дополнений, или, будь по Вашему, за счет связок объект-свойство-значение. Но в реальности мы просто скажем «Маша села в красную машину». Применяем определение. Тоже самое с обстоятельствами.

В этом и претензия к RDF. Эта штука действительно то необходимое, что нужно для описания чего угодно. Но в реальности, как и в случае с языками, нужно не минимальное, а удобное. Ученым это не надо, а всем остальным надо.

Что интересно, сообщество SemanticWeb, не смотря на свою академическую природу, таки пытается сделать RDF чем-то удобным. Думаю, так появился RDFS — попытка реализовать обстоятельства. Аналогично туда попали именованные графы — шаг в сторону реализации определений. Но это все костыли. Прилепляются сбоку и соответствующим образом воспринимаются.

RDF — хорош как идея, но кажется эту идею нужно переписывать с нуля.

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity