Я пытаюсь понять нюансы между использованием типов отношений и ссылок со свойством Name.
Возможно, пример лучше всего проиллюстрирует мой вопрос.Рассмотрим отформатированный ответ HAL, представляющий рецензируемую статью:
{
name: "Mechanics (Le mecaniche)",
_links : {
canonical : { href: "https://phys.org/articles/Mechanics"},
"x:author" : [
{ href : "https://phys.org/authors/111", title : "Galileo Galilei"}
],
"x:reviewer" : [
{ href : "https://phys.org/authors/222", title : "Isaac Newton"}
]
}
}
Ключевым моментом, который я пытаюсь показать на этом примере, является то, что ресурс статьи содержит более одного семантически различного отношения к одному и тому жетип ресурса .В этом примере в статье есть ссылка на автора, который является автором статьи, а также ссылка на автора, который провел рецензирование статьи.
В приведенном выше примере я определил текак два разных типа отношений.Основываясь на моем прочтении спецификации HAL и спецификации Web Linking , вышеуказанный подход является действительным и согласуется со многими примерами.
НО ... Что еслиЯ отформатировал тот же ответ следующим образом:
{
name: "Mechanics (Le mecaniche)",
_links : {
canonical : { href: "https://phys.org/articles/Mechanics"},
"x:author" : [
{ name = "author", href : "https://phys.org/authors/111", title : "Galileo Galilei"},
{ name = "reviewer", href : "https://phys.org/authors/222", title : "Isaac Newton"}
]
}
}
В этом примере я решил использовать тип отношения, чтобы указать тип ресурса, и перенес его на свойство имени ссылки, чтобы сузить значение отношений.
Я считаю последний подход привлекательным с прагматической точки зрения.Я могу представить автора клиентского приложения, использующего тип отношений в качестве ключа к кешу ресурсов.В этом случае клиент будет иметь один кэш ресурсов Author вместо кэшей независимых авторов и рецензентов с дублированными записями (где автор также рецензент). Я понимаю, что один кэш разнородных ресурсов устранит этот и / или принудительный кешответственность перед браузером (где это должно быть ИМХО), НО ... опять же, это прагматическая перспектива.Многие веб-приложения обрабатывают кеширование внутренне и хотят кешировать данные по типу ресурса (возможно, применять различные политики по типу ресурса.)
Мне также нравится последний подход, потому что я могу использовать свойство имени ссылки "в качестве вторичного ключа.для выбора объектов ссылки, которые имеют один и тот же тип отношения ", согласно спецификации HAL .Я не могу помочь, но читать эту строку из спецификации как "... тот же ресурс тип."
И последнее, но не менее важное, мне интересно, как повлияет любой из этих подходовдокументация этих ссылок.В частности, в качестве «Типов отношений расширения» типы отношений «x: author» и «x: reviewer» должны иметь документацию, доступную по их URL (напрямую или через CURIE.) Если я следовал последнему подходу, используя свойства имени ссылки, тоДокументация потребует подразделов, описывающих этот именованный вариант отношения ресурса.
Я провел небольшой поиск и не нашел примеров использования свойства name ссылки.Я хотел бы увидеть некоторые из них и / или услышать больше от автора о намерениях в этой области.
Обновление ..
В ответах до сих пор подчеркивалось, чтотип отношения предназначен для отражения связи между контекстом и результатом в href, а не типом ресурса в этом месте назначения.
Это понятно, но, если возможно, пожалуйста, уточните цельсвойство «Имя ссылки». Какой пример его использования отличает его от типа отношения?