Le vocabulaire ddigraph, version 1.0

Cette page est ce que résout https://pbisson44.github.io/ddigraph/ns/1.0/. Dans un graphe exporté par ddigraph, tout IRI qui n'est pas un terme standard publié vit sous cet espace de noms, et cette page dit ce que ces termes signifient.

Télécharger vocabulary.ttl

Pourquoi la version n'est pas celle du package

L'espace de noms est en 1.0. Le package, non.

Les consommateurs écrivent leurs requêtes contre ces IRI. Un espace de noms portant la version du package changerait à chaque version mineure et casserait toutes les requêtes écrites contre la précédente. 1.0 ne change que lorsqu'un terme change de sens ou disparaît. Ajouter des termes n'est pas une rupture et ne le fait pas bouger.

Trois couches

Réutiliser un standard publié quand il en existe un. La DDI Alliance publie deux vocabulaires RDF qui couvrent une bonne part du terrain : DISCO, construit à partir de DDI Codebook et DDI Lifecycle, et XKOS, qui étend SKOS pour les classifications statistiques. Les listes de codes et les catégories s'alignent sur SKOS lui-même. Une Variable est exportée en disco:Variable : elle se joint donc aux données DISCO de n'importe qui sans étape de traduction.

Créer un seul espace de noms pour le reste. DISCO définit 16 classes. Les schémas DDI que lit ce package portent environ 250 libellés de nœuds. Tout ce qui n'a pas d'équivalent standard reçoit un terme ici.

Toujours émettre les deux types. L'alignement est multiple vers un : Question et QuestionItem sont tous deux disco:Question ; CodeScheme, CodeList et CategoryScheme sont tous skos:ConceptScheme. À partir du seul type standard, un lecteur ne peut pas savoir lequel était le point de départ. Chaque nœud porte donc deux types :

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

Les consommateurs orientés interopérabilité lisent disco:Question et ignorent le reste. Le lecteur ddigraph lit ddigraph:QuestionItem et reconstruit le graphe d'origine à l'identique. C'est la raison pour laquelle ddigraph export et ddigraph load peuvent faire un aller-retour sans rien perdre.

Ce que contient le document

vocabulary.ttl est généré à partir des mêmes tables de schéma que les contraintes Neo4j et les formes SHACL : il ne peut donc pas décrire des termes que l'exportateur n'émet pas. Il définit :

Type	Nombre	Déclaré comme
Classes	249	owl:Class, une par libellé de nœud
Propriétés d'objet	369	owl:ObjectProperty, une par type de relation
Propriétés de données	85	owl:DatatypeProperty, une par attribut créé

Les termes ayant un équivalent publié sont déclarés par rapport à lui plutôt que redéfinis :

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

rdfs:subClassOf, et non owl:equivalentClass. Tout ddigraph:QuestionItem est une disco:Question, mais toute disco:Question n'est pas un QuestionItem : certaines sont des Question. Les déclarer équivalents dirait à un moteur d'inférence que Question et QuestionItem sont la même chose.

Le document n'affirme rien sur les termes DISCO, SKOS ou XKOS eux-mêmes. Les affirmations sur le vocabulaire d'autrui appartiennent à son document, pas au nôtre.

Le sens compte

La plupart des prédicats alignés sont déclarés avec rdfs:subPropertyOf. Trois ne le sont pas :

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

Le graphe modélise les vocabulaires contrôlés en partant du conteneur, car c'est ainsi que le XML s'imbrique : CodeList -HAS_CATEGORY-> Category. SKOS part du membre : le concept porte skos:inScheme, et skos:member appartient à skos:Collection plutôt qu'à skos:ConceptScheme. L'exportateur échange donc sujet et objet pour ceux-là, et la bonne relation entre les deux prédicats est owl:inverseOf. En faire une sous-propriété dirait à un moteur d'inférence que le schéma est dans le concept.

Les IRI de sujet

Les sujets utilisent l'URN DDI lorsque l'enregistrement en a un :

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

Il est unique au niveau mondial, neutre vis-à-vis de l'agence, et c'est déjà l'identifiant qu'utilise le monde DDI. Lorsqu'un enregistrement n'a pas d'URN, l'IRI retombe sur {base}/{Libellé}/{id} : passez --base-uri à ddigraph export pour publier sous un domaine que vous contrôlez.

L'utiliser

Voyez le guide du backend RDF pour les commandes d'export, les exemples SPARQL et les formes SHACL, et l'étude de cas RDF pour une liste de codes menée de DDI jusqu'aux données liées validées.