Meet up with Sebastian Castro from transiscope

This is a template comment. This template is documented:
.

Meeting with @Sebastian from transiscope

16-17 decembre 2017

Adjust the time with the ‘Insert Date’ button or change the example below.

07:00 :arrow_right: 11:00

Lieu

France - Landes

Participant·e·s

@Sebastian
@how
@natacha

Objectifs

Discussing collaboration between IN COMMON and Transiscope
We happily discovered that we share some part of countryside as we are only 200km apart in south west France and decided to spend time meeting eachother and working together accross bothe projects.
We will document the encounter and formalize a bit more the objectives here below.

I imagine most people are not around to be physically present but if you have an interest sign the Rsvp button and we will organise an online meeting, via chat or voice chat.

Saisir la proposition d’ordre du jour

Cette liste est une proposition : si vous voyez d’autres points à aborder, merci des les indiquer dans les commentaires.

{Premier point}

Durée estimée : {30 minutes}

  • {Quoi?} : {Détails de la proposition}
  • {Quoi?} : {Détails de la proposition}
  • {Quoi?} : {Détails de la proposition}

{Autre point}

Durée estimée : {1 heure à 2 heures}

  • {Quoi?} : {Détails de la proposition}
  • {Quoi?} : {Détails de la proposition}
  • {Quoi?} : {Détails de la proposition}

Etc.

Hi,
I don’t know well IN COMMON. I work on the topic of commons and third places in Lille in France. We have to chose a techno to share a common map of third places in France (the existing regional networks have their own interface). There is a debate between transiscope and communecter. We know well communecter and we try to push the choice of communecter because of the additionnal functionalities of analysis or collaborative work they are developing.
Do you know Communecter ?
Perhaps Sebastian has a clearer idea of the strategy to adopt and the technical choices to make.

Have a nice meeting.
Benoit DE HAAS

Bonjour Natacha et Sebastian. Je ne pourrais pas être présent. Je vous fait confiance pour imaginer les coopérations possibles.

1 Like

Ping @yala. Nous sommes en route pour rejoindre @Sebastian

Nous avons passé 2 journées merveilleuses et inspirantes au milieu de la forêt avec @Sebastian où nous avons envisagé ensemble les nombreuses avancées de GoGoCarto notamment avec les outils de modération qui sont utilisés par Près de Chez Nous. Nous avons convenu ensemble que les projets de Transiscope et de IN COMMON fonctionnent d’une façon similaire en termes de choix de décentralisation, de fédérer les différentes initiatives cartographiques.
Du coup, nous avons envisagé quels développements nous pourrions partager et qui avanceraient la compatibilité de nos deux projets et ouvriraient à d’autres arrivées, ces point sont :

  • La saisie données propres: normalisation des données afin de faciliter leur validation, c’est à dire s’assurer que les champs proposés soient spécifiques à l’information, que le champ de numéro de téléphone ne prennent que des numéro de téléphone que l’adresse soit géocodé, vérifier que les url soient bien des url et éventuellement vérifier les url elles mêmes, vérifier que les e-mail soient bien des e-mails.

  • Requalifier les données existantes: une fois que les champs de saisie sont organisés pour permettre la normalisation, il faut adresser les données déjà existantes afin de les mettre à jour. Pour cela on pourrait envisager le développement d’un outil qui désignerait les endroits problématiques pour demander une correction manuelle (parfois une correction automatique est possible).

  • Transformation de données:
    – La transformations des ontologies, le bus sémantique/La Grappe permet de transformer les ontologies, du coup on envisagerait d’utiliser leur fonctionnalité à réfléchir.
    – La question des taxonomies est au coeur des débats de la cartographie, chaque structure a développé sa taxonomie et celle-ci a bien souvent fait l’objet de nombreux débats, c’est un objet identitaire important pour la structure. La question se pose de savoir si nous souhaitons engager le débat autour d’une méta taxonomie qui les associerait, et faciliterait la recherche ou si ce débat n’est pas souhaité. D’autres options seraient de suggérer des listes de termes lors du choix des catégories, ou de générer des cluster de qualificatifs de catégories associées au travers des différents taxonomies, In Common pourrait être intéressé par une telle approche à moyen ou long terme.

  • La question des doublons, Les doublons sont fréquents et doiventêtre mergés un des sujets de l’intermapping devrait être la manière dont nous décidons de les merger, par exemple en choisissant la version qui a le plus de champ remplis, il s’agit d’un problème difficile car demandant du temps humain, et nous n’avons pas suffisamment de modérateurs pour vérifier l’ensemble de ces données.

  • Exposer des données faire des recherche, envisager des manières de faire des recherches à partir de termes non fixe, c-a-d ne pas proposer les catégries qui conditionnent la recherche mais plutôt faire une recheche à partir de mots clefs.

Cela pourrait être un développement proposé par In Common dans une deuxième phase de développement.

1 Like

@Sebastian: curl "https://api.incommon.cc/maps/?api_key=23d8009f-f2ec-44b6-bcbe-58ad1d3af10b&include=resources,taxonomy" > dewey-maps.data.json

Pour la transformation des donnes je m’imagine un interface comme dswarm.org / demo.dswarm.org. On decouvre les schemas qui sont utilisee dans les bases des donnees, et on garde le mapping comme c’etait fait dans https://github.com/TransforMap/transformapetl/tree/master/jobs (nous n’ont jamais utiliser cet util). Est-qu’il y a un modele similare dans https://github.com/assemblee-virtuelle/Semantic-Bus?

La question des doublons est une question de la geosemantique en general. On regard la proximite semantique des object pour s’assurer si un element est le meme d’un autre. Elle peut etre le resultat d’une comparation des proprietes de quelques elements. Ca touche aussi les question de la proximite spatio-temporel, car les donnes peuvent se changer pendent le temp qui passe.

Bibliographie sur la geosemantique

http://ecgs.ncsa.illinois.edu/

http://www.wsiabato.info/spaceandtime/tGIS_Project.html

http://www.geoweb-studien.nat.fau.de/critical-knowledge-geographies-of-the-geospatial-semantic-web-exploring-social-dimensions-of-wikidata/

http://www.geoweb-studien.nat.fau.de/2018/04/14/mapping-geosemantics/

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.302.2290

https://www.sciencedirect.com/science/article/pii/S0198971504000250

https://sci-hub.tw/https://www.sciencedirect.com/science/article/pii/S0198971504000250

https://corpus.ulaval.ca/jspui/bitstream/20.500.11794/19058/1/24136.pdf

http://www.projetfogrn-bc.ulaval.ca/fileadmin/documents/Seminaire_PEFOGRN/Interoperabilite_geo-semantique_en_vue_d_une_integration_optimale_des_donnees_issues_des_reseaux_de_senseurs_pour_une_meilleure_prise_de_decision.pdf

https://perso.liris.cnrs.fr/rlaurini/Casa60.pdf

Nous ont aime de garder des taxonomies multi-linguel dans une instance de Wikibase base.transformap.co (l’outil arriere Wikidata), pour ca a aide la traduction volontaire des mots cles.

Salut ! Oui très chouettes journées, merci à vous d’être venu jusqu’à moi !

Merci pour les liens @yala ! J’ai essayé d’utiliser un peu Dswarm, ça à l’air prometteur mais c’est un peu dur de s’en servir, et plusieurs trucs ne fonctionnent pas chez moi…
En tout cas oui c’est ça l’idée, et gogocarto et grappe.io permettent aussi de faire ce genre de choses

Concernant InCommon, mon avis personnel sur la question (que j’ai partagé avec @natacha et @how) c’est que en terme de technos, InCommon devrait essayer d’utiliser celles développées du côté français (gogocarto & grappe.io) puisqu’elle répondent déjà au besoin de Transiscope, qui est a priori le même que celui d’InCommon. En reprenant les points évoqués plus haut par natacha, voilà un petit diagnostic de l’état des lieux et de ce qui pourrait être amélioré (@simon.louvet.zen corrige moi si je me trompe, je suis peut être pas à jour des derniers développement de grappe.io!)

Saisie des données
Gogocarto a un formulaire customisable
Il y a une détection des doublons lors de la saisie
Il y a des validations sur les champs url, email etc…
-> on pourrait améliorer les validations
-> on pourrait faire des preset de formulaire qui reprennent certaines ontology type comme “Organization” ou “Event”

Requalifier les données
Je crois qu’on a rien de ce côté
-> ça me semblerai assez approprié de créer un nouveau composant à l’intérieur de grappe.io pour faire cette fonctionnalité

transformation des données
gogocarto permet de faire des transfos simple sur l’ontology et la taxo
grappe.io permet de faire des transfos plus complexes

L’agrégation
Quand le nombre de sources grandit, une interface pour s’y retrouver est appréciable. gogocarto en possède une qui permet de savoir quelle source a été updated quand, si y’a eu des erreurs, combien de nouveaux éléments on été reçus etc…
grappe.io permet aussi de faire des aggrégations

les doublons
gogocarto a un système de détection de doublon. Si des “perfect match” sont trouvés, ils sont fusionnés automatiquement. Si le match n’est pas assez bon pour la fusion automatique, les doublon potentiels sont traités via une interface graphique
-> cela fonctionne bien au sein d’une source de donnée. Mais lorsqu’on gère des doublons entre plusieurs sources, d’autres questions se posent : est ce qu’on veut garder chaque représentation? en garder qu’une? si oui selon quels critère? faire une fusion automatiquement de chaque représentation? Il y a des choses à creuser de ce côté là…

exposer les données
gogocarto et grappe.io ont des systèmes d’apis.
grappe.io permet de construire des API custom en programmant l’impact de chaque paramètre de l’API sur les datas renvoyés
gogocarto a une interface graphique pour construire des requête simple (exple https://transiscope.gogocarto.fr/api/)
-> l’api JsonLD n’est plus fonctionnelle mais une contribution est en cours (https://gitlab.adullact.net/pixelhumain/GoGoCarto/merge_requests/38)
-> le système de filtres et de recherche via l’API est assez basique et pourrai être amélioré

Il me semble donc qu’une bonne partie des besoins vitaux InCommon ou Transiscope sont satisfait. A voir dans le détail, il y a surement des besoins que je n’ai pas vu. Mais il est peut être plus facile d’investir de l’énergie à combler ces besoins manquant on sein des technos existantes, plutôt que de tout re développer.

Le premier pas serait de créer une instance InCommon sur gogocarto. D’y intégrer Dewey et le réseau transition belge, et comme ça InCommon pourrait se faire une idée plus précise. On a commencé avec natacha et how, mais ça a été assez compliqué de mettre la main sur les données de Dewey, et à la fin il nous manquait toujours certaines infos. Pour réseau transition, j’ai cru comprendre qu’ils allaient être intégrés dans transiscope donc on pourra facilement reprendre le flux pour le mettre dans l’instance InCommon. Affaire à suivre donc !

1 Like