Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Schema editor based on the actual fields #10

Open
4 tasks
amercader opened this issue Jul 6, 2017 · 0 comments
Open
4 tasks

Schema editor based on the actual fields #10

amercader opened this issue Jul 6, 2017 · 0 comments

Comments

@amercader
Copy link
Member

amercader commented Jul 6, 2017

Description

Providing an existing schema that has been created elsewhere, probably by hand, is a great feature but one that will be probably only used by power users or data-savvy publishers that are familiar with validation, standards, etc.

To really engage publishers in the description of their data we need to guide the creation of these schemas based on the actual contents of the file, what people is familiar with.

In a nutshell, when uploading or linking to a new file, the user gets a list of the existing fields, with an option to define the type of that field (a guessed one is provided for them). Additionally they can provide extra information about the field like user-friendly labels or a description.

This gets transformed into a Table Schema internally that gets stored in the schema field.

This pattern is well established (see eg Socrata), the challenge is how to integrate it in the existing workflow in CKAN for creating a dataset.

Obviously we need to read the file somehow to infer the fields and types. There are two options:

  1. Read the file in the browser using tableschema-js and infer a schema that would be used to generate the edit interface. This tool shows how the general interaction would be (and perhaps we can reuse part of it): https://csv-schema.surge.sh/. We would need to consider browser support for this.

  2. Rework the resource form to have a two step process, with a dedicated endpoint to upload the file first and read its contents. This has the benefit that it will be probably be required anyway for the next version of the synchronous validation (TODO ref) but obviously it means more clicks

Tasks

  • Integrate schema editor in current resource form
  • Infer field names and types. See above for options
  • Design schema editor component. Basic requirements: definite title, description and type of fields (TODO: prior work?)
  • Implement schema editor component functionality. Based on the inputs above, create a Table Schema JSON object that gets stored in the schema form field.

Estimate

7 days

@amercader amercader modified the milestone: Current Jul 6, 2017
@amercader amercader modified the milestones: Backlog, Current Sep 4, 2017
@amercader amercader mentioned this issue Oct 3, 2017
3 tasks
@roll roll removed this from the Backlog milestone Jun 11, 2019
JVickery-TBS pushed a commit to JVickery-TBS/ckanext-validation that referenced this issue Jul 23, 2024
KatiRG pushed a commit to KatiRG/ckanext-validation that referenced this issue Dec 6, 2024
Skip default type-error at Step 1 of validation workflow
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants