Обсуждение

http/2 -- это хорошо. Наконец-то появится шанс, что поделия w3c станут окончательно очевидным нонсенсом, и их можно будет со спокойной душой выкинуть.

Мне кажется, что эти две хакатонские темы неразделимы. В обоих случаях придётся заниматься и presentation, и representation. Там низкоуровневая кодировка будет различаться при обработке бинарных форматов, XML-based форматов или построении пользовательского интерфейса через HTML+CSS+JS в браузере. Можно либо выращивать обобщённый механизм на базе scanner+builder (с потерей разного сахарка, специфичного для 15926-2 и 15926-8) и лёгкие readers/writers, либо всё то же писать вручную в виде тяжёлых readers/writers, но с общими концепциями в голове.

Конечно, темы presentation и representation тесно связаны, просто по определению этих понятий. Но фишка не в простой "перекодировке", а паттерновой -- так что там уже не просто билдер со сканером, но и pattern search (в части паттернов у нас много чего сейчас происходит. И это вполне в духе самых разных мейнстримов, имеющихся сейчас в новом моделировании данных -- там всякие перегонки из таблиц в граф обязательно паттернированные, хотя и называется это всё везде по-разному). Я вот поглядел ещё раз, может и правильно было бы делать не два разных проекта, а один проект покрупнее: там ведь работа более-менее естественно распараллеливается на работу с отдельными представлениями.

Речь вот о чём: Запросы сканера это один язык. Выражения билдера - другой. Описания паттернов - третий. Каждый импорт из экселя, будь то таблан напрямую в билдер или импорт через паттерны - ещё отдельный код. Но можно написать сканер для экселевских таблиц - find(sheet="Goods", Supplier="Acme Corporation"). Или билдер для документов-отчётов. И все они будут удивительно похожи. Действительно ли нужны разные языки, или достаточно одного, с разными адаптерами? Мне кажется, что достаточно.

Не совсем так. Хочется писать with context("data_1.rdf", "data_2.xlsx") find(hasName='AcmeCo", hasAddress=icontains('Main'), hasDirector='Ivanov') где hasAddress - http://adresses.org#BusinessAdress hasDurector - колонка "Director Name"

В этом примере не ясно, какая часть запроса относится к графу, а какая к таблице. Все properties определены и для графа и для таблицы? То есть, у нас пересечение всех айдишников, для которых в графе "AcmeCo" и icontains("Main"), а также в таблице "Ivanov", или у нас объединение всех айдишников, для которых либо в графе, либо в таблице соблюдаются все три условия? Однако, развитый движок запросов должен поддерживать оба кейса.

Пример неполный, конечно. В более полном варианте контекст определяет для каждого источника реализацию в нём от одного до всех трёх ключей в виде предиката/имени колонки/имени поля/.... С айдишниками тоже надо сперва разобраться. Указать, где в данном источнике уникальный ID - URI/имя колонки/номер строки/primary key/... или же уникальный ID строится из нескольких элементов или частей элементов. Это всё навеяно стандартным мэппингом R2RML и стнадартом JSON-LD. Поиск возвращает все элементы, для которых при совпадении уникального ID все три условия могут быть собраны по источникам. Кейс вроде один, второй кейс появляется только для источников без primary ID? То есть надо конечно разбираться, как возвращать данные, когда значения пропертей для одного ID попадают под условие, но в разных источниках разные. В общем-то я это представляю как объединение всех источников в один трипл стор (ну или квад стор конечно, так как нам нужны и реификация, и именованные графы).

Зависит от объёмов данных. Какие-то выгоднее сливать на лету, другие лучше сразу перегнать в единую базу для задачи. И не обязательно в квадстор. Таблицы в реляционках менее ресурсозатратны. Т.е. запрос к таблице Specializations может оказаться в разы быстрее чем поиск экземпляров part2:Specialization в графе, при тех же технологиях и железе.

Я не про реализацию и перформанс, конечно. Я про концептуальную модель этого безобразия. Мне пока что кажется, что мультиграфы - наиболее адекватная модель, мультиграфы реализуются над именованными графами, именованные графы - над квадами. Значит надо реализовывать квады, а дальше разберёмся :-)

Наиболее адекватная модель - лестница модальностей, о которой я писал летом. В этом виде представим любой мультиграф. Как обычный граф образует таблицу рёбер, так и мультиграф образует лестницу. Но с такой лестницей информация может быть представлена более эффективно для человеческого восприятия и машинной обработки, используя записи вида weight 42 kg, без разбития их на лапшу мелких записей-квадов. А вот для запросов наиболее применимо выглядят конструкции высшего уровня над FOL. Так можно организовать эффективный доступ к разным представлениям и уровням абстракции, включая "условные триплы/квады" (как hasSubclass(Rel, X) в 15926-7), вне зависимости от того, есть ли они в модели данных источника.

Тут у нас с Виктором спор: он считает RDF и JSON-LD одним и тем же (трипловым) представлением, мультиграфом. А я говорю, что разница таки там есть. Так что я бы на вашем месте потестировал, что он понял из ваших примеров: вы, скорее всего, о разном говорите. Отмечу также, что Ontology Summit 2014 Hackathon -- это хорошее место, чтобы попробовать собрать заинтересованных трёх-четырёх человек (может, из разных стран) и попробовать сделать какие-то эксперименты в направлении реализации и оценки этих лесенных форматов, парсинга их в какие-то внутренние представления ("триплы", как скажет Виктор? или всё-таки иное?), запросов к ним из FOL-на-стероидах и т.д.. Ещё не поздно заявить проект ;-)

В RDF псевдотрипловая модель, т.е. кроме триплов (s, p, o) и (s, p, literal) используются (s, p, literal, datatype) и (s, p, literal, language), в качестве хака под частное применение для бесхозных метаданных. Соответственно, квады тоже могут состоять из 4 или 5 элементов. Модели RDF и JSON-LD различаются тем, что в RDF нельзя декларировать локальные свойства и локальные графы (blank nodes доступны только для subjects и objects), в JSON-LD это ограничение снято. Обе модели не поддерживают N-ary relationships. То есть, каждый экземпляр N-ary отношения приходится заменять на N+2 триплов, что увеличивает когнитивные расходы, а также в десятки раз увеличивает машинные расходы на хранение и обработку. Поверх этих моделей возможны различные представления. И мультиграф, и гиперграф, и даже одна сверхбольшая таблица. Но материализация такой таблицы невыгодна по ресурсам. А вот эквивалентной лесенкой можно минимизировать как когнитивные, так и машинные ресурсы.

Я думаю, что основное тут непонимание Виктора -- это не "нечистая трипловость" (хотя и она важна), а наличие-отсутствие нативных N-ary отношений и оценку связанных с этим различий в методах парсинга, запросов и прочих обработок, визуализации, работы с паттернами. Про хакатон -- дата события 29 марта 2014 года. В прошлом году мы участвовали, было весело. В этом году я co-champion и в моей ответственности формирование команд. Есть возможность сформировать команды (одну или больше) ровно для "низкоуровневого представления" и экспериментов с ним -- все эти RDF, JSON-LD, CVS-WD, "лесенный формат" скопом и в рознгицу т.д.. Это всё совсем может быть не связано с .15926 Editor, а может быть связано как платформой для демонстрации. Было бы кому стать team lead.

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

В обсуждении на форуме мелькала мысль, что RDF это бэкенд-бэкенд формат, а JSON фронтэнд-бэкенд формат. Ещё одна дискуссия касалась того, что имена в Linked Data должны быть нечеловекочитаемыми (чтобы мэппиться во что хочешь) и одновременно человекочитаемыми (ибо отладка мэппинга при нечеловекочитаемых именах становится невозможной). Ещё один вариант -- это уход в http/2 в бинарные представления. Правильно ли я понимаю, что предметом хакатона мог бы быть брейнсторм по поводу баланса между машино-читаемостью и человекочитаемостью? Типа какой-то метрики (шкалы) и сортировки разных представлений на предметы а) эффективности представления мультиграфов -- по памяти, скорости парсинга, объему текстов и т.д., т.е. машиночитаемости и б) человекочитаемости (уж не знаю, как тут оценивать: сколько обычно людей, столько и мнений по этому поводу -- достаточно вспомнить холивары по стилям "правильной расстановки операторных скобок" в языках программирования). Это ведь и есть "визуальные представления".

Плюсы и минусы форматов давно известны. Экспериментировать не с чем. Можно продемонстрировать различие пайплайнов "вот так всё делается через медленный и бажный RDF, а вот так через быструю бинарную лесенку". Но смысл в этом есть лишь при наличии достаточно стабильного продукта. Что касается визуальных представленией: В .15926 данные отображаются в виде определённого стиля деревьев, определённого стиля таблиц, а также обрабатываются определённого стиля запросами. Какие другие интерфейсные и инфографические методы могут быть здесь полезны? Вот что-то такое может подойти под методы коллективного брейнсторма.

Ну, ничего не мешает иметь пару или даже тройку проектов вокруг .15926 -- основной обсуждаемый пока там проект связан с публикацией чего-нибудь в Сети с сопутствующей семантизацией и дереференсингом (ибо прикручивается веб-фреймворк). Можно и интерфейсную-инфографическую команду сделать с демонстрацией преимуществ какого-то формата над RDF и JSON-LD вместе взятых, не вопрос. Ну, или обсуждать это как beyond .15926 решение, драфтинг и претендотайпинг чего-то совсем нового.