Caractéristiques de la BD RCR


#1

Comme promis, voici un lien JSON avec les initiatives cartographiées par le
RCR identifiées comme actuellement actives.

http://www.asblrcr.be/initiatives.json

J’ai fait au plus simple pour l’instant : on pourra en faire un vrai
service RESTfull avec authentification plus tard si besoin.

*La nomenclature : *

INITIATIVE

  • nom_initiative : le nom usuel de l’initiative*

  • id_initiative_rcr : l’id unique de l’initiative dans notre base de
    données*

  • type_initiative : gac, sel, res, potager, repaircafe, donnerie*

  • geolocation_initiative : point où se situe l’initiative, bien souvent
    au centre de sa commune principale*

  • (adresse_initiative) : adresse libre (rue, numéro, cp, localite) de
    l’initiative SI PERTINENT*

  • (courriel_initiative) : adresse email générale de l’initiative (par
    opposition à l’adresse email privée d’une personne de contact… même si
    parfois une adresse email privée est renseignée à cet endroit)*

  • (website_initiative) : URL du site web*

  • (gsm_initiative) : numéro gsm général de l’initiative (par opposition à
    un numéro gsm privé d’une personne de contact… même si parfois un numéro
    privé est enregistré à cet endroit) - parfois pertinent, pour certaines
    donneries*

  • (contact)*

  •  prenom: prénom de la personne physique ou nom de l'association*
    
  •  nom : nom de la personne physique ou forme juridique de
    

l’association*

  •  (courriel)*
    
  •  (gsm)*
    
  •  (rue_et_numero)*
    
  •  (localite)*
    
  •  type_d_identite : Association ou Personne Physique*
    
  • (communes) communes où l’initiative est active*

  •  nom_commune*
    
  •  point_geolocalise : centre de la commune*
    
  •  zipcode : code postal 4 chiffres*
    
  • (type_donnerie) : Donnerie virtuelle ou Donnerie physique, si donnerie*

  • (type_potager) : Citoyen, Pédagogique, Scolaire, CPAS, EFT*


Importation des données de RCR
#2

Voici un aperçu de la méthode et des enjeux de l’importation de ces données dans le modèle d’Incommon.

Données GeoJSON vers Incommon

Les données GeoJSON diffèrent de celles saisies depuis le formulaire d’ajout d’initiatives du RCR. La table ci-dessous se base sur les données GeoJSON.

RCR Incommon Notes
name Resource.name
description Resource.summary Ici nous préférons utiliser un champ plus simple et réserver les informations de popup pour la description, sous réserve de la longueur de ces données.
nid Resource.properties Les champs inconnus du modèle externe se retrouvent dans Resource.properties, qui se présente sous la forme d’un objet JSON arbitraire.
title Resource.summary
type Resource.type Le type originel est ‘donnerie’, toutefois il s’agit dans Incommon d’un Tag ou d’une Classification, le type étant de l’ordre de Place ou Entity dans ce cas.
Communes Resource.properties Le champs Communes semble être une liste de communes dans lesquelles est active la donnerie. Comme il ne correspond à aucun champ d’une Resource d’Incommon, on la notera dans les properties.
popup N/A Le champs popup donne un exemple d’un gain d’information à entrer dans Incommon, mais qui nécessite une intervention humaine pour effectuer cette capture d’information à partir de données arbitraires. Nous conservons les données de popup telles quelles afin d’assurer la compatibilité avec l’existant, cependant nous en profitons pour renseigner les champs utiles commes telephone, email, url, etc. En outre nous requalifions la description en Markdown.

Nous voyons dans cette table récapitulative que l’importation des données existantes n’est pas nécessairement un processus automatique. Afin qu’il le devienne, RCR devrait harmoniser ses champs avec le modèle d’Incommon qui offre une granularité d’information plus fine.

Chaque Resource suivant un modèle unique, on peut importer le GeoJSON, donné comme FeatureCollection, comme une Collection liée à un Agent RCR (qui en a la responsabilité).

Agent RCR

L’Agent est une Resource. On le crée une fois avec des données minimales nous permettant de sauver l’objet histoire d’avoir son identifiant disponible pour y attacher les ressources à importer.

FeatureCollection

Une “collection d’objets remarquables” en GeoJSON se traduit par une Collection dans Incommon. Pour chaque objet importé, nous allons donc l’assigner à cette collection des donneries. Ainsi nous conservons au sein de la base de données d’Incommon les informations originales concernant la source des données.

URL de la ressource

Nous observons qu’une ressource dont le nid est 12345 est accessible à l’URL http://www.asblrcr.be/carto#overlay=node/12345, aussi nous pouvons inscrire cette URL dans le champ correspondant au cas où il n’y a pas de site web indiqué dans le popup.

Note: dans la version de développement (v0), une Resource ne peut avoir qu’une URL et qu’un numéro de téléphone. Il est possible que certaines données de RCR contiennent plusieurs de ces éléments. Dans ce cas on les conservera dans Resource.properties afin de faciliter la transition.

Données accessibles

Les données concernant les donneries en provenance du Réseau Consommateurs Responsables sont disponibles à https://www.asblrcr.be/donnerie_geojson.txt sous forme de GeoJSON. Le fichier comporte 71 entrées.

@sylvainlohest est-ce que ces informations te sont utiles ?

Penses-tu qu’il faille d’ores et déjà intégrer une UUID pour les ressources “externes” (à Incommon) afin d’en conserver la maîtrise dans votre base et ne prendre dans Incommon qu’une version en cache ? Dans ce cas, les Resources auraient un champ uuid qui servirait de référence globale et permettrait donc la modification hors-ligne des données (pour être synchronisées plus tard). On aura ainsi des “ressources gérées ailleurs” comportant un UUID et une URL pour lire (et éventuellement modifier) les données ; la version dans Incommon sera donc plus un cache qu’une donnée interne. Par la suite on pourra synchroniser et/ou utiliser l’API pour modifier les données directement.


#3

(ceci est un wiki)

La classification de RCR dans Incommon

Sur le modèle de Dewey Maps, Incommon comporte une classification arborescente à deux niveaux qui peut être adaptée à chaque projet. La Classification peut être utilisée comme discriminant pour parcourir les ressources. Chaque Resource est attachée à au-moins une Section particulière. Dans le cas de RCR, on peut envisager le découpage suivant :

  • Classification : RCR
    • Category : Donnerie
      • Section : Donnerie physique
      • Section : Donnerie virtuelle
    • Category : Initiative citoyenne
      • Section : Groupement d’Achat Coopératif (GAC)
      • Section : Repair Café
      • Section : ?? (RES)
      • Section : Système d’Échange Local (SEL)
      • Section : Autres initiatives
    • Category : Potager
      • Section : Potager citoyen
      • Section : Potager pédagogique
      • Section : Potager scolaire
      • Section : Centre Public d’Aide Sociale (CPAS)
      • Section : ?? (EFT)

La proposition chamboule un peu l’existant et peut être remplacé par des catégories avec une seule section (par exemple GAC, RES, SEL…) pour coller au découpage actuel car les Resources sont attachées à des Sections. Les sections permettent de jouer sur la granularité des catégories plus abstraites. Le parti pris ici est d’offrir des catégories comportant plusieurs sections.