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
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 Universiteit 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 Tr´e te bedanken. Hij gaf mij de vrijheid 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’ bemoedigingen was ik er waarschijnlijk niet in geslaagd deze thesis tot een goed einde te brengen. Ook wil ik Tom Matth´e 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 deze 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 kopi¨eren 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.”
Lennert Acke, juni 2007
Kennisgebaseerde GUI generatoren voor de gezondheidszorg door Lennert Acke Scriptie ingediend tot het behalen van de academische graad van Burgerlijk Ingenieur in de Computerwetenschappen: optie Informatie- en Communicatietechnologie Academiejaar 2006–2007 ´ Promotor: Prof. Dr. G. De Tre ´ Scriptiebegeleiders: Dr. D. Colaert MD, Ir. J. Deroo, Ir. T. Matthe In samenwerking met Agfa HealthCare Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. H. Bruneel
Samenvatting In deze scriptie onderzoeken we hoe we de generatie van grafische gebruikersinterfaces door te redeneren over verschillende bronnen van kennis en regels kunnen vereenvoudigen. Hiervoor gebruiken we technologie¨en die in volle ontwikkeling zijn in het kader van het semantisch web, zoals RDF en N3Logic. We bewijzen door een demonstratiemodel dat op redeneren-gebaseerde GUI generatie een duidelijk voordeel biedt t. o. v. de traditionele methode. Dit alles gebeurt in samenwerking met het bedrijf Agfa HealthCare in de context van de gezondheidszorg.
Trefwoorden semantisch web, grafische gebruikersinterface, reasoning
Knowledge based GUI generators in the healthcare industry Lennert Acke Supervisor(s): Guy De Tr´e, Dirk Colaert, Jos De Roo, Tom Matth´e Abstract—This article gives a general approach to introducing reasoning in the generation of graphical user interfaces by making use of semantic web technologies such as RDF in [1] and N3Logic in [2]. The approach is then illustrated with a proof-of-concept based on a typical use case for the healthcare industry. Keywords—Semantic web, RDF, N3Logic, reasoning, GUI, Agfa, healthcare
I. I NTRODUCTION
T
ODAY , the implementation and design of graphical user interfaces is not a straightforward task. Software developers have to design graphical user interfaces for a variety of users, a variety of tasks and a variety of heterogeneous platforms. Furthermore, a developer needs be aware of a rising number of user design parameters, such as company guidelines, usability patterns and accessibility constraints. Needless to say, development and maintenance costs rise due to this increasing development complexity. On the other hand, last years have showed an increasing research interest in so-called semantic web technologies. Seen as the successor to the World Wide Web, the ambition of the semantic web is to provide a web of machine-accessible data with formalised semantics. The foundations for these technologies are being laid by the World Wide Web Consortium, standardizing technologies such as RDF, RDF-S, OWL, RIF, . . . Also, several reasoners (such as Euler) have been developed, enabling users (and machines) to reason over knowledge declared using those technologies. In this abstract, we claim that the concept of using reasoning can be introduced in the process of GUI generation, with the ultimate goal of making the task of software developers lighter and their labour less error-prone. We propose a model wherein much of the knowledge developers need to take into account can be explicitly declared using ontologies and rules. We then use reasoning software such as Euler to generate custom graphical user interfaces, based on an abstract GUI description.
information also needs to be processed by the user. As an example of clinical information, symptoms such as blood pressure, body temperature and pulse need to be recorded. If however, a patient needs several examinations for different reasons, similar symptoms must only be presented and processed once. The form also needs to be dependent of the context of the user, which comprises the user’s environment, the platform and the device the user is running. Equally important is the fact that the form needs to be adapted to the user’s preferences and to the guidelines of the organisation in which the user operates. III. G ENERAL A PPROACH A. Knowledge domain vs. Execution domain The introduction of the notion “knowledge” in the world of graphical user interfaces introduces a declarative concept in an otherwise very procedural world. In the traditional way, the development of GUI’s is associated with programming languages such as C, C++, C#, JAVA, etc. In these procedural languages, the behaviour of a function is described in a list of sequential actions, such as function calls, assignments, comparisons, . . . In RDF based knowledge representation however, knowledge is represented using triples in the form of (subject, property, object). Once a triple is declared, it is considered true. There is no notion of “behaviour” or “sequence of actions” in the knowledge domain. This poses a natural tension between a procedural environment, such as the user’s execution domain and a knowledge domain such as expressed in RDF triples. One of the goals of this abstract is to overcome this tension.
Knowledge domain
web server
HTTP
Execution domain
web of proof engines
II. U SE C ASE In healthcare, the well-being of the patient is key. It is therefore imperative that health care workers always have access to correct and relevant information. Furthermore, the presentation of this information can be different for every user, based on the user’s context, the organisation the user operates in, the role of the user and finally the user’s preferences. Adapting the presentation based on the needs of the user is important to guarantee efficiency. We define an application in which a GUI form needs to present information of administrative and clinical nature. This
reasoning software
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 of graphical user interfaces, we first need to declare their characteristics. We therefore need a vocabulary to provide the terms and concepts we can use in these descriptions. To this purpose
we define an abstract GUI ontology, in which implementationindependent user interface elements are defined. These elements must be general in a way that they are omnipresent in a wide range of GUI toolkits and implementations. Once this ontology is established, we can use it’s vocabulary to define abstract graphical user interfaces. These abstract versions contain all the information that is necessary in all final versions of the form. Other information is omitted and should be added afterwards using rules.
IV. I MPLEMENTATION To illustrate the proposed general approach, we present an implementation of the described use case. This implementation relies on the web browser as an application platform and uses xHTML as a presentation format. This does not impose a limitation on the achieved results, because XML-based description languages are becoming more and more common. Examples include the widespread XAML by Microsoft in [3] and XUL in [4] by the Mozilla project.
C. Other 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 form for the user. We propose to do this using rules. Rules are in essence a different way of expressing knowledge compared to ontologies. Using technology such as N3Logic however, we are able to harness the power of both ontologies and rules within one notation. In our approach of generating GUI’s, we use reasoning to produce custom forms based on the abstract form’s description, the description of the user’s context and rules that alter the characteristics of the form and act based on the user’s context. It is this very powerful concept that will allow us to make any kind of alteration to the abstract forms we defined earlier to achieve a fully customized form.
web browser
web server
Asynchrone XmlHTTPRequests
Aside from the abstract GUI ontology, there is a need for other ontologies describing common characteristics of user preferences, device capabilities, user roles, usability patterns, accessibility constraints, user contexts, company guidelines and so on. For some of the beforementioned ontologies, there are already standards in active development. For example, the Composite Capabilities / Preference Profiles W3C working group has already issued a W3C Working Draft in which a standard is being proposed for the description of device capabilities and user preferences. On the other hand there are other domains without apt proposals. It is however out of the scope of our research to provide for these ontologies.
FAT CLIENT
XHTML & CSS & JAVASCRIPT
Fig. 2. The implementation of the use case uses the web browser as the application platform
By this demonstration model we prove that the approach taken on this problem is effective and therefore introducing reasoning in the generation of GUI’s is definitely worthy of further research. V. C ONCLUSION We presented a general approach towards the introduction of reasoning in the generation of user interfaces. This approach is valid, but depends largely on a variety of ontologies that have not been standardized by domain experts. However, we have implemented a proof-of-concept that illustrates the approach and the very powerful concept of customized GUI generation based on reasoning. R EFERENCES
E. Mapping As a final piece of the puzzle in our approach, we need to map the customized description of the form in terms of the abstract GUI ontology to a more specialized terminology, based on the final implementation. Indeed, we need to “translate” the abstract GUI definitions to a more specialised, implementation dependent form. We achieve this transformation step by defining a ruleset for each implementation language, thus effectively mapping abstract concepts to the underlying GUI toolkit’s concepts. F. Presentation With all the knowledge of the former sections combined, an implementation specific form, customized on the user’s context will be forwarded to the execution environment. This environment must carry a component that can interpret this knowledge en build an instance of the form.
[1]
RDF/XML Syntax Specification, http://www.w3.org/ TR/ rdf-syntaxgrammar/ [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 2.1
6
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 2.3.1
. . . . . . . . . . . . . . . . . . . 15
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
Ontologie¨en 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 3.1
3.2
3.3
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
Use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.2.1
Definitie . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.2
Voordelen van op redeneren gebaseerde GUI generatie . 33
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 4.1
28
42
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: ontologie¨en 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 semantisch web in het algemeen is dat men door machines te laten redeneren over verschillende bronnen van kennis en regels nieuwe informatie kan afleiden. Door deze informatie aan te wenden in de executie-omgeving van de gezondheidswerker wordt de mogelijkheid geboden dagelijkse taken te vereenvoudigen.
1
Hoofdstuk 1. Inleiding Een goed voorbeeld hiervan is het bieden van ’decision support’ aan de gebruiker van een medische applicatie (bvb. een arts of verpleger). Hierbij wordt door reasoning engines een pati¨entspecifieke klinische workflow afgeleid op basis van vooraf gedeclareerde algemene medische guidelines en andere bronnen van kennis. Dit kunnen bvb. specifieke gegevens over de pati¨ent zijn. Hierdoor wordt voor de gebruiker een procedure opgesteld die niet alleen aangepast is aan de noden van de pati¨ent 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 principe ook op hogere en lagere niveaus kan worden toegepast. Een voorbeeld van een toepassing op hoger niveau is de monitoring van een pati¨ent 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
kennis
kennis & regels
reasoning
regels
nieuwe informatie
Figuur 1.1: Door machines te laten redeneren over expliciet gedeclareerde kennis en regels, kunnen we nieuwe, nuttige informatie afleiden.
2
Hoofdstuk 1. Inleiding 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 ´e´en 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 gebruikersinterfaces 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
Hoofdstuk 1. Inleiding
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, pati¨entinformatie, etc. Hiervoor gaan we als volgt te werk: Onderzoek naar de state of the art van het semantisch web. Welke
technologie¨en 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 gebruikersinterfaces illustreert.
1.4
Overzicht
In hoofdstuk 2 onderzoeken we de state of the art van het huidige semantisch web. We bespreken de architectuur en daardoor ook enkele standaarden 4
Hoofdstuk 1. Inleiding 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 voornaamste 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 ´e´en 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 representatie 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
href href
URI URI
URI
href href URI
Figuur 2.1: Het WWW bestaat uit resources (aangeduid door URI’s) die door hyperlinks (href) met elkaar zijn geconnecteerd.
7
Hoofdstuk 2. Het Semantisch Web 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 weergegeven. Een begintag is steeds van de vorm <soortTag>, een eindtag wordt steeds geschreven als . 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 zoekmachines ontworpen. Zij hebben de toename aan populariteit van het WWW zeker in grote mate gestimuleerd. Een zoekmachine bestaat uit een aantal onderdelen. E´en 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
Hoofdstuk 2. Het Semantisch Web Voor de gebruiker is het belangrijkste deel van de zoekmachine echter de interface. Deze laat hem/haar toe een zoekopdracht te defini¨eren. Vervolgens zal de zoekmachine een lijst van hyperlinks weergeven die refereren naar pagina’s die een grote correlatie vertonen met de zoekopdracht. Meestal hanteren 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 zoekmachines 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
Hoofdstuk 2. Het Semantisch Web 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 stellen 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 extension of the current one, in which information is given well-defined meaning, better enabling computers and people to work in cooperation. 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 functionality as machines become much better able to process and ‘understand’ the data that they merely display at present.”
10
Hoofdstuk 2. Het Semantisch Web 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 introductie 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 semantisch 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
Hoofdstuk 2. Het Semantisch Web werelden: een web van data en documenten, met een natuurlijke representatie 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 toevoegen en raadplegen. Dit maakt het WWW een zeer democratisch medium, wat opnieuw ´e´en van de katalysatoren is voor haar succes. Vandaag is het Word Wide Web Consortium (W3C) de autoriteit voor standaardisatie 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 ´e´en van de stuwende krachten achter de innovatie en onderzoek naar nieuwe technologie¨en. 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 onderzoeksgroepen. 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 technologie¨en die in dit hoofdstuk – en algemener: in deze hele scriptie – aan bod komen zijn nog in volle ontwikkeling in onderzoeksgroepen 12
Hoofdstuk 2. Het Semantisch Web 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 ’Technology 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 information management, enterprise application integration, and the global sharing of commercial, scientific and cultural data. Facilities 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 worden 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
Hoofdstuk 2. Het Semantisch Web 2. (Last Call Working Draft) 3. Candidate Recommendation (CR) 4. Proposed Recommendation (PR) 5. W3C Recommendation (REC)
Hierbij is de Working Draft het initi¨ele 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 implementeerbaarheid van de standaard te onderzoeken. Vaak speelt de industrie hier dus een rol. Hierna wordt het document een Proposed Recommendation. Hoewel de overgang naar W3C Recommendation vaak met geringe wijzigingen gebeurt, is dit niettemin een belangrijke stap. Dit document moet immers worden goedgekeurd 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 verschillende 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
Hoofdstuk 2. Het Semantisch Web
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
Hoofdstuk 2. Het Semantisch Web 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 technologie¨en 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 technologie¨en van de architectuur.
2.3.2
Uniform Resource Indicator (URI)
Een URI is een compacte string van karakters die ´e´en enkele resource identificeert. Bewust is het begrip “resource” hier niet nader bepaald. We kunnen 1
De laatste versie van HTML, xHTML (eXtensible HyperText Markup Language) is
een XML dialect van HTML dat als de huidige standaard wordt aanzien.
16
Hoofdstuk 2. Het Semantisch Web 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 beschreven worden in een bericht. Resources die slechts benaderend kunnen gekarakteriseerd 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 Locator. Een voorbeeld is http://www.example.com/. In deze string duidt http: het URI schema aan. http: is het schema dat gebruikt wordt om computerbestanden (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 schema’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 defini¨eren van de URI schema’s wordt daarom gecontroleerd door IANA (Internet Assigned Numbers Authority). 17
Hoofdstuk 2. Het Semantisch Web
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 omgevingen. 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 karakters van juist 1 byte groot. Daarom zijn voor Unicode enkele encoderingsschema’s opgesteld die hier rekening mee houden. E´en 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 gebruiken. Daarom is Unicode de de facto standaard bij de aanmaak van XML bestanden. Hoewel Unicode ´e´en 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
Hoofdstuk 2. Het Semantisch Web
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 defini¨eren. 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.
< t i t l e>Weaving t h e Web Tim Berners −Lee
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 datauitwisseling niet langer aangewezen is op implementatiespecifieke representatievormen, zoals die van een databank, zonder de structuur die verbonden is aan die data te verliezen.
19
Hoofdstuk 2. Het Semantisch Web XML Schema en namespaces Het vastleggen van de typische structuur van een specifieke XML-applicaties gebeurt d. m. v. XML Schema. Een XMLapplicatie 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 defini¨eren 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 x m l n s : l i b r a r y 1=” h t t p : //www. l i b r a r y 1 . com/ l i b r a r y . xsd ” x m l n s : l i b r a r y 2=” h t t p : //www. l i b r a r y 2 . com/ l i b r a r y . xsd ”> < l i b r a r y 1 : t i t l e>Weaving t h e Web Tim Berners −Lee
Namespaces zorgen dus voor een modularisatie van XML Schema, zodat verschillende XML Schema in dezelfde context door elkaar gebruikt kunnen 20
Hoofdstuk 2. Het Semantisch Web 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 defini¨eren 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 architectuur 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
Hoofdstuk 2. Het Semantisch Web 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: 2
Hierbij bedoelen we op dit moment niet de syntax, wel het model.
22
Hoofdstuk 2. Het Semantisch Web
property object
subject
Figuur 2.3: Een triple kunnen we voorstellen als een gerichte gelabelde graaf.
Codefragment 2.3: Voorbeeld van een RDF fragment.
August 1 6 , 1999
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 element. Het subject van het triple wordt hierbij opgenomen als attribuut rdf:about in de tag. In dit geval is het een statement met als subject http://www.example.org/ index.html. Binnen het element wordt dan een sequentie van elementen opgenomen waarbij de tagname 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
Hoofdstuk 2. Het Semantisch Web 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
Ontologie¨ en en regels
Een ontologie is een formele beschrijving van een kennisdomein. De ontologie bepaalt het vocabularium en het gebruik van concepten en relaties. Bovendien tracht een ontologie zoveel mogelijk relaties binnen dat kennissysteem te karakteriseren en legt ze er zo extra beperkingen op. Men kan bovendien verschillende ontologie¨en defini¨eren voor dezelfde domeinen. 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 drukken dat verschillende termen uit verschillende ontologie¨en hetzelfde concept aanduiden. Dit is op zichzelf al een ontologie. Hierdoor hoeft de verspreide 24
Hoofdstuk 2. Het Semantisch Web natuur van kennis op het web geen beperking te vormen voor de algemene werking. Voor de definitie van ontologie¨en op het semantisch web zijn enkele expressiemechanismen 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 klassehi¨erarchie¨en en geassocieerde hi¨erarchie¨en van eigenschappen (properties) te defini¨eren, met een beperkte mogelijkheid om het domein en het bereik van die eigenschappen te specifi¨eren. OWL biedt ruimere expressiemogelijkheden om een kennisdomein te beschrijven. We merken op dat de mate van expressiviteit van een ontologie- beschrijvingstaal vaak een negatieve relatie heeft tot de complexiteit van de bewijsvoeringsstrategie¨en: hoe expressiever de taal, hoe complexer de bewijsvoering (in het slechtste geval) [2]. Naast ontologie¨en kan men ook gebruik maken van regels om expliciet kennis over een domein te declareren. Regels maken het mogelijk om bvb. beperkingen 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 ´e´en 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
Hoofdstuk 2. Het Semantisch Web 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, ontologie¨en (RDF-S en OWL) en regels (RIF) kunnen door de technologie¨en 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 aanwezig 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 predicatenlogica of eerste-orde logica, zoals beschrijvingslogica (Description Logic) en regelsystemen zoals Horn logica. Door deze logica in software te implementeren, slaagt men erin logische consequenties te trekken uit bepaalde premisses, gedefinieerd in hogervermelde formaten. Bovendien biedt predicatenlogica een systeem voor bewijsvoering die juistheid 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 antwoorden. Door de gedistribueerde natuur van het web is een bewijsvoering alleen niet genoeg om te betrouwen op de resultaten van redeneersoftware. Immers,
26
Hoofdstuk 2. Het Semantisch Web 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, ontologie¨en 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 technologie¨en, 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 introduceren 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 redeneersoftware in te zetten bij de generatie van GUI’s.
3.1
Grafische gebruikersinterfaces (GUI’s)
De gebruikersinterface (Eng. : user interface (UI)) is ´e´en 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 effici¨entie 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 gemaakt worden voor verschillende toestellen met zeer uiteenlopende eigenschappen. Zo kan het zijn dat een bepaalde toepassing zowel op een doorsnee PC als op een PDA moet kunnen gebruikt worden. Vaak vereisen verschillende soorten gebruikers ook verschillende interfaces om in essentie dezelfde informatie te bewerken. Deze formulieren zijn dan aangepast aan bvb. de 1
De eerste GUI werd genoteerd in de de jaren ’70 in het Palo Alto Resarch Center van
Xerox
29
Hoofdstuk 3. Gebruik van redeneersoftware bij de generatie van GUI’s 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 ontwikkelaars.
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 huisstij30
Hoofdstuk 3. Gebruik van redeneersoftware bij de generatie van GUI’s len uit die moeten garanderen dat de GUI’s consistente lay-outs en stijlen gebruiken doorheen elke applicatie en – indien mogelijk – doorheen de hele productfamilie. ...
3.1.3
2 uiteenlopende taken, 1 ontwikkelaar
huisstijl
toesteleigenschappen
toegankelijkheid platform
ontwikkelaar
usability patterns
gebruikerspreferenties
taal
Figuur 3.1: Een softwareontwikkelaar wordt vaak geconfronteerd met zeer veel randvoorwaarden.
Niettegenstaande implementatie en ontwerp expertises vereisen die niet vaak aanwezig zijn in ´e´en en dezelfde persoon, is het net vaak ´e´en 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 toestellen – moet het ontwerpproces vaak aan belang inboeten. Daarbij komt 31
Hoofdstuk 3. Gebruik van redeneersoftware bij de generatie van GUI’s 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 defini¨eren we nu een use case. Deze definitie is belangrijk, aangezien we op deze use case verder zullen bouwen bij de implementatie van een demonstratiemodel. 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 pati¨ent. 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 informatie, 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
Hoofdstuk 3. Gebruik van redeneersoftware bij de generatie van GUI’s Aldus defini¨eren we een applicatie, waarbij een formulier gegevens over pati¨enten moet kunnen voorstellen en de verwerking ervan toelaten. Deze gegevens zijn zowel van administratieve als klinische aard. Zo moet de gebruiker in staat zijn de meetwaarden van enkele symptomen, zoals bloeddruk, temperatuur, 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 pati¨ent meer dan ´e´en onderzoek gepland heeft voor verschillende doeleinden, de meetwaarden van symptomen die door de gezondheidswerker in kwestie mogen worden vastgesteld te groeperen in ´e´en formulier. Hierbij moet echter vermeden worden dat bepaalde gegevens meermaals moeten worden ingevuld. Het formulier moet ook afhankelijk zijn van de context waarbinnen de gebruiker 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 generatie
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
Hoofdstuk 3. Gebruik van redeneersoftware bij de generatie van GUI’s
Figuur 3.2: E´en 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 pati¨entspecifieke 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
Hoofdstuk 3. Gebruik van redeneersoftware bij de generatie van GUI’s De ambitie bestaat er nu in deze kennis expliciet te declareren m. b. v. de technologie¨en 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 kennisdomein en de executie-omgeving.
KENNIS DOMEIN
Toestel beschrijving
GUI ?
Abstracte GUI Widgets
Gebruikers preferenties Abstracte GUI regels Finale GUI Mapping Company Guidelines
Semantisch web
R E D E N E E R S O F T W A R E HTTP
Figuur 3.3: Algmene benadering
35
EXECUTIE-OMGEVING
GUI
Hoofdstuk 3. Gebruik van redeneersoftware bij de generatie van GUI’s
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 bronnen aan die we zullen gebruiken. Elke bron duidt een brok kennis aan, vastgelegd volgens het datamodel van RDF. We zullen daarom vaak in termen van triples spreken. In die triples liggen ontologie¨en, 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 specifieker: 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 executieomgeving een procedurale context. Hierbij leggen procedures vast hoe men een bepaald resultaat kan bereiken. Voorbeelden van procedurale programmeertalen 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. E´en van de uitdagingen bestaat er nu in 36
Hoofdstuk 3. Gebruik van redeneersoftware bij de generatie van GUI’s 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 kennisdomein. 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 toolkits 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
Hoofdstuk 3. Gebruik van redeneersoftware bij de generatie van GUI’s volledig te zijn. Nadat we een algemeen bruikbare ontologie hebben opgesteld, hebben we de middelen om een eerste formulier te defini¨eren.
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 defini¨eren 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
Hoofdstuk 3. Gebruik van redeneersoftware bij de generatie van GUI’s Ontologie¨ en voor gebruikerspreferenties, huisstijlen, toestelbeschrijvingen en regelverzamelingen
Nu we de basis hebben gelegd voor de definitie van een formulier kunnen we verdergaan door het kennisdomein uit te breiden met ontologie¨en voor andere bronnen van kennis die we zullen gebruiken bij de generatie van het uiteindelijke formulier. Voor bepaalde domeinen, zoals gebruikerspreferenties en toestelbeschrijvingen zijn reeds ontologie¨en in de maak. Zo is er Composite Capabilities/Preference 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 beschrijving van de GUI aanpassen. Dit doen we door regels te defini¨eren die de kenmerken van de abstracte GUI wijzigen.
Mapping van de abstracte GUI beschrijving naar implementatieafhankelijke triples
Aangezien het uiteindelijke formulier moet worden voorgesteld in een executieomgeving die een bepaalde GUI toolkit gebruikt, moeten we in een finale stap
39
Hoofdstuk 3. Gebruik van redeneersoftware bij de generatie van GUI’s nog een mapping doorvoeren van het formulier dat aangepast is aan de context, 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:
kennisdomein
web server
HTTP
executie domein
web of proof engines redeneersoftware
Figuur 3.4: Schematisch overzicht van de entiteiten in het communicatieproces tussen executie-domein en kennisdomein.
40
Hoofdstuk 3. Gebruik van redeneersoftware bij de generatie van GUI’s In figuur 3.4 zijn de sleutelelementen in deze overgang opgenomen. We beschrijven 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 ontologie¨en gedefinieerd in het kennisdomein. 2. Vanuit de executie-omgeving gebeurt een oproep naar de redeneersoftware. In deze oproep worden de triples die de context defini¨eren meegegeven. 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, cre¨eert
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 realiseerbaarheid 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 browser
server
Asynchrone XmlHTTPRequests
web
FAT CLIENT
XHTML & CSS & JAVASCRIPT
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 gebruikersinterface 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 1
Dit zijn applicaties die onmiddellijk onder het besturingssysteem draaien en niet af-
geschermd worden door een andere omgeving.
43
Hoofdstuk 4. Implementatie van een proof-of-concept de ontwikkeling van GUI’s neigt steeds meer naar een definitie van gebruikersinterfaces 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 layout 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 realiseren. 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
Hoofdstuk 4. Implementatie van een proof-of-concept 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 testopstelling:
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]. 2
Representational State Transfer is een principe waarbij men berichten verzendt over
HTTP zonder dat een extra laag een toestand bijhoudt. 3 Beschikbaar gesteld door Douglas Crockford, senior JavaScript Architect bij Yahoo!
45
Hoofdstuk 4. Implementatie van een proof-of-concept
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 datamodel 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 uitgebuit. Voor hetgeen volgt volstaat het volgend codefragment te bekijken: Codefragment 4.1: Voorbeeld van een Notation3 fragment. < t i t l e>Weaving t h e Web Tim Berners −Lee
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 neerschrijven. 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 ´e´en triple genoteerd. Dit gebeurt in de vorm 46
Hoofdstuk 4. Implementatie van een proof-of-concept subject property object. In dit geval is subject een URI. URI’s worden 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 overgenomen. Tenslotte is object in het voorbeeld een literal. Vermeldenswaardig hierbij is dat strings steeds tussen dubbele aanhalingstekens worden genoteerd. N3 wordt vaak in ´e´en 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. existenti¨ele 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 redeneersoftware beschikbaar wordt gemaakt als RESTfull web service. Zoals reeds aangegeven in4.1.1 staat REST voor “Representational State Transfer”. 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
Hoofdstuk 4. Implementatie van een proof-of-concept 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 services, 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: ontologie¨ en en regels
Nu we de testopstelling besproken hebben, gaan we over tot het eigenlijke ontwerp van de ontologie¨en die we zullen gebruiken om de use case te imple48
Hoofdstuk 4. Implementatie van een proof-of-concept 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 beschrijven. 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 gebruikersinterface beschreef. We merkten ook op dat deze scriptie zeker niet pretendeert een toereikende ontologie voor te stellen. Immers, het ontwerp van een algemene ontologie die het domein van gebruikersinterfaces beschrijft, is een studie op zich. In die context stellen we UsiXML ([19]) voor, een project van de Universit´e 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 multimodale gebruikersinterfaces. Men tracht het concept gebruikersinterface dus op een zo algemeen mogelijke manier te benaderen en dit onafhankelijk van implementatiespecifieke karakteristieken. 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 gebruikersinterfaces. 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, invoervelden, 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 nietimplementatiespecifieke 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 abstractieniveau in: de Abstract User Interface (AUI). Bij een AUI maakt men abstractie van de interactiemodaliteit. Interactiemodaliteiten kunnen grafisch, 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 abstractieniveaus. 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, onafhankelijk van de uiteindelijke implementatie, interactiemodaliteit en platform. 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 abstractieniveau overeenstemde met dat van de CUI. Het lijkt ons dan ook opportuun 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 uitspitten 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 technologie¨en 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, ontologi¨en, 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 generatie van GUI’s. Deze houdt o. a. de definitie van een ontologie voor algemene GUI’s in die abstractie maakt van de onderliggende implementatie, ontologie¨en 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 illustreren 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 interest 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 ture
and
capability/preference vocabularies
profiles
2.0.
(cc/pp):
Struc-
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. Universit´e 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.1
2
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
E´en use case leidt al vaak tot een waaier van andere formulieren voor dezelfde taak. . . . . . . . . . . . . . . . . . . . . . . 34
3.3
Algmene benadering . . . . . . . . . . . . . . . . . . . . . . . 35
61
Lijst van figuren 3.4
Schematisch overzicht van de entiteiten in het communicatieproces 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
