Schema file

[timwis]

Following the discussion in pull request #56, which was prompted by issue #34.

This pull request allows the site administrator to add a schema file to the _data/schemas/ directory and activate it by modifying the schema setting in _config.yml.

Dataset display pages have (a) title, (b) organization, and (c) description hard-coded into the layout. These are considered "system fields," which schemas should specify using the system_field property.

Below that, the Resources are rendered. These need to be configurable too - this pull request isn't quite finished because of this.

Following that, the rest of the fields in the schema file are rendered in the order they are listed in the schema file.

Schema files support bracket notation to access deep values (thanks to a clever/hacky "recursive function" if you can call it that).

Datasets have a schema property in them, which allows JKAN to render the display page and form according to the specific dataset (rather than just the site-wide setting).

Thoughts @JJediny?

TODO:

• Incorporate Resources into the schema files
• datasets.json should access the data via system_field
• Ensure javascript doesn't rely on field names (and uses data-hook with system fields instead)

[timwis]

I may have overthought this a bit. This pull request lets you actually change the field names of system fields like title, notes, organization in the dataset yaml files, and the rest of the site still works. That's pretty cool, but I'm not sure that functionality is necessary; if the driver is being able to produce a data.json file, we can just map the fields. An alternative, simpler approach would be to use a core schema that is as flat as possible (the only depth would be the resources). Any interoperability would involve mapping the system fields to whatever name they need to be. This would reduce the complexity of this pull request (including that clever recursive function). Looking forward to feedback.

[JJediny]

Finally getting a chance to review this! I think there is definitely a need to handle mapping from schema to schema so not to have to swap out all the jekyll templates when switching over. Think this is an awesome hack, but I fear the invention of a new recursive syntax with [ ] and the field to field remapping in the _data/schemas/default.yml is not easy to intuit. What if instead of assigning a value from the remapping into the template using logic to find/replace we instead use site_data/schema/default.yml to reassign what variable is to be rendered by jekyll...

Basically using a variable and jekyll's ability to embed a variable within a variable (ex. {{ page.{{ site.data.schema.default.title}} }} to override what attribute/value gets rendered by jekyll without having to change the template itself, ex.

for default in /_data/schema/default.yml:

title: title
notes: notes
maintainer: maintainer
maintainer_email: maintainer_email
organization: organization
category: category
resources: resources
  - url: url
    name: name
    format: format
    description: description

for data.json v1.1 schema /_data/schema/default.yml:

title: title
notes: description
maintainer: contactPoint.fn
maintainer_email: contactPoint.hasEmail
organization: publisher.name
category: theme
resources: distribution
  - url: downloadURL
    name: title
    format: format
    description: description

[JJediny]

Alternative approach to editing schema as json to remove the need for creative logic/hacks of dataset entries... Using a JSON schema to control the hierarchy, ordering, description of the fields could significantly simplify the core jekyll site and reduce the workflow to:

1. GET raw yml for page from github API
2. CONVERT auto convert yml2json, dump into text area where the form is set to listen/watch as a JS event to pre-populate the form with the current pages data.
3. UPDATE info through the form UI
4. POST auto convert json2yaml output using github API to update

datajson-editor

using data.json but could control which schema is used and offer the dataset.md ckan model/schema currently being used by JKAN

DEMO

Related to issues #34 and #33

[timwis]

Closing in favor of #60