Re: [Specifications] Relative Template URIs (#208)

I gave it lot of thoughts. Here is how [Heracles.ts](/HydraCG/heracles.ts) and [Heracles.net](/HydraCG/heracles.net) are doing it:

- received payload is assigned a _base_ url either an originally requested Url or actual response's Url
- received payload is processed
- each resource considered link, templated link or operation get's the assigned _base_ url
- this _base_ url assigned is used when expanding relative Iri template

I think it is more likely to be an expected behavior. I also find it easier to implement as it does not require any RDF traversing as the subject may be a blank node (in which case you would need to climb through the graph to find a first named node which still may lead to rare circumstances when it is not found).

Still, let's consider some alternatives. Let's try to figure it out on how the expansion algorithm could look like as having it bound-able to i.e. collections is tempting:

```
In case of an relative IRI template, client SHOULD consider these steps to obtain a _base_ Iri for expansion:
- Iri of the first subject being a named node that is NOT of type hydra:IriTemplate
- _base_ provided within the document carrying an Iri template
- Url of the document used to obtain a payload carrying an Iri template
```

We could also consider some additional hints to the client on which algorithm to use (leaving `current` behavior as default):
- some new predicate that could explicitly define a base url for the Iri template
- Iri template could start with some special character, i.e. ~ that could point to the `owning` resource
- variable mapping with explicit value

Please feel free to deliberate more. I just don't want to use any unnecessary quick moves to claim low hanging fruits while breaking something we can't see now.

-- 
GitHub Notification of comment by alien-mcl
Please view or discuss this issue at https://github.com/HydraCG/Specifications/issues/208#issuecomment-616222339 using your GitHub account

Received on Sunday, 19 April 2020 20:44:49 UTC