Add support for the alternate link relation

[gkellogg]

… with type application/ld+json to be used as a redirect if the retrieved document is not JSON.

For w3c/json-ld-syntax#204.

---

Preview | Diff

[gkellogg]

Note that I wrote this so that the documentUrl remains that of the original document, not that that is redirected to, but I could be convinced otherwise.

[pchampin]

This probably needs to be discussed (it is not just editorial).

This would create a different behaviour when the document is accessed directly, than when it is accessed through the "link header indirection". So I am not a big fan of the idea.

I would rather encourage the author of the JSON-LD document to explicitly set the base to the URL o the non-JSON-LD document, if that is the behaviour they intend.

[gkellogg]

The PR is definitely prospective, as the issue is still marked to be discussed, but I wanted to get it out there and see the consequences. The link header shouldn’t affect any json format, but would affect html content. What document base should be applied can be debated, but using the original document has precedent.

[dlongley]

Hmm, I think I disagree with @pchampin ... and that we want to treat this like we do with redirects, which I believe uses the original document. The argument for doing what @pchampin suggests would be that there's no way to know ahead of time what the final document will be, so you couldn't set the base to it, whereas you could set the base to the original document if you wanted it to stick.

But, processors could have a flag to switch to this other behavior. It seems to me that the sensible default would be the original document. Especially given the way that we expect this feature to be used ... which is that the linked document is really a hidden implementation detail. If you wanted to use the linked document directly you would have specified it instead of some, e.g., HTML document.

[gkellogg]

👎 to introducing another flag, though. If the document should have some specific base different from the originally referenced resource, it can use @base.

My thought in using the original resource base, rather than the referenced document, is essentially the same reasoning that lead to the semantics of HTTP status 303 for range-14 considerations.

[BigBlueHat]

If this use of alternate (which comes from HTML primarily) is meant to supplant using content negotiation, then the expectation would be (afaict) that the original resource URL would (semantically) be the correct base URL--which I think agrees with what @gkellogg said above.

Once the alternate is retrieved it should experientially be like getting a content negotiated response with a Content-Location set to the alternate and having Location still be set to the original Request-URI--which is how content negotiation plays out.

[BigBlueHat]

What I mentioned on the call Friday was that the only definition of rel="alternate" (that I'm aware of) is in https://html.spec.whatwg.org/multipage/links.html#rel-alternate

The summary definition is "Gives alternate representations of the current document." but the follow-on expansion on it includes "The meaning of this keyword depends on the values of the other attributes."

The examples in that section include alternate CSS styles (i.e. rel="alternate stylesheet"), Atom/RSS alternate representations (i.e. rel="alternate" type=""), and using it for language [content] negotiation (i.e. rel="alternate" hreflang="" +/- type="").

So, using alternate here to accomplish a pre-flight content negotiation (of sorts) is not without its precedence conceptually. However, none of that directly answers the base URI situation...as in the closest experiential case (language negotiation) the browser would navigate to the new resource based on language preferences--thereby acting more like a 30* redirect than like content negotiation.

[BigBlueHat]

Additionally, if we stick with alternate, we may need to require other link parameters (or type parameters) to clarify that this is a representation of the current document as a context vs. a representation of the current document expressed in JSON-LD (i.e. as a data document).

We could use the existing context profile URL (which is used as a rel in Interpreting JSON as JSON-LD). The experience would be similar to referencing a data document as the context of another data document.

[gkellogg]

I understand the parallel with HTTPRange-14 . But I see nowhere in those documents an indication that relative IRIs in the target document should be resolved against the source document's IRI...

There's a discussion in Cool URIs:

... Each of the RDF documents would contain statements about the appropriate resource, using the original URI, e.g. http://www.example.com/id/alice, to identify the described resource.

[pchampin]

Yes, but they do not say that a relative URI could or should be used for that...

[gkellogg]

At this point, I think you need to raise a new issue for discussion, because we seem to have quite different views on this, and discussing in a merged PR isn't a good way to be sure we resolve it.

We resolved to use the 303 redirect semantics.

[gkellogg]

the current document as a context vs. a representation of the current document expressed in JSON-LD (i.e. as a data document).

In fact, this is not simply for contexts, but for any non-JSON content where we want to use a JSON-LD representation.

I didn’t think that anything other than the rel and type fields would be necessary.

[BigBlueHat]

In fact, this is not simply for contexts, but for any non-JSON content where we want to use a JSON-LD representation.

Gotcha, so if I shipped a data document describing http://bigbluehat.com/ which also included an inline context and then referenced that URL as the @context value in my other data, JSON-LD processors would know the difference in usage based on...context? 😜 Makes sense, but maybe we should explain that, so it's clear we're not overloading the meaning of alternate in some way.

[gkellogg]

A context is just JSON-LD including @context which has meaning because of where it’s dereferenced from. The document loader is used to retrieve resourses, both as primary use (expand, compact, etc), for frames, and contexts.

The document loader will follow a link, if the retrieved resource is not JSON, for any of these cases. The use for context retrieval is incidental.