Clarify that slash doesn't entail containement #538
Conversation
|
Thanks for that. Here is the issue #505 . It also raises few other dependent issues. |
| <div class="note" id="slash-and-containment" inlist="" rel="schema:hasPart" resource="slash-and-containment"> | ||
| <h4 property="schema:name"><span>Note</span>: Slash and containement</h4> | ||
| <div datatype="rdf:HTML" property="schema:description"> | ||
| <p>URI Slash Semantic on its own is not sufficient to determine containment. For example <code>/albums/garfield</code> does not entail <code></albums/> ldp:contains </albums/garfield></code></p> |
There was a problem hiding this comment.
The current wording ("URI Slash Semantic on its own is not sufficient to determine containment.") is possibly confusing. After all, within the context of Solid, slash semantics ARE sufficient to determine containment (as of the current spec, which reads in the section on Resource Containment: "There is a 1-1 correspondence between containment triples and relative reference within the path name hierarchy.").
I would therefore insert the following, and possibly also move/copy the note to the Resource Containment section (in fact, it would probably be clearer if the Slash Semantics section was part of Resource Containment altogether, as that is where its impact lies.).
| <p>URI Slash Semantic on its own is not sufficient to determine containment. For example <code>/albums/garfield</code> does not entail <code></albums/> ldp:contains </albums/garfield></code></p> | |
| <p>Outside of the context of Solid, URI Slash Semantic on its own is not sufficient to determine containment. For example, without knowing whether the resource server adheres to Solid, <code>/albums/garfield</code> does not entail <code></albums/> ldp:contains </albums/garfield></code></p> |
There was a problem hiding this comment.
Yes, I'm 👎 on the original wording in this PR, but I think with the suggestion, I'm 👍 , as it is indeed a clarification that could be useful to some.
There was a problem hiding this comment.
I find Wouter's suggestion to be generally a bit more useful here as a note. (I'm pressed on time to look at the exact location where it'd be best to put this in... but can review again after the change goes through, if any).
I'd suggest paraphrasing "outside of the context of Solid" into something more concrete, e.g., whether that's explicitly about the Solid Protocol (including its dependencies) or in particular the Storage space, or something else.
I'd also putting a bit more emphasis / clarification / distinction on the expectations/interpretations (if any) from the identifier vs. what might a representation of it describe it to be.
Pavlik, since you originally proposed, if you're on board with these, and other suggestions, could you like to or have Wouter give it another pass at the note?
|
During the meeting we agreed to continue in #505 and based on resolution create new PR |
The wording most likely can be improved. I aim to clarify that while URI Semantics require contained resources IRI must have a hierarchical path component, having a hierarchical component doesn't mean that the resource is contained. It can only be determined based on
ldp: containsstatements in the container description.closes #505