В общем, спасибо еще раз за замечание, я наконец-то созрел дать взвешенный ответ.
GRAKN, конечно, интересен. В первую очередь тем, что является единственным отличным от триплсторов более-менее популярным в наши дни представителем того, что Дейт называет «системами баз данных, основанными на логике». В их мультимодельности я бы посомневался… Да, они говорят, что поддерживают реляционную модель, но это не традиционная реляционная модель, а ее, гм, обобщение. Впрочем, тот же известный нам с вами K. I. любит утверждать, что графовая модель тоже реляционная, а Кодд, стало быть, просто узурпировал название. Не согласен с этим, тисну скоро один перевод на эту тему.
Ну и главное, про Virtuoso. Он немного ломает всю классификацию, поэтому не стал его включать (зато для любителей RDF рассказывается про MarkLogic). Базовая модель в Virtuoso реляционная, по сути это такой EAV на стероидах, однако ведущей реляционной СУБД он не является. Логика же истории была к том, что мономодельные СУБД тех времен пытались стать мультимодельными. Virtuoso же был мультимодельным уже тогда. Было принято решение в качестве «субстрата» для хранения RDF использовать реляционную модель (ну а что, разработчики КИС до сих пор всё в нее укладывают), а заодно разработать классную реляционную СУБД. Эх, сейчас так уже не делают, а берут в качестве нижележащей системы хранения RocksDB (писал об этом тут).
Если же о причинах не риторических… Когда поддерживаются и реляционная модель, и RDF, то хочется каких-то содержательных отношений между ними, а не просто чтобы первая была субстратом для второй. Адепты RDF люди избалованные, им хочется чего-то вроде RDB2RDF DM в обе стороны. Кстати, что-то подобное есть в NitrosBase. А когда отношение между данными в двух моделях заключается в банальном EAV, не очень ясна практическая применимость этих вкусностей Virtuoso наподобие SPASQL (возможность сочетать SQL- и SPARQL-запросы), пополнения SQL-таблиц результатами присоединения следствий и пр.
И самое главное… Реализованная через EAV мультимодельность кажется мне причиной багов Virtuoso, связанных с поддержкой property paths. Она на самом деле в Virtuoso весьма плохая. Предполагаю, что потому, что пришлось ее реализовывать через механизм транзитивных SQL-запросов.
Disclaimer
Но можно дипломатично согласиться, что Virtuoso просто опередил свое время. OpenLink поспешили реализовать property paths, но в SPARQL 1.1 те были стандартизованы не совсем так, как реализованы в Virtuoso, что и стало источником проблем. Но если посмотреть на работу SPARQL 1.2 CWG, то можно увидеть в вопросе о property paths некоторое тяготение в сторону Virtuoso. Но больше все предвкушают SPARQL 2, заточенный на работу с RDF*. Сможет ли Virtuoso его в принципе поддержать — не знаю. Про RDF* я немного написал тут.
Там почти в половине случаев первое предложение абзаца — шедевр гуглоперевода. Отправил автору 10 сообщений об ошибках. Надеюсь, что все выловил. Так что об ошибках в первых предложениях абзацев автору не пишите.
Пункт 16 предложил перевести как «изучение весобезразличных нейронных сетей».
Update. Об этом была статья на Хабре, там перевели как «нечувствительные к весам».
В 2011 вышло второе издание, исправленное и дополненное.
В числе «дополнений» нововведения в рекомендациях SPARQL 1.1 и OWL 2 (уже были во время подготовки второго издания в статусе Working Draft).
Книжка, безусловно, классическая. Кстати, вот название в переводе на греческий: Σημασιολογικος Ιστος για τον δημιουργο οντολογιων. Но с тех пор все же много времени прошло, появляются и другие кандидаты на роль хорошего базового учебника. Из недавнего в первую очередь назвал бы Keet, M. An Introduction to Ontology Engineering (2018). Если с уклоном в индустрию (хотя бы в названии): Uschold M. Demystifying OWL for the Enterprise (2018).
Если он говорит вам «я тебя убью», то это на самом деле означает «ты мне не нравишься», и вы должны вызвать его на баттл. Если вы ответите «да я тебя сейчас в тюрьму посажу», то услышите «все, теперь точно убью тебя». Но вы можете надеяться, что это означает всего лишь «теперь ты мне очень не нравишься».
В свете недавних событий
Допустим, кто-то призывает мстить служащим Нацгвардии США, убивая их детей. Однако если это делается красиво и в рифму, то придраться не к чему. Рифма — такое заклинание, которое не дает судье штамповать самосбывающиеся пророчества. А то ведь начнет сажать, тогда действительно убивать начнут. Грамотно расставленные запятые в посте — тоже почти индульгенция. Типа, здесь у нас не Россия, у нас интеллигенция защищает власть от народа, а не как-то наоборот.
Наверное, все зависит еще от того, поступают ли угрозы в адрес и защищаются права широкого круга лиц или определенного лица. Хотя вот в «12 разгневанных мужчин», если помните, оба «я тебя убью» произносились в адрес конкретных людей, и ничего.
Да и вообще, американский суд сам разберется. Тамошний юрист обычно бакалавр в философии-социологии-истории и рассуждать о том, что имелось в виду «в такой-то песне и в такой-то строчке», и на тему «искусство и действительность» может не хуже Эминема. Может и на баттл его вызвать :-). Один вон наш соотечественник, получивший приличное западное гуманитарное образование, долгое время на своей родине вообще в этих баттлах непобедим был.
Вряд ли какие-либо аспекты проблемы «искусство и действительность» не были уже отрефлексированы представителями этого самого «искусства». Что, если дать слово им самим? Например, вот у Эминема в «Criminal»:
A lot of people ask me, stupid fuckin' questions
A lot of people think that, what I say on record
Or what I talk about on a record
That I actually do in real life or that I believe in it
Or if I say that I wanna kill somebody
That I'm actually gonna do it or that I believe in it Well, shit, if you believe that, then I'll kill you
Т. е. если вы начинаете воспринимать все «взапраду», что ж… мы готовы начать отвечать за свои слова. Не надо, иначе говоря, замахиваться палкой на рычащую собаку. Но когда собака рычит, она определенно что-то имеет в виду.
Однако Эминем признаёт, что иногда лучше все же промолчать:
‘Cause every time I write a rhyme these people think it's a crime
To tell 'em what's on my mind, I guess I'm a criminal!
I don't gotta say a word, I just flip 'em the bird
And keep goin', I don't take shit from no one
Вообще, появление PartiQL можно рассматривать в рамках тренда SQL Interfaces to Cloud Object Stores, зафиксированного в гартнеровских Hype Cycle for Data Management 2017, 2018 и 2019 годов и потихоньку смещающегося там вправо.
Табличка из нее, похожая на приведенную в посте, предлагает классификацию мультимодельных СУБД. Не все в этой табличке согласуется с написанным в посте.
Насколько, кстати, понял, Aletheia Business — название все же компании, а не мероприятия, так что прошу прощения.
Пользуясь случаем, прошу прощения и за резкость. Мысль-то хорошая: задачи развития противоположны текущим задачам и т. д. Только не стоит приписывать её этимологическому словарю, а лучше подать эти, так сказать, морфологические эвристики просто как игру слов.
Для хранения сведений о связях между ребрами используется оригинальный sparse link index, довольно далекий от B-деревьев и их производных. Можно сказать, что он быстрый, как в специализированных графовых библиотеках, но быстрый еще и на запись. А для хранения скалярных атрибутов используются (когда используются) довольно стандартные индексы.
Я много рассказать не могу, вот в открытом доступе информация в объеме и формате патентной заявки.
Как бы отработал a.country если a имеет тип int или varchar или point
В PartiQL в свободном режиме (permissive mode) будет возвращено MISSING, в режиме проверки типов (type checking mode) запрос не выполнится. Можно «предохраняться»: CASE WHEN a IS TUPLE и т. д.
Как-то токсичненько
Ну да, ядовито. Но сами ведь пишут: а давайте сделаем как с XML.
Yet another standard
Точка и квадратные скобки, которые ведут себя практически как в Javascript, а вы там ниже предлагаете освоить JSON_TABLE, примеры использования которой ужасают даже в спецификации, где они по идее должны быть игрушечными :).
Cоздатели же знают, что называют кортежами в других языках? Почему интересно не object navigation?
Создатели знают, что называется кортежем в SQL, и пытаются это обыграть. Кортеж из реляционной модели представляется в абстрактной модели данных PartiQL плоским (со скалярными значениями полей) объектом.
$.keyvalue()
Правда зачем это, не понятно. Нужен бизнес-смысл этого действия
Спасибо, буду знать! Бизнес-смысл: допустим, есть внешний большой JSON и нужно по этим ключам сджойнить соответствующие значения из JSON с кортежами из таблицы, в которой в одном из полей лежит что-то похожее на эти ключи.
Неправильно понимаете, в режиме lax получите NULL, в режиме strict получите ошибку.
Хотите массив получить, тогда JSON_QUERY, хотите отношение сгенерировать — JSON_TABLE.
Насколько можно судить по таблицам в разделе 5.9.2 второй части, правильно. Но даже рад, если неправильно. Значит, настолько все сложно :-) В то время как в PartiQL одна простая концепция (вместо мощного языка путей и впиливаемых в декларативный язык функций): маршрут порождает отношение. Добавил там в статье обновление, объясняющее, каким образом.
Кстати интересно, как отработает по такому JSON: {"a": 1, "a": 2, "a": 3, "b": null}
В PartiQL в щадящем режиме [a] вернет, вероятнее всего, 1 (оставляется на откуп реализации). В режиме проверки типов будет ошибка, см. стр. 13 спецификации. Но можно вытащить и все значения "a" с помощью UNPIVOT.
Я бы предложил разойтись вот на чем. В SQL/JSON доступ к внешним JSON-данным отнесен к числу «non-goals» (см. раздел 1.1.8 первой части), в то время как в PartiQL все наоборот.
Во-вторых, SQL/JSON рассчитан на работу исключительно с JSON, в то время как PartiQL — и с другими иерархическими форматами (Parquet, Amazon Ion). Всем этим, можно считать, и обусловлена разница в дизайне SQL/JSON и PartiQL.
Тут хоть на двадцати, во всех это в той или иной степени калька с латинского evolutio. В русском, на мой взгляд, было бы удачнее калькировать как «разврат», но к сожалению, слово было уже занято :-).
Понятие относит нас к принципам спиральных динамик, к последовательному распутыванию чего-то.
Если что-то нужно развить, очевидно, сначала оно каким-то образом было «завито».
Лень нырять в авторов, но думаю, что мотивирующими тут были метафоры актуализации потенциального (как при развертывании свитка) или линейной проекции циклического времени.
В случае сомнений насчет смысла слова лучше всего сначала обратиться к этимологии.
В диахронии словообразовательная мотивация может оказаться довольно причудливой. Сначала лучше всего обратиться к словарю толковому.
Я бы промолчал, но на мероприятии со словом «ἀλήθεια» в названии должно быть стыдно нести такое :). Могу, конечно, предположить, что вольностью обращения с лингвистическим материалом оратор хочет уподобиться Хайдеггеру, но, блин, сначала нужно научиться правильно ставить ударение в слове «рефлексия».
В общем, спасибо еще раз за замечание, я наконец-то созрел дать взвешенный ответ.
GRAKN, конечно, интересен. В первую очередь тем, что является единственным отличным от триплсторов более-менее популярным в наши дни представителем того, что Дейт называет «системами баз данных, основанными на логике». В их мультимодельности я бы посомневался… Да, они говорят, что поддерживают реляционную модель, но это не традиционная реляционная модель, а ее, гм, обобщение. Впрочем, тот же известный нам с вами K. I. любит утверждать, что графовая модель тоже реляционная, а Кодд, стало быть, просто узурпировал название. Не согласен с этим, тисну скоро один перевод на эту тему.
Ну и главное, про Virtuoso. Он немного ломает всю классификацию, поэтому не стал его включать (зато для любителей RDF рассказывается про MarkLogic). Базовая модель в Virtuoso реляционная, по сути это такой EAV на стероидах, однако ведущей реляционной СУБД он не является. Логика же истории была к том, что мономодельные СУБД тех времен пытались стать мультимодельными. Virtuoso же был мультимодельным уже тогда. Было принято решение в качестве «субстрата» для хранения RDF использовать реляционную модель (ну а что, разработчики КИС до сих пор всё в нее укладывают), а заодно разработать классную реляционную СУБД. Эх, сейчас так уже не делают, а берут в качестве нижележащей системы хранения RocksDB (писал об этом тут).
Если же о причинах не риторических… Когда поддерживаются и реляционная модель, и RDF, то хочется каких-то содержательных отношений между ними, а не просто чтобы первая была субстратом для второй. Адепты RDF люди избалованные, им хочется чего-то вроде RDB2RDF DM в обе стороны. Кстати, что-то подобное есть в NitrosBase. А когда отношение между данными в двух моделях заключается в банальном EAV, не очень ясна практическая применимость этих вкусностей Virtuoso наподобие SPASQL (возможность сочетать SQL- и SPARQL-запросы), пополнения SQL-таблиц результатами присоединения следствий и пр.
И самое главное… Реализованная через EAV мультимодельность кажется мне причиной багов Virtuoso, связанных с поддержкой property paths. Она на самом деле в Virtuoso весьма плохая. Предполагаю, что потому, что пришлось ее реализовывать через механизм транзитивных SQL-запросов.
Но можно дипломатично согласиться, что Virtuoso просто опередил свое время. OpenLink поспешили реализовать property paths, но в SPARQL 1.1 те были стандартизованы не совсем так, как реализованы в Virtuoso, что и стало источником проблем. Но если посмотреть на работу SPARQL 1.2 CWG, то можно увидеть в вопросе о property paths некоторое тяготение в сторону Virtuoso. Но больше все предвкушают SPARQL 2, заточенный на работу с RDF*. Сможет ли Virtuoso его в принципе поддержать — не знаю. Про RDF* я немного написал тут.
Там почти в половине случаев первое предложение абзаца — шедевр гуглоперевода. Отправил автору 10 сообщений об ошибках. Надеюсь, что все выловил. Так что об ошибках в первых предложениях абзацев автору не пишите.
Пункт 16 предложил перевести как «изучение весобезразличных нейронных сетей».
Update. Об этом была статья на Хабре, там перевели как «нечувствительные к весам».
В 2011 вышло второе издание, исправленное и дополненное.
В числе «дополнений» нововведения в рекомендациях SPARQL 1.1 и OWL 2 (уже были во время подготовки второго издания в статусе Working Draft).
Книжка, безусловно, классическая. Кстати, вот название в переводе на греческий: Σημασιολογικος Ιστος για τον δημιουργο οντολογιων. Но с тех пор все же много времени прошло, появляются и другие кандидаты на роль хорошего базового учебника. Из недавнего в первую очередь назвал бы Keet, M. An Introduction to Ontology Engineering (2018). Если с уклоном в индустрию (хотя бы в названии): Uschold M. Demystifying OWL for the Enterprise (2018).
Мне кажется, Эминем противоположное имел в виду.
Если он говорит вам «я тебя убью», то это на самом деле означает «ты мне не нравишься», и вы должны вызвать его на баттл. Если вы ответите «да я тебя сейчас в тюрьму посажу», то услышите «все, теперь точно убью тебя». Но вы можете надеяться, что это означает всего лишь «теперь ты мне очень не нравишься».
Допустим, кто-то призывает мстить служащим Нацгвардии США, убивая их детей. Однако если это делается красиво и в рифму, то придраться не к чему. Рифма — такое заклинание, которое не дает судье штамповать самосбывающиеся пророчества. А то ведь начнет сажать, тогда действительно убивать начнут. Грамотно расставленные запятые в посте — тоже почти индульгенция. Типа, здесь у нас не Россия, у нас интеллигенция защищает власть от народа, а не как-то наоборот.
Наверное, все зависит еще от того, поступают ли угрозы в адрес и защищаются права широкого круга лиц или определенного лица. Хотя вот в «12 разгневанных мужчин», если помните, оба «я тебя убью» произносились в адрес конкретных людей, и ничего.
Да и вообще, американский суд сам разберется. Тамошний юрист обычно бакалавр в философии-социологии-истории и рассуждать о том, что имелось в виду «в такой-то песне и в такой-то строчке», и на тему «искусство и действительность» может не хуже Эминема. Может и на баттл его вызвать :-). Один вон наш соотечественник, получивший приличное западное гуманитарное образование, долгое время на своей родине вообще в этих баттлах непобедим был.
Стоит отметить, что по умолчанию «Блокировка содержимого» производится на уровне «Стандартная»:
Если хочется большей приватности на постоянной основе, выбирайте уровень блокировки содержимого «Строгая» или «Персональная».
Добавлю еще, что пользователи AdBlock Plus могут теперь на свой страх и риск отключить:
Вряд ли какие-либо аспекты проблемы «искусство и действительность» не были уже отрефлексированы представителями этого самого «искусства». Что, если дать слово им самим? Например, вот у Эминема в «Criminal»:
Т. е. если вы начинаете воспринимать все «взапраду», что ж… мы готовы начать отвечать за свои слова. Не надо, иначе говоря, замахиваться палкой на рычащую собаку. Но когда собака рычит, она определенно что-то имеет в виду.
Однако Эминем признаёт, что иногда лучше все же промолчать:
Недавняя новость про VISmart, ваших «выпускников»: https://habr.com/ru/news/t/466259/. Молодцы!
Вообще, появление PartiQL можно рассматривать в рамках тренда SQL Interfaces to Cloud Object Stores, зафиксированного в гартнеровских Hype Cycle for Data Management 2017, 2018 и 2019 годов и потихоньку смещающегося там вправо.
IBM движется тем же путем. Из Introducing IBM Cloud SQL Query от 2 апреля 2018 года:
Так и не смог найти эту партию. В Liechtenstein Open в 1988 году герой статьи не участвовал.
И в оригинала стоит «master», а не «grandmaster».
См. https://habr.com/ru/news/t/465697 от 31 августа.
Раз есть режим «read-only», значит, должен быть и «write-only» что тут поделаешь...
Коллеги подкинули ссылку на статью C. Zhang, J. Lu, P. Xu, Y. Chen. UniBench: A Benchmark for Multi-Model Database Management Systems из сборника проходившей год назад в Рио-де-Жанейро 10th TPC Technology Conference on Performance Evaluation and Benchmarking (боковой трек в VLDB 2018).
Табличка из нее, похожая на приведенную в посте, предлагает классификацию мультимодельных СУБД. Не все в этой табличке согласуется с написанным в посте.
А есть ещё выражение «Dead White Males». Если бы конференцию не отменили, можно было бы пошутить на эту тему.
Сайт в сети Интернет :-). Есть ещё статья в Википедии.
Насколько, кстати, понял, Aletheia Business — название все же компании, а не мероприятия, так что прошу прощения.
Пользуясь случаем, прошу прощения и за резкость. Мысль-то хорошая: задачи развития противоположны текущим задачам и т. д. Только не стоит приписывать её этимологическому словарю, а лучше подать эти, так сказать, морфологические эвристики просто как игру слов.
P.S. Правильно «приоритизация».
Для хранения сведений о связях между ребрами используется оригинальный sparse link index, довольно далекий от B-деревьев и их производных. Можно сказать, что он быстрый, как в специализированных графовых библиотеках, но быстрый еще и на запись. А для хранения скалярных атрибутов используются (когда используются) довольно стандартные индексы.
Я много рассказать не могу, вот в открытом доступе информация в объеме и формате патентной заявки.
В PartiQL в свободном режиме (permissive mode) будет возвращено
MISSING, в режиме проверки типов (type checking mode) запрос не выполнится. Можно «предохраняться»:CASE WHEN a IS TUPLEи т. д.Ну да, ядовито. Но сами ведь пишут: а давайте сделаем как с XML.
Точка и квадратные скобки, которые ведут себя практически как в Javascript, а вы там ниже предлагаете освоить
JSON_TABLE, примеры использования которой ужасают даже в спецификации, где они по идее должны быть игрушечными :).Создатели знают, что называется кортежем в SQL, и пытаются это обыграть. Кортеж из реляционной модели представляется в абстрактной модели данных PartiQL плоским (со скалярными значениями полей) объектом.
Спасибо, буду знать! Бизнес-смысл: допустим, есть внешний большой JSON и нужно по этим ключам сджойнить соответствующие значения из JSON с кортежами из таблицы, в которой в одном из полей лежит что-то похожее на эти ключи.
Насколько можно судить по таблицам в разделе 5.9.2 второй части, правильно. Но даже рад, если неправильно. Значит, настолько все сложно :-) В то время как в PartiQL одна простая концепция (вместо мощного языка путей и впиливаемых в декларативный язык функций): маршрут порождает отношение. Добавил там в статье обновление, объясняющее, каким образом.
В PartiQL в щадящем режиме
[a]вернет, вероятнее всего,1(оставляется на откуп реализации). В режиме проверки типов будет ошибка, см. стр. 13 спецификации. Но можно вытащить и все значения"a"с помощьюUNPIVOT.Я бы предложил разойтись вот на чем. В SQL/JSON доступ к внешним JSON-данным отнесен к числу «non-goals» (см. раздел 1.1.8 первой части), в то время как в PartiQL все наоборот.
Во-вторых, SQL/JSON рассчитан на работу исключительно с JSON, в то время как PartiQL — и с другими иерархическими форматами (Parquet, Amazon Ion). Всем этим, можно считать, и обусловлена разница в дизайне SQL/JSON и PartiQL.
Работающему по найму. С зарплаты работника (до вычета НДФЛ) работодатель платит следующие страховые взносы:
Можно считать, что эти добавочные 30% тоже являются доходом работника. Хотелось бы так считать.
Тут хоть на двадцати, во всех это в той или иной степени калька с латинского evolutio. В русском, на мой взгляд, было бы удачнее калькировать как «разврат», но к сожалению, слово было уже занято :-).
Лень нырять в авторов, но думаю, что мотивирующими тут были метафоры актуализации потенциального (как при развертывании свитка) или линейной проекции циклического времени.
В диахронии словообразовательная мотивация может оказаться довольно причудливой. Сначала лучше всего обратиться к словарю толковому.
Я бы промолчал, но на мероприятии со словом «ἀλήθεια» в названии должно быть стыдно нести такое :). Могу, конечно, предположить, что вольностью обращения с лингвистическим материалом оратор хочет уподобиться Хайдеггеру, но, блин, сначала нужно научиться правильно ставить ударение в слове «рефлексия».
Можно немного усложнить, добавив, например, пенсионные отчисления.
Да, это отсылка к анекдоту про поручика Ржевского, положившему начало известному мему с участием некоторых из действующих лиц вашего цикла статей.
[@A=2 or @A=3]вы что-то придумали, а как будете восстанавливать[@A>1]?//и*?