Cette page a vocation à structurer un discours de la solution basée sur Semantic Media Wiki à laquelle nous avons réfléchi dans le cadre de ToursTech, mais qui dépasse ce cadre. Les objectifs sont :

1. d'être capable d'expliquer la solution
2. de montrer quelles sont ses spécificités
3. de dire pourquoi ces spécificités sont intéressantes pour les territoires
4. d'anticiper sur comment une telle solution pourrait évoluer sur 2 ou 3 ans

• expliquer de façon neutre les aspects technico-fonctionnels de la solution
• faire un diagramme d'archi.

• Un outil “wiki”
  • Media Wiki : même logiciel que Wikipedia
  • 1 “chose” (organisation, personne, projet) = 1 “fiche”
  • Tout pour permettre une gestion coopérative de l'information
    • faible barrière à l'entrée
    • historiques de modification pour revenir en arrière
    • pages de discussion
    • …
• Un “wiki” oui… mais structuré !
  • Semantic Media Wiki = Structured Media Wiki
  • Permet de structurer l'information, et de créer des formulaires structurés :
    • adresse
    • code APE
    • type d'organisation
    • …
  • Une approche données vs. une approche document
  • La structure n'est jamais figée, et peut évoluer au gré des remontées de la communauté
    • Le formulaire ne vous convient pas ? vous pouvez toujours saisir une donnée structurée en dehors du formulaire

• Semantic Media Wiki = fonctionnalités coopératives/communautaires, mais silo de données
  • Les données ne sont pas réutilisables en dehors du contexte du wiki
• Solution : diffuser les données structurées du wiki au travers d'une base ouverte
• Technologie : base de données de graphe RDF
  • pas de modèle de données a priori (comme dans le wiki)
  • protocole d'interrogation des données standard (langage SPARQL)
  • conforme aux bonnes pratiques d'échanges des données sur le web (web de données, web sémantique)

• Données accessibles + protocoles standards = maximisation de la réutilisation des données
• Outils “sur étagère” capables de tirer parti des données :
  • Gephi (voir la carto à http://smw.coopaxis.fr/carto/carto.png)
• Bibliothèques de programmation (nécessitant du code) :
  • Sigma.js (voir les réalisations d'Antoine http://www.cartographie.mwebius.com/)
  • D3JS (voir la répartition par codes NAF par Cyrille http://smw.coopaxis.fr/carto2/NAF_Tree.html)
• Des réutilisateurs potentiels dans l'écosystème pour des projets “à valeur ajoutée” (= commerciaux)
  • Banlieue Ouest ?
  • EW-innovation ?

• Open… Source
  • s'appuie sur des logiciels open-source, pas de logiciels propriétaires
• Open… Data
  • Une finalité : mettre à disposition les données pour l'ensemble du territoire…
  • … voir plus : des données pour échanger avec d'autres territoires
• Open… Community
  • Pas de restriction a priori sur les contributeurs potentiels : qui veut participer, participe. Système de “méritocratie” du wiki : les contributeurs actifs peuvent devenir administrateurs au fil du temps.
  • Barrière à l'entrée de contribution faible
  • Plus il y a de contributeurs, plus le système a de la valeur

• outil wiki + base de graphe = aucun modèle de données imposé à priori
• on peut toujours ajouter un champ, ajouter un “type de fiche” au cours de la vie du système, sans intervention technique, montée de version, etc.
• Il est toujours possible de saisir une information même si elle n'est pas prévue dans le formulaire

• Les contributeurs décident
• Les contributeurs les plus actifs, de part la flexibilité du système, peuvent proposer des nouveaux champs, des nouveaux types de fiche, en fonction de leur besoin
• “Par le territoire, pour le territoire”

• Protocole d'accès aux données standard, non propriétaire
  • langage SPARQL
  • formats XML ou JSON
• Les connaissances acquises pour accéder aux données sont transposables pour d'autres systèmes
  • Par exemple DBPedia.org est une base de données structurées issue de Wikipedia, utilisant le même protocole
• Inversement, l'outil wiki permet d'intégrer des données d'autres systèmes respectant le même protocole standard
  • voir l'extension Linked wiki

(ici c'est plus une question de positionnement que de fonctionnalités)

• Le système doit être “par la communauté pour la communauté”
• Il faut éviter les enjeux politiques
• Il ne faut pas qu'il y ait de questionnement pour les contributeurs :
  • Mes données…
    • où vont elles ?
    • à quoi vont-elles servir ?
  • Les données…
    • sont-elles exhaustives ?
    • qui en est responsable ?

Les caractéristiques précédentes (ouverture, flexibilité, standardisation, neutralité) en font une solution intéressante pour mutualiser des données entre les acteurs (collectivités, associations, acteurs privés, etc.)

La solution me semble en rupture sur plusieurs points :

• incitation à la participation pour tous les acteurs
• incitation à partager des données de collaboration entre acteurs économiques
• ouverture des données à tous, pour tous
• s'inscrit dans le “web des données” :
  • Permet à d'autres sur le web de faire du lien vers les données du territoire
    • Relie les “archipels” entre eux

(à compléter) cas de Fabien qui saisi la liste des projets CoopAxis + idées de Malvina et Amandine ?

• En quoi les points listés dans la partie précédente sont-ils particulièrement intéressants pour une politique territoriale, un territoire ?

(En s'inspirant d'autres initiatives et d'autre réflexion (FING, …) voir également quels doivent être les points à faire attention pour le succès du projets)

• : Trouver un nom spécifique à cet outil