Support view / edit of data package metadata

[JDziurlaj]

Right now, the sidebars for datapackage metadata (i.e. Table, Provenance, Package) display content as form fields, making editing very simple. However, if the metadata is being used for reference purposes, for example, to ensure entered data meets an already defined schema, then a more static view might be preferable.

Desired Behaviour (for feature requests only)

1. Render sidebars as static content by default
2. Add a edit button that will toggle between the two views

Our goal is to provide the tableschema to the user, and allow them to fill out the data, using the sidebars as a reference.

[ghost]

Hi @JDziurlaj
Not sure I've understood correctly, but is the change to allow for a read-only view vs edit view? And if so, what's the gain by providing the read-only view?

[JDziurlaj]

I understand this might be an break from the expected workflow for data-curator, but basically we have a tableschema that is fixed (and provided by us), that various producers are expected to provide data in. In this case, we would like to discourage the modification of the tableschema using related functions in the tool, as they will no longer be validating against our format.

[ghost]

HI @JDziurlaj
So this is a tableschema, that isn't frictionless, but a different standard?
Not sure how much capacity is available atm to perform this work, but is it specific behaviours/menu button/clicks that you want disabled? Sorry to keep asking, but the more I can understand, the better chance I have of working out the simplest/quickest way forward if possible - it also means that if there is support for others who want similar behaviour, we can make the changes as generic as possible.
I'm thinking that you don't want function/buttons like:

• Guess Column Properties
• Validate
• And then certain behaviours/messages that you see in 'Table Properties'/Column Properties for example (which I'll be able to determine then what could be turned on/off), or metadata that is added when exporting/importing, through interacting with frictionless' tableschema.js and data-package.js libraries.
  If this more what you're after (feel free to add screenshots, wireframes, images if you think I'm not getting it 😛 )?

[JDziurlaj]

Hi @mattRedBox,

The tableschema in question is just an instance / descriptor of frictionless standard which we have crafted ourselves. It complies with their format and can be validated by the tableschema-js tool. We would want to disallow any modifications to the /resources/schema portion of the datapackage. From what I can tell this would mean:

• Disabling:
  • Guess button / Tools pulldown
  • Insert column before
  • Insert column after
  • Remove column(s)
• Make column sidebar read only

This mode could be toggled by adding a menu item called "lock columns" or something similar. Validation is a key function we want, so that shouldn't be disabled.

Here is the workflow we are trying to support:

1. Jurisdiction collects data from local system, assembles it into a CSV.
2. Jurisidction opens data-curator.
3. Jurisdiction opens the CSV. They are prompted to select an existing tableschema to validate against.
4. Jurisdiction can Validate their file against the tableschema, make corrections in the data-curator interface.
5. Jurisdiction publishes validated datapackage.

I've developed an extension to datacurator to handle (3). This workflow is very similar to what XML validation tools provide, where a user can validate against a XML Schema (XSD). In this case we are just extending this scenario to support tabular data.

[ghost]

Hi @JDziurlaj
Ok, sounds simpler than I first thought - thanks for clarifying.
In your point: 'Make column sidebar read only', do you mean just the 'Column Properties', or all of the Side navigation flyout panels (both LHS and RHS)? This is the one that might take a bit of time (just with juggling other commitments), but still doable I think.

[JDziurlaj]

Hi @mattRedBox,

I was referring to the sidebar (RHS) that comes out when the Column icon is clicked.

[ghost]

OK so just the Column Properties then (not Table, Package and others).

[Stephen-Gates]

I really like this idea and I think @JDziurlaj has nailed the spec.

For clarification...

Add Import Column Properties to the File menu that allows a table schema JSON file to be opened from a URL or local file.

Add a Lock Column Properties checked menu item in Tools that is set per Data Tab to enable:

• the Column Properties to be edited/read only
• menu and toolbar items dis/enabled.

On selecting Import Column Properties:

• check the Lock Column Properties menu item
• fill the Column Properties from the JSON file and make them read only
• Disable the menu and toolbar items

My question is what happens when the number of columns in the CSV and Table Schema are not equal? We may need some extra validation because at the moment these can't be different.

[ghost]

Hi @markwheels
The summary by @Stephen-Gates, if this is the way it is to work, involves more than just making columns/menus read-only. I'll split out the import column properties, validation to another issue. That will bring the estimate for this down (I'll adjust this estimate once I've moved this other work out to another issue).
So moving forward, will just keep the disabled/locked part of this work in this ticket.

[Stephen-Gates]

@mattRedBox Oversight on my part! If you want to lock the Table Schema then Primary and Foreign Keys and Missing Values in Table Properties also need to be made readonly