perma-data — design (1/2) : par la donnée

pas d’objet plante en base. L’objet plante c’est l’agrégation des propriétés contenues dans les extraits matchant tel ou tel nom

une problématique majeure, c’est la conversion (parsing) du format d’entrée et en base [de données] (extraits de livre) en le format de sortie et affiché [UI, user interface](pages plante)

idéalement, on cherche à favoriser l’option qui réduit le plus les opérations de parsing, c’est à dire : l’objet en base = l’objet affiché dans l’UI

toutefois dans perma-data nous n’évoluerons pas sur ce modèle

cela pose un certain nombre de difficultés (qui sont aussi le thème de cet article), exposées plus loin, alors pourquoi privilégier cette option ?

• d’abord, à cause de la donnée en entrée: la pluralité des structures et des présentations dont on veut conserver un minimum l’expérience “comme dans un livre”
• ensuite, à cause de la relation 1..* — 1..* entre extraits et plantes. Autrement dit : un extrait cible une ou plusieurs plante(s), les propriétés d’une plante sont agrégées depuis une ou plusieurs sources
• enfin, parce qu’en fin de course nous aimerions agir à l’échelle atomique sur l’agrégation des valeurs de propriétés sémantiquement proches (dont le nom/le sens se rapproche)

le format des extraits

premier point : il faut un format suffisamment standard, suffisamment abstrait, pour contenir les extraits de tous les livres

exemple avec le désormais fameux chénopode bon-henri

diversité des formes des extraits (de gauche à droite: edible forest gardens vol.1 — “forest gardening’s ‘top 100’ species”, la forêt-jardin [martin crawford] — “vivaces et couvre-sol à fleurs comestibles”, permaculture 1 — “catalogue des plantes”)

motifs

première étape : dégager les éléments récurrents. C’est ce qu’on appelle motifs, ou pattern en anglais :

• le livre et les sous-sections qui le contiennent

adressé avec l’identifiant relationnel (voir plus bas) “biblio”

• la langue impacte les valeurs de l’extrait

adressé avec l’identifiant relationnel “lang” + propriété multilingue(spécifique au nom)

• le nom : la plupart du temps le nom latin + un (ou plusieurs) noms dans la langue de l’extrait et/ou d’autres

adressé avec une propriété object { lang: [nom] }, pour chaque clé lang on a un tableau de noms

• la généalogie : en général on cible une espèce, celle-ci appartient à un genus et à une famille et peut également se décliner en sous-espèces/cultivars

adressé avec une propriété lineage : object { [LINEAGE_LEVEL]: #plant }

• souvent, une description/un résumé. Il contient des propriétés implicites qu’il serait bon de distinguer dans le futur

adressé avec une propriété summary : text

• des propriétés similaires dans leur champ lexical mais variables dans leur format

adressé par l’agrégation des valeurs

ces éléments et les contre-motifs, ci-dessous, guident le design descendant de l’application. Rappel du livre permaculture — principes et pistes d’action pour un mode de vie soutenable, de david holmgren :

principe 7 : la conception, des motifs aux détails

contre-motifs

certaines exceptions nous forcent à relever le niveau d’abstraction pour son formatage en base. Quelques cas majeurs et leur implication :

groupe d’alders : genus alnus, et sub-species (edible forest gardens vol.1)

• les groupes de plantes, isole une sélection d’individus dans la descendance d’un de niveau généalogique supérieur

deux solutions : on permet de matcher des groupes comme des plantes uniques (mutabilité de l’UI et de l’index de recherche = plus gros volume de développement) ou on attribue à chaque plante unique cet extrait + la référence aux plantes par le nom du groupe

on privilégie la seconde action en créant un type de propriété spécifique pour les groupes avec :

• le nom du groupe (toujours multilingue)
• la référence au niveau généalogique supérieur (ex: genus, famille …)
• les données des différentes plantes avec leurs identifiants

explicite la relation extrait — 1..* plantes

l’encart “exploiter un arbre pour la sève”. Illustre également le contre-motif de groupe : arbres à sève {érables & bouleaux} forêt-jardin [martin crawford])

• l’encart, fonctionne grosso modo comme un résumé avec un titre. Certaines autres propriétés de l’extrait peuvent y faire référence. Propriétés implicites à travailler …

chacune des plantes du tableau central hérite de la propriété “edible flowers”. (edible forest gardens vol.1)

• les tableaux, dont le titre est, en plus, implicitement une propriété (parfois la seule) des plantes qu’il contient

on adresse le sujet en donnant le tableau comme section et chaque entrée comme extrait individuel

identifiants relationnels

qu’est-ce qui définit, en amont, un extrait ? qu’est-ce qui en conditionne l’existence ? de ces questions on peut déduire les dépendances d’une entrée :

(les parenthèses sont importantes) le livre (et éventuellement la (les) (section(s)) dans le(s)quel(les) on le trouve + la langue + la (les) plante(s) à laquelle (auxquelles) il fait référence

à ce stade on peut dégager les identifiants de l’extrait :

• biblio : #section : { title, ?#section }, récursif, pattern branch/leaf retourné, la top section c’est le livre
• lang: un code langue, idéalement depuis un référentiel langue disponibles en base
• name: { lang: [nom]}, on fait au moins référence aux plantes par leur nom latin (unique, obligatoire), doublon sur langues ou noms différents

matcher extraits et plantes

afin de reconstituer l’objet plante affiché en répondant à la condition qu’implique la relation plante — 1..*extraits, nous abordons maintenant le sujet de récupération et de combinaison des extraits

la réponse au questionnement sur ce que reçoit le composant en bout de chaîne est traité avec l’agrégation des valeurs. Pour le matching en particulier :

• ou une collection d’extraits qui concerne la plante ciblée (délégué au serveur/connecteur de la base de données)
• ou de la donnée déjà formatée, prête à être affichée comme telle (délégué à l’application client)

recherche

pour le moment, la recherche a été simplement adressée sur une double requête :

• extraits dont la propriété nom latin matche le texte de la recherche
• extraits dont la propriété nom dans la langue de l’interface matche

le résultat est un tableau d’extraits, sans doublon, présenté en liste par nom latin unique

non-vide, la liste signifie que le texte de la recherche est valide et que de la donnée spécifique à la plante [qu’identifie conceptuellement le nom latin] peut être chargée dans l’interface

tags

on ajoute un troisième angle de recherche avec une propriété tags sur les extraits

les tags devraient éviter la redondance avec les autres propriétés qui ont pour vocation a être intégrées à la recherche par la suite :

• le nom des propriétés (ex: hardiness, cuisson/préparation …)
• les valeurs de certaines propriétés (ex: biblio, fonctions …)

les tags auraient tendance à servir de synonymes ou de “ce à quoi on pense généralement quand on dit …”

agrégation des valeurs

toutes les propriétés telles que : la taille ou les conditions climatiques; peuvent varier, de l’une à l’autre, tant par le format que par la valeur

non-adressé pour l’instant. En cours de design

réflexions sur le stack cible de l’agrégation :

• digestion en amont, sur le serveur
• calcul en aval, côté client

réflexions sur les formats standards cibles et sur les composants consommateurs/displayers

permadata — design par la donnée (2/2)

le site permadata.net (développement, peut être down)