Specification: 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 https://github.com/solid/solid-spec/issues/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.

[mikeadams1]

I believe we should leave this subject alone! This is a feature, and if we now believe that this feature needs to be abolished due to failure to access data browser, then that is an excuse to limit the use of the feature to a very limited and backwards driven model. What we have hear is the capacity to be even more creative, and just because one does not express turtle in it, does not mean that this is problematic for those who are using it for an alternative use.

[mikeadams1]

@RubenVerborgh

Writing: I'd be inclined to say, only the specific representation then.

If you limit this only to specific representations, what about those of us who have implemented its use and are constructing our own model and use cases?

[RubenVerborgh]

@mikeadams1 It seems that you have a different interpretation of the subject than the rest of us in this thread. This has nothing to do with Databrowser or with us removing support for any representation format whatsoever.

Rather, the question is whether representations should be available through their own URLs, in addition to the existing mechanism for resources, which will not be touched in any way.

This is a feature

Not yet.

if we now believe that this feature needs to be abolished

We don't.

If you limit this only to specific representations,

I don't.

what about those of us who have implemented its use and are constructing our own model and use cases?

Nothing changes.

[mikeadams1]

https://github.com/solid/specification/issues/69#issue-497863441

[RubenVerborgh]

@mikeadams1 Then that discussion belongs there, not here.

[mikeadams1]

@RubenVerborgh my comment was not off topic and i do not appreciate you silencing my opinion, this is an open source project.

[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]

@mikeadams1 No one's being silenced; your comments on here so far pertain to #69 and should all be there. In this issue, were are discussion the notion of representation-specific URLs. None of the things you wrote in this thread have any technical relevance to that. Happy to follow up in #69, not here—unless you write comments specifically about representation-specific URLs.

[mikeadams1]

My comments were regarding that, I am not confused, you are!

[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.

[RubenVerborgh]

@mikeadams1 Okay then:

This is a feature

It is not, so not relevant.

we now believe that this feature needs to be abolished

No one here does, so not relevant.

just because one does not express turtle in it

Not said at all, so not relevant.

If you limit this only to specific representations

We don't, so not relevant.

what about those of us who have implemented its use and are constructing our own model and use cases?

Unaffected, so not relevant.

---

So as you can see above, you have not produced any comments relevant to the topic. Please refrain from commenting in the wrong place.

[mikeadams1]

The facts on the face of the resource URL should be able to speak for itself, why does a URL resources need to point to something else?

[RubenVerborgh]

The facts on the face of the resource URL should be able to speak for itself

They do.

why does a URL resources need to point to something else?

They don't. Please allow the others here to have a relevant technical discussion, thanks.

[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 https://github.com/solid/solid-spec/issues/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 https://github.com/solid/specification/issues/105

• where index.* exists by other means, we need to resolve https://github.com/solid/specification/issues/119

• if /index.* exists, what happens when / is requested, we need to resolve https://github.com/solid/specification/issues/69

[csarven]

There is no need to specify index.* as a special case: https://github.com/solid/specification/issues/69#issuecomment-563455568

[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 https://github.com/solid/specification/pull/196