Should you be allowed to submit overlapping resource and container URIs?

[jaxoncreed]

Let's say I would like to save information about me on my pod at /people/jackson and access information about my friends at /people/jackson/friends/pat. Should this be possible? In other words, should the following requests fail?

Request 1:

POST /people/jackson
content-type: text/turtle
body: SOME TURTLE ABOUT ME

Expected Result:

201 Created

Request 2:

POST /people/jackson/friends/pat
content-type: text/turtle
body: SOME TURTLE ABOUT PAT

Expected Result:

201 Created

Request 3:

GET /people/jackson/friends/pat

Expected Result:

SOME TURTLE ABOUT PAT

Request 4:

GET /people/jackson

Expected Result:

SOME TURTLE ABOUT ME

Request 5:

GET /people/jackson/

Expected Result:

SOME TURTLE ABOUT THE CONTAINER

[csarven]

I've attempted to address the underlying conceptual designs of this issue at #105 and #107. Can we close this issue in favour of those?

Here is a response any way:

Take the following as tentative based on rough consensus at #35 (comment) . There is an isomorphic relationship between a URI pattern and a specific type of LDPR. We'll detail the extent in which LDP interaction models play a role alongside URI path segments. POSTing to a non-Container request target will need to be detailed as well. For now we'll just assume your POST requests is equivalent to PUT with same request target or POST with Slug.

Request 1

Scenario including Link: <http://www.w3.org/ns/ldp#RDFSource>; rel="type" (or http://www.w3.org/ns/ldp#NonRDFSource):

• /people/jackson is created as RDFSource or NonRDFSource (depending on Content-Type value)
• /people/ is created as BasicContainer

Why:
Client's intention is to create an RDFSource at /people/jackson and they also expect that there are side effects triggered by way of server determining the path segments in the target resource. Hence, /people/ is created as BasicContainer.

Scenario including Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type":

• Fail.

Why:
Fail is preferable due to the mismatch between path segment ie. /people/jackson not ending with / and the requested interaction model as BasicContainer, as well as catching potential client mistakes and halting immediately.

Scenario without an LDP interaction model in Link - result depends on #105 but here is what's likely to happen:

• /people/jackson is created as RDFSource or NonRDFSource (depending on Content-Type value)
• /people/ is created as BasicContainer

Why:
Same as Request 1 above as if Link was used.

Request 2

Scenario including Link: <http://www.w3.org/ns/ldp#RDFSource>; rel="type":

• Fail.

Why:
Fail. From Request 1, if /people/jackson exists, /people/jackson/, then /people/jackson/friends, /people/jackson/friends/ and /people/jackson/friends/pat cannot exist.

Request 3

Respond with 404 status code.

Request 4

Respond with 200 status code.

Request 5

#107

---

Aside:
I acknowledge that /people/jackson/friends/pat is just an example but want to note here that is not particularly a good URI design. What may be the difference between /people/jackson/friends/pat and /people/pat?

[jaxoncreed]

What may be the difference between /people/jackson/friends/pat and /people/pat?

I'd say in this hypothetical URI scheme, we're treating URIs as graph indicators and not resources in a tree, so they would both refer to the same thing.

I understand the decision given we decided to go with a tree oriented structure

[csarven]

Specifics are described in #107 . In the spec at this time: 44a0c2d