REST и RDF, какова стратегия представления?

Question

Ваш триплер содержит множество узлов, и вы должны сделать доступной эту базу данных через интерфейс REST.

Теперь, мое решение было бы, что каждый названный (не анонимный) узел экспортируются как ресурс, чье представление:

1. всех триплеты, имеющие узел в качестве субъекта
2. всех тройных имеющий узел как объект
3. все связанные анонимные узлы.

Я немного неохотно отношусь к пункту 2: это в основном даст как входящие, так и исходящие троек.

Как вы относитесь к представлению синтаксиса REST для чисто хранилища данных, ориентированного на RDF? Вы разделяете мою точку зрения или нет, а если нет, то каково ваше отношение к ней?

Answer 1

В зависимости от того, что данные и что пользователь интерфейса хочет сделать с ним. Этот вопрос аналогичен запросу формы запроса SPARQL DESCRIBE. (Это определяется реализацией.)

Для случаев использования, которые у меня были с данными RDF, я бы пошел с 1 и 3, создав пустое закрытие узла ресурса. Кроме того, у вас может быть отдельный интерфейс для случая 2, возвращающий входящие дуги ресурса.

Answer 2

(отказ от ответственности: это не может точно соответствовать содержанию вашего вопроса, но это соответствует названию)

Я думаю, что о теме представления Rest данных RDF является общей проблемой обращения порядка концепций. Для меня нормальным было бы иметь коллекцию документов Rest с данными RDF и использовать базу данных RDF для индексирования и создания глобальных запросов.

В этой ситуации вы можете организовать свои ресурсы так, как вам нравится.

Также (если вы притворяетесь, что используете URI узла как экспортированный ресурс), ваш подход будет иметь тонкие проблемы о том, что означает ваши ресурсы: ресурсы Rest, которые вы предлагаете здесь, - «information resources», а затем они не могут быть абстрактными ресурсами. Будет конфликт между информацией и метаинформацией.

Опубликована статья here, объясняющая этот взгляд более подробно.

Answer 3

Один простой способ сделать RDF-набор данных REST-трассируемым - использовать URL-адреса для всех перемещаемых элементов.

Когда URL доступен, например, через HTTP GET, тогда результат показывает подключенные узлы (связанные как свойства и/или обратные свойства).

Формально возвращаемое представление может быть Concise Bounded Description ресурса.