-
Notifications
You must be signed in to change notification settings - Fork 5
Glossary
This glossary defines common terms used across the DCAT-US 3 implementation support and DCAT-US v3.0 maintenance wiki pages.
Terms may be updated as implementation guidance, maintenance processes, and agency support materials evolve.
A metadata field or concept used to describe whether access to a dataset or resource is restricted.
In DCAT-US v3.0 maintenance discussions, changes touching accessRestriction require special attention and must include a security considerations note in the relevant pull request.
Related terms:
- Use Restriction
- CUI Restriction
- Security Considerations Note
A meeting used to gather practical implementation feedback from selected agencies before final maintenance decisions are made.
Agency feedback meetings may be used to discuss:
- Proposed schema changes
- Field clarifications
- Documentation updates
- Deprecation notices
- Validation issues
- Harvesting impacts
- Migration guidance needs
- Implementation blockers
The person or group identified by an agency to coordinate communication with the Data.gov team or DCAT Interagency Maintenance Team.
An agency point of contact may help coordinate:
- Harvest source requests
- DCAT-US 3 implementation questions
- Validation follow-up
- Release feedback
- Agency participation in maintenance discussions
A summary prepared as part of the annual retrospective to identify agency cohorts that may benefit from targeted implementation assistance.
The annual compliance support summary is an implementation support tool and is not an enforcement document.
It may include:
- Validation trends
- Common field-level error patterns
- Agency implementation blockers
- Documentation gaps
- Recommended support activities
- Priorities for the next maintenance cycle
An annual review conducted as part of Cycle 2 in July.
The retrospective reviews:
- Harvest validation error trends
- New Relic data
- GitHub issue trends
- Documentation gaps
- Agency blockers
- Release communications
- Lessons learned
- Priorities for the next annual maintenance cycle
A set of issues or tasks that are not currently assigned to an active release cycle but may be considered in the future.
Backlog items may include:
- Deferred issues
- Future enhancements
- Documentation updates
- Questions needing more information
- Lower-priority maintenance items
A change that may cause existing valid metadata to become invalid or require agencies to modify existing implementations.
Examples may include:
- Removing a field
- Changing an enum
- Changing a field from optional to required
- Changing allowed values
- Changing validation behavior in a way that causes previously valid records to fail
- Changing structure in a way that affects existing
data.jsonimplementations
Breaking changes require prior deprecation notice and a minimum 90-day agency implementation window before enforcement.
An issue where the schema behaves incorrectly or inconsistently with the specification.
Examples may include:
- The schema validates something that should not be valid
- The schema rejects something that should be valid
- A field behaves inconsistently with documented requirements
- A schema rule conflicts with implementation guidance
In GitHub, these issues may be labeled:
bug
A system, platform, or collection that organizes metadata records for datasets or other resources.
In the Data.gov context, Catalog may refer to Data.gov catalog functionality or a system that displays, indexes, or organizes harvested metadata.
A communication channel associated with the Federal Chief Data Officers Council.
CDO Council channels may be used to share:
- Release notes
- Deprecation notices
- Maintenance cycle updates
- Requests for agency feedback
- Implementation support information
- Broader interagency announcements
A record of changes included in a release.
A changelog may include:
- Schema changes
- Documentation updates
- Bug fixes
- Enhancements
- Clarifications
- Deprecation notices
- Breaking changes
- Migration guidance links
An issue disposition indicating that the issue will not be addressed through a schema or documentation change.
This disposition may be used when:
- The requested change is out of scope
- The proposed change is not aligned with the standard
- The issue is already addressed elsewhere
- The maintenance team decides not to proceed
A URI used to indicate the standard or profile to which metadata conforms.
For each DCAT-US v3.0 release, the Data.gov team should confirm with the schema team whether the conformsTo URI requires updating for the new version.
A rolling process for reviewing new issues as they are submitted rather than batching them to a specific time of year.
The Data.gov team applies a classification label to each new issue within two weeks of submission.
Labels include:
bugenhancementquestion
A metadata concept related to restrictions associated with Controlled Unclassified Information, often referenced through the cuiRestriction field.
Changes touching cuiRestriction must include a security considerations note in the relevant pull request.
Related terms:
- Access Restriction
- Use Restriction
- Security Considerations Note
See Controlled Unclassified Information Restriction.
The spring DCAT-US v3.0 maintenance release cycle.
Cycle 1 occurs in March or April and focuses on:
- Reviewing Cycle 1 milestone issues
- Approving non-breaking schema changes
- Resolving P1 documentation issues
- Validating examples
- Publishing release notes
- Issuing deprecation notices for changes planned for Cycle 2, if needed
The summer DCAT-US v3.0 maintenance release cycle.
Cycle 2 occurs in July and aligns with the M-25-05 annual compliance reference date.
Cycle 2 focuses on:
- Reviewing Cycle 2 milestone issues
- Releasing approved changes
- Including eligible breaking changes that received prior notice
- Resolving P1 and P2 documentation issues
- Updating migration guidance, if needed
- Publishing release notes
- Conducting the annual retrospective
A JSON file used by agencies to publish metadata for harvesting by Data.gov.
Agencies may create or update a data.json file as part of DCAT-US 3 implementation.
Changes to DCAT-US v3.0 may affect existing data.json implementations, especially when field-level changes, validation behavior, or migration guidance are involved.
A support contact for questions related to Data.gov harvesting or resources.data.gov documentation.
Contact:
An outreach channel that may be used to share DCAT-US v3.0 release notes, documentation updates, grace period information, and implementation support information with Data.gov stakeholders.
The team at GSA responsible for maintaining the DCAT-US repository and coordinating the DCAT-US v3.0 maintenance cycle.
The Data.gov team supports:
- Issue triage
- Repository maintenance
- Release coordination
- Documentation coordination
- Agency communication
- Harvest source request tracking
- Data.gov product implementation tracking
A GitHub project board used to track technical implementation issues, enhancements, and defects across Data.gov products.
Board:
https://github.com/orgs/GSA/projects/11/views/1
This board may include work related to:
- Harvester
- Catalog
- Inventory.data.gov
- Other Data.gov services
Data Catalog Vocabulary.
DCAT is a vocabulary designed to facilitate interoperability between data catalogs published on the web.
A monthly interagency information sharing session related to DCAT, DCAT-US 3, metadata standards, agency implementation efforts, and Data.gov harvesting and display considerations.
This session may include:
- Presentations
- Demonstrations
- Walkthroughs
- Q&A
- Open floor discussion
The interagency team responsible for governing DCAT-US v3.0 schema maintenance decisions.
The team reviews prioritized issues, considers agency implementation impacts, assigns dispositions, reviews potential breaking changes, and helps identify maintenance priorities.
A bi-weekly open Q&A session for agencies implementing DCAT-US 3.
This meeting is not a formal training or presentation. No prepared presentation materials or scheduled instruction are provided.
Agencies may bring questions about:
- DCAT-US 3 implementation
- Metadata fields
- Validation
- Harvesting
- Data.gov display
- Related metadata standards
If no questions are raised, the meeting may remain open in silence or conclude early.
The United States profile of DCAT.
DCAT-US provides metadata standards for describing datasets and data catalogs in a way that supports interoperability, discovery, harvesting, and reuse.
A prior version of the DCAT-US metadata standard.
Agencies may transition from DCAT-US 1.1 to DCAT-US 3 as part of metadata modernization and Data.gov harvesting updates.
The current DCAT-US metadata standard discussed in this wiki.
DCAT-US 3 supports agency metadata implementation, Data.gov harvesting, validation, and display considerations.
The GitHub issue tracker used to request or discuss changes to the DCAT-US metadata standard itself.
Issue tracker:
https://github.com/GSA/dcat-us/issues
Use this tracker for:
- Proposed changes to the standard
- Field definition questions
- Schema bugs
- Enhancements
- Standard-level documentation or guidance issues
The GitHub repository for the DCAT-US metadata standard.
Repository:
https://github.com/GSA/dcat-us
Frequently asked questions related to technical implementation of the DCAT-US 3 metadata standard.
FAQ page:
https://github.com/GSA/dcat-us/wiki/DCAT-US-3-Technical-Implementation-FAQ
The version of the DCAT-US metadata standard covered by the maintenance process described in this wiki.
DCAT-US v3.0 follows a semi-annual maintenance cycle covering schema governance, documentation, and agency communication.
An issue disposition indicating that the issue should be reconsidered in a future cycle.
A deferred issue may need:
- More information
- Agency feedback
- Additional analysis
- Future release consideration
- Related documentation or implementation work
A notice issued when a breaking change is planned for a future release.
A deprecation notice should include:
- Affected field or schema area
- Planned change
- Reason for change
- Expected release timing
- Agency implementation impact
- Minimum 90-day implementation window
- Recommended agency action
- Where to ask questions or provide feedback
People or teams responsible for maintaining DCAT-US documentation, examples, migration guidance, FAQs, changelogs, and related resources.
Documentation may be maintained on:
- resources.data.gov
- GitHub release notes
- DCAT-US GitHub wiki
- Other implementation guidance pages
An issue disposition indicating that the issue should be addressed through documentation, examples, FAQs, or guidance rather than a schema change.
A proposed addition or improvement to the schema.
Examples may include:
- Adding a new optional field
- Improving a field definition
- Updating usage guidance
- Clarifying allowed values
- Supporting an implementation pattern not currently covered
In GitHub, these issues may be labeled:
enhancement
The process of validating example metadata records against the current schema.
Example validation helps ensure that documentation examples are accurate and aligned with the live schema.
Frequently Asked Questions.
FAQs may be developed based on:
- GitHub issues
- Office hours questions
- Agency feedback
- Validation trends
- Harvest source transition issues
- Annual retrospective findings
A period of time before new requirements are enforced.
For DCAT-US v3.0 maintenance releases, agencies should have a 90-day grace period before any new requirements are enforced.
The grace period gives agencies time to:
- Review release notes
- Review documentation
- Assess implementation impact
- Update metadata generation workflows
- Validate updated metadata files
- Ask questions
A metadata source that Data.gov harvests from an agency.
A harvest source may point to a data.json file or other supported metadata source that Data.gov uses to ingest agency metadata.
The agency-facing form used to request a new DCAT-US 3 harvest source or a change to an existing harvest source.
Form:
https://touchpoints.app.cloud.gov/touchpoints/ffb7e9d0
A board used by the Data.gov team to track harvest source requests received through the Harvest Source Change Request Form.
Board:
https://github.com/orgs/GSA/projects/431
The board tracks:
- Request details
- Agency communications
- Notes
- Troubleshooting items
- Current stage or status
A tool agencies can use to check whether a proposed or updated harvest source is expected to pass validation.
Tool:
https://harvest.data.gov/validate/
A Data.gov product or service used to harvest metadata from agency sources.
Harvester-related technical implementation issues, enhancements, and defects may be tracked on the Data.gov Team Board.
See DCAT Interagency Info Sharing Session.
A Data.gov tool that agencies may use to create a DCAT-US 3 compliant file.
Agencies can request access using the Inventory.data.gov Access Request Form.
The form agencies use to request access to Inventory.data.gov.
Form:
https://touchpoints.app.cloud.gov/touchpoints/9145dd7e
Once an Inventory.data.gov account is established, agencies must re-submit the same form once per quarter to maintain access.
A decision assigned to an issue during maintenance review.
Common dispositions include:
- Approved for PR
- Deferred
- Closed as won’t fix
- Needs more information
- Documentation update only
- FAQ update only
The process of reviewing, labeling, and routing issues.
For DCAT-US v3.0 maintenance, the Data.gov team triages issues on a rolling basis and applies a classification label within two weeks of submission.
The recurring process used to maintain DCAT-US v3.0.
The maintenance cycle includes:
- Continuous issue triage
- Cycle 1 spring release
- Cycle 2 summer release
- Annual retrospective
- Documentation updates
- Release communications
- Agency feedback
See DCAT Interagency Maintenance Team.
Data that describes other data.
In this context, metadata describes datasets, distributions, catalogs, access information, use restrictions, identifiers, publishers, and related information needed for discovery and reuse.
See Harvest Source.
Guidance that helps agencies update existing metadata implementations when schema or field-level changes affect existing data.json files.
Migration guidance may include:
- Field-level changes
- Before-and-after examples
- Validation considerations
- Harvesting considerations
- Recommended agency actions
- Timeline information
A GitHub planning mechanism used to group issues for a release cycle.
Examples may include:
- Cycle 1 Spring Release
- Cycle 2 Summer Release
- Future Maintenance Cycle
- Backlog
A federal reference connected to DCAT-US 3 implementation and the annual compliance reference date described in the maintenance process.
The July Cycle 2 release aligns with the M-25-05 annual compliance reference date.
An issue disposition indicating that additional information is needed before a decision can be made.
Information needed may include:
- More complete examples
- Validation output
- Agency implementation details
- Clarification of requested change
- Impact analysis
- Documentation references
A monitoring and analytics tool referenced in the maintenance process for reviewing harvest validation error trends.
New Relic data may be used during the annual retrospective to identify recurring validation patterns, field-level issues, or agency cohorts that may benefit from targeted support.
A change that adds functionality or expressiveness without requiring agencies to modify existing valid metadata records.
Example:
- Adding a new optional field
A non-breaking addition may be included in the next release cycle if approved.
A change that improves understanding without changing validation expectations or requiring agencies to change existing valid metadata.
Examples:
- Updating a field description
- Clarifying a usage note
- Correcting documentation
- Adding implementation examples
A non-breaking clarification may be included in the next release cycle if approved.
See DCAT Interagency Q&A Office Hours.
A meeting format where discussion is driven by participant questions rather than a prepared presentation.
The DCAT Interagency Q&A Office Hours use an open Q&A format.
A critical documentation issue.
Cycle 1 documentation work includes resolving all P1 documentation issues on resources.data.gov.
A documentation issue that is important but lower priority than P1.
Cycle 2 documentation work includes resolving all P1 and P2 documentation issues on resources.data.gov.
The organization under which a metadata harvest source is configured.
Final acceptance criteria for harvest source requests include confirming that a new or updated metadata harvest source exists under the correct parent organization.
A harvest source transition approach where a new, additional DCAT-US 3 harvest source is created while the existing harvest source remains available temporarily.
Path A allows an agency to transition datasets or metadata records from an existing DCAT-US 1.1 harvest source to a new DCAT-US 3 harvest source over time.
A harvest source transition approach where an existing harvest source is stopped, updated, and resumed using the DCAT-US 3 metadata format or profile.
Path B requires coordination with the agency to confirm timing and ensure the agency has updated its JSON file before harvesting resumes.
A release that updates the current major version without moving to a new major version.
Examples:
v3.1v3.2
Point releases are used in the DCAT-US v3.0 semi-annual maintenance cycle.
A proposed change submitted to the GitHub repository for review.
Approved issues may result in pull requests that modify the schema, documentation, examples, or related repository content.
A request for clarification on schema intent or behavior.
In GitHub, these issues may be labeled:
question
A summary of changes included in a release.
Release notes should include:
- Release version
- Release date
- Summary of changes
- Changelog
- Schema changes
- Documentation changes
- Breaking changes, if applicable
- Deprecation notices, if applicable
- Grace period information
- Agency action items
- Links to documentation
- Contact information
A meeting held before a release to confirm that pull requests, documentation, release notes, changelog entries, and outreach materials are ready.
A Data.gov resource site used to publish implementation guidance, crosswalks, updates, changelogs, and related documentation.
Relevant pages include:
- DCAT-US 3 Updates
- DCAT-US 3 Implementation Guide
- DCAT-US 3 to M-25-05 Crosswalk
The formal structure and rules used to validate DCAT-US metadata.
Schema maintenance may include bug fixes, enhancements, clarifications, and versioned releases.
The group or individuals who provide technical review and schema-specific guidance for proposed changes.
The schema team may help determine:
- Whether a change is breaking or non-breaking
- Whether validation behavior changes
- Whether the
conformsToURI requires updating - Whether security considerations are needed
A required note for pull requests that touch any of the following fields:
accessRestrictionuseRestrictioncuiRestriction
The note should describe:
- What field is affected
- What behavior is changing
- Whether validation is affected
- Whether agency implementation is affected
- Any recommended agency review considerations
A versioning approach used for releases.
For DCAT-US v3.0 maintenance, point releases should use semantic versioning.
Examples:
v3.1v3.2
Major version changes, such as v4.0, are planned separately.
The URL for the metadata file or source that Data.gov will harvest.
Agencies should confirm the source URL before submitting a harvest source change request.
The Data.gov team confirms and tests the source URL as part of harvest source request processing.
An issue related to the DCAT-US metadata standard itself.
Examples include:
- Proposed changes to fields or definitions
- Questions about schema intent
- Schema bugs
- Enhancements
- Standard-level modeling questions
Standard-level issues should be submitted through DCAT-US GitHub Issues.
A frequently asked question related to implementing DCAT-US 3.
Technical implementation FAQs may address:
- Field interpretation
- Validation issues
- Metadata formatting
- Harvesting considerations
- Common implementation patterns
- Edge cases
A metadata field or concept used to describe restrictions on how a dataset or resource may be used.
In DCAT-US v3.0 maintenance discussions, changes touching useRestriction require special attention and must include a security considerations note in the relevant pull request.
Related terms:
- Access Restriction
- CUI Restriction
- Security Considerations Note
The process of checking whether metadata conforms to expected schema rules or requirements.
Agencies can validate proposed or updated harvest sources at:
https://harvest.data.gov/validate/
A problem identified during validation that indicates metadata does not meet expected schema or validation requirements.
Validation errors may indicate:
- Missing required fields
- Incorrect formats
- Invalid values
- Structural issues
- Field-level problems
A validation message that may indicate a potential issue or recommended improvement but may not necessarily prevent validation from passing.
Warnings should still be reviewed by agencies.
A support channel through which issues or questions may be received.
Issues received through Zendesk that relate to the DCAT-US metadata standard and are not already on GitHub may be cross-filed by the Data.gov team.
- DCAT-US 3 Implementation Resources
- Agency Workflow for DCAT-US 3 Harvest Source Requests
- Inventory.data.gov Access
- Harvest Source Review and Validation
- Harvest Source Change Requests
- FAQ Overview
- DCAT-US 3 Technical Implementation FAQ
- Harvest Source Request FAQ
- Inventory.data.gov Access FAQ
- Meeting FAQ
- Tracking and Issue Routing FAQ
- DCAT Interagency Maintenance Team
- DCAT IMT CHARTER
- Maintenance Process Overview
- Roles and Responsibilities
- Issue Triage and GitHub Workflow
- Semi-Annual Release Cycles
- Agency Feedback and Participation
- Release Communications and Outreach
- Annual Retrospective
- Maintenance Meeting Schedule
- Maintenance Templates