1. 1. Document
   2. User
   3. Groepen
   4. Rechten
2. WaihonaPedia datamodel
   1. stakeholders model
      1. supportgroep
      2. extra user info
      3. Persoon met syndroom
      4. Persoon relatie met syndroom persoon
      5. Relatie type
   2. Scorecards, Observaties, Behandelingen of therapien
      1. Observatie
      2. Type observatie
      3. Behandeling of Therapie
   3. Belangstelling
   4. Keuzelijst
      1. Dimensions:
      2. Topic's
      3. Topic zwaarte (weight)
   5. Vragenlijsten
      1. Kern data
      2. Kern data en vragenlijsten
      3. Overige data in een vragenlijst
      4. Classes voor vragenlijsten
   6. Overzichten
      1. Data bestanden
      2. Logo's
   7. Illustraties

Om WaihonaPedia data te kunnen begrijpen is het belangrijk voldoende van het platform te begrijpen waarop WaihonaPedia wordt gedraaid; in dit geval XWiki.

Kort onderzoek eind 2015 heeft aangetoond dat een WaihonaPedia functioneel veel overeenkomsten heeft metWiki en minder met een CMS (Content Management Systeem). Er zijn mogelijk wel andere types platformen waarop men WaihonaPedia kan maken en men kan overwegen om er een  volledige maatwerk van te maken. Maatwerk heeft natuurlijken verplichting om periodiek upgrade werk te voorzien. Een platform zal vanzelf upgrades aanbieden (of end-of-life! aankondigen=probleem).

Een wiki heeft sterke punten in het samen werken aan kennis, ervaring. Een nadeel is dat het standaard beperkte database functies heeft. Dit is o.a. waarom in deze fase van het project voor XWiki is gekozen; een wiki die deze database functies wel heeft.

Document

Een datamodel op XWiki begint met de class: Document (Page).
Belangrijk omdat een data-definitie (Class), een data object of een data element in XWiki niet kan bestaan zonder een document. Een document bevat als het ware de ander types.
XWiki kan oneindig veel documenten hebben, met name om teksten te schrijven; immers dit is de belangrijkste eigenschap van een wiki. Dit geeft families, vrienden en experts de kans om te beschrijven hoe het is om met de zeldzame aandoening te leven, zowel in vragende vorm als in coachende vorm. Vooral de mogelijkheid om verschillende opinies te kunnen beschrijven is van belang om de kennis te kunnen ontwikkelen.

User

Om teksten (en data) te schrijven en beheren zijn er mensen nodig die dit invoeren. Door te registeren komen er gebruikers (Users]!
Deze class User bevat bijvoorbeeld de naam, de pasfoto (Avatar) zodat altijd kan worden bijgehouden wie aan bepaalde tekst of data heeft gewerkt.
Notabene: Een User wordt in XWiki opgeslagen in een Document; dus opgeslagen informatie over een user vindt je in een speciaal type document. 

Groepen

Het is niet handig om voor elke persoon individueel de zaken te moeten instellen, met name over wat/hij zij voor rechten heeft. Daarom gebruiken we de class "Groups". Hiermee kun je één of meerdere gebruikers in groepen indelen.
Standaard komt XWiki met twee groepen; XWikiAllUsers en XWikiAdministators.
Binnen WaihonaPedia zullen we minimaal één groep toevoegen om een gebruiker toegang te geven tot een WaihonaPeda.
Dit is met name gedaan om het goedkeuren van een registratie mogelijk te maken en daardoor niet gewenste gebruikers buiten de deur te houden.
Elke organisatie kan in principe zijn eigen groepen structuur aanmaken; denk aan bijvoorbeeld rechten om anderen te helpen; "Moderator" Of rechten om in een bestuur-blog mee te doen; "Bestuur" of "Leaders". 

Rechten

Met name data, maar ook tekst, zal worden beveiligd. Omdat we in een WaihonaPedia altijd willen weten wie wat gedaan heeft moeten we bijvoorbeeld beschermen dat mensen die niet geregistreerd zijn niets mogen wijzigen (en soms de tekst of data niet mogen zien)!
Dit wordt gedaan door aan elk document een object van class "Rights" toe te kunnen voegen. Indien er geen object van class "Rights" aan een document is toegevoegd, gelden de rechten van een hoger document (of een space)

Natuurlijk zijn er meer classes in een XWiki platform, maar bovenstaande spelen een belangrijke rol in het databeheer van een WaihonaPedia

- = bestaat altijd
.... = Kan binnen het omringende object bestaan
null = Dit attribuut kan bestaan, maar altijd testen 

WaihonaPedia datamodel

Om een WaihonaPedia te kunnen hebben zijn wat extra data-classes nodig
In dit geval interactieren ze natuurlijk met de bovenbeschreven standaard classes van XWiki.
Notabene: Een standaard XWiki class kan ook worden uitgebreid; in WaihonaPedia hebben we attributen aan User toegevoegd;

• country (country: String)
• gender (gender: Static List)
• Show introductory information (introductoryInformation

Bij onderstaande classes hebben sommige attributen hebben nog 'cdls' in naam; dit is een gevolg dat eerste versies van deze class zijn ontwikkeld binnen cdlsworld waihonapedia (prototype). Om functionaliteit te behouden is de naam gehandhaafd, echter moet er op het scherm en in het gebruik van de mensen niets van te merken zijn; dus kijk schermen na op restanten en pas indien nodig translationfiles aan!

stakeholders model

Bij WaihonaPedia moeten in eerste instantie mensen worden verbonden.
Het geheel is gebaseerd op een (officieel) community (stichting, vereniging ) rondom een zeldzame aandoening; de SupportGroep.
De Users van een WaihonaPedia kunnen zich aansluiten bij zo'n supportgroep.

Belangrijkste entiteit is de persoon met een syndroom/aandoening. Meestal is dit niet iemand die zich achter de computer met WaihonaPedia kan bezighouden, dus moeten er één of meerdere users zijn die een relatie met zo'n persoon hebben.
In dit deel wordt het model om dit te bereiken verklaard.

supportgroep

_{supportGroupClass}

• logoSupportGroup (countryCode: String)
• language (language: String)
• supportedCountries (supportedCountries: String)
• memberCdlsWorld (memberCdlsWorld: Boolean)
• contactInfo (contactInfo: TextArea)
• emailContact (emailContact: Email)
• website (website: String)
• facebookPage (facebookPage: String)
• facebookGroup (facebookGroup: String)
• twitter (twitter: String)
• Supportgroup (countryName: String)
• Code (Code: String)
• Address (address: TextArea)
• skinForSupportgroup (skinForSupportgroup: Page)
• themeForSupportgroup (themeForSupportgroup: Page)
• bannersForSupportgroup (bannersForSupportgroup: Page)

Deze class maakt het mogelijk om communities te vormen. Dat zou ook met groepen kunnen, echter deze class maakt het mogelijk ook de socialmedia en eigen visuele identiteit (skin+colortheme+foto's voor banner) te maken.

extra user info

_{waihonaPediaUserProfileClass}

Street Address (street: String)
City (city: String)
State (state: String)
Postal Code (postalCode: String)
Country (country: String)
Telephone (telephone: String)
cdlsPersonName (cdlsPersonName: String) Depricated, niet meer gebruiken in nieuwe code 
Date of Birth (cdlspersonDOB: Date) Depricated, niet meer gebruiken in nieuwe code 
Height (cdlspersonHeight: String) Depricated, niet meer gebruiken in nieuwe code 
measureHeight (measureHeight: Static List) Depricated, niet meer gebruiken in nieuwe code 
Weight (cdlspersonWeight: String) Depricated, niet meer gebruiken in nieuwe code 
measureWeight (measureWeight: Static List) Depricated, niet meer gebruiken in nieuwe code 
Current Medication (currentMedication: TextArea) Depricated, niet meer gebruiken in nieuwe code 
Your relationship with this person (cdlspersonRelation: String) Depricated, niet meer gebruiken in nieuwe code 
contextUsr (contextUsr: String)
Allowance for visibility of profile (visible: Boolean)
Open to be contacted by other members (contact: Boolean)
supportGroup (supportGroup: Database List)
gender (gender: Static List) Depricated, niet meer gebruiken in nieuwe code 
socialStatus (socialStatus: String) Depricated, niet meer gebruiken in nieuwe code 
cdlsPersonAvatar (avatar: String) Depricated, niet meer gebruiken in nieuwe code 

Deze class is er met name om privacy redenen. We hadden de XWiki user class kunnen aanpassen.
Echter de XWiki user class mag niet te goed beveiligd worden en dus is deze class er om gegevens over een gebruiker vast te leggen die bijzonder zijn voor WaihonaPedia. Sommige zijn overlappend met XWiki user (adres ,...) echter deze worden alleen aan geregistreerde waihonapedia gebruikers getoond
Voorwaarde is dat de rights van de space en/of document waarin object is opgeborgen goed gezet zijn.!
Er mag slechts één object per document zijn omdat full document name als key wordt gebruikt

Persoon met syndroom

_{personWithSyndromeClass}

Misschien wel de belangrijkste class van allemaal. Met name voor families en vrienden.
Dit is een nieuwe class die de depricated elementen uit de vorige class gaat vervangen.
In het prototype cdlsworld was het gecombineerd met vorige class.
Echter er ontstond een probleem als twee of meer mensen een relatie met de zelfde persoon hadden; bijvoorbeeld als vader en moeder  beide geregistreerd zijn.

Dus in deze versie van WaihonaPedia is er begonnen met deze class apart te zien, en ook te ontdoen van meetwaarden...

• key (key: String)
• diagnosedWith (diagnosedWith: Database List)
• name (name: String) (synonym: Last Name)
• firstname (firstname: String)
• photo (photo: String)
• dateofbirth (dateofbirth: Date)
• gender (gender: Static List)
• relationships (relationships: Computed Field)
• socialHistory (socialHistory: Computed Field)
• medicationHistory (medicationHistory: Computed Field)
• visible (visible: Boolean)
• attentionPoints (attentionPoints: Database Tree)

Note: het attribuut relationships, social history and medication history is computed, dit betekend dat één of meer objecten van de volgende class moeten bestaan om hier iets te zien.
Er mag slechts één object per document zijn omdat full document name als key wordt gebruikt.

Met name de geboorte datum en het geslacht zijn belangrijke velden voor de gebruiksvriendelijkheid van WaihonaPedia.
Met deze twee elementen kunnen veel zaken gefilterd worden en kunnen keuzelijsten korter worden (en dus eenvoudiger)  

Persoon relatie met syndroom persoon

_{personToSyndromePersonRelationClass}

Middels een key (document name) van een extra User Info object en de key van de persoon met syndroom wordt een object gecreëerd
Deze objecten moeten worden toegevoegd aan het document waarin ook het object van de persoon met syndroom staat.
(niet technisch noodzakelijk maar wel om overzichtelijkheid and aantal documenten nodig te minimaliseren (performance)

Het derde veld geeft aan welk type relatie beide personen hebben, dit is een query uit de hulp class hieronder (roletype)

• keyUser (keyUser: Database List)
• keySyndromePerson (keySyndromePerson: Database List)
• role (role: Database List)
• dateStart (dateStart: Date)
• dateEnd (dateEnd: Date)

In theorie kunnen nu ook vrienden, experts, onderwijzers een relatie met de persoon met het syndroom hebben.
En omgekeerd kan bv een expert een relatie met meerdere personen met het syndroom hebben

Relatie type

_{roleTypeClass}

Een hulp class zodat elke organisatie haar eigen rollen kan maken, hoewel er nog geen syndroom filter mogelijk is.

• key (key: String)
• title (title: Computed Field)
• description (description: Computed Field)

Deze class bepaalt welk type relaties er mogelijk zijn tussen users en personen met syndroom;

• Moeder
• Vader
• Moeder (niet biologisch)
• Vader (niet biologisch)
• Oma
• Opa
• Zus
• Broer
• Familie
• Vriend
• ...

Scorecards, Observaties, Behandelingen of therapien

De manier om data registraties te doen is via scorecards. Een scorecard applicatie is een vereenvoudigde registratie app waarbij veel context informatie via het stakeholder model kan worden afgeleid. Hoe oud de persoon is, welke opties...

De waarnemingen bij een scorecard worden gedaan middels een Observatie

Observatie

_{observationClass}

• PersonKey (personKey: String)
• odatetimestart (odatetimestart: Date)
• odatetimeend (odatetimeend: Date)
• observationType (observationType: Database List)
• measureInterval (measureInterval: Number)
• measureNominal (measureNominal: String)
• measureOrdinal (measureOrdinal: Number)
• measureRatio (measureRatio: Number)
• withmilestone (withmilestone: Database List)
• withtopic (withtopic: Database List)
• byRole (byRole: Database List)

Deze class is één van de meest belangrijke classes voor het registreren van data. Hij is daarom ook flink uitgebreid om verschillende types observaties te kunnen vangen en vergt ook flink wat kennis over de registratie. Dit in tegenstelling tot bijvoorbeeld de vragenlijsten; waarbij zeer eenvoudig een nieuwe class wordt gecreëerd. Dus elke vragenlijst z'n eigen class
Bij Observaties is dat omgekeerd;
Een Diagnose bijvoorbeeld wordt een observatie op een bepaalde datum (geen tijd) van een bepaald type (diagnose) met een Nominale meting (een keuze uit de lijst met mogelijke diagnoses. Dit wordt ook automatisch een milestone (Diagnose bekend) en het Topic wordt ook gezet (Diagnose stellen). Er kan een rol worden gekozen uit RoleTypes.
Een gewicht meting wordt een observatie op een bepaalde datum/tijd (indien tijd bekend) van een bepaald type (weging) met een Ratio meting (het gemeten gewicht)
Dit type observatie is normaliter niet aan een milestone gekoppeld (wat probeer je te bereiken met groeien?) maar kan wel weer aan een topic worden gekoppeld. (Ontwikkeling, groei). Ook kan worden vastgelegd door welke rol de weging is uitgevoerd.

Belangrijk is een juiste keuze te maken uit Interval, Nominaal, Ordinaal of Ratio Voor de definitie van dezen verwijzen we naar literatuur over wetenschappelijke  metingen. Het is duidelijk dat de familie/vrienden die de registraties uitvoeren een App willen die de complexiteit van deze class verbergen.

Type observatie

_{healthListItemClass}

Deze class bevat ook objecten voor de keuzelijst van Interesse gebieden. Echter door een 'where typelist = "observation"' toe te passen in de database list zullen er alleen items getoond worden van Type observation

• key (key: String)
• topic (topic: Database List)
• typelist (typelist: Static List)
• title (ctitle: Computed Field)
• description (description: Computed Field)

Notabene; de topic die bij de lijst zit kan gebruikt worden om de Topic in de Observation te vullen, maar voor generieke observaties zoals gewicht-meting kan dit misschien specifieker worden.

Behandeling of Therapie

_{treatmentClass}

Een veelgevraagde set van informatie is welke soorten therapiën of behandelingen (Met of zonder medicatie) zijn toegepast. Hoewel hier het Persoonlijk patiënten dossier bij het ziekenhuis natuurlijk leidend is en altijd moet worden geraadpleegd bij het plannen van nieuwe behandelingen is het ook goed indien de familie/verzorger beschikt over een overzicht.
We spreken bij deze gegevens altijd over een periode waarin het is toegepast (Start-date End-date), vanwege welk topic, beschrijving, één medicatie met dosering.
Een behandeling of therapie (met of zonder medicatie) zal vaak gebeuren onder een observatie van een probleem (Observation having a withtopic) (hoewel niet alle observaties having a withtopic  een probleem zijn). Normaliter zal de startdatum en einddatum van de behandeling moeten passen binnen de startdatum einddatum van de observatie, maar deze logica moet goed worden bekeken, met name als er meerdere observaties over hetzelfde probleem worden gedaan.

Belangstelling

_{personHealthAttentionClass}

• personkey (personkey: String)
• topickey (topickey: String)
• occurence (occurence: String)
• severity (severity: String)
• treatment (treatment: String)
• surgery (surgery: String)
• protocol (protocol: String)
• other (other: TextArea)

WaihonaPedia richt zich op complexe aandoeningen (meervoudig). Dat betekend dat als je alle kennis beschikbaar stelt, alle vragen die er gesteld zijn, alle vragenlijsten die er zijn en alle scorecards die er mogelijk zijn een berg aan informatie beschikbaar stelt die overweldigend is.
Daarnaast is elk persoon uniek, en brengt ook die kenmerken in.

Daarom willen we het mogelijk maken om 'belangstelling' vast te leggen. Dit is een essentieel bouwsteen in een WaihonaPedia.
Het geeft een familie de mogelijkheid stap voor stap belangstelling te registeren; middels een topickey.
Dit topickey wordt een kennis-koppeling-id waarmee de 4 modules van een WaihonaPedia met elkaar worden verbonden.

• een kennis stuk heeft topickey's
• een vraag zal voorzien worden van topickey's

Het idee is dat op deze manier families een eigen dossier kunnen opbouwen dat precies past bij hun kind.

De eerste stap is het aanmaken van een document (page) die de belangstelling kan bevatten
En dan op die pagina voor één persoon met syndroom objecten met topickey's toe te kunnen voegen
Nu biedt het object de mogelijkheid om een soort zwaarte aan het topickey toe te kennen; bv door een Occurence waarde (nominaal), een severity (nominaal), een treatment (nominaal), een uitgevoerde ingreep, of een toegepast protocol. Ook kan er nog wat text aan het topacid worden toegevoegd

Keuzelijst

_{een combinatie van classHealthDimensions en healthTopicsClass}
Een aandoening binnen waihonapedia (complex-zeldzaam met verstandelijke beperking) kent een flink aantal topic's. Deze topic's kunnen in verschillende dimensies van geluk/levenskwaliteit spelen.
Een Topic worden onderverdeeld in sub-topic's die op hun beurt ook weer kunnen worden onderverdeeld.
Nu zijn topickey's een pointer naar (een stukje kennis). Kennis is een begrip waarbij in het ene geval naar een redelijk breed gebied wordt gekeken en in een ander geval (moet worden) wordt ingezoomd (sub-topic of sub-sub-sub-topic) naar een aspect binnen dat gebied.
In WaihonaPedia is dit middels een soort boom-diagram gerealiseerd. Dat betekend dat gezocht wordt naar key's die een child zijn van een andere key en parent kunnen zijn van getal key's.
Om te voorkomen dat dit flexibiliteit van hoe naar kennis wordt gekeken in de weg zal staan is er gekozen de boom met twee classes op te bouwen.
Elk topic heeft dus een parent en optioneel een dimension-parent.
Het Topic dat geen parent heeft mag gezien worden als 'de aandoening'.
In principe kunnen er meerdere topics zijn zonder parent maar met verschillende dimension-parents.
Men kan dat dan zien als 'op meerdere manieren naar het syndroom kijken' (vanuit verschillende dimensies).
Enige terughoudendheid en design verdieping is nodig voordat we deze flexibiliteit gaan gebruiken!
Vooralsnog één dimension tree en één topic tree....

Dit alles maak de Keuzelijst een van de meest belangrijkste bouwstenen van een WaihonaPedia.

Dimensions:

_{classHealthDimensions}

• key (key: String)
• parent (cparent: Database List)
• title (ctitle: Computed Field)
• description (cdescription: Computed Field)

In deze versie van WaihonaPedia wordt gekozen voor de dimensies volgens het model 'Positieve gezondheid' van Huber

Topic's

_{healthTopicsClass}

• key (key: String)
• reference (reference: String)
• description (description: Computed Field)
• dimension (dimension: Database List)
• Topic Title (topictitle: Computed Field)
• parent (parent: Database List)

Een geneste query kan worden gebruikt om de lijst op te bouwen, te beginnen bij de dimensions
Het complete resultaat zal een boom diagram zijn... 

Topic zwaarte (weight)

_{personHealthAttentionClass}
Zodra een topic gekozen wordt kan het van belang een indicatie te kunnen geven van de zwaarte die het Topic voor de persoon met het syndroom heeft. 'Zwaarte' kan op verschillende manieren worden aangegeven.

• occurence (occurence: String)
• severity (severity: String)
• treatment (treatment: String)
• surgery (surgery: String)
• protocol (protocol: String)
• other (other: TextArea)

Alle opties (behalve 'other') zijn nominale indicatie lijsten die middels een heathlistitem kunnen worden gedefinieerd. Mbv Other kan een familie ook nog vrije tekst invoeren over het topic

Verder kunnen Observaties aan het topic worden toegekend.

Nu is het maken van een belangstelling-keuze en een toekennen van zwaarte normaliter geen gelijktijdige actie (of behoeft dit niet te zijn). Gaande het leven zal de men de belangstelling verder specificeren. Uiteindelijk zou bijvoorbeeld een topic 'onder controle' zijn en geen hoge prioriteit meer hebben. Dit zou middels een bijzonder observatie-type gemarkeerd kunnen worden. 

Vragenlijsten

Een vragenlijst is een hulpmiddel om een familie met de Scholen, ZorgInstellingen, Ziekenhuizen, Onderzoekers maar ook met de familie-groep (vereniging, stichting, ...) te laten communiceren.

Het gaat volgens het principe van een set van vragen welke door de vragende partij worden gesteld. Belangrijk uitgangspunt van WaihonaPedia is dat we een vraag aan een familie maar één keer stellen en dat het antwoord automatisch beschikbaar komt zodra de vraag nogmaals gesteld wordt. Denk bijvoorbeeld aan hoe vaak de geboorte datum wordt gevraagd!

Kern data

We hebben in het datamodel reeds gesproken over classes van data welke gegevens houden over de persoon met het syndroom (of de verzorger). Deze kern-data is het hart van het systeem en data welke vaker gevraagd zou kunnen worden is per definitie kandidaat om tot kern-data te worden gepromoveerd ! Dus de geboortedatum is kern data. Omdat we WaihonaPedia als evolutionair platform zien kan een patiënten groep zelf besluiten welke data tot kern-data te promoveren. Hier staat dan een configuratie inspanning en eventueel een migratie inspanning tegenover als de data al veel is ingevoerd terwijl het nog geen kern-data was.

Kern data en vragenlijsten

Kern data wordt in Objecten van de  Classes bewaard zoals beschreven. Dus de vragenlijst bevat geen kern-data.
Een vragenlijst welke ook kern-data wil uitvragen moet dan een referentie naar de kern-data hebben.
Dus geen veldje waar geboortedatum moet worden ingevoerd, maar een link naar de geboorte datum in de kern-data.

Hiervoor gebruiken we het veldtype 'computed field' van XWiki. Een computed field bevat zelf geen data maar toont data. Het kan ook informatie berekenen; bv als je de geboortedatum vergelijkt met de datum van vandaag kan een leeftijd worden berekend. Dit kan dan in Maanden, Dagen, Jaren en zelfs seconden worden uitgedrukt. Een computed field kan ook een lijst van informatie bevatten; bijvoorbeeld de vraag: Welke medicatie of Welke artsen

Overige data in een vragenlijst

Alle overige vragen worden wel opgeslagen in de vragenlijst. Dit gebeurt bij voorkeur met eenvoudig te vertalen vraagtypes: Ja/Nee/Weet niet of Een keuzelijst met meerdere opties. Daarnaast kunnen echter betalen, datums of text invoer worden gevraagd. Het laatste type heeft als nadeel dat een buitenlander of een computer hier meestal niet veel mee kan. De buitenlander omdat hij/zij woorden niet gebruikt en de Computer omdat het gevoelig is voor een typefout en alle controle de software erg duur zou maken.

Classes voor vragenlijsten

Elke vragenlijst wordt als data gerepresenteerd door een speciale class voor die vragenlijst.
We spreken hiervoor een 3 letterige code af welke begint met een "q".
Een class bevat 2 type velden:

• Data velden
• Computed field (Kern Data)

Overzichten

Een WaihonaPedia tracht data dat is vastgelegd waarde te geven middels 'beloningen'. Dit zijn overzichten, info graphics die ontstaan uit behoefte:
Voorbeelden zijn:

• Medische Alarm kaart
• Groei analyse grafiek
• Milestone info-graphic

Er zijn (nu nog) geen classes voor deze overzichten. Wel kunnen ze worden ondersteund middels bijlages (Data bestanden, logo's, illustraties)

Data bestanden

Voor data bestanden spreken we een voorkeur uit voor JSON (JavaScript Object Notation). Dit maakt verwerking gestandaardiseerd en heeft voldoende integriteit controle.
In principe kan een data bestand in ander formaat ook worden gebruikt, maar dit zal een verzwaring van software betekenen (meer types software te onderhouden).
Database links middels een rechtstreekse query wordt afgeraden
Een data bestand van het JSON formaat kan ook op externe servers beschikbaar worden gesteld; bijvoorbeeld bij Expertise centra

Logo's

Een overzicht moet in de context van een syndroom of partner worden opgemaakt. In principe heet WaihonaPedia de 'Supportgroep' class. Aan die pagina moeten logischer wijze de Logo's worden gekoppeld. Partner organisaties krijgen ook een eigen class (nog te beschrijven)

Illustraties

Het overzicht kan voor design icon's, foto's of andere illustraties nodig hebben, deze dienen op de pagina die bij de code voor het overzicht hoort

Een overzicht moet een relatie met minimaal één topicid hebben!
Bij voorbeeld een alert card wordt geconfigureerd door een lijst van topacid's. Dit bepaald ook de volgorde van de topic's op het overzicht.
Vooral nog is het idee deze lijst in de code van het overzicht te bewaren. Met name bij meertaligheid waarbij verschillende talen een andere versie van het overzicht willen hebben is dit een prima compromis.

Lees de velocity guide van Apache over Array's, Objects voor een slimme notatie voor een lijst met topicid's