Skip to content

Implement a standards-based, machine-readable Extended Data Dictionary #2373

Closed

Description

@jqnatividad

Already, we create an extended data dictionary with describegpt.

However, it's not machine-readable.

Create a machine-readable version that we can use with DP+ to populate the dcat-us:describedBy property.

https://doi-do.github.io/dcat-us/#dataset-describedBy

DOI-DO/dcat-us#138

see #1705

Activity

  1. added
    enhancementNew feature or request. Once marked with this label, its in the backlog.
    CKANinteroperability with CKAN Data Management System
    DCAT3metadata standard
    on Dec 24, 2024
  2. added this to the v3.0 milestone on Jan 15, 2025
  3. added
    DRUFfor Data Resource Upload First workflow
    on Jan 26, 2025
  4. self-assigned this
    on Mar 9, 2025
  5. jqnatividad commented on Jul 14, 2025

    @jqnatividad
    CollaboratorAuthor

    As there is no existing standard format for a data dictionary, we will leverage JSON Schema validation instead.

    qsv already supports the creation of a schema by inferring it from its summary stats and frequency table with the schema command and validate similar CSV files with the validate command.

    So the Data Dictionary is not just a documentation artifact, it can be used for actual validation work.

    And we can add DCAT3 properties without worrying if it invalidates the JSON Schema as the spec has additionalProperties where we can add the extended data dictionary "stuff" - e.g. summary stats, frequency table, etc.

    https://tour.json-schema.org/content/03-Objects/02-Additional-Properties

    cc @rzmk @samibaig @wardi

  6. removed this from the v4.0 milestone on Aug 12, 2025
  7. jqnatividad commented on Aug 12, 2025

    @jqnatividad
    CollaboratorAuthor

    Based on the learnings while creating the --json option for the frequency command.

    Let's go ahead with extending JSON Schema so that is also doubles as a "validating" data dictionary as well.

    Not only should it have summary stats, it will also have the frequency table for each field.

    https://github.com/dathere/qsv/blob/master/scripts/NYC_311_SR_2010-2020-sample-1M-frequency.json

    Take into account Croissant guidance on using properties from external vocabularies (mlcommons/croissant#885), so we can create one common format for both Croissant and DCAT-US v3's describedBy property.

  8. pinned this issue on Aug 13, 2025
  9. jqnatividad commented on Aug 18, 2025

    @jqnatividad
    CollaboratorAuthor

    The revamped describegpt for the upcoming qsv 7.0 release is a step towards this.

    For the initial implementation, we'll be optimizing for the current CKAN data dictionary.

  10. jqnatividad commented on Nov 7, 2025

    @jqnatividad
    CollaboratorAuthor

    Closing this now that describegpt has JSON output.

    We can map it to the standard CKAN dictionary and just use the JSONSchema created by the schema command as a CKAN dataset resource that the DRUF can use to validate updates.

  11. unpinned this issue on Nov 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

CKANinteroperability with CKAN Data Management SystemCroissantmetadata standard for describing ML datasetsDCAT3metadata standardDRUFfor Data Resource Upload First workflowWIPwork in progressdatapusher+for Datapusher+enhancementNew feature or request. Once marked with this label, its in the backlog.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions