Identifiant unique pour un objet :EntertainmentAndEvent

[Rodolphe_TERRY]

Bonjour,

De ce que je comprends, un identifiant unique (propriété dc:identifier voir éventuellement l’uri de l’objet) est disponible pour tout :PointOfInterest et donc pour le sous type :EntertainmentAndEvent.

Concernant le sous type :EntertainmentAndEvent, la définition fournie dans la documentation est :

:EntertainmentAndEvent: manifestations, festivals, exposition, ou tout autre événement
ayant un début et une fin.

Actuellement il est impossible d’identifier de manière unique (au sens base de données) un événement précis au sein d’une série d’événements. C’est le cas par exemple pour un marché. Il est possible d’identifier clairement le « méta événement » de type :EntertainmentAndEvent (« le marché de Trifouilly-les-Oies » par exemple). Cependant il est impossible d’identifier clairement une date précise de l’événement (« le marché du JEUDI 13 MARS de Trifouilly-les-Oies » par exemple).

Etant gestionnaire et développeur d’une base de données d’événements, il y a, à mon sens, un problème de sémantique entre « événement » (avec UNE date de début ET UNE date de fin) et un « méta événement » (composé de plusieurs événement). Dans mon cas, il est indispensable de pouvoir identifier sans ambiguïté, au sein de la base DataTourisme, une programmation précise (UNE date de début ET UNE date de fin) d’un événement.

Merci pour votre retour sur ce point.

[Ben]

Rodolphe,

D’après les infos que j’ai pu lire, Datatourisme est une source de données « froides », donc, sauf erreur de ma part, pas d’actualisation sur les données chaudes « dates, tarifs, dispo…etc »

Cdt

[Rodolphe_TERRY]

Ben,

Je ne suis pas vraiment sûr de faire le distinguo entre données « chaudes » et « froides ». En tout cas j’ai observé des objets « événements » (:EntertainmentAndEvent) d’actualité mais qui présentent une date de publication périmée depuis plus d’un an. Ces objets présentent aussi une date de mise à jour, mais je ne suis pas sûr qu’elle soit fiable.

Ma problématique n’est pas en fait de récupérer d’éventuelles mises à jour d’un objet « événement ». Je souhaite pouvoir extraire des objets « événements » quotidiennement sans à avoir dans mon extraction ceux déjà récupérés la veille… D’où la nécessité d’un identifiant unique (croissant) de type indexe de table dans une base de données relationnelles.

Cordialement

[Ben]

Rodolphe,

Les données chaudes, ce sont des données qui bougent fréquemment, le meilleur exemple c’est les disponibilité d’une chambre par exemple.
Les données froides sont celles qui ne bougent que de temps en temps, voir jamais (l’adresse, le téléphone…etc)

Pour les évènements, je ne sais pas mais tu pourrais utiliser l’identifiant unique de datatourisme « dc:identifier » juste après l’@id.
Pour la dernière date de mise à jour je pense que c’est « lastUpdate »… mais c’est vrai que j’ai des données qui datent de 3 ans et plus, mais peut être qu’elles n’ont pas été modifiées depuis ?

Donc pour récupérer les fiches que tu n’as pas, tu compares le dc:identifier de ta base avec celui de datatourisme, s’il n’est pas dans la tienne tu récupères les données.

Bien entendu, ce n’est que ma lecture et je me trompe peut être. Datatourisme est encore très jeune et la marge de progression et l’amélioration des résultats vont forcément venir avec le temps.

Cdt

[Rodolphe_TERRY]

Ben,

Merci pour tes explications sur la « température des données ».

Concernant l’identifiant unique, j’ai effectivement « bricolé » un id custom mais ce n’est pas l’idéal. A quelle propriété fais tu allusion avec @id ?

J’extrais déjà des événements d’une base de données tierce qui propose bien un identifiant unique de type indexe. Pour le coup, c’est plus direct car il n’y a qu’à extraire le delta depuis le dernier identifiant récupéré. En plus de l’unicité de l’identifiant on peut donc utilisé le filtre « identifiant > dernier identifiant récupéré » sans se poser plus de questions.

Cordialement

[Ben]

      "@id": "https://data.datatourisme.gouv.fr/31/3c5d70dc-8a5b-3491-8a7e-b21103b46cb6",
  "dc:date": {
    "@value": "2017-04-06",
    "@type": "xsd:date"
  },
  "dc:identifier": "TFO221566270870"

TF0221… est un identifiant unique (je pense partagé avec les différents STI)

[Rodolphe_TERRY]

OK, c’est ce que j’appelais (à tort ?) l’uri de l’objet Evenement. Je concatène actuellement « @id de l’objet Evenement + dc:identifier + date de début » pour avoir un identifiant unique. Mais ce n’est vraiment pas terrible.

Je ne peux pas utiliser l’@id d’un objet date car ces objets dates sont réutilisés par de nombreux objets Evenements qui n’ont aucun lien sémantique entre eux. Cette réutilisation de données dates me semble très farfelue d’un point de vue structuration de données (mais ce n’est que mon avis).

[Ben]

Je pense que tu peux prendre cet identifier comme id unique tu rajoutes un champs date dans ta table.
Tu compares les id et ton champs date avec ceux de datatourisme et le tour est joué

[Rodolphe_TERRY]

Compliqué… ma plateforme web tourne déjà depuis 1 an avec d’autres fournisseurs de données. Je me suis par ailleurs basé sur le coeur d’un CMS sur lequel j’ai redéveloppé un gestionnaire d’événements… donc pas possible de customiser les tables du CMS. Dommage, va falloir se casser la tête pour intégrer les événements DataTourisme au chausse pied.

[Equipe_DATATOURISME]

Bonjour Rodolphe

L’identifiant du POI est avant tout son URI. Cette information est stable dans le temps.
Certains producteurs laissent leurs archives en ligne, vous pouvez donc trouver des Poi EntertainmentAndEvent dont les dates sont passées. Cela sert pour certains ré-utilisateurs. Vous pouvez filtrer pour ne prendre que ceux à venir.
Un Poi EntertainmentAndEvent doit avoir la propriété takesPlaceAt (se déroule le) complétée. Cette propriété peut contenir une ou plusieurs dates de début.
Pour votre exemple du marché, vous trouverez donc un seul POI avec une occurrence de période pour chaque date à laquelle a lieu ce marché.
En espérant vous avoir éclairé à mon tour

[Rodolphe_TERRY]

Bonjour,

Merci pour votre retour. C’est effectivement le fonctionnement de DataTourisme que j’avais observé et qui est limitant pour mes besoins. Cependant, je propose, à titre d’une éventuelle évolution future, de faire un différence de conception entre un événement simple (une date de début et une date de fin sans discontinuité) et un « méta événement » (événement périodique, récurrent ou avec une programmation discontinue), et de pouvoir identifié clairement un événement simple.

Cordialement,