DCAT-R: Data Catalog Vocabulary for RDF Repositories

A dcatr:Service provides the basis for operations that access and process repository data. Following dcat:DataService, services represent 'collections of operations that provide access to one or more datasets or data processing functions.' Services are the application layer of DCAT-R, defining what you can do with repository data. Different service types provide different operations and access patterns; multiple instances of the same service type can serve the same repository with different configurations on different machines.

• service repository ^op
• service local data ^op
• use primary as default ^dp

A managed collection containing an RDF dataset, its catalog metadata (repository manifest graph), and operational system graphs. The repository is the distributable unit of DCAT-R - when replicated or shared between service instances, all of its contents travel together. DCAT-R supports two patterns: a multi-graph pattern using repositoryDataset to link to a Dataset containing multiple data graphs, and a single-graph shortcut using repositoryDataGraph to combine primary designation and containment in one statement.

• dcat:Catalog
• Directory ^c

• repository dataset ^op
• repository primary graph ^op
• repository data graph ^op
• repository system graph ^op
• repository manifest ^op

Local catalog for service-specific graphs that are not distributed with the repository. Usually instantiated as a blank node, but can have an explicit URI if needed.

• dcat:Catalog
• Directory ^c

• service manifest graph ^op
• service working graph ^op
• service system graph ^op

The RDF dataset within a repository, modeled as both a DCAT catalog and a DCATR Directory. As the root directory of the graph hierarchy, it contains data graphs and nested directories.

• dcat:Catalog
• Directory ^c

Abstract base class for all graphs in a DCAT-R repository. Every graph must belong to exactly one of the four concrete subclasses: DataGraph (user data), ManifestGraph (DCAT-R configuration), SystemGraph (system mechanisms), or WorkingGraph (temporary working areas).

• dcat:Dataset
• Element ^c

• Default Graph ^c
• Named Graph ^c
• Data Graph ^c
• Manifest Graph ^c
• Working Graph ^c
• System Graph ^c

The default graph of an RDF dataset, which contains triples not assigned to any named graph. This classification is specific to a service instance and should be defined in the ServiceGraph, not in the repository metadata. Only one graph per dataset can be designated as DefaultGraph within a service.

The classification of a graph as DefaultGraph is analogous to defining a localGraphName for a NamedGraph - both are service-specific configurations that belong in the ServiceGraph.

A named graph within an RDF dataset whose graph name (specified via dcatr:localGraphName) may differ from the graph's canonical URI. This classification is specific to a service instance and should be defined in the service manifest graph, not in the repository metadata. The DefaultGraph/NamedGraph classification is orthogonal to the four content-based graph types - a graph can be, for example, both a DataGraph and a NamedGraph.

The NamedGraph classification belongs in the ServiceGraph alongside any localGraphName mappings, as both concern how the service accesses the graph.

Graph containing the actual user data of the dataset. These are the primary content graphs that form the core of the repository's dataset, distinct from manifests, system data, and working areas. Data graphs are intended for distribution and represent the repository's main content.

• repository primary graph ^op
• repository data graph ^op
• data graph ^op

Base class for graphs containing DCAT-R configuration and descriptions. Unlike other graph types, manifest graphs have a known structure that DCAT-R understands and depends upon. They contain the DCAT descriptions and configuration that define the repository and service structure.

• Service Manifest Graph ^c
• Repository Manifest Graph ^c

Manifest graph containing service-specific configuration and local settings. This graph is not replicated between service instances and contains the local configuration specific to one service instance.

Manifest graph containing the DCAT descriptions of the repository itself, including metadata about the dataset and all graphs. This manifest is part of the repository distribution and shared across all service instances.

DESIGN NOTE: This graph exhibits controlled self-reference - it describes the repository of which it is part. This is by design and analogous to metadata patterns in traditional information systems (e.g., a book's index being part of the book it describes).

BEST PRACTICE: The graph MUST have its own URI distinct from the repository URI to avoid identifier collision. Recommended URI patterns: - {repository-uri}/manifest - {repository-uri}#manifest - {repository-base}/catalog/manifest

The self-reference is managed through the dcatr:repositoryManifestGraph property which explicitly links the repository to its manifest graph. This pattern acknowledges that metadata about a system can be part of that system while maintaining clear boundaries through URI separation.

Service-local graph not included in distributions. Used for drafts, experiments, temporary work, cache graphs, import/export buffers, personal sandboxes, or validation graphs. Working graphs belong to the ServiceData catalog and are never part of repository distributions.

Operational graph that supports service functionality but is opaque to DCAT-R (unlike manifest graphs, whose structure DCAT-R understands). System graphs can be either distributed (linked to the repository via repositorySystemGraph, e.g. version history, provenance records, shared indexes) or local (linked to service data via serviceSystemGraph, e.g. query caches, operation logs). Applications extend DCAT-R by defining specialized SystemGraph subclasses for their operational needs.

• repository system graph ^op
• service system graph ^op

Abstract base class for items that can be organized within a Directory. Both Graphs and Directories are Elements, enabling hierarchical containment.

• Graph ^c
• Directory ^c

A named collection of graphs and nested directories within a Dataset. Directories enable hierarchical organization of graphs, providing structure for navigation, scoped metadata, and targeted operations. Each directory can contain DataGraphs as members and nested Directories.

• dcat:Catalog
• Element ^c

• member ^op
• directory ^op

• parent directory ^op
• directory ^op

• Repository ^c
• Service Data ^c
• Dataset ^c

Document that describes a DCAT-R service configuration, including repository and dataset settings and their metadata.

Links a service to its repository.

Links a service to its local data catalog (usually a blank node) containing service-specific graphs not distributed with the repository.

Links a repository to its primary dataset. Used in the multi-graph pattern where the dataset contains multiple data graphs.

Designates the primary graph of a repository. Pure designator - does not imply containment. In multi-graph repositories, the primary graph must also be listed in the dataset. For single-graph repositories that need both containment and designation, use dcatr:repositoryDataGraph instead.

Convenience property for single-graph repositories that combines primary designation and containment in one statement. For multi-graph repositories, use repositoryDataset with repositoryPrimaryGraph instead.

• repository primary graph ^op
• member ^op

Links a repository to its system graphs that are distributed with the repository (like history or application-specific operational graphs).

Links a repository to its manifest graph containing the DCAT descriptions and configuration of the repository itself.

Service-specific configuration graph, local to this service instance.

Temporary working graphs local to this service instance.

Service-local system graphs not distributed with the repository.

Links a dataset to its constituent data graphs. Only DataGraphs (user data) belong to the Dataset; SystemGraphs are linked directly to the Repository.

The local name under which this graph appears in a specific service instance's RDF dataset. Enables service-specific aliasing: a graph's canonical URI (its RDF resource identifier) can differ from the graph name used in a particular service. Should be unique within a service instance (enforced by implementations, not by OWL semantics).

While this property should be unique within a service context, it is not declared as owl:InverseFunctionalProperty to avoid global inference conflicts between independent service instances.

Links a directory to an Element (Graph or Directory) that is a direct member of this directory. As an inverse functional property, each element belongs to at most one directory (unique containment).

• repository data graph ^op
• repository system graph ^op
• repository manifest ^op
• service manifest graph ^op
• service working graph ^op
• service system graph ^op
• data graph ^op
• directory ^op

Links an element to its containing directory. Inverse of dcatr:member.

Links a directory to a nested subdirectory.

Links a manifest to its configured service.

Controls whether the repository's primary graph should automatically be designated as the service's default graph.

Three-value semantics: - Absence: Auto mode - convention-based fallback. If no explicit default graph is configured in the service manifest, the primary graph becomes the default. If an explicit default is configured, it takes precedence. - true: Enforce mode - the primary graph MUST be the default. Raises an error if an explicit default graph differs from the primary graph. - false: Disable mode - no automatic designation. The service must explicitly configure a default graph, or none will be set.

This property enables flexible configuration: most single-graph repositories benefit from automatic designation, while edge cases requiring explicit control can disable it (false mode) or enforce consistency (true mode).

When not set in the manifest, the runtime behavior is determined by the application.

Links a service to its repository.

Links a service to its local data catalog (usually a blank node) containing service-specific graphs not distributed with the repository.

Links a repository to its primary dataset. Used in the multi-graph pattern where the dataset contains multiple data graphs.

Designates the primary graph of a repository. Pure designator - does not imply containment. In multi-graph repositories, the primary graph must also be listed in the dataset. For single-graph repositories that need both containment and designation, use dcatr:repositoryDataGraph instead.

Convenience property for single-graph repositories that combines primary designation and containment in one statement. For multi-graph repositories, use repositoryDataset with repositoryPrimaryGraph instead.

• repository primary graph ^op
• member ^op

Links a repository to its manifest graph containing the DCAT descriptions and configuration of the repository itself.

Service-specific configuration graph, local to this service instance.

Links an element to its containing directory. Inverse of dcatr:member.

Links a manifest to its configured service.