Representation URLs and interactions

[csarven]

Should a resource's representation URL(s):

• exist?
• if exists, should a resource advertise it through Content-Location?
• if exists, should there be a redirect to the representation URL?
• if the representation can be accessed, are there any constraints on i) reading ii) writing?
• if writing is allowed on a representation URL, are there any side effects to other representation URLs?

[RubenVerborgh]

My answers below:

• exist?

MAY

• if exists, should a resource advertise it through Content-Location?

SHOULD

• if exists, should there be a redirect to the representation URL?

MAY

• if the representation can be accessed, are there any constraints on i) reading ii) writing?

Reading: same as original resource.
Writing: I'd be inclined to say, only the specific representation then.

• if writing is allowed on a representation URL, are there any side effects to other representation URLs?

Yes; representations stay connected to the resource.

[kjetilk]

• if exists, should a resource advertise it through Content-Location?

SHOULD

With the guideline to avoid optional features, I am inclined to say MUST there. Other than that, I agree.

[csarven]

One design consideration is to minimise the number of interactions around a resource. From that perspective, representation URLs would not be exposed. Alternatively, if exposed, certain requests methods (basically writing; POST, PUT, PATCH) should be disallowed.

There are of course some advantages to exposing the representation URLs (eg caching), so making that optional seems reasonable, with the expectation that if supported, there is a required behaviour.

Based on that, one possibility:

• exist?

MAY

• if exists, should a resource advertise it through Content-Location?

MUST

• if exists, should there be a redirect to the representation URL?

MUST NOT. (MAY could be an alternative but that explicitly introduces new affordances around the representation.)

• if the representation can be accessed, are there any constraints on i) reading ii) writing?

Reading: don't see a need to set any. Anything in particular we need to consider?

Writing: 405. Writing must happen through the original resource. Side effect: don't have to specify or manage access controls for representations. Allow only includes read methods; GET, OPTIONS, HEAD.

• if writing is allowed on a representation URL, are there any side effects to other representation URLs?

By only allowing writing to go through the resource, server implementation is somewhat simplified ie. doesn't have to bounce from writing to a particular representation and then generating equivalents for the other representation URLs. Things should exist and die with the resource. Bonus: avoid write access control policies around representations.

[RubenVerborgh]

Writing: 405. Writing must happen through the original resource.

307?

[csarven]

307 sounds good. How well do user-agents/tools adhere to it?

[RubenVerborgh]

Perfectly, as far as I know. 307 brought clarity where the others didn't.

[dmitrizagidulin]

What is a Representation URL?

[kjetilk]

What is a Representation URL?

Following the examples in #69 , https://example.org/foo/index.html would be the URL of the representation of the resource https://example.org/foo/

[kjetilk]

Sorry, linked the wrong issue..., the one I meant to link was solid/solid-spec#134

[dmitrizagidulin]

@kjetilk I see, thanks!

[csarven]

A minor note that this is not strictly about media types. Language would be another dimension in which a server may want to expose URLs for. Ditto Datetime.

[kjetilk]

Upon thinking about this a little further, I'm curious to understand whether this is a general issue, or if it is really just about index.html. Do we have use cases for anything beyond that?

[RubenVerborgh]

@kjetilk Having representation-specific URLs is a generic issue. The fact that I can point to a certain Memento for instance. Or that I can point to a mistake in a JSON-LD representation.

[kjetilk]

@kjetilk Having representation-specific URLs is a generic issue. The fact that I can point to a certain Memento for instance. Or that I can point to a mistake in a JSON-LD representation.

Right, OK, good.

Apart from the apparent consensus in solid/solid-spec#134 that the ACL should be connected to the resource, not any particular representation, the main other problem I see is that a non-RDF resource usually wouldn't be representation of an RDF resource.

The reason I asked for whether it was just index.html is that this has some special properties: index.html would then be a representation of an LDP-C, and the LDP-C requires that certain minimal triples are present, including containment triples. HTML could easily accommodate for that using RDFa, but the generic case seems harder. Though, I suppose there usually isn't enforcement on that two different media types can be said to be a representation of a resource.

Perhaps we should have special requirements in the case where a LDP-NR is used to represent an LDP-RS, i.e. say something like "If an LDP-NR is used to represent and LDP-RS, then the representation MUST include a machine readable representation of the original RDF embedded in the representation."

This would deal with the case of index.html, in that people can stuff anything they want in there, but they would have to include RDFa to describe the container. As an implementation detail, the server could manipulate the DOM in an output filter to add it if not already present.

[csarven]

re index ("special handling"):

• index.* gets its interaction model from the HTTP request, and for the case where there isn't one specified, we need to resolve Handling requests without an interaction model #105

• where index.* exists by other means, we need to resolve Handling of resources which did not go through the HTTP interface #119

• if /index.* exists, what happens when / is requested, we need to resolve Specify/advise semantics of default Container resources (index.html/.ttl) #69

[csarven]

There is no need to specify index.* as a special case: #69 (comment)

[michielbdejong]

I see no need to complicate the life of app devs with something like Content-Location. Why not just use the same URL for all representations, and use content negotiation to retrieve them?

[RubenVerborgh]

I see no need to complicate the life of app devs with something like Content-Location.

We're not. Nobody needs to touch it.

Why not just use the same URL for all representations, and use content negotiation to retrieve them?

We are; note that those are not contradictions. We can have both:

• one resource URL that connegs to different representations
• URLs for every individual representation (indicated via Content-Location)

Then app devs who want to do conneg, can. Those who don't want, don't have to. Choice is easy.

An actual use case for per-representation URLs is legacy systems (a real one I have now is a calendar system) that do not negotiate.

[csarven]

Resolved by #196