solid / solid/data-interoperability-panel

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

Open
#294 9 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Bikeshed
Stars
58
Forks
18
PR merge metrics
No merged PRs in 30d

Description

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

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the issue's Shape Tree Descriptions link and the repository's specification material. Clarify how data registries owned by the user and by sharing social agents should be identified, especially for ACME's regional storages. Done requires an agreed presentation and labeling specification for the described access scenario.

Written by the indexing model from the issue text.

Assessment

Domain
design
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.