Ability to Share a specific datapoint (node+any children) and its sourcefile, path, data etc

[alexbfree]

(excuse the brevity, adding tickets in a rush. Contact Alex or Paul for more details)

button always present on every node

to allow us to learn and collect in context examples.

also with ability to add comment (to build up a knowledgebase)

[pdehaye]

This issue requires extensive design before any implementation.

It is about enabling the sharing of feedback (as raw data or more reworked information) with some complex combination of downstream beneficiaries.

There are multiple types of feedback flows we want to enable:

• sharing information that is meaningful from a tooling standpoint: "hey, this is a date", "here is a bug"
• sharing information that is meaningful from a paedagogical standpoint: "here is some data that I find interesting/puzzling", "here is some data that others might find interesting" "here is an investigative lead" "here is how it should be visualized"

[pdehaye]

@alexbfree any others?

[alexbfree]

I think the above is now covered by our work in the consent form, and this ticket can be considered as a purely technical feature, regardless of purpose. @pdehaye do you agree?

[pdehaye]

If what you are suggesting @alexbfree is to decouple upstream data preparation to consent for downstream purposes, I agree. Since the consenting mechanism is getting worked on separately, we can re-focus this ticket on data preparation (where? what?)

[valentinoli]

Possible duplicate of https://github.com/hestiaAI/data-pipelines/issues/27 ?

[ffsinger]

It's not a duplicate, the issue you mention is about sharing to social media, and the issue here is about sharing via forms

[valentinoli]

Ah, ok.

[alexbfree]

This partially depends upon hestiaAI/hestialabs-experiences#265 but that should not be considered a blocker for this ticket

[alexbfree]

Let's move this up to priority 1.5 :-)

[alexbfree]

@ffsinger is there anything that is worth starting on the consent form side of this while @andreaskundig pursues the accessor side of this? Or is this blocked until accessors are available?

[ffsinger]

I think it's hard to start this without the accessors, but maybe @andreaskundig has an idea

[andreaskundig]

I think you can get started on that with accessors.

The accessors I'm writing are just objects with the attributes filePath, jsonPath and jsonSchema (the last two are optional). Here we only need the first two to specify what we want to export. (jsonSchema could actually be useful if we want to allow the user to choose what attributes of an object to export)

{ filePath: '...', jsonPath: '...' } 

The json viewer should know the jsonPath address of each of its nodes. We also need this feature for #113. We need to add a checkbox on each node's ui. Just as the file explorer produces a list of file names, the json viewer would produce a list of accessors. The accessors could then be used at export to extract the chosen nodes from the file-manager (I'm working on that).

[ffsinger]

There are still unclear details for implementing this issue:

• if you select one node, all children should probably be automatically selected. What happens then when you unselect and reselect some of the children ? Are they considered as separate datapoints ? Do they have their own accessor, or do we specify exclusions in the parent accessor ?
• in the filtered exported file, do we give a list of nodes without links between them, or should we keep the structure of the parents (if we export node b from a file containing a->b->c, do we write a->b->c where a is stripped of all info, instead of just writing b->c without context ? On import, this would let us explore a filtered file in the same way as the original. Or should we just include and show the accessors as context, since they contain the filename and path ?)
• the file explorer is splitting lists into multiple slices, but it doesn't make much sense to make them individually selectable. In other words, there is a structural difference between the actual data and how we present it.

I will start implementing this simple prototype:

• one checkbox for each node in the file explorer
• when selecting a node, all children are automatically included, and their corresponding checkbox is disabled (= not unselectable). Similarly, when the whole file checkbox is selected, all checkboxes of the nodes are selected and disabled.
• export as a list of nodes without context, but write this into a file of the same name as the source data
• in the summary, say "x files and y individual objects selected", where x=sum("the file is selected") and y=sum("a node is selected in an unselected file")
• checkboxes are disabled for list slices (if we have "list of 20 items"->["elements 1 to 10", "elements 11 to 20"], only "list of 20 items" is selectable)

[alexbfree]

In light of some of the new tickets, I am dropping this to priority 3.

[ffsinger]

It seems that the UX I was planning to implement (putting the node selection as part of the file selection dialog, for a finer-grained sharing) is not what you have in mind . So should it be part of the file explorer experience, or as a separate dialog (where?) ?