You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a technical Pod user or service with access to a Pod ...
... I want to search Pod data via a SPARQL query ...
... So that optimum results are retrieved according to specific search patterns, which scale well to large datasets.
Preconditions:
What conditions must be in place or assumed before this use case can begin?
A user has a Pod, and has uploaded data to it. Additionally, sooner or later they may have a connected and authenticated service that they allow to query their data.
Trigger:
What (user or system) event or action initiates this use case?
The user or service wishes to find something in the user's Pod data that they suspect exists. The user has access to a text entry field in their Pod user interface to enter their query using SPARQL syntax. The service has access to a SPARQL endpoint that they can also submit queries to.
Actors:
Describe the primary actor, and any other relevant actors involved in this use case
The Pod user is the primary actor, and there may be a secondary actor that provides a service to which the Pod user has subscribed.
Distinction:
What unique challenges or distinguishing factors (like technical issues, user experience needs, workflow integration, etc.) are associated with this use case?
The user must have technical understanding of how to write SPARQL queries. The user also has a handle on allowing their data to be queried by an external service.
Scenario:
Describe an ideal or happy-case scenario where this use case would play out as intended.
Technical users can search their data quickly and efficiently, retrieving results for both simple and complex queries. This feature is clear and easy to use, both in terms of input and output. Service providers can also interface with Pods to query them in a simple way via a clear API. They understand that users have control over whether or not access is granted, and can anticipate all scenarios.
Alternative case(s):
What alternative flows or variations should the system handle for this use case?
For users without the technical understanding for writing SPARQL queries, this feature should not feature so heavily in the UI that it seems a necessity of Pod use, which could alienate some users. There could, however, be some integrated basic usage information, and/or links to tutorials.
Error scenario:
What unexpected issues or errors might arise, and how should the system handle them?
Queries may not be submitted with proper SPARQL syntax, in which case syntax hints should ideally be provided rather than generic error messages.
Acceptance Criteria:
What conditions or criteria must be met for this use case to be considered successfully handled? What limitations are acceptable?
SPARQL queries can be adequately performed by users and services who wish to use this feature, and, for users that don't, the feature is not overtly present in their Pod UI.
References:
List any relevant resources or examples that could inform this use case, possibly from other domains or solutions.
@Reikyo thank you for submitting this issue. Generally, use cases should not identify specific technical solutions (e.g. SPARQL) but rather focus on the higher level needs from particular personas. For instance, this could be reframed in terms of a user wanting to efficiently discover certain data in a Storage.
SPARQL may be one solution to that use case, but it is not the only solution.
Don't have time to turn this into a specific use-case flow right now, but wanted to add these stats that I just came across on the forum (forum.solidproject.org) as an indication of there being a demand for some form of query interface:
As a technical Pod user or service with access to a Pod ...
... I want to search Pod data via a SPARQL query ...
... So that optimum results are retrieved according to specific search patterns, which scale well to large datasets.
Preconditions:
What conditions must be in place or assumed before this use case can begin?
A user has a Pod, and has uploaded data to it. Additionally, sooner or later they may have a connected and authenticated service that they allow to query their data.
Trigger:
What (user or system) event or action initiates this use case?
The user or service wishes to find something in the user's Pod data that they suspect exists. The user has access to a text entry field in their Pod user interface to enter their query using SPARQL syntax. The service has access to a SPARQL endpoint that they can also submit queries to.
Actors:
Describe the primary actor, and any other relevant actors involved in this use case
The Pod user is the primary actor, and there may be a secondary actor that provides a service to which the Pod user has subscribed.
Distinction:
What unique challenges or distinguishing factors (like technical issues, user experience needs, workflow integration, etc.) are associated with this use case?
The user must have technical understanding of how to write SPARQL queries. The user also has a handle on allowing their data to be queried by an external service.
Scenario:
Describe an ideal or happy-case scenario where this use case would play out as intended.
Technical users can search their data quickly and efficiently, retrieving results for both simple and complex queries. This feature is clear and easy to use, both in terms of input and output. Service providers can also interface with Pods to query them in a simple way via a clear API. They understand that users have control over whether or not access is granted, and can anticipate all scenarios.
Alternative case(s):
What alternative flows or variations should the system handle for this use case?
For users without the technical understanding for writing SPARQL queries, this feature should not feature so heavily in the UI that it seems a necessity of Pod use, which could alienate some users. There could, however, be some integrated basic usage information, and/or links to tutorials.
Error scenario:
What unexpected issues or errors might arise, and how should the system handle them?
Queries may not be submitted with proper SPARQL syntax, in which case syntax hints should ideally be provided rather than generic error messages.
Acceptance Criteria:
What conditions or criteria must be met for this use case to be considered successfully handled? What limitations are acceptable?
SPARQL queries can be adequately performed by users and services who wish to use this feature, and, for users that don't, the feature is not overtly present in their Pod UI.
References:
List any relevant resources or examples that could inform this use case, possibly from other domains or solutions.
The text was updated successfully, but these errors were encountered: