The ddigraph vocabulary, version 1.0

This page is what https://pbisson44.github.io/ddigraph/ns/1.0/ resolves to. Every IRI in a graph exported by ddigraph that is not a published standard term lives under that namespace, and this page says what those terms mean.

Download vocabulary.ttl

Why the version is not the package version

The namespace is 1.0. The package is not.

Consumers write queries against these IRIs. A namespace carrying the package version would change on every minor release and break every query written against the last one. 1.0 changes only when a term changes meaning or disappears. Adding terms is not a breaking change and does not move it.

Three layers

Reuse a published standard where one exists. The DDI Alliance publishes two RDF vocabularies covering much of this ground: DISCO, built from DDI Codebook and DDI Lifecycle, and XKOS, which extends SKOS for statistical classifications. Code lists and categories map onto SKOS itself. A Variable is exported as a disco:Variable, so it joins to anyone else's DISCO data without a translation step.

Mint one namespace for the rest. DISCO defines 16 classes. The DDI schemas this package reads carry roughly 250 node labels. Everything with no standard equivalent gets a term here.

Emit both types, always. The alignment is many-to-one: Question and QuestionItem are both disco:Question; CodeScheme, CodeList and CategoryScheme are all skos:ConceptScheme. From the standard type alone, a reader cannot tell which one it started as. So every node carries two types:

<urn:ddi:ie.cso:q-4711:1.0.0>
    a disco:Question , ddigraph:QuestionItem ;
    skos:prefLabel "Main activity status"@en-IE .

Interop consumers read disco:Question and ignore the rest. The ddigraph reader reads ddigraph:QuestionItem and reconstructs the original graph exactly. This is the reason ddigraph export and ddigraph load can round-trip a file without losing anything.

What is in the document

vocabulary.ttl is generated from the same schema tables that generate the Neo4j constraints and the SHACL shapes, so it cannot describe terms the exporter does not emit. It defines:

Kind	Count	Declared as
Classes	249	owl:Class, one per node label
Object properties	369	owl:ObjectProperty, one per relationship type
Datatype properties	85	owl:DatatypeProperty, one per minted record attribute

Terms with a published equivalent are declared against it rather than redefined:

ddigraph:QuestionItem a owl:Class ;
    rdfs:label "QuestionItem"@en ;
    rdfs:subClassOf disco:Question .

rdfs:subClassOf, not owl:equivalentClass. Every ddigraph:QuestionItem is a disco:Question, but not every disco:Question is a QuestionItem — some are Question. Declaring them equivalent would tell a reasoner that Question and QuestionItem are the same thing.

The document asserts nothing about DISCO, SKOS or XKOS terms themselves. Statements about someone else's vocabulary belong in their document, not this one.

Direction matters

Most aligned predicates are declared with rdfs:subPropertyOf. Three are not:

ddigraph:hasCategory a owl:ObjectProperty ;
    rdfs:label "HAS_CATEGORY"@en ;
    owl:inverseOf skos:inScheme .

The graph models controlled vocabularies container-first, because that is how the XML nests: CodeList -HAS_CATEGORY-> Category. SKOS models them member-first: the concept carries skos:inScheme, and skos:member belongs to skos:Collection rather than skos:ConceptScheme. The exporter swaps subject and object for those, so the correct relation between the two predicates is owl:inverseOf. Declaring it a subproperty would tell a reasoner the scheme is in the concept.

Subject IRIs

Subjects use the DDI URN where the record has one:

urn:ddi:ie.cso:q-4711:1.0.0

It is globally unique, agency-neutral, and already the identifier the DDI world uses. Where a record has no URN, the IRI falls back to {base}/{Label}/{id} — pass --base-uri to ddigraph export to publish under a domain you control.

Using it

See the RDF backend guide for the export commands, the SPARQL examples and the SHACL shapes, and the RDF case study for a code list taken all the way from DDI to validated linked data.