I am trying to understand the nuances between the use of Relation Types and Link's with a Name property.
Perhaps an example will best illustrate my question. Consider a HAL formatted response representing a peer reviewed article:
{
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"}
]
}
}
The key thing I'm trying to show with this example is that the article resource contains more than one semantically different relationship to the same type of resource. In this example, the article has a link to an author who is the author of the article as well as a link to an author who performed a peer review of the article.
In the above example, I defined those as two different Relation Types. Based on my read of the HAL spec and the Web Linking spec, the above approach is both valid and consistent with many examples.
BUT... What if I formatted the same response as follows:
{
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"}
]
}
}
In this example, I chose to use the Relation Type to indicate the resource type and deferred to the Link's Name property to narrow the relationships meaning.
I find the latter approach appealing from a pragmatic perspective. I can imagine the author of a client application using the Relation Type as the key to a resource cache. In this case, the client would have a single cache of Author resources instead of independent author and reviewer caches with duplicated entries (where an author is also a reviewer.) I realize that a single heterogeneous resource cache would obviate this and/or pushing cache responsibility to the browser (where it should be IMHO), BUT ... again, this is the pragmatic perspective. Many web-apps handle caching internally and want a cache per resource type (perhaps to apply different policies by resource type.)
I also like the latter approach because I can utilize the link's name property "as a secondary key for selecting Link Objects which share the same relation type", per the HAL spec. I can't help but to read that line from the spec as "...the same resource type."
Last but not least, I'm wondering how either approach would impact the documentation of these links. Specifically, as "Extension Relation Types" the 'x:author' and 'x:reviewer' relation types should have documentation available at their url (directly or via CURIE.) If I followed the latter approach, using link name properties, then the documentation would need sub-sections that describe that named variant of the resource relation.
I've done a bit of searching and I haven't found any examples of the use of a link's name property. I'd love to see some, and/or to hear more from the author about the intent of that field.
Update..
The responses so far have emphasized that the relation type is intended to reflect the relationship between the context and the result at the href, and not the type of resource at that destination.
That's understandable, but if possible, please elaborate on the purpose of a Link's Name property. What is an example of its use that distinguishes it from the Relation Type?
