Domain model¶

Generated from the docstrings. Domain Model explains the dataset hierarchy and how the classes map to DCAT-AP.

model ¶

Domain model for statcatlib.

Agent ¶

An organization or person responsible for a dataset.

Maps to foaf:Agent / dct:publisher / dct:creator in DCAT-AP.

ContactPoint ¶

Contact information for a dataset.

Maps to dcat:contactPoint → vcard:Kind in DCAT-AP.

CatalogDescription ¶

A DCAT-style description record for a catalog of datasets.

Maps to dcat:Catalog in DCAT-AP. This is metadata describing the catalog as a published artefact — title, publisher, list of datasets and services, licence, etc. The runtime store with the same DCAT-shaped role is statcatlib.Catalog; the two are separate concerns. Use this when serialising to / from DCAT-AP RDF or when a catalog needs a self-describing manifest record.

CatalogRecord ¶

Metadata about a dataset's entry in the catalog.

Maps to dcat:CatalogRecord in DCAT-AP. This is metadata about the catalog entry itself — when it was listed, where it was harvested from, etc. Optional — not all catalogs use this.

Standard ¶

A standard or specification that the dataset conforms to.

Maps to dct:conformsTo in DCAT-AP. Used to link to SDMX DSDs, CSV schemas, API specifications, etc.

AggregateDataset ¶

Bases: BaseDataset

A statistical aggregate dataset (tabular, with dimensions and measures).

Extends BaseDataset with StatDCAT-AP discovery fields and an optional link to the full SDMX structural record in sdmxlib's shared DuckDB tables. dimension_names carries enough info for catalog search without a JOIN.

BaseDataset ¶

Common fields for all dataset variants. Maps to DCAT-AP 3.0.

Not intended for direct construction — use one of the five concrete variants: OpenDataset, AggregateDataset, MicrodataDataset, GeospatialDataset, PublicationDataset.

GeospatialDataset ¶

Bases: BaseDataset

A geospatial dataset.

MicrodataDataset ¶

Bases: BaseDataset

A microdata (survey/record-level) dataset.

OpenDataset ¶

Bases: BaseDataset

Generic open dataset — the default bucket for non-specialized data.

PublicationDataset ¶

Bases: BaseDataset

A publication (article, report, monograph).

Variable ¶

A variable in a microdata dataset.

DataService ¶

An API endpoint that serves one or more datasets.

Maps to dcat:DataService in DCAT-AP. For SDMX sources, the endpoint_url is the SDMX REST base URL.

Distribution ¶

A specific available form of a dataset.

Maps to dcat:Distribution in DCAT-AP. A dataset may have multiple distributions: CSV download, API endpoint, visualization, etc.

LicenceDocument ¶

A licence under which the dataset is made available.

Maps to dct:license → dct:LicenseDocument in DCAT-AP.

ProvenanceStatement ¶

A statement about the origin/methodology of the dataset.

Maps to dct:provenance in DCAT-AP.

QualityAnnotation ¶

A quality statement about the dataset.

Maps to dqv:hasQualityAnnotation in StatDCAT-AP. Intentionally simple — a label + optional body. Richer quality modelling can be added later.

SpatialCoverage ¶

A geographic area covered by the dataset.

Maps to dct:spatial → dct:Location in DCAT-AP. Can be a named region (with URI) or a bounding box.

Frequency ¶

Update frequency of a dataset.

Maps to dct:accrualPeriodicity in DCAT-AP. The id should use the Dublin Core frequency vocabulary or SDMX CL_FREQ values where possible (e.g. "ANNUAL", "QUARTERLY", "MONTHLY").

TemporalCoverage ¶

A time interval that the dataset covers.

Maps to dct:temporal → dct:PeriodOfTime in DCAT-AP.

Concept ¶

A SKOS Concept.

Identity is notation within its parent scheme — the "code" (e.g. "PUMF", "HEAL", "ON"). broader, narrower, and related are tuples of notations in the same scheme, not URIs. Cross-scheme relations use ConceptRef or (in future) an XKOS Correspondence artefact.

ConceptRef ¶

Typed reference to a Concept.

Carried on Dataset.themes, .subject, and .dataset_type (DCAT's dcat:theme, dcterms:subject, dcterms:type).

URI is identity. scheme_uri, notation, and label are hints that speed up display and within-scheme lookups but do not affect equality.

label is populated at read time via a LEFT JOIN with the concept table; it is an empty dict when the concept is not materialized in the store (permissive refs — datasets may cite concepts from external vocabularies that are never locally ingested).

ConceptScheme ¶

A SKOS ConceptScheme — a controlled vocabulary.

Globally identified by URI. Owns its Concepts: a Concept has no identity outside its scheme (skos:inScheme is a required property).

concepts maps notation → Concept for Pythonic within-scheme access::

scheme.concepts["PUMF"]  # direct lookup by notation

top_concepts lists notations of the top-level hierarchy entries (skos:hasTopConcept).

Construction with embedded concepts enables cascade persistence::

store.put_concept_scheme(ConceptScheme(uri=..., label=..., concepts={...}))

put_concept_scheme() writes the scheme row and cascades to write each Concept row. This is the correct container convenience: the ownership relation is genuine.

ConceptSchemeRef ¶

Typed reference to a ConceptScheme.

Carried on Catalog.theme_taxonomy (DCAT's dcat:themeTaxonomy). URI is identity; label is denormalized display convenience only.

is_concept_in_scheme ¶

is_concept_in_scheme(
    scheme: ConceptScheme, notation: str
) -> bool

Return True if notation is a known concept in scheme.

Pure-Python — no DuckDB or any other storage involved. Useful for validation pipelines that operate on in-memory domain objects.

Parameters:

Name	Type	Description	Default
`scheme`	`ConceptScheme`	The concept scheme.	required
`notation`	`str`	The concept's notation.	required

Returns:

Type	Description
`bool`	Whether scheme lists notation among its concepts.

Example

valid = is_concept_in_scheme(product_type_scheme, dataset.dataset_type.notation)