Specify semantics of resource creation via PUT #40
What does the Solid specification say about
Specifically, if a resource is created via
For example, if a client creates a resource via
The text was updated successfully, but these errors were encountered:
Just to eliminate any ambiguity, by "create resources", we consider all ldp Resources; (Non)RDFSources as well as Containers:
The thing is that LDP doesn't recommend containment triples to be updated through PUT ( https://www.w3.org/TR/ldp/#ldpc-put-mbrprops ):
The reason I'm mentioning is that, if PUT is used, Solid needs to make a decision on whether when a resource is created, it should update the containment triples right there and then, or not. Otherwise, it has to go against the stream (re "SHOULD NOT"). Putting aside the case where the SHOULD NOT recommendation is ignored, PUT without updating containment triples would entail that the created resources won't be discoverable through the container.
Aside: that doesn't imply that created resource is not discoverable through a property other than
It is kind of a one way street. I would suggest that to keep PUT as a MAY (as LDP), but add that server if PUT is used, server MUST update containment triples. Otherwise, containment triples are confined to POST. I'm not sure about any downsides to not updating the containment triples other than the challenge of determining the right container.
I suppose that non-overly LDP-centric clients can still operate in PUT mode without having to rely on POST or POST w/ Slug, if they are authorised and the server is willing any way.
AFAIK, LDP implementations generally do support PUT, however I don't know what they do with regards to managing containment triples.
The fundamental issue is that PUT has no context about where it belongs with regards to containers. Either additional hacking is required (eg URI parsing), default to root container as its container, or the server finds the closest container. I don't think the client should mess around with URIs and assume what the server actually claims the URI to be. (Not to mention being subject to potential differences with URI's HTTP header and/or body).
I find this to be difficult to answer right now because it depends on resolving #35 . Provided that if 1) PUT changes containment triples (as mentioned above) and 2) /foo/bar/ is a container, then yes. If 1) but not 2) (or unknown), I suppose "/ contains /foo/bar/baz"? What I think may be reasonable to expect from clients is that, they identify the container in which they want to PUT a resource into. That eliminates relying on a URI pattern or parsing URI strings. However!!! The server doesn't explicitly know where it should be contained.. other than itself finding the most appropriate spot, possibly checking the URI pattern or throwing it under the root container.
The server should keep the number of operations to minimum with respect to creating new containers. Answering if/how containment is done, this may be easier to answer provided that we know the closest container.
Same as above. Server probably needs to find the closest or most meaningful container and link to the resource from there. However, unpopular opinion but keeping URIs opaque: if /foo/bar is a (Non)RDFSource resource, /foo/bar/baz can be a (Non)RDFSource ie. not caring about it being associated to a filesytem. I realise the obvious advantages to keeping it close to filesystem's directory/file relationship. I'm not strongly opposed to that,.. just sayin'.
More discussion and implementation experience (on different code from different implementers) would be useful here.
Just my initial thoughts (mainly due to 'keeping the server dumb'):
Like LDP, optional (so MAY).
If /foo/bar is already explicitly an ldp:Container then yes, otherwise, no.
Server MUST reject the operation. (Client should explicitly create '/foo/bar' first as an 'ldp:Container'.)
Server MUST reject the operation. (Client should update '/foo/bar' first (via PATCH or PUT) to try and explicitly make it an 'ldp:Container' first.)
That seems like a reasonable policy. I do want to point out, though, that the current behavior (and I believe spec) for both PATCH and POST in Solid is to follow the
(Personally, I vote for the
I like @acoburn's questions from solid/solid-spec#198 (comment) so I'm adding them here for a more comprehensive coverage. The reader may want to contrast the following response with what I said in #40 (comment) but note that the intention of that comment was exploratory.
None. LDP does not recommend updating containment triples via
Assuming that containment triples are desired, then the reason to not do that is same as above ie. "SHOULD NOT". It also goes against URIs Opacity. Moreover, it is at odds with https://tools.ietf.org/html/rfc7231#section-4.3.4 :
Inapplicable. Implementation detail. (
Inapplicable. Note related recommendation https://www.w3.org/TR/ldp/#ldpc-post-createrdf (and if that's adopted for
Inapplicable. Implementation detail.
Can you be more specific? LDP says SHOULD for
Let's support PUT
I am strongly in favor of Solid servers supporting
Addressing the concerns
I see two concerns in the previous comments (both raised by @csarven).
updating containment triples
There is some concern about this requirement from the LDP spec:
However, I will observe that this requirement is in section 5.2, which is addressing HTTP requests to LDPC, not to resources. Also, 5.2.4 explicitly says "this specification imposes the following new requirements for LDPCs.". This means this requirement is referring to a client making a
Yes, indeed, I think we are much closer to this now.
that's also very helpful, and a feature I hadn't thought of.
The LDP spec is intended to be organised for readability. Document sectioning is not strict in the algorithmic sense. There are many cross-references. Basing things on the structure of sections is fine, but I'd take it with a grain of salt. Because even with that line of reasoning, it is evident that LDP doesn't say anything about PUT creating a resource within a particular container. The client doesn't specify which container to PUT a resource in and the server is not told how to determine where it should be contained in, if at all - implementation detail. Compare that with how a client can make a request to create a new resource in a particular container using POST. As it stands, what's clear with LDP's PUT is that, it can create a resource (with no strings attached to a container) and the resource can be updated.
That is one of the reasons why we went around in circles in LDP, RFCs etc to be certain about what it says and doesn't say, what's allowed and not - in several issues - as well as to figure out the affordance of URIs with slashes. The rough consensus around 97, 98 (and certainly elsewhere) indeed helps a lot to clarify what we perceived to be under specified for Solid's needs.
I have been thinking about
In my proposal, I will introduce two concepts, exactness and consistency. Now only informally. By consistency, I mean that a request must be consistent with its data, metadata and URI. This relates to #128 in that if it writes to a
With that, here's my thinking on
Unless you mean MUST NOT, this is covered by SHOULD NOT re-use URI in LDP drawing from AWWW.
re Container Creation: Agree.
re Container Update: Already mentioned #40 (comment) , solid/solid-spec#201 (comment) for different circumstances prior to 69.. So, yes, I agree and glad that we're now in alignment on the intentions ;) If by "PUT not allowed in updating a container" you mean MUST NOT, then I think SHOULD NOT would be preferable as in LDP; primarily for the reason of client staying far clear of containment management. PUT should not appear in Allow header of that resource while it exists.
re RDF and non-RDF resources Creation: Agree.
re RDF and non-RDF resources Update: Agree.
re ACL resources: Agree. We should further review controls.
continued on Container Update:
Recommending against updating containers with PUT means that the homepage case gets past onto POST or PATCH. POST is unclear. PATCH is currently only in SPARQL Update ( #125 ).
If core concern is about avoiding containment, all that needs to be done is checking to see if the RDF graph of the representation contains statement for new containment or altering a containment under server-managed triples, then return 409 and explain why in the message. We don't actually have to prevent PUT updates altogether as it would make it difficult or impossible for some use cases to be realised.
The full sentence (with one added word):
The "re-use" of a URI which is discussed in AWWW and LDP would be using a URI which previously identified one referent to identify a different referent. That is not what would happen if a server took a
That discrepancy notwithstanding, LDP forbids such relocation on a
I'm seeing a LOT of cherry-picking from LDP. (Similar is happening with other external specs, but to a lesser extent.) One sentence (or less) -- which may not even come from a normative section of the LDP spec -- gets taken out of context, and presented as the authority behind a position taken on how Solid should function, while ignoring other parts in the LDP spec which contradict that position.
This is not productive.
Either LDP applies to Solid, in which case it must be taken as a whole, with primary if not exclusive focus on the normative sections of the LDP spec; or LDP does not apply to Solid, in which case, most if not all appeals and references to the LDP spec should be ceased.
Ted, you're absolutely right. I was specifically adding on to the point modifications, changes, reuse..
Yes Ted, I'm aware of that. I didn't contradict that. I think the term "re-use" is fairly clear and I was responding specifically (as I've even quoted) "modify".
I don't think we need to adopt binary decision making with extremes. There are notions in LDP that's thought through and aligned with what we'd like to see in Solid. Some things in LDP are indeed unclear or absurd. We can better understand the gaps and borrow what's useful. We still have to go through that process even if we were to take LDP as a whole.
Just to clarify my thinking with regards to LDP is that we shouldn't have it as a full normative reference, since many of Tim's ideas collide with that, but we should have the ambition to make Solid trivially implementable on LDP. So, we're allowed to cherry-pick :-)
OK. I can go with SHOULD NOT, but I don't see the win in terms of interop, that would mostly be in the case someone figures out something clever around it... And I guess they could. You could have "add-only replacements" and that kind of stuff, so indeed, it can be envisioned valid use cases for it.
Just to add some implementation context....
PUT is supported for Containers in Trellis with the following behavior: first, internally, there is a clear separation between "user-managed" triples and "server-managed" triples; containment triples are "server-managed". So any containment triples that are included in a
where "server-managed" properties are defined as:
And following from that, I see no problems with allowing PUT on Containers, provided that the containment triples are not modified. I will note that PUT operations on Container resources in Trellis cannot in any way modify the LDP containment triples on that target resource.
Great re Trellis 184.108.40.206 implementation.
220.127.116.11 is a more specific constraint on the container than 18.104.22.168 on the resource.
We can look at the effects when taken individually:
22.214.171.124 potentially allows containment to be affected. This criteria alone will introduce the possibility of discovery and data issues without having defined error routes. It also introduces complexity to make sure that there are no conflicting containment statements.
126.96.36.199 prevents clients from attempting to update containment and gives a specific error. This makes sure that the resource doesn't have conflicting statements with respect to the server-managed triples portion.
188.8.131.52 alone on the container doesn't cut it. 184.108.40.206 is useful but the actual implementation can vary, especially when trying to deal with use case like the the homepage. It is possible that an implementation can return 409 as soon as it observes containment triples in the payload. Yet another implementation would only reach the same result by observing the actual resources that may be affected. This second point is what I had in mind when earlier I said:
What that allows is an application to use PUT to update a container as long as there is no conflicting information about containment. If the payload includes containment triples that is a subset of the server-managed triples, the request can succeed.
I'm curious to know if and how does Trellis implement 220.127.116.11.
Thanks, @acoburn , that's interesting!
Yes, I can see that this is consistent with LDP, but my concern goes back to the more Fielding-idea of a representation and the expectation in the RFC that
In my interpretation, by separating server-managed triples and user-managed triples, that is essentially the resource's own semantics, and therefore falls under what shouldn't be
I'm certainly open to relax the constraint on container update. My main idea with that is that it makes it simpler to implement. But perhaps that too doesn't hold.
So, first, do we have rough consensus on all the other operations at this point? Is container update the only item where there is (slight) disagreement?
During test development, I encountered the following NSS behaviour:
First, I update that with a
PUT /test-put-bc/dahut-rs.ttl Content-Type: "text/plain"; Link: <http://www.w3.org/ns/ldp#NonRDFSource>; rel="type"
NSS will create a file
My understanding is that both these operations should result in a
But then, I figured, it could be argued that they are just two different representations of the same resource, and should be allowed, i.e. it is not a change, it just adds another representation.
My intuition says that allowing this would introduce quite some extra complexity, and also is a more radical departure from LDP than we have done before, so it may be hard to implement this on top of a pure LDP server, but I'll bring it up for discussion.