Comment récupérer des données basiques

[Ben]

Je souhaiterais récupérer dans un premier temps des informations somme toutes, assez basiques.

Nom de l’hébergement
Adresse - Cp -Ville
Téléphone
email
téléphone

Voilà plusieurs jours que je me casse la tête à trouver la logique la plus simple pour parser et récupérer ces données. Je travaille bien sur des objets et je code en ruby.

Dans le meilleur des cas, j’arrive à récupérer 90% des données, mais sans aucune garantie sur la fiabilité.

Je voudrais juste illustrer mon propos : Pour simplement récupérer l’adresse, le cp et la ville…

Je récupère donc l’uri des hébergements et vais récupérer la key isLocatedAt

Jusque là pas de soucis

A ce niveau, il faut déjà que je gère 3 possibilités :

1. isLocated => renvoie juste un @id parfois vers un autre => isLocated parfois vers => hasContact
2. isLocated => renvoie schemaAddress avec un @id vers => hasContact {schemaAddress avec les données qui m’intéressent}
3. isLocated => renvoie schemaAddress avec les données comme rue, cp, ville…

Parfois on peut récupérer le legalName, le telephone, l’email, le site web, dans une de ces branches mais pas toujours…
Le parcours du graph devient alors très compliqué, puisque pour chaque branche, il faut gérer les exceptions.
Vérifier par exemple si l’adresse est présente, sinon utiliser une autre méthode… on perd en efficacité et la fiabilité des données n’est pas assurée.

J’ai bien entendu votre argument, sur les POIs qui ont un lieu mais avec un contact à un autre endroit.

La logique ne serait-il pas d’avoir pour tous les POIs ces données obligatoires :

• Nom du POI
• address
• zip_code
• city
• telephone
• email
• website

Sauf erreur, ces informations sont génériques à tous les Pois
Un marché à un lieu, (éventuellement un telephone, un email, un website)
Un évènement, un hébergement, un restaurant… c’est pareil. Pour faire simple, je vais dire qu’il s’agit des données commerciales de base.

Loin de moi, l’idée de vous jeter la pierre, j’ai tout à fait conscience du travail qu’il y a derrière. Je suis peut être tout simplement passé à coté de la logique qu’il faut suivre.
Voilà plusieurs jours, que j’essaie de remonter le fil, et qu’à chaque fois je rencontre de nouvelles exceptions…

Je tenais simplement à vous faire part de ces difficultés, même si je vous le redis, cela vient peut être de ma logique…

Si je m’y prend mal, je serai ravi que vous m’indiquiez la voie à suivre

Merci

[conjecto]

Bonjour,

Les données DATAtourisme sont stockées sous un format Graph/RDF, certaines sous ressources et propriétés cités dans la documentation sont obligatoires.
Documentation · master · datatourisme / ontology · GitLab , les fichiers PDF mais aussi la documentation HTML qui décrit les classes et propriétés. (la doc html est aussi disponible aussi ici → http://www.datatourisme.fr/ontology/core/2.0/)

Les noms, villes, coordonnées géographiques et d’autres informations sont effectivement obligatoires.

Ceci implique coté manipulation de la donnée que toutes les autres sous ressources et propriétés doivent par défaut être considérées comme potentiellement absentes.

Avec le format Json-ld, le parcours du graph est effectué avec des références (les @id) de ressources, ce qui permet de ne pas les répéter dans le fichier.

Il existe des librairies en ruby pour vous aider à manipuler des graphs → Ruby RDF · GitHub
Et spécifiquement du json-ld GitHub - ruby-rdf/json-ld: Ruby JSON-LD reader/writer for RDF.rb
(Ceci n’est pas une liste exhaustive)

Vous pouvez par exemple avec une « frame json-ld » ne garder que les POI qui ont les sous-ressources et propriétés que vous considérez comme obligatoires.

Vos retours utilisateur sur la pertinence ou la qualité des données fournies sont important car ils permettent aux producteurs d’améliorer ces dernières.

Merci pour vos questions sur ce forum car elles sont tout aussi importantes pour accompagner les ré-utilisateurs à rentrer dans l’univers du Linked Open Data. (Linked open data — Wikipédia)

Cordialement.

[Ben]

Le seul objectif de mes remarques, c’est de vous aider à proposer un outil fiable et performant.

Mais ne pensez vous pas que les informations génériques, propres à tous les pois :

• Nom du POI
• address
• zip_code
• city
• telephone
• email
• website

gagneraient à se trouver au niveau le plus haut, sans que l’ont ai besoin de descendre dans le graph ?

[Rodolphe_TERRY]

Bonjour Ben,

Ton objectif est il de « télécharger » dans ta base les infos POI depuis DataTourisme et de les actualiser périodiquement ? Si tel est le cas, je te conseille, mais ce n’est que mon avis et ma méthode, de les extraire via une requête SPARQL (bien sûr il faut se cogner l’apprentissage de ce langage un peu déroutant aux premiers abords, surtout si tu connais bien déjà SQL). Ceci te permet de mettre en place, entre DataTourisme et ton appli, un couche d’abstraction avec ton format d’échange propriétaire. Si tu dois intégrer une autre base tierce plus tard, tu n’auras pas à modifier ton code mais simplement à procéder de la même manière.

Je confirme qu’il y a trop de combinatoires au cas par cas à gérer actuellement dans DataTourisme pour pouvoir récupérer les données génériques que tu mentionnes. Il faut donc tu partes du principe que tu essaies d’en récupérer un maximum en gérant quelques cas par cas en fonction de ce que tu observes sur tes premières extractions. En ce qui me concerne avec des POI de type « événements » (incluant une date de début et une date de fin par définition) je ne peux pas tout récupérer à 100% et surtout je dois admettre un taux de fiabilité inférieur à 100%. Le problème est que je ne peux pas chiffre ce taux de fiabilité. Je préfère donc perdre de POI plutôt que d’avoir des données approximatives, voir fausses, pour mes utilisateurs finaux.

J’espère que cela puisse t’aider dans ta réflexion.

[Ben]

Merci Rodolphe pour ton éclairage,

Si je ne me trompe pas, sparql permet simplement de faire la requête générant le json-ld. Donc à priori, ce là ne devrait rien changer dans le fait qu’au moment du parsing, les données soient à des niveaux différents.
J’ai constaté, qu’en fait chaque STI avait un modèle qui a certainement été mappé avec datatourisme. Je travaille donc sur des méthodes différentes avec chaque département, c’est loin d’être idéal, mais de cette façon, j’arrive à récupérer près de 100 % des données.
Ca va parce que je travaille pour l’instant en mode test et sur un nombre de dpts réduits, mais c’est difficile à maintenir et j’espère que l’équipe de datatourisme adaptera ses modèles.