Conversation
There was a problem hiding this comment.
[WebID] has been profiled for the Solid ecosystem in the [Solid WebID Profile]
The suggested addition to the Solid Protocol is already covered by that Solid WebID profile, see https://solid.github.io/webid-profile/#webid-profile-data-model .
Also note, that an agent identified by a WebID does not necessarily have a storage, and is not required to obtain a storage at any point. Whether that is useful depends on the use case: There might be a (software) agent which is identified by a WebID but does not have/own storages itself but writes only to external ones.
In addition, requiring the inclusion of the storage on a WebID top-level breaks existing approaches to hide the storage in extended profiles to only let authorized agents (e.g., clients) discover this protected storage.
I suggest to point to the [Solid WebID Profile] instead of breaking with the orthogonality of specifications employed by the current Solid Protocol.
There was a problem hiding this comment.
PRs above correction class 1 should target ED/protocol.html not TR/protocol.
I believe the proposed change is essentially already covered in https://solidproject.org/ED/protocol#client-rdf-storage .
As for parts that's proposing to define the Solid WebID Profile model in the Solid Protocol, it'd be great to maintain adherence (or some sense of it) to the principle of orthogonal specifications. This is expressed in the introduction, as well as in comments #771 (review) and #772 (review) (which mentions the Solid WebID Profile data model being the best place). If you believe that a Solid WebID Profile (or its extensions) ought to contain at least one pim:storage relation, consider making the proposal against that spec since currently it is set to "zero or more" - based on consensus that some profiles may not wish to use or disclose their storage, but can still participate in the Solid ecosystem. In any case, that discussion can continue elsewhere if you'd like to bring in new information that hasn't been already (adequately) evaluated.
Aside: re "overwhelming practice in implementations" [citation needed], but I won't argue against anecdotal evidence. For instance, and FWIW, the data at https://jeff-zucker.github.io/solid-load-profile/ indicates that ldp:inbox is used more frequently than pim:storage. So, perhaps to "improve interoperability" as argued, profiles should also include one inbox. After all, there is not much "social" or any sense of communication between agents or interactions around documents, if one agent can't notify other things in some shape or form 🤷
|
This is just one of the approaches for discovery, I'm mentioning another one in w3c/lws-protocol#106 (comment) 👎 on having it a MUST |
|
I added it to the agenda of our weekly CG call |
|
The challenge that @langsamu and I were trying to address was reducing the complexity of storage discovery. The primary case we were looking to mitigate is that where a WebID is located within a Solid Pod, and the WebID does not advertise the storage root within the WebID -- requiring clients, like Bashlib, to traverse up the resource heirachy until they discover a container of type This means that there are implementations including the default CSS configuration which continue to not advertise the storage via Given this, would a more appropriate wording to suggest be along the lines of: "If a WebID is contained in a Storage, it is assumed that the WebID is the owner of the Solid Storage. In this case the WebID MUST contain the triple Is https://solidproject.org/ED/protocol#client-rdf-storage making an equivalently strong statement @csarven? If so, then is it then a matter of getting that statement into TR and raising it with the CSS team? |
|
Solid Protocol does not particularly single out the types of resources a #storage may contain. This is one of the reasons for why the requirement only describes how a #Client can discover a resource's storage or the storage of which the resource may be a part. When a client encounters a WebID, it is not necessarily stored in a Solid Protocol-based storage. When a WebID Profile does not mention its storage location, clients are not required to find its storage. The Solid Protocol only explains that if a client wants to try to determine a resource's - in this case the WebID Profile - storage, there is a way to do that. It is not the responsibility of the Solid Protocol to dictate how a WebID Profile should be expressed. The Solid WebID Profile is the appropriate place to define if and how an agent's storage can be discovered. Moreover, if a URI owner chooses to delegate to a server that does not adhere to a given specification, that is a decision outside the scope of any specification to mandate. Since WebID Profiles are not required to indicate a storage (as mentioned above "based on consensus that some profiles may not wish to use or disclose their storage, but can still participate in the Solid ecosystem") I believe there is nothing further to address here. |
Why not to discover it from Storage Description?
based on what @mrkvon days it doesn't work in NSS but it seems like simple nonconformance which can't be fixed by adding another requirement to the spec. |
Following the discussion in solid/specification#772 - this PR requires that WebID's conforming to the Solid WebID profile use `pim:storage` to advertise the storage in which a WebID is contained, if the WebID is contained in Solid Storage. The goal of this is to prevent the majority of client applications from needing to implement discovery of storages using link headers.
Implementors of client libraries and applications often fail to do this (e.g. [1, 2, 3]), so this requirement seemingly creates a footgun for those developers.
In practise, we see servers such as the CSS -- which intentionally exclude the As mentioned, the goal is to discourage/prevent server implementations from unnecessarily excluding that claim -- so as to simplify the implementation of a common class of client applications. The common class of clients in question being those that support the flow "Log in with a WebID" -> use that WebID to discover the user storages for reading/writing.
👍 -- have opened up solid/webid-profile#123 |
|
Solid Protocol's Privacy Considerations section advises the following about WebID Profile Privacy:
|
|
If the goal is interoperability, I do not see how a storage statement is sufficient. If my WebID doc is on a non-Solid server and it points to a storage on a Solid server, how does an app go from there to discovery? The root of the storage will indicate the owner which points back to the WebID document. There is no required pointer from the storage root to anywhere else in the storage so the only option for discovery is laborious walking the tree. What there should be instead is a requirement that there be at least one rdfs:seeAlso or foaf:primaryTopicOf link in the WebID doc pointing to a document on a Solid resource server. That would provide a reliable path for discovery. |
|
Closing this issue following the discussion in today's CG call |
6 participants
Current section 9.1 mentions WebID as "underpinning component" and "used as the primary identifier" in Solid.
This change adds a requirement for WebID Profiles to be dereferencable 'publicly'.
The Protocol currently enables discovery of the root container from a Solid resource
However there is no defined mechanism for discovering a Solid storage from a WebID.
This change aims to improve interoperability by adding a normative requirement which corresponds to overwhelming practice in implementations of WebID in the ecosystem.