Lecture (et compréhension) de la documentation : cardinalités

[Alain_DIART]

Bonjour,

je cherche à importer dans une base de données relationnelle des infos issues de DataTourisme.

J’ai lu la documentation de référence, mais reste dans le flou sur les cardinalités des relations entre les objets.

Par exemple hasContact semble être un many-to-one entre un PointOfInterest et son Agent. Par contre hasTheme semble être un many-to-many entre un PointOfInterest et ses thèmes(1).

D’abord, est-ce bien le cas ou bien tout est potentiellement many-to-many ?

Et si c’est le cas, quelle information dans la doc (ou ailleurs) pourrait me donner la cardinalité d’une relation ?

Question subsidiaire : est-il seulement envisageable d’espérer importer d’une manière fiable et relativement directe (sans introduire de traitement spécifique sur chacun des champs) des données de DataTourisme dans une base de données relationnelle ?

(1) Pour déterminer cette cardinalité, j’ai d’abord cherché dans la documentation si on parlait au singulier ou au pluriel des objets, puis à partir d’un fichier jsonld téléchargé, en regardant si le json me donne un objet ou un tableau. Mais ça ne colle pas toujours, par exemple dans la doc hasFeature dit « Quels équipements… » mais dans mon json j’ai un objet…

Merci

[Equipe_DATATOURISME]

Bonjour Alain,

Les cardinalités entre les objets ne sont pas déterminées. Pour le hasContact, un POI peut avoir plusieurs agents avec le rôle contact mais ce même contact (son URI) peut aussi être le contact de plusieurs POIs. Il en est de même pour « isLocatedAt », un POI se situe normalement sur un seul lieu (même si rien ne l’oblige dans l’ontologie), et ce lieu peut être lié avec son Uri sur plusieurs POIs. Tout est donc potentiellement en many to many.
Cela me parait très fastidieux de stocker du rdf dans un sgbd, à la limite vous pourriez y stocker des index pour la rapidité de requetes spécifiques. Pourquoi ne pas installer un triplestore comme Blazegraph par exemple ?

[Alain_DIART]

Merci de cette réponse qui confirme ce que j’avais cru identifier.

Blazegraph, on n’a aucune expertise dessus, je n’ai pas trouvé d’outil qui entre trop facilement dans le reste de notre projet, et notre sortie est à un moment ou un autre structurée. Les sites qu’on génère listent des « trucs » qui répondent à un format, nos intégrateurs/clients n’aimeraient pas avoir à gérer autant d’exception sur les données qu’ils manipulent. Et puis notre projet n’est pas seulement lié à DataTourisme, on a d’autres entités qui elles sont déjà dans le sgbd. On peut sans doute monter une architecture avec des tas de technos et de sources de données différentes, mais à un moment il me faudra les structurer.

Mais encore une fois, je n’ai pas d’expérience et très peu de connaissance sur les graphdb, je vais me donner un peu de temps pour explorer ce que ça peut ajouter aux sgbd/nosql, mais ce n’est instinctivement pas la piste que je privilégierais…

Merci de votre réponse, c’est très éclairant.

[conjecto]

Bonjour,

Pour compléter votre analyse/exploration l’équivalent du schéma relationnel en Linked Open Data existe sous la forme d’une ontologie.
Vous trouverez des informations sur la cardinalité de certaines propriétés dans cette ontologie. Par exemple owl:FunctionalProperty sur une propriété signifie qu’elle est présente au maximum 1 fois sur l’objet. (donc absente ou unique)
Celle dédiée à DATAtourisme se trouve ici → Files · master · datatourisme / ontology · GitLab

Cordialement