Année universitaire 2011/2012 Master 1 AIGLE Rapport de projet Web sémantique et données liés : application aux données de transport PARTIE APPLICATION Réalisé par DEMIRDJIAN Yves LAMOUREUX Gaétan Encadré par SCHARFFE François PLU Julien MAURY Marc SCHNEIDER Audrey
Remerciements Pour la réalisation de ce projet, nous tenons à remercier notre encadrant, François SCHARFFE, pour nous avoir orienté et conseillé durant ces quatre derniers mois, mais aussi pour nous avoir proposé un sujet aussi intéressant qu éducatif. Nous souhaitons aussi remercier Julien PLU pour l aide qu il nous a apporté durant la réalisation du projet, et enfin Jérémie VALENTIN, responsable du projet Open Data de Montpellier, pour le soutien apporté au projet et les explications fournies. 2
Table des matières Remerciements... 2 I. Introduction... 5 II. Analyse du projet... 6 a. Présentation du web sémantique... 6 b. Etude des données... 6 1. But du projet et analyse des données... 6 2. Trouver une idée de projet... 6 c. Cahier des charges... 8 1. Un projet innovant... 8 2. Mise en relation du sujet avec le web sémantique... 8 3. Côté joueur... 9 4. Côté organisateur... 9 d. Calcul du score... 11 e. Planning... 11 1. Planning prévisionnelle... 11 2. Planning réel... 12 f. Outils... 12 g. Diagrammes UML... 12 1. Diagrammes de cas d utilisation... 12 2. Diagrammes de séquences... 14 3. Diagramme de classes... 16 h. Mock-ups... 18 1. Côté organisateur... 18 2. Côté joueur... 22 III. Conception... 24 a. Langages et ressources... 25 b. Répartition des tâches... 25 IV. Résultats et discussion... 26 Partie joueur... 26 Partie administration... 27 Discussion générale... 27 V. Conclusion... 28 VI. Webographie... 29 3
VII. Glossaire... 30 VIII. Annexes... 32 a. Saisie-partie suite à la carto-partie (Kawenga)... 32 4
I. Introduction Dans le cadre de notre première année de Master Informatique AIGLE (Architecture et InGénierie du Logiciel et du web) à Montpellier, nous avons réalisé un projet sur une durée de quatre mois afin d appliquer nos connaissances, développer nos compétences et nous préparer au monde professionnel. Notre projet est né de la volonté de SCHARFFE François, chercheur au sein du LIRMM, et consiste à utiliser le Web sémantique et les données de transport de certaines villes. Ce projet a été élaboré avec 3 groupes d étudiants : le premier groupe «Conversion», qui consiste à créer du RDF brut, en déduire une ontologie, et convertir le RDF brut suivant cette ontologie ; le deuxième groupe «Interconnexion» qui doit permettre de relier plusieurs jeux de données RDF ; et notre groupe «Application» qui consiste à concevoir une application utilisant ces données. Ce rapport a pour but de présenter notre projet et détailler la conception de l application, que nous avons nommé «Géonigme», de la phase d analyse au produit final et fonctionnel. Dans un premier temps, nous évoquerons explicitement les besoins et exigences émanant du cahier des charges ainsi que les recherches, outils et méthodes pouvant être utilisés pour mener à bien le projet. Dans une deuxième partie, il s agira de détailler la phase de développement de Géonigme. Une troisième partie présentera les résultats obtenus, illustrés par des captures d écrans et agrémentés d explications. Puis, une quatrième partie fait l objet d une discussion dans laquelle nous ferons le point sur la réalisation du projet et où nous comparerons le produit final aux objectifs initiaux fixés. 5
II. Analyse du projet a. Présentation du web sémantique Le Web sémantique (plus techniquement appelé «le Web de données») permet aux machines de comprendre la sémantique, la signification de l'information sur le Web. Il étend le réseau des hyperliens entre des pages Web classiques par un réseau de lien entre données structurées permettant ainsi aux agents automatisés d'accéder plus intelligemment aux différentes sources de données contenues sur le Web et, de cette manière, d'effectuer des tâches (recherche, apprentissage, etc.) plus précises pour les utilisateurs. Le terme a été inventé par Tim Berners-Lee, co-inventeur du Web et directeur du W3C. La plupart du temps, lorsque l'on prononce le terme de Web sémantique, on parle des différentes technologies qui se cachent derrière. Parmi les plus connues, on peut citer RDF (Ressource Description Framework) qui correspond à un modèle d'information, et les formats d'échanges de données en RDF pour communiquer entre différentes applications (RDF/XML, RDF/JSON, N3, Turtle et d'autres). Dans le domaine du Web sémantique, la sémantique des données est décrite par des ontologies avec des langages prévus pour fournir une description formelle de concepts, termes ou relations d'un domaine quelconque. Ces langages sont RDFS (Resource Description Framework Schema) et OWL (Web Ontology Language). Ensuite, pour finir avec la liste des technologies, il existe un langage de requête, au même titre que SQL pour les bases de données relationnelles, SPARQL, qui effectue des requêtes mais sur des triplets RDF. b. Etude des données 1. But du projet et analyse des données Le but du projet défini dans le sujet est d utiliser des données de transports appartenant au web sémantique dans les formats décrit dans la partie Analyse du projet. Le sujet original étant divisé en 3 sous projets : Conversion, Interconnexion et Application et ayant choisi le sous projet Application, nous nous devions d utiliser les données générées par les autres groupes Conversion et Interconnexion. Ces données étaient d abord basées sur le portage des données actuelles que sur les transports de certaines agglomérations (Montpellier n en faisait pas partie). Puis le sujet s est un peu étendu du fait du peu d applications offertes et surtout par la difficulté à tester une application dont les données concernent des choses se trouvant à plusieurs centaines de kilomètres de notre université. Nous avons eu donc à disposition toutes les données du web sémantique disponibles sur la toile, à condition de trouver une idée novatrice, d utiliser des données du web sémantique et d implémenter une section en rapport avec les transports. 2. Trouver une idée de projet Une fois les recherches effectuées, nous devions trouver une idée d application qui pourrait utiliser ces données. Celle-ci devait être originale et innovante. Nous avons pensé à un guide touristique de la ville avec une liste des lieux intéressants à visiter (monuments, musées, parc, etc.). Chaque lieu aurait eu une description et aurait contenu des avis d utilisateurs. L accès à ces lieux aurait été généré via les données de transports. On aurait pu 6
ensuite imaginer un «quizz» sur le lieu en question. Mais ce projet ne faisant pas l unanimité, nous avons donc réfléchi à une autre idée tout en gardant à l esprit cette idée de «quizz». Nous avons finalement opté pour une application qui permettrait de créer et de participer à une chasse aux trésors en utilisant les données de transport et de lieux (appelés points d intérêts) de Montpellier. Cette idée nous a paru originale, innovante et intéressante à mettre en place. Elle permettrait d étendre la culture de Montpellier à ses habitants et faire découvrir aux touristes les lieux du patrimoine culturel de Montpellier tout en s amusant. Le nom de notre application est «Géonigme» pour Géo et Enigmes faisant référence à une chasse aux trésors utilisant des lieux géolocalisés et proposant diverses énigmes en rapport avec ceux-ci. 7
c. Cahier des charges 1. Un projet innovant Avant de voir les fonctionnalités de notre application, définissons la chasse aux trésors telle qu elle existe dans notre application : une chasse aux trésors est composée de différentes étapes, chaque étape se déroulant dans un lieu différent (plus ou moins proche) et contenant entre une et plusieurs énigmes. Chaque énigme est agrémentée d un ou plusieurs indices, qui peuvent être un texte, une image ou une musique. Chaque énigme a une réponse, celle-ci pouvant être textuelle ou géolocalisée (grâce au GPS). L application est divisée en deux catégories, la partie «joueur» et la partie «organisateur» qui permet de créer ses propres chasses aux trésors. Voici un exemple d une chasse aux trésors : Chasse aux trésors Étape 1 / Zone 1 Étape 2 / Zone 2 Énigme 1 Type réponse texte Énigme 1 Type réponse géo Énigme 2 Type réponse géo Énigme 2 Type réponse texte Énigme 3 Type réponse texte 2. Mise en relation du sujet avec le web sémantique L application proposera un itinéraire au joueur lorsqu il devra se déplacer, dans le but de se déplacer rapidement et facilement dans la ville sans en connaître tous les recoins. L itinéraire sera représenté par une carte et une liste d actions (prendre le tramway, descendre à tel arrêt ). Le web sémantique regorge d informations, et notamment sur la ville. L application pourra donc utiliser ces informations. Pour récupérer des données, sur les monuments de la ville par exemple, on interrogera le web des données grâce à des requêtes SPARQL. Pour rester dans la même optique de partage des données, l application publiera et stockera ses propres données générées en RDF, et proposera une ontologie pour ces données. 8
3. Côté joueur Il est important de noter que l application côté joueur s exécute sur un Smartphone ou une tablette connecté à internet. En effet, cela est plus pratique étant donné que l utilisateur devra se déplacer dans toute une ville. C est surtout de ce point de vue qu on peut qualifier notre application de novatrice comparée aux applications de chasses aux trésors existantes sur le web actuellement. Le but est de permettre à l utilisateur d accéder aux chasses aux trésors proposées dans sa ville et d y jouer. Pour cela, une liste des chasses aux trésors est proposée au joueur, caractérisée par diverses informations décrites par le créateur de la chasse comme par exemple leur difficulté, la zone de jeu, une description, etc. Avant de commencer une partie, l utilisateur a la possibilité de s inscrire sur Géonigme afin d obtenir un compte et garder un historique de ses chasses aux trésors avec ses scores. Il peut cependant jouer sans créer de compte, c'est-à-dire en étant «anonyme», mais ce mode ne permet pas la sauvegarde de sa progression. Une fois la chasse sélectionnée, l utilisateur doit se rendre sur le lieu de départ, la première étape. L application lui propose alors un itinéraire avec les transports en commun que le joueur est invité à suivre. Une fois sur place, la première énigme débute. Le type de réponse attendu s affiche : soit l utilisateur doit entrer une réponse textuelle sur son appareil, soit il doit se rendre à un lieu précis (qui sera validé grâce au GPS de l appareil). Si le joueur souhaite être aidé pour trouver la réponse, il peut afficher un ou plusieurs indices (sachant qu à chaque fois qu il visualise un indice, son score diminue). Les indices peuvent être de formes textuelles, sonores ou d images. Enfin, si l utilisateur ne trouve pas la réponse (où est dans l incapacité de le faire), il peut passer à l énigme suivante (avec un score de 0 point). Plusieurs énigmes s enchainent dans une zone restreinte du lieu d arrivée de l itinéraire. Quand le joueur a terminé toutes les énigmes de l étape, un nouvel itinéraire correspondant à une nouvelle étape lui est proposé. Et ainsi de suite, jusqu à la fin de la partie. Enfin, son score est affiché et le joueur a la possibilité de le partager sur les réseaux sociaux. Enfin, le joueur peut noter (sur 5) la chasse aux trésors en fonction de son originalité, du parcours qu elle propose, etc. 4. Côté organisateur Au contraire de la partie joueur, l organisateur créé sa chasse sur un ordinateur pour plus de simplicité, et il est obligé de s inscrire pour ajouter une nouvelle chasse. Ensuite, il peut facilement créer une nouvelle chasse en se faisant guider parmi des formulaires, du nom de la chasse jusqu à la réponse. En ce qui concerne les données géolocalisées (zone d une chasse ou d une étape, position d une réponse), une carte est proposée au créateur où il peut déplacer des marqueurs permettant de définir ses zones. 9
Une fois la chasse créée, la personne peut choisir de la publier pour que n importe qui puisse jouer avec, ou seulement de l enregistrer dans le but de la modifier plus tard, pour ajouter de nouvelles étapes et énigmes par exemple. Il peut ainsi consulter la liste des chasses qu il a créé sur sa page d accueil, en voyant lesquelles ont été publiées, et s il le souhaite les tester pour voir si elles sont suffisamment intéressantes pour être montré au grand public. A partir de la page d accueil il peut aussi accéder à une vue détaillée d une chasse sélectionné, pour décider de la modifier si nécessaire. 10
d. Calcul du score Le score permet de classer le joueur en fonction du nombre d indices qu il a visualisé pendant l énigme. Notons n le nombre d'indices que possède une énigme. Soit x l indice courant, c'est-à-dire le nombre d indice affiché par le joueur. Ainsi, si aucun indice n a été visualisé, x vaut donc 0. La formule de calcul du score pour une énigme, si le joueur a trouvé la réponse au e (n - x) indice, est la suivante : (n - x + 1)² points. Par exemple : 9 points si trouvé avec le (n - 2) indice. 4 points si trouvé avec l'avant dernier indice. 1 pt si trouvé avec le dernier indice. Dans le cas où le joueur ne trouve pas la solution ou il refuse de partager ses données de localisation (pour une énigme qui attend une réponse géo localisée) son score équivaut à 0. Le score final équivaut au cumul des points. Et le score total de la chasse est égal à la somme des (n + 1)² pour chaque énigme de la chasse. e. Planning 1. Planning prévisionnelle Ce planning a été effectué le 23 Janvier. 11
2. Planning réel En réalité, la phase d analyse et la phase de réflexion sur le type d application a été beaucoup plus longue. En effet, au départ nous devions étudier les données du département de Gironde, puis nous avons changé d avis le 16 Février (3 semaines après la première réunion) pour nous concentrer sur la ville de Montpellier par soucis de facilité à tester l application. Cela nous a fait prendre un peu de retard. De ce fait, cela a décalé les phases suivantes : l étude UML, la rédaction du cahier des charges, la conception et l implémentation. De plus, il y a eu une phase que nous n avions pas prise en compte au début du projet : celle de la construction de l ontologie et des mock-ups, essentielles pour l implémentation, qui a duré une semaine. f. Outils Les outils nécessaires à la réalisation de notre projet ont été : PC pour pouvoir développer l application et tester la partie «organisateur» Windows Phone, Android, IPhone pour pouvoir tester la partie jeu g. Diagrammes UML 1. Diagrammes de cas d utilisation Avant de commencer à jouer à une chasse au trésor, l utilisateur à la possibilité de s inscrire afin de mémoriser son score et d accéder à l historique de ses énigmes. Il peut toutefois jouer anonymement. Une fois la chasse sélectionnée, le joueur doit se rendre sur le lieu de départ pour démarrer la partie. Il faut savoir que pour chaque déplacement du joueur d'un lieu à un autre, l'application propose un itinéraire via les transports en commun. 12
Ensuite, le joueur peut répondre à l énigme (réponse géolocalisée ou textuelle). Il peut aussi s aider en affichant des indices. Quand il n y a plus d indices, le joueur peut choisir de visionner la réponse afin de passer à l énigme suivante. A chaque fois que le joueur affiche un indice (ou la réponse), cela diminue son score. A la fin de la partie, il prendra connaissance son score final. L organisateur va, de son côté, pouvoir créer des chasses aux trésors. Pour cela il doit se connecter à son compte (les comptes des joueurs et des organisateurs sont partagés). La création d une chasse se déroule en plusieurs étapes, l utilisateur étant guidé par les formulaires. Toutes les pages du site sont accompagnées d une carte interactive où l organisateur va pouvoir glaner des informations sur les différents points d intérêts de la ville. 13
2. Diagrammes de séquences Pour participer à une chasse au trésor, le joueur doit choisir une chasse parmi une liste donnée, puis se rendre au début de la chasse et répondre à toutes les énigmes sur le lieu de l étape, avant d aller à la suivante et ce jusqu à la fin de la partie. Des indices lui sont fournis toutes les x secondes si celui-ci ne trouve pas la réponse dans le délai prévu. 14
En ce qui concerne la création d une chasse, l organisateur définit la zone géographique de la chasse, puis il créé autant d étapes et d énigmes par étapes qu il le veut, en fonction des points d intérêts qui lui sont proposés sur la carte. 15
3. Diagramme de classes 16
4. Ontologie Ontologie graphique représentant l ontologie OWL d une chasse au trésor 17
h. Mock-ups Avant de nous lancer dans la programmation, nous avons réalisé les mock-up des interfaces «joueur» et «organisateur». 1. Côté organisateur Via une page web, l utilisateur qui aimerait organiser une chasse aux trésors devra au préalable indiquer un nom, une description, et délimiter une zone. 18
Il pourra ensuite définir une première énigme : celle-ci sera forcément écrite. La réponse par contre pourra être textuelle ou géolocalisée. Dans ce dernier cas, l organisateur pourra alors délimiter la zone de «réponse» où le joueur devra se trouver pour valider l énigme. 19
Ensuite, l organisateur pourra spécifier le ou les indices de son énigme : cela pourra être un texte, une image ou une musique. Il pourra aussi se voir suggérer des indices (en fonction des centres d intérêts à proximité par exemple). Puis, l organisateur pourra ajouter une nouvelle énigme (donc renouveler les précédentes étapes), ou enregistrer sa chasse. 20
21
2. Côté joueur Le joueur pourra accéder aux chasses aux trésors via son Smartphone (ou tablette). Un moteur de recherche est présent afin qu il puisse limiter les résultats à ses propres intérêts. Ensuite, il l utilisateur se rendra sur le lieu de départ. Une carte avec un itinéraire (carte + indications textuelles) amènera donc le joueur sur place. 22
Une fois sur place, l énigme apparaitra avec le type de réponse attendu : il s agit ici d une réponse gélocalisée. Ainsi, l utilisateur devra se rendre dans la zone correspondante pour répondre à l énigme. Si la réponse attendue avait été textuelle, un formulaire aurait été disponible pour que le joueur puisse écrire la réponse (schéma suivant). De plus, le joueur pourra afficher des indices si nécessaire via un bouton prévu à cet effet. Un délai (d une minute par exemple) est ajouté avant d avoir la possibilité d afficher le prochain indice. Si le joueur trouve la réponse (ou souhaite afficher la réponse parce qu il ne trouve pas la solution), il pourra passer à l énigme suivante (avec un nouvel itinéraire si l utilisateur termine les énigmes de l étape courante). 23
III. Conception L application globale (partie «joueur» et «organisateur») s appuie sur un framework PHP (fait maison) utilisant le design pattern MVC. Il est inspiré du framework Silex, lui-même basé sur le kernel de Symfony. L application mobile doit permettre l accessibilité au grand public donc avoir une interface claire et intuitive. Nous avons décidé pour cela de la créer sous forme de site web adaptée aux terminaux, ainsi elle sera disponible sur toutes les plateformes (IOS, Android, Windows Phone ). 24
a. Langages et ressources Lors de la phase d analyse, nous avons conçu les diagrammes UML, l ontologie et le mock-up de l application. Pour cela, nous avons utilisé Cacoo.com, un outil de dessin en ligne gratuit (plan de site, maquettes, UML, etc.). Lors de la phase de conception, étant à quatre sur le projet, nous avons préféré travailler avec l aide d un logiciel de gestion de versions. En l occurrence ici nous avons utilisé Tortoise SVN (avec plus de 200 versions du projet). Le projet a été réalisé avec les langages Web : HTML5, CSS3 et PHP5. De plus, la partie «joueur» a utilisé JQuery Mobile, une librairie JavaScript facilitant la programmation des interfaces sur mobile. La partie «organisateur», quant à elle, est basée sur le Bootstrap Twitter. Ce dernier est une librairie qui utilise CSS et JavaScript afin de permettre une conception simplifiée des interfaces web. b. Répartition des tâches Avant de commencer à développer, nous avons procédé à une partie analyse très rigoureuse et indispensable pour la suite de projet. En ce qui concerne la répartition des tâches : Marc MAURY et Gaétan LAMOUREUX se sont occupés de la partie «organisateur» sur ordinateur de bureau, et Yves DEMIRDJIAN et Audrey SCHNEIDER de la partie «joueur» sur mobile. 25
IV. Résultats et discussion Partie joueur La partie «Joueur» correspond à nos attentes en matière d'ergonomie et de fonctionnalités. Cependant les nouvelles technologies du web (HTML 5, CSS3, JQuery Mobile, etc.) ne sont pas encore mûres et cela pose parfois des problèmes de compatibilité selon les appareils (audio, positionnement des éléments de la page, taille du texte, orientation). L ensemble est cependant entièrement fonctionnel et esthétiquement réussi pour l utilisateur lambda. Il faut dire que l accent a beaucoup été mis sur l accessibilité et l ergonomie générale. Nous avons minimisé le nombre de connexions HTTP afin que l utilisateur ne soit pas embêté avec la couverture réseau et n ait seulement qu à charger la page (seulement ce qui change du cache). Pour prouver l efficacité de notre application, nous avons même joué à une des chasses que nous avons créées! Cependant d autres points sont à signaler indépendants de notre volonté : la partie «joueur» n est disponible qu avec la dernière génération de Smartphone supportant les technologies citées ci-dessus. La majorité des gens ne possède pas de tels appareils mais cela va croître avec le temps. Une mauvaise couverture du réseau peut empêcher le bon déroulement du chargement des pages et du contenu multimédia. Une utilisation excessive de la 3G et du GPS diminue la charge de la batterie. Pourvu que le joueur puisse terminer sa chasse avant s il n a pas au préalable pensé à recharger son appareil. De futures fonctionnalités pouvant être implémentées : Intégration dans les réseaux sociaux plus poussée. Statistiques sur la progression du joueur. Calcul de l itinéraire en temps réel selon la position du joueur (attendre que les batteries aient une charge plus conséquente et le réseau mobile une meilleure qualité de réception en France) Interface spécifique aux tablettes pour s adapter à leur dimension Interconnexion des Smartphones pour une jouer à une chasse en groupe (ex : premier qui trouve la réponse gagne plus de points, groupes sociaux, localisation des autres joueurs, mode groupe contre groupe). Cela demande une connexion continue au serveur grâce aux Web sockets et donc une connexion mobile irréprochable (donc pas pour toute suite). Récompenses (exemple, des trophées) si l utilisateur termine une chasses au trésor dans les conditions remplies. 26
Partie administration Du côté de l organisateur, une grosse partie du travail a été fait sur le «back-end» pour gérer correctement toutes les sources de données provenant de différents endroits. Aussi, les interfaces de création et de vue d une chasse complète ont été travaillées de manière à ne pas être trop déplaisantes à voir et à remplir, en minimisant le superflu pour ne faire apparaître à l organisateur que ce qu il veut voir à l aide du Javascript. Ce qui pourrait être implémenté à l avenir de ce côté : - Gestion plus complète d une chasse en fonction de sa publication (suppression, modification ). - Notation étendue aux créateurs des chasses. Discussion générale Il est nécessaire de préciser que nous avons développé cette application de A à Z, c est-à-dire que le sujet initial du TER ne contenant aucune indication quant au cahier des charges où à l idée de l application à développer. Nous avons donc nous même : trouvé l idée en correspondance avec le sujet de départ écris le cahier des charges dans son intégralité développé l application à partir de 0, c est-à-dire sur aucune base existante Du fait du développement d une application conséquente dans son intégralité, le développement de l application nous a consacré énormément de temps. Le projet compte plus de 14000 lignes (librairies exclues) et ne nous a pas laissé un moment de répit mais le résultat nous a donné satisfaction du travail accompli. 27
V. Conclusion Ce projet, comparé aux autres projets que nous avons eu à développer dans le passé nous apporté bien plus. Nous avons eu à non seulement à nous expérimenter dans le travail de groupe mais aussi à travailler en multi-groupes, c est-à-dire qu une partie de notre projet dépendait du travail des autres groupes. Nous y avons aussi appris de nombreuses choses dont tout ce qui touche au web sémantique (format RDF et OWL, requêtes SPARQL, le principe des ontologies, le but du web sémantique) et découvert différentes implémentations (DbPedia par exemple). Nous avons aussi appris à travailler efficacement grâce à l utilisation d un framework, d un Wiki et d un SVN. Nous pourrons aussi, à présent, nous vanter de bien connaître les technologies du web mobile mais plus généralement du HTML5 et des futurs nouveaux standards. Nous ajouterons que nous avons rencontrés à Montpellier, de nombreuses personnes participant à des communautés dont le but est de permettre la diffusion des données jalousement gardées à la disposition de tous (données géographiques de Montpellier par exemple, transports en commun). Enfin nous finirons par dire que nous nous sommes présentés comme participant à la sélection des projets participant à l ouverture des données numériques pour la culture à la mairie de Montpellier, afin, espérons-le, d être retenu et de faire connaître notre application à tous. 28
VI. Webographie Quelques liens qui nous ont été utiles : - Pour les données de Montpellier : http://opendata.montpelliernumerique.fr/ http://linkedgeodata.org http://dbpedia.inria.fr/ - Autres : https://github.com/semsol/arc2 (pour le travail sur les données) http://www.assembla.com/ (gestion du projet) 29
VII. Glossaire JavaScript : Langage de programmation de scripts principalement utilisé pour les pages web interactives. C'est un langage orienté prototype, c'est-à-dire que les bases du langage et ses principales interfaces sont fournies par des objets qui ne sont pas instanciés au sein de classes mais qui sont chacun équipés de constructeurs permettant de générer leurs propriétés. JQuery : Bibliothèque JavaScript libre qui porte sur l'interaction entre JavaScript (comprenant AJAX) et HTML, et a pour but de simplifier des commandes communes de JavaScript. A noter que nous utilisons aussi JQuery mobile dans notre projet (utilisable sur smartphone). HTML : L'HTML, abréviation de l'anglais Hypertext Markup Language, aussi appelé langage HTML, est le langage informatique créé et utilisé pour écrire les pages Web. Mock-up : Cela désigne un prototype d'interface utilisateur. Un mock-up a ainsi pour rôle de présenter les idées sur l'utilisation d'un logiciel. MVC (ou Modèle Vue Contrôleur) : Patron d'architecture et une méthode de conception qui organise l'interface homme-machine (IHM) d'une application logicielle. Ontologie : Modélisation d un ensemble de connaissances dans un domaine donné avec des concepts organisés dans un graphe. PHP : PHP est l'acronyme récursif de PHP : Hypertext Preprocessor. C'est un langage de script qui est principalement utilisé pour être exécuté par un serveur http, mais il peut fonctionner comme n'importe quel langage interprété en utilisant les scripts et son interpréteur sur un ordinateur. Il permet de développer des scripts suivant le modèle procédural et/ou objet. RDF : Un modèle de graphe destiné à décrire de façon formelle les ressources Web et leurs métadonnées, de façon à permettre le traitement automatique de telles descriptions. SQL : SQL, Structured Query Language (que l'on peut traduire par Langage structuré de requêtes), est un langage informatique standard, destiné à interroger ou piloter (modifier contenu et structure) une base de données. SPARQL : SPARQL Protocol and RDF Query Language, ou «protocole SPARQL et langage de requêtes RDF», est un langage de requête et un protocole qui permet de rechercher, d'ajouter, de modifier ou de supprimer des données RDF disponible à travers Internet. C est un équivalent du SQL dans le web de données, et on pourrait donc en théorie accéder à toutes les données du web grâce à SPARQL. L'ambition du W3C est d'offrir une interopérabilité non pas seulement aux niveaux des services, comme avec les services Web, mais aussi aux niveaux des données structurées ou non qui sont disponible à travers l'internet. UML : United Modeling Language ou «Langage de modélisation unifié», est un langage graphique de modélisation des données et des traitements. C'est une formalisation très aboutie de la modélisation objet utilisée en génie logiciel. On peut distinguer l UML en pro-ingénierie, réalisé avant la 30
conception afin d avoir une vision globale des objectifs à atteindre, ainsi que l UML en rétroingénierie, réalisé après la conception et qui permet d expliquer celle-ci aux autres utilisateurs. 31
VIII. Annexes a. Saisie-partie suite à la carto-partie (Kawenga) 32