kennisgebaseerde gui generatoren voor de gezondheidszorg · heid en het vertrouwen zelf het...

Faculteit Ingenieurswetenschappen

Vakgroep Telecommunicatie en Informatieverwerking

Voorzitter: Prof. Dr. Ir. H. Bruneel

Kennisgebaseerde GUI generatoren

voor de gezondheidszorg

door

Lennert Acke

Promotor: Prof. Dr. G. De Tre

Scriptiebegeleiders: Dr. D. Colaert MD, Ir. J. Deroo, Ir. T. Matthe

In samenwerking met Agfa HealthCare

Scriptie ingediend tot het behalen van de academische graad van

Burgerlijk Ingenieur in de Computerwetenschappen

optie Informatie- en Communicatietechnologie

Academiejaar 2006–2007

Voorwoord

Deze scriptie vormt de thesis van mijn opleiding tot ingenieur aan de Univer-

siteit Gent. Zij kwam tot stand dankzij de hulp en de steun van vele mensen.

Ik zou bij deze dan ook graag iedereen bedanken die zijn steentje, hoe klein

ook, het voorbije jaar heeft bijgedragen. In het bijzonder verdienen enkele

mensen een speciale vermelding.

In de eerste plaats wens ik prof. Guy De Tre te bedanken. Hij gaf mij de vrij-

heid en het vertrouwen zelf het onderwerp voor deze scriptie aan te brengen

en was bereid mijn promotor te zijn voor dit onderzoek. Ook Dirk Colaert

wil ik bedanken, die mij voor het eerst introduceerde tot het semantisch web

en wiens advies bepalend was voor het onderwerp van dit onderzoek.

Een speciale vermelding verdient ook Jos De Roo. Jos, bedankt voor de vele

wijze raad en tips die je me gaf bij het ontwikkelen, je onverminderde ambitie

om mij de nuances van het semantisch web bij te brengen en je enthousiasme

voor nieuwe technologie. Zonder jouw begeleiding en ‘vaderlijke’ bemoedi-

gingen was ik er waarschijnlijk niet in geslaagd deze thesis tot een goed einde

te brengen. Ook wil ik Tom Matthe bedanken, voor de tips en begeleiding

die hij me het voorbije jaar gaf.

Er zijn nog 2 mensen die, na 24 jaar zorg en toewijding, een speciaal woord

van dank verdienen. Papa, mama, bedankt voor alles wat jullie voor mij

gedaan hebben. Bedankt voor me de kans te geven te studeren en me al die

jaren te steunen en voor mij te zorgen. Charlotte, ook jou wil ik bedanken

voor alle liefde die je me elke dag geeft sinds ik je heb leren kennen.

Tot slot wens ik nog iedereen te bedanken die meegeholpen hebben om de-

ze scriptie zorgvuldig na te lezen op fouten. Papa, mama, Els, Charlotte,

. . . bedankt !

Lennert Acke, juni 2007.

Toelating tot bruikleen

“De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te

stellen en delen van de scriptie te kopieren voor persoonlijk gebruik.

Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bij-

zonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden

bij het aanhalen van resultaten uit deze scriptie.”

Lennert Acke, juni 2007

Kennisgebaseerde

GUI generatoren

voor de gezondheidszorgdoor

Lennert Acke

Scriptie ingediend tot het behalen van de academische graad vanBurgerlijk Ingenieur in de Computerwetenschappen:

optie Informatie- en Communicatietechnologie

Academiejaar 2006–2007

Promotor: Prof. Dr. G. De TreScriptiebegeleiders: Dr. D. Colaert MD, Ir. J. Deroo, Ir. T. Matthe

In samenwerking met Agfa HealthCare

Faculteit IngenieurswetenschappenUniversiteit Gent

Vakgroep InformatietechnologieVoorzitter: Prof. Dr. Ir. H. Bruneel

Samenvatting

In deze scriptie onderzoeken we hoe we de generatie van grafische gebrui-kersinterfaces door te redeneren over verschillende bronnen van kennis enregels kunnen vereenvoudigen. Hiervoor gebruiken we technologieen die involle ontwikkeling zijn in het kader van het semantisch web, zoals RDF enN3Logic.

We bewijzen door een demonstratiemodel dat op redeneren-gebaseerde GUIgeneratie een duidelijk voordeel biedt t. o. v. de traditionele methode. Ditalles gebeurt in samenwerking met het bedrijf Agfa HealthCare in de contextvan de gezondheidszorg.

Trefwoorden

semantisch web, grafische gebruikersinterface, reasoning

Knowledge based GUI generatorsin the healthcare industry

Lennert Acke

Supervisor(s): Guy De Tre, Dirk Colaert, Jos De Roo, Tom Matthe

Abstract—This article gives a general approach to introducing reasoningin the generation of graphical user interfaces by making use of semanticweb technologies such as RDF in [1] and N3Logic in [2]. The approach isthen illustrated with a proof-of-concept based on a typical use case for thehealthcare industry.

Keywords—Semantic web, RDF, N3Logic, reasoning, GUI, Agfa, health-care

I. INTRODUCTION

TODAY , the implementation and design of graphical userinterfaces is not a straightforward task. Software develop-

ers have to design graphical user interfaces for a variety of users,a variety of tasks and a variety of heterogeneous platforms. Fur-thermore, a developer needs be aware of a rising number of userdesign parameters, such as company guidelines, usability pat-terns and accessibility constraints. Needless to say, developmentand maintenance costs rise due to this increasing developmentcomplexity.

On the other hand, last years have showed an increasing re-search interest in so-called semantic web technologies. Seen asthe successor to the World Wide Web, the ambition of the se-mantic web is to provide a web of machine-accessible data withformalised semantics. The foundations for these technologiesare being laid by the World Wide Web Consortium, standard-izing technologies such as RDF, RDF-S, OWL, RIF, . . . Also,several reasoners (such as Euler) have been developed, enablingusers (and machines) to reason over knowledge declared usingthose technologies.

In this abstract, we claim that the concept of using reasoningcan be introduced in the process of GUI generation, with theultimate goal of making the task of software developers lighterand their labour less error-prone. We propose a model whereinmuch of the knowledge developers need to take into account canbe explicitly declared using ontologies and rules. We then usereasoning software such as Euler to generate custom graphicaluser interfaces, based on an abstract GUI description.

II. USE CASE

In healthcare, the well-being of the patient is key. It is there-fore imperative that health care workers always have access tocorrect and relevant information. Furthermore, the presentationof this information can be different for every user, based on theuser’s context, the organisation the user operates in, the role ofthe user and finally the user’s preferences. Adapting the presen-tation based on the needs of the user is important to guaranteeefficiency.

We define an application in which a GUI form needs topresent information of administrative and clinical nature. This

information also needs to be processed by the user. As an exam-ple of clinical information, symptoms such as blood pressure,body temperature and pulse need to be recorded. If however, apatient needs several examinations for different reasons, similarsymptoms must only be presented and processed once.

The form also needs to be dependent of the context of theuser, which comprises the user’s environment, the platform andthe device the user is running. Equally important is the fact thatthe form needs to be adapted to the user’s preferences and to theguidelines of the organisation in which the user operates.

III. GENERAL APPROACH

A. Knowledge domain vs. Execution domain

The introduction of the notion “knowledge” in the world ofgraphical user interfaces introduces a declarative concept in anotherwise very procedural world. In the traditional way, the de-velopment of GUI’s is associated with programming languagessuch as C, C++, C#, JAVA, etc. In these procedural languages,the behaviour of a function is described in a list of sequentialactions, such as function calls, assignments, comparisons, . . .

In RDF based knowledge representation however, knowledgeis represented using triples in the form of (subject, property, ob-ject). Once a triple is declared, it is considered true. There isno notion of “behaviour” or “sequence of actions” in the knowl-edge domain. This poses a natural tension between a proceduralenvironment, such as the user’s execution domain and a knowl-edge domain such as expressed in RDF triples. One of the goalsof this abstract is to overcome this tension.

HTTP

Knowledge domain

web server

web of proof engines

reasoning software

Executiondomain

Fig. 1. Schematic illustrating the basic concepts of the general approach

B. Abstract GUI ontology

If we want to reason over the representation and contents ofgraphical user interfaces, we first need to declare their charac-teristics. We therefore need a vocabulary to provide the termsand concepts we can use in these descriptions. To this purpose

we define an abstract GUI ontology, in which implementation-independent user interface elements are defined. These elementsmust be general in a way that they are omnipresent in a widerange of GUI toolkits and implementations.

Once this ontology is established, we can use it’s vocabularyto define abstract graphical user interfaces. These abstract ver-sions contain all the information that is necessary in all finalversions of the form. Other information is omitted and shouldbe added afterwards using rules.

C. Other ontologies

Aside from the abstract GUI ontology, there is a need forother ontologies describing common characteristics of user pref-erences, device capabilities, user roles, usability patterns, acces-sibility constraints, user contexts, company guidelines and soon.

For some of the beforementioned ontologies, there are alreadystandards in active development. For example, the CompositeCapabilities / Preference Profiles W3C working group has al-ready issued a W3C Working Draft in which a standard is beingproposed for the description of device capabilities and user pref-erences. On the other hand there are other domains without aptproposals. It is however out of the scope of our research to pro-vide for these ontologies.

D. Rules

With a proper description of the form and the user’s context,we can now proceed towards a customized version of the formfor the user. We propose to do this using rules. Rules are inessence a different way of expressing knowledge compared toontologies. Using technology such as N3Logic however, we areable to harness the power of both ontologies and rules withinone notation.

In our approach of generating GUI’s, we use reasoning to pro-duce custom forms based on the abstract form’s description, thedescription of the user’s context and rules that alter the charac-teristics of the form and act based on the user’s context. It isthis very powerful concept that will allow us to make any kindof alteration to the abstract forms we defined earlier to achievea fully customized form.

E. Mapping

As a final piece of the puzzle in our approach, we need tomap the customized description of the form in terms of the ab-stract GUI ontology to a more specialized terminology, basedon the final implementation. Indeed, we need to “translate” theabstract GUI definitions to a more specialised, implementationdependent form. We achieve this transformation step by defin-ing a ruleset for each implementation language, thus effectivelymapping abstract concepts to the underlying GUI toolkit’s con-cepts.

F. Presentation

With all the knowledge of the former sections combined, animplementation specific form, customized on the user’s contextwill be forwarded to the execution environment. This environ-ment must carry a component that can interpret this knowledgeen build an instance of the form.

IV. IMPLEMENTATION

To illustrate the proposed general approach, we present animplementation of the described use case. This implementationrelies on the web browser as an application platform and usesxHTML as a presentation format. This does not impose a lim-itation on the achieved results, because XML-based descriptionlanguages are becoming more and more common. Examples in-clude the widespread XAML by Microsoft in [3] and XUL in[4] by the Mozilla project.

web

server

web browser

XHTML

&

CSS

&

JAVASCRIPT

FAT CLIENT

Asy

nchr

one

XmlH

TTP

Req

uest

s

Fig. 2. The implementation of the use case uses the web browser as the appli-cation platform

By this demonstration model we prove that the approachtaken on this problem is effective and therefore introducing rea-soning in the generation of GUI’s is definitely worthy of furtherresearch.

V. CONCLUSION

We presented a general approach towards the introduction ofreasoning in the generation of user interfaces. This approach isvalid, but depends largely on a variety of ontologies that have notbeen standardized by domain experts. However, we have imple-mented a proof-of-concept that illustrates the approach and thevery powerful concept of customized GUI generation based onreasoning.

REFERENCES

[1] RDF/XML Syntax Specification, http://www.w3.org/ TR/ rdf-syntax-grammar/

[2] Berners-Lee et al, N3Logic - A Logic For the Web[3] Microsoft Developer Network, XAML Overview,

http://msdn2.microsoft.com/en-us/library/ms752059.aspx[4] XML User Interface Language (XUL) Project,

http://www.mozilla.org/projects/xul/

Inhoudsopgave

Overzicht iii

Extended abstract iv

Inhoudsopgave vi

Afkortingen viii

1 Inleiding 1

1.1 Situering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Doelstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Het Semantisch Web 6

2.1 Van World Wide Web naar Semantisch Web . . . . . . . . . . 6

2.1.1 Het World Wide Web en haar tekortkomingen . . . . . 6

2.1.2 De visie van het semantisch web . . . . . . . . . . . . . 10

2.2 W3C en standaardisatie . . . . . . . . . . . . . . . . . . . . . 12

2.3 Technologische achtergrond . . . . . . . . . . . . . . . . . . . 15

2.3.1 Architectuur . . . . . . . . . . . . . . . . . . . . . . . . 15

vi

2.3.2 Uniform Resource Indicator (URI) . . . . . . . . . . . 16

2.3.3 Unicode . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3.4 eXtensible Markup Language (XML) . . . . . . . . . . 19

2.3.5 Resource Description Framework (RDF) . . . . . . . . 21

2.3.6 Ontologieen en regels . . . . . . . . . . . . . . . . . . . 24

2.3.7 Logica, bewijsvoering & vertrouwen . . . . . . . . . . . 26

2.3.8 Interfaces & applicaties . . . . . . . . . . . . . . . . . . 27

3 Gebruik van redeneersoftware bij de generatie van GUI’s 28

3.1 Grafische gebruikersinterfaces (GUI’s) . . . . . . . . . . . . . . 28

3.1.1 Complexiteit van de implementatie . . . . . . . . . . . 29

3.1.2 Complexiteit van het ontwerp . . . . . . . . . . . . . . 30

3.1.3 2 uiteenlopende taken, 1 ontwikkelaar . . . . . . . . . . 31

3.2 Use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2.1 Definitie . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2.2 Voordelen van op redeneren gebaseerde GUI generatie . 33

3.3 Algemene benadering . . . . . . . . . . . . . . . . . . . . . . . 35

3.3.1 Het kennisdomein en de executie-omgeving . . . . . . . 36

3.3.2 Spanningsveld . . . . . . . . . . . . . . . . . . . . . . . 36

3.3.3 Werkwijze . . . . . . . . . . . . . . . . . . . . . . . . . 37

4 Implementatie van een proof-of-concept 42

4.1 Testopstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.1.1 Keuze van executie omgeving . . . . . . . . . . . . . . 43

4.1.2 N3Logic . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.1.3 Web of Proof Engines . . . . . . . . . . . . . . . . . . 47

4.2 Overzicht: ontologieen en regels . . . . . . . . . . . . . . . . . 48

5 UsiXML 50

5.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.2 Abstractieniveaus . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.3 Vergelijking met ons onderzoek . . . . . . . . . . . . . . . . . 53

6 Besluit 55

Bibliografie 58

Lijst van figuren 61

Lijst van codefragmenten 63

Afkortingen

AJAX Asynchronous JavaScript and XML

AUI Abstract User Interface

CC/PP Composite Capabilities/Preference Profiles

CUI Concrete User Interface

FUI Final User Interface

HTML HyperText Markup Language

HTTP HyperText Transfer Protocol

N3 Notation3

QName Qualified Name

REST Representational State Transfer

RIF Rule Interchange Format

UI User Interface

URI Uniform Resource Indicator

URL Uniform Resource Locator

ix

UsiXML USer Interface eXtensible Markup Language

W3C Word Wide Web Consortium

WOPEG Web of Proof Engines

WPF Windows Presentation Foundation

WWW World Wide Web

XAML eXtensible Application Markup Language

xHTML eXtensible HyperText Markup Language

XUL XML User Interface Language

Hoofdstuk 1

Inleiding

In dit inleidend hoofdstuk schetsen we de context waarin deze scriptie zich

situeert. We identificeren de probleemstelling om zo tot de doelstellingen

voor dit onderzoek te komen. Hierna stippelen we de rode draad uit voor de

volgende hoofdstukken in een kort overzicht.

1.1 Situering

Agfa HealthCare is actief in onderzoek naar het gebruik van het semantisch

web in de gezondheidszorg. Het basisidee bij dit onderzoek en van het se-

mantisch web in het algemeen is dat men door machines te laten redeneren

over verschillende bronnen van kennis en regels nieuwe informatie kan aflei-

den. Door deze informatie aan te wenden in de executie-omgeving van de

gezondheidswerker wordt de mogelijkheid geboden dagelijkse taken te ver-

eenvoudigen.

1

Hoofdstuk 1. Inleiding

Een goed voorbeeld hiervan is het bieden van ’decision support’ aan de ge-

bruiker van een medische applicatie (bvb. een arts of verpleger). Hierbij

wordt door reasoning engines een patientspecifieke klinische workflow afge-

leid op basis van vooraf gedeclareerde algemene medische guidelines en ande-

re bronnen van kennis. Dit kunnen bvb. specifieke gegevens over de patient

zijn. Hierdoor wordt voor de gebruiker een procedure opgesteld die niet al-

leen aangepast is aan de noden van de patient maar ook conform is aan de

algemene regels. Deze aanpak weegt duidelijk op t. o. v. het scenario waarbij

deze informatie niet voorhanden is.

De ambitie van Agfa reikt echter verder. Men is ervan overtuigd dat dit prin-

cipe ook op hogere en lagere niveaus kan worden toegepast. Een voorbeeld

van een toepassing op hoger niveau is de monitoring van een patient over de

grenzen van het hospitaal heen. Een voorbeeld van een toepassing op laag

niveau is het aanpassen van de applicaties waar een gebruiker mee werkt.

kennis

&

regels

regels

kennis

&

regels

kennisreasoning

nieuwe

informatie

Figuur 1.1: Door machines te laten redeneren over expliciet gedeclareerde kennis

en regels, kunnen we nieuwe, nuttige informatie afleiden.

2


Zo stellen we in deze scriptie de vraag hoe dit principe kan worden toegepast

bij het samenstellen en wijzigen van gebruikersinterfaces, op zich een zeer

laag-niveau onderwerp.

1.2 Probleemstelling

Het ontwerp en de implementatie van gebruikersinterfaces in software is geen

sinecure. Ondanks het feit dat ontwerp en implementatie zeer uiteenlopende

taken zijn, worden ze toch vaak uitgevoerd door een persoon: de software

developer. Vaak wordt het deze dan nog bemoeilijkt door de eis dat de

software op een veelheid aan plaftormen en applicaties met sterk verschillende

eigenschappen moet werken.

Bovendien moet de software developer niet alleen op de hoogte zijn van

gangbare user interface en usability patterns, maar moet hij/zij zich ook

bewust zijn van company guidelines. Deze leggen vast aan welke stijl en

regels gebruikersinterfaces van dat welbepaalde softwarehuis moeten voldoen.

Kortom, het ontwerp en de implementatie van gebruikersinterfaces is een

moeilijke, tijdrovende en vooral dure zaak.

Om de kosten te drukken ligt het voor de hand om de gebruikersinterfa-

ces generischer te maken. Hierdoor verliest zij aan expressiviteit voor de

onderliggende data en vermindert de bruikbaarheid drastisch. Nochtans is

de gebruikersinterface vaak het enige contactpunt van de gebruiker met de

software.

3


1.3 Doelstelling

In deze scriptie gaan we na op welke manier we uitgaande van reasoning

op declaratieve kennis het proces van de generatie van gebruikersinterface

kunnen vereenvoudigen. Hierbij gaan we uit van een generator voor een

grafische gebruikersinterface die zich baseert op talrijke bronnen van kennis,

zoals company guidelines, gebruikerspreferenties, patientinformatie, etc.

Hiervoor gaan we als volgt te werk:

� Onderzoek naar de state of the art van het semantisch web. Welke

technologieen zijn beschikbaar, in welk stadium bevindt het onderzoek

zich en hoe kunnen we er gebruik van maken in het kader van dit

eindwerk.

� Onderzoek naar een declaratieve standaard voor de beschrijving van ge-

bruikersinterfaces, onafhankelijk van een welbepaalde executie-omgeving.

� Het mogelijk maken om deze beschrijvingen te genereren door middel

van reasoning

� Implementatie van een proof-of-concept die duidelijk enkele voordelen

van het gebruik van reasoning bij de samenstelling van gebruikersinter-

faces illustreert.

1.4 Overzicht

In hoofdstuk 2 onderzoeken we de state of the art van het huidige seman-

tisch web. We bespreken de architectuur en daardoor ook enkele standaarden

4


waar we in het vervolg nog extensief gebruik van zullen maken.

In hoofdstuk 3 bespreken we de rationale van dit onderzoek en introduceren

we een use case die zal dienen als leidraad voor hetgeen wat volgt. Hierna

stellen we de algemene benadering voor de op redeneren gebaseerde generatie

van gebruikersinterfaces voor.

In hoofdstuk 4 werken we de use case uit tot een demonstratiemodel die de

eigenschappen van de algemene benadering concretiseert. We verantwoorden

de ontwerpkeuzes en gaan na of de gestelde doelen werden bereikt.

In hoofdstuk 5 bespreken we het onderzoek rond UsiXML, de USer Interface

eXtensible Markup Language. We brengen dit onderzoek in verband met deze

scriptie en poneren enkele paden voor verdere academische research.

In hoofdstuk 6 komen we ten slotte tot een besluit en vatten we de voor-

naamste bevindingen van deze scriptie samen.

5

Hoofdstuk 2

Het Semantisch Web

2.1 Van World Wide Web naar Semantisch

Web

2.1.1 Het World Wide Web en haar tekortkomingen

Het World Wide Web (WWW) werd rond 1990 uitgevonden door de Brit Tim

Berners-Lee. Het is zonder twijfel uitgegroeid tot een van de meest populaire

toepassingen van het internet. In wat volgt duiden we kort de bouwstenen

van het WWW en identificeren we de beperkingen die het ontwerp impliceert.

Bouwstenen van het WWW Het WWW is een informatieruimte die

bestaat uit resources die geıdentificeerd worden door een Uniform Resource

Locator (URL). Een URL is een specifieke vorm van een Uniform Resource

Indicator (URI).

6

Hoofdstuk 2. Het Semantisch Web

Hoewel “resource” een zeer ruim begrip is, zijn de meest resources op het

WWW computerbestanden, opgemaakt met de HyperText Markup Language

(HTML). Deze HTML documenten kunnen bekeken worden door hun URL

door te geven aan een browser: een computerprogramma dat een represen-

tatie van deze documenten kan weergeven.

Men kan een URL doorgeven aan de browser door deze ofwel letterlijk in te

geven ofwel door een hyperlink te volgen. Een hyperlink is een verwijzing

naar een URI in een HTML bestand. Doordat de meeste HTML bestanden

hyperlinks bevatten naar andere HTML bestanden ontstaat voor de gebruiker

een web van documenten, naar analogie met de structuur van een spinnenweb.

Dit web groeide sinds 1990 exponentieel tot een schat van informatie. Anno

2005 telde [1] meer dan 1013 afzonderlijke documenten en dan beperkte men

zich nog tot het publiek indexeerbare web.

URI URI

URI

URI

URI

hrefhref

href

href

Figuur 2.1: Het WWW bestaat uit resources (aangeduid door URI’s) die door

hyperlinks (href) met elkaar zijn geconnecteerd.

7


HTML, de taal van het WWW HTML-documenten bestaan uit tekst

en tags. Tags zijn speciale stukjes tekst die de browser vertellen dat wat

tussen de begin- en eindtag staat op een bepaalde manier moet worden weer-

gegeven. Een begintag is steeds van de vorm <soortTag>, een eindtag wordt

steeds geschreven als </soortTag>. soortTag staat hierbij voor het type van

de tag. Als we bijvoorbeeld p gebruiken, dan vertellen we aan de browser dat

het ingesloten fragment een paragraaf is, h1 duidt dan weer een titel aan, h2

een subtitel en zo verder.

HTML tags bieden een semantiek die zich beperkt tot de opmaak en – in

zeer beperkte mate – de structuur van documenten, zoals een titel en een

paragraaf. Vaak wordt zelfs deze semantiek niet gerespecteerd. Zo is het

op het WWW schering en inslag dat “table” tags gebruikt worden om de

structuur van een volledige pagina in te beschrijven, omdat dit makkelijker

lijkt dan andere methodes. In de HTML standaard wordt een “table” tag

echter aangeduid om tabulaire data te beschrijven.

Het belang van zoekmachines Doordat het WWW bestaat uit een

enorm aantal geınterconnecteerde HTML-pagina’s, is het vinden van de juiste

informatie geen gemakkelijke opdracht. Om dit op te lossen, werden zoekma-

chines ontworpen. Zij hebben de toename aan populariteit van het WWW

zeker in grote mate gestimuleerd.

Een zoekmachine bestaat uit een aantal onderdelen. Een daarvan is de spider:

een speciaal programma dat HTML pagina’s leest en indexeert. Een spider

beweegt zich als een spin door het WWW door hyperlinks van resource naar

resource te volgen.

8


Voor de gebruiker is het belangrijkste deel van de zoekmachine echter de

interface. Deze laat hem/haar toe een zoekopdracht te definieren. Vervol-

gens zal de zoekmachine een lijst van hyperlinks weergeven die refereren naar

pagina’s die een grote correlatie vertonen met de zoekopdracht. Meestal han-

teren zoekmachines speciale algoritmes om de resultaten te ordenen volgens

relevantie. Deze algoritmes zijn vaak gebaseerd op een veelheid aan factoren.

Doordat de semantiek van HTML beperkt is tot de opmaak en de structuur

van documenten is het voor machines bijzonder moeilijk om de informatie

die deze documenten bevatten te correleren met de zoekopdracht. De meest

voor de hand liggende manier is het maken van lexicografische vergelijkingen

tussen de zoektermen en de index van de zoekmachine. Spijtig genoeg leidt

dit ook vaak tot minder relevante resultaten. De kunst van informatie zoeken

op het WWW bestaat er dan ook in zodanig te zoeken dat men de meest

relevante resultaten bekomt.

[2] duidt de voornaamste problemen aan waarmee gebruikers van zoekmachi-

nes te maken krijgen:

� veel resultaten, lage precisie

� weinig of geen resultaten

� vocabularium-gevoelige resultaten

� “antwoord” is verspreid over meerdere resultaten

Een eenvoudig voorbeeld om dit te illustreren. Zoekt men op het trefwoord

“Kok”, dan is het voor de machine onduidelijk (afgezien van de hoofdletter)

of het over de politicus “Wim Kok” dan wel het beroep “kok” gaat en geeft

9


dus resultaten over de beide weer. Dit is dus een vocabularium-gevoeligheid.

Bovendien worden meer dan 17.5 miljoen resultaten gevonden.

Een complexer voorbeeld is het volgende. Stel dat we de volgende vraag stel-

len aan het WWW: “Wat is de meest voordelige manier om op 15 december

van Brussel naar Bergamo te vliegen?” Generieke zoekmachines zijn (nog)

niet in staat een antwoord te formuleren, hoewel de nodige informatie om

een antwoord te geven met grote zekerheid op het WWW aanwezig is.

Dit alles benadrukt de beperking van zoekmachines die inherent is aan de

manier waarop het WWW is opgebouwd, nl. als web van documenten.

2.1.2 De visie van het semantisch web

In [3] stelt Tim Berners-Lee zich een web voor dat fundamenteel verschilt van

het web van documenten zoals we dit vandaag kennen. Onderstaand citaat

geeft zijn visie over het web goed weer:

“The Semantic Web is not a separate Web but an extensi-

on of the current one, in which information is given well-defined

meaning, better enabling computers and people to work in coo-

peration. The first steps in weaving the Semantic Web into the

structure of the existing Web are already under way. In the near

future, these developments will usher in significant new functio-

nality as machines become much better able to process and ‘un-

derstand’ the data that they merely display at present.”

10


Berners-Lee ziet de toekomst van het web dus als een web van data in plaats

van het web van documenten zoals dit vandaag het geval is. De ambitie van

het semantisch web ligt er dan ook in de fundamenten van het huidige web

uit te breiden zodanig dat data (en niet alleen documenten) kunnen gedeeld

worden over het gehele internet en deze data door machines kan verwerkt

worden.

Dit impliceert dat in het semantisch web data beschikbaar worden gemaakt

op een manier die aanleunt bij hoe een databank gegevens bijhoudt. Hiervoor

maakt men gebruik van metadata. Metadata kan worden aanzien als “data

over data”. Door de data die we publiceren te beschrijven met metadata

maken we het voor anderen (mensen, software) makkelijker om deze gegevens

te interpreteren.

Naast dit feit ligt het grootste potentieel van het semantisch web in de in-

troductie van machine-toegankelijke semantiek. Hierdoor kan ook software

consistente relaties tussen gegevens leggen net zoals de mens dit kan door

interpretatie.

Aangezien het semantisch web een enorm mogelijkheid biedt voor een zeer

uiteenlopend aantal toepassingen en de drempel tot de technologie even laag

wordt gelegd als bij het WWW (zie ook 2.2), valt te verwachten dat ook het

semantisch web de volgende jaren enorm aan populariteit zal winnen, niet

in het minst wegens de complementariteit van het WWW en het semantisch

web.

Zij sluiten elkaar immers niet uit. Integendeel, de architectuur van het se-

mantisch web steunt op dezelfde fundamenten als die van het traditionele

WWW. Zo biedt de synergie van WWW en semantisch web het beste van 2

11


werelden: een web van data en documenten, met een natuurlijke representa-

tie voor de mens en een voor machines toegankelijke semantiek.

2.2 W3C en standaardisatie

Doordat het WWW steunt op standaarden zoals HTML, URI en HTTP

werd het mogelijk om een groot, gedistribueerd web van informatie uit te

bouwen. Deze standaarden zijn open, consistent, goed gedocumenteerd en

werden geadopteerd door grote softwarehuizen, zoals Microsoft en Netscape.

Hierdoor kan iedereen die zich aan de standaarden houdt informatie toevoe-

gen en raadplegen. Dit maakt het WWW een zeer democratisch medium,

wat opnieuw een van de katalysatoren is voor haar succes.

Vandaag is het Word Wide Web Consortium (W3C) de autoriteit voor stan-

daardisatie op het WWW. Dit houdt in dat zij zich er op toelegt de bestaande

standaarden te verbeteren, uit te breiden en er nieuwe te ontwikkelen. Zo

vormt het W3C ook een van de stuwende krachten achter de innovatie en

onderzoek naar nieuwe technologieen.

Het W3C werd opgericht in oktober 1994 door Sir Tim Berners-Lee. Hij

staat ook vandaag nog aan de leiding van deze internationale organisatie. Ze

wordt in verschillende landen gehuisvest door academische onderzoeksgroe-

pen. In de V. S. is dit het Massachusetts Institute of Technology (MIT), in

Europa het European Research Consortium for Informatics and Mathematics

(ERCIM) en in Japan de Keio University.

Vele van de technologieen die in dit hoofdstuk – en algemener: in deze hele

scriptie – aan bod komen zijn nog in volle ontwikkeling in onderzoeksgroepen

12


van het W3C. Daarom blijkt het nuttig kort haar werking te schetsen zodat

we de verschillende stadia van het onderzoek met hun intrinsieke benaming

kunnen aanduiden.

Structuur en werking van het W3C Het W3C is onderverdeeld in

domeinen (domains) ([4]). Deze domeinen omvatten activiteiten (activities).

Aan elke activiteit zijn een aantal werkgroepen toegewezen.

Een voorbeeld van zo’n activiteit is de ’Semantic Web Activity’ uit het ’Tech-

nology and Society Domain’. Hierna volgt een beknopte samenvatting van

de doelstelling van deze activiteit:

“The goal of the Semantic Web initiative is as broad as that

of the Web: to create a universal medium for the exchange of

data. It is envisaged to smoothly interconnect personal infor-

mation management, enterprise application integration, and the

global sharing of commercial, scientific and cultural data. Facili-

ties to put machine-understandable data on the Web are quickly

becoming a high priority for many organizations, individuals and

communities (. . . )”

De resultaten van de werkgroepen en activiteiten zijn technische rapporten,

web standaarden, open source programma’s en diensten. Standaarden wor-

den in W3C-jargon ’W3C Recommendations’ genoemd. Dit document is het

eindproduct van een langdurig proces, waarbij het volgende stadia doorloopt:

1. Working Draft (WD)

13


2. (Last Call Working Draft)

3. Candidate Recommendation (CR)

4. Proposed Recommendation (PR)

5. W3C Recommendation (REC)

Hierbij is de Working Draft het initiele document dat publiekelijk beschikbaar

wordt gesteld voor commentaar. Wanneer het document de status Candidate

Recommendation krijgt is de werkgroep reeds vrij zeker dat het document

de beoogde doelstelling vervult. Men laat hier echter de kans om de imple-

menteerbaarheid van de standaard te onderzoeken. Vaak speelt de industrie

hier dus een rol.

Hierna wordt het document een Proposed Recommendation. Hoewel de over-

gang naar W3C Recommendation vaak met geringe wijzigingen gebeurt, is

dit niettemin een belangrijke stap. Dit document moet immers worden goed-

gekeurd door de adviesraad voor het W3C. Immers, eens een document het

label ’W3C Recommendation’ krijgt, wordt het door de volledige organisatie

ondersteund.

Kortom: een W3C Recommendation is grondig nagelezen en getest in ver-

schillende omstandigheden voor het die status krijgt. Indien er toch nog

fouten instaan, worden deze errata toegevoegd. Pas wanneer een voldoende

groot aantal errata wordt bereikt, brengt men een nieuwe versie uit van de

standaard.

14


2.3 Technologische achtergrond

In wat volgt belichten we met meer precisie de fundamenten waarop het

Semantic Web wordt gebouwd. We duiden telkens het stadium aan waarin

een technologie zich bevindt, zodanig dat de lezer zich een idee kan vormen

over de mate waarin zij nog kan evolueren.

2.3.1 Architectuur

Figuur 2.2: De Semantic Web stack, zoals bedacht door Tim Berners-Lee

Het huidige model voor de architectuur van het semantisch web bestaat uit

een aantal lagen, zoals is te zien in figuur 2.2. Men refereert hier soms met

15


een knipoog naar als de ’layer cake’.

Zoals gebruikelijk bij zulke architecturen (bvb. de alomtegenwoordige OSI

netwerkarchitectuur) steunt elke laag op de interface van de onderliggende

la(a)g(en) en biedt ze een welgedefinieerde functionaliteit aan de la(a)g(en)

erboven. Deze laagstructuur maakt het mogelijk een complex geheel op te

bouwen uit relatief eenvoudigere subcomponenten die (relatief) onafhankelijk

kunnen worden ontwikkeld. De mate van complexiteit stijgt naarmate men

klimt naar hogere lagen.

Zoals vermeld in 2.1.2 zien we dat de architectuur niet enkel nieuwe techno-

logieen definieert, maar ze voor een groot deel bestaat uit standaarden die

ook in het huidige WWW worden gebruikt. Deze opmerking is belangrijk in

die zin dat dit er voor zorgt dat het semantisch web geen web op zich vormt,

dan wel een uitbreiding is van het huidige WWW.

Het bewijs hiervan is dat de onderste lagen van het model, gevormd door

URI, Unicode, XML1 en Namespaces de de facto standaarden zijn van het

huidige WWW.

Hierna bespreken we laag per laag de verschillende technologieen van de

architectuur.

2.3.2 Uniform Resource Indicator (URI)

Een URI is een compacte string van karakters die een enkele resource identi-

ficeert. Bewust is het begrip “resource” hier niet nader bepaald. We kunnen

1De laatste versie van HTML, xHTML (eXtensible HyperText Markup Language) is

een XML dialect van HTML dat als de huidige standaard wordt aanzien.

16


immers uiteenlopende zaken als resource benoemen: bijvoorbeeld een HTML

pagina of JPEG afbeelding, maar ook een fysiek object, zoals een auto of een

boek.

We kunnen resources wel partitioneren in informatie resources en niet-informatie

resources. Zo zijn informatie resources resources die volledig kunnen beschre-

ven worden in een bericht. Resources die slechts benaderend kunnen geka-

rakteriseerd worden door een bericht zijn niet-informatie resources. Zo is het

onmogelijk een fysiek object volledig te beschrijven.

URI’s vormen het globale identificatiesysteem van het WWW. Wanneer de

URI van een resource bekend is, laat dit ons toe ernaar te verwijzen, of er

iets over te zeggen. Mocht er geen globaal identificatiesysteem zoals URI’s

bestaan zou het onmogelijk zijn beweringen te maken over resources. Ze

vormen dus een essentieel onderdeel van de architectuur.

De meest bekende vorm van zo’n URI is een URL of Uniform Resource Lo-

cator. Een voorbeeld is http://www.example.com/. In deze string duidt

http: het URI schema aan. http: is het schema dat gebruikt wordt om com-

puterbestanden (zoals HTML pagina’s) die beschikbaar zijn op het WWW

te identificeren. isbn: wordt gebruikt om het International Standard Book

Numbering schema aan te duiden. Zo duidt isbn:006251587X de paperback

editie van het boek “Weaving the Web” van Tim Berners-Lee aan.

In het licht van URI’s als globale identifiers wordt het aangeraden URI sche-

ma’s zo vaak mogelijk te hergebruiken.Het is bijvoorbeeld onnodig een nieuw

schema voor de identificatie van boeken uit te vinden ter vervanging van

ISBN. Het definieren van de URI schema’s wordt daarom gecontroleerd door

IANA (Internet Assigned Numbers Authority).

17


2.3.3 Unicode

Unicode heeft als doel alle soorten karakters en tekens die over de hele wereld

in gebruik zijn op een consistente manier door machines te laten manipuleren

en voorstellen. Hierdoor wordt Unicode vaak gebruikt in meertalige omge-

vingen. Unicode slaagt er in om de verschillende karakters en tekens een

uniek nummer toe te kennen.

Door het grote aantal heeft men hiervoor echter meer dan 8 bits nodig. Vaak

geeft dit problemen met oudere software die vaak gebruik maakt van karak-

ters van juist 1 byte groot. Daarom zijn voor Unicode enkele encoderings-

schema’s opgesteld die hier rekening mee houden. Een van de bekendste is

het Unicode Transformation Format (UTF).

Voorbeelden hiervan zijn UTF-7, UTF-8 en UTF-16, waarbij het cijfer in de

naam steeds het aantal bits per karakter aanduidt. UTF-8 is zo opgebouwd

dat er een maximale compatibiliteit is met ASCII, de standaard encodering

van de meeste Westerse (Engelstalige) documenten.

Het gebruik van Unicode en UTF bij de encodering en het parsen van XML

bestanden laat toe om deze bestanden in een internationale context te ge-

bruiken. Daarom is Unicode de de facto standaard bij de aanmaak van XML

bestanden. Hoewel Unicode een van de fundamenten vormt van het WWW

en het semantisch web, wordt de Unicode standaard echter niet beheerd door

het W3C, doch wel door het Unicode Consortium en dit in samenwerking met

de International Organization for Standardization (ISO).

18


2.3.4 eXtensible Markup Language (XML)

XML is een markup taal waarmee men data kan beschrijven. Hiervoor maakt

men, net zoals bij HTML (2.1.1) gebruik van tags. In tegenstelling tot bij

HTML, kan men bij XML zelf tags definieren. Dit verklaart waarom de taal

de eXtensible Markup Language wordt genoemd. XML is dus eigenlijk niks

meer dan een metataal voor markup. Een eenvoudig voorbeeld van een XML

fragment is het volgende:

Codefragment 2.1: Voorbeeld van een XML fragment.

<?xml version=” 1 .0 ” encoding=”UTF−8”?>

<book i sbn=”006251587X”>

< t i t l e>Weaving the Web</ t i t l e>

<author>Tim Berners−Lee</ author>

</book>

Dit voorbeeld illustreert enkele kwaliteiten van XML:

� XML brengt structuur aan in data door tags te introduceren en deze

tags te nesten. Door deze structuur wordt de data toegankelijk(er) voor

machines.

� XML documenten blijven leesbaar voor mensen.

Deze kwaliteiten zorgen ervoor dat XML een uniform formaat is voor de

uitwisseling van data. De verdienste van XML is dus dat men voor data-

uitwisseling niet langer aangewezen is op implementatiespecifieke represen-

tatievormen, zoals die van een databank, zonder de structuur die verbonden

is aan die data te verliezen.

19


XML Schema en namespaces Het vastleggen van de typische structuur

van een specifieke XML-applicaties gebeurt d. m. v. XML Schema. Een XML-

applicatie is per definitie de klasse van documenten die conform is aan de

richtlijnen van het XML Schema. XML Schema maakt het mogelijk voor de

verschillende deelnemers aan het datatransfer om XML documenten te ijken

t. o. v. een voorgedefinieerde structuur.

De oplettende lezer merkt misschien op dat verschillende XML applicaties

niet met elkaar in verband kunnen gebracht worden als zij identieke tags

gebruiken voor verschillende concepten. Inderdaad, het staat elke gebruiker

vrij zijn eigen XML Schema te definieren en daarbij tags te gebruiken die

ook in andere schema worden gebruikt. Wenst men echter toch gebruik te

maken van beide applicaties door elkaar, dan kan men gebruik maken van

XML namespaces. Een namespace bindt een XML Schema aan een string

die dan gebruikt wordt als prefix voor de tags uit dat schema. Een voorbeeld

wordt gegeven in onderstaand fragment:

Codefragment 2.2: Voorbeeld van XML Namespaces.


<myLibrary

xmln s : l i b r a ry1=” ht tp : //www. l i b r a r y 1 . com/ l i b r a r y . xsd”

xmln s : l i b r a ry2=” ht tp : //www. l i b r a r y 2 . com/ l i b r a r y . xsd”>

< l i b r a r y1 : book l i b r a r y 1 : i s b n=”006251587X”>

< l i b r a r y 1 : t i t l e>Weaving the Web</ t i t l e>

< l i b r a r y 2 : a u t h o r>Tim Berners−Lee</ author>

</ l i b r a r y1 : book>

</myLibrary>

Namespaces zorgen dus voor een modularisatie van XML Schema, zodat

verschillende XML Schema in dezelfde context door elkaar gebruikt kunnen

20


worden.

XML en het semantisch web Men zou kunnen stellen dat XML alle

elementen bevat om de visie van het semantisch web te verwezenlijken:

� XML is een metataal: XML staat toe tags te definieren die andere data

beschrijven.

� XML maakt daardoor de data toegankelijk voor machines.

� XML is ideaal als intermediair formaat in gegevensuitwisseling.

Deze functionaliteit zal inderdaad erg belangrijk blijken in de algemene ar-

chitectuur van het semantisch web. Echter:

� het nesten van tags, i. e. de structuur van een XML document zegt niks

over de betekenis van die structuur,

� de eventuele achterliggende betekenis van de structuur is enkel toegan-

kelijk voor mensen.

XML mist dus m. a. w. een manier om de expressie van de semantiek van

data mogelijk te maken.

2.3.5 Resource Description Framework (RDF)

RDF is het datamodel dat de ultieme basis vormt voor het semantisch web.

Sedert 10 februari 2004 wordt RDF dan ook door het W3C als standaard en

21


W3C Recommendation voorgesteld ([5] en [6]). In [6] worden de volgende

doelstellingen voor het ontwerp van RDF aangegeven:

� een eenvoudig datamodel

� met een formele semantiek met bewijsbare inferentie

� gebruik van een uitbreidbaar, URI-gebaseerd vocabularium

� een XML syntax

� ondersteuning van XML Schema datatypes

� laat toe iedereen beweringen te laten maken over elke mogelijke resource

Het datamodel van RDF RDF drukt kennis uit in de vorm2 van triples:

(subject, property, object)

Een triple is een bewering die uitdrukt dat de relatie property tussen een

subject en object geldig is. Hierbij zijn zowel subject, object als property

resources. Object kan echter ook een literal zijn, een atomaire waarde zoals

een getal of string.

Een triple kunnen we voorstellen d.m. v. een gerichte gelabelde graaf, zoals

te zien is in figuur 2.3. We hebben dus al 2 manieren om kennis vervat in

RDF voor te stellen. RDF heeft echter ook een XML syntax. In wat volgt

duiden we dit kort m. b. v. een voorbeeld uit [7]. Hierbij wordt een statement

gemaakt over de resource http://www.example.org/index.html. De XML

representatie van dit statement luidt:

2Hierbij bedoelen we op dit moment niet de syntax, wel het model.

22


subject object

property

Figuur 2.3: Een triple kunnen we voorstellen als een gerichte gelabelde graaf.

Codefragment 2.3: Voorbeeld van een RDF fragment.

<?xml version=” 1 .0 ”?>

<rdf:RDF

xmlns : rd f=” ht tp : //www.w3 . org /1999/02/22− rdf−syntax−ns#”

xmlns:terms=” ht tp : //www. example . org / terms/”>

<r d f :D e s c r i p t i o n rd f : about=” ht tp : //www. example . org / index . html”>

<t e rms : c r ea t i on−date>August 16 , 1999</ t e rms : c r ea t i on−date>

</ r d f :D e s c r i p t i o n>

</rdf:RDF>

We zien dat hierbij gebruikt wordt gemaakt van XML namespaces en XML

Schema’s, zoals besproken in voorgaande sectie. De XML representatie van

een RDF triple gebeurt steeds in een <rdf:Description> element. Het sub-

ject van het triple wordt hierbij opgenomen als attribuut rdf:about in de

<rdf:Description> tag. In dit geval is het een statement met als subject

http://www.example.org/ index.html. Binnen het <rdf:Description>

element wordt dan een sequentie van elementen opgenomen waarbij de tag-

name van elk element verwijst naar een bepaalde eigenschap (property).

In dit voorbeeld is dit creation-date. Hierbij wordt de betekenis van

creation-date vastgelegd in http://www.example.org /terms/.

23


Inderdaad, we mogen de betekenis van creation-date niet afleiden uit de

eigen interpretatie die we afleiden uit de naam van de tag maar moeten de

definitie volgen uit http://www.example.org/terms/, net zoals software dit

zou moeten doen. De graafrepresentatie van dit RDF/XML fragment wordt

weergegeven in figuur 2.4

Figuur 2.4: Graafvoorstelling van het RDF/XML fragment.

2.3.6 Ontologieen en regels

Een ontologie is een formele beschrijving van een kennisdomein. De ontologie

bepaalt het vocabularium en het gebruik van concepten en relaties. Boven-

dien tracht een ontologie zoveel mogelijk relaties binnen dat kennissysteem

te karakteriseren en legt ze er zo extra beperkingen op.

Men kan bovendien verschillende ontologieen definieren voor dezelfde domei-

nen. Dat dit mogelijk is, is denkbaar gezien de gedistribueerde natuur van

het web. Om dit probleem op te vangen is het mogelijk om uit te druk-

ken dat verschillende termen uit verschillende ontologieen hetzelfde concept

aanduiden. Dit is op zichzelf al een ontologie. Hierdoor hoeft de verspreide

24


natuur van kennis op het web geen beperking te vormen voor de algemene

werking.

Voor de definitie van ontologieen op het semantisch web zijn enkele expressie-

mechanismen voorzien, zoals RDF-S ([8]) en OWL (Web Ontology Language,

W3C REC) ([9]). Deze talen verschillen in mate van expressiviteit, waarvan

de semantiek wordt vastgelegd in logische axioma’s.

Zo biedt de RDF Vocabulary Description Language of (RDF-S) slechts een

zeer beperkte semantiek om klassehierarchieen en geassocieerde hierarchieen

van eigenschappen (properties) te definieren, met een beperkte mogelijkheid

om het domein en het bereik van die eigenschappen te specifieren. OWL

biedt ruimere expressiemogelijkheden om een kennisdomein te beschrijven.

We merken op dat de mate van expressiviteit van een ontologie- beschrij-

vingstaal vaak een negatieve relatie heeft tot de complexiteit van de bewijs-

voeringsstrategieen: hoe expressiever de taal, hoe complexer de bewijsvoering

(in het slechtste geval) [2].

Naast ontologieen kan men ook gebruik maken van regels om expliciet kennis

over een domein te declareren. Regels maken het mogelijk om bvb. beper-

kingen te leggen op bepaalde relaties tussen resources of kunnen leiden tot

de nieuwe relaties. Omdat men zeer complexe soorten regelsystemen kan

bedenken, is het beter zich te beperken tot een type regels dat in de meeste

regelgebaseerde logica’s terugkomt, de zgn. “Horn” regels. Het gebruik van

Horn regels legt echter ook beperkingen op de voorwaarden en gevolgen die

men kan gebruiken. “Horn” regels zijn van de vorm:

als “voorwaarde” dan “gevolg”

25


In het W3C is de Rule Interchange Format (RIF) Working Group actief in het

onderzoek naar de ontwikkeling van een representatiestandaard voor regels,

zie ook de RIF Core Design WD (RIFCORE).

2.3.7 Logica, bewijsvoering & vertrouwen

RDF, ontologieen (RDF-S en OWL) en regels (RIF) kunnen door de tech-

nologieen die we hierboven besproken hebben gerepresenteerd worden. Met

deze machine-toegankelijke representatie van kennis en regels wordt het nu

mogelijk voor software om de consistentie van deze gegevens na te trekken

en er nieuwe kennis uit af te leiden. Deze nieuwe kennis is niet expliciet aan-

wezig in de bronnen, maar is wel impliciet aanwezig. Hiervoor maakt men

gebruik van zgn. redeneersoftware.

De logica waar deze redeneersoftware op berust zijn subsets van de predica-

tenlogica of eerste-orde logica, zoals beschrijvingslogica (Description Logic)

en regelsystemen zoals Horn logica. Door deze logica in software te imple-

menteren, slaagt men erin logische consequenties te trekken uit bepaalde

premisses, gedefinieerd in hogervermelde formaten.

Bovendien biedt predicatenlogica een systeem voor bewijsvoering die juist-

heid en volledigheid garandeert. Doordat er een systeem voor bewijsvoering

bestaat, kan het bewijs geleverd worden dat leidt tot de logische consequentie.

Hierdoor kan de redeneersoftware een uitleg bieden voor bepaalde antwoor-

den.

Door de gedistribueerde natuur van het web is een bewijsvoering alleen niet

genoeg om te betrouwen op de resultaten van redeneersoftware. Immers,

26


aangezien we als uitgangspunt een geınterconnecteerd semantisch net nemen

dat put uit kennis van vele verschillende bronnen, hangt het vertrouwen dat

we stellen in de logische consequentie van deze premisse af van de mate waarin

we vertrouwen stellen in de bronnen van de premisse.

Dit betekent dat we in het semantisch web middelen zullen nodig hebben die

de authenticatie van de identiteit van data en diensten kan garanderen en

we zo een bewijs kunnen leveren voor de graad van betrouwbaarheid van de

conclusies.

2.3.8 Interfaces & applicaties

Uiteraard zal de gebruiker niet onmiddellijk in contact komen met RDF, on-

tologieen en redeneersoftware. Net zoals vandaag de web browser de interface

vormt tussen gebruiker en WWW, zal speciale software de brug slaan tussen

gebruikers en het semantisch web.

Naast gebruikerssoftware zullen ook de agents, die bepaalde resources op het

web beheren een belangrijkere rol gaan spelen. Deze agents bieden immers,

gebaseerd op voorgaande technologieen, antwoord op complexe vragen. Door

te steunen op kennisbronnen en redeneersoftware zijn zij flexibeler dan in het

traditionele geval en kunnen zij een oplossing bieden voor problemen die niet

bij het ontwerp werden voorzien.

27

Hoofdstuk 3

Gebruik van redeneersoftware

bij de generatie van GUI’s

In dit hoofdstuk bespreken we meer in detail welke voordelen op redeneren

gebaseerde GUI generatie kan bieden t. o. v. de traditionele aanpak. We in-

troduceren ook een use case, die verder in deze scriptie zal geımplementeerd

worden. Door deze use case zullen heel wat voordelen van het gebruik van

redeneersoftware bij GUI generatie duidelijk worden. Uiteindelijk eindigen

we dit hoofdstuk met de algemene benadering die we zullen volgen om rede-

neersoftware in te zetten bij de generatie van GUI’s.

3.1 Grafische gebruikersinterfaces (GUI’s)

De gebruikersinterface (Eng. : user interface (UI)) is een van de belangrijkste

aspecten van een computerprogramma. De UI vormt immers per definitie

28

Hoofdstuk 3. Gebruik van redeneersoftware bij de generatie van GUI’s

het enigste contactpunt met de gebruiker en is zo ultiem verbonden met de

efficientie waarmee laatstgenoemde zijn/haar taak kan uitvoeren.

Het type gebruikersinterface dat het meest voorkomt bij computersoftware is

de zgn. grafische UI, kortweg GUI. Hierbij bestaat de user interface uit een

tweedimensionale ruimte waarin grafische objecten zoals vensters en knoppen

kunnen gemanipuleerd worden door de gebruiker. Deze bedient hiervoor een

aanwijstoestel (zoals een muis). Deze relatief oude1 technologie is tot op de

dag van vandaag nog steeds dominant.

3.1.1 Complexiteit van de implementatie

Tegenwoordig is de implementatie van GUI’s geen sinecure. Om te beginnen

bestaan er zeer veel GUI toolkits en zijn de meeste ervan platformafhankelijk.

Zo kunnen applicaties geschreven voor de Microsoft Foundation Class Library

– de standaard GUI toolkit van Microsoft Windows – niet in een Linux

omgeving gebruikt worden. In Linux zelf zijn er 2 zeer populaire toolkits, nl.

Qt en GTK. Dan is er ook nog JAVA, MacOS, . . . en xHTML, CSS en Flash

voor webapplicaties.

Daarenboven moeten voor sommige applicaties een gebruikersinterface ge-

maakt worden voor verschillende toestellen met zeer uiteenlopende eigen-

schappen. Zo kan het zijn dat een bepaalde toepassing zowel op een doorsnee

PC als op een PDA moet kunnen gebruikt worden. Vaak vereisen verschil-

lende soorten gebruikers ook verschillende interfaces om in essentie dezelfde

informatie te bewerken. Deze formulieren zijn dan aangepast aan bvb. de

1De eerste GUI werd genoteerd in de de jaren ’70 in het Palo Alto Resarch Center van

Xerox

29


rol of de preferenties van de gebruiker. Door de combinatie van al deze

verschillende randvoorwaarden en beperkingen stijgt de complexiteit en de

multipliciteit van de ontwikkeling van GUI’s zeer snel. De implementatie van

gebruikersinterfaces vereist m. a. w. polyvalente en zeer bedreven ontwikke-

laars.

3.1.2 Complexiteit van het ontwerp

Bij de ontwikkeling van GUI’s blijft de belangrijkste stap echter het ontwerp.

Een slecht ontworpen GUI die goed geımplementeerd is blijft immers flawed

by design. Het ontwerp van GUI’s is een aparte expertise en moet rekening

houden met tal van factoren:

� Communicatie: een GUI is in de eerste plaats een communicatiemid-

del. Men doet er dus goed aan deze communicatie zo helder mogelijk

te maken.

� Bruikbaarheid (Eng. :usability): Er bestaan vele bronnen met usa-

bility patterns. Dit zijn verzamelingen van beproefde oplossingen voor

vaak voorkomende usability problemen.

� Toegankelijkheid (Eng. :accessibility): software dient toegankelijk

te zijn voor gebruikers met vaak verschillende behoeftes. Zo is een GUI

in een taal die de gebruiker niet machtig is nutteloos voor die persoon.

Hetzelfde gaat op voor gebruikers die omwille van een handicap de GUI

van een applicatie niet kunnen gebruiken.

� Huisstijlen (Eng. :company guidelines): om een consistente ge-

bruikerservaring te garanderen, schrijven softwarehuizen vaak huisstij-

30


len uit die moeten garanderen dat de GUI’s consistente lay-outs en

stijlen gebruiken doorheen elke applicatie en – indien mogelijk – door-

heen de hele productfamilie.

� . . .

3.1.3 2 uiteenlopende taken, 1 ontwikkelaar

usability patterns

huisstijl

toegankelijkheid

gebruikers-preferenties

toestel-eigenschappen

taal

ontwikkelaarplatform

Figuur 3.1: Een softwareontwikkelaar wordt vaak geconfronteerd met zeer veel

randvoorwaarden.

Niettegenstaande implementatie en ontwerp expertises vereisen die niet vaak

aanwezig zijn in een en dezelfde persoon, is het net vaak een persoon die

beide taken moet uitvoeren: de software-ontwikkelaar.

Gezien de implementatie van een gebruikersinterface vaak een tijdrovende

zaak is – vooral indien dit moet gebeuren voor meerdere platformen of toe-

stellen – moet het ontwerpproces vaak aan belang inboeten. Daarbij komt

31


nog de grote hoeveelheid randvoorwaarden die hierboven werden gegeven.

Vaak is de ontwikkelaar/programmeur ook niet opgeleid als usability expert

en kan men dus ook geen navenante resultaten verwachten.

Het ontwerp en de implementatie van GUI’s verwacht dus een grote dosis

kennis van de ontwikkelaar. We gaan nu in de volgende paragrafen na in welke

mate het gebruik van redeneersoftware deze taken zou kunnen verlichten.

3.2 Use case

Om het nut van op redeneren gebaseerde GUI generatie te illustreren defi-

nieren we nu een use case. Deze definitie is belangrijk, aangezien we op deze

use case verder zullen bouwen bij de implementatie van een demonstratiemo-

del. Deze use case werd voorgesteld door Agfa HealthCare en situeert zich

dus in de context van de gezondheidszorg. Niettemin is het denkbaar dat de

geıllustreerde concepten toepasbaar zijn in andere omgevingen.

3.2.1 Definitie

In het kader van de gezondheidszorg draait alles rond het welzijn van de

patient. Het is dan ook van het grootste belang dat de gezondheidswerker

steeds juiste en relevante informatie gepresenteerd krijgt. Deze informatie is

ook afhankelijk van gebruiker tot gebruiker. Echter, niet alleen de informa-

tie, doch ook de manier waarop deze informatie gepresenteerd wordt is zeer

belangrijk. Zo kan de context en de organisatie waarbinnen de gebruiker

fungeert belangrijke eisen opleggen aan de gebruikersinterface.

32


Aldus definieren we een applicatie, waarbij een formulier gegevens over pa-

tienten moet kunnen voorstellen en de verwerking ervan toelaten. Deze gege-

vens zijn zowel van administratieve als klinische aard. Zo moet de gebruiker

in staat zijn de meetwaarden van enkele symptomen, zoals bloeddruk, tempe-

ratuur, hartslag, . . . in te voeren. Echter, deze meetwaarden moeten slechts

ingevuld worden als dit in het onderzoek gepland is.

Bovendien moet het mogelijk zijn om, indien de patient meer dan een on-

derzoek gepland heeft voor verschillende doeleinden, de meetwaarden van

symptomen die door de gezondheidswerker in kwestie mogen worden vastge-

steld te groeperen in een formulier. Hierbij moet echter vermeden worden

dat bepaalde gegevens meermaals moeten worden ingevuld.

Het formulier moet ook afhankelijk zijn van de context waarbinnen de ge-

bruiker opereert. Werkt hij/zij in een omgeving met weinig licht, dan heeft

de gebruikersinterface andere contrasteigenschappen. Werkt men vooral met

een PDA dan impliceert dit wederom andere beperkingen, etc.

Bovendien moet het formulier inzetbaar zijn in verschillende organisaties. Zij

vereisen dat de software consistent is met de algemene gebruikerservaring van

software binnen hun organisatie.

3.2.2 Voordelen van op redeneren gebaseerde GUI ge-

neratie

Deze eenvoudige use case toont aan hoe een eenvoudige opdracht snel in

complexiteit kan stijgen door verschillende randvoorwaarden en vereisten die

aan de software worden gesteld. In wat volgt tonen we aan dat we heel

33


Figuur 3.2: Een use case leidt al vaak tot een waaier van andere formulieren voor

dezelfde taak.

wat van die complexiteit kunnen opvangen door de generatie van de GUI te

baseren op redeneren over expliciete kennis.

Bekijken we immers de grote lijnen van de use case, dan is de opdracht

typisch doorheen alle verschillende scenario’s dezelfde: geef een aantal pa-

tientspecifieke gegevens weer en maak het mogelijk deze aan te passen. De

taak die achter het formulier zit blijft dus intrinsiek dezelfde.

De ontwikkelaar dient nu echter voor elk scenario waarin de gebruiker en

context verschilt het formulier aan te passen om aan de randvoorwaarden te

voldoen. Heel wat van die randvoorwaarden kunnen gevat worden in regels

die eigen zijn aan het domein waarin het formulier wordt gebruikt. Zo kan

men de huisstijl vastleggen in een set regels, maar ook de preferenties van de

gebruiker zijn in principe onafhankelijk van het formulier zelf.

34


De ambitie bestaat er nu in deze kennis expliciet te declareren m. b. v. de

technologieen uit hoofdstuk 2. Door de combinatie van alle verschillende

kennisbronnen zal dan een GUI gegenereerd worden die aangepast is aan de

specifieke context van de gebruiker.

3.3 Algemene benadering

In figuur 3.3 wordt schematisch de algemene benadering weergegeven die we

zullen volgen bij het introduceren van reasoning in de generatie van GUI’s.

We kunnen onmiddellijk opmerken dat het schema verdeeld is in het kennis-

domein en de executie-omgeving.

KENNIS DOMEIN EXECUTIE-OMGEVING

AbstracteGUI

Widgets

AbstracteGUI

regels

Gebruikerspreferenties

FinaleGUI

Mapping

CompanyGuidelines

GUI

REDENEERSOFTWARE

HTTP

GUI ?

Semantisch web

Toestelbeschrijving

Figuur 3.3: Algmene benadering

35


3.3.1 Het kennisdomein en de executie-omgeving

Het kennisdomein komt eigenlijk overeen met een semantisch web zoals uit

hoofdstuk 2. Inderdaad, de ruiten in figuur 3.3 duiden de verschillende bron-

nen aan die we zullen gebruiken. Elke bron duidt een brok kennis aan,

vastgelegd volgens het datamodel van RDF. We zullen daarom vaak in ter-

men van triples spreken. In die triples liggen ontologieen, regels en data

vastgelegd die onze applicatie zullen bepalen.

De andere zijde van het plaatje is de executie-omgeving van de gebruiker.

In die executie-omgeving is de applicatie die de gebruiker bedient actief. De

executie-omgeving omvat dus de machinecode van de applicatie en specifie-

ker: van de GUI. In de executie-omgeving voert de gebruiker dus zijn/haar

taak uit.

3.3.2 Spanningsveld

Er bestaat een spanningsveld tussen kennisdomein en executie-omgeving

die te wijten is aan hun verschillende natuur. Traditioneel is de executie-

omgeving een procedurale context. Hierbij leggen procedures vast hoe men

een bepaald resultaat kan bereiken. Voorbeelden van procedurale program-

meertalen zijn legio: C++, C#, JAVA, Pascal, . . . Deze talen zijn het beste

gekend en ook zeer snel. De meeste applicaties en dus ook hun GUI’s worden

dan ook geprogrammeerd in een procedurale taal.

Het kennisdomein is echter een zuiver declaratieve aangelegenheid. Zoals we

in het vorige hoofdstuk gezien hebben declareert men kennis en regels, en

leidt men daaruit nieuwe kennis af. Een van de uitdagingen bestaat er nu in

36


deze 2 zeer verschillende omgevingen aan elkaar te rijmen.

3.3.3 Werkwijze

We illustreren nu een implementatie-onafhankelijke algemene benadering die

we in het volgend hoofdstuk zullen volgen om redeneren-gebaseerde GUI

generatie mogelijk te maken.

Algemene GUI ontologie

Om redeneren op de elementen van een user interface mogelijk te maken, is

het noodzakelijk een basisversie van deze GUI vast te leggen in het kennis-

domein. Hiervoor hebben we een vocabularium nodig dat de juiste termen

en betekenis biedt om GUI’s te beschrijven. D.w. z. dat we een ontologie

nodig hebben. Deze ontologie is implementatie-onafhankelijk, d. w. z. dat

zij niet opgesteld is met een bepaalde toolkit in gedachten, zoals er enkele

aangegeven staan in 3.1.

Dat dit geen beperking hoeft te zijn volgt uit het feit dat vele GUI tool-

kits widgets aanbieden die op eenzelfde concept steunen. Zo zijn knoppen,

vensters, labels, invoervelden, etc. omnipresente elementen die in elke toolkit

aanwezig zijn. De definitie van een ontologie die niet implementatiegebonden

is hoeft dus zeker geen beperking te vormen.

Het opstellen van een ontologie voor een zeer uitgebreid concept als een

grafische gebruikersinterface is echter het werk van experts. De ontologie die

we in het volgende hoofdstuk zullen voorstellen pretendeert dus zeker niet

37


volledig te zijn.

Nadat we een algemeen bruikbare ontologie hebben opgesteld, hebben we de

middelen om een eerste formulier te definieren.

Definitie van een abstract formulier

M.b. v. de ontologie uit het vorige puntje kunnen we nu overgaan naar een

zeer generische beschrijving van het formulier dat we wensen te genereren.

Deze beschrijving is een abstracte versie van het uiteindelijke formulier en

bevat alleen die elementen die in elke versie moeten aanwezig zijn.

Het is goed de opmerking te maken dat men in deze stap ook op een meer

granulair niveau kan werken i. p. v. dat van een volledig formulier. Door de

definitie van een algemene GUI ontologie is het mogelijk om ook kleinere

componenten (vaak worden zij widgets genoemd) te definieren die bestaan

uit generische elementen uit de algemene GUI ontologie. Op die manier is het

mogelijk deze ontologie uit te breiden met eigen bibliotheken van complexe

widgets die hebruikbaar zijn doorheen applicaties.

In principe is ook een abstract formulier een soort ontologie die beschrijft

hoe instanties van dat formulier eruit kunnen zien. Dit is een heel krachtig

concept dat we nu met behulp van redeneersoftware kunnen uitbuiten bij de

generatie van de concrete formulieren.

38


Ontologieen voor gebruikerspreferenties, huisstijlen, toestelbeschrij-

vingen en regelverzamelingen

Nu we de basis hebben gelegd voor de definitie van een formulier kunnen

we verdergaan door het kennisdomein uit te breiden met ontologieen voor

andere bronnen van kennis die we zullen gebruiken bij de generatie van het

uiteindelijke formulier.

Voor bepaalde domeinen, zoals gebruikerspreferenties en toestelbeschrijvin-

gen zijn reeds ontologieen in de maak. Zo is er Composite Capabilities/Pre-

ference Profiles (CC/PP W3C WD ([10]) dat als doel heeft het mogelijk te

maken CC/PP profielen op te stellen. Zo’n profiel is een beschrijving van de

capaciteiten van een toestel en gebruikerspreferenties.

Voor andere beschrijvingen, zoals company guidelines of usability patterns

zijn nog geen standaarden in de maak. Om hierover te redeneren zullen we

dus zelf (een deel van) deze kennis moeten vastleggen.

Nu we over een degelijke beschrijving beschikken van zowel de GUI als de

context waarin deze GUI zal gebruikt worden, kunnen we de abstracte be-

schrijving van de GUI aanpassen. Dit doen we door regels te definieren die

de kenmerken van de abstracte GUI wijzigen.

Mapping van de abstracte GUI beschrijving naar implementatie-

afhankelijke triples

Aangezien het uiteindelijke formulier moet worden voorgesteld in een executie-

omgeving die een bepaalde GUI toolkit gebruikt, moeten we in een finale stap

39


nog een mapping doorvoeren van het formulier dat aangepast is aan de con-

text, maar nog steeds op een abstracte ontologie is gedefinieerd. Dit kan

eveneens gebeuren door te redeneren.

Hierdoor wordt het mogelijk de eigenschappen van het abstracte formulier

aan te passen aan de specifieke vereisten en voorzieningen van de uiteindelijke

executie-omgeving. Zo kunnen bepaalde complexe widgets reeds ingebakken

zitten in bepaalde toolkits. Door in regels vast te leggen hoe het eindelijke

formulier moet worden weergegeven, aangepast aan de specifieke API van de

toolkit, kunnen we hiervan gebruik maken.

Overgang naar de executie-omgeving

Wat nu nog rest is de overgang van kennisdomein naar de executie-omgeving

te beschrijven. Immers, het enige wat we tot nu toe gedaan hebben is kennis

en regels declareren in het kennisdomein. We beschrijven nu hoe we deze

kennis in de executie-omgeving kunnen krijgen:

HTTP

kennisdomein

web server

web of proof engines

redeneersoftware

executiedomein

Figuur 3.4: Schematisch overzicht van de entiteiten in het communicatieproces

tussen executie-domein en kennisdomein.

40


In figuur 3.4 zijn de sleutelelementen in deze overgang opgenomen. We be-

schrijven nu stap voor stap hoe een formulier gegenereerd wordt.

1. De executie-omgeving definieert de context waarin het formulier zal

worden gebruikt. Dit gebeurt in triples en in termen van de ontologieen

gedefinieerd in het kennisdomein.

2. Vanuit de executie-omgeving gebeurt een oproep naar de redeneersoft-

ware. In deze oproep worden de triples die de context definieren mee-

gegeven. Dit gebeurt als volgt:

� Voor elke redeneersoftware is een web interface gedefinieerd. Dit

maakt het mogelijk om de software op te roepen en de argumenten

voor de reasoners mee te geven in het webadres.

� Een web server zorgt ervoor dat deze web interfaces effectief be-

schikbaar zijn in het (lokaal) netwerk.

� Door dit voor meerdere soorten redeneersoftware te doen, creeert

men een zgn. web of proof engines.

� De web interfaces zorgen ervoor dat de output van de redeneer-

software geretourneerd wordt als antwoord.

3. Het antwoord op de aanvraag van de applicatie wordt gegenereerd door

de redeneersoftware. Met de contextbeschrijving kan ze nu de regels

toepassen om uit de beschrijving van de abstracte GUI een aangepaste

versie te halen.

4. Het aangepaste scherm, uitgedrukt in triples, wordt nu door de software

weergegeven.

41

Hoofdstuk 4

Implementatie van een

proof-of-concept

We zetten in dit hoofdstuk de algemene benadering uit 3.3 kracht bij door

de implementatie van een proof-of-concept. Dit demonstratiemodel werkt de

use case zoals gedefinieerd in 3.2 uit en demonstreert hierdoor de realiseer-

baarheid van de voorgestelde werkwijze. We verdedigen telkens de gemaakte

ontwerpkeuzes. Op het einde van dit hoofdstuk gaan we na in welke mate

dit proof-of-concept de beoogde doelstellingen kan invullen.

4.1 Testopstelling

Figuur 3.4 geeft in algemene termen de kenmerken van onze testopstelling

weer. We zullen deze elementen nu stelselmatig concretiseren.

42

Hoofdstuk 4. Implementatie van een proof-of-concept

4.1.1 Keuze van executie omgeving

web

server

web browser

XHTML

&

CSS

&

JAVASCRIPT

FAT CLIENT

Asy

nchr

one

XmlH

TTP

Req

uest

s

Figuur 4.1: Concrete testopstelling voor het demonstratiemodel.

Voor de implementatie van dit demonstratiemodel opteren we bij de keuze

van de executie-omgeving voor de web browser, waarbij de gebruikersinter-

face wordt gerepresenteerd in xHTML. Een schematische beschrijving van

onze aanpak wordt gegeven in figuur 4.1.

Op het eerste zicht is dit geen evidente keuze. De meeste applicaties zijn

immers zgn. stand-alone applicaties1. Dat onze keuze echter geen beperking

vormt voor de algemeenheid van ons resultaat volgt uit het feit dat we een

XML dialect gebruiken – nl. xHTML – als eindproduct. Immers, de trend in

1Dit zijn applicaties die onmiddellijk onder het besturingssysteem draaien en niet af-

geschermd worden door een andere omgeving.

43


de ontwikkeling van GUI’s neigt steeds meer naar een definitie van gebrui-

kersinterfaces in de vorm van XML documenten.

Twee bekende voorbeelden hiervan zijn de eXtensible Application Markup

Language (XAML) en de XML User Interface Language (XUL). XAML werd

ontwikkeld door Microsoft en er wordt intensief gebruik van gemaakt in het

.NET Framework (meer specifiek in de Windows Presentation Foundation

(WPF), [11]). XUL werd dan weer ontwikkeld door het Mozilla project [12]

en kan gerenderd worden in browsers die gebaseerd zijn op de zgn. Gecko lay-

out engine. Er bestaan nog veel andere XML-gebaseerde gebruikersinterface

beschrijvingstalen, maar dit zijn de voornaamste twee.

Een ander argument voor onze keuze is de huidige explosie in zgn. Web 2.0

applicaties. Web 2.0 verwijst naar een soort applicaties dat de web browser

gebruikt als platform. Men gebruikt hier de browser als run-time omgeving

om m. b. v. xHTML, CSS en Javascript een bepaalde functionaliteit te re-

aliseren. Deze explosie wordt niet in het minst gestuwd door de stabiliteit

van de Javascript implementaties de laatste jaren, die steeds beter en beter

worden.

Men noemt Web 2.0 applicaties dan ook vaak AJAX applicaties. Hierbij staat

AJAX voor Asynchronous JavaScript and XML. Dit acronym verwijst naar

een paradigma dat steeds aanwezig is: door m. b. v. JavaScript asynchrone

XMLHttpRequests uit te voeren kan men de weergave van de huidige pagina

in de browser wijzigen naar believen. Het asynchrone karakter zorgt ervoor

dat de huidige pagina niet moet worden herladen, zodat de gebruiker het

gevoel van een continue gebruikerservaring krijgt.

Het is dan ook de laatste aanpak die we zullen volgen bij de implementatie

44


van het demonstratiemodel. Het is echter niet onze bedoeling dit patroon

als de facto oplossing te poneren. Zoals vermeld hierboven kunnen we even

goede resultaten bekomen in applicaties in de traditionele zin van het woord,

waarbij onze manier van werken rechtstreeks kan afgebeeld worden indien

men gebruik maakt van een XML vorm als eindresultaat.

We vatten nu kort samen welke elementen we hebben gekozen in onze test-

opstelling:

� Webserver: Codd is een mini-webserver die standaard wordt meege-

leverd bij de Euler redeneersoftware (zie verder). Deze service werd

specifiek ge-implementeerd om de Euler functionaliteit aan te bieden

als een RESTfull2 web service.

� Browser: Er werd voornamelijk ontwikkeld in de Mozilla Firefox web

browser.

Volgende middelen werden onmisbaar bevonden tijdens de ontwikkeling:

� Firebug: Een Mozilla Firefox toevoeging die de ontwikkeling van web

applicaties vereenvoudigt [13].

� JSLint: Een online dienst3 die JavaScript code doorzoekt op proble-

men [14].

� JQuery: Een JavaScript bibliotheek die veelgebruikte handelingen in

web applicaties vereenvoudigt [15].

2Representational State Transfer is een principe waarbij men berichten verzendt over

HTTP zonder dat een extra laag een toestand bijhoudt.3Beschikbaar gesteld door Douglas Crockford, senior JavaScript Architect bij Yahoo!

45


4.1.2 N3Logic

Bij het neerschrijven van kennis volgens het RDF data model is de RDF/XML

syntax geen bijster vlotte manier om triples te noteren. Vandaar dat er

verschillende andere RDF syntaxen de kop opsteken, zoals N-Triples [16],

Turtle [17] en Notation3 (N3) [18].

Deze alternatieve syntaxen behouden de expressiviteit van het RDF data-

model maar bieden een eenvoudigere syntax aan om met de hand triples te

noteren. Inderdaad, in 2 merkten we al op dat het uitdrukken van triples

als RDF/XML of als een gerichte en gelabelde graaf slechts representaties

vormen van het onderliggend model. Precies deze eigenschap wordt hier uit-

gebuit. Voor hetgeen volgt volstaat het volgend codefragment te bekijken:

Codefragment 4.1: Voorbeeld van een Notation3 fragment.


<book i sbn=”006251587X”>

< t i t l e>Weaving the Web</ t i t l e>

<author>Tim Berners−Lee</ author>

</book>

Dit N3 fragment stelt precies hetzelfde RDF fragment uit 2.3.5 voor maar

in een veel compactere vorm. In wat volgt zullen we alle triples in N3 neer-

schrijven. In bovenstaand codefragment komen enkele concepten voor die

ook in de XML notatie voorkomen, zij het in een andere vorm. Zo duidt

@prefix identifier: "uri". aan dat het prefix identifier: in hetgeen

volgt mag vervangen worden door uri. Dit is in essentie hetzelfde concept

als XML namespaces.

Verder wordt dan precies een triple genoteerd. Dit gebeurt in de vorm

46


subject property object. In dit geval is subject een URI. URI’s wor-

den in N3 steeds tussen vishaken (< en >) genoteerd.

In het voorbeeld is property een voorbeeld van een QName. Ook hier wordt

de link gelegd met XML, waar een QName staat voor “Qualified Name”,

wat in de praktijk neerkomt op de concatenatie van een prefix voor de XML

Namespace, ’:’ en de naam van het element. In N3 werd deze notatie over-

genomen.

Tenslotte is object in het voorbeeld een literal. Vermeldenswaardig hierbij

is dat strings steeds tussen dubbele aanhalingstekens worden genoteerd.

N3 wordt vaak in een adem genoemd met N3Logic. N3Logic is een combinatie

van Notation3 en een logische uitbreiding van RDF. Deze uitbreiding laat

enkele zeer handige notaties toe om bvb. existentiele en universele kwantoren

en variabelen, logische implicaties, en quoting [18] uit te drukken.

4.1.3 Web of Proof Engines

In figuur 3.4 is aan de web server ook een WOPEG verbonden. WOPEG

staat voor “Web of Proof Engines”. Dit verwijst naar het feit dat de re-

deneersoftware beschikbaar wordt gemaakt als RESTfull web service. Zoals

reeds aangegeven in4.1.1 staat REST voor “Representational State Trans-

fer”. REST verwijst naar een typisch patroon in de context van het WWW,

waarbij informatie wordt uitgewisseld onder de vorm van berichten over het

HTTP protocol.

Het beschikbaar stellen van software als een RESTfull web service betekent

dus dat men deze software kan gaan aanspreken over het web, en de software

47


dus ook een resource wordt met een eigen URI. Zo worden de argumenten

voor de software / dienst meegegeven als elementen in de querystring en

wordt de uitvoer van de software geretourneerd in een HTTP bericht.

In onze implementatie bestaat ons WOPEG uit verschillende RESTfull ser-

vices, gebaseerd op de volgende software:

� Euler: Euler is redeneersoftware die ook een logisch bewijs van het

resultaat kan leveren – vandaar de benaming “proof engine”. Euler is

een backward-chaining reasoner waarbij gebruik wordt gemaakt van een

Euler pad detectie techniek. Er bestaan verschillende implementaties

voor Euler, waarbij elke implementatie zijn eigen suffix krijgt: zo is

Euler1 gemaakt in JAVA, Euler2 in C# versie, Euler3 in Python, Euler4

in Javascript en Euler5 is de Prolog versie. Euler bevat ook een mini

web server die Euler (e. a. diensten) kan aanbieden als RESTfull web

service.

� Cwm: Cwm is, net als Euler, redeneersoftware. Cwm maakt echter

gebruik van forward-chaining reasoning en bestaat enkel in een Python

implementatie.

Zowel Euler als cwm aanvaarden input in zowel RDF als N3.

4.2 Overzicht: ontologieen en regels

Nu we de testopstelling besproken hebben, gaan we over tot het eigenlijke

ontwerp van de ontologieen die we zullen gebruiken om de use case te imple-

48


menteren. In de puntjes hieronder bespreken we elke ontologie, en gaan we

na wat de functie ervan is in het geheel.

� ClinicalDataOntology.n3 Deze ontologie definieert enkele begrippen

uit de medische wereld, zoals Patient, Symptoom, Klinische Procedure,

etc.

� UserInterfaceOntology.n3 Deze ontologie bepaalt een terminologie

die ons toelaat GUI’s in implementatie-onafhankelijke termen te be-

schrijven.

� XHTMLOntology.n3 Modellering van de gebruikersinterface elemen-

ten die m. b. v. xHTML representeerbaar zijn.

� WidgetOntology.n3 Ontologie waarin de abstracte formulieren wor-

den gedefinieerd.

Verder leggen we nog enkele regels vast die de kenmerken van het formulier

wijzigen op basis van de context van de gebruiker. Uiteindelijk wordt dan de

abstracte beschrijving van het formulier afgebeeld op de xHTML ontologie.

Het resultaat hiervan wordt teruggestuurd naar de client. Deze parset de

GUI beschrijving (met een xHTML vocabularium) en geeft deze ten slotte

weer in de browser.

49

Hoofdstuk 5

UsiXML

5.1 Inleiding

Wanneer we in 3.3 de algemene benadering voorstelden die we kunnen volgen

bij de generatie van op redeneren gebaseerde GUI’s, introduceerden we een

ontologie die in algemene termen het domein van de grafische gebruikersin-

terface beschreef. We merkten ook op dat deze scriptie zeker niet pretendeert

een toereikende ontologie voor te stellen. Immers, het ontwerp van een al-

gemene ontologie die het domein van gebruikersinterfaces beschrijft, is een

studie op zich. In die context stellen we UsiXML ([19]) voor, een project van

de Universite Catholique de Louvain dat op een eigenzinnige manier actief

onderzoek doet naar dit onderwerp.

UsiXML staat voor USer Interface eXtensible Markup Language en is een

XML syntax ([20]) voor de beschrijving van gebruikersinterfaces. Men tracht

hierin niet alleen het domein van de grafische gebruikersinterface te beschrij-

50

Hoofdstuk 5. UsiXML

ven, maar men doet dit ook voor andere vormen, zoals auditieve of multimo-

dale gebruikersinterfaces.

Men tracht het concept gebruikersinterface dus op een zo algemeen mogelijke

manier te benaderen en dit onafhankelijk van implementatiespecifieke karak-

teristieken. In die zin vormt UsiXML een interessant project om te bekijken

bij de definitie van een algemene UI ontologie.

Figuur 5.1: Abstractieniveaus van UsiXML. Bron: [21]

51

Hoofdstuk 5. UsiXML

5.2 Abstractieniveaus

UsiXML definieert 5 abstractieniveaus bij de modellering van gebruikersin-

terfaces. Het minst abstracte niveau is de zgn. Final User Interface (FUI ).

Dit niveau is het niveau dat zich manifesteert in de executie-omgeving van de

gebruiker en kan dus gerelateerd worden aan een bepaalde programmeertaal

(C, C#, C++, JAVA, . . . ) of aan een bepaalde markup-taal (xHTML, XML,

XAML, XUL,. . . ).

Net zoals wij opmerkten, merkt men bij UsiXML op ([20]) dat vele (G)UI

toolkits beschikken over dezelfde widgets, zoals labels, titels, knoppen, in-

voervelden, etc. Het tweede abstractieniveau dat men daarom invoert is de

Concrete User Interface (CUI).

Dit niveau abstraheert toolkit-specifieke elementen tot een model dat een

volledige klasse van bvb. grafische gebruikersinterfaces kan representeren.

Een CUI is een directe afspiegeling van een FUI, maar dan in een niet-

implementatiespecifieke terminologie. Dit is ongeveer hetzelfde van wat wij

beschouwen als een abstracte (G)UI.

Bij UsiXML gaat men echter nog een stap verder en voert men een derde ab-

stractieniveau in: de Abstract User Interface (AUI). Bij een AUI maakt men

abstractie van de interactiemodaliteit. Interactiemodaliteiten kunnen gra-

fisch, vocaal, haptisch/tactiel of een combinatie van vorige zijn. Inderdaad,

een gebruikersinterface kan op vele verschillende manieren met de gebruiker

interageren.

Tenslotte voert men nog twee abstractieniveaus in, waarin men de taak en

ten slotte de context van de gebruiker in modelleert. Net zoals wij dit doen

52

Hoofdstuk 5. UsiXML

in 3.3.3, definieert men in UsiXML mappings tussen de enkele van de ab-

stractieniveaus. Deze mappings kunnen een abstractieniveau op een ander of

hetzelfde abstractieniveau afbeelden en voert hierbij ook een transformatie

uit.

We merken ook nog op dat er in het UsiXML project implementaties bestaan

die CUI beschrijvingen omzetten naar FUI’s, alhoewel deze implementaties

beperkt zijn.

5.3 Vergelijking met ons onderzoek

UsiXML heeft als doel de uniforme modellering van gebruikersinterfaces, on-

afhankelijk van de uiteindelijke implementatie, interactiemodaliteit en plat-

form. Deze methodologie kan worden gevolgd door de ontwerper van de

gebruikersinterface, waarbij eerst de taak wordt gemodelleerd waarvoor men

een gebruikersinterface wenst te ontwerpen. Hierna kan de ontwerper telkens

specialisaties uitwerken, zoals bvb. een AUI waarbij men reeds in termen van

interface elementen spreekt, of een CUI waarbij de interactie modaliteit is

vastgelegd.

Dit onderzoek stemt overeen met deze scriptie in die zin dat ook wij geınteresseerd

waren in een manier om abstracte GUI’s te modelleren, waarbij ons abstrac-

tieniveau overeenstemde met dat van de CUI. Het lijkt ons dan ook oppor-

tuun om te onderzoeken of de implementatie van UsiXML voldoende is om

als model te dienen.

Wat we echter onmiddellijk dienen op te merken is dat de semantiek van

UsiXML niet is vastgelegd in het XML Schema. Een XML Schema kan

53

Hoofdstuk 5. UsiXML

immers alleen een syntaxis vastleggen. De semantiek van UsiXML wordt

vastgelegd in UML klassediagramma’s en moet dus nog a. h. w. geporteerd

worden naar RDF. Dit is geen evidente opdracht. Bovendien is er in het

UsiXML project geen sprake van reasoning. Het is nog steeds de taak van

de ontwerper om de (G)UI vorm te geven en dit gebeurt ongeassisteerd.

De raakvlakken tussen ons onderzoek en het UsiXML project zijn groot. De

toegevoegde waarde die de introductie van reasoning zou kunnen bieden bij

beschrijvingen in UsiXML en vice versa is duidelijk aanwezig. Het verder uit-

spitten van deze opportuniteit gaat echter het doel van deze scriptie voorbij,

doch is zeker een interessant project voor de toekomst.

54

Hoofdstuk 6

Besluit

In dit hoofdstuk vatten we, als finale van deze scriptie, ons voornaamste

besluiten en vaststellingen samen in een bondig synthese.

Het doel van deze scriptie was te onderzoeken hoe we de generatie van GUI’s

konden vereenvoudigen door te steunen op redeneersoftware en de technolo-

gieen van het semantisch web.

Hiertoe begonnen we met een uitgebreide bespreking van de state of the art

van het semantisch web. Dit hield een vergelijking in met de toestand van

het huidige World Wide Web en de verbeteringen die men in het achterhoofd

heeft. Hierna bespraken we de architectuur van het semantisch web, die nog

in volle ontwikkeling is maar waarvan de grote lijnen reeds vastliggen. Hierbij

hadden we aandacht voor het belang van RDF, ontologien, regels en logica.

In een tweede fase van deze scriptie gingen we na welke de moeilijkheden

zijn van de ontwikkelaar bij de implementatie en het ontwerp van GUI’s.

Hierbij hadden we aandacht voor de veelheid aan kennis en factoren die elk

55

Hoofdstuk 6. Besluit

hun invloed hebben op het uiteindelijke formulier.

Uiteindelijk definieerden we een use case, die enkele moeilijkheden van de

implementatie en het ontwerp van GUI’s illustreert. Hierna stelden we de

algemene aanpak op die we zullen volgen bij de op redeneren gebaseerde gene-

ratie van GUI’s. Deze houdt o. a. de definitie van een ontologie voor algemene

GUI’s in die abstractie maakt van de onderliggende implementatie, ontolo-

gieen voor gebruikerspreferenties, huisstijlen, toestelbeschrijvingen, etc.

Uiteindelijk wordt een aangepast formulier gegenereerd door combinatie van

de hierboven vermelde bronnen van kennis en regels. Dit abstracte formulier

kunnen we dan met een mapping afbeelden op een formaat dat geschikt is

voor de uiteindelijke executie-omgeving.

Hierna gingen we verder in ons betoog door de algemene aanpak die we

voorstelden kracht bij te zetten met een implementatie van de use case. Het

resultaat hiervan was een proof-of-concept dat de kracht illustreerde van het

concept achter op redeneren gebaseerde GUI generatie.

Uiteindelijk stelden we het UsiXML project voor, een op XML gebaseerde

beschrijvingssyntax voor GUI’s die ontwikkeld wordt aan de UCL. We illu-

streren enkele zeer interessante concepten die zouden gecombineerd kunnen

gecombineerd worden met verder onderzoek naar op redeneren gebaseerde

GUI generatie.

We sluiten deze scriptie af met het besluit dat op redeneren gebaseerde GUI

generatie een onderwerp is waar nog bijna geen onderzoek naar is gebeurd,

maar een enorm potentieel biedt om de taak van de software developer te

vereenvoudigen en gebruikersinterfaces te produceren die beter aangepast zijn

56

Hoofdstuk 6. Besluit

aan de noden van de gebruiker.

57

Bibliografie

[1] A. Gulli and A. Signorini. The indexable web is more than 11.5 billion

pages. International World Wide Web Conference archive: Special in-

terest tracks and posters of the 14th international conference on World

Wide Web, pages 902–903, 2005.

[2] Grigoris Antoniou and Frank van Harmelen. A Semantic Web Primer.

The MIT Press, 2004.

[3] Tim Berners-Lee, James Hendler, and Ora Lassila. The semantic web:

A new form of web content that is meaningful to computers will unleash

a revolution of new possibilities. Scientific American, May, 2001.

[4] World wide web consortium homepage. http://www.w3.org/.

[5] Rdf/xml syntax specification. http://www.w3.org/TR/

rdf-syntax-grammar/, 2004. W3C REC.

[6] Resource description framework: Concepts and abstract syntax. http:

//www.w3.org/TR/rdf-concepts/, 2004. W3C REC.

[7] Rdf primer. http://www.w3.org/TR/REC-rdf-syntax/, 2004. W3C REC.

58

Bibliografie

[8] Rdf vocabulary description language 1.0: Rdf schema. http://www.w3.

org/TR/rdf-schema/, 2004. W3C REC.

[9] Owl web ontology language overview. http://www.w3.org/TR/

owl-features/, 2004. W3C REC.

[10] Composite capability/preference profiles (cc/pp): Struc-

ture and vocabularies 2.0. http://www.w3.org/TR/2007/

WD-CCPP-struct-vocab2-20070430/, 2007. W3C WD.

[11] Xaml overview. http://msdn2.microsoft.com/en-us/library/

ms752059.aspx. Microsoft Corporation.

[12] Xml user interface language (xul) project. http://www.mozilla.org/

projects/xul/. Mozilla Project.

[13] Firebug - web development evolved. http://www.getfirebug.com/.

[14] Douglas Crockford. Jslint,the javascript verifier. http://www.jslint.

com/.

[15] John Resig. jquery: The write less, do more, javasscript library. http:

//jquery.com.

[16] N-triples. http://www.w3.org/TR/rdf-testcases/\#ntriples, 2004.

[17] Dave Beckett. Turtle - terse rdf triple language. http://www.dajobe.

org/2004/01/turtle/, 2006.

[18] Tim Berners-Lee, Dan Connolly, Lalana Kagal, and Yosi Scharf.

N3logic - a logic for the web. dig.csail.mit.edu/2006/Papers/TPLP/

n3logic-tplp.pdf.

59

Bibliografie

[19] Usixml homepage. http://www.usixml.org, 2007. Universite Catholique

de Louvain.

[20] Jean Vanderdonckt. Usixml, user interface extensible markup lan-

guage reference manual. http://www.usixml.org/index.php?download=

UsiXML_v1.8.0-Documentation.pdf, 2007.

[21] Jean Vanderdonckt. A mda-compliant environment for developing user

interfaces of information systems. http://www.isys.ucl.ac.be/bchi/

publications/2005/Vanderdonckt-CAiSE2005-Web.ppt, juni 2005.

60

Lijst van figuren

1.1 Door machines te laten redeneren over expliciet gedeclareerde

kennis en regels, kunnen we nieuwe, nuttige informatie afleiden. 2

2.1 Het WWW bestaat uit resources (aangeduid door URI’s) die

door hyperlinks (href) met elkaar zijn geconnecteerd. . . . . . 7

2.2 De Semantic Web stack, zoals bedacht door Tim Berners-Lee . 15

2.3 Een triple kunnen we voorstellen als een gerichte gelabelde graaf. 23

2.4 Graafvoorstelling van het RDF/XML fragment. . . . . . . . . 24

3.1 Een softwareontwikkelaar wordt vaak geconfronteerd met zeer

veel randvoorwaarden. . . . . . . . . . . . . . . . . . . . . . . 31

3.2 Een use case leidt al vaak tot een waaier van andere formulie-

ren voor dezelfde taak. . . . . . . . . . . . . . . . . . . . . . . 34

3.3 Algmene benadering . . . . . . . . . . . . . . . . . . . . . . . 35

61

Lijst van figuren

3.4 Schematisch overzicht van de entiteiten in het communicatie-

proces tussen executie-domein en kennisdomein. . . . . . . . . 40

4.1 Concrete testopstelling voor het demonstratiemodel. . . . . . . 43

5.1 Abstractieniveaus van UsiXML. Bron: [21] . . . . . . . . . . . 51

62

Lijst van codefragmenten

2.1 Voorbeeld van een XML fragment. . . . . . . . . . . . . . . . 19

2.2 Voorbeeld van XML Namespaces. . . . . . . . . . . . . . . . . 20

2.3 Voorbeeld van een RDF fragment. . . . . . . . . . . . . . . . . 23

4.1 Voorbeeld van een Notation3 fragment. . . . . . . . . . . . . . 46

63

kennisgebaseerde gui generatoren voor de gezondheidszorg · heid en het vertrouwen zelf het...

Documents