So my perspective on this has changed a bit in the latest iteration, which I have not properly blogged / documented.
At the time of writing, PD plan had member lists associated with spaces. Roles naturally require member lists so the idea of re-using the member-list of spaces so store role data was the natural fit. So it was multiple semantic usages on top of the same technical affordance.
Anyway, now that is all moot because spaces no longer have membership lists in them. On that point:
I think this is slightly inaccurate since the PD proposal doesn’t have a membership list concept at the space level anymore. Either you are able to get a credential to the space or not, regardless of any possibly existing member list.
Also PD does define the permissioned repos as the the physical stores of data that are logically placed in the space.
On that point, I think this quote of the collab doc somewhat misrepresents spaces. I think spaces really are containers from many perspectives. Maybe you would call them “logical” containers and not “physical” containers, because they don’t literally store the actual data records. But I would call them a container in a similar way that a parcel of land could be considered a “space” that is carved out by law and not by walls.
Now obviously we can create abstract concepts on computers that don’t have perfect physical analogies, but I would argue that the people using the apps built on spaces are very much going to think of spaces as containers. A channel in Roomy is going to map directly to a permissioned space, and people will see it as a container for chat messages.
Even though the real data is spread out across different PDSes, It doesn’t seem categorically wrong to consider the space as having “encompassed” them logically.
All that said, I agree with this point here. It does make it conceptually somewhat difficult that spaces don’t necessarily even say which repos are a part of them.
The space acts kind of like a guard handing out keys. The guard is the only one allowed to hand out keys for his space, but he doesn’t actually guard the door. Instead, anybody in the world is allowed to make a door that can be unlocked by the any of that guard’s keys.
The data lies behind those doors. Some apps may use the key but only unlock some of the doors, and therefore only have some of the data. Apps may not even have a way of knowing which doors there are to unlock!
Even stranger, people who aren’t even allowed to get a key can make a door that is unlocked by the key!
Anyway, I don’t mind the “space” terminology. The more abstract impression of “realm” or “zone” might feel a little better, but I don’t know that there’s a word that we can use that clearly captures the strangely non-physical combination of affordances granted by permissioned spaces.
Because it’s kind of tricky no matter what, I don’t don’t really have anything against any of the suggestions so far.