[UX] Presenting multiple data registries to the user (mostly label)

[elf-pavlik]

I marked it as UX since minor lacks in specification affect it.

Short recap of current state:

• each user can have multiple storages
• each storage can have multiple data registries (should we reconsider?)
• each data registry can have only one data registration for a given shape tree

We can use Shape Tree Descriptions to present the data registration.
What we lack is presenting the data registry, all owned the end user and all owned by each social agent who shares data with the end-user.

Having one data registry per storage can help, since presenting storage would be sufficient to identify the data registry.
There is also the case of data registries owned by other social agents, we need to make sure that user which received access to some data in them can have those registries labeled e.g.

• ACME has regional storages
• ACME shares project with Alice from NA and EU storage (data registry), it includes permission to create new project
• Alice wants to create new project specifically in NA storage

[woutermont]

As indicated in the meeting, I think the most elegant solution would be to just add a label (rdfs:label) to the Data Registry, and always only present Data Registries (not Storages) to the End-User. Storage providers can then decide themselves whether their Users can create new Storages, whether they can create new Data Registrations, and how many Data Registrations can be created per Storage.

(Data Registries might have to link to the Storage on which they are held, in order for Applications to retrieve additional Storage-wide info, such as geographical location, for example.)

[elf-pavlik]

To be honest I would even consider following thought in solid/specification#377 and have a DataRegistry as very specific storage type. In that case DataRegistry would equal Storage.

I still can't imagine how (and why) an average user should need to distinguish between a storage and data registry. Most likely the difference will be nuanced and generally confusing when non geek people try to use the solid ecosystem.

If at some point we need to add in FAQ for regular users

Q: When do I use new solid storage and when new data registry
A: ????

Can we document some reasons for creating multiple data registries in a single solid storage?

[elf-pavlik]

I think the most elegant solution would be to just add a label (rdfs:label) to the Data Registry,

Let's give it a go. I only see issue with propagating this information to Data Grants. Below I describe how it can be done, we should keep in mind that changing that label (which shouldn't happen often) will cause regeneration of all the Data Grants for all the Data Registrations in the Data Registry. As well as any Delegated Data Grants created for those Data Grants.

I'm going to implement following in sai-js

• Data Registry uses rdfs:label set by the owner
• Authorization Agent includes in each data grant two statements from the Data Registry
  • relating Data Registry to the Data Registration which the grant applies to
  • providing label for the Data Registry
• Authorization Agent copies the two statements mentioned above to any Delegated Data Grant

PREFIX interop: <http://www.w3.org/ns/solid/interop#>
PREFIX alice-home: <https://home.alice.example/>

alice-home:2d3d97b4-a26d-434e-afa2-e3bc8e8e2b56
  a interop:DataRegistry ;
  rdfs:label "Home" ;
  interop:hasDataRegistration
    alice-home:f6ccd3a4-45ea-4f98-8a36-98eac92a6720 ,
    alice-home:92f43be4-d12c-4ca3-9bd6-c18e83167b2f .

PREFIX acl: <http://www.w3.org/ns/auth/acl#>
PREFIX interop: <http://www.w3.org/ns/solid/interop#>
PREFIX solidtrees: <https://solidshapes.example/trees/>
PREFIX alice-auth: <https://auth.alice.example/>
PREFIX alice-home: <https://home.alice.example/>

alice-auth:d738e710-b06e-4ab6-9159-ee0d7d603402
  a interop:DataGrant ;
    interop:dataOwner <https://alice.example/#id> ;
    interop:registeredShapeTree solidtrees:Project ;
    interop:hasDataRegistration alice-home:f6ccd3a4-45ea-4f98-8a36-98eac92a6720 .
    # [...]

# include two statements providing Data Registry label

alice-home:2d3d97b4-a26d-434e-afa2-e3bc8e8e2b56
  rdfs:label "Home" ;
  interop:hasDataRegistration
    alice-home:f6ccd3a4-45ea-4f98-8a36-98eac92a6720  ;

[elf-pavlik]

#295 notes:

Some issues with approach above:

• Label has to be propagated into grants and delegated data grants
  • Trail of changes would be polluted by regen triggered by changing label
• Authorization of access to that label becomes hard to keep track on, especially if any data was made public.

We lean towards having one data registry per storage, Also solid:storageDescription could be a clear place to keep public label for the storage. It will land in solid/specification#492

[woutermont]

Fully agree with the Storage = Data Registry correspondence (and keeping label in Storage Description).

Objecting to treating Data Registry as only one type of Storage (see solid/specification#377 (comment)). What is the scenario for having a Storage without a Data Registry?

[elf-pavlik]

I plan to keep Authorization Registry and Agent Registry in a single storage, with separate storage for each Data Registry. I'm also considering aligning authorization agent implementation with CSS to be able to run them together. In this case, the authorization agent could have local access to storage with Authorization Registry and Agent Registry.

In the case above, any storage with Data Registry would store nothing else besides that single Data Registry.

[woutermont]

Yes, I agree. In the end we are just creating an UMA-like AS with a Solid pod as storage backend.

But my question was rather: why would we want a storage that stores anything outside of a Data Registry? A Data Registry is just an abstraction of what is stored (and can be accessed in certain contexts). Having a Storage without a Data Registry boils down to having storage without an interface to what is stored.

[elf-pavlik]

I don't know if we can assume that the whole Solid ecosystem will use SAI. I think there are people who want to explore other approaches and I think Solid Protocol should allow it. Even if eventually we agree that Data Registries are the best approach, we can only conclude it for today and maybe in 3 years we will have a rough consensus on the superiority of some newer approach.

Given above:

• Non-SAI setups can use Solid Storage with no Data Registry
• SAI setups can have dedicated storage with no Data Registry but only Agent Registry and Authorization Registry
• SAI setups can have storage with nothing but Data Registry (here I think it's worth considering to allow Data Registry to be the Storage itself)

[woutermont]

Not sure I follow you. If a Data Registration is an abstraction of 'which data is in a user's pod' (and how it is organised), it should be able to encompass all kinds of approaches to data/pod organisation.

SAI should remain the Solid interop interface, not an implementation of it. Otherwise things get even more complex, and we need yet another spec to describe the interoperable interface. #spec-ception