Cohérence dans le mapping des données?

[Ben]

Je pense que le souci, c’est qu’il y a un problème de mapping entre les différents STI et datatourisme.

Je viens de me battre à gérer toutes les exceptions en prenant comme données modèle les hébergements du département de l’Aveyron… ça passe impec
Sauf qu’en voulant élargir à d’autres départements, patatra mon script tombe.

Pour le dépt 48 :
Pour récupérer l’adresse, les coordonnées de base (tel, email…etc) il faut taper dans

• isLocated (shema:adresse) + isOwnedBy

Pour le dépt 12 :
Pour récupérer l’adresse, les coordonnées de base (tel, email…etc) il faut taper dans

• hasContact (schema adresse) etc…
• isLocated est vide

Pour le dépt 40 :
C’est encore différent

A l’heure actuelle, sur des données basiques (Nom etabl., propriétaire, localisation, contact), il est quasi impossible d’exploiter les données de datatourisme de façon générique. Il y a beaucoup trop d’exceptions à gérer. Seule solution, faire un script pour chaque département… (région ?)

Je pense que c’est un axe de travail que vous devriez privilégier, la cohérence des données est primordiale pour qui voudrait exploiter ces données

Selon moi, isLocated et isOwned devraient être la base de tout POI. A condition également qu’on y trouve toutes les infos comme nom du propriétaire, email, téléphone… qui sont parfois dans d’autres branches.

Allez courage, vous allez y arriver

[Equipe_DATATOURISME]

Bonjour Ben,
Tous les POis doivent toujours avoir une adresse renseignée (Place) dans isLocatedAt, sinon le POI n’est pas valide.
Concernant le contact, il se peut qu’il y ait effectivement un Agent associé au Place du isLocatedAt. Dans ce cas c’est le contact du lieu.
Cependant, il se peut que le contact soit spécifique, dans ce cas, il faut effectivement aller voir dans hasContact. Ce contact pouvant d’ailleurs être typé : booking, information, …

merci

[Ben]

C’est une bonne chose, cependant, par exemple sur le département de l’Aveyron, dans isLocated nous ne pouvons récupérer que les coordonnées géographique :

      "isLocatedAt": {
    "@id": "data:33ef82cb-4626-3716-9b2d-5fcf562ef203",
    "schema:address": {
      "@id": "data:c72d300e-3f99-3a00-95d9-a5081533eae6"
    },
    "schema:geo": {
      "@id": "data:5fe35eda-946c-38dd-b7f1-5093fef40b1e",
      "schema:elevation": {
        "@value": "364",
        "@type": "xsd:decimal"
      },
      "schema:latitude": {
        "@value": "44.0717",
        "@type": "xsd:decimal"
      },
      "schema:longitude": {
        "@value": "3.1214",
        "@type": "xsd:decimal"
      },
      "@type": "schema:GeoCoordinates",
      "latlon": {
        "@value": "44.0717#3.1214",
        "@type": "http://www.bigdata.com/rdf/geospatial/literals/v1#lat-lon"
      }},

Avec un renvoie vers le hasContact pour les legalName, adresse etc…

C’est dommage que ces données ne soient pas rendues obligatoires dans isLocated, ce serait plus facile à parser

[Ben]

Désolé, je viens de comprendre, sans pour autant que cela résolve mon problème Je m’étais basé sur le json de l’aveyron, sans que celui-ci soit représentatif de la logique de l’Api.

Si je prends pour exemple cette donnée : https://data.datatourisme.gouv.fr/31/8a8c5905-6c16-39f4-9cd9-8cb15a523946

Dans isLocated, je peux récupérer l’@id de schemaAddress : data:59531715-3ef9-3e6e-ab47-96190f795e01 mais si je me réfère seulement à cet @id pour aller parser schemaAddress, je ne peux pas récupérer, le téléphone, l’email et le site web, qui se situent dans le schemaAdress suivant.

C’est peut être un cas isolé, ne n’ai pas encore fait de test, mais pourquoi ne pas faire remonter ces données au niveau de isLocated ?

Merci pour votre soutien

[Equipe_DATATOURISME]

Les coordonnées ce contact ne sont pas forcément ceux du site physique indiqué dans isLocatedAt.
Exemple: une brocante à lieu sur une place de marché, le contact des organisateurs est ailleurs…
Merci pour votre intérêt

[Ben]

J’entends bien, dans votre exemple c’est cohérent… puisque que c’est un « évènement », masi pour tous les autres, ça l’est bcp moins (hebergement, restaurant, parc, musée…)
Peut être qu’un traitement différencié serait judicieux ?

Mais par exemple, isLocated ne renvoie pas forcément à un schema:Address donc difficile de changer de niveau.

Pour l’uri :

Brit Hôtel Cahors - Le Valentré | DATAtourisme

renvoie : « isLocatedAt »: {"@id": « data:627c54c6-d877-3883-ba12-581bbd12392b »}
mais cet @id correspond à schemaAddress d’un autre POI https://data.datatourisme.gouv.fr/22/1b806512-91c7-3b2c-9162-36b36f7a6ee1

[Equipe_DATATOURISME]

isLocated renvoie systématiquement sur une instance de Place
Il se peut effectivement que des POIs soient sur le même lieu : expositions d’un musée, concerts dans une salle… et cas très très rare j’imagine : deux hôtels !
Pour créer l’ontologie nous nous sommes basés sur Schema et Foaf et avons suivi leur logique.

[Ben]

Le problème ne vient probablement pas de l’ontologie qui est construit sur des bases avérées, mais peut être du mapping entre les différents STI et datatourisme. Qu’en pensez vous ?

[Equipe_DATATOURISME]

Il ne faut pas confondre les sens de isLocatedAt et hasContact même si ces deux propriétés peuvent faire référence à une même instance de Place.