search

unitaryfund / metriq-app

Web app for Metriq
https://metriq.info
Apache License 2.0
27 stars 17 forks source link

Top-level topics #411

Closed WrathfulSpatula closed 2 years ago

WrathfulSpatula commented 2 years ago

Create top-level topics for submissions, with UI.

nathanshammah commented 2 years ago

Great.

WrathfulSpatula commented 2 years ago

After discussions with Nathan last week, the demanded feature seems to be for top-level tasks, at least. Since tasks are already hierarchical, we'll update the task index view to show the highest level topics, and users will have the option of clicking to see either the top-level task detail or child tasks, successively. (We'll track progress here in this issue.)

Since task detail views already list child tasks, the actionable content of this issue becomes to restrict the task index view to display only top level tasks. This is trivial. We can also do the same with methods, if we add a method hierarchy.

WrathfulSpatula commented 2 years ago

@nathanshammah @willzeng Do we have particular top level topics in mind, for tasks? Most of the work here seems to be to decide what these top level categories actually are, and to update the database to reflect that decision. (I have a PR up already that restricts the tasks index view to top level categories, but the de facto categories are ad hoc, right now.)

willzeng commented 2 years ago

The topics you had drafted were great! Applications, Compilation, Hardware and Simulators.

Worth keeping in mind in design that we may want to edit, remove, and extend them later.

On Mon, Feb 14, 2022, 3:54 PM Daniel Strano @.***> wrote:

@nathanshammah https://github.com/nathanshammah @willzeng https://github.com/willzeng Do we have particular top level topics in mind, for tasks? Most of the work here seems to be to decide what these top level categories actually are, and to update the database to reflect that decision. (I have a PR up already that restricts the tasks index view to top level categories, but the de facto categories are ad hoc, right now.)

— Reply to this email directly, view it on GitHub https://github.com/unitaryfund/metriq-app/issues/411#issuecomment-1039546579, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHZDATNUJNZ44B2OTGB7WLU3FTW5ANCNFSM5NQH744A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

nathanshammah commented 2 years ago

Looks fine to me, thanks!

nathanshammah commented 2 years ago

By the way, next to tasks, I see use also for top-level categories for Methods to help with a tidier taxonomy #363 and sort out questions like the one here #435. For example, top-level methods could be: "Superconducting-circuit processors">Rigetti80Q,H1, etc. "Neutral-atom processors">"Cs", etc. "Trapped-ion processors">"Yb+","Ca+", etc.

WrathfulSpatula commented 2 years ago

I'm collecting notes on the general topic of taxonomy and data model reorganization here, as we've gathered the related issues and seek to address them this week:

@crazy4pi314 raised the point in the submission party today that our data model seems to put the task of visualization first and work backwards to a schema. While this lets us visualize data easily, it puts a lot of load on the user, and it centers the visualization rather than the domain-specific knowledge in our data model. For example, for the t|ket> submission, hardware architecture becomes a permutation of a child task for a parent circuit definition task. We see almost the same thing happen with Quantum Search on Noisy Intermediate-Scale Devices, where hardware is permuted as sub-tasks, which is counterintuitive to domain experts.

While we might actually permute these out as tasks in our back end and database, it makes more sense, in terms of domain logic, to specify a single task, like the t|ket> circuit to compile. Then, as metadata on the result, the user has the option of selecting one hardware architecture per result, for this same task. Users can move up and down the task hierarchy in the task detail view, to see architecture-specific as well as cross-architecture comparisons, but this is much easier and more intuitive if the work of permuting tasks is done on the demand for metadata association with the result. I'll be adding this as well, this week, at least for choices of hardware architecture, and any other result metadata fields that come up.