[UC] Projection- / View-based filesystem-like storage and access

[renyuneyun]

As an application developer,
I want to be able to access (read and write) user's Pod in a different (filesystem-like but) projected structure (i.e. a "view" of it),
So that data interoperation can happen more easily, such that I don't have to follow the same storage structure as other Apps.

Preconditions:

What conditions must be in place or assumed before this use case can begin?

User has a Pod, and uses multiple Apps reading/writing to the same (or partially shared) data in their Pod.

Trigger:

What (user or system) event or action initiates this use case?

An App accesses user's Pod and reads / writes data.

Actors:

Describe the primary actor, and any other relevant actors involved in this use case

• Pod: the LWS storage
• App: the application interacting with the Pod
• App2 (inactive): another application that also interacted with the Pod

Distinction:

What unique challenges or distinguishing factors (like technical issues, user experience needs, workflow integration, etc.) are associated with this use case?

Compared to #97, the key difference is that the App wants a different view of the Pod content, rather than the original (if that exists) structure of containers and resources in it. Different permissions may also be considered for this if relevant.

Compared to #98, the key difference is that the Pod content is still presented as a filesystem-like structure, rather than a knowledge graph.

Scenario:

Describe an ideal or happy-case scenario where this use case would play out as intended.

App and App2 are both movie library applications. The user first used App2 which stored movie collection by the year of the movies. However, App stores movie collection by user's rating of them. Ideally, App can request the Pod to automatically project / create a view of the data stored by App2, to restructure by the user's rating rather than the year of the movie, and read/write to the data directly. Thus, App and App2 can work happily together.

Alternative case(s):

What alternative flows or variations should the system handle for this use case?

• Apart from "structure", vocabulary is also a consideration point for RDF resources (and file types for other resources).
• There may be different ways how the "view creation" is performed.
• Other than resources / files, views may also be based on the resource content, and custom filter (e.g. App2 being an addressbook app, while App being an messaging app).
• Not just for developers, the Pod owner or data manager may also wish to see things in their Pods differently.
• This also relates to data discovery, as a projection/view usually indicates either a different location of some resources/nodes, or different types (as for Type Index)

Error scenario:

What unexpected issues or errors might arise, and how should the system handle them?

View may fail to create, due to different reasons (original content doesn't exist; view-creation code is wrong; no system capacity), each handled accordingly (usually rejecting request).

Acceptance Criteria:

What conditions or criteria must be met for this use case to be considered successfully handled? What limitations are acceptable?

App can read/write contents in Pods in a structure more acceptable for them, rather than a structure used by other applications. That is, developers don't have to agree on a single best data structure, but can work differently first (and in fact, sometimes they may never reach a consensus as each has their own pros and cons).

References:

List any relevant resources or examples that could inform this use case, possibly from other domains or solutions.

• This is relevant to the View in relational database
• Two movie library Solid Apps with different underlying vocabular and structure (and different features, e.g. recommendation): SolidFlix and Media Kraken
• projfs: a projection-based filesystem, which illustrates a very simple and naive case on why file type projection may be useful