Запрос JSON-LD в масштабе

Вопрос о крупномасштабной архитектуре данных - это, конечно, обширная тема, и я далеко не специалист. Однако меня интересует, как JSON-LD используется в масштабе, поэтому, пожалуйста, извините за отсутствие конкретики и вопрос высокого уровня.

Очевидно, что такие крупные игроки, как Google, включают JSON-LD, например, в сеть знаний Google.

Если взять это в качестве примера и предположить, что JSON-LD используется в качестве формата данных для ввода-вывода в сети знаний, как строится база данных, чтобы можно было запрашивать такие массивы данных? Зависит ли он от преобразования в RDF-тройки для запросов с помощью SPARQL, или существуют другие архитектуры, которые позволяют запрашивать данные в необработанном формате JSON-LD? Какие уловки, если таковые имеются, позволяют обрабатывать (и запрашивать) JSON-LD в больших масштабах?

Такие системы, как MongoDB или Virtuoso (?), Полезны для управления большими данными в формате JSON и обеспечения их запросов, но всегда ли желательно указывать JSON (-LD) в качестве внутреннего формата для данных, а не, скажем, xml (если кто-то хочет использовать какой-то RDF)?

Опять же, извинения за неясность. Мы будем очень благодарны за любые комментарии, такие как общие указатели или обсуждение темы.


person Boris    schedule 19.09.2017    source источник
comment
Существуют также гибкие интерфейсные системы, такие как PostGraphile (прямой SQL JSON и JSON-LD support) где мы что-то предлагаем.   -  person Peter Krauss    schedule 26.05.2018


Ответы (1)


Таким образом, tl; dr заключается в том, что JSON-LD запрашивается в масштабе путем вставки его во что-то, что запрашивает данные в масштабе.

JSON-LD - это синтаксис для данных, облегчающий обмен. Спрашивать, как запросить конкретно, на самом деле не имеет никакого смысла.

Запросы к нему в масштабе - это просто вопрос помещения его в базу данных. Поскольку существует очевидное отображение модели данных RDF, любая база данных RDF будет работать. JSON-LD, вероятно, также будет легко вставлен в любую базу данных документов, например MarkLogic, где его затем можно будет запросить. А если бы у вас была обычная схема, которой соответствовали документы JSON, было бы несложно вставить их и запросить с помощью SQL. Фактически, Postgres до некоторой степени поддерживает JSON изначально, так что это, вероятно, сразу же сработает.

Любой из этих вариантов позволит вам запросить "в масштабе". Некоторые системы будут лучше, чем другие, в зависимости от вашего определения масштаба и того, какую рабочую нагрузку вы собираетесь бросить в систему. Существует также выбор дизайна: SPARQL или SQL, или ни то, ни другое, в том, как вы запрашиваете данные. Я личный поклонник SPARQL поверх SQL, но у меня есть несколько предвзятое мнение по этому поводу.

imo JSON-LD или просто JSON - это хороший синтаксис обмена между серверной системой и клиентской частью, где JSON легко анализируется и используется в любой среде Javascript. JSON / JSON-LD довольно удобочитаем, поэтому он также может быть синтаксисом представления для нас, простых смертных. Но для обмена между системами двоичная сериализация данных имеет гораздо больший смысл.

person Michael    schedule 20.09.2017