Universiteit Gent Faculteit Toegepaste Wetenschappen...

Universiteit Gent

Faculteit Toegepaste Wetenschappen

Vakgroep

Elektronica en Informatiesystemen

Voorzitter: Prof. dr. ir. J. VAN CAMPENHOUT

Classificeren en opzetten van gebruikersvoorkeuren voor zoekrobotten

in het kader van MPEG-21

door

Tim COMBEL

Promotor: Prof. dr. ir. R. VAN DE WALLE

Scriptiebegeleider: Lic. M. MACCARINI

Scriptie ingediend tot het behalen van de academische graad van

licentiaat informatica

Academiejaar 2001-2002

Woord vooraf

Een scriptie schrijven is een moeilijke opdracht. Toch gaf ze mij de kans mijn

interessegebieden uit te breiden. De auteur houdt er dan ook aan op deze plaats zijn dank

hiervoor te betuigen aan zijn promotor, prof. dr. ir. R. Van de Walle. Voor het tot een goed

einde brengen van deze zware taak was de deskundige begeleiding van M. Maccarini van

onschatbare waarde. De vele tik- en taalfouten die tijdens het ijverig werken in dit

afstudeerwerk geslopen waren, werden er even ijverig uitgehaald door de spellingscorrector,

helaas niet altijd met evenveel succes. Mijn ouders wil ik dan ook bedanken voor het nalezen

van de kladversie. Verder wens ik al mijn vrienden en vriendinnen te bedanken voor de

morele steun die ze me de afgelopen maanden en jaren gegeven hebben, alsook voor het delen

van de vele plezierige momenten gedurende deze periode.

``De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen

van de scriptie te kopiëren voor persoonlijk gebruik.

Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met

betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van

resultaten uit deze scriptie.''

31 mei 2002

Tim Combel

Universiteit Gent Faculteit Toegepaste Wetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: Prof. dr. ir. J. VAN CAMPENHOUT Classificeren en opzetten van gebruikersvoorkeuren voor zoekrobotten in het kader van MPEG-21 door Tim COMBEL Promotor: Prof. dr. ir. R. VAN DE WALLE Scriptiebegeleider: Lic. M. MACCARINI Scriptie ingediend tot het behalen van de academische graad van Licentiaat informatica Academiejaar 2001-2002

Samenvatting:

In de onderzoeksgroep multimediatoepassingen van de vakgroep ELIS wordt actief meegewerkt aan één van de belangrijkste wereldwijde standaardisatieactiviteiten in verband met multimediasystemen, namelijk MPEG-21. Door het steeds toenemende aantal digitale objecten is een performant zoeksysteem van cruciaal belang. Om dergelijke zoeksystemen nog performanter te maken, is het aangewezen om de voorkeuren van de gebruiker te kennen en te gebruiken om de zoekruimten te verkleinen. In het kader van dit afstudeerwerk zullen de voorkeuren van de gebruiker geclassificeerd worden en zal er een systeem opgezet worden om die voorkeuren op te slaan op basis van MPEG-technologie. Er zal in het bijzonder aandacht besteed worden aan de declaratie van de nodige multimediaobjecten ("MPEG-21 Digital Item Declaration"), gebruikmakend van XML (eXtensible Markup Language). In deze scriptie wordt nagegaan welke types voorkeuren een gebruiker kan hebben en hoe deze voor te stellen zijn door middel van de keuzestructuren die deel uitmaken van MPEG-21. Er wordt een drielagenmodel opgesteld waarbij een DID omgezet wordt naar objecten. Op deze objecten zijn dan alle bewerkingen op voorkeuren voorzien. Er zal een framework opgezet worden dat de verschillende types voorkeuren zal omvatten en tevens uitbreidbaar blijft voor nieuwe evoluties. Tevens is er aandacht voor de omzetting van de objecten naar een grafische voorstelling. Het model wordt gedemonstreerd aan de hand van een geschreven applicatie in JAVA. Bij de conclusies gaan we dan verder in op de mogelijkheden, toepassingsgebieden en uitbreidingen van deze technologie. Trefwoorden: gebruikersvoorkeuren, MPEG-21, DIDL, zoekrobotten, keuzemethodes

Inhoudsopgave:

Inleiding .................................................................................................................................... 1

Hoofdstuk 1 Probleemstelling en de MPEG-21 benadering ................................................ 3

1.1 Zoekmethodes ................................................................................................................ 3

1.2 MPEG-21 en de DID...................................................................................................... 6

1.2.1 Wat is MPEG-21?.................................................................................................................. 6

1.2.2 Wat is DID? ........................................................................................................................... 8

1.3 Zoeken over het netwerk in het kader van MPEG-21.................................................. 10

Hoofdstuk 2 Classificeren van de gebruikersvoorkeuren .................................................. 16

2.1 Algemene inleiding ...................................................................................................... 16

2.2 Een Voorkeur ............................................................................................................... 18

2.2.1 Conditions............................................................................................................................ 20

2.3 Lijstvoorkeuren ............................................................................................................ 21

2.3.1 SingleSelection .................................................................................................................... 22

2.3.2 MultipleSelection................................................................................................................. 24

2.4 Tekstvoorkeuren........................................................................................................... 25

2.5 Intervalvoorkeuren ....................................................................................................... 28

2.6 Complexe keuzestructuren ........................................................................................... 30

2.7 GebruikersVoorkeuren................................................................................................. 33

Hoofdstuk 3 Maken van de applicatie.................................................................................. 34

3.1 Het parsen..................................................................................................................... 34

3.2 Structuur van het programma....................................................................................... 38

3.3 Gebruik van de applicatie............................................................................................. 44

Hoofdstuk 4 Conclusies en mogelijke uitbreidingen........................................................... 52

4.1 Besluiten....................................................................................................................... 52

4.2 Mogelijke uitbreidingen ............................................................................................... 52

Appendix A: XML ................................................................................................................. 55

XML................................................................................................................................... 55

XML-Schema..................................................................................................................... 56

Namespaces........................................................................................................................ 57

Appendix B: UML.................................................................................................................. 58

Appendix C: Uitgewerkt voorbeeld...................................................................................... 60

De DID ............................................................................................................................... 60

De beslissingsboom en JAVA-objectvorm ........................................................................ 64

Appendix D: Inhoud van de CD-ROM ................................................................................ 67

Referenties .............................................................................................................................. 68

Algemene Bibliografie............................................................................................................ 69

Tabel van afkortingen en symbolen:

API: Application Program Interface

CBR: Case Based Reasoning

DID: Digital Item Declaration, ook gebruikt voor het document beschreven m.b.v DIDL

DIDL: Digital Item Declaration Language

DIDM: Digital Item Declaration Model

DII&D: Digital Item Identification and Declaration

DOM: Document Object Model

DTD: Document Type Definition

GUI: Graphical User Interface

HTML: HyperText Markup Language

I/O: Input/Output

JDK: Java Development Kit

MPEG: Moving Picture Experts Group

MPEG-21: MPEG Standard “framework for multimedia interoperability”

OO: Object Oriented

RDF: Resource Description Framework

SAX: Simple API for XML

UML: Unified Modeling Language

URI: Uniform Resource Identifier

URL: Uniform Resource Locator

W3C: World Wide Web Consortium

WD: Working Draft

WWW: World Wide Web

XML: eXtensible Markup Language

1

Inleiding

“Zoeken is een kwestie van steegjes in te gaan en te merken dat ze doodlopen.”

- Plutarchus (leerling van Pythagoras)

In de onderzoeksgroep multimediatoepassingen van de vakgroep ELIS wordt actief

meegewerkt aan één van de belangrijkste wereldwijde standaardisatieactiviteiten in verband

met multimediasystemen, namelijk MPEG-21. Door het steeds toenemende aantal digitale

objecten is een performant zoeksysteem van cruciaal belang. Om dergelijke zoeksystemen

nog performanter te maken, is het aangewezen om de voorkeuren van de gebruiker te kennen

en te gebruiken om de zoekruimten te verkleinen. In het kader van dit afstudeerwerk zullen de

voorkeuren van de gebruiker geclassificeerd worden en zal er een systeem opgezet worden

om die voorkeuren op te slaan op basis van MPEG-technologie. Er zal in het bijzonder

aandacht besteed worden aan de declaratie van de nodige multimediaobjecten ("MPEG-21

Digital Item Declaration"), gebruikmakend van XML (eXtensible Markup Language).

In het eerste hoofdstuk wordt de probleemstelling helemaal besproken. Eerst worden de

huidige courant gebruikte zoekmethoden uit de doeken gedaan. Daarna worden MPEG-21 en

de DID geïntroduceerd. In de laatste sectie van dit hoofdstuk wordt dan gekeken hoe MPEG-

21 tot betere zoekresultaten kan leiden en gebruik zal maken van gebruikersvoorkeuren. We

krijgen dus een overzicht van de in de literatuurstudie ontdekte problemen en oplossingen, en

de toekomstige evoluties hierin. Voor de definities over MPEG-21 volgen we [1] en het

recentere werk [2].

Het tweede hoofdstuk gaat dan in op de classificatie van gebruikersvoorkeuren. De

noodzakelijke attributen van algemene voorkeuren en gebruikersvoorkeuren worden

vastgelegd en er wordt een algemene classificatie van een aantal basistypes gemaakt. Elk type

wordt besproken aan de hand van zijn specifieke eigenschappen, zijn representatie in een

MPEG-21 DID en zijn mogelijke grafische voorstellingen.

Een zelfgeschreven applicatie zal dan de theorie in praktijk omzetten. In deze applicatie

zullen gebruikersvoorkeuren in- en uitgevoerd, aangepast en getoond worden. Hoofdstuk drie

zal de werking en het gebruik van deze applicatie tonen.

We ronden af met de conclusies, verder werk en uitbreidingen.

2

We vermelden alvast dat er een CD-ROM voorhanden is, die zowel het werkende programma

als alle documentatie en code bevat. Voor het schrijven van de applicatie werd gebruik

gemaakt van JAVA (JDK1.4.0). De tekst werd geschreven met Microsoft Word 2002. Gezien

dit onderzoek op een internationaal niveau gebeurt, zullen Nederlandstalige en Engelstalige

termen door elkaar gebruikt worden. De twee termen zullen bij introductie wel steeds vermeld

worden.

De naamgeving van variabelen, klassen en functies is zoveel mogelijk gebaseerd op de

“Netscape's software coding standards guide for JAVA” [3], een veelgebruikte

programmeerstijl voor JAVA. Wanneer we het in deze tekst zullen hebben over objecten,

zullen de namen beginnen met een hoofdletter. Verder dient vermeld dat “hij” doorheen de

tekst vanzelfsprekend ook als “zij” gelezen kan worden.

3

Hoofdstuk 1 Probleemstelling en de MPEG-21 benadering

“Knowledge is of two kinds. We know a subject ourselves, or we know where we can

find information upon it.”

- Samuel Johnson

1.1 Zoekmethodes

Vooraleer te beginnen met een classificatie van gebruikersvoorkeuren is het belangrijk een

goed beeld te hebben van de gebruikte zoekmethodes en hun specifieke eigenschappen. Op

die manier wordt het duidelijk waarom we moeten streven naar verbeteringen, zowel langs de

kant van de gebruikers als vanuit het standpunt van de producenten van data. We zullen de

methoden vergelijken m.b.v. twee factoren: "productie-efficiëntie" en "gebruikersefficiëntie".

De Engelse termen hiervoor zijn “externalisation efficiency” en “internalisation efficiency”.

Productie-efficiëntie staat voor het gemak waarmee de producent van data nieuwe

documenten kan toevoegen aan het zoeksysteem. Gebruikersefficiëntie geeft aan in welke

mate een zoeker de gewenste informatie zal terugvinden. In Figuur 1 uit [4] zien we de

verschillende soorten zoekmethodes en hun respectievelijke efficiëntie.

Figuur 1 Productie efficiëntie en gebruikersefficiëntie

Wanneer we nu naar informatie zoeken met zoekrobotten, kunnen we vier veel voorkomende

methodes terugvinden. De meest gebruikte is de "full text search". Deze bestaat erin een

zoekterm op te geven waar de zoekrobot zal zoeken. De ingegeven zoekterm is hier steeds een

4

tekst, een string. De gevonden informatie is dan afkomstig uit string-matching tussen de

zoektermen en de inhoud van een bepaalde pagina. Deze methode wordt bij de meeste

zoekrobotten gebruikt (Yahoo!, Lycos, ...). Voor de maker van multimedia is dit een

uitstekende methode aangezien zijn werk tot een minimum herleid is. Het enige wat de

producent hoeft te doen is zijn werk beschikbaar stellen op het WWW en eventueel kenbaar

maken aan één of meerdere zoekrobotten. De verdere classificatie is gemakkelijk

automatiseerbaar en wordt gedaan door robotten zelf. Deze classificatie wordt gedaan op basis

van in de tekst voorkomende kernwoorden. Dit systeem heeft dus een grote productie-

efficiëntie, gezien de producent het classificeren kan overlaten aan robotten. Precies dit is het

grote probleem van full text search: het systeem is maar zo goed als de implementatie van zijn

classificatieroutine. De robotten blijken niet in staat een goede classificatie door te voeren op

basis van tekst alleen. Anders gezegd: de robotten zijn niet in staat een semantiek, een

betekenis, te geven aan een document. Dit resulteert in een lage gebruikersefficiëntie. De

gebruiker, de zoeker naar specifieke informatie, heeft grote problemen om deze te vinden.

Aangezien deze methode enkel aan matching van woorden doet, verschijnen er veel resultaten

die niet beoogd werden. Het is ook bijna onmogelijk om op een doorgedreven manier te

zoeken naar niet - tekstobjecten. Het toelaten van Booleaanse uitdrukkingen verbetert de

resultaten minimaal, maar vergroot de input query en wordt op die manier door de gebruikers

dikwijls als tijdrovend ervaren.

Hypertextsearch is een tweede methode. Deze wordt bijvoorbeeld gebruikt in het web

directory systeem van Yahoo!. De zoekmethode bestaat erin op een centrale plaats te

beginnen. Door het gebruik van hyperlinks kan men steeds weer niveaus dieper in de

zoekstructuur afdalen (en dus dichter bij het zoekresultaat). De maker moet hier zelf beslissen

tot welke categorie(ën) zijn werk behoort. Deze methode levert betere zoekresultaten op, op

voorwaarde dat de gebruiker weet waarnaar te zoeken. Indien de zoekterm verschillende

domeinen beslaat blijft het voor de gebruiker moeilijk om goede resultaten te bekomen. De

hoge kost voor producenten om zelf een classificatie te bepalen maakt deze methode zelfs

minder interessant dan full text search. Bij de meeste hedendaagse zoekrobotten is het

mogelijk zowel informatie te zoeken via full text search als via hypertextsearch, of zelfs

meestal een combinatie van de twee. Op de beschikbare data wordt dan eerst een full text

search verricht. Op basis van deze set resultaten kan men dan opnieuw de beslissingsboom

aanmaken om hierop een hypertextsearch uit te voeren.

5

Wat hypertextsearch betreft is er een uniforme classificatiemethode nodig. Een project dat

hierbij enige aandacht verdient is ODP of Open Directory Project. ODP is een open source

project waarin een classificatie gemaakt is van het Internet. Deze classificatie werd door

mensen gemaakt en gecodeerd in RDF, een XML-taal. Wiskundige modellen tonen aan dat

een dergelijke classificatie voorgesteld kan worden door een graafstructuur. Wanneer men de

terugkerende takken, die lussen veroorzaken, hieruit verwijdert, kan men deze structuur

beperken tot amper tien niveaus! In praktijk zal het aantal niveaus hoger liggen. Hiermee

moet zeker rekening gehouden worden bij het opstellen van gebruikersvoorkeuren voor

zoekrobotten. Men mag hierbij de beslissingsboom dan ook niet dieper maken, wel

integendeel. ODP is momenteel wellicht de beste classificatie van het Internet die beschikbaar

is. Het grote nadeel is opnieuw dat in principe alle documenten van het Internet manueel

toegevoegd moeten worden aan dit systeem. OPD brengt ons ook enkel een subjectieve

classificatie van het net: enkel onderwerpen en interessegebieden worden gecatalogeerd. Een

objectief classificatiesysteem (bijvoorbeeld op basis van de bestandstypes, groottes of

producenten van documenten) bestaat niet.

Case Based Reasoning (CBR) is een techniek die vaak toegepast wordt bij helpdesksituaties.

Voorbeelden hiervan zijn de helpfuncties bij de klassieke Windows toepassingen

(bijvoorbeeld Office Assistant). De gebruiker heeft een probleem en door middel van vraag en

antwoord komt hij dichter bij de oplossing voor zijn probleem. Deze methode blijkt zeer

efficiënt in probleemsituaties. Op voorwaarde dat de classificatie correct gedaan werd, zal het

systeem steeds relevante antwoorden produceren en ten slotte alle gezochte documenten

tonen. Het grote probleem is echter de lage productie-efficiëntie. Documenten worden

beschreven aan de hand van een formele specificatie van de mogelijke probleemgebieden. De

inhoud van de documenten zelf wordt niet geclassificeerd. De maker van objecten moet voor

elk mogelijk probleem of invalshoek van de zoeker een aparte case gaan ontwikkelen. Bij het

updaten van een bestaand systeem ontstaan dikwijls nieuwe situaties die elk ook weer

opnieuw in het oude systeem moeten worden ingebracht. Dit is met andere woorden een zeer

arbeidsintensief en duur systeem en daarom niet op grote schaal (zoekrobotten op het Internet)

bruikbaar.

Metadata based search is de meest recente van de vier zoekmethodes. Hierbij zal men aan

documenten (tekst of andere multimedia) zogenaamde metadata toevoegen. Metadata zijn

data over data. Dit kan de naam van de auteur zijn, maar ook de taal van het document, een

6

beschrijving van een frame uit een film, een categorie, ... Dit systeem kan zeer gedetailleerd

gemaakt worden en bijgevolg ook goede zoekresultaten produceren. Het feit dat de metadata

niet beperkt hoeft te zijn, zorgt ervoor dat een classificatie oneindig fijn kan gemaakt worden

en dus ook de beste zoekresultaten zal weergeven. Het grote nadeel van deze methode is de

moeilijkheid om metadata classificatie te automatiseren. Nu gebeurt dit bijna altijd manueel

door mensen die de documenten eerst moeten bekijken en dan subjectief een keuze maken

voor een bepaalde categorie. Metadata search heeft dus de hoogste gebruikersefficiëntie,

maar, gezien het vele werk voor het invoeren van de beschrijvingen, een lage productie-

efficiëntie.

Deze scriptie zal zich focussen op het standpunt van de gebruiker. Het is de bedoeling de

metadata methode voor de gebruiker te vergemakkelijken: nu wordt van de gebruiker

verwacht dat hij nog steeds alle zoektermen opgeeft. Deze zoektermen dienen dan gevonden

te worden in de data en/of metadata van een document. Ondanks het feit dat de gebruiker

betere zoekresultaten terugkrijgt, ervaart hij het zoeken zelf nog steeds als even omslachtig als

bij de full text search. In deze scriptie wordt een methode besproken om op voorhand enkele

voorkeuren vast te leggen en deze steeds bij elke zoekopdracht te gebruiken.

1.2 MPEG-21 en de DID

Dit afstudeerwerk is uitgeschreven in het kader van het MPEG-21 onderzoek dat aan deze

universiteit plaatsvindt. Om de gebruikersvoorkeuren op te slaan zal gebruik gemaakt worden

van MPEG-21 DID's.

1.2.1 Wat is MPEG-21?

MPEG-21 is een multimedia framework dat op een transparante manier het gebruik van

multimedia resources (tekst, audio, video, stilstaande beelden, enz.) over verschillende

netwerken (Internet, draadloos, breedband, enz.) en devices (van geavanceerde

multimediawerkstations tot GSM) moet toelaten. Op dit moment zijn een waaier van

modellen, procedures, protocollen en bestandsformaten in gebruik voor het verspreiden,

bekijken en verwerken van multimedia. Wanneer verschillende gemeenschappen met elkaar

communiceren, leidt dit dikwijls tot conflicten: wat bijvoorbeeld voor het ene systeem een

standaard bestandsformaat is, blijkt niet te bestaan onder een ander systeem. Het is de

bedoeling van MPEG-21 een framework op te stellen dat de sleutelelementen nodig voor

creatie, productie, distributie en consumptie van multimedia identificeert en beschrijft.

7

MPEG-21 werd opgesplitst in 7 onderdelen:

• Digital Item Declaration: een uniforme en flexibele abstractie van Digitale Items.

• Digital Item Identification and Description: zorgt voor identificatie en beschrijving

van Digitale Items.

• Content Handling and Usage: concentreert zich op de inhoud. Er worden interfaces

en protocollen voorzien voor creatie, manipulatie, zoeken, bewaren, enz. van de

inhoud van Digitale Items. Dit kan zowel op gebied van multimediadata als op gebied

van metadata zijn.

• Intellectual Property Management and Production: behandelt de rechten op de

Items.

• Terminals and Networks: het netwerkaspect van MPEG-21: het opzetten van

gebruikersgemeenschappen of communities waarbinnen multimedia aangemaakt en

uitgewisseld kan worden, binnen een betrouwbaar en flexibel netwerksysteem.

• Content Representation: zorgt voor de uiteindelijke technologie voor het tonen van

de inhoud van Digitale Items.

• Event Reporting: interfaces voor het beschrijven van unieke events binnen MPEG-

21. Dit stuk encapsuleert de zes voorgaande.

In de vorige beschrijving van de zeven onderdelen van MPEG-21 wordt vaak de term Digitaal

Item of "Digital Item" gebruikt. Een Digitaal Item is de standaardrepresentatie van een

intellectueel werk. Een Digitaal Item kan een structuur bezitten: bv. de inhoud is afhankelijk

van eigenschappen van andere Digitale Items. Verder bezit een Digitaal Item natuurlijk ook

inhoud (audio, tekst, foto, beeld, …) en de hiermee geassocieerde informatie (beschrijvingen,

gebruiksregels en –rechten) kunnen afhankelijk gemaakt worden. Het is belangrijk duidelijk

te maken dat een Digitaal Item niet de fysische vorm van het werk is (een foto, een boek,…),

maar dat een Digitaal Item het werk zal beschrijven en zal verwijzen naar zijn fysieke vorm in

al zijn gedaantes. Digitale Items zijn dus digitale objecten die naast gestructureerde digitale

objecten ook een standaard representatie, identificatie en metadata bevatten. Digitale Items

vormen de basiseenheid voor alle transacties en distributies binnen MPEG-21.

Een klassiek voorbeeld van een Digitaal Item is een digitaal fotoalbum. Dit bevat naast foto’s

ook tekst, geluidscommentaar of zelfs videofilmpjes. Dit alles geïntegreerd in één enkel

navigeerbaar systeem, aangepast aan de voorkeuren van de gebruiker. Het Digitaal Item is dan

8

het geheel hiervan dat alle multimedia beschrijft en aan elkaar koppelt. De gebruiker zal dan

enkel kennis maken met dit Digitaal Item, welke multimedia in welke formaten dan ook

hierachter zitten, blijft voor hem verborgen.

Verder dient ook nog gezegd dat MPEG-21 geen onderscheid maakt tussen de producent en

de consument van multimedia. Beiden worden door het systeem aanzien als gebruikers of

“Users”.

Figuur 2 De zeven onderdelen van MPEG-21

1.2.2 Wat is DID?

Zoals eerder gezegd is de DID of Digital Item Declaration het eerste en meeste vergevorderde

onderdeel van MPEG-21. Om een Digitaal Item te beschrijven zullen we gebruik maken van

de Digital Item Declaration Language of kortweg DIDL. DIDL is een taal gebaseerd op een

speciaal hiervoor ontwikkeld XML schema. In het verdere verloop zal ook het XML-

document, beschreven met behulp van DIDL, een DID genoemd worden. Er werd bij het

maken van de applicatie en het schrijven van dit document steeds uitgegaan van de DIDL

syntax uit [2]. De DIDL zorgt enkel voor de beschrijving van bronnen zonder deze zelf te

9

bevatten. In de DID kunnen echter wel verwijzingen (referenties) staan naar de plaats waar de

resources te vinden zijn. Het gevolg hiervan is dat enkel de DID naar de gebruikers gestuurd

moet worden om ze te laten kiezen uit verschillende resources.

De DIDL is gebaseerd op het Digital Item Declaration Model (DIDM) dat ook in [1] en [2]

wordt besproken. DIDM levert een algemeen model om Digitale Items te beschrijven. We

zullen de belangrijkste elementen voor dit werk kort samenvatten:

• Container: een structuur die toelaat Items en/of andere Containers te groeperen.

• Item: een groepering van Items of componenten. Items kunnen beschreven worden

met Descriptors en voorwaarden opgelegd worden d.m.v. Conditions.

• Component: bevat een verwijzing naar de eigenlijke Resource, alsook zijn

Descriptions en Conditions.

• Descriptor: voegt informatie toe aan het element waartoe het behoort. Deze

informatie kan een Statement of Component zijn.

• Condition: legt een voorwaarde op aan het element waartoe het behoort.

• Choice: beschrijft een set van Selections en stelt zo een keuze voor. Een Choice bevat

ook Descriptions en Conditions. De Selections binnen een Choice zijn ofwel exclusief

(kies één keuzeoptie), ofwel inclusief (kies een aantal keuzeopties, allemaal of geen

enkel zijn hierbij ook toegelaten)

• Selection: kan gezien worden als een keuzeoptie, opnieuw voorzien van Descriptions

en Conditions.

• Resource: een verwijzing naar het eigenlijke fysieke multimediaobject.

• Statement: een tekstuele waarde die informatie bevat.

Al deze sleutelwoorden hebben hun eigen voorstelling binnen de DIDL.

Voor het verdere vervolg is het ook nog belangrijk een klein woordje te zeggen over het

tweede en derde onderdeel van MPEG-21. De eigenlijke uitwerking van deze scriptie is

beperkt tot de DID, maar om het algemene kader duidelijk te maken moeten hierin ook de

twee volgende stappen betrokken worden.

Digital Item Identification and Description (DII&D) moet zorgen voor de unieke beschrijving

en identificatie van Digitale Items. Tevens zorgt het voor nauwere koppelingen tussen de

identificatie en beschrijving enerzijds en de eigenlijke inhoud anderzijds. DII&D zal gebruik

10

maken van de structuur aangeboden door de DID. In de DID is het mogelijk om metadata toe

te voegen om een Item of een Resource te beschrijven. Deze beschrijving vindt plaats in de

Descriptors. De identificatie zal dus gebeuren op basis van Descriptors die gedefinieerd zijn

a.d.h.v. DII&D.

Content Handling and Usage (CHU) zal tenslotte zorgen voor de bewerkingen op en met de

Digitale Items: zoeken, plaatsen, verspreiden, gebruiken, editeren, etc. CHU kan opnieuw

zowel op het niveau van de eigenlijke resource plaatsvinden als op dat van de metadata. Een

belangrijk aspect van CHU is het gebruiken en verwerken van gebruikersvoorkeuren. Deze

voorkeuren zitten vervat in de Choice elementen uit de DID. In CHU zullen methodes

ontwikkeld worden die uitgaande van de gemaakte keuzes, de juiste Resource zullen zoeken.

1.3 Zoeken over het netwerk in het kader van MPEG-21

Nu MPEG-21 en de DID gedefinieerd zijn, zal in deze sectie uitgelegd worden hoe DIDs

gebruikt kunnen worden om tot betere zoekresultaten te leiden.

Om tot correcte zoekresultaten te komen, zonder dat daarbij niet-relevante oplossingen

worden aangeboden, is het van cruciaal belang de zoekruimte te verkleinen. De gebruiker kan

dit doen door het invullen van een aantal gebruikersvoorkeuren. Er is voor gekozen om de

gebruikersvoorkeuren zelf voor te stellen als een MPEG-21 DID. Deze DID bevat dan één

Item namelijk de gebruikersvoorkeuren zelf. Dit Item zal vervolgens bestaan uit een

onbepaald aantal keuzes. Door het invullen van deze keuzes kan de gebruiker zelf zijn profiel

bepalen. Merk op dat deze DID met gebruikersvoorkeuren geen Resources zal bevatten, enkel

keuzes en keuzeopties. De DID leent zich uitstekend tot het definiëren en instellen van de

gebruikersvoorkeuren. Door de specifieke structuur is het onmiddellijk mogelijk keuzes en

keuzeopties voor te stellen. Via Descriptors kunnen we ook minder voor de hand liggende

keuzes aanbieden. Zo is het mogelijk een ander protocol, dat ook met voorkeuren werkt, te

encapsuleren binnen een DID. Dit alles zal gedemonstreerd worden in het volgende

hoofdstuk.

Eens de gebruiker zijn voorkeuren kenbaar gemaakt heeft, kunnen deze opnieuw opgeslagen

worden in een DID. Het definiëren van de voorkeuren is dus in principe slechts een éénmalig

proces en kan bijvoorbeeld al uitgevoerd worden bij het installeren van het besturingssysteem.

Uiteraard zijn de voorkeuren achteraf nog steeds aanpasbaar.

11

Meteen na het bewaren van de voorkeuren, zijn deze klaar voor gebruik. Talrijke toepassingen

zijn nu denkbaar: installatie van clipart in het gewenste formaat, viewers voor de aangegeven

beeldformaten, aanpassen van desktop thema’s aan de hand van opgegeven interesses,… De

interessantste mogelijkheden zijn te vinden op het web: levering van nieuws over

gedefinieerde interessegebieden, niet hoeven te kiezen in welk beeldformaat je een foto of

video wilt bekijken en natuurlijk ook beter zoeken!

Laten we nu het geval van de zoekrobotten iets dieper uitspitten. De gebruiker stelt zoals

steeds zijn traditionele query op. Deze wordt verzonden naar de zoekrobot. Met de huidige

technieken zou hierop dan een full text search of metadata search (of een combinatie van

beiden) uitgevoerd worden. Het gebruik van de DID met zoekvoorkeuren zal de resultaten

echter verbeteren. Het in onderstaande figuur getoonde model van de Inquirus2 zoekrobot

([5]-[8]) kan hiervoor gebruikt worden.

Figuur 3 Combineren van zoekquery met voorkeuren

De DID wordt gecombineerd met de zoekopdracht, dit geeft aanleiding tot een nieuwe, meer

uitgebreide zoekopdracht die gebruikt kan worden bij het zoeken. Het zoeken en ophalen van

de pagina’s zal nog steeds op dezelfde wijze verlopen als bij de huidige generatie

zoekrobotten. Het grootste verschil, wat betreft multimedia, is dat men niet langer op zoek zal

gaan naar de echte resources, maar dat men enkel DIDs hoeft te zoeken. In deze DIDs zullen

immers de nodige verschillende componenten zitten, die afhankelijk van gemaakte keuzes tot

12

het zoekresultaat zullen behoren. De zoekrobotten sturen dus de referenties van DIDs terug.

De resultaten worden dan nog een tweede keer gematcht met de gebruikersvoorkeuren. Dit is

nodig omwille van twee redenen: ten eerste mogen enkel deze componenten van de

teruggegeven DIDs getoond worden die voldoen aan de voorkeuren. Een teruggegeven DID

kan immers ook nog andere componenten bevatten die niet voldoen aan de voorkeuren. Ten

tweede kan de nieuwe vergelijking als extra controle en ordening gebruikt worden. Het

combineren van de zoekopdracht met de gebruikersvoorkeuren en het hieruit destilleren van

betere zoekresultaten valt binnen het MPEG-21 onderdeel CHU. De set resultaten zal

uiteindelijk bestaan uit een ordening van verwijzingen naar de eigenlijke Resources.

We geven hier voor de duidelijkheid een klein voorbeeld over hoe we "zoeken met

gebruikersvoorkeuren" moeten interpreteren. Stel de gebruiker van een zoekrobot is op zoek

naar informatie over "jaguar". "Jaguar" heeft echter meerdere betekenissen: het is een dier,

een automerk, een F1-team, een de Atari spelcomputer, het kan de bijnaam van iets of iemand

zijn, ... Iemand die "jaguar" intikt in een zoekrobot op Internet wordt dus bedolven onder de

informatie en meestal niet die informatie waarnaar hij op zoek was. We kunnen nu alle

gevonden resultaten voorstellen door een n-dimensionale ruimte. De grootte van n zal

afhangen van het aantal gebruikte voorkeuren. Elke voorkeur stelt hierin dan een as voor.

Wanneer we stellen dat de gebruiker twee voorkeuren ingegeven heeft, kunnen de resultaten

in een vlak voorgesteld worden. Stel dat die voorkeuren taal (Nederlands) en interesse (auto)

zijn, dan wil dit zeggen dat de gebruiker liefst Nederlandstalige documenten terugkrijgt van

de zoekrobot. Wanneer deze documenten gaan over auto’s, dan worden deze als belangrijker

aanzien. Als men op zoek is naar een foto kan dit bijvoorbeeld Nederlandstalige metadata

zijn. Alle Nederlandstalige documenten zullen dan terug te vinden zijn in één band van het

vlak, alle documenten over auto's zullen ook in eenzelfde band zitten, zoals voorgesteld in

Figuur 4. De zoekresultaten die aan de voorkeuren van de gebruiker voldoen hoeven dus in

principe enkel in de doorsnede van die twee banden gezocht te worden. Dit levert dus een

forse inkrimping van de zoekruimte op! Dit systeem is natuurlijk ook uitbreidbaar naar

meerdere voorkeuren, die de ruimte nog meer zullen opsplitsen.

Bij deze werkwijze moeten nu enkele cruciale opmerkingen gemaakt worden. Vooreerst moet

het duidelijk zijn dat zowel gebruikersvoorkeuren als de beschikbaar gestelde DID’s op elkaar

afgestemd moeten zijn. Dit wil zeggen dat er duidelijk afspraken gemaakt moeten worden

over de beschikbare voorkeuren en keuzeopties. Op gebied van eerder technische voorkeuren

13

als favoriete beeldformaat, gebruikte besturingssysteem, gebruikte schermresolutie mag dit

geen problemen opleveren. Naar de gebruiker toe kunnen al deze keuzes en keuzeopties in

hun respectievelijke taal of voorstelling weergegeven worden (de Descriptor zorgt hiervoor

binnen een DID), intern moet dan eenzelfde code gebruikt worden, d.w.z. de intern gebruikte

naamgeving moet overal ter wereld dezelfde zijn. Bij eerder subjectieve voorkeuren

(interessegebieden, persoonlijke gegevens,…) kan dit moeilijker zijn, het eerder besproken

ODP kan hierin een oplossing bieden.

Figuur 4 N-dimensionale voorstelling van voorkeuren (N=2)

Een tweede punt is de plaats waar de DID met voorkeuren moet gestockeerd worden. Zowel

aan cliënt- als aan serverzijde biedt dit interessante mogelijkheden. De clientzijde heeft het

grote voordeel dat de DID met voorkeuren quasi onmiddellijk bruikbaar is. Indien we de DID

aanmaken tijdens de installatie van een besturingssysteem, kan deze dienen voor het

onderscheiden van installatieprofielen. Ook andere software kan dan van de DID

gebruikmaken. Wanneer we nu naar het zoeken op het Internet kijken, zien we dat een lokaal

bewaarde DID steeds zal moeten meegestuurd worden bij elke zoekopdracht. Hoewel het hier

uiteindelijk maar om kleine tekstbestanden zal gaan, veroorzaakt dit toch een onnodige

verkeersstroom. Een schematische voorstelling hiervan is te vinden op Figuur 5.

De meeste toepassingen van de voorkeurDID liggen ontegensprekelijk op het net. Daarom

ware het interessant om meteen de DID op het net te stockeren. We stellen ons hierbij dan één

centraal of gedistribueerd systeem voor. Wanneer nu een zoekopdracht wordt gelanceerd, zal

de gebruiker zijn query en een identificatie doorsturen. De zoekrobot zal dan het centrale

systeem raadplegen om de voorkeuren terug te vinden. Is de DID nodig op de computer van

14

de gebruiker zelf, dan wordt deze gedownload. We kunnen natuurlijk ook een lokale kopie,

gesynchroniseerd met de netwerkversie, bijhouden. Hierdoor kunnen we ook gebruik maken

van de pluspunten van bewaring aan cliëntzijde. Nog een bijkomend voordeel van bewaring

aan serverzijde is dat de gebruiker overal ter wereld zijn zelfde voorkeuren kan gebruiken.

Serverzijde zou ook ideaal zijn wat betreft de distributie van DIDs: op deze manier kan men

een methode bedenken waarbij iedereen steeds over de laatste versie van de voorkeurDID

beschikt. Serverside brengt echter wel grote risico’s met zich mee wat betreft security en

privacy. Tevens willen we ook opmerken dat om dit project te doen slagen, de medewerking

van iedere betrokkene vereist is. Hiermee wordt bedoeld dat alle beelden geluidsformaten

beschikbaar moeten zijn, dat de zoekrobotten ook daadwerkelijk dezelfde voorkeuren zullen

moeten gebruiken en bijvoorbeeld niet elk een eigen versie ter beschikking stellen, enz.

De werkwijze van Amazon.com is hierbij een interessant voorbeeld. De lay-out en taal van

deze online boekenwinkel worden opgeslagen in cookies Deze bewaringsmethode is in onze

situatie uiteraard niet interessant. De profielen van de klant worden bij Amazon op een

andere, veel betere manier bewaard. De producten die de klant gekocht heeft (en bijgevolg het

koopgedrag en de interessesfeer) worden bijgehouden in een databanksysteem. Om een

product te kopen moet de klant eerst inloggen met een login en paswoord. Met deze unieke

combinatie wordt een geserialiseerd sessieobject opgehaald uit de databank. De gebruiker

doet zijn verrichtingen op dit object. Na afloop wordt het aangepaste sessieobject terug

geserialiseerd weggeschreven in een databank. Een dergelijke databank beslaat dan natuurlijk

wel terabytes aan gegevens. Zowel technisch als logisch zijn dit zeer complexe

bedrijfsprocessen waar we nu niet zullen op ingaan. Het is wel van belang te zeggen dat

intelligente algoritmes uit het koopgedrag een profiel van de klanten kunnen opstellen om

deze dan later, voor hem, relevante reclamebanners of promoties te laten zien. Andere externe

sites die samenwerken met Amazon maken hier ook gebruik van en voorkomen zo dat de

gebruiker ook bij hen een apart profiel moet samenstellen. Deze manier van werken is ook

toepasbaar op het opslaan van voorkeuren en het gebruik ervan door zoekrobotten.

15

Figuur 5 Schematische voorstelling van het zoeken met behulp van voorkeuren

16

Hoofdstuk 2 Classificeren van de gebruikersvoorkeuren

“Who controls the vocabulary, controls the knowledge.”

- George Orwell

2.1 Algemene inleiding

In het vorige hoofdstuk werd ruim beschreven in welk algemeen kader we dit onderzoek

moeten situeren. In dit en volgende hoofdstukken zal hiervan dan verder één aspect behandeld

worden. We hebben uitgelegd hoe het zoeken met behulp van gebruikersvoorkeuren in zijn

werk kan gaan. De zoekopdracht combineren met de gebruikersvoorkeuren en hieruit betere

zoekresultaten afleiden valt binnen MPEG-21 onder Content Handling and Usage. Dit

document zal zich verder focussen op de eerste stap in het proces namelijk het opstellen van

een DID waarin de voorkeuren van de gebruikers vervat zitten. Deze stap valt binnen de

eerste fase van MPEG-21: Digital Item Declaration. Hiertoe zal eerst een algemene

classificatie van de voorkeuren en keuzemethodes gemaakt worden.

Omwille van demonstratiedoeleinden was het aangewezen hiervan een applicatie te maken.

Dit JAVA-programma zal aantonen hoe we de verschillende types voorkeuren kunnen

voorstellen binnen een DID. Om ook bewerkingen op deze DID te kunnen uitvoeren is

gekozen voor een mapping van de DID naar een JAVA-objectstructuur, die eveneens

voorkeuren zal voorstellen. Om ten slotte ook het geheel aanschouwelijk te maken werden

deze JAVA-objecten omgezet naar herkenbare JAVA-SWING panelen. De GUI zal gebruikt

worden om wijzigingen op de Voorkeuren door te voeren. Deze wijzigingen maken gebruik

van de JAVA-objecten en de daarop gedefinieerde bewerkingen. Is de gebruiker klaar met het

invullen of aanpassen van de gebruikersvoorkeuren, dan kunnen de JAVA-objecten terug

omgezet worden in een XML-document. Deze werkwijze heeft enkele belangrijke voordelen.

De verschillende types voorkeuren en keuzemethodes blijven normaal gezien constant. We

kunnen dus een model van JAVA-objecten opbouwen dat aan alle eisen voldoet. Indien zich

nieuwe keuzetypes aandienen, kunnen deze zonder problemen in het bestaande model

ingevoegd worden. Ook de omzetting van de objecten naar een grafische representatie is niet

onderhevig aan veranderingen. Wil men nu meerdere presentatiemogelijkheden voor een

zelfde type voorkeur invoeren, dan is dit geen enkel probleem: ze kunnen ook gewoon

toegevoegd worden aan de bestaande representaties. Het grote voordeel is dat de grafische

voorstelling onafhankelijk is van de DID. Gezien MPEG-21 eigenlijk nog in volle

17

ontwikkeling is, bestaat de kans dat de gebruikte standaard zoals in [2] nog aan veranderingen

onderhevig is. Dit “drielagenmodel” speelt hierop in door de tekstuele representatie in XML

los te koppelen van de grafische voorstelling. Indien de standaard daadwerkelijk nog

gewijzigd zou worden volstaat het enkel het parsingsalgoritme te herschrijven. Dan kan

opnieuw gebruik gemaakt worden van dezelfde JAVA-objecten. In Figuur 6 wordt dit nog

eens schematische beschreven.

Figuur 6 Schematische voorstelling van de verschillende lagen binnen de applicatie

Het volgende hoofdstuk zal dan voornamelijk ingaan op de verschillende aspecten van de

eigenlijke implementatie (parsen, structuur en gebruik). Dit hoofdstuk zal zich meer richten

tot het definiëren van de verschillende voorkeuren, hun voorstellingswijze in een DID en

mogelijke grafische weergaven. Tevens wordt hun voorstelling als JAVA-object gegeven, met

speciale aandacht voor de noodzakelijke attributen en bewerkingen. Systematisch zal de

voorstelling van een tekstgebaseerde in- en uitvoer gegeven worden. De voorstelling van een

grafische voorstelling zal gebeuren aan de hand van de in JAVA-SWING courant gebruikte

structuren. In de demo applicatie zal steeds één van deze laatste voorstellingen worden

gebruikt.

De keuze van JAVA als programmeertaal is ingegeven door het feit dat het binnen deze

objectgeoriënteerde taal relatief eenvoudig is zich meester te maken over nieuwe technieken

en modules. Voor deze applicatie waren dat in het bijzonder het werken met XML (inlezen,

parsen, interpreteren en uitschrijven) en het maken van grafische toepassingen (GUI). Gezien

het groeiende belang van deze programmeertaal in het bedrijfsleven en het beperkte contact

dat we hiermee gehad hebben in onze opleiding, leek dit een uitstekende gelegenheid om

hierover kennis op te doen.

18

Bij het modelleren van de verschillende objecten (=keuzetypes) zal gebruik gemaakt worden

van UML. Een korte uitleg over UML is te vinden in Appendix A. Er zullen ook korte

voorbeelden in de DID-vorm gegeven worden, hiervoor is een Appendix B voorzien die meer

uitleg geeft over de basisprincipes van XML.

2.2 Een Voorkeur

Het is uiteraard nodig allereerst te specifiëren wat een voorkeur precies is. Wel, het Van Dale

woordenboek definieert “voorkeur” als “het verkiezen van het één boven het andere”. Hieruit

kunnen we twee belangrijke zaken afleiden: een voorkeur moet een keuze bevatten en die

keuze moet meerdere keuzeopties aanbieden.

Figuur 7 UML voorstelling van de klasse Preference

We vertrekken echter bij het begin: een Voorkeur of Preference bezit een unieke naam

(name). Deze naam zal vooral intern binnen de applicatie gebruikt worden, voor het contact

met de gebruikers zal een beschrijving (description) voorzien worden. Indien geen

beschrijving aanwezig is, dient men de naam te gebruiken. Zoals gezegd bevat de Voorkeur

een keuze (choice) en keuzeopties (options) Beide variabelen zijn lijsten. In de lijst choice

zullen de door de gebruiker gekozen opties bewaard worden.

De opties en keuzes hoeven echter niet noodzakelijk ingevuld te zijn. Een voorbeeld hiervan

aan de hand van twee vaak voorkomende keuzes:

• “Kies ja of nee”: in dit geval zijn de keuzeopties “ja” en “nee”. De gemaakte keuze

kan dan enkel “niets”, “ja”, “nee” of “ja en nee” bevatten, naargelang hoeveel keuzes

gemaakt kunnen of moeten worden.

19

• “Geef uw favoriete boek”. Dit kan een lijst met een aantal boeken zijn, maar kan ook

onbepaald zijn. De gebruiker wordt dan geacht zelf de naam van een boek in te tikken:

de lijst van keuzeopties is leeg, als keuze mag eender wat opgegeven worden.

We gaven het al even aan: er is nood aan duidelijkheid hoeveel keuzes gemaakt kunnen

worden. Hiervoor voeren we de attributen maxSelection en minSelection in. Zij bepalen

het minimum en maximum aantal keuzes (uit de lijst opties) die gemaakt mogen worden.

Wanneer dit aantal niet vooraf is vastgelegd worden hun waarden geïnitialiseerd op “-1”. De

keuzeopties bevatten trouwens dezelfde kenmerken als een keuze: ze hebben een eigen unieke

interne naam die in een lijst options zal bewaard worden en een eigen optionele beschrijving

(optionDescription). Tevens werd ook een attribuut optionShowed voorzien, dit zal een

lijst zijn waarin de huidige status van de keuzeopties weergegeven zal worden (d.w.z. of ze

actief zijn of niet). Dit attribuut is niet noodzakelijk, aangezien het steeds berekend kan

worden. De aanwezigheid ervan verhoogt echter wel de performantie (rechtstreekse toegang

tegenover een reeks berekeningen). Al deze attributen zijn protected, dit wil zeggen dat ze

enkel toegankelijk zijn vanuit objecten van deze klasse of vanuit overervende klassen.

Deze attributen moeten volstaan om met algemene voorkeuren te kunnen werken. Hoe stellen

we een algemene voorkeur dan voor binnen een DID? Binnen DIDM zijn analoge

modelelementen vastgelegd: Choice en Selection (zie 1.2.2), hun representatie binnen DIDL

is als volgt (XML-Schema):

<xsd:element name="Choice"> <xsd:complexType> <xsd:sequence> <xsd:element ref="Condition" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="Descriptor" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="Selection" maxOccurs="unbounded"/> <xsd:element ref="Override" minOccurs="0" maxOccurs = "unbounded"/> </xsd:sequence> <xsd:attribute name="minSelections" type="xsd:nonNegativeInteger"/> <xsd:attribute name="maxSelections" type="xsd:nonNegativeInteger"/> <xsd:attribute name="default" type="xsd:IDREFS"/> <xsd:attribute name="choice_id" type="xsd:ID"/> </xsd:complexType> </xsd:element> <xsd:element name="Selection"> <xsd:complexType> <xsd:sequence>

<xsd:element ref="Condition" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="Descriptor" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="Override" minOccurs="0" maxOccurs = "unbounded"/> </xsd:sequence> <xsd:attribute name="select_id" type="xsd:ID" use="required"/> </xsd:complexType> </xsd:element>

20

Het Choice element bevat dus naast Descriptors en Conditions een onbeperkt aantal

Selections. De attributen van een Choice zijn het minimum en maximum aantal te maken

keuzes, defaultkeuzes en een naam (choice_id). Een keuze of Selection bestaat ook uit

Conditions en Descriptions en een eigen naam (select_id). Uiteraard blijken dit dezelfde

attributen en elementen te zijn die gebruikt werden bij het modelleren van het type Voorkeur.

De aandachtige lezer heeft ondertussen gemerkt dat onze voorkeur in de vorm van een JAVA-

object nog 4 bijkomende attributen heeft: require, except, optionRequire en

optionExcept. Deze stellen afhankelijkheden voor op keuze- en op keuze-optieniveau en zijn

een parallel met Conditions uit de DIDM. Gezien hun belang vragen ze een woordje extra

uitleg.

2.2.1 Conditions

Een voorkeur is dus een keuze met mogelijke keuzeopties. Dit systeem is voldoende in

simpele gevallen. “Kies ja of nee” is er zo één. Willen we echter een model hebben voor een

vraag als: “Leest u soms boeken en zo ja, welke?”, dan volstaat één keuze niet meer om deze

voorkeur te modelleren. De tweede vraag bestaat uit een afhankelijkheid: als op “Leest u soms

boeken?” positief geantwoord werd, dient een bijkomende vraag “Welke?” gesteld te worden.

Beide vragen zijn dus opnieuw aparte voorkeuren die samen één grotere voorkeur vormen.

Het is duidelijk dat een voorkeur modelleren als één enkele keuze niet voldoende is om

complexere voorkeuren op te bouwen. We moeten dus ook de context kunnen bewaren in een

voorkeur, dit zal gebeuren door bij te houden onder welke voorwaarden keuzes en

keuzeopties mogen optreden.

Conditions stellen nu deze voorwaarden voor en kunnen op verschillende elementen toegepast

worden (Choice, Selection, Item,…). Hun predikaten zijn de unieke namen van andere

keuzeopties (Selections). Pas als aan de voorwaarden voldaan is mogen keuzes of keuzeopties

getoond worden.

Er zijn 2 soorten Conditions:

• require: een set van predikaten die vervuld moeten zijn.

• except: een set predikaten die niet vervuld mogen zijn.

21

Een Condition met meerdere predicaten wordt gecombineerd tot een conjunctie (EN),

meerdere Conditions behorend bij hetzelfde element worden geïnterpreteerd als een disjunctie

(OF).

Het is duidelijk dat men op deze manier Booleanse uitdrukkingen kan vormen en zo een

hiërarchie geven aan het spel van keuzes en keuzemogelijkheden. Conditions spelen een

cruciale rol in het opstellen van de beslissingsbomen binnen de MPEG-21 DID. Door

Conditions te combineren met Items, Choices en Selections kunnen we een hiërarchie

opleggen aan het systeem om keuzes te maken. Het is meteen duidelijk dat het aantal

mogelijkheden hierdoor vrijwel onbeperkt is.

Het XML-Schema van een Condition ziet er als volgt uit:

<xsd:element name="Condition"> <xsd:complexType> <xsd:attribute name="require" type="xsd:IDREFS"/> <xsd:attribute name="except" type="xsd:IDREFS"/> </xsd:complexType> </xsd:element> Een voorbeeldje zal de werking ervan verduidelijken :

<Condition require=”VWD1 VWD2”> <Condition require=”VWD3”> <Condition except=”VWD4”> <Condition require=“VWD5” except=“VWD6”> Dit voorbeeld wil zeggen dat de keuze of keuzeoptie getoond mag worden in vier gevallen:

• er is voldaan aan voorwaarden 1 EN 2

• er is voldaan aan voorwaarde 3

• er is NIET voldaan aan voorwaarde 4.

• er is voldaan aan voorwaarde 5, maar niet aan voorwaarde 6

2.3 Lijstvoorkeuren

Lijstvoorkeuren zullen onze eerste subklassen van de voorkeuren worden. Een LijstVoorkeur

(of ListPreference) bevat geen extra attributen tegenover een Voorkeur, maar werd toch

behouden als abstracte subklasse omwille van mogelijke uitbreidingen en duidelijkere

modellering. Het is immers de modellering die lijstvoorkeuren zal onderscheiden van andere

voorkeuren. We hebben gesteld dat alle voorkeuren keuzes met keuzeopties zijn. Deze

keuzeopties zullen niet steeds bepaald zijn: we zullen zien dat tekstvoorkeuren de opties vrij

laten en intervalvoorkeuren een interval voorstellen. Lijstvoorkeuren zullen echter steeds

22

welgedefinieerde keuzeopties moeten omvatten. Het zal ook niet toegelaten zijn binnen

lijstvoorkeuren andere opties als keuze aan te duiden.

Twee types lijstvoorkeuren kunnen onderscheiden worden: de SingleSelection en de

MultipleSelection. In een SingleSelection moet één en slechts één keuzeoptie gekozen

worden. In een MultipleSelection is het aantal keuzes onbepaald. Meestal zal men enkele

opties kiezen uit een lijst. Geen enkele optie of juist allemaal kiezen is soms ook toegelaten,

zolang de keuzes maar uit de lijst met keuzeopties komen. De abstracte klasse

ListPreference zal dus gebruikt worden om te voorkomen dat keuzes gemaakt worden die

niet tot de geboden mogelijkheden behoren.

2.3.1 SingleSelection

SingleSelections vormen dus een logische subklasse van de Lijstvoorkeuren. Binnen DIDL

zijn deze heel eenvoudig voor te stellen: Lijstvoorkeuren zijn immers de standaardvorm om

keuzes aan te bieden binnen MPEG-21 DID.

We gebruiken opnieuw het klassieke “Kies ja of nee” voorbeeld: <Choice choice_id="KEUZE" maxSelections="1" minSelections="1"> <Descriptor> <Statement type="text/plain">Kies ja of nee</Statement> </Descriptor> <Selection select_id="JA"> <Descriptor> <Statement type="text/plain">Ja</Statement> </Descriptor> </Selection> <Selection select_id="NEE"> <Descriptor> <Statement type="text/plain">Nee</Statement> </Descriptor> </Selection> </Choice> Bovenstaand voorbeeld geeft de XML-voorstelling van een DID met een SingleSelection

weer. Typisch aan een SingleSelection is het feit dat maxSelections en minSelections

beiden gelijk zijn aan 1. Er moet één van de keuzeopties gekozen worden. Dit kenmerk is

uniek voor een SingleSelection en zal tijdens het parsen ook gebruikt worden om een

SingleSelection te herkennen. Verder zien we de gebruikelijke attributen van een voorkeur

éénduidig ingevuld worden: de naam (KEUZE), de opties (JA, NEE) en hun optionele

beschrijvingen (in vet aangeduid).

23

Het is nu duidelijk hoe een DID met een SingleSelection kan omgezet worden in een JAVA-

object dat deze SingleSelection zal voorstellen. Nieuwe attributen hoeven niet toegevoegd te

worden. Alles is al voorhanden in de structuur van een algemene Voorkeur. De omzetting van

de DID naar het object komt dus neer op het correct interpreteren van de structuur en

gegevens in het stukje XML dat deze SingleSelection zal voorstellen.

De volgende stap omvat nu de omzetting van dit JAVA-object naar een voor de gebruiker

duidelijke representatie. We beginnen met een tekstgebaseerde I/O:

Kies ja of nee (Ja, Nee)?

Dit is de voorstelling van bovenstaand stukje DID. Een eerste opmerking is dat de

beschrijvingen optioneel zijn. Indien zij niet aanwezig zouden zijn, moet de naam getoond

worden. We zouden dan KEUZE (JA, NEE)? Als uitvoer krijgen. De gebruikers krijgen de

keuze voorgeschoteld en krijgen de keuzeopties te zien. Ze moeten dan één van de twee

keuzes ingeven. De verschillende voorkeuren worden onderscheiden door de manier waarop

keuzes gemaakt worden. In het geval van een SingleSelection zal men er steeds voor zorgen

dat de keuze één van de mogelijke opties was en dat er ook slechts één keuze gemaakt wordt.

Binnen de tekstgebaseerde weergave zijn natuurlijk ook kleine varianten denkbaar, dit hangt

helemaal af van de gemaakte implementatie. De standaardtypes binnen een grafische

weergave zijn een stuk verscheidener, enkele hiervan worden voorgesteld in onderstaande

figuur.

Figuur 8 Grafische voorstellingen van SingleSelection

De meest evidente voorstelling is uiteraard deze met radio buttons. Dit is ook een

voorstellingswijze van een SingleSelection in een HTML-formulier. De mogelijkheden van

deze representatie zijn geïmplementeerd in de demo. Een andere voor de hand liggende

voorstelling is deze met uitklaplijsten. Hier houdt het echter niet bij op: ook achter een

menustructuur kan een SingleSelection vervat zitten. Ook hier wordt het uitzicht opnieuw

helemaal bepaald aan de hand van de geïmplementeerde GUI, enkel de werking en interactie

24

met de JAVA-objecten is overal dezelfde. Elk type GUI moet enkel gemeen hebben dat

slechts één keuze aanvaard wordt en dat niet getoonde opties ook niet gekozen kunnen

worden.

2.3.2 MultipleSelection

MultipleSelection is ook een logische subklasse van Lijstvoorkeur. Het verschil met

SingleSelections is dat het hier wel mogelijk is nul of meerdere opties aan te duiden. In een

DID zal een MultipleSelection dan ook op identiek dezelfde manier voorgesteld worden als

een SingleSelection. De enige verschillen zijn de waarden van de attributen in een Choice-

element. maxSelections en minSelections krijgen nu niet meer de standaardwaarde “1”,

het zijn zelfs geen noodzakelijk attributen meer. Zo zal het ontbreken ervan betekenen dat er

geen minimum- of maximumvereisten zijn en dus bijvoorbeeld alle opties of geen opties

kiezen ook geldig is. De toepassingen worden echter pas interessant als men de gebruiker

verplicht om minstens een verplicht aantal opties aan te duiden. Een voorbeeld: we stellen ons

een applicatie voor het online bestellen van pizza voor. De gebruiker krijgt de mogelijkheid

zijn pizzabeleg zelf samen te stellen. Dit is een MultipleSelection: een aantal ingrediënten

wordt aangeboden, de gebruiker moet er verschillende aanduiden om zo de pizza samen te

stellen. De pizzaverkoper kan nu een beperking instellen op het aantal ingrediënten (bv. de

gebruiker kan kiezen uit tien soorten beleg, maar mag er maximum vijf kiezen per pizza). Bij

een MultipleSelection wordt dus vrij gebruik gemaakt van de minSelection en maxSelection

attributen van een Voorkeur, terwijl beiden bij een SingleSelection steeds 1 moeten zijn.

De omzetting van een DID naar een JAVA-object stelt ons voor weinig nieuwe problemen.

De voorstelling van deze objecten in een tekstgebaseerde I/O kan ook volledig analoog

gebeuren als bij een SingleSelection, enkel de verwerking van de antwoorden zal anders zijn.

Volgende grafische voorstellingen zijn bruikbaar voor een MultipleSelection:

Figuur 9 Grafische voorstellingen van een MultipleSelection

25

In de demo hebben we ervoor gekozen MultipleSelections voor te stellen door check boxen.

Opnieuw zijn er talrijke andere varianten denkbaar: list boxen en zelfs boomstructuren

waarbij je meerdere takken kunt uitklappen. Opnieuw is de volledige vrijheid hiervoor aan de

programmeur van de GUI.

2.4 Tekstvoorkeuren

LijstVoorkeuren blijken dus goed modelleerbaar, zowel in de vorm van een GUI als DID. We

definiëren nu een nieuwe klasse Voorkeur: de TekstVoorkeur. Tekstvoorkeuren zullen een

oplossing bieden voor gevallen waarin de mogelijke keuzeopties onbepaald zijn of waarin hun

aantal simpelweg te groot is om nog in lijsten voor te stellen. Enkele eenvoudige voorkeuren

als “Geef uw naam?” , “Wat is uw favoriete auteur?” ,… behoren hiertoe.

Wat de JAVA-objecten betreft, kunnen we nog steeds zonder problemen en zonder

bijkomende attributen gebruik maken van de standaardvoorkeur. Het enige wat typisch is aan

de TekstVoorkeur is de manier waarop de keuzes gemaakt worden: er hoeft niet meer

gekeken te worden of de gemaakte keuze tot de opties behoort. Op het eerste zicht lijkt het dat

we in het type Voorkeur attributen teveel hebben vastgelegd. De options-attributen worden

niet meer gebruikt, want er zijn nu immers geen keuzemogelijkheden vastgelegd. Deze

redenering klopt niet! De options-attributen zullen nog steeds gebruikt worden om

afhankelijkheden in vast te leggen. Het kan immers dat het intikken van een bepaalde tekst

aanleiding geeft tot het oproepen van nieuwe keuzes of dat een ingegeven tekst niet geldig

wordt geëvalueerd bij een foutief antwoord.

Tekstvoorkeuren blijken echter niet voorstelbaar binnen een gewone DID. Hiervoor is echter

een oplossing voorzien. Een Descriptor kan een Statement van het type “text/xml” bevatten.

We krijgen dan volgende structuur om een niet-Lijstvoorkeur in voor te stellen: <Choice choice_id="NAAM"> <Descriptor> <Statement type="text/plain">beschrijving</Statement> </Descriptor> <Selection> <Descriptor> <Statement type="text/xml"> Hier komt een ander type </Statement> </Descriptor> </Selection> </Choice>

26

Deze nieuwe Voorkeur bevat nog steeds een naam en een optionele beschrijving, maar de

verplichte Selection zal nu zeker een beschrijving van het type “text/xml” bevatten.

Wanneer een parser een beschrijving van een speciaal type tegenkomt, vervalt het

oorspronkelijke type. Wanneer we dus te maken hebben met een LijstVoorkeur (gezien de

vorm van keuzes in een DID is dit steeds zo) en binnen een Selection een speciale text/xml

Statement tegenkomen, hebben we te maken met een ander type Voorkeur. Die speciale

text/xml statement moet dan wel aan de parser gekend zijn als een apart type Voorkeur. In het

andere geval hebben we gewoon te maken met de traditionele text/xml statements die hun

metadata informatie op een speciale manier structureren. Wat hierin zit is eigenlijk onbepaald.

We hebben dus zelf een type TextPreference samengesteld. Binnen een Selection zal een

text/xml Statement van volgende vorm een Tekstvoorkeur voorstellen:

<prefs:Textpreference> <prefs:Descriptor> <prefs:Statement type="text/plain">

Favoriete auteur? </prefs:Statement>

</prefs:Descriptor> <prefs:Selection select_id="textpref:X1">

<prefs:Condition except="NONFICTION" /> </prefs:Selection> </prefs:Textpreference>

Alle elementen van Textpreference zullen zich in een speciale namespace bevinden (hier

prefs). Het onderscheiden van verschillende namespaces naast de standaard MPEG-21

namespace laat hier toe eenzelfde structuur te gebruiken om tekstvoorkeuren voor te stellen.

Opnieuw is het mogelijk (niet nodig) een aparte beschrijving te voorzien. Deze beschrijving

verschilt van de originele beschrijving, meegegeven aan wat toen nog een Lijstvoorkeur was.

Die eerste beschrijving zal de keuze op zich beschrijven, terwijl de beschrijving horende bij

het element Textpreference een extra uitleg zal geven bij wat ingevuld moet worden. In zijn

minimale vorm kan een tekstvoorkeur dus als volgt voorgesteld worden:

<prefs:Textpreference> </prefs:Textpreference>

Er werden ook Selections voorzien, naar analogie met de Selections in Lijstvoorkeuren. Bij

Lijstvoorkeuren worden de Selections gebruikt om de mogelijke correcte opties af te bakenen.

Bij een Tekstvoorkeur zullen deze uitsluitend gebruikt worden om Conditions vast te leggen.

Ondanks het feit dat tekstvoorkeuren om het even welke input aanvaarden, kan het antwoord

op een vraag toch als niet correct worden aanzien. Het voorbeeld van hierboven geeft een

dergelijk eenvoudig voorbeeld. De gebruiker kan X1 als favoriete auteur ingeven. Op zich is

27

dit een juiste keuze. Er kan echter in een andere voorkeur gevraagd worden of de gebruiker

enkel fiction of non-fiction boeken leest. Als de gebruiker daarop te kennen gaf enkel non-

fiction boeken te lezen, dan kan X1 niet meer als een correcte keuze aanvaard worden

aangezien deze enkel fantasieverhalen schreef. De Selections in de namespace van de

Tekstvoorkeuren zullen deze condities kunnen regelen.

We kunnen dus besluiten dat een TekstVoorkeur niet ingebouwd is binnen de MPEG-21 DID,

maar gezien de uitbreidingsmogelijkheden van deze standaard, aangemaakt kan worden. Het

grote nadeel is dat een TekstVoorkeur op geen enkele manier gestandaardiseerd is. Iedereen

kan in principe zijn eigen namespace en XML-codering voor een TekstVoorkeur bedenken,

zolang men de parser maar laat weten hoe het deze XML-codering kan omzetten in een echt

Voorkeur object.

De omzetting tussen objecten van het type Tekstvoorkeur en een gebruiksvriendelijke

representatie verloopt volledig analoog als de omzetting van LijstVoorkeuren naar hun

grafische representatie. We beginnen opnieuw met de tekstgebaseerde I/O:

Vraag?

De tekstgebaseerde I/O bestaat in feite uit niets meer dan de vraagstelling d.m.v. de twee

mogelijke beschrijvingen die voorzien werden in het type. De gebruiker kan dan om het even

welk antwoord geven. Dit antwoord zal wel nog vergeleken worden met de actieve condities.

De soorten grafische voorstellingen zijn een stuk beperkter dan bij de Lijstvoorkeuren: bij

Tekstvoorkeuren is het immers steeds de bedoeling dat men vrij een tekstueel antwoord kan

geven. De meest voorkomende vormen zijn de edit box en de text box. In Figuur 10 tonen we

nogmaals duidelijk hoe de twee beschrijvingen gebruikt kunnen worden. “Geef uw favoriete

auteur” is de beschrijving op keuzeniveau; “Auteur:” geeft een aparte beschrijving voor het

invulvak. In de meegeleverde applicatie is een edit box implementatie voorhanden.

Figuur 10 Grafische voorstellingen van een TekstVoorkeur

28

2.5 Intervalvoorkeuren

Een laatste basistype Voorkeuren zijn de Intervalvoorkeuren. Zoals de naam doet vermoeden

behandelen deze types intervallen. Typische voorbeelden hiervan zijn:”Ik wil enkel

documenten gepubliceerd tussen jaar x en jaar y raadplegen”, “Mijn digitale foto’s moeten

tussen de x en de y kleuren hebben”, “De bitrate van mijn audiobestanden moet tussen de x en

de y kbps liggen”, … De antwoorden op deze voorkeuren omvatten dus niet enkel de twee

uitersten maar ook alle tussenliggende waarden. Een intervalvoorkeur is echter volledig te

modelleren met zijn grenzen. Het is eigenlijk niet nodig om voor intervalvoorkeuren een apart

type te voorzien. Een intervalvoorkeur kan uitstekend gemodelleerd worden aan de hand van

twee identieke Selections, waarbij er één de rol van ondergrens moet vervullen en één de rol

van bovengrens. We zouden een IntervalVoorkeur dus perfect kunnen voorstellen door twee

LijstVoorkeuren of twee TekstVoorkeuren. Omwille van de speciale betekenis van

intervalvoorkeuren (en deels ook om de uitbreidbaarheid van het systeem te demonstreren)

zullen we intervalvoorkeuren toch als een aparte klasse implementeren.

De omzetting van een DID naar een JAVA-object verloopt weer analoog. We zullen opnieuw

een nieuw type moeten inpassen in de bestaande DID-structuur. Opnieuw zal dit moeten

gebeuren door een Statement van het type text/xml te voorzien in een Selection. Binnen die

Statement kunnen we dan zonder problemen een nieuw type definiëren. Een aanpassing aan

de parser zal dan voor de herkenning zorgen.

De naam en algemene beschrijving van de IntervalVoorkeur zal traditioneel terug te vinden

zijn in de Choice zelf. In een Statement zullen dan de specifieke eigenschappen voor het type

uitgeschreven worden. De IntervalVoorkeur is een voorkeur die niet genoeg heeft aan de

standaardattributen van een gewone Voorkeur. Een Intervalvoorkeur is dus een voorbeeld van

een Voorkeur met eigen extra attributen: BeginValue en EndValue. Deze twee extra

attributen geven de minimum- en maximumgrenzen van het interval aan. Tussen deze twee

grenzen moeten dus de grenzen van het voorkeurinterval gekozen worden. Figuur 11 toont

ons hoe het werkt. De gebruiker moet het interval van zijn voorkeur kiezen tussen een

BeginValue en een EndValue. Deze twee waarden vormen de donkere band. De door de

gebruiker gekozen voorkeur wordt dan voorgesteld door de lichte band. Deze band is opnieuw

te modelleren door zijn twee grenzen. We merken dus op dat het voorkeurinterval steeds

binnen de maximumgrenzen moet liggen! Deze voorkeursgrenzen zullen gewoon bewaard

29

kunnen worden in het Choice attribuut, dat door middel van extra toegangsfuncties beperkt

wordt tot twee elementen, zodat de voorkeur steeds een aaneengesloten interval voorstelt. Een

mogelijke uitbreiding is dan uiteraard de IntervalVoorkeur waarin de keuze bepaald wordt

door een unie van deelintervallen.

Figuur 11 Voorstelling van intervalvoorkeuren

We hebben nu twee extra attributen toegevoegd die enkel van toepassing zijn op een

IntervalVoorkeur. Deze nieuwe attributen zullen dus ook voorgesteld moeten worden in een

XML-syntax. Net als bij de TekstVoorkeur zullen we eenzelfde vorm als bij de DIDL

aanhouden, maar we zullen ook nieuwe XML-elementen introduceren.

<prefs:Rangepreference> <prefs:Descriptor> <prefs:Statement type="text/plain"> beschrijving </prefs:Statement> </prefs:Descriptor> <prefs:Upperbound value="BOVENGRENS_WAARDE" default="STANDAARDKEUZE"/> <prefs:Lowerbound value="ONDERGRENS_WAARDE" /> </prefs:Rangepreference>

De elementen Rangepreference, Descriptor en Statement spreken voor zich, zij

vervullen immers dezelfde functies als uitgelegd bij de Tekstvoorkeuren. Uiteraard is het ook

hier weer mogelijk Selections met speciale Conditions voor bepaalde antwoorden in te

voegen. Het interessantste zijn wellicht de twee volledig nieuwe elementen Upperbound en

Lowerbound. Deze behoren niet tot de MPEG-21 DIDL, maar zijn nu enkel gedefinieerd

binnen de Rangepreference. Upperbound zal de bovengrenzen van het interval beschrijven.

Hiertoe dienen twee attributen: value dat de maximumgrens weergeeft en default dat de

voorkeur zal meegeven. Deze voorkeur werd dan door de gebruiker zelf gekozen. Beiden zijn

uiteraard enkel van toepassing als ze gedefinieerd zijn. Lowerbound zal dan het analoge doen

voor de ondergrens van IntervalVoorkeur.

30

In de demo-applicatie is de IntervalVoorkeur ook van de partij. Wat echter niet voorzien is, is

een controle. Het spreekt vanzelf dat aan Intervalvoorkeuren een uitgebreid controlesysteem

verbonden hoort te zijn. Zowel de bovengrens als de ondergrens moeten van hetzelfde type

zijn en de gekozen grenzen moeten binnen het maximuminterval liggen. Dit vereist een te

ingewikkelde logica om één algemene klasse voor IntervalVoorkeuren te maken. De

meegeleverde klasse RangePreference moet dus eerder gezien worden als een abstracte

klasse waarvan specifieke types IntervalVoorkeuren van moeten afgeleid worden. In die

afgeleide klassen moet dan een grondiger controle voorzien worden. Wat toepassingen betreft

denken we dan bijvoorbeeld aan een klasse voor getallen, strings, kleuren, …

De grafische voorstelling hangt dan eigenlijk ook af van deze subklassen, toch werd een

eenvoudige implementatie van een IntervalVoorkeur voorzien (een interval van strings,

voorgesteld door twee tekstboxen). Andere mogelijkheden zijn bijvoorbeeld de combinatie

van twee sliders. Zoals bij de overige types voorkeuren kan de gebruiker opnieuw volledig

vrij bepalen hoe hij gebruik maakt van de beschikbaren attributen en functies om een

Intervalvoorkeur grafisch voor te stellen.

2.6 Complexe keuzestructuren

Tot hiertoe zijn de basistypes Voorkeuren behandeld. In realiteit zal echter nood zijn aan veel

complexere keuzestructuren. We denken bijvoorbeeld aan een lijst met welomlijnde

keuzemogelijkheden en een extra tekstvak “andere”.

Figuur 12 Voorbeeld samengestelde voorkeur

Een dergelijke keuze is voor te stellen in de DID-structuur. Voor bovenstaand voorbeeld

voorzien we een SingleSelection met vier keuzeopties en een TextVoorkeur die conditioneel

verwijst naar de vierde keuzeoptie. Ook grafisch is dit eenvoudig voor te stellen. In de JAVA-

objecten is het type van de keuzeoptie immers volledig onbepaald. Dit kan dus een getal of

een string zijn, maar ook een andere Voorkeur. Door middel van deze structuur is het dus

eenvoudig te achterhalen hoe we de GUI moeten opbouwen. Hét probleem is echter de

31

mapping tussen de MPEG-21 DID en de JAVA-objecten. Zoals gezegd is de voorstelling

binnen een DID eenvoudig, maar moet hij gebruik maken van twee aparte voorkeuren. Deze

twee voorkeuren kunnen in principe op totaal willekeurige plaatsen in het document

voorkomen en maken het extra moeilijk om te detecteren dat één van de aangeboden opties in

een Lijstvoorkeur een andere Voorkeur is. Het is zeker niet onmogelijk dit te doen, maar het

vergt vermijdbaar rekenwerk. Men moet immers van alle aanwezige voorkeuren (dus niet

enkel de twee betrokken voorkeuren) de namen, de opties en de condities controleren. Pas

wanneer we vaststellen dat een bepaalde keuze afhangt van één en slechts één andere keuze

hebben we te maken met een afhankelijkheid. We definiëren een enkelvoudige

afhankelijkheid als een afhankelijkheid tussen twee keuzes of keuzeopties waarbij één van de

twee keuzes of keuzeopties slechts van toepassing is als één bepaalde optie bij de andere

gekozen werd. De lijst met gebruikersvoorkeuren voor zoekrobotten zal wel groter zijn dan

enkele (enkelvoudige) keuzes en zal talrijke samengestelde keuzes bevatten. De controle zou

dus wel eens een zeer inefficiënte schakel in de omzetting van de DID naar de GUI kunnen

worden. Vandaar de keuze om dit niet te doen en in de demo-applicatie alle keuzes en

deelkeuzes apart te houden. Binnen de huidige vorm van de DID moet er echter wel naar een

goed werkende oplossing gezocht worden voor dit probleem. Dit kan ons aangeboden worden

door een minimale uitbreiding.

Wanneer we simpelweg voorzien dat een Selection ook uit een Choice kan bestaan, zijn alle

hindernissen in één stap overwonnen. In dat geval kunnen alle keuzes die afhankelijk zijn van

slechts één andere optie, genest worden binnen die optie. Conditions hoeven dan enkel nog

gebruikt te worden om afhankelijkheden voor te stellen met keuzes die door meerdere andere

keuzes of keuzeopties gebruikt worden. Enkelvoudige afhankelijkheden worden dan niet meer

voorgesteld met Conditions. Door de geneste structuur zou de parser wel moeten aangepast

worden, maar dat is natuurlijk geen probleem. Het resultaat is immers dat de structuur van de

JAVA-objecten beter en efficiënter benut kan worden en een omzetting in een GUI kan

verlopen zoals de maker van de DID het voor ogen had. Dit gegeven is te realiseren binnen de

huidige standaard. We kunnen een nieuwe DID als een text/xml statement bij een Selection

invoeren. Dit veroorzaakt echter wel een overhead aan code, het is echter ook mogelijk niet de

volledige DID te includeren, maar slechts een referentie ernaartoe.

We illustreren dit aan de hand van een volgend voorbeeld. Hiervoor nemen we een stukje

DID dat twee keuzes voorstelt. De tweede keuze is enkel van toepassing wanneer de

32

gebruiker de voorkeur gaf aan de eerste optie van de eerste keuze. Binnen de huidige DIDL-

standaard wordt deze enkelvoudige afhankelijkheid opgevangen door een Condition te

plaatsen in de tweede Choice. In de voorgestelde uitbreiding zal er sprake zijn van een

basiskeuze. Binnen het eerste Selection element zal de tweede Choice genest zitten. Het

gevolg hiervan is dat geen Condition meer nodig is. In een grote DID met veel keuzes komt

dit soort situaties frequent voor, het levert ons dan ook een interessante optimalisatie op. We

merken echter op dat dit enkel van toepassing is op enkelvoudige afhankelijkheden. Precies

dit legt het pijnpunt van deze uitbreiding bloot. Indien door een bepaalde aanpassing van de

DID de tweede keuze ook afhankelijk gemaakt wordt van nog een andere keuze of optie, moet

de volledige geneste structuur ontrafeld en ontdubbeld worden. In de huidige standaard hoeft

enkel een extra Condition toegevoegd worden. Het gebruik van een referentie kan dit

probleem opnieuw oplossen. We kunnen dus stellen dat deze uitbreiding van de DIDL-

grammatica niet zeer flexibel is, maar wel efficiënter en, gezien de geneste structuur van de

keuzes en keuzeoptie, een helderder structuur heeft dan de huidige versie.

De huidige versie van de DID met dit voorbeeld: <Choice choice_id="KEUZE1"> <Selection select_id="KEUZE1_OPTIE1" /> <Selection select_id="KEUZE1_OPTIE2" /> <Selection select_id="KEUZE1_OPTIE3" /> </Choice> <Choice choice_id="KEUZE2"> <Condition require="KEUZE1_OPTIE1"> <Selection select_id="KEUZE2_OPTIE1" /> <Selection select_id="KEUZE2_OPTIE2" /> <Selection select_id="KEUZE2_OPTIE3" /> </Choice> De mogelijke uitbreiding voor enkelvoudige afhankelijkheden: <Choice choice_id ="KEUZE1"> <Selection select_id ="KEUZE1_OPTIE1"> <Descriptor> <Statement type=”text/xml”> <DIDL> <Item>

<Choice choice_id="KEUZE2"> <Selection select_id="KEUZE2_OPTIE1" />

<Selection select_id="KEUZE2_OPTIE2" /> <Selection select_id="KEUZE2_OPTIE3" />

</Choice> </Item> </DIDL>

</Statement> </Descriptor> </Selection> <Selection select_id="KEUZE1_OPTIE2" /> <Selection select_id="KEUZE1_OPTIE3" /> </Choice>

33

2.7 GebruikersVoorkeuren

Zoals hierboven aangegeven is ook zonder de gesuggereerde uitbreiding van de DIDL nood

aan een object dat op JAVA-niveau voor de interactie tussen de verschillende keuzes zal

zorgen. Dit wordt gedaan door de klasse UserPreferences of GebruikersVoorkeuren. Deze

klasse vertoont veel analogieën met de gewone Voorkeuren. Een gebruikersvoorkeur zal een

lijst Voorkeuren (attibuut userPreference) bevatten, naast een eigen naam (name),

beschrijving (description) en eigen Conditions (require en except). Dit alles laat toe van

een reeks Voorkeuren een apart Item te maken. Uitgebreide systemen met

gebruikersvoorkeuren kunnen dan verschillende Items bevatten.

Figuur 13 UML voorstelling van de klasse UserPreferences

Het attribuut dat voor de onderlinge communicatie tussen de verschillende Voorkeuren zal

zorgen is forfill. Dit is een lijst met alle op dat moment actieve, gekozen opties. Bij het

grafisch voorstellen van Gebruikersvoorkeuren zal dus constant naar dit attribuut verwezen

worden. Het attribuut bevat immers alle predikaten van de vervulde opties. Om een keuze te

tonen moeten eerst zijn Conditions geanalyseerd worden. Die analyse zal gebeuren door de

Conditions te vergelijken met de predikaten in het forfill-attribuut. Naargelang voor een

bepaalde keuze voldaan is aan de Condition require of de Condition except zal de keuze al

dan niet getoond worden. Indien er voor een keuze geen Conditions gedefinieerd zijn, hoeft

men uiteraard niet te vergelijken met de predikaten in forfill. De keuze zal dan immers

altijd getoond worden. Deze hele procedure zal niet enkel gebeuren met de keuzes, maar ook

met de keuzeopties, ongeacht het type Voorkeur.

Alle attributen in de klasse UserPreferences zijn private. Het is immers niet de bedoeling dat

er nog wordt overgeërfd van deze klasse. Alle transacties dienen dus via de vastgelegde get-

en set-operaties te gebeuren.

34

Hoofdstuk 3 Maken van de applicatie

“Internet is so big, so powerful and pointless that for some people it is a complete

substitute for life.”

- Andrew Brown

3.1 Het parsen

Wellicht het moeilijkste gedeelte van deze scriptie is het omzetten van een DID in de

structuur van Voorkeuren. In het vorige hoofdstuk werd al besproken hoe de belangrijkste

types Voorkeuren voorgesteld worden in een DID. In deze sectie wordt iets dieper ingegaan

op het parsen.

Voor het parsen werd gebruik gemaakt van SAX2 en Xerces. SAX (Simple API for XML)

definieert een interface die parsers kunnen gebruiken om informatie over XML-documenten

naar applicaties te sturen. Xerces is dan de eigenlijke implementatie van die interface en, net

als SAX, open source.

Er zijn twee grote types API’s voor het parsen van XML:

• Tree-based (boomgestructureerde) API’s

• Event-based (gebeurtenisgebaseerde) API’s

Een tree-based API zet een XML-bestand om in een boomstructuur en laat dan toe deze te

doorlopen. DOM (Document Object Model) is een voorbeeld hiervan en behoort tot de W3C

standaarden. Een event-based API reageert op parsing events (starten of eindigen van XML-

elementen). De API rapporteert deze direct aan de applicatie via callbacks en moet op die

manier geen interne boomstructuur bijhouden. In de applicatie moeten dan wel eventhandlers

ingebouwd worden. Het is trouwens perfect mogelijk om indien nodig de parse-tree alsnog te

construeren met een event-based parser. SAX is een voorbeeld van een event-based parser.

SAX is geen gestandaardiseerd protocol, maar in realiteit wel een de facto standaard. SAX is

een open development project: iedereen mag zijn steentje bijdragen. Dit maakt de SAX-parser

uitermate flexibel en goed ontwikkeld.

SAX heeft tegenover DOM enkele belangrijke voordelen die de keuze voor deze manier van

werken kunnen verantwoorden. DOM bouwt een boomstructuur op die in het geheugen

bijgehouden wordt. Dit is overduidelijk een zware last voor het systeem, zeker als de

35

documenten groot kunnen zijn en de applicatie zich aan serverzijde bevindt. Een groot aantal

gebruikers (wat met gebruikersvoorkeuren voor zoekrobotten zeker het geval zou zijn) zou

dan het systeem kunnen overbelasten.

Bovendien hebben sommige applicaties een eigen datastructuur nodig. In ons geval is dat de

Voorkeur. Door het systeem van events is het veel eenvoudiger dit binnen SAX te doen. De

datastructuur kan dan gaandeweg ingevuld worden naargelang zich onderweg bepaalde events

voordoen. We willen onze applicatie ook zo maken dat het hele model nog behouden blijft

mocht er iets veranderen aan de onderliggende XML-structuur. Gezien de standaardisatie van

MPEG-21 nog in volle gang is, is dit een noodzaak. Bij een SAX-parser zullen dan enkel de

events moeten aangepast worden, bij een DOM-parser bestaat de kans dat de volledige

boomstructuur foutief wordt. Syntaxwijzigingen en kleine aanpassingen in de grammatica

zullen zeer snel opgelost kunnen worden met SAX, terwijl dit bij DOM complexer kan zijn.

Voor grote grammatica-aanpassingen moet de parser in beide gevallen herschreven worden.

SAX biedt ten slotte ook nog de mogelijkheid om niet het hele document te moeten

interpreteren. In dit project zijn enkel de Choices van belang. Als zich dus een event voordoet,

veroorzaakt door bijvoorbeeld een Component of een Resource, dan kan dit genegeerd

worden (tenzij ze natuurlijk behoren tot een Choice). Bij een DOM-parser zullen ook zij

nodeloos overlopen worden.

Aangezien event-based parser niet aan bod komt in onze opleiding, volgend voorbeeld:

<?xml version="1.0"?> <doc> <para>Hello, world!</para> </doc> Een event-based parser interpreteert dit stukje XML als volgt:

Start document Start element: doc Start element: para Characters: Hello, world! End element: para End element: doc End document

Nadelen van SAX tegenover DOM zijn het ontbreken van een API voor output: SAX leest

enkel het document. DOM bewaart het document in het geheugen en kan dit dan ook

gebruiken voor de output. Het gevolg is dat eens een document geparst is met een DOM-

parser, op die structuur meerdere bewerkingen gedaan kunnen worden, zonder opnieuw te

36

moeten parsen. Bij SAX zal voor elke verwerking van het document een aparte parsing nodig

zijn. Het omzetten van de DID naar de gebruikersvoorkeuren is echter een éénmalige operatie,

dit nadeel speelt dus geen rol.

De algemene conclusie is dat SAX omwille van zijn grotere snelheid het best geschikt is voor

grote documenten en voor het parsen naar data in documenten. DOM is door de

boomstructuur meer flexibel en aanpasbaar. De flexibiliteit van DOM gaat echter ten koste

van de doorzichtigheid en de instapsnelheid bij gebruik van de API. Daarom wordt SAX

steeds meer gezien als de beste en meest betrouwbare API voor het verwerken van XML-

documenten. Er bestaan trouwens ook transformaties om de ene structuur in de andere om te

zetten. JDOM, een tree-based document object model, gebouwd bovenop de SAX interface

(!), lijkt de beste eigenschappen van de twee technieken over te nemen, maar is nog in volle

ontwikkeling. Zowel SAX als DOM maken ondertussen wel al deel uit van de jongste JDK.

We gaan nu iets dieper in op de werking van de SAX parser. Om het parsen te beginnen moet

een instantie van de klasse SAXParserFactory aangemaakt worden. Dit object kan dan de

eigenlijke SAX-parser genereren. We kunnen aan de factory meegeven welke eigenschappen

het eindproduct (de eigenlijke parser dus) moet hebben. Hier wordt dus beslist of we een

validating parser maken, rekening houden met namespaces,… De parser zelf zal dan een

product van de SAXParserFactory zijn. Naargelang de versie van SAX zal de parser het

type SaxParser (SAX 1.0) of XMLReader (SAX 2.0) hebben.

De parser omvat een SAXReader object. Wanneer het parser begonnen wordt (door het

oproepen van de procedure parse()), zal het readerobject één van de types callback

methodes oproepen. Deze methodes zijn vastgelegd in vier interfaces ContentHandler,

ErrorHandler, DTDHandler en EntityResolver. De vier interfaces worden gegroepeerd in

de klasse DefaultHandler, een basisklasse die default implementaties bevat voor de vier

soorten callbacks. Die implementatie bestaat uit null methodes, zodat de gebruiker van de

parser enkel deze functies moet implementeren die nodig zijn voor zijn specifiek probleem.

In Figuur 14 uit [11] is de algemene structuur van de SAXParserFactory en de SAXParser

zelf nog eens weergegeven. We zullen nu de vier interfaces van SAX kort bespreken.

37

Figuur 14 Structuur van de SAX-parser

• ContentHandler

Roept methods als startDocument, endDocument, startElement en endElement op

wanneer een XML-element herkend wordt. Deze methodes zorgen dus voor de

verwerking van de events. De methode characters wordt gebruikt om de tekst tussen de

verschillende tags te kunnnen verwerken. Het spreekt vanzelf dat dit de belangrijkste

interface van de vier is: om een DID in Voorkeur-objecten om te zetten is het immers

noodzakelijk te herkennen waar en wanneer er nieuwe keuzes en keuzeopties starten.

• ErrorHandler

Omvat de methods error, fatalError en warning. Deze worden opgeroepen bij parsing

errors.

• DTDHandler

Zorgt voor het parsen van een document met behulp van een DTD. Dit zullen we dus niet

gebruiken.

• EntityResolver

De resolveEntity methode wordt gebruikt bij het verwerken van een URI.

In het kader van het programmeren van een applicatie die een DID kan omzetten naar

Voorkeur objecten was het dus nodig de ContentHandler interface te implementeren en

voor een foutopvang te zorgen.

38

3.2 Structuur van het programma

We bekijken nu de algemene structuur van het gemaakte programma. Deze is terug te brengen

tot drie packages: preferences, preferencesGUI en preferencesMapper. Niet toevallig

komen deze overeen met ons drielagenmodel. In het package preferences is de algemene

definitie van de types JAVA-objecten die Voorkeuren voorstellen terug te vinden. Het

package preferencesMapper bevat de klassen die zorgen voor het inlezen en uitschrijven

van de DIDs. Van dit package wordt dan uiteraard gebruik gemaakt in de sturing van de I/O

in het package preferences. preferencesMapper bevat ook relaties naar het package

preferences: deze relaties verbinden de in- en outputmethodes met hun overeenkomstige

voorstelling als JAVA-object. Het derde onderdeel is preferencesGUI. Dit package zorgt

voor de grafische voorstelling van de JAVA-objecten. Uiteraard zal dus tussen elk object en

zijn grafische voorstelling een relatie liggen.

Dit leidt tot volgende UML package-diagram:

Figuur 15 Algemene programmastructuur in UML

De klasse Demo is hier uiteraard de hoofdklasse. Zij zal het frame bevatten waarop alle

tekenactiviteiten zullen plaatsvinden. De meeste attributen verwijzen dan ook naar de

grafische elementen van het scherm. Zoals in volgend hoofdstuk zal uitgelegd worden, bestaat

het hele concept uit drie panelen: de grafische voorstelling van een DID (desktop), de XML-

boom van de DID (xTreePanel) en een editorvenster (sourcefield) om de DID

39

tekstgebaseerd aan te passen. Voor de eerste voorstellingswijze zijn er zoals eerder gezegd

oneindig veel mogelijkheden. Wij hebben er hiervan één uitgewerkt waarbij alle bewerkingen

op een desktopomgeving (JDesktopPane) worden gedaan en elke voorkeur een apart

InternalFrame voorstelt. Verder bevat de klasse Demo nog een relatie met het package

preferencesGUI (om de GUI-componenten (van de Voorkeuren) die aangemaakt worden

binnen dit package te kunnen invoegen in de algemene GUI) en een relatie met het package

preferences voor het bijhouden van en de werking op de GebruikersVoorkeuren zelf.

Enkele extra’s zoals een browers voor de help-functie, de voorstelling van de XML-boom en

een splashscreen zitten vervat in het package utility.

Het belangrijkste package is uiteraard preferences. Figuur 16 geeft ons het klassendiagram

voor dit package. Preferences bevat de hele uitwerking van onze voorkeurproblematiek,

beschreven in het vorige hoofdstuk. Centraal in beeld merken we natuurlijk de klassen

Preference en UserPreferences. Zij zullen respectievelijk de Voorkeuren en

GebruikersVoorkeuren voorstellen en bevatten de al vertrouwde attributen zoals in vorig

hoofdstuk beschreven. Onder Preference merken we dan een cascade van overervingen op.

Elke overerving zal het type Voorkeur op zijn eigen manier uitbreiden met nieuwe attributen,

methodes of gedragingen. Het moge duidelijk zijn dat z’n model zich leent tot het nog verder

uitbreiden van de structuur. Nieuwe types Voorkeuren kunnen door een nieuwe overerving

ingepast worden in het bestaande systeem. Omwille van de overerfbaarheid werden de

attributen van een Voorkeur protected gehouden, terwijl deze van de GebruikersVoorkeuren

private zijn. De afhankelijkheid tussen het package preferences en preferencesMapper

komt tot uiting in de klasse UserPreferences waar de I/O functies voor voorkeuren

geimplementeerd zijn. De reden waarom deze functies niet binnen de klasse van de

Voorkeuren voorkomen is dat we gesteld hebben dat Voorkeuren steeds vervat moeten zitten

in één of andere container. Om het in de DIDM taal te zeggen: een Choice dient zich te

bevinden binnen een Item of een Container. Het is dus steeds het Item dat we moeten inlezen

en wegschrijven en niet de individuele keuze.

Tot slot van de bespreking van dit package leggen we de nadruk op de geleverde interfaces.

De interface PreferenceIO werd al deels uitgelegd: in deze interface zijn de I/O functies van

en naar DID-bestanden vastgelegd. De interface Requirementhandlers wordt door zowel

UserPreferences als Preference geïmplementeerd. Deze interface definieert de functies

40

voor het afhandelen van de afhankelijkheden (Conditions) op niveau van de objecten zelf: dus

de volledige keuze of de verzameling van keuzes. Conditions kunnen immers van toepassing

zijn op zowel Choices als op Items en Containers. OptionRequirementhandler zal dan

soortgelijke functies vastleggen op niveau van de keuzeopties. Aangezien keuzeopties enkel

van toepassing zijn op Voorkeuren en niet op GebruikersVoorkeuren zal de interface enkel

daar geïmplementeerd moeten worden. De laatste interface is PreferenceActions en deze

zal de meer algemene bewerkingen op Voorkeuren optekenen. Dit zijn dan typische

bewerkingen (getters and setters) op de naam, beschrijving en opties van de Voorkeur.

Figuur 16 UML voorstelling van het package preferences

41

Nagenoeg alle functies gedefinieerd binnen de verschillende interfaces worden al direct

geïmplementeerd in de klassen Preference en UserPreference en dat als finale methodes.

Van de klassen zelf werden echter geen finale klassen gemaakt om de uitbreidbaarheid te

kunnen waarborgen. Voorbeelden van interface methoden die pas hun implementatie in een

lager gelegen klasse krijgen, zijn de setters van de keuzes en keuzeopties. Bij SingleSelections

is het bijvoorbeeld van belang dat slechts één keuze gemaakt kan worden, terwijl dit bij

MultipleSelections niet het geval is. Bij LijstVoorkeuren moet onder andere ook de controle

voorzien zijn dat de gemaakte keuzes tot de mogelijke opties behoren, terwijl de invoer van

TekstVoorkeuren quasi vrij is. Naargelang het type Voorkeur varieert de manier van

toevoegen van keuzes. Daarom worden deze methoden pas in de eigenlijke subklasse

ingevuld.

We gaan nu over naar het volgende package: preferencesGUI. Dit package zal de grafische

voorstelling van de verschillende voorkeuren behandelen. Het is dan ook helemaal niet

verwonderlijk dat de structuur van dit package sterke overeenkomsten vertoont met het

vorige. Elk type GUI zal dan ook een relatie bezitten met zijn overeenkomstig element uit

preferences. In deze structuur komt de uitbreidbaarheid voor nieuwe types Voorkeuren en

nieuwe types GUI opnieuw goed naar voren.

PreferenceGUI is hier de uitgangsklasse. Zoals eerder gezegd is dit een uitwerking van een

systeem waarbij de GebruikersVoorkeuren voorgesteld worden als een desktop, met voor elke

Voorkeur een apart InternalFrame, een apart Venster. PreferenceGUI zal dus zo’n geheel van

voorkeuren voorstellen. De attributen laten toe gebruik te maken van de desktop waarop men

zich bevindt (de variabele desktop), het venster waarin men zich bevindt (de variabele

internalWindow) en het huidige paneel binnen het venster (currentPanel). De twee eerste

zijn beiden private, want deze mogen enkel aangepast worden door de UserPreferences

zelf. De laatste variabele is protected want het is ook hierop dat de verschillende types GUI

voor de verschillende Voorkeuren hun tekenwerk zullen verrichten. We wensen op te merken

dat het door currentPanel mogelijk is nieuwe panels in te pluggen in het huidige panel. Een

nuttige toepassing hiervan is de situatie waarin het selecteren van een keuzeoptie één

specifieke nieuwe keuze tot gevolg heeft. Deze materie werd besproken in 2.6. Binnen de

GUIs is telkens één mogelijke implementatie beschikbaar, uiteraard is het hier het werk van

de designer om de GUI aan te passen naar de gewenste mogelijkheden en het gewenste

uitzicht.

42

Figuur 17 UML voorstelling van het package preferencesGUI

We bekijken nu het onderste gedeelte van dit model. Daar zien we de klasse FrameListMenu.

Deze klasse zorgt voor een menu-item met hierin de actieve vensters. De klasse maakt dus

gebruik van objecten van de verschillende types Voorkeuren en dient tevens voor het

bijhouden van de lijst met getoonde Voorkeuren. Dit is ook de reden waarom er een relatie

tussen PreferenceGUI en FrameListMenu bestaat: dit is een eenvoudige manier om zonder

43

overtollige berekeningen te kijken welke Voorkeuren er op dat moment actief zijn. De functie

van deze klasse is dus vergelijkbaar met het attribuut optionShowed in de klasse

Preference. Dit attribuut doet immers net hetzelfde maar dan op gebied van de keuzeopties.

Verder zien we nog twee klassen: PreferencePanel en InternalFrame. InternalFrame zal

de inhoud van een venster op de desktop (= een Voorkeur) behandelen. De inhoud van zo’n

venster zal dan een object van de klasse PreferencePanel zijn. PreferencePanel krijgt als

input een Voorkeur (dus een object van een type uit het package preferences) en beslist dan

wat de overeenkomstige grafische voorstelling is. PreferencePanel zorgt er dus

bijvoorbeeld voor dat een SingleSelectionPreference zal voorgesteld worden door een

object van de klasse SingleSelectionPreferenceGUI. Deze klasse doet op dit moment dus

niet anders dan de relatie te onderhouden tussen de object voorstelling van een Voorkeur en

de GUI voorstelling. Het potentieel van deze klasse vergroot drastisch wanneer men met

verschillende GUIs voor eenzelfde type Voorkeur gaat werken. Stel dat we een

SingleSelection kunnen voorstellen door een reeks radio buttons en door een uitklaplijst, dan

kunnen de klasse PreferencePanel automatisch laten beslissen welke voorstelling genomen

wordt. Een Voorkeur met weinig opties kan dan door radio buttons voorgesteld worden,

terwijl bij een Voorkeur met veel opties beter de lijst genomen wordt.

We gaan tenslotte nog even in op het package preferencesMapper. Dit bevat de klassen voor

I/O van en naar de GebruikersVoorkeuren. Hierin bevinden zich in eerste instantie de klassen

voor I/O met een DID. Dit zijn dus DIDReader en DIDWriter, twee klassen die het stukje van

de DIDL grammatica betreffende het gebruik van Choices implementeren. Deze parser is dus

zeker geen volledige parser voor DIDL. Om aanpassingen van de syntax te kunnen opvangen

werd de interface DIDLSyntax in het leven geroepen. Deze interface groepeert de

kernwoorden van de DIDL. Een syntaxwijziging, zoals het geval was tussen de DIDL versie

van juli 2001 [1] en deze van december 2001 [2], levert dus geen problemen op. Dit package

staat natuurlijk open voor verdere uitbreiding. In ons drielagenmodel is het immers niet

verplicht Voorkeuren in XML-vorm te bewaren als een DID. Andere tekstgebonden

voorstellingswijzen, tot zelfs omvorming naar databanksystemen zijn hier dus perfect

mogelijk.

44

Figuur 18 UML voorstelling van het package preferencesMapper

3.3 Gebruik van de applicatie

Uiteraard is het nu ook nog nodig het gebruik van de applicatie uit te leggen. Dit zal gebeuren

aan de hand van enkele screenshots en beschrijving van de verschillende items van het menu.

De applicatie zelf is terug te vinden op de CD-ROM. De inhoud van de CD-ROM is trouwens

ook te bekijken in Appendix D.

De applicatie zelf is terug te vinden onder de directory application. In deze folder zijn

enkele subfolders te vinden: scr (waar zich de bronbestanden in JAVA bevinden), class

(met de gecompileerde versies van deze bestanden), doc (de JAVADOC bestanden), zip (met

gezipte versies van de net genoemde folders en van de applicatie zelf) en examples (met

enkele voorbeelden van DIDs die gebruikt kunnen worden). Het programma bestaat uit vier

JAR-files: xerces.jar en SAX2.jar vormen de parser en maken het ook mogelijk voor

mensen die niet beschikken over JDK 1.4.0 om SAX te gebruiken. DIDviewer.jar is het

bestand dat alle zelfgeschreven klassen en packages zal groeperen en vormt dus het hart van

deze applicatie. Het geheel wordt gegroepeerd in Demo.jar.

Het programma kan nu op verschillende manieren worden gestart:

• door te dubbelklikken op Demo.jar (indien de computer is ingesteld om JAR-files als

executables te runnen)

• onder een Windows - besturingssysteem kan dit ook via het bestand demo.bat.

• via de commando lijn. Daar moet u java –jar Demo.jar intikken.

45

Na het opladen van het programma komen we op volgend venster:

Figuur 19 Startsituatie programma

We onderscheiden vier onderdelen in deze interface: het menu, de toolbar, het tabbedPane en

het informatiepaneel. Het menu en de knoppen op de toolbar zullen dezelfde functies

behandelen. De toolbar werd toegevoegd om enkele handelingen sneller te kunnen selecteren.

Het tabbedPane bestaat uit drie onderdelen: Preferences, Source en Editor. Zoals eerder

gemeld zal hierin de DID voorgesteld worden. In het paneel Preferences krijgen we de

grafische voorstelling van de DID te zien, paneel Source zal ons de XML-boom van diezelfde

DID tonen en in paneel Editor krijgen we de DID in tekstvorm te zien. Het informatiepaneel

toont ons extra informatie over welke bestanden ingeladen zijn, welke voorkeuren gekozen

zijn,…

Laten we de bespreking van dit programma beginnen met een evidente handeling: het inladen

van een DID. Dit kan gebeuren op twee manieren: lokaal of vanop een netwerk. Deze twee

manieren van werken representeren natuurlijk de situatie waarin de DID gestockeerd wordt:

op cliënt- of op serverniveau. Het inladen zelf gebeurt via het menu Opties waar we Open

(voor lokaal did-bestand) of OpenNet (voor het intikken van een URL) kiezen. Op de toolbar

worden deze functies voorgesteld door (voor lokaal openen) en (voor de

tabbedPane

Menu

Paneel met

de namen

van de

laatst

ingeladen

bestanden

toolbar

Paneel

met

extra

informatie

46

netwerkmethode). Bij het openen van een DID zal deze volledig geparst worden. Indien zich

tijdens dit proces fouten voordoen (bijvoorbeeld document is niet well-formed), dan zal dit

proces afgebroken worden en een foutmelding verschijnen. In het Editor paneel is het

document echter wel volledig ingeladen, wat het mogelijk maakt de fout onmiddellijk te

herstellen.

Wanneer we nu een tweede DID openen zullen de keuzes van deze DID toegevoegd worden

aan de eerste keuze, we krijgen dus een samenvoeg- of merge-operatie. We dienen hierbij wel

de opmerking te maken dat het samenvoegen van twee identieke DIDs weliswaar mogelijk is,

maar dat het nadien opgeslagen bestand (dus met de eigenlijke samenvoeging) niet langer aan

het XML-schema van MPEG-21 zal voldoen. DIDM stelt immers dat de ID’s van Selections

uniek moeten zijn, wat niet het geval is bij het samenvoegen van twee identieke bestanden.

Ook is het zo dat enkel de keuzes van het tweede bestand overgenomen worden, de naam en

beschrijving van het tweede bestand gaan dus verloren. De keuzes van het tweede bestand

worden dus als het ware opgeslorpt door het eerste.

We bekijken nu het resultaat van dit parsewerk. In het Preferences paneel zal de DID nu op

een grafische manier voorgesteld worden. De manier waarop de individuele keuzes

voorgesteld worden, hangt af van de implementatie in de verschillende klassen van het

package preferencesGUI. In dit geval zullen alle keuzes voorgesteld worden door een apart

intern venster. Een SingleSelection wordt voorgesteld door radio buttons, een

MultipleSelection door check boxen, een TekstVoorkeur door een tekstveld en een

IntervalVoorkeur door twee tekstvelden. Binnen het paneel Preferences kan de gebruiker nu

zijn keuzes kenbaar maken. Elk intern venster is een aparte keuze met een vraagstelling (de

naam of de beschrijving) en een keuzegedeelte. De gebruiker kan hierin dus zijn eigen

voorkeuren aanklikken of intikken. Ook het effect van de Conditions zal merkbaar zijn op dit

niveau. Bij Conditions kunnen na het aanklikken of invullen van bepaalde voorkeuren,

nieuwe keuzes of keuzeopties verschijnen. Een uitgebreid voorbeeld volgt in Appendix C. In

deze appendix zal het voorbeeld alwaysred.did besproken worden. Deze DID stelt een

digitaal muziekalbum met extra content voor. In Figuur 20 wordt getoond hoe de grafische

vorm van deze DID eruit ziet. We kunnen duidelijk vier basiskeuzes onderscheiden: drie van

het type SingleSelection en één van het type MultipleSelection. De namen van de keuzes

gemaakt door de gebruiker zijn te zien in het informatiepaneel onderaan het programma.

47

Figuur 20 Het paneel Preferences en de grafische voorstelling van enkele keuzes

Het paneel Source bevat een ander aspect van de DID. De DID is opgesteld in XML en bevat

bijgevolg een XML-boom. Het is deze XML-boom die te zien is in dit paneel. De gebruiker

kan hierop geen aanpassingen uitvoeren, maar kan deze boom wel gebruiken om nader kennis

te maken met de structuur en de opbouw van het volledige document. In het paneel Source is

naast de structuur van de verschillende keuzes immers ook de structuur van de rest van het

document te zien. Met de rest bedoelen we dan de uiteindelijke Items die de Resources in zich

zullen dragen. Binnen het paneel Preferences mogen alleen de keuzes getoond worden en

zijn deze Items ook niet zichtbaar. Het is immers pas in een later stadium van het zoeken met

zoekrobotten dat voorkeuren zullen gelinkt worden aan deze resources. De attributen van elk

element worden weergegeven naast dit element. De inhoud van een element (bijvoorbeeld een

tekstuele beschrijving) en subelementen worden als een kind weergegeven in deze boom.

Deze XML-boom of XTree is niet alleen bruikbaar voor het weergeven van de structuur van

een DID, maar algemeen bruikbaar voor elk XML-document.

48

Figuur 21 Het paneel Source en de XML-boom van de ingeladen DID

Het derde paneel is dan de Editor. Deze toont nog steeds de XML-code van de DID, maar nu

in tekstformaat. Dit paneel maakt het mogelijk aanpassingen uit te voeren op de DID. Deze

aanpassingen hebben dan geen betrekking op het maken van keuzes, maar laten toe dat de

gebruiker fouten kan corrigeren, nieuwe keuzes of keuzeopties kan toevoegen en verwijderen

of zelfs de beschrijving van bepaalde elementen kan aanpassen. Om de wijzigingen van de

tekst te kunnen bewaren werden onderaan het paneel een Save en Save As knop voorzien.

Naast het klikken op de tabbedPane zijn de drie panelen ook toegankelijk via de knoppen

(voor de grafische voorstelling), (voor de XML-boom) en (voor de editor).

49

Figuur 22 Het paneel Editor met de tekstuele voorstelling van de DID

We kijken nu naar het bewaren van de wijzigingen. Dit kan door het drukken op de knoppen

(Save) en (Save As). Diezelfde opties kunnen ook teruggevonden worden in het

menu Opties. Onder bewaren verstaan we hier het bewaren van de voorkeuren. Dit wil

zeggen dat zowel de keuzes, de keuzeopties als de door de gebruiker aangegeven voorkeuren

zullen bewaard worden. Simpel gezegd: de volledige Voorkeurobjecten worden nu

weggeschreven naar een DID-bestand. Wat dus niet weggeschreven wordt, zijn de elementen

in de DID die niets te maken hebben met het maken van keuzes (Items met enkel Resources,

Descriptors opgesteld in een voor de parser onbekende XML-taal,…). Dit laatste is ook niet

nodig. We werkten hier immers vanuit het oogpunt de DID te gebruiken om

gebruikersvoorkeuren kenbaar te maken aan zoekrobotten. Het spreekt vanzelf dat in zo’n

DID dan ook enkel Items met Choices hoeven voor te komen. Willen we dit uitbreiden naar

een programma dat toelaat keuzes te maken en het resultaat van de gemaakte keuzes toont,

dan konden we ons deze vereenvoudiging niet permitteren. Een zoekrobot zal uiteindelijk

zelfs aan nog minder informatie genoeg hebben. Voor hem volstaat het om enkel het Choice

50

element op te geven vermits hier de gemaakte keuzes zullen te vinden zijn in het default

attribuut. Werden er aan de ingeladen DID wijzigingen aangebracht waar de gebruiker

achteraf niet tevreden mee was, dan biedt de knop reload ( ) redding. Drukken op deze

knop heeft als gevolg dat de huidige versie van de actieve gebruikersvoorkeuren volledig

verwijderd wordt en dit bestand heringeladen wordt. Op deze manier zijn alle wijzigingen

tenietgedaan en kan met een propere lei herbegonnen worden.

Naast de in- en uitvoerfuncties zijn er binnen het menu Opties nu nog drie extra functies te

bewonderen. Een eerste is Clear (knop ). Deze functie zal naast alle panelen ook het

volledige GebruikersVoorkeurenObject wissen. We bevinden ons hierdoor weer in de situatie

die we krijgen bij het opstarten van het programma, wanneer er nog geen DIDs ingeladen zijn.

De functie Validate (knop ) zal de geldigheid van de gemaakte keuzes nagaan. Een

gemaakte keuze is geldig als er een correct aantal keuzes gemaakt is (bijvoorbeeld één bij een

SingleSelection). De functie acteert op het niveau van de JAVA-objecten en mag niet verward

worden met het valideren van de keuzes tegenover het XML-schema van MPEG-21 of

tegenover de betekenis van sommige keuzes. Valideren op objectniveau houdt in dat het

aantal keuzes gecontroleerd moet worden. Dit aantal is voor iedere keuze vastgelegd in de

attributen maxSelection en minSelection zoals besproken in 2.2. Een geldige validatie wil

echter niet zeggen dat de gemaakte keuze ook daadwerkelijk een correcte keuze is. De keuze

moet immers achteraf opgeslagen worden in een DID, bijgevolg moet de gemaakte voorkeur

ook valideerbaar zijn tegen het XML-schema van die DID. Validatie tegenover de betekenis

valt niet te controleren in het XML-document en bijgevolg ook niet in het Voorkeurobject.

Semantische validatie behandelt de correctheid van de gekozen opties. Een voorbeeld hiervan

is een quiz. Een quiz valt perfect te modelleren met een MPEG-21 DID: de vragen kunnen

gezien worden als keuzes, multiple choice antwoorden kunnen gezien worden als de

keuzeopties. Het gegeven antwoord is dan hetzelfde als de voorkeur van de gebruiker. Bij een

dergelijke quiz kunnen op een geldige manier verschillende antwoorden gekozen worden.

Deze keuzes zullen dan elk geldig zijn op niveau van de DID en op niveau van de Voorkeur-

objecten, toch bestaat de mogelijkheid dat de gebruiker wel een keuze maakt, maar dat dit een

foutief antwoord op de gestelde vraag is. Dit type fout is dus niet detecteerbaar. Bij het maken

van zo’n quiz zal dus een aparte klasse of API gemaakt moeten worden. Deze maakt gebruik

van Voorkeuren, maar geeft aan de gemaakte keuzes een eigen betekenis. Deze situatie is

vergelijkbaar met de noodzakelijke uitbreidingen op het type van de IntervalVoorkeuren.

51

Binnen het menu Opties rest ons nu nog enkel de functie info (of knop ). Deze functie

zal een venster met informatie over de GebruikersVoorkeuren (dus het hele pakket van

Voorkeuren) te voorschijn toveren. Het gaat hierbij dan om de naam en beschrijving van dit

pakket en nuttige informatie over het aantal ingesloten voorkeuren.

Op de menubalk merken we ook het submenu Look and Feel op. In dit submenu kan de

gebruiker zijn favoriete type GUI kiezen. Het effect hiervan wijst zichzelf uit.

Het menu Venster is echter een stuk interessanter. De inhoud van dit venster wordt gevormd

door de namen van de geopende interne vensters. Deze interne vensters zijn uiteraard de

keuzes. Venster vormt dus ten alle tijden een inventaris van de getoonde keuzes en een

handig hulpmiddel voor gebruikers die het noorden kwijt zouden zijn. Dit vereist natuurlijk

dat de maker van de DID een duidelijke naamkeuze hanteert. Wanneer er geen keuzes

getoond worden, is dit menu uiteraard niet toegankelijk.

Tot slot vermelden we ook nog het menu Help met de functies Contents (ook knop ) en

About (knop ). Contents zal een browservenster oproepen dat zal linken naar de website

horende bij dit afstudeerwerk. Deze website is ook terug te vinden op de CD-ROM. Deze

sectie van dit hoofdstuk kan dus gezien worden als de gebruiksaanwijzing voor het

programma.

52

Hoofdstuk 4 Conclusies en mogelijke uitbreidingen

“If we knew what we were doing, it wouldn't be called research, would it?”

Albert Einstein

4.1 Besluiten

In de voorgaande hoofdstukken is duidelijk geworden hoe we de DID kunnen gebruiken bij

het voorstellen van voorkeuren. De structuur toont zich flexibel genoeg om de basistypes

voorkeuren voor te stellen. Via text/xml Statements wordt de uitbreidbaarheid gewaarborgd.

Deze structuren laten immers om het even welke XML-structuur toe.

De voorkeuren werden geclassificeerd in een algemene structuur waarin de basistypes

voorhanden zijn. De klasse Voorkeur is hier de basisklasse van dit systeem. Deze klasse

omvat dus de basisattributen die voor zullen komen bij elke voorkeur. Tevens is in Voorkeur

ook al een koppelingsmechanisme vastgelegd om afhankelijkheden te respecteren. De

basistypes werden vastgelegd in volgende vier types: SingleSelection, MultipleSelection,

TekstVoorkeur en IntervalVoorkeur. De eerste twee zijn standaard aanwezig binnen DIDL, de

twee laatste werden hieraan toegevoegd met text/xml statements. Deze opsplitsing kan door

middel van overervingen uitgebreid worden tot een diepere classificatie.

Bij het opzetten van een systeem dat voorkeuren kan interpreteren, werd een drielagenmodel

ingevoerd. De onderste laag wordt in dit geval gevormd door de DID. De bovenste laag wordt

gevormd door een GUI-voorstelling van voorkeuren. De communicatie tussen beide lagen zal

gebeuren door een JAVA-objectlaag, waarop alle bewerkingen uitgevoerd zullen worden.

Waar de DID en de objecten min of meer vast liggen, wordt de grafische voorstelling volledig

vrij gelaten aan de programmeur van de applicatie. De gebruikers van dit systeem zijn de

mensen die hun voorkeuren willen kenbaar maken aan zoekrobotten. De gebruikers komen bij

het gebruik van de applicatie enkel in aanraking met de GUI-laag. De DID en de objecten

worden dus volledig afgeschermd, wat uiteraard de bedoeling is.

4.2 Mogelijke uitbreidingen

Wat de mogelijke uitbreidingen betreft, focussen we ons eerst op de structuur van de DID.

Zoals in 2.6 Complexe keuzestructuren aangehaald is, is de DID-structuur niet efficiënt

genoeg om complexere vormen van voorkeuren voor te stellen. Dit is weliswaar mogelijk

53

door een aparte DID in te voegen in een Selection, wat veel overbodig rekenwerk zal

besparen. Het zou ons ook toelaten de mogelijkheden van het framework van Voorkeur-

objecten beter en vollediger te benutten. Een verdere studie van de verwerking van de

beslissingsbomen die gevormd worden door de keuzemogelijkheden binnen DIDL dringt zich

dus op. Indien zou blijken dat de uitbreidbaarheid primeert op de efficiëntie, moet gezocht

worden naar snellere beslissingsalgoritmen om afhankelijkheden op te lossen.

Verder is tijdens het ontwikkelen van de applicatie horende bij dit afstudeerwerk ook

gebleken dat er nood is aan een parser voor DIDs. In de applicatie is een zelfgeschreven

parser verwerkt (misschien wel de eerste parser voor DIDL), maar deze behandelt slechts een

fractie van de taal. Er wordt momenteel vanuit gegaan dat dit programma enkel nodig is voor

de grafische voorstelling van een DID die gebruikersvoorkeuren voor zoekrobotten voorstelt.

Dit laatste heeft als implicatie dat slechts één Item bestaande uit keuzes verwacht. Uiteraard is

de realiteit veel complexer. Een algemene DID kan meerdere Items bevatten en zal ook

meerdere Descriptors bevatten, die daarom niet allemaal door eenzelfde programma begrepen

moeten worden. Tevens zijn ook DIDM elementen als Resource, Override of Anchor niet

aanwezig in deze parser. Het verdient dus aanbeveling dat deze lacune opgevuld wordt: het

ontbreken van een complete DIDL-parser voor eender welke programmeertaal kan de groei en

doorbraak van MPEG-21 zelfs al in zijn beginfase doen afremmen.

We hebben de uitbreidbaarheid van voorkeurtypes binnen de DIDL gedemonstreerd door het

invoeren van niet-standaardtypes als TekstVoorkeur en IntervalVoorkeur. Vooral deze eerste

zou omwille van zijn frequent gebruik in reële situaties eigenlijk ook op een meer

gestandaardiseerde manier ondersteund moeten worden. Wanneer zich nu een nieuw type

Voorkeur of zelfs Description aandient, moet de parser hiervoor (minimaal) aangepast

worden. Ook hiervoor dient een betere, inplugbare manier gevonden te worden, iets wat

vanzelfsprekend vast hangt aan de ontwikkeling van een algemene parser. Waar de drie

gedefinieerde lagen een solide basis vormen voor verder werk, is de communicatie tussen de

lagen onderling soms nog voor verbetering vatbaar.

Op gebied van de objecten in JAVA die Voorkeuren voorstellen, is het geleverde model zeer

compleet en gemakkelijk uitbreiden aanpasbaar. Voor nieuwe types keuzes of voorkeuren

moeten we enkel een nieuwe klasse aanmaken die overerft van één van de al gedefinieerde.

Nu is dus een model geleverd dat Voorkeuren kan opslaan en behandelen. Wanneer het ook

54

nodig is méér met deze Voorkeuren te doen (verwerking, analyse, correctie,…) is het ook

nodig een nieuwe laag bovenop de Voorkeuren te bouwen. Deze nieuwe laag zal dan met de

Voorkeuren communiceren via de algemene functies. Deze kan gebruikt worden voor

bijvoorbeeld de semantische controle van de ingevulde keuzes.

Het niveau van de GUI blijft natuurlijk de figuurlijke speeltuin van de programmeur van

applicaties. Deze kan hierin zijn eigen grafische voorstelling van Voorkeuren vrij bepalen.

Het verdient wel aanbeveling hiervoor eenzelfde UML klassenstructuur te gebruiken als in 3.2

vastgelegd. Dit komt immers de helderheid en uitbreidbaarheid van het ontwerp ten goede.

Het zesde onderdeel van MPEG-21 (Content Representation) zal hierin ook een meer

algemene representatie vastleggen. In deze applicatie is ervoor gekozen het geheel van

GebruikersVoorkeuren vast te leggen als een desktop. De individuele Voorkeuren gedragen

zich dan als aparte entiteiten binnen dit wereldbeeld. Omwille van het feit dat deze

representatie nog niet definitief is en nog niet genoeg voldoet aan de

gebruiksvriendelijkheideisen voor internettoepassingen, werd geen overdreven aandacht

gegeven aan het gedetailleerd uitwerken van dit systeem. De gebruiker van de demoapplicatie

zal het wellicht opgevallen zijn dat het systeem op zich perfect werkt, maar dat nieuwe,

geactiveerde Voorkeuren op soms onlogische posities op de desktop geplaatst worden. Dit

komt door het ontbreken van een communicatiemiddel tussen de desktop en zijn elementen.

Zo’n communicatiemiddel moet dan de vrije posities op de desktop gaan beheren. Dit zou

bijvoorbeeld kunnen met een gelinkte lijst die de begincoördinaten van die posities gaat

bijhouden. Door de onbekende inhoud en voorstelling van de inhoud van Voorkeuren

volstaan begincoördinaten alleen niet, ook hoogte en breedte moeten bewaard worden. Het

spreekwoordelijke addertje onder het gras wordt gevormd door de context. De gebruiker

verwacht immers dat een nieuwe Voorkeur, die afhankelijk was van een ander gemaakte

keuze, in de buurt van zijn ouder zal verschijnen. Deze gegevens maken het probleem

complexer dan dat het op het eerste zicht zou lijken. Aangezien het ontbreken van dit

communicatiemiddel geen enkele invloed heeft op de eigenlijke werking van het programma,

enkel op de grafische vormgeving en het gebruiksgemak, werd dan ook besloten dit als

mogelijke verdere uitbreiding te voorzien.

55

Appendix A: XML

“The 'Net is a waste of time, and that's exactly what's right about it.”

William Gibson

XML komt in onze opleiding slechts oppervlakkig aan bod. Gezien de MPEG-21 DIDL een

taal gebaseerd op XML is, werd een kleine introductie voorzien.

XML

XML staat voor eXtensible Markup Language en wordt beschreven in [9]. De XML syntax is

gelijkaardig aan de HTML-syntax, toch zijn er enkele belangrijke verschillen:

• Elk element heeft een begintag en een eindtag. Tussen de begin- en eindtag kan tekst

staan. Elementen moeten, in tegenstelling tot HTML steeds gesloten worden. <element>tekst</element>

• Indien er geen tekst aanwezig is kunnen we

<element></element> noteren als

<element />

• Een element kan ook attributen hebben, deze bestaan steeds uit een naam en een

waarde ingesloten door dubbele aanhalingstekens (””). De attributen komen steeds

voor in de begin-tag van een element.

<element attribuutnaam=”attribuutwaarde” />

• XML is case sensitive.

Belangrijk bij de omzetting van XML naar JAVA-objecten is het valideren van het XML-

document. Valideren is het controleren van de correctheid. Een eerste validatie-aspect is well-

formedness. Een document is goed gevormd als al zijn elementen voldoen aan volgende

voorwaarden:

• De eindtag komt na de begintag.

• De begin- en eindtag van een element moeten zich beiden binnen hetzelfde

ouderelement bevinden

• Het element is geldig. (bezit begin-tag en eind-tag, attribuutwaarden staan tussen

quotes,…)

• De inhoud van een element mag niet bestaan uit opmaakkarakters als <,>,&,…

56

Enkele voorbeelden:

• <voornaam>Tim<familienaam></voornaam>Combel</familienaam> is fout

• <voornaam>Tim</voornaam><familienaam>Combel</familienaam> is correct

• <naam><voornaam>Tim</naam></voornaam> is fout

• <naam><voornaam>Tim</voornaam></naam> is correct

Een tweede validatie-aspect is grammer validation of validatie van de grammatica. Een XML-

document is geldig als het de juiste elementen bevat, in de juiste volgorde, met correcte

inhoud,…

XML-Schema

De grammatica van XML wordt beschreven in een DTD of een XML-Schema. In dit geval is

enkel het XML-Schema van belang gezien dit in [1] en [2] meegegeven is voor de definitie

van DIDL.

Een XML-Schema definieert:

• De elementen en attributen die kunnen voorkomen in een document.

• De volgorde en het aantal kindelementen van een ouder.

• Of de inhoud van een element leeg kan zijn of tekst moet bevatten.

• Datatypes en standaardwaarden voor elementen en attributen.

Een XML-Schema is zelf ook een XML-document met voorafbepaalde elementen en

attributen. XML-Schema wordt beschreven in [10]. Zeer bondig samengevat bestaat XML-

Schema uit volgende elementen:

• Root element Schema met namespace http://www.w3.org/2001/XMLSchema

• element: het eigenlijke taalelement

• attribute: de definitie van een attibuut bij een element

• complexType: de definitie van een groep elementen of attributen. Om meerdere

subelementen bij een ouderelement toe te voegen gebruikt men een combinatie van

complexType en het taalwoord sequence of choice. Sequence toont alle mogelijke

kinderen van een element, bij choice is slechts één keuze uit een lijst opties mogelijk.

• simpleType: een definitie van een specialisatie van een bestaand type.

• minOccurs en maxOccurs zijn attributen die de hoeveelheid elementen van een

beschreven type onder controle kunnen houden.

Op de verdere vorm van XML-Schema zullen we hier niet verder ingaan.

57

Namespaces

Er rest ons nu enkel nog namespaces in te leiden. Een namespace is een groep elementen

attribuutnamen. Per element kan bepaald worden tot welke namespace het behoort en tegen

welk schema het gevalideerd moet worden. Namespaces dienen dus vooral om elementen op

een logische manier te groeperen en zo conflicten op te lossen wanneer de betekenis van

bepaalde tags niet duidelijk is.

Een element met namespace wordt als volgt genoteerd:

namespace-prefix:naam

Het geheel van namespace-prefix en lokale naam wordt ook “qualified name” genoemd.

Wanneer een element geen namespace-prefix draagt, wordt de standaard namespace

verondersteld. De URI waar het XML-Schema, horende bij deze namespace, te vinden is

moet natuurlijk ook aangegeven worden. Dit wordt namespace declaratie genoemd en gebeurt

als volgt: xmlns:namespace-prefix=”URI”

De declaratie van een namespace kan gebeuren in om het even welk element, maar meestal

wordt hiervoor het rootelement gebruikt. Binnen een DID is de standaard namespace

natuurlijk steeds deze die gedefinieerd is door het XML-Schema van DIDL. Toch kunnen er

ook andere namespaces aanwezig zijn bijvoorbeeld voor speciale types beschrijvingen,

speciale keuzestructuren, enz.

58

Appendix B: UML

“Programming today is a race between software engineers striving to build bigger

and better idiot-proof programs, and the Universe trying to produce bigger and better

idiots. So far, the Universe is winning.”

Rich Cook

UML staat voor Unified Modelling Language en is de standaardmanier geworden waarop

diagrammen worden getekend waarmee objectgeoriënteerde onderwerpen worden

beschreven. Voor het modelleren van de voorkeuren en ook voor de rest van de gemaakte

applicatie werd dan ook gretig gebruik gemaakt van deze techniek. Voor de UML

diagrammen in de tekst werd gebruik gemaakt van het programma Microsoft Visio. De enige

afwijking van de UML standaard is dat de namen van abstracte klassen schuin worden

gedrukt. In standaard UML gebeurt dit normaal door het taalwoord {abstract} aan het model

toe te voegen.

Voor dit afstudeerwerk is het niet nodig een volledige kennis van UML te hebben. We zullen

hier ingaan op de essenties van klassendiagrammen. Klassendiagrammen vormen de basis

van vrijwel elke OO-methode. Een klassendiagram beschrijft de typen objecten die een

systeem kent en laat zien welke statische relaties tussen de objecten bestaan. Hierin bestaan er

twee types: de associatie (een klant koopt een product) en de subtypen (een student is een

klant). Naast de relaties worden in een klassendiagram ook de attributen en bewerkingen van

de klasse weergegeven, samen met de beperkingen die van toepassing zijn op de verbinding

van de objecten.

Naast klassendiagrammen komen in de tekst ook packagediagrammen voor. De

voorstellingswijze van deze diagrammen is echter volledig analoog aan deze van

klassendiagrammen. Packagediagrammen worden gebruikt om een functionele decompositie

van een groep klassen voor te stellen.

Op de volgende bladzijde zullen we het klassendiagram inleiden aan de hand van een alles

omvattend voorbeeld.

59

Figuur 23 Voorbeeld klassendiagram UML

• Class A is een klasse met attributen (something) en functies (function). Bij de

attributen slaat de + op public attributen, # op protected en – op private.

• Class A is de ouder van Class C. De pijl met de driehoek stelt een generalisatie voor:

alle attributen en functies van Class A worden overgeërfd door Sub-Class. Wanneer

een klasse abstract is zal zijn naam cursief geschreven worden.

• Interface Class I is een interface. Tussen de klasse die de interface zal

implementeren (Class C) en de interface zelf zal opnieuw een pijl lopen. Bij

interfaces zal deze pijl een stippellijn zijn en wordt dit een realisatie genoemd.

• Class A is geassocieerd met Class B. In dit geval is slechts 1 Class B geassocieerd

met meerdere versies van Class A (aangegeven door 1 en *). De naam van de

associatie is something.

• Class T is een template klasse.

• De relatie tussen Class B en Class T wordt een afhankelijkheid genoemd. Hier wil

<<Bind>> duidelijk maken dat de parameter T van het type int moet zijn. Andere veel

voorkomende afhankelijkheden zijn <<Uses>> (de ene klasse maakt gebruik van de

andere) en <<Creates>> (de ene klasse maakt een object van de andere klasse aan).

• AssociationClass1 is een klasse die attributen of functies kan toevoegen aan de

associatie tussen Class B en Class C.

60

Appendix C: Uitgewerkt voorbeeld

“We must know, we shall know”

-Hilbert

We geven hieronder eerst de voorstelling van een DID, voorzien van commentaar. Deze DID

beschrijft een digitaal muziekalbum en is ook terug te vinden in [2]. We zullen omwille van

de eenvoud ons enkel concentreren op de Choices d.w.z. dat we Items met Resources

verwijderd hebben uit dit voorbeeld evenals Descriptions in niet ondersteunde talen (als

RDF), gezien deze toch niet relevant zijn voor het onderzochte probleem. Het volledige

bestand is terug te vinden op de CDROM onder de naam “alwaysred.did”.

De DID

De DID start met het rootelement DIDL waarin ook de gebruikte namespaces zijn opgegeven.

<?xml version="1.0"?> <DIDL xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cr="http://www.music-ratings.org/Content-Ratings-Scheme" xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" xmlns:profile="urn:mpeg:mpeg21:example: Profile-Specs" xmlns="urn:mpeg:mpeg21:2002/01-DIDL-NS">

Het document bestaat uit een container van elementen. Deze elementen of Items bevatten de

keuzestructuren of de resources. Er wordt gestart met een algemene beschrijving voor het

geheel. Dit is de beschrijving van de GebruikersVoorkeur. <Container> <Descriptor> <Statement type="urn:mpeg:mpeg21:did/statement-types/text/plain">

This is a package for John Q. Consumer. This package was provided by Digital Music Unlimited.

</Statement> </Descriptor> <Item>

De eerste keuze vraagt de gebruiker naar het gebruikte besturingssysteem. Windows, Linux

en Mac worden als keuze aangeboden. Gezien de beschrijving van de keuzeopties gedaan

wordt in een onbekend XML-formaat (van de onbekende namespace profile) zullen bij een

grafische voorstelling de namen van de keuzeopties gebruikt worden als beschrijving. Zowel

minSelections als maxSelections zijn hier gelijk aan 1, we hebben dus te doen met een

SingleSelection.

61

<Choice choice_id="PLATFORM_CHOICE" minSelections="1" maxSelections="1"> <Selection select_id="PLATFORM_WINDOWS" /> <Selection select_id="PLATFORM_LINUX" /> <Selection select_id="PLATFORM_MAC" /> </Choice>

De tweede keuze laat de gebruiker toe te bepalen of hij zijn muzieknummers zelf wil kiezen.

Hier zien we een statement van het type text/plain. Dit is ons bekend en zal dan ook letterlijk

getoond worden. Gezien in de Choice geen aanwijzingen voorkomen met betrekking tot het

aantal mogelijke keuzes, is dit een MultipleSelection.

<Choice choice_id="ALL_SONGS" > <Selection select_id="PICK_SONGS"> <Descriptor> <Statement type="text/plain"> I want to choose among the individual songs. </Statement> </Descriptor> </Selection> </Choice>

De twee vorige keuzes bevatten geen speciale Conditions. Dit wil dus zeggen dat zij steeds

getoond moeten worden in een grafische omgeving. Bij de volgende keuze is dit niet het

geval. Deze keuze mag enkel aangeboden worden als het predikaat PICK_SONGS uit de vorige

keuze aangeklikt is. Deze keuze laat dus toe dat de gebruiker zijn liedjes individueel kan

kiezen. Dit is een voorbeeld van een Condition op keuzeniveau. We merken hier ook het

gebruik van een default attribuut in de Choice op. In dit attribuut staan de keuzeopties die

standaard geselecteerd zijn. In de Selections waren nog Descriptors terug te vinden met als

inhoud een Reference. Dit type wordt echter nog niet vertaald door de parser. Als beschrijving

nemen we opnieuw de naam van de Selection. <Choice choice_id="SONG_PICKER" default="SONG1 SONG2 SONG3 SONG4"> <Condition require="PICK_SONGS"/> <Descriptor> <Statement type="text/plain"> Choose the songs you would like: </Statement> </Descriptor> <Selection select_id="SONG1" /> <Selection select_id="SONG2" /> <Selection select_id="SONG3" /> <Selection select_id="SONG4" /> </Choice>

In de volgende keuze (een keuze van de bitrate) zien we hoe Descriptors met tekst zowel

gebruikt kunnen worden bij het beschrijven van een keuze als bij het beschrijven van een

62

keuzeoptie. De namen zullen nu nog enkel gebruikt worden bij de interne communicatie

tussen de verschillende voorkeuren.

<Choice choice_id="BITRATE_CHOICE" default="LOW_BITRATE" minSelections="1" maxSelections="1"> <Descriptor> <Statement type="urn:mpeg:mpeg21:did/statement-types/text/plain"> Please select the fidelity you would prefer. </Statement> </Descriptor> <Selection select_id="LOW_BITRATE"> <Descriptor> <Statement type="urn:mpeg:mpeg21:did/statement-types/text/plain"> Low (128 Kbits/sec, $10.00). </Statement> </Descriptor> </Selection> <Selection select_id="HIGH_BITRATE"> <Descriptor> <Statement type="urn:mpeg:mpeg21:did/statement-types/text/plain"> High (192 Kbits/sec, $15.00). </Statement> </Descriptor> </Selection> </Choice>

Volgende keuze is opnieuw een standaardkeuze met een vraag naar extra content. Deze keuze

introduceert echter niets nieuws. <Choice choice_id="EXTRA_CONTENT_CHOICE" minSelections="1" maxSelections="1"> <Descriptor> <Statement type="urn:mpeg:mpeg21:did/statement-types/text/plain"> Would you like to get supplemental content for this album? </Statement> </Descriptor> <Selection select_id="WANT_EXTRA_CONTENT"> <Descriptor> <Statement type="urn:mpeg:mpeg21:did/statement-types/text/plain"> Yes, get all of the supplemental content. </Statement> </Descriptor> </Selection> <Selection select_id="ASK_EXTRA_CONTENT"> <Descriptor> <Statement type="urn:mpeg:mpeg21:did/statement-types/text/plain"> Yes, but let me choose which items to get. </Statement> </Descriptor> </Selection> <Selection select_id="DONT_ASK_ABOUT_CONTENT"> <Descriptor> <Statement type="urn:mpeg:mpeg21:did/statement-types/text/plain"> No, I don't want any of the extra stuff. </Statement> </Descriptor> </Selection> </Choice>

63

Keuze COVER_ART_CHOICE is dan een stuk complexer. Deze keuze mag enkel getoond worden

wanneer de gebruiker vroeg om extra content. Ze bevat vier verschillende keuzeopties. Toch

zullen deze niet altijd gezamenlijk getoond worden. Selection GET_VIDEO bevat immers

Conditions op niveau van de keuzeoptie. In dit geval wil dit zeggen dat deze keuzeoptie enkel

getoond mag worden indien de gebruiker als besturingssysteem Windows of Mac opgegeven

heeft. Linuxgebruikers zullen deze keuze dus niet te zien krijgen.

<Choice choice_id="COVER_ART_CHOICE" minSelections="1" maxSelections="1"> <Condition require="ASK_EXTRA_CONTENT"/> <Descriptor> <Statement type="urn:mpeg:mpeg21:did/statement-types/text/plain"> Supplemental content: </Statement> </Descriptor> <Selection select_id="GET_ART"> <Descriptor> <Statement type="urn:mpeg:mpeg21:did/statement-types/text/plain"> Include the cover art. </Statement> </Descriptor> </Selection> <Selection select_id="GET_LYRICS"> <Descriptor> <Statement type="urn:mpeg:mpeg21:did/statement-types/text/plain"> Include the song lyrics. </Statement> </Descriptor> </Selection> <Selection select_id="GET_VIDEO"> <Condition require="PLATFORM_WINDOWS"/> <Condition require="PLATFORM_MAC"/> <Descriptor> <Statement type="urn:mpeg:mpeg21:did/statement-types/text/plain"> Include video footage from the latest concert. </Statement> </Descriptor> </Selection> <Selection select_id="GET_REVIEWS"> <Descriptor> <Statement type="urn:mpeg:mpeg21:did/statement-types/text/plain"> Include press reviews. </Statement> </Descriptor> </Selection> </Choice>

Ook onze voorlaatste keuze (een vraag naar het beeldformaat van de foto’s) geeft ons een

duidelijk beeld van de werking van Conditions op de verschillende lagen van een keuze.

<Choice choice_id="IMAGE_FORMAT_CHOICE" default="JPEG_IMAGE"> <Condition require="GET_ART"/> <Condition require="WANT_EXTRA_CONTENT"/> <Selection select_id="JPEG_IMAGE" /> <Selection select_id="GIF_IMAGE" />

64

<Selection select_id="BMP_IMAGE"> <Condition require="PLATFORM_WINDOWS"/> </Selection> </Choice>

De laatste voorkeur biedt ons nog een nieuwigheid. Deze is terug te vinden in de Conditions.

Naast de require voorwaarde is nu ook een except voorwaarde aanwezig. Wanneer eerder

de keuze GET_ART of WANT_EXTRA_CONTENT gekozen werd, moet de nieuwe keuze getoond

worden, BEHALVE wanneer BMP_IMAGE als beeldformaat gekozen werd. De gebruiker kan

dus vrij de grootte van zijn foto’s kiezen, behalve indien hij BMP als beeldformaat wou. Deze

beperking kan bijvoorbeeld betekenen dat er slechts één grootte beschikbaar is bij het BMP-

formaat.

<Choice choice_id="IMAGE_SIZE_CHOICE" default="LARGE_IMAGE"> <Condition require="GET_ART" except="BMP_IMAGE"/> <Condition require="WANT_EXTRA_CONTENT" except="BMP_IMAGE"/> <Descriptor> <Statement type="urn:mpeg:mpeg21:did/statement-types/text/plain"> Please select the image size you would like: </Statement> </Descriptor> <Selection select_id="LARGE_IMAGE"> <Descriptor> <Statement type="urn:mpeg:mpeg21:did/statement-types/text/plain"> Large (301x300) </Statement> </Descriptor> </Selection> <Selection select_id="SMALL_IMAGE"> <Descriptor> <Statement type="urn:mpeg:mpeg21:did/statement-types/text/plain"> Small (130x130) </Statement> </Descriptor> </Selection> </Choice>

Tot slot worden de elementen nog afgesloten.

</Item> </Container> </DIDL>

De beslissingsboom en JAVA-objectvorm

We hebben nu de relevante elementen van de DID ingelezen. Deze zullen omgezet worden in

JAVA-Objecten van het type Voorkeur. In dit geval hebben we te maken met één

GebruikersVoorkeur, die bestaat uit acht verschillende Voorkeuren. Binnen die acht

Voorkeuren bestaat de helft uit SingleSelections en de andere helft uit MultipleSelections.

Alle Conditions en Options zullen nu mooi in de hiertoe voorziene ruimtes van het type

65

Voorkeur ingevuld worden. De laatste stap is dan de eigenlijke omzetting van de objecten

naar hun grafische voorstelling. In de volgende figuur staat dan de beslissingstructuur van

deze DID.

De drie verschillende lagen zijn duidelijk herkenbaar. We stellen een proces voor door een

rechthoek. De processen op niveau van de GUI bestaan dan uit het tonen van de verschillende

keuzes. We zien hierbij hoe vier van de acht keuzes automatisch opgeroepen worden. Elke

actie (selecteren of deselecteren van een keuzeoptie) veroorzaakt een interactie met het

JAVA-Object niveau waar de Voorkeuren verwerkt worden. Om het schema duidelijk te

houden is ervoor gekozen enkel deze acties weer te geven die in een Condition verwerkt

zitten. Bij elke actie moeten de condities dus gecontroleerd worden. Dit gebeurt opnieuw op

niveau van de Objecten. Elk predikaat, verwerkt in een Condition werd hier weergegeven als

een ruit. Afhankelijk van de test van het predikaat gebeurt er een actie op niveau van de GUI.

Wanneer het predikaat PICK_SONGS waar is (PICK_SONGS werd dus geselecteerd in

ALL_SONGS), moet de keuze SONG_PICKER getoond worden door de GUI, enz.

Parallellogrammen stellen opties binnen een keuze voor. Deze opties zijn opnieuw

Conditioneel, de andere opties worden steeds getoond. Ook de verwerking van de

conditionele opties gebeurt bij de JAVA-Objecten. Dat deze beslissingen zeer complex

kunnen worden, wordt aangegeven door de conditionele keuze IMAGE_SIZE_CHOICE. Om

deze keuze te tonen moeten eerst de predikaten WANT_EXTRA_CONTENT en GET_ART

geëvalueerd worden. Bij een positief antwoord moet dan nog BMP_IMAGE extra in rekening

gebracht worden.

Hoe dit voorbeeld er uiteindelijk grafisch zal uitzien was al terug te vinden in Figuur 20.

66

Figuur 24 Beslissingsstructuur van alwaysred.did

67

Appendix D: Inhoud van de CD-ROM

Als afsluiter geven we nog even de inhoud van de CD-ROM mee:

• In de root directory is index.html te vinden. Dit is de homepage voor de website.

• Subfolder application:

• Hierin staan de bestanden nodig bij het uitvoeren van het programma. Voor de

gebruiksaanwijzingen verwijzen we naar 3.3.

• Subfolder scr: de JAVA – bronbestanden.

• Subfolder class: de gecompileerde code.

• Subfolder zip: een verzameling van gezipte bestanden. De naamgeving komt

overeen met de map die ze bevatten. Application.zip zal bijvoorbeeld het

volledige programma bevatten,…

• Subfolder doc: JAVADOC bestanden van het programma.

• Subfolder examples: voorbeelden van DID’s die gebruikt kunnen worden bij het

uitproberen van het programma.

• Subfolder website: Bevat de volledige website horende bij het programma. Hier zijn

links voorzien naar de bovengenoemde mappen en naar de gebruiksaanwijzing.

• Subfolder tekst: Bevat de tekst van dit document in verschillende digitale formaten

(word, pdf, html).

68

Referenties

[1] V. IVERSON, Y.-W. SONG, R. VAN DE WALLE, M. ROWE, D. CHANG, E.

SANTOS, T. SCHWARTZ, MPEG-21 Digital Item Declaration WD (v2.1), ISO/IEC

JTC1/SC29/WG11 MPEG2001/7174, Sydney(2001).

[2] T. SCHWARTZ, V. IVERSON, Y.-W. SONG, R. VAN DE WALLE, D. CHANG, E.

SANTOS, MPEG-21 Digital Item Declaration FCD, ISO/IEC JTC 1/SC 29/WG 11

N4530, (2001).

[3] C. BADEAUX, Netscape's software coding standards guide for JAVA, Technology

Evangelist, http://developer.netscape.com/docs/technote/java/codestyle.html, (1998).

[4] K. STANOEVSKA, A. HOMBRECHER, S. HANDSCHUH, B. SCHMID, Efficient

Information Retrieval: Tools for Knowledge Management, Institute for Media and

Communications Management, University of St. Gallen (1998).

[5] S. LAWRENCE, C.L. GILES, Inquirus, the NECI Meta Search Engine. Proceedings of

The Seventh International World Wide Web Conference (1998), 95-105.

[6] S. LAWRENCE, E. GLOVER, J. ERIC, W.P. BIRMINGHAM, C.L. GILES,

Architecture of a Metasearch Engine that Supports User Information Needs, Eighth

International Conference on Information and Knowledge Management ({CIKM}'99)

(1999) 210-216.

[7] S. LAWRENCE, C.L. GILES, Context and Page Analysis for Improved Web Search.

IEEE Internet Computing, (2)4 (1998), 38-46.

[8] S. LAWRENCE, E. GLOVER, G. FLAKE, W.P. BIRMINGHAM, A. KRUGER, C.L.

GILES, D. PENNOCK, Improving Category Specific Web Search by Learning Query

Modifications, Symposium on Applications and the Internet, {SAINT} (2001) 23-31.

[9] Extensible Markup Language 1.0 (Second Edition), W3C Recommendation,

http://www.w3.org/TR/2000/REC-xml-20001006, (2000).

[10] XML Schema Part 1: Structures and Part 2: Datatypes, W3C Recommendation,

http://www.w3.org/TR/2001/REC-xmlschema-1-20010502,

http://www.w3.org/TR/2001/REC-xmlschema-2-20010502, (2001).

[11] The official website for SAX, http://www.saxproject.org/

69

Algemene Bibliografie

Werken i.v.m. het classificeren van voorkeuren en webpagina’s:

[12] C. CHEKURI, M. GOLDWASSER, P. RAGHAVAN, E. UPFAL, Web search using

automatic classification. Sixth World Wide Web Conference (1996).

[13] C. KURZKE, M. GALLE, M. BATHELT, WebAssist: a user profile specific information

retrieval assistant. Computer Networks and ISDN Systems ,30 (1998), 654-655.

[14] Website Open Directory Project, http://dmoz.org/

Werken i.v.m. MPEG-21:

[15] MPEG-21 Use Case Scenarios v2.0, ISO/IEC JTC1/SC29/WG11/N4330, Sydney (2001).

[16] J. BORMANS (IMEC), MPEG-21 Requirements v 1.0, ISO/IEC JTC1/SC29/WG11

N4681, Jeju (2002).

[17] J. BORMANS, N. RUMP, Updated Study on MPEG-21 (Digital Audiovisual

Framework) Part 1 v2.0, ISO/IEC JTC1/SC29/WG11/N7225, Sydney (2001).

Werken i.v.m. XML:

[18] E.T. Ray, Learning XML, O’Reilly, Sebastopol, 2000, 354 p.

[19] Validating XML, developerWorks, ibm.com/developerWorks.

Werken i.v.m. JAVA:

[20] J.W. COOPER, The Design Patterns JAVA Companion, Addison-Wesley, (1998), 218 p.

[21] JAVA look and feel design guidelines, SUN MICROSYSTEMS, INC.,

http://java.sun.com/products/jlf/ed1/dg/index.htm, (2001).

[22] B. ECKEL, Thinking in Java, http://www.mindview.net, (2000).

[23] K. COOLSAET, Programmeren van GUIs met Java Swing, cursus Programmeren II,

Universiteit Gent, (2001).

Werken i.v.m. XML-JAVA interactie:

[24] R. HUSTEAD, Mapping XML to Java, http://www.javaworld.com/javaworld/jw-08-

2000/jw-0804-sax.html.

[25] R. G. BALDWIN, XML to Objects and Objects to XML using SAX,

http://home.att.net/~baldwin.rick/Advanced/Java826.htm.

70

[26] E. ARMSTRONG, Working with XML: The Java API for Xml Processing (JAXP)

Tutorial, http://java.sun.com/xml/jaxp/dist/1.1/docs/tutorial/index.html, (2001).

[27] E. R. HAROLD, Processing XML with Java,

http://www.cafeconleche.org/books/xmljava/chapters/index.html, 2002

[28] Xerces2 JAVA parser, http://xml.apache.org/xerces2-j/index.html

[29] S. HEINTZE , T. WREIGHT, XML Programming using JAVA, ITcourseware,

Englewood, (2002)

[30] D. TIDWELL, Tutorial: XML programming in Java, Cyber Evangelist, developerWorks

XML Team, (1999).

[31] Understanding SAX, developerWorks, ibm.com/developerWorks.

Andere:

[32] M. FOWLER, S. KENDALL, UML bekopt, Addison-Wesley, Zeist (2000), 181 blz.

[33] G. MOUTY, Literature Review on User-friendly interface design, UNED-UK's

Stakeholder Toolkit, (1999).

71

Figuren en tabellen

Figuur 1 Productie efficiëntie en gebruikersefficiëntie.............................................................. 3

Figuur 2 De zeven onderdelen van MPEG-21 ........................................................................... 8

Figuur 3 Combineren van zoekquery met voorkeuren............................................................. 11

Figuur 4 N-dimensionale voorstelling van voorkeuren (N=2)................................................. 13

Figuur 5 Schematische voorstelling van het zoeken met behulp van voorkeuren ................... 15

Figuur 6 Schematische voorstelling van de verschillende lagen binnen de applicatie ............ 17

Figuur 7 UML voorstelling van de klasse Preference.............................................................. 18

Figuur 8 Grafische voorstellingen van SingleSelection........................................................... 23

Figuur 9 Grafische voorstellingen van een MultipleSelection................................................. 24

Figuur 10 Grafische voorstellingen van een TekstVoorkeur ................................................... 27

Figuur 11 Voorstelling van intervalvoorkeuren....................................................................... 29

Figuur 12 Voorbeeld samengestelde voorkeur ........................................................................ 30

Figuur 13 UML voorstelling van de klasse UserPreferences................................................... 33

Figuur 14 Structuur van de SAX-parser................................................................................... 37

Figuur 15 Algemene programmastructuur in UML................................................................. 38

Figuur 16 UML voorstelling van het package preferences...................................................... 40

Figuur 17 UML voorstelling van het package preferencesGUI............................................... 42

Figuur 18 UML voorstelling van het package preferencesMapper ......................................... 44

Figuur 19 Startsituatie programma .......................................................................................... 45

Figuur 20 Het paneel Preferences en de grafische voorstelling van enkele keuzes................. 47

Figuur 21 Het paneel Source en de XML-boom van de ingeladen DID.................................. 48

Figuur 22 Het paneel Editor met de tekstuele voorstelling van de DID .................................. 49

Figuur 23 Voorbeeld klassendiagram UML ............................................................................ 59

Figuur 24 Beslissingsstructuur van alwaysred.did................................................................... 66

Universiteit Gent Faculteit Toegepaste Wetenschappen...

Documents

Transcript of Universiteit Gent Faculteit Toegepaste Wetenschappen...