The DCAT-US Profile Version 3 (DCAT-US 3.0) is an updated specification designed to facilitate data cataloging, discovery, and interoperability among US government agencies. Leveraging the strong foundation laid by the Project Open Data (POD) 1.1 standard (also known as [[DCAT-US-1.1]]), this profile seamlessly aligns with the emerging Data Catalog Vocabulary (DCAT) - Version 3 (DCAT 3.0)[[[VOCAB-DCAT-3]]] recommendations approved by the World Wide Web Consortium (W3C), all while upholding the essential FAIR principles. Moreover, it emphasizes maintaining compatibility with the existing POD 1.1 standard, ensuring a fluid transition. The result ensures data's Findability, Accessibility, Interoperability, and Reusability (FAIR).

The predominant significance of the DCAT-US 3.0 lies in its role as a bridge between the well-established DCAT-US 1.1 and the forward-looking DCAT 3.0, uniting them under a single, standardized approach for articulating and exchanging datasets. By harmonizing the most significant attributes of both standards, this profile also addresses the distinctive metadata prerequisites inherent to the US context. It goes above and beyond by encompassing specialized properties to address geospatial and statistical datasets, effectively harnessing established vocabularies to elevate the process of data sharing and subsequent reuse.

Distinguished by its usage of the Shapes Constraint Language (SHACL) for structural and semantic validation, the DCAT-US 3.0 introduces a highly refined, interoperable, and future-proof framework for describing and validating dataset metadata. In essence, it is not just a specification but an advanced stride towards achieving a data-centric landscape where precise metadata description empowers the efficient flow of information while laying the groundwork for sustained innovation.

Background

The FAIRness Project is introducing a draft update to the Data Catalog (DCAT) standard for the United States. This update, “DCAT-US v3.0 Schema,” builds upon the requirements we received from agencies as well as data creators, providers, and users, Data Inventory statutory requirements, and the lessons learned over ten years of successful implementation of the Project Open Data Metadata Standard (DCAT-US v1.1) used by Data.gov.

We need your help to review and comment on this draft so that it meets agencies’ data inventory needs and those of cross-government programs like Data.gov, GeoPlatform, and the Standard Application Process Portal.

Once approved and implemented, the update will improve the FAIRness, or Findability, Accessibility, Interoperability, and Reusability of all types of federal data. DCAT-US v3 will provide a *single* metadata standard able to support most requirements for documentation of business, technical, statistical, and geospatial data consistently.

Key features of the DCAT-3 Schema are:

Please review the documentation below and provide feedback to help make this standard as useful as possible to you and the broader federal data user community.

Please follow the instructions found here to submit your comments and issues with the current draft schema specification.

Overview

The DCAT-US Profile Version 3 is a comprehensive update to the Project Open Data (POD) 1.1 standard, designed to meet the evolving needs of data exchange and interoperability among US government agencies. This profile builds on the foundation laid by POD 1.1 and is aligned with the latest DCAT 3.0 standard from the World Wide Web Consortium (W3C). In addition, the profile aims to embody the FAIR principles, ensuring that data is Findable, Accessible, Interoperable, and Reusable. This introduction will provide an overview of the purpose of this profile, highlight the gaps between POD 1.1 and DCAT 3.0, and elaborate on the differences and enhancements offered by the DCAT-US Profile Version 3.

Purpose and Evolution

The purpose of the DCAT-US Profile Version 3 is to improve data discoverability, accessibility, and interoperability among US government agencies. By adhering to the FAIR principles, the profile promotes more effective data sharing and reuse. The FAIR principles emphasize that data should be:

The DCAT-US Profile Version 3 bridges the gap between the POD 1.1 and DCAT 3.0 standards by incorporating the best features of both while also addressing specific metadata requirements unique to the US context. It offers a standardized approach for describing and exchanging datasets, thereby enabling more efficient data sharing and reuse.

Data Structure

The Application Profile specified in this document is based on the specification of the Data Catalog Vocabulary (DCAT) developed under the responsibility of the Government Linked Data Working Group at W3C. DCAT is an RDF vocabulary designed to facilitate interoperability between data catalogs published on the Web. Additional classes and properties from other well-known vocabularies are re-used where necessary.

The DCAT vocabulary consists of classes and properties.

Classes and properties are used to deliver the metadata in a structured way.

Application Areas

The DCAT Application Profile for data portals in United States (DCAT-US) is an Application Profile of the DCAT vocabulary.

It should be always kept in mind that both DCAT-US primarily focus on metadata. Metadata is by definition secondary information on the data: when and by whom were they published, which usage conditions apply, how often are they updated, whom to contact about them and where and how can they be accessed.

Gaps with DCAT-US 1.1

The DCAT-US 1.1 standard, while effective for its time, had some limitations that the DCAT 3.0 standard has addressed. The key differences between the two standards include:

DCAT-US Features

The DCAT-US Profile Version 3 not only incorporates the enhancements provided by DCAT 3.0 but also maintains the US-specific metadata requirements defined in POD 1.1. This profile offers a harmonized approach to data cataloging that accounts for the unique needs of US agencies.

One of the key features of this profile is its use of reference controlled vocabularies. These vocabularies enable better interoperability between US agencies by providing a common language for describing datasets. The profile also introduces new properties to handle geospatial data and statistical datasets, leveraging established vocabularies in these domains.

Profile Encoding

The encoding of the DCAT-US profile involves the technical aspects of how data is represented and exchanged, addressing questions about data format and interoperability. While the DCAT-US 3.0 conformance does not strictly mandate the use of RDF serialization for data exchange, it emphasizes the importance of ensuring that the exchanged format can be unambiguously transformed into RDF. This flexibility allows for interoperability while accommodating various data exchange requirements.

One prevalent format for data exchange between systems is JSON (JavaScript Object Notation), which is widely used due to its simplicity and human-readable nature. To facilitate data exchange in JSON while adhering to the DCAT-US profile, a dedicated mechanism is provided: the JSON-LD context file. JSON-LD (JSON for Linked Data) is a W3C Recommendation (JSON-LD 1.1) that establishes a standardized approach for interpreting JSON structures as RDF, enhancing the potential for semantic integration and interoperability.

The DCAT-US profile offers a JSON-LD context file that implementers can utilize as a foundation for their data exchange processes. By incorporating this JSON-LD context file, implementers can ensure that their data adheres to the DCAT-US standards while being exchanged in a JSON format. This allows for a coherent and consistent representation of the data that aligns with the RDF model, promoting interoperability among different systems and tools.

It's important to note that the provided JSON-LD context file is not normative, indicating that other JSON-LD contexts can also be used to establish a conformant DCAT-US data exchange. This flexibility caters to various implementation scenarios and data requirements, while still adhering to the overarching principles of the DCAT-US profile. Overall, the encoding of the DCAT-US profile acknowledges the significance of data format and interchange methods, leveraging JSON-LD and related mechanisms to facilitate seamless and interoperable data exchange within the context of the DCAT-US specification.

Profile Validation

While the JSON Schema approach used in POD 1.1 was effective in certain scenarios, it has limitations when compared to using SHACL for defining data models and constraints:

Considering these limitations, the DCAT-US Profile Version 3 has chosen SHACL as the foundation for its data modeling and validation, ensuring a more expressive, interoperable, and future-proof framework for defining dataset metadata.

The DCAT-US Profile Version 3 is defined using the Shapes Constraint Language (SHACL), which offers several advantages over previous approaches:

By using SHACL, the DCAT-US Profile Version 3 ensures a robust and extensible foundation for future updates, as well as compatibility with a wide range of data processing tools and applications.

Document Status

Initial Draft

Conformance

DCAT-US is an application profile of DCAT Version 3.

The DCAT-Profile Guidance states that application profiles may form hierarchies.

The following diagram captures the relationship between DCAT and DCAT-US :

Data Provider requirements

A data catalog conforms to DCAT-US if:

Receiver requirements

An application (data portal) conforms to DCAT-US if:

DCAT-US Classes

This section displays the classes for the DCAT-US 3 profile. We distinguish core classes, which represent the primary business entities that the application profile is concerned with, from supporting classes, which are used to provide additional context, metadata, or structure to the core classes.

This following table provides a summary of critical changes and updates in the DCAT-US 3.0 Application Profile, offering valuable insights into the evolution of class definitions within this data cataloging standard. Each change type is carefully documented, from the introduction of new classes specifically designed for DCAT-US 3.0 to updates and adaptations from the broader DCAT specifications, such as DCAT 1, DCAT 2, and DCAT 3. Understanding these changes is essential for data practitioners, as it enables them to grasp the evolving landscape of data cataloging and its alignment with various DCAT versions, ultimately facilitating more effective data management and interoperability.

Change Type Description
New! New DCAT-US 3.0 specific class that is not referred in DCAT specifications
Aligned Class introduced in DCAT specifications that does not exist in DCAT-US 1.1

Core Classes

The DCAT US Application Profile (“DCAT-US ”) are structured around the following main classes:

Class name Usage note for the Application Profile URI and Reference Changes from DCAT-US 1.1
Catalog A catalog or repository that hosts the Datasets or Data Services being described. dcat:Catalog Aligned
Catalog Record A record in a catalog, describing the registration of a single dcat:Resource dcat:CatalogRecord Aligned
Dataset A conceptual entity that represents the information published. dcat:Dataset Aligned
Distribution A physical embodiment of the Dataset in a particular format. dcat:Distribution Aligned
Data Service A collection of operations that provides access to one or more datasets or data processing functions. dcat:DataService Aligned
Dataset Series A collection of datasets that are published separately, but share some characteristics that group them. dcat:DatasetSeries Aligned

Supporting Classes

Class name Usage note for the Application Profile URI and Reference Changes from DCAT-US 1.1

AccessRestriction

The "AccessRestriction" class used by NARA represents limitations placed on accessing specific records or information within their archives, ensuring controlled and responsible access based on legal, ethical, or security considerations.

dcat-us:AccessRestriction

New!

Activity

An activity carried out by an Agent over an entity, according to a plan, and generating another entity.

prov:Activity

Aligned

Address (Location)

A postal address for a Location.

locn:Address

New!

Address (Contact Point)

A postal address for Contact Point.

vcard:Address

Aligned
Agent

An entity (e.g., an individual or an organisation) that is associated with Catalogs, Catalog Records, Data Services, or Datasets. If the Agent is an organisation, the use of the Organization Ontology [[VOCAB-ORG]] is recommended.

foaf:Agent

Aligned

Attribution

A responsibility of an Agent for a resource.

prov:Attribution

Aligned
Concept

A subject of a Catalog, Dataset, or Data Service.

skos:Concept

Aligned
Concept scheme

A concept collection (e.g. controlled vocabulary) in which the Concept is defined.

skos:ConceptScheme

Aligned
Checksum

A value that allows the contents of a file to be authenticated. This class allows the results of a variety of checksum and cryptographic message digest algorithms to be represented.

spdx:Checksum

Aligned
Contact

A description following the [[VCARD-RDF]] specification, e.g. to provide telephone number and e-mail address for a contact point using vcard:Contact .

vcard:Contact

Aligned

CUI Restriction

Controlled Unclassified Information (CUI) is information that requires safeguarding or dissemination controls pursuant to and consistent with applicable law, regulations, and government-wide policies but is not classified.

dcat-us:CuiRestriction

New!
Document

A textual resource intended for human consumption that contains information, e.g., a Web page about a Dataset, a publication, a chapter book, a technical report, but also a blog post.

foaf:Document

New!

Geographic Bounding Box

GeographicBoundingBox describes the spatial extent of domain of application of an resource and is standardized in WGS 84 Lat/Long coordinate system.

dcat-us:GeographicBoundingBox

New!
Identifier

An identifier in a particular context, consisting of the string that is the identifier; an optional identifier for the identifier scheme; an optional identifier for the version of the identifier scheme; an optional identifier for the agency that manages the identifier scheme

adms:Identifier

New!

Investment

This new class specific to DCAT-US represents U.S. government-funded initiatives, allowing datasets to be linked with unique government identifiers, promoting transparency and effective resource management.

dcat-us:Investment

New!
LiabilityStatement

A formal declaration accompanying a dataset which outlines the responsibilities and limitations of the data provider in terms of the accuracy, completeness, and potential use of the data. It often serves to limit the legal exposure of the data provider by defining the scope of allowed uses and disclaiming warranties or guarantees.

dcat-us:LiabilityStatement

New!
Licence Document

A legal document giving official permission to do something with a resource.

dct:LicenseDocument

Aligned
Location

A spatial region or named place. It can be represented using a controlled vocabulary or with geographic coordinates.

dct:Location

Aligned

Media type

A media type, e.g. the format of a computer file.

dct:MediaType

Aligned

Metric

Represents a standard to measure a quality dimension. An observation (instance of dqv:QualityMeasurement) assigns a value in a given unit to a Metric.

In DCAT-US, this class is used to define individuals corresponding to the different types of spatial resolution.

dqv:Metric

Aligned
Organization

Represents a collection of people organized together into a community or other social, commercial or political structure. The group has some common purpose or reason for existence which goes beyond the set of people belonging to it and can act as an Agent. Organizations are often decomposable into hierarchical structures.

org:Organization Aligned
Period of time

An interval of time that is named or defined by its start and end dates.

dct:PeriodOfTime

Aligned
Person

This class represents an individual human being or a person. It can be used to provide information about individuals, such as their name, email address, homepage URL, and other personal details.

foaf:Person Aligned

Program

This new class specific to DCAT-US represents the primary federal program associated with a specific data asset, sourced from the Federal Program Inventory. This association helps establish the relevance and context of the data asset, potentially aiding in compliance with the U.S. Evidence Act.

dcat-us:Program

New!
Provenance Statement

A statement of any changes in ownership and custody of a resource since its creation that are significant for its authenticity, integrity, and interpretation

dct:ProvenanceStatement

New!

Quality Measurement

Represents the evaluation of a given resource (as a Data Service, Dataset, or Distribution) against a specific quality metric.

dqv:QualityMeasurement

Aligned
Relationship

An association class for attaching additional information to a relationship between DCAT Resources

dcat:Relationship

Aligned
Rights statement

A statement about the intellectual property rights (IPR) held in or over a resource, a legal document giving official permission to do something with a resource, or a statement about access rights.

dct:RightsStatement

Aligned
Role

A role is the function of a resource or agent with respect to another resource, in the context of resource attribution or resource relationships.

Note it is a subclass of skos:Concept.

dcat:Role

Aligned
Standard

A standard or other specification to which a Catalog, Catalog Record, Data Service, Dataset, or Distribution conforms.

dct:Standard

Aligned

Use Restriction

A UseRestriction is a set of rules, guidelines, or legal provisions that dictate how a particular resource, asset, information, or object can be utilized. Use restrictions may encompass limitations on access, distribution, reproduction, modification, or sharing, and they are often put in place to protect privacy, intellectual property rights, security, or compliance with legal or ethical standards.

dcat-us:UseRestriction

New!

Properties per Class

Requirement levels

DCAT-US defines four requirement levels for data receivers and senders:

The meaning of the terms MUST, MUST NOT, SHOULD and MAY in this section and in the following sections are as defined in RFC 2119.

In the given context, the term "processing" means that receivers MUST accept incoming data and transparently provide these data to applications and services. It does neither imply nor prescribe what applications and services finally do with the data (parse, convert, store, make searchable, display to users, etc.).

Notation

Property Evolution in DCAT-US 3.0.

The following table provides an overview of the various types of changes and updates within the DCAT-US specifications, shedding light on the evolution and adaptation of the data catalog standard. Each change type is categorized, and its significance is explained, ranging from the introduction of new properties to updates that align with the latest DCAT specifications. Understanding these changes is essential for data practitioners and stakeholders seeking to keep pace with the evolving landscape of data cataloging and data sharing standards.

Change Type Description
New! New DCAT-US 3.0 specific property that is not referred in DCAT specifications
Aligned Property aligned with latest DCAT-3 specification that does not exist in DCAT-US 1.1
Fixed Fixed property that is inconsistent with DCAT specification
No Change No change from DCAT-US 1.1 profile
Multilingual Support Extension of DCAT-US property to support multilingual values

Class: AccessRestriction

The class "AccessRestriction" used by the National Archives and Records Administration (NARA) refers to a categorization or specification that denotes limitations or conditions imposed on the accessibility of certain records, documents, or information within their archival holdings. Access restrictions are employed to regulate and control access to sensitive or confidential content based on legal, ethical, security, or other relevant considerations. These restrictions may pertain to who can access the information, the purposes for which it can be accessed, and the conditions under which it can be utilized. The "AccessRestriction" class provides a structured framework for classifying and managing these access limitations within NARA's archival context, contributing to the proper governance and responsible dissemination of historical records and data.

RDF Class: dcat-us:AccessRestriction
Definition: The "AccessRestriction" class used by NARA represents limitations placed on accessing specific records or information within their archives, ensuring controlled and responsible access based on legal, ethical, or security considerations.
Usage note:

The "AccessRestriction" class serves as a valuable tool within NARA's archival framework, enabling the organization to effectively manage and communicate access limitations for specific records or information. By employing this class, NARA can categorize and enforce controlled access to sensitive content, safeguarding confidentiality, adhering to legal requirements, and preserving the integrity of historical data. Researchers, archivists, and authorized users can rely on "AccessRestriction" to navigate and understand the accessibility parameters associated with archived materials, facilitating responsible information dissemination and usage.

Rationale The "AccessRestriction" class in the DCAT-US application profile is essential for categorizing and managing access restrictions according to NARA standards, ensuring responsible access to sensitive historical records. It enhances transparency, aiding researchers and authorized users in understanding and navigating access parameters for archived materials.

Properties Summary

Property URI Range ReqLevel Card
restriction status dcat-us:restrictionStatus skos:Concept M 1..1
restriction authority dcat-us:authority org:Organization R 0..1
restriction note dcat-us:restrictionNote rdfs:Literal O 0..1

Mandatory Properties

Property: restriction status

Property restriction status
Requirement level Mandatory
Cardinality 1
URI dcat-us:restrictionStatus
Range skos:Concept
Definition The indication of whether or not there are access restrictions on the data.

Optional Properties

Property: restriction note

Property restriction note
Requirement level Optional
Cardinality 0..1
URI dcat-us:restrictionNote
Range rdfs:Literal
Definition A note related to the access restriction

Example

Class: Activity

Class: Address (Contact Point)

Class: Address (Location)

Class: Agent

RDF Class: foaf:Agent
Definition: An entity that acts on something (eg. person, group, software or physical artifact).
Usage note:
  • Use this class when refering to a software agent that is associated with Catalogues, Catalogue Records, Data Services, or Datasets.
  • If the Agent is an organisation, the use of the org:Organization is recommended.
  • If the Agent is a person, the use of foaf:Person is recommended
Rationale: The addition of the foaf:Agent class in DCAT-US 3.0 serves a dual purpose. Firstly, it allows for the representation of software agents, aligning with modern data automation needs. Secondly, it acts as an abstract class for both foaf:Person and org:Organization, promoting consistency and interoperability while simplifying resource descriptions within the dataset catalog.

Properties Summary

Property URI Range ReqLevel Card
name foaf:name xsd:string M 1..1
type dcterms:type skos:Concept R 0..1
email foaf:mbox owl:Thing O 0..1
phone foaf:phone owl:Thing O 0..1
URL foaf:workplaceHomepage foaf:Document O 0..1
address locn:address locn:Address O 0..1
member of org:memberOf foaf:Organization O 0..n

Mandatory Properties

Property: name

Property name
Requirement level Mandatory
Cardinality 1
URI foaf:name
Range xsd:string
Definition The name of the software agent

Optional Properties

Property: email

Property email
Requirement level Optional
Cardinality 0..1
URI foaf:mbox
Range owl:Thing
Definition This property MAY be used to provide the email address of the Agent, specified using fully qualified mailto: URI scheme

Property: phone

Property phone
Requirement level Optional
Cardinality 0..1
URI foaf:phone
Range owl:Thing
Definition This property MAY be used to provide the phone number of the Agent, specified using fully qualified tel: URI scheme

Property: URL

Property URL
Requirement level Optional
Cardinality 0..1
URI foaf:workplaceHomepage
Range foaf:Document
Definition This property MAY be used to specify the Web site of the Agent.

Property: address

Property address
Requirement level Optional
Cardinality 0..1
URI locn:address
Range locn:Address
Definition This property MAY be used to specify the address of the Agent.

Property: affiliation

Property name
Requirement level Optional
Cardinality 0..n
URI org:memberOf
Range org:Organization
Definition This property MAY be used to specify the affiliation of the Person to an organization.

Example

Class: Attribution

RDF Class: prov:Attribution
Definition: A responsibility of an Agent for a resource.
Usage note: Used to link to an Agent where the nature of the relationship is known but does not match one of the standard [[DCTERMS]] properties (dcterms:creator, dcterms:contributor, dcterms:rightsHolder, and dcterms:publisher). Use dcat:hadRole on the prov:Attribution to capture the responsibility of the Agent with respect to the Resource.
Rationale The inclusion of prov:Attribution in the DCAT profile enables clear data source attribution, promoting responsible data sharing and proper citation practices. It aligns the profile with data provenance best practices for accurate attribution in data sharing.

Properties Summary

Property URI Range ReqLevel Card
agent prov:agent foaf:Agent M 1
role dcat:hadRole dcat:Role M 1

Mandatory Properties

Property: agent

Property agent
Requirement level Mandatory
Cardinality 1
URI prov:agent
Range foaf:Agent
Definition The prov:agent property references an Agent that plays a role in the resource

Property: role

Property role
Requirement level Mandatory
Cardinality 1
URI dcat:hadRole
Range dcat:Role
Definition The function of an entity or agent with respect to another entity or resource.

Example

Class: Catalog

A Catalog or repository that hosts the Datasets or Data Services being described.

DCAT-US allows Catalogs of only Datasets, but also Catalogs of only Data Services

RDF Class: dcat:Catalog
Definition: A curated collection of metadata about resources (e.g., datasets and data services in the context of a data catalog)
Sub-class of: dcat:Dataset
Usage note:
  • A Web-based data catalog is typically represented as a single instance of this class.
  • Populate metadata within the dcat:Catalog to facilitate resource discovery, including title, description, classifiers and other relevant information.
  • Specify the resources hosted within the catalog by linking them as dcat:dataset or dcat:service.
Rationale The update of the dcat:Catalog class aligns with the generalization of catalog scope in DCAT-US 3.0, accommodating catalogs of datasets, data services, or a mixture of both. It reflects the evolving landscape of data publication and discovery, allowing data publishers to describe and share their resources effectively. Additionally, by making Catalog a subclass of Dataset, DCAT-US promotes consistency in metadata representation and enables catalogs to be composed of other catalogs, promoting modularity and extensibility in the data catalog ecosystem.
Property URI Range ReqLevel Card Changes from DCAT-US 1.1
title dcterms:title rdfs:Literal M 1..n Multilingual support
description dct:description rdfs:Literal M 1..n Multilingual support
publisher dct:publisher foaf:Agent M 1..1 Aligned
dataset dcat:dataset dcat:Dataset M 1..n No Change
homepage foaf:homepage foaf:Document R 0..1 Aligned
language dct:language dct:LinguisticSystem R 0..n Aligned
license dct:license dct:LicenseDocument R 0..1 Aligned
release date dct:issued rdfs:Literal (typed as xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth) R 0..1 Aligned
rights dct:rights dct:RightsStatement R 0..1 Aligned
spatial /geographic dct:spatial dct:Location R 0..n Aligned
themes dcat:themeTaxonomy skos:ConceptScheme R 0..n Aligned
update/ modification date dct:modified rdfs:Literal (typed as xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth) R 0..1 Aligned
schema version dct:conformsTo dct:Standard R 0..1 No Change
creator dct:creator dct:Agent O 0..n Aligned
access rights dct:accessRights dct:RightsStatement O 0..1 Aligned
catalog dcat:catalog dcat:Catalog O 0..n Aligned
contact point dcat:contactPoint vcard:Contact O 0..n Aligned
keyword/tag dcat:keyword rdfs:Literal O 0..n Aligned
has part dcterms:hasPart dcat:Catalog O 0..n Aligned
catalog record dcat:record dcat:CatalogRecord O 0..n Aligned
service dcat:service dcat:DataService O 0..n Aligned
theme/category dcat:theme skos:Concept O 0..n Aligned
identifier dct:identifier rdfs:Literal O 0..n Aligned
rights holder dct:rightsHolder foaf:Organization O 0..1 New!
subject dct:subject skos:Concept O 0..n New!
temporal coverage dct:temporal dct:PeriodOfTime O 0..n Aligned
qualified attribution prov:qualifiedAttribution prov:Attribution O 0..n Aligned

Mandatory Properties

Property: title
Property Title
Requirement level Mandatory
Cardinality 1..n
URI dcterms:title
Range rdfs:Literal
Usage Note
  • The title of the catalog in the indicated language
  • This property can be repeated for parallel language versions of the description (see )

Property: description

Property description
Requirement level Mandatory
Cardinality 1..n
URI dct:description
Range rdfs:Literal
Definition Free-text description of the catalog (in the language indicated in the attribute).
Usage Note
  • This property contains a free-text account of the data Catalog (in the language indicated in the attribute).
  • This property can be repeated for parallel language versions of the description (see ).

Property: publisher

Property publisher
Requirement level Mandatory
Cardinality 1..1
URI dct:publisher
Range foaf:Agent
Definition Entity responsible for making the catalog available.
Usage Note
  • This property refers to an entity (organisation) responsible for making the Catalog available.

Property: dataset

Property dataset
Requirement level Mandatory
Cardinality 1..n
URI dcat:dataset
Range dcat:Dataset
Definition Dataset that is part of the catalog.
Usage Note
  • This property links the Catalog with a Dataset that is part of the Catalog.
  • As empty Catalogs are usually indications of problems, this property SHOULD be combined with the property service to implement an empty Catalog check.

Optional Properties

Property: creator

Property creator
Requirement level Optional
Cardinality 0..n
URI dct:creator
Range dct:Agent
Usage Note
  • This property refers to the license under which the Catalog can be used or reused.
  • CV to be used: [[DATA-GOV-LICENSE]]

Property: access rights

Property access rights
Requirement level Optional
Cardinality 0..1
URI dct:accessRights
Range dct:RightsStatement
Usage Note
  • This property refers to information that indicates whether the Catalog is open data, has access restrictions or is not public.
  • CV to be used: [[DATA-GOV-AR]].

Property: catalog

Property catalog
Requirement level Optional
Cardinality 0..n
URI dcat:catalog
Range dcat:Catalog
Usage Note
  • This property refers to a catalog whose contents are of interest in the context of this catalog.

Property: contact point

Property contact point
Requirement level Optional
Cardinality 0..n
URI dcat:contactPoint
Range vcard:Kind
Usage Note
  • Relevant contact information for the cataloged resource. Use of vCard is recommended

Property: keyword/tag

Property keyword/tag
Requirement level Optional
Cardinality 0..n
URI dcat:keyword
Range rdfs:Literal
Usage Note
  • A keyword or tag describing the resource.

Property: has part

Property has part
Requirement level Optional
Cardinality 0..n
URI dcterms:hasPart
Range dcat:Catalog
Usage Note
  • This property refers to a related catalog that is part of the described catalog.

Property: catalog record

Property catalog record
Definition: A record describing the registration of a single resource (e.g., a dataset, a data service) that is part of the catalog.
Requirement level Optional
Cardinality 0..n
URI dcat:record
Range dcat:CatalogRecord
Usage Note

Property: service

Property service
Requirement level Optional
Cardinality 0..n
URI dcat:service
Range dcat:DataService
Usage Note
  • This property refers to a site or end-point (Data Service) that is listed in the Catalog.
  • As empty Catalogs are usually indications of problems, this property SHOULD be combined with the property Dataset to implement an empty Catalog check.

Property: theme/category

Property theme/category
Requirement level Optional
Cardinality 0..n
URI dcat:theme
Range skos:Concept
Usage Note
  • This property refers to a category of the Catalog. A Catalog may be associated with multiple themes.
  • CV to be used: [[DATA-GOV-THEME]]

Property: identifier

Property identifier
Requirement level Optional
Cardinality 0..n
URI dct:identifier
Range rdfs:Literal
Usage Note
  • This property contains the main identifier for the Catalog, e.g. the URI or other unique identifier.

Property:rights holder

Property rights holder
Requirement level Optional
Cardinality 0..n
URI dcterms:rightsHolder
Range foaf:Organization
Usage Note
  • This property refers to an organisation holding rights on the Catalog.

Property: subject

Property subject
Requirement level Optional
Cardinality 0..n
URI dcterms:subject
Range skos:Concept
Usage Note

Property: temporal coverage

Property temporal coverage
Requirement level Optional
Cardinality 0..n
URI dct:temporal
Range dct:PeriodOfTime
Usage Note
  • This property refers to a temporal period that the Catalog covers.

Property: qualified attribution

Property qualified attribution
Requirement level Optional
Cardinality 0..n
URI prov:qualifiedAttribution
Range prov:Attribution
Usage Note
  • This property refers to a link to an Agent having some form of responsibility for the Catalog.

Example

Class: Catalog Record

RDF Class: dcat:CatalogRecord
Definition: A record in a catalog, describing the registration of a single dcat:Resource.
Usage note: This class is optional and not all catalogs will use it. It exists for catalogs where a distinction is made between metadata about a dataset or service and metadata about the entry in the catalog about the dataset or service. For example, the publication date property of the dataset reflects the date when the information was originally made available by the publishing agency, while the publication date of the catalog record is the date when the dataset was added to the catalog. In cases where both dates differ, or where only the latter is known, the publication date SHOULD only be specified for the catalog record. Notice that the W3C PROV Ontology [[?PROV-O]] allows describing further provenance information such as the details of the process and the agent involved in a particular change to a dataset or its registration.
Rationale While its use is not mandatory, the incorporation of dcat:CatalogRecord into DCAT-US 3.0 holds significant value. It enables catalogs to distinguish between metadata describing datasets or services and the actual catalog entries. This differentiation proves especially advantageous for ensuring adherence to application profiles that demand specific metadata for catalog records. Furthermore, it streamlines resource lifecycle management, empowering catalogs to monitor alterations and revisions to their entries, ultimately bolstering data governance and quality assurance protocols.

Properties Summary

Property URI Range ReqLevel Card
application profile dct:conformsTo dct:Standard R 0..1
change type adms:status skos:Concept R 0..1
description dct:description rdfs:Literal O 0..n
language dct:language dct:LinguisticSystem O 0..n
listing date dct:issued rdfs:Literal (typed as xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth) O 0..n
modification date dct:modified rdfs:Literal (typed as xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth) M 1..1
primary topic foaf:primaryTopic dcat:Resource M 1..1
source metadata dct:source dcat:Resource O 0..1
title dct:title rdfs:Literal O 0..n

Mandatory Properties

Property: modification date

Property modification date
Requirement level Mandatory
Cardinality 1..1
URI dct:modified
Range rdfs:Literal (typed as xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth)
Definition The most recent date on which the Catalog entry was changed or modified.

Property: primary topic

Property primary topic
Requirement level Mandatory
Cardinality 1..1
URI foaf:primaryTopic
Range dcat:Resource
Definition A link to the Dataset, Data service or Catalog described in the record.
Usage note: A catalog record will refer to one entity in a catalog. This can be either a Dataset or a Data Service. To ensure an unambigous reading of the cardinality the range is set to Cataloged Resource. However it is not the intend with this range to require the explicit use of the class Cataloged Record. As abstract class, an subclass should be used.

Optional Properties

Property: description

Property description
Requirement level Optional
Cardinality 0..n
URI dct:description
Range rdfs:Literal
Definition A free-text account of the record. This property can be repeated for parallel language versions of the description.

Property: language

Property language
Requirement level Optional
Cardinality 0..n
URI dct:language
Range dct:LinguisticSystem
Definition A language used in the textual metadata describing titles, descriptions, etc. of the Dataset.
Usage Note This property can be repeated if the metadata is provided in multiple languages.

Property: listing date

Property listing date
Requirement level Optional
Cardinality 0..n
URI dct:issued
Range rdfs:Literal (typed as xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth)
Definition The date on which the description of the Dataset was included in the Catalogue.

Property: source metadata

Property source metadata
Requirement level Optional
Cardinality 0..1/td>
URI dct:source
Range dcat:Resource
Definition The original metadata that was used in creating metadata for the Dataset.

Property: title

Property title
Requirement level Optional
Cardinality 0..n
URI dct:title
Range rdfs:Literal
Definition A name given to the Catalog Record.
Usage note This property can be repeated for parallel language versions of the name.

Class: Checksum

RDF Class: spdx:Checksum
Definition: A Checksum is a value that allows to check the integrity of the contents of a file. Even small changes to the content of the file will change its checksum. This class allows the results of a variety of checksum and cryptographic message digest algorithms to be represented [[SPDX]].
Usage note:
  • The Checksum includes the algorithm (spdx:algorithm) and value (spdx:checksumValue) that allows the integrity of a file to be verified to ensure no errors occurred in transmission or storage.

Properties Summary

Property URI Range ReqLevel Card
algorithm spdx:algorithm spdx:ChecksumAlgorithm M 1..1
checksum value spdx:checksumValue xsd:hexBinary M 1..1

Mandatory Properties

Property: algorithm

Property algorithm
Requirement level Mandatory
Cardinality 1..1
URI spdx:algorithm
Range spdx:ChecksumAlgorithm
Definition The algorithm used to produce the subject Checksum.

Property: checksum value

Property checksum value
Requirement level Mandatory
Cardinality 1..1
URI spdx:checksumValue
Range xsd:hexBinary
Definition A lower case hexadecimal encoded digest value produced using a specific algorithm.

Example

Class: Concept

RDF Class: skos:Concept
Definition: A controlled vocabulary term used to classify Catalog, Dataset, or Data Service.
Usage note:
  • Following FAIR Vocabulary principles, Concept URI should be made resolvable and accessible using SKOS encoding and provided in Linked Data format (RDF/XML,TTL, JSON-LD, NTriples)
  • Ensure FAIR Resolvability: Make Concept URIs resolvable using FAIR principles, allowing them to be Findable, Accessible, Interoperable, and Reusable. This ensures that skos:Concept instances can be easily discovered, accessed, integrated with other resources, and reused across the DCAT-US ecosystem, promoting data interoperability and accessibility.
  • To enhance data interoperability and consistency, it is advisable to reuse established controlled vocabularies such as GCMD, Agrovoc, and NAICS for data description.
Rationale: The inclusion of skos:Concept in DCAT-US 3.0 enhances semantic search in catalogs, enabling more accurate discovery of Catalogs, Datasets, and Data Services. It improves user experience, promotes data discoverability, and supports better resource utilization. Additionally, it aligns with international standards like SKOS, ensuring compatibility and adherence to recognized controlled vocabulary practices.

Properties Summary

Property URI Range ReqLevel Card
alternate label skos:altLabel rdfs:Literal O 0..n
definition skos:definition rdfs:Literal R 0..n
in scheme skos:inScheme skos:ConceptScheme M 1..1
notation skos:notation xsd:string O 0..n
preferred label skos:prefLabel rdfs:Literal M 1.n

Mandatory Properties

Property: preferred label

Property preferred label
Requirement level Mandatory
Cardinality 0..n
URI skos:prefLabel
Range rdfs:Literal
Definition Preferred label for the controlled vocabulary term (one per

Property: concept scheme

Property in scheme
Requirement level Mandatory
Cardinality 1
URI skos:inScheme
Range skos:ConceptScheme
Definition Concept scheme defining the concept

Optional Properties

Property: alternate label

Property alternate label
Requirement level Optional
Cardinality 0..n
URI skos:altLabel
Range rdfs:Literal
Definition alternative labels for a concept

Property: notation

Property notation
Requirement level Optional
Cardinality 0..n
URI skos:notation
Range xsd:string
Definition abbreviations or codes from code lists for an organization

Example

Class: Concept Scheme

RDF Class: skos:ConceptScheme
Definition: A concept collection (e.g. controlled vocabulary) in which a concept is defined.
Usage note:
  • Following FAIR Vocabulary principles, Concept Scheme URI should be made resolvable and accessible using SKOS encoding and provided in Linked Data format (RDF/XML,TTL, JSON-LD, NTriples)
  • To enhance data interoperability and consistency, it is advisable to reuse established controlled vocabularies such as GCMD, Agrovoc, and NAICS for data description.
Rationale: The introduction of skos:ConceptScheme in DCAT-US 3.0 enhances data resource organization, categorization, and accessibility. It provides a structured framework for controlled vocabularies, aligning with FAIR Vocabulary principles for improved data interoperability and discoverability.

Properties

Property URI Range ReqLevel Card
title dcterms:title rdfs:Literal M 1..n
description dcterms:description rdfs:Literal R 0..n
created dcterms:created xsd:date O 0..1
issued dcterms:issued rdfs:Literal (typed as xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth) O 0..1
modified dcterms:modified rdfs:Literal (typed as xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth) O 0..1
version info dcat:version xsd:string O 0..1

Mandatory Properties

Property: title

Property title
Requirement level Mandatory
Cardinality 0..n
URI dcterms:title
Range rdfs:Literal

Optional Properties

Property: created

Property created
Requirement level Optional
Cardinality 0..1
URI dcterms:created
Range rdfs:Literal (typed as xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth)
Definition This property contains the date on which the Concept Scheme has been first created.

Property: issued

Property issued
Requirement level Optional
Cardinality 0..1
URI dcterms:issued
Range rdfs:Literal (typed as xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth)
Definition This property contains the date of formal issuance (e.g., publication) of the Concept Scheme.

Property: modified

Property modified
Requirement level Optional
Cardinality 0..1
URI dcterms:modified
Range rdfs:Literal (typed as xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth)
Definition This property contains the most recent date on which the Concept Scheme was changed or modified.

Property: version

Property version
Requirement level Optional
Cardinality 0..1
URI dcat:version
Range xsd:string
Definition This property contains a version number or other version designation of the Concept Scheme.

Examples

Class: Contact

RDF Class: vcard:Contact
Definition: Point of Contact information
Usage note:
Rationale: The introduction of vcard:Contact in DCAT-US 3.0 is driven by the need for standardized, reliable, and interoperable Point of Contact information, ultimately improving the accessibility and usability of data resources within the DCAT-US ecosystem.

Properties Summary

Property URI Range ReqLevel Card
formatted name vcard:fn xsd:string M 1
email vcard:email rdfs:Resource M 1

Mandatory Properties

Property: formatted name

Property formatted name
Requirement level Mandatory
Cardinality 1
URI vcard:fn
Range xsd:string
Definition The formatted text corresponding to the name of the contact

Property: email

Property email
Requirement level Mandatory
Cardinality 1
URI vcard:email
Range rdfs:Resource
Definition

Example

Class: CUI Restriction

Controlled Unclassified Information (CUI) is information that requires safeguarding or dissemination controls pursuant to and consistent with applicable law, regulations, and government-wide policies but is not classified.

RDF Class: dcat-us:CuiRestriction
Definition: Represents Controlled Unclassified Information (CUI), which is information that requires safeguarding or dissemination controls in accordance with applicable laws, regulations, and government-wide policies but is not classified as confidential.
Usage note:
  • The CUI Restriction class is designed to capture information related to Controlled Unclassified Information (CUI) in accordance with NARA guidelines.
  • Users of this class must provide the mandatory properties, i.e the CUI banner marking and designation indicator, to accurately describe the CUI status of a resource.
  • The optional property, "required indicator per authority," allows for additional information or context about CUI restrictions, providing flexibility for specific use cases.
Rationale: The introduction of the dcat-us:CuiRestriction class in DCAT-US 3.0 is driven by the need for compliance with National Archives and Records Administration (NARA) guidelines regarding Controlled Unclassified Information (CUI). This addition ensures that DCAT-US aligns with NARA's standards, promotes transparency, facilitates compliance audits, and supports efficient resource management. Ultimately, it enhances data interoperability and security within the government data ecosystem.

Properties Summary

Property URI Range ReqLevel Card
cui banner marking dcat-us:cuiBannerMarking xsd:string M 1..1
cui designation indicator dcat-us:designationIndicator xsd:string M 1..1
required indicator per authority dcat-us:requiredIndicatorPerAuthority xsd:string O 0..n

Mandatory Properties

Property: CUI banner marking

Property CUI banner marking
Requirement level Mandatory
Cardinality 1
URI dcat-us:cuiBannerMarking
Range xsd:string
Definition CUI (Controlled Unclassified Information) banner marking is required for any unclassified information that is deemed sensitive and requires protection.

Property: designation indicator

Property Designation Indicator
Requirement level Mandatory
Cardinality 1
URI dcat-us:designationIndicator
Range xsd:string
Definition Designation Indicator show which agency made the document CUI. free text per NARA Marking Guidebook and DODI 5200.48 (should have at least "controlled by:).It is best practice to include contact information.

Optional Properties

Property: required indicator per authority

Property Required indicator per authority
Requirement level Optional
Cardinality 0..n
URI dcat-us:requiredIndicatorPerAuthority
Range xsd:string
Definition free text (e.g., text of the category description or the distribution statement)

Class: Data Service

RDF Class: dcat:DataService
Definition: A collection of operations that provides access to one or more datasets or data processing functions.
Sub-class of: dcat:Resource
Sub-class of: dctype:Service
Usage note:
  • If a dcat:DataService is bound to one or more specified Datasets, they are indicated by the dcat:servesDataset property.
  • The kind of service can be indicated using the dcterms:type property. Its value may be taken from a controlled vocabulary such as the Data.GOV spatial data service type code list [[DATA-GOV-SDST]].
Rationale: Introducing dcat:DataService is essential as it clarifies the representation of data services, addressing the confusion caused by using dcat:Distribution to describe services in DCAT 1. This addition promotes clear communication of service-related information, improving discoverability, and facilitating seamless integration and usage by data consumers and applications.
Property URI Range ReqLevel Card
endpoint URL dcat:endpointURL rdfs:Resource M 1..n
Contact Point dcat:contactPoint vcard:Kind M 1..n
Publisher dct:publisher foaf:Agent M 1..1
Title dcterms:title rdfs:Literal M 1..n
endpoint description dct:endpointDescription rdfs:Resource R 0..n
license dct:license dct:LicenseDocument R 0..1
serves dataset dcat:servesDataset dcat:Dataset R 0..n
Keyword dcat:keyword rdfs:Literal O 0..n
spatial resolution in meters dcat:spatialResolutionInMeters xsd:decimal O 0..n
temporal resolution dcat:temporalResolution rdfs:Literal typed xsd:duration O 0..n
theme/category dcat:theme skos:Concept O 0..n
access rights dct:accessRights dct:RightsStatement O 0..1
conforms to dct:conformsTo dct:Standard O 0..n
creation date dct:created rdfs:Literal typed as xsd:date or xsd:dateTime O 0..1
creator dct:creator dct:Agent O 0..n
description dcterms:description rdfs:Literal O O..n
identifier dcterms:identifier rdfs:Literal O 0..n
language dct:language dct:LinguisticSystem O 0..n
update/modification date dct:modified rdfs:Literal (typed as xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth) O 0..1
Rights dct:rights dct:RightsStatement O 0..n
rights holder dct:rightsHolder foaf:Organization O 0..n
spatial/geographic coverage dct:spatial dct:Location O 0..n
termporal coverage dct:temporal dct:PeriodOfTime O 0..n
type dct:type skos:Concept O 0..1
spatial resolution dqv:hasQualityMeasurement dqv:QualityMeasurement O 0..n
has policy odrl:hasPolicy odrl:Policy O 0..n
qualified attribution prov:qualifiedAttribution prov:Attribution O 0..n
was used by prov:wasUsedBy prov:Activity O 0..n
geographic bounding box dcat-us:geographicBoundingBox dcat-us:GeographicBoundingBox O 0..n

Mandatory Properties

Property: endpoint URL

RDF Property dcat:endpointURL
Requirement level Mandatory
Cardinality 1..n
URI dcat:endpointURL
Range rdfs:Resource
Usage Note The root location or primary endpoint of the service (a Web-resolvable IRI)

Property: contact point

Property contact Point
Requirement level Mandatory
Cardinality 1..n
URI dcat:contactPoint
Range vcard:Kind
Usage Note
  • This property contains contact information that can be used for sending comments about the Dataset.
  • This property MUST contain an email address that is continuously monitored by the data publisher.
  • If there are several contributors involved in the publication of the Dataset, the property can be used multiple times.

Property: publisher

Property publisher
Requirement level Mandatory
Cardinality 1..1
URI dct:publisher
Range foaf:Agent
Definition This property refers to an entity (organisation) responsible for making the Data Service available.
Usage Note This property refers to an entity (organisation) responsible for making the Catalog available.

Property: title

Property title
Requirement level Mandatory
Cardinality 1..n
URI dcterms:title
Range rdfs:Literal
Usage Note
  • The title of the catalog in the indicated language
  • This property can be repeated for parallel language versions of the description (see )

Optional Properties

Property: keyword

Property keyword
Requirement level Optional
Cardinality 0..n
URI dcat:keyword
Range rdfs:Literal
Usage Note This property contains a keyword or tag describing the Data Service.

Property: spatial resolution in meters

Property spatial resolution in meters
Requirement level Optional
Cardinality 0..n
URI dcat:spatialResolutionInMeters
Range xsd:decimal
Usage Note This property refers to the minimum spatial separation resolvable in a Data Service, measured in metres.

Property: temporal resolution

Property temporal resolution
Requirement level Optional
Cardinality 0..n
URI dcat:temporalResolution
Range rdfs:Literal typed as xsd:duration
Usage Note This property refers to the minimum time period resolvable in the Data Service.

Property: theme/category

Property theme/category
Requirement level Optional
Cardinality 0..n
URI dcat:theme
Range skos:Concept
Usage Note
  • This property refers to a Category of the Data Service. A Data Service may be associated with multiple Categories.
  • CV to be used: [[DATA-GOV-THEME]]

Property: access rights

Property access rights
Requirement level Optional
Cardinality 0..1
URI dct:accessRights
Range dct:RightsStatement
Usage Note
  • This property MAY include information regarding access or restrictions based on privacy, security, or other policies.
  • CV must be used: [[DATA-GOV-AR]]

Property: conforms to

Property conforms to
Requirement level Optional
Cardinality 0..n
URI dct:conformsTo
Range dct:Standard
Usage Note This property is used to indicate the general standard or specification that the Data Service endpoints implement.

Property: creation date

Property creation date
Requirement level Optional
Cardinality 0..1
URI dct:created
Range rdfs:Literal typed as xsd:date or xsd:dateTime
Usage Note This property contains the date on which the Data Service has been first created.

Property: creator

Property creator
Requirement level Optional
Cardinality 0..n
URI dct:creator
Range foaf:Agent
Usage Note This property refers to the Agent primarily responsible for producing the Data Service.

Property: description

Property description
Requirement level Optional
Cardinality 0..n
URI dct:description
Range rdfs:Literal
Usage Note
  • This property contains a free-text account of the Data Service.
  • This property can be repeated for parallel language versions of the description (see ). On the user interface of data portals, the content of the element whose language corresponds to the display language selected by the user is displayed.

Property: identifier

Property identifier
Requirement level Optional
Cardinality 0..n
URI dct:identifier
Range rdfs:Literal
Usage Note This property contains the main identifier for the Data Service, e.g. the URI or other unique identifier in the context of the Catalog.

Property: language

Property language
Requirement level Optional
Optional 0..n
URI dct:language
Range dct:LinguisticSystem
Usage Note
  • This property refers to a language supported by the Data Service. This property can be repeated if multiple languages are supported in the Data Service.
  • CV to be used: [[ISO 639-1]]

Property: update/ modification date

Property update/ modification date
Requirement level Optional
Cardinality 0..1
URI dct:modified
Range rdfs:Literal (typed as xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth)
Usage Note This property contains the most recent date on which the Data Service was changed or modified.

Property: rights

Property rights
Requirement level Optional
Cardinality 0..n
URI dct:rights
Range dct:RightsStatement
Usage Note A statement that concerns all rights for the Data Service not addressed with dcterms:license or dcterms:accessRights, such as copyright statements.

Property: rights holder

Property rights holder
Requirement level Optional
Cardinality 0..n
URI dcterms:rightsHolder
Range foaf:Organization
Usage Note This property refers to an Agent (organisation) holding rights on the Data Service.

Property: spatial/geographic coverage

Property spatial/geographic coverage
Requirement level Optional
Cardinality 0..n
URI dct:spatial
Range dct:Location
Usage Note
  • This property refers to a geographic region that is covered by the Data Service.
  • TO DISCUSS: Conventions to be used: The Vocabularies Name Authority Lists MUST be used for continents, countries and places that are in those lists; if a particular location is not in one of the mentioned Named Authority Lists, Geonames URIs MUST be used: [[DATA-GOV-CONT]], [[DATA-GOV-COUNTRY]], [[DATA-GOV-PLACE]], [[GEONAMES]]

Property: temporal coverage

Property temporal coverage
Requirement level Optional
Cardinality 0..n
URI dct:temporal
Range dct:PeriodOfTime
Usage Note This property refers to a temporal period that the Data Service covers.

Property: type

Property type
Requirement level Optional
Cardinality 0..1
URI dcterms:type
Range skos:Concept
Usage Note

Property: spatial resolution

Property spatial resolution
Requirement level Optional
Cardinality 0..n
URI dqv:hasQualityMeasurement
Range dqv:QualityMeasurement
Usage Note
  • Refers to the performed quality measurements.
  • In GeoDCAT-AP, this property is used to specify "spatial resolution", as defined in [INSPIRE-MD-REG], [ISO-19115], and [ISO-19115-1].

Property: has policy

RDF Property: odrl:hasPolicy
Definition: An ODRL conformant policy expressing the rights associated with the Data Service.
Range: odrl:Policy
Usage note: Information about rights expressed as an ODRL policy [[ODRL-MODEL]] using the ODRL vocabulary [[ODRL-VOCAB]] MAY be provided for the Data Service.

Property: qualified attribution

Property qualified attribution
Requirement level Optional
Cardinality 0..n
URI prov:qualifiedAttribution
Range prov:Attribution
Usage Note This property refers to a link to an Agent having some form of responsibility for the Data Service.

Property: was used by

Property was used by
Requirement level Optional
Cardinality 0..n
URI prov:wasUsedBy
Range prov:Activity
Usage Note
  • This property refers to an Activity that used the Data Service.
  • This property MAY be used to specify a testing Activity over a Data Service, against a given Standard, producing as output a conformance degree.

Property: geographic bounding box

Property geographic bounding box
Requirement level Optional
Cardinality 0..n
URI dcat-us:geographicBoundingBox
Range dcat-us:GeographicBoundingBox
Usage Note

Example

Class: Dataset

A Dataset is a collection of data, published or curated by a single source and related by a common idea or concept. In contrast to a Data Service a Dataset is expected to be a collection of data that is available for access or download in one or more formats, as Distributions. Distributions belonging to the same Dataset should not differ in regards to the idea of the data that they represent. They may differ in regards to the physical representation of the data such as format or resolution. Or they may split the data of the dataset into portions of comparable size such as data per time period or location.

DCAT 3 provides guidelines about the usage of Data services and Distribution in relation to Datasets [[VOCAB-DCAT-3]].:

RDF Class: dcat:Dataset
Definition: A collection of data, published or curated by a single agent, and available for access or download in one or more representations.
Subclass Of: dcat:Resource
Usage note:
  • This class describes the conceptual dataset. One or more representations might be available, with differing schematic layouts and formats or serializations.
  • This class describes the actual dataset as published by the dataset provider. In cases where a distinction between the actual dataset and its entry in the catalog is necessary (because metadata such as modification date might differ), the dcat:CatalogRecord class can be used for the latter.
  • The notion of dataset in DCAT is broad and inclusive, with the intention of accommodating resource types arising from all communities. Data comes in many forms including numbers, text, pixels, imagery, sound and other multi-media, and potentially other types, any of which might be collected into a dataset.
Rationale: The update of dcat:Dataset is crucial as it aligns the DCAT profile with international standards, offering a standardized and widely recognized way to describe datasets. This alignment enhances data interoperability and discoverability, enabling data publishers to provide structured metadata, improving data sharing, and facilitating seamless integration for users and applications.
Property URI Range ReqLevel Card Changes from DCAT-US 1.1
title dcterms:title rdfs:Literal M 1..n Multilingual support
description dcterms:description rdfs:Literal M 1..n Multilingual support
identifier dcterms:identifier rdfs:Literal M 1..n No Change
contact point dcat:contactPoint vcard:Contact R 0..n No Change
dataset distribution dcat:distribution dcat:Distribution R 0..n No Change
spatial/geographical coverage dct:spatial dct:Location R 0..n Fixed
keyword/tag dcat:keyword rdfs:Literal R 0..n No Change
landing page dcat:landingPage foaf:Document R 0..n No Change
update/modification date dct:modified rdfs:Literal (typed as xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth) R 0..1 No Change
publisher dct:publisher foaf:Agent R 0..1 No Change
geographic bounding box dcat-us:geographicBoundingBox dcat-us:GeographicBoundingBox R 0..n New!
temporal coverage dct:temporal dct:PeriodOfTime R 0..n Fixed
theme/category dcat:theme skos:Concept R 0..n Fixed
access rights dct:accessRights dct:RightsStatement O 0..1 Aligned
conforms to dct:conformsTo dct:Standard O 0..n No Change
creator dct:creator dct:Agent O 0..n Aligned
documentation foaf:page foaf:Document O 0..n New!
frequency dct:accrualPeriodicity dct:Frequency O 0..1 Fixed
has version dcat:hasVersion dcat:Dataset O 0..n Aligned
is referenced by dct:isReferencedBy rdfs:Resource O 0..n Aligned
language dct:language dct:LinguisticSystem O 0..n Fixed
other identifier adms:identifier adms:Identifier O 0..n New!
provenance dct:provenance dct:ProvenanceStatement O 0..n New!
qualified attribution prov:qualifiedAttribution prov:Attribution O 0..n Aligned
qualified relation dcat:qualifiedRelation dcat:Relationship O 0..n Aligned
related resource dct:relation rdfs:Resource O 0..n Aligned
release date dct:issued rdfs:Literal (typed as xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth) O 0..1 No Change
sample adms:sample dcat:Distribution O 0..n New!
source dct:source dcat:Dataset O 0..n New!
quality measurement dqv:hasQualityMeasurement dqv:QualityMeasurement O 0..n Aligned
spatial resolution in meters dcat:spatialResolutionInMeters rdfs:Literal (typed as xsd:decimal) O 0..n Aligned
temporal resolution dcat:temporalResolution rdfs:Literal (typed as xsd:duration) O 0..n Aligned
category dct:type skos:Concept O 0..1 Aligned
version dcat:version rdfs:Literal O 0..n Aligned
version notes adms:versionNotes rdfs:Literal O 0..n New!
was generated by prov:wasGeneratedBy prov:Activity O 0..n New!
program dcat-us:program dcat-us:Program O 0..n New!
investment dcat-us:investment dcat-us:Investment O 0..n New!
application legislation dcat-us:applicableLegislation dcat-us:Legislation O 0..n New!
supported schema adms:supportedSchema dcat:Dataset O 0..1 New!
metadata distribution dcat-us:metadataDistribution dcat:Distribution O 0..n New!
liability statement dcat-us:liabilityStatement dcat-us:LiabilityStatement O 0..1 New!
purpose dcat-us:purpose rdfs:Literal O 0..n New!
contributor dct:contributor dct:Agent O 0..n New!
image schema:image schema:url or schema:ImageObject O 0..n New!
related resource vann:usageNote rdfs:Resource O 0..n New!

Mandatory Properties

Property: title

Property Title
Requirement level Mandatory
Cardinality 1..n
URI dcterms:title
Range rdfs:Literal
Usage Note
  • This property contains a name given to the Dataset.
  • This property can be repeated for parallel language versions of the title (see Multilingualism).

Property: description

Property description
Requirement level Mandatory
Cardinality 1..n
URI dct:description
Range rdfs:Literal
Usage Note
  • This property contains a free-text account of the Dataset.
  • This property can be repeated for parallel language versions of the description (see Multilingualism). On the user interface of data portals, the content of the element whose language corresponds to the display language selected by the user is displayed.

Property: identifier

Property identifier
Requirement level Mandatory
Cardinality 1..n
URI dct:identifier
Range rdfs:Literal
Usage Note
  • This property contains the unique identifier for the Dataset, e.g. the URI or other unique identifier in the context of the Catalog.
  • The identifier may be used as part of the URI of the Dataset.

Optional Properties

Property: access rights

Property access rights
Requirement level Optional
Cardinality 0..1
URI dct:accessRights
Range dct:RightsStatement
Usage Note
  • This property refers to information that indicates whether the Dataset is open data, has access restrictions or is not public.
  • CV to be used: [[DATA-GOV-AR]].

Property: conforms to

Property conforms to
Requirement level Optional
Cardinality 0..n
URI dct:conformsTo
Range dct:Standard
Usage Note
  • This property refers to an implementing rule or other specification.
  • This property SHOULD be used to indicate the model, schema, ontology, view or profile that this representation of a Dataset conforms to. This is (generally) a complementary concern to the media-type or format.

Property: contributor

Property contributor
Requirement level Optional
Cardinality 0..n
URI dct:contributor
Range foaf:Agent
Usage Note This property refers to an agent contributing to the Dataset.

Property: creator

Property creator
Requirement level Optional
Cardinality 0..1
URI dct:creator
Range foaf:Agent
Usage Note This property refers to an entity responsible for producing the dataset.

Property: documentation

Property documentation
Requirement level Optional
Cardinality 0..n
URI foaf:page
Range foaf:Document
Usage Note This property refers to a page or document about this Dataset.

Property: frequency

Property frequency
Requirement level Optional
Cardinality 0..1
URI dct:accrualPeriodicity
Range dct:Frequency
Usage Note
  • This property refers to the frequency at which the Dataset is updated.
  • CV to be used: [[CLD-FREQ]].

Property: has version

RDF Property: dcat:hasVersion
Definition: This resource has a more specific, versioned resource [[PAV]].
Equivalent property: pav:hasVersion
Sub-property of: dcterms:hasVersion
Sub-property of: prov:generalizationOf
Usage note:

A related Dataset that is a version, edition, or adaptation of the described Dataset.

Property: is referenced by

Property is referenced by
Requirement level Optional
Cardinality 0..n
URI dct:isReferencedBy
Range rdfs:Resource
Usage Note This property is about a related resource, such as a publication, that references, cites, or otherwise points to the Dataset.

Property: language

Property language
Requirement level Optional
Optional 0..n
URI dct:language
Range dct:LinguisticSystem
Usage Note
  • This property refers to a language of the Dataset. This property can be repeated if there are multiple languages in the Dataset.
  • CV to be used: [[ISO 639-1]]

Property: other identifier

Property other identifier
Requirement level Optional
Optional 0..n
URI adms:identifier
Range adms:Identifier
Usage Note A secondary identifier of the Dataset, such as MAST/ADS17, DataCite18, DOI19, EZID20 or W3ID21.

Property: provenance

Property provenance
Requirement level Optional
Optional 0..n
URI dct:provenance
Range dct:ProvenanceStatement
Definition
  • A statement of any changes in ownership and custody of the resource since its creation that are significant for its authenticity, integrity, and interpretation.
Usage Note This property contains a statement about the lineage of a Dataset.

Property: qualified attribution

Property qualified attribution
Requirement level Optional
Cardinality 0..n
URI prov:qualifiedAttribution
Range prov:Attribution
Usage Note This property refers to a link to an Agent having some form of responsibility for the resource.

Property: qualified relation

Property qualified relation
Requirement level Optional
Cardinality 0..n
URI dcat:qualifiedRelation
Range dcat:Relationship
Usage Note
  • This property provides a link to a description of a relationship with another resource and it is especially meant for relationships between Datasets.
  • It replaces the property rdfs:seeAlso of DCAT-US v1.
  • See here for examples on how to use it: dcat:qualifiedRelation.

Property: release date

Property release date
Requirement level Optional
Cardinality 0..1
URI dct:issued
Range rdfs:Literal (typed as xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth)
Usage Note
  • This property contains the date of formal issuance (e.g., first publication) of the Dataset.
  • If this date is not known, the date of the first referencing of the data collection in the Catalog can be entered.

Property: sample

Property sample
Requirement level Optional
Cardinality 0..n
URI adms:sample
Range dcat:Distribution
Definition
  • Links to a sample of an Dataset, which is a dcat:Distribution.

Property: source

Property source
Requirement level Optional
Cardinality 0..n
URI dct:source
Range dcat:Dataset
Usage Note A related Dataset from which the described Dataset is derived.

Property: spatial resolution

Property spatial resolution
Requirement level Optional
Cardinality 0..n
URI dqv:hasQualityMeasurement
Range dqv:QualityMeasurement
Usage Note
  • Refers to the performed quality measurements.
  • In GeoDCAT-AP, this property is used to specify "spatial resolution", as defined in [ISO-19115], and [ISO-19115-1].

Property: spatial resolution in meters

Property spatial resolution in meters
Requirement level Optional
Cardinality 0..n
URI dcat:spatialResolutionInMeters
Range rdfs:Literal (typed as xsd:decimal)
Usage Note
  • If the dataset is an image or grid this should correspond to the spacing of items. For other kinds of spatial datasets, this property will usually indicate the smallest distance between items in the dataset.
  • The range of this property is a decimal number representing a length in meters. This is intended to provide a summary indication of the spatial resolution of the data as a single number. More complex descriptions of various aspects of spatial precision, accuracy, resolution and other statistics can be provided using the Data Quality Vocabulary [VOCAB-DQV].

Property: temporal resolution

Property temporal resolution
Requirement level Optional
Cardinality 0..n
URI dcat:temporalResolution
Range rdfs:Literal (typed as xsd:duration)
Usage Note
  • If the dataset is a time-series this should correspond to the spacing of items in the series. For other kinds of dataset, this property will usually indicate the smallest time difference between items in the dataset
  • This is intended to provide a summary indication of the temporal resolution of the dataset as a single value. More complex descriptions of various aspects of temporal precision, accuracy, resolution and other statistics can be provided using the Data Quality Vocabulary [VOCAB-DQV].

Property: type

Property type
Requirement level Optional
Cardinality 0..1
URI dct:type
Range skos:Concept
Usage Note
  • A type of the Dataset.
  • A recommended controlled vocabulary data-type is foreseen.

Property: version

Property version
Requirement level Optional
Cardinality 0..n
URI dcat:version
Range rdfs:Literal
Usage Note The version indicator (name or identifier) of a resource.

Property: version notes

Property version notes
Requirement level Optional
Cardinality 0..n
URI adms:versionNotes
Range rdfs:Literal
Usage Note
  • A description of the differences between this version and a previous version of the Dataset.
  • This property can be repeated for parallel language versions of the version notes.

Property: was generated by

Property was generated by
Requirement level Optional
Cardinality 0..n
URI prov:wasGeneratedBy
Range prov:Activity
Usage Note An activity that generated, or provides the business context for, the creation of the dataset.

Property: program

Property program
Requirement level Optional
Cardinality 0..n
URI dcat-us:program
Range dcat-us:Program
Usage Note
  • TO-DO

Property: investment

Property investment
Requirement level Optional
Cardinality 0..n
URI dcat-us:investment
Range dcat-us:Investment
Usage Note
  • TO-DO

Property: applicable legislation

Property applicable legislation
Requirement level Optional
Cardinality 0..n
URI dcat-us:applicableLegislation
Range dcat-us:Legislation
Usage Note
  • TO-DO

Property: supported schema

Property supported schema
Requirement level Optional
Cardinality 0..1
URI adms:supportedSchema
Range dcat:Dataset
Usage Note
  • TO-DO

Property: metadata distribution

Property metadata distribution
Requirement level Optional
Cardinality 0..n
URI dcat-us:metadataDistribution
Range dcat:Distribution
Usage Note Distribution to "original" metadata document

Property: liability statement

Property liability statement
Requirement level Optional
Cardinality 0..1
URI dcat-us:liabilityStatement
Range dcat-us:LiabilityStatement
Usage Note A liability statement about the dataset

Property: purpose

Property purpose
Requirement level Optional
Cardinality 0..n
URI dcat-us:purpose
Range rdfs:Literal
Usage Note The purpose of the dataset

Property: image

Property image
Requirement level Optional
Cardinality 0..3
URI schema:image
Range schema:url or schema:ImageObject
Definition A thumbnail picture illustrating the content of the dataset.
Usage Note
  • A thumbnail picture illustrating the content of the Dataset.
  • For distributions that consist of visual content (photographs, videos, maps, etc.) it makes sense to add a limited number of thumbnails to the metadata.
  • It’s a DCAT-US Custom Class

Property: usage note

Property usage note
Requirement level Optional
Cardinality 0..n
URI vann:usageNote

Class: Dataset Series

RDF Class: dcat:DatasetSeries
Definition: A collection of datasets that are published separately, but share some characteristics that group them.
Subclass Of: dcat:Resource
Usage note:
  • Dataset series can be also soft-typed via property dcterms:type as in the approach used in [[GeoDCAT-AP]]
  • Common scenarios for dataset series include: time series composed of periodically released subsets; map-series composed of items of the same type or theme but with differing spatial footprints.
Rationale: Incorporating dcat:DatasetSeries is essential to enable the structured grouping and presentation of related datasets, ensuring that data publishers can convey meaningful collections of data. This facilitates efficient data organization and discovery for users, aligning the DCAT profile with international standards for dataset series representation.
Property URI Range ReqLevel Card
title dcterms:title rdfs:Literal M 1..n
description dcterms:description rdfs:Literal M 1..n
contact point dcat:contactPoint vcard:Kind R 0..n
first dcat:first dcat:Dataset R 0..1
spatial/geographical coverage dct:spatial dct:Location R 0..n
last dcat:last dcat:Dataset R 0..1
update/modification date dct:modified rdfs:Literal (typed as xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth) R 0..1
publisher dct:publisher foaf:Agent R 0..1
series member dcat:seriesMember dcat:Dataset R 0..1
temporal coverage dct:temporal dct:PeriodOfTime R 0..n
frequency dct:accrualPeriodicity dct:Frequency O 0..1
release date dct:issued rdfs:Literal (typed as xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth) O 0..1

Mandatory Properties

Property: title

Property Title
Requirement level Mandatory
Cardinality 1..n
URI dcterms:title
Range rdfs:Literal
Usage Note
  • This property contains a name given to the Dataset Series.
  • This property can be repeated for parallel language versions of the name (see Multilingualism).

Property: description

Property description
Requirement level Mandatory
Cardinality 1..n
URI dct:description
Range rdfs:Literal
Usage Note
  • This property contains a free-text account of the Dataset Series.
  • This property can be repeated for parallel language versions of the description (see Multilingualism). It is recommended to provide an indication about the dimensions the Dataset Series evolves.

Optional Properties

Property: frequency

Property frequency
Requirement level Optional
Cardinality 0..1
URI dct:accrualPeriodicity
Range dct:Frequency
Usage Note
  • This property refers to the frequency at which the Dataset Series is updated.
  • The frequency of a dataset series is not equal to the frequency of the dataset in the collection.
  • CV to be used: [[CLD-FREQ]].

Property: release date

Property release date
Requirement level Optional
Cardinality 0..1
URI dct:issued
Range rdfs:Literal (typed as xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth)
Usage Note
  • This property contains the date of formal issuance (e.g.,publication) of the Dataset Series.
  • The moment when the dataset series was established as a managed resource. This is not equal to the release date of the oldest dataset in the collection of the dataset series.

Example

Class: Distribution

In the context of the DCAT-US profile, a metadata entry of this class serves to characterize a distribution of data, which constitutes a specific representation of a Dataset. Datasets within this profile may offer multiple serializations, each potentially differing in various aspects, including natural language, media type or format, schematic organization, temporal and spatial resolution, level of detail, or profiles that specify any combination of these attributes.

A distribution may encompass the entirety of the Dataset's data or only a subset thereof. For example, it could encompass all data related to the population in the United States or focus exclusively on a specific year, such as 2020. Alternatively, it might provide the data in an alternate format, such as a graphical representation covering the years 2010 through 2020.

Within the DCAT-US profile, various relationships between Datasets and their distributions are represented. The most straightforward relationship involves aggregating different physical representations of data, referred to as "Distributions," into a single Dataset. An example of such a Dataset is a time series, where each distribution corresponds to one year of data, and the Dataset spans multiple years.

In the DCAT vocabulary, dcat:Distribution is employed to characterize the diverse representations and formats in which a dataset is disseminated, facilitating the description of different versions or media types of the same data, and often includes properties like dcat:downloadURL for direct download links. On the other hand, dcat:DataService serves the purpose of detailing data access services, such as APIs and endpoints, enabling programmatic or interactive data retrieval, with key properties like dcat:endpointURL specifying service endpoints and dcat:serviceType indicating the type of service, thus distinguishing between the description of data formats and the specification of data access services within the DCAT framework.

RDF Class: dcat:Distribution
Definition: A specific representation of a dataset. A dataset might be available in multiple serializations that may differ in various ways, including natural language, media-type or format, schematic organization, temporal and spatial resolution, level of detail or profiles (which might specify any or all of the above).
Subclass Of: dcat:Resource
Usage note:
  • This represents a general availability of a dataset. It implies no information about the actual access method of the data, i.e., whether by direct download, API, or through a Web page. The use of dcat:downloadURL property indicates directly downloadable distributions.
Rationale: The update to DCAT 3 dcat:Distribution is of paramount significance as it greatly enhances data accessibility. It introduces a more comprehensive and structured approach to describing data distributions, ensuring that data consumers can easily understand and access the data in the format that best suits their needs, ultimately fostering greater data utilization and dissemination.
Property URI Range ReqLevel Card Changes from DCAT-US 1.1
access URL dcat:accessURL rdfs:Resource M 1..n No Change
license dct:license dct:LicenseDocument M 1..1 Aligned
availability dcatap:availability skos:Concept R 0..1 New!
description dct:description rdfs:Literal R 0..n Multilingual support
format dct:format dcterms:MediaType R 0..1 Fixed
rights dct:rights dct:RightsStatement R 0..1 Aligned
access Restriction dcat-us:accessRestriction dcat-us:AccessRestriction R 0..n New!
usage restriction dcat-us:useRestriction dcat-us:UseRestriction R 0..n New!
cui Restriction dcat-us:cuiRestriction dcat-us:CuiRestriction R 0..1 New!
title dcterms:title rdfs:Literal R 0..n Multilingual support
update/ modification date dct:modified rdfs:Literal (typed as xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth) R 0..1 Aligned
representation technique adms:representationTechnique skos:Concept O 0..1 New!
status adms:status skos:Concept O 0..1 Aligned
character encoding cnt:characterEncoding rdfs:Literal O 0..n New!
compression format dcat:compressFormat dcterms:MediaType O 0..1 Aligned
spatial resolution in meters dcat:spatialResolutionInMeters xsd:decimal O 0..1 Aligned
access rights dct:accessRights dct:RightsStatement O 0..1 Aligned
access service dcat:accessService dcat:DataService O 0..n Aligned
byte size dcat:byteSize rdfs:Literal (typed as xsd:decimal) O 0..1 Aligned
checksum spdx:checksum spdx:Checksum O 0..1 Aligned
documentation foaf:page foaf:Document O 0..n New!
download URL dcat:downloadURL rdfs:Resource O 0..n No Change
identifier dct:identifier rdfs:Literal O 0..1 Aligned
image schema:image schema:url or schema:ImageObject O 0..3 New!
language dct:language dct:LinguisticSystem O 0..n Aligned
linked schemas dct:conformsTo dct:Standard O 0..n unchanged
media type dcat:mediaType dct:MediaType O 0..1 Fixed
packaging format dcat:packageFormat dcterms:MediaType O 0..1 Aligned
release date dct:issued rdfs:Literal (typed as xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth) R 0..1 Aligned
temporal resolution dcat:temporalResolution xsd:duration R 0..1 Aligned

Mandatory Properties

Property: access URL

Property access URL
Requirement level Mandatory
Cardinality 1..n
URI dcat:accessURL
Range rdfs:Resource
Usage Note
  • This property contains a URL that gives access to a Distribution of the Dataset. The resource at the access URL may contain information about how to get the Dataset.

Property: license

Property license
Requirement level Mandatory
Cardinality 1..1
URI dct:license
Range dct:LicenseDocument
Usage Note
  • This property refers to the license under which the Distribution is made available.
  • CV to used: [[DATA-GOV-LICENSE]]

Optional Properties

Property: representation technique

Property representation technique
Requirement level Optional
Cardinality 0..1
URI adms:representationTechnique
Range skos:Concept
Usage Note This property MAY be used to provide more information about the format in which an Distribution is released. This is different from the file format as, for example, a ZIP file (file format) could contain an XML schema (representation technique).

Property: status

Property status
Requirement level Optional
Cardinality 0..1
URI adms:status
Range skos:Concept
Usage Note This property refers to the maturity of the Distribution. It MUST take one of the values Completed, Deprecated, Under Development, Withdrawn from the ADMS status [[VOCAB-ADMS-SKOS] vocabulary.

Property: character encoding

Property character encoding
Requirement level Optional
Cardinality 0..n
URI cnt:characterEncoding
Range rdfs:Literal
Usage Note This property SHOULD be used to specify the character encoding of the Distribution, by using as value the character set names in the IANA register [[IANA-CHARSETS]].

Property: compression format

Property compression format
Requirement level Optional
Cardinality 0..1
URI dcat:compressFormat
Range dcterms:MediaType
Usage Note This property refers to the format of the file in which the data is contained in a compressed form, e.g., to reduce the size of the downloadable file. It SHOULD be expressed using a media type as defined in the official register of media types managed by IANA [[IANA-MEDIA-TYPES]].

Property: spatial resolution in meters

Property spatial resolution in meters
Requirement level Optional
Cardinality 0..n
URI dcat:spatialResolutionInMeters
Range xsd:decimal
Usage Note
  • This property refers to the minimum spatial separation resolvable in a Distribution, measured in meters.

Property: access rights

Property access rights
Requirement level Optional
Cardinality 0..1
URI dct:accessRights
Range dct:RightsStatement
Usage Note
  • This property MAY include information regarding access or restrictions based on privacy, security, or other policies.

Property: access service

Property access service
Requirement level Optional
Cardinality 0..n
URI dcat:accessService
Range dcat:DataService
Usage Note This property refers to a data service that gives access to the distribution of the Dataset

Property: byte size

Property byte size
Requirement level Optional
Cardinality 0..1
URI dcat:byteSize
Range rdfs:Literal (typed as xsd:decimal).
Usage Note This property contains the size of a Distribution in bytes. If the precise size is not known, an approximate size can be indicated.

Property: checksum

Property checksum
Requirement level Optional
Cardinality 0..1
URI spdx:checksum
Range spdx:Checksum
Usage Note
  • This property provides a mechanism that can be used to verify that the contents of a distribution have not changed.
  • The checksum is related to the downloadURL.
  • Property added in [[VOCAB-DCAT-3]]: spdx:checksum

Property: coverage

Property coverage
Requirement level Optional
Cardinality 0..n
URI dct:coverage
Range dct:LocationPeriodOrJurisdiction
Usage Note
  • If a dataset contains distributions that differ regarding their content beyond just differences in format or resolution this property can be used to specify temporal or spatial coverage of the data that the distribution contains.
  • It’s a DCAT-US Custom Class.

Property: documentation

Property Documentation
Requirement level Optional
Cardinality 0..n
URI foaf:page
Range foaf:Document
Usage Note This property refers to a page or document about this Distribution.

Property: download URL

Property download URL
Requirement level Optional
Cardinality 0..n
URI dcat:downloadURL
Range rdfs:Resource
Usage Note In case of a downloadable file, it is good practice to repeat the mandatory accessURL in this more specific property, to indicate to the data user that the distribution has this extra characteristic of being downloadable. The downloadURLs MAY thus be the same as the accessURLs but they MAY also differ.

Property: identifier

Property identifier
Requirement level Optional
Cardinality 0..1
URI dct:identifier
Range rdfs:Literal
Usage Note An identifier for the distribution, that identifies it as a resource mainly for the organisation publishing the data.

Property: image

Property image
Requirement level Optional
Cardinality 0..3
URI schema:image
Range schema:url or schema:ImageObject
Usage Note
  • A thumbnail picture illustrating the content of the Distribution.
  • For distributions that consist of visual content (photographs, videos, maps, etc.) it makes sense to add a limited number of thumbnails to the metadata.
  • It’s a DCAT-US Custom Class (not present in [[DCAT-AP]]).

Property: language

Property Language
Requirement level Optional
Cardinality 0..n
URI dct:language
Range rdfs:Literal
Usage Note
  • This property refers to a language used in the Distribution.
  • This property can be repeated if the metadata is provided in multiple languages.
  • The property MUST be set if the distribution is language-dependent, or if it is given in some of the languages German, French, Italian and English but not in all four languages.
  • CV to be used: [[ISO 639-1]]

Property: linked schemas

Property linked schemas
Requirement level Optional
Cardinality 0..n
URI dct:conformsTo
Range dct:Standard
Usage Note This property refers to a page or document about this Data Service.

Property: media type

Property media type
Requirement level Optional
Cardinality 0..1
URI dcat:mediaType
Range dct:MediaType
Usage Note
  • This property refers to the media type of the Distribution as defined in the official register of media types managed by IANA.
  • Der Wert des Elements "dcat:mediaType" muss einem MIME Type gemäss IANA entsprechen: [[IANA-MEDIA-TYPES]].

Property: packaging format

Property packaging format
Requirement level Optional
Cardinality 0..1
URI dcat:packageFormat
Range dct:MediaType
Usage Note
  • This property refers to the format of the file in which one or more data files are grouped together, e.g. to enable a set of related files to be downloaded together.
  • It SHOULD be expressed using a media type as defined in the official register of media types managed by IANA.

Property: release date

Property release date
Requirement level Optional
Cardinality 0..1
URI dct:issued
Range rdfs:Literal (typed as xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth)
Usage Note
  • This property contains the date of formal issuance (e.g., publication) of the Distribution.
  • Date of formal issuance (publication) of the distribution
  • UsageThe first time issuance of the distribution.

Property: temporal resolution

Property temporal resolution
Requirement level Optional
Cardinality 0..1
URI dcat:temporalResolution
Range xsd:duration
Usage Note This property refers to the minimum time period resolvable in the Dataset distribution.

Example

Class: Document

RDF Class: foaf:Document
Obligation Optional
Definition: A publication - as a scientific paper, a techni cal report, a book, book chapter, but also a blog post.
Usage note: Depending on whether a catalog supports or not publications as first-class citizens, a publication can be fully described, or simply denoted by its URI.
Rationale: The introduction of foaf:Document significantly improves the representation of documents within the DCAT-US profile. It ensures that metadata about documents, such as title, format, language, and access options, are clearly defined and standardized. This alignment with global data standards fosters interoperability and eases document integration into various data ecosystems, benefiting both publishers and consumers.
Reference

§ Class: foaf:Document [FOAF]

Properties Summary

Property URI Range ReqLevel Card
title dcterms:title rdfs:Literal M 1..n
individual author dcterms:creator foaf:Person O 0..n
corporate author dcterms:creator org:Organization O 0..n
author(s) as literal dc:creator rdfs:Literal M 1
publisher organization dcterms:publisher org:Organization M 1
publisher(s) as literal dc:publisher rdfs:Literal M 1
identifier dcterms:identifier rdfs:Literal R 0..1
publication date dcterms:issued rdfs:Literal (typed as xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth) M 1
bibliographic citation dcterms:bibliographicCitation rdfs:Literal R 0..1
document type dcterms:type skos:Concept R 0..1
abstract dcterms:abstract rdfs:Literal O 0..n
description dcterms:description rdfs:Literal R 0..n
conforms to dcterms:conformsTo dct:Standard O 0..n
media type dcterms:mediaType dct:MediaType O 0..n

Mandatory Properties

Property: author(s) as literal

Property author(s) as literal
Requirement level Mandatory
Cardinality 1..n
URI dc:creator
Range rdfs:Literal
Usage Note

Property: publisher(s) as literal

Property publisher(s) as literal
Requirement level Mandatory
Cardinality 1..n
URI dc:publisher
Range rdfs:Literal
Usage Note

Property: publication date

Property publication date
Requirement level Mandatory
Cardinality 1..n
URI dcterms:issued
Range rdfs:Literal
Usage Note

Property: publisher organization

Property publisher organization
Requirement level Mandatory
Cardinality 1..n
URI dcterms:publisher
Range org:Organization
Usage Note

Property: title

Property title
Requirement level Mandatory
Cardinality 1..n
URI dcterms:title
Range rdfs:Literal
Usage Note

Optional Properties

Property: abstract

Property abstract
Requirement level Optional
Cardinality 0..n
URI dcterms:abstract
Range rdfs:Literal
Usage Note

Property: individual author

Property individual author
Requirement level Optional
Cardinality 0..n
URI dct:creator
Range foaf:Person
Usage Note

Property: corporate author

Property corporate author
Requirement level Optional
Cardinality 0..n
URI dct:creator
Range org:Organization
Usage Note

Property: conforms to

Property conforms to
Requirement level Optional
Cardinality 0..n
URI dcterms:identifier
Range dct:Standard
Usage Note An implementing rule or other specification.

Property: media type

Property media type
Requirement level Optional
Cardinality 0..n
URI dcterms:mediaType
Range dct:MediaType
Usage Note An implementing rule or other specification.

Class: Geographic Bounding Box

GeographicBoundingBox describes the spatial extent of domain of application of an resource and is standardized in WGS 84 Lat/Long coordinate system.

RDF Class: dcat-us:GeographicBoundingBox
Definition: GeographicBoundingBox describes the spatial extent of domain of application of an resource and is standardized in WGS 84 Lat/Long coordinate system.
Usage note: Strongly recommended for geospatial data
Rationale There is no consensus and common vocabulary to describe spatial bounding box in the community. GML Envelope was proposed but it is too cumbersome to process. We introduce four separates fields for each bound (west, east, north and south) that removes any ambiguity and make it easy to index and query

Properties Summary

Property URI Range ReqLevel Card
west bounding longitude dcat-us:westBoundingLongitude xsd:decimal M 1
east bounding longitude dcat-us:eastBoundingLongitude xsd:decimal M 1
south bouding latitude dcat-us:southBoundingLatitude xsd:decimal M 1
north bounding latitude dcat-us:northBoundingLatitude xsd:decimal M 1

Mandatory Properties

Property: west bounding longitude

Property west bounding longitude
Requirement level Mandatory
Cardinality 1
URI dcat-us:westBoundingLongitude
Range xsd:decimal
Definition West bound longitude in decimal degrees

Property: east bounding longitude

Property east bounding longitude
Requirement level Mandatory
Cardinality 1
URI dcat-us:eastBoundingLongitude
Range xsd:decimal
Definition East bound longitude in decimal degrees

Property: south bounding latitude

Property south bounding latitude
Requirement level Mandatory
Cardinality 1
URI dcat-us:southBoundingLatitude
Range xsd:decimal
Definition South bound latitude in decimal degrees

Property: north bounding latitude

Property north bounding latitude
Requirement level Mandatory
Cardinality 1
URI dcat-us:southBoundingLatitude
Range xsd:decimal
Definition North bound latitude in decimal degrees

Example

Class: Identifier

RDF Class: adms:Identifier
Obligation Optional
Definition: This is based on the UN/CEFACT Identifier class.
Usage note: An identifier in a particular context, consisting of the
  • content string that is the identifier;
  • an optional identifier for the identifier scheme;
  • an optional identifier for the version of the identifier scheme;
  • an optional identifier for the agency that manages the identifier scheme.
Reference

§ Term name: Identifier [ADMS]

Rationale Incorporating adms:Identifier in the DCAT-US profile fosters a culture of data governance and trust by transparently documenting the authority behind each identifier. This enhances data reliability and credibility, boosting confidence for DCAT-US users. Additionally, it enables versatile data access using multiple identifiers, enhancing overall data accessibility and usability for diverse stakeholders.

Properties Summary

Property URI Range ReqLevel Card
notation skos:notation xsd:string R 0..1
creator dct:creator dct:Agent O 0..1
schema agency adms:schemaAgency rdfs:Literal O 0..1
version dcat:version rdfs:Literal O 0..1
issued dct:issued rdfs:Literal (typed as xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth) O 0..1

Optional Properties

Property: creator

Property creator
Requirement level Optional
Cardinality 0..1
URI dct:creator
Range dct:Agent

Property: schema agency

Property schema agency
Requirement level Optional
Cardinality 0..1
URI adms:schemaAgency
Range rdfs:Literal

Property: version

Property version
Requirement level Optional
Cardinality 0..1
URI dcat:version
Range rdfs:Literal

Property: issued

Property issued
Requirement level Optional
Cardinality 0..1
URI dct:issued
Range rdfs:Literal (typed as xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth)

Class: Investment

Class: Liability Statement

RDF Class: dcat-us:LiabilityStatement
Definition: A formal declaration accompanying a dataset which outlines the responsibilities and limitations of the data provider in terms of the accuracy, completeness, and potential use of the data. It often serves to limit the legal exposure of the data provider by defining the scope of allowed uses and disclaiming warranties or guarantees.
Usage note:
  • The LiabilityStatement should be attached to a dcat:Dataset to indicate the terms and conditions of the dataset's usage.
  • This statement should provide information on:
    • The accuracy or completeness of the dataset.
    • Limitations on how the dataset may be used.
    • Any disclaimers or lack of guarantees/warranties.
    • Indemnification details.
  • The statement may be provided as a literal text or as a URL pointing to a detailed liability statement.
  • Utilizing the LiabilityStatement helps in setting clear expectations for consumers of the dataset and limits potential legal exposures of the data provider.
Rationale Introducing dcat-us:LiabilityStatement in DCAT-US clarifies data provider responsibilities and limitations, reducing legal risks by defining acceptable uses and disclaiming warranties. This ensures transparency and legal compliance in data sharing within the United States.

Properties Summary

Property URI Range ReqLevel Card
liability statement text rdfs:label rdfs:Literal O 0..n

Optional Properties

Property: liability statement text

Property liability statement text
Requirement level Optional
Cardinality 0..n
URI rdfs:label
Range rdfs:Literal
Definition Full text of the liability statement.
Usage Notes Property rdfs:label MAY only be used to specify the text of liability statement information. This property can be repeated for parallel language versions of the description

Example

Class: LicenseDocument

RDF Class: dcterms:LicenseDocument
Obligation Optional
Definition: A legal document giving official permission to do something with a resource.
Usage note: Licence document SHOULD be specified only with URIs from an endorsed Data.gov registry. Property spdx:licenseText MAY only be used to specify license information in legacy metadata records, not compliant with standard license from an endorsed Data.Gov registry.
Rationale: The introduction of dcterms:LicenseDocument in the DCAT profile enables the customization of license text. This flexibility empowers data publishers to tailor license terms to specific dataset requirements, facilitating clear communication of licensing conditions and promoting responsible data sharing and usage while adhering to established international standards.
Reference

§ Term name: LicenseDocument [DCTERMS]

Properties Summary

Property URI Range ReqLevel Card
license text spdx:licenseText rdfs:Literal O 0..n

Optional Properties

Property: license text

Property license text
Requirement level Optional
Cardinality 0..n
URI spdx:licenseText
Range rdfs:Literal
Definition Full text of the license.
Usage Notes Property spdx:licenseText MAY only be used to specify license information in legacy metadata records, not compliant with standard license from an endorsed registry. This property can be repeated for parallel language versions of the description

Example

Class: Location

A spatial region or named place.

RDF Class: dcterms:Location
Definition: A spatial region or named place. It can be represented using a controlled vocabulary or with geographic coordinates.
Usage note:
  • For an extensive geometry (i.e., a set of coordinates denoting the vertices of the relevant geographic area), the property locn:geometry [[LOCN]] SHOULD be used.
  • For a geographic bounding box delimiting a spatial area the property dcat:bbox SHOULD be used.
  • For the geographic center of a spatial area, or another characteristic point, the property dcat:centroid SHOULD be used.
Rationale: The introduction of dcterms:Location in DCAT-US 3.0 is driven by the need to restore compatibility with the DCAT standard. DCAT-US 1.1 had deviated from the standard by using strings for location in dct:spatial property, which was incompatible. This addition aligns DCAT-US with recognized geospatial standards (e.g., Geosparql, WKT, GeoJSON, W3C Location) for representing geometries, addresses, and location names, ensuring data compatibility, discoverability, and integration while adhering to international data management practices.

Properties Summary

Property URI Range ReqLevel Card
bounding box dcat:bbox rdfs:Literal typed as gsp:wktLiteral or gsp:gmlLiteral. R 0..1
centroid dcat:centroid rdfs:Literal typed as gsp:wktLiteral or gsp:gmlLiteral. O 0..1
geographic identifier dcterms:identifier rdfs:Literal O 0..n
geometry locn:geometry locn:Geometry O 0..1
gazetteer skos:inScheme skos:ConceptScheme O 0..1
geographic name skos:prefLabel rdfs:Literal typed as gsp:wktLiteral or gsp:gmlLiteral. M 1..n

Mandatory Properties

Property: geographic name

RDF Property skos:prefLabel
Requirement level Mandatory
Cardinality 1..n
Range rdfs:Literal typed as geosparql:wktLiteral or geosparql:gmlLiteral
Usage Note This property contains a preferred label of the Location. This property can be repeated for parallel language versions of the label.

Optional Properties

Property: centroid

Property centroid
Requirement level Optional
Cardinality 0..1
URI dcat:centroid
Range rdfs:Literal typed as geosparql:wktLiteral or geosparql:gmlLiteral
Usage Note
  • The range of this property (rdfs:Literal) is intentionally generic, with the purpose of allowing different geometry literal encodings. E.g., the geometry could be encoded as a WKT literal (geosparql:wktLiteral)
  • Please note that the order of usage is as follows: use the most specific geospatial relationship by preference. E.g. if the spatial description is a bbox, use dcat:bbox, otherwise use locn:geometry
  • The WKT encoding supports geospatial positions expressed in coordinate reference systems other than WGS84.

Property: geographic identifier

Property geographic identifier
Requirement level Optional
Cardinality 0..n
URI dcterms:identifier
Range rdfs:Literal
Usage Note This property contains the geographic identifier for the Location, e.g., the URI or other unique identifier in the context of the relevant gazetteer.

Property: geometry

Property geometry
Requirement level Optional
Cardinality 0..1
URI locn:geometry
Range locn:Geometry
Definition: Associates a spatial thing [[?SDW-BP]] with a corresponding geometry.
Usage Note The range of this property (locn:Geometry) allows for any type of geometry specification. E.g., the geometry could be encoded by a literal, as WKT (geosparql:wktLiteral [[GeoSPARQL]]), or represented by a class, as geosparql:Geometry (or any of its subclasses) [[GeoSPARQL]].

Property: gazetteer

RDF Property skos:inScheme
Requirement level Optional
Cardinality 0..1
Range skos:ConceptScheme
Usage Notes: This property MAY be used to specify the gazetteer to which the Location belongs.

Class: MediaType

RDF Class: dcterms:MediaType
Obligation Optional
Definition: A media type, e.g. the format of a computer file.
Usage Note: Data publishers should consider using well-established IANA [[IANA-MEDIA-TYPES]] URLs for media types whenever possible to enhance compatibility and interoperability. However, the ability to create custom media types using labels provides flexibility for unique data requirements. When creating custom media types, it's advisable to provide clear and concise definitions to ensure transparency and understanding for data consumers. Striking a balance between standardized and custom media types optimizes data sharing within the DCAT-US framework.
Rationale: Incorporating dcterms:MediaType in DCAT-US combines the use of established IANA [[IANA-MEDIA-TYPES]] URLs for standardized media types with the flexibility to create custom types using labels. This dual approach ensures compatibility with recognized media types while allowing adaptability to specific needs, promoting both data interoperability and flexibility in data sharing and dissemination.
Reference

§ Term name: MediaType [DCTERMS]

Properties Summary

Property URI Range ReqLevel Card
label rdfs:label xsd:string R 0..1

Class: Metric

RDF Class: dqv:Metric
Obligation Optional
Definition: Represents a standard to measure a quality dimension. An observation (instance of dqv:QualityMeasurement) assigns a value in a given unit to a Metric.
Usage note: The concept of a metric is used to define and measure specific aspects or dimensions of data quality within a given context, providing a standardized and quantifiable way to assess the quality of data. It allows for the comparison and evaluation of data quality across different resources and enables the development of consistent quality assessment frameworks and methodologies.
Rationale: Introducing dqv:Metric in the DCAT-US profile enhances dataset quality assessment and management by aligning with international data quality standards. It allows data publishers to systematically define and communicate dataset quality characteristics, promoting transparency and informed data utilization, fostering trust, and supporting responsible data sharing within the DCAT-US ecosystem.
Reference

§ 4.1 Class: Metric [VOCAB-DQV]

Properties Summary

Property URI Range ReqLevel Card
in dimension dqv:inDimension dqv:Dimension M 1
expected DataType dqv:expectedDataType xsd:anySimpleType M 1
definition skos:definition rdfs:Literal R 0..n

Mandatory Properties

Property: in dimension

Property in dimension
Requirement level Mandatory
Cardinality 1
URI dqv:inDimension
Range dqv:Dimension
Definition Represents the dimensions a quality metric, certificate and annotation allow a measurement of.

Property: expected datatype

Property expected datatype
Requirement level Mandatory
Cardinality 1
URI dqv:expectedDataType
Range xsd:anySimpleType
Definition Represents the expected data type for the metric's observed value (e.g., xsd:boolean, xsd:double etc...)

Example

Class: Organization

TODO

RDF Class: org:Organization
Definition: Represents a collection of people organized together into a community or other social, commercial or political structure. The group has some common purpose or reason for existence which goes beyond the set of people belonging to it and can act as an Agent. Organizations are often decomposable into hierarchical structures.
Subclass Of: foaf:Agent
Usage note: When utilizing the org:Organization class in DCAT-US 3.0, data publishers are encouraged to provide the preferred label (skos:prefLabel) for the organization, along with any relevant alternative labels (skos:altLabel) and abbreviations skos:notation. This usage is consistent with the W3C Organization Recommendation standard [[VOCAB-ORG]].This practice ensures comprehensive and flexible organization identification, improving data discoverability and search accuracy. Data publishers should strive to maintain consistency in naming conventions while considering variations and common aliases used to refer to organizations. By providing a well-rounded representation of organizations, DCAT-US 3.0 enhances data usability and transparency, facilitating efficient data search and retrieval.
Rationale: Improving the org:Organization class in DCAT-US 3.0 by supporting prefLabel, alternative labels, and abbreviations is essential to enhance organization representation. This enhancement accommodates variations in organization naming, promotes data interoperability, and improves discoverability within datasets. By incorporating these features, DCAT-US 3.0 aligns with best practices in data representation, enhances data search and transparency, and optimizes the overall usability of data resources.

Properties Summary

Property URI Range ReqLevel Card Changes from DCAT-US 1.1
name foaf:name xsd:string M 1..1 No Change
preferred label skos:prefLabel xsd:string O 0..1 Aligned
alternative label skos:altLabel xsd:string O 0..n Aligned
notation skos:notation xsd:string O 0..n Aligned
subOrganizationOf org:subOrganizationOf org:Organization O 0..1 No Change

Mandatory Properties

Property: name

Property name
Requirement level Mandatory
Cardinality 1
URI foaf:name
Range xsd:string
Definition The name of the Organization

Optional Properties

Property: preferred label

Property preferred label
Requirement level Optional
Cardinality 0..1
URI skos:prefLabel
Range xsd:string
Definition The legal name or preferred name of the Organization

Property: alternate label

Property alternate label
Requirement level Optional
Cardinality 0..n
URI skos:altLabel
Range xsd:string
Definition alternative names (trading names, colloquial names) for an organization

Property: notation

Property notation
Requirement level Optional
Cardinality 0..n
URI skos:notation
Range xsd:string
Definition abbreviations or codes from code lists for an organization (e.g. DOI, DOD)

Property: suborganization of

Property sub organization of
Requirement level Optional
Cardinality 0..n
URI org:subOrganizationOf
Range org:Organization
Definition Represents hierarchical containment of Organizations or OrganizationalUnits; indicates an Organization which contains this Organization.

Example

Class: Period of Time

PeriodOfTime represents a period of time with a start date and an end.

RDF Class: dct:PeriodOfTime
Definition: PeriodOfTime represents a period of time with a start date and an end.
Usage note: The start and end of the interval SHOULD be given by using properties dcat:startDate, and dcat:endDate, respectively. The interval can also be open - i.e., it can have just a start or just an end.
Rationale: The introduction of dct:PeriodOfTime in DCAT-US 3.0 is pivotal for harmonizing with international standards and rectifying the inconsistency with DCAT 1. In DCAT-US 1.1, [[ISO8601-1]] was used for interval representation in dct:temporal, diverging from DCAT 1's requirement of dct:PeriodOfTime. This alignment with DCAT 3 standards in DCAT-US 3.0 not only resolves discrepancies but also streamlines data processing, simplifying parsing and indexing of time intervals. By adopting dct:PeriodOfTime, DCAT-US 3.0 promotes ease of implementation, ensuring uniformity, flexibility, accuracy, and enhanced interoperability in handling time-related data, ultimately benefiting data usability and exchange.
Property URI Range ReqLevel Card
start date dcat:startDate xsd:date R 0..1
end date dcat:endDate xsd:date R 0..1

Example

Class: Person

TODO

RDF Class: foaf:Person
Definition: This class represents an individual human being or a person. It can be used to provide information about individuals, such as their name, email address, homepage URL, and other personal details.
Subclass Of: foaf:Agent
Usage note:
Rationale: The rationale for enhancing the foaf:Person class in DCAT-US 3.0 is to provide a more comprehensive and standardized representation of individuals within datasets. In earlier versions, like DCAT 1.1, only a single "name" property was available for describing persons, limiting the richness of personal data representation. By introducing properties like "firstName," "givenName," and "affiliation," DCAT-US 3.0 aligns with best practices in data representation, allowing data publishers to provide more detailed information about individuals and their affiliations with organizations. This enhancement enhances data usability and transparency.
Property URI Range ReqLevel Card
name foaf_name xsd:string M 1..1

Mandatory Properties

Property: name

Property name
Requirement level Mandatory
Cardinality 1
URI foaf:name
Range xsd:string
Definition The full name of the Person

Optional Properties

Property: affiliation

Property name
Requirement level Optional
Cardinality 0..n
URI org:memberOf
Range org:Organization
Definition This property MAY be used to specify the affiliation of the Person to an organization.

Example

Class: Program

Class: Provenance Statement

RDF Class: dcterms:ProvenanceStatement
Obligation Optional
Definition: Any changes in ownership and custody of a resource since its creation that are significant for its authenticity, integrity, and interpretation.
Usage note: The dcterms:ProvenanceStatement in DCAT-US 3.0 offers flexibility in how it can be referenced. It can either be referred to by a URL or included in-line by using a label. This versatility allows data publishers to choose the most suitable method for providing information about significant changes in ownership and custody, enhancing the accessibility and usability of provenance details within datasets.
Rationale: Introducing dcterms:ProvenanceStatement in DCAT-US 3.0 enhances dataset transparency and trustworthiness. It allows data publishers to provide structured information about significant changes in ownership and custody, aligning with international data quality and provenance standards. This flexibility ensures greater confidence in dataset authenticity and interpretation, promoting responsible data usage within DCAT-US.
Reference

§ Term name: ProvenanceStatement [DCTERMS]

Properties Summary

Property URI Range ReqLevel Card
provenance statement text rdfs:label xsd:string R 0..n

Class: Role

Class: Quality Measurement

RDF Class: dqv:QualityMeasurement
Obligation Optional
Definition: Represents the evaluation of a given dataset (or dataset distribution) against a specific quality metric.
Usage note: Represents the evaluation of a given resource (as a Data Service, Dataset, or Distribution) against a specific quality metric, such as spatial resolution in scale, angle or metric.
Rationale: The inclusion of dqv:QualityMeasurement in DCAT-US assists end-users in better evaluating the fitness of use of resources. This optional class enhances data quality assessment, aligns with international standards (DQV), and enables more precise evaluation against specific quality metrics, ultimately improving data usability and adherence to recognized quality assessment practices.
Reference

§ 4.1 Class: Quality Measurement [VOCAB-DQV]

Properties Summary

Property URI Range ReqLevel Card
is measurement of dqv:isMeasurementOf dqv:Metric M 1
value dqv:value rdfs:Literal M 1
value sdmx-attribute:unitMeasure rdfs:Resource O 0..1

Mandatory Properties

Property: is measurement of

Property is measurement of
Requirement level Mandatory
Cardinality 1
URI dqv:isMeasurementOf
Range dqv:Metric
Definition Indicates the metric being observed.

Property: value

Property value
Requirement level Mandatory
Cardinality 1
URI dqv:value
Range rdfs:Literal
Definition Refers to values computed by metric.

Optional Properties

Property: unit of measure

Property unit of measure
Requirement level Optional
Cardinality 0..1
URI sdmx-attribute:unitMeasure
Range rdfs:Resource
Definition Unit of measure associated with the value

Example

Class: Relationship

RDF Class: dcat:Relationship
Definition: An association class for attaching additional information to a relationship between DCAT Resources
Usage note: Use to characterize a relationship between datasets, and potentially other resources, where the nature of the relationship is known but is not adequately characterized by the standard [[?DCTERMS]] properties (dcterms:hasPart, dcterms:isPartOf, dcterms:conformsTo, dcterms:isFormatOf, dcterms:hasFormat, dcterms:isVersionOf, dcterms:hasVersion, dcterms:replaces, dcterms:isReplacedBy, dcterms:references, dcterms:isReferencedBy, dcterms:requires, dcterms:isRequiredBy) or [[?PROV-O]] properties (prov:wasDerivedFrom, prov:wasInfluencedBy, prov:wasQuotedFrom, prov:wasRevisionOf, prov:hadPrimarySource, prov:alternateOf, prov:specializationOf)
Rationale: The introduction of dcat:Relationship in DCAT-US serves to enhance the representation and description of relationships between datasets and other resources. This class allows for the attachment of additional information to relationships that are not adequately characterized by standard properties, promoting a more comprehensive understanding of dataset connections. By accommodating nuanced relationship types beyond existing standards like [[DCTERMS]] and [[PROV-O]] properties, DCAT-US ensures greater flexibility and precision in documenting dataset relationships, facilitating more informed data discovery and utilization.

Properties Summary

Property URI Range ReqLevel Card
relation dcterms:relation dcat:Resource M 1
role dcat:hadRole dcat:Role M 1

Mandatory Properties

Property: relation

Property relation
Requirement level Mandatory
Cardinality 1
URI dcterms:relation
Range
Definition The resource related to the source resource.

Property: role

Property role
Requirement level Mandatory
Cardinality 1
URI dcat:hadRole
Range dcat:Role
Definition The function of an entity or agent with respect to another entity or resource.

Example

Class: RightsStatement

RDF Class: dcterms:RightsStatement
Obligation Optional
Definition: A statement about the intellectual property rights (IPR) held in or over a resource, a legal document giving official permission to do something with a resource, or a statement about access rights.
Usage note: Information about rights SHOULD be provided on the level of Distribution. Information about rights MAY be provided for a Dataset in addition to but not instead of the information provided for the Distributions of that Dataset. Providing rights information for a Dataset that is different from information provided for a Distribution of that Dataset SHOULD be avoided as this can create legal conflicts.
Rationale: The introduction of dcterms:RightsStatement in DCAT-US is vital for standardizing the conveyance of intellectual property rights (IPR) and access permissions. This optional class accommodates URL references and custom rights statements via attribution text, promoting transparency and compliance. By encouraging consistent rights information at the Distribution and optional Dataset levels, DCAT-US enhances data sharing while reducing legal conflict risks.
Reference

§ Term name: RightsStatement [DCTERMS]

Properties Summary

Property URI Range ReqLevel Card
label rdfs:label rdfs:Literal R 0..n
attribution text odrs:attributionText rdfs:Literal R 0..n

Example

Class: Standard

RDF Class: dct:Standard
Obligation Optional
Definition: A standard or other specification to which a Dataset or Distribution conforms.
Usage note: A standard or other specification to which a Catalog, Catalog Record, Data Service, Dataset, or Distribution conforms
Rationale: The inclusion of dct:Standard in DCAT-US accommodates standard references through URLs or custom, detailed descriptions when specific standards are not available, promoting flexibility and completeness in resource metadata.
Reference

§ Term name: Standard [DCTERMS]

Properties Summary

Property URI Range ReqLevel Card
description dcterms:description rdfs:Literal R 0..n
identifier dcterms:identifier xsd:string R 0..n
issued dcterms:issued xsd:date R 0..1
title dcterms:title rdfs:Literal R 0..n
type dcterms:type skos:Concept R 0..n
version dcat:version xsd:string R 0..1
in scheme skos:inScheme skos:ConceptScheme O 0..1
creation date dcterms:created xsd:date O 0..1
last modified dcterms:modified xsd:date O 0..1

Optional Properties

Property: creation date

Property creation date
Requirement level Optional
Cardinality 0..1
URI dcterms:created
Range xsd:date
Definition This property contains the date on which the Standard has been first created.

Property: last modified

Property last modified
Requirement level Optional
Cardinality 0..1
URI dcterms:modified
Range xsd:date
Definition This property contains the most recent date on which the Standard was changed or modified.

Examples

Class: UseRestriction

A UseRestriction is a set of rules, guidelines, or legal provisions that dictate how a particular resource, asset, information, or object can be utilized. Use restrictions may encompass limitations on access, distribution, reproduction, modification, or sharing, and they are often put in place to protect privacy, intellectual property rights, security, or compliance with legal or ethical standards.

RDF Class: dcat-us:UseRestriction
Definition: A UseRestriction is a set of rules, guidelines, or legal provisions that dictate how a particular resource, asset, information, or object can be utilized. Use restrictions may encompass limitations on access, distribution, reproduction, modification, or sharing, and they are often put in place to protect privacy, intellectual property rights, security, or compliance with legal or ethical standards.
Usage note: When utilizing the dcat-us:UseRestriction class, data publishers are encouraged to provide comprehensive and precise details regarding the specific use restrictions applied to a resource. This may include information on access limitations, distribution rules, reproduction guidelines, modification constraints, and any other pertinent restrictions. Adherence to NARA guidelines and standards should be a priority when defining use restrictions, ensuring that data resources align with archival and preservation practices. By offering clear and concise use restriction information, data consumers can make informed decisions about the utilization of these resources while complying with NARA's requirements.
Rationale: The introduction of dcat-us:UseRestriction in DCAT-US 3.0, aligned with NARA (National Archives and Records Administration) guidelines, enhances compliance and interoperability with NARA-specific use restriction standards. This enables organizations to accurately convey NARA-specific restrictions on data resources, ensuring adherence to archival and data preservation requirements, and promoting consistent data management practices within the DCAT-US framework.

Properties Summary

Property URI Range ReqLevel Card
restriction status dcat-us:restrictionStatus skos:Concept M 1..1
restriction authority dcat-us:authority org:Organization R 0..1
restriction note dcat-us:restrictionNote rdfs:Literal O 0..1

Mandatory Properties

Property: restriction status

Property restriction status
Requirement level Mandatory
Cardinality 1
URI dcat-us:restrictionStatus
Range skos:Concept
Definition Indication of whether or not there are use restrictions on the archival materials

Optional Properties

Property: restriction note

Property restriction note
Requirement level Optional
Cardinality 0..1
URI dcat-us:restrictionNote
Range rdfs:Literal
Definition Significant information pertaining to the use or reproduction of the data.

Usage Guidelines

Dereferenceable identifiers

The FAIR principles, under the Findability and the Accessibility chapters respectively, state that:

In the expansive realm of digital data and ontology, the ability to unambiguously identify and access resources is foundational. this section delves deep into the principles and practices that underpin this crucial aspect of digital data management. Guided by the FAIR principles, this section unravels the nuances of generating resolvable URLs, the importance of URI resolution, the roles of various identifier resolution services, and the distinctions between alternate identifier properties. Through a comprehensive exploration, this section offers insights into ensuring data is not only uniquely identifiable but also consistently accessible in an ever-evolving digital landscape.

Generating Resolvable URLs

In the context of FAIR data, resources on the web must have unique, persistent, and resolvable identifiers. In order to achieve the capability of persistence, it is necessary for the resource identifiers to comply to the RFC 3986 IETF standard for URIs (and IRIs, which are URI extended to cope with unicode). This means that it must comprise the following components:

Identifier Resolution

URI resolution is a fundamental process that involves directing requests to the appropriate identified entity. The standard approach typically entails resolving an HTTP GET request through content negotiation, enabling the selection of different representations of the desired resource.

A PURL, or persistent URL, serves as a permanent address for accessing web resources. To grasp the concept of PURLs, it's essential to first understand the concept of URL indirection (also known as URL redirect or URL forwarding). This practice involves providing a stable and fixed web address/URL that is configured to point to different content, which might undergo periodic modifications.

When a user accesses a PURL, they are automatically redirected to the current location of the resource. This means that when an author decides to relocate a page, they can easily update the PURL to direct it to the new location.

The practice of indirection proves beneficial as it ensures a consistent URL address for resources that are prone to change, such as due to version updates or ownership changes.

A concrete example of this practice can be observed in the utilization of purl.org URLs for identifying OBO Foundry resources. For instance, the URL http://purl.obolibrary.org/obo/stato.owl redirects to the latest release of the file, which can be found at https://raw.githubusercontent.com/ISA-tools/stato/dev/releases/latest_release/stato.owl.

PURLs sharing a common prefix are organized into domains, each managed by a single maintainer. The maintainer has the authority to add new PURLs to the domain and make modifications to existing PURLs within that domain.

According to FAIR Principle A1, it is essential for (meta)data to be retrievable using its identifier. When the identifier itself is not a resolvable URL, Identifier Resolution Services are required. These services possess the capability to map an Internationalized Resource Identifier (IRI) to a specific location where the corresponding data can be accessed.

Identifier Resolution services

In the digital realm, ensuring consistent and persistent access to resources is paramount. Identifier Resolution Services play a crucial role in achieving this by providing unique and persistent identifiers for various digital objects and entities. This section delves into several prominent services, detailing their functions and significance in the broader digital ecosystem.

purl.org
The PURL system is a service of the Internet Archive, which provides an interface to administer domain. For more information about the service, visit https://archive.org/services/purl/help
w3ids

W3IDs.org provides persistent identifiers for Linked Data resources. These identifiers can be used in DCAT to uniquely identify datasets and data services. This can help to improve the discoverability and interoperability of datasets and data services. W3IDs.org is an important part of the Linked Data ecosystem and plays a key role in making data more discoverable and interoperable.

Send a request to add a redirect to the public-perma-id@w3.org mailing list. Make sure to include the URL that you want on w3id.org, the URL that you want to redirect to, and the HTTP code that you want to use when redirecting. An administrator will then create the redirect for you.

doi.org
DOI.org is a digital identifier system that assigns unique and persistent identifiers to digital objects. These identifiers can be used to cite, share, and track digital objects across different platforms and systems. DOI.org identifiers can be used in DCAT to uniquely identify datasets and data services. This can help to improve the discoverability and interoperability of datasets and data services.
orcid.org
ORCID (Open Researcher and Contributor ID) is a global, non-profit organization that provides a unique and persistent identifier for researchers. ORCID IDs are used to link researchers to their professional activities, such as publications, grants, and affiliations. This helps to ensure that researchers are properly credited for their work and that their work is more easily discoverable. ORCID is a valuable tool for researchers, and it is becoming increasingly important as the research landscape becomes more complex.
arxiv.org
ArXiv identifiers are globally unique identifiers (GUIDs) assigned to scholarly articles submitted to the arXiv preprint server. These identifiers can be used in DCAT (Data Catalog Vocabulary) to uniquely identify authors and their publications. This can help to improve the discoverability and interoperability of research data.
Identifiers.org
The Identifiers.org Resolution Service provides consistent access to life science data using Compact Identifiers. Compact Identifiers consist of an assigned unique prefix and a local provider designated accession number (prefix:accession). The resolving location of Compact Identifiers is determined using information that is stored in the Identifiers.org Registry.

Alternate identifiers

In the realm of data cataloging, identifiers play a pivotal role in ensuring the uniqueness, traceability, and interoperability of resources. Different namespaces and vocabularies offer distinct properties to denote identifiers. Here, we discuss three such properties: dcterms:identifier, adms:hasIdentifier, and skos:notation, shedding light on their distinct usages and nuances.

dcterms:identifier

Originating from the Dublin Core Metadata Terms (DCTERMS), dcterms:identifier is a broad and general property used to denote a unique reference for a resource. It does not impose any constraint on the format or nature of the identifier. In essence, it's a flexible property that can be employed across various domains and for diverse types of resources, be they digital documents, physical artifacts, or abstract concepts.

adms:hasIdentifier

The Asset Description Metadata Schema ([[VOCAB-ADMS]]) introduces adms:hasIdentifier. Unlike the more generic dcterms:identifier, this property is more structured. It's designed to link a resource to its identifier, which is itself described using further properties. This allows for a richer description of the identifier, such as specifying its type (e.g., ISBN, DOI), its status, and its version. It's particularly useful in contexts where there's a need to provide additional metadata about the identifier itself, beyond just its value.

skos:notation

skos:notation is a property from the Simple Knowledge Organization System ([[SKOS-REFERENCE]]) vocabulary. It's used to provide a symbolic string notation for a concept. While it can function similarly to an identifier, its primary intention is to give a machine-readable, often standardized, symbolic name to a concept, especially when such a notation exists in a legacy or external system. For example, in a controlled vocabulary, each concept might have a notation that denotes its code in a classification scheme.

Multilingualism

From a technical perspective multilingualism SHOULD be handled as follows:

The table lists multilingual properties of DCAT-US and the translation strategies that apply to them:

Property RDF property Range Multilingual Support
Catalog title dcterms:title rdfs:Literal Language encoded string
Catalog description dct:description rdfs:Literal Language encoded string
Dataset title dcterms:title rdfs:Literal Language encoded string
Dataset description dct:description rdfs:Literal Language encoded string
Dataset keyword dcat:keyword rdfs:Literal Language encoded string
Catalog homepage foaf:homepage foaf:Document Content negotiation
Dataset landing Page dcat:landingPage foaf:Document Content negotiation
Catalog publisher dct:publisher foaf:Agent Content negotiation for the URI and language encoded string for the name
Dataset publisher dct:publisher foaf:Agent Content negotiation for the URI and language encoded string for the name

Agents

Agent

An agent represents an entity involved in producing or managing datasets. It can be either a person, organization, software, or service.

Person

A person agent represents an individual involved in producing or managing datasets. It provides information about the person and their associated contact details.

In the context of a DCAT-US 3.0, the foaf:Person class plays a crucial role. It is used to represent individuals who are associated with or responsible for the datasets or resources described within the DCAT profile.

Let's break down the specific properties associated with foaf:Person and their significance within this context:

  • foaf:name: This property represents the full name of a person. It can be used to specify the full name of individuals associated with datasets. For example, if a person's full name is "John Smith," you can use this property to provide their complete name. This property is the only property mandatory for describing a person and is typically used for display.
  • foaf:firstName: This optional property represents the first name of a person. It is used to provide the first name of individuals associated with or responsible for resources in the DCAT-US profile. It can be used to provide structured information about an individual's first name.
  • foaf:givenName: This optional property represents the given name of a person. It can be used to provide structured information about an individual's name.
  • org:memberOf While not a FOAF property,this property is typically used to indicate the organization or group to which a person is affiliated to. In the context of a DCAT-US profile, it can be used to specify the organization or entity with which an individual is affiliated in relation to the described resources. For instance, if a person is a member of an organization of Department of Interior, you can use this property to link them to that organization identified by http://www.doi.gov.

Organization

An organization agent represents an organization or institution involved in producing or managing a resource. It provides information about the organization responsible for the resource and its associated contact details.

Contact Point

Resource Attributions

Attribution, in the context of a data catalog, refers to the process of associating a particular resource (like a dataset or a service) with a responsible party, often referred to as an "agent". Agents could be individuals, organizations, or services that contribute to, create, publish, or have some significant interaction with the data. These attributions often include details about the role the agent played, such as whether they were a contributor, creator, publisher, funder, distributor, custodian, or editor, etc.

Attributions are critically important for data catalog search for several reasons:

  1. Provenance and Trustworthiness: Attributions help users understand who created or has interacted with the data, which can inform assessments of its quality and trustworthiness. For example, data published by a well-known and trusted organization might be deemed more reliable.
  2. Credit and Accountability: Attributions ensure that the individuals or organizations that contributed to the data are appropriately acknowledged. This is not only a matter of fairness but can also be legally required in some cases.
  3. Search and Discovery: Attributions can be used as a filter or search criterion. For instance, users might want to find all datasets created by a specific researcher or organization, or all datasets on which a certain individual was a contributor.
  4. Collaboration and Networking: Identifying the agents involved in a dataset can lead to new collaboration opportunities, allowing users to reach out to those who have relevant expertise or shared research interests.
  5. Issue Resolution: When users find issues or have questions about a particular dataset, they can reach out to the attributed agent for clarification or resolution, thus ensuring data reliability and integrity.

Attributions with well-known roles

The [[DCTERMS]] standard properties dcterms:creator, dcterms:contributor, dcterms:rightsHolder, and dcterms:publisher, and the generic prov:wasAttributedTo from [[!PROV-O]], support basic associations of responsible agents with a cataloged resource.

Attribution with other roles

There are many other roles of importance in relation to datasets and services - e.g., funder, distributor, custodian, editor. Some of these roles are enumerated in the CI_RoleCode values from [[ISO-19115-1]], in the [[DataCite]] metadata schema, and included within the MARC relators.

A general method for assigning an agent to a resource with a specified role is provided by using the qualified form prov:qualifiedAttribution from [[PROV-O]]. It is used to link to an Agent where the nature of the relationship is known but does not match one of the standard attribution property roles ( dcterms:creator, dcterms:contributor, dcterms:rightsHolder, and dcterms:publisher).

The range of prov:qualifiedAttribution is prov:Attribution. Use dcat:hadRole on the prov:Attribution to capture the responsibility of the Agent with respect to the Resource. More precisely, the relevant Agent is specified via property prov:agent, whereas the role is specified with property dcat:hadRole, which takes as value a skos:Concept describing that role - as those included in the relevant code list operated a US Government-controlled Registry.

The prov:qualifiedAttribution property is used to provide more detailed and structured information about the attribution of a resource. It allows for specifying additional attributes, such as the role or position of the attributed entity, the date of attribution, or other relevant details. The [PROV-O]-based approach is meant to give data providers an extension mechanism to specify, in a harmonised way, any kind of role, and, possibly,to attach additional information to the role and the associated Agent. As such, it MAY be used in combination with or to complement the property-based approach, but it MUST NOT replace it. For instance, it can be used to specify roles not covered by the agent role properties used in DCAT-US, and/or to specify additional information that cannot be expressed via a property (as the period during which an Agent covered a given role).

provides an illustration of the usage of attribution properties:

Resource Classification

Controlled vocabularies, encompassing taxonomies, thesauri have a transformative impact on data searchability. By using these vocabularies, datasets can be classified, tagged, and described with standardized terms and phrases. This standardization ensures that users searching with different terms or synonyms can still retrieve the most relevant datasets.

More than just keyword matching, the use of controlled vocabularies facilitates semantic search. This means that the search process understands the context, relationships, and meanings behind terms, rather than just the terms themselves. For instance, when using a thesaurus-based vocabulary, searching for "automobiles" might also yield results for "cars" or "vehicles".

Such an enriched search experience becomes especially vital when dealing with vast and diverse datasets. It ensures that users can find the most relevant and comprehensive results, even if the exact phrasing or terminology varies between the user's query and the dataset's metadata. In essence, controlled vocabularies bridge the gap between user intent and dataset content, leading to more accurate and meaningful search outcomes.

The DCAT US profile uses a range of properties from the DCAT 3 framework to classify and categorize resources, helping users and systems understand and navigate resources.

Resource types

The dct:type property specifies the nature or genre of content and is applicable to dcat:Dataset, dcat:DataService, and dcat:DatasetSeries. For instance, types might include "Geospatial Dataset", "Image", "Statistical Dataset", or "Map". The Dublin Core Type Vocabulary is for example a popular vocabulary used to categorize datasets.

Keywords

Relevant for dcat:Dataset, dcat:DataService, dcat:Catalog, and dcat:DatasetSeries, the dcat:keyword property allows datasets to be tagged with pertinent terms represented as literals. Using keywords from AGROVOC, GCMD, or the North American Industry Classification System (NAICS) can enhance consistency in the US context.

Thematic Classification

Applicable to dcat:Dataset and dcat:DatasetSeries, the dcat:theme property offers thematic categorization. The Data Theme Taxonomy from Data.gov (TBD) and the Federal Geographic Data Committee (FGDC) Controlled Vocabularies such as ISO 19115 Topic CodeList and Geoplatform NSDI Themes are widely used in the US to ensure a unified theming approach.

Subject Classification

Suitable for dcat:Dataset and dcat:DatasetSeries, the dct:subject property provides deeper insight into a dataset's primary subject. Adopting vocabularies like the Global Change Master Directory (GCMD) FAO Agrovoc, the Integrated Taxonomic Information System (ITIS), the North American Industry Classification System (NAICS) or Library of Congress Subject Headings (LCSH), can optimize clarity and searchability in US Governement datasets.

Spatial Metadata

Spatial metadata play a vital role in the context of geospatial data within the US Government by providing essential information about data quality, facilitating data discovery and interoperability, and ensuring responsible data governance. They describe the characteristics, source, and limitations of geospatial datasets, enabling informed decision-making based on data credibility. Spatial metadata support efficient data discovery, retrieval, and sharing, reducing duplication and promoting collaboration. They also promote interoperability by adhering to standardized metadata schemas and facilitate compliance with legal and regulatory requirements, ensuring accountable data stewardship. Spatial metadata are essential for maximizing the value and effective utilization of geospatial data within the US Government.

The Data Catalog Vocabulary (DCAT) specification provides a standardized way to represent metadata about datasets and services, including information about their spatial properties. In the context of DCAT-US, which is a profile tailored specifically for the United States, several spatial properties are relevant for describing resources. This wiki page aims to provide an overview of these spatial properties and their usage within the DCAT-US framework.

Geographic Bounding Box

A bounding box represents the minimum and maximum coordinates that enclose a specific geographic area. In DCAT-US, the dcat-us:geographicBoundingBox property and the class dcat-us:GeographicBoundingBox are introduced and utilized to define the spatial extent of a resource. This class consists of four numerical properties: the west (dcat-us:westBoundLongitude) and east longitude (dcat-us:eastBoundLongitude), followed by the north (dcat-us:northBoundLatitude) and south latitude (dcat-us:southBoundLatitude), which are based on the WGS84 coordinate system.

By specifying a bounding box, datasets can be associated with a particular geographic region. If the west bound longitude is greater than the east bound longitude, then the box spans the anti-meridian

Antimeridian crossing
Geographic Bounding Box crossing antimeridian

Defining a common reference system is of utmost importance when searching for geospatial data. Geospatial datasets are typically represented using different coordinate systems, projections, and datums, which can lead to challenges in interoperability and data integration. A common reference system ensures that data from diverse sources can be accurately aligned and combined, enabling effective analysis, visualization, and decision-making.

The introduction of the dcat-us:geographicBoundingBox property in DCAT-US profile addresses this challenge by providing a standardized way to express the spatial extent of a resource. Unlike using a Polygon, which requires explicit geometric coordinates, the dcat-us:GeographicBoundingBox offers a simpler and more interoperable approach. Here are a few reasons why the dcat-us:GeographicBoundingBox is advantageous:

By utilizing multiple geographic bounding boxes, geospatial search results within the United States can be significantly enhanced in terms of relevance. The use of multiple bounding boxes allows for a more precise definition of the spatial extent of search criteria, ensuring that the retrieved results align closely with the desired geographic areas of interest. This level of specificity helps filter out irrelevant data points that fall outside the defined bounding boxes, resulting in more targeted and pertinent search outcomes. For instance, when searching for national parks within the United States, using multiple bounding boxes for each park ensures that the search results only include relevant parks within their respective geographic boundaries. Similarly, when searching for metropolitan statistical areas, employing multiple bounding boxes for each area helps retrieve data specific to each metropolitan region, ensuring more accurate and focused results. Furthermore, non-contiguous states like Alaska and Hawaii require separate bounding boxes to accurately capture their unique spatial coverage. The inclusion of multiple bounding boxes in geospatial searches improves the accuracy and relevance of the retrieved datasets, facilitating more effective decision-making and analysis in various applications and domains.

Spatial Coverage

In DCAT 3, the use of the dct:spatial property is intended to provide information about the spatial coverage or location of a resource. This property allows for the description of the spatial aspect of a dataset, dataset distribution, or data service in a standardized manner.

The dct:spatial property can be used to represent spatial coverage using various spatial reference systems, such as coordinates, polygons, or place names. This flexibility allows data publishers to express the spatial extent of their resources in a way that is most appropriate for the given context.

For example, the dct:spatial property can be used to indicate the geographic bounding box that represents the extent of a dataset. This can be expressed using minimum and maximum latitude and longitude values, providing a rectangular approximation of the resource’s coverage area. Alternatively, a more precise polygon can be used to describe complex or irregularly shaped spatial extents.

By including the dct:spatial property in DCAT 3, datasets can provide explicit information about their spatial coverage. This enables data consumers and applications to understand the geographic scope of a resource and determine its relevance for their specific use cases. It supports efficient searching, discovery, and integration of geospatial datasets across different platforms and systems.

Furthermore, the use of standardized properties like dct:spatial enhances interoperability and data exchange among different data catalogs and applications. By conforming to the DCAT 3 specification, data publishers ensure that spatial information is consistently represented and interpreted, facilitating seamless data integration and interoperability within the geospatial community.

Spatial Resolution

Spatial resolution is a characteristic of geospatial datasets that describes the level of detail or granularity in the spatial representation. In DCAT 3.0, the dcat:spatialResolutionInMeters property is used to specify the spatial resolution of a resource, measured in meters. This property helps users understand the level of detail provided by the dataset and assess its suitability for their specific needs. Applications benefit from this property in various ways. For instance, in remote sensing and satellite imagery, users can determine if the dataset captures the required level of detail for their analysis. In cartography and mapping, spatial resolution influences the clarity and accuracy of displayed features. Environmental modeling relies on appropriate resolution for accurate simulations, and emergency management requires datasets that support informed decision-making. The dcat:spatialResolutionInMeters property supports data integration, ensuring compatibility between datasets with different resolutions. Overall, this property enhances the usability and effectiveness of geospatial datasets across diverse domains.

Temporal Metadata

Temporal metadata provides the time-related context of datasets. It informs about the time period data covers, the frequency of updates, and other temporal nuances. Properly documented temporal metadata ensures data is discoverable, understandable, and relevant for time-based analyses.

Temporal References

Temporal reference encompasses into two categories:

  • Temporal interval (or the duration of time it covers).
  • Dates indicating when something was published, revised, or first created.

The temporal span aligns with the term dct:temporal, which has a scope of dct:PeriodOfTime. The exact moment or time frame is denoted using dcat:startDate for the start and dcat:endDate for the end.

On the other hand, the dates for publishing, revising, and initiating are correspondingly linked to dct:issued, dct:modified, and dct:created.

The ISO 19115 metadata component labeled as metadata date is defined as:

The date marking the creation or latest update of the metadata record.

Given this vagueness, the mapped property for this component is identified as dct:modified.

Temporal Resolution

Maintenance information

In [[ISO-19115]], element “Maintenance information” is meant mainly to describe how frequently a resource is updated.

In DCAT-US, the update frequency is expressed through dct:accrualPeriodicity, with the frequency codes defined in the Dublin Core Collection Description Frequency Vocabulary [[CLD-FREQ]], which can be partially mapped to the ones used in [[ISO-19115]] and [[ISO8601-1]], as shown in the following table. The Collection Description Frequency Vocabulary is based on the set of codes used for publication frequency in the MARC 21 Concise Format for Holdings Data.

ISO 19115 - MD_MaintenanceFrequencyCode ISO-8601 Dublin Core Collection Description Frequency Vocabulary [[CLD-FREQ]]
continual R/PT1S continuous
daily R/P1D daily
weekly R/P1W weekly
fortnightly R/P2W or R/P0.5W biweekly
monthly R/P1M monthly
quarterly R/P3M quarterly
biannually R/P6M semiannual
annually R/P1Y annual
asNeeded - -
Irregular - irregular
notPlanned - -
unknown - -
- R/P3Y triennial
- R/P2Y biennial
- R/P4M threeTimesAYear
- R/P2M or R/P0.5M bimonthly
- R/P0.5M semimonthly
- R/P0.33M threeTimesAMonth
- R/P1W semiweekly
- R/P3.5D threeTimesAWeek

Citation Metadata

Resource Restrictions

DCAT-US profile makes use of a code list to specify access restrictions.

In the following table, the URIs of code list values are abbreviated for space constraints, specifying only the local part. For all of them, the base URI is http://data.gov/vocab/access-rights/

URI (abbr.) Label Description
no-limitations No limitations Anybody can directly and anonymously access the data, without being required to register or authenticate.
registration-required Registration required Anybody can access the data, but they have to register first.
authorisation-required Authorisation required Only some users can access the resource.
unknown Unknown Access restrictions are unknown.

Distribution Description

Format and Representation

This category of properties deals with how data is encoded, structured, packaged, and presented, as well as the media type and language it's available in. Properly understanding and managing these aspects is essential for data interoperability, accessibility, discoverability, and usability. A set standardized property values ensure cross-platform interoperability, enabling datasets to be seamlessly processed and integrated. They offer clear semantics about a dataset's nature, ensuring users and systems have a precise understanding. Furthermore, by promoting consistent descriptions, they enhance dataset discoverability, making it easier for users to find and access relevant data.

Distribution Format

Within [[VOCAB-DCAT-3]], format details are specifically tied to the distribution of a dataset rather than the dataset itself. This distinction ensures that datasets, which can have multiple distributions, can cater to varied format requirements while keeping the dataset definition consistent.

When defining the format of a distribution, consider the following properties:

  • dcat:mediaType: Ideal for scenarios where the format aligns with media types registered by IANA [[IANA-MEDIA-TYPES]].
  • dct:format: Suitable for other cases, especially when associating with file form registers managed by a central authority such as Data.gov (TDB).
  • dcat:compressFormat: This property defines when distribution files are compressed, such as in ZIP format. If possible, leverage media types from IANA [[IANA-MEDIA-TYPES]] to express the format.
  • dcat:packageFormat: Use this property to detail the packaging of distributions that bundle multiple data files. This can be crucial for scenarios where related files need collective downloads, like TAR, ZIP, Frictionless Data Package, or Bagit files. Again, if an associated media type from IANA [[IANA-MEDIA-TYPES]] exists, it's recommended to use it.
  • adms:representationTechnique: This property can be used to specify the technique or method by which the data is represented in the distribution. This is different from the file format as, for example, a ZIP file (file format) could contain an XML schema (representation technique). It can help users understand the underlying structure or visualization method of the dataset.

Utilizing these properties effectively can enhance data discoverability, interoperability, and the overall user experience when accessing and working with datasets.

Character encoding

In [[VOCAB-DCAT-3]], the specification of the character encoding of a dataset and the character encoding of a metadata record is not explicitly supported.

According to [[RFC4288]], the character set can be part of the media type specification, but only for type “text”. By contrast, in DCAT-US 3.0 application profile the character set can be specified also for other media types.

The W3C Content vocabulary [[Content-in-RDF10]] provides a suitable candidate, namely, property cnt:characterEncoding, taking as value the character set names in the IANA register [[IANA-CHARSETS]]. DCAT-US uses this property.

Character encoding in [[ISO-19115]] metadata is specified with a code list that can be mapped to the corresponding codes in [[IANA-CHARSETS]], as shown in the following table (entries with 1-to-many mappings are in italic).

ISO 19115 - MD_CharacterSetCode Description IANA
ucs2 16-bit fixed size Universal Character Set, based on ISO/IEC 10646 ISO-10646-UCS-2
ucs4 32-bit fixed size Universal Character Set, based on ISO/IEC 10646 ISO-10646-UCS-4
utf7 7-bit variable size UCS Transfer Format, based on ISO/IEC 10646 UTF-7
utf8 8-bit variable size UCS Transfer Format, based on ISO/IEC 10646 UTF-8
utf16 16-bit variable size UCS Transfer Format, based on ISO/IEC 10646 UTF-16
8859part1 ISO/IEC 8859-1, Information technology - 8-bit single byte coded graphic character sets - Part 1 : Latin alphabet No.1 ISO-8859-1
8859part2 ISO/IEC 8859-2, Information technology - 8-bit single byte coded graphic character sets - Part 2 : Latin alphabet No.2 ISO-8859-2
8859part3 ISO/IEC 8859-3, Information technology - 8-bit single byte coded graphic character sets - Part 3 : Latin alphabet No.3 ISO-8859-3
8859part4 ISO/IEC 8859-4, Information technology - 8-bit single byte coded graphic character sets - Part 4 : Latin alphabet No.4 ISO-8859-4
8859part5 ISO/IEC 8859-5, Information technology - 8-bit single byte coded graphic character sets - Part 5 : Latin/Cyrillic alphabet ISO-8859-5
8859part6 ISO/IEC 8859-6, Information technology - 8-bit single byte coded graphic character sets - Part 6 : Latin/Arabic alphabet ISO-8859-6
8859part7 ISO/IEC 8859-7, Information technology - 8-bit single byte coded graphic character sets - Part 7 : Latin/Greek alphabet ISO-8859-7
8859part8 ISO/IEC 8859-8, Information technology - 8-bit single byte coded graphic character sets - Part 8 : Latin/Hebrew alphabet ISO-8859-8
8859part9 ISO/IEC 8859-9, Information technology - 8-bit single byte coded graphic character sets - Part 9 : Latin alphabet No.5 ISO-8859-9
8859part10 ISO/IEC 8859-10, Information technology - 8-bit single byte coded graphic character sets - Part 10 : Latin alphabet No.6 ISO-8859-10
8859part11 ISO/IEC 8859-11, Information technology - 8-bit single byte coded graphic character sets - Part 11 : Latin/Thai alphabet ISO-8859-11
8859part13 ISO/IEC 8859-13, Information technology - 8-bit single byte coded graphic character sets - Part 13 : Latin alphabet No.7 ISO-8859-13
8859part14 ISO/IEC 8859-14, Information technology - 8-bit single byte coded graphic character sets - Part 14 : Latin alphabet No.8 (Celtic) ISO-8859-14
8859part15 ISO/IEC 8859-15, Information technology - 8-bit single byte coded graphic character sets - Part 15 : Latin alphabet No.9 ISO-8859-15
8859part16 ISO/IEC 8859-16, Information technology - 8-bit single byte coded graphic character sets - Part 16 : Latin alphabet No.10 ISO-8859-16
jis japanese code set used for electronic transmission JIS_Encoding
shiftJIS japanese code set used on MS-DOS machines Shift_JIS
eucJP japanese code set used on UNIX based machines EUC-JP
usAscii United States ASCII code set (ISO 646 US) US-ASCII
ebcdic IBM mainframe code set IBM037
eucKR Korean code set EUC-KR
big5 traditional Chinese code set used in Taiwan, Hong Kong of China and other areas Big5
GB2312 simplified Chinese code set GB2312

Data Quality

The quality of a dataset plays a pivotal role in shaping trust, reusability, and the overall performance of applications that rely on it. As a result, it is imperative to integrate data quality information seamlessly into both the data publishing and consumption processes. This inclusion allows for a thorough evaluation of a dataset's quality, thereby determining its suitability for a particular application.

Thorough documentation of data quality significantly streamlines the dataset selection process, enhancing the likelihood of reuse. Regardless of domain-specific nuances, documenting data quality and explicitly stating known quality issues in metadata are fundamental practices. Typically, assessing quality involves multiple dimensions, each encapsulating characteristics of importance to both data publishers and consumers.

The Data Quality Vocabulary defines machine-readable concepts such as measurements and criteria to assess quality across various dimensions [[VOCAB-DQV]]. Tailored heuristics designed for specific assessment scenarios rely on quality indicators, which encompass data content, metadata, and human ratings. These indicators offer valuable insights into the dataset's suitability for its intended purpose.

Versioning

Versioning is a concept used to describe the relationship between an original resource and its variations, updates, or translations. In this section, we explore how DCAT (Data Catalog Vocabulary) is employed to document versions resulting from updates or modifications throughout a resource's lifecycle.

DCAT relies on established vocabularies, including the versioning section of the PAV ontology and terms from [[PAV]], [[DCTERMS]], [[OWL2-OVERVIEW]], and [[VOCAB-ADMS]].

It's important to note that versioning applies to all primary DCAT-US resources, including Catalogs, Catalog Records, Datasets, Dataset Series, and Distributions.

The versioning approach within DCAT is designed to complement existing methods specific to certain resources (such as versioning properties for ontologies in [[OWL2-OVERVIEW]]) and those prevalent in particular domains. A detailed comparison with other vocabularies can be found in section 11.4: Complementary Approaches to Versioning.

Versioning is closely linked to community conventions, data management strategies, and existing processes. Data providers bear the responsibility of determining when and why a new version should be released.

Handling Dataset Changes

Datasets published on the Web are subject to change over time. Some datasets are updated on a regular schedule, while others evolve as improvements in data collection methods make updates necessary. To manage these changes effectively, new versions of a dataset may be created. However, there isn't a unanimous consensus on when changes to a dataset should categorize it as an entirely new dataset or simply a new version. Below, we outline scenarios where most publishers would agree that a revision warrants consideration as a new version:

Scenarios:

  1. Scenario 1: Creation of a new bus stop that needs to be added to the dataset.
  2. Scenario 2: Removal of an existing bus stop, necessitating its deletion from the dataset.
  3. Scenario 3: Identification and correction of an error in one of the existing bus stops stored in the dataset.

In general, when dealing with datasets that represent time series or spatial series, such as data for different regions or years, these are not typically regarded as multiple versions of the same dataset. Instead, each dataset covers a distinct set of observations about the world and should be treated as a new dataset. This principle also applies to datasets collecting data about weekly weather forecasts for a specific city, where a new dataset is created each week to store data for that particular week.

Scenario 1 and 2 may trigger major version updates, while Scenario 3 is likely to trigger only a minor version update. However, the distinction between minor and major versions is less critical than ensuring that any changes are clearly indicated by incrementing the version number. Even for minor changes, maintaining a record of different dataset versions is essential for ensuring the dataset's reliability. Publishers should be mindful that a dataset may be in use by one or more data consumers, and they should take reasonable steps to inform those consumers when a new version is released. For real-time data, an automated timestamp can serve as a version identifier. It's crucial for publishers to adopt a consistent and informative approach to versioning for each dataset, ensuring that data consumers can effectively understand and work with evolving data.

Dataset Series

A Dataset Series is a way for publishers to convey that a dataset is evolving across specific dimensions and is available as a set of related datasets. However, choosing to group datasets this way depends on the use case. Since it demands extra metadata management from the publisher, it's optional. For instance, a dataset updated frequently via an API may not require individual records for each yearly snapshot unless the publisher wishes to share each snapshot's lifecycle.

Guidelines for Using Dataset Series:

Expressing Connection in Dataset Series

If datasets within a Dataset Series are tightly interconnected or generated through an automated process, it's intuitive to use versioning to describe their relationship. For guidance on incorporating versioning in DCAT-US, refer to the DCAT versioning guidelines. However, since versioning might not always be the best descriptor, DCAT offers properties (like next, previous, inSeries, last, and others) to articulate the links between the Dataset Series and its datasets. It's advised to consistently use these properties with Dataset Series, and apply versioning where it fits.

Membership Influence on Metadata

Being part of a Dataset Series can affect a dataset's metadata to emphasize its uniqueness compared to others in the collection. For example, a common adjustment is appending the release date to the dataset's title.

Controlled Vocabularies

Importance of Controlled Vocabularies

Controlled vocabularies are predetermined sets of terms that have been carefully curated to ensure consistency, accuracy, and standardized representation of concepts within a specific domain. In the context of DCAT-US, controlled vocabularies are used to define and constrain the values of specific metadata elements. These vocabularies enable the creation of a common language for describing datasets, facilitating data integration and harmonization across different repositories.

The use of controlled vocabularies in DCAT-US offers several key benefits:

  • Consistency: By providing a predefined list of terms, controlled vocabularies ensure consistent representation and labeling of metadata elements. This consistency promotes data interoperability and simplifies data integration efforts, as different datasets can be mapped to a shared set of controlled terms.
  • Enhanced search and discovery: Controlled vocabularies enable more effective search and discovery of datasets. By aligning metadata elements with standardized terms, users can easily navigate and explore datasets based on their specific domain knowledge. Furthermore, controlled vocabularies facilitate the development of advanced search capabilities, such as faceted search, which allows users to refine search results based on predefined categories or facets.
  • Data harmonization: In a diverse data landscape where multiple agencies and organizations produce and manage datasets, controlled vocabularies help in harmonizing the data representation. By agreeing on a set of controlled terms, data publishers can ensure that similar concepts are represented consistently across different datasets. This harmonization promotes data integration and interoperability, enabling meaningful analysis and comparison of data from various sources.

Requirements for controlled vocabularies

The following is a list of requirements that were identified for the controlled vocabularies to be recommended in this Application Profile.

Controlled vocabularies SHOULD:

  • Be published under an open license.
  • Be operated and/or maintained by an agency of the US Government, by a recognised standards organisation or another trusted organisation.
  • Be properly documented.
  • Have labels in english, and optionally in Spanish
  • Contain a relatively small number of terms (e.g. 10-25) that are general enough to enable a wide range of resources to be classified.
  • Have terms that are identified by URIs with each URI resolving to documentation about the term.
  • Have associated persistence and versioning policies.

These criteria do not intend to define a set of requirements for controlled vocabularies in general; they are only intended to be used for the selection of the controlled vocabularies that are proposed for this Application Profile.

Controlled vocabularies to be used

In the table below, a number of properties are listed with controlled vocabularies that MUST be used for the listed properties. The declaration of the following controlled vocabularies as mandatory ensures a minimum level of interoperability.

Compared with [[DCAT-AP-20200608]], DCAT-US makes use of additional controlled vocabularies mandated by [[DATA-GOV-REG]], and operated by the Data.gov Registry - with the only exceptions of the coordinate reference systems register maintained by OGC [[OGC-EPSG]].

For two of these controlled vocabularies, namely the NGDA spatial data themes [[NGDA-THEMES]] and the ISO topic categories [[ISO-19115-1]], the DCAT-US Working Group has defined a set of harmonised mappings to the Data.gov Vocabularies Data Themes [[DATA-GOV-THEME]], in order to facilitate the identification of the relevant theme in [[DATA-GOV-THEME]] for geospatial/statistical metadata.

Other controlled vocabularies

In addition to the proposed common vocabularies in , which are mandatory to ensure minimal interoperability, implementers are encouraged to publish and to use further region or domain-specific vocabularies that are available online. While those may not be recognised by general implementations of the Application Profile, they may serve to increase interoperability across applications in the same region or domain. Examples are the full set of concepts in GCMD [[GCMD]],and numerous other schemes.

For geospatial metadata, the working group has identified the following additional vocabularies:

Licence vocabularies

Concerning license vocabularies, implementers are encouraged to use widely recognised licenses such as Creative Commons licenses [[?CC]], and in particular the CC Zero Public Domain Dedication [[?CC0]] or CC-BY Attribution 4.0 International [[?CC-BY]], or the Open Data Commons Public Domain Dedication and License (PDDL) [[?PDDL]]. Often there is applicable legislation or a licency policy in place which determine the set of licenses to be used.

Further activities in this area are undertaken by the Open Data Institute (ODI) with the Open Data Rights Statement Vocabulary [[ODRS]] and by the Open Digital Rights Language (ODRL) Initiative [[VOCAB-ODRL]].

JSON-LD context file

One common technical question is the format in which the data is being exchanged. For DCAT-US 3.0 conformance, it is not mandatory that this happens in a RDF serialisation, but the exchanged format SHOULD be unambiguously be transformable into RDF. For the format JSON, a popular format to exchange data between systems, DCAT-US profile provides a JSON-LD context file. JSON-LD is a W3C Recommendation [[[json-ld11]]] that provided a standard approach to interpret JSON structures as RDF. The provided JSON-LD context file can be used by implementers to base their data exchange upon, and so create a DCAT-US conformant data exchange. This JSON-LD context is not normative, i.e. other JSON-LD contexts are allowed to create a a conformant DCAT-UD data exchange. The JSON-LD context file downloadable here.

SHACL Profile

Namespaces

Namespaces and prefixes used in normative parts of this recommendation are shown in the following table:

Prefix Namespace IRI Source
cnt http://www.w3.org/2011/content# [[Content-in-RDF10]]
dcat https://www.w3.org/TR/vocab-dcat-3/ [[VOCAB-DCAT]]
dct http://purl.org/dc/terms/ [[DCTERMS]]
foaf http://xmlns.com/foaf/0.1/ [[FOAF]]
schema http://schema.org/ [[schema-org]]
rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# [[RDF-SYNTAX-GRAMMAR]]
rdfs http://www.w3.org/2000/01/rdf-schema# [[RDF-SCHEMA]]
vcard http://www.w3.org/2006/vcard/ns# [[VCARD-RDF]]
xsd http://www.w3.org/2001/XMLSchema# [[XMLSCHEMA11-2]]
adms http://www.w3.org/ns/adms# [[VOCAB-ADMS]]
skos http://www.w3.org/2004/02/skos/core# [[SKOS-REFERENCE]]
locn http://www.w3.org/ns/locn# [[LOCN]]
prov http://www.w3.org/ns/prov# [[PROV]]
spdx http://spdx.org/rdf/terms# [[SPDX]]
gsp http://www.opengis.net/ont/geosparql# [[GeoSPARQL]]