Brevet FR2841671A1 — publié le 20040102

Le domaine concerné est celui de la production industrielle d'information pratique à l'usage de services à valeur ajoutée. Il s'agit de produire et de vendre des données concernant des évènements ou des lieux accessibles au public. Par exemple des informations pratiques concernant un concert, un restaurant, une visite guidée, etc. La partie temporelle indique quand est-ce qu'un lieu est ouvert ou quand est-ce que évènement a lieu. Les possibilités d'interactivité offerts par les produits communicants ou nomades, nécessitent la production d'informations pratiques plus détaillées notamment sur la partie temporelle. Produire des informations détaillées est fastidieux et coteux. Traditionnellement, les process ne sont pas flexibles. Produire des informations détaillées implique de ne produire que des informations détaillées. Les producteurs d'information pratique produisent donc soit beaucoup d'information avec peu de détail, soit peu d'information avec beaucoup de détail. Actuellement, les principales utilisations de telles informations utilisent un seul niveau de détail pour toutes leurs données. Or, toutes les utilisations de l'information ne nécessitent pas le niveau de détail maximal. Pour un producteur, une façon d'optimiser les cots de production serait de produire certaines données avec un niveau de détail élevé, et d'autres avec un niveau de détail plus faible. Pour un utilisateur, une façon de baisser les cots o d'acheter plus de données serait d'utiliser certaines données avec un niveau de détail élevé, et d'autres avec un niveau de détail plus faible. Une organisation qui rassemble des objets liées à des données temporelles, doit pour satisfaire ses clients, sélectionner et communiquer certains des objets et leurs données temporelles en fonction d'un intervalle de temps. Il s'agit par exemple d'extraire les évènements de loisirs auquel une personne pourrait aller pendant trois jours de vacances, ou bien l'ensemble des informations pratiques des évènements ou des lieux accessibles pendant la semaine à venir. Les échanges se font traditionnellement avec un seul niveau de précision déterminé. En effet, lorsque la précision des données est variable, des difficultés apparaissent: Les données temporelles ne peuvent alors pas toutes être comparées entre elles, et elles ne peuvent pas toutes être traitées de la même façon par le système utilisateur. L'échange de données temporelles de précision hétérogène est source d'ambiguté. Les réponses sont a priori impossibles à interpréter et à traiter par l'utilisateur. L'objet de l'invention est un protocole, basé sur une métrique spécifique, permettant de réaliser sans ambiguté cet échange de données avec une partie temporelle, ceci avec la possibilité de gérer des informations connues à des niveaux de détail différents. Le protocole s'applique pour un système (1) qui interroge un système (2). Le système (2) dispose d'informations temporelles sur des évènements ou des lieux publics. Le système (1) souhaite obtenir une liste d'évènements ou de lieux disponibles sur un intervalle de temps. Le système (1) envoie une demande au système (2), constitué d'un intervalle de temps à l'intérieur duquel les évènements ou lieux doivent être accessibles. Selon l'invention, le protocole stipule que dans la demande, l'intervalle de temps peut être de plusieurs niveaux de précision - niveau de demande 1 (Ql). Demande sur un intervalle de Dates Une date de début (jour/mois/année) (Dl) et une date de fin (jour/mois/année) (D2) - niveau de demande 2 (Q2). Demande sur un intervalle de temps à l'heure près: Une date et une heure de début (jour/mois/année (Dl), heure/minutes (Hi)> et une date et une heure de fin (jour/mois/année (D2), heure/minutes (H2)) - niveau de demande 3 (Q3). Demande sur un intervalle de dates, tous les jours à heures fixées : Une date de début (jour/mois/année) (Dl) et une date de fin (jour/mois/année) (D2), complétés par une heure de début (heure/minutes) (Hi) et une heure de fin (heure/minutes) (H2) valables pour toute la période. - niveau de demande 0 (QO). Demande sans intervalle: Ne pas donner de contraintes de dates et heures. Le système (2) dispose d'un ensemble de données temporelles d'évènements ou de lieux publics: Les données sont composées soit de valeurs dites structurées, soit de texte dit texte libre. Les valeurs structurées sont un ensemble de valeurs individuelles, de type de dates et heures, ou numérique ou booléens, c'est à dire un ensemble d'éléments sur lesquels on peut appliquer des méthodes automatiques de comparaison et de calcul. Le texte libre peut être compris par un lecteur, mais ne peut pas faire l'objet d'opérations. Le système (2) envoie une réponse au système (1). Selon l'invention, le protocole stipule que dans la réponse, pour chaque évènement ou lieu public sélectionné (O), on associe une mesure (N) qui permet de distinguer le niveau de précision de la réponse. Ces mesures sont référencées dans la métrique objet de l'invention, et qui comporte les niveaux suivants Voici tout d'abord les principaux niveaux - mesure 6 sur 6 (R6) - "Date et heure OK" Les données structurées ont permis de déterminer que le lieu était accessible au moins un des jours de l'intervalle demandé et dans l'intervalle horaire demandé. - mesure 5 sur 6 (R5): "Date OK et plage horaire" Les données structurées ont permis de déterminer que le lieu était accessible au moins un des jours de l'intervalle demandé. Au niveau des horaires, la partie heures des données structurées a permis de déterminer que l'intervalle horaire demandé était cohérent avec les plages d'accessibilité publique, c'est à dire qu'au moins une des plages horaires possède un moment commun avec l'intervalle horaire. L'évènement ou le lieu est donc potentiellement accessible à l'intérieur des heures demandées. En revanche, faute d'avoir la garantie qu'à l'intérieur de ces plages horaires il n'y a pas d'heures d'interruption, ou faute de savoir si toutes les plages ont été indiqués dans les données structurées, on ne peut garantir l'accessibilité pendant l'intervalle horaire demandé. - mesure 3 sur 6 (R3): "Date OK" Les données structurées ont permis de déterminer que le lieu ou l'événement était accessible au moins un des jours de l'intervalle demandé. En revanche, si la demande comporte des heures, ces heures n'ont pas été prises en compte, et l'on ne peut pas garantir que l'évènement ou le lieu est accessible aux heures indiquées. - mesure 2 sur 6 (R2): "Plage de dates": Les données structurées étant composées de plages de dates (jour/mois/année de début et jour/mois/année de fin), elles ont permis de déterminer que l'intervalle demandé était cohérent avec les plages d'accessibilité publique, c'est à dire qu'au moins une des plages possède un moment commun avec l'intervalle. L'évènement ou le lieu est donc potentiellement accessible. En revanche, faute d'avoir une information structurée sur l'intérieur des plages de dates, notamment savoir s'il y a des jours d'interruption, on ne peut garantir l'accessibilité pendant la période demandée. De plus, si la demande comporte des heures, ces heures n'ont pas été prises en compte, et l'on ne peut pas garantir que l'évènement ou le lieu est accessible aux heures indiquées. A ces niveaux se rajoutent les niveaux suivants - mesure 0 sur 6 (RO): "Pas de données" Les données structurées étant inexistantes, elles n'ont pas du tout permis de déterminer si l'évènement ou le lieu était accessible selon les critères temporels demandés. - mesure 1 sur 6 (Rl): "Dates inconnues, mais a priori accessible" Les données structurées comportant uniquement la notion "accessible une majorité de jours", qui ne permet pas de déterminer si l'évènement ou le lieu est accessible selon les critères temporels demandés, mais permet faire ressortir l'objet avec une probabilité d'être accessible assez forte. - mesure 4 sur 6 (R4): "Date OK, heures inconnues mais a priori accessible" Les données structurées ont permis de déterminer que l'événement ou le lieu était accessible au moins un des jours de l'intervalle demandé. En revanche, si la demande comporte des heures, on ne peut pas garantir que l'événement ou le lieu est accessible aux heures indiquées. Cependant, les données structurées comportant la notion "accessible une majorité de la journée", l'objet peut ressortir comme ayant une probabilité plutôt forte d'être accessible dans l'intervalle horaire. L'utilisation de la métrique décrite ci-dessus, ou d'une partie de cette métrique, dans le cadre du protocole, permet de réaliser l'échange de données souhaité sans ambiguté. Elle est illustrée dans la figure 1. Une des utilisations de ce protocole est que le système (2) fournisse dans sa réponse l'ensemble des objets (O) correspondant à un quelconque des niveaux (N) dans la métrique, malgré l'incertitude. Les données sont tout de même exploitables, car les données texte libre permettront lorsqu'un lecteur interviendra dans la chaîne, de lever l'ambiguté. Le protocole stipule que dans la réponse, le système (2) rappelle le niveau de détail de la demande. Il est à noter que: - pour un niveau de demande 0 (QO), la mesure des réponses ne peut être que 0 ou 1. - pour un niveau de demande 1 (Ql), la mesure des réponses ne peut être que de 0 à 3. - pour un niveau de demande 2 (Q2) ou 3 (Q3), la mesure des réponses peut être de 0 à 6. Cet aspect est illustré dans la figure 2. Lorsque l'incertitude n'est pas souhaitable pour le système (1), le protocole stipule de manière optionnelle que le système (1) peut indiquer dans sa demande quelles mesures de la métrique sont acceptables pour lui, et ne recevoir dans la réponse que des objets ayant certaines mesures de la métrique. Lorsque cette option est activée, le protocole peut permettre que le système (1) demande à ce que les informations envoyées par le système (2) soient triées dans un certain ordre en fonction des données temporelles. Les systèmes de tri possibles dépendent des niveaux (N) de la métrique acceptables choisis par le système (1). En effet, il est possible de trier entre eux des objets qui ont un minimum de précision commune. Une autre option du protocole est de permettre au système (2), dans le cas de réponse de mesure 2 (R2) ou 5 (R5), c'est à dire les cas o l'on touche des intervalles de dates, d'indiquer un pourcentage de chance que l'objet soit bien accessible. Ceci peut en effet se faire en se basant sur une donnée structurée indiquant le pourcentage de jours ou d'heures qui sont accessibles dans ces plages de dates ou d'heures dans lesquelles on sait qu'il y a une interruption, sans savoir o. Une autre option du protocole est de stipuler que dans la réponse, le système (2) doit donner les information structurées et de texte selon les règles suivantes: - Elément de réponse "global" Un premier niveau d'informations composé de deux éléments structurés: une date de début et une date de fin, et éventuellement une heure de début et de fin (jj/mm/aa et jj/mm/aa ou bien jj/mm/aa hh:mm et jj/mm/aa hh:mm), ainsi que d'une partie texte libre, les deux décrivant les informations temporelles globales, c'est à dire sur toute la plage d'accessibilité du lieu ou de évènement connus par le système (2). - Elément de réponse "sur l'intervalle demandé" Un second niveau d'informations composé de deux éléments structurés : une date de début et une date de fin, et éventuellement une heure de début et de fin (jj/mm/aa et jj/mm/aa ou bien jj/mm/aa hh:mm et jj/mm/aa hh:mm), ainsi que d'une partie texte libre. Les dates et heures structurées sont calculées afin d'être inclues dans l'intervalle de temps demandé par le système (1). De même, le texte libre décrit les informations temporelles uniquement sur l'intervalle de temps demandé par le système (1). - Elément de réponse "détaillé" Un troisième niveau d'informations composé uniquement éléments structurés, en donnant uniquement les données correspondant à l'intervalle de temps demandé par le système (1). Une autre option du protocole est de permettre au système (2) de préciser pour chaque objet (O) figurant dans la réponse, si parmi ses données structurées, il dispose de la liste des jours de la semaine. Une autre option du protocole est de permettre au système (2) de préciser pour chaque objet (O) figurant dans la réponse, si l'accessibilité du lieu ou de évènement débute ou finit dans la période de temps demandée. Une autre option du protocole est de permettre au système (2) de préciser pour chaque objet (O) figurant dans la réponse, si l'accessibilité du lieu ou de l'événement est de type "séance", c'est à dire que le public doit être présent à l'heure de début, ou bien si l'accessibilité est de type "ouvert", c'est à dire que le public peut entrer ou sortir quand il veut à l'intérieur des horaires d'ouverture. Il est à noter que dans le cas d'un objet de type "séance" - lorsque, d'après les données structurées, l'événement commence et finit à l'intérieur de la plage horaire (Hl) à (H2) demandée par le système (1), la mesure est de niveau 6 (R6). - lorsque, d'après les données structurées, l'événement commence à l'intérieur de la plage horaire (Hl) à (H2) demandée par le système (1), mais que la durée de la séance est inconnue, la mesure est de niveau 5 (R5). L'heure de début est considérée pour le système (2) comme un intervalle très court situé à l'heure dite. Un mode de réalisation peut être un dialogue entre systèmes informatiques, les systèmes (1) et (2) pouvant être des serveurs informatiques de deux sociétés différentes, de la même société, ou deux parties d'un même programme, ou encore une partie stockage et une partie affichage d'un système. Le protocole peut s'implémenter sur les couches de protocoles existantes, par exemple http ou API ou XML, ou l'appel de fonctions d'un même langage informatique. Du côté du système (2),le protocole peut notamment être mis en oeuvre avec les technologies de base de données classique, par exemple SQL. Un système (2) qui utiliserait la métrique et le protocole peut être réalisé: - en partant de plusieurs systèmes capables de sélectionner des informations en fonction de leurs éléments temporels, chacun sur un seul niveau de précision, - en les faisant travailler ensemble en parallèle, et en rassemblant les résultats de chacun des systèmes grâce à la métrique et selon le protocole. Un mode de réalisation de cette métrique est un système tel que représenté sur la figure 3. Le système (2) est dans cet exemple une base de données SQL (BD) associé à un serveur d'application (SA) sur lequel tourne une application web dynamique. Le système (1) est un utilisateur sur un client type browser web (BW), il formule sa demande en saisissant sur une page formulaire (FO) date et éventuellement heures, et le système (2) renvoie la réponse sous forme de page web hmtl (HT), qui affiche une liste de données sur l'écran du browser. La mesure (N) de chaque donnée(O) selon la métrique est indiquée par un pictogramme. La métrique et le protocole peuvent être utilisés lors de la vente de données, soit que ces données comportent des éléments temporaires, soit que les éléments temporaires aient simplement servi, seuls ou couplés à d'autres critères, à faire la sélection de ces données. Une application industrielle est la fourniture d'information à un journal magazine ou quotidien au format texte, afin de créer, à un rythme régulier, des pages d'information o les évènements sont présentées avec un classement selon les dates et heures. Une autre application industrielle est le dialogue entre un système d'information d'un client et celui d'un fournisseur, le client utilisant ces informations pour la mise à jour d'une base de données servant à actualiser un site Internet et pour la rédaction d'un magazine ou d'un quotidien. Une autre application est la constitution d'un guide de voyage interactif ou l'utilisateur peut sélectionner les activités recensées en indiquant l'intervalle de dates ou d'heures qui l'intéresse, et avoir accès d'un seul coup par exemple à des information d'accessibilité temporelle de restaurants, peu précises, d'expositions, plus précises, et de spectacles, très précises. Une autre application est un fil d'information destiné aux professionnels des loisirs, o l'utilisateur peut indiquer la période sur laquelle il souhaite trouver des informations récentes. REVENDICATIONS 1) Un protocole permettant à deux systèmes informatiques (1) et (2) de s'échanger des données concernant des lieux et événements (O) avec des données temporelles structurées dont les niveaux de précision sont différents, - o le système (2) est dépositaire d'informations temporelles d'accessibilité au public de lieux et d'événements publics, - o les données temporelles stockées dans le système (2), pour chaque lieu ou événement, sont constituées: soit de données structurées, c'est à dire d'un ensemble de valeurs formatées au format date et heure ou au format numérique ou au format booléen, manipulables automatiquement par les banques de données et les langages de programmation classiques par comparaison et calcul, soit d'une zone de texte libre, soit d'un mélange de données structurées et de texte libre, caractérisé en ce que a) le système (1) envoie une demande au système (2) afin d'obtenir de ce dernier des données concernant des lieux ou évènements accessibles au public à l'intérieur d'un intervalle de temps donné, l'intervalle de temps envoyé par le système (1) étant structuré en dates de début et de fin (Dl) et (D2) et horaires de début et de fin (Hi) et (H2), et les valeurs nulles étant autorisées, b) le système (2) répond au système (1) avec un ensemble de données de résultats, concernant des lieux ou événements (O) potentiellement accessibles au public dans l'intervalle demandé, qu'il sélectionne en faisant des opérations de comparaison et de calcul entre les données structurées qu'il détient et les dates (Dl), (D2) et heures (Hl) et (H2), c) le système (2) adjoint aux données qu'il renvoie, pour chacun des lieux ou événements (O), une mesure (N) choisie dans une métrique comportant au moins 3 échelons et permettant de distinguer le niveau de précision des données structurées disponibles pour ce lieu ou cet événement, de sorte que le système (2) sélectionne et renvoie, dans la même réponse, des données concernant des lieux et événements (0) avec différents niveaux de précision des données temporelles structurées disponibles, et ceci sans ambiguté pour le système (1), ce qui ne serait pas possible sans la mesure (N), 2) Protocole permettant à deux systèmes informatiques (1) et (2) de s'échanger des données selon la revendication 1), caractérisé en ce que les mesures possibles de la métrique utilisée comportent au moins 3 des niveaux suivants - mesure 6 (R6): "Date et heure OK" Les données structurées de ce lieu ou de cet événement (0) ont permis au système (2) de déterminer que le lieu ou événement (0) est accessible à l'intérieur de l'intervalle demandé en prenant en compte à la fois les dates et les heures. - mesure 5 (R5): "Date OK et plage horaire" Les données structurées de ce lieu ou de cet événement (0) ont permis d'interpréter qu'il est potentiellement accessible durant l'intervalle demandé, ceci en prenant en compte les dates et les heures, mais sans prendre en compte d'éventuelles interruptions horaires, c'est à dire que le système (2) a pu manipuler d'une part des jours précis, et d'autre part des plages horaires qui ne détaillent pas forcément toutes les périodes d'interruptions horaires de (0). - mesure 4 (R4) "Date OK, heures inconnues mais a priori accessible" Les données structurées de ce lieu ou de cet événement (0) ont permis d'interpréter qu'il est potentiellement accessible durant l'intervalle demandé, ceci au niveau des dates mais sans pouvoir affirmer qu'il est aussi accessible au niveau des horaires indiqués, tout en ajoutant qu'au niveau des horaires, malgré l'absence de détermination, le lieu ou l'événement (0) peut être considéré comme à priori plutôt ouvert. - mesure 3 (R3): "Date OKT" Les données structurées de ce lieu ou de cet événement (0) ont permis d'interpréter qu'il est potentiellement accessible durant l'intervalle demandé, ceci au niveau des dates indiquées mais sans pouvoir affirmer s'il est aussi accessible au niveau des horaires indiqués. mesure 2 (R2): "Plage de dates" Les données structurées de ce lieu ou de cet événement (0) ont permis d'interpréter qu'il est potentiellement accessible durant l'intervalle demandé, ceci en ne prenant en compte que les dates, sans prendre en compte les heures, et sans prendre en compte d'éventuels jours d'interruptions, c'est à dire que le système (2) a pu manipuler uniquement des plages de dates qui ne détaillent pas forcement tous les jours d'interruption de (0). - mesure 1 (Rl): "Dates inconnues, mais a priori accessible" Les données structurées de ce lieu ou de cet événement (0) n'ont pas permis d'interpréter s'il est potentiellement accessible durant l'intervalle demandé en termes de dates ou d'heures, mais le système (2) peut indiquer cependant qu'au niveau des jours, malgré l'absence de détermination, le lieu ou l'événement (0) peut être considéré comme à priori plutôt ouvert. - mesure 0 (RO): "Pas de données" Les données structurées étant vides, elles n'ont pas du tout permis de déterminer si l'évènement ou le lieu est accessible durant l'intervalle demandé. 3) Protocole permettant à deux systèmes informatiques (1) et (2) de s'échanger des données selon la revendication 2), caractérisé en ce que le système (1) envoie une demande pouvant contenir en plus des dates de début et de fin (Dl) et (D2), et horaires de début et de fin (Hi) et (H2), une indication booléenne permettant de savoir: - si l'on est dans le cas (Q2), ie: l'heure (Hl) s'ajoute à la date (Dl) pour préciser le début de l'intervalle, et (H2) s'ajoute à (D2) pour préciser la fin de l'intervalle, - ou bien si l'on est dans le cas (Q3), ie: les heures (Hl) et (H2) indiquent un intervalle horaire valable tous les jours de l'intervalle de dates (Dl) à (D2), 4) Protocole permettant à deux systèmes informatiques (1) et (2) de s'échanger des données selon la revendication 2), caractérisé en ce que le système (1) précise dans sa demande qu'il ne doit obtenir dans la réponse du système (2) que des objets (O) ayant une mesure (N) faisant partie d'une liste restreinte de mesures de la métrique, spécifiée dans la demande. ) Protocole permettant à deux systèmes informatiques (1) et (2) de s'échanger des données selon la revendication 4), caractérisé en ce qu'il permet de manière optionnelle au système (1) de demander d'obtenir un résultat trié en fonction des éléments temporels, sachant que les types de tris possibles sont fonction desdits niveaux de la métrique. 6) Protocole permettant à deux systèmes informatiques (1) et (2) de s'échanger des données selon la revendication 2), caractérisé en ce que dans la réponse du système (2) au système (1), figure optionnellement la communication d'un ou plusieurs éléments suivants - un pourcentage de chance que l'événement ou le lieu soit accessible, dans le cas des niveaux 2 (R2) et 5 (R5). - une indication permettant de savoir si le système (2) possède parmi les données structurées de l'objet (O), la liste des jours de la semaine (lundi, mardi...) accessibles dans l'intervalle demandé. - une indication permettant de distinguer des évènements de type "séance" et ceux de type "ouvert" - une indication permettant de savoir si la période d'accessibilité totale du lieu ou de l'évènement débute ou bien se finit à l'intérieur de l'intervalle demandé par le système (1).