Site Management Handleiding Onderhouden en beheren van een door Smartsite 5 aangedreven site Smartsite Software BV
Copyright 2004 Smartsite Software B.V. Alle rechten voorbehouden. Niets uit deze uitgave mag worden verveelvoudigd, opgeslagen in een geautomatiseerd gegevensbestand, of openbaar gemaakt worden, in enige vorm of op enige wijze, hetzij elektronisch, mechanisch, door fotokopieën, of op enige manier, zonder voorafgaande toestemming van de uitgever. Voor het overnemen van gedeelte(n) uit deze uitgave in bloemlezingen, readers en andere compilatie- of andere werken (artikel 16 Auteurswet 1912), in welke vorm dan ook, dient men zich tot de uitgever te wenden. Ondanks alle aan de samenstelling van deze handleiding bestede zorg kan noch de redactie, noch de auteur, noch de uitgever aansprakelijkheid aanvaarden voor schade die het gevolg is van enige fout in deze uitgave.
Voorwoord Voor je ligt de Smartsite Site Management Handleiding. De handleiding voor sitemanagers is een lastige handleiding. Een door Smartsite aangedreven site kan namelijk in vele gedaanten voorkomen: van een relatief simpele site die op een enkele server draait tot een over meerdere servers uitegerolde applicatie waar productie en publicatie van informatie volledig van elkaar gescheiden zijn. Wanneer er sprake is van een grote organisatie dan zullen de sitemanagers zich niet gauw hoeven bezig te houden met de technische aspecten van een site, terwijl in een kleine organisatie misschien wel hogere eisen aan de sitemanager worden gesteld. Door deze brede invulling die je aan het begrip sitemanager kunt geven is het lastig om de informatie daar eenduidig op af te stemmen. In deze handleiding proberen we de concepten die aan Smartsite ten grondslag liggen uit te leggen. Daarnaast willen we ook de praktische handelingen niet vergeten. Wanneer je vindt dat er informatie in deze handleiding ontbreekt dan moedigen we je aan om ook eens op onze sites te kijken: manual.smartsite.nl en support.smartsite.nl. Op deze sites wordt meer informatie gegeven en deze informatie wordt altijd actueel gehouden. We hopen dat je als sitemanager jullie site tot een succes weet te maken. Delft, december 2003 Smartsite Software BV Smartsite is continu bezig om zijn product te verbeteren. Dat betekent dat er telkens weer nieuwe versies van Smartsite worden uitgebracht. Bij het uitbrengen van een nieuwe versie wordt bestaande functionaliteit herzien, en waar nodig verbeterd, en nieuwe functionaliteit toegevoegd. Bij het uitbrengen van de nieuwste versie is ook de Site Management Handleiding herzien. De informatie uit bepaalde hoofdstukken is verplaatst en nieuwe hoofdstukken zijn toegevoegd. Er is geprobeerd een scheiding aan te brengen in de sitemanager als content manager en de sitemanager als technisch beheerder van de site. Hierbij wordt meteen een scheiding aangebracht in de dagelijkse routine die bij het beheer van de site komt kijken en de technische handelingen die minder vaak voorkomen.
De kennis die je als sitemanager nodig hebt is nogal afhankelijk van hoe jouw rol als sitemanager er uitziet. Ben je voornamelijk bezig met het beheren van de content dan is speciale kennis niet vereist, maar is het een vordeel als je een basisidee hebt de werking van een database. Ben je als sitemanager bezig met het importeren en exporteren van content, het aanpassen van de Rendertemplates of het configureren van de security dan is meer kennis noodzakelijk van bijvoorbeeld XML, HTML en databases. We hopen dat de handleiding in de nieuwe opzet voldoet en wensen je succes met het beheren van jouw site. Delft, december 2004 Smartsite Software BV II 1997-2004 Smartsite Software BV
Inhoud Voorwoord Inhoud I III Hoofdstuk 1 Smartsite Data Model en Architectuur 1 Content Data Model 2 Wat is een database 2 De Contents tabel 3 Contenttypes 5 De ContentVersions tabel, workflow en versies 6 Security model 9 Gebruikers, Groepen, Rollen, Acties 9 Role-based Management 10 Delegated Security 12 Hardware architectuur en Outscaling 15 Hoofdstuk 2 Meta-informatie: thesauri en tabellen 17 Inleiding over thesauri 18 Relatie-indicatoren en term data 20 De equivalente relatie 20 De hiërarchische relatie 21 De associatieve relatie 23 Aanvullende informatie voor termen 24 Een thesaurus beheren 25 Data aan een thesaurus toevoegen 25 Door een thesaursus bladeren 28 Een thesaurus exporteren of importeren 29 Exporteren 29 Importeren 30 De opzet van een thesaurus wijzigen 33 Een thesaurus definiëren 34 Definiëren van Term Data Types 35 Definiëren van Relation Types 37 De thesaurus definiëren 40 Tabellen bewerken 43
Hoofdstuk 3 Content Management 45 Praktische site opbouw 46 CMS folders 47 Translations 48 Geneste Translations 49 Geparametriseerde Translations 50 Afbeeldingen en Binaries 50 Folders op orde houden 51 Sturen van content 52 Overzicht van items in een worfklow 52 Items aan gebruikers toekennen 53 Een workflow van een item halen 54 Content publiceren en archiveren 56 Publicatiestatus instellen 57 Content actualiseren 60 Meta-informatie wijzigen 60 Tekst in meerdere items aanpassen 63 Gewijzigde items versneld activeren 65 Hoofdstuk 4 Data Management 67 Wat is data-management 68 Een site labelen 69 Gelabelde versies terugzetten 69 Verwijderde items 71 Gearchiveerde taken opruimen 73 Versies opruimen 74 Hoofdstuk 5 Formulieren 77 Wat zijn formulieren 78 Een nieuw formulier toevoegen 80 Default Source 81 Save as Item, field Body 81 Save as Item 83 Send Email 84 Database Table 84 Databinding eigenschappen wijzigen 85 Het formulier definiëren 86 Elementen toevoegen 87 Eigenschappen van elementen 90 Tekstelementen 90 Lijstelementen 91 Overige elementen 92 htmledit element 93 Label element 93 FileInput element 93 Submit en Reset button element 93 Subformulieren 94 Opmaak van elementen 94 IV 1997-2004 Smartsite Software BV
Formulieren gebruiken 95 Verstuurde formulieren bekijken 98 Hoofdstuk 6 Import en export 101 Import-functies 102 Import mogelijkheden 102 Word-documenten importeren 104 Tekst- en HTML-documenten importeren 105 Een aantal opties in de Export Wizard 106 Importeren of refereren 107 Hoofdstuk 7 Rechten en Security 109 Smartsite Application Console 110 Gebruikers aanmaken en beheren 112 Een apart soort gebruiker: de visitor 113 Groepen aanmaken en beheren 114 Rollen aanmaken en beheren 117 Wie, waar, wat 119 Gebruik van de Smartsite Manager 119 Bladeren door de site 121 Hoofdstuk 8 Workflow 125 Definitie Workflow 126 Hoe werkt workflow 128 CMS-statussen 129 CMS-Statussen en interactie 130 Analyse Workflow 133 De basis van een workflow 135 De definitie van activiteiten 136 Acties binnen Activiteiten 141 Transitions 142 Hoofdstuk 9 Channels, Rendertemplates en Macro s 147 Wat zijn channels 148 Opbouw van een channel 148 Wat zijn Rendertemplates 152 Opzet van Rendertemplates 152 Simpele HTML Rendertemplate 154 Complexe rendertemplates 155 XLinks Macro 156 Een XLinks macro invoegen 156 Hoofdstuk 10 Contenttype Management 161 Weergave van een contenttype aanpassen 162 Eigenschappen van een contenttype 165 Contenttype velden 166 Smartsite Content Management Server V
Aanpassen van Contenttype veldeigenschappen 167 Hoofdstuk 11 Servercache en AIM 169 Active Integrity Maintenance (AIM) 170 Overzicht van verwijzingen 170 AIM in de praktijk 171 Servercache 172 Servercache instellen 172 Servercache en AIM 174 Level I en Level II cache 175 Bijlage A De Smartsite Management Information module A-1 Meten van bezoekers A-2 Cache A-3 Proxyserver A-3 Cookies A-4 Cookie instellingen A-5 Methode van tellen A-5 Referrer A-5 Algemene issues A-6 Conclusie A-6 Hardware en software eisen A-7 SMI Architectuur A-7 SMI Database model A-8 jdays A-12 Applet beschrijving A-13 De buttons van het applet A-14 De SMI menubalk A-14 Management Information Setup A-15 SMI menu opties A-17 SMI templates A-17 Scope Menu A-17 Site menu A-18 Visitor menu A-19 Referrers Menu A-20 Server Menu A-21 Eigen events meten A-21 Personalisatie A-22 Colofon VI 1997-2004 Smartsite Software BV
Hoofdstuk 1 Smartsite Data Model en Architectuur Om een site te kunnen beheren is het goed om een globaal inzicht te hebben van de technische achtergronden van Smartsite. Smartsite is een database georiënteerde applicatie en veel zaken die met het beheer te maken hebben zijn beter te begrijpen wanneer je enigszins begrijpt hoe een database werkt. Binnen de Smartsite Manager is Security van groot belang; elke gebruiker mag alleen die acties uitvoeren die aan zijn rol zijn gekoppeld. In dit hoofdstuk wordt een korte inleiding op het security model van Smartsite gegeven. Smartsite is een server-side application. Hierdoor hoeven er geen programma s op lokale computers geïnstalleerd te worden om met Smartsite te kunnen werken. Alleen Microsoft Internet Explorer is vereist om te surfen naar de Smartsite Manager. Om de werkdruk van de server zo optimaal te verdelen kunnen de taken over meerdere servers verdeeld worden. Dit proces wordt outscaling genoemd en zal in dit hoofdstuk kort worden toegelicht. Met deze kennis worden sommige aspecten, die komen kijken bij het beheren van een door Smartsite aangedreven site, eenvoudiger te begrijpen en te doorzien.
Smartsite Data Model en Architectuur 1.1 Content Data Model Smartsite is een database georienteerde applicatie waarin alle informatie wordt opgeslagen. Ook alle ondersteunende informatie is in deze database terug te vinden. Deze informatie is verdeeld over verschillende tabellen die onderling relaties met elkaar kunnen hebben. Veel processen binnen Smartsite kunnen beter worden beschreven wanneer men een globaal inzicht heeft in de structuur van deze database 1.1.1 Wat is een database Databases zijn bestemd om op een ordelijke manier uiteenlopende informatie op te slaan. Een database bestaat uit een verzameling van tabellen. Elke tabel bestaat uit kolommen, in een database de velden genoemd, en rijen, ook wel records genoemd. Door steeds rijen te vullen met informatie, sla je die informatie op een geordende manier op. ID Naam Group Groepsomschrijving 1 J. Jansen Content Managers Beheert en structureert de content in de site. 2 M. Gerritsen Content Editors Voegt nieuwe content toe aan de site. 3 C. Ontent Content Editors Voegt nieuwe content toe aan de site. Tabel 1-1: Voorbeeld van een tabel Gebruikers Een database zou uit een tabel kunnen bestaan, maar vaak zie je dat er meerdere tabellen in een database aanwezig zijn. Deze tabellen kunnen relaties met elkaar onderhouden waardoor een zogenaamde relationele database ontstaat. Het voordeel van deze relaties is dat informatie niet onnodig hoeft worden ingevuld. In bovenstaand voorbeeld hebben we een eenvoudige tabel waarin we een overzicht hebben van alle gebruikers van de Smartsite Manager en in welke groep zij zitten. Daarnaast wordt er een omschrijving van die groep gegeven. Deze tabel is nog kort en overzichtelijk, maar in werkelijkheid kan deze tabel uit tientallen, misschien wel honderden records bestaan. We zien in het voorbeeld dat er twee personen zijn die de rol van Content Editor hebben. De omschrijving voor de groep is natuurlijk exact hetzelfde. Deze omschrijving moet echter wel elke keer ingevuld worden en ook nog eens opgeslagen. Dat kost voornamelijk ruimte in de database. Door nu meerdere tabellen in deze database te gebruiken kunnen we dat probleem voorkomen. Er wordt een aparte tabel gemaakt voor alle Groepen: 2 1997-2004 Smartsite Software BV
Content Data Model GroepsID Naam Omschrijving 1 Content Editors Voegt nieuwe content toe aan de site. 2 Content Managers Beheert en structureert de content in de site. Tabel 1-2: een tabel met alle Groepen De Gebruikers tabel kan nu korter gemaakt worden. In deze tabel worden de velden Groepsnaam een Groepsomschrijving vervangen door een enkel veld GroepsID. ID Naam GroepsID 1 J. Jansen 2 2 M. Gerritsen 1 3 C. Ontent 1 Tabel 1-3: de vereenvoudigde Gebruikers tabel In het veld GroepsID wordt nu het nummer van de betreffende groep uit de tabel Groepen gezet. De velden GroepsID uit beide tabellen zjin aan elkaar gerelateerd. Op deze manier hoeft er veel minder informatie te worden opgeslagen. Door de GroepsID van een gebruiker kunnen we achterhalen wat de naam van de groep is en wat de omschrijving van die groep is door deze uit de tabel Groepen te lezen. Je plakt de twee tabellen dus als het ware achter elkaar: ID Naam GroepID 1 J. Jansen 2 2 M. Gerritsen 1 Content Editors Voegt nieuwe content toe aan de site. 3 P. Fuijk 1 Tabel 1-4: Dit is een zeer beknopte beschrijving van een hoe het in een database toegaat en in werkelijkheid is het ook gecompliceerder dan hier beschreven. Echter, het principe van elke relationele database werkt zoals in dit voorbeeld is uitgelegd. 1.1.2 De Contents tabel In de database van een door Smartsite aangedreven site is de Contents tabel de belangrijkste tabel. Alle informatie die door middel van items wordt inge- Smartsite Content Management Server 3
Smartsite Data Model en Architectuur voerd wordt in deze tabel opgeslagen. Elk item is dus eigenlijk een record, een rij, in deze tabel. De Contents tabel bevat een heleboel velden. Zomaar een greep uit deze velden is bijvoorbeeld: Veldnaam Nr Title Body AddDate Parent CTSpecificInt1 CTSpecificVar3 Omschrijving Dit veld bevat het unieke nummer van een item. De titel van een item wordt in dit veld weggeschreven. De tekst die in het body-veld wordt getypt wordt in dit veld opgeslagen. De datum wanneer een item werd aangemaakt en toegevoegd aan de Contents tabel. Het nummer van het item waar dit item een kind van is. Op deze manier wordt de hiërarchie van de boomstructuur gecreëerd. Een veld waarin numerieke waarden kunnen worden opgeslagen. Een veld waarin tekst kan worden opgeslagen. Tabel 1-5: Een greep uit de velden van de Contents tabel Elk veld is van een bepaald veldtype en kan dienovereenkomstig een bepaald soort informatie herbergen; het veld Body is een uitgebreid tekstveld en kan grote hoeveelheden tekst bevatten, het veld AddDate is een veld dat alleen datums accepteert en het veld CTSpecificInt1 accepteert alleen gehele getallen. Een speciaal veld is het veld Nr, dat een uniek nummer bevat en dat automatisch wordt opgehoogd elke keer dat er een nieuwe regel aan de tabel wordt toegevoegd. Alle items die in de Contents tabel zijn aangemaakt hebben een relatie tot elkaar. Elk item in de tabel heeft een uniek nummer. Elk item heeft een veld genaamd Parent. Dit veld Parent verwijst naar het unieke nummer van een ander item. Het resultaat van deze verwijzing is een boomstructuur. Binnen Smartsite wordt gesproken over Parents (Ouders) en Children (Kinderen) en een daaruit resulterende Parent-Child relatie (Ouder-Kind relatie). Door deze Parent-Child relatie ontstaat er een hiërarchie in de informatie die is opgeslagen. De Parent-Child relatie wordt gebruikt om eigenschappen van een item door te geven aan een item dat een kind is van dat item. Dit doorgeven van eigenschappen wordt binnen Smartsite, en net als in het echte leven, overerving genoemd. De hiërarchische boomstructuur die ontstaat door gebruik te maken van Parent-Child relaties wordt binnen Smartsite voor uiteenlopende doelen gebruikt: het vastleggen van een functionele indeling; het erven (doorgeven) van eigenschappen van items; 4 1997-2004 Smartsite Software BV
Content Data Model het dynamisch genereren van hyperlinks naar onderliggende en/of bovenliggende items; het toekennen van rechten aan gebruikers om delen van de boomstructuur wel of niet te mogen bewerken. In eerdere versie van Smartsite was er behoefte om extra velden aan de Contents tabel toe te voegen om de invoer van informatie te structureren; het aantal benodigde velden was vaak groter dan het aantal beschikbare velden die in de database voorkwam. Het aantal velden in de database groeide daarom explosief omdat elke soort invoer van informatie weer andere velden noodzakelijk maakte. De Contents tabel van Smartsite 5 bevat een groot aantal velden die voorzien zijn van een hele algemene naam zoals CTSpecificText1, CTSpecificBit3 en CTSpecificBinary1. Deze velden kunnen nu gebruikt worden om informatie in op te slaan. Om de velden effectief te gebruiken worden contenttypes gebruikt. Elk item in de Contents tabel is daarom aan een contenttype gekoppeld. 1.1.3 Contenttypes Het aantal velden in de Contents tabel bedraagt ongeveer vijftig. Wanneer een item wordt toegevoegd met behulp van de Smartsite Manager hoef je (gelukkig) niet al die velden in te vullen. Voor het invullen van die velden wordt namelijk gebruik gemaakt van zogenaamde contenttypes. Noot Het genoemde aantal van vijftig velden is een standaardsituatie. Omdat het datamodel van Smartsite uitbreidbaar is, is het mogelijk dat het aantal velden in de Contents tabel groter is dan vijftig. Contenttypes zijn definities van informatie. Een contenttype heeft een aantal velden waarin deze informatie kan worden ingevuld. De definitie van het contenttype koppelt deze velden aan de velden in de Contents tabel. Heel basaal gezegd is een contenttype een masker dat over een regel in de Contents tabel wordt gelegd om de invoer in deze tabel te vereenvoudigen - het laat aleen die velden zien die moeten worden ingevuld terwijl de andere velden zijn afgedekt. Een contenttype stelt je dus in staat om eenvoudig informatie in te voeren. Je hoeft je alleen nog maar te beperken tot die velden die getoond worden. Maar wat gebeurt er eigenlijk met de overige velden die niet zichtbaar zijn? Voor die velden die niet zichtbaar zijn zijn er twee mogelijkheden: 1. De velden worden door Smartsite ingevuld. De datum en tijd dat een item wordt aangemaakt (AddDate) en het nummer van een item (Nr) zijn typisch velden waar Smartsite zorg voor draagt; 2. Het veld blijft simpelweg leeg. Niet alle velden hoeven verplicht te worden ingevuld. Smartsite Content Management Server 5
Smartsite Data Model en Architectuur Naast dat een contenttype velden afschermt heeft een contenttype nog een functie. Een contenttype kan namelijk het gedrag van een veld bepalen. Dat wordt gedaan door het toepassen van speciale hulpmiddelen op een veld - denk aan de webeditor - of door het afdwingen van bepaalde invoer - denk aan het niet leeg mogen zijn van het titelveld. Verder is het zo dat er afgedwongen kan worden welke rollen een bepaald veld wel of niet mogen zien en/of bewerken. Het definiëren en implementeren van contenttypes gebeurt bij het opzetten van een site. Daar heeft een site-manager in principe niets meer mee van doen. Smartsite heeft zelf al een groot aantal standaard contenttypes die gebruikt worden voor de werking van de site, zoals het bijvoorbeeld de contenttypes Channel, Rendertemplate en Worfklow die respectievelijk de definitie van een channel, de opmaak van contenttypes in een bepaald channel en de definitie van de worfklow bevatten. Om het zetten van de eigenschappen van de afzonderlijke velden zo eenvoudig mogelijk te houden zijn contenttypes gegroepeerd. Contenttypes die in dezelfde groep zitten hebben hetzelfde aantal velden. Of die velden ook zichtbaar zijn bij het bewerken van items van dat contenttype hangt helemaal van de eigenschappen af. Het ene contenttype uit een groep heeft misschien wel vier zichtbare velden, het andere contenttype heeft er zes. Omdat ze in dezelfde groep zitten hebben ze exact hetzelfde aantal velden, alleen bij het ene contenttype is aangegeven dat twee van de zes velden niet zichtbaar zijn. Er kan nu echter wel gebruik worden gemaakt van de mogelijkheid om de eigenschappen van de overige vier velden van het contenttype tegelijk te bepalen in plaats van voor elk contenttype afzonderlijk. Dat contenttypes gegroepeerd zijn komt bijvoorbeeld terug in de actie Switch Contenttype Noot Het is misschien goed om te onderstrepen dat contenttypes géén items zijn en ook geen zelfstandige objecten. Het zijn alleen maar hulpmiddelen om informatie in de contentstabel op een gestructureerde manier te manipuleren en weer te geven. Toch zal er in het verdere verloop van deze handleiding over contenttypes gesproken worden als waren het zelfstandige objecten die informatie bevatten. Voor de beeldvorming is dit ook een prima uitgangspunt maar in sommige gevallen moet je je weer even realiseren dat de informatie niet in het contenttype is opgeslagen maar in de Contents tabel. 1.1.4 De ContentVersions tabel, workflow en versies Alle items die in de Smartsite Manager worden aangemaakt zijn onderworpen aan een workflow. Dat betekent dat een item een keten van stappen moet doorlopen voordat het item actief wordt en zichtbaar aan de voorkant van de site. Daarnaast wordt er elke keer dat een item wordt opgeslagen een nieuwe versie van een item opgeslagen. In een later stadium kan een oude 6 1997-2004 Smartsite Software BV
Content Data Model versie van een item worden teruggehaald en opnieuw actief gemaakt worden. Het opslaan van de versies gebeurt in de ContentVersions tabel. De actieve content bevindt zich in de Contents tabel. De Contents tabel en de Content- Versions tabel hangen nauw met elkaar samen. In onderstaande tabel wordt geprobeerd om de samenhang tussen deze twee tabellen en de levenscyclus van een item weer te geven: Actie Workflow Status Publication Status tabel Contents tabel ContentVersions Busy Prepublished nieuw record nieuw record Busy Prepublished nieuw record Busy Prepublished nieuw record Busy Prepublished nieuw record Active Active bestaand record nieuw record overschreven Busy Active nieuw record Busy Active nieuw record Busy Active nieuw record Active Active bestaand record overschreven Tabel 1-6: nieuw record In bovenstaande tabel zien we dat elke keer dat een item wordt bewerkt er een nieuw record, een nieuwe rij in de ContentVersions tabel wordt geplaatst. Pas wanneer een item een gehele workflow heeft doorlopen wordt de laatste versie van een item overgeheveld van de ContentVersions tabel naar de Contents tabel. Op dat moment is de informatie ook zichtbaar aan de voorkant van de site. Noot In dit voorbeeld is gebruik gemaakt van de default workflow. Deze workflow kent maar twee statussen, namelijk Busy en Active. Echter, je zou het hele pad van het aanmaken van een item tot het actief worden tot het opnieuw bewerken en opnieuw actief worden van een item natuurlijk ook langs een zeer uitgebreide workflow kunnen laten lopen. De ContentVersions tabel is dus een soort schaduwtabel van de Contents tabel. Het bevat bijvoorbeeld ook het veld Title het veld Body. Echter, er is een grote maar. Het hoeft niet zo te zijn dat alle velden uit de Contents tabel ook in de ContentVersions tabel bestaan. Die velden die niet in de ContentVersions tabel bestaan worden direct in de Contents tabel aangepast. Een wijziging in de Contents tabel betekent een directe wijziging van de actieve content en dat betekent vaak ook een direct resultaat aan de voor- Smartsite Content Management Server 7
Smartsite Data Model en Architectuur kant van de site. Wanneer ik he veld Description van een item in de Contents tabel verander dan zal die verandering direct te zien zijn wanneer je het item aan de voorkant van de site opvraagt. Voor veel velden is het ook niet zo interresant wanneer zij aan versiebeheer onderhevig zijn. Het grote gevaar schuilt in de zogenaamde tekstvelden die aan de voorkant van de site gebruikt worden. Voorbeeld Stel dat het veld Title en het veld Body in de ContentVersions tabel staan en het veld Description niet. Een redacteur bewerkt een item en typt in het Description veld een vreemde tekst. De redacteur slaat het item op in de workklow-status Busy. Hierbij gaat hij er vanuit dat de nieuwe informatie pas zichtbaar wordt als hij het item in de status Active opslaat en dat het niet erg is dat de tekst in de verschillende velden nog niet compleet is of tijdelijke,misschien wel gevoelige, informatie bevat. Omdat het veld Description niet in de ContentVersionstabel staat zal de tekst in dit veld direct zichtbaar zijn aan de voorkant van de site op die plaatsen waar dit veld wordt afgebeeld. 8 1997-2004 Smartsite Software BV
Security model 1.2 Security model Het Security Data model regelt de rechten van de gebruikers van de Smartsite Manager en de bezoekers van de door Smartsite aangedreven site. Het Security Model van Smartsite is veelomvattend en de mogelijkheden om rechten nauwkeurig aan te passen nemen in de oplopende edities van Smartsite (Standard, Professional en Enterprise) alleen maar toe. Bij de security-instellingen van Smartsite gaat het om rechten van gebruikers of bezoekers. Het gaat hierbij niet om zaken als firewalls, packet filters, of virus scanners; deze maken geen deel uit van Smartsite zelf. Anders gezegd: het gaat niet om hekken met prikkeldraad om Smartsite heen, maar om de sloten op de deuren binnen Smartsite zelf. 1.2.1 Gebruikers, Groepen, Rollen, Acties Alle mogelijkheden die je binnen de Smartsite Manager hebt zijn samengevat in acties en privileges. Je kunt items toevoegen, contenttypes aanmaken en bewerken, bestanden importeren en je hebt de privileges om folders aan te maken, de WebEditor te gebruiken of om items te verwijderen. De acties die er binnen de Smartsite Manager mogelijk zijn moeten worden gekoppeld aan de gebruikers die met de Smartsite Manager aan de slag gaan. Daarnaast willen we ook aangeven waar binnen de hiërarchische boomstructuur van de site acties mogen worden uitgevoerd. Voor het koppelen van de acties aan de gebruikers zijn er in Smartsite twee tussenstappen: rollen en groepen. Deze rollen en groepen worden respectievelijk gevuld met acties en met gebruikers. Daarna worden de rollen aan groepen toegekend. Figuur 1-1: De onderlinge samenhang van gebrukers, groepen, rollen en acties De groepen spelen een centrale rol in de beveiliging en rechtenstructuur van de Smartsite Manager. De groepen worden gebruikt om het Waar, Wat en Hoe te definiëren. Smartsite Content Management Server 9
Smartsite Data Model en Architectuur Groepen worden allereerst gebruikt om aan te geven op welk deel van de boomstructuur de groep recht heeft om items en folders te bewerken (Waar). De contenttypes die aan een groep zijn toegekend bepalen welke items en folders er bewerkt kunnen worden (Wat). De rol die aan een groep is toegekend bepaalt hoe de items en folders bewerkt kunnen worden (Hoe). Wanneer een gebruiker in een groep wordt geplaatst betekent dat: hij een rol heeft die bepaalt welke acties hij mag uitvoeren hij alleen items en folders van bepaalde contenttypes mag bewerken hij alleen bepaalde folders op de file-server mag gebruiken Dit is de basis van het securitymodel. Het model gaat echter verder. Gebruikers kunnen bijvoorbeeld niet in een enkele groep geplaatst worden maar in meerdere groepen tegelijk. Hierdoor kunnen gebruikers verschillende rollen aannemen waarmee hun rechten worden ingedamd of uitgebreid. Dit wordt Role-based Management genoemd. De groepenstructuur is hiërarchisch van opbouw. Deze hiërarchie is enerzijds van belang voor de workflow van items maar deze hiërarchische opbouw van de groepen maakt het ook mogelijk om rechten door te geven aan lagere gebruikers. Dit principe wordt Delegated Security genoemd. 1.2.2 Role-based Management Role-based Management betekent dat een gebruiker bij het werken met de Smartsite Manager gebruik maakt van een bepaalde rol. De acties die aan een rol zijn toegekend bepalen in feite hoe je binnen de Smartsite Manager kunt werken Een gebruiker van de Smartsite Manager heeft een rol omdat hij in een bepaalde groep zit. Wanneer een gebruiker in meedere groepen zit dan zou het kunnen zijn dat hij in iedere groep een andere rol heeft. Is dat het geval dan betekent dat dat een gebruiker van rol kan wisselen. Het wisselen van rol betekent dus in feite dat de gebruiker in een andere groep terecht komt. In de hiërarchische boomstructuur van de website kan worden aangegeven welke groepen waar rechten hebben om hun acties uit te voeren. Door een deel van de boomstructuur aan een groep toe te kennen leg je de verantwoordelijkheid voor het onderhoud van de informatie in dat deel bij die groep. Wanneer een gebruiker dus meerdere rollen heeft dan kan het wisselen van rol betekenen dat hij in een andere groep terecht komt en dus op andere delen van de boomstructuur acties kan uitvoeren. Voorbeeld Een medewerker van een organisatie zit in de groep News Editors. Deze groep heeft de rol van Editor (redacteur). Dit betekent dat deze persoon items mag aanmaken in een bepaald deel van de site, bijvoorbeeld onder een folder 10 1997-2004 Smartsite Software BV
Security model met nieuwsitems. Voordat deze items kunnen worden gepubliceerd moeten deze, door de toegepaste workflow, ook nog langs de groepen Public Relations Management en Content Managers. Figuur 1-2: Voorbeeld van een hiërarchische groepenstructuur Deze persoon uit de groep News Editors is ook hoofd van de Sales afdeling. Alle berichten en informatie die te maken heeft met de verkoop, en die worden aangemaakt door de redacteuren uit de twee subgroepen Sales Dep. Interntl. en Sales Dep. Local, worden eerst door deze persoon gecontroleerd alvorens ze de laatste stap naar de groep Content Managers maken. Aan de groep Sales Management is de rol van Chief Editor (Hoofdredacteur) gekoppeld. Deze gebruiker zit nu dus in twee groepen en heeft in beide groepen een andere rol. Wisselen van rol betekent dus dat hij op andere delen van de boomstructuur andere acties kan uitvoeren. Niet alle edities van Smartsite ondersteunen bovenstaande volwaardige manier van Role-based Management. In het kort ziet de situatie er als volgt uit: Editie Standard Edition Professional Edition Enterprise Edition Security model Een gebruiker kan maar in een groep zitten en aan een groep kan maar een rol worden toegekend. Een gebruiker kan in meerdere groepen zitten maar de acties uit de verschillende rollen worden allemaal samengevoegd. Een gebruiker kan in meerdere groepen zitten en in elke groep een compleet andere rol met andere acties spelen. Dat betekent dus dat volwaardig Role-based management alleen in deze editie mogelijk is. Tabel 1-7: overzicht Smartsite Content Management Server 11
Smartsite Data Model en Architectuur 1.2.3 Delegated Security Dat een bepaalde groep van gebruikers meerdere rollen kan vervullen lijkt overbodig wanneer de inhoud van bepaalde rollen (de toegekende acties aan die rol) elkaar overlapt; een deelverzameling van de acties uit een hogere rol zit ook in de lagere rol. Smartsite maakt gebruik van het begrip Delegated Security. Het delegeren van een deel van jouw rechten kan wanneer je die rechten in verschillende rollen hebt ondergebracht. Het maximale wat je kunt uitdelen zijn de rechten die je zelf bezit. Als voorbeeld nemen we een standaard redactie waar de hoofdredacteur een aantal redacteuren onder zich heeft (Figuur 1-3:een elementaire hoofdredactie). De hoofdredacteur maakt in dit geval deel uit van de groep hoofdredacteuren, de redacteuren maken deel uit van de groep redacteuren. Hoofdredactie A Redactie A1 Redactie A2 Figuur 1-3: een elementaire hoofdredactie Bij deze groepen horen de volgende rollen: Groep/Rol Hoofdredacteuren Redacteuren Hoofdredacteu r Redacteur Tabel 1-8: groepen en rollen De groep hoofdredacteuren heeft dus de rollen Hoofdredacteur en Redacteur. Bij de rollen uit dit voorbeeld horen de volgende acties: Acties/Rol Hoofdredacteur Redacteur Add Item Edit Item Delete Configure Security, Edit Users Tabel 1-9: Rollen en acties 12 1997-2004 Smartsite Software BV
Security model Acties/Rol Hoofdredacteur Redacteur Configure Security, Edit Groups Set Manager Access Tabel 1-9: Rollen en acties Noot Om het voorbeeld overzichtelijk te houden is de situatie vereenvoudigd. In werkelijkheid moeten naast de acties ook een aantal privileges worden toegekend. Deze maken het onder meer mogelijk toegang te krijgen tot de Manager, de SmartEditor te starten, een folder aan te maken en direct op de site te publiceren. Afdeling A krijgt een nieuwe medewerker die ook aan de slag moet met de Smartsite Manager. De webmaster uit dit voorbeeld heeft geen tijd om zich bezig te houden met de personele wijzigingen op de redactie. Daarom heeft hij de Hoofdredacteur voorzien van de Gebruikers Bewerken (Edit Users) actie. Met deze actie kan de hoofdredacteur een nieuwe gebruiker aanmaken en deze in een groep plaatsten. Hij plaatst deze nieuwe redacteur natuurlijk in de groep redacteuren. De webmaster zelf heeft de rechten Rollen bewerken (Edit Roles) en Actielijst bewerken (Edit Action List). Daarmee is het mogelijk acties aan te maken en vast te leggen binnen rollen. Dit kan echter eenmalig gebeuren waarna wijzigingen in bezetting door de hoofdredacteur zijn op te lossen. Pas wanneer de organisatie drastisch wijzigt (en er nieuwe afdelingen bijkomen) wordt weer een beroep gedaan op de webmaster. Deze hoeft alleen een nieuwe folder voor een redactie aan te maken in de site naast de bestaande folders voor redacties. Binnen deze folder kan de nieuwe redactie items plaatsen. Stel dat de organisatie wordt uitgebreid en er in de nieuwe situatie sprake is van drie afzonderlijke hoofdredacties (A, B en C) elk verbonden aan een eigen productgroep. De drie redacties krijgen een afzonderlijk deel van de site toegewezen voor het publiceren van artikelen. Het is niet de bedoeling dat leden van een redactie de artikelen van een andere redactie bewerken of wissen of voor deze andere redactie artikelen toevoegen. Als de hoofdredacteur nu drie groepen aanmaakt voor hoofdredacteuren en daarnaast redacteuren hiervoor aanmaakt, krijgen deze alle dezelfde rechten. Om ervoor te zorgen dat de redacties gescheiden van elkaar zijn (m.b.t. de rechten) is het noodzakelijk met de actie Manager Rechten Instellen (Set Manager Access) aan te geven op welk deel van de site de rechten van toepassing zijn. Smartsite Content Management Server 13
Smartsite Data Model en Architectuur Hoofdredactie Bedrijf Rol HR Rol R Set edit access Hoofdredactie A Hoofdredactie B Hoofdredactie C Rol HR Rol R Redactie A1 Redactie A2 Redactie B1 Redactie B2 Redactie C1 Redactie C2 Rol R Figuur 1-4: Een voorbeeld van een organisatiestructuur Het aangeven van de plaats waar één rol mag worden uitgevoerd, zodat op verschillende plaatsen de acties uit verschillende rollen zijn toegestaan, wordt alleen volledig ondersteund door de Enterprise Edition. Binnen de overige edities is het wel mogelijk de hiërarchie op te bouwen en de plaats aan te geven waar een rol mag worden uitgevoerd maar alle rollen waarover een gebruiker beschikt worden samengevoegd. Dus op de plaats die je aangeeft zijn alle acties uit alle rollen toegestaan. Stel dat iemand deel uitmaakt van Hoofdredactie A en Redactie C1. Zowel in de Professional als in de Enterprise Edition is het mogelijk de rollen in te stellen (rol HR en rol R bij Hoofdredactie A, rol R bij redactie C1). In de Professional edition worden alle toegekende rollen echter samengevoegd waardoor deze persoon ook over de rol HR beschikt op redactie C1. In de Enterprise Edition worden de rollen niet samengevoegd. Het is absoluut aan te raden de hiërarchie van het begin af aan goed op te bouwen (ook als je niet over de Enterprise Edition beschikt) om het werken met Smartsite te structureren en om eventuele upgrades te vergemakkelijken. 14 1997-2004 Smartsite Software BV
Hardware architectuur en Outscaling 1.3 Hardware architectuur en Outscaling Smartsite is een server-side application - een applicatie die op een centrale (web)server draait en waarvoor geen apart programma op een lokale computer hoeft te worden geïnstalleerd. Het bewerken van de informatie die door Smartsite wordt beheerd en gepubliceerd gebeurt met behulp van de Smartsite Manager. De Smartsite Manager wordt geopend in de webbrowser en we kunnen dus zeggen dat de Smartsite Manager niets ander is dan een zeer geavanceerde website die jou in staat stelt om informatie te bewerken en te beheren. De opgeslagen informatie wordt ook gepubliceerd deze informatie wordt opgevraagd de bezoekers van de site. Deze situatie zou als geschetst kunnen worden zoals in onderstaande figuur Figuur 1-5: Client-Server model In Smartsite termen noemen we deze architectuur een CMS-server en een Publicatie-server in een. De redacteuren van de site die de informatie bewerken en de bezoekers die de informatie opvragen surfen naar dezelfde webserver. Wanneer er sprake is van een druk bezochte site waar op hetzelfde moment ook een groot aantal redacteuren en beheerders bezig is met het toevoegen, bewerken en beheren van (nieuwe) informatie, dan kun je je voorstellen dat de webserver het druk krijgt - de performance van de site komt onder druk te staan. Om de performance te verbeteren kan de architectuur van de site zodanig worden ingericht dat er verschillende stromen van elkaar worden gescheiden. Dit proces wordt Outscaling genoemd. Er zijn verschillende vormen van Outscaling. Waar het bij Outscaling op neer komt is dat je de taken gaat verdelen over verschillende servers: publicatieservers en CMS servers. De publicatieserver wordt benaderd door bezoekers terwijl de CMS server wordt gebruikt voor het toevoegen en bewerken van nieuwe content. Smartsite Smartsite Content Management Server 15
Smartsite Data Model en Architectuur zorgt voor de communicatie tussen de twee servers en zorgt ervoor dat de publicatieserver gevoed wordt met de laatste actieve content. Figuur 1-6: Voorbeeld van outscaling Hoe beïnvloedt de architectuur nu het beheerproces van een Smartsite omgeving? Voor de site managers die zich met het beheer van de content bezighouden zal een complexe architectuur nauwelijks merkbaar zijn. Smartsite is zodanig ingericht dat het beheer van de content op alle CMS servers hetzelfde verloopt. Men heeft niet door dat men eventueel op een andere CMS server aan het werk is. Met betrekking tot de publicatie zijn er echter wel een aantal zaken die de aandacht verdienen. Wanneer er sprake is van een aparte publicatieserver die met behulp van webservices wordt gevoed met de actieve content kan er in het bijwerken van de publicatieserver een vertraging zijn ingebouwd. Hoe groot deze vertraging is, is instelbaar. Dat betekent dat de informatie soms pas na enige tijd zichtbaar is aan de publicatiekant van de site. Wanneer je het resultaat echter aan de voorkant van de CMS-server bekijkt dan zul je direct de juiste informatie zien. 16 1997-2004 Smartsite Software BV
Hoofdstuk 2 Meta-informatie: thesauri en tabellen Een belangrijk onderdeel van een site is meta-informatie. Metainformatie is informatie die iets zegt over andere informatie - de categorie van een item, de sleutelwoorden of trefwoorden van een item, de auteur, het contenttype zijn allemaal elementen van een item die duiding geven over de feitelijke inhoud van een item. Een belangrijke taak voor site managers is het beheren van de meta-informatie opdat redacteuren altijd een juiste categorie of trefwoord kunnen selecteren. Deze meta-informatie is voornamelijk opgeslagen in de thesaurus. Andere meta-informatie is terug te vinden in tabellen die in de database aanwezig zijn. Een thesaurus is een gestructureerde woordenlijst waarin tussen de termen die in deze lijst voorkomen relaties bestaan. Deze relaties kunnen van verschillende aard zijn: equivalent, hiërarchisch of associatief.
Meta-informatie: thesauri en tabellen 2.1 Inleiding over thesauri De vertaling van het latijnse woord Thesaurus is in het Nederlands schatkamer. Dit geeft al aan welke waarde er aan een goed opgezette thesaurus gegeven kan worden; een goed opgezette thesaurus maakt het mogelijk om op een gestructureerde manier meta-informatie aan de content van een site toe te voegen. Door de onderlinge relaties van de meta-informatie kunnen we de inhoud van de site op een nog betere manier ontsluiten. In deze en volgende paragrafen wordt eerst een analyse gemaakt van de verschillende onderdelen van een thesaurus in het algemeen. Deze analyse is voornamelijk ontleend aan document van het amerikaanse instituut voor standaardisatie: NISO. Het document is getiteld: Guidelines for the Construction, Format, and Management of Monolingual Thesauri ANSI/NISO Z39.19-2003 (Revision Z39.19-1980) ISSN:1041-5653 ISBN: 1-8080124-04-1. Dit document kunt u vinden op de website van de National Information Standards Organization (NISO): www.niso.org. Een definitie die door de National Information Standards Organization (NISO) wordt gegeven voor een thesaurus is: Een thesaurus is een gecontroleerde en geordende woordenlijst waarin equivalente, homografische, hiërarchische en associatieve relaties tussen termen eenduidig zijn vastgelegd door gestandaardiseerde relatie-indicators die ook omkeerbaar zijn. Het doel van een thesaurus is het bevorderen van consistentie bij het indexeren van documenten, voornamelijk bedoeld voor systemen voor het beheren en opslaan van informatie, en het faciliteren van zoekmogelijkheden door het verbinden van termen op basis van de relatie-indicators. Uit de definitie van de thesaurus kun je afleiden dat een thesaurus gebruikt wordt voor het toekennen van meta-informatie aan items. Meta-informatie speelt binnen Smartsite namelijk een belangrijke rol. Veel van de meta-informatie die binnen Smartsite aan items wordt toegekend is geautomatiseerd. Men kan hierbij denken aan de datum wanneer een item bewerkt is of het contenttype waar het item op is gebaseerd. Echter, deze meta-informatie zegt niets over de inhoud van het item - zij wordt alleen gebruikt voor de technische mogelijkheden van Smartsite: items kunnen gesorteerd worden weergegeven op datum van aanmaak of gegroepeerd per contenttype. Wil je iets kunnen zeggen over de inhoud van een item dan zul je gebruik moeten maken van woordenlijsten die bestaan uit een verzameling algemene en conceptuele termen. Door deze termen toe te kennen aan items kunnen deze items worden gecategoriseerd. Naast een lijst van algemene termen kan 18 1997-2004 Smartsite Software BV
Inleiding over thesauri men ook gebruik maken van een lijst van sleutelwoorden. Dat zijn woorden die niet zo zeer conceptueel van aard zijn maar die hele specifieke kernwoorden zijn voor bepaalde delen van een tekst. Voor de duiding van de inhoud van een item zouden meerdere sleutelwoorden van toepassing kunnen zijn. Voor het toekennen van categorieën en sleutelwoorden aan items worden vaak afzonderlijke lijsten gebruikt. Dit wordt gedaan om de aangeboden hoeveelheid informatie - de hoeveelheid woorden in een lijst - overzichtelijk te houden. Met behulp van een thesaurus kunnen deze woordenlijsten gecombineerd worden. Het combineren van woordenlijsten tot een thesaurus heeft als voordeel dat er nu relaties bestaan tussen de woorden onderling. Het bestaan van deze relaties werkt twee kanten op. Op basis van een geselecteerde categorie kan de gebruiker een tweede lijst van sub-categorieën worden aangeboden die het mogelijk maken het item nog duidelijker te specificeren. Deze lijst van sub-categorieën wordt aangeboden op basis van een relatie die de termen in die lijst het hebben met het woord dat is gekozen als categorie. Aan de andere kant kan bij het zoeken van informatie op een site ook gebruik gemaakt worden van de relaties die tussen de woorden onderling staan. Op een eenvoudige manier kan bij een geselecteerde pagina in de site een overzicht gegeven worden van andere pagina s met gelijkwaardige of gelijksoortige informatie op basis van de relaties die er tussen de meta-informatie van die pagina s bestaat. Smartsite Content Management Server 19
Meta-informatie: thesauri en tabellen 2.2 Relatie-indicatoren en term data Een van de belangrijke verschillen tussen een thesaurus en andere vocabulaire lijsten is dat de woorden in de lijst onderling gerelateerd zijn. Een ideale thesaurus bevat dan ook geen wezen - termen die op generlei wijze gerelateerd zijn aan enige andere term. Er worden drie typen relaties onderscheiden binnen een thesaurus: De equivalente relatie De hiërarchische relatie De associatieve relatie Elk van deze relaties heeft de eigenschap dat zij omkeerbaar is, i.e., elke relatie tussen term A en term B heeft een corresponderende relatie tussen van term B naar term A. De conventionele afkortingen voor de relatie indicatoren zijn als volgt: Relatie Relatie indicator Afkorting Equivalentie (synoniem) USE U USED FOR UF Hiërarchie BROADER TERM BT NARROWER TERM NT Associatie RELATED TERM RT Tabel 2-1: Relatie indicatoren en hun afkortingen 2.2.1 De equivalente relatie Wanneer een bepaald concept beschreven kan worden door twee of meer termen dan moet een keuze gemaakt worden welke van deze termen de voorkeur krijgt boven de andere(n). De (quasi)synoniemen van de voorkeursterm zijn niet de woorden die in de hoofdwoordenlijst terecht dienen te komen. Deze woorden kunnen als ingang gebruikt worden, maar het is niet wenselijk dat deze termen ook andere relaties onderhouden met termen uit de hoofdwoordenlijst van de thesaurus. Die relaties worden alleen gelegd met de voorkeursterm. Welke term de voorkeursterm is wordt bepaald door de context van de thesaurus. Wanneer bijvoorbeeld een chemische thesaurus wordt gemaakt dan zullen de chemische termen de voorkeurstermen zijn, terwijl algemene omschrijving van die termen als equivalenten worden ingevoerd. 20 1997-2004 Smartsite Software BV
Relatie-indicatoren en term data Voorbeeld Binnen een chemische thesaurus zullen de technische termen de voorkeursterm zijn: aspirine / acetylsalicylzuur zout / natriumchloride De voorkeurstermen zijn vet weergegeven. De voorkeurstermen zijn dus die termen die de behoefte van de meerderheid van de gebruikers van de thesaurus bevredigt. De beslissing welke term de voorkeursterm wordt in een equivalente relatie zal dus bij de opzet van de thesaurus genomen moeten worden. Noot Binnen de thesaurus van Smartsite wordt de equivalente relatie ondergebracht onder de kop Term Data. Term Data is aanvullende informatie op een term uit de thesaurus en deze aanvullende informatie zal geen onderdeel uitmaken van de hoofdwoordenlijst. Op deze manier komen de equivalenten van een woord niet in de hoofdwoordenlijst terecht en kunnen deze equivalente termen ook geen relaties onderhouden met andere termen uit de hoofdwoordenlijst. 2.2.2 De hiërarchische relatie Dit type relatie is de primaire eigenschap van een thesaurus die deze onderscheidt van een ongestructureerde woordenlijst. De hiërarchische relatie is gebaseerd op basis van niveau s van superioriteit en ondergeschiktheid van termen waarbij de superieure termen een gehele klasse voorstellen en de ondergeschikte termen een deel of lid van die klasse zijn. Voor het beschrijven van de hiërarchische relatie worden de volgende relatie indicatoren gebruikt: BT (Broader Term) - label voor de superieure term NT (Narrower Term) - label voor de ondergeschikte term Hiërarchische relaties tussen termen onderling kunnen worden onderscheiden in drie typische situaties: Hiërarchisch relatie type Omschrijving Generieke relatie Een manier van beschrijven waarbij een klasse en zijn leden worden beschreven Geheel - Onderdeel relatie De ondergeschikte termen zijn een onderdeel van de bredere term die het geheel beschrijft Categoriserende relatie De ondergeschikte termen zijn voorbeelden van de bredere term Tabel 2-2: overzicht van hiërarchische relatie types De generieke relatie Smartsite Content Management Server 21
Meta-informatie: thesauri en tabellen De generieke relatie beschrijft de verbanden tussen een klasse en de leden van die klasse. Een eenvoudige manier om te testen of deze hiërarchische relatie van toepassing is, is door gebruik te maken van de zin: [Narrower Term] is een [Broader Term] (de zogenaamde Allemaal - Sommige test). Let hierbij wel op de omkeerbaarheid van de relatie. Voorbeeld Een meer algemene term voor een cactus is vetplant. Ook woestijnplant lijkt op het eerste gezicht een bredere term voor een cactus. Maar omgekeerd geldt niet dat alle cactussen woestijnplanten zijn. Formeel gezien behoort de cactus daarom niet als ondergeschikte term van de categorie woestijnplanten te worden gedefinieerd. De geheel - deel relatie Deze hiërarchische relatie legt een verband tussen een geheel en de leden die tot dat geheel behoren. Een zeer duidelijk voorbeeld voor zo n type relatie is een overzicht van geografische lokaties: Nederland Zuid-Holland Den Haag Delft Rotterdam De categoriserende relatie Deze relatie legt het verband tussen een algemene categorie van dingen of gebeurtenissen en individuele voorbeelden van die categorie: Berggebieden Alpen Himalaya Pyreneeëen Wanneer daar behoefte aan is kan binnen een thesaurus expliciet onderscheid gemaakt worden tussen deze drie situaties. Dat onderscheid kan worden gemaakt door aparte hiërarchische relaties, inclusief hun unieke relatieindicatoren, te definiëren voor elk van de situaties Voorbeeld Uitgedrukt in de relatie-indicatoren zouden de volgende hiërarchische relaties kunnen zijn gedefinieerd: BT/NT BTG/NTG BTC/NTC 22 1997-2004 Smartsite Software BV
Relatie-indicatoren en term data Wanneer er sprake is van een hiërarchie tussen termen dan is er sprake van een structuur. Deze structuur kan verschillende vormen aannemen: Maximaal aantal Tree Type Maximaal aantal algemene termen ondergeschikte termen Not Defined - - Path 1 1 Binary Tree 1 2 Tree 1 oneindig Network oneindig oneindig Tabel 2-3: Types structuren voor hiërarchische relaties tussen termen in een thesaurus 2.2.3 De associatieve relatie De meest lastige relatie om te definiëren is de associatieve relatie. Deze relatie omvat die termen die noch equivalent, noch hiërarchisch tot elkaar in relatie staan. Toch staan deze termen op een of andere manier, conceptueel dan wel semantisch, in relatie tot elkaar. Voor het beschrijven van de associatieve relatie wordt de relatie indicator RT (relational term) gebruikt. Binnen de associatieve relatie kunnen we nog onderscheid maken tussen relaties tussen termen uit dezelfde hiërarchie en termen uit verschillende delen van de hiërarchie. Voorbeeld Boten en Schepen zijn allebei termen die tot de klasse (BT) Voertuigen behoren. Voor beide kan een afzonderlijke complete beschrijving gemaakt worden omdat de termen Boten en Schepen zich binnen de scheepvaart duidelijk onderscheiden door bijvoorbeeld afmetingen en tonnage. Het is dus niet zo dat een de termen Boten en Schepen equivalent (U/UF) zijn. Conceptueel gezien staan deze termen echter wel in relatie tot elkaar. Een associatieve relatie (RT) tussen deze twee termen is dus op zijn plaats. Paarden, Ezels en Muilezels behoren allemaal tot de familie van de Equidae, net als bijvoorbeeld Zebra s. Tussen Paarden en Ezels bestaat er niet direct een verband anders dan hun beider relatie tot een bredere term: Equidae. Echter, voor beiden geldt dat er een relatie bestaat tot de Muilezel, een dier dat een kruising is tussen een paard en een ezel. Beide termen kunnen dus een associatieve relatie aangaan met de term Muilezel. Smartsite Content Management Server 23