Обсуждение

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

Я вот сейчас потихоньку различаю "модель данных" и "онтологию" (это по-разному различение везде называется, но мне именно эта пара терминов сейчас нравится: в модели данных все эти "двойные целые" и "массивы", а в онтологии "функциональные места" и "продукты"). Как я понимаю, моя идея поразбираться заменой семантического веба лежит именно в части "модели данных". Впрочем, там есть и серая зона (так, во всех этих "классификациях" обсуждается именно онтологическая природа таксона. Как и в сумеречной зоне "информационных объектов" -- у нас весь облом в моделировании Essence происходит именно при попытке единообразно отмоделировать информационные и физические объекты: в ISO 15926 с этим плохо, Essence полностью все эти нюансы игнорирует, и нужно думать, что с этим делать). Как я понимаю, текущим местом обсуждения всех этих новых решений сегодня является Ontolog Forum, там как раз тусуются все те 50 человек, которые способны это хоть как-то обсуждать -- каждый со своими тараканами в голове, но они хотя бы мысль артикулируют явно. Ссылка в тексте на письмо Sowa как раз из этой серии. Так что шансы организовать какую-то коалицию всегда есть.

На онтологфоруме очередная итерация закукливания "давайте снова придумаем самый лучший ризонинг для всего, в прошлый семантиквеб получилось неубедительно". При этом, за пределы логики первого порядка вылезать не умеют или не желают. В это же время, весь остальной мир работает с разными микротеориями, применяя адекватные для разных случаев инструменты (от Agda до Python), и первым порядком не ограничиваясь. Разбираться же надо именно с данными. Единообразно моделировать всё - будь то Class, ClassOfClass, WholeLifeIndividual или темпоральная часть. Осуществлять нормализацию модальностей. И только тогда получается настоящая интеграция данных, потому что для авторов тех самых инструментов на Agda/Python/whatever становится дешевле и понятнее воспользоваться системным решением, чем изобретать свои ad hoc схемы взаимодействия.

Тут явно какое-то недопонимание про ту часть тусовки онтологов, на которую я пытаюсь указать. Главный критик decidability как раз John Sowa. Он регулярно говорит, что "требуется выразительность, никогда не требуется decidability". Ну, и он же говорит, что "ни один подход не закрывает проблемы" и пропагандирует микротеории и сознательно недоопределённый верхний уровень онтологии. Момент, когда данные переходят в онтологию -- это очень тонкий момент. В ISO 15926 этот момент тоже не решён: пришлось в том числе повторять сущности части 2 в части 4 (т.е. дублировать модель данных в онтологии, а это кривовато). Я согласен, что начинать нужно с данных, в явном виде учитывать модальности. Плюс учитывать лингвистику (тот же Sowa замечает, что без лингвистики онтология закрывает только небольшую часть задач). Ну, и помнить про http://ailev.livejournal.com/1045081.html (отношения "презентации-репрезентации" ведь основные в мостике между данными и онтологией).

Для меня граница проходит не там, где начинают обсуждать decidability, а там, где начинают сравнивать заведомо неработающие подходы к reasoning (как в письме John Sowa и слайдах из предыдущего письма треда). Это знак, что люди более увлечены религиозными вопросами, чем практикой и аспектами удобства работы с данными. Нужно ли данным вообще переходить в онтологию? Нет. Различные наборы правил (микротеории, онтологии, ...) могут присутствовать в программном обеспечении на местах. Это код. Для машин, для людей. Код тоже данные, но есть разница. Можно переслать .mp3 файл с музыкой, а можно исходный код синтезатора и .pdf с нотами - компилируйте, читайте и играйте, если получится.

Семантика -- это в каком-то смысле код. Если я переслал .mp3, то это указание на то, что играть нужно плеером. Это без разницы, даю я имя кода, ссылку на код или исходную программу кода. Онтология должна быть, конечно и в передаваемых данных. Но чужой код вполне может делать мэппинг, переопределяя в свои понятия. Это игры семантики и прагматики: их нет в чистом виде. Для кого-то перчатка брошенная, для кого-то вызов на дуэль. Но чтобы вызвать на дуэль, нужно знать про существование брошенных перчаток.

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

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

Сам смысл быстрых данных в том, что они позволяют быструю перенарезку под другую стадию жизненного цикла. Например, взять необходимые показатели из нескольких тысяч документов, и поместить их под соответствующие модальности в документ-дайджест. Ситуация, когда данные с приемлемой скоростью работают лишь на одном участке обычно означает медленные данные + месяцы тюнинга какой-нибудь Java+XSLT лапши на обоих концах, шаг в сторону и всё разваливается.

Я бы всё-таки как-то более формально определял, что такое "быстрые данные". Реляционные модели на 20тыс. табличек, как в SAP -- это быстрые данные? А фортрановские common blocks из старинных вычислительных пакетов? А JSON, который вообще не очень модель данных (как буквы алфавита ещё не язык)? Может выясниться, что сейчас есть медленные данные разной степени медленности, а быстрых пока и нет вовсе. Тогда хотелось бы метрику получить для разных степеней медленности. Без метрики плохо, результаты разных проектов по моделированию данных и онтологиям получаются несравнимыми.

Быстрые данные - когда в их спецификации отсутствуют известные нам архитектурные ошибки-замедлители. Примеры таких ошибок: 1. Невпихуемость. Ситуации вида "вы можете указать все данные в нашем прекрасном формате, но геометрию придётся добавлять отдельными файлами с указанием путей". На одной системе пути внезапно оказываются глобальными и ведущими не туда, на другую систему геометрию просто забыли прислать, etc. Это серьёзная ошибка дизайна. Формат должен поддерживать как многосхемность, так и включение произвольных бинарных данных. 2. Нерасширяемость моделей данных. Когда многосхемность (или многотабличность) есть, но приходится городить отдельную модель требований к оборудованию, вместо того чтобы реализовать её модальным дополнением к существующей модели характеристик оборудования. 3. Отсутствие чёткой спецификации. Пример - CSV: что именно будет использоваться в качестве разделителя, кавычек и escape-последовательности в кавычках заранее неизвестно, и может различаться даже между разными локализациями одной и той же версии MSOffice. Если файл пришёл не от заранее известной версии известного софта с известными настройками, то параметры его загрузки оператору приходится подбирать вручную. 4. Семантическая низкоуровневость. Например, если взять данные проекта на уровне паттернов и 15926-7, то информацию о каких-то характеристиках оборудования можно извлечь линейно или даже быстрее. Если те же данные через аксиомы слить в граф 15926-2, то автоматическое извлечение полезной информации из графа становится NP-полной задачей. Дорого, медленно, бестолково. 5. Синтаксический оверхед. Встречается во всех текстовых форматах и в ряде бинарных. Линейно завышает ресурсы на хранение данных в ~N раз и замедляет машинную обработку в ~N раз. Для человека не так страшен - нечитаемые текстовые форматы могут быть преобразованы в чуть более читаемые (например, для редактирования ужасных .plist их обычно конвертируют в .json, а затем обратно). У всего упомянутого (ад таблиц SAP, JSON, common blocks) наблюдаются различные ошибки из этого списка.

Вспомнился анекдот: "Гиви, вертолёт знаешь? -- Нет. -- А апельсин? -- Знаю. -- Так вот, вертолёт совсем не похож на апельсин!". Задание "ошибок-замедлителей" не продвигает, продвигает задание ускорителей (определяется же не антискорость, а скорость! Это же не проводимость/сопротивление!). Хотя это и напоминает определение "профессионализма" в формулировке Нильса Бора: когда не делаются основные ошибки в какой-то предметной области. Так что это не "скорость" определяется, а "профессионализм данных". Из написанного видно, что все три примера относятся к скоростям совершенно разных процессов совершенно разных жизненных циклов данных, списка процессов и метрик скоростей нет. И не отвечается на моё замечание про разные скоростные предпочтения: когда замедляется скорость одного из процессов (например, допускается невпихуемость), но ускоряется путём выкидывания синтаксического оверхеда. Главная скорость, которая обычно обсуждается в данных -- это скорость запросов. Все эти споры про SQL-NoSQL и ругань про SPARQL против реляционок именно про универсальность и скорость выполнения этих универсальных запросов. Все пять примеров не про запросы и их скорости написания-выполнения (кроме примера 4, который про запросы, но не про универсальные запросы). Из примеров, так все "пять ошибок" очень натянуто применять к common blocks. Он неудобен по совсем другим соображениям (но в целом более чем удобен: недаром огромные фортранные библиотеки просуществовали столько лет!).

Упомянутые пять ошибок это ошибки в чистом виде, а не возможная жертва за какие-то дополнительные возможности. К естественному процессу балансировки какой-либо модели данных под актуальное на сегодняшний день состояние предметной области они отношения не имеют. Ситуация "допустили невпихуемость ради ..." возможна лишь при смене шила на мыло - одной проблемной технологии на другую. Что касается хранения и быстрых запросов, то перспективнее выглядит развивать подход SQLite4 ( http://sqlite.org/src4/doc/trunk/www/design.wiki ), но не как реляционку над быстрым key-value хранилищем, а как реляционку-с-модальностями над быстрым key-value хранилищем. Но здесь, как я уже говорил, требуются дополнительные исследования.

Ну, трипл-сторы начиная с пяти реляционных join, по слухам, выигрывают уже по скорости у реляционок -- там ведь тоже оптимизаторы разные бывают. В любом случае, модальность как-то нужно моделировать (чаще всего просто пришивают сбоку классификатор, который классифицирует ту или иную модальность. И нужно понимать, как с этими модальностями обходиться по-другому. Место, где изучают модальные логики в связи с компьютингом сейчас -- это агентский подход. Там как раз и онтологии, и модальности, и всякое разное бывает. Хотя там базоданческая тематика и не обсуждается, там свои тараканы на этот счёт -- логики да онтологии, но не базы данных). SQLite4 перспективная штука, конечно. В этом году большинство NoSQL движков обещают обзавестись SQL интерфейсом, как это бы странно ни звучало. Ибо это всё аристотель у них там внутре.

У меня в черновиках висит пост о том, как удобно моделировать модальности, и когда (и как) возможен автоматический, полуавтоматический или ручной мэппинг между ними (например, между 3D+1 и 4D). Очень простая штука, как выяснилось спустя годы. Подбор примеров для широкой аудитории - сложнее.

Странно, 3D+1 и 4D обычно к модальностям не относят. Хотя темпоральная модальность, конечно, широко обсуждается, но как-то не в плане 3D+1 и 4D. Наверное, я чего-то где-то недочитал, надо будет посмотреть. Подбор примеров всегда сложнее, чем формулирование какого-то содержательного утверждения. Но меня учили, что если трудно подобрать три конкретных примера, то само содержательное утверждение не такое уж и важное: не столько знание, сколько мелкая частная эвристика для одного-двух случаев.

Возвращаясь, кстати, к теме CSV: вот свеженькая инициатива W3C -- http://www.w3.org/2013/csvw/wiki/Main_Page

У этих бюрократов обострение - лезут в любые модные или уже дохлые темы, добавляя волшебные слова "for Web". Добиваются ситуации http://xkcd.com/927/ , но чтобы все 14+1 были by W3C и одновременно actively developed.

Кстати, мне про модель данных против онтологии вчера на заседании оргкомитета один из авторов ссылку подкинул -- http://geog.ucsb.edu/~jano/LDandO.pdf Основная тема этого Summit-2014 это попытка как-то связать работу трёх комьюнити: работников данных (с их реляционными табличками и NoSQL), семантик вебовцами с их самыми разными for Web (уже часто не связанными со стеком RDF-OWL, а включающем в том числе и schema.org и многое другое), и прикладных онтологов с их Common Logic и прочими ризонерами.