Generic query-based data viewer

[pheyvaer]

Pitch

When developing apps and adding/removing/editing data in pods, it is useful to be able to easily view what data is actually in your pods. At the moment, there is no generic app that easily allows users to execute queries over multiple pods and inspect the corresponding results.

Desired solution

The desired solution is a Web app with the following features:

• Before using the app, a developer defines via a config file the queries that should be used by the app. This includes
  • The query itself
  • A name for the query
  • A description of the query
  • The data sources over which the query has to be executed
  • A unique id for the query
• Users can log in with their WebID or identity provider.
• Users select the query based on their name from the sidebar.
• The app shows the results of the query in a table.
  • If a variable is a link to an image and the variable ends with _img then the app shows the actual images.
  • If a variable is a float and the variable ends with _float, the app shows the values as floats.
• Users can refresh the results of a query via a button.

Below you see a mock-up of how the Web app could look like:

You find the source of the image here.

Acceptance criteria

The solution needs to support the following flow:

1. The developer defines 2 queries: one that uses public resources in pods and one that uses private resources in pods.
2. The user opens the app.
3. The user selects the query with the public resources.
4. The app shows the results.
5. The user selects the query with the private resources,
6. The app doesn't show the results, because the user is not yet logged in.
7. The user logs in.
8. The user refreshes the results of the query with the private resources.
9. The app shows the results.

Pointers

• Comunica
• solid-client-authn-browser library to authenticate in a browser
• Grid.js for tables
• http://query.linkeddatafragments.org/ is useful, but it doesn't fit the scope:
  • It doesn't show the results in a table.
  • It's too complex for lay people.

[bjdmeest]

I would (but that's splitting hairs) not go for a dropdown of queries, but a left sidebar with (hierarchical) menu items, so that it's more familiar for people using dashboards, eg this example

[bjdmeest]

And considering visualizations of the results, I'd go for a similar approach as Yasgui, ie, use response variable names to hint at specific visualizations (where the first focus point is just strings, floats, and images, so that if your query variable ends with _img (eg ?favicon_img), you'll render the image)

[bjdmeest]

right now the acceptance critera 1/2 seems as if it's all the same user, I'd go for a 'app developer' and 'user'. The configuration of the web app can, e.g. happen via a JSON file that may or may not require the app to be rebuilt before deployment (that doesn't need a Web UI).

[pheyvaer]

@bjdmeest I made the requested changes. Is it ok now?

[bjdmeest]

@pheyvaer good for me!

[pheyvaer]

We will put the code of this challenge in this repo.

[github-actions[bot]]

Please provide a status update about this challenge. Every ongoing challenge needs at least one status update every 2 weeks. Thanks!

[pheyvaer]

We are making good progress with our first version.

[github-actions[bot]]

Please provide a status update about this challenge. Every ongoing challenge needs at least one status update every 2 weeks. Thanks!

[pheyvaer]

The first version should be finished next week.

[pheyvaer]

You find the result here. I still have to provide all the required information to request completion approval.

[pheyvaer]

@bjdmeest Everything for this challenge is done. I included all requirements for completion directly in the corresponding PR #122 for the report. Can you have a look at that? Thanks!

[github-actions[bot]]

Please provide a status update about this challenge. Every ongoing challenge needs at least one status update every 2 weeks. Thanks!

[pheyvaer]

You find the report here.