Clarifications around containers and roots

[kaefer3000]

Please clarify the terms storage system and root, as encountered in 7.1 Container Model, where there is the following sentence (introduced in #81 - which has already been merged, thus I open this issue):

The storage system's root is designated as a container, serving as the apex organizational unit devoid of a superior parent.

Link to the source code:

lws-protocol/lws10-core/logicalresourceorganization.md

Lines 6 to 7 in ebac8fb

	beyond metadata or enumerations of its members; its principal role is to aggregate and structure subordinate resources. The storage system's root is designated as a container, serving
	as the apex organizational unit devoid of a superior parent. Containers MUST support pagination for membership listings using 'ContainerPage' types, with properties such as 'first',

I am confused by the term storage system, as we are defining a protocol, where the implementing systems should be irrelevant.

• Is the storage system the file system where the resource representations are physically located?

Once we clarified what the storage system is, what is its root?

• Is the root per-implementing-system, i.e. on Windows, that would be \ with all its ambiguities (C:\ D:\ ...)?
• Is the root per-user and refers to the URI path / (as in https://user1234.solidcommunity.net/ )
• Is the root just some URI per-user that is defined as the user's root container?

This is a side-issue but could be addressed in the remaining draft PR for containers #83 .

If we already discussing this sentence maybe a native speaker like @TallTed can suggest a more accessible version of "apex organizational unit devoid of a superior parent".

Discussion moved from #113 (comment)

[acoburn]

Thanks, @kaefer3000, this is definitely something the group needs to address.

There are several related entities that need to be clearly described in our terminology section. We also need to define the relationship between these entities.

• Storage -- this is the central concept for LWS
• Storage Identifier -- this is a globally unique identifier for a Storage
• Storage Description Resource -- this is a resource that describes a Storage (i.e., the subject of the resource is the Storage)
• Storage Workspace -- This is not currently defined in the draft spec, but we hint at it with words such as "root".

I am not wedded to the terms "workspace" or "root", but I'll use "workspace" as a placeholder here.

I imagine that a Workspace would act like an LWS Container but its defining characteristic would be that it is not a member of any other LWS Container. Having a distinct term may help distinguish this entity from a normal Container.

I would expect that the description resource would include links to one or more Workspaces. I have heard some WG members express the desire to have multiple, distinct Workspaces within a single Storage.

Concretely, this could be represented like so in a Storage Description Resource:

{
  "@context": "https://www.w3.org/ns/lws/v1",
  "id": "https://storage.example/",
  "type": "Storage",
  "workspace": [
    "https://storage.example/ws1/"
  ],
  "service": [{
    "type": "StorageDescription",
    "serviceEndpoint": "https://storage.example/description"
  }]
}

Another potential way to model this would be to treat workspaces like discrete services:

{
  "@context": "https://www.w3.org/ns/lws/v1",
  "id": "https://storage.example/",
  "type": "Storage",
  "service": [{
    "type": "StorageDescription",
    "serviceEndpoint": "https://storage.example/description"
  },{
    "type": "StorageWorkspace",
    "serviceEndpoint": "https://storage.example/ws1/"
  }]
}

In these example, the identifiers for the Storage, Storage Description Resource, and Workspace are all distinct, but that wouldn't need to be the case. For instance, in a typical Solid server today, the Workspace URL would be the same as the Storage URL.

[kaefer3000]

Hi @acoburn ,

thanks for your clarifications. I think it is important to avoid the word "system", which you haven't repeated, so you seem even less wed to it. Yet we may need a similar notion, see below.

an LWS Container but its defining characteristic would be that it is not a member of any other LWS Container. Having a distinct term may help distinguish this entity from a normal Container.

Agreed!

The word root is great, as it gives the right mathematical intuition.

However we need to define the boundaries in which a root container is actually root:

Imagine you run on an origin (origin as in a HTTP URI) a LWS server with a root container. If a LWS server on another origin has a container that links to said root container, then under the boundaries of one origin it is actually root, whereas globally it is not.

However, I doubt that origin is the right abstraction (you may want to run multiple LWS servers on an origin, similarly as you can deploy multiple Java servlets with their own "roots" on an application server, or have code on different routes in Express.js), maybe a term such as realm (as in HTTP authentication) is better.

In these example, the identifiers for the Storage, Storage Description Resource, and Workspace are all distinct, but that wouldn't need to be the case. For instance, in a typical Solid server today, the Workspace URL would be the same as the Storage URL.

...and the description would additionally also be part of the workspace's/storage's resource representation.

Another open question for me is whether the notion of root should be per-user, is there a 1:1 relationship between a user and a workspace or can a user have multiple workspaces, similarly as somebody in Solid could have https://user1234.solidcommunity.net/workspace1 https://user1234.solidcommunity.net/workspace2.

[pchampin]

+1 to remove "storage system" (only one occurrence in the current ED) and replace it with "storage"

Another open question for me is whether the notion of root should be per-user, is there a 1:1 relationship between a user and a workspace or can a user have multiple workspaces, similarly as somebody in Solid could have https://user1234.solidcommunity.net/workspace1 https://user1234.solidcommunity.net/workspace2.

I'm confused by your question, because

• the two "workspaces" that you cite above are not, in Solid parlance, "root containers"
• my understanding of LWS "root" was that it was align with Solid's
  (with the difference that LWS does not conflate storage and root, while Solid does)
• my understanding was that "workspace" was, in this thread, used as a synonym for "root"

[kaefer3000]

I read up on storages and roots in Solid, thanks @pchampin for reminding me that they have definitions for that.

What cleaned up my confusion was that a Solid Server can have multiple Solid Storages (i.e. Solid Roots).

My intuition when reading "the storage system's root" was there is a computer system (possibly running one instance of Solid server software) with a 1:1 cardinality to a root, as if we were talking about / on a Linux system (that provides the file system backing Solid Pods). Another intuition was that root is the relative URI / on some web server. Both intuitions went wrong, obviously.

I found that LWS also has definitions, e.g. for root, but those (except for container) are not linked in the mentioned paragraph. Maybe that would have helped. Later in the section that contains the mentioned paragraph, the definition of root from the terminology section is repeated and extended, but also not linked.

Thus, I recommend to re-work the wording, streamline the section, and link the definitions.

[gibsonf1]

I think the Storage representation should also act as a container (the root container for the storage) which would then contain one or more root containers. Ideally a GET etc on the Storage URI should behave like any container/data resource as well. Storing data at the top level Storage URI should be identical to storing in any container.

This also simplifies permissions by enabling permissions at the top Storage URI that could allow access to everything in that Storage, all root containers/data resources at top level, etc.