Sdchealthdcatap

sdc_healthdcat_ap

One Semantic Data Charter model, described in HealthDCAT-AP.

sdchealthdcatap reads a published SDC model's package and writes the dcat:Dataset description that HealthDCAT-AP, the health extension of DCAT-AP for the secondary use of health data under the European Health Data Space, asks a data holder to publish into the HealthData@EU catalogue: one Dataset per model at a declared access level, its variables as a CSVW table group built from the record's leaves, its coding systems from the model's bindings, and the holder's facts from declared input. One rdflib graph, serialized as Turtle and as JSON-LD. The output is checked with the HealthData@EU validator's own shape set for the level, at a pinned commit of the specification's repository.

1. What this is, and where it came from

The sample, samples/nhanes-participant/catalog.ttl (and catalog.jsonld, the same graph), is one Dataset at the NON_PUBLIC access level, with no catalogue wrapper, as the release's own examples are (part 4 says why): the records of NHANES Participant (dm-xy8upneajsb8vdcmnve01g6g) from the FAIR Data Demo, a demographic, examination and laboratory record of the National Health and Nutrition Examination Survey (CDC), 9,254 records, one per participant. The model is public:

• the catalog record: https://sdcstudio.axius-sdc.com/api/v1/catalog/dm/xy8upneajsb8vdcmnve01g6g/
• the schema the records conform to: https://sdcstudio.axius-sdc.com/dmlib/dm-xy8upneajsb8vdcmnve01g6g.xsd
• the Semantic Data Charter: https://semanticdatacharter.com

pip install -e ".[fetch]"

sdchealthdcatap write --package samples/nhanes-participant --out catalog.ttl --jsonld catalog.jsonld sdchealthdcatap write --ct-id xy8upneajsb8vdcmnve01g6g --save-package pkg/ --out catalog.ttl # any published model, from the public catalog sdchealthdcatap write --package DIR --catalog my-catalog.yaml --out catalog.ttl # a data holder's own declared input

Two kinds of input, kept apart. From the model's package (its JSON-LD, its schema, the public catalog record and the published schema versions; no account needed; a model without a package is refused): title, description, identifier, creator, dates, licence, the schema's URL and SHA-256, every leaf of the record for the variables, every concept system the model binds to for the coding systems, and the model's own Dublin Core when the modeler wrote it. From the data holder, declared in catalog.yaml because the profile asks for facts only a holder has and for values from the DG SANTE and EU vocabularies: the access level, the health data access body, the applicable legislation, the health category and theme, the dataset type, the distribution that is the access route, the counts of records and individuals, typical ages, population coverage, personal-data categories, legal basis, purpose, the publisher's type, the contact point. The package ships the sample's file (src/sdchealthdcatap/data/catalog.yaml); a holder supplies its own.

The data dictionary is a slot here. healthdcatap:hasVariables takes a csvw:TableGroup; the writer builds one table with one csvw:Column per leaf of the record, 153 for NHANES Participant: csvw:name the leaf's path in the record, csvw:title its label, csvw:datatype its XSD type, dct:description its definition, csvw:propertyUrl its library slot (the identifier that says what the variable means wherever it is reused), dct:identifier its element name. healthdcatap:hasStructuredData is true. healthdcatap:hasCodingSystem carries SNOMED CT, LOINC and NCIT from the Coding System NAL, derived from the model's skos:exactMatch bindings by IRI prefix.

What else the Dataset carries:

Every NAL concept the graph uses states its scheme (skos:inScheme), and every scheme is typed and titled, because the validator's codelist shapes check membership that way. Every agent is typed and named, with a contact point.

2. How to verify it

The tests run the HealthData@EU validator's own configuration from data/healthdcat-ap-r8-cd7841f/validator/ (build/snapshot_healthdcat_ap.py verifies the pin first): config.properties names the shape files per access level, and the tests load exactly those for the declared level, plus SEMIC's DCAT-AP 3.0.1 shapes as the release ships them, plus the thirteen vocabularies the codelist shapes name, which the validator preloads as background:

pip install -e ".[dev]"

python -m pytest tests -q

Result at the pin, NON_PUBLIC, in Turtle and in JSON-LD: 0 violations, 10 warnings, the recommended properties the package does not carry (analytics, retention period, frequency, dct:conformsTo on the Dataset, references, relations, source, temporal coverage and resolution, a sample). The committed samples are asserted isomorphic to a fresh run. The release's own ARCA example, run the same way at PUBLIC, passes except where the background we carry stops (part 4).

Second witness, the Interoperability Test Bed, which the specification's validation section names as where the shape and import files "can be loaded": its generic SHACL validator (https://www.itb.ec.europa.eu/shacl/any/upload, REST API /shacl/any/api/validate) given the release's non-public shape files as external rules, 9 October 2026: no violation on any node of the document, 14 warnings (the ten above, plus dct:format on the distribution, dct:spatial, and dct:type on the creator agent and the licence document). The 22 violations it also reports fall on nodes the Test Bed carries itself, six ADMS concept schemes without a title and five unnamed blank agents, each twice, the same an empty catalog receives on its DCAT-AP domain. The network-marked test asserts the first part; CI skips it. The HealthData@EU platform's own validator page was not reachable: both the production and the acceptance platforms answer 404 at the validator path, and the platform's public pages do not link one.

3. What the projection could not say

Declared rather than read from the package, and said so here:

• The health data access body is the publisher. The field is mandatory at every level and no EU body holds this dataset. The sample names Axius SDC, Inc., with its contact point, as the body that grants access, which is true of the FAIR Data Demo and would be replaced by the real body for a dataset inside the EHDS.
• The applicable legislation is the EHDS Regulation, as the profile's usage note recommends, for a dataset the Regulation does not govern. It is the profile's required way of saying "described for the EHDS framework."
• The counts, ages, population, personal-data categories, legal basis and purpose are the holder's statements about the FAIR Data Demo's generation run and the NHANES source, not facts the package carries.
• The distribution is a route, not a file. The records are not published; the access route is the contact page. A holder with a download or a data service replaces it.

Left out: retention period, analytics distribution, sample distribution, frequency, temporal coverage, relations. The package does not carry them, and the profile recommends rather than requires them.

In the other direction, what the record carries that the catalog entry only points at:

• The governance envelope is data in every record, an audit event, a PROV activity and a PROV agent, validated with the rest. The columns for them are in the table group, so a reader can see they exist; the values are in the records.
• The schema is bound to each record, and cited here on the distribution and the page by URL and SHA-256.
• The reason a value is missing is typed in the record. The table group's description says every column may carry one of sixteen exceptional values; which one applies, and where, is in the record.

4. What we learned about HealthDCAT-AP Release 8 and its validator

Implementer's notes from building this against healthdataeu/healthdcat-ap at cd7841f on 9 October 2026. They describe how the artifacts behave, so the next implementer spends the day on their own catalog rather than on these.

• The document is the Dataset, not a Catalogue. The release's examples are dataset-only, and the reason shows under validation: with DCAT loaded as background (dcat:Catalog is a subclass of dcat:Dataset), a validator reads a dcat:Catalog node as a Dataset and holds it to the Dataset's mandatory list, eleven violations on the wrapper alone (contact point, distribution, keyword, theme, access rights, identifier, provenance, type, health category, access body, the structured-data flag). The writer emits no Catalogue; the HealthData@EU catalogue is the catalogue.
• The validator ships with the release, configured. html/shacl/HealthDCAT-AP_validator/config/rdf-validator/ehds/ holds config.properties, which names the shape files per access level, and the vocabularies and ontologies the validator preloads. Running that file set with pySHACL is running the validator's logic; the hosted instance adds background knowledge and a web interface.
• Membership in a vocabulary is checked through `skos:inScheme`. Every codelist restriction asks the concept for skos:inScheme , several also ask the scheme to be a typed skos:ConceptScheme, and SEMIC's base shapes then ask every scheme in the graph for a dct:title. The hosted validator preloads the vocabularies, which supply the inScheme; offline, either load them or state them. The writer states them for every concept it uses, and the tests load the thirteen vocabularies anyway, which is why the release's ARCA example passes offline except for its language (the Languages NAL is 14 MB and stays out) and its licence type (the ADMS scheme is not among the preloads).
• `dct:conformsTo` on a Dataset is closed to the Technical Standard NAL (FHIR, OMOP-CDM, openEHR, DICOM, CDISC SDTM and about twenty more), at violation level. A schema of one's own cannot go there; the writer cites it on the distribution, which has no such restriction, and on foaf:page.
• **A health publisher is an agent with exactly on