[UC] Server / Storage Description

[csarven]

Server and/or storage "description" (in its general sense) encompasses a category of use cases. I originally raised this issue in solid/specification#355, where I provided several specific examples. I've adapted and extended the examples:

Use cases:

• Guinan as advisor wants to read the description of the storage and understand its purpose.
• Janeway as captain wants to find the server's policies to review and update its data privacy and resource persistence for the ship's long-term missions.
• Uhura as communications officer wants to review the storage system's data sharing capabilities to consider adjustments for more efficient, secure, or timely communication.
• Kira as operations officer wants to determine a suitable location to store tactical data from the server's available storages.
• Picard as commanding officer wants to find the server's contact information to arrange a diplomatic meeting with an ally to discuss an urgent matter.
• Torres as engineer wants to access URI templates to ensure consistent resource naming across her engineering tools.
• Ro as system architect wants to advertise the availability of a proxy service and update its location so that authorized actors can use it for seamless access to resources while masking their identity or network location.
• T'Pol as science officer wants to review the storage's usage permissions and constraints to ensure the scientific data complies with ethical sharing and usage policies.
• Kes as medical assistant needs to export crew medical datasets from the server for offline analysis in emergencies.
• T'Lor as system administrator wants to monitor usage patterns, detect unauthorized access, and investigate anomalies in the storage system.
• T'Pel as compliance officer wants to review the storage system's audit trails to verify that access and modifications comply with organisational policies.
• Crusher as medical officer needs to review the medical data retention policies to ensure they align with health data regulations and the privacy requirements of the crew.
• Seven of Nine as data scientist wants to assess the quality and suitability of the astrometric datasets to ensure they meet the precision requirements for mapping and star navigation purposes.
• Dax as architect wants to check the compatibility of the storage's data policies with her preferred policies for architectural standards before committing structural data and blueprints to this storage.

---

Preconditions:

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

• Actors can choose to identify themselves with the authoring tool by using their personal online identities.
• Storage and hosting are set up.
• Extended description about server's capabilities or the available storages' descriptions can be discovered through follow-your-nose exploration methods.
• Some actors may be authorized to read or write certain aspects of the storage description.

Trigger:

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

When actors generally needs to assess the storage system's description to ensure compatibility with their requirements, which may prompt the need for updates. This could be initiated by a need to verify policies, available resources, or alignment with existing standards before committing data or actions to the storage.

Actors:

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

• Primary Actors: any individual needing to interact with the storage at a high-level.
• Secondary Actors: any user agent, user agent add-on, assistive technology, or web application, e.g., authoring tool (see [UC] Authoring Tool for Collaborative Web Content Creation #7 ) that communicates or negotiates with the storage on behalf of the individual to fulfill their needs.

Distinction:

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

• The storage description may vary in some areas, but key consistent elements are essential for interoperability checks.
• User experience challenges in interpreting and interacting with storage descriptions across diverse tools.
• Need for seamless integration with existing workflows, policies, and regulatory requirements.

Scenario:

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

An individual or system reviewing the storage description to assess its alignment with specific requirements, policies, or standards. This enables them to determine the storage's suitability and potentially initiate updates if necessary to ensure compatibility and meet the intended use case.

Alternative case(s):

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

• If the storage description is incomplete or lacks critical information, the system should allow actors to request additional details or clarification from the storage provider.

Error scenario:

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

• If there is a failure to retrieve the storage description or if it’s incompatible with the actor's tools, the system should provide an error message with clear instructions on how to proceed, e.g., contacting support or retrying.
• If the compatibility check fails due to missing or inconsistent data, the system should prompt the actor to recheck the data or provide an option to report an issue to the system administrator.

See also #34

Acceptance Criteria:

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

• The storage description is efficiently discoverable without prior knowledge of the storage or its description location.
• The storage description is available in a format that is either human- or machine-readable.
• The storage description may be read or modified by different actors.
• Clear options are available for resolving conflicts or discrepancies if an update is needed.

References:

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

• https://dokie.li/media/video/dokieli-odrl-storage-description.webm
• https://w3id.org/dpv/
• https://www.w3.org/2001/tag/doc/selfDescribingDocuments
• https://www.w3.org/TR/dwbp-ucr/
• https://www.w3.org/TR/dwbp/
• https://www.w3.org/TR/odrl-model/
• https://www.w3.org/TR/powder-dr/
• https://www.w3.org/TR/powder-use-cases/
• https://www.w3.org/TR/sparql11-service-description/

[bumblefudge]

Picard wants to find the server's contact information to request a diplomatic meeting about security audits.

i feel like there's a CVE user-story hiding in here 😄

[bumblefudge]

Torres wants her devices to use server's URI templates when naming particular kinds of resources.

Would some kind of templating language (even of optional/opt-in) be in-scope here? I feel like the group needs to decide (separately?) if this could be in-scope or if the timeline inclines the group to establish an "extension point" and comes back to it in later iterations...

[hzbarcea]

Torres wants her devices to use server's URI templates when naming particular kinds of resources.

Would some kind of templating language (even of optional/opt-in) be in-scope here? I feel like the group needs to decide (separately?) if this could be in-scope or if the timeline inclines the group to establish an "extension point" and comes back to it in later iterations...

I assume that @csarven 's intent was not necessarily to include such a feature in the spec, but to not define a spec that would make such feature(s) impossible. He'll correct me if I got it wrong.

[edit] maybe I am wrong, at least in part.

[csarven]

Right, I mean that URI template as an example, and can be among many things that could be potentially described in a storage description. No doubt it is generally wide open as to what could be described. It's also clear that all of this could be split into separate use cases, but for now, they all fit under the broader case of describing something about the storage. This is because the notion of storage is fundamental: what it can do, what it represents, and so on. I'll update the use case description with more detail.

[elf-pavlik]

IMO all those use cases need more specific context. In collaborative environments, there can be dozens of servers, dozens of apps, and dozens of other parties involved. Whenever a server is mentioned, it should be clear how it relates to the actor. If the actor isn't a developer, there is a good chance they will not know much about underlying infrastructure; instead, casual actors would see things as pod provided by ACME, etc. Some of the one-liners heavily suggest that the actor is a developer and not a casual user. I think it would be better to make it explicit.

[csarven]

On the contrary, all of this is ultimately for the "user". The "developer" seeks to discover and present information within an interface, in the appropriate context. Once again, the examples I listed are grounded in incubated work. The user is never expected to discover, fetch, or process storage information on their own. Thus, nothing heavy is being suggested here beyond the obvious:

• there is storage description that's potentially discoverable and readable
• the storage description provides useful information - whatever is deemed to be useful by its owners / controllers (see also Self-describing Documents)

Let me know if you'd like me to create a use case along the lines of:

"Describe Resources" that is human and machine-readable.

since based on your reasoning, anything short of human-readable will be for the developer as opposed to the user, so we'll have to make sure that will be applied consistently.

[elf-pavlik]

On the contrary, all of this is ultimately for the "user".
...
Torres wants her devices to use server's URI templates when naming particular kinds of resources.

I can't imagine talking to any of my neighbors or to someone I meet at the farmer's market and hearing them say word URI templates.
In the rural area where I live, I hear people constantly complaining about places without mobile data service. For example, Pepe might want to be able to add new ideas to their ideation app and relate them to other existing ideas while they are offline. Or Beto wants to edit their shopping list while at the farmer's market without internet connection.

LWS could decide to meet those needs by using URI templates. Still, Pepe and Beto should never have to understand that such a thing exists. Just as I don't need to know which time of the year to plant zucchini or how to prescribe lenses for myopia.

[csarven]

Reductio ad absurdum.

---

Once again, I copied the examples for a category and marked my comment as a draft intentionally. The broader context is about storage descriptions (or something similar) in all cases.

Even if Torres were portrayed as a "developer" in the draft example, that role is not mutually exclusive with others, such as a "casual user" (see also cyborgs). Additional parallels include dogfooding, eating one's own cooking, self-publishing, etc.

What seems evident is that the concept of a storage description holds value for a variety of actors. Recognising this only strengthens the proposal.

Even if the specific draft example involving Torres were omitted, it would not diminish the larger picture - the idea that some details about a storage system remain universally useful.

That said, I went ahead and revised the content, added more example use cases, and expanded the remaining details. While some specific use cases might warrant their own separate exploration, this potential does not preclude their inclusion as part of the general use case here.

[w3cbot]

This was discussed during the #lws meeting on 13 January 2025.

View the transcript

Storage Description

<gb> Issue 21 [UC] Server / Storage Description (by csarven) [triage] [usecase]

acoburn: I agree. It may not be the best one to use now. Maybe alternatively try #21
… csarven, maybe you do it as it's from you?

csarven: Data management, maybe? I think Hadrian made a good point to focus on the core one(s). So, data management and data discovery.

acoburn: Any further topics? Nope

---