Post on 14-Oct-2020
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
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 beeld- en 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 uitbreid- en 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 element- en
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