DATAtourisme

Jsonld... comment extraire un poi ?

J’essaie désespérément de parcourir le @graph pour extraire un poi.

Pour comprendre comment était construit le fichier, j’ai fais une requète pour n’avoir qu’un seul poi en sortie (un hébergement) => résultat un fichier de plus de 397 000 lignes, ça n’aide pas à la compréhension. :wink:

Peut être dans l’idéal, des exemples simples pourraient nous aider à construire nos requêtes.

Ma difficulté, c’est que je n’arrive pas à trouver la porte d’entrée de chaque poi, puisque quand je regarde le fichier, j’ai l’impression de n’avoir que des hashs superposés, alors que j’aimerais bien avoir un truc dans le genre :
{ @id: {hasContact: {telephone: 1}}}

Si je comprends bien l’@id permet de déterminer le point de départ des données d’un poi dans le fichier, tous les hashs qui sont dessous jusqu’à l’@id suivant, lui sont associés ?

Sinon, super boulot, manque peut être encore un peu de doc, mais avec ce forum, on devrait rapidement quitter les mains du cambouis, pour se faire plaisir.

Bravo et bon courage à vous :wink:

Bonjour Benoit,
Nous sommes sur DATATourisme en tant qu’utilisateur des données (diffuseur), j’ai pas mal tâtonné au départ pour savoir comment utiliser tout cela. Nous utilisons aussi le format JSON-LD (structuré)
La 1ere chose étrange est votre requête pour n’avoir qu’un seul POI en sortie : vous utilisez le mode « avancé » ? Je ne crois pas que vous puissiez avoir qu’un seul résultat.
Quoi qu’il en soit : une fois que vous récupérez votre export JSON-LD … vous devez l’exploiter.
Par exemple nous utilisons PHP et la librairie GitHub - lanthaler/JsonLD: JSON-LD processor for PHP … on indique à ce script le graph à ouvrir et là il va le charger (c’est assez long, PHP n’est pas top côté perf là dessus… il vaut mieux s’orienter sur du Nodejs qui est beaucoup plus rapide ou Python ou autre).

Après tout dépend de la librairie que vous utilisez mais normalement c’est du graph donc chaque noeud du graph va être accessible directement. De notre côté nous indiquons que nous voulons les noeud de type « PointOfInterest »… ensuite pour chacun de ses noeud nous avons ce qui nous intéresse .
Par exemple « getProperty(‹ hasContact ›) » (c’est vulgarisé, il faut rajouter l’URL disponible en haut du fichier json ld) pour accéder à la propriété « hasContact ».

L’@id est l’identifiant du noeud, c’est une URI.
Normalement ça vous retourne un objet javascript (json) tout ce qui est entre la même accolade de début et de fin appartient à l’objet. Entre chaque objet/noeud vous avez des virgules pour les séparer. La propriété @id se retrouve en début de chaque objet (en tous cas de mon côté…)

J’ai essayé d’être clair, désolé s’il y a des fautes.

Simon, développeur de Go-France

3 « J'aime »

Bonjour Ben,

Tout d’abord, merci pour votre retour !

Vous avez pointé du doigt une regression de la dernière mise à jour : il est tout à fait anormal qu’un flux contenant un seul POI fasse près de 400k lignes. Nous avons déployé le correctif, et votre flux de test fait maintenant 16ko pour un peu plus de 400 lignes.

Ensuite, il faut bien faire la distinction entre le JsonLD compacté et le JsonLD structuré :

  • Le JsonLD compacté est un format plat qui fonctionne exclusivement sur la base de références : toutes les ressources sont à la base du @graph et les propriétés utilisent les références grâce à @id. C’est un format plus léger mais un peu plus complexe à utiliser.

  • Le JsonLD structuré est un format qui imbrique les ressources les unes dans les autres, en fonction de leurs relations hiérarchiques et à partir d’un POI. Dans ce format, toutes les ressources à la base du @graph sont des POI.

Vous pouvez donc facilement accèder au numéro de téléphone de chaque POI :

"@graph": [
  {
    "@id": "https://data.datatourisme.gouv.fr/31/3c9e2aa7-f2e8-3f9e-a83c-0fadb53e3a8c",
    "hasContact": {
      "schema:telephone": "+33 5 65 72 91 56"
    }
  }
]

Si vous souhaitez manipuler un fort volume de données, nous vous conseillons plutôt de mettre en place une base de données sémantiques de votre côté et utiliser l’API GraphQL.

Si vous n’êtes pas à l’aise avec l’idée d’installer une base de données sémantiques, vous pouvez regarder du côté du stack Docker, qui inclut une base de donnée, un chargement automatique de votre flux et un point d’accès GraphQL.

GraphQL vous permet notamment d’atteindre plus simplement votre objectif :

query {
  poi {
    total 
    results {
      hasContact {
        schema_telephone
      }
    }
  }
}

Réponse :

{
  "data": {
    "poi": {
      "total": 195414,
      "results": [
       {
          "hasContact": [
            {
              "schema_telephone": [
                "+33 3 83 51 80 00"
              ]
            }
          ]
        }, 
        ...
      ]
    }
  }
}

N’hésitez pas à venir chercher de l’aide sur ce forum en cas de difficulté.

Et merci pour vos encouragements,

Cordialement.

1 « J'aime »

Merci à tous les deux pour votre retour :wink:

J’ai pas mal avancé et j’ai enfin réussi à récupérer des datas OUF :wink:

Je bloque un peu sur le hasContact car ça peut retourner un tableau… une exception qu’il me faut gérer :wink:

Pour info, je code sous ror :wink:

1 « J'aime »

oui, depuis juin il y a eu pas mal d’évolutions et d’améliorations mais en effet il faut jongler entre tableau ou objet directement après tout dépend de la méthode utilisée pour accéder aux données. bon courage !

1 « J'aime »