web information systems analysis, design, development, and

Web Information SystemsAnalysis, Design, Development, and Implementation of

Business Sites, Collaboration Sites, Edutainment(e-Learning) Sites, and Infotainment (Information) Sites

Collection of Recent Papers

Bernhard Thalheim

Christian-Albrechts-University Kiel, Department of Computer Science, 24098 Kiel, [email protected]

A Web Information System (WIS) is an information system that can be accessedthrough the world-wide-web. On a high level of abstraction a WIS can be described bya storyboard [ST05b], which in an abstract way specifies who will be using the system,in which way and for which goals. In a nutshell, a storyboard consists of three parts:

– a story space, which itself consists of a hierarchy of labelled directed graphs calledscenarios, one of which is the main scenario, whereas the others define the details ofscenes, i.e. nodes in a higher scenario, and a plot that is specified by an assignment-free process, in which the basic actions correspond to the labels of edges in thescenarios,

– a set of actors, i.e. abstractions of user groups that are defined by roles, which de-termine obligations and rights, and user profiles, which determine user preferences,

– and a set of tasks that are associated with goals the users may have.

In addition, there are many constraints comprising static, dynamic and deontic con-straints for pre- and postconditions, triggering and enabling events, rights and obli-gations of roles, preference rules for user types, and other dependencies on the plot.Details of storyboarding have been described in [ST05b]. An overview of our methodfor the design of WISs was presented in [ST05d].

While syntax and semantics of storyboarding has been well explored, its pragmat-ics apart from the use of metaphors [TD00] has not. Pragmatics is part of semiotics,which is concerned with the relationship between signs, semantic concepts and thingsof reality. This relationship may be pictured by the so-called semiotics triangle. Mainbranches of semiotics are syntactics, which is concerned with the syntax, i.e. the con-struction of the language, semantics, which is concerned with the interpretation of thewords of the language, and pragmatics, which is concerned with the current use of ut-terances by the user and context of words for the user. Pragmatics permits the use of avariety of semantics depending on the user, the application and the technical environ-ment. Most languages defined in Computer Science have a well-defined syntax; someof them possess a well-defined semantics; few of them use pragmatics through whichthe meaning might be different for different users.

Syntactics is often based on a constructive or generative approach: Given an alpha-bet and an set of constructors, the language is defined as the set of expressions thatcan be generated by the constructors. Constructions may be defined on the basis ofgrammatical rules.

Semantics of generative languages can be either defined by meta-linguistic seman-tics, e.g. used for defining the semantics of predicate logics, by procedural or referentialsemantics, e.g. operational semantics used for defining the semantics of programminglanguages, or by convention-based semantics used in linguistics. Semantics is often de-fined on the basis of a set of relational structures that correspond to the signature of thelanguage.

Pragmatics has to be distinguished from pragmatism. Pragmatism means a practi-cal approach to problems or affairs. According to Webster [Web91] pragmatism is the“balance between principles and practical usage”. Here we are concerned with prag-matics, which is based on the behaviour and demands of users, therefore depends onthe understanding of users.

The six characteristics of WISs that were discussed in [ST05b] can be mapped toconceptual structures that are used for storyboard specification:

1. We start with the characteristics used for the strategic layer. Main specificationelements used are intention and mission. They are mapped to metaphors, generalgoals, rhetorical figures, and patterns and grids of web pages discussed later.

2. The scenarios reflect the utilisation by actors, for which we envision a number ofstories that correspond to real use. These scenarios may be captured through ob-servation of reality. Story spaces and plots are recorded in various level of detailthrough the methods discussed in [ST05b]. The stories are reflected in the story-board.

3. Content specification is the basis for the media types, i.e. data types and their func-tions, which will be introduced in part III. It combines data specification with userrequirements and is reflected in the content portfolio.

4. Functionality is provided by the media types as required by the storyboard. Typicalstandard functions are navigation, retrieval (search), support functions, and feed-back facilities.

5. Context is based on tasks, history, and environment. We use the specification ofcontext for restructuring and functionality enhancement, which will form the basisof XSL transformations and the onion approach that is discussed in the last part ofthe book.

6. Presentation depends on the intention, the provider, the technical environment avail-able and the users the WIS is targeting at. Presentation results in the layout andthe playout of the WIS. Layout requires the development of multimedia presenta-tions for each page. Playout additionally requires the development of functionalitythat supports visits of users depending on the story they are currently followingto achieve their goals. Layout and playout integrate the chosen metaphors; theydepend on chosen page patterns and grids as well as on quality requirements.

Conceptual structures and their association are depicted in Figure 1. We may sepa-rate the syntactics and pragmatics layers. Arrows are used for representing part-of- or

uses- or relates-associations. For instance, the story is based on the user and the func-tions. Information metaphors relate content to information.

Y6

?

¼

*

j

Technical environmentof the user

User

Datarepresentation

Data Functions

Functionrepresentation

Y

U

j

Information

®

¼

Story

*

jContent

¼

YFunctionality

¸*

O

Layout

KY

º

Playout

µ

N

Informationmetaphors

Y

°

Story andfunctionalitymetaphors

Web utilisation space

PR

AG

MA

TIC

SS

YN

TAC

TIC

S

Fig. 1. The Web Utilization Space Based On the Characteristics of WIS

We use the notions of information and content in a specific manner. Information asprocessed by humans, is carried by data that is perceived or noticed, selected and orga-nized by its receiver, because of his subjective human interests, originating from his in-stincts, feelings, experience, intuition, common sense, values, beliefs, personal knowl-edge, or wisdom, simultaneously processed by his cognitive and mental processes, andseamlessly integrated in his recallable knowledge. Content is complex and ready-to-usedata. Content management systems are information systems that support extraction,storage and delivery of complex data. Content may be enhanced by concepts that spec-ify the semantic meaning of content objects and by topics that specify the pragmaticunderstanding of users.

Therefore, information is directed towards pragmatics, whereas content may be con-sidered to highlight the syntactical dimension. If content is enhanced by concepts andtopics, then users are able to capture the meaning and the utilisation of the data theyreceive. In order to ease perception we use metaphors. Metaphors may be separatedinto those that support perception of information and into those that support usage orfunctionality.

The information transfer from a user A to a user B depends on the users A and B,their abilities to send and to receive the data, to observe the data, and to interpret thedata. Let us formalise this process. Let sX denote the function user by a user X for dataextraction, transformation, and sending of data. Let rX denote the corresponding func-tion for data receival and transformation, and let oX denote the filtering or observationfunction. The data currently considered by X is denoted by DX . Finally, data filteredor observed must be interpreted by the user X and integrated into the knowledge KX

a user X has. Let us denote by iX the binary function from data and knowledge to

knowledge. By default, we extend the function iX by the time tiXof the execution of

the function.Thus, the data transfer and information reception (or briefly information transfer) is

formally expressed it by

IB = iB(oB(rB(sA(DA))),KB , tiX ) .

In addition, time of sending, receiving, observing, and interpreting can be takeninto consideration. In this case we extend the above functions by a time argument.The function sX is executed at moment tsX

, rX at trX, and oX at toX

. We assumetsA

≤ trB≤ toB

≤ tiBfor the time of sending data from A to B. The time of a

computation f or data consideration D is denoted by tf or tD, respectively. In thisextended case the information transfer is formally expressed it by

IB = iB(oB(rB(sA(DA, tsA), trB

), toB),KB , tiB

) .

messagesender receiver

content

s-r-relationship

appeal to

receiver

presen-

tation

Fig. 2. Dimensions of understanding messages

The notion of information extends the dimensions of understanding of message dis-played in Figure 2 to a web communication act that considers senders, receivers, theirknowledge and experience. Figure 3 displays the multi-layering of communication, theinfluence of explicit knowledge and experience on the interpretation.

The communication act is specified by

– the communication message with the content or content chunk, the characterisationof the relationship between sender and receiver, the data that are transferred andmay lead to information or misinformation, and the presentation,

– the sender, the explicit knowledge the sender may use, and the experience thesender has, and

– the receiver, the explicit knowledge the receiver may use, and the experience thereceiver has.

The communication act is the basis for sagas that are the basic units of stories.Users are reflected by actors that are abstractions of groups of users. Pragmatics and

syntactics share data and functions. The functionality is provided through functions andtheir representations. The web utilisation space depends on the technical environment ofthe user. It is specified through the layout and the playout. Layout places content on thebasis of a data representation and in dependence of the technical environment. Playout

communicationactsender receiver

data(information, misinformation)

sender-receiver relationship

appeal to

receiver

formappearance,

gestaltpresentation

explicitknowledge

explicitknowledge

experienceexperience data

- -

- -

Fig. 3. Dimensions of the communication act

is based on functionality and function representations, and depends on the technicalenvironment.

We may base the pragmatics of storyboarding on two ingredients that are easy todevelop:

The utilisation portfolio of the WIS: The utilisation portfolio consists of

– tasks users might wish to accomplish within the system,– goals of user groups, i.e. actors, and– actors that might use the web information system.

The profiles of the users: Profiles of users describe their abilities, skills, knowledge,and other dimensions. We map user profiles to preference rules for utilisation ofsystems.

Table of Content

1. Systematic development of internet sites: Extending approaches of conceptual mod-elingpublished in [DT03]related papers: [BZT03,DT01,DT04,FOST00,FT02]see also my website under miscellaneous or Verschiedenes: talks 2007/2008

2. The co-design approach to WIS development in e-business and e-learning applica-tionspublished in [ST04c]related papers: [DT02,ST05a,LTV07,FJM+08,ST05c,Tha04,Tha03,ST04d,ST07a]see also my website under miscellaneous or Verschiedenes: talks 2007/2008

3. Structural media types in the development of data-intensive web information sys-temspublished in [ST04b]related papers: [KSTW04,TSR+04,Sri00,Fey03,FRR+04,ST04d,ST04e,FRuDMT07]see also my website under miscellaneous or Verschiedenes: talks 2007/2008

4. Formalization of user preferences, obligations, and rightspublished in [STT06]related papers: [ST07c,?,STT07,ST07e,ST04a]see also my website under miscellaneous or Verschiedenes: talks 2007/2008

5. View Integration and Cooperation in Databases, Data Warehouses and Web Infor-mation Systemspublished in [MKDTZ05]related papers: [FRT05,MST05a]see also my website under miscellaneous or Verschiedenes: talks 2007/2008

6. Pragmatics of storyboarding for web information systems: Usage analysispublished in [ST07d]related papers: [ST08b,FKT04a,FSB04,STZ04,FKT04b,FSBST04,ST06]see also my website under miscellaneous or Verschiedenes: talks 2007/2008

7. Context analysis: Towards pragmatics of information system designpublished in [ST08b]related papers: [KSTZ03,BZKST04]see also my website under miscellaneous or Verschiedenes: talks 2007/2008

8. Intention-Driven Screenographypublished in [MNST07a]related papers: [NT08,MNST07b]see also my website under miscellaneous or Verschiedenes: talks 2007/2008

9. Quality assurance in Web Information Systems developmentpublished in [STZ]related papers: []see also my website under miscellaneous or Verschiedenes: talks 2007/2008

10. Strategic modeling of web information systemspublished in [MST05c]related papers: [MST05b,LTV07,FKT04a]see also my website under miscellaneous or Verschiedenes: talks 2007/2008

11. Databases of Personal Identifiable Informationpublished in [AFT08]related papers: [AFFT05,TAFAS08,AFT09]see also my website under miscellaneous or Verschiedenes: talks 2007/2008

12. Privacy enhanced information systemspublished in [AFFT05]related papers: [AFT08,TAFAS08,AFT09]see also my website under miscellaneous or Verschiedenes: talks 2007/2008, 2009

13. LIFE CASES: An Approach to Address Pragmatics in the Design of Web Informa-tion Systemspublished in [ST07b]related papers: [ST08d,TSM09,BT08]see also my website under miscellaneous or Verschiedenes: talks 2007/2008

14. Facets of Media Typespublished in [ST08c]related papers: [ST01,ST04b,MST05a]see also my website under miscellaneous or Verschiedenes: talks 2007/2008

15. Towards Semantic Wikis: Modelling Intensions, Topics, and Origin in ContentManagement Systemspublished in [FT09]related papers: []see also my website under miscellaneous or Verschiedenes: talks 2007/2008

16. A Conceptual View of Electronic Learning Systemspublished in [BZKK+05]related papers: [SBZ04,JMR+03,JLG+04]see also my website under miscellaneous or Verschiedenes: talks 2007/2008

17. Logistics for learning objectspublished in [BZTT03b]related papers: [JMR+03,SBZ04]see also my website under miscellaneous or Verschiedenes: talks 2007/2008

18. Towards Generative Engineering of Content-Intensive Applicationspublished in [BZ04b]related papers: [Bie08,BZ04a,BZTT03a,BST06,BZSBTT03,NT04,JLG+04,ST04c]see also my website under miscellaneous or Verschiedenes: talks 2007/2008

19. Adapting to Changing Times and Needspublished in [BZ04b,JLG+04,NT04]related papers: [ST08f,ST04c]see also my website under miscellaneous or Verschiedenes: talks 2007/2008

20. Storyboarding Concepts for Edutainment WISpublished in [ST08f]related papers: [BZ04a,BZTT03a,BZSBTT03,NT04,JLG+04,ST04c]see also my website under miscellaneous or Verschiedenes: talks 2007/2008

21. Pragmatics of Storyboarding - Web Information Systems Portfoliosto be published in WebIST’2010related papers: [ST08f,ST06,ST07b,ST07d,ST08b,JLG+04]see also my website under miscellaneous or Verschiedenes: talks 2007/2008

22. The Enhanced Entity-Relationship Modelpublished in [Tha09]related papers: [Tha00,Tha07a,ST08e,ST08a,Tha07b,DMT07,MDT04]see also my website under miscellaneous or Verschiedenes: talks 2007/2008

23. Generalisation and specialisationpublished in [Tha09]related papers: [Tha00,BT07]see also my website under miscellaneous or Verschiedenes: talks 2007/2008

24. Abstractionpublished in [Tha09]related papers: [Tha00]see also my website under miscellaneous or Verschiedenes: talks 2007/2008

References

[AFFT05] S. S. Al-Fedaghi, G. Fiedler, and B. Thalheim. Privacy enhanced information sys-tems. In Proc. EJC’05, Informaton Modelling and Knowledge Bases Vol. XVII,Series Frontiers in Arificial Intelligence,, Tallinn, 2005. IOS Press.

[AFT08] S. A. Al-Fedaghi and B. Thalheim. Databases of personal identifiable information.In Proc. 4th SITIS-SePTIS, pages 617–624. IEEE, ACM SIGAPP, 2008.

[AFT09] Sabah S. Al-Fedaghi and Bernhard Thalheim. Personal information databases.CoRR, abs/0909.4196, 2009.

[Bie08] A. Bienemann. A generative approach to functionality of interactive informationsystems. PhD thesis, CAU Kiel, Dept. of Computer Science, 2008.

[BST06] A. Bienemann, K.-D. Schewe, and B. Thalheim. Towards a theory of genericitybased on government and binding. In Proc. ER’06, LNCS 4215, pages 311–324.Springer, 2006.

[BT07] A. Berztiss and B. Thalheim. Exceptions in information systems. In DigitalLibaries: Advanced Methods and Technologies, RCDL 2007, pages 284–295, 2007.

[BT08] E. Borger and B. Thalheim. Modeling workflows, interaction patterns, web ser-vices and business processes: The ASM-based approach. In ABZ, volume 5238 ofLecture Notes in Computer Science, pages 24–38. Springer, 2008.

[BZ04a] A. Binemann-Zdanowicz. Sitelang::edu - towards a context-driven e-learning con-tent utilization model. In Proc. SAC’2004 (ACM SIGAPP), Nicosia, Cyprus, March2004, pages 924–928. Association for Computing Machinery, 2004.

[BZ04b] A. Binemann-Zdanowicz. Towards generative engineering of content-intensive ap-plications. In Proc. Principles of Software Engineering Conference (PRISE 2004),pages 41–49, 2004.

[BZKK+05] A. Binemann-Zdanowicz, R. Kaschek, T. Kuss, K.-D. Schewe, B. Thalheim, andB. Tschiedel. A conceptual view of electronic learning systems. Education andInformation Technologies, 2005.

[BZKST04] A. Binemann-Zdanowicz, R. Kaschek, K.-D. Schewe, and B. Thalheim. Context-aware web information systems. In APCCM’2004, volume 31, pages 37–48. Aus-tralian Computer Science Comm., 2004.

[BZSBTT03] A. Binemann-Zdanowicz, B. Schulz-Bruenken, B. Tschiedel, and B. Thalheim.Flexible e-payment based on content and profile in the e-learning system damit.In Proc. eLearn’2003, Phoenix, Arizona, USA, November 2003, pages 1802–1805,2003.

[BZT03] A. Binemann-Zdanowicz and B. Thalheim. Modeling of information services onthe basis of ASM semantics. In ASM’2003, LNCS 2589, pages 408 – 410. Springer,2003.

[BZTT03a] A. Binemann-Zdanowicz, B. Thalheim, and B. Tschiedel. Content modeling fore-learning services. In Proc. SCI’2003, Orlando, Florida, USA, July 2003, 2003.

[BZTT03b] A. Binemann-Zdanowicz, B. Thalheim, and B. Tschiedel. Logistics for learningobjects. In eTrain’2003, pages 315–324. Kluwer, 2003.

[DMT07] J. Demetrovics, A. Molnar, and B. Thalheim. Graphical axiomatisation of setsof functional dependencies in relational databases. In Alkalmazott MatematikaiLapok, volume 24, pages 223–264. 2007.

[DT01] A. Dusterhoft and B. Thalheim. Conceptual modeling of internet sites. In Proc.ER’01, LNCS 2224, pages 179–192. Springer, 2001.

[DT02] A. Dusterhoft and B. Thalheim. Integrating retrieval functionality in web sitesbased on story board design and word fields. In NLDB’2002, LNCS 2553, pages52 – 63, 2002.

[DT03] A. Dusterhoft and B. Thalheim. Information Modeling for Internet applications,chapter Systematic development of internet sites: Extending approaches of con-ceptual modeling, pages 80–101. Idea Group Publishing, 2003.

[DT04] A. Dusterhoft and B. Thalheim. Linguistic based search facilities in snowflake-likedatabase schemes. Data and Knowledge Engineering, 48:177–198, 2004.

[Fey03] T. Feyer. A Component-Based Approach to Human-Computer Interaction - Speci-fication, Composition, and Application to Information Services. PhD thesis, BTUCottbus, Computer Science Institute, Cottbus, Dezember 2003.

[FJM+08] G. Fiedler, H. Jaakkola, T. Makinen, B. Thalheim, and T. Varkoi. Co-design ofweb information systems supported by SPICE. In Proc. EJC 2008, 2008.

[FKT04a] G. Fiedler, U. Krautz, and B. Thalheim. SeSAM - support on profile, portfolio,and demand for (e-)parliamentarians. In Proc. e-Society’04, 2004.

[FKT04b] G. Fiedler, U. Krautz, and B. Thalheim. SeSAM - support on profile, portfolio,and demand for (e-)parliamentarians. In e-Society’04, pages 11–18, 2004.

[FOST00] T. Feyer, K. Odey, K.-D. Schewe, and B. Thalheim. Design of data-intensive web-based information services (proc. 1st intern. conf. on web information systemsengineering, wise’2000). In Proc. 1st Intern. Conf. on Web Information SystemsEngineering, WISE’2000, Hong Kong (China), June 19-21 2000.

[FRR+04] G. Fiedler, T. Raak, I. Romalis, K.-D. Schewe, and B. Thalheim. Website model-ing, website orchestration, and website management. In LIT’04, pages 219–228.infix Verlag, 2004.

[FRT05] G. Fiedler, T. Raak, and B. Thalheim. Database collaboration instead of integra-tion. In APCCM’05, 2005.

[FRuDMT07] K.-D. Schewe F. Riaz-ud Din, R. Noack, H. Ma, and B. Thalheim. Capturingforms in information systems design. In 4th International Conference on Innova-tions in Information Technology (Innovations’07), 2007.

[FSB04] G. Fiedler and T. Schwanzara-Bennoit. State and object oriented specificationof interactive VoiceXML information services. In Springer, editor, NLDB’2004,LNCS 3136, pages 13–25, 2004.

[FSBST04] G. Fiedler, T. Schwanzara-Bennoit, P. Schmidt, and B. Thalheim. State-, HTML-,and object-based dialog design for voice-web applications. In IWWOST’04, LNCS,pages 27–38, 2004.

[FT02] T. Feyer and B. Thalheim. A model for defining and composing interaction pattern.In EJC’2002, volume Information Modelling and Knowledge Bases XIV, pages277–289, 2002.

[FT09] G. Fiedler and B. Thalheim. Towards semantic wikis: Modelling intensions, topics,and origin in content management systems. Information Modelling and KnowledgeBases, XX:1–21, 2009.

[JLG+04] K.-P. Jantke, S. Lange, G. Grieser, P. Grigoriev, B. Thalheim, and B. Tschiedel.Learning by doing and learning when doing - dovetailing e-learning and decisionsupport with a data mining tutor. In ICEIS’2004, pages 238–241. INSTICC, 2004.

[JMR+03] K.-P. Jantke, M. Memmel, O. Rostanin, B. Thalheim, and B. Tschiedel. Deci-sion support by learning-on-demand. In DSE’2003, Workshops Proc., InformationSystems for a Connected Society, pages 317 – 328. CEUR Workshop Proc. 75Technical University of Aachen (RWTH), 2003.

[KSTW04] M. Kirchberg, K.-D. Schewe, B. Thalheim, and R. Wang. A three-level architecturefor distributed web information systems. In Springer, editor, ICWE’2004, LNCS3140, pages 137–141, 2004.

[KSTZ03] R. Kaschek, K.-D. Schewe, B. Thalheim, and Lei Zhang. Integrating context inconceptual modelling for web information systems, web services, e-business, andthe semantic web. In WES 2003, LNCS 3095, pages 77–88. Springer, 2003.

[LTV07] L. Landwehr, B. Thalheim, and A. Vitzthum. Navigieren in wissensstrukturen -benutzerprofile und neue retrievalstrukturen. In Tagung Kunst- und Medientech-nologie, Karlsruhe, pages 8–9, 2007.

[MDT04] A. Molnar, J. Demetrovics, and B. Thalheim. Graphical and spreadsheet reasoningfor sets of functional dependencies. Technical Report 2004-2, Christian AlbrechtsUniversity Kiel, Institute of Computer Science and Applied Mathematics, Kiel,2004.

[MKDTZ05] H. Ma, K.-D.Schewe, B. Thalheim, and J. Zhao. View integration and cooperationin databases, data warehouses and web information systems. Journal on DataSemantics, LNCS 3730, pages 213–249, 2005.

[MNST07a] T. Moritz, R. Noack, K.-D. Schewe, and B. Thalheim. Intention-driven screenog-raphy. In ISTA 2007, volume LNI 107, pages 128 – 139, 2007.

[MNST07b] T. Moritz, R. Noack, K.-D. Schewe, and B. Thalheim. Principles of screenography.In CAiSE Forum 2007, pages 73–76, 2007.

[MST05a] Hui Ma, K.-D. Schewe, and B. Thalheim. Integration and cooperation of mediatypes. In ISTA’05, 2005.

[MST05b] T. Moritz, K.-D. Schewe, and B. Thalheim. Strategic modeling of web informationsystems and its impact on visual design patterns. In F. Frasincar, G.-J. Houben, andR. Vdovjak, editors, WISM’05, pages 5–13, Sydney, 2005.

[MST05c] T. Moritz, K.-D. Schewe, and B. Thalheim. Strategic modelling of web informationsystems. International Journal on Web Information Systems, 1(4):77–94, 2005.

[NT04] P. Nicholson and B. Thalheim. Adaptation to learning styles. In UNESCO-SAMEAconference, 2004.

[NT08] R. Noack and B. Thalheim. Patterns for screenography. In Information Systems ande-Business Technologies, volume LNBIP 5, pages 484–495, Klagenfurt, Austria,2008. 2nd International United Information Systems Conference UNISCON 2008,Springer-Verlag Berlin Heidelberg.

[SBZ04] J. Sonnberger and A. Binemann-Zdanowicz. Kopra - ein adaptives Lehr-Lernsystem fur kooperatives Lernen. In GMW’2004, Graz, Austria, Sept. 2004,pages 274–285, 2004.

[Sri00] S. Srinivasa. An algebra of fixpoints for characterizing interactive behavior of in-formation systems. PhD thesis, BTU Cottbus, Computer Science Institute, Cottbus,April 2000.

[ST01] K.-D. Schewe and B. Thalheim. Modeling interaction and media objects. InM. Bouzeghoub, Z. Kedad, and E. Metais, editors, NLDB. Natural Language Pro-cessing and Information Systems, 5th Int. Conf. on Applications of Natural Lan-guage to Information Systems, NLDB 2000, Versailles, France, Jun 28-30, 2000,Revised Papers, volume 1959 of LNCS, pages 313–324. Springer, 2001.

[ST04a] K.-D. Schewe and B. Thalheim. Reasoning about web information systems usingstory algebra. In ADBIS’2004, LNCS 3255, pages 54–66, 2004.

[ST04b] K.-D. Schewe and B. Thalheim. Web Information Systems, chapter Structural me-dia types in the development of data-intensive web information systems, pages34–70. IDEA Group, 2004.

[ST04c] K.-D. Schewe and B. Thalheim. The co-design approach to wis development ine-business and e-learning applications. In Workshop Fragmentation versus Integra-tion, co-located with Fifth International Conference on Web Information SystemsEngineering (WISE 2004), LNCS 3307, pages 181–189. Springer, Nov. 2004.

[ST04d] K.D. Schewe and B. Thalheim. Web information systems: Usage, content, andfunctionality modelling. Technical Report 2004-3, Christian Albrechts UniversityKiel, Institute of Computer Science and Applied Mathematics, Kiel, 2004.

[ST04e] K.D. Schewe and B. Thalheim. Web information systems: Usage, content, andfunctionality modelling. Technical Report 2004-8, Massey University, PalmerstonNorth, 2004.

[ST05a] K.-D. Schewe and B. Thalheim. The co-design approach to web information sys-tems development. International Journal of Web Information Systems, 1(1):5–14,March 2005.

[ST05b] K.-D. Schewe and B. Thalheim. Conceptual modelling of web information sys-tems. Data and Knowledge Engineering, 54:147–188, 2005.

[ST05c] K.-D. Schewe and B. Thalheim. Conceptual modelling of web information sys-tems. Data and Knowledge Engineering, 54:147–188, 2005.

[ST05d] Klaus-Dieter Schewe and Bernhard Thalheim. The co-design approach to webinformation systems development. International Journal on Web Information Sys-tems, 1(1):5–14, 2005.

[ST06] K.-D. Schewe and B. Thalheim. Usage-based storyboarding for web informationsystems. Technical Report 2006-13, Christian Albrechts University Kiel, Instituteof Computer Science and Applied Mathematics, Kiel, 2006.

[ST07a] K.-D. Schewe and B. Thalheim. Development of collaboration frameworks forweb information systems. In 20th Int. Joint Conf. on Artifical Intelligence, SectionEMC07 (Evolutionary models of collaboration), pages 27–32, Hyderabad, 2007.

[ST07b] K.-D. Schewe and B. Thalheim. Life cases: An approach to address pragmatics inthe design of web information systems. In J. Filipe, J. Cordeiro, B. Encarnacao,and V. Pedrosa, editors, Proc. WebIST, volume II (WIA), pages 5–12, 2007.

[ST07c] K.-D. Schewe and B. Thalheim. Personalisation of web information systems. Dataand Knowledge Engineering, 62(1):101–117, 2007.

[ST07d] K.-D. Schewe and B. Thalheim. Pragmatics of storyboarding for web informationsystems: Usage analysis. Int. Journal Web and Grid Services, 3(2):128–169, 2007.

[ST07e] K.-D. Schewe and B. Thalheim. Term rewriting for web information systems -termination and Church-Rosser property. In Proc. WISE 2007, pages 261–272,2007.

[ST08a] K.-D. Schewe and B. Thalheim. ASM foundations of database management. InInformation Systems and e-Business Technologies, volume LNBIP 5, pages 318–331, Berlin, 2008. Springer.

[ST08b] K.-D. Schewe and B. Thalheim. Context analysis: Towards pragmatics of infor-mation system design. In A. Hinze and M. Kirchberg, editors, Fifth Asia-PacificConference on Conceptual Modelling (APCCM2008), volume 79 of CRPIT, pages69–78, Hobart, Australia, 2008. ACS.

[ST08c] K.-D. Schewe and B. Thalheim. Facets of media types. In Information Systemsand e-Business Technologies, LNBIP 5, pages 296–305, Berlin, 2008. Springer.

[ST08d] K.-D. Schewe and B. Thalheim. Life cases: A kernel element for web informationsystems engineering. In WEBIST 2007, LNBIP 8, pages 139–156, Berlin, 2008.Springer.

[ST08e] K.-D. Schewe and B. Thalheim. Semantics in data and knowledge bases. In SDKB2008, LNCS 4925, pages 1–25, Berlin, 2008. Springer.

[ST08f] K.-D. Schewe and B. Thalheim. Storyboarding concepts for edutainment wis. InInformation Modelling and Knowledge Bases XIX, pages 59–78. IOS Press, 2008.

[STT06] K.-D. Schewe, B. Thalheim, and A. Tretjakow. Formalization of user preferences,obligations, and rights. In R. Kaschek, editor, Perspectives of Intelligent SystemsAssistents, PISA’05. IDEA, 2006.

[STT07] K.-D. Schewe, A. Tretiakov, and B. Thalheim. Intelligent Assistant Systems - Con-cepts, Techniques, and Technologies, chapter Formalisation of user preferences,obligations and rights, pages 114–143. IGI Publishing, 2007.

[STZ] K.-D. Schewe, B. Thalheim, and J. Zhao. Quality assurance in web informationsystems development. In QSIC 2007, pages 219–224. IEEE.

[STZ04] K.-D. Schewe, B. Thalheim, and S. Zlatkin. Modeling actors and stories in webinformation systems. In ISTA’04, Lecture Notes in Informatics P-48, pages 13–23,2004.

[TAFAS08] B. Thalheim, S. S. Al-Fedaghi, and K. Al-Saqabi. Information stream based modelfor organizing security. In ARES, pages 1405–1412. IEEE Computer Society, 2008.

[TD00] B. Thalheim and A. Dusterhoft. The use of metaphorical structures for internetsites. Data & Knowledge Engineering, 35:161–180, 2000.

[Tha00] B. Thalheim. Entity-relationship modeling – Foundations of database technology.Springer, Berlin, 2000.

[Tha03] B. Thalheim. Co-design of structuring, functionality, distribution, and interactivityof large information systems. Technical Report 15/03, BTU Cottbus, ComputerScience Institute, Cottbus, September 2003. 190pp.

[Tha04] B. Thalheim. Codesign of structuring, functionality, distribution and interactivity.Australian Computer Science Comm., 31(6):3–12, 2004. Proc. APCCM’2004.

[Tha07a] B. Thalheim. Conceptual modeling in information systems engineering. InJ.Krogstie and A. Lothe, editors, Challenges to Conceptual Modelling, pages 59–74, Berlin, 2007. Springer.

[Tha07b] B. Thalheim. Pearls of modelling: From relational databases to XML suites. InLiber Amicorum for Jan Paredaens on the occasion of his 60th birthday, pages120–139. 2007.

[Tha09] Bernhard Thalheim. Abstraction. In Encyclopedia of Database Systems, pages6–7. Springer US, 2009.

[TSM09] Bernhard Thalheim, Klaus-Dieter Schewe, and Hui Ma. Conceptual applicationdomain modelling. In APCCM, volume 96 of CRPIT, pages 49–57. AustralianComputer Society, 2009.

[TSR+04] B. Thalheim, K.-D. Schewe, I. Romalis, T. Raak, and G. Fiedler. Website modelingand website generation. In Springer, editor, ICWE’2004, LNCS 3140, pages 577–578, 2004.

[Web91] Websters ninth new collegiate dictionary, 1991.

80 Thalheim & Düsterhöft

Chapter V

Systematic Development ofInternet Sites:

Extending Approaches ofConceptual Modeling

Bernhard ThalheimBrandenburg University of Technology at Cottbus, FRG

Antje DüsterhöftUniversity of Applied Science Wismar, FRG

ABSTRACTInternet information services are developed everywhere. Such servicesinclude content generation and functionality support that have to bemodeled in a consistent way. Here, we show how concepts of conceptualmodeling can be used for systematic development of Internet sites.We give an introduction into our methodology of modeling Internetapplications resulting in the Cottbus Internet site development language(SiteLang). The language has an operational semantics based on entity-relationship structuring and abstract state machines. It allows specificationof entire Web sites, i.e., of structuring, behavior, information support, andof the interaction and story space. The methodology supports applicationsin different environments, e.g., Internet Web sites, WAP technology, or TVchannels.

Copyright © 2003, Idea Group, Inc.

Systematic Development of Internet Sites 81

INTRODUCTIONNowadays, “Internet” is one of the main buzzwords in journals and

newspapers. However, to become a vital and fruitful source for informationpresentation, extraction, acquisition, and maintenance, concepts have to bedeveloped that allow flexible and adaptable services. Fundamental designconcepts are required but still missing.

Internet Information SystemsIn the scope of this paper, we observe a number of general tendencies that

were easing Web site development.

Tendency toward Large Sophisticated Web SitesIn the beginning, Web sites of more than 500 pages were rarely encoun-

tered. Meanwhile, Web sites are becoming larger and larger and tend toprovide a total and integral service according to the entire scope. Themaintenance and update problem forced Web developers to reuse techniquesdeveloped for conceptual modeling of database systems.

Transfer of Business Applications to the WebEnterprises discovered that their business can be partially transferred to

the Web. The support of business processes in the Web is, however, com-pletely different. Large and closed B2B sites are now developed and employedby almost all larger companies with exchange of products.

From Fancy Graphics Heaps toward Skillful XML SuitesIn the past, Internet site development was largely understood as develop-

ment of graphical site presentation. More than three-score good books arefound on sites of booksellers. Meanwhile, people understood the necessity ofsophisticated script languages. The advent of XML led to unification andsimplification of Web site programming.

Database MiddlewareBecause the maintenance of consistency of Web sites can be based on

database paradigms, database support has been intensively included in Websites. Currently, information-intensive Web sites are entirely based on databasesupport (sometimes also using incomplete systems such as mySQL).

Thus, we observe that Internet sites become similar to large informationsystems with a specific scope on distributivity of subsites and sophisticatedinteraction support.


Specific Demands of Large Internet SitesInternet information services have to cope with a broad variety of

problems beside information presentation, information generation, and graph-ics or multimedia design.

Services need to be personalized in order to be acceptable for anyuser. Because users are treating services in a different form, flexibility ofinformation presentation, of query and answer dialogues, and of interpretationof user’s intensions become crucial. User abilities in asking a query are verydifferent. User semantics differ. Users are misinterpreting results obtainedthrough summarization and contraction, for instance, in multidimensional data-bases. Summarized data often carry a different semantics (Agrawal, Gupta, &Sarawagi, 1997). Users are used to a certain cultural environment.

Personalization of information, information content, and informationrepresentation is playing the major success factor of information services thathave to cope with restricted display spaces such as videotext, WAP or phonedisplays, and Internet services distributed over TV nets based on set-top boxtechnology. Usually, Internet services are developed for Internet display onlyand do not cope with restrictions such as channel capacity. In our Internetprojects, we aimed early on multidisplay via Internet, TV, videotext, and phonedisplay. The specific requirements led us to search for languages enabling us inflexible and user-specific displays of infons (information units).

Data may vary over time. This approach is partially supported by temporaldatabases (Etzion, Jajodia, & Sripada, 1998; Snodgrass, 2000). Data mayhave a temporal dimension based on a time algebra or a time validity fordefining, querying, or modifying, may have been based on user-defined time,and may be computed under restrictions of transaction time. Temporal logicsused in service must be based on branching time, because we need to take intoconsideration different schedules of user groups, a variety of user-groupspecific breakpoints. Branching time needs to be handled dynamically bygenerating service pages on demand (Caumanns, 2000) based on the currentstate of the service.

Users act in a specific context (Feyer et al., 2001). Their contextdepends on and is limited by technical environment such as available equip-ment, channel and server capacity currently available, and understanding oftheir tasks. Context is based on the tasks currently under consideration. Usersare entering sites with certain occasions and intensions in their mind. Well-developed Internet sites use this knowledge for modeling scenarios of usage(Schewe & Thalheim, 2000). These scenarios can be integrated into stories andcomposed to the story space of an Internet service. Services may also varyaccording to availability of server functionality, communication channel, and


according to user’s preferences. This variation led to the ACE approach ofLewerenz (2000), where the adaption of services to heterogeneous anddynamic environments has been investigated. This approach is based oncomponent technology (Rieckmann, 2001) and allows the derivation of theXML content whenever the page content can be specified on the basis ofparametric components.

These problems lead to a misunderstanding of services, unacceptablepresentations, and counterintensional use of services. Therefore, we need away to represent these services in a consistent and concise way.

Challenges of Site DevelopmentThe Cottbusnet information site team has developed and participated in

development of a number of Internet sites together with companies such as theLausitzer Informations- und Medienzentrum GmbH: city or town informa-tion sites (currently 18; see, for instance www.cottbus.de), region service sites(five German regions), community sites for associations (2), one learning site,B2B, B2C, A2C, and B2A sites, respectively. The methodology presented inSchewe & Thalheim (2000) has been developed in parallel to the projectsmentioned above. During development of Internet sites, we faced a number ofdifficult challenges that required a full and powerful theory of the Internet site:• Full flexibility: Internet services often require full flexibility of a site’s

scenarios. The set of scenarios necessary to be supported looks graphi-cally similar to a complete graph (clique). It is possible in such cases to useany menu point and to jump to any other dialogue step. For instance,visitors of information sites do not want to read the same informationseveral times. This problem is even more severe for learning sites (see forexample, Caumanns, 2000; http://DaMiT.dfki.de). In this case, anystudent wants to see the information needed at the given moment and theamount of repetition has to be thoughtfully restricted.

• Support of tracing: Site visitors do not want to insert their data twice orread the same information. Once they identified themselves or areidentifiable, they want to keep their identity during the entire site visit andhave the site adaptable to their actual visit. In one of our industrialprojects, for instance, we faced this requirement as the killing requirement:Based on set-top-box technology, a user can access their Internet suitevia TV, depending on their previous and their actual visits. Because TVrepresentation is limited, content display is rather limited. At the sametime, interaction facilities are limited.

• Push-up content just-in-time: Users want to get the content dependingon their actual specific information requirements and demand. Tools


(Caumanns, 2000) allow content systems for learning sites to be built withthe ability to automatically adapt the content depending on the learningsituation, depending on the learning stage and on the specific user profile.In order to support this, sophisticated views should be materialized similarto OLAP (Agrawal, Gupta, & Sarawagi, 1997; Lewerenz, Schewe, &Thalheim, 1999) approaches. These views are extended to media objects(Feyer et al., 2000) by functionality attachment and are based on thecontainer shipment.

• No transactional semantics: Despite the massive parallel access andexecution in Web site service, the approach to consistency enforcementapplied especially to DBMS cannot be used for providing operationalsemantics. Users access Web sites in parallel. They complete their tasksor partially complete their task or leave the page whenever they like,expecting sometimes also partial recording. This variety has to be explic-itly modeled or supported by robust systems. In both cases, modelingbecomes a nightmare.

Focus of This PaperThis paper gives an introduction into our methodology of modeling Internet

applications resulting in the Cottbus Internet site development language(SiteLang). The language has an operational semantics based on entity-relationship structuring and abstract state machines. It allows specification ofentire Web sites, i.e., of structuring (structure, static integrity constraints),behavior (processes and dynamic semantics), information support (views,units, and containers) and of the interaction and story space (scenes, mediaobjects, and dialogue steps). The methodology supports applications indifferent environments, e.g., Internet Web sites, WAP technology, or TVchannels. SiteLang has been developed with the cooperation of the Cottbusteam (see acknowledgement) and is based on components developed by theteam members. The theoretical background of this work generalizes theapproaches of Schewe (2000) and Thalheim (2000).

BACKGROUNDIntensive Research in a Broad Variety of Groups

Recent conference series such as CMWWW, Hypertext, SAC, WebDB,WebNet, or WWWW have shown a lot of research in this area. Almost allconferences, such as ER or HICSS, devote a special section to Web develop-ment. Programming an agent to search for references on Web site development


brought us more than 1400 references. Almost in any university, a Webdevelopment group exists. There are some surveys that summarize the achieve-ments in the Web site development business (Fraternali, 1999; Schewe &Thalheim, 2000). A rough classification of the approaches developed so farcould highlight the achievements as follows [references named are onlyexemplary; for more complete references, see the survey mentioned above orThalheim (2000b)]:• Development of specific languages such as IIDM, JML, WCML, WebML,

and WSDM, e.g., in Bonifati et al., 2000; Ceri, Fraternali, & Paraboschi,1999; Gaedke & Turowski, 1999; Göschka & Schranz, 2001.

• Extending hypertext methodologies, e.g., HDM and RMM, see, forinstance, Baresi, Garzotto, & Paolini, 2000; Garzotto, Paolini, & Schwabe,1993; Isakowitz, Kamis, & Koufaris, 1998; Nanard, Nanard, & Kahn,1998; Rossi, Schwabe, & Lyardet, 2000; Rossi, Garrido, & Schwabe,2000; Schranz, 1998; Güell, Schwabe, & Vilain, 2000) .

• Development of entire work benches such as Araneus (Mecca, Merialdo,& Atzeni, 1999; Thalheim, 2000b).

• Extending object-oriented methodologies, e.g., Hennicker & Koch (2000),Pastor, Molina, & Aparicio (2000) .

• One of the major drawbacks of conceptual modeling research in theInternet area is its unlikeness. Paper refers mostly to own groups that donot consider the experience gained in other groups. There is no generali-zation of the approaches. This lack is caused by the large variety ofapplications and is similar to the situation in conceptual modeling, whereit is commonly agreed that no common language will overtake all otherapproaches despite UML. UML, however, does not have any approachbeyond plans to incorporate meaning or semantics (Schewe, 2000).

Generalizable ApproachesThere are some approaches that might be adopted to the development of

Internet sites.

Workflow and PatternWorkflow approaches try currently to cover the entire behavior of systems

beginning with modeling of implementable processes to conceptual modeling ofbehavior toward representation of results obtained in the analysis phase ofsystems development. Nevertheless, this research has led to a good under-standing of processes. Workflows can be constructed on the basis of basicprocesses by application of basic control constructors such as sequence,parallel split, exclusive choice, synchronization, and simple merge, by applica-


tion of advanced branching and synchronization control constructors such asmultiple choice, multiple merge discriminator, n-out-of-m join, and synchroniz-ing join, and by application of structural control and state-based controlconstructors.

Wegner’s Interaction MachinesDespite the presence of an active research community that studies concep-

tual models for ISs, this term still lacks precise formal underpinnings. We usethe interaction machine approach (Goldin, Srinivasa, & Thalheim, 2000) inorder to reason formally on information services. An interaction machine(Wegner & Goldin, 1999) can be understood as Turing machine with multiuserdynamic oracles (MIM) or with single-user dynamic oracles (SIM).

As shown in Börger (2002), they can be entirely based on abstract statemachines.

if conditionthen state = nextstate(state, database, input)

database = update(state, database, input)output = input o output(state, database, input)

The output and the input can be structured by channels. Thus, differentusers can receive only an output directed to them. The input of a user differentfrom the user is invisible to other users. Usually, the output is the concatenationof the input and the new output. We can use another function for sophisticatedoutput functions. This model is convenient for reasoning abstractly on interac-tive systems properties such as reliability, consistency, and liveness (Thalheim,2000b).

Wegner’s interaction machines approach is based on four assumptions:• User should observe machine behavior instead of having a complete

understanding of the machines’ I/O behaviors• Modeling of systems cannot be entirely inductive. Instead, coinduction

needs to be used, at least for the earlier design phases.• Users Compete for Resources, thus, modeling includes an explicit speci-

fication of cooperation and competition.• Interactive behavior cannot be entirely modeled on the basis of I/O

behavior but rather in term of interaction streams.

State Chart DiagramsThe state chart approach has been proved to be useful for state-oriented

modeling of database applications and more generally for use-case diagrams.


Despite its usage in UML, it has a precise semantics that can be easily integratedinto ER modeling approaches. Furthermore, this approach can be extendedtoward modeling user interfaces (Horrocks, 1999).

User Interaction ModelingInteraction involves several partners (grouped according to characteris-

tics; group representatives are called “actors”), manifests itself in diverseactivities and creates an interplay between these activities. In order to developusable Web sites, the story of the application has to be neatly supported(Schewe & Thalheim, 2000; Thalheim, 2000b) .

Interaction modeling includes modeling of environments, tasks, and actorsbeside modeling of interaction flow, interaction content, and interaction form(Lewerenz, 2000).

SITE SPECIFICATIONThe aim of the specification of large, information-intensive Web sites is to

develop Web sites that are generatable on the basis of the specifications, whichare error-prone and simple to change. Site specification might be rathercomplex. For this reason, we prefer the following modeling concepts:• Stories are collected into the story space. The story space describes the

set of all possible intended interactions of actors with the system.• Scenarios are used to describe a specific utilization of the Web site by an

actor at a given moment of time. We might have a large variety ofscenarios. For this reason, scenarios need to be integrated into the storyspace.

• Scenes are macrosteps within a scenario. They involve a number of actorsin various roles, rights, and occasions. They are supported by mediaobjects.

• Dialogue steps describe specific actions of enabled actors that act inspecific context. Dialogue steps are supporting different scenes. Anyscene has a dialogue expression expressing the dialogue workflow.

• Media objects describe the “adornment” of a scene similar to the movieor drama production.

Each of the concepts has a specific representation formalism defined in thedescription language SiteLang and will be illustrated in the next parts.

Story and Scenario SpecificationInteraction description can be based on notions developed in linguistics,


in movie business, or for the description of graphical animations. We use theaids, concepts, and experiences for acquiring an adequate conceptual design.Let us consider the concepts in detail.

The story space can be modeled by many-dimensional (multilayered)graphs (Schewe & Thalheim, 2000):

Story-space(Site) = ( scene , E , λ , κ )

Transition Ε ⊆ scenes × scenes

λ : scene → sceneDescription

κ : Ε → events × ifCond × postCond

The function λ is described in detail in Section 3.1.1. Each scene is markedby its identifier. It is associated with a media object, with a set of involvedactors, the context of the scene, the applicable representation styles, and adialogue step expression for the specification of the scene.

The function κ is used for the adornment of transitions by the events thatallow movement from one scene to another by the interaction of actors. Atransition may be blocked until a certain post condition is valid for theacceptance of the completion of the corresponding scene. A transition may beused if a condition is valid for the states of the system. Thus, we define

TransitionDescription ⊆

(events ∪ activities) × actors × preConds × postConds ×

priorities × frequencies × repetition rates )

Whenever a scenario is running, a certain state of the systems may beassociated with the scenario. This state might be changed during the scenario,e.g., on the basis of input information provided by the actor or by temporaryinformation used for recording actions of the actor.

A scenario is a run through a system by a cooperating set of actors. Ascenario may be cyclic or completely sequential. A scenario is composed ofscenes, which are discussed below. We model the order of scenes on scenariosby event sequences. Each scene belongs to a general activity. Each scenariohas its history which can be accumulated and used for the representation of thehistory of the part of the scenario visited so far. This history is used for theescort information (Feyer, Schewe, & Thalheim, 1998) attached to the mediaobjects of the scenes of the scenario.


We distinguish between the abstract scenario and the run-time sce-nario. The latter extends the specification of abstract scenarios by instantiationof parameters according to the concrete run-time history, according to theusers acting currently in the scenario, by the environment (channel, technicalequipment) currently used.

The abstract scenario specification consists of the following:• Dialogue scenes representing actions to be performed for a specific task

and dialogue steps for representation of an episode• Actors with information needs and interaction requirements• Media object satisfying interaction requirements and information needs• Description of the intention of the dialogue scenes and steps consistent

with the goals according to the mission and outcome of the step and withthe occasions depending on the aim

• Context of the dialogue scenes and steps consistent with tasks and thehistory, with particular attention paid to the environment according to theoccasion

The following scenario is used in one of our community service Web sitesfor membership application:

Membership Application extends scenario Purchase with Approval

Intention: Actor wants to apply for membership

Roles: Actor as applicant

Systems: Electronic Commerce Web Server, Certification Authority, ...

Scenario

Dialogue Scene: Making Membership Application Available

Goal: Membership Application Available

Outcome: Membership Application is available

Actions: Actor invokes the membership application page

....

Dialogue Scene: Approving Payment

Occasion: Membership requires payment first

Goal: Association budget balance increased


Outcome: Certification authority has approved membership fee payment

Information need: Association account, bank details

Actions: Membership data are processed

Web server receives payment information

Certification authority consulted

Certification authority approves payment

Web server notifies notifies actor

Context: safe connection, existing application

...

The abstract scenarios are integrated into the story space. An example ofthe story space of city information systems is the following brief description ofthe www.cottbus.de story space:

Entry Business Portrait1 | Technology Region | Real Estate

| Environment | Fairs, Exhibitions, Events1 | Projects | Traffic1

| Culture & Tourism Portrait | Tourist Service Center

| Calendar of Events | Eating & Dining

| Spare time, Relaxation, Entertainment | Sport | Traffic2

| Inhabitants Political life | Town management | Guide for inhabitants

| Education | Social life and Associations | Traffic

For instance, we identified more than 30 scenarios for city informationsites:• Tourist content, e.g., inhabitants permanently living in the town, inhabit-

ants temporarily living in the town, short-term tourist, businessman onshort-term trip, vacationist planing a trip for more than five days, teenagerwith uncertain wishes, senior with profile of interest, visitor on weekendtrip, visitor of highlights and festivals

• Official content, e.g., inhabitant on search through directory of publicauthority, inhabitant on search for emergency cases, inhabitant orienting


before applying in public offices, inhabitant interested in problems of citymanagement

• Business content, e.g., investor considering engagement in the area

In order to handle this variety, we used the trick to interview the personnelcurrently providing the service outside the Web area. Due to this large varietyof scenarios, we integrate scenarios and stories to story trees or graphs fornavigation, usage pattern, etc. We use approaches of case-based reasoningand decision theory. A composition of scenarios in information sites is dis-played in Figure 1. We represent scenes by frameboxes and transitions withcorresponding events by oval boxes.

ScenesScenes are specified on the basis of the following specification frame:

Scene = ( Scene-ID, DialogueStepExpression , MediaObject ,

Actors , ActorID , Right , Tasks , Assigned Roles ,

Representation (styles, defaults, emphasis, ...) ,

Context (equipment, channel, particular) )

The scene identification is the conceptual identification of the scene. It isextended by a run-time identification in order to distinguish scenes, to recordthe communication channel, and to abide by specific communication restric-

Figure 1: Integration of some tourist scenarios into a tourist story.


tions. The scene of an abstract scenario is associated with a consistentexpression of dialogue steps considered in detail in Section 3.1.2.

A scene is supported by media objects. Media objects can be parameter-ized. Typical parameters are the representation style, the actor frame, and thecontext frame. Therefore, we distinguish between media objects and run-timemedia objects which are sent to the actor in a concrete run time. Furthermore,involved actors are specified in dependence on their profiles, tasks assignedto them, their access and manipulation rights, and their roles to be taken duringvisiting the scene. This specification is based on Altus (2000) and is similar toprofiles of actors in information systems. It is our aim to specify generic scenes.Thus, we add the representation styles that can be applied to the media objectof the scene. Representation depends on the equipment of the actor. In the citysite projects, we have experience with different representation styles: Internetdisplay with high-speed channel, Internet display with medium-speed display(default style), videotext, and WAP display. For instance, for videotext, anygraphical information is cut or replaced by textual information. Finally, thecontext of access is specified. Access determines the display facilities.Channels can be of high or low speed. The particular of using a scene by anactor depends on the scenario history.

Dialogue Step SpecificationDialogue steps are the elementary units of Internet sites. They are used to

represent the basic state transformations triggered by actors. The distinctionbetween dialogue scenes and dialogue steps is not strict but depends on theapplication. We use media objects for scenes. Dialogue steps use mediaobjects or parts of them. In some applications, we might use scenes consistingof one dialogue step. In this case, we can integrate the dialogue step specifica-tion directly into the scene specification.

Dialogue steps can be represented by tables, e.g., the dialogue steps ofan actor A in a community service:

Step name On event If cond Then with

unit

Using

processes

Let manipulation By

actor

Accept on

Registration ClickReg(A) ¬Member(A) ∧

permission(A)

Member-

ship_choices

Collect_Mem-

ber_Data(A)

Insert(Member, A) A Payment(A)

= ok

Withdrawal ClickWDraw(A) Member(A) Member-

Data(A)

Collect-

_reason(A)

Delete(Member,A)

∧ send_Message

(A, Withdraw)

A Commit (A,

Withdraw)


Based on the properties of the actions, we conclude, for instance, that afterwithdrawal, a previous member cannot participate in the discussions in thecommunity. The table frame we used is called task property frame in Paech(1998). A task property frame is defined by a task name, reasons for taskinvolvement, an aim, a postcondition (enabled next activities), the informationfrom the database, the information for the database, the resources (actor,resources, partner), and a starting situation (precondition, activity, priority,frequency, repetition rate).

We chose the frames above instead of the ECA frame which is used for ruletriggering systems because of the necessity to be as flexible as possible in thespecification. The integration of postconditions into the preconditions of thenext dialogue steps is possible whenever the dialogue step has only one outputor the postconditions are identical for all incoming dialogue steps. Also, thetrigger framework is too weak and contradictory (Thalheim, 2000).

Dialogue scenes are represented by frameboxes. We represent dialoguesteps by ellipses. The transitions among dialogue steps are represented bycurves. Thus, we obtain the graphical representations displayed in Figure 3.The additional information attached to dialogue steps can be omitted wheneverwe want to have a schema surveyable.

We adopt the graphical notation developed for state charts, e.g., thedefault start step of a scene is denoted by a solid circle, the end state by a solidcircle surrounded by an empty circle, the history entry into a scene is denotedby an “H” surrounded by an empty circle. Furthermore, we can adopt

Figure 2: Representation of dialogue steps within a dialogue scene.


refinement and clustering, concurrency, delays and time-outs, transient states,event priorities, and parameterized states.

The preconditions can be specified on the basis integrity constraint pattern(Thalheim, 2000): condition, localization (local restrictions, navigation, etc.),validity condition, exception condition, enforcement pattern, and conditionaloperation (for example, synchronization conditions). Further, the preconditioncan be extended by additional context restrictions. The postcondition is usedfor description of acceptance conditions. If those are invalid, the entire dialoguestep is not accepted.

Search is a general functionality of a site. The search can be extended tobooking. This frame is supported by the scene demonstrating the search andbooking of a hotel. The entry dialogue step enables a number of choices, suchas search via categories (depending on the categories specified for events,restaurants, hotels) or properties (date, time, location, etc.), search via the mapand locations, search via direct targeted input, or search via full display. On themap, several locations are noted. The user can select those for targeted input.There are also points of interest that might be used for targeted search. If theactor however chooses the full display option, then the clarification step allowsrestriction of the results of the search step by step. At each step, the actor canleave the scene. Thus, each step might be the end step. By default, we assumethis behavior. Defaults are not displayed. The presentation of search resultsdepends on the scene, the restrictions the actor made for the scope of thesearch. For instance, in the hotel search scene, we used the following presen-tation structure:

hotelObject = (identification(name, hotelObjects’s link,

area (in raw map)), rooms (# per category),

prices (range per category), equipment (icon-based))

hotelObject’s link = additional (address, contact info, picture(s),

video, map (with different travel details), travel info,

location (of closest places of interest, distance info) + reservation connection

Site ImplementationThe Onion Approach

Layering of applications is one of the general approaches used in computerscience. We observe that Web site functionality and content may be layered aswell. On the outer layer, the presentation facilities may be introduced. Typical


functions are style and context functions. Containers are used to ship theinformation, and the functionality is provided by the Web engine. Theirfunctionality is described in Feyer, Schewe, & Thalheim (1998). Containerscontain information units that in general are views enriched by functions foroperating on the views. Views may provide information to the dialogue or maybe used for updating the database. Further, views may be materialized. If theyare materialized, then the view handler provides an automatic refreshmentsupport. Thus, we can use the onion system architecture displayed in Figure 3.

The DBS Functionality BehindIn Feyer, Schewe, & Thalheim (1998), the codesign approach has been

developed. This approach has been generalized to media objects. Mediaobjects consist of abstract containers, supplied DBMS processes, anddatabase manipulations requests. Basic media objects (Schewe, 2000) arecharacterized by syntactic expressions, have a semantical meaning, and areused within a certain pragmatical framework.

During run time, the media object is extended by specific escort informa-tion (Feyer, Schewe, & Thalheim, 1998). This escort information is repre-sented for user support. It allows the user to see the history of steps performedbefore being in the current state. Escort information is further generated fromthe story space. In this case, a user is informed on alternative paths that could

Figure 3: The onion approach to stepwise generation of sites.


be used to reach the given scene and which might be used for backtracking fromthe current scene.

For the generation of media objects and their composition on the basis ofinformation units, we extend the classical SQL frame:

SELECT Structure FROM DB relations WHERE Condition

GROUP BY Substructure HAVING Condition

to the frame

GENERATE MAPPING: Vars → Structure

FROM Views WHERE Selection condition

REPRESENT USING Style guide & Abstraction

BROWSING DEFINITION Condition & Navigation

In the case of the cultural events, we obtain:

Media object (CulturalEventSelectionPanel) =

Structure of container

unit todayEvents =

generate EventsOf( :Today)

<[EventID]Title,Location,Time,

link(newPapge(EventID)>

from EventGeneral, Scheduled, At

where ....

represent using paragraphStyle

browsing definition longList

navigationByScrolling

unit tomorrowEvent ....

unit thisWeekEvent ....


unit nextWeekEvent ...

unit searchByCategory ...

SuppliedProcess

collectSpecificRequest

ManipulationRequest none

Views, and therefore, the media object may have hidden parameters (forinstance, EventID) that are not visible to the actor. They can be parameterizedby variables (for instance, :Today). For media objects, we reuse ideasdeveloped for OLAP technology (Thalheim, 2000): Views on ER schemata(abstraction on schemata (aggregation, scoping,...), versions, variations ofgeneration functions, display with canonical functionality (drill-down,roll-up, rotate, pivot, push, pull, dimension, aggregation), using genericevaluation functions and models, implicit incorporation of hierarchiesand implicit incorporation of time, space,....

Scenes are dynamically adapted to the environment, to the specific profileof the actor, and are extended by the escort information. The specificrepresentation is selected among the possible representations of the mediaobject. The context of the media object also depends on the scenario historyat run time. Thus, we extend the context of the container by the run-time historydepending on the scenario chosen by the actor acting on the site. In order tohandle the dynamic changes and the history, we record the control informationin the scene control component. Finally, the specific actor might obtain duringthe scenario an identity or other specific information such as products selectedfor later purchase. This information is stored in the component for scene actors.For instance, given an Internet channel with medium capacity, the entry pageof a city’s information sites may be composed by a star graphics, extended byadditional information such as town maps, imprint, and contact information. Forexample, in this case, the www.cottbus.de site has the following entry scenespecification:

Add (Add (Add (ComposeGen ( genFrame, ComposeStar(t1, (t2, t3, t4), ov)),

NavQuick (n1, n2, n3), style2 ), Text (entry), style1),

NavQuick (townMaps) + imprint + cont1, derivStruct(site), style2)


The corresponding media object which is the central object of the entrypage uses the following queries and navigation elements:

t1 = emblem(pyramid) ... t3 = RollNav( emblem(tourist), tourPage, repres1)

n1 = Sub( Query( calend (today), order1), repres2)

entry = “Known as the city ... <a>Energie Cottbus </a> ...”

cont1 = ComposeSub( email, guestsBook, seq1)

The event database is used by different parts of the Web site. Some of theevents are accessed frequently. Thus, we use materialization of components ofsites. Pages are as follows:• Static, i.e., they have been developed once and stay for a longer period• Pseudo-static, i.e., generated and transformed to static pages whenever

an update of the corresponding data is made• Fully dynamic, i.e., are generated during processing the request of an

actor

The XML-Perl Functionality BehindThe language Perl neatly support the onion approach, because we can use

Perl for conservative expansion of views to units, of units to containers, and ofcontainers to presentation objects. Further, the database connectivity isentirely supported. This onion generation mechanism is also used for theexpansion of XML specifications to page objects.

CONCLUSIONIn this paper, we presented the Web site specification language Site Lang.

This language is based on a layering of Web site specification into the storyspace, dialogue scenes, and dialogue steps. An aim during specification is toentirely include all main scenarios in the application into the scenes and the storyspace. A scenario is, in this case, a run through the scenes and the story space.There might be more utilization scenarios in the interaction space. But, we areinterested in a complete inclusion of the main scenarios. If the system issupporting more than the scenarios of the interaction space, then we can restrictthe system. Our aim is, however, to develop a language that allows us to specifyWeb sites. The main advantage of our approach is its well-foundedness. Basedon the extended ER model, on the abstraction layer approach, and on the


abstract state approach, we obtain an operational semantics that can be usedfor derivation and proof of properties. At the same time, we can use abstractstate machines for generation of executable prototypes of the Web site.

The specification of a Web site can also be made manually. However, itis definitely preferable to develop, to extend, and to maintain a site viaautomated tools. Such tools allow generation of the site content, the pagepresentation, the navigation structure, the indexing support, etc. The next stepin our team is the development of such tools.

We are concentrated on information-intensive and large Web sites. SmallWeb sites may not need any specification languages. Web sites that are notinformation-intensive can be developed in a similar fashion. The SiteLangsupports Web site specification for e-commerce sites, for information sites, forcommunity sites, and for learning sites. Identity sites are usually smaller if theydo not include specifics of e-commerce or community sites. Also, entertain-ment sites are not within the scope of this paper, because quality criteria to beapplied to such sites (Schewe & Thalheim, 2000) are not oriented towardcontent but rather toward presentation and multimedia objects.

ACKNOWLEDGEMENTThe research presented and summarized in this paper is based on the work

of the Internet services Cottbusnet team at Cottbus Tech. We are very thankfulto Ph.D. and Master students working and contributing in these projects, andthankful to our Master students handling the implementations and develop-ments within these projects, and furthermore, to our commercial partnerssupporting and running the implementations. The research represented here isbased on a tight collaboration with K.-D. Schewe (Schewe & Thalheim,2000).

BIBLIOGRAPHYAbiteboul, S., Buneman, P., & Suciu, D. (1998). Data on the Web. San

Francisco: Morgan Kaufmann Publs.Agrawal, R., Gupta, A., & Sarawagi, S. (1997). Modeling multidimensional

database. Proceedings Data Engineering Conference, Birmingham, AL,(232–243).

Altus, M. (2000). Decision support for conceptual database design basedon the evidence theory - an intelligent dialogue interface for concep-tual database design. PhD, BTU Cottbus.


Bonifati, A., Ceri, S., Fraternali, P., & Maurino, A. (2000). Building multi-device, content-centric applications using WebML and the W3I3 toolsuite. ER Workshops 2000, LNCS 1921, (64–75), Heidelberg: Springer-Verlag.

Baresi, L., Garzotto, F., & Paolini, P. (2000). From Web sites to Webapplications: New issues or conceptual modeling. ER Workshops2000, LNCS 1921, (89–100), Heidelberg: Springer-Verlag.

Biskup, J. & Embley, D.W. (2000). Mediated information gain. ProceedingsIDEAS Conference 2000, 360–370.

Börger, E. (2002). Discrete systems modeling. To appear in: Encyclopediaof Physical Sciences and Technology, New York: Academic Press.

Caumanns, J. (2000). Automatisierte Komposition vonwissensvermittelnden Dokumenten für das World Wide Web. PhD,BTU Cottbus.

Ceri, S., Fraternali, P., & Paraboschi, S. (1999). Data-driven, one-to-oneWeb site generation for data-intensive applications. ProceedingsVLDB Conference 1999, (615–626).

The intelligent data mining tutorial work bench. http://DaMiT.dfki.de.De Troyer, O. (1998). Designing well-structured Web sites: Lessons to be

learned from database schema methodology. Proceedings ER Confer-ence 1998, LNCS 1507, (51–64), Heidelberg: Springer-Verlag.

Düsterhöft, A. & Thalheim, B. (2000). The use of metaphorical structures forInternet sites. Data and Knowledge Engineering 35(2), 161–180.

Embley, D.W. et al. (1999). Conceptual-model-based data extraction frommultiple-record Web pages. Data and Knowledge Engineering 31(3),227–251.

Etzion, O., Jajodia, S., & Sripada, S. (1998). Temporal databases: Re-search and practice. LNCS 1399, Heidelberg: Springer-Verlag.

Feyer, T., Odey, K., Schewe, K.-D., & Thalheim, B. (2000). Design of data-intensive Web-based information services. Proceedings WISE 2000,Hong Kong (China).

Fraternali, P. (1999). Tools and approaches for developing data-intensiveWeb applications: A survey. ACM Computing Surveys, 31(3), 227–263.

Feyer, T., Schewe, K.-D., & Thalheim, B. (1998). Conceptual design anddevelopment of information services. Proceedings ER Conference1998, LNCS 1507, (7–20), Heidelberg: Springer-Verlag.

Feyer, T., Varas, M., Fernandez, M., & Thalheim, B. (2001). Intensionallogic for integrity constraint specification in predesign databasemodeling. Proceedings EJ Conference 2001, Maribor.


Gaedke, M. & Turowski, K. (1999). Generic Web-based federation ofbusiness application systems for e-commerce applications. Proceed-ings EFIS Conference 1999, 25–42.

Göschka, K. & Schranz, M. (2001). Client and legacy integration in objectoriented Web engineering. IEEE Multimedia, 8(1), 32–41.

Garzotto, F., Paolini, P., & Schwabe, D. (1993). HDM — A model-basedapproach to hypertext application design. TOIS, 1(1), 1–26.

Goldin, D., Srinivasa, S., & Thalheim, B. (2000). IS = DBS + interaction -towards principles of information systems. Proceedings ER Confer-ence 2000, LNCS 1920, (140–153), Heidelberg: Springer-Verlag.

Güell, N., Schwabe, D., & Vilain, P. (2000). Modeling interactions andnavigation in Web applications. Proceedings ER Workshops 2000,LNCS 1921, (115–127), Heidelberg: Springer-Verlag.

Hennicker, R. & Koch, N. (2000). A UML-based methodology forhypermedia design. Proceedings UML Conference 2000, LNCS 1939,(410–424), Heidelberg: Springer-Verlag.

Horrocks, I. (1999). Constructing the user interface with statecharts.Reading, MA: Addison-Wesley.

Isakowitz, T., Kamis, A., & Koufaris, M. (1998). The extended RMMmethdology for Web publishing. New York University. Available underhttp://rrr-java.stern.nyu.edu/rmm/

Lewerenz, J. (2000). Human–computer interaction in heterogeneous anddynamic environments: A framework for its conceptual modelingand automatic customization. Ph.D., BTU Cottbus.

Lewerenz, J., Schewe, K.-D., & Thalheim, B. (1999). Modeling datawarehouses and OLAP applications by means of dialogue objects.Proceedings ER Conference 1999, LNCS 1728, (354–369), Heidel-berg: Springer-Verlag.

Mecca, G., Merialdo, P., & Atzeni, P. (1999). ARANEUS in the Era of XML.IEEE Data Engineering Bullettin, Special Issue on XML.

Nanard, N., Nanard, N., & Kahn, P. (1998). Pushing reuse in hypermediadesign: Golden rules, design patterns and constructive templates.Proceedings Hypertext Conference 1998, (11–20).

Paech, B. (1998). Aufgabenorientierte Softwareentwicklung. Heidelberg:Springer-Verlag.

Pastor, O., Molina, P.J., & Aparicio, A. (2000). Specifying interfaceproperties in object oriented conceptual models. Proceedings Ad-vanced Visual Interfaces Conference 2000, (302–304).

Rossi, G., Garrido, A., & Schwabe, D. (2000). Navigating between objects— Lessons from an object-oriented framework perspective. ACM


Computing Surveys, 32(1), 30.Rieckmann, J. (2001). Entwicklung einer Reportingplattform als

Entscheidungsunterstützendes System — Einkomponentenbasierter Ansatz. Ph.D., BTU Cottbus.Rossi, G., Schwabe, D., & Lyardet, F. (2000). User interface patterns for

hypermedia application. Proceedings Advanced Visual Interfaces Con-ference 2000, (136–142).

Schranz, M.W. (1998). Engineering flexible World Wide Web services.Proceedings SAC Conference 1998, (712–718).

Schewe, K.-D. (2000). UML — a modern dinosaurus. Proceedings Euro-pean-Japanese Conference on Information Modeling and KnowledgeBases, Finland.

Schewe, K.-D. & Thalheim, B. (2000). Conceptual development of Internetsites. Full-day tutorial at ER Conference 2000, Salt Lake City.

Snodgrass, R.T. (2000). Developing time-oriented database applicationsin SQL. San Francisco, CA: Morgan Kaufman Publishers.

Thalheim, B. (2000). Entity-relationship modeling — Fundamentals ofdatabase technology. Heidelberg: Springer-Verlag.

Thalheim, B. (2000b). Readings in fundamentals of interaction in informationsystems. Reprint, BTU-Cottbus, http://www.informatik.tu-cottbus.de/~thalheim.

Thalheim, B. (2001). ASM specification of Internet information services.Proceedings Eurocast Conference 2001, Las Palmas, (301–304).

Wegner, P. & Goldin, F. (1999). Interaction as a Framework for Modeling.Conceptual Modeling: Current Issues and Future Directions,.Chen, P.P.et al., (Eds.), LNCS 1565, (243–247), Heidelberg: Springer-Verlag.

The Co-Design Approach to WIS Developmentin E-Business and E-Learning Applications

Klaus-Dieter Schewe1, Bernhard Thalheim2

1 Massey University, Department of Information Systems &Information Science Research Centre

Private Bag 11 222, Palmerston North, New [email protected]

2 Christian Albrechts University KielDepartment of Computer Science and Applied Mathematics

Olshausenstr. 40, D-24098 Kiel, [email protected]

Abstract. We argue that the generic co-design approach to the devel-opment of web information systems is powerful enough to cover diverseapplications. We illustrate the validity of this claim by comparing thekey features of the approach with needs arising in e-business and e-learning applications. While this does not exclude that there still existapplication-specific features that need to be handled separately, it under-lines that it is advisable to consider the most generic approach first. Inaddition, it is recommendable trying to generalise specific features thatarise in e-business and e-learning to the whole area of web informationsystems.

1 Introduction

Data-intensive information systems are a well-researched field that hasfound a lot of applications. Over the last decade there has been a shift ofinterest toward web information systems (WISs), i.e. information systemsthat are made available via the world-wise web. This area also has founda lot of applications in information services [10], electronic learning [5, 4,3, 11, 12, 19], electronic business [14, 15], and others.

In these application fields, in particular in Electronic Business (EB)and Electronic Learning (EL) we now find groups of researchers claimingthe field to be not just a field of application but a genuine research area inits own right. Of course, both areas have to link to business or education,respectively, but the question is, whether there are enough researchprob-lems that would lead to substantively different results than those achievedfor WISs, i.e. on a more generic level.

In this position paper we argue that it is better to treat them still asapplication areas for WISs and not as separate fields in their own right.

2 K.-D. Schewe, B. Thalheim

In order to present evidence for this claim we will briefly sketch the keyconcepts of the generic co-design approach to the development of webinformation systems [16], i.e. storyboarding [8] and media types [9]. Bothcomponents have been deeply analysed with respect to their expressivepower in [18, 16, 17] and [13, 16], respectively. Both approaches have alsobeen tailored to applications in EB [15] and EL [19].

We will demonstrate that key features such as story spaces, actors,media types and adaptivity each have a specialisation in EB and EL. Thatis, the generic co-design is very well reflected in the application area, andmost of the specific needs arising from the application will already becaptured by the approach. While this does not exclude that there stillexist application-specific features that need to be handled separately, itunderlines that it is advisable to consider the most generic approach first.

There are lots of other generic approaches to the development of WISsuch as ARANEUS [1, 2], WebML [6, 7] and OOHDM [20]. We do not wantto discuss the individual merits of these approaches, their advantages anddisadvantages (see [13, 17, 16] for some comparison). We are confident thatour argument will also hold largely for these other approaches.

2 Story Spaces

On a high level of abstraction we may think of a WIS as a set of abstractlocations, which abstract from actual pages. A user navigates betweenthese locations, and on this navigation path s/he executes a number ofactions. We regard a location together with local actions, i.e. actions thatdo not change the location, as a unit called scene.

Then a WIS can be decribed by a edge-labelled directed multi-graph,in which the vertices represent the scenes, and the edges represent transi-tions between scenes. Each such transition may be labelled by an actionexecuted by the user. If such a label is missing, the transition is due toa simple navigation link. The whole multi-graph is then called the storyspace. A story is a path in the story space. It tells what a user of aparticular type might do with the system.

The combination of different stories to a subgraph of the story spacecan be used to describe a “typical” use of the WIS for a particular task.Therefore, we call such a subgraph a scenario. Usually storyboardingstarts with modelling scenarios instead of stories, coupled by the integra-tion of scenarios to the story space. At a finer level of details we may adda triggering event, a precondition and a postcondition to each action, i.e.

The Co-Design Approach to WIS Development 3

we specify exactly, under which conditions an action can be executed andwhich effects it will have.

Looking at scenarios or the whole story space from a different angle,we may concentrate on the flow of actions:

– For the purpose of storyboarding actions can be treated as beingatomic, i.e. we are not yet interested in how an underlying databasemight be updated. Then each action also belongs to a uniquely deter-mined scene.

– Actions have pre- and postconditions, so we can use annotations toexpress conditions that must hold before or after an action is executed.

– Actions can be executed sequentially or parallel, and we must allow(demonic) choice between actions.

– Actions can be iterated.– By adding an action skip we can then also express optionality and

iteration with at least one execution.

These possibilities to combine actions lead to operators of an algebra,which we will call a story algebra. Thus, we can describe a story space byan element of a suitable story algebra. We should, however, note alreadythat story algebras have to be defined as being many-sorted in order tocapture the association of actions with scenes.

In the area of EL the story space corresponds to the curriculum, whichcan be modelled by an outline graph that describes the navigation oflearners through an e-learning system [3]. Formally, an outline graph isa finite, directed graph G = (V,E), i.e. V and E are finite sets withE ⊆ V ×V . The vertices, i.e. the elements of V , are called learning units,and the edges, i.e. the elements of E are links between these units. Thus,scenes in story spaces correspond to learning units in EL systems.

Take for example a course dealing with e-learning systems. Then wemight have learning units such as Introduction, Learner Profiling, CourseOutlining, Data Management, Adaptivity, Style Definition, and Imple-mentation.

Actions on a learning unit may depend on the successful completionof the learning unit by the learner. According to our view this is part ofthe action specification, and should be left for further refinement of theoutline.

From a more conceptual point of view we model learner interactionwith an e-learning system according to two primitives: transition betweenlearning units and using the functionality offered at a given learning unit.This allows for a two-step modelling procedure to be applied. First at


a coarse-grained level learning units and navigation links are modelled.Then in a refinement step the actual activities of the the learners areadded. This procedure allows for a good separation of concern with re-spect to personalisation and localisation.

In the area of EB, the notions of story space and scenario have beenadopted directly [14]. Describing the application story for e-business sys-tems permits concentration on the business aspects. In particular, the ac-centuation of the communication aspects can be more easily approachedon such a level of abstraction. Thus, it satisfies the primary criteriumfor conceptual modelling of not being implementation-biased. Further-more, the approach is both grounded in solid mathematical theory suchas Kleene algebras and deontic logic [16], and in the sophisticated prag-matics of a successful business branch – movie production – which maybe considered a godfather for the approach.

3 Actors

A second key feature of storyboarding concerns the description of theactors, i.e. groups of users with the same profile. Users can be classifiedaccording to their roles, intentions and behaviour. We use the term ac-tor for such a group of users. The role of an actor indicates a particularpurpose of the system. As such it is usually associated with obligationsand rights, which lead to deontic integrity constraints. Roles are also con-nected with the tasks, but tasks will be handled separately. The intentionof an actor can be modelled by goals, i.e. postconditions to the storyspace. Modelling the behaviour of an actor leads to user profiles, whichcan be modelled by giving values for various properties that characterize auser. Furthermore, each profile leads to rules that can again be expressedby constraints on the story space.

In addition, each actor has an information portfolio, which specifiesthe information needs as well as the information entered into the system.We do not model the information portfolio as part of an actor, but in-stead of this we will model the information “consumed” and “produced”with each more detailed specification of a scene. However, we associateinformation consumption and production with each scene of the storyspace. Assuming that there is a database for the data content of the WISwith database schema S, information consumption on a scene s definitelyaccounts for a view Vs over S. That is, we have another schema SV and acomputable transformation from databases over S to databases over SV .


Such a transformation is usually expressed by a query qV . Such views willform the basis of the theory of media types.

The presence of roles indicates a particular purpose of the system.For instance, in a web-based conference system we may have roles forthe programme committee chair(s), the programme committee members,and for authors. On the other hand, in an on-line loan system we maynot wish to distinguish roles, as all actors will only appear in the one roleof a customer.

A role is defined by the set of actions that an actor with this rolemay execute. Thus, we first associate with each scene in the story spacea set of role names, i.e. whenever an actor comes across a particularscene, s/he will have to have one of these roles. Furthermore, a role isusually associated with obligations and rights, i.e. which actions have tobe executed or which scenes are disclosed.

An obligation specifies what an actor in a particular role has to do.A right specifies what an actor in a particular role is permitted to do.Both obligations and rights together lead to complex deontic integrityconstraints. The intention of an actor can be expressed by goals, whichcan be modelled by postconditions to the story space.

Modelling the behaviour of an actor leads to user profiles. We mayask which properties characterize a user and provide values for each ofthese properties. Each combination of such values defines a profile, butusually the behaviour for some of these profiles is the same. Furthermore,each profile leads to rules that can again be expressed by constraints onthe story space.

The dimensions used in user profiles depend on the application. For-mally, in order to describe such user profiles, we start with a finite set ∆of user dimensions. For each dimension δ ∈ ∆ we assume to be given ascale sc(δ). Formally, a scale is a totally ordered set. If ∆ = δ1, . . . , δnis a set of user dimensions, then the set of user profiles is gr(∆) =sc(δ1)× . . .× sc(δn). A user type is a convex region U ⊆ gr(∆).

The analogue of the actor in EB and EL applications are the customerand the learner, repectively. In particular, user types become customertypes or learner types, respectively. The only decisive feature in both ap-plication areas is the decision on the relevant user dimensions and theassociated scales. Formally, however, there is no need to introduce a par-ticular new theory.


4 Media Types

The central concept for modelling the content and the functionality ofa WIS is the media type. We may assume that we have an underlyingdatabase. On the basis of a given database schema we may introduce in-teraction types as views that are extended by operations. This permitsto apply completely different design criteria for the database schema andthe interaction schema. One major facility used in interaction types isthe possibility to create a navigation structure via URLs and links. Me-dia types arise from tailoring the information types in such a way thatdifferent presentation options will be enabled.

A media type is an interaction type M together with an cohesionorder M (or a set of promimity values) and a set of hierarchical versionsH(M).

Cohesion introduces a controlled form of information loss. Formally,we define a partial order ≤ on content data types, which extends sub-typing. If cont(M) is the content data type of a interaction type M andsup(cont(M)) is the set of all content expressions exp with cont(M) ≤exp, then a preorder M on sup(cont(M)) extending the order ≤ oncontent expressions is called an cohesion preorder .

Small elements in sup(cont(M)) with respect to M define informa-tion to be kept together, if possible. Clearly, cont(M) is minimal withrespect to M . This enables a controlled form of information decomposi-tion. If we want to decompose an interaction type or if we are forced todecompose according to user requirements or technical restrictions, thenwe may choose a minimal elements t1 ∈ sup(cont(M)) with respect toM such that it satifies the representation requirements. Note that if weonly provide a preorder, not an order, then there may be more than onesuch t1.

Taking just t1 instead of cont(M) means that some information islost, but this only refers to the first data transfer. When transferring t1,we must include a link to a possible successor containing detailed infor-mation. In order to determine such a successor we can continue lookingat all content types t′ ∈ sup(cont(M)) with t1 6M t′. These are just thosecontaining the complimentary information that was lost. Again we canchoose a least type t2 among these t′ with respect to M that requiresnot more than the available capacity. t2 would be the desired successor.

Proceeding this way the whole communication is broken down into asequence of suitable units t1, t2, . . . , tn that together contain the informa-tion provided by the interaction type. Of course, the cohesion pre-order


suggests that the relevance of the information decreases, while progress-ing with this sequence. The user may decide at any time that the level ofdetail provided by the sequence t1, . . . , ti is already sufficient for his/herneeds. An alternative to cohesion preorders is to use proximity values,which we do not discuss here.

Another possibility to tailor the information content of interactiontypes is to consider dimension hierarchies as in OLAP systems. Flatteningof dimensions results in information growth, its converse in informationloss. Such a hierarchy is already implicitly defined by the component orlink structures, repectively.

For an interaction type M let H(M) be the set of all interaction typesarising fromM by applying a sequence of flat-operations or their conversesto interaction types or underlying database types. A set of hierarchicalversions of M is a finite subset H(M) of H(M) with M ∈ H(M). Eachcohesion order M on M induces an cohesion order M ′ on each elementM ′ ∈ H(M).

Media types are used directly in EL applications [12] and in EB ap-plications [13].

5 Adaptivity

In order to avoid an unnecessary replication of WISs with the undesiredincrease in maintenance costs we prefer to have a single server-side spec-ification of the system, which adapts itself to various needs of the clients.Basically, we see two dimensions of this adaptivity problem.

The first one concerns the distinction between the adaptivity of con-tent and process. Processes determine which functionality becomes avail-able to users and which not. Process adaptivity thus results in discardingaccess to part of the system and to reduce the number of available actions.Content adaptivity on the other hand refers to tailoring the data contentthat is presented to a user. This may result in reducing the content, split-ting or merging it, or aggregate it to a more compact representation.

The second dimension of adaptivity concerns the parameters that de-termine the adaptation. Here we distinguish between adaptivity to users,locations, channels and devices. With respect to the users we considerpreferences of users and requirements resulting from profiling character-istics of users. With respect to locations we consider the actual location ofa user. With respect to channel we consider the communication channelused by a user, e.g. fixed line, telephone, broadband, mobile, TV cable-


net, etc. With respect to devices we consider the end-device used by auser, e.g. PCs, PDAs, cellphones, TVs, etc.

Content adaptivity can be approached on the level of media types. Infact, that is exactly the purpose of cohesion. We already described theadaption procedure. Obviously, there is no need for a particular theoryin the areas of EL or EB.

Process adaptivity to can be obtained on the level of the story space.For this we may exploit the fact that a story space can be describedby an expression in a many-sorted Kleene algebra with tests (MKATs)[?,16]. The general approach is as follows. We express the story space orparts of it by some process expression p. We then formulate a problem byusing equations or conditional equations in this MKAT. Furthermore, weobtain equations, which represent application knowledge. This applicationknowledge arises from events, postconditions and knowledge about the useof the WIS for a particular purpose. We then apply all equations to solvethe particular problem at hand.

The equations that define the application knowledge formulate pref-erences of a user. Furthermore, we formalised the intention of a user bysome propositional formula ψ. Then the problem is to find a minimalexpression p′ in the MKAT such that pψ = p′ψ holds.

The equational reasoning with MKATs used for process adaptivity isindependent from the application. The application area only determinesthe equations and the goal formulae. In EL these correspond to learningstyle and learning goals [11]. In EB no particular notions were introduced.

6 Conclusion

In this position paper we claimed that the generic co-design approachto the development of web information systems is powerful enough tocover diverse applications, in particular in EB and EL, and therefore itwould not be justified to treat EB and EL as fields in their own right. Wedemonstrated the validity of this claim by comparing the key features ofthe approach with corresponding features in these two application areas.

From this we may conclude that a generic theory for WISs is needed,and that the development of such a theory is the preferable scientificapproach. This does not exclude that there still exist application-specificfeatures that need to be handled separately. In addition, it is recommend-able trying to generalise specific features that arise in applications to thewhole area of WISs.


References

1. Atzeni, P., Gupta, A., and Sarawagi, S. Design and maintenance of data-intensive web-sites. In Proceeding EDBT’98, vol. 1377 of LNCS. Springer-Verlag,Berlin, 1998, pp. 436–450.

2. Baresi, L., Garzotto, F., and Paolini, P. From web sites to web applications:New issues for conceptual modeling. In ER Workshops 2000, vol. 1921 of LNCS.Springer-Verlag, Berlin, 2000, pp. 89–100.

3. Binemann-Zdanowicz, A., Schewe, K.-D., and Thalheim, B. Adaptation tolearning styles. In Proceedings ICALT 2004 (2004), IEEE Computer Society. toappear.

4. Binemann-Zdanowicz, A., Schulz-Brunken, B., Thalheim, B., andTschiedel, B. Flexible e-payment based on content and profile in the e-learningsystem DaMiT. In Proceedings of E-Learn 2003 (Phoenix (Arizona), USA, 2003),Association for the Advancement of Computing in Education.

5. Binemann-Zdanowicz, A., Thalheim, B., and Tschiedel, B. Logistics forlearning objects. In Proceedings of eTrain 2003 (2003).

6. Bonifati, A., Ceri, S., Fraternali, P., and Maurino, A. Building multi-device, content-centric applications using WebML and the W3I3 tool suite. In ERWorkshops 2000, vol. 1921 of LNCS. Springer-Verlag, Berlin, 2000, pp. 64–75.

7. Ceri, S., Fraternali, P., Bongio, A., Brambilla, M., Comai, S., and Mat-era, M. Designing Data-Intensive Web Applications. Morgan Kaufmann, SanFrancisco, 2003.

8. Dusterhoft, A., and Thalheim, B. SiteLang: Conceptual modeling of internetsites. In Conceptual Modeling – ER 2001, H. S. K. et al., Ed., vol. 2224 of LNCS.Springer-Verlag, Berlin, 2001, pp. 179–192.

9. Feyer, T., Kao, O., Schewe, K.-D., and Thalheim, B. Design of data-intensive web-based information services. In Proceedings of the 1st InternationalConference on Web Information Systems Engineering (WISE 2000), Q. Li, Z. M.Ozsuyoglu, R. Wagner, Y. Kambayashi, and Y. Zhang, Eds. IEEE Computer So-ciety, 2000, pp. 462–467.

10. Feyer, T., Schewe, K.-D., and Thalheim, B. Conceptual modelling and de-velopment of information services. In Conceptual Modeling – ER’98, T. Ling andS. Ram, Eds., vol. 1507 of LNCS. Springer-Verlag, Berlin, 1998, pp. 7–20.

11. Kaschek, R., Schewe, K.-D., Thalheim, B., Kuss, T., and Tschiedel, B.Learner typing for electronic learning systems. In Proceedings ICALT 2004 (2004),IEEE Computer Society. to appear.

12. Rostanin, O., Schewe, K.-D., Thalheim, B., and Tretiakov, A. Managingthe data in electronic learning systems. In Proceedings ICALT 2004 (2004), IEEEComputer Society. to appear.

13. Schewe, K.-D. The power of media types: Formal specification and verificationof web information systems. submitted for publication, 2004.

14. Schewe, K.-D., Kaschek, R., Wallace, C., and Matthews, C. Modellingweb-based banking systems: Story boarding and user profiling. In Advanced Con-ceptual Modeling Techniques: ER 2002 Workshops (2003), vol. 2784 of LNCS,Springer-Verlag, pp. 427–439.

15. Schewe, K.-D., Kaschek, R., Wallace, C., and Matthews, C. Emphasizingthe communication aspects for the successful development of electronic businesssystems. Information Systems and E-Business Management (2004). to appear.


16. Schewe, K.-D., and Thalheim, B. Conceptual modelling ofweb information systems. Tech. Rep. 3/2004, Massey Univer-sity, Department of Information Systems, 2004. available fromhttp://infosys.massey.ac.nz/research/rs techreports.html.

17. Schewe, K.-D., and Thalheim, B. Expressiveness of storyboarding. submittedfor publication, 2004.

18. Schewe, K.-D., and Thalheim, B. Reasoning about web information systemsusing story algebras. In Proceedings ADBIS 2004 (Budapest, Hungary, 2004). toappear.

19. Schewe, K.-D., Thalheim, B., Binemann-Zdanowicz, A., Kaschek, R.,Kuss, T., and Tschiedel, B. A conceptual view of electronic learning systems.submitted for publication.

20. Schwabe, D., and Rossi, G. An object oriented approach to web-based applica-tion design. TAPOS 4, 4 (1998), 207–225.

34 Schewe & Thalheim

Copyright © 2004, Idea Group Inc. Copying or distributing in print or electronic forms without writtenpermission of Idea Group Inc. is prohibited.

Chapter II

Structural Media Types inthe Development ofData-Intensive WebInformation Systems

Klaus-Dieter Schewe, Massey University, New Zealand

Bernhard Thalheim, Brandenburgian Technical University, Germany

ABSTRACTIn this chapter, a conceptual modeling approach to the design of webinformation systems (WIS) will be outlined. The notion of media type iscentral to this approach. Basically, a media type is defined by a view onan underlying database schema, which allows us to transform the datacontent of a database into a collection of media objects that represent thedata content presented at the web interface. The view is extended byoperations and an adaptivity mechanism, which permits the splitting ofmedia objects into several smaller units in order to adapt the WIS todifferent user preferences, technical environments and communicationchannels. The information entering the design of media types is extractedfrom a previous story boarding phase. In consecutive phases, media typeshave to be extended by style patterns as the next step toward implementation.

Development of Data-Intensive Web Information Systems 35


INTRODUCTIONIn this chapter, we address the conceptual modeling of web information

systems following the abstraction layer model that was already presented inanother chapter of this book (Kaschek et al., 2003). We concentrate only onthe structural aspects, i.e., operations will not be discussed. Thus, the centraltask will be the specification of the data content that is to be made available onthe Web. The goal is to provide conceptual means for describing the contentin a way that it can be tailored to different users, different end-devices anddifferent communication channels without designing multiple systems.

The chapter will guide the reader through a three-layer model of describingsuch data. Describing the structure of the data as it is presented on the Web willlead to defining the structure of media types. However, these structures will befull of redundancies and, thus, hard to maintain as such. Therefore, the data hasto be restructured in order to define a suitable database schema, which definesthe second layer. As database design follows different objectives, the contentspecification should lead to views, i.e., transformations, which turn the contentof a database into the content of a media type. The third layer is made up bydata types, i.e., immutable sets of values that can be used in the description ofthe other two layers.

Thus, a media type will basically be defined by a view on an underlyingdatabase schema, which allows us to transform the data content of a databaseinto a collection of media objects that represents the data content presented atthe web interface. Then, we extend media types in a way that they becomeadaptive to users, devices and channels. The adaptivity of a media typepermits the automatic splitting of media objects into several smaller units,allowing a user to retrieve information, in a step-by-step fashion, with the mostimportant information presented first. The reader will see two different ways tospecify which data should preferably be kept together, and how this will impacton the splitting of media objects.

The result of conceptual modeling will be a media schema, i.e., acollection of media types, which adequately represents the data content of thestory board. In this chapter, we will formalize this idea of conceptual modelingof web information systems by the use of media types. In the remainder of thischapter, we will first look at related work on conceptual modeling of webinformation systems. This will provide the reader with the necessary frameworkof the theory of media types. In a second step, we will illustrate in detail, butquite informally, the central ideas underlying media types. This is to convincethe reader about the naturalness of the approach. The third and fourth steps are



devoted to introducing, formally, data types, database schemata, and mediatypes on top of such schemata. The adaptivity extension will be introduced last,before we summarise the chapter, put again the media types into the context ofthe abstraction layer model and discuss follow-on activities, and draw someconclusions. Throughout the chapter, we will use a simple bottleshop example.

RELATED WORKThere are a few major groups working on conceptual modeling of web

information systems. One of them is the group around Paolo Atzeni (Universityof Rome), who defined the ARANEUS framework (Atzeni et al., 1998). Thiswork emphasises that conceptual modeling of web information systems shouldapproach a problem triplet consisting of content, navigation and presentation.This leads to modeling databases, hypertext structures and page layout.

However, the ARANEUS framework does not explicitly separate be-tween the content at the database layer and the web information system layer,i.e., the aspect of dealing with views. The navigation is not treated as anintegrated part of such views, but more as an “add-on” to the contentspecification. Besides navigation, no further operations that could cover thefunctionality of the system are handled. There is quite a fast drop fromconceptual modeling to the presentation, instead, of a more sophisticated workon the presentation and implementation aspects. The conceptual modelingapproach is not integrated in an overall methodology, e.g., the aspect of storyboarding is completely neglected. Adaptivity, with respect to users, usedtechnology, and channels is not incorporated into the conceptual model.

Of course, the work in the group continues and addresses most of theseissues. Also, other authors refer to the ARANEUS framework. The work inBaresi et al. (2000) addresses the integrated design of hypermedia andoperations, thus, picking up the functionality aspect but remaining on a veryinformal level. Similarly, the work in Bonifati et al. (2000) presents a webmodeling language WebML and starts to discuss personalisation of webinformation systems and adaptivity, but, again, is very informal.

Another group working on integrated conceptual modeling approaches isthe one around Gustavo Rossi (Argentina) and Daniel Schwabe (Brazil), whodeveloped the OOHDM framework (Schwabe et al., 1996), which is quitesimilar to the ARANEUS approach. A major difference is that the Romangroup has its origins in the area of databases, whereas the Latin American grouporiginally worked in the area of hypertext (Schwabe & Rossi, 1998).



The OOHDM framework (see also Rossi et al., 2000) emphasizes anobject layer, hypermedia components, i.e., links (discussed in more detail inRossi et al., 1999)) and an interface layer. This is, more or less, the same ideaas in the work of the Roman group, except that Rossi and Schwabe explicitlyrefer to an object oriented approach.

A third group working on integrated conceptual modeling approaches toweb information systems is the group around Stefano Ceri and Piero Fraternali(Polytecnico di Milano) (see Ceri et al., 2002 and Fraternali, 1999). The workemphasizes a multi-level architecture for the data-driven generation of websites, thus, taking the view aspect into account. The work addresses thepersonalisation of web sites by providing user-dependent site views, thus,being aware of the problem of adaptivity. The work emphasises structures,derivation and composition, i.e., views, navigation and presentation, thus,addressing the same problem triplet as the ARANEUS framework. Remainingdifferences to our work on media types are the fast drop from the conceptuallevel to the presentation, the treatment of navigation as an “add-on” and not anintegrated part of the views, and the missing emphasis on higher-level methodssuch as story boarding. Besides that, the theory of media types is formally moreelaborate.

Our own work started with the Cottbusnet project, addressing the designand development of a regional information service (see Thalheim, 1997) for adetailed description of the project, its approach, and the achieved results). Asa large project arising from practice, all problems had to be addressed at thesame time. This even included the demand for adaptivity to different end-devices. The research challenge was to formalise the concepts and to bringthem into the form of an integrated design and development methodology forweb information systems.

This resulted in a methodology oriented at abstraction layers and the co-design of structure, operations and interfaces (see Schewe & Thalheim 2000).Central to the methodology is the story boarding (Feyer et al., 1998; Feyer &Thalheim, 1999). The work in Düsterhöft and Thalheim (2001) contains anexplicit language SiteLang for the purpose of story boarding. The work inSchewe et al. (2002) applies story boarding to electronic banking. For theconceptual level, the methodology provides the theory of media types (Feyeret al., 1998; Feyer et al., 2000) — more elaborate work on this subject iscontained in Schewe and Thalheim (2000). The theory of media typesaddresses the objectives described in the previous subsection. It will bedescribed in detail in the remainder of this chapter.



Finally, there is uncountable work on the eXtensible Markup Language(XML). The Roman group has investigated how ARANEUS could be sup-ported by XML (Mecca et al., 1999), and we did the same with the theory ofmedia types (Kirchberg et al., 2003). However, as Lobin emphasises in Lobin(2000), XML should be considered as a “bridge” between the areas ofdatabases and the Web; and, as such, is neither completely part of databasesnor of web documents. Therefore, it is debatable whether XML should betreated as a new data model or just kept for modeling views.

CONCEPTUAL MODELING OFCONTENT AND ADAPTIVITY

The content aspect concerns the question: Which information should beprovided? This is tightly coupled with the problem of designing an adequatedatabase. However, the organisation of data that is presented to the user via thepages in a web information system differs significantly from the organisation ofdata in the database. We conclude that modeling the content of a webinformation system has to be addressed on at least two levels: a logical levelleading to databases, and a conceptual level leading to the content of pages.Both levels have to be linked together.

Consider an arbitrary web page. Ignore all the fancy graphics, colours,etc., and concentrate on the data content. For instance, consider a page usedin a bottleshop site, showing the label on a wine bottle together with adescription of the wine. You can describe the content saying that it consists ofthe picture of the label, the name of the wine, its year, the description of thewinery, the used grapes, information about colour, bouquet, acidity level,residue sugar, and many other details. You can write down this description ina formalised way, e.g.:

(name : “Chateau-Lafitte Grand Crus”, picture : “pic4711.gif”, year: 1998, winery : (name : “Chateau Lafitte”, region : “Hérault”,country : “France”, address : “…”), composition : (grape : “Merlot”,percentage : 65), …, … )

The components of this complex value need not only be strings, tuples,numbers, etc. They can be also complex values, such as tuples, sets, or URLsrepresenting links to other pages.



The URL associated with the arbitrary web page can be considered as anabstract identifier associated with this complex value. Thus, an adequateabstract description would be a pair (u, v), where u is a URL and v is a complexvalue, as shown above. We decide to call such a pair a media object. The term‘object’ is used because pairs constructed out of an abstract identifier and acomplex value are called ‘objects’ in the context of object oriented databases.Here, they refer to ‘media,’ as their collection describes the content of thewhole web information system as some kind of electronic media.

Content Types of Media TypesThe example suggests that several raw media objects share the same

structure. Continuing the bottleshop example, there may be lots of differentwines but, in all cases, the structure of the complex value would almost look thesame. Classification abstraction means to describe the common structure ofthese values. Formally, we can introduce data types, such as STRING forcharacter strings, NAT for natural numbers, DATE for dates, etc. We may evenhave composed types, such as ADDRESS. In general, we may think of a datatype as providing us with a set of values. Thus, the wines in the bottleshopexamples could be described by the following expression:

(name : STRING, picture : PIC, year : NAT, winery : (name : STRING,region : STRING, country : STRING, address : ADDRESS), composition: (grape : STRING, percentage : NAT) , …)

We have taken the freedom to assume that we may use a data type PICfor pictures. We may also assume to be given a type URL for all the possibleURLs. This data type also uses the notation ( … ) for tuple types, i.e., allpossible values are tuples, and … for set types, i.e., all possible values aresets.

We call an expression as the one above a content type. Content types area relevant part of media types. In our example, we would define a media typewith the name WINE and specify that the expression above is its content type.In general, every data type can become the content type of a media type.Thus, if M denotes a media type, the media objects of type M are pairs (u, v),consisting of a value u of type URL and a value v of the content type of M. Wecall u the URL of the media object and v its content value.

For example, if we define the content type of a media type WINE asabove, a media object of type WINE could be:



(“www.bottleshop.co.nz/wine/wine_tmp234”,(name : “Chateau-LafitteGrand Crus”, picture : “pic4711.gif”, year : 1998, winery : (name : “ChateauLafitte”, region : “Hérault”, country : “France”, address : “ … ”), composition: (grape : “Merlot”, percentage : 65), … , … ))

taking a “virtual” URL and the complex value that we started with.A little subtlety comes in here, which makes the definition still a bit more

complicated. When a value of type URL appears inside the content value v, thismay be a URL somewhere outside the Web Information System that we wantto develop. However, in the case where the URL is an internal one, it will bethe URL of a media object, say of type M . For instance, for a wine, i.e., amedia object of type WINE, the description of the winery may involve a historycomponent. As this history can be a long structured text on its own, we mayseparate it from the wine and place it on a separate page that is reachable bya navigation link. However, we would always get a link to (the URL of) a mediaobject of type WINERY_HISTORY.

Therefore, we extend content types in such a way that, instead of the typeURL, we may also use links : M , with a unique link name and a name ofa media type M . In our WINE example, the content type would change to

(name : STRING, picture : PIC, year : NAT, winery : (name : STRING,region : STRING, country : STRING, address : ADDRESS, history :WINERY_HISTORY), composition : (grape : STRING, percentage :NAT) , …)

We used a bit of meta-level syntax here: small capitals are used for thenames of media types, italic letters for data types, and normal letters for linknames and other labels.

In order to obtain a media object, we would have to replace the links : Mby the data type URL first. However, the link : M would force us to use onlyvalues of type URL that are URLs of the media type M .

In summary, the content of a web page may be described as a complexvalue. Combining a complex value with the URL for the web page forms amedia object. Several media objects may share the same structure; in otherwords, the complex values share the same structure. A content type is thegeneric expression capturing the structure of these complex values.



Database TypesMedia objects support an individual user and only provide a section of the

data of the system. The question arises how the data can be described globally.In fact, we would need to combine all the content types. For instance, in thebottleshop example we will not only have the content types of media typesWINE and WINERY_HISTORY. There may also be a PRICE_LIST or anOFFER. Some of the data that we use in media objects of type WINE may alsoappear in media objects of type OFFER, e.g., the information about the wineryor the grapes. Similarly, we could have added the price of a wine (for a bottleor a case) to the media object of type WINE.

This indicates that it is not the best idea to directly use the content typesof the media types for global data storage because this may lead to redundancy.Instead, we reorganise the global data content and set up a database.Designing the schema for such a database underlies completely different qualitycriteria. For instance, for databases we would like to avoid redundancies asmuch as possible. We would also have to pay much attention to providing fastand concurrent access to the data.

Therefore, we use a separate layer defined by database types. Thus, weobtain a description of the static components on at least two layers: the globalor database layer, and the local or media type layer. More than that, we evenuse a three layer approach consisting of a layer of data types, a layer ofdatabase types, and a layer of raw media types.

The Data Type LayerThe first layer is defined by data types, which define sets of possible

values for using them in content types and database types. We have alreadyseen examples of such data types, which are either base types such as STRING,NAT, URL, etc., or complex types, composed of base types and other complextypes such as tuple or set types. The example content type that we have seenalready used such tuple and set types. Tuple types (also called record types)can be written using the notation (a1 : t1, …, an : tn) with arbitrarily chosen labelsa1 …, an and data type names, t1, …, tn. Set types can be written using thenotation t. In the cases of tuple and set types, we call t1, …, tn (or t,respectively) the component types of the complex type.

To repeat, the content type of raw media type WINE was a tuple type

(name : STRING, picture : PIC, year : NAT, winery : (name : STRING,region : STRING, country : STRING, address : ADDRESS, history



:WINERY_HISTORY), composition : (grape : STRING, percent-age : NAT), …, …)

with the labels a1 = name, a2 = picture, a3 = year, a4 = winery, a5 = composition,etc., and the component types t1 = STRING, t2 = PIC, t3 = NAT, t4 = (name:…), t5 = (…), etc. The component type t4 is, again, a tuple type; thecomponent type t5 is a set type, which has a tuple type as its component type,etc. We see that, with composed data types, we can have any depth of nesting.

We call the collection of all possible data types a type system. There arelots of choices for type systems. Which one is used in a particular applicationdepends on the needs of the application and on the systems that are available.For our purposes here, the theory of media types, we may take the viewpointthat any type system will work as long as one of its base types is the data typeURL.

The Database Type LayerThe second layer is defined by database types over the type system.

These database types are, more or less, defined in the same way as the contenttypes. For instance, we may define a database type as:

(name : STRING, year : CARD, composition : (grape : STRING,percentage : CARD) , colour : STRING, bouquet : STRING,acidity : STRING, sugar : DECIMAL)

In particular, they may already include links. However, relational databasesystems would not be able to support such links. In general, the format ofdatabase types depends on the data model that has been chosen for theapplication.

The Media Type LayerThe third layer is defined by the media types which we have already

discussed above. Remaining questions are: how these media types differ fromthe database types and how they are connected to the database types.

We already stated that, when we look at the content types of media typesonly, there is no formal difference between such content types and databasetypes. The major difference concerns their purpose and usage. The databasetypes are used to represent the global data content of the WIS. The collectionof all the database types — this is what we call a database schema — isorganised in such a way that the desirable quality criteria for databases, such



as fast access, redundancy freeness, etc., can be met, whereas the contenttypes of media types are organised in a way that the information needs of theusers who navigate through the WIS are met. Redundancy among content typesis not only unavoidable, it is even intended.

Furthermore, links may already exist between database types, but thisneed not be the case. For the media types, however, the links are an importantmeans to represent the navigation structure of the WIS. Thus, links betweenmedia types are unavoidable and intended.

Finally, media types are not independent from the database types. Theinformation represented by the content types is already present in the databaseschema. Therefore, we need transformations from the database schema to thecontent types of the raw media types. Such transformations are called views.

Therefore, we have to add a description of the transformation from thedatabase schema to the content type. Such a transformation is called a query.In fact, a view is given by an input database schema, an output database schema— in our case the content type — and a query, which transforms a databaseover the input schema into a database over the output schema. In general, aquery could be any such (computable) transformation. In most cases, however,the query languages that come with the used data model determine whichqueries can be used. In doing so, they limit the expressiveness of the queries.

AdaptivityAdaptivity, in general, deals with the ability of a system to adapt itself to

external needs. We distinguish between three different lines of adaptivity.• Adaptivity to the user deals with needs arising from different users. Users

may prefer to receive information in a dense or sparse form. In the formercase, a larger portion of information would be transmitted to the user,whereas, in the latter case, the information would be delivered step bystep. Furthermore, it should be possible to provide different levels ofdetail and let the user switch between these levels.

For instance, taking up again the example of wines, a user may prefer tosee the information about a wine together with detailed information about thegrapes or the winery. Another user may prefer to see a list of several wines ata time, each coupled with only rough information about name, year, grapes.• Adaptivity to the technical environment copes with technical restrictions

of end-devices. For instance, if mobile end-devices with small screens orTV-based end-devices are to be supported, it would, nevertheless, bedesirable to have only one conceptual description, and to tailor the media



objects to the specific needs of the technical environment only when theseneeds arise.

• Adaptivity to the communication channel deals with adaptation to needsarising from various communication channels. As users do not want to waittoo long for the information to be transferred, a restricted channel capacityshould imply a step-by-step delivery of the information.

Structural media types deal with adaptivity by extending the definition ofmedia types by cohesion, which allows a controlled form of information loss.On the level of content types, we determine which data should preferably bekept together. In all cases where user preferences or technical constraints forcethe information to be split, the split will be made in such a way that data that isto be kept together will be kept together. The lost information will becomeavailable in a follow-on step.

DATABASE TYPES AND DATA TYPESIn this section, we start describing media types in a more formal way. We

concentrate first on the data type and the database layer, that are used to definemedia types. Recall that the data type layer introduces data types, i.e., sets ofpossible values, whereas the database layer introduces database types, whichdefine the structure of the possible databases.

This section can be treated as a short introduction to conceptual datamodeling. In particular, if the central notions of this section, such as databaseschema, are known, it is possible to skip this section and proceed directly withthe introduction of media types in the next section.

Our presentation in this section will introduce a data model that is quiteclose to the Entity-Relationship model. It lies somewhere between the basicEntity-Relationship model and the Higher-order Entity-Relationship model(Thalheim, 2000). Recall from the introduction above that structural mediatypes could take any other data model. The choice of data model for this sectionis mainly due to the fact that its structural units leave only a small gap betweenthe data model and the media types.

Data TypesData types are used to classify values. In general, types are used for

classification. Thus, the name “data type” suggests that we classify data.However, in our context, the term “data” is used for several quite different



purposes. We should distinguish between the data treated by data types, thedata treated by database types, and the data treated by media types. Therefore,in the context of data types, we talk of values; in the context of databases, we willtalk of objects; and in the context of media types, we will talk about media objects.

Thus, a data type gives some notation for a set of values. To be precise,data types should also provide the operations that can be applied to thesevalues. For the moment, these operations are not important for us, so we willignore them. A collection of data types that is defined by some syntax is calleda type system. If we use abstract syntax, we can define a type system bywriting:

t = b (a1 : t1, …, an : tn) t [t] (a1: t1) (an : tn)

This description of syntax needs some further explanation. We use thesymbol b to represent an arbitrary collection of base types, such as thefollowing types:• CARD for non-negative integers, INT for integers,• CHAR for characters, STRING for character strings,• DATE for date values, BOOL for truth values,• URL for URL-addresses, MAIL for e-mail-addresses, OK for a single

value ok, etc.

Thus, the definition of the type system above states that a type t is eithera base type or has one of the following four forms:• We can have t = (a1: t1, …, an : tn) with arbitrary, pairwise different labels

a1, …, an and types t1, …, tn. Such a type is called a tuple type. The typest1, …, tn used to define the tuple type are called the component types ofthe tuple type. The intention of a tuple type is to provide a set of tuplevalues, each of which has the form (a1: v1, …, an :vn), using the labels a1,…, an and values v1 of type t1, v2 of type t2, etc.

• We can have t = t with another type t . Such a type is called a set type.The intention of a set type is to provide a set of values, each of which isitself a finite set v1, …, vn, with values v1,…, vn of type t .

• Similarly, we can have t = [t ] with another type t . Such a type is calleda list type. The intention of a list type is to provide a set of values, eachof which is a finite, ordered list [v1, …, vn], with values v1, …, vn of type t .

• Finally, we can have t = (a1: t1) (an : tn) with arbitrary, pairwisedifferent labels a1, …, an and types t1, …,tn. Such a type is called a union



type. The types t1, …,tn used to define the union type are called thecomponent types of the union type. The intention of a union type is toprovide a set of values, each of which has the form (ai : vi), using one ofthe labels a1, …, an and values v1 of type t1, v2 of type t2, etc.

We say that ( ), and [ ] and … are constructors for records,sets, lists and unions.

Example 1. Define a data type NAME by:

NAME = (first_names : [STRING], middle_initial : (y : CHAR) (n : OK), titles : STRING, family_name : STRING) .

This is a tuple type with four components according to the followingintention:• The first component gives a list of character strings for the first names.• The second component is either a single character for a middle initial or

ok, which indicates that there is no middle initial.• The third component gives a set of character strings for titles.• The last component is a single character string for the family name.

Thus, possible values of type NAME would be:

(first_names : [ “George”, “Francis”, “Leopold” ], middle_initial : (n : ok),titles : “Professor”, “Sir”, family_name : “Stocker”)

and

(first_names : [ “Harry” ], middle_initial : (y : ‘F’), titles : ,family_name : “Rugger”).

Let us now define the semantics of data types, i.e. we will associate witheach data type t a set dom(t) of values, called values of type t. In the definitionof data types, and in Example 1, we already gave a glimpse of what thedefinition of semantics will look like.

We follow the inductive definition of data types to define the set dom(t) ofvalues of type t as follows:



• For a base type t, we obtain- dom(CARD) = N = 0, 1, 2, … is the set of natural numbers.- dom(INT) = Z = 0, 1, -1, 2, -2 … is the set of integers.- dom(CHAR) = A, a, B, b, … is a fixed set of characters.- dom(BOOL) = T, F is the set of Boolean truth values.- dom(OK) = ok.- dom(DATE) = dd-mm-yyyy d, m, y 0, 1,…, 9 is the set of alldate values.- dom(STRING) = dom(CHAR)* = a1… an n N, ai dom(CHAR)is the set of all character strings over A, a, B, b, ….- dom(MAIL) is the set of all syntactically valid mail addresses.- dom(URL) is the set of all syntactically valid URLs.- If further base types are defined, we associate with them a fixed set ofvalues in the same way.• dom((a1 : t1, …, an : tn)) = (a1 : v1, …, an : vn) vi dom(ti) for all i= 1,…, n is the set of n-tuples with component values in dom(ti) for i =1,…, n.• dom( t ) = A P (dom(t)) A is the set of all finite subsetsof (dom(t). Thus, we have dom(t) = v1,…, vk k N and vi dom(t)for all i = 1,…, k• Similarly, dom([t]) = [ v1,…, vk ] k N and vi dom(t) for all i =1,…, k is the set of all finite lists with elements in dom(t).• dom((a1 : t1) (an : tn)) = (a1 : v1) v1 dom(t1) ∪ ∪ (an : vn)vn dom(tn) is the disjoint union of the sets dom(ti) (i = 1,…, n), i.e.

elements in dom(ti) are labeled with ai before the union is built.

Example 2. Let us continue Example 1 and consider again the data type:

NAME = (first_names : [STRING], middle_initial : (y : CHAR) (n : OK), titles : STRING, family_name : STRING) .

As the outermost constructor is the tuple type constructor, each value indom(NAME) is a tuple of the form:

(first_names : v1, middle_initial : v2, titles : v3, family_name : v4).

Here, v1 must be a value of type [STRING], i.e. is a finite list of strings: v1= [ v11, v12, …, v1k] with all v1i dom(STRING). v2 must be a value of type (y: CHAR) (n : OK), so it is either (y : v2) with a value v2 dom(CHAR) or



(n : ok). v3 is a value of type STRING, i.e., it is a finite set of strings: v3 = v31 , v32, …, v3 with all v3i dom(STRING). Finally, v4 is a character string.

Database TypesWe now proceed with the second layer, which deals with database types

and database schemata. Look again at the bottleshop example that we used sofar. A basic unit of information in this example is given by the wines. So, we maydescribe a wine by its name, its year, the used grapes, information about colour,bouquet, acidity level, and residue sugar. Assume that we do not have toprovide further details. We may want to keep the description of the wineryseparate, but it is not intended to provide any details about grapes. So, wecreate attribute names such as name, year, composition, colour, bouquet,acidity and sugar. These attributes are sufficient to describe wines, providedthat, for each of these attributes, we declare a data type, which will describethe possible values for this attribute.

Thus, a first definition would be the following:

A database type of level 0 has a name E and is described by a finite set attr(E)= a1, …, am of attributes. Each attribute ai is associated with a datatype type(ai).

We will extend this definition below by adding key attributes.

Example 3. Taking the example of wines from above, we define a databasetype with the name WINE and the attribute set

attr(WINE) = name, year, composition, colour, bouquet, acidity, sugar.

Associated data types could be type(name) = STRING, type(year) =CARD, type(colour) = STRING, type(bouquet) = STRING, type(acidity) =STRING, type(sugar) = DECIMAL, and type(composition) = (grape :STRING, percentage : CARD). Thus, we would describe an object of typeWINE by a combination of values for all these types or, equivalently, by a singlevalue of the following tuple type:

(name : STRING, year : CARD, composition : (grape : STRING,percentage : CARD) , colour : STRING, bouquet : STRING, acidity :STRING, sugar : DECIMAL)

using the attribute names of the database type as labels.



Similarly, we can define a database type WINERY with attributes name,founded, owners, address, and maybe more. We omit the details of such a type.

Besides database types of level 0, we may also define database types onhigher levels. For instance, in the bottleshop example, we may relate wines withwineries that produce them. In this case, the entity types WINE and WINERYwould become components of a new type PRODUCER. Such a type is adatabase type of level k, with k 1 being the maximum of the levels of thecomponent types. Of course, we may extend the higher-level database type byadding attributes such as start_date, end_date, and maybe others.

A database type of level k has a name E and consists of:• a set comp(E) = r1 : E1 ,…, rn : En of components with pairwise

different role names ri and names Ei of database types,• a set attr(E) = a1,…, am of attributes, each associated with a data type

type(ai), and• a key id(E) comp(E) ∪ attr(E),

such that the database types Ei S are all on levels lower than k, with atleast one database type of level exactly k 1.

Note that the role names are only needed to allow the same database typeto appear more than once as a component of another database type. Obviously,in this case, the occurrences have to be distinguished by using different rolenames.

Example 4. Let us complete the description of a relationship type PRO-DUCER. We define this type by the set of components comp(PRODUCER)= of : WINE, by : WINERY and the set of attributes attr(PRODUCER)= start_date, end_date. The associated types can be type(start_date)= DATE and type(end_date) = (f : DATE) (nf : OK).

In Example 3, we have seen that we can associate a single data type witha database type of level 0 by turning the attribute names into labels of a tupletype. The question is how this can be generalised to database types on higherlevels. The easiest solution would be to treat the attributes in the same way asdatabase types of level 0, and to use the role names also as labels, using the datatypes associated with the lower level database types as components. Forinstance, for the database type PRODUCER in Example 4, we would obtain thedata type:



(of : tWINE

, by : tWINERY

, start_date : DATE, end_date : (f : DATE) (nf: OK)),

with the component type tWINE

defined in Example 3, and a component typetWINERY

defined elsewhere. Values of this type would be called objects of typePRODUCER.

Though this approach is formally correct, it has certain disadvantages, asthe resulting data types will be quite big and, in each value, we would have torepeat values that describe on lower levels. Instead of this, we will exploit thekeys, i.e., combinations of components and attributes that uniquely identifyobjects.

In the following, we often write E = ( r1 : E1, …, rn : En , a1 , …, am , id(E))to denote a database type. The first component in this triple is the componentset comp(E). The second component is the attribute set attr(E). The thirdcomponent is the key id(E).

We use this notation to associate two data types with each database typeE. These data types are called the associated data type of E and theassociated key type of E. These types are defined as follows:• The associated data type of E, denoted as type(E), is

(r1: key-type(E1), …, rn : key-type(En), a1: type(a1), …, am : type(am)).• The associated key type of E, denoted as key-type(E), is defined

analogously with the difference that only those ri and aj are considered thatoccur in id(E).

In particular, if we have a database type E of level 0, then comp(E) is theempty set. This implies that there will be no labels ri in type(E) nor in key-type(E).

Example 5. In Example 3, we have seen a database type of level 0. Thefollowing definition extends this database type by a key:

WINE = (, name, year, composition, colour, bouquet, acidity, sugar,name, year) .

We keep the associated data types:type(name) = STRING,type(year) = CARD,type(composition) = (grape : STRING, percentage : CARD),



type(colour) = STRING,type(bouquet) = STRING,type(acidity) = STRING,type(sugar) = DECIMAL.

So, as we have already seen in Example 3, the associated data typetype(WINE) would be the data type:

(name : STRING, year : CARD, composition : (grape : STRING,percentage : CARD) , colour : STRING, bouquet : STRING,acidity : STRING, sugar : DECIMAL).

The associated key type key-type(WINE) would be the data type:

(name : STRING, year : CARD).

In Example 4, we discussed a database type PRODUCER of level 1. Weextend this definition by a key, which leads to:

PRODUCER = (of : WINE, by : WINERY, start_date, end_date,of : WINE, by : WINERY, start_date.

We keep the same associated data types:

type(start_date) = DATE,type(end_date) = (f : DATE) (nf : OK).

Then, the associated data type and the associated key type of the databasetype PRODUCER are:

(of : (name : STRING, year : CARD), by : …, start_date : DATE,end_date : (f : DATE) (nf : OK) ),

and

(of : (name : STRING, year : CARD), by : …, start_date : DATE) ,

respectively. In both data types, the dots have to be replaced by the associatedkey type key-type(WINERY). As we omitted the definition of the database type



WINERY, we have to omit the replacement of these dots by a real data type,too.

Cluster TypesBefore we introduce database schemata and databases, we still have to

discuss one further extension. This will be the introduction of so-called clustertypes. In order to get started, look again at Example 5, in which we presenteda database type PRODUCER of level 1. The component database types ofPRODUCER were the types WINE and WINERY. Now, assume that ourbottleshop also offers beers, and these beers are produced by breweries. So,we would add two other database types of level 0: BEER and BREWERY. Wecan now extend the of-component in PRODUCER in such a way that it refersto WINE or BEER. In the same way, we could change the by-component sothat it refers to WINERY or BREWERY. In order to do so, replace the of-component in PRODUCER by a new type BEVERAGE, and the by-componentby a new type COMPANY, while defining BEVERAGE by the “disjoint union” ofWINE and BEER, and COMPANY by the “disjoint union” of WINERY andBREWERY. Such disjoint unions are defined by cluster types.

A cluster type of level k, written E = (id1 : E1) (idn : En), has a nameE and consists of a non-empty sequence of components E1, …, En, which canbe database types or cluster types, with pairwise different component identi-fiers idi, such that the level k is the maximum of the levels of the Ei.

Example 6. Formalising our motivating example from above we define the twocluster types BEVERAGE = (w : WINE) (b : BEER) and COMPANY =(w : WINERY) (b : BREWERY) of level 0.

Now we can extend the definition of associated data types and associatedkey types to cluster types. According to the motivation above, it should not besurprising to see that we now use union types. Therefore, let E = ( id1 : E1 ) ( idn : En ) be a cluster type. The associated data type type(E) and the associatedkey type key-type(E) are defined as follows:

type(E) = key-type(E) = (id1 : key-type(E1) ) (idn : key-type(En)).

Database Schemata and DatabasesLet us now conclude the presentation of the global database layer by

defining database schemata. A database schema is simply a collection of



database and cluster types. Of course, if Ei is a component of a database orcluster type E, and E is defined in the schema, then Ei must also be defined inthe schema. Formally, we can define a database schema as follows:

A database schema S is a set of database types and cluster typessatisfying the following two conditions:• If E S is a database type, then, for all components ri : Ei comp(E),

we must also have Ei S.• If E = E1 Ek is a cluster type in S, then, for all components Ei (i =1,…, k),

we must also have Ei S.

We define the semantics of database schemata by the collection ofpossible databases by the database schema. Thus, let S be a database schema.For each database or cluster type E S, we have defined an associated datatype type(E) and an associated key type key-type(E). As these two are indeeddata types, they define fixed sets of values, which we call the set of objects oftype E and the set of keys of type E, respectively:

Obj(E) = dom(type(E)) and Key(E) = dom(key-type(E))

As the key id(E) in a database type E is a subset of comp(E) ∪ attr(E),each object of type E can be projected to a key of type E. Let O[key-type(E)] Key(E)denote the projection of the object O Obj(E) to the value of its key. For acluster type E each object O of type E, we have O[key-type(E)] = O. We use thesets of objects and keys for the database and cluster types E S to define adatabase over S as follows:

A database db over S assigns to each database or cluster type E S afinite set db(E) Obj(E) of objects of type E such that the following conditionsare satisfied:1. Key values are unique, i.e., there cannot be two different O1, O2 db(E)

with O1[key-type(E)] O2[key-type(E)].2. Component values exist in the database, i.e., for each O db(E) and each

r:E comp(E), there must exist some O db(E ), such that r:O [key-type(E )] ispart of O.

3. Clusters are disjoint unions, i.e., for a cluster E = ( id1 : E1 ) ( idn : En ),we obtain db(E) = (idi : Oi[key-type (Ei)]) Oi db(Ei) and i 1,…, n .



Finally, let us briefly introduce a graphical representation for databaseschemata, which we call a (database) schema diagram:• We use rectangles to represent database types on level 0 — in this case,

we always have comp(E) = — and place the name of the type insidethe rectangle.

• We use diamonds to represent database types on higher levels — in thiscase, we always have comp(E) — and place the name of the typeinside the diamond.

• We use arrows from a type to all its component types, and attach the rolenames to these arrows.

• We use to represent cluster types, and arrows to the components of thecluster type.

• We attach attributes directly to the rectangles or diamonds.• We underline the attributes in the key, and mark the arrows corresponding

to components in the key with a dot.

If schema diagrams tend to become large, we usually omit the attributenames. Sometimes we even drop the names of the cluster types.

Example 7. Let us consider an example database schema for a bottleshopapplication illustrated in Figure 1. A bottleshop is to deliver wines, beers,juices and other soft drinks, and hard alcoholics drinks such as Cognac,Grappa, Scotch and Irish Whiskey. The sales are to be supported by aweb information system. The Web Information System shall provide acatalogue containing the offered products, as well as occasional specialoffers. Additional information about wines, grapes, vineyards (also forCognac, Grappa, Calvados and Whiskey) shall be provided, as well. Thesystem must offer information about the shop itself, historical and actualinformation about certain grapes, wine producers, etc. The system shouldalso provide special information about best sellers, new products, etc.Comments from (hopefully pleased) clients shall be made available on theWeb.

QUERIES AND STRUCTURAL MEDIA TYPESIn this section, we address the layer of media types. The intention behind

the media types is to provide a local view on the data that are stored in theunderlying database. The emphasis of this layer is to specify data as they are



to appear on web pages, however, without any consideration of how the datashould be presented. Thus, the media types are used to structure dataaccording to a usage perspective rather than a storage perspective.

Formally, a structural media type is defined by a content type and adefining query. There is no big, formal difference between content types ofstructural media types and database types, except that content types shouldsupport links, whereas the existence of links in database types depends on thedata model. The major difference is given by the fact that structural media typesneed a defining query which links the media type with an underlying databaseschema. If Q is the defining query of a structural media type M, it may beexecuted on databases db over the underlying database schema S. The querywill result in the set of media objects of type M. Of course, if databases areupdated, the database db and consequently also the set of media objectschanges.

In the following, we will first briefly discuss queries. It is beyond the scopeof this chapter to go into details of query languages, but we will emphasize theneed and difficulty of creating links (Schewe, 2001). In fact, each data modelrequires its own query languages, and the theory of media types can be basedon any data model. In a second step, we will then give a formal definition ofstructural media types and media objects.

Figure 1: Schema Diagram of the Example Database Schema

WINE HARD_DRINK SOFT_DRINK BEER

PRODUCER PACKAGE OFFER

BOTTLE DISTILLERY VINEYARD ORDER

REGION PUBLICATION DELIVERY CUSTOMER

NEWS COUNTRY



QueriesLet us consider queries. In general, a query is a transformation from one

database schema into another one. In most cases, the target schema of such atransformation is significantly simpler than the source schema.

For instance, consider the database schema from the bottleshop examplewhich we developed in the previous section. Suppose we are given a databasedb over this schema, i.e. we have information about wines, producers,vineyards, etc. Suppose we want to have a list of New Zealand wines from1998 on, with at least 30% Cabernet Sauvignon, together with some informa-tion about the vineyard and the region. In this case, we define a target databaseschema with exactly one database type NZ_WINE. This database type —which is, of course, a database type of level 0 — can be defined as follows:

NZ_WINE = ( , name, year, composition, vineyard, owners, since, history, region, climate, name, year).

The data types of the attributes can be defined as follows:

type(name) = STRINGtype(year) = CARDtype(composition) = (grape : STRING, percentage : CARD)type(vineyard) = STRINGtype(owners) = STRINGtype(since) = DATEtype(history) = STRINGtype(region) = STRINGtype(climate) = STRING

Formally, a query can be defined as follows:

A query Q consists of a source database schema src(Q), a target databaseschema trgt(Q), and a map q(Q), which takes as its input all databases oversrc(Q) and produces databases over trgt(Q).

How would we process such a query? Of course, we can only sketch anidea of query processing. Actually, techniques used in query processing differsignificantly from this simple outline here, but we are only interested in gettingan idea of the database transformation, not of its technical realisation. In our



example query looking for New Zealand wines, we could take a database dbover the source schema, i.e., the database schema from the previous section.The set db(WINE) contains finitely many values of type type(WINE), which isa tuple type with labels name, year, composition, colour, bouquet, acidity andsugar. First, we use a projection, i.e., we simply “forget” the last fourcomponents. Each tuple will be reduced to a tuple of a tuple type containingonly the labels name, year and composition.

Looking into the details of the component labeled by ‘composition,’ weknow that we must have a set of pairs, the first component of which is labeledby grape, the second one by percentage. We only keep those tuples, where thisset contains a pair (“Cabernet Sauvignon”, x) with a value x 30. This is calleda selection. Similarly, we only keep tuples where the value y of the yearcomponent satisfies y 1998. In doing this, we would already obtain the winesfrom 1998 on with at least 30% Cabernet Sauvignon.

However, we want to have New Zealand wines only, and for these wedemand information about the vineyard and the region. Therefore, we have tolook at the cluster BEVERAGE_H and the database type PRODUCER. We onlykeep those tuples where the values for name and wine appear as a pair labeledby b in the component labeled by of in objects in db(PRODUCER). However,as we want to get vineyards and not distilleries, we only consider those objectsin db(PRODUCER) with a by-component labeled by v. Using this component,we obtain objects of type VINEYARD. We rename the label name in theseobjects to vineyard, in order to avoid mixing up the name of wines with vineyardnames, and we forget the size and grapes components. Adding the remainingcomponents to the tuples gives new tuples with components name, year,composition, vineyard, owners, since, history, and in.

The latter one can be used for another join with db(REGION). Again, inthis way we obtain the name component of the region, which we rename toregion, the climate component, the wines component, which we forget, and thespecialities component, which we forget, as well. The in-component finallyleads to db(COUNTRY). We only keep tuples where the join gives a value “NZ”for the code component.

This rough sketch of query processing shows how a database over thesource schema can be transformed into a database over the target schema. Thequery may have produced a tuple such as the following:

(name : “Otago Red”, year : 2000, composition : (grape :“Cabernet Sauvignon”, percentage : 65), (grape : “Malbec”, per-centage : 35) , vineyard : “Martha’s Vineyard”, owners : “Rudi



Müller”, “Martha Thurgau” , since : 1967, history : “Once upon atime …’’, region : “Otago”, climate : “The climate in Otago …”).

Now, recall that a media object is not only a complex value, but it is a pair(u, v), with a value u of type URL and a complex value v. Queries, as wediscussed them above, would only result in a set of objects of the databasetypes in the target database schema. Thus, instead of obtaining the value above,we would also like to obtain a URL, or at least a unique identifier, which couldlater be replaced by an actual URL. As such URLs are not stored in thedatabase, they have to be created by processing the query.

This implies requiring that the query language should allow the creation ofURLs and links. We call this property create facility (see, e.g., Abiteboul etal., 2000, Chapter 6). In terms of our sketch of query processing, this simplymeans that, at any stage, we may introduce URLs by transforming a set v1,…,vm or list [ v1, …,vm ] of values into a set (u1, v1), …,(um, vm) or list [(u1,v1), …,(um, vm)] of pairs, with new values ui of type URL, respectively, orsimply by transforming a value v of any type into a pair (u, v) with a value u oftype URL.

Note that once we process a query on a database db, we may add theresult to the database. Processing further queries may then also include thenewly created URLs into their results. In this way, navigation structures can beset up.

Structural Media TypesWe are now ready to formally round up this section and define structural

media types. We first need an exact definition of a content type. Recall that acontent type is an extended data type, in which the place of a base type maybe occupied by a pair : M , with some label and a name M of a media type— in fact, this means to choose any name.

Thus, using abstract syntax again (as we did for data types on page 10),we can define the system of content types by writing:

ct = b (a1 : ct1 , …, an : ctn) ct [ ct ] (a1 : ct1) (an : ctn) : N

The explanation we gave on data types is still valid. However, theextension by pairs : M is of pure syntactical nature. We cannot associate aset of values with a content type. Instead, for a content type cont(M), we define



a representing datatype tM, which results from cont(M) by replacing all : Mby the base type URL. Of course, tM is a real data type, and this means thatdom(tM) is defined.

Let S be a database schema. A structural media type over S has a nameM and consists of:• a content data type cont(M), in which the place of a base type may be

occupied by a pair : M , and• a defining query qM with source schema S and target schema (url : URL,

value : tM), where tM is the representing datatype of M.

Example 8. Let us define some structural media types over the databaseschema from the previous section. We will concentrate on the content typeand the representing data type. However, we will only sketch the definingquery, as we have not yet introduced a concrete query language.

Of course, the type type(NZ_WINE) that we used in the target schema inthe previous subsection is a content type defined as follows:

(name : STRING, year : CARD, composition : (grape : STRING,percentage : CARD) , vineyard : STRING, owners : STRING ,since : CARD, history : STRING, region : STRING, climate :STRING).

However, it does not contain any links : M , which implies that it isidentical with its representing data type t

NZ_WINE. Adding a formal description

of a defining query qNZ_WINE

as sketched in the previous subsection turnsNZ_WINE into a structural media type.

Now assume that we want to represent information about New Zealandwines by a slightly changed structural media type NZ_WINE* with the followingcontent type:

(name : STRING, year : CARD, composition : (grape : STRING,percentage : CARD) , vineyard : STRING, owners : STRING ,since : CARD, history : STRING, region : REGION*).

In this case, the content type contains the link region : REGION*.Consequently, the representing data type t

NZ_WINE* is the following:



(name : STRING, year : CARD, composition : (grape : STRING,percentage : CARD) , vineyard : STRING, owners : STRING ,since : CARD, history : STRING, region : URL).

Of course, we also would have to define a structural media type with thename REGION* with a content type chosen to be (name : STRING, climate :STRING), which, again, is identical to the representing data type t

REGION*. Thedefining query q

REGION* for REGION* would select all regions in NewZealand, reduce them to their name and climate components, and create URLsfor all the resulting objects.

Then the defining query qNZ_WINE* for the structural media type NZ_WINE*

would be processed in the same way as sketched in the previous subsection.However, components region and climate would be replaced by the URL thathas been created while processing the query q

REGION*. Furthermore, theoperation create_urls would be applied to the result. We omit formaldetails on how to write the queries q

REGION* and qNZ_WINE*.

Note that, with the introduction of links between structural media types,the defining queries are no longer independent from each other. In Example 8,the processing of the query q

NZ_WINE* depends on the result of the queryqREGION*. As long as there are no cyclic dependencies, the query processing

can be done in a particular order. However, in the case of cycles, the processrequires calculating a fixed point. Queries that demand fixed point calculationare one of the most advanced topics in the field of databases.

Content SchemataFinally, let us look at the analog of a database schema on the level of

structural media types. For this, assume that we have fixed a database schema S.As structural media types abstract from content, a collection of structural mediatypes over S will be called a content schema. Analogously to the definition ofdatabase schemata, where we had to ensure that components of databasetypes are defined in the database schema, we now have to ensure that thestructural media types that occur in links are defined in the content schema.Therefore, we define a content schema as follows:

A content schema C over a database schema Sis a finite set of structuralmedia types over S, such that for each M C and each link : M occurringin the content type cont(M), we also have M C.



Finally, assume that we are given a database schema S and a contentschema C over S. We may now define a site s over C analogously to a databaseover S.

For this, let db be a database over S. We may evaluate the defining queryqM for each structural media type M C. These result in sets s(M) of pairs (u,v),such that u is a value of type URL and v is a value of the representing data typetM of M. We call s(M) the set of media objects of type M in the site s. Of course,we must ensure that for each URL u that appears inside the complex value vat a place occupied by : M in the content type cont(M) of M, we have a mediaobject (u , v ) s(M ).

The family of all the sets s(M) with M C defines the site s over Cdetermined by the database db over S.

ADAPTIVITYIn this section, we extend media types by adding adaptivity to users,

technical environment, and channels. In all three cases, the idea is to split theinformation provided by a structural media object in such a way that parts thatare preferred to be kept together — we use the term cohesion for this — willbe kept together, if this is possible. This can be seen as a controlled form ofinformation loss.

The Idea of AdaptivityAs indicated above, cohesion intends to declare “parts” of a content type

cont(M) to belong closer together than others. We will approach this in twodifferent, but similar, ways. In both cases, we consider all possible contenttypes that result from cont(M) by losing information. If ct is such a content typewith reduced information, we write cont(M) ct. Thus, we first have to definethis relation , which, in fact, is a partial order.

The idea of using the partial order is by choosing one such possible contenttype ct, which is as close to the original cont(M) as possible. Instead of creatinga media object of type M using the content type cont(M), we reduce the contentto the one described by the content type ct, and present this to the user. Iffurther information is needed, the user may request it by following a link addedto ct. There should be a complementary content type ct covering the lostinformation. This complementary content type can then be treated again in thesame way.



For instance, take again the example of a structural media type NZ_WINE.Its content type was defined as follows:

(name : STRING, year : CARD, composition : (grape : STRING,percentage : CARD) , vineyard : STRING, owners : STRING ,since : CARD, history : STRING, region : STRING, climate :STRING).

Losing information would mean to drop the year, or the composition, orthe percentages of the grapes, or the history, etc. Assume that we want to keepthe information on name, year and composition together with the highestpriority, followed by the information on the vineyard, its owners and history,and leaving the lowest priority for the information on the region and its climate.Then we could first choose the following content type ct1:

(name : STRING, year : CARD, composition : (grape : STRING,percentage : CARD) , further : NZ_WINE

2).

Here, the link further : NZ_WINE2 provides a link to a dynamically

constructed structural media type named NZ_WINE2. The content type of this

new structural media type should contain the lost information. Thus, it could bethe following content type ct2:

(name : STRING, year : CARD, vineyard : STRING, owners : STRING, since : CARD, history : STRING, further : NZ_WINE

3).

Here, we find the information about the vineyard, its owners, and itshistory. We also repeat the name and year of the wine. Furthermore, the linkfurther : NZ_WINE

3 provides a link to another dynamically constructed

structural media type named NZ_WINE3. The content type of this new

structural media type should contain further information, because the informa-tion on the region is still lost. Thus, it could be the following content type ct3:

(name : STRING, year : CARD, region : STRING, climate : STRING).

The alternative is to provide a priori such a split of the content type. In ourexample, we would define the split by the three content types ct1, ct2 and ct3.These three content types define an antichain with respect to the partial order

, i.e., each two of them are incomparable in the sense that cti ctj holds forall i j.



For both ideas, we first have to define the partial order on content types.This is done as follows:• For any content type ct, we have ct ct.• For any content type ct, we have ct OK.• For content types of the form (a1 : ct1 ,…, am : ctm), we have:

(a1 : ct1 , …, am : ctm) (a (1) : ct (1), …, a (1) : ct (n)),

with injective : 1, …, n 1, …, m and ct (i) ct (i).

• For content types of the form [ ct ], we have [ ct ] [ ct ] iff ct ct holds.• For content types of the form (a1 : ct1) (am : ctm), we have (a1 : ct1)

(am : ctm) (a1 : ct 1) (am : ct m) iff cti ct i holds for alli = 1,…, m.

• For content types of the form ct , we have ct ct iff ct ct holds.

We use the notation sup(cont(M)) to denote the set of all content types ctwith cont(M) ct. If, in the example above, we remove the links ‘further :NZ_WINE

2’ and ‘further : NZ_WINE

3’ in ct1 and ct2, respectively — these

were added only as a link to follow-on information — then we obtain cont(M) cti forall i = 1, …, 3.

Cohesion PreorderLet us now go into details of our first idea (Feyer et al., 2000). The partial

order also defines a partial order on sup(cont(M)). However, the order is nottotal, i.e., there can be content types ct1, ct2 sup(cont(M)) with neither ct1 ct2nor ct2 ct1. Thus, in case of making a choice among the elements insup(cont(M)), both ct1 and ct2 have equal rights. Making a choice in favour ofone of them, say ct1, means to state that the information represented by ct1 ismore important than the one represented by ct2.

Therefore, the first idea can be realised by extending to a total order.Nevertheless, we may state explicitly that we do not want to prefer ct1 over ct2nor vice versa, even in case they were comparable with respect to . Therefore,we only require to obtain an extension by a pre-order as defined now:

A cohesion pre-order on a structural media type M is a total pre-order Mon sup(cont(M)) extending the order , i.e., whenever ct1 ct2 holds, wealso have ct1 Mct2.



The major idea behind the cohesion pre-order is that, in order to adapt todifferent users, channels or environments, smaller content types with respect to

are preferred over larger content types. In all three cases, we assume thatthe amount of data to be transmitted at a time and presented to the user is limitedby some bound. If the presentation of a structural media object of type Mexceeds this bound, the content type will be split according to the followingprocedure:• First, we determine the maximum amount of data that should be transmit-

ted.• Then, we determine the least element ct1 with respect to M that requires

not more than the available capacity. As M is only a preorder, there maybe more than one such t1, in which case, one of these content types ischosen randomly.

• Taking t1 instead of cont(M) means that some information is lost.Therefore, we include a link to a possible successor. The link name andthe name of the successor structural media type will be randomly chosen.

• In order to determine such a successor, all content types ct sup(cont(M))with ct1

≺M ct are considered. We choose a least content type ct2 among

these ct with respect to M , such that ct2 does not require more than theavailable capacity.

Continuing this way the whole communication using the structural mediatype M is broken down into a sequence of suitable units ct1, ct2, … , ctn that,together, contain the information provided by the structural media type.

Example 9. Let us consider again the content type of the structural media typeNZ_WINE used earlier. However, as sup(cont(NZ_WINE)) will be large,we reorganise the content type and outline the splitting procedure withoutlooking into details of the content type. Thus, assume that we have thefollowing content type:

(wine-info : (name : STRING, year : CARD, composition : (grape: STRING, percentage : CARD) ), vineyard : (name : STRING,owners : STRING , since : CARD, history : STRING), region :(name : STRING, climate : STRING)).

In order to shorten our presentation, we consider only



(wine-info : …, vineyard : …, region : …)

and ignore the inner structure, which is indicated by the dots. Ignoring the innerstructure, we could define a cohesion pre-order by:

(wine-info : …, vineyard : …, region : …)(wine-info : …, vineyard : …)

(wine-info : …, region : …) (vineyard : …, region : …)

(wine-info : …) (vineyard : …)

(region : …)

Assume that only the complete content type exceeds the computedmaximum capacity. Then, the first content type to be chosen would be:

(wine-info : …, vineyard : …),

which will be extended to:

(wine-info : …, vineyard : …, next : NZ_WINE2).

This leaves the following content types:(wine-info : …, vineyard : …, region : …)

(wine-info : …, region : …)(vineyard : …, region : …)

(region : …).

Thus, the second content type to be chosen will be:

(wine-info : …, region : …).

This will become the content type of the dynamically generated structuralmedia type NZ_WINE

2. The splitting process stops here, as further processing

would not lead to more information.



Proximity ValuesFinally, let us consider the alternative approach (Feyer et al., 1998). In this

approach, the content types that will be chosen instead of cont(M) aredetermined a priori. We only determine whether they will be transmitted one byone, or whether some of them will be recombined. Thus, we choose a maximalantichain ct1, …, ctn in sup(cont(M)) with respect to . This antichain alreadyrepresents a possible split of information. In addition, we define a symmetric (n × n)-matrix pij 1 i,j n of proximity values with 0 pij 1. The intention is that thehigher the proximity value, the more do we wish to keep the componentstogether.

Splitting is processed analogously to the case a using a cohesion pre-order:• For each X 1, …, n , we determine its weight, i.e., w(X) = i,j X,i j pi,j.• For each X 1, …, n , we determine its greatest common subtype

gcs(X), i.e., the greatest element ct1 sup(cont(M)) with t1 cti for alli X.

• Then, we choose the X with largest weight, such that the gcs(X) does notrequire more than the available capacity.

Example 10. We take the same media type as in Example 9 and the antichain

ct1 = (wine-info : …) ct2 = (vineyard : …) ct3 = (region : …).

Let the proximity values be chosen as p1,2 = 0.8, p1,3 = 0.5 and p2,3 = 0.1.Then, we obtain the following weights and greatest common subtypes:

The result will be the same sequence of content types as in Example 9.

X w(X) gcs(X)

1 0 (wine-info : …) 2 0 (vineyard : …) 3 0 (region : …) 1, 2 0.8 (wine-info : …, vineyard : …) 1, 3 0.5 (wine-info : …, region : …) 2, 3 0.1 (vineyard : …, region: …) 1, 2, 3 1.4 (wine-info : …, vineyard : …, region: …)



We discussed adaptivity to users, environment and channels. This wasdone in the form of allowing structural media types to be extended by acontrolled form of information loss, coupled with the notion of cohesion.

A cohesion extension of structural media type M is given either by acohesion pre-order on sup(cont(M)) or by a pair consisting of maximalantichain ct1,…,ctn in sup(cont(M)) with respect to and a symmetric(n×n)-matrix pij1 i,j n of proximity values with 0 pij 1.

A media type is a structural media type M together with a cohesionextension. A media schema is a content schema, in which all structuralmedia types are media types.

Given a media schema, then, it is basically a content schema over anunderlying database schema. Thus, any database determines sets of mediaobjects. The cohesion extension further determines variants of the mediaobjects that are dynamically constructed when the need arises. It leads to astep-by-step delivery of a media object.

CONCLUSIONWe presented a conceptual model for data-intensive web information

systems, which is centered around the central notion of media type. Roughlyspeaking, a media type is defined as an extended view on an underlyingdatabase schema, and includes operations and adaptivity features.

Conceptual modeling with structural media types is embedded in anintegrated methodology based on an abstraction layer model for web informa-tion systems. Prior to this activity, we have an activity of story boarding, whichmodels the WIS from a usage perspective (Kaschek et al., 2003). The scenesin the story board are used as the data source for the media types. Further on,the media types do not yet specify anything on their web presentation. For this,media types have to be associated with style options. Using these style optionsand suites of XML representations leads to the implementation. The completemethodology has been applied in more than 30 large projects. The report(Thalheim, 1997) describes the first of these projects; for others, the work andpublication rights have been transferred to professional companies.

We have seen that several other groups have also developed conceptualmodeling approaches for web information systems. The theory of media types



is one of these approaches. As work progresses, the ideas produced by thedifferent groups are now converging, though the theory of media types is stillthe most advanced model with respect to formal foundations. Furthermore, itis still more elaborate with respect to adaptivity, the scope of the overallmethodology, in particular, with respect to an integration with story boarding,the work on implementation and presentation issues, and applications inpractical projects.

Taking the convergence of ideas, the currently existing advantages of thetheory of media types in comparison to other approaches will disappear. Forinstance, other approaches will take up the work on adaptivity. Conversely, thetheory of media types will benefit from the work of others and become evenmore elaborate. However, the convergence trend concerns the concepts, notconcrete languages. In particular, the theory of media types will be likely topreserve its connections to theory.

The role of XML will become even more important. On one side, XMLmay pick up ideas that will enable a better support for media types or similarconceptual modeling approaches. On the other side, XML will always remaina concrete language and may distract from the important issue of conceptualmodeling. If XML is treated as a data model, most of the hardest databaseproblems still have to be solved in this context. Therefore, we think it is betternot to fix the attention only on XML. Using XML for representing the views isuncritical, but it is unlikely that it will be able to replace completely the theoryof media types. As this theory can be based on any data model, it is much moregeneric than any concrete language.

REFERENCESAbiteboul, S., Buneman, P., & Suciu, D. (2000). Data on the Web: From

Relations to Semistructured Data and XML. San Francisco, CA:Morgan Kaufmann.

Atzeni, P., Gupta, A., & Sarawagi, S. (1998). Design and maintenance of data-intensive web-sites. In Proceedings of the EDBT’98 (Vol. 1377 ofLNCS, pp. 436-450). Berlin: Springer-Verlag.

Baresi, L., Garzotto, F., & Paolini, P. (2000). From web sites to webapplications: New issues for conceptual modeling. In ER workshops2000 (Vol. 1921 of LNCS, pp. 89-100). Berlin: Springer-Verlag.

Bonifati, A., Ceri, S., Fraternali, P., & Maurino, A. (2000). Building multi-device, content-centric applications using WebML and the W3I3 tool



suite. In ER workshops 2000 (Vol. 1921 of LNCS, pp. 64-75). Berlin:Springer-Verlag.

Ceri, S., Fraternali, P., & Matera, M. (2002). Conceptual modeling of data-intensive web applications. IEEE Internet Computing, 6(4), 20-30.

Düsterhöft, A. & Thalheim, B. (2001). SiteLang: Conceptual modeling ofinternet sites. In H. S. Kunii, S. Jajodia, & A. Sølvberg (Eds.), Concep-tual modeling – ER 2001 (Vol. 2224 of LNCS, pp. 179-192). Berlin:Springer-Verlag.

Feyer, T. & Thalheim, B. (1999). E/R based scenario modeling for rapidprototyping of web information services. In P. P.-S. Chen (Ed.), Ad-vances in Conceptual Modeling (Vol. 1727 of LNCS, pp. 253-263).Berlin: Springer-Verlag.

Feyer, T., Kao, O., Schewe, K.-D., & Thalheim, B. (2000). Design of data-intensive web-based information services. In Q. Li, Z. M. Ozsuyoglu, R.Wagner, Y. Kambayashi, & Y. Zhang (Eds.), Proceedings of the 1stInternational Conference on Web Information Systems Engineering(WISE 2000) (pp. 462-467). IEEE Computer Society.

Feyer, T., Schewe, K.-D., & Thalheim, B. (1998). Conceptual modelling anddevelopment of information services. In T. Ling & S. Ram (Eds.),Conceptual Modeling – ER’98 (Vol. 1507 of LNCS, pp. 7-20). Berlin:Springer-Verlag.

Fraternali, P. (1999). Tools and approaches for developing data-intensive webapplications: A survey. ACM Computing Surveys, 31(3), 227-263.

Kaschek, R., Schewe, K.-D., Wallace, C., & Matthews, C. (2003). Storyboarding for web-based information systems. In W. Rahayu & D. Taniar(Eds.), Web Information Systems. Hershey, PA: Idea Group.

Kirchberg, M., Schewe, K.-D., & Tretiakov, A. (2003). Using XML tosupport media types. Submitted for publication.

Lobin, H. (2000). Informationsmodellierung in XML und SGML. Berlin:Springer-Verlag.

Mecca, G., Merialdo, P., & Atzeni, P. (1999). ARANEUS in the era of XML.IEEE Data Engineering Bulletin.

Rossi, G., Garrido, A., & Schwabe, D. (2000). Navigating between objects:Lessons from an object-oriented framework perspective. ACM Com-puting Surveys, 32(1).

Rossi, G., Schwabe, D., & Lyardet, F. (1999). Web application models aremore than conceptual models. In P. C. et al. (Eds.), Advances inConceptual Modeling (Vol. 1727 of LNCS, pp. 239-252). Berlin:Springer-Verlag.



Schewe, K.-D. (2001). Querying web information systems. In H. S. Kunii, S.Jajodia, & A. Sølvberg (Eds.), Conceptual Modeling – ER 2001 (Vol.2224 of LNCS, pp. 571-584). Berlin: Springer-Verlag.

Schewe, K.-D. & Thalheim, B. (2000). Conceptual modelling of internetsites. Tutorial notes. 19th International Conference on Conceptual Mod-elling (ER 2000). Available at: http://infosys.massey.ac.nz/~kdschewe/pub/slides/ER00tuti.ps with i = 0, …,6.

Schewe, K.-D., Kaschek, R., Matthews, C., & Wallace, C. (2002). Model-ling web-based banking systems: Story boarding and user profiling. In H.Mayr & W.-J. Van den Heuvel (Eds.), Proceedings of the Workshop onConceptual Modelling Approaches to E-commerce. Berlin: Springer-Verlag.

Schwabe, D. & Rossi, G. (1998). An object oriented approach to web-basedapplication design. TAPOS, 4(4), 207-225.

Schwabe, D., Rossi, G., & Barbosa, S. (1996). Systematic hypermedia designwith OOHDM. In Proceedings of Hypertext ‘96 (pp. 116-128). NewYork: ACM Press.

Thalheim, B. (1997). Development of Database-backed Information Ser-vices for CottbusNet. Cottbus, Germany: BTU Cottbus. (TechnicalReport No. CS-20-97)

Thalheim, B. (2000). Entity-relationship Modeling: Foundations of Data-base Technology. Berlin: Springer-Verlag.

Formalisation of User Preferences,

Obligations and Rights

Klaus-Dieter Schewe1, Bernhard Thalheim2, Alexei Tretiakov1

1 Massey University, Department of Information Systems & Information Science Research Centre

Private Bag 11 222, Palmerston North, New Zealand k.d.schewe | [email protected]

2 Christian Albrechts University Kiel

Department of Computer Science and Applied Mathematics Olshausenstr. 40, D-24098 Kiel, Germany

[email protected]

Abstract The aim of this paper is to formalise user preferences, obligations and rights in the context of web information systems (WISs), and to indicate how this formalisation can be used to reason about WIS specifications. This problem is approached on two levels of abstraction. On a high level a WIS is represented by a storyboard, which itself can be represented by an algebraic expression in a Kleene algebra with tests (KAT). Preferences can be formalised using the equational theory of KATs, which enable sophisticated propositional reasoning that can be applied to WIS personalisation. Obligations and rights give rise to a propositional deontic logic. On a lower level of abstraction detailed state specifications are added using extended views. This amounts to replacing KATs by higher-order dynamic logic, using a higher-order deontic logic, and the formalisation of proof obligations.

Introduction

Web information systems (WISs) are an important class of data-intensive systems with a lot of applications in e-business (Schewe et al., 2005a), e-learning (Schewe et al., 2005b), information services (Feyer et al., 1998), and many more. Each WIS provides a dialogue between the system and the users, the latter ones being very often unknown to the designers. Each user uses the system to perform a certain task, some of which may only be realised by a joint effort of several users.

One problem we are confronted with in WISs is to be aware of user preferences and goals such that the system can be set up in way that permits an automatic customisation to these preferences and goals. In order to do so we have to formalise the user preferences, which of course depend on a classification of users into user profiles or user types.

Furthermore, not all users are eligible to perform or contribute to the same tasks. This requires another classification of users according to their roles, and each role determines the rights and obligations of users in this role.

The aim of this paper is to formalise user preferences, obligations and rights and to indicate how this formalisation can be used to reason about the WIS specification. For this purpose we adopt the co-design approach from (Schewe and Thalheim, 2005) to WIS design. On a high-level of abstraction the major modelling activity is storyboarding (Kaschek et al., 2004; Schewe and Thalheim, 2005; Thalheim and Düsterhöft, 2001), which consists of defining the story space, the actors, and the tasks. The system is considered as a set of abstract locations called scenes, between which users navigate. On their paths (called stories) through these scenes the users execute actions. This leads first to modelling story spaces by directed labelled graphs that are further refined by story algebras (Schewe and Thalheim, 2004; Thalheim and Düsterhöft, 2001). Actor modelling comprises user profiling, role modelling plus modelling information portfolios. However, information portfolios are treated as part of supporting information for scenes (Schewe and Thalheim, 2005). We will present the gist of storyboarding in the next section.

In particular, we will formalise obligations and rights as part of user roles (Schewe and Thalheim, 2005) using a propositional variant of deontic logic (Eiter and Subrahmanian, 1999). This permits expressing deontic constraints already on a high level of abstraction. Furthermore, preferences will be associated with user profiles or user types (Schewe and Thalheim, 2005).

In (Schewe and Thalheim, 2004) it was actually shown that story algebras carry the structure of Kleene algebras with tests (KATs, (Kozen, 1997)), thus term rewriting can be applied to reason about story spaces, in particular, as KATs subsumes propositional Hoare logic (Kozen, 1999). In (Schewe and Thalheim, 2004) this was applied to personalisation with respect to user preferences, which can be formalised by equations, and user goals, which can be formalised by postconditions. However, it was left open where the preferences were to be taken from. According to this model several dimensions are used to characterise user properties and for each dimension a usually ordered set of values is provided. A user profile is determined by values for each of the dimensions, whereas a user type combines several value combinations. While this is an accurate approach in accordance with more application oriented approaches, e.g. learner modelling for e-learning systems, it bears the risk of having to define too many user types. Preferably, it would be better, if equations that express preferences would be made explicitly depending on values of some dimensions. This avoids identifying the user types and may be used to determine evolving user-specific story spaces. However, it is very unlikely that user types are compositional, so that we must expect non-monotonicity in personalisation using such an approach. We will demonstrate this approach to personalisation in another section.

Obligations and rights that are associated with roles have been formalised in (Schewe and Thalheim, 2005) using a propositional variant of deontic logic (Eiter and Subrahmanian, 1999). This permits expressing deontic constraints already on a high level of abstraction. However, all these high-level propositional approaches to formalising preferences, goals, obligations and rights with their reasoning facilities provide only a first and rather coarse handling of the problem. In order to fully capture the problem we have to look at a finer

level of detail taking the data content and the functionality that is available at each scene into account. For this the method in (Schewe and Thalheim, 2005) provides media types that are extended views on some underlying database schema. The data model for this schema is of minor importance as long as the query language used for the views is expressive enough. For instance, it is well possible to assume that the database schema is modelled using HERM (Thalheim, 2000), while the query language constructs rational trees (Schewe and Thalheim, 2005).

One of the extensions to the views captures explicitly adaptivity to users, channels and end-devices by using cohesion pre-orders or proximity values, which both enable a controlled split of information. For our purposes here, however, the extension by operations is a greater importance. As briefly indicated in (Schewe, 2004) the media types permit the refinement of propositional conditions in the story algebra by formulae in higher-order logic, while the operations refine the actions in the story space. These operations can be modelled as abstract programs, so that the whole story space will be refined by expressions of higher-order dynamic logic (Harel et al., 2000). This can be used to set up proof obligations for personalisation, static and dynamic consistency and story space correctness (Schewe, 2004).

With respect to obligations and rights, the deontic constraints associated with the storyboard can be refined as well using the full power of deontic logic for agents (Eiter and Subrahmanian, 1999; Elgesem, 1997; Nute, 1997). Similar use of deontic logic has been made in (Broersen et al., 2002; Dignum et al., 1996; Wieringa and Meyer, 1993; Wieringa and Meyer, 1991). In particular, we obtain a level of granularity that will allow us to model the cooperation of actors including messaging and task delegation. The non-monotonicity requests to take defeasibilty into account as well (Antoniou et al., 2001). In the last section before the conclusion we will present this refined approach to the problem of formalising preferences, obligations and rights.

Storyboarding

A storyboard describes the ways users may choose to interact with the system. It consists of three parts: a model of the story space, a model of actors, and a model of tasks. The story space describes the paths users follow while navigating through the WIS. These paths are the stories. Actors are groups of users with the same behaviour, which leads to modelling user profiles and roles. Tasks link the actions of the story space with the actors, but we will not discuss tasks in this paper.

Story Spaces On a high level of abstraction we may think of a WIS as a set of abstract locations, which abstract from actual pages. A user navigates between these locations, and on this navigation path s/he executes a number of actions. We regard a location together with local actions, i.e. actions that do not change the location, as a unit called scene.

Then a WIS can be described by a edge-labelled directed graph, in which the vertices represent the scenes, and the edges represent transitions between scenes. Each such transition may be labelled by an action executed by the user. If such a label is missing, the transition is due to a simple navigation link. The whole graph is then called the

type_

of_

loan

1

loan_

overv

iew1

0

mortg

age_sam

ples 14

mo

rtgage 13

enter_loan

_system

1

perso

nal_loan

11

perso

nal_loan

_

samp

les1

2

applicant_

details 2

perso

nal_loan

_

details 3

look

_at_

loans_

at_

a_glance 2

skip

skip

skip

request_

mo

rtgage_

details 4

loo

k_at_

mortg

age_sam

ples 6

skiplo

ok_

at_perso

nal_

loan_

samp

les 5

skip

request_p

ersonal_

loan

_details 3

select_m

ortg

age 13

select_perso

nal_loan

7

pro

vide_

applicant_

details 8

skip

describ

e_loan

_p

urp

ose 9

enter_am

ount_

requested 10p

ersonal_

loan_

bud

get 4

select_p

l_term

s_and

_con

ditions 1

2

comfirm

ation

8

con

firm_

applica

tion 2

0

skipsk

ip

incom

e 9

mo

rtgag

e_d

etails 5

securities_

details 6

mo

rtgage_

bud

get 7

describe

_object 14

enter_m

ortgag

e_am

ou

nt 15

enter_

inco

me_

details 11

describ

e_secu

rities 16

select_m_

terms_an

d_

con

ditions 1

8

calculate_

paym

ents 1

9

enter_

oblig

ations 12

skip

skip

skip

skip

skip

skip

skip

skip

skip

skip

start0

loan

_

purp

ose 15

skip

specify_

purpo

se 21

Fig. 1. A Story Space for On-Line Loan Applicaitoine.

story space. Scenes may be atomic or complex. In the latter case the scene itself represents another set of abstract locations, between which users can navigate. This gives rise to a multi-layer model.

Example 1. Figure 1 shows the graph of a story space for on-line loan applications. We numbered the scenes and the actions, so referring to this example we only talk of scene is and action jα . In addition, scenes and actions are named, and the names have been chosen in a way to be understandable without deeper explanation.

The scene 0s start= is the start scene, i.e. a user using the WIS will start here. Only one action 1 _ _enter load systemα = can be chosen in this scene. This action leads to a transition to scene 1 _ _s type of loan= , in which general information about loans will be provided. A user has several actions to choose from in this scene. The actions 7 _ _select personal loanα = and

13 _select mortgageα = lead to the scene 2s applicant_details= , the starting scene for the core of a loan application. Alternatively, a user may choose the action 2 _ _ _ _ _look at loans at a glanceα = requesting an overview on all available loans with a short description for each, which will be done in scene 10 _s loan overview= . From here a simple transition without action, indicated by the label skip leads back to the scene 1s .

Similarly, actions 3 _ _ _request personal loan detailsα = and 3 _ _request mortgage detailsα = to scenes 11 _s personal loan= and 13s mortgage= , respectively, in which details about a particular personal loan or mortgage will become available. In both cases a user can navigate back to scene 1s , or request samples for the personal loan or mortgage by choosing the action 12 _ _ _ _look at personal loan samplesα = in scene 11s or

6 _ _ _look at mortgage samplesα = in scene 13s , respectively, which will lead to scene 12 _ _s personal loan samples= or 14 _s mortgage samples= , respectively. The last action 21 _specify purposeα = in scene 1s takes a user to scene 15 _s loan purpose= , in which advice

on suitable loans for a specified purpose can be sought.

The part of the story space starting from scene 2s deals with gathering applicants' details, details of the selected mortgage or personal loan or mortgage such as the amount requested, terms and conditions and securities, details concerning the incoming of the applicants, and finally a confirmation of the application. It can be understood in the same way, as the names of scenes and actions are self-explanatory - using "pl" and "m" as shortcuts for personal loan and mortgage, respectively.

At a finer level of detail we would like to extend the story space and indicate, under which conditions an action or scene transition can or must be executed and what will be the effect of an action. In doing so we associate a precondition with each action to specify exactly, under which conditions an action can be executed. Such preconditions can be easily expressed on the basis of propositional logic. That is, we take a set 1, , nϕ ϕ… of atomic propositions and complete this to a propositional logic defining the set Φ of propositional formulae in the usual way, i.e.

• Each atomic proposition iϕ is a proposition in Φ .

• If ,ϕ ψ ∈Φ , then also , ,ϕ ϕ ψ ϕ ψ¬ ∧ ∨ and ϕ ψ→ are propositions in Φ .

Thus, the precondition of an action α is a proposition ( )Pre α ∈Φ . A user can only choose the action α and execute it, if the precondition ( )Pre α is satisfied in the current state of the WIS.

In a similar way we associate a postcondition ( )Post α ∈Φ with each action α to specify exactly, which effects the action will have. That is, if the action α is selected and executed, the resulting state of the WIS will satisfy the proposition ( )Post α .

Example 2. Take another look at the story space represented by Figure 1, in particular at the action 13 _select mortgageα = . In this case we may want that a user can only execute this action, if s/he has received the necessary information about available mortgages, i.e. mortgages must be known. This can be simply formalised by requesting

( _ ) _Pre select mortgage mortgages known= using an atomic proposition. The interpretation of this atom should be that a user knows about mortgages.

Analogously, we may set ( )_ _Post select mortgage mortgage selected= , which states that after executing 13α a mortgage has been selected.

Plots The introduction of pre- and postconditions of actions opens a new perspective to the story space. We may look at the plot, which give a detailed, yet still high-level specification of functionality. In addition to pre- and postconditions, actions can be executed sequentially or in parallel, they can be iterated, and if several actions are available, users can choose between them. These extensions should also become part of the plot. These possibilities to combine actions lead to operators of an algebra, which we will call a story algebra. Thus, we can describe a story space by an element of a suitable story algebra.

Let us take now a closer look at the storyboarding language SiteLang (Thalheim and Düsterhöft, 2001), which defines a story algebra that captures the details of plots. For this we take the set A of actions and the set S of scenes as the basis for defining the set of processes ( ),P P A S= determined by A and S .

The set of processes ( ),P P A S= determined by the set of actions A and the set of scenes S and the extension of the scene assignment σ to a partial mapping : P Sσ → are inductively defined as follows:

• Each action Aα ∈ is also a process.

• skip (or 1) is a process with no effect.

• fail (or 0) is a process that is not executable.

• If 1p and 2p are processes, then also the sequence 1 2p p is a process.

• If 1p and 2p are processes, then also the choice 1 2p p+ is a process.

• If p is a process, then also the iteration *p is a process.

• If p is a process and ϕ is a boolean condition, then the guarded process pϕ and the post-guarded process pϕ are processes.

We would like to define also the parallel process 1 2p p . However, as we are mainly interested in the stories, we can consider 1 2p p as a shortcut for 1 2 2 1p p p p+ , i.e. we just state that the order of the component processes does not matter.

A plot may contain boolean conditions. The rationale behind this is that such a condition can be identified with a test that checks the condition. In particular, we write ϕ ψ+ for the disjunction of conditions ϕ and ψ , ϕ ψ⋅ for their conjunction, and ϕ for a negated condition. This unusual notation is in accordance with the notation for Kleene algebras with tests, which we will exploit in the next section. In particular, the overloaded use of + for disjunction and choice, ⋅ for conjunction and sequence, 1 for true and skip skip, and 0 for false and fail does not lead to conflicts.

Example 3. A plot expression for the detailed loan application in Figure 1 can be described as follows:

( ) ( ) ( )( )( )( )( ) ( )( )

1 0 21 13 2 1 3 5 3 2 4 6 4 5 7 6 13 7

* *6 8 8 9 10 11 12 8 7 8 8 14 15 16 11 17 12 18 19 12 18 9

1 1 1 *

1 *

α ϕ α ϕ α ϕα α ϕ ϕ α α ϕ ϕ α ϕ α ϕ

ϕ α α α α α α ϕ ϕ α α α α α α α ϕ α α ϕ α ϕ

+ + + + + +

+ +

The scenes and actions have already been named in Figure 1. Furthermore, the plot involves the Boolean conditions

0 = information_loan_types_neededϕ 1 = information_personal_loans_neededϕ

2 = information_mortgages_neededϕ 3 = personal_loans_knownϕ

4 = mortgages_knownϕ 5 = available_loans_knownϕ

6 = personal_loan_selectedϕ 7 = mortgage_selectedϕ

8 = personal_loan_application_completedϕ 9 = mortgage_application_completedϕ

10 = applied_for_personal_loanϕ 11 = applied_for_mortgageϕ

12 = payment_options_clearϕ 13 = loans_recommendedϕ

As in the previous examples the names chosen for the propositional atoms should be self-explanatory, e.g. 0 = information_loan_types_neededϕ expresses that the user needs information about the available types of loans, while 12 = payment_options_clearϕ indicates that the different payment options for mortgages are understood by the user.

User Roles: Deontic Logic for Web Information Systems Users can be classified according to their roles, goals and behaviour. We use the term actor for such a group of users. The role of an actor indicates a particular purpose of the

system. As such it is usually associated with obligations and rights, which lead to deontic integrity constraints.

Roles are used to classify actors according to their rights and obligations. For instance, in a web-based conference system we may have roles for the programme committee chair(s), the programme committee members, and for authors. In an on-line loan system we may distinguish between actors in the role of customers and those in the role of bank clerks. In most systems we may expect one default role that is taken on by any actors, whereas other roles require some form of identification or at least an active switch to this role.

Let us now look briefly at a more sophisticated way to express rights and obligations that depend on other actions. An obligation specifies what an actor in a particular role has to do. A right specifies what an actor in a particular role is permitted to do. Both obligations and rights together lead to complex deontic integrity constraints. We use the following logical language L for this purpose:

• All propositional atoms are also atoms of L .

• If α is an action on scene s and r is a role associated with s , then ( ),O do r α ,

( ),P do r α and ( ),F do r α are atoms of L .

• For , Lϕ ψ ∈ we also have ϕ¬ , ϕ ψ∧ , ϕ ψ∨ , ϕ ψ→ and ϕ ψ↔ are also formulae in L .

Here we use the more familiar notation for negation, conjunction and disjunction than in the previous subsection. For the time being both approaches do not interfere with each other.

The interpretation is standard. In particular, ( ),O do r α means that an actor with role r is

obliged to perform action α , ( ),P do r α means that an actor with role r is permitted to

perform action α , and ( ),F do r α means that an actor with role r is forbidden to perform action α .

Example 4. The on-line loan example plot from Example 3 only contains one role customer, thus all actions and scenes in this example are associated with these role. Nevertheless, we may express some deontic constraints using the logical language defined above.

A customer has the obligation to leave his/her details (action 9α ), once a personal loan or a mortgage has been selected (condition 6ϕ or 7ϕ ), Furthermore, if a mortgage is selected (condition 7ϕ ), the customer is obliged to describe securities (action 16α ) and to enter obligations (action 17α ), i.e. we obtain the deontic constraints

( )6 7 8,O do customerϕ ϕ α∨ → and ( ) ( )7 16 17, ,O do customer O do customerϕ α α→ ∧ . Furthermore, a customer is allowed to look at mortgage samples (action 6α ), which is simply expressed by ( )6,P do customer α .

We may of course extend the on-line loan system further by adding roles bank clerk and mortgage advisor and further deontic constraints.

User Profiles and Types Modelling the behaviour of an actor leads to user profiles, which can be modelled by giving values for various properties that characterize a user. Furthermore, each profile leads to preference rules that can again be expressed by constraints on the story space.

While roles classify actors according to their rights and obligations, user profiles and user types classify actors according to their behaviour. That is, roles indicate a pro-active approach to WIS modelling, whereas user profiling is reactive.

The general approach is to start with characterising properties of users and to provide values for each of these properties. Each combination of such values defines a user profile. However, the behaviour for some of these profiles is usually the same. So we combine user profiles to user types.

Furthermore, each user profile or type leads to rules, in particular preference rules. According to the characterising aspects of WISs we may distinguish between preferences concerning the content, the functionality or the presentation. In the context of storyboarding such preferences can be expressed by constraints on the story space.

We will now discuss in more detail these user profiles and types. We start with a finite set ∆ of dimensions capturing the properties of users. For each dimension δ ∈∆ we assume to be given a domain ( )dom δ . Some of these domains may be totally ordered, i.e. there

is a total order δ≤ on ( )dom δ usually, we drop the index. A totally ordered domain is also a called a scale of the dimension.

As there are usually many dimensions, each of which has a domain with at least two elements, this gives us many ways to combine these values to obtain user profiles. In order to be able to manage the combinatorial explosion, we introduce user types.

If 1, , nδ δ∆ = … is a set of dimensions, then the set of user profiles (or the user-grid)

over ∆ is ( ) ( ) ( )1 ngr dom domδ δ∆ = × ×… . A user type over ∆ is a subset ( )U gr⊆ ∆ .

This way of defining a user type as any subset of the user-grid leaves a lot of freedom to define a set 1, , kU U… of user-types for a particular story space. We must of course assure that this set of user types is complete in the sense that all user profiles are covered. That is, for each user profile ( ) ( )1, , nv v gr∈ ∆… , i.e. ( )i iv dom δ∈ , there must exist at least

one 1, ,j k∈ … with ( )1, , n jv v U∈… .

One might expect that user profiles that contribute to the same user type, do not differ too much in the values for the dimensions. For this consider cubes in the user-grid.

If 1, , nδ δ∆ = … is a set of dimensions, then a subset ( )U gr⊆ ∆ is a cube iff it has the

form 1, , nU D D= … , such that for all 1, ,i n= … , for which ( )idom δ is totally ordered

scale, whenever 1 2,i i iv v D∈ with 1 2ii iv vδ≤ holds, then also i iv D∈ for 1 2i ii i iv v vδ δ≤ ≤ . Thus, one common way of defining user types is to consider cubes in the user-grid. We call these user types kiviat, because they can be easily represented by Kiviat graphs. We expect that most user types will be kiviat.

The major purpose of introducing user types is to provide ways to customise the WIS to its users, i.e. to personalise the system. In principle there are two ways of doing it. The first one would just introduce user-type-specific plots, whereas the second one would try to generate them out of preference rules and general rules about the story space. Therefore, it is a good idea to formulate preference rules. Even if user-specific plots are not derived but specified by WIS designers, the rules can be useful to quality check the customised plots.

In view of the algebraic constructors, that were used to specify plots, we consider preference rules in connection with these constructors. This leads to the following definition.

A preference rule associated with a user type U is expressed through one of the following

equations:

• An equation of the form ( )ϕ α β ϕα+ = expresses that a user conditionally prefers action α over action β , where the condition is expressed by ϕ . The special case

trueϕ = expresses an unconditional preference.

• An equation ( )1 2 1p p p pp+ = expresses the conditional preference of the process 1p over 2p after the process p . The special case 1p = expresses an unconditional preference.

• An equation 1 2 2 1 1 2p p p p p p+ = expresses a preference of order, i.e. if the processes

1p and 2p can be executed in arbitrary order, it is preferred to execute first 1p .

• An equation * *p pp= expresses that in case of an iteration it will be executed at least once.

Story Space Customisation

Let us now see how we can use preference rules to customise plots. For this we exploit the fact that our story algebra carries the structure of a Kleene algebra with tests (KAT) as shown in (Schewe and Thalheim, 2005).

Kleene Algebras with Tests As the set of processes Ρ carries the structure of a Kleene algebra, the following conditions hold:

• + and ⋅ are associative, i.e. for all , ,p q r we must have ( ) ( )p q r p q r+ + = + + and

( ) ( )p qr pq r= ;

• + is commutative and idempotent with 0 as neutral element, i.e. for all ,p q we must have p q q p+ = + , p p p+ = and 0p p+ = ;

• 1 is a neutral element for ⋅ , i.e. for all p we must have 1 1p p p= = ;

• for all p we have 0 0 0p p= = ;

• ⋅ is distributive over + , i.e. for all , ,p q r we must have ( )p q r pq pr+ = + and

( )p q r pr qr+ = + ;

• *p q is the least solution x of q px x+ ≤ and *qp is the least solution of q xp x+ ≤ , using the partial order x y x y y≤ ≡ + = .

In addition, the Boolean conditions involved in the processes, i.e. the "tests", form a Boolean algebra. In order to exploit these equations for story space customisation we further take the preference equations into consideration, so we can start from equations in the following form:

preferences: An equation of the form ( )ϕ α β ϕα+ = expresses that a user conditionally prefers action α over action β , where the condition is expressed by ϕ . The special case

1ϕ = expresses an unconditional preference.

precondition: An equation of the form 0ϕα = (or equivalently α ϕα= ) expresses that the condition ϕ is a precondition for the action α .

postcondition: An equation of the form 0αϕ = (or equivalently α αϕ= ) expresses that the condition ϕ is a postcondition for the action α .

invariance: An equation of the form αϕ ϕα= , which is equivalent to ϕα αϕ= and to 0ϕαϕ ϕαϕ+ = , expresses that the condition ϕ (and so its negation ϕ ) is invariant under

the action α .

exclusion: An equation of the form 0ϕψ = expresses that the conditions ϕ and ψ exclude each other.

parallelism: An equation of the form αβ βα= expresses that the order of the actions α and β is irrelevant, hence they behave as if they were executed in parallel.

Then we can formalise the following optimisation task, in which the minimality request refers to the order ≤ on processes, i.e. elements of the KAT, that was defined above:

Given a process p K∈ that represents a plot of a story space, and a set Σ of equationson K that represents (among other constraints) user preferences and a postcondition ψ , we look for a minimal process p′ such that p pϕ ϕ′= holds.

That is, the resulting process p′ is a personalisation of p according to the user intention formalised by ψ . We illustrate this kind of propositional reasoning with KATs by the following example.

Example 5. Let us continue Example 3 and look at a user who is going to apply for a home loan. This can be expressed by the goal 10ϕ . Then we express application knowledge by the equations 10 11 0ϕ ϕ = (a user either applies for a home loan or a mortgage, not for both), 10 9 0ϕ ϕ = (a user applying for a home loan does not complete a mortgage application) and 6 7 0ϕ ϕ = (a user either selects a home loan or a mortgage, but not both).

Then we can simplify 10pϕ with the expression p from Example 3 step by step. First we get ( )10 11 10 10ϕ ϕ ϕ ϕ+ = , which can then be used for

( ) ( )( )( ) ( )

( )

** *6 8 8 9 10 11 12 8 7 8 8 14 15 16 11 17 12 18 19 12 18 9 10

* *6 8 8 9 10 11 12 8 10 7 8 8 14 15 16 11 17 12 18 19 12 18 9 10

6 8 8 9 10 11 12 8 10

1

1

1

ϕ α α α α α α ϕ ϕ α α α α α α α ϕ α α ϕ α ϕ ϕ

ϕ α α α α α α ϕ ϕ ϕ α α α α α α α ϕ α α ϕ α ϕ ϕ

ϕ α α α α α α ϕ ϕ

+ + =

+ + =

+

Then finally we get

( ) ( )( )( )( )

7 6 13 7 6 8 8 9 10 11 12 8 10

7 6 6 8 8 9 10 11 12 8 10

13 7 6 8 8 9 10 11 12 8 10

7 6 8 8 9 10 11 12 8 10

1

1

1

1

α ϕ α ϕ ϕ α α α α α α ϕ ϕ

α ϕ ϕ α α α α α α ϕ ϕ

α ϕ ϕ α α α α α α ϕ ϕ

α ϕ α α α α α α ϕ ϕ

+ + =

+

+ + =

+

This means that the story space can be simplified to

( ) ( ) ( )( )( )( )

*1 0 21 13 2 1 3 5 3 2 4 6 4 5

7 6 8 8 9 10 11 12 8 20 10

1 1 1

1

α ϕ α ϕ α ϕα α ϕ ϕ α α ϕ ϕ

α ϕ α α α α α α ϕ α ϕ

+ + + + +

+

This simply means that for a user who is looking for a home loan application the part of the story space that deals with mortgage application will be cut out.

Decidability and Complexity Let us now look at the personalisation problem in the light of the theory of KATs. Our formalisation in the previous section has led to an optimisation problem: we look for a minimal p p′ ≤ with | p pψ ψ′Σ = = . However, in the theory of KATs so far only completeness and the decidability of decision problems have been investigated. In other words, we only know about the decidability and complexity of problems of the form

| p qΣ = = .

However, if the expression p that describes the story space is *-free, there will be only finitely many expressions p′ with p p′ ≤ . In this case we can rephrase our problem by the following decision problem:

Given process ,p p K′∈ such that p represents a story space and p p′ ≤ holds, and a set Σ of equations on K that represents (among other constraints) user preferences and a postcondition Bψ ∈ , then decide, whether | p pψ ψ′Σ = = holds.

If p involves the *-operator, say we have a sub-expression *q , it may be the case that replacing *q by ( )21 nq q q+ + + + leads to some p′ , for which | p pψ ψ′Σ = = holds. In this case adopt the following pragmatic strategy:

1. Check whether for some n replacing q by ( )21 nq q q+ + + + leads to some p′ with | p pψ ψ′Σ = = .

2. If such an n exists, replace p by p′ , thus remove the occurrence of the *-operator.

3. If such an n does not exist, leave the *-operator in p , and consider only those

expressions p p′ ≤ , for which *q is replaced by ( )*q′ with q q′ ≤ .

While this strategy may miss out to find the optimal solution, it guarantees that we are able to reduce personalisation to a decision problem.

For the equational theory of KATs we know from (Kozen and Smith, 1996) that it is decidable, but PSPACE-complete. That is, we can decide in polynomial space, whether p q= can be derived from the axioms of KATs. However, the decision problem we are

dealing with is of the form | p qΣ = = with a set of equations Σ , i.e. in the Horn theory of KATs.

From (Kozen, 2002) we already know that such problems are undecidable in general. Even if we reduce ourselves to Kleene algebras instead of KATs, we already get 0

1Σ -completeness, i.e. the problem is in general recursively enumerable hard.

However, the problem we deal with is not the general decision problem for the Horn theory, as in our case Σ only contains equations that have a particular form. From (Kozen and Smith, 1996) we know that we can reduce equations of the form 0r = - these include equations obtained from pre- and postconditions, exclusion conditions, and invariance equations - to the equational theory. Instead of showing 0r p pψ ψ′= → = we can equivalently show p uru p uruψ ψ′+ = + , where u is a "universal" process. That is

( )*1 mu α α= + + , where the iα are all the atomic actions that are not tests - it is easy to see (and crucial for the proof) that p u≤ holds for all processes p . So we can remove all equations of the form 0r = from Σ and enrich the equation that is to be derived instead.

This leaves us with only two kinds of equations: those arising from conditional preferences and those arising from parallelism. Recall that the former ones have the form ( )ϕ α β ϕα+ = . Here we apply a little trick and introduce exclusive postcondition αψ

and βψ for α and β , respectively. Thus, we have the equations 0α βψ ψ = , 0αψ α =

and 0βψ β = . Then, we can replace the preference equation by ( ) 0βϕ α β ψ+ = . Hence,

we get again equations of the form 0r = , which can be used to reduce the problem to a decision problem in the equational theory of KATs, which is PSPACE-complete.

Database Issues: The Power of Media Types

Each user of a WIS has information needs that have to be satisfied by the system. These information needs are usually not known in advance. Part of the needed information may depend on other parts, on decisions made while navigating through the WIS, and even on the information provided by the user him/herself. That is, the information portfolio of a user depends on the path through the WIS, i.e. in our terminology on the story.

Media Types Therefore, assuming that there is a database for the data content of the WIS with database schema S , the information need on a scene s definitely accounts for a view sV over S . That is, we have another schema VS and a computable transformation from databases over S to databases over VS . Such a transformation is usually expressed by a query Vq .

This leads us to media types (Schewe and Thalheim, 2005). In principle, it is not important what kind of database we have as long as there exists a sufficiently powerful query mechanism that permits to define views. So assume to be given a database schema S , which itself is based on some underlying type system such as (using abstract syntax)

( ) 1 1| : , , : | .n nt b a t a t t= …

Here b represents an arbitrary collection of base types, e.g., BOOL for boolean values T and F , 1 for a single value 1, TEXT for text, PIC for images, MPIC for video data, CARD and INT for numbers, DATE for dates, ID for object identifiers, URL for URL-addresses, MAIL for e-mail-addresses, etc. The constructors ( )⋅ and ⋅ are used for records and finite sets.

For each type R S∈ we have a representing type Rt . In a S -database db each type R S∈ gives rise to a finite set ( )db R consisting of pairs ( ),i v with i of type ID and v of type Rt . Using this we may set up a powerful query language adapting a logic programming approach as in (Abiteboul and Kanellakis, 1989).

Thus, a query will be expressed as a set of rules (precisely: a sequence of such sets). Evaluating the rule body on a given database will result in bindings of variables, and the corresponding bindings for the head together with the creation of new identifiers for unbound variables results in an extension to the database. These extensions are iterated until a fixed point is reached.

In order to formalise this, assume to be given countable sets of variables tV for each type t . These sets are to be pairwise disjoint. Variables and constants of type t are terms of that type. In addition, each R S∈ is a term of type ( ) : , : Rident ID value t , and for each

variable ι of type ID (and URL , respectively) there is a term ι of some type ( )t ι . If

1, , kτ τ… are terms of type t , then 1, , kτ τ… is a term of type t , and if 1, , kτ τ… are

terms of type 1, , kt t… ,respectively, then ( )1 1: , , :k ka aτ τ… is a term of type

( )1 1: , , :k ka t a t… .

If 1 2,τ τ are terms of type t and t , respectively, then ( )1 2τ τ is a positive literal (also

called a fact) and ( )1 2τ τ¬ is a negative literal. If 1 2,τ τ are terms of the same type t , then

1 2τ τ= is a positive literal and 1 2τ τ≠ is a negative literal. A ground fact is a fact without variables.

A rule is an expression of the form 0 1, , kL L L← … with a fact 0L (called the head of the rule) and literals 1, , kL L… (called the body of the rule), such that each variable in 0L not appearing in the rule's body is of type ID or URL , respectively. A logic program is a sequence 1; ; lP P… , in which each iP is a set of rules.

Finally, a query Q on S is defined by a type Qt and a logic program QP such that a

variable ans of type ( ) : , : Qurl URL value t is used in QP . A boolean query can be

described as a query Q with type 1 . Alternatively, as we are not interested in creating a URL for the answer, we can simplify the approach above and consider a logic program, in which a variable ans of type BOOL = 1 appears.

A logic program 1; ; lP P… is evaluated sequentially. Each set of rules is evaluated by computing an in inflationary fixed point as in inflationary DATALOG. That is, start with the set of ground facts given by the S -database db . Whenever variables in the body of a rule can be bound in a way that all resulting ground literals are satisfied, then the head fact is used to add a new ground fact. Whenever variables in the head cannot be bound in a way that they match an existing ground fact, the variables of type ID and URL will be bound to new identifiers or URLs, respectively.

Example 6. Consider a query Q with type Qt defined as

(type : STRING, conditions : STRING, interest : STRING,amount : CARD, disagio : RATIONAL, interest_rate : RATIONAL,object : STRING, securities : (value : RATIONAL, object : STRING, type : STRING), customers : (income :(type : STRING, amount : CARD, frequency : STRING), obligations : (type : STRING, amount : CARD,frequency : STRING)))

Assume the database schema S contains (among others) the types Loan_Type , Customer , Mortgage , Owes_Mortgage , Security , Income , and Obligation with the following representing types:

Loan_Typet = (type : STRING, conditions : STRING,interest : STRING)

Customert = (customer_no : CARD, name : STRING, address : STRING,date_of_birth : DATE)

Mortgaget = (type : ID, mortgage no : CARD, amount : CARD,

disagio : RATIONAL, interest rate : RATIONAL,begin : DATE, end : DATE, object : STRING)

Owes_Mortgaget = (who : ID, what : ID, begin : DATE, end : DATE)

Securityt = (whose : ID, for : ID, value : CARD, object : STRING,

type : STRING)

Incomet = who : ID, type : STRING, amount : RATIONAL,frequency : RATIONAL, account : CARD

Obligationt = (who : ID, type : STRING, amount : RATIONAL,

frequency : RATIONAL, account : CARD)

Then the following logic program QP will produce an anonymised set of mortgages:

(1 m m l,M (t, c, i, a, d, p, o, S, C, i ) Mortgage i , (i ,n, a, d, p, b, e, o)), Loan Type(i (t, c, i));←

ˆ , , , , , , , , , .s c m 1 mS(v,o,t ) Security(i ,(i , i , v, o, t )),M (t c i a d p o S C i )′ ′←

ˆ , , , , , , , _ , , , , ,, , , , , , , , ,

c c o c m

1 m

C(I O i ) Customer(i (n n a db)) Owes Mortgage(i (i i b e))M (t c i a d p o S C i );

′←

1ˆˆ , , , , , , , , , , , , , , ,

, , , , , .m

m c

I(t a f) C(I O ic) M (t c i a d p o S C i )Income(i (i t a f ac))

′ ′ ←′ ′

ˆ ˆ, , , , , , , , , , , , , , ,, , , , ,

c 1 m

o c

O(t a f) C(I O i ) M (t c i a d p o S C i )Obligation(i (i t a f ac));

′ ′ ←′ ′

ˆ, , , , , , , , , , , , , , , , ,2 1 mM (t c i a d p o S D) M (t c i a d p o S C i );←

ˆ ˆ ˆˆ ˆ, , , , , , , , , , , , ,, , , , , , , , ,

c 2

1 m

D(I O) C(I O i ) M (t c i a d p o S D)M (t c i a d p o S C i );

←

ˆ ˆˆ, , , , , , , , , , , , , , , , , .Ans(u (t c i a d p o S D)) M2(t c i a d p o S D)←

This logic program consists of a sequence of six sets of rules. In a nutshell, the fixed-point computed by the first set will contain the additional relation 1M , which collects information about mortgages including conditions and interest (from Loan_Type ) and new identifiers S and C for the sets of securities and customers, respectively. The fixed-

point computed by the next set of rules contains details for each of these sets. Furthermore, for the customers it creates new identifiers for sets of incomes and sets of obligations, the details of which are computed by the third set of rules. The last three sets of rules replace the identifiers for the sets of securities and customers, respectively, by the corresponding sets.

An interaction type has a name M and consists of a content data type ( )cont M with the

extension that the place of a base type may be occupied by a pair :l M ′ with a label l and the name M ′ of an interaction type, a defining query Mq with type Mt , and a set of operations. Here Mt is the type arising from ( )cont M by substitution of URL for all pairs :l M ′ .

Finite sets C of interaction types define content schemata. Then an S -database db and the defining queries determine finite sets ( )db M of pairs ( ),u v with URLs u and values v of type Mt for each M C∈ . We use the notion pre-site for the extension of db to C . The pair ( ),u v will be called an interaction object in the pre-site db . A boolean query on S C∪ defines a condition ϕ .

A media type extends an interaction type M together in two ways: It adds adaptivity and hierarchies, which can be formalised by a cohesion pre-order M≺ (or a set of proximity values) and a set of hierarchical versions ( )H M , respectively. For our purposes here we concentrate on the operations that already come with the interaction types, for the extensions see (Schewe and Thalheim, 2005).

In general, an operation on a type R consists of a signature and a body. The signature consists of an operation name O , a set of input-parameter/type pairs :i itι and a set of output parameter/type pairs :j jo t′ . The body is an abstract program using the following constructs:

• 1 and 0 are abstract programs meaning skip and fail , respectively.

• An assignment :x exp= with a variable x and an expression of the same type as x is an abstract program. The possible expressions are defined by the type system. In addition, we permit expressions P with a logic program P , assuming that P

contains a variable ans . The expression P is interpreted as the result of the logic program bound to ans .

• If P , 1P and 2P are abstract programs, the same holds for the iteration *P , the choice

1 2P P+ and the sequence 1 2 1 2P P PP⋅ = .

• If P is an abstract program and ϕ is a condition, then the guarded program Pϕ and the postguarded program Pϕ are also abstract programs.

• If x is a variable and P is an abstract program, then the selection @ x P• is also an abstract program.

There are a few subtleties regarding variable scoping and restrictions to assignments that have to be taken into account for operations on interaction types (Schewe and Thalheim, 2005), but for our purposes here it is not relevant to discuss them.

With respect to the connection to the story space, the propositional conditions ϕ now have to be refined to conditions on S C∪ , while each action α on a scene s is refined by operations associated with the media type that supports s .

Correctness, Consistency and Personalisation With the introduction of media types to support scenes we can no longe rely on simple equational reasoning using KATs. Therefore we introduce a higher-order dynamic, where the order comes from the intrinsic use of the set constructor and the logic programs in queries. In fact, instead of using logic programs with a semantics defined by inflationary fixed-points, we could use directly higher-order logic enriched with a fixed-point operator.

As a consequence, we may consider a logic program P as a representative of a higher-order logical formula, say Pϕ . If P is used as the right-hand side of an assignment, then it will correspond to a term . PansϕI denoting the unique ans satisfying formula Pϕ That is, all conditions turn out to be formulae of a logic L, which happens to be a higher-order logic with an inflationary fixed-point operator. From the point of view of expressiveness the fixed-point operator is already subsumed by the order, but for convenience we do not emphasise this aspect here.

Furthermore, by adding terms of the form .xϕI with a formula ϕ and a variable x all assignments in operations are just "normal" assignments, where the left-hand side is a variable and the right-hand side is a term of L .

We now extend L to a dynamic logic by adding formulae of the form [ ]p ϕ with an

abstract program p and a formula ϕ of L . Informally, [ ]p ϕ means that after the successful execution of p the formula ϕ necessarily holds (Harel et al., 2000). In addition, we use the shortcut [ ]p pϕ ϕ≡ ¬ ¬ , so p ϕ means that after the successful execution of p it is possible that the formula ϕ holds.

Using our recursive definition of abstract programs the following rules apply to [ ]p ϕ for a complex abstract program p :

[ ]1 ϕ ϕ≡

[ ]0 0ϕ ≡

[ ] : /x t x tψ ψ= ≡ (substitute all free occurrences of x in ψ by t )

[ ] [ ][ ]1 2 1 2p p p pψ ψ≡

[ ] [ ] [ ]1 2 1 2p p p pψ ψ ψ+ ≡ ∧

*p ψ ≡ the weakest solution ϕ of [ ]pϕ ψ ϕ↔ ∧

[ ] [ ]p pϕ ψ ϕ ψ≡ →

[ ] [ ]( )p pϕ ψ ϕ ψ≡ →

[ ] [ ]@ .x p x pψ ψ• ≡ ∀

The equivalence for the iteration operator refers to the implication order, i.e. if |ϕ ψ= holds, then ψ is called weaker than ϕ . Further rules looking also at the structure of ψ are given in (Harel et al., 2000).

With these preparations we can rethink the reasoning about the story space. In the sequel we will discuss three applications of dynamic logic:

• We take a look at proof obligations for the operations that result from the specification of the story space.

• We take a look at proof obligations for the operations that arise from static and dynamic integrity constraints on the underlying database schema.

• We reconsider WIS personalisation in the light of dynamic logic as opposed to KATs.

Story Space Proof Obligations. Let p denote the KAT expression that represents the complete story space. If all conditions in p are replaced by conditions on the pre-site and all actions are replaced by the abstract programs defining the realising operations, we obtain an abstract program, which by abuse of notation shall still be denoted p .

As a WIS has a general purpose, this can be formalised by some post-condition ψ . Thus, [ ]p ψ describes the weakest condition, under which the purpose of the system can be achieved. If ϕ characterises a precondition that should be sufficient for the achievability of the WIS purpose, then we obtain [ ]pϕ ψ→ as a general story space proof obligation. In most cases we should expect 1ϕ ≡ .

Similarly, we may concentrate on fragments p′ of the story space expression of the form pϕ ψ , which corresponds to a Hoare triplet pϕ ψ (Hoare, 1969) and thus gives rise

to a special story space proof obligation [ ]pϕ ψ′→ .

Consistency Proof Obligations. A static constraint on the underlying database schema S is a condition ζ , in which the free variables are among the R S∈ . Such constraints give rise to the request that whenever an operation is started in a database satisfying ζ , then the database reached after successfully completing the execution of the operation, must necessarily satisfy ζ , too.

That is, for all operations p that are defined on a pre-site and all static constraints ζ we obtain a static consistency proof obligation [ ]pζ ζ→ .

A dynamic constraint on the underlying database schema 1, , nS R R= … is a condition

ζ , in which the free variables are among in S S ′∪ with 1, , nS R R′ ′ ′= … and each iR′ having the same type as iR . The additional variables iR′ are used to distinguish between S -databases db , on which an operation p is started, and S ′ -databases db′ resulting after p has been successfully executed.

Obviously, a dynamic constraint ξ has to be interpreted on a pair ,db db′ of databases. Following a standard approach to dynamic consistency (Schewe et al., 1992) we associate with ξ an abstract program

( ) 1 1 1@ , , : :n n np R R R R R Rξ ξ′ ′ ′ ′= • = =… … .

Then dynamic consistency of an operation p with respect to ξ means that p must "specialise" ( )p ξ , i.e. we require that ( ) [ ]p pξ ψ ϕ → for all conditions ψ on S .

Fortunately, this proof obligation can be rephrased using a renaming p′ of ( )p ξ given by

1 1 1 1 1 1@ , , / , , / : : :n n n n np R R R R R R R R R R Rξ′ ′ ′ ′′ ′′ ′′ ′′ ′ ′′ ′= • = = =… … … .

Then the dynamic consistency proof obligation for p with respect to ξ becomes

[ ] ( )( ) 1 1 1 1/ , , /n n n np p R R R R R R R R′ ′′ ′′ ′′ ′′= ∧ ∧ = … .

Personalisation Proof Obligations. The general approach to personalisation that was outlined in the previous section is still the same, i.e. we can assume a set Σ containing general constraints on S C∪ and specific constraints that refer to preferences of a particular user type. Examples of such preferences are the following:

An equation 1 2 1p p p+ = expresses an unconditional preference of operation 1p over 2p .

• An equation ( )1 2 1p p pϕ ϕ+ = expresses a conditional preference of operation 1p over 2p in case the condition ϕ is satisfied.

• Similarly, an equation ( )1 2 1p p p pp+ = expresses another conditional preference of operation 1p over 2p after the operation p .

• An equation 1 2 2 1 1 2p p p p p p+ = expresses a preference of order.

• An equation * *p pp= expresses that in case of an iteration of operation p it will be executed at least once.

Furthermore, personalisation assumes a postcondition χ that expresses the goals of the particular user. Then personalisation of story space p aims at a simpler story space p′ such that

[ ] [ ]p pχ χ′↔ holds.

Conclusion

In this paper we formalised user preferences, obligations and rights and indicated how this formalisation can be used to reason about the WIS specification. The work was done in the context of the Co-Design approach to WIS development (Schewe and Thalheim, 2005), but it seems to be not too dificult to adapt it to other methods such as ARANEUS (Atzeni et al., 1998), OOHDM (Schwabe and Rossi, 1998), WebML (Ceri et al., 2003), HERA (Houben et al., 2003) or WSDM (De Troyer and Leune, 1998).

However, the formalisation requires that the method contains models of users, user roles, actions and logical conditions that bring these models together. These models are a central component of Co-Design, but they are only partially available in other methods. That is, the coupling of the work presented in this paper with the other mentioned WIS development methods requires that these methods first take up directly or in a modified form the concept of storyboarding from the Co-Design approach.

We demonstrated that capturing preferences, obligations and rights can be achieved on the basis of various logics. For the personalisation of WISs according to preferences and goals we adopted propositional reasoning with Kleene algebras with tests, which at the end amounts to a term rewriting approach. From this a new challenge arises that may allow us to dispense with explicitly modelling user types. In fact, the main purpose of user types is to associate preference rules with them, but these preferences may depend only on some of the characteristics of a user type. Thus, it may be advantageous to use conditional preference rules instead, and conditional term rewriting may turn out to be the key to personalisation on a propositional storyboard level. This path of research will be explored in the future.

We also demonstrated that obligations and rights can be formalised in (propositional) deontic logic, but we were not yet able to take this approach beyond the first step of just capturing deontic constraints. For our future research we plan to investigate more deeply the application of deontic logic for reasoning purposes on WIS specifications.

The major challenge in dealing with preferences, obligations and rights, however, is the coupling of the approach with the detailed conceptual model of WISs that is given by media types, which are extended views on some underlying database schema. In logical terms this basically means that we leave the safe grounds of propositional reasoning, as actions are no longer atomic but refined by abstract programs, while propositional conditions are refined by conditions that can be evaluated on underlying databases. In this paper we did not go further than indicating the use of higher-order dynamic logic to obtain proof obligations. In the same way we should expect proof obligations in higher-order deontic logic.

Thus, in dealing with preferences, obligations and rights we shift the focus of WISs from just conceptual modelling of particular data-intensive application systems to knowledge-intensive systems that require reasoning techniques in complex logics to be explored.

References

Abiteboul, S. and Kanellakis, P. (1989). Object identity as a query language primitive. In Proceedings SIGMOD 1989.

Antoniou, G., Billington, D., Governatori, G., and Maher, M. (2001). Representation results for defeasible logic. ACM Transactions on Computational Logic, 2(2):255-287.

Atzeni, P., Gupta, A., and Sarawagi, S. (1998). Design and maintenance of data-intensive websites. In Proceeding EDBT'98, volume 1377 of LNCS, pages 436-450. Springer-Verlag, Berlin.

Broersen, J., Wieringa, R., and Meyer, J.-J. C. (2002). A fixed-point characterization of a deontic logic of regular action. Fundamenta Informaticae, 49(4):107-128.

Ceri, S., Fraternali, P., Bongio, A., Brambilla, M., Comai, S., and Matera, M. (2003). Designing Data-Intensive Web Applications. Morgan Kaufmann, San Francisco.

De Troyer, O. and Leune, C. (1998). WSDM: A user-centered design method for web sites. In Computer Networks and ISDN Systems - Proceedings of the 7th International WWW Conference, pages 85-94. Elsevier.

Dignum, F., Meyer, J.-J. C., Wieringa, R., and Kuiper, R. (1996). A modal approach to intentions, commitments and obligations: Intention plus commitment yields obligation. In Brown, M. A. and Carmo, J., editors, DEON 1996, Workshops in Computing, pages 80-97. Springer.

Elgesem, D. (1997). The modal logic of agency. Nordic Journal of Philosophical Logic, 2:1-48. Feyer, T., Schewe, K.-D., and Thalheim, B. (1998). Conceptual modelling and development of information services. In Ling, T. and Ram, S., editors, Conceptual Modeling - ER'98, volume 1507 of LNCS, pages 7-20. Springer-Verlag, Berlin.

Harel, D., Kozen, D., and Tiuryn, J. (2000). Dynamic Logic. The MIT Press, Cambridge (MA), USA.

Hoare, C. A. R. (1969). An axiomatic basis for computer programming. Communications of the ACM, 12(10):576-580.

Houben, G.-J., Barna, P., Frasincar, F., and Vdovjak, R. (2003). HERA: Development of semantic web information systems. In Third International Conference on Web Engineering - ICWE 2003, volume 2722 of LNCS, pages 529-538. Springer-Verlag.

Kaschek, R., Schewe, K.-D., Wallace, C., and Matthews, C. (2004). Story boarding for web information systems. In Taniar, D. and Rahayu, W., editors, Web Information Systems, pages 1-33. IDEA Group.

Kozen, D. (1997). Kleene algebra with tests. ACM Transactions on Programming Languages and Systems, 19(3):427-443.

Kozen, D. (1999). On Hoare logic and Kleene algebra with tests. In Logic in Computer Science, pages 167-172.

Kozen, D. (2002). On the complexity of reasoning in Kleene algebra. Information and Computation, 179(2):152-162.

Kozen, D. and Smith, F. (1996). Kleene algebra with tests: Completeness and decidability. In Computer Science Logic, pages 244-259.

Nute, D. (1997). Defeasible Deontic Logic. Kluwer Academic Publishers. Eiter, T. and Subrahmanian, V. S. (1999). Deontic action programs. In Polle, T., Ripke, T., and Schewe, K.-D., editors, Fundamentals of Information Systems, pages 37-54. Kluwer Academic Publishers.

Schewe, K.-D. (2004). The power of media types. In Proceedings WISE 2004: Web Information Systems Engineering, LNCS. Springer-Verlag.

Schewe, K.-D., Kaschek, R., Wallace, C., and Matthews, C. (2005a). Emphasizing the communication aspects for the successful development of electronic business systems. Information Systems and E-Business Management, 3(1):71-100.

Schewe, K.-D. and Thalheim, B. (2004). Reasoning about web information systems using story algebras. In Proceedings ADBIS 2004, Budapest, Hungary.

Schewe, K.-D. and Thalheim, B. (2005). Conceptual modelling of web information systems. Data and Knowledge Engineering, 54(2):147-188.

Schewe, K.-D., Thalheim, B., Binemann-Zdanowicz, A., Kaschek, R., Kuss, T., and Tschiedel, B. (2005b). A conceptual view of electronic learning systems. Education and Information Technologies, 10(1-2):83-110.

Schewe, K.-D., Thalheim, B., Schmidt, J. W., and Wetzel, I. (1992). Integrity enforcement in object-oriented databases. In Modelling Database Dynamics, Workshops in Computing, pages 174-195. Springer-Verlag, Berlin.

Schwabe, D. and Rossi, G. (1998). An object oriented approach to web-based application design. TAPOS, 4(4):207-225.

Thalheim, B. (2000). Entity-Relationship Modeling: Foundations of Database Technology. Springer-Verlag.

Thalheim, B. and Düsterhöft, A. (2001). SiteLang: Conceptual modeling of internet sites. In Kunii, H. S., Jajodia, S., and Sølvberg, A., editors, Conceptual Modeling - ER 2001, volume 2224 of LNCS, pages 179-192. Springer-Verlag, Berlin.

Wieringa, R. and Meyer, J.-J. C. (1991). Actor-oriented specification of deontic integrity constraints. In Thalheim, B., Demetrovics, J., and Gerhardt, H.-D., editors, Mathematical Fundamentals of Database Systems (MFDBS 1991), volume 495 of LNCS, pages 89-103. Springer-Verlag.

Wieringa, R. and Meyer, J.-J. C. (1993). Actors, actions, and initiative in normative system specification. Annals of Mathematics and Artificial Intelligence, 7(1-4):289-346.

View Integration and Cooperation in Databases,

Data Warehouses and Web Information Systems?

Hui Ma1, Klaus-Dieter Schewe1, Bernhard Thalheim2, Jane Zhao1

1 Massey University, Department of Information Systems &Information Science Research Centre

Private Bag 11 222, Palmerston North, New Zealand[h.ma|k.d.schewe|j.zhao]@massey.ac.nz2 Christian Albrechts University Kiel

Department of Computer Science and Applied MathematicsOlshausenstr. 40, D-24098 Kiel, Germany

[email protected]

Abstract. View integration aims at replacing a set of existing views bya single new one in such a way that with respect to information capacitythe new view dominates or is equivalent to the old ones. Therefore, in thisarticle we first investigate a theory of schema equivalence and dominancefor the higher-order Entity-Relationship model (HERM) based on thenotion of computable queries. We then develop formal transformationrules for schema integration that are embedded in a pragmatic methodtelling how they should be applied for integration.

We then apply the approach to views, which occur as the basic con-stituents for user interfaces as formalised by the notion of dialogue type.In two follow-on steps we apply the rule-based view integration tech-nique to data warehouses and web information systems. In the case ofdata warehouses the fundamental idea is the separation of input from op-erational databases and output to on-line analytical processing (OLAP)systems. Both the extraction of data from the operational databases andthe definition of the data-marts for OLAP can be formulated by views.

In the case of web information systems, views form the core of mediatypes, which provide abstract means for describing content, functionality,context and adaptivity to user preferences and intentions, end-devices,and channel limitations. In this case the queries defining the views mustbe highly expressive, as they must involve the creation of abstract iden-tifiers, complex values and links. We extend the transformation rules tocope with these requirements.

View cooperation provides an alternative to view integration in whichthe integrated view is only virtual. That is the constituting views arekept and exchange functions are designed to provide the same function-ality as if the views were integrated.

Keywords. view integration, schema equivalence, data warehouses, webinformation systems, view cooperation

? The work in this paper was supported by FRST/NERF grant MAUX0025 “DIMO –Distributed Multi-Level Object Bases” and MU/ABRF grants 57413 “Foundationsof Conceptual Modelling” and 57501 “Distributed Data Warehouses”.

2 H. Ma, K.-D. Schewe, B. Thalheim, J. Zhao

1 Introduction

Database schema integration is an old issue that has attracted a lot of research[12–14, 16, 30]. The starting point for schema integration is a set of schemataover some data models. Usually the focus is on two schemata over the samedata model. If the underlying data models differ, then we may assume somepreprocessing transforming both schemata – or one of them, if this is sufficient –into an almost equivalent schema over a data model with higher expressiveness.Then schema integration aims at replacing the given schemata by a single newone in such a way that the new schema dominates or is equivalent to the oldones.

A view on some database schema consists of another schema called the targetschema, and a defining query, which maps instances of the source schema toinstances of the target schema. If we integrate the target schemata of views wetalk of view integration [3, 29, 30]. In this case we obtain embeddings for eachtarget schema into the new schema. If these embeddings are coupled with thedefining queries for the given views we obtain a new defining query, i.e. we obtainnot only an integrated target schema, but an integrated view.

So the first thing we need is a theory of schema equivalence and dominance.Roughly, we may say that two schemata are equivalent, if they have the sameinformation capacity, i.e. we may store the same information in both schemata.A schema dominates another one, if it has a larger information capacity. Vari-ous formal definitions for equivalence and dominance have been given [9, 19, 30]and compared in [15, 16]. Here we extend this work and introduce novel defini-tions for equivalence and dominance based on computable queries [5, 34], i.e. webase the transformation functions on the most general notion of query, but wediscard total arbitrariness, as computable queries must respect isomorphisms.We compare the new notions with the ones defined in [9, 19, 30]. We base thiscomparison on the higher-order Entity-Relationship model (HERM) [30].

On this basis we then reconsider schema integration following the frameworkin [15, 16]. In a nutshell, we first “clean” the given schemata by removing nameconflicts, synonyms and homonyms, then we add inter-schema constraints, whichleads to a single constrained schema, which is just the union of the given ones. Tothis schema we then apply formal equivalence transformation or augmentationrules, which will finally take us to an integrated schema that is either equivalentto the union of the given ones or dominates this.

One group of rules addresses the restructuring of the complex attributes,entity types, relationship types and clusters. Another group of rules considersthe shifting of attributes over hierarchies and paths. A third group of rules dealswith selected integrity constraints such as keys, functional, inclusion and joindependencies, cardinality constraints and path constraints. A fourth group ofrules is devoted to aggregation, decomposition, specialisation and generalisation.

The transformation rules can be used as well for view cooperation [15, 28, 30],which provides an alternative to view integration in which the integrated viewis only virtual. That is the constituting views are kept and exchange functionsare designed to provide the same functionality as if the views were integrated.

View Integration and Cooperation 3

Views are important for user interfaces. In [21] an integrated concept of di-

alogue type was developed, which combines views with operations defined onthem. As conceptual interface specifications are a viable source during the sys-tems development process, the problem of view integration comes up naturally.With respect to the transformation rules, we now need an extension that dealswith the operations.

Data Warehouses are data-intensive systems that are used for analyticaltasks in businesses such as analysing sales/profits statistics, cost/benefit relationstatistics, customer preferences statistics, etc. The term used for these tasks is“on-line analytical processing” (OLAP) [33] in order to distinguish them fromoperational data-intensive systems, for which the term “on-line transaction pro-cessing” (OLTP) has become common. The idea of a data warehouse [11] is toextract data from operational databases and to store them separately. Thus, afirst problem in data warehouse design is to integrate views from various sourcedatabases. This point of view of data warehouse design as a view integrationproblem has been strongly promoted in [12, 32, 36]. In fact, there is another re-lated problem in here, the support of OLAP applications by materialised views,which in their totality reflect the data warehouse. In this sense data warehousesalso involve a view design problem.

In [17] dialogue types have been applied to data warehouses and OLAPsystems. The principle result states that OLAP functionality corresponds tooperations on views over the data warehouse. So we may apply our extendedtransformation rules to this problem. In fact, the main idea of data warehousesimplies a separation of input from operational databases and output to viewsthat contain the data for particular OLAP tasks. This implies a three-layerarchitecture for data warehouses and OLAP systems [38], which is the basis ofa formal design approach for such systems [26, 37].

In the field of web information systems (WISs) the importance of views iscommonly accepted [2, 4, 24, 25]. In [7, 6] the notion of media type has been in-troduced. A media type is an extended view over some underlying database.However, different to the approaches in [2, 4] the defining query already con-structs the navigation structure. Furthermore, media types are prepared for dy-namic WISs [18] by adding operations, and for adaptivity by adding cohesionpreorders. As a consequence, transformation rules for the purpose of media typeintegration have to extend the view integration rules in a way that cohesion iscovered as well. In this article we will develop these extensions.

Outline. We start in Section 2 with a look at published work on the topic of thisarticle. In Section 3 we describe the basics of HERM emphasising our approachto schema equivalence and dominance. Section 4 is devoted to the process ofschema and view integration. We describe first the process in general followedby a presentation of the transformation rules for this process. We also showhow these rules can be used for view cooperation instead of integration. Section5 applies the integration framework to data warehouses and OLAP systems.We emphasise the particular case of view integration and indicate additional


rules dealing with the adaptation of dialogue operations. In Section 6 we brieflypresent media types, i.e. other extended views that are used for web informationsystems. We particularly focus on the aspect of adaptivity for which we discusscohesion. This is followed by an extension to the transformation rules dealingwith the implications of view integration to cohesion. We conclude with a shortsummary and discussion of further research directions.

2 Related Work

The work on view integration in [13, 14, 29] is based on the Entity-Relationshipmodel. Larson et al. [14] consider containment, equivalence and overlap relationsbetween attributes and types that are defined by looking at “real world objects”.Equivalence between types gives rise to their integration, containment definesa hierarchy with one supertype and one subtype, and overlapping gives rise tonew common supertype. The work by Spaccapietra and Parent [29] considersalso relationships, paths and disjointness relations between types. The work byKoh et al. [13] provides additional restructuring rules for the addition or removalof attributes, generalisation and specialisation, and the introduction of surrogateattributes for types.

The work by Biskup and Convent in [3] is based on the relational data modelwith functional, inclusion and exclusion dependencies. The method is based onthe definition of integration conditions, which can be equality, containment, dis-jointness or selection conditions. Transformations are applied aiming at the elim-ination of disturbing integration conditions. In the same way as our work it isbased on a solid theory. On the other hand, it has never been applied to largesystems in practice. The approach by Sciore et al. in [28] investigates conver-sion functions on the basis of contexts added to values. These contexts provideproperties to enable the semantic comparability of values.

The work by Lehmann and Schewe [15, 16] assumes that the given schemataare defined on the basis of the higher-order Entity-Relationship model (HERM)[30] which is known to provide enough expressiveness such that schemata existingin practice can be easily represented in HERM. The work relies on the notionsof equivalence and dominance as defined for HERM in [30].

In [15, 16] these notions of equivalence and dominance are also comparedwith those defined by Hull [9] and Qian [19]. Basically, the four different notionsof schema dominance introduced by Hull differ by the way the transformationfunctions are defined. In the simplest case (calculus dominance) they correspondto calculus queries, whereas in the most general case (absolute dominance) thereare no restrictions at all. In fact, taking computable queries will remove the ar-bitrariness from absolute dominance that has been criticised in [19] while takinginto account the most general form of queries [5, 34].

The design of data warehouses and OLAP applications has been intensivelystudied. Widom [36] and Theodoratos [32] emphasise that data warehouse designis mainly a view integration problem, Whereas Lewerenz et al. [17], Thomson


[33], and Zhao and Schewe [26, 37, 38] also take the OLAP functionality intoaccount.

The design and development of WISs has attracted a lot of attention. TheARANEUS framework in [2] emphasises that conceptual modelling of web infor-mation systems should approach a problem triplet consisting of content, naviga-tion and presentation. This leads to modelling databases, hypertext structuresand page layout. OOHDM [27] is quite similar to ARANEUS, but its originsare not in the area of databases but in hypertext and it explicitly refers toan object oriented approach. OOHDM emphasises an object layer, hypermediacomponents, i.e. links, and an interface layer. The work in [8] also starts from hy-pertext design. The work introduces “authoring in the large”, i.e., the conceptualmodelling of information elements and navigation, and uses this to categorise dif-ferent types of links. Another similar approach is WebML [4], which emphasisesa multi-level architecture for the data-driven generation of WIS, thus takes theview aspect into account. Furthermore, it emphasises structures, derivation andcomposition, i.e. views, navigation and presentation, thus addresses the sameproblem triplet as the ARANEUS framework.

Our own work on WIS design combines the usage-oriented storyboardingmethodology [22, 23, 31] and the content- and functionality-oriented theory ofmedia types [6, 20, 24], which are embedded in an integrated co-design method-ology based on an abstraction layer model [25].

3 Schemata, Equivalence and Dominance

As we will base our presentation on the higher-order Entity-Relationship model(HERM) [30], we start with a brief review of the model as far as it is importantfor our purposes here. In particular, we focus on algebraic and logical querylanguages for HERM. These will be needed to address the important issue ofdefining schema dominance and equivalence in a way that the expressiveness issufficient for the integration of extended views as needed for data warehousesand web information systems. The basic case dealing only with plain views overHERM schemata, i.e. ignoring the extensions by operations, adaptivity, etc. wasalready handled in [15, 16].

3.1 HERM

The major extensions of the HERM compared with the flat ER model con-cern nested attribute structures, higher-order relationship types and clusters, asophisticated language of integrity constraints, operations, dialogues and theirembedding in development methods. Here we only review some of the structuralaspects.

In the following let A denote some set of simple attributes . Each simpleattribute A ∈ A is associated with a base domain dom(A), which is some fixedcountable set of values. The values themselves are of no particular interest.


In HERM it is permitted to define nested attributes. For this take a setL of labels with the only restriction that labels must be different from simpleattributes, i.e. L ∩ A = ∅.

Definition 3.1. A nested attribute is either a simple attribute, the null at-tribute ⊥, a tuple attribute X(A1, . . . , An) with pairwise different nested at-tributes Ai and a label X ∈ L or a set attribute XA with a nested attributeA and a label X ∈ L. Let NA denote the set of all nested attributes.

We extend dom to nested attributes in the standard way, i.e. a tuple attributewill be associated with a tuple type, a set attribute with a set type, and the nullattribute with dom(⊥) = 1l, where 1l is the trivial domain with only one value.

In principle we could also permit other constructors than tuple and set con-structors, e.g. constructors 〈·〉 and [·] for multisets and lists. This would, however,only complicate our presentation here without leading to additional insights. Wetherefore disregard these other constructors.

On nested attributes we have a partial order ≥ defined as follows.

Definition 3.2. ≥ is the smallest partial order on NA with

– A ≥ ⊥ for all A ∈ NA,– XA ≥ XA′ ⇔ A ≥ A′ and– X(A1, . . . , An) ≥ X(A′

1, . . . , A′m)⇔

∧

1≤i≤m

Ai ≥ A′i.

A generalised subset of a set F ⊆ NA of nested attributes is a set G ⊆ NAof nested attributes such that for each A′ ∈ G there is some A ∈ F with A ≥ A′.

It is easy to see that X ≥ X ′ gives rise to a canonical projection πXX′ :

dom(X)→ dom(X ′).Let us now define the entity and relationship types and clusters in HERM

using the following compact definition.

Definition 3.3. A level-k-type R consists of a set comp(R) = r1 : R1, . . . , rn :Rn of labelled components with pairwise different labels ri, a set attr(R) =A1, . . . , Am of nested attributes and a key key(R). Each component Ri is atype or cluster of a level at most k − 1, but at least one of the Ri must belevel-(k − 1)-type or -cluster.

For the key we have key(R) = comp ′(R)∪attr ′(R) with comp′(R) ⊆ comp(R)and a generalised subset attr ′(R) of the set of attributes.

A level-k-cluster is C = R1 ⊕ · · · ⊕ Rn with pairwise different componentsRi, each of which is a type of a level at most k. At least one of the Ri must belevel-k-type.

The labels ri used in components are called roles . Roles can be omitted incase the components are pairwise different. A level-0-type E – here the definitionimplies comp(E) = ∅ – is usually called an entity type, a level-k-type R withk > 0 is called a relationship type.


A HERM schema is a finite set S of entity types, relationship types andclusters together with a set Σ of integrity constraints defined on S. We write(S, Σ) for a schema, or simply S, if Σ = ∅.

Note that the notion of level has only been introduced to exclude cycles inschemata. Besides this it has no other meaning. Conversely, if there are no cyclesin a schema, then there is a straightforward way to assign levels to the types andclusters in the schema such that the conditions in Definition 3.3 are satisfied.

Security Mortgage Loan_Type Personal_Loan type type for

Customer

w h

o s

e

Owes

Loan

who what

Income Obligation Account Account_Record a

w h

o who l n

account amount type

frequency

customer_no

name

address

date_of_birth

object

value

type

account

type

amount

frequency

begin

end

mortgage_no

amount disagio

begin

interest_rate

object end

type conditions

interest loan_no amount

begin

end

interest_rate terms_of_payment

account_no

balance

record_no

amount

type

date

Fig. 1. HERM diagram for loan application

Example 3.1. The following type definitions define a HERM schema for a loanapplication as it might be used by some bank:

Loan Type = (∅, type, conditions, interest , type )

Customer = (∅, customer no, name, address, date of birth , customer no )

Personal Loan = ( type : Loan Type , loan no, amount,interest rate, begin, end, terms of payment , loan no )

Mortgage = ( type : Loan Type , mortgage no, amount, disagio,interest rate, begin, end, object , mortgage no )

Loan = Home Loan ⊕ Mortgage

Account = ( ln : Loan , account no, balance , account no )

Account Record = ( a : Account , record no, type, amount,date , a : Account, record no )

Owes = ( who : Customer, what : Loan , begin, end , who : Customer, what : Loan, begin )


Security = ( whose : Customer, for : Mortgage , value, object,type , whose : Customer, for : Mortgage, object )

Income = ( who : Customer , type, amount, frequency, account , who : Customer, account )

Obligation = ( who : Customer , type, amount, frequency,account , who : Customer, account )

For this it is easy to see that the types Customer and Loan Type areon level 0, because they do not have components. Level-1-types are Income,Obligation, Mortgage and Personal Loan, because all their componentsare on level 0. Consequently, the cluster Loan ist a level-1-cluster. The typesOwes, Security and Account are then level-2-types, because all componentsare on level 1 or below, and finally, Account Record is a level-3-type.

Figure 1 provides a graphical representation of the schema in Example 3.1.We call this a HERM diagram. According to the common convention in Entity-Relationship diagrams we represented types on level 0 by rectangles and typeson higher levels by diamonds. Clusters are represented by ⊕. We use directededges from a relationship type to each of its components, and from clustersto their components, and undirected edges between types and their attributes.Roles names are attached to the directed edges. Keys are marked by underliningattributes and marking the edges that correspond to components in the key bysome dot.

As each HERM schema can be represented by such a HERM diagram, i.e. bya graph, we can apply all graph-theoretic notions. In particular, when we talk ofpaths in a HERM schema, we mean a path in the underlying undirected graphthat results from ignoring the orientation of edges in the HERM diagram.

In order to define the semantics of HERM schemata we concentrate onidentifier-semantics, also known as pointer-semantics. For this assume a count-able set ID of identifiers with ID ∩ D = ∅ for all domains D used for simpleattributes. Furthermore, we associate with each type R ∈ S a representing at-

tribute

XR = R(Xr1, . . . , Xrn

, A1, . . . , An)

with new simple attributes Xrifor each role ri and dom(Xri

) = ID, as wellas a key attribute

KR = R(Xri1, . . . , Xri`

, A′1, . . . , A

′m)

for key(R) = ri1 : Ri1 , . . . , ri`: Ri`

, A′1, . . . , A

′m. Obviously, we have XR ≥

KR.

Definition 3.4. An instance of a HERM schema (S, Σ) is a family db(R)R∈S

of finite sets. For each type R the set db(R) consists of pairs (i, v) with i ∈ ID

and v ∈ dom(XR) subject to the following conditions:

– Identifiers are globally unique, i.e. whenever (i, v1) ∈ db(R1) and (i, v2) ∈db(R2) hold, we must have R1 = R2 and v1 = v2.


– Key values are locally unique, i.e. whenever (i1, v1), (i2, v2) ∈ db(R) holdwith πXR

KR(v1) = πXR

KR(v2), then we must have i1 = i2.

– Roles are always defined, i.e. whenever (i, v) ∈ db(R) and πXRR(Xrij)(v) =

i′ for rij: Rij

∈ comp(R), then (i′, v′) ∈ db(Rij) for some v′ ∈ dom(XRij

).– The integrity constraints in Σ are satisfied.

For each cluster C = R1 ⊕ · · · ⊕Rk the set db(C) is the disjoint union of thesets db(Ri) (i = 1, . . . , k).

We write inst(S, Σ) for the set of all instances over (S, Σ).

3.2 Query Languages for HERM

As for the relational data model, basic queries against a HERM schema canbe formulated both in an algebraic and a logical way. We will extend both thesimple HERM algebra and the HERM calculus in a way that we can expressmore queries, but let us start with first-order queries.

Definition 3.5. The HERM algebra H provides the operations σϕ (selection)with a selection formula ϕ, πA1,...,Am

(projection) with a generalised subsetA1, . . . , Am, %f (renaming) with a renaming function f , ./G (join) with a com-mon generalised subset G, ∪ (union), − (difference), νX:A1,...,An

with attributesA1, . . . , An (nest), and µA (unnest) with a set attribute A.

As the details of these operations are not much different from the relationaldata model, we omit the details and refer to [30].

However, in order to make the HERM algebra operational for our purposeshere, we need a little extension:

– We permit new type names R to be added to S, and use assignments R :=exp with a HERM algebra expression exp. Then applying such a query toan instance of (S, Σ) results in an instance over (S ∪ R, Σ). The type orcluster definition for R is implicitly determined by the expression exp.

– In order to satisfy the global uniqueness of identifiers, such an assignmentsinvolve the non-deterministic creation of identifiers in ID for the pairs (i, v)in the added db(R). Such identifier creation has been investigated thoroughlyin [35].

– While sequences of assignments only extend the schema, we also allow todrop types or clusters.

In summary, a HERM algebra program P has the form C1; . . . ;Cr \S ′, whereeach Ci is an assignment, say Ri : +expi that extends the schema by Ri and theinstance by db(Ri), while S ′ is a subschema of S ∪R1, . . . , Rr. Thus, P definesa mapping q(P ) taking instances over (S, Σ) to instances over (S ′, Σ′), thoughthe set Σ′ of constraints is left implicit.


The algebra may be further extended with WHILE, in which case we talk ofthe extended HERM algebra Hext. In this case we add constructs of the form

WHILE change DO C1; . . . ;Cr END.

We obtain a logical perspective from the following simple observation. Eachtype R ∈ S – or more precisely, its representing attribute XR – defines a vari-able in a higher-order logic. The order depends on the depth of nesting of theattributes in attr(R). For instance, if the set constructor is not used, we obtain afirst-order variable. In fact, we obtain a type for each such variable, where typescorrespond to nested attributes. Thus, a schema defines a signature, and eachinstance defines a finite structure for this signature.

There are a few subtleties to be aware of. First, for clusters we have to allowparticular union variables to cope with the requirement to have disjoint unions.Second, we have to define first the logic and then permit only those structuresthat are in fact models for the theory defined by the restrictions in Definition3.4.

Now use further variables and constants of any available type and defineatoms as follows:

– A predicative atom has the form X(t1, . . . , tn) with a higher-order variableX and terms, i.e. variables or constants, t1, . . . , tn such that the types of theti and the one of X match properly.

– An equational atom has the form t1 = t2 with terms of the same type orof different types, where one is a cluster and the other one is one of itscomponents.

Finally, use the usual connectives ∧, ∨, →, ∃ and ∀ to define HERM logic.Then the concept of free and bound variables is defined as usual. We write fr(ϕ)for the set of free variables of a formula ϕ.

Definition 3.6. A HERM calculus query has the form X(x0, . . . , xn) : ϕ with aformula ϕ of HERM logic such that fr(ϕ) ⊆ S∪x1, . . . , xn and x1, . . . , xn ⊆fr(ϕ).

Obviously, we may interpret a formula ϕ provided we are given a value as-signment σ(xi) for all the variables x1, . . . , xn and an instance over (S, Σ). Ifaccording to this interpretation the formula ϕ is interpreted as true, we obtain atuple (σ(x0), . . . , σ(xn)) with a new identifier σ(x0) ∈ ID . The result is the setof all such tuples, and will be bound to variable X .

It can be shown that such HERM calculus queries express exactly the sameas HERM algebra queries with non-deterministic identifier creation and assign-ments to new type variables. Using sequences and a fixed-point constructionyields the same expressiveness as the extended HERM algebra. We use the termextended HERM calculus for this approach to query languages.

Let us finally extend the discussion on queries to computable queries in thespirit of [5]. Computable queries are defined on a semantic rather than a syn-tactic level. A query language that can express all computable queries is called


complete, but this has to be verified. It is known that the calculus and algebraqueries defined so far (even in their extended form) are not complete.

Roughly speaking, a computable query is a query that commutes with isomor-phisms. So we have to define a concept of isomorphism for HERM instances. Forthis consider bijections ψA : dom(A)→ dom(A) for each simple attribute A ∈ Aand ψID : ID → ID. We call this family Ψ = ψAA∈A∪ID a t-isomorphism.Obviously, we may extend Ψ to all nested attributes defining

ψX(A1,...,An)(v1, . . . , vn) = (ψA1(v1), . . . , ψAn

(vn))

and

ψXA(v1, . . . , vn) = ψA(v1), . . . , ψA(vn).

In particular, a t-isomorphism Ψ induces a mapping ΨS : inst(S, Σ) →inst(S, Σ).

Definition 3.7. Two instances db1 and db2 over (S, Σ) are called isomorphic

(notation: db1 ' db2) iff there exists a t-isomorphism Ψ with ΨS(db1) = db2.A computable query on a database schema (S, Σ) with output schema (S ′, Σ′)

is a partial recursive function q : inst(S, Σ)→ inst(S ′, Σ′) mapping isomorphicdatabases to isomorphic databases, i.e.,

db1 ' db2 ∧ q(db1) ↓ ⇒ q(db2) ↓ ∧ q(db1) ' q(db2),

where q(db1) ↓ means that the partial recursive function q is defined on db1.

3.3 Schema Dominance and Equivalence

As already stated schema and view integration requires precise notions for schemadominance and equivalence, which we will introduce now.

Definition 3.8. A HERM schema (S ′, Σ′) dominates another HERM schema(S, Σ) by means of the language L (notation: (S, Σ) vL (S ′, Σ′)) iff there aremappings f : inst(S, Σ) → inst(S ′, Σ′) and g : inst(S ′, Σ′) → inst(S, Σ) bothexpressed in L such that the composition g f is the identity.

If we have (S, Σ) vL (S ′, Σ′) as well as (S ′, Σ′) vL (S, Σ), we say that thetwo schemata are equivalent with respect to L (notation: (S, Σ) ∼=L (S ′, Σ′)).

According to our discussion of HERM query languages in the previous sub-section we obtain three different notions of dominance and equivalence. vH and∼=H refer to the use of the HERM algebra or equivalently the HERM calcu-lus as the language, in which the transformations f and g are to be expressed.Analogously, vHext

and ∼=Hextrefer to the use of the extended HERM algebra

or the extended HERM calculus. Finally, vcomp and ∼=comp refer to the use ofcomputable queries. According to these choices we talk of HERM dominance,extended HERM dominance and computable dominance, respectively.


For completeness, let us mention a fourth alternative. If we do not imposeany restrictions on the language L, i.e. f is any injective and g any surjectivemapping, then we obtain absolute dominance vabs and absolute equivalence ∼=abs.In the following sections we will always refer to vcomp and ∼=comp and thereforedrop the index and simply write v for dominance and ∼= for equivalence.

vgen

vint

vH

vHext

vcomp

vabs

vcalc

vADT

Fig. 2. Relationship between schema dominance notions

In the literature several other notions of schema dominance and equivalencehave been introduced. Hull in [9] introduces four different notions on the basis ofthe relational data model. In the case of calculus dominance vcalc the mappingsf and g must be defined by safe relational calculus or equivalently the relationalalgebra. In the case of generic dominance vgen the mappings f and g mustbe generic in the sense that they commute with permutations of domain valuesfixing only a finite set Z of values. In the case of internal dominance vint themappings f and g may only introduce a finite set of new values. Finally, Hullalso defines absolute dominance.

All these notions can be generalised to HERM schemata. For instance, thework in [10] uses the same absolute dominance relation as [9] without referringexplicitly to the relational model. In [9] it has been shown that calculus domi-nance implies generic dominance, which itself implies internal dominance, whichimplies absolute dominance. All these implications are strict. In [15] it has beenshown that calculus dominance implies HERM dominance vH, which impliesgeneric dominance. Of course, both in internal dominance and extended HERMdominance we have to deal with computable queries, so both imply computabledominance.

ADT dominance as defined by Qian [19] is based on order-sorted signaturesand algebras. A schema transformation, i.e. our f , must be defined as a signatureinterpretation. It has been shown in [19] that calculus dominance implies ADTdominance, which implies absolute dominance. These implications are strict. Fur-


thermore, ADT dominance is incomparable with the other notions of dominanceas defined by Hull. In [15] it has been shown that ADT dominance and HERMdominance are also incomparable. However, the transformations defined by Qiandefine computable queries, so ADT dominance implies computable dominance.

Figure 2 illustrates the relationship between the various notions of schemadominance. We base our work on computable dominance, because absolute dom-inance is too general. It does not really preserve the semantics of the originalschemata. On the other hand, extended HERM dominance, internal dominanceand ADT dominance are pairwise incomparable, but all three notions make per-fect sense in that the examples that can be expressed in them (but maybe notin the other formalisms) are reasonable. Therefore, computable dominance hasbeen chosen, because it covers all reasonable notions of dominance without run-ning into the problems arising from absolute dominance. However, computabledominance still leaves a lot of latitude for schema integration, and in most prac-tical cases this latitude will not be exploited, i.e. a weaker notion of dominancewould be sufficient.

4 Schema and View Integration and Cooperation in

Databases

In this section we address first schema integration in databases following [16].Without loss of generality we assume that we are given only two HERM schemata(S1, Σ1) and (S2, Σ2). Before starting the integration process we assume thatthese schemata have been “cleaned”, i.e. we assume that all name clashes havebeen removed by renaming homonymous attributes. Ideally, we may assume thatnames used in both schemata are different.

4.1 Schema and View Integration Process

We first describe a pragmatic method for schema integration, and then explainhow this method applies to view integration. The details are then filled by trans-formation rules described in the following subsections.

1. The first step is the homogenisation of the schemata. This includes the re-structuring of the schemata turning attributes into entity types, entity typesinto relationship types and vice versa. Furthermore, we add attributes andshift attributes along hierarchies and paths. All these individual paces corre-spond to the application of transformation rules. The result of the homogeni-sation step are schemata (S ′1, Σ

′1) and (S ′2, Σ

′2).

2. The second step consists in adding inter-schema integrity constraints thatdescribe the semantic relationships between the two schemata. Formally, weobtain another set of constraints Σ0, and thus the result of this step is asingle HERM schema (S ′1 ∪ S ′2, Σ′

1 ∪Σ′2 ∪Σ0).

3. The third step is only a preparation of the following steps. Due to the ex-pected large size of the schemata, these are divided into modules, each of


which describes a subschema. Corresponding modules are identified in orderto approach the integration of modules first. If schemata are of moderatesize, this step can be omitted.

4. Step four considers the integration of types on level 0, 1, etc., i.e. we startwith entity types and level-0-clusters, then proceed with relationship typesand clusters on level 1, then relationship types and clusters on level 2, etc.For each level we integrate corresponding types or clusters with respect toequality, containment, overlap and disjointness conditions. Note that thisstep is similar to the work done in [13, 14, 29].

5. The fifth step deals with the integration of paths using path inclusion de-pendencies.

6. Finally, we consider remaining integrity constraints such as (path) functionaldependencies and join dependencies.

Let us now see how this method deals with view integration. First recall thata view is nothing but a stored query.

Definition 4.1. A view V on a HERM schema (S, Σ) consists of a schema SV

and a query qV with a query mapping inst(S, Σ)→ inst(SV ).

Example 4.1. Let S1 be the HERM schema from Example 3.1. Let us define aview V1 = Customer Credibility on this schema, in which the target schemaSV1

consists of a single entity-type

Customer Cr = (∅, customer no, name, date of birth,inc oblig(type, amount, frequency),loans(type, amount, account balance),

customer no)

What we want to obtain is the set of all customers with their customernumber, name and date of birth, plus their set of incomes and obligations (eachdescribed by their type, amount and frequency of payment), plus their set ofloans (each described by their type, amount and corresponding account balance).

The defining query for this view is a bit tricky, as it has to involve theconstruction of two set-valued attributes. Following [25] we could employ a gen-eralised nest-operation or use an IQL-like logic program, which would look asfollows:

C(ic, c, n, b, O, L)←Customer(ic, (c, n, a, b));

L(“mortgage”, a, c)←Mortgage(im, (ilt,m, a, d, p, b, e, o)),Loan(il, (mortgage : im)),Account(ia, (il, n, c),Owes(io, (ic, il, b′, e′),C(ic, cc, nc, bc, O, L).


L(“personal”, a, c)←Personal Loan(ipl, (ilt, l, a, p, b, e, t)),Loan(il, (personal : ipl)),Account(ia, (il, n, c),Owes(io, (ic, il, b′, e′),C(ic, cc, nc, bc, O, L).

O(“income”, a, f)←C(ic, cc, nc, bc, O, L),Income(ii, (ic, c, a, t, f)).

O(“obligation”, a, f)←C(ic, cc, nc, bc, O, L),Obligation(io, (ic, c, a, t, f));

Customer Cr(i, (c, n, b, O, L))←C(ic, c, n, b, O, L).

In a nutshell – without going into formal details – this logic program is asequence of clause sets, separated by a semicolon. These clause sets are evaluatedsequentially. Each clause set itself is evaluated by computing an inflationary fixedpoint, i.e. for each clause we bind the variables on the right hand side using thegiven instance of the database, and add the corresponding value for the left handside to the database. The interesting point is that the variables that only occuron the left hand side will be bound to new identifiers, and for each such variableX we obtain a new predicate X so that we can compute a set corresponding toeach identifier.

In our special case here, we first construct a set C of customers with theiridentifier ic, customer number c, name n, date of birth b and identifiers O and Lrepresenting the set of obligations and loans, respectively. In the second clauseset we construct the corresponding sets O and L of obligations and loans, respec-tively, for each customer in C. In the final clause set we replace the identifiersO and L by the corresponding sets O and L, respectively, and create a newidentifier i for each element of the result.

So the view integration problem starts with two views V1 and V2 on the sameHERM schema (S, Σ), and should result in a new integrated view V such thatSV results from integration of the schemata SV1

and SV2, and for each instance

db over (S, Σ) the two query results qV1(db) and qV2

(db) together are equivalentto qV (db).

Now, if the schemata SV1and SV2

are “cleaned”, we may combine the queriesqV1

and qV2into one yielding a query mapping inst(S, Σ) → inst(SV1

∪ SV2)

defined by the query qV1∪ qV2

. If we simply integrate the schemata SV1and

SV2into SV according to the method described above, we obtain an induced

mapping f : inst(SV1∪SV2

)→ inst(SV ). As we deal with computable queries, fis the query mapping of some computable query qf . Taking qV = qf (qV1

∪qV2),

V becomes a view over (S, Σ) with schema SV and defining query qV .This approach to view integration also works in the more general situation,

where the given views V1 and V2 are defined over different schemata (S1, Σ2)and (S2, Σ2), respectively.


4.2 Transformation Rules

In the following subsections we describe transformation rules in detail. All ruleswill be presented in the same way, i.e. we assume a given HERM schema (S, Σ),but we only indicate parts of it. The resulting schema will be (Snew , Σnew). Thenew types in the new schema will be marked with a subscript new . With theseconventions the rules will be self-explanatory.

All the rules in this subsection subsume the rules that have been statedimplicitly or explicitly in former work by others. In addition, the rules will es-tablish computational equivalence in all cases, but formal proofs – which arenot too hard – have been omitted. So what we can expect from our approachis soundness, but not completeness. The non-completeness results from the factthat computational dominance would allow us to define more general rules. Itis very unlikely that there will exist a complete set of rules. On the other hand,having used the notion of computational dominance permits openness, i.e. theset of rules can be extended, if such a need arises.

Schema Restructuring. The first group of rules addresses the aspect ofschema restructuring which will be used in the homogenisation step 1 of ourmethod.

Rule 1. Replace a tuple attribute X(A1, . . . , Am) in an entity or relationshiptype R by the attributes A1, . . . , Am. The resulting type Rnew will replace R.For X(A′

1, . . . , A′n) ∈ key(R) with Ai ≤ A′

i we obtain A′1, . . . , A

′n ∈ key(R′).

This rule includes the simple case, where R is an entity type, which could betreated as a separate rule.

Rule 2. Replace a component r : R′ in a relationship type R by lower levelcomponents and attributes. Let the new type be Rnew. For comp(R′) = r1 :R1, . . . , rn : Rn we get comp(Rnew) = comp(R)−r : R′∪r

(r)1 : R1, . . . , r

(r)n :

Rn with new role names r(r)i composed from ri and r and attr(Rnew) =

attr(R)∪ attr(R′). In the case r : R′ ∈ key(R) and key(R′) = ri1 : Ri1 , . . . , rik:

Rik, A1, . . . , Am we obtain key(Rnew) = key(R)−r : R′∪r

(r)i1

: Ri1 , . . . , r(r)ik

:Rik

, A1, . . . , Am, otherwise we have key(Rnew) = key(R).

It is easy to see how to simplify this rule in the case, where R′ is an entitytype. Again, this could by formulated by two separate rules.

Rule 3. Replace a cluster C = C1 ⊕ · · · ⊕ Cn with a cluster component Ci =Ci1 ⊕ · · ·⊕Cim

by a new cluster C = C1⊕ · · ·⊕Ci−1⊕Ci1 ⊕ · · ·⊕Cim⊕Ci+1⊕

· · · ⊕ Cn.

Rule 4. Replace a relationship type R with a cluster component r : C (C =C1 ⊕ · · · ⊕ Cn) by a new cluster Cnew = R1,new ⊕ · · · ⊕ Rn,new and new rela-tionship types Ri,new with comp(Ri,new) = comp(R) − r : C ∪ ri : Ci andattr(Ri,new) = attr(R). For r : C ∈ key(R) we obtain key = key(R) − r :C ∪ r : Ci, otherwise take key = key(R).


In the case of the restructuring rules 1 – 4 we can always show that theoriginal schema and the resulting schema are equivalent. The next rule onlyguarantees that the resulting new schema dominates the old one.

Rule 5. Replace a key-based inclusion dependency R′[key(Ri)] ⊆ R[key(R)] bynew relationship types R′

new with comp(R′new) = r′ : R′, r : R = key(R′

new)and attr(R′

new) = ∅ together with participation cardinality constraintscard(R′

new, R) = (0, 1) and card (R′new, R

′) = (1, 1).

The last two restructuring rules allow to switch between attributes and entitytypes and between entity and relationship types. These rules 6 and 7 guaranteeschema equivalence.

Rule 6. Replace an entity type E with A ∈ attr(E) by Enew such thatattr(Enew) = attr(E)−A holds. Furthermore, introduce an entity type E ′

new

with attr(E′new) = A = key(E ′

new) and a new relationship type Rnew withcomp(Rnew) = rnew : Enew , r

′new : E′

new = key(Rnew) and attr(Rnew) = ∅.Add the cardinality constraints card(Rnew, Enew) = (1, 1) and card (Rnew, E

′new)

= (1,∞).

Rule 7. Replace a relationship type R with comp(R) = r1 : R1, . . . , rn : Rnand the cardinality constraints card(R,Ri) = (xi, yi) by a new entity type Enew

with attr(Enew) = attr(R) = key(Enew) and n new relationship types Ri,new

with comp(Ri,new) = ri : Ri, r : Enew = key(Ri,new) and attr(Ri,new) = ∅.Replace the cardinality constraints bycard(Ri,new , Ri) = (1, yi) and card(Ri,new , Enew) = (1,∞).

In the case of rule 7 explicit knowledge of the key of R allows to sharpen thecardinality constraints.

Shifting Attributes. The second group of rules deals with the shifting ofattributes. This will also be used in the homogenisation step 1 of our method.Rule 8 allows to shift a synonymous attribute occurring in two subtypes, i.e.whenever tuples agree on the key they also agree on that attribute, to be shiftedto a supertype. This rule leads to a dominating schema. Conversely, rule 9 al-lows to shift an attribute from a supertype to subtypes, in which case schemaequivalence can be verified.

Rule 8. For comp(Ri) = ri : R and Ai ∈ attr(Ri) − key(Ri) (i = 1, 2) to-gether with the constraint ∀t, t′.t[key(R1)] = t′[key(R2)]⇒ t[A1] = t′[A2] replacethe types R, R1 and R2 such that attr(Rnew) = attr(R)∪Ai, comp(Ri,new) =ri : Rnew and attr(Ri,new) = attr(Ri)− Ai hold.

Rule 9. For comp(Ri) = ri : R (i = 1, . . . , n) and A ∈ attr(R) − key(R)together with the constraint ∀t ∈ R.∃t′ ∈ Ri.t

′[ri] = t replace the types such thatattr(Rnew) = attr(R) − A, comp(Ri,new) = ri : Rnew and attr(Ri,new) =attr(Ri) ∪ A hold.


The next two rules 10 and 11 concern the reorganisation of paths and theshifting of attributes along paths. In both cases we obtain a dominating schema.Rule 10 could be split into two rules dealing separately with binary and unaryrelationship types Rn.

Rule 10. For a path P ≡ R1 − · · · − Rn and a relationship type R with rn :Rn ∈ comp(R) together with path cardinality constraints card(P,R1) ≤ (1, 1) ≤card(P,Rn) replace R such that comp(Rnew) = comp(R)−rn : Rn∪ r1,new :R1 with a new role r1,new holds.

Rule 11. For a path P ≡ R1 − · · · − Rn with A ∈ attr(Rn) and path cardi-nality constraints card(P,R1) ≤ (1, 1) ≤ card(P,Rn) replace R1, Rn such thatattr(R1,new) = attr(R1) ∪ A and attr(Rn,new) = attr(Rn)− A hold.

Schema Extension. The third group of rules deal with the schema exten-sions. This either concerns new attributes, new subtypes or the simplification ofhierarchies. These rules are needed in step 1 of our method.

Rule 12. Add a new attribute A to the type R, i.e. attr(Rnew) = attr(R)∪A.In addition, the new attribute may be used to extend the key, i.e. we may havekey(Rnew) = key(R) ∪ A.

If the new attribute A introduced by rule 12 does not become a key attribute,we obtain a dominating schema.

The next two rules allow to introduce a new subtype via selection or projec-tion on non-key-attributes. In both cases we have schema equivalence.

Rule 13. For a type R introduce a new relationship type R′new with comp(R′

new)= r : R = key(R′

new) and add a constraint R′new = σϕ(R) for some selection

formula ϕ.

Rule 14. For a type R and attributes A1, . . . , An ∈ attr(R) such that thereare no Bi ∈ key(R) with Ai ≥ Bi introduce a new relationship type R′

new withcomp(R′

new) = r : R = key(R′new) and attr(R′

new) = A1, . . . , An, and add aconstraint R′

new = πA1,...,An(R).

The last rule 15 in this group allows to simplify hierarchies. Here again wemust exploit Hext to obtain dominance.

Rule 15. Replace types R, R1, . . . , Rn with comp(Ri) = ri : R = key(Ri)and card(R,Ri) = (0, 1) (i = 1, . . . , n) by a new type Rnew with comp(Rnew) =

comp(R), attr(Rnew) = attr(R) ∪n⋃

i=1

attr(Ri) and key(Rnew) = key(R).


Type Integration. The fourth group of rules deals with the integration oftypes in step 4 of our method. Rule 16 considers the equality case, rule 17considers the containment case, and rule 18 covers the overlap case. Note thatthese transformation rules cover the core of the approaches in [13, 29, 14].

Rule 16. If R1 and R2 are types with key(R1) = key(R2) and we have theconstraint R1[key(R1) ∪ X ] = f(R2[key(R2) ∪ Y ]) for some X ⊆ comp(R1) ∪attr(R1), Y ⊆ comp(R2)∪attr(R2) and a bijective mapping f , then replace thesetypes by Rnew with comp(Rnew) = comp(R1) ∪ (comp(R2) − Y − key(R2)),attr(Rnew) = attr(R1) ∪ (attr(R2) − Y − key(R2)) ∪ D and key(Rnew) =key(R1) ∪ D and an optional new distinguishing attribute D.

Rule 17. If R1 and R2 are types with key(R1) = key(R2) and the constraintR2[key(R2)∪Y ] ⊆ f(R1[key(R1)∪X ] holds for some X ⊆ comp(R1)∪attr(R1),Y ⊆ comp(R2)∪ attr(R2) and a bijective mapping f , then replace R1 by R1,new

with comp(R1,new) = comp(R1), attr(Rnew) = attr(R1)∪D and key(Rnew) =key(R1) ∪ D and an optional new distinguishing attribute D. Furthermore,replace R2 by R2,new with comp(R2,new)rnew : R1,new ∪ comp(R2) − Y −key(R2), attr(R2,new) = attr(R2) − Y − key(R2) and key(R2,new) = rnew :R1,new.

Rule 18. If R1 and R2 are types with key(R1) = key(R2) such that for X ⊆comp(R1) ∪ attr(R1), Y ⊆ comp(R2) ∪ attr(R2) and a bijective mapping f theconstraints

R2[key(R2) ∪ Y ] ⊆ f(R1[key(R1) ∪X ] ,

R2[key(R2) ∪ Y ] ⊇ f(R1[key(R1) ∪X ] andR2[key(R2) ∪ Y ] ∩ f(R1[key(R1) ∪X ] = ∅

are not satisfied, then replace R1 by R1,new with comp(R1,new)r1,new : Rnew∪comp(R1)−X−key(R1), attr(R1,new) = attr(R1)−X−key(R1) and key(R1,new)= r1,new : Rnew, replace R2 by R2,new with comp(R2,new)rnew : R1,new ∪comp(R2)−Y −key(R2), attr(R2,new) = attr(R2)−Y −key(R2) and key(R2,new)= rnew : R1,new and introduce a new type Rnew with comp(Rnew) = comp(R1)∪comp(R2), attr(Rnew) = attr(R1) ∪ attr(R2) ∪ D and key(Rnew) = key(R1)∪D and an optional new distinguishing attribute D.

The rules 16-18 could each be split into several rules depending on f beingthe identity or not and the necessity to introduce D or not. In all cases we obtaindominance.

Rule 19 considers the case of a selection condition, in which case schemaequivalence holds.

Rule 19. If R and R′ are types with comp(R′) ∪ attr(R′) = Z ⊆ comp(R) ∪attr(R) such that the constraint R′ = σϕ(πZ (R)) holds for some selection con-dition ϕ, then omit R′.


Handling Integrity Constraints. The fifth group of rules to be applied instep 5 of our method concerns transformations originating from path inclusionconstraints. Rule 20 allows us to change a relationship type. This rule leads toequivalent schemata. Rule 21 allows to introduce a relationship type and a joindependency. Finally, rule 22 handles a condition under which a relationship typemay be omitted. Both rules 21 and 22 guarantee dominance.

Rule 20. If there are paths P ≡ R1 − R − R2 and P ′ ≡ R2 − R′ − R3

with comp(R) = r1 : R1, r2 : R2 and comp(R′) = r3 : R3, r′2 : R2 such

that the constraint P [R2] ⊆ P ′[R2] holds, then replace R in such a way thatcomp(Rnew) = r1 : R1, rnew : R′, attr(Rnew) = attr(R) and key(Rnew) =key(R)− r2 : R2 ∪ rnew : R′ hold.

Rule 21. If there are paths P ≡ R1 − R − R2 and P ′ ≡ R2 − R′ − R3 withcomp(R) = r1 : R1, r2 : R2 and comp(R′) = r3 : R3, r

′2 : R2 such that

the constraint P [R2] = P ′[R2] holds, then replace R and R′ by Rnew such thatcomp(Rnew) = r1 : R1, r2,new : R2, r3 : R3, attr(Rnew) = attr(R) ∪ attr(R′)and key(Rnew) = (key(R) − r2 : R2) ∪ (key(R′) − r′2 : R2) ∪ r2,new : R2hold. Add the join dependency

Rnew[r1, r2,new] ./ Rnew [r2,new, r3] ⊆ Rnew[r1, r2,new, r3].

Rule 22. If there are paths P ≡ R1−R2−· · ·−Rn and P ′ ≡ R1−R−Rn withcomp(R) = r1 : R1, rn : Rn such that the constraint P [R1, Rn] = P ′[R1, Rn]holds, then omit R.

The final group of transformation rules 23-26 permits to handle remainingconstraints such as functional dependencies, path functional dependencies, andjoin dependencies. All these constraints are described in detail in [30]. The rulesrefer to step 6 of our method.

Rule 23 handles vertical decomposition in the presence of a functional de-pendency. Rule 24 allows to simplify a key in the presence of a path functionaldependency. Rule 25 introduces a new entity type in the presence of a pathfunctional dependency. Finally, rule 26 replaces a multi-ary relationship type bybinary relationship types in the presence of a join dependency. The four ruleslead to dominating schemata.

Rule 23. If a functional dependency X → A with a generalised subset Xof attr(E) and an attribute A ∈ attr(E) − X holds on an entity type E, butX → key(E) does not hold, then remove A from attr(E) and add a new entitytype E′

new with attr(E′new) = X ∪ A and key(E ′

new) = X .

Rule 24. For a path P ≡ R1 − R − R2 with comp(R) = r1 : R1, r2 : R2such that the path functional dependency X → key(R2) holds for a generalisedsubset X of attr(R1) replace key(R) by r1 : R1.

Rule 25. For a path P ≡ R1 − · · · −Rn such that the path functional depen-dency X → A holds for a generalised subset X of attr(R1) and A ∈ attr(Rn)add a new entity type Enew with attr(Enew) = X ∪ A and key(Enew) = X .


Rule 26. If R is an n-ary relationship type with comp(R) = r1 : R1, . . . , rn :Rn and attr(R) = ∅ such that the join dependency R[r1, r2] ./ · · · ./ R[r1, rn] ⊆R[r1, . . . , rn] holds, then replaceR by n new relationship typesR1,new, . . . , Rn,new

with comp(Ri,new) = r1 : R1, ri : Ri = key(Ri,new) and attr(Ri,new) = ∅.

4.3 View Cooperation

View cooperation [30] provides an alternative to view integration in which theintegrated view is only virtual. That is the constituting views are kept andexchange functions are designed to provide the same functionality as if the viewswere integrated.

Definition 4.2. Let Vi = (SVi, qVi

) (i = 1, 2) be views (on the same or differentHERM schemata). V1 cooperates with V2 iff there are subschemata S ′Vi

of SVi

and functions f1 : inst(S ′V1) → inst(S ′V2

) and f2 : inst(S ′V2) → inst(S ′V1

), suchthat both f1 f2 and f2 f1 are the identity function.

Basically, view cooperation expresses that part of view V1, exactly the onecorresponding to the subschema S ′V1

can be expressed by the part of view V2

corresponding to the subschema S ′V2.

Now, if we want to obtain a cooperation between given views V1 and V2, wemay simply apply our view integration method to them using the same trans-formation rules. This will result in an integrated view V = (SV , qV ). Withrespect to this integrated view both S ′

V1and S ′V2

will be identified with a sub-schema S ′V . In particular we obtain functions f ′

i : inst(S ′Vi) → inst(S ′V ) and

g′i : inst(S ′V ) → inst(S ′Vi)) (i = 1, 2) with g′i f

′i = id and f ′

i g′i = id. Thus,

f1 = g′2 f′1 and f2 = g′1 f

′2 define the view cooperation functions.

4.4 Case Study

In order to demonstrate our approach to view integration and cooperation wefirst use a second HERM schema S2, which is given by the HERM diagramin Figure 3. We may think of this schema being used by a mortgage brokerwho deals with mortgages from different banks. In addition, the assessment ofthe credibility of a customer may depend on securities owned by supportingrelatives, so we add information about relatives to the schema. We omit theformal definition for this HERM schema.

Example 4.2. Let us first address the integration of the HERM schemata S1

and S2 from Figures 1 and 3. In these schemata we mainly have to deal with thehomogenisation of types in the two schemata, i.e. with type restructuring, andwith type integration.

First we homogenise Customer appearing in both schemata adding at-tributes (rule 12) and turning the attributes name and address into tuple at-tributes with components first name and last name, and city and street address,respectively – which means to apply rule 1. We obtain the integrated type


Relative Customer

Security_Ob ject

Available_Security Mortgage

Mortgage_Type

Finance_Transactions

Account

on_account

for_customer

supporter

self

for

object security

who payments

type

begin

end

customer_no

first_name

last_name

date_of_birth

street_address

city phone

value type

object

identification

interest

conditions

mortgage_no

amount

disagio

begin end

object

interest_rate

bank_id

account_no

account_name

transaction_no

amount

type

frequency

plus/minus

Fig. 3. HERM diagram for mortgage broker application

Customer = (∅, customer no, name(first name, last name),address(city, street address), phone, date of birth , customer no )

Next we split Finance Transactions in S2 into Income and Obligation

according to the value of the attribute plus/minus. This results from applyingrule 13. Furthermore, we can rename role names and turn the attribute accountfor both Income and Obligation into a component on account : Account.

The homogenisation of Mortgage Type in S1 and Loan Type in S2 re-qires not much more than the renaming of the attribute type to identification.The homogenisation of Mortgage in both schemata requires first to introducein S2 a new type Payment, which takes the components who : Customer andpayments : Account from Mortgage, and add a component for : Mortgage.Similarly, we can split Security in S1 into Available Security, for which wecan drop the component for : Mortgage, and Security. In S1 we can renameOwes to Payment and add a component payments: Account. Finally, wereplace Mortgage in Payment by the cluster Loan.

The HERM diagram of the final resulting schema is shown in Figure 4.

The work in [16] contains further examples for schema integration.The integration of schemata turns each view over one of the source schemata

into a view over the integrated schema. What is changed is the defining query.

Example 4.3. Consider the view V1 from Example 4.1. If schema S1 is integratedwith schema S2 into schema S12 in Figure 4, the defining query for V1 changes


Relative Customer

Security_Ob ject

Available_Security Mortgage

Loan_Type

Obligation

Account

on_account

for_customer

supporter

self

for

object type

begin

end

customer_no

name(first_name,last_name)

phone

date_of_birth

address(city,street)

value

type object

identification

interest

conditions

mortgage_no

amount

disagio

begin

end

object

interest_rate

bank_id

account_no

account_name

transaction_no

type

frequency

Security

for

object

amount

balance

Income

for_customer

transaction_no

type

frequency

amount

on_account

Personal_ Loan

type

loan_no

amount

begin end

terms_of_payment

interest_rate

Payment

Loan

who

for

from Account_Record

a

record_no

type

date

amount

Fig. 4. HERM diagram for integrated HERM schemata

as follows:

C(ic, c, n, b, O, L)←Customer(ic, (c, n, a, b, ph));

L(“mortgage”, a, c)←Mortgage(im, (ilt,m, a, d, p, b, e, o)),Loan(il, (mortgage : im)),Payment(ip, (ia, il, ic),C(ic, cc, nc, bc, O, L).

L(“personal”, a, c)←Personal Loan(ipl, (ilt, l, a, p, b, e, t)),Loan(il, (personal : ipl)),Payment(ip, (ia, il, ic),C(ic, cc, nc, bc, O, L).

O(“income”, a, f)←C(ic, cc, nc, bc, O, L),Income(ii, (ic, ia, t, t′, a, f)).

O(“obligation”, a, f)←C(ic, cc, nc, bc, O, L),Obligation(ii, (ic, ia, t, t′, a, f));

Customer Cr(i, (c, n, b, O, L))←C(ic, c, n, b, O, L).


Example 4.4. Let us now address the integration of views. For this consideranother view V2 defined on the database schema S2. Let the target schema SV2

consist again of a single entity-type

Customer Cr = (∅, customer no, name(first name,last name), date of birth,inc oblig(type, amount, frequency),securities(type, object, value, self),

customer no)

Analogous to Example 4.1 we want to obtain the set of all customers withtheir customer number, name and date of birth, plus their set of incomes and obli-gations (each described by their type, amount and frequency of payment), plustheir set of securities (each described by their type, object, value and whetherit is a security owned by the customer or a supporting relative). The definingquery will be built analogously to the one in Example 4.1 – we omit the details.We also omit how this defining query will be translated into a query on theintegrated schema S12.

Then we basically integrate the target schemata of V1 and V2, which resultsin a schema SV12

with a single entity-type

Customer Cr = (∅, customer no, name(first name,last name), date of birth,inc oblig(type, amount, frequency),securities(type, object, value, self),loans(type, amount, account balance),

customer no)

The defining query on S12 is built analogously to the ones for V1 and V2.We just obtain a third set-valued attribute that has to be constructed by somefixed-point computation.

Let us finally look at view cooperation, i.e. we do not integrate the views V1

and V2 on schema S12, but only determine view cooperation functions.

Example 4.5. The target schemata of the views V1 and V2 from Examples 4.1and 4.4 share an equivalent subschema. Both S ′

V1and S ′V2

consist of a singleentity-type

Customer Cr = (∅, customer no, name, date of birth,inc oblig(type, amount, frequency),

customer no)

The only difference is that in V1 the attribute name is a simple attribute,while in V2 it is a tuple attribute name(first name, last name). The correspondingequivalent subschema of SV12

also contains this tuple attribute. Therefore, thecooperation functions f1 : inst(S ′V1

)→ inst(S ′V2) and f2 : inst(S ′V2

)→ inst(S ′V1)

only affect the name attribute. That is, f2 will concatenate the first name andthe last name, while f1 will decompose name according to some algorithm. Forinstance, if we assume that spaces are not allowed inside last names, we couldsimply search for the last space in a name string and take the substring precedingit for first name, and the string following the space for last name.


5 View Integration in Data Warehouses

In this section we apply our view integration method to data warehouses. Forthis we exploit the general idea of data warehouses, i.e. the separation of inputfrom operational databases and output to data marts. This idea is illustratedusing a three-tier architecture in Figure 5. In particular, we take up the ideafrom [17] to model OLAP applications by dialogue types [21].

The underlying idea is simply that the content presented to a user can bedescribed by a value of a complex data type. In addition a user is offered op-erations – the OLAP operations in the case of data warehouses – that work onthe presented value. This defines a dialogue object, and dialogue types arise fromthe usual abstraction. In addition, the values presented to the users depend onsome database, so the dialogue types give rise to views that are extended by op-erations. We briefly illustrate these concepts, then extend our view integrationmethod to this case.

Data Warehouse

Data Mart 1 Data Mart n

Database 1 Database k

Fig. 5. General Data Warehouse Architecture

The fact that view integration arises within the area of data warehousingarises from using the dialogue types approach to model the data marts for theOLAP applications. In developing an OLAP application we would first collectthe user needs including ways how to work with a system – see [21] for moredetails. This gives a collection of views, while the warehouse itself is the resultof integrating these views. The problems of deciding on materialised views that


support the data marts efficiently and chosing view cooperation as an alternativeare orthogonal to this integration problem.

5.1 Data Warehouse Architecture

On the bottom tier we have operational databases set up for purposes that are ofno particular interest for the data warehouse. However, we assume that the datastored in the data warehouse is extracted from these operational databases. Inother words, the input of data into the data warehouse is defined by update- orrefresh operations, which take data from these operational databases and insertthem into the data warehouse. In particular, these refresh-operations can be for-mulated by queries on the operational databases. Assuming that the HERM hasbeen used for the operational databases, we can express the refresh-operationsin (extended) HERM algebra or calculus. It is not very likely that the structureof a data warehouse will require more complicated (computable) queries.

In general, if there is some conflict between these operational data, i.e. datafrom different operational databases has to be integrated before it can be insertedinto the data warehouse, we need an integrator component [36]. However, we mayassume that this integrator is part of the extraction functions.

The second tier of the architecture in Figure 5 is made up by the data ware-house itself. In principle, we just have a database system here with the onlydifferences that we may assume a simpler schema, i.e. star or snowflake schema,and we do not have to consider complex transactions. The only write-operationsare the refresh operations that connect the data warehouse to the operationaldatabases. All other operations only read data from the data warehouse. In fact,we just build views for the “data marts” or dialogue objects that are used asthe OLAP interface. So, the view construction operations are the only ones thatlink the middle tier to the top tier, which deals with OLAP. So again, the majorfunctionality is expressed by views.

The top tier itself is constructed out of the dialogue objects and the OLAPoperations working on them. This tier realises the idea of using dialogue objectsfor this purpose. The general idea from [21] is that each user has a collectionof open dialogue objects, i.e. data marts. At any time we may get new users,and each user may create new dialogue objects without closing the existing ones.Thus, we maintain the lists of users and their data marts in the system. Part ofthe functionality of the OLAP tier deals with adding and removing users anddata marts. In particular, if a user leaves the system, all data marts owned byhim/her must be removed as well.

The major functionality, however, deals with running operations on existingdata marts or creating new data marts. In the latter case we have to use a viewcreation query as described for the middle tier. In this case we choose a newidentifier for this data mart / dialogue object, and initialise its data content. Ifthe user selects some of the data of the data mart and an operation other thanquit (i.e. the user does not want to leave the system), close (i.e. the user does notwant to finish work on the current data mart) or open (i.e. no new data mart is


to be created), then we request to receive additional input from the user, beforethe selected operation will be executed.

5.2 Dialogue Types

We have seen that the major functionality on the OLAP tier is expressed byviews that are extended by operations, which is exactly the idea underlyingdialogue types. However, we simplify the original definition from [21] omittingthe subtle distinction between hidden and visible parts. We also omit hierarchiesof dialogue types.

Definition 5.1. A dialogue type D over a HERM schema (S, Σ) consists of aview VD = (SD , qD), in which SD consists of a single entity type E, and a setO of dialogue operations. Each dialogue operation (d-operation for short) in Oconsists of

– an operation name op,– a list of input parameters i1 : D1, . . . , ik : Dk with domain names Di,– an (optional) output domain Dout,– a subattribute sel of the representing attribute XE , and– a d-operation body, which is built from usual programming constructs op-

erating on instances over (S, Σ) and constructs for creating and deletingdialogue objects.

Whenever we are given an instance db over (S, Σ), the defining query qD

produces an instance over SD , i.e. a set of pairs (i, v) with i ∈ ID and v ∈dom(XE), each of which will be called a dialogue object of type D. At any timeonly a subset of qD(db) will be available, the set of active dialogue objects. Theserepresent the active user dialogues in an abstract way.

The presented value v may be projected to πXE

sel (v), which represents the datathat must be selected by the user as a prerequisite for executing operation op.Once these data are selected and the operation op is started, further input forthe parameters i1, . . . , ik will be requested from the user – using e.g. so-calleddialogue boxes [21] – and the execution of op will update the database db andresult in a new set of active dialogue objects.

5.3 Transformation Rules for Dialogue Types

As user dialogues are an invaluable source of information in requirements engi-neering, we may usually assume that we know about dialogue objects before thedefining queries and the underlying database schema is fixed. Therefore, viewintegration is an unavoidable design task. Integrating the views that underlythe dialogue types leads to a design of the data warehouse. In addition, we willalways be confronted with the desire to rearrange the “data marts”, i.e. the di-alogue types that define the OLAP functionality. This problem also appears indatabase applications other than OLAP.


Therefore, the additional problem is to adapt the d-operations that are usedfor the functionality presented to a database or data warehouse user. For thiswe define further transformation rules. However, these additional transformationrules have to be understood as follow-on rules for the case that one of the rules 1-26 is not just applied to schemata or views, but to dialogue types. Thus, we obtainadditional changes to the selection attribute sel and the body of d-operations.

Rule 27. In case rule 1 is applied to a dialogue type, whenever X(A′1, . . . , A

′k)

(k ≤ m) appears in sel or in the body of a d-operation, replace it by A′1, . . . , A

′k.

Rule 28. In case rule 2 is applied to a dialogue type, whenever r appears insel or in the body of a d-operation, replace it by r(r)

1 , . . . , r(r)n .

We may ignore rules 3 and 4, as clusters have not been allowed in dialoguetypes. There is also nothing to add for rule 5, as this introduces a new type, sooperations have to be defined for that type.

Rule 29. In case rule 6 is applied to a dialogue type omit A in sel or in thebody of a d-operation, whenever it appears.

Rule 30. In case rule 6 is applied to a dialogue type omit r1, . . . , rn in sel orin the body of a d-operation, whenever it appears.

These extensions capture the first group of rules dealing with schema re-structuring. For the second group of rules dealing with the shifting of attributeswe obtain the following extension rules in case the rules are applied to dialoguetypes.

Rule 31. In case rule 8 is applied to a dialogue type omit Ai in sel and thebody of operations associated with Ri,new, whenever it appears in sel or thebody of an operation associated with Ri.

Rule 32. In case rule 9 is applied to a dialogue type omit Ai in sel and thebody of operations associated with Rnew , whenever it appears in sel or the bodyof an operation associated with R.

Note that the last two extension rules have no effect on Rnew or Ri,new, asthe extension of the selection attribute or the body of an operation has to bedefined for these new types.

Rule 33. In case rule 10 is applied to a dialogue type replace rn by r1,new insel and the body of operations associated with Rnew.

Rule 34. In case rule 11 is applied to a dialogue type omit A in sel and thebody of operations associated with Rn,new.

For the third group of rules, i.e. rules 12-15 dealing with schema extension wecannot define reasonable extension rules for dialogue types, as we always have todeal with completely new types. The same applies to rules 16-19, i.e. the groupof rules dealing with type integration.

Finally, for the group of rules dealing with integrity constraints only rules20, 21 and 23 give rise to the following three extension rules for dialogue types.


Rule 35. In case rule 20 is applied to a dialogue type replace r2 by rnew in seland the body of operations, whenever it appears.

Rule 36. In case rule 21 is applied to a dialogue type replace r2 by r2,new insel and the body of operations, whenever it appears.

Rule 37. In case rule 23 is applied to a dialogue type remove A in sel and thebody of operations, whenever it appears.

5.4 Case Study

Let us continue the case study from the previous section. What we have to dois to study how operations associated with a view will be affected by the viewintegration process.

Example 5.1. Consider the view V1 on schema S1 from Example 4.1. Let usassociate a d-operation show security with this view turning it into a dialoguetype. The idea behind this operation is that a user who gets a presentation of acustomer together with his/her obligations and loans, checks the securities for amortgage in the list. So the user will select one of the loans, a mortgage, thenchoose the operation show security, and receive a presentation of a security list,i.e. a new dialogue object will be opened. That is, the d-operation is defined as

show security[mortgage no]() = d-open (Security List[mortgage no])

This is a very simple d-operation, which only opens a d-object that is specifiedby another dialogue type Security List and the value for the key attributemortgage no. We omit the definition of this dialogue type.

The integration of schemata S1 and S2 and the integration of views V1 and V2

has only a marginal effect on this d-operation, which becomes a d-operation forthe integrated view. As we only open a d-object, the change is already reflectedin adapting the defining query for the underlying view of the dialogue typeSecurity List.

Let us consider another d-operation loan update with selection attribute sel= loan no, i.e. we request again that a loan, this time a personal loan, be selectedfrom the list of loans of a customer. For this operation we also request additionalinput from a user, which is specified by the parameters amount and interest, bothwith domain Decimal , and terms with domain String . So we may specify

loan update[loan no](amount:Decimal ,interest:Decimal ,terms:String) =let (i, (t′, l, a, p, b, e, t)) = Ix ∈ Personal Loan.

x.loan no = loan no

in Personal Loan :& (i, (t′, l, amount, interest, b, e, terms))

That is, we select the data about the loan with the selected loan numberfrom the database, which is expressed by “the unique x . . . ”, written as Ix ∈Personal Loan. . . . , then update (: &) this tuple in the database using the


input provided by the user, i.e. the values of the parameters amount, interestand terms.

In adapting this d-operation to the integrated view, we have to replace thespecification of values in Personal Loan according to the changes to the inte-grated schema.

6 View Integration in Web Information Systems

A web information system (WIS) is a database-backed information system thatis realized and distributed over the web with user access via web browsers. In-formation is made available via pages including a navigation structure betweenthem and to sites outside the system. Furthermore, there should also be opera-tions to retrieve data from the system or to update the underlying database(s).

The methodology for WIS design in [22, 25] emphasises abstraction layers andthe co-design of structure, operations and interfaces. As WISs are open systemsin the sense that everyone who has access to the web may turn up as a user, theirdesign requires a clear picture of the intended users and their behaviour. Thisincludes knowledge about the used access channels and end-devices. At a highlevel of abstraction this first leads to storyboarding, an activity that addressesthe design of underlying application stories. Storyboarding first describes a story

space by scenes and actions on these scenes. Furthermore, it describes the actors

in these scenes, i.e. groups of users of the WIS. Actor modelling leads to roles,profiles, goals, preferences, obligations and rights. Finally, the actors are linkedto the story space by means of tasks.

Further on in the development process the scenes in the story space haveto be adequately supported. For this the methodology focuses on media types,which cover extended views, adaptivity and hierarchies. In a nutshell, a mediatype is an extended view on some underlying database schema. These views arebuilt in a way that they capture the complex content and navigation structurethat is to be presented to a user. In order to capture the navigation structure weuse abstract identifiers in the views, both for having a unique handle for eachobject in the reult and for being able to reference this object. So the definingqueries must be powerful enough to create these identifiers. As a consequence,views are no longer independent from each other in the sense that creating oneview may require to create another one simultaneously. This is a well knownproblem from querying object oriented databases, for which the solution by IQL[1] can be adopted. An alternative would be to use the extended query algebrafrom [25].

The view integration (or cooperation) problem for WISs arises in the sameway as the one for data warehouses. Storyboarding results among others in acollection of elementary scenes, each of which has to be supported by a mediatype, i.e. an extended view. Defining these views gives a collection of views, whilethe actual database support requires the integration of these views.

Adaptivity to users, channels and end-devices mainly concerns the question,whether all information or only the most important part of it is to be presented


to a user. By specifying on a conceptual level what these “most important”parts are and which parts have to be kept together we may then leave thetechnical realisation of adaptivity to an algorithmic solution. Hierarchies enablethe presentation of information at different levels of granularity allowing a userto switch between these levels. Such hierarchies are common in OLAP systemsand the principles can be borrowed from there. We will not deal with hierarchiesin this article.

Similar to OLAP systems it is likely that the content that is to be madeavailable to users is modelled, before an underlying database schema and thusdefining queries for media types have been defined. This leads unavoidably to aview integration problem. In addition, we have to cope with the implications foroperations and for adaptivity – postponing the hierarchies to later. Operationscan be dealt with in the same way as for data warehouses and OLAP systems.

The transformation rules in Section 4 already capture the core of the in-tegration process, the integration of the views. So we only have to look at theextensions that arise from media types. Operations have already been dealt within Section 5, so we are left with the adaptivity, i.e. we just explain in this sectionhow the rules have to be extended to be applicable to media types. Thus, wemay concentrate on the aspect of adaptivity.

6.1 Extended Views for Web Information Systems

At the core of a media type we have the same idea as for dialogue types with somesubtle distinctions. The idea is the same as for the dialogue types: The contentof a web page can be described by a complex value of some type, which maycontain references to other values. These references abstract from links betweenpages. Then abstract to types and add operations. This leads first to the notionof interaction type as defined (in a simplified form) next.

Definition 6.1. An interaction type I over a HERM schema (S, Σ) consists ofa view VI = (SI , qI), and a set O of dialogue operations.

The difference between interaction and dialogue types is that the view schemaSI of an interaction type may be much more complicated. In particular, wepermit references (or roles) between the interaction objects of any type in SI

that result from applying the defining query qI to an instance over (S, Σ). Thisusually requires qI to be written in a highly expressive query language. As alreadyindicated above, we require languages that create abstract identifiers. It is knownfrom [1] that this identifier creation may involve computing a fixed point, whichis more expressive than what we would use in simpler SQL-like query languages.

Furthermore, for each interaction object (i, v) in qI(db) we interpret the ab-stract identifier i as a surrogate for a URL address. In this way the queries usedin interaction types already define the navigation structure of the WIS. This isa fundamental difference to work by others as e.g. in [4], where views are onlyused to extract data, whereas the navigation structure is added later on in aseparate design step.


Apart from these subtle differences media types extend interaction types bycohesion in order to enable adaptivity. Cohesion introduces a controlled form ofinformation loss exploiting the partial order ≥ on nested attributes.

Definition 6.2. If XM is the representing attribute of an interaction type Mand sub(XM ) is the set of all nested attributes Y with XM ≥ Y , then a preorderM on sub(XM ) extending the order ≥ is called a cohesion preorder .

Large elements in sub(XM ) with respect to M define information to be kepttogether, if possible. Clearly, XM is maximal with respect to M . This enablesa controlled form of information decomposition [25]. So we obtain the following(simplified) definition of a media type.

Definition 6.3. A media type is an interaction type M together with an cohe-sion preorder M .

As media types are extended views over some database schema, any instanceof such a schema defines a set of objects for the media types, which we call media

objects. The difference between these media objects and the interaction objectsthat we considered first is that the existence hierarchies leads to different ver-sion of these objects, while adaptivity replaces a single object by an interlinkedsequence of objects, i.e. the information is fragmented. Nevertheless, these ver-sions and sequences are determined by the media type, and for our purpose ofintegrating these types we do not have to look at the objects at all.

[25] contains an algorithmic approach to adaptivity based on cohesion pre-orders. This algorithm is not relevant for our purposes here. In that article alsoalternatives to cohesion preorders, which consist of proximity values, but leadto the same results, are discussed.

6.2 Transformation Rules for Media Types

The addition of cohesion preorders requires further extensions to our view inte-gration methodology. We now need additional transformation rules dealing withthe impact of the view integration on the cohesion. We may dispense with dis-cussing operations as these have already been captured by the rules for dialoguetypes. So the following rules are either extension rules to the basic transformationrules 1-26 or to the rules 27-37 for dialogue types.

Rule 38. In case rules 1 and 27 are applied to a media type, if X(A′1, . . . , A

′k)

(k ≤ m) appears in Y ∈ sub(XM ), replace it by A′1, . . . , A

′k.

Rule 39. In case rules 2 and 28 are applied to a media type, whenever r appearsin Y ∈ sub(XM ), replace it by r(r)

1 , . . . , r(r)n .

Same as for dialogue types we may ignore rules 3, 4 and 5 for media types.

Rule 40. In case rules 6 and 29 are applied to a media type omit A in Y ∈sub(XM ), whenever it appears.


Rule 41. In case rules 7 and 30 are applied to a dialogue type omit r1, . . . , rnin Y ∈ sub(XM ), whenever it appears.

These extensions capture the first group of rules dealing with schema restruc-turing. For the second group of rules dealing with the shifting of attributes weobtain the following extension rules in case the rules are applied to media types.

Rule 42. In case rules 8 and 31 are applied to a media type omit Ai in Y ∈sub(XM ) associated with Ri,new , whenever it appears..

Rule 43. In case rules 9 and 32 are applied to a media type omit Ai in Y ∈sub(XM ) associated with Rnew , whenever it appears..

As for dialogue types the last two extension rules have no effect on Rnew orRi,new , as the extension of the cohesion preorder has to be defined for these newtypes.

Rule 44. In case rules 10 and 33 are applied to a media type replace rn byr1,new in Y ∈ sub(XM ) associated with Rnew .

Rule 45. In case rules 11 and 34 are applied to a dialogue type omit A inY ∈ sub(XM ) associated with Rn,new.

For the third group of rules, i.e. rules 12-15 dealing with schema extensiononly rules 12 and 15 give rise to reasonable extension rules for media types. Thisdefines the following two extension rules.

Rule 46. In case rule 12 is applied to a media type, add A to all Y ∈ sub(XM )associated with Rnew and extend the now incomplete cohesion preorder.

Rule 47. In case rule 15 is applied to a media type, define the Cartesian prod-uct of the cohesion preorders and extend the resulting flawed cohesion preorder.

For the group of rules dealing with type integration, i.e. rules 16-19, noreasonable extension rules for media types can be defined, as we deal with newtypes. Finally, for the group of rules dealing with integrity constraints again onlyrules 20, 21 and 23 give rise to the following three extension rules for dialoguetypes.

Rule 48. In case rules 20 and 35 are applied to a media type replace r2 byrnew in Y ∈ sub(XM ), whenever it appears.

Rule 49. In case rules 21 and 36 are applied to a media type replace r2 byr2,new in Y ∈ sub(XM ), whenever it appears.

Rule 50. In case rules 23 and 37 are applied to a media type remove A inY ∈ sub(XM ), whenever it appears.


O(T1, A1, F )

O(T1, A1) O(T1, F ) O(A1, F )

O(T1) O(A1) O(F )

O()

()

Fig. 6. Cohesion lattice

6.3 Case Study

Let us continue the case study from the previous sections. What we have to dois to study how a cohesion preorder associated with a view will be affected bythe view integration process.

Example 6.1. Consider the view V1 on schema S1 from Example 4.1. Therepresenting attribute of the type Customer Cr is a tuple attribute withfive components, two of which are set attributes. As a shortcut we may write(C,N,D,O(T1, A1, F ), L(T2, A2, B)) for this attribute.

Here C represents customer no, N the name, D the date of birth, and O andL the income-obligations and loans, respectively. If this is used as the basis of amedia type M , it is easy to calculate that there are 648 attributes in sub(XM ).As this is a bit too big for our purposes here, let us concentrate only on one com-ponent, say on the attribute O(T1, A1, F ), for which T1, A1 and F representthe attributes type, amount and frequency, respectively.

The corresponding lattice is shown in Figure 6. Thus, we may define thefollowing cohesion preorder:

O(T1, A1, F ) O(T1, A1) O(T1, F ) O(T1) O(A1, F ) O(A1) O(F ) O() ()

If we now remove the attribute F , this preorder reduces to

O(T1, A1) O(T1) O(A1) O() ()


7 Conclusion

In this article we revisited schema and view integration and cooperation. Wepresented a method for schema (or view) integration following the framework in[16], i.e. we first “clean” given schemata by removing name conflicts, synonymsand homonyms, then we add inter-schema constraints, and to this schema wethen apply formal equivalence transformation or augmentation rules. The trans-formation and augmentation rules are correct in the sense that they will alwaysresult in a new schema / view that is equivalent to the original one or dominatesit. For this we introduced a new concept of schema equivalence and dominancebased on computable queries.

This new notion of equivalence and dominance subsumes all reasonable exist-ing ones, so we do not lose valuable transformation rules. On the other hand it israther general, so that the set of transformation rules can be extended if neededwithout violating schema equivalence. It is an open problem to characterise ex-actly, which integration problems would require which notion of dominance andequivalence. The work in this article did not aim at solving this interesting the-oretical problem. We concentrated instead on finding a reasonable approach toview integration and cooperation that is theoretically founded, but pragmaticallyoriented.

In follow-on steps we applied the view integration and cooperation frameworkto databases, data warehouses and web information systems. In the first two casesthe key concept is that of a dialogue type, which is a view extended by operations.In the last case the key concept is that of a media type, which further extendsdialogue types by cohesion in order to facilitate adaptivity. In all three cases theintegration of the extended views requested additions to the transformation andaugmentation rules.

The extension of view integration and cooperation to data warehouses andweb information systems is completely new. So far, the relevant work in the liter-ature concentrated exclusively on the structural aspect, leaving the implicationsto view extensions aside. As the extensions to the views are the core contribu-tion of dialogue types (for the case of data warehouses) and media types (forweb information systems), respectively, it is important to have a pragmatic viewintegration and cooperation method at hand. Without such a method the devel-opment methodology would be incomplete.

Thus, the presented approach to view integration and cooperation turns outto be general enough to be applicable to a large class of data-intensive informa-tion systems. By means of the areas for which we demonstrated this applicability,it contributes to a decisive aspect in systems development. We demonstrated thisapplicability by a case study for all three areas. However, the integration of viewintegration / cooperation into an overall framework for systems development hasbeen left out of this article. For dialogue-oriented enterprise information systemswe refer to [21], and for WISs to [25].

On a more theoretical basis the new concept of schema dominance and equiv-alence can be the subject of a deeper investigation. In particular, it opens thepossibility to develop even more powerful transformation and augmentation rules


and to investigate the implications on complexity. Such problems are left for fu-ture research.

References

1. Abiteboul, S., and Kanellakis, P. C. Object identity as a query languageprimitive. In Proceedings SIGMOD 1989 (1989), pp. 159–173.

2. Atzeni, P., Gupta, A., and Sarawagi, S. Design and maintenance of data-intensive web-sites. In Proceeding EDBT’98, vol. 1377 of LNCS. Springer-Verlag,Berlin, 1998, pp. 436–450.

3. Biskup, J., and Convent, B. A formal view integration method. In Proceedingsof the 1986 ACM SIGMOD International Conference on Management of Data.Association for Computing Machinery, 1986, pp. 398–407.

4. Ceri, S., Fraternali, P., Bongio, A., Brambilla, M., Comai, S., and Mat-

era, M. Designing Data-Intensive Web Applications. Morgan Kaufmann, SanFrancisco, 2003.

5. Chandra, A., and Harel, D. Computable queries for relational data bases.Journal of Computer and System Sciences 21 (1980).

6. Feyer, T., Kao, O., Schewe, K.-D., and Thalheim, B. Design of data-intensiveweb-based information services. In Proceedings of the 1st International Conferenceon Web Information Systems Engineering (WISE 2000), Q. Li, Z. M. Ozsuyoglu,R. Wagner, Y. Kambayashi, and Y. Zhang, Eds. IEEE Computer Society, 2000,pp. 462–467.

7. Feyer, T., Schewe, K.-D., and Thalheim, B. Conceptual modelling and de-velopment of information services. In Conceptual Modeling – ER’98, T. Ling andS. Ram, Eds., vol. 1507 of LNCS. Springer-Verlag, Berlin, 1998, pp. 7–20.

8. Garzotto, F., Paolini, P., and Schwabe, D. HDM - a model-based approachto hypertext application design. ACM ToIS 11, 1 (1993), 1–26.

9. Hull, R. Relative information capacity of simple relational database schemata.SIAM Journal of Computing 15, 3 (1986), 856–886.

10. Hull, R., and Yap, C. K. The FORMAT model: A theory of database organi-sation. Journal of the ACM 31, 3 (1984), 518–537.

11. Inmon, W. Building the Data Warehouse. Wiley & Sons, New York, 1996.12. Kedad, Z., and Metais, E. Dealing with semantic heterogeneity during data in-

tegration. In Conceptual Modeling – ER’99 (1999), J. Akoka, M. Bouzeghoub,I. Comyn-Wattiau, and E. Metais, Eds., vol. 1728 of LNCS, Springer-Verlag,pp. 325–339.

13. Koh, J., and Chen, A. Integration of heterogeneous object schemas. In Entity-Relationship Approach - ER’93, R. Elmasri, V. Kouramajian, and B. Thalheim,Eds., vol. 823 of LNCS. Springer-Verlag, 1994, pp. 297–314.

14. Larson, J., Navathe, S. B., and Elmasri, R. A theory of attribute equiva-lence in databases with application to schema integration. IEEE Transactions onSoftware Engineering 15, 4 (1989), 449–463.

15. Lehmann, T. Ein pragmatisches Vorgehenskonzept zur Integration und Koopera-tion von Informationssystemen. PhD thesis, TU Clausthal, 1999.

16. Lehmann, T., and Schewe, K.-D. A pragmatic method for the integrationof higher-order Entity-Relationship schemata. In Conceptual Modeling - ER 2000,A. H. F. Laender, S. W. Liddle, and V. C. Storey, Eds., vol. 1920 of LNCS. Springer-Verlag, 2000, pp. 37–51.


17. Lewerenz, J., Schewe, K.-D., and Thalheim, B. Modelling data ware-houses and OLAP applications using dialogue objects. In Conceptual Modeling– ER’99 (1999), J. Akoka, M. Bouzeghoub, I. Comyn-Wattiau, and E. Metais,Eds., vol. 1728 of LNCS, Springer-Verlag, pp. 354–368.

18. Ludascher, B., and Gupta, A. Modeling interactive web sources for informationmediation. In Advances in Conceptual Modeling, P. P.-S. Chen, Ed., vol. 1727 ofLNCS. Springer-Verlag, 1999, pp. 225–238.

19. Qian, X. Correct schema transformations. In Advances in Database Technology -EDBT’96, P. M. G. Apers, M. Bouzeghoub, and G. Gardarin, Eds., vol. 1057 ofLNCS. Springer-Verlag, 1996, pp. 114–126.

20. Schewe, K.-D. The power of media types. In Web Information Systems Engineer-ing – WISE 2004, M. Papazoglou, S. Su, and X. Zhou, Eds., vol. 3306 of LNCS.Springer-Verlag, 2004, pp. 233–238.

21. Schewe, K.-D., and Schewe, B. Integrating database and dialogue design.Knowledge and Information Systems 2, 1 (2000), 1–32.

22. Schewe, K.-D., and Thalheim, B. Modeling interaction and media objects. InNatural Language Processing and Information Systems: 5th International Confer-ence on Applications of Natural Language to Information Systems, NLDB 2000,M. Bouzeghoub, Z. Kedad, and E. Metais, Eds., vol. 1959 of LNCS. Springer-Verlag, Berlin, 2001, pp. 313–324.

23. Schewe, K.-D., and Thalheim, B. Reasoning about web information systemsusing story algebras. In Advances in Databases and Information Systems – ADBIS2004, G. Gottlob, A. A. Benczur, and J. Demetrovics, Eds., vol. 3255 of LNCS.Springer-Verlag, 2004, pp. 54–66.

24. Schewe, K.-D., and Thalheim, B. Structural media types in the development ofdata-intensive web information systems. In Web Information Systems, D. Taniarand W. Rahayu, Eds. IDEA Group, 2004, pp. 34–70.

25. Schewe, K.-D., and Thalheim, B. Conceptual modelling of web informationsystems. Data and Knowledge Engineering 54, 2 (2005), 147–188.

26. Schewe, K.-D., and Zhao, J. Balancing redundancy and query costs in dis-tributed data warehouses – an approach based on abstract state machines. InConceptual Modelling 2005 – Second Asia-Pacific Conference on Conceptual Mod-elling (Newcastle, Australia, 2005), S. Hartmann and M. Stumptner, Eds., vol. 43of CRPIT, Australian Computer Society, pp. 97–105.

27. Schwabe, D., and Rossi, G. An object oriented approach to web-based applica-tion design. TAPOS 4, 4 (1998), 207–225.

28. Sciore, E., Siegel, M., and Rosenthal, A. Using semantic values to facilitateinteroperability among heterogeneous information systems. ACM TODS 19, 2(1994), 254–290.

29. Spaccapietra, S., and Parent, C. View integration – a step forward in solvingstructural conflicts. IEEE Transactions on Knowledge and Data Engineering 6, 2(1994), 258–274.

30. Thalheim, B. Entity-Relationship Modeling: Foundations of Database Technology.Springer-Verlag, 2000.

31. Thalheim, B., and Dusterhoft, A. SiteLang: Conceptual modeling of internetsites. In Conceptual Modeling – ER 2001, H. S. K. et al., Ed., vol. 2224 of LNCS.Springer-Verlag, Berlin, 2001, pp. 179–192.

32. Theodoratos, D., and Sellis, T. Data warehouse schema and instance de-sign. In Conceptual Modeling – ER’98 (1998), vol. 1507 of LNCS, Springer-Verlag,pp. 363–376.


33. Thomson, E. OLAP Solutions: Building Multidimensional Information Systems.John Wiley & Sons, 2002.

34. Turull Torres, J. M. On the expressibility and computability of untypedqueries. Annals of Pure and Applied Logic 108, 1-3 (2001), 345–371.

35. Van den Bussche, J. Formal Aspects of Object Identity in Database Manipulation.PhD thesis, University of Antwerp, 1993.

36. Widom, J. Research problems in data warehousing. In Proceedings of the 4th In-ternational Conference on Information and Knowledge Management (1995), ACM.

37. Zhao, J., and Ma, H. Quality-assured design of on-line analytical processingsystems using abstract state machines. In Proceedings of the Fourth InternationalConference on Quality Software (QSIC 2004) (Braunschweig, Germany, 2004), H.-D. Ehrich and K.-D. Schewe, Eds., IEEE Computer Society Press.

38. Zhao, J., and Schewe, K.-D. Using abstract state machines for distributeddata warehouse design. In Conceptual Modelling 2004 – First Asia-Pacific Con-ference on Conceptual Modelling (Dunedin, New Zealand, 2004), S. Hartmann andJ. Roddick, Eds., vol. 31 of CRPIT, Australian Computer Society, pp. 49–58.

! "#$&% '(*)+ "$,- ./0+ '(-),123'546 "879!

:/;=<?>A@CBEDGFIHKJ9HKLNMPORQSHKTUHWV<?XAY[ZHKL!X+Q+<WL!Y]\Q+<?;=QSH$F=^`_abGcRdedefhgNikjmlonpfrqsdelotugKv$wxjzy|Rqs8ctslo~j/$ClofCjmCffCdef9cqsrfCjKteqsf qslonRc!tsf c!G~R~Kv cRofhqsdtsRjGk!qetsvkfh?f9cRc!jW

? derfh f9k8cRdedefhg cR jqslodtslcRjoqsfCEKtsdijmlonpfhqsdeltug8lfh=vm fC¡mc!qetsfCjKt!yA~¡¢tsfhq$ClofCjmCf

£ odeWc!¢mdefCjdteq W¤~¥ vk¦x ¤p¥R§~¨ lofCIvª©kfrqs8cRjKgtsmcRomfCloklod lojy|!qs8c!tsl ? ¢mjml¦ lofC zf

«¬PC®C¯°W±~®~² £ j/c³mlo~ofCn~fCPRyAc!mdteqEc!htslo~j0c³´"fCGwujyµRqs8c!tsloRj0$gzdtsfC·¶|´]wm¸ 9cRj/?f(fhdehqslo?f9KgcdtsRqegz?pcqE¹vz,mloENlojGc!jcRdteqEcRht c9gde¡?fCClºmfCd,mU,loo»?fk¢mdelojmtsf dgzdtsfCGv$loj,lEN c9gcRjm0y|!qU,lor"Rpc!d ´]mloofdgzjKtEc!¼cRjmdefC8c!j$tsloCd!ydtsRqegz?pcqElojmmcRd?fCfhj½ fCoAfh¼z¡moRqsfC¹vlotsd¡qEc!~8c!tsloCdWc!djRt ?¾ lod¡mcR¡?fhqC~jKteqslom¢ztsfCd,tsmf ºmqsdtdtsfC¡Gts9cqEdCo~delojm8tsmlodpc!¡$gNcRjmcRgzdelojmtsmf(¢mdsc!~f!y+´]we$d $tEcqetsljyµqs~¿cCcRdedelºW9ctslo~j½!ylojKtsfCjKtslo~jd fºmqsdtk¡qsfCdefhj$tUÀ Á Â9ÃUÄEÅ!ÆCÃrÆsvª,mloE9cR¡zts¢qsf,~defhqsnRc!tslo~jdÇ!y¢defhqÇ?fCWc9n$lo~¢qAloj³qsf9c!ltug ´"f,zlodeC¢mdedAtsmf yIc!CfhtsdÇRy¹oloyµfCcRdefCdcRjWU¡qsfCdefCjKtÇcdefCl¦=y|Rqs8c!mcCg³yµRq tsfClqzKC¢mfCjKtEctslRj $È ly|fkCcRdefCd CcRj8?f¢def9lojc¡zqEcR~8ctslo c9gtsUde¡?fChloyÉg8cdtsRqeg8de¡mcRCf~v$,lEld cRjl¡?!qetEcRjKt h~¡?~jfCjKt !yScdtsRqegz?pcqE wxjcdefCC~jmdtsfh¡f C~¡ofCfCjKtoloyµfCcRdefCdU$g`Ê$ÆhÃrËÌ³Í9ÎKÃhÀ Æktsmc!tc!qsf8de¡?fCClºmf9"KgnRc!qsloR¢mdyIcRhfhtsd!ykc!htsRqU¡qs!ºWofCd(tsWc!tUcqsfjfCf9zf9y|!qtsfC ´"fc!jWc!ogzdefc!htsRq¡qs!ºWofCdcRjm¡zqsfCdefCjKtcUdefCl¦=y|!qs8cR?cCgy|!qtsfClqKC¢fCjKtEc!tslo~j ´"f~¢ztslojfkm9]tsfCdefk¡zqsRºWofCd9cRj?fk¢def98ts(de¡?fCClyÉgcRhts!qsdCv,lEc!qsfc!jlo¡?!qetEcRjKt CR¡?~jfCjKt Ry»cdtsRqegz?pcqE Ï lojWc!gKv$ f cRjWc!gdef³ÄEÍ!ÐmÑuÃeÒRÑIÆc!jWtsmfcCg8tsmfhglo¡mcRhtRjNoly|f CcRdefCdCv¢mdefhq,$zfCodcRjmtsmfdts!qeg?~c!qE

Ó ÔÕÖ?×ªØÙ(Ú(Û»ÖªÜEØÕ

ÝßÞ HKàáhXSâxã?L!^<WJF=ãªXäM»åP@9J9H$^5æ Þ áM+çF=@(<?XäF=X+âuã?L!^`<WJFIãªX@9åP@9J9H$^&JQA<WJUOK<?XäàH<?OKOpH$@@9H$YJQSLãª>SèªQ`JQSHTã?L!;=YPBsTFéYSHpBsTUHKàêSëGXì<íQ+F=èªQ;=HKî?H$; ã?â<WàA@9J9LR<?OpJFIãªX]< Þ áMOK<?Xìà HYSH$@OpL!FIà H$Yäàå<í@9J9ã?Lå»à ãª<WL!Yðï|ñ$òósôTQ+FéO!QìF=X]<?X]<WàA@9J9LR<?OpJ8T<zå@õH$OKF=ö+H$@³TQSã"TF=;é;Aà H>+@F=X+èJQSH/@å»@9J9H$^[ô+F=XTQ+F=ORQäT³<$å]<?X+Yìâxã?LTQ+FéO!Qè?ãª<?;=@KêAáhX[<íX»>SJ@Q+H$;=;eôS<ì÷~øsù?úRû¹üùzýWúCþ"OpãªXA@F=@9J@ã?âkJQSLHKH0õA<WLJ@Kÿ

<`÷~øsùWú~û½÷ ýpôPTQAF=O!QäFIJ@9H$;IâOpãªX+@Fé@9J@ã?â,<½Q+FIHKL!<WLRO!Qåíã?â,;=<Wà H$;=;IH$YíY+FIL!H$OpJ9H$Y`è?L!<WõÇQ+@(OK<?;=;=H$Y]÷Çý?ú ùm÷RôSãªX+Hã?âTQ+FéO!QìF=@³JQSH^<?F=X]@!OpH$X+<WL!FIãSôPTQSHKL!H$<?@³JQSHã?JQSHKL!@YSHKöÇXSHGJQSHYSHKJ<?F=;=@³ã?â(÷~÷~ô+FeêH?êXSãPYSH$@GF=X<ìQ+FIèªQSHKLG@OpH$X+<WL!F=ãSô <?XAY < ù?ø JQ+<WJF=@G@9õ H$OKFIö+H$Y àå<?X <?@@FIèªX+^H$X¹JCBsâxLHKH"õ+LãPOpH$@@Kô F=XTQAF=O!QìJQSH0àA<?@F=O<?OpJFIãªXA@8Opã?LLH$@9õ ãªX+YìJ9ã`JQSH0;=<Wà H$;=@³ã?âkH$YSè?H$@FéXìJQSH0@OpH$X+<WLRFIãª@Kô

<í@9HKJã?âýzøsùWú!÷~ôAFeêH?ê+<WàA@J9L!<?OpJFIãªX+@ã?âk>+@9HKLè?Lãª>+õA@³JQ+<WJ8<WLH/YSHKöÇXSH$Yìàå úCù p÷Rô+TQAF=O!Q]YSHKJ9HKLR^F=XSHã?àA;éFIèª<WJFIãªX+@<?X+Y[L!FIèªQJ@Kô+<?X+Y»÷Kú ú9ù ~÷RôTQ+FéO!Q]YSHKJ9HKL!^`F=XSH/>+@9HKLõALHKâuHKL!H$X+OpH$@Kô

<?X+Y <@9HKJ8ã?â³øsým÷÷JQA<WJ<WLH0<?@@ã»OKF=<WJ9H$Y TFIJQù$ý ÷³JQ+H/>+@9HKL!@8^`<$å]Q+<$î?H?ê

áCX<?YAY+FIJFIãªXôzJQSHKLH³<WLH^`<?X¹å0OpãªXA@9J9L!<?F=XJ@ Opãª^íõ+L!F=@!F=XSè@9J<WJFéOWômYSåPX+<?^FéO(<?X+Y½YSHKãªXJF=OUOpãªXA@9J9L!<?F=XJ@âxã?Lõ+L!HpBN<?X+Y õ ãª@9JOpãªX+Y+FIJF=ãªX+@KôJ9L!FIè?è?HKLRF=XSè <?XAY H$X+<WàA;éF=XSè[HKî?H$XJ@Kô L!FIèªQJ@0<?X+Y ã?àA;=F=èª<WJFIãªX+@/ã?âL!ãª;IH$@Kôõ+LHKâxHKLH$X+OpH0L!>+;IH$@³âxã?L>+@HKL8JEå»õ H$@KôA<?X+Y ã?JQSHKLYSHKõ H$X+Y+H$X+OKFIH$@³ãªX[JQ+H/õA;Iã?JKêADNHKJ<?F=;é@ã?â@9J9ã?Lå»àãª<WLRY+F=XSèQ+<zî?HNà HKH$XäYSH$@OpL!FIà H$YäF=X ï|ñ$òósê Ý X`ãî?HKLî»F=HKT¿ã?âãª>SL^HKJQSã»Yäâxã?LUJQSHGYSH$@F=èªXã?â Þ á9MS@(T³<?@õ+LH$@9H$XJ9H$YF=X ï|ñ?ñ~ósê

Þ Q+F=;IH8@å»XJ<<?X+Y@9H$^<?XJF=OK@Uã?â@9J9ã?Lå»àãª<WLRY+F=XSèQ+<?@à HKH$X`TUH$;=;PHPõA;Iã?L!H$YôªFIJ@õAL!<Wèª^<WJF=OK@U<WõA<WLJâxLãª^5JQSHí>+@9H½ã?âU^íHKJ<WõAQ+ã?L!@íï|ñó(Q+<?@GXSã?JKêL!<Wèª^<WJFéOK@F=@NõA<WLJNã?âU@9H$^F=ã?JF=OK@KôTQ+F=ORQ F=@GOpãªX+OpHKLRXSH$YTFIJQ"JQ+H8LH$;=<WJFIãªXA@Q+FIõ"à HKJETHKH$X`@F=èªX+@Kôª@9H$^<?XJF=O8OpãªXAOpHKõ+J@U<?XAYíJQ+F=XSèª@ ã?â LH$<?;éFIJEå?ê¹\Q+F=@ LH$;=<WJF=ãªX+@Q+FIõ

cR¢d¦uklfrtsfhqkzEmfhfcRjWfhqsjWc!qE ¾ WcRofClo

^<zåà H³õAF=OpJ>SL!H$Yà»å½JQSH@9ãWBEOK<?;=;IH$Y@H$^FIã?JF=OK@ J9L!Fé<?XSèª;IH?ê <?FéX"à+L!<?X+ORQSH$@ ã?â@H$^FIã?JF=OK@<WLHG÷~û Aøsý$ø p÷~ôTQ+FéO!QðF=@GOpãªX+OpHKL!X+H$YðTFIJQ JQSH@å»XJ<ô,FsêH?êJQSHOpãªX+@9J9L!>AOpJFIãªXðã?âJQSH;=<?XSèª>+<Wè?H?ô ÷ý Aø p÷~ô,TQ+FéO!QF=@GOpãªX+OpHKL!X+H$Y TFIJQJQSHíF=XJ9HKLõ+LHKJ<WJFIãªX ã?âUJQSH"TUã?LRY+@Gã?â(JQSHí;=<?X+èª>+<Wè?H?ô,<?X+Y ú9ýý?ø p÷~ô,TQ+FéO!Q F=@OpãªX+OpHKL!X+H$Y TFIJQ JQ+H"OK>+LLH$XJN>+@Hã?â(>+J9J9HKL!<?X+OpH$@Gà»å JQSH">+@9HKL<?X+YOpãªX¹J9HPJ/ã?âTã?L!Y+@Nâxã?LGJQSH½>A@9HKL$êLR<Wèª^<WJF=OK@õHKLR^FIJ@8JQ+H>+@9Hã?â<îW<WL!FIHKJrå[ã?â@9H$^<?XJF=OK@NYSHKõ H$X+Y+F=XSèíãªX JQSH½>+@9HKL$ô+JQ+H½<Wõ+õÇ;=F=OK<WJFIãªX<?X+Y JQSH[J9H$O!QAX+F=OK<?;8H$XîPFILãªX+^íH$XJKê ãª@9Jì;=<?XSèª>+<Wè?H$@äYSHKöAXSH$Y FéXãª^íõA>+J9HKLMPOKFIH$X+OpHQ+<$î?H< TH$;=;|BYSHKöAX+H$Yð@9å»XJ<@9ãª^íHã?â³JQSH$^-õãª@!@9H$@@/<]TH$;=;|BEY+HKöAXSH$Yð@9H$^<?XJF=OK@âxHKT6ã?âJQSH$^#>+@9Híõ+L!<Wèª^`<WJF=OK@JQSLãª>+èªQ]TQ+F=ORQìJQSH/^íH$<?X+FéXSè^FIèªQJà H/Y+F HKLH$X¹Jâxã?LY+F HKLH$XJ8>+@9HKLR@Kê

M»åPXJ<?OpJF=OK@(F=@ã?âuJ9H$X`àA<?@9H$YíãªX<0OpãªX+@9J9L!>+OpJF=î?H8ã?L(è?H$XSHKLR<WJFIî?H<Wõ+õ+L!ãª<?O!QÿFIî?H$X`<?X<?;=õAQ+<Wà HKJ<?X+Y<?Xì@9HKJã?âOpãªX+@9J9LR>+OpJ9ã?L!@Kô»JQSHG;=<?XSèª>+<Wè?HF=@YSHKöAXSH$Y<?@JQSHG@9HKJ³ã?â,H»õALH$@@FIãªXA@(JQ+<WJ³OK<?Xìà Hè?H$XSHKLR<WJ9H$Yà»åäJQSHOpãªX+@9J9L!>+OpJ9ã?LR@KêãªX+@J9L!>+OpJFIãªX+@^`<$åìà H/YSHKöAXSH$YìãªX]JQ+HàA<?@F=@ã?âkè?L!<?^^`<WJF=OK<?;,L!>A;IH$@Kê

M»H$^`<?X¹JF=OK@ã?â,è?H$X+HKL!<WJFIî?H/;=<?XSèª>A<Wè?H$@OK<?Xìà HH$FIJQSHKLYSHKöAXSH$Yäà»å`^íHKJ<mBE;=F=X+èª>+F=@9JF=O@9H$^<?XJF=OK@KôPH?êèSê>+@9H$Yâxã?L`YSHKöÇX+F=XSèJQSH @9H$^`<?X¹JF=OK@ã?âõ+L!H$Y+F=OK<WJ9H[;Iã?èªF=OK@$ôàå õ+LãPOpH$Y+>SL!<?;³ã?L`LHKâuHKL!H$X¹JF=<?;@H$^<?X¹JFéOK@KôH?êèSê,ã?õ HKL!<WJFIãªXA<?;k@H$^<?X¹JFéOK@/>+@9H$Yâxã?L/YSHKöAX+F=X+è`JQSH@9H$^`<?X¹JF=OK@Gã?âõ+Lã?è?LR<?^^F=XSèì;=<?XSèª>A<Wè?H$@Kôã?LàåOpãªXî?H$X¹JFIãªXSBsàA<?@9H$Y @9H$^<?XJF=OK@>A@9H$Y F=X ;éF=XSèª>+F=@JF=OK@Kê,M»H$^<?XJF=OK@0F=@/ã?âuJ9H$X YSHKöAXSH$YðãªX JQSHàA<?@!F=@ã?â8<@9HKJ8ã?âkLH$;=<WJF=ãªX+<?;,@9J9L!>AOpJ>SLH$@JQ+<WJ8Opã?L!LH$@9õ ãªX+Y]J9ãJQ+H/@FIèªX+<WJ>SL!Hã?âkJQ+H/;=<?XSèª>+<Wè?H?ê

(L!<Wèª^<WJF=OK@Q+<?@J9ãà H/Y+F=@JF=XSèª>+F=@!QSH$Y`âxLãª^ õAL!<Wèª^<WJF=@^[ê L!<Wèª^<WJFé@^ ^íH$<?X+@<íõ+L!<?OpJFéOK<?;,<WõSBõ+Lãª<?ORQJ9ã0õ+Lã?àÇ;IH$^@ã?L³<<?FIL!@Kê Ý OKOpã?L!YAF=XSè0J9ã Þ HKàA@9J9HKL/ï|ñóõ+L!<Wèª^`<WJF=@^6Fé@JQSHCàA<?;=<?X+OpHà HKJETHKH$Xõ+L!FéX+OKFIõA;IH$@N<?X+Y õ+L!<?OpJF=OK<?;>A@<Wè?HPêHKLHTH`<WLHOpãªX+OpHKL!XSH$Y TFIJQðõAL!<Wèª^<WJF=OK@KôTQ+F=ORQðF=@àA<?@9H$Y ãªXJQSH/à H$Q+<zî»F=ãª>SL8<?X+Y]YSH$^<?XAY+@ã?â >+@9HKL!@KôSJQ+HKLHKâuã?L!H0YSHKõ H$X+Y+@ãªX[JQ+H/>+X+YSHKL!@J<?X+Y+F=XSè½ã?â >+@9HKL!@Kê

\8Q+H0@F ]O!Q+<WLR<?OpJ9HKL!F=@9JF=OK@ã?â Þ á9MP@JQ+<WJTHKLH½Y+F=@OK>+@!@9H$Y]F=X ï|ñ$òóOK<?X à H0^`<Wõ+õ H$Y]J9ãäOpãªX+OpHKõAJ>+<?;@9J9L!>AOpJ>SLH$@JQ+<WJ<WLH/>+@9H$Y]âxã?L@9J9ã?L!åà ãª<WL!Y[@õH$OKF=öAOK<WJFIãªXÿñWê Þ H0@J<WLJTFIJQJQSHO!QA<WL!<?OpJ9HKL!F=@9JFéOK@8>+@9H$Yìâxã?LJQSH/@9J9L!<WJ9HKèªFéO;=<$å?HKL$ê <?F=X]@9õ H$OKFIöÇOK<WJFIãªXìH$;IH$^íH$XJ@>+@H$Y[<WLH0F=XJ9H$XJFIãªX[<?X+Y ^F=@@F=ãªXê»\QSHKå]<WLH0^<Wõ+õ H$YìJ9ã^íHKJ<WõAQSã?L!@$ô+è?H$XSHKL!<?;è?ãª<?;é@KôAL!Q+HKJ9ã?L!F=OK<?;ö+èª>+LH$@Kô+<?X+Y]õÇ<WJ9J9HKL!X+@8<?X+Y[è?L!F=Y+@³ã?âkTUHKà õA<Wè?H$@YAF=@OK>+@@H$Y;é<WJ9HKL$ê

ò»ê\8Q+H½@OpH$XA<WL!FIãª@LH+H$OpJGJQSH">SJF=;=F=@!<WJFIãªX]à»å <?OpJ9ã?L!@Kôâxã?LTQ+F=O!Q THH$Xî»Fé@FIãªX<äX»>+^àHKLNã?â(@9J9ã?LRFIH$@JQ+<WJ]Opã?LL!H$@9õ ãªX+Y J9ãLH$<?;G>+@H?ê\8Q+H$@9H@!OpH$X+<WL!FIãª@]^<zå à HOK<WõAJ>SLH$Y¿JQSLãª>SèªQ¿ã?àA@HKLîm<WJF=ãªXã?âLH$<?;éFIJEå?êAM»J9ã?Låä@9õA<?OpH$@<?X+YõA;Iã?J@<WLHGLH$Opã?L!Y+H$YFéX`îW<WL!FIãª>+@;IHKî?H$;ã?âY+HKJ<?F=;AJQ+Lãª>SèªQJQSH^íHKJQSãPY+@Y+Fé@OK>+@@9H$Y]FéX ï|ñ$òósêÇ\8QSH@9J9ã?LRFIH$@<WLHL!H+H$OpJ9H$Y F=XìJQ+H0@9J9ã?Lå»à ãª<WL!Yê

êãªXJ9H$XJ@9õ H$OKFIöAOK<WJFIãªX]Fé@UJQ+HàA<?@F=@³âxã?L8JQSH/^íH$YAF=<½JEå»õH$@$ô+FeêH?ê+Y+<WJ<"JEå»õ H$@8<?X+YìJQSH$F=Lâx>+XAOpJFIãªX+@KôTQAF=O!Q"TFé;=;»àH8FéX¹J9LãPY+>+OpH$Y"F=X"õÇ<WLJááá~êWárJOpãª^àAF=X+H$@Y+<WJ</@9õ H$OKFIöÇOK<WJFIãªX"TFIJQí>+@HKLLH»>+FILH$^íH$XJ@<?X+Y F=@³LH+H$OpJ9H$Y F=XìJQSH0OpãªXJ9H$X¹Jõ ã?LJ9âuãª;éFIãSê

Sê +>AX+OpJFIãªX+<?;=F=JEåF=@(õ+LãzîPF=YSH$Y`àåíJQ+H^íH$Y+Fé</JEå»õ H$@U<?@ULH»>+FILH$YàåíJQSHG@9J9ã?Lå»à ãª<WL!Yê¹\Uå»õAF=OK<?;@9J<?XPBY+<WLRY0â>+X+OpJFIãªXA@<WLH³X+<zî»FIèª<WJF=ãªXôL!HKJ9L!FIHKîW<?; æ@H$<WL!O!QÇçRô?@>+õ+õ ã?LJ,â>+X+OpJFIãªX+@$ô<?X+Y½âxHKH$YSàA<?O"!0âx<?OKF=;éFIJFIH$@Kê

»êãªXJ9HPJF=@`àA<?@9H$YãªX J<?@"!»@KôQ+F=@9J9ã?L!å?ôU<?X+Y H$X¹îPFILãªX+^H$X¹JKê Þ H >A@9H[JQSH@9õ H$OKFIöAOK<WJFIãªX ã?â/OpãªXPBJ9HPJ0âxã?L0LH$@J9L!>+OpJ>SL!FéXSè[<?X+Y â>+X+OpJF=ãªX+<?;=FIJrå H$X+Q+<?XAOpH$^íH$X¹JKôTQ+F=ORQðTF=;é; âuã?L!^JQSHàA<?@!F=@ã?â$#M&%J9L!<?XA@9âuã?LR^<WJFIãªX+@8<?XAYìJQSH/ãªX+FIãªX <Wõ+õ+Lãª<?ORQ]JQ+<WJF=@Y+F=@OK>+@!@9H$YìF=XìJQSH0;=<?@JõA<WLJã?â JQSHà ãã!ê

»ê (LH$@9H$XJ<WJFIãªX Y+HKõH$XAY+@8ãªX JQSHF=XJ9H$XJFIãªXôAJQ+H0õ+Lãî»FéYSHKL$ô+JQSHJ9H$O!Q+XAF=OK<?;H$XîPFILãªX+^íH$XJ<zîm<?Fé;=<WàA;IH<?X+Y[JQSH0>+@9HKLR@JQSH Þ á9M[F=@³J<WLè?HKJF=X+èä<WJKê(LH$@9H$XJ<WJFIãªX[L!H$@>+;IJ@F=X[JQSH0;=<zå?ãª>SJ<?X+Y JQSH/õA;=<zå?ãª>SJã?âJQ+H Þ á9M ê('ýWûªù SøL!H>+F=LH$@JQ+H½YSHKî?H$;=ã?õA^íH$XJã?â(^½>+;IJFé^íH$Y+F=<íõALH$@9H$XJ<WJFIãªX+@Nâuã?LGH$<?ORQ õA<Wè?H?ê) ýWûªù SøS<?Y+YAFIJFIãªX+<?;=;=åNL!H>+F=LH$@kJQSHYSHKî?H$;Iã?õA^íH$XJã?âAâ>+X+OpJF=ãªX+<?;=FIJråJQ+<WJ@>Sõ+õ ã?LJ@îPF=@FIJ@kã?âÇ>A@9HKL!@YSHKõ H$X+YAF=XSè[ãªX JQSH]@9J9ã?Lå JQSHKå <WLHìOK>SLL!H$X¹J;Iå âuãª;=;=ãzTF=X+è J9ãð<?O!Q+F=HKî?HJQ+H$FIL"è?ãª<?;=@Kê*%<zå?ãª>SJ<?X+YõA;é<$å?ãª>SJGF=XJ9HKè?L!<WJ9HíJQSH"O!QSãª@9H$X ^íHKJ<WõÇQSã?L!@JQSHKå YSHKõ H$X+Y ãªX O!QSãª@9H$X õÇ<Wè?HõA<WJ9J9HKLRX+@G<?X+Y è?LRF=Y+@<?@TUH$;=;<?@ãªX+»>+<?;=FIJråäLH»>+FIL!H$^íH$X¹J@$êãªXAOpHKõ+J>+<?;S@9J9L!>AOpJ>SLH$@<?X+Y"JQSH$F=L <?@!@9ã»OKFé<WJFIãªXí<WLH8YSHKõAFéOpJ9H$YíF=X,kF=èª>SLHñWê Þ H8^<$å"@9HKõA<WLR<WJ9H8JQSH

@9åPX¹J<?OpJFéOK@U<?X+Yõ+L!<Wèª^<WJF=OK@(;=<$å?HKL!@$ê Ý LLãzT@<WLH>+@H$Yíâuã?LULHKõ+LH$@H$X¹JF=X+èõA<WLJCBsã?âuBã?LU>+@H$@CBã?LLH$;é<WJ9H$@CB

qEc!~8c!tsloCd,!yÇ$tsRqegz?~c!qElojy|!q´½fCNwujyµRqs8c!tsloRj/$gzdtsfCd wmidscRRfjWc!gdelod <?@@9ãPOKF=<WJFIãªXA@Kê Sã?L F=X+@J<?X+OpH?ô³JQSH @9J9ã?Lå¿F=@ìàA<?@9H$YßãªXßJQSHð>+@HKL[<?X+Y¿JQSHðâx>AX+OpJFIãªX+@KêáCXSâuã?LR^<WJFIãªX^íHKJ<WõAQ+ã?L!@LH$;=<WJ9HOpãªX¹J9H$XJJ9ã`FéXSâuã?LR^<WJFIãªXê

¾ fCEmjmlo9c!fhjzn$lqs~jfCjKtRyPtsf¢mdefhq

idefhq

c!tEcqsfh¡qsfCdefCjKtEctslRj

c!tEc Ï ¢mjhtslo~jmd

Ï ¢mjhtslo~jqsfC¡qsfhdefCjKtEc!tslo~j

wxjzy|Rqs8ctslo~j

$ts!qeg

Rj$tsfhj$t

Ï ¢mjmrtslRjWc!ltug

È cCgKR¢t

c9gp~¢t

wxjzy|!qs8c!tslo~jfrtEcR¡mRqsd

$tsRqegc!jWy|¢jmhtsloRjWcRoltxgfhtEcR¡mRqsd

Ã(Ê$ÑIÁIÀ Á|ÆrÅRÑIÁ=Í!Ð0Æ! zÅpÄEÃ

" #$ %&$ '()*

+ ,- '$ ) '()*

.0/21 ²43W²¹¾ mf ´½fCNitslolo9ctslRj0z¡mcRCfcRdef9 £ jtsmfmc!qEcRrtsfhqslodtslhdkRyS´ìwe

Þ H½>+@9H/JQSH½XSã?JFIãªX+@8ã?â FéXSâuã?LR^<WJFIãªX[<?X+Y OpãªX¹J9H$XJNFéX[<`@9õ H$OKFIöÇO^<?X+XSHKL$ê6587pùWú ý?ø ù <?@õ+LãWBOpH$@@9H$Y à»å[Q>+^`<?X+@Kô+F=@OK<WLL!FIH$Y àå þªýªøsýìJQ+<WJFé@8õ HKL!OpH$FIî?H$Y ã?LXSã?JF=OpH$Y,ôÇ@9H$;IH$OpJ9H$Y<?X+Y ã?Lèª<?X+F:9KH$Y àåFIJ@ULH$OpH$FIî?HKL$ôPà H$OK<?>+@9HNã?â,Q+F=@@>Sà;CH$OpJFIî?HGQ»>+^<?X`FéX¹J9HKLH$@J@KôPã?L!FIèªF=X+<WJFéXSè/âxLãª^3QAF=@UFéX+@9JF=X+OpJ@$ôªâuHKH$;éF=XSèª@KôHPõHKLRFIH$X+OpH?ô,F=XJ>+FIJFIãªX,ô Opãª^`^íãªX @9H$XA@9H?ô,îW<?;=>SH$@Kô,à H$;=F=HKâx@Kô õ HKL!@9ãªXA<?; !»XSãT;IH$YSè?H?ôã?L0TF=@!YSãª^]ô,@F=^½>+;|BJ<?XSHKãª>+@!;Iå õ+L!ã»OpH$@@H$Y àåQ+F=@GOpã?èªX+FIJFIî?H<?XAY^H$X¹J<?;õALã»OpH$@!@9H$@Kô<?X+Yð@9H$<?^;=H$@@;Iå FéX¹J9HKè?L!<WJ9H$Y F=X Q+F=@LH$OK<?;=;é<WàA;IH,!»X+ãzT;IH$Y+è?H?êãªXJ9H$X¹J½F=@Opãª^íõA;IH <?X+Y L!H$<?YSå¹BsJ9ãWBE>A@9HäY+<WJ<Pê ãªX¹J9H$XJ^`<?X+<Wè?H$^íH$XJ@9åP@CBJ9H$^@8<WL!H/F=XSâxã?L!^<WJFIãªXì@9åP@9J9H$^@JQA<WJ8@>Sõ+õ ã?LJH»J9LR<?OpJFIãªXô+@9J9ã?L!<Wè?H<?X+Y]YSH$;=FIî?HKL!å`ã?â Opãª^íõA;IHìY+<WJ<PêãªXJ9H$X¹JN^<$å]à H/H$XAQ+<?X+OpH$Y[à»å !ù øx÷½JQ+<WJN@9õ H$OKFIâxåäJQSH@9H$^<?XJF=O0^íH$<?XAF=XSèíã?âOpãªXJ9H$X¹JNã?à<;9H$OpJ@<?X+Y]à»å øsù p÷0JQ+<WJ@9õ H$OKFIâuåäJQSHõ+L!<Wèª^`<WJF=O/>+X+Y+HKL!@9J<?X+Y+FéXSèã?â >+@9HKLR@Kê

\8Q+HKLHKâuã?L!H?ôWFéXSâuã?LR^<WJFIãªX0Fé@kYAFILH$OpJ9H$Y½J9ãzT³<WL!Y+@ õ+LR<Wèª^<WJF=OK@KôWTQSHKL!H$<?@kOpãªXJ9H$XJ^<$åàH³OpãªX+@FéYSHKLH$YJ9ã QAFIèªQ+;=FIèªQJGJQSH`@9åPXJ<?OpJF=OK<?;UYAF=^íH$X+@F=ãªXê árâ³OpãªX¹J9H$XJ"F=@H$X+Q+<?XAOpH$Y à»å OpãªXAOpHKõ+J@<?XAYðJ9ã?õAF=OK@KôJQSH$X>+@9HKLR@N<WL!H<WàA;IH"J9ã[OK<Wõ+J>SLHíJQ+H"^H$<?X+F=XSè]<?X+Y JQSHí>SJFé;=F=@<WJFIãªX ã?â(JQ+HY+<WJ<ìJQSHKå L!H$OpH$FIî?H?ê,áCX ã?LRYSHKLJ9ã]H$<?@9Hõ HKL!OpHKõAJFIãªXTUH>+@H $øsý >= ùWúR÷?ê HKJ<WõAQSã?LR@/^<$åà Hí@9HKõA<WL!<WJ9H$Y FéX¹J9ã]JQSãª@HíJQ+<WJ/@>Sõ+õ ã?LJõ HKL!OpHKõ+JFIãªXìã?âF=X+âuã?L!^`<WJFIãªXì<?X+Y[F=XJ9ãJQSãª@9HJQA<WJ@>Sõ+õ ã?LJ>+@!<Wè?H/ã?L8â>+X+OpJFIãªX+<?;éFIJEå?ê

?N@9HKL!@ä<WLH LHAH$OpJ9H$Y à»å<?OpJ9ã?LR@`JQ+<WJ<WLH <WàÇ@9J9L!<?OpJFIãªX+@`ã?âGè?Lãª>SõA@íã?â/>A@9HKL!@Kê (L!<Wèª^<WJF=OK@<?X+Y@9åPX¹J<?OpJFéOK@[@Q+<WLH Y+<WJ< <?X+Y¿â>+X+OpJFIãªXA@Kê\QSH â>+X+OpJF=ãªX+<?;=FIJrå F=@äõ+LãzîPF=YSH$Y¿JQSL!ãª>SèªQ¿âx>+XAOpJFIãªX+@ì<?X+YJQSH$FILL!HKõ+LH$@9H$XJ<WJFIãªX+@KêS\8Q+HNTHKà >SJFé;=F=@<WJFIãªX@9õA<?OpH/Y+HKõH$XAY+@(ãªX[JQSHGJ9H$O!Q+X+FéOK<?;H$X¹îPFILãªXA^íH$X¹J³ã?âkJQSH>+@9HKLzêáhJFé@U@9õ H$OKFIöAH$YJQSLãª>+èªQäJQ+HN;=<zå?ãª>SJ<?X+YäJQSHGõA;=<$å?ãª>+JKê%<$å?ãª>SJõA;é<?OpH$@OpãªXJ9H$XJãªXäJQ+HàA<?@!F=@(ã?â<]Y+<WJ<]L!HKõ+LH$@9H$XJ<WJFIãªX <?X+Y F=X YSHKõ H$X+YSH$X+OpH"ã?â³JQSHíJ9H$O!QAX+F=OK<?;H$Xî»F=LãªX+^íH$XJKê (;=<zå?ãª>SJ/F=@GàA<?@H$YðãªXâ>+X+OpJFIãªX+<?;éFIJEå<?X+Y]â>+X+OpJFIãªXìLHKõALH$@9H$XJ<WJFIãªX+@Kô+<?X+Y YSHKõ H$X+Y+@ãªX[JQSHJ9H$ORQ+X+F=OK<?;H$X¹îPFILãªXA^íH$X¹JKê

Þ H^`<$å"àA<?@9HJQSHõ+L!<Wèª^<WJF=OK@ã?â@9J9ã?L!åà ãª<WL!Y+FéXSèGãªXíJETã0F=XSè?L!H$Y+FIH$XJ@ JQ+<WJ(<WLHH$<?@9å"J9ã0Y+HKî?H$;Iã?õ,ÿ

@BADCFE0GIHJKHLNMGIHPOQSR0OTUG:VWOJKHPOYX>Z\[]ADCY^`_]acb \8QSH/>SJFé;=F=@<WJFIãªXõ ã?LJ9âxãª;=FIãíOpãªX+@Fé@9J@³ã?â J<?@"!»@>+@9HKL!@8^`FIèªQ¹JTF=@QJ9ã`<?OKOpãª^íõA;éF=@Q]TF=JQ+F=XäJQSH0@9åP@9J9H$^]ô è?ãª<?;é@8ã?â>+@9HKLè?Lãª>+õA@Kô+FeêH?êA<?OpJ9ã?LR@KôA<?X+Y <?OpJ9ã?LR@JQ+<WJ^FIèªQJ8>+@9HJQSHTHKà F=X+âuã?L!^`<WJFIãªXì@9å»@J9H$^]ê

@BADCYRdT8O]efJKghLiX6Z\[jAkCmlDnoCqp]nNb Lã?öÇ;IH$@Gã?â>A@9HKL!@YSH$@OpLRFIà H½JQ+H$FIL/<WàAF=;=F=JFIH$@Kô @ !»Fé;=;=@Kô!»X+ãzT;IH$Y+è?H?ô<?X+Yã?JQSHKLNY+F=^íH$XA@FIãªX+@Kê Þ H0^<Wõ >+@9HKL8õ+L!ã?öA;IH$@³J9ãõ+L!HKâuHKLH$XAOpHL!>+;IH$@³âxã?L>SJF=;éF=@<WJFIãªXã?â@9åP@9J9H$^@Kê

¤ cR¢d¦uklfrtsfhqkzEmfhfcRjWfhqsjWc!qE ¾ WcRofClo

Þ HGö+L!@JOpãªX+@!F=YSHKLJQSH$@9HNàA<?@F=O >SH$@JFIãªX+@KêP\8QSHKå<WLHGLH$;é<WJ9H$YäJ9ã½JQSH@9J9L!<WJ9HKèªFéON<?XAY`JQSHNàA>+@!F=XSH$@@;=<zå?HKL!@KôÇ@ãJQSHKå]<?;=@9ã`QA<$î?H<?X F=^íõA<?OpJãªX JQSH0@9J9ã?L!åà ãª<WL!Yê8HKöAXSH$^H$X¹J<?XAY[>SJF=;=F=JEå`J< !?H">+@J9ãäJQSHOpãªX+OpHKõ+J>A<?;;=<zå?HKL$ê

áCX·JQ+F=@]<WL!JF=OK;IHðTH <Wõ+õ+Lãª<?ORQ JQSH <?X+<?;IåP@F=@ìã?â Þ áM·>+@!<Wè?H <?@]JQSH öAL!@9J[F=^íõ ã?LJ<?XJìõA<WLJ[ã?â@9J9ã?Lå»à ãª<WL!Y+F=X+èõ+L!<Wèª^<WJFéOK@Kê Ý âxJ9HKLG<äà+L!F=HKâkL!HKî»FIHKT ã?âLH$;é<WJ9H$Y Tã?L"! FéX[JQSH";=FIJ9HKL!<WJ>+LHF=X M»H$OpJFIãªXðòTHíö+L!@9J;Iã»ã! <WJ/F=XJ9H$XJFIãªX+@GJQ+<WJ/<WLH<?@!@9ã»OKFé<WJ9H$YðTFIJQJQSH Þ á9M ô <?XAYðOK;=<?@@FIâxå[JQSH$^>+@F=XSèâ<?OpHKJ@âxã?LNõÇ>SLõ ãª@9H?ô F=X¹J9H$XJKô JF=^íH"<?X+YLHKõ+LH$@H$X¹J<WJFIãªX,ôJQ+H½öAL!@9JNã?â(TQ+FéO!Q T<?@<?;IL!H$<?YSå Y+Fé@OK>+@@9H$Y F=XJQSH@9J9L!<WJ9HKèªFéO^íãPYSH$;ã?â Þ áMP@ïzósê \8QSH$@9H0âx<?OpHKJ@Nã?âF=XJ9H$X¹JF=ãªX+@8âxã?L!^ JQ+H0àA<?@Fé@âuã?LNJQSHâuãª;=;=ãzTF=X+èíJQSLHKH@9H$OpJFIãªXA@KôFéX TQAF=O!Q TUH"F=XJ9LãPY+>+OpH;éFIâuH½OK<?@9H$@Kô>+@9HKLG^íãPYSH$;=@N<?X+YOpãªX¹J9HPJ@KêM»H$OpJFIãªX ìF=@NYSHKî?ã?J9H$Y J9ãJQSH8Y+Fé@OK>+@@F=ãªX/ã?â 7 Rým÷p÷Rô?TQ+FéO!Q"OK<Wõ+J>SLHã?àÇ@9HKLîW<WJFIãªX+@ ã?â >+@9HKL à H$Q+<$îPFIãª>SLF=X½LH$<?;=F=JEå?ê Þ HY+Fé@OK>+@@JQSHäâx<?OpHKJ@ã?â;=FIâxHOK<?@9H$@½JQ+<WJF=^õA<?OpJ/ãªX JQ+H`YSH$@FIèªX ã?â8@9J9ã?Lå»àãª<WLRY+@/<?X+Y õ+LH$@9H$XJ0< @H$^F|Bsâxã?L!^<?;T³<$å]âxã?LJQSH$F=LYSãPOK>+^íH$XJ<WJFIãªXê%FIâuHOK<?@9H$@OK<?X à H0>+@9H$Y F=X[<õAL!<Wèª^<WJF=O0T<zå]J9ãä@9õ H$OKFIâxåäJQ+H@9J9ã?Lå@9õA<?OpH?ê\8Q+HTã?L"! ãªX ;=F=âuH½OK<?@9H$@GH»J9H$XAY+@<`õALHKî»F=ãª>+@OpãªX+âuHKLH$XAOpH½õÇ>SàA;=F=OK<WJF=ãªX ïósêáCX M»H$OpJF=ãªX THOpãª^íõA;=H$^íH$X¹J;=FIâxH/OK<?@9H$@à»å ÷pú ù$þ ÷8JQ+<WJ<WLH@9õ H$OKFIö+H$Yìà»åì>A@9HKL<?X+Y <?OpJ9ã?Lõ+L!ã?öA;IH$@KôS<?X+Y <?OpJ9ã?Lõ ã?LJ9âxãª;=FIãª@Kê Þ H<?XA<?;Iå»@H/<?OpJ9ã?Lõ+L!ã?öA;IH$@<?X+Y]õALH$@9H$XJ8<@9H$^F|Bsâxã?L!^<?;,T<zåâxã?L8JQSH$F=LYSãPOK>+^íH$XJ<WJFIãªXê\8QSH½<?OpJ9ã?LGõã?L!J9âuãª;=F=ãª@<WLH">+@9H$Y J9ãäè?HKJ<à HKJ9J9HKL>+X+Y+HKL!@9J<?X+Y+FéXSè"ã?âJQSH0J<?@"!»@G<?@@9ãPOKF=<WJ9H$YTFIJQ JQSHÞ á9Mê\QSHìTUã?L"! ãªX >+@HKL^íã»Y+H$;=@½H»J9H$X+YA@< õ+LHKîPFIãª>+@íOpãªXSâxHKLH$X+OpH]õÇ>SàA;=F=OK<WJF=ãªX¿ï|ñmósê kFéX+<?;=;Iå?ô F=XM»H$OpJFIãªX TUH]<?X+<?;=å»@9H!ù Aø ¹øx÷<?X+Y JQSHT<zå JQSHKå Fé^íõA<?OpJ½ãªX ;éFIâuHOK<?@9H$@Kô>+@9HKL"^íãPYSH$;=@½<?X+Y JQSH@9J9ã?Lå»à ãª<WL!YêSáCX M»H$OpJFIãªXTUH0OpãªXAOK;=>+YSHTF=JQ]<íà+L!FIHKâk@>+^^`<WLåä<?X+Y <íY+F=@OK>+@!@FIãªXã?â ã?õH$X]Fé@@>SH$@Kê

Ö AÙ Ø,×

M»J9ã?Lå»à ãª<WL!Y+F=X+èì<?XAY <?;=@9ã JQSHõ+L!H$OpH$Y+F=XSè[@9J9LR<WJ9HKèªF=Oä^ã»YSH$;é;=F=XSèìã?â Þ áM ïzó<WLH`>AX+F »>SHíJ9ã ãª>SL½<WõSBõ+Lãª<?ORQ J9ã Þ á9M ^íãPYSH$;=;=F=X+èSê+ëGJQSHKLN<WõAõ+Lãª<?O!Q+H$@J9ã Þ áM[H$XSèªF=XSHKHKL!FéXSè@>+ORQ <?@JQSH0ã?à;CH$OpJNã?L!FIH$XJ9H$Yë/ë ND #ï Sô»ôzñWósô Þ HKà % ï|ñ~ósô Ý ï óÇ<?X+Y"îW<WL!F=<?XJ@ã?â ? % ïò»ô óOpãªX+OpH$X¹J9LR<WJ9HãªXíõ+L!ãzîPF=Y+F=XSè^íãPYSH$;=@ã?â OpãªX¹J9H$XJKôAX+<zî»FIèª<WJF=ãªX[<?X+YìF=XJ9HKL!<?OpJFIãªX]à»åä^íH$<?XA@³ã?âHPJ9H$X+YSH$YìîPFIHKT@KôPTQAF=O!QìF=Xãª>SLãTXTã?L"! F=@½OK<Wõ+J>SLH$Y à»å @9ãWBEOK<?;=;=H$Y !þ ý øû ~÷ï|ñ$òósêUëX+;Iå Þ MSD ï óH$^íõAQ+<?@Fé@9H$@0JQ+H<?Y+YAFIJFIãªX+<?;XSHKH$Y]âxã?L<^`F=@@FIãªXì@9J<WJ9H$^H$X¹JN<?X+Y[<Q+F=èªQPBE;IHKî?H$;YSH$@OpLRFIõ+JFIãªXìã?âkõ+LãPOpH$@@9H$@8<?XAY[>+@9HKL!@F=XìJQSH Þ á9Mê

[8X CUX "!$#KC% C'&[8C'(

) *+Û% SÖ,[Ø.-/ÔmÕÖ/ ÇÕÖªÜEØÕ

\8QSHYSH$@OpL!FIõAJFIãªXíã?â,F=XJ9H$X¹JF=ãªX`F=@(àA<?@9H$YãªX<0OK;=H$<WLU>+X+Y+HKL!@9J<?X+Y+FéXSèGã?â,<?F=^@(<?XAYJ<WLè?HKJ@ã?âJQSH Þ áMF=X+OK;é>+Y+F=XSè½<@9õ H$OKFIöAOK<WJF=ãªX]ã?â;IãªXSèWBsL!<?XSè?H<?X+Y[@QSã?L!JCBsJ9HKL!^ J<WLè?HKJ@$ôAHPõH$OpJ9H$Y î»Fé@FIJ9ã?L!@Kô+ORQ+<WL!<?OpJ9HKL!Fé@CBJF=OK@Gã?âUJQ+F=@G<?>+Y+FIH$XAOpH?ôJ<?@"!»@Gõ HKLâxã?L!^íH$Yà»å[JQSH>+@9HKLR@KôX+H$OpH$@@<WLå <?X+Y >+X+XSH$OpH$@!@<WLå OpãªXJ9H$X¹JKôk<?X+YöAX+<?;é;Iå`<?X >AX+YSHKL!@9J<?XAY+F=XSèã?âkL!H$@9J9L!F=OpJFIãªXA@³ã?â >A@<Wè?H?ê

?JF=;=F=@!<WJFIãªXì@OpH$X+<WL!FIãª@<WL!H/YSHKî?H$;Iã?õ H$YìãªX]JQSHàA<?@!F=@ã?âkF=XJ9H$XJFIãªX+@Kê Ý X[F=XJ9H$X¹JFIãªX]@õH$OKF=ö+H$@TQ+<WJãªXSHõA>SLõ ãª@9H$@J9ã½<?OKOpãª^íõA;=Fé@Qã?L³YSãSô¹FeêH?êãªXSHQA<?@UF=X`^F=X+YíJ9ã½YSã0ã?Là+L!FéXSè/<Wà ãª>SJKêªáhJUQ+<?@Uâuãª>+L(â<?OpHKJ@JQ+<WJ<WL!H/àA<?@9H$Y]ãªX[JQSH/è?H$XSHKL!<?;O!Q+<WL!<?OpJ9HKLRF=@9JF=OK@<?X+Y+»>SH$@9JFIãªX+@YAF=@OK>+@@H$Y]F=X ïzósÿ

0 lkp1! X>noCmZ324UCW[Wb \QSH Pú ùm÷ðã?â/@9J< !?H$Q+ãª;=YSHKL!@ì@9õ H$OKFIö+H$@ä<?X<?XJF=OKFIõÇ<WJ9H$Y ãª>SJOpãª^HJQA<WJF=@äF=XPBJ9H$X+Y+H$Yðã?L0JQ+<WJ0èª>+F=YSH$@JQ+HõA;=<?X+X+H$Yð<?OpJFIãªX+@Kê,áhJ/^<zåðàHíàÇ<?@9H$YðãªX JrTUã<?Y+Y+FIJF=ãªX+<?;kõAFIH$OpH$@/ã?âF=X+âuã?L!^`<WJFIãªXÿ \QSHGý ½÷@9õ H$OKFIâuåTQ+<WJkFé@kFéX¹J9H$X+Y+H$Y0J9ãGà HU<WJ9J<?F=X+H$Yí<?X+Y0TQ+<WJkFé@à H$;=FIHKî?H$YJ9ãGà H<WJ9J<?F=XA<WàA;IH?ê \QSHù¹ü65 zø 87 ~÷/<WLH/^íã?LHè?H$X+HKL!<?;JQ+<?XìJQSH/<?Fé^@KêS\8QSHKå@9õ H$OKFIâuå@9ãª^íHKJQ+FéXSè"J9ãzT³<WL!Y]TQ+FéO!Q<?X Hã?L!JF=@Y+FIL!H$OpJ9H$YôSH?êèSêAè?ãª<?;=@ã?L8H$X+Y+@³ã?â<?X[<?OpJF=ãªXê

qEc!~8c!tsloCd,!yÇ$tsRqegz?~c!qElojy|!q´½fCNwujyµRqs8c!tsloRj/$gzdtsfCd wmidscRRfjWc!gdelod

\8Q+H(õA>SL!õãª@H(F=@k<?;ILH$<?YSå/@9õ H$OKFIöAH$Y0<WJkJQSH@J9L!<WJ9HKèªF=O³;=<$å?HKLzêáhJkY+HKõH$XAY+@,ãªXJQSHý +þ 8F=XJ9H$X+YSH$Yâxã?L8JQSH Þ áMô+<?X+Y[F=@FéX&A>SH$X+OpH$Yìà»åJQSH ÷R÷ ù ðJQ+<WJF=@Y+HKJ9HKL!^F=XSH$Yìà»åJQSH Þ á9MõALãzîPF=YSHKL$ê

_ &[8C%&[ Z32 WCW[Ub \8Q+H Aø Aø@!>Sè?è?H$@9J@G<`OK;IH$<WL!HKLâxã?L!^½>+;=<WJFIãªX ã?Lè?LH$<WJ9HKLYSH$;éFIà HKL!<WJ9H$XSH$@@KêSáhJYAF=@9JF=XPBèª>+Fé@QSH$@³à HKJETHKH$X[JQSH0âuãª;=;=ãzTF=X+è½JrTUãä<?@9õ H$OpJ@Kÿ \QSH8øsýWú Køx÷Uã?âP@J< !?H$QSãª;=YSHKL!@@9õ H$OKFIâxåJQSH@9J9HKõÇ@,ã?âP<õA;=<?X<?X+Y0FIJ@J9HKL!^FéX+<WJFIãªXã?L@!<WJF=@9â<?OpJFIãªXOpãªXAY+FIJFIãªX+@$ê

\QSH½ù¹ü 5$øã?â,@J< !?H$QSãª;=YSHKL!@F=@(LH$;=<WJ9H$YäJ9ãTFé@QSH$@ã?L³XSHKH$Y+@(ã?â>+@9HKLR@Kô¹<?X+Yä@9õ H$OKFIö+H$@(<?XäH ã?LJã?LN<?OpJFIîPFIJEåã?â<>+@9HKL8F=Xìã?LRYSHKL8J9ã`@<WJFé@9âuåJQSH0X+HKH$Yê

\8Q+H F=XJ9H$X¹Jâ<?OpHKJF=@äLH$;=<WJ9H$YJ9ãßøsým÷÷JQSH>+@9HKLT<?XJ@J9ã <?OKOpãª^õA;=F=@Q,ê(\8QSHF=X¹J9H$XJì^<$å à Hã?L!Y+HKLH$YäFéX¹J9ã ý 5pù?ú Aø Aøx÷@9õ H$OKFIâuåPF=XSèJQ+HG^`<?F=X`>+@H$@Uã?âJQSHN@å»@9J9H$^ <?X+Y ùWú Çø Aøx÷NJQ+<WJ^<zå à HìãªX+;Iå õA<WLJF=<?;=;=åðã?âNF=XJ9HKLH$@9JKê áCX¹J9H$XJ@^<zå à Hìè?H$XSHKL!<?;éF:9KH$YJ9ã ø = p÷ìJQA<WJíLHKõ+LH$@9H$XJOK;=<?@!@9H$@8ã?â F=XJ9H$X¹J@Kê

@ C Z 2 UCh[Ub \8QSHø /â<?OpHKJFé@>+@9H$Yìâxã?L@9õ H$OKFIöAOK<WJFIãªXìã?â JQSHè?H$X+HKL!<?;,JF=^HLH$@9J9L!F=OpJF=ãªX+@@>+ORQ[<?@ JQ+Häþ~÷ +ô+TQAF=O!Q]F=^õA;=FIH$@<^íã?LHOK<WLHKâx>A;=;IåäOK<?;éOK>+;=<WJ9H$Y]õA;é<?XôS<?X+Y JQ+H þWôªTQ+FéO!Q@9J9L!H$@@9H$@UJQSHF=XJ9H$X+YSH$YíH H$OpJã?â <?Xä<?OpJFIãªXôã?âuJ9H$XF=XY+Fé@9JF=X+OpJFIãªX½ã?L³OpãªX¹J9LR<?@9JJ9ã`JQSH0<?OpJFIãªX ã?L^íH$<?X+@8<?@@>+ORQê

\8Fé^íH³âx<?OpHKJ@U^<$å"à H³î?HKLå"è?H$XSHKL!<?;eê?áCX"JQ+F=@OK<?@9H?ô¹TUH>A@9H0ùRým÷ ù S÷NJ9ãLHKõ+LH$@H$X¹J<?XíH$XJFILH8OK;é<?@@ã?â JF=^íHâxL!<?^íH$@$ê

C ! pjCqnoC%&[ 2[ X & Z 2 UCh[Ub áhXJ9H$X¹JF=ãªX+@<WLHGYSH$@OpL!FIà H$Yäã?L<?X+XSã?J<WJ9H$YìJQSLãª>+èªQ>+J9J9HKL!<?X+OpH$@KôPTã?L!Y+@ã?LõAFéOpJ>SLH$@Kê \8QSHìTã?L!YLHKõ+LH$@H$X¹J<WJFIãªX Fé@"LH$;=<WJ9H$YJ9ãðTã?L!Y ö+H$;=Y+@">+@9H$Y FéX JQSH[@J9L!<WJ9HKèªF=O]^íãPYSH$;ïzósê\8QSH F=OpãªX LHKõ+LH$@9H$XJ<WJFIãªXF=@íàA<?@9H$Y ãªX ^íHKJ<WõÇQSã?L!@Kê Þ ã?LRY ö+H$;=YA@^<$åà H @9õ H$OKF=<?;éF=@9H$Y J9ãOpãªX+OpHKõAJNöAH$;=Y+@YAF=@OK>+@@H$Y ;=<WJ9HKLF=X JQ+F=@NO!Q+<WõAJ9HKL$ê 8HKõ+LH$@H$X¹J<WJFIãªX F=@NYSHKHKõA;=å[YSHKõ H$X+YSH$XJãªXJQSHOK>+;=J>SL!<?;ÇH$X¹îPFILãªX+^H$X¹J<?X+YJQSHNOpãª^`^>+XAFIJEåJQA<WJ³>A@9H$@(JQ+H Þ áMêáCXJ9H$X¹JFIãªXA@OK<?Xà HG@>Sõ+õ ã?LJ9H$Yà»åäõALãzîPF=Y+F=X+è"@JF=^>A;=FJQ+<WJ8Lãª>+@Hã?LF=X+OKFIJ9H/<?OpJF=î»FIJrå?ê

áCX¹J9H$XJFIãªX+@`^<$å à HL!H$@9J9L!F=OpJ9H$Yà»å < ÷!ù ªêU\8QSH]@Opã?õ H[<?;=;IãT@"J9ã OpãªX+OpH$XJ9L!<WJ9H ãªXJQ+H[^<?F=X<?@9õ H$OpJ@Kêm\(å»õAF=OK<?;?L!H$@9J9L!F=OpJFIãªXA@,<WLH(JQ+H(OK>+;IJ>SLR<?;?H$X¹îPFILãªXA^íH$X¹JKôzH$Y+>+OK<WJFIãªX0ã?Lã?JQSHKLkõ+Lã?öA;=Hõ+Lã?õ HKLJFIH$@ã?â õ ã?J9H$X¹JF=<?;>A@9HKL!@KôSã?LN@9õ H$OKFIöAONJF=^íHâ<?OpHKJ@8âxã?L>SJF=;éF=@<WJFIãªXã?â JQSH Þ á9Mê

\8Q+Hö+L!@9JJETãâ<?OpHKJ@ã?âSF=XJ9H$XJFIãªX0Q+<zî?H<è?H$XSHKL!<?;¹âuã?L!^ æxã?à<;9H$OpJFIî?H?ôã?à;CH$OpJRç,<?X+Y0<^íã?LH(OpãªX+OpL!HKJ9Hâxã?L!^-æ<?F=^]ôPJ<WLè?HKJRçRê\8QSHNõA>SLõ ãª@9HNâx<?OpHKJ8Y+HKõH$XAY+@ãªXìJQSH^F=@@F=ãªX<?XAYäJQ+H/<?>+Y+FIH$X+OpH?ôPTQ+HKLH$<?@³JQSHF=XJ9H$X¹J0âx<?OpHKJ0Y+HKõH$XAY+@GãªXðJQSHJ<?@"!»@Kê\8QSHKLHKâxã?LH?ôJQSHíö+LR@9Jâx<?OpHKJ½@9õ H$OKFIö+H$@GJQSHoTQ+<WJIô,JQSH`@H$OpãªX+YJQSHQSãzTIô <?XAY JQSHJQ+FILRY â<?OpHKJ½JQ+HoTQ+H$Xã?â<?XF=XJ9H$XJFIãªXê Þ H]^<zå H$FIJQ+HKL½OpãªX+OpH$XJ9L!<WJ9H]ãªX<^íã?LH0è?H$XSHKL!<?;,@9õ H$OKFIöÇOK<WJFIãªXìã?L<^íã?L!H0OpãªX+OpLHKJ9HãªXSH?ê

\8Q+H YAFHKL!H$X¹Jìâ<?OpHKJ@[^<$å¿à HðOpãªX+@F=YSHKL!H$Y¿@HKõA<WL!<WJ9H$;Iåã?L[<?;IJ9ã?è?HKJQSHKL FéX¿<OpãªX+Y+H$X+@9H$Yßâxã?L!^]ê\8QSHYSHKJ<?F=;IH$YäOpãªX+@F=YSHKLR<WJFIãªXF=@UXSH$OpH$@@<WLå?ô»TQSH$X+HKî?HKLU</â<?@9JF=YAFIãª>+@<?>+YAFIH$X+OpH8LH»>+FIL!H$@@9ã?õAQ+Fé@9JF=OK<WJ9H$YOpãªXJ9H$X¹JKêFIèªQ]Y+H$^<?X+Y+@Opãª^íHF=X¹J9ãOpãªXA@F=YSHKL!<WJF=ãªX]Y+>SHGJ9ãíJQSH/OpãªXJ9H$X¹Jõ+LãzîPF=YSH$Y,ô»JQ+H/Opãª^^>AX+FIJEåJQ+<WJ ^½>+@9J]à H @<WJFé@9ö+H$Yô³JQSH @ã?õAQ+F=@9JFéOK<WJ9H$Yßâx>+XAOpJFIãªX+<?;=FIJrå LH»>+FIL!H$Yßâuã?L[JQ+H Þ áMôã?L JQ+H Q+FIèªQ<WJ9J9H$XJFIãªX[JQSH Þ áMèª<?F=X+@$ê ý \8QSH"õA>SL!õãª@H½â<?OpHKJ0F=@/ã?âuJ9H$X OpãªXA@F=YSHKLH$Y J9ã Opãzî?HKL@9ã?âuJF=X¹J9H$XJFIãªX+@ã?L/àåoàA>+@!F=XSH$@@L!>+;=H$@Iê áhX <?X FéXSâuã?LR^<WJFIãªX@9HKLîPF=OpH[<ð>+@9HKL^`<$å àH[FéX¹J9HKLH$@J9H$Yã?Là H$Opãª^F=XSèð^íã?LH[FéX¹J9HKLH$@J9H$Y F=X@9ãª^íH/OpãªXJ9H$XJKêÇ\8QSHF=XJ9H$XJâ<?OpHKJF=@YAFHKL!H$X¹J<?X+Y]^<?FéX+;IåYSL!F=î?H$Xäà»åJ<?@ !»@8JQSH>+@9HKLJ9L!FIH$@³J9ã@ãª;Iî?H?ê

MPFé^F=;=<WL!;=å?ô»TH"^<$å[YSHKLRFIî?H<äX>+^à HKLã?âF=XJ9H$XJFIãªX+@<>+@9HKLNQ+<?@NF=X[^F=XAY]TQSH$XSHKî?HKLG@mQSHî»Fé@FIJ@<?X]H$Y+>+J<?F=X+^íH$XJ8@FIJ9H?ÿ

6 Sb Ý X <?F=^ ã?â<?X H$Y+>SJ<?F=XA^íH$X¹J8>A@9HKL^<zå]à HJ9ã`ã?à+J<?F=X <`OpHKLJF=öAOK<WJ9H0JQ+<WJõ+Lã»ã?âx@8JQSH@>AOKOpH$@@ã?â;IH$<WL!X+F=X+èSê Ý F=^@Nã?âõ+LãzîPF=YSHKLR@ã?âH$Y+>SJ<?F=XA^íH$X¹JG@FIJ9H$@^`FIèªQ¹J<?;=@ãà H½àAF=X+YAF=XSè`JQ+H";=H$<WL!XSHKLGJ9ã


@9ãª^Hõ+LãPY+>+OpJ@/@!>+O!Q <?@0JQSHä@ã?âuJrT<WLHäã?â<[@>Sõ+õ ã?LJ9HKLã?â³JQSH`TUHKàA@!FIJ9H?ê\UåõAFéOK<?;è?H$XSHKL!<?;U<?F=^@TF=JQ+F=X <?XðH$Y+>SJ<?FéX+^íH$XJG@!FIJ9H<WLHJ9ã[è?LR<?X¹JH»>+<?;L!F=èªQ¹J@J9ã]HKî?HKL!åà ãPYSå ,X+ã?àãPYSå@QSãª>+;=Y Q+<zî?HQ+F=èªQSHKLL!FIèªQJ@JQ+<?X]ã?JQ+HKL;IH$<WL!X+HKL!@Kê

oC'N[6CqnNb \(å»õAF=OK<?;Nã?à<;9H$OpJFIî?H ã?â>A@F=XSè <?XH$YA>SJ<?F=X+^íH$XJì@FIJ9H <WLH è?LH$<WJ9HKL]H$<?@9Hðã?â0;IH$<WLRX+F=XSèSôè?LH$<WJ9HKLNõA;IH$<?@!>SLHã?L@!<WJF=@9â<?OpJFIãªX[Y+>SLRF=XSèí;IHKL!<?X+FéXSèSôS<?X+Y ^íã?L!H/âx>AXê Ý XSã?JQ+HKLè?H$XSHKL!<?;ã?à<;9H$OpJFIî?HF=@@9H$OK>SL!F=JEå[<?X+Y õ+L!FIîW<?Opå?ê4(YA>SJ<?F=X+^íH$XJ<Wõ+õÇ;=F=OK<WJFIãªX+@<?;=@9ãäQ+ãª@9JOpãªXSöAY+H$X¹JF=<?;F=XSâxã?L!^<WJFIãªX,ô+H?êèSêF=X+âuã?L!^`<WJFIãªXãªXõ+Lã?è?LH$@@<?X+Y/HKL!Lã?L!@Kêz\QSH(;IH$<WL!X+HKL!@XSHKH$Y0J9ãà H(@!>SLHã?âSJQSHU@9H$OK>SL!FIJrå/<?X+Y/õAL!FIîW<?Opåã?â JQSH$FIL8YA<WJ<PêA\8QSHKåì@QSãª>+;éYìàHF=X+âuã?L!^H$Yìã?âJQSH@9H$OK>SL!FIJråäõALH$OK<?>SJFIãªX+@$ê

\8Q+Hý +þ ã?â8<?X H$YA>SJ<?F=X+^íH$XJ@!FIJ9H`^<zå à HL!<WJQSHKL">+X+@9õ H$OKFIöÇO"ã?L^íã?LH@9õ H$OKFIöAO@!>+O!Q <?@@9J>+Y+H$X¹J@ã?â<íOpãª;=;=HKè?H/ã?L<?X+<?;=å»@9J@8ã?âk<íàÇ<?X&!Çê

\8Q+H ÷R÷ ù ã?â/<?XH$Y+>SJ<?F=XA^íH$X¹Jä@FIJ9H Fé@J9ã@>Sõ+õ ã?LJ`;=H$<WL!X+F=XSèðà»å õ+Lãî»FéY+F=XSèðH$<?@9åBsJ9ãWBsè?L!<?@9õ!PXSãzT;=H$YSè?H?ê Ý JJQSH@!<?^íHJF=^H?ôªJQSHõALãzîPF=YSHKL^<$åíà HF=XJ9HKLH$@9J9H$YF=XFéX+OpLH$<?@9H$Y`î»F=@!FIJ9ã?L9BsJ9ãWBEOK>+@9J9ãª^HKLOpãªXî?HKL!@FIãªX L!<WJ9H?ôAF=X+OpL!H$<?@9H$Y[X»>+^0à HKLã?âkLHKJ>SL!XAF=XSèíOK>+@9J9ãª^íHKLR@KôA<?X+Y]F=XAOpLH$<?@9H$Y]LHKî?H$X»>SH?ê

\8Q+H/F=X¹J9H$XJF=@³L!H$;=<WJ9H$Y]J9ãJQSH^íã?LH/OpãªX+OpLHKJ9HJ<?@ !P@<>+@HKL8Q+<?@8F=X]^FéX+YìTQ+F=;=HîPF=@FIJFéXSè½< Þ áMê ý ·áCXJ9H$X¹J@8Opãª^H/Y+FILH$OpJ;Iå`âuLãª^ <?XA<?;Iå»@!F=XSè0JQ+H/XSHKH$Y+@³<?X+YìJQSHYSH$^<?XAY+@ã?â>+@9HKLR@KêAM»ãª^íHõ ãª@@FIàÇ;IH½øsýW÷z÷½<í>+@9HKL^<zåìT<?XJ8J9ã`<?OKOpãª^íõÇ;=F=@Q]F=X]<?X H$Y+>SJ<?F=XA^íH$X¹J8@!FIJ9H/<WLHJQSH/âxãª;=;IãTF=XSèSÿ

Ý >+@9HKL]LH$<?;=Fé@9H$@JQ+<WJ[OpHKLJ<?F=X !PXSãzT;IH$YSè?H ã?L[F=XSâxã?L!^<WJFIãªXßF=@ìXSH$OpH$@!@<WLå¿âuã?L[@9ãª;=î»F=X+è < J<?@ !êSã?L/FéX+@9J<?X+OpH?ô <?X <?X+<?;IåP@9Jã?âU<äàÇ<?X&!]T<?XJ@GJ9ã!»X+ãzTTQ+<WJNJQSHíO!Q+<?X+è?H$@<WLH½FéX JQSHíOK>+@J9ãª^íHKLOpãª^^½>+X+F=JEåJQ+<WJ;IH$Y]J9ãä<íL!F=@9HGã?â â<?>+;IJEåìOpLH$Y+F=J@Kê

Ý @9J>AYSH$X¹JUF=X<0Opãª;é;IHKè?HXSHKH$YA@J9ã !PXSãT^íHKJQSãPY+@(âuã?L<?X+<?;IåP@F=XSè/Y+<WJ<Pê»áCXíJQ+F=@UOK<?@9H?ô¹JQSHN@9J>+YSH$XJF=@F=XJ9HKLH$@9J9H$Y FéX[<`Y+<WJ<ä^F=X+FéXSèíOpãª>SL!@9H/JQA<WJõ+Lãî»FéYSH$@8^<WJ9HKL!Fé<?;,ãªX QAF=@mQSHKL8H$YA>+OK<WJFIãªX+<?;;IHKî?H$;eôõ HKL!^F=J@;IH$<WL!X+F=X+è½JQ+H0OpãªX¹J9H$XJFéX¹J9HKL!<?OpJF=î?H$;Iå?ôÇ<?X+Y F=@Opãª^íõA<WL!<WàÇ;IH/J9ãJQSH^<WJ9HKL!F=<?;JQ+H0@9J>+YSH$XJF=@OK>SLLH$XJ;Iå`Tã?L"!PF=XSèíTF=JQ]F=XìJQSH/Opãª;=;IHKè?H?ê

kãª@@F=àA;IHF=XJ9H$X¹J@F=X]<?X]H$Y+>SJ<?FéX+^íH$XJ8@FIJ9H/<WLH/JQ+Hâuãª;=;=ãzTF=X+èSÿ

oC'N[8nNb \8QSHKL!H<WLH³<GX>A^0à HKLkã?â+ã?à<;9H$OpJ@@>+O!Q"<?@ â<?@9J9HKL J<?@ !Opãª^õA;IHKJFIãªXôW@>+OKOpH$@!@9âx>A;Opãª^íõÇ;IHKJFIãªXã?â^íã?LHJ<?@"!»@KôAã?LOpãª^^Fé@@FIãªXã?â âuHKTHKLHKL!Lã?L!@Kê

@ 2 p>Ch[8nNb áhXßJQ+HàÇ<?X&!<?X+<?;=å»@9J]OK<?@9H?ôJQ+H <?X+<?;IåP@9J]XSHKH$Y+@ìJ9ã !»X+ãzTY+<WJ< ^`F=X+F=XSè ^íHKJQSãPY+@Kô³J9ãOK<Wõ+J>+LH/JQSH/<?ORQ+FIHKî?H$^íH$XJ@<?XAY]JQSH0Y+Fé@<?YSîW<?X¹J<Wè?H$@8<?XAY]õAFIJ9â<?;=;=@ã?â@>+ORQ[^íHKJQSãPY+@Kê

\8Q+HGø = ~÷8F=X½JQSH³àA<?X&!½<?X+<?;IåP@9JOK<?@9H8Opãª>+;=Y½à H³JQSHF=XJ9HKLH$@9JF=X";IH$<WL!X+FéXSè<?@@ã»OKF=<WJF=ãªXí^íHKJQSãPY+@Kôõ+LHKõALã»OpH$@!@F=XSè"ã?â Y+<WJ<PôÇ<?X+YìõALH$Y+F=OpJFIãªX]^HKJQSã»YA@Kê

\8Q+HäJF=^Häâ<?OpHKJíLHKõ+LH$@H$X¹J@"è?H$XSHKLR<?;UJFé^íHìLH$@9J9L!F=OpJF=ãªX+@@!>+O!Q<?@"JQSHìJF=^íHã?LíJQSHìF=XJ9HKLîm<?;âxã?LîPF=@FIJ@Nã?â(JQ+H Þ áMô JQSHíJF=^íHí<?X+YJQSHF=XJ9HKLîW<?;kã?â(LHKõ H$<WJ9H$YðîPF=@FIJ@$ôÇã?LJQSH"J9H$^íõ ã?L!<?;éFIJEå JQ+<WJ^<$åâxã?L!OpH0<>+@HKLJ9ã`;IH$<$î?HJQSH0@F=J9H?ê ý NFé@FIJ9ã?L!@ã?â<;=H$<WL!X+F=XSèí@F=J9H0OK<?X[à H/O!QA<WL!<?OpJ9HKL!F=@9H$Y àåìJQSH$F=L8JF=^íH/Y+Fé^íH$X+@FIãªX,ôPFsêH?ê+JQSHJF=^íHGJQSHKåì<?OKOpH$@@N<?X+Y]>+@9HGJQSH/@!FIJ9H?ôSJQSH/<?OKOpH$@@õA<WJ9J9HKL!X]JQSHKåõ+LHKâxHKL$ôS<?X+YìJQSHL!H$@9õ ãªX+@9HGJF=^íHJQSHKåLH»>SH$@9JâxLãª^ JQSH@FIJ9H?ê

Cqn & b Ý X H$Y+>SJ<?F=XA^íH$X¹JN@FIJ9H"^<$å <?;=;IãzT<äî»F=@!FIJ9ã?LJ9ãì>+@9HJQSH"^<WJ9HKL!F=<?;ãªXãªXSH½@!QSã?Jã?LGJ9ãì>+@9HFIJ½@9J9HKõ àåð@9J9HKõ,êkáCX JQSH;=<WJ9J9HKL½OK<?@H?ô YAF=Y+<?OpJF=OK@âxã?L½JQSH`H$;=<Wà ã?L!<WJF=ãªX ã?â8^<WJ9HKL!Fé<?;(à H$Opãª^íH$@½<?XF=@!@>SHã?â Þ áM]Y+HKî?H$;Iã?õA^íH$XJKê M»J9HKõ+BsàåBE@9J9HKõ ;IH$<WL!X+F=X+è"Y+HKõH$XAY+@³ãªX[JQSH½OK>+;IJ>SLR<?; H$X¹îPFILãªX+^H$X¹J8ã?âJQSH>+@9HKL$ôSJQSH/Opãª;é;=<Wà ã?L!<WJFIãªXìTFIJQ[ã?JQSHKL;IH$<WL!X+HKL!@Kô+<?X+Y]JQ+H/F=X¹J9HKLR<?OpJFIî?H/â<?OKF=;=FIJFIH$@³ã?âkJQSH0@!FIJ9H?ê


+>+LJQSHKL!^íã?L!H?ôH$Y+>+J<?F=X+^íH$XJ@FIJ9H$@k^<zå/à HU>+@9H$Y0ãzî?HKL<;IãªXSè?HKLkJF=^íH(õ HKL!F=ã»Yê$\QSHKLHKâxã?LH?ômOpãªXJ9HPJCB@9H$XA@FIJFIî?H(Q+H$;Iõ0à H$Opãª^íH$@kF=^íõ ã?LJ<?XJKô$à H$OK<?>+@9H@9ãª^íHU<?OpJF=ãªX+@ã?L @OpH$XSH$@k^<zå/XSã?Jà Hã?à»î»F=ãª>+@J9ãN<?;=;>+@HKL!@Kê& < !PF=XSèí@>+ORQ]QSH$;Iõì<$îW<?F=;=<WàA;=H?ôH?êèSêSJQSL!ãª>SèªQìõ ã?õSBE>SõTF=X+YSãT@UH$X+@>SLH$@JQ+<WJ³JQSH;IH$<WLRXSHKL!@YSãX+ã?J;Iãª@9HJF=^H/<?X+Y[F=XJ9HKLH$@9JKê

& ( b (<?ORQ <?OpJFIãªXßã?â<>+@HKLì;=H$<?Y+@J9ã@ãª^íHðHH$OpJ]JQA<WJìFé@äH$F=JQSHKL]^<?YSH î»Fé@FIàA;IH J9ã JQ+H >A@9HKL$ôLH$Opã?LRYSH$Yôã?L`ORQ+<?XSè?H$@`JQSH @9J<WJ9H[ã?âGJQSH ;IH$<WL!X+F=X+è õ+L!ã»OpH$@@`FIJ@9H$;Iâhê\8QSHìH$X+Y+@ã?âN<?OpJFIãªXA@`^½>+@9Jà H]O!QSH$O !?H$Y <Wèª<?F=XA@9JíJQSH]F=XJ9H$X+YSH$Y HH$OpJKê\8Q+F=@ !PF=X+Y ã?âOpãªX+@!F=@9J9H$X+Opå O!QSH$O !Fé@í@>Sõ+õ ã?LJ9H$Y àå<?OKOpHKõ+J<?XAOpH½OpãªX+YAFIJFIãªX+@>+@H$Yìâuã?L8HPõA;=FéOKFIJO!QSH$O !?ãª>SJâxLãª^ @!OpH$XSH$@Kê

Sã?LH$Y+>SJ<?F=XA^íH$X¹J8@!FIJ9H$@KôSJEå»õAF=OK<?;ùRým÷ ù S÷"^<$åìà HJQSH/@>AY+YSH$XìLH»>+FILH$^H$X¹J³J9ã`HPõA;Iã?L!H/@9ãª^íH!PXSãzT;=H$YSè?H8ã?L(J9ãõ+LHKõA<WL!H8<õAFIH$OpH8ã?âQSãª^HKTUã?L"!ê Ý XSã?JQSHKL(ã»OKOK<?@F=ãªXä^F=èªQ¹Jà H8JQSH@>+Y+YSH$XíY+H$^<?X+YF=X »>+<?;=FIJråFéXSâuã?LR^<WJFIãªXìY+>SHJ9ã`@ãª^íH0XSHKT@8õã?õAõAF=XSè">Sõ[@9ãª^íHKTQSHKLHH$;=@9H?ê

\8Q+HLHKõALH$@9H$XJ<WJFIãªXâx<?OpHKJLHKõALH$@9H$XJ@UJQ+H A<zî?ãª>SLã?L<WJ^íãª@9õAQ+HKLHã?âk<@!FIJ9HN<?@YAF=@OK>+@@H$Y`F=X ïzósê\8Q+Fé@³âx<?OpHKJFé@8;=<WLè?H$;IåYSHKJ9HKL!^FéXSH$YìàåìJQSHã?JQ+HKLJQSLHKHâ<?OpHKJ@Kê

ý Ý X[H$Y+>SJ<?FéX+^íH$XJ@FIJ9HJQ+<WJ@>+õ+õ ã?LJ@àA<?X&!]<?X+<?;=å»@9J@@QSãª>+;éY[@9J9L!FIî?H0âuã?LN<?X <WH$@9JQ+HKJF=O<?X+Yð^FéX+F=^<?;=Fé@9JYSH$@!FIèªXê\8QSHí^<?F=X J<WL!è?HKJ/âuã?LJQ+HíLHKõ+LH$@9H$XJ<WJFIãªX Fé@GJ9ã @>Sõ+õ ã?LJNTã?L"!Çê,\QSHí@FIJ9HXSHKH$Y+@kJ9ãGH$X+@>+LHU<GOK;IH$<?X"<?X+Y">+X+Y+HKL!@9J<?X+Y+<WàÇ;IH(;=<zå?ãª>SJKê Ý ;é;FIL!LH$;IHKîW<?X¹JâuH$<WJ>SL!H$@^>+@Jà H(ãª^`FIJ9J9H$Yê Ý JJQSH³@<?^íH³JF=^íH³<?X"F=XSâxã?L!^<WJFIî?HâxHKH$YSàA<?O"!½F=@LH>AFILH$Yêm\8QSH³@FIJ9H³XSHKH$Y+@kJ9ãGàHOpãªX+@F=@J9H$X¹J JQSLãª>+èªQSãª>SJKê\8QSHG<?X+<?;IåP@9J@³T³<?X¹JJ9ãOpãªXJ9Lãª; JQSH$F=LT³<$åã?âTã?L"!PF=XSèSê Ý JJQSH@<?^íHGJF=^HNJQ+HKå`à H$Opãª^íHGH»õ HKLJ@³ã?âJQSH@F=J9H<?X+YðJQ»>+@/XSHKH$Y @!QSã?LJOK>SJ@<?X+Y <?OKOpH$;IHKL!<WJ9ã?L!@Kê+>SLJQ+HKL!^íã?LH?ôJQSHKåð<WLHíL!H$@9J9L!F=OpJ9H$Y FéX JQSH$FIL<WJ9J9H$XJFIãªX[J9ãäJQSH/@FIJ9H?ôA@ãíJQSHKå]XSHKH$Y[<íâ<?OKF=;=FIJrå`J9ãL!H$Opãzî?HKLNâuLãª^ HKLLã?L!@Kê

Ý XH$Y+>SJ<?F=XA^íH$X¹Jí@F=J9Hã?LRFIH$X¹J9H$YJ9ã @>Sõ+õ ã?LJõA>SõAF=;é@0^<zå âxãª;=;IãT Opãª^íõA;IHKJ9H$;Iå Y+F HKLH$XJ"Y+H$@FIèªXõ+L!FéX+OKFIõA;IH$@$ê (>SõÇF=;=@½XSHKH$YJ9ãðà Hì<WJ9J9LR<?OpJ9H$Y à»å è?L!<WõAQAF=OK<?;H$;IH$^íH$XJ@íJQSHKå ;éF !?H?ô JQSHKå â<?OpH[F=X HKî?HKLåY+<zå»@ä;=FIâxH?ô<?X+Y TQ+FéO!Q ^< !?H>+@F=X+èJQ+H @FIJ9H < õA;IH$<?@F=X+èHPõ HKL!FIH$X+OpH?ê (>SõAFé;=@"Q+<$î?H< ;IH$@@CBsJ9LR<?F=XSH$Y@QSã?L!JCBsJ9HKL!^ ^íH$^íã?Lå?êÇMPãSô»JQ+H/@QSã?LJCBsJ9HKL!^ ^H$^íã?Låä;=ãª<?Y]F=@LH$Y+>+OpH$YôSFIâõA>SõAF=;é@(OK<?XìLH$Opã?èªX+F!9KHTQ+<WJJQSHKå]XSHKH$Y]J9ã !»XSãT âxLãª^ îPF=@FIàA;=HH$;IH$^H$X¹J@ã?âJQSH@FIJ9H?ê

\8Q+H@9HKJã?âF=XJ9H$X¹JF=ãªX+@TH@QSãª>A;=YíOpãªX+@F=Y+HKL(^<$åíà HL!<WJQ+HKLU;=<WLè?H?ê[ã?LHKãî?HKL$ôPJQSH8â<?OpHKJ9H$Y`L!HKõ+LHpB@9H$XJ<WJFIãªX ^`<$åìà H$Opãª^íH/J9ã»ã`Y+F`OK>A;IJUJ9ãä^<?X+<Wè?H<?XAYìJ9ãä@<WJF=@âuå?ê+\8Q+Hã?L!YSHKL8TH0^<zåì>A@9H/YSHKõ H$X+Y+@ãªX JQSH]<?>+Y+FIH$XAOpH<?X+Y ãªX JQSHìõ+Lãî»FéYSHKL$ê\QSH<?>AY+FIH$X+OpHìF=@½ã?L!FIH$XJ9H$Y J9ãzT³<WL!Y+@í@9ãª;IîPF=XSè J<?@ !P@Kê\8QSHõ+Lãî»FéYSHKL(Q+<?@U<^F=@!@FIãªXIê Þ HGOK<?Xä>A@9H8JQSH$@9HJETãL!H$@9J9L!F=OpJFIãªXA@J9ã0ö+èª>+LH8ãª>SJUTQ+F=ORQ !»FéX+Y"ã?âTUHKàÇ@FIJ9H@>SõAõã?L!J@GJQ+F=@õ+L!ã?öA;IH?ôJ9ã QA<WL!^íãªX+F:9KH`ãª>SL>+XAYSHKL!@9J<?X+YAF=XSèTFIJQðJQSHäOpã?Lõ ã?L!<WJ9HäF=Y+H$X¹JFIJrå?ôJ9ã[ã?LRYSHKLJQSHíJ<WLè?HKJLH$<?;=F=@!<WJFIãªX æ@QSã?LJCBsJ9HKL!^[ô;IãªXSèWBsJ9HKL!^çRô<?X+Y öAX+<?;é;Iå[J9ã YSHKî?H$;=ã?õ <?X >+X+Y+HKL!@9J<?X+Y+FéXSèäQSãTJQSH0@!FIJ9HTF=;=;;Iã»ã!;éF !?H/F=XìJETã`å?H$<WLR@8âxLãª^ XSãT ãªXê

ý Ý Fé^@<?X+YJ<WLè?HKJ@kOK<?X/à Hã?L!Y+HKLH$Yê Þ H(OK<?X>+@9HJQSH(^`F=@@FIãªXG<?X+Y/è?ãª<?;=@,ã?âPJQSHõ+L!ãzîPF=YSHKL<?X+Y Opãª^íõA<WLH½JQSH$^ TFIJQ[JQSHJ<?@ !P@JQSHõ+Lãî»F=Y+HKLT³<?X¹J@J9ã@!>Sõ+õ ã?LJâxã?LNY+F HKLH$XJ<?>+YAFIH$X+OpH$@Kê+ã?LF=X+@J<?X+OpH?ôSTUH^<$åìL!<?XSè?H0JQSHõ+L!FIã?LRFIJEå>+@F=XSèí<@!OK<?;IHâuL!ãª^-ñ`æQ+FIèªQ+H$@9JRçUJ9ã ]æ;IãTUH$@JRçRê

<?F=^@8<?XAYìJ<WLè?HKJ@Opãª^^½>+X+FIJråOK>+@J9ãª^íHKL

OK<?@>+<?;OK>+@9J9ãª^HKL L!H$@9H$;=;IHKL

Q»>+XJ9HKL èª<WJQSHKLHKL !PF=Y+@ @9J>+YSH$XJ@

@9H$;=;=FéXSèà ã»ã!»@ ñ ñ ñ F=XSâxã?L!^F=X+èãªX]à ã»ã!»@ ñ ñ ñ LHKîPFIHKTF=XSè"à ã»ã!»@ ñ ñ ñ @9H$;=;=FéXSèà H$@9J@H$;=;IHKL!@ ñ ñ ò YSHKî?H$;Iã?õAFéXSè<íOpãª^^½>+X+FIJrå ñ ñ ò

¨ cR¢d¦uklfrtsfhqkzEmfhfcRjWfhqsjWc!qE ¾ WcRofClo

Sã?LàA>+@FéXSH$@@ã?LF=X+âuã?L!^`<WJFIãªXì@FIJ9H$@TH/ã?à+J<?F=X[JQSH/âxãª;=;IãzTF=XSè½ã?L!YSHKL$ÿñWê8õ+LRF=^<WLåF=X¹J9H$XJFIãªX+@³ã?â JQSHõALãzîPF=YSHKLò»ê8õ+LRF=^<WLåXSH$OpH$@@FIJF=H$@<?X+Y[YSH$^<?XAY+@ã?âkJQSH0OK>+@9J9ãª^HKL!@ ê@9H$OpãªXAY+<WLå]<?F=^@³ã?â JQSHõ+L!ãzîPF=YSHKLSê@9JFé^>+;éFÇâxã?LOK>+@J9ãª^íHKL!@8J9ã`LHKî»Fé@FIJ³JQSH/@9åP@9J9H$^ <?XAY]J9ãàA>Så^íã?LH»ê<?>+YAFIH$X+OpHH$Y+>+OK<WJF=ãªX]âuã?LJQSH0OK>+@9J9ãª^HKL8TFIJQìãª>SLOK>+@9J9ãª^íHKLNOpãª^^>AX+FIJEå»ê8à H$<?>SJråâxã?LOK>+@J9ãª^íHKL!@êOK>+@J9ãª^íHKL!@@H$;IâéBsL!H$<?;=F=@<WJFIãªX,ê

\8Q+HU@9õ H$OKFIöAOK<WJF=ãªX/ã?âSJQSH³F=XJ9H$X+YSH$Y0<?>AY+FIH$X+OpHUã?âSJQSH Þ á9M0F=@àA<?@9H$YãªX<TUH$F=èªQ¹J9H$Y";=F=@J,ã?â&!»FéX+Y+@,ã?â>+@9HKLR@KôJQ+H$FIL<?F=^@Kô?<GOpãª^íõA<WL!Fé@9ãªX½ã?âAJQSHF=XJ9HKL!<?OpJFIãªX"TF=JQ½>A@9HKL!@kTUHQ+<zî?H8@9ãâ<WL$ô?<?X+Y"<N@õH$OKF=öAOK<WJFIãªXã?â<?F=^@³ã?â JQSH/<?>+YAFIH$X+OpH/<?X+Y]L!H$<?@9ãªX+@âxã?L8LHpBsîPF=@FIJFéXSèSê ý %HKJ>+@OpãªX+@FéYSHKLU<?XìF=XSâxã?L!^<WJF=ãªX`@9HKLîPF=OpHJQ+<WJ@!>Sõ+õ ã?LJ@J9LR<$î?H$;=F=X+èSôH?êèSêPàA<?@9H$YäãªXJQSHà+L!<?XAY

æ ³FIJEå?ô ã?J9H$;xç mò+æ\ãª>SL!F=@JKôáhXî?H$@9J9ã?L~ç ! \8QAF=@³õA<WJ9J9HKL!X[Fé@àA<?@9H$Y]ãªX[JQSHâuãª;é;IãzTFéXSèíOpãª<WL!@9H@õH$OKF=öAOK<WJFIãªXìã?âF=XJ9H$X¹JFIãªX,ÿ

) »ú ùm÷¹ÿ¹<WJ9J9L!<?OpJFIãªX`ã?âÇîPF=@FIJ9ã?LR@<?X+Y"àA>+F=;éY+F=XSè>+õOK>+@9J9ãª^íHKLL!H$;=<WJFIãªX+@ àA<?@H$Y"ãªX< ÷R÷ ù JQ+<WJF=@OpH$X¹J9HKLH$Y <WLãª>+X+Y]<WL!H$<F=XSâxã?L!^<WJFIãªX]<?XAY[<WJ9J9L!<?OpJFIãªX+@$ê

5Aø Aø~ÿ³J9L!<$î?H$;OpãªXî?H$X+FIH$X+OpH?ô8Q+ã?J9H$;L!ããª^ @<?;IH$@ì<?X+Yß^íã?L!H Y+HKõH$XAY+F=XSèðãªXßJQSHø = J9L!<zî?H$;@>+õ+õ ã?LJKê

#" !ým÷ ù kÿÇ>+JF=;=F=@<WJF=ãªXäã?â ;=F=X !»@âxLãª^ JQSH0@!FIJ9Hã?L8ã?JQSHKLN<?@@9ãPOKF=<WJ9H$Y @F=J9H$@Kê%$ Køsý >= ùWú!÷">+@9H$Yìâxã?Lõ+L!H$@9H$X¹J<WJF=ãªXÿ+@>SLî?HKåì<?X+Y[Opãª;é;IH$OpJF=XSèíàA<?@"!?HKJKê\8Q+HF=XJ9H$X¹JF=ãªX`LHAH$OpJ@UJ<?@"!»@³@>+ORQä<?@J9L!<zî?H$;õ+LHKõA<WL!<WJF=ãªXô@>+õ+õ ã?LJF=XSèîPF=@FIJ9ã?LR@ã?â<?X<WLH$<PôS<?X+Y

è?H$XSHKL!<?;F=XSâxã?L!^<WJFIãªXìâxã?LOKFIJF:9KH$XA@8<?X+Y]J9ãª>SLRF=@9J@Kê

ý '& \QSHFéX¹J9H$XJFIãªX ú ýWú i7pù?úìý 7 ÷ øUF=@àA<?@9H$Y ãªX <X>A^0à HKL½ã?âF=XJ9H$X¹J@"@>AO!Q<?@í<?YPBYSLH$@!@F=XSèî»F=@!FIJ9ã?L!@à HKâuã?LH$QA<?X+Y`âxã?L8@9ãª^íHGõA>+Lõ ãª@9H?ô>+@H?ô»ã?L8<?OpJF=î»FIJrå?êSárJF=XAOK;=>+YSH$@UJQSH<?F=^ J9ãíõA>SJJQSHîPF=@FIJ9ã?LNã?âJQSH Þ áM F=X<`õ+L!ã?õHKLN@9J<WJ9Híã?â(^FéX+Yê Ý J<?@"! <?@@9ãPOKF=<WJ9H$YTFIJQ õ+LHKõÇ<WL!<WJFIãªX^<$å àHJ9ãTã?L"!ðãª>SJ0JQ+HYSHKJ<?Fé;=@/ã?â8< õA;=<?X FéX <?YSîW<?X+OpH?êk\QSH`J<?@ ! ^`<$å à HHPJ9H$X+YSH$Y àåðõÇ>SJ9JF=XSè[õÇFIH$OpH$@0ã?âF=XSâxã?L!^<WJF=ãªX`J9ã?è?HKJQSHKLNF=XJ9ã"<"Opãª^íõ ãª>+XAYäâxã?L!^ ã?Lõ+LHKõÇ<WL!F=XSè½<"LHKõ ã?LJKê»\QSHGJF=^íHGâx<?OpHKJ8^`<$åL!<?XSè?HâxLãª^ X+ãzT »>+X¹JFé;XSHPJ(ã?õ+õ ã?LJ>AX+FIJEå Iê¹\UåõÇF=OK<?;A^íHKJ<WõÇQSã?L!@@>Sõ+õ ã?LJF=X+èJQ+F=@(FéX¹J9H$XJFIãªX`<WL!HàA<?@"!?HKJ@KôYSH$@OpLRFIõ+JFIãªX+@$ôP<?XAY]OK>+;IJ>SL!<?;h;9ãª>SL!XA<?;=@Kê

\8Q+HF=XJ9H$X¹JF=ãªX ú ý?ú 7KùWú½ý ý 7 ÷ ø,HPJ9H$X+Y+@JQSHFéX¹J9H$XJFIãªX ã?â ú ýWú 7pùWú"ý 7 ÷ ø,à»å[<OpHKLJ<?F=X OpãªX¹J9H$XJKô<LHKöAXSH$^íH$XJã?â JQSHJF=^íHâ<?OpHKJJ9ã`JQSH0XSHPJ8õ ãª@@FIàÇ;IHîPF=@F=JKôP<?XAY[<"LHKöAXSH$^H$X¹J8ã?âJQSH/õÇ>SLõ ãª@9HNâx<?OpHKJNXSãzT J<WL!è?HKJF=XSè`<WJH$X¹J9HKLJ<?FéX+^íH$XJKê

Þ H^<$åð>+@9H<[è?L!<WõAQ+F=OK<?;;é<?XSèª>+<Wè?Hâxã?L0JQSHíL!HKõ+LH$@9H$XJ<WJFIãªX ã?â³F=XJ9H$X¹JF=ãªX+@Kê\8Q+H;=<?XSèª>+<Wè?HíTH<WLH>+@FéXSè0HPJ9H$X+Y+@³JQSHGJ<?@ !Bsè?ãª<?;è?L!<WõÇQ+@OpãªX+@F=Y+HKLH$YäFéX ïzósê+\k<?@ !P@³<WLHLHKõ+LH$@H$X¹J9H$Yà»å`LH$OpJ<?XSèª;=H$@KêNãª<?;=@<WL!HLHKõALH$@9H$XJ9H$Y àå YAF=<?^íãªX+Y+@$ê Þ Hí<?Y+Y XSãzTõA>+Lõ ãª@9H$@KôÇFéX¹J9H$XJ@Kô Y+<WJ<JEå»õH$@GJQA<WJG^`<$å à H>+@9H$Yìâxã?LJ<?@ !]Opãª^íõA;=HKJFIãªXôS<?X+YìJQSHJF=^HG<?XAYìLHKõ+LH$@9H$XJ<WJFIãªX]â<?OpHKJ@KêMSF=X+OpHGõA>SLõ ãª@9H$@³<?X+Y]FéX¹J9H$XJ@LHKöAX+HUJ<?@ !P@KôWTH³^`<$å0õÇ;=<?OpHUJQ+ãª@9HF=X¹J9ãNJQSH³J<?@ !P@Kê (>SL!õãª@H$@KôzH?êèSêª<?F=^`@<WLH³LHKõALH$@9H$XJ9H$Yà»å0L!ãª>+X+YSH$YLH$OpJ<?XSèª;=H$@Kê+ã?Lã?à<;CH$OpJF=î?H$@UTHG>+@9HOK;=ãª>+Y+@Kê'8H$@9ãª>SLROpH$@Kô»FsêH?ê^íH$Y+Fé</JEå»õ H$@³<WLHLHKõALH$@9H$XJ9H$Yäà»åYSãPOK>PB^íH$XJF=OpãªX+@Kê»áhXJ9H$XJ@<WL!HNL!HKõ+LH$@9H$XJ9H$Yàå`Q+HP<Wè?ãªX+@$ê»áCXì<?Y+Y+FIJF=ãªXô¹THN^`<$åä<?YAYäJQ+HJF=^Hâ<?OpHKJKôSJQSHLHKõ+L!H$@9H$X¹J<WJF=ãªX]âx<?OpHKJKôÇ<?X+Y]@>Sõ+õ ã?LJFéXSèY+<WJ<WàÇ<?@9H$@Kê FIèª>SL!Hò"YAF=@9õA;=<zå»@³<"è?L!<WõÇQ+F=OK<?;õ+LH$@9H$XJ<WJFIãªX]ã?âJQSH"F=XJ9H$X¹JFIãªX ú ý?ú 7KùWúý 7 ÷ øê Þ H"QA<$î?Hí<?Y+YSH$Y;=F=X&!P@8JQA<WJG@!QSãzT JQSH"YSHKõ H$X+YSH$X+OpH½<?^íãªXSèìJQSHâ<?OpHKJ@Kê

qEc!~8c!tsloCd,!yÇ$tsRqegz?~c!qElojy|!q´½fCNwujyµRqs8c!tsloRj/$gzdtsfCd wmidscRRfjWc!gdelod §

.0/21 ²¹²¾ mfRqEc!¡mlCcRqsfh¡qsfCdefCjKtEctslRjNy|!q,tsmf lojKtsfCjKtslo~j

Þ H"OK<?X Opãª^àAF=X+H/JQSH0YSH$@!OpL!FIõ+JFIãªX[ã?â FéX¹J9H$XJFIãªX+@F=X[<`@H$^F|Bsâxã?L!^<?;T³<$å <?@âxãª;=;IãzT@Kê+\8QSH0F=J9H$^@F=XìJQSH;=F=@9J<WLHã?õ+JF=ãªX+<?;HSOpHKõ+J8JQSH/öAL!@9J³ãªXSH?ê

"!$#&% '( ÿ*)F=XJ9H$X¹JFIãªX X+<?^íH,+-"./"% ! # ÿ )xãª>SJOpãª^íH½YSH$@OpL!FIõAJFIãªX0+

1 2# ÿ );=F=@9Jã?â <?F=^@3+465 7 ( 89# ÿ );=F=@9Jã?âkã?à<;9H$OpJFIî?H$@:+

0# ÿ )xãª>SJOpãª^íH½YSH$@OpL!FIõAJFIãªX0+;'"/<=0# ÿ );=F=@9Jã?âkTH$FIèªQ¹J9H$Y J<WLè?HKJ@:+465 7 (0# ÿ );=F=@9Jã?âkTH$FIèªQ¹J9H$Y ã?à<;9H$OpJ@:+;"> 620 # ÿ )OK;=<?@@ã?âkF=XJ9H$XJ@:+

; 20 ÿ )xãª>SJOpãª^íH½YSH$@OpL!FIõAJFIãªX0+? #@<" ÿ )xè?H$XSHKL!<?; +ãzTA+B"9C ÿ )xHH$OpJ@$ôÇJ9HKL!^`F=X+<WJFIãªX]OpãªX+YAFIJFIãªX+@:+4 (=('#@! ÿ );=F=@9Jã?âkã?à<;9H$OpJFIî?H$@:+

-@/9#9'0"! ÿ )xè?H$XSHKL!<?;@9JEåP;IH/èª>+FéYSH,+1 2D!9#&%@> / ÿ )xè?H$XSHKL!<?;YSH$@OpL!FIõAJFIãªXìã?âk<WJ^ãª@9õAQSHKLH,+E9'6%=>9!/D# ÿ );=F=@9Jã?â ^íHKJ<WõAQ+ã?L!@:+

F'9#@C 4 ÿ )HGJIKMLKONPIQ=R=SUT3VPW3T&N X*SYKKSUZ6VPN=[=ZI\U+

¥ cR¢d¦uklfrtsfhqkzEmfhfcRjWfhqsjWc!qE ¾ WcRofClo

Ü- , 4,

%F=âuH0OK<?@H$@<?;=;=ãzT J9ããzî?HKLROpãª^íHJQ+HF=XSâxã?L!^<WJF=ãªX]ãzî?HKL!;=ãª<?Y<?XAY ;Iãª@9JF=X]JQSH½Q¹å»õ HKL!@9õA<?OpH0@å»X+Y+Lãª^íH$@JEå»õAF=OK<?;é;Iå`ã?àA@HKLî?H$Yìâuã?L Þ áMP@Kê Sã?LOpãª^íõA;IHKJFIãªXìã?âkJ<?@ !P@8>+@9HKLR@XSHKH$Y]JQSHL!F=èªQ¹J$!PF=X+Yã?âkYA<WJ<í<WJ8JQSHL!FIèªQJ³^íãª^íH$XJUã?â,JFé^íH?ô»FéX`JQSHNL!FIèªQJUY+ãª@9H?ôPã?â,JQSHNL!FIèªQJUâxã?L!^]ô»F=X`JQ+HNOpãª^íõÇ;IHKJ9HGH»J9H$XJKôS<?X+Y`TFIJQ+F=XJQSHLH$@9J9L!FéOpJFIãªX+@ì<Wè?LHKH$Y·>Sõ ãªX FéX<?YSîW<?X+OpH?ê ã?LHKãzî?HKL$ô>+@9HKL!@<WLHð;=F=^F=J9H$Y F=XJQSH$FILì<WàAF=;=F=JFIH$@âxã?Lî?HKLàA<?;éF=@<WJFIãªXì<?X+YìY+FIè?H$@JFIãªXã?âkY+<WJ<Pô+<?XAYäà»å`JQ+H$FILQ+<WàAFIJ@KôPõ+LR<?OpJF=OpH$@KôS<?X+Y]OK>+;IJ>+L!<?;AH$XîPFILãªX+^íH$XJKê

\8Q+H$@9H;éF=^FIJ<WJFIãªXA@,^<$å½OK<?>+@9H³F=XJ9H$;=;IH$OpJ>+<?;ãzî?HKLàÇ>SL!YSH$X+FéXSè8ã?âA>+@HKL!@Kê ãª@9J@9åP@9J9H$^@kJQ+<WJkLH»>+FILH@9ã?õAQAF=@9JF=OK<WJ9H$Yß;IH$<WL!XAF=XSè Opãª>+L!@9H$@âuã?L]JQ+H$FILäHPõA;Iã?LR<WJFIãªXß<?X+Yß>SJF=;=F:9$<WJF=ãªX Y+F=Y¿XSã?J]OpãªX+@FéYSHKLäJQ+H$@9H;=F=^`FIJ<WJFIãªX+@ì<?X+Y·Y+FéY¿X+ã?J[Opã?õHðTFIJQ¿LH$<?;/;=FIâxH @FIJ>+<WJFIãªXA@Kê\8QSH <Wõ+õ+L!ãª<?O!Q·TH >+@9Hðâxã?L[<$î?ãªF=YAF=XSèãzî?HKLR;Iãª<?Y F=@8àA<?@9H$Y]ãªX]ã?àÇ@9HKLîW<WJFIãªX]ã?â LH$<?;,<Wõ+õÇ;=F=OK<WJFIãªX+@à HKâxã?LH/YSHKî?H$;Iã?õAFéXSèíJQSH/@9åP@9J9H$^]ê

Þ HN^<$åíHPJ9L!<?OpJU;éFIâuH8OK<?@H$@(âxLãª^ ã?àA@HKLîm<WJF=ãªX+@(F=X"L!H$<?;=FIJEå?ôTQ+F=ORQí<WLHî?HKL!å">A@9HKâx>A;S@9ãª>SL!OpH?ôTQSH$XPBHKî?HKLí< Þ áM F=@è?ãªF=XSè J9ã àHäYSHKî?H$;Iã?õ H$Y âxLãª^ @OpL!<WJORQã?L½F=@LH»>+FILH$Y J9ã õALãzîPF=YSH`< X+<WJ>SLR<?; à HpBQ+<zî»FIãª>+L$êPáhXìJQSH;=<WJ9J9HKLOK<?@9H0>+@9HKLR@<WLH/XSã?J³LH»>+FILH$YJ9ã;IH$<WL!XìJQ+HàH$QA<$îPFIãª>SL³ã?âJQ+H Þ áMêSáhXA@9J9H$<?YôJQSH0>A@9HKL8OK<?X OpãªXJF=X»>SH0>+@FéXSè½< OK;=<?@@F=OK<?; SàH$QA<$îPFIãª>SL!<?; õA<WJ9J9HKLRXê ý Ý @U<^íã?JFIîW<WJF=XSèHS<?^íõA;IH8;IHKJ>A@OpãªX+@F=Y+HKLJQSH8;=FIâxHOK<?@9H/ú ù!ý?ø ù "ã?â <õ HKL!@9ãªXôWTQ+FéO!QOpãªX+@Fé@9J@ã?â

JQSH O!QA<?XSè?H ã?âàA<?@F=O LH$;IãPOK<WJFIãªXYA<WJ< FéX+OK;=>+Y+FéXSè JQSH õ ãª@@!FIàA;IH]LH$^ãzîW<?;ã?â/YA<WJ< ãªXJQSHãª;=Y;IãPOK<WJFIãªXô

JQSHO!Q+<?XSè?H0ã?âkã äOKF=<?;,YSãPOK>+^íH$XJ@8@>+ORQ[<?@JQSH0õA<?@@9õ ã?LJKô JQSH½ã?õ+JFIãªXA<?;ORQ+<?XSè?H"ã?âLH$;=<WJF=ãªX[H$X+Q+<?XAOpH$^íH$X¹J@@!>+O!Q<?@NJQSHL!HKèªF=@9J9L!<WJFIãªX ã?âõ HKJ@KôÇLH$;IãPOK<WJFIãªXã?âOK<WL!@Kô

JQSHðORQ+<?XSè?Hðã?â0õ HKL!@ãªX+<?;@õH$OKF=öAO YA<WJ< @!>+O!Q·<?@ìâ<?^F=;Iå H$XAQ+<?X+OpH$^íH$XJ@Kô³ã?L]LH$;=<WJFIãªXA@Q+FIõA@`J9ãLH$;éFIèªFIãª>+@à ã»YAFIH$@Kô

JQSHO!Q+<?X+è?HUã?âAYA<WJ<8âxã?Lk<?Y+YAFIJFIãªX+<?;?L!H$;Iã»OK<WJF=ãªX0<?X+XSãª>AX+OpH$^íH$XJ@@>AO!Q½<?@J< ômFéX+@>SL!<?XAOpH(O!Q+<?X+è?H$@Kô<?X+Y

@9õ H$OKFIöÇON<?YAY+FIJFIãªX+<?; J<?@"!»@8@!>+O!Q[<?@<Wõ+õA;=FéOK<WJFIãªX+@³âxã?LQSãª>+@FéXSèí<?;=;IãzT³<?X+OpH$@Kê\8Q+HíõHKLR@9ãªXð<?OpJ@FéX JQSHLãª;IHíã?â³<?X ÷!÷ pú~ê Þ Hã?àA@9HKL!î?HJQ+<WJú ù!ýªø ù Fé@GH$X+Q+<?X+OpH$Yðà»å JQSH

õ+Lã?öÇ;IHíã?âJQSH`F=@!@>SHKL$ôà»å JQSHä@9õ H$OKFIöÇO"J<?@ !»@LH$;=<WJ9H$Y J9ã JQSH ú ù !ý?ø ù ðã?â³JQSHäFé@@>SHKL$ôà»åð@9õ H$OKFIöAO;=<zT@(<?X+YLHKèª>+;=<WJFIãªXA@Kôª<?X+Yíà»åí<?YSîm<?XAOpH$Yâ>+X+OpJFIãªX+<?;éFIJEåLH>AFILH$Y"âxã?LU<?@@9ãPOKF=<WJF=X+è/JQSH;=F=âuHOK<?@9HTFIJQã?JQSHKLN;=FIâxHGOK<?@H$@Kê

\8Q+H;=FIâxHOK<?@9H[ú ù!ý?ø ù OpãªX+@!F=@9J@ã?â@9J9HKõA@@>+ORQ <?@ = ý ìù7äýªþªþ?ú p÷!÷þªýªøsýWô = ý ìù7`þªý?øsý7KùWúým÷!÷Kù ý?ø þ !ù pô = ý `ùI7½ú ÷pøúCýªø ù þªýªøsý"âuã?LOK<WL!@$ôõHKJ@$ôÇHKJOWêIô = ý `ù7½÷ þªý?øsý?ôH?êèSê Y+<WJ<âxã?LõA>+àA;=F=OG<?>SJQSã?LRFIJEåìLH$@9õ ãªX+@!FIàA;IHGâxã?L<?;=FIH$XA@Kô = ý ù7½þªýªøsý 7pù?ú/÷pù ý ý þWôÇHKJOWê\QSH$@9H@9J9HKõA@G<WLH"àA>AX+Y+;IH$Y]J9ã?è?HKJQ+HKL0Y+>SHJ9ãJQ+H$FILL!H$;=<WJFIãªX+@QAFIõ J9ãìãªXSH½õ HKL!@9ãªX<?X+YJ9ããªX+H½;=F=âuH½OK<?@9H?ê\8QSH<?@@9ãPOKF=<WJFIãªXA@,^<$åà HLHKõALH$@9H$XJ9H$Y/à»åG<?YAQSH$@FIãªXGã?âSY+F HKLH$XJ@9J9HKõA@$ô$H?êèSêzLHKõALH$@9H$XJF=XSèJQSH(<?@!@9ã»OKFé<WJFIãªXã?â@9J9HKõA@à»åì<Q¹å»õ HKLè?L!<WõAQ,ô»H?êèSêÇJQSHãªXSH0FéX kF=èª>SLH ê

@iAkCBX& UC !k[ X6Z KZPC 2>noC' 7 Rým÷p÷<WLH/ORQ+<WL!<?OpJ9HKL!F:9KH$Y à»åÇÿ kn8Chp 2[ X&knNb Þ H<WLHF=XJ9HKLH$@9J9H$YðFéX JQ+H"Opãª;é;IH$OpJFIãªXð<?X+Yð<?@@H$@@^íH$XJã?â(à H$Q+<zî»FIãª>+LNL!H$;=<WJF=XSèJ9ã

JQSH@9õ H$OKFIöÇO<Wõ+õÇ;=F=OK<WJFIãªXê»\8Q+F=@UTãª>+;=YäJEå»õAF=OK<?;=;IåäF=X¹î?ãª;=î?HG<?Xã?àA@HKLîm<WJF=ãªXìã?âà H$Q+<$îPFIãª>SLã?â>A@9HKL!@F=XäLH$<?;H$Xî»FIL!ãªX+^íH$XJ@Kô»FéX+OK;=>+Y+FéXSè/<0àÇ<?O"!»è?Lãª>+X+Y]ORQSH$O"!äJQ+<WJ³LH$;=<WJ9H$@>+@<Wè?HGJ9ãíF=XJ9H$X¹JF=ãªX+@Kô»è?ãª<?;=@ã?LJ<?@ !»@$ê

qEc!~8c!tsloCd,!yÇ$tsRqegz?~c!qElojy|!q´½fCNwujyµRqs8c!tsloRj/$gzdtsfCd wmidscRRfjWc!gdelod R

J"IvY

H

H

HOHY Y Y H

YY H

Y H

.0/21 ²¹² lofhqEc!qsEmlo9c!gNRqEfrqsf9Noly|f9cRdefdtsfh¡mdy|!q H Y

0 p]X UCqnonoCqnNb \8Q+Fé@F=Xî?ãª;Iî?H$@ <WLL!<?XSèªFéXSèN<?;é;¹JQSH³<?OpJFIãªX+@kã?àA@HKLî?H$Y"F=X<?X"<Wõ+õÇ;=F=OK<WJFIãªXF=X¹J9ãG<G^<?F=X½;Iã?èWBF=OK<?; <?X+YOpãªQSHKLH$XJ³õA<WJ9J9HKL!XêPáCXä@ãª^íHNOK<?@H?ô+YSHKî»Fé<WJFIãªX+@Uã?â,JQSHG^<?F=XäõA<WJ9J9HKL!X]^½>+@9J(à HG^íãPYSH$;=;IH$YJQSL!ãª>SèªQ]HSOpHKõ+JFIãªX+@KêAáhX]^íãª@JOK<?@9H$@Kô+TH0OK<?X >+@9HõA<WL!<?;é;IH$;H»H$OK>SJF=ãªX[ã?âF=X+YSHKõ H$X+Y+H$X¹J³<?OpJFIãªX+@Kê

nonoCqnon C'&[Wb \Q+F=@íF=Xî?ãª;Iî?H$@íJQSH LH$OpãªX+@9J9L!>AOpJFIãªX ã?âNJQSH @9H»>SH$X+OpH]ã?â<?OpJFIãªX+@`<?X+Y @9õ H$OKFIöAOà HpBQ+<zî»F=ãª>SL/ã?â>+@9HKL!@$ê\8Q+F=@GTF=;=; <?F=Y F=X >+X+YSHKL!@J<?X+Y+F=XSèJQSHL!ãª;IHH$<?O!Q F=X+YAFIî»FéY+>+<?;kQ+<?@TFIJQAF=X JQSH@9J9ã?L!å?ê+árJ<?@@F=@9J@F=X]YSHKî?H$;Iã?õAFéXSè"JQSH0>+@9HKLõALã?öA;IH?ê

_ & ( ( l 24# ! pjX$# CqnNb Ý ;=F=@9Jã?âPàA<?O !è?Lãª>AX+Y0F=XAOK;=>+Y+F=X+è(õAQå»@!F=OK<?;eô$<?X+Yà H$Q+<zî»F=ãª>SL!<?;?O!QA<WL!<?OpJ9HKL!F=@9JFéOK@ã?âF=X+Y+FIîPF=Y+>A<?;=@F=@GOpãªX+Y+>+OpJ9H$Y,ê \Q+F=@N;=F=@9JNOK<?Xð<?;=@9ãìà H½>+@H$Y âxã?LYSHKL!FIîPF=XSèäJQSHí^íãª@9J<Wõ+õ+L!ã?õ+L!F=<WJ9HF=XJ9HKLîPFIHKT·J9H$O!QAX+F »>SHTUHY+F=@OK>+@!@³àH$;=ãzT/ê

_ &[8Cqp1! Chp]noX& 24# UXADCqpjC%& UC>b Ý îm<WL!Fé<WJFIãªX F=X JQSH"<?OpJFIî»F=JEå[TFé;=; LH$;=<WJ9H½J9ãäîW<WL!F=<WJF=ãªX+@8ã?âã?JQ+HKLN;=F=âuHOK<?@9H$@$ê

a & $24& UCmX>Z [6 C24& ( !$#824UC>b \8Q+H0O!QSãªFéOpH$@^<?YSH<?;=@9ãYSHKõ H$X+YìãªX[^ã?àAF=;=FIJrå?ô+@>SLL!ãª>+X+Y+F=X+èSô<?X+Y @O!QSH$YA>+;IH$@³ã?â HKî?H$X¹J@ã?â F=X¹J9HKL!H$@9JKê

BA 2 p 2 N[8Cqp n4[ 8Wn X>Z [jADC# KZPC 2 noC6b áhX+YAFIî»FéY+>+<?;=@>+@!F=XSè <@9HKLîPF=OpHä^`<$å à H`è?L!ãª>Sõ H$Y à»å O!Q+<WLR<?O~BJ9HKL!Fé@9JF=OK@Kê+Z³<?@9H$Y ãªX]JQ+F=@³è?Lãª>+õAF=XSè<í@Fé^F=;=<WL³à H$Q+<$îPFIãª>SL8Fé@³ã?àA@9HKLî?H$Yê

"!.! Cqp C%& UC24& ( n$# #6# nNb áCX+Y+FIîPF=Y+>A<?;=@^<$åQ+<$î?H"JQSH$F=LNãTXH»õ HKL!F=H$X+OpH0TF=JQ @9HKL!î»F=OpH$@Nõ+L!ãzîPF=YSH$YF=XìL!H$<?;,;=FIâxH<?X+Y]JQ»>+@8>+@9H/YAFHKL!H$X¹Jà H$Q+<zî»FIãª>+L!<?; õA<WJ9J9HKL!X]ã?â@9HKL!î»F=OpHH$^õA;IãzåP^íH$XJKê

áCXìè?H$XSHKL!<?;eôÇ;=FIâxHNOK<?@9H@9J>+Y+FIH$@<WL!H/YSH$@FIèªXSH$YìJ9ã`õ+LãPY+>+OpH<"õAF=OpJ>SL!HNã?â @9HKLîPF=OpHH$^íõÇ;IãzåP^íH$XJJQ+<WJF=@½<?@"<?OKOK>SL!<WJ9H]<?@½õãª@!@FIàA;IH?êDHKJ9HKLR^F=X+F=X+è&% = û ' = ù%(')% = pú '% = <?X+Y*% = û<@9HKLîPF=OpHìF=@½OK<?;=;IH$Y>+@FéXSè+% = ý?øY+<WJ<]õALãzîPF=YSH$@<ìà HKJ9J9HKL/õAFéOpJ>SLH"âuã?L>SJF=;=F=@!<WJFIãªX @OpH$X+<WL!FIãSê Ý @/;=F=âuH"OK<?@9H$@0<WL!H`>+@9H$Y âxã?L»>+<?;=FIJråOpãªXJ9Lãª;eôÇTUH½^>+@JOK<WLHKâ>+;=;IåLH$Opã?L!Y ãª>SLã?àA@HKLîm<WJF=ãªX+@Kê Þ H½H$FIJQSHKLN>+@9H/<`XA<WJ>SL!<?;;é<?XSèª>+<Wè?H@9õ H$OKFIöAOK<WJF=ãªXìã?L<í@9H$^FIBsâuã?L!^`<?; ãªXSH0<?@Y+H$@OpL!FIà H$Yì;=<WJ9HKL$ê ý -, %,HKJ]>+@`OpãªXA@F=YSHKLJQSH @>Sõ+õ ã?LJíã?â0Q+ã?J9H$;N@H$<WL!O!Q¿TFIJQAF=X <?X¿F=XSâxã?L!^<WJFIãªX@9HKLîPF=OpH?êUáCXJQ+F=@"OK<?@9H TUH[^<zå ã?àÇ@9HKLî?H]JQSH]à H$Q+<zî»FIãª>+L½ã?âGF=X+YAFIî»FéY+>+<?;=@F=XJ9LR<$î?H$;8<Wè?H$X+OKF=H$@íTQ+F=;=H@9HKH!PF=XSè âxã?LQSã?J9H$;=@$ê Þ H`ã?àA@HKLî?H`JQ+<WJF=X ^íãª@9JOK<?@9H$@@H$<WL!O!Q àA<?@9H$Y ãªX <?@@9ãPOKF=<WJFIãªXA@/F=@õ+L!HKâuHKLL!H$Yðãzî?HKL"@9H$<WL!ORQà»å`^<?F=X`õ+Lã?õ HKLJFIH$@U@>+O!Qì<?@X+<?^íH?ôP<?Y+YSLH$@!@(ã?L³â<?OKF=;=FIJFIH$@$ê Ý @!@9ã»OKFé<WJFIãªX+@^<$åà Hã?â<;é<WLè?HîW<WL!FIHKJrå?ôH?êèSêOpãªX¹î?H$XAFIH$X+OpH"J9ãäL!H$<?O!Qð<QSã?J9H$;eô ;Iã»OK<WJF=ãªX F=XOpHKLJ<?F=X^<WõA@$ôÇõA;é<?OpH$@ã?â(FéX¹J9HKLH$@JKôÇã?LGHKî?H$XJ@GJQ+<WJQ+<zî?HOK<?>+@9H$Y[JQSH0@9H$<WL!ORQêëNJQ+HKL@9H$<WL!ORQ OpL!FIJ9HKLRF=<í^<$åìà HàA<WLèª<?FéXìã?LàA>+XAY+;IH$Yäã HKL!@$ê Ý JJQSH@<?^íHJF=^íH0TUH/ã?àÇ@9HKLî?H/JQ+<WJNQSã?J9H$;@H$<WL!O!Q F=@8Opãª^àAF=XSH$Y]TFIJQ]ã?JQSHKLNF=X¹J9H$XJFIãªX+@8ã?â >A@9HKL!@8@>AO!Q <?@î»Fé@FIJF=XSèOK>+;IJ>+L!<?;F=X+@9JF=J>SJFIãªX+@Kê»áhJ8^<$å]YSHKõ H$X+YìãªX]L!H$@>+;IJ@³âxã?L@9H$<WL!ORQ[ã?â ã?JQSHKLNF=X+Y+FIîPF=Y+>A<?;=@Kê

Ý XSã?JQSHKLHS<?^íõA;IHNã?â<";=F=âuHGOK<?@9H/@9J>+Y+åF=@JQSHGàã»ã!PF=XSè½ã?â,J9L!<?F=XJF=O !?HKJ@YSHKõ H$X+Y+FéXSè/ãªXìF=X+Y+F=î»F=YSB>+<?;=@$ôSã HKL!@8ã?âkLR<?F=;IT³<$åìOpãª^íõA<?X+FIH$@$ô+OKFIL!OK>+^@J<?X+OpH$@ã?â F=X+Y+FIîPF=Y+>A<?;=@(<WLH>+@F=XSè"J9L!<?FéX+@KôPHKJOWê

/. ZC 2 n8C C 6C%#KX! C%&[%F=âuH/OK<?@9H$@^<$åìà H/YSHKî?H$;Iã?õ H$Y]<?X+Y F=X¹J9HKL!õ+LHKJ9H$Y[@9J9HKõ àåì@9J9HKõ,ÿ


ñWê\8Q+HUö+LR@9J@9J9HKõíY+>+L!F=XSè;éFIâuHOK<?@9HOpãª;=;IH$OpJFIãªX"F=@kJQSH³@>SL!î?HKå/ã?â+õ ãª@@FIàÇ;IH(<Wõ+õA;éF=OK<WJFIãªX0OK<?@H$@TUH³^FIèªQJOpãªX+@!F=YSHKL$ê \8QSH½ã?àA@9HKLîW<WJFIãªX+@Opãª>A;=Y QA<$î?H^íã?LH"JQ+<?X ãªX+H"^H$<?X+F=XSèì<?X+Y ^<$å âuãª;é;IãzT <ìîW<WL!FIHKJEåã?â>+@9HKLBsLH$;=<WJ9H$Y]è?ãª<?;=@$ê+áhXìJQAF=@8OK<?@9H/TH0OpãªX+@!F=YSHKLJQSH0^ãª@9J8;=F !?H$;Iå^íH$<?X+F=X+èSê

ò»ê\8Q+H @9H$OpãªX+Y¿@9J9HKõßF=X¹î?ãª;=î?H$@`< Y+HKHKõ¿<?@@H$@@^íH$XJ`ã?âJQSH;=FIâxH[OK<?@9H$@Kê Þ H HPJ9L!<?OpJJQSH Y+F HKLH$XJHPH$OK>SJFIãªXßã?L!Y+HKL!@Kô(JQ+HL!H$;=<WJFIãªX+@QAFIõ <?^íãªXSè <?OpJFIãªXA@Kô<?X+Y JQ+HL!ãª;IH$@äFéX+Y+FIîPF=Y+>+<?;é@"õA;=<$å JQ+H$@9H<?OpJFIãªXA@Kê

ê\8Q+HNJQAFIL!Y@9J9HKõ[HPJ9L!<?OpJ@JQSãª@9H/;éFIâuHGOK<?@9H0ORQ+<WL!<?OpJ9HKL!Fé@9JF=OK@JQ+<WJ<WLH/YAF=@9JF=XSèª>AF=@Q+F=X+èâuH$<WJ>SL!H$@8<?X+Y<WLHLH$;IHKîW<?X¹Jâxã?LJF=^H8<?X+Y;IãPOK<WJFIãªXê Ý JUJQSH8@<?^íH8JFé^íHTUH@9H$<WL!O!Q`âuã?L@F=^Fé;=<WL!FIJFIH$@TFIJQAF=X0JQ+H$@9H;=F=âuHOK<?@9H$@Kê

Sê\8Q+HNöÇX+<?; @9J9HKõ[F=@OpãªX+OpHKL!X+H$YìTFIJQJQSH/O!QA<WL!<?OpJ9HKL!F:9$<WJFIãªX[ã?âõ ã?J9H$XJF=<?;>+@9HKL!@$ôJQSH$F=LàH$QA<$îPFIãª>SL!<?;õA<WJ9J9HKLRX+@KôA<?X+Y[JQSH$FILLãª;IH$@F=Xìîm<WLRFIãª>+@@9J<Wè?H$@ã?âJQ+H0;=FIâxHOK<?@9H?ê

ãª;é;IH$OpJFIî?H$;Iå?ô,JQAF=@/F=XSâxã?L!^<WJF=ãªXðTF=;=;kõ+L!ã»Y+>AOpH`<]õAF=OpJ>+LHíã?âJQSH`;=F=âuHOK<?@9HäTUH<WLHäFéX¹J9H$X+YAF=XSèìJ9ã@>SõAõã?L!Jà»å < Þ áMê \8Q+F=@N^<zå õ+LãPY+>+OpH½â>SLJQSHKLG;=FIâxHOK<?@9H$@$ôã?L/^<$å<?F=Y F=X L!H$Y+>+OKF=XSèJQSH"<?^íãª>+XJã?âYSHKî?H$;=ã?õA^íH$XJKêáhJ½^`<$å LH$@!>+;IJFéX < õ+L!FIã?L!F=JF=@<WJFIãªXðã?â8;éFIâuHOK<?@9H$@">+X+YSHKL½OpãªX+@F=Y+HKL!<WJFIãªXôk<?@@F=@9J½F=XJQSH`;éF=X&!W<Wè?Hã?â³õã?J9H$XJF=<?;=;=å LH$;é<WJ9H$Y ;=FIâxHOK<?@9H$@Kôk<?@@F=@J0F=X <?@@H$@@F=XSè]JQ+H`õ ã?J9H$X¹JFé<?;ã?âJQSH Þ á9M YSHpBî?H$;Iã?õA^H$X¹JKôSõ+L!ãzîPF=YSHNJQSH Þ áMäYSHKî?H$;Iã?õ HKL!@TFIJQLH$;IHKîW<?XJ³;=H$<?Y+@³<?X+Yì@9J9L!<WJ9HKèªFIH$@Kô+<?XAY!?HKHKõ]JQSH Þ áMYSHKî?H$;Iã?õÇ^íH$X¹J(ãªXJ9L!<?O !"<?XAY>+X+Y+Fé@9J9L!<?OpJ9H$Yêª\8Q+H$@9H8;=FIâxH8OK<?@9H<WLH^<Wõ+õ H$Y"J9ã@OpH$XA<WL!FIãª@F=XJQSH8@9H»>SH$;eê\8QSH/FéX¹J9HKè?L!<WJF=ãªX]ã?â@OpH$X+<WL!FIãª@OK<?X <?;=@9ãíà HàA<?@H$Y]ãªX[;=FIâxHOK<?@9H$@Kê

ý %,HKJG>+@GOpãªX+@FéYSHKLN<?XF=XSâxã?L!^<WJF=ãªX @9HKL!î»F=OpHâuã?L<OKFIJEå ã?L<`LHKèªF=ãªXôÇTQ+F=O!Q @>Sõ+õ ã?LJ@N<X»>+^0à HKLã?â;=FIâxHOK<?@9H$@Kÿ

Ý J9J9L!<?OpJFéXSè`îPF=@FIJ9ã?LR@Kÿ+\8QSH/F=X+âuã?L!^`<WJFIãªXìTUH<WLH/õ+Lãî»FéY+F=XSèíF=@àÇ<?@9H$Y]ãªX @ãª^íH0F=XSâxã?L!^<WJF=ãªX]XSHKH$YîPF=@FIJ9ã?LR@(^<zåäQ+<zî?H?êP\QSH;=F=âuHNOK<?@9HGâuãª;=;=ãzT@(JQSãª@9HGJQ+<WJTUHNã?àA@9HKLî?HY+>+L!F=XSè/^<WL !?HKJF=XSè"<?OpJFIî»F=JFIH$@Kê

áCX+Q+<WàAF=J<?X¹J@NF=XSâxã?L!^<WJFIãªX,ÿÇ\8QSH";=FIâxHOK<?@H"Fé@àÇ<?@9H$YãªX@H$;IH$OpJ9H$YðF=XSâxã?L!^<WJFIãªX O!Q»>+X&!P@NJQ+<WJ^<$åà H/ã?âF=XJ9HKLH$@9JJ9ãäF=X+YAFIî»FéY+>+<?;=@Kô»<?X ã?LRYSHKL!F=XSèíã?âJQ+H0Opã?LLH$@9õ ãªX+YAF=XSè<$îW<?F=;=<WàÇ;IH0F=XSâxã?L!^<WJF=ãªXô+<?X+Y<Y+HKL!FIîW<WàA;IHGõ HKL!@9ãªX+<?; XSHKT@õA<Wõ HKL$ê

áCXSâxã?L!^F=XSè"J9ãª>SLRF=@9J@KÿS\8QSH/;éFIâuHOK<?@9H½F=@@F=^`F=;=<WL³J9ãJQSãª@9H0ã?àA@9HKLî?H$Y[FéX]OKFIJEå]F=XSâxã?L!^<WJF=ãªX]OpH$X¹J9LH$@$ê (LãzîPF=Y+F=X+è/ã ÒKF=<?;OKFIJEåFéXSâuã?LR^<WJFIãªXJ9ã"F=X+QA<WàAFIJ<?XJ@Kÿ¹\8Q+Fé@;=FIâxHOK<?@9HGâxãª;=;IãzT@JQSHG^íH$@@<Wè?HNà ãª<WL!Y^íHKJ<WõÇQSã?L8JQ+<WJFé@8>+@9H$Yìâxã?LXSHKT@9õA<Wõ HKLF=XSâxã?L!^<WJFIãªXê

DG>SL!FéXSè"JQSH0YSHKî?H$;Iã?õÇ^íH$X¹Jã?âOKFIJrå]F=XSâxã?L!^<WJFIãªXì@9HKLîPF=OpH$@8@!>+O!Q[<?@JQSH0@9HKL!î»F=OpH (!= 5 .P# C=TH/Q+<$î?H/^<?Y+H/<½;éFIâuHGOK<?@9H0<?XA<?;Iå»@!F=@âuã?L8OKFIJråäF=X+âuã?L!^`<WJFIãªXì@9HKLîPF=OpH$@<?X+Y]YSHKJ9H$OpJ9H$Y[<WL!ãª>+X+Y íY+F HKL9BH$XJ0;=FIâxH½OK<?@H$@Kê Þ HÒK<?X OK<WJ9HKè?ã?L!F:9KH`JQ+H$@9H;=FIâxHíOK<?@9H$@à»å JQSHOpãªXJ9H$XJ<?X+Y FéXSâuã?LR^<WJFIãªX YSH$^<?X+Y ã?âF=X+YAFIî»FéY+>+<?;=@Kê¹áhX]JQAF=@OK<?@9H/TH0Y+F=@JF=XSèª>+F=@!Qÿ

;=F=âuHOK<?@9H$@ìLH$;=<WJ9H$Y¿J9ã J9ãª>SL!F=@9JìOpãªXJ9H$X¹J]âxã?LFéX+Q+<WàAFIJ<?XJ@äõHKLR^<?XSH$XJ;Iå ;=FIîPF=XSè F=XJQSH OKFIJEå?ô³âxã?LF=XAQ+<WàAFIJ<?XJ@8J9H$^íõ ã?L!<WLRF=;Iåì;=FIîPF=XSèF=X JQSHOKFIJrå?ôÇâxã?LG@QSã?LJCBsJ9HKL!^ J9ãª>SL!Fé@9J@<?XAY[àA>+@!F=XSH$@@õ HKã?õA;=H/ãªX@Q+ã?LJ8J9HKL!^ J9L!FIõ,ôAâuã?Lîm<?OK<WJFIãªXAF=@9J@õA;=<?X+X+FéXSèí<J9L!FIõ âuã?LG^íã?LH/JQA<?X `Y+<$åP@KôAâxã?LJ9HKH$XA<Wè?HKL!@NTFIJQ>+XAOpHKLJ<?F=XTF=@QSH$@Kô¹âuã?L³@9H$X+FIã?LR@(TF=JQõA<WLJFéOK>+;=<WL(F=XJ9HKLH$@9J@$ôâxã?LUTHKH!BsH$X+Yî»F=@!FIJ9ã?L!@Kôªâxã?Lî»F=@!FIJ9ã?L!@ã?âQ+F=èªQ+;=FIèªQJ@KôPâuH$@JFIîm<?;é@KôPHKJOWê

;=F=âuH½OK<?@9H$@GLH$;=<WJ9H$YJ9ãìã ÒKF=<?;kOpãªX¹J9H$XJâxã?LGFéX+Q+<WàAFIJ<?XJ@ãªX@H$<WL!O!QJQSLãª>+èªQYAFILH$OpJ9ã?Lå]ã?âUõA>SàA;=FéO<?>SJQ+ã?L!FIJEå?ô âxã?LNFéX+Q+<WàAFIJ<?XJ@8ãªX @9H$<WLRO!Q âxã?LH$^íHKL!è?H$X+Opå OK<?@9H$@$ôâxã?LGF=X+Q+<WàAF=J<?X¹J@ã?L!FIH$XJF=XSèäJQSH$^"B@9H$;=î?H$@[à HKâuã?L!H <WõAõA;IåPF=XSè <WJ[õA>SàÇ;=F=O[ã äOpH$@Kôâxã?L F=X+QA<WàAFIJ<?XJ@FéX¹J9HKLH$@J9H$Y F=Xßõ+L!ã?àA;IH$^@ã?âíOKFIJEå^<?XA<Wè?H$^íH$X¹JKôÇHKJOWê

;=F=âuHOK<?@9H$@L!H$;=<WJ9H$YíJ9ã/àA>A@F=XSH$@@kOpãªXJ9H$X¹JKôH?êèSêªâuã?LUF=X¹î?H$@J9ã?L!@OpãªX+@FéYSHKL!F=XSèH$XSèª<Wè?H$^íH$XJUF=X"JQ+H8<WLH$<Pê

qEc!~8c!tsloCd,!yÇ$tsRqegz?~c!qElojy|!q´½fCNwujyµRqs8c!tsloRj/$gzdtsfCd wmidscRRfjWc!gdelod Sã?LJQSHNOpãª;=;IH$OpJFIãªX<?X+YYSHKî?H$;=ã?õA^íH$XJ(ã?â,;=FIâxH8OK<?@9H$@³FIJ(Fé@(XSã?L!^`<?;=;Iå<0è?ããPYF=YSH$<J9ã½F=X¹J9HKL!î»FIHKTJQSH

õ HKL!@9ãªX+X+H$;OK>+LLH$XJ;IåäõALãzîPF=Y+F=X+èJQSH@9HKLîPF=OpH?ê

%FIâuH/OK<?@H@QSãª>A;=Yìà H/O!QSH$O !?H$Y<Wèª<?FéX+@9J@!> `Opå?ê Ý @JQSHKå[^<zå]Q+<$î?H½<îW<WL!FIHKJEåìã?â J9L!<?OpH$@KôÇTUH½<?Y+YJETãä@J<Wè?H$@8J9ãä;éFIâuHOK<?@9H<?X+<?;IåP@F=@Kÿ"!.! # X6p12[ KX & b \QSH<?OpJ>+<?;;éFIâuHOK<?@9HF=@(õALãzîPF=YSH$YäJ9ã Þ áMOK>A@9J9ãª^íHKL!@<?X+YF=X+Opã?L!õã?LR<WJ9H$YäF=XJ9ã½JQSH$FIL

õ+L!ã»OpH$@@H$@Kê %F=âuH8OK<?@9HH»õÇ;Iã?L!<WJFIãªXíOK<?X`àHOpãªX+Y+>+OpJ9H$YFéXXSã?L!^<?;PH$XîPFILãªX+^íH$XJ@ã?â JQSH>A@9HKL(@>+ORQ<?@/Q+ãª^íHíã?L/Tã?L"!Çê,\QSH$Xð>+@9HKL!@OK<?X @QSãzT6JQSH<?OpJFIãªX+@TQ+F=;IH½JQSHKå <WLHíH»õÇ;=<?F=X+F=X+èäJQSH$F=L/<?F=^@<?X+Y[J<WLè?HKJ@Kê

! ! p]CqAkC'&kn X& b F=X+<?;=;=å?ôÇOpLãª@@NO!Q+H$O"!PF=XSèìã?â;=FIâxHOK<?@9H$@G<?X+Y>SJF=;éF=@<WJFIãªX[@!OpH$X+<WL!FIãF=@>A@9H$Y âxã?LGOpã?L9BLH$OpJF=ãªXô+HPJ9H$X+@FIãªX[<?XAY]< L!^<WJFIãªX[ã?âkJQ+H/YSHKî?H$;Iã?õ H$Y[>SJF=;éF=@<WJFIãªXì@OpH$X+<WLRFIãª@KêDG>SL!FéXSèí;=FIâxHNOK<?@9H0H$;=F=OKFIJ<WJFIãªX]<?XAY[@9õ H$OKFIöAOK<WJFIãªXì>+@HKL!@<WLH0OpãªXSâxLãªXJ9H$Y]TFIJQ]@"!?HKJO!QSH$@ã?âk@OpH$XA<WL9B

FIãª@Kê Þ H]<?@ ! TQA<WJ½>+@HKL!@0JQAF=X&! <Wà ãª>SJ0JQ+H$@9H]OpãªX+OpHKõ+J>+<?;=Fé@<WJFIãªX+@Kêk\8QSHâuHKH$Y+àA<?O"! F=@>A@9H$Y âxã?L"JQSHLHKöAX+H$^íH$X¹Jã?â;=F=âuHNOK<?@9H$@Kê Þ H^<$å>+@9HG< `X+FIJrå`Y+F=<Wè?LR<?^^F=XSèSôF=X`TQ+F=O!QOK<?@9HTHN<WL!L!<?XSè?HGJQSHGF=X+Y+F|BîPF=Y+>+<?;»OpãªX+OpHKõ+JFIãªXA@TUH8YAF=@Opãzî?HKL(ãªXí<GàA;=<?O"!»à ãª<WL!Yô?<?@@9ãPOKF=<WJ9H8JQ+H$^]ô?<?X+YíY+F=@OK>A@@kJQSH$FILLH$;=<WJF=ãªX+@Q+FIõJ9ã`JQ+Hè?H$XSHKL!<?;ORQ+<WL!<?OpJ9HKL!Fé@9JF=OK@ã?â Þ áMP@Kê Ý XSã?JQSHKLJ9H$ORQ+X+F »>SH/F=@8àA<?@9H$Y[ãªX OK<WL!Y @9ã?L!JF=XSè@F=^`F=;=<WL³J9ãJQSHN^íã»Y+H$;|Bsî»F=HKTBEOpãªX¹J9L!ãª;+OK<WL!Y+@U>+@9H$Y`FéX@9ã?âxJET³<WLHH$X+èªF=XSHKHKL!F=X+èSê?áhX`JQ+F=@OK<?@9HNOK<WL!Y+@ULHKõ+LH$@H$X¹J(@!F=^íõA;IH;=FIâxH@FIJ>+<WJF=ãªX+@Kêª\8QSH$F=L <?@!@9ã»OKFé<WJFIãªX+@<WLHJQSH$X`>+@H$Y"âuã?Lã?L!èª<?X+F=@F=X+èJQSH8OpãªX+OpHKõ+JFIãªXA@Kê¹\8QSH$@H8@ !?HKJO!QSH$@OK<?X[<?;=@ã½à HG>+@9H$Yìâxã?L8Y+F=@OK>A@@F=XSèYSHKî»Fé<WJFIãªX+@³âxLãª^ JQSH/XSã?L!^<?; OK<?@9H/<?XAYìâuã?L8@9H$<WLRO!Q]ã?âHPOpHKõ+JF=ãªX+<?;;=FIâxH OK<?@9H$@$êáCX+@9J9H$<?Y¿ã?â0YAFILH$OpJF=XSè >+@9HKL!@äJ9ã @õH$OKF=öAO ;=F=âuH OK<?@H$@ìTUH OK<?Xß@QSãzT5JQSH$^*JETãã?L]^íã?LH<?;IJ9HKL!XA<WJFIî?H$@8âxã?L8JQSHõ+L!ã?àA;IH$^ @9ãª;=>+JFIãªXê

%FIâuH8OK<?@H<?X+<?;IåP@F=@ è?ã»H$@à HKå?ãªX+Y"J<?@ !í<?X+<?;=å»@Fé@KêWárJ(Fé@@F=^íõA;=H<?X+YH$<?@9å"J9ã0OK<WLLå½ãª>SJKô¹;=F=èªQ¹JrTUH$FIèªQJ<?X+Y @9J9L!<?FIèªQJ9âxã?LT<WLRY J9ã >+X+YSHKLR@9J<?X+Yô<?XAY å?HKJ >AFIJ9Hä<?OKOK>SLR<WJ9HF=X F=YSH$XJFIâxå»FéXSèìJQSHäL!H$<?;UYSH$^`<?X+Y+@>+@9HKLR@ ã?âÇ< Þ á9M½^F=èªQ¹JQ+<zî?H?ê Þ Q+F=;IHã?àA@9HKLîPF=XSèNLH$<?;+;éFIâuH³OK<?@9H$@<?XAYí^<Wõ+õAF=X+èJQSH$^&J9ã/;=FIâxHOK<?@9H$@JQ+<WJ^½>+@9JGà H½@>+õ+õ ã?LJ9H$Yàå JQSH Þ áM TUHíOK<WLL!å ãª>SJ/<ì>+@9HKLBEOpH$X¹J9HKLH$Y YSHKî?H$;Iã?õA^íH$XJKê Ý Y+Y+FIJFIãªXA<?;=;Iå?ô+TH^<zå[F=YSH$XJFIâuå<?X+Y]LH$@ãª;Iî?HOpãªX&ÇF=OpJF=XSèíã?LNOpãª^íõ HKJF=XSèF=XJ9H$X¹JF=ãªX+@KêA\8Q+H$@9H0OpãªX&AFéOpJ@8OK<?X à HLH$@ãª;Iî?H$YãªX JQ+H[àA<?@F=@ã?âG;éFIâuH[OK<?@H$@`à»å <?OKOpãª^^íãPY+<WJF=XSè àã?JQ F=X¹J9H$XJFIãªX+@$ô(FeêH?êâ>+;IöA;é;=F=XSè[JQ+H @9J< !?H$QSãª;éYSHKLF=XJ9H$X¹JF=ãªX+@8<?X+Y]@>+õ+õ ã?LJF=XSè½JQSH0YSH$^`<?X+Yìã?â>+@9HKL!@Kê

ZH$@F=Y+H$@³ã?àA@9HKLîW<WJFIãªXìã?âL!H$<?;;=FIâxHN@F=J>+<WJFIãªX+@³;=FIâxHOK<?@H0YSHKJ9H$OpJFIãªX]OK<?X[<?;é@9ã"àHKH$XàA<?@H$YìãªX Aø Kú7 %¿ø = ~÷?ê4H$@9H$<WL!O!Q ãªX]<WLJFIöAOKFé<?;F=X¹J9H$;é;=FIè?H$X+OpHGQ+<?@8<?;=@ãíLH$@>+;IJ9H$Y]FéX<íX»>+^à HKLã?âkF=XJ9HKLîPFIHKTJ9H$O!QAX+F »>SH$@Kÿ

?NX+@9J9L!>AOpJ>SLH$YíF=XJ9HKLîPFIHKT@OK<?Xíà H8OpãªX+@!F=YSHKLH$Yí<?@U<?X`F=XSâxã?L!^<?;P<?X+YH»õA;=ã?L!<WJFIî?H8OpãªXî?HKL!@<WJFIãªXäãªXè?ãª<?;=@³<">+@9HKL³F=@Uâuãª;é;IãzTFéXSè0<?X+YäãªXJ<?@ !»@³<">+@9HKL³Q+<?@UJ9ãíOpãª^íõA;IHKJ9H?ê?NX+@9J9L!>+OpJ>+LH$Y`F=XJ9HKLîPFIHKT@Uã?àSB@9HKL!î?HJQSHL!>+;IH$@kJQ+<WJ<WL!H8<Wõ+õA;=FIH$YJ9ã/à+LR<?F=X+@9J9ã?L!^`F=XSèSê Ý ;=;PF=XJ9HKLL!>SõAJFIãªX+@k@QSãª>+;=Yà H<$î?ãªF=YSH$Y,êª\8QSH»>SH$@9JFIãªXA@U<?@ !?H$Y]^½>+@9Jà H@Q+ã?LJ<?XAY@!F=^íõA;IHJ9ã"<?XA@9TUHKL<?X+Y@QSãª>A;=Yà HNã?õH$XSBsH$X+YSH$Y >SH$@JFIãªX+@KêáCX¹J9HKL!î»FIHKT õÇ<WLJXSHKL!@@Q+ãª>+;=Y @Q+<WLHíJQ+H$FILJQSãª>SèªQJ@/<?X+Y HPõ HKL!FIH$X+OpH$@Kê,\QSHKLHíF=@XSãB;>+YSè?H$^íH$XJKôOpãªXSâxLãªXJ<WJFIãªX ã?L/OpãªX+YSH$@!OpH$X+@FIãªXê ?N@9HKL!@G@QSãª>+;éY XSã?JGà H½;=H$<?Y J9ãT<WLRYð<OpHKL!J<?F=X @OpH$X+<WL!FIãSê ?NXPB@9J9LR>+OpJ>SLH$Y F=XJ9HKLîPFIHKT@í@Q+ãª>+;=Y ãªX+;Iå àH]F=XJ9HKLL!>+õ+J9H$Y FIâOK;é<WL!FIöAOK<WJFIãªXF=@"L!H>+F=LH$Yê\8QSHKå XSHKH$YOpãªX+@H$OK>SJFIî?HâxHKH$YSàA<?O"!F=Xäã?L!YSHKL³J9ã"èªFIî?HGJQSHF=X¹J9HKL!î»FIHKTHKH$@JQSHF=^íõ+L!H$@@FIãªX`JQ+<WJ³JQSHF=X¹J9HKL!î»FIHKTHKLF=@;=F=@9J9H$X+FéXSèSê Þ QAF=;IHJQSH0FéX¹J9HKLîPFIHKTHKH$@<WL!H/J<?; !PF=XSèSô+HKî?HKLå»JQ+F=X+èJQ+<WJ@HKH$^@J9ãäà H/F=^íõ ã?LJ<?XJF=@T8LRFIJ9J9H$X[YSãTX]<?X+Y[>+@H$Y]âuã?L;=<WJ9HKL »>SH$@9JFIãªX+@$ê

M»J9LR>+OpJ>SLH$Y]F=XJ9HKLîPFIHKT@³<WLHàA<?@H$Y]ãªX >+HKLå`õA;é<?X+@KêS\8QSH$@9HGõA;é<?X+@OK<?X]à HGàA<?@9H$YìãªX]JQSHè?H$X+HKL!<?;ORQ+<WL!<?OpJ9HKL!F=@JF=OK@íã?â Þ áMP@Kê Þ H[@9J<WLJíTF=JQ H$<?@9å »>SH$@9JFIãªX+@½ãªX Y+<WJ<ð<?XAY ^`<?F=X âx>+XAOpJFIãªX+@"<?X+YOpãªXJF=X»>SH0TF=JQ[JQSH½;=FIâxH0OK<?@9H$@Nã?âJQSH$FILN>SJF=;=F:9$<WJF=ãªXê ãªXJ9H»J<?X+Y F=X¹J9H$XJFIãªX+@<WLH"^íã?LHYAF`OK>+;IJJ9ãíOK<Wõ+J>SL!H?êSM»J9LR>+OpJ>SLH$YF=XJ9HKLî»F=HKT@U<WL!HN<?;=@ãàA<?@H$YäãªXâxH$<WJ>SLH$@KôPTQAF=O!QOK<?XàHN@QSãTXJ9ã">A@9HKL!@âxã?L<íL!<WJFéXSèíã?â JQSH$FIL8F=^íõ ã?LJ<?XAOpH?ê


%FIâuH]OK<?@9H$@OK<?X <?;=@ãðàH[Y+HKJ9H$OpJ9H$Y à»å ã?àA@HKLî»FéXSèð<?X+Y OpL!FIJFéOK<?;=;Iå <?X+<?;=å»@FéXSè õ+LãPY+>+OpJ@"ã?âGOpãª^"Bõ HKJFIJ9ã?L!@$ê (;=F=OKF=J<WJFIãªX]ã?â;=FIâxHOK<?@9H$@âxLãª^ HSF=@9JFéXSè@9ãª;=>SJF=ãªX+@F=@àA<?@H$Y[ãªX[@9õ H$OKFIöÇOK<WJFIãªX+@KôSLH$@!>+;IJ@âxLãª^ F=X¹J9HKL!î»FIHKT@TFIJQäàA>+@!F=XSH$@@>A@9HKL!@KôHPOpHKLõAJ@UâxLãª^ YSãPOK>+^íH$XJ@U<?X+Y@9õ+L!H$<?Y+@QSHKHKJ@Kô»<?X+<?;Iåq9KH$Y^íH$@!@<WèªF=XSèð<?X+Y J9L!<?X+@!<?OpJFIãªX+@Kô!»X+ãzT;IH$Y+è?HãªX JQSH]@9ãª;é>SJFIãªX+@JQ+<WJí<WLH]OK>SLLH$XJ;Iå >A@9H$Yô ^íHKJ<mBY+<WJ<ä<?X+Y OpãªXJ9HPJGFéXSâuã?LR^<WJFIãªX]ãªX JQSH>SJFé;=F:9$<WJFIãªX]TFIJQ+F=XìJQSHOK>SLLH$XJâxL!<?^íHKTã?L"!ôÇ<?X+Y JQ+FIL!YõA<WL!JEå]F=XSâxã?L!^<WJFIãªX,ê Ý @LH$<?@ãªX+@âxã?L8LH$@9J9L!FéOpJFIãªX+@OK<?X+XSã?JàH/OK<WõAJ>SLH$YôSJQSHOpã?õåPF=XSèíã?â <?;ILH$<?YSåHSF=@9JF=X+è@9ãª;=>SJFIãªXA@OK<?X ãªX+;IåäàH/>A@9H$Y[F=XìHSOpHKõ+JFIãªX+<?;@FIJ>+<WJFIãªXA@Kê

?N@9HKL!@G^<zå <?;=@9ãì>+@9Hõ+Lã?J9ãPOpãª;=@Nã?â 9;Iãª>+Y JQ+F=X&!PF=XSèPôAFéX TQAF=O!Q OK<?@9H"JQSHKå <WLH½õ+Lãî»F=Y+H$Y[TFIJQ<LH$<?;IBE;=FIâxHõALã?àA;IH$^ã?â < !PF=X+Y½JQ+<WJJQSHKå"YSH$<?;STFIJQíY+>SL!FéXSèJQ+H$FILTUã?L !»F=X+è/;=FIâxH?ôW<?XAY<?@ !?H$YJ9ã@9ãª;Iî?HFIJKêª\QSHKå½Fé^<WèªF=XSHJQ+<WJ(JQSHKåí<WLH@9ãª;IîPF=XSèGJQSHõ+Lã?àA;IH$^õALH$@9H$XJ9H$YíJ9ã/JQSH$^]ê Ý @(JQSHKå½Y+ã0@9ãSôªJQSHKå<WLHGLH»>+FIL!H$YJ9ãíYSH$@OpL!F=àHH$<?O!Q[@9J9HKõ]<?X+YäJQSHGLH$<?@9ãªXA@Uâxã?LYSãªF=XSèTQ+<WJJQSHKå`YSãSêP\8QSHNJ9L!<?X+@!OpL!FIõ+Jã?âUJQSH$FILNî?HKLàA<?; <?OKOpãª>+XJGFé@JQ+Hõ+L!ã?J9ã»Opãª;eê áCX JQAF=@OK<?@H?ôJQSHKå[Tã?L"! <?X+Y HPõA;=<?F=X JQSH$FILGOK>SLLH$XJTã?L"!êP\QSH$@9HGõ+Lã?J9ãPOpãª;=@OK<?Xìà HJQ+HàA<?@F=@Uâuã?L8OK<WõAJ>SL!F=XSè"<"@OpH$X+<WL!F=ãSêP\Q+F=@F=X¹J9HKL!î»FIHKTßJ9H$ORQ+X+F »>SH@Q+ãª>+;=Yìà HOpãª^0àAFéXSH$Y]TFIJQìã?JQ+HKLF=XJ9HKLîPFIHKT·J9H$O!Q+XAF >+H$@Kê

\8Q+HKLH0<WLH/ã?JQ+HKLNF=XJ9HKLîPFIHKT·J9H$O!QAX+F »>SH$@8JQ+<WJN^FIèªQJ8à H/>+@9HKâ>+; âxã?L;=FIâxH/OK<?@9HH$;=F=OKFIJ<WJFIãªX @>+O!Q <?@JQSHN;=<?Y+YSHKLRF=XSèã?Lè?L!F=YJ9H$ORQ+X+F »>SH$@KêáhX`JQSH$@9HGOK<?@9H$@KôP<0Q+F=HKL!<WL!O!QAF=OK<?;A@9J9LR>+OpJ>SLH8ã?âJQ+HN<Wõ+õÇ;=F=OK<WJFIãªXYSãª^`<?F=X0F=@âuã?LR^íH$Y0à»å/<?@ !PF=XSè>SH$@JFIãªX+@Y+H$@FIèªXSH$Y0J9ãN^íãî?H>Sõ,ôzYSãTXôm<?X+Y<?OpL!ãª@@JQ+HQ+F=HKL!<WL!O!Qå?ê

a C% kX>p/ 24# C'! pjCqnoC%&[ 2[ X& X>Z KZPC 2>noChnÝ ;IJQSãª>SèªQ F=JGFé@/@> `OKF=H$X¹Jâxã?L0;=FIâxHíOK<?@9H$@/J9ã àH@J<WJ9H$Y F=XðX+<WJ>+L!<?;;=<?XSèª>A<Wè?H?ô,TUHä^<$åð>+@9H<]@H$^F|Bâxã?L!^<?;LHKõALH$@9H$XJ<WJFIãªX[F=X+@J9H$<?Y[>+@F=X+è½JQ+Hâuãª;=;=ãzTF=X+è½J9H$^õA;=<WJ9H?ÿ

= ('# ÿ );=FIâxH/OK<?@9H0X+<?^íH,+ >0'/9'(6"/0#'" "! ÿ )xãª>SJOpãª^íHY+H$@OpL!FIõ+JF=ãªX0+

;'9#D# ÿ );=F=@9Jã?â >+@9HKL8J<?@"!»@:+-@/! 5 ,2# ÿ );=F=@9Jã?âkõ+Lã?àA;=H$^@:+F'(<@/!.=C ÿ )xè?H$XSHKL!<?;ORQ+<WL!<?OpJ9HKL!Fé@<WJFIãªX0+465 7 ( 89# ÿ );=F=@9Jã?âkã?à<;9H$OpJFIî?H$@:+

= ('# ! ÿ )xè?H$XSHKL!<?;,è?LR<WõAQ+F=OK<?;YSH$@!OpL!FIõ+JFIãªXD+E0 9#6! 9# ÿ )xè?L!<WõAQ[ã?â ^F=;=H$@9J9ãªXSH$@:+ ! ("! #&."2DC ÿ )OpãªX+@>+^íH$Y OpãªX¹J9H$XJNF=J9H$^@:+ ! %/!@C".D("C ÿ )xõ+LãPY+>+OpH$Y]OpãªXJ9H$X¹JGFIJ9H$^@:+;"> 620 # ÿ )OK;=<?@@8ã?â F=XJ9H$X¹J@3+

<./9# ÿ )<?OpJ9ã?L!@;éF=@9J:+B"% (@C %/!9 ÿ )xè?H$XSHKL!<?;,õALã?öA;IHYSH$@OpLRFIõ+JFIãªX0+ ! ' 5 !/9'0! ÿ )xè?H$XSHKL!<?;Opãª;é;=<Wà ã?L!<WJFIãªX]YSH$@OpLRFIõ+JFIãªX0+

! ÿ )xè?H$XSHKL!<?;OpãªXJ9HPJYSH$@OpLRFIõ+JFIãªX0+; 2D ÿ )xJ9H$^íõ ã?L!<?;=FIJrå;=Fé^FIJ<WJFIãªX+@3+- '( ÿ )<?@@FIèªX+^H$X¹J8ã?âkõA;=<?OpH$@3+@<'( ÿ )X+<?^íH$@8ã?âYSãPOK>+^íH$XJ@:+D ÿ )xè?H$XSHKL!<?; Þ áMìOpãªX¹J9HPJ:+

%/ #9'" "! ÿ )xè?H$XSHKL!<?;,à H$Q+<zî»F=ã?L3+1 %=%/!'(,> 9# ÿ )xè?H$XSHKL!<?;Y+H$@OpL!FIõ+JF=ãªXäã?â<Wõ+õALãª<?O!QSH$@3+

\8QAF=@³J9H$^íõA;=<WJ9HOK<Wõ+J>SLH$@JQ+Hâuãª;=;=ãzTF=X+è"Opãª^õãªX+H$X¹J@ã?âk;=F=âuHOK<?@9H$@Kÿ


MT8MWG ghTUHLNMGIHPOQ %FIâxHNOK<?@9H$@<WLH/O!Q+<WLR<?OpJ9HKL!F=@9H$YìãªXìJQSHGàA<?@!F=@ã?â@9J9L!<WJ9HKèªFéOF=@@>SH$@$ôJQSHõALã?àA;IH$^@9J<WJ9H$^H$X¹JKôàA<?O !è?L!ãª>+X+Y <?X+Y ã?à<;CH$OpJF=î?H$@Gâuã?LGJQSH";=FIâxH0OK<?@9H?ô JQSHí^íHKJQSãPYSãª;Iã?è?å JQ+<WJNFé@>+@H$Y âxã?L@9ãª;=î»F=X+è/JQSHG;=FIâxHOK<?@9H?ôS<?X+YäàåYSH$@!OpL!FIàAF=X+èJQSHàÇ<?@F=O^ã»Y+>A;IH$@JQ+<WJ³<WLHG>+@9H$Y`âuã?L³@9ãª;IîPF=XSèJQSH;=F=âuHOK<?@9H?ê\8QSH/ORQ+<WL!<?OpJ9HKL!F=@!<WJFIãªX F=@QA<WL!^íãªX+F:9KH$YìTFIJQ]F=XJ9H$X¹JFIãªXA@KôSJ<?@ !P@<?X+Y]è?ãª<?;é@Kê

H VWgjMLNg O \8Q+H ;=FIâxH[OK<?@9H AãzT Opãª^0àAFéXSH$@JQSH ã?àA@9HKLîW<WJFIãªX+@`TUH^<?YSH?ô(JQ+H õ+LãPOpH$@@9H$@äF=XPBî?ãª;Iî?H$Y,ôÇ<?X+Y]JQ+H0Y+<WJ<TQ+F=O!Q]<WL!HOpãªX+@>A^íH$Y]ã?LõALã»YA>+OpH$Yê+\8QSH/;éFIâuHOK<?@9H +ãzT F=@8^<WõAõH$Y[J9ãä<@OpH$XA<WL!FIãSê

H E0TjgWL Þ H½Y+HKî?H$;Iã?õ õALã?öA;IH$@KôSH$@õH$OKFé<?;=;IåìJQSãª@9Hã?âF=X+Y+FIîPF=Y+>A<?;=@Kô<?@NõA<WL!J8ã?âJQSH Þ áM[>SJFé;=F:9$<WJFIãªXõ ã?LJ9âxãª;=FIãSôS<?X+Y[FéX¹J9HKLõ HKL!@ãªX+<?;OpãªQSHKLH$X+OpH@9õ H$OKFIöAOK<WJFIãªX+@$ê

OQcG g6G \8F=^H[<?X+Y ;IãPOK<WJFIãªX F=@"HPõA;=FéOKFIJ;Iå YSH$@!OpL!FIà H$Y âuã?L;=FIâxHìOK<?@H$@Kê(\8QSH[<WõAõA;=F=OK<WàAFé;=FIJEå ã?âN;=F=âuHOK<?@9H$@íFé@L!H$@9J9L!F=OpJ9H$Y à»å LHKèª>+;=<WJF=ãªX+@Kô;é<$T@Kô <?X+Y ã?L!YSHKLR@Kêk\QSH$@9HLH$@9J9L!F=OpJF=ãªX+@<WL!Hì@H$;=YSãª^#èªFIî?H$XF=X <?X H»õÇ;=F=OKFIJ½âuã?LR^]êáhX <?Y+Y+FIJFIãªX,ôkJQ+H OpãªX¹J9HPJ`ã?âG;=FIâxH]OK<?@9H$@F=@"èªFIî?H$X à»åJQSH]õ+Lãî»F=Y+HKL$ôJQSHF=XJ9H$X+YSH$Y`<?>+Y+FIH$X+OpH?ôJQSH>SJFé;=F:9$<WJFIãªXQAF=@9J9ã?Lå?ô¹<?XAYJQSHN<$îW<?F=;=<WàAF=;éFIJEåã?â,Y+<WJ<0Y+>+H8J9ã0JQSHJ9H$O!Q+XAF=OK<?;H$Xî»F=LãªX+^íH$XJKê Þ H<?;=@ã>+@9HJQ+F=@F=XSâxã?L!^<WJFIãªXâxã?L8JQSH0OpãªXJ9H»JN@9õ H$OKFIöAOK<WJFIãªX,ê

ghE0HTjg ghQcGIL %FIâxH0OK<?@9H$@N<WLH0LH$@J9L!F=OpJ9H$Y àå]Q+<WàAF=J@Kô+è?H$XSHKL!<?;k<Wõ+õ+L!ãª<?O!QSH$@KôÇè?ããPY[õAL!<?OpJF=OpH$@Kô <?X+Yà ãª>+X+YA<WLåOpãªXAY+FIJFIãªX+@âuã?LNJQSH$FILG<Wõ+õA;éF=OK<WJFIãªXêA\QSHKå]õ+LH$@>+õ+õ ãª@9HH»õ HKL!F=H$X+OpH$@<?XAY @ !PF=;=;=@8ã?âJQSH>+@HKL!@8F=Xî?ãª;Iî?H$Yê

ã?J9H JQ+<WJä;=FIâxHìOK<?@H TH F=XJ9H$X¹JJ9ã @>Sõ+õ ã?LJ"à»å< Þ áMOK<?X à H[Opãª^íõÇ;IHKJ9H$;IåY+F HKLH$X¹JFéXLH$<?;;=FIâxH?ê MPãª^íHKJF=^íH$@TUH"XSHKH$Y <Opãª^íõA;IHKJ9H½LHKã?Lèª<?X+Fé@<WJFIãªXã?âJQSH½àA>+@FéXSH$@@8<?OpJFIîPFIJFIH$@$êÇáCX JQAF=@OK<?@HTH@QSãª>A;=YX+ã?J ^`<WõíJQSH³LH$<?;S;=FIâxHUOK<?@9HJ9ãG<@!>+FIJ9Hã?âÇ<?@@9ãPOKF=<WJ9H$Y@!OpH$X+<WL!FIãª@KôWàA>+JL!<WJQ+HKLH$X¹îPF=@FIãªX½<Gà HKJ9J9HKLã?Lèª<?X+Fé@<WJFIãªXìã?âkJQSHJ<?@ !P@8<?X+Yìè?ãª<?;=@8<?XAYìJQSH$X[^<Wõ]JQSH$@HJ9ã`<íXSHKT·H$Xî»F=@!FIãªXSH$YìQ¹å»õ ã?JQSHKJF=OK<?;;=F=âuHOK<?@9H?ê ý Sã?L[F=;é;=>+@9J9L!<WJF=ãªX ;IHKJì>+@ìOpãªX+@F=YSHKLì< JEå»õAF=OK<?;G;=FIâxH OK<?@9HðJQA<WJìFé@äOK>SL!LH$X¹J;=å àA<?@9H$Y¿ãªX^<?F=;éF=XSè <?XAY¿Y+H$;=FIî?HKLå @HKLî»FéOpH$@KêMS>+O!Q·<;=FIâxH OK<?@H OK<?XßàH ã?âxJ9H$Xßã?àA@9HKLî?H$Y,ôTQSH$Xß< X»>+^à HKLã?âF=X+@JFIJ>SJFIãªX+@³F=@F=X¹î?ãª;=î?H$Y F=XìJQSH<?OpJ>+<?;;=F=âuH/OK<?@9H½<?X+Y]JQSH$@H0F=X+@9JF=J>SJFIãªX+@Opãª;=;é<Wàã?LR<WJ9H/;Iããª@H$;Iå>A@F=XSè< X»>+^à HKL0ã?âYSHKâ<?>+;IJ0<?X+Y HPOpHKõAJFIãªX+<?;OK<?@9H$@KêëNâuJ9H$X,ôJQSH`;é<WJ9J9HKL½ãªX+H$@0<WLHìXSã?J0HPõA;=FéOKFIJ;Iå @J<WJ9H$YôàA>SJà H$;IãªX+è½J9ã`JQSH0@9HKLîPF=OpH/OpãªXJ9H»JKê

Sã?LFéX+@9J<?X+OpH?ôm<âxHKH<WõAõA;=FIH$@J9ã !PF=X+YSHKL!èª<WLJ9H$X0ã?LY+<zå0X»>SL!@9HKL!F=H$@Kêz\8Q+Fé@,âxHKHYSHKõ H$X+YA@,ãªXJQSHFéX+Opãª^íHã?â,JQSHõA<WLH$XJzæ@Rçã?L³;=HKèª<?;Aèª>+<WLRY+F=<?X+@Kô¹JQSH$FILU@ã»OKF=<?;@9J<WJ>+@$ôJQSHLHKèª>+;=<WJF=ãªX+@(ã?âJQ+HNY+<zå`X»>SL!@9HKLå?ô»<?X+YJQSH½@>Sõ+õ ã?LJã?âJQSHè?ãzî?HKL!XA^íH$X¹JKê Ý Y+Y+FIJF=ãªX+<?;=;Iå?ôSHSOpH$^íõ+JFIãªX ã?ââxHKH$@^<zå[à H0<Wõ+õA;éFIH$Y]âxã?L$ê M»ãSôÇJQSHã?àA@9HKL!î?H$Y[;=FIâxHOK<?@9HOpãªX+@!F=@9J@8F=XìJQ+Hâuãª;=;=ãzTF=X+è"@J9HKõA@Kÿ

<WLH$XJ@ã?LN;IHKèª<?;,èª>A<WL!Y+F=<?X+@<WLH0öA;é;=F=XSè"F=X[<?X <Wõ+õA;=F=OK<WJF=ãªXìõ+LãzîPF=YSH$Y[àåìJQSH½Y+<$å]X»>SL!@9HKLå?êÇ\8Q+F=@<Wõ+õÇ;=F=OK<WJFIãªX]F=@^`<?F=;IH$YìJ9ãJQSH0å?ãª>SJQ]TH$;Iâx<WL!H0YSHKõA<WLJ^H$X¹JKê

\8Q+Híå?ãª>SJQðTH$;Iâx<WL!HYSHKõA<WLJ^íH$XJ/O!Q+H$O"!P@/JQSH<Wõ+õÇ;=F=OK<WJFIãªXê\8Q+HKå >+@9HYA<WJ<ìõ+LãzîPF=YSH$Y à»åã?JQSHKLOKFIJråã `OKF=<?;é@Kê¹\8QSHLH$@>+;=J(OK<?X`à H8JQ+HLHKâ>+@<?;+ã?L<?OKOpHKõ+J<?XAOpHã?âJQSH<Wõ+õÇ;=F=OK<WJFIãªXô¹ã?LUJQSHLH»>SH$@9JJ9ãHPJ9H$X+Y JQSH/<Wõ+õA;=FéOK<WJFIãªXìàåâ>SLJQSHKL8Y+<WJ<Pê

áCXJQSH½;é<?@9JOK<?@9Hí<X+HKT<WõAõA;=F=OK<WJFIãªX âuã?LR^5Fé@N@H$X+Y àÇ<?O"!J9ãJQ+H½<Wõ+õÇ;=F=OK<?XJzæ@RçJQA<WJNTF=;=;,à H½JQSHàA<?@!F=@³âuã?LNOK<?;=OK>+;=<WJF=ãªXìã?âkJQ+HâuHKH$@Kê

\8Q+H <Wõ+õA;éF=OK<?X¹J@<WLHõ+Lãî»F=YAF=XSè <?Y+YAFIJFIãªX+<?;8YA<WJ<PôH?êèSêY+<WJ<<Wà ãª>SJäJQSH$FILìF=X+Opãª^íH?ê³\8Q+F=@`XSHKT<Wõ+õÇ;=F=OK<WJFIãªXìâxã?L!^ F=@^`<?F=;IH$YìJ9ãJQSH0å?ãª>SJQ]TH$;Iâx<WL!H0YSHKõA<WLJ^H$X¹JKê

\8Q+HNå?ãª>+JQìTUH$;Iâ<WLHYSHKõA<WL!J^íH$X¹JOK<?;=OK>A;=<WJ9H$@XSãzT·JQ+HNâxHKH$@³JQ+<WJ8<WLH<Wõ+õÇ;=F=OK<WàA;IHNF=XJQSHæ@9õ H$OKF=<?;uçOK<?@9H?ê

\8Q+H/YSH$OKF=@FIãªXìã?âkJQSH/å?ãª>+JQ[TH$;Iâx<WL!H/YSHKõA<WLJ^íH$XJF=@^`<?F=;IH$YìàA<?O !J9ã`JQSH0<Wõ+õA;éF=OK<?X¹J@$ê \8Q+H<Wõ+õÇ;=F=OK<?XJ@k^`<$å<?OKOpHKõAJJQSHYSH$OKF=@FIãªX½^<?YSH³ã?L^<zåöA;=HU<?X"ã?à<;9H$OpJFIãªX"<Wèª<?F=X+@9J JQSHYSH$OKFé@FIãªXê\8Q+Hã?à<;CH$OpJF=ãªX[F=@8^<?Fé;IH$Y]<Wèª<?F=XêSáhJ^<zåìOK<?>A@9H0<?XSã?JQSHKLõA<WLJF=<?;ã?Lâx>+;é;<?@!@9H$@@^íH$XJKê


\8QAF=@;=F=âuHOK<?@9H@QSãª>+;=YXSã?J à HU^<Wõ+õ H$YJ9ãN<G@>+õ+õ ã?LJ9H$Y0;=F=âuHOK<?@9H?ê?ZUH$@!F=YSH³>+XSLH$;=Fé<WàAF=;=FIJråã?âA^`<?F=;=F=XSè@9HKLîPF=OpH$@<Gè?ã»ã»Y`X>+^à HKL ã?âÇHSOpHKõ+JFIãªX+@OK<?XàH³ã?àA@HKLî?H$Yê Þ H^<zå½>A@9H<?XSã?JQSHKL(<Wõ+õALãª<?O!QíJQA<WJQ+<?@à HKH$X]F=^íõA;=H$^íH$X¹J9H$YTF=JQ+F=XäJQSH ã?J9J9àA>+@>AX+FIî?HKL!@F=JEå`@9HKL!î»F=OpH/@å»@9J9H$^[ê HKLHJQ+H/<Wõ+õA;=F=OK<?XJ³à H$Opãª^íH$@JQSHìãzTXSHKL"ã?âJQSH]<Wõ+õA;éF=OK<WJFIãªX <?XAY <?@í@!>+O!Q<?;=;³XSHKT Y+<WJ< <?@@9ãPOKF=<WJ9H$YTF=JQ JQSH]<Wõ+õÇ;=F=OK<WJFIãªX <WLH^<?YSHîPF=@F=àA;IHNJ9ãJQSH/<Wõ+õA;éF=OK<?X¹JKê Þ QSH$XSHKî?HKLNXSHKT H$@@9H$XJF=<?;Y+<WJ<`<WLH0<?Y+YSH$YìJ9ã`JQSH/<Wõ+õA;=FéOK<WJFIãªXìJQSH<Wõ+õA;éF=OK<?X¹JGF=@GXSã?JFIöAH$Y<Wà ãª>SJFIJKê áhâU<LH$<?OpJFIãªX F=@GXSH$OpH$@@<WLå JQSH$X JQSHíXSã?JFIöÇOK<WJFIãªXðF=@NH»J9H$XAYSH$Y àå<ðYSH$<?Y+;éF=XSH`J9LR<?O"!PF=XSèð;=FIâxHOK<?@H?ê(\8QSHì<Wõ+õA;=FéOK<?X¹J"ã?õ H$X+@"< X>+^à HKL"ã?âîPFIHKT@½J9ãðã?JQSHKL<?OpJ9ã?L!@TFIJQL!FIèªQJ@J9ã@9HKH?ôJ9ãì>SõY+<WJ9H0ã?LNJ9ãäHPJ9H$X+YY+<WJ<Pê ãªX+OK>SL!LH$X¹J;=å?ô+JQSH½å?ãª>SJQ TH$;Iâ<WLH"YSHKõA<WLJ^íH$XJ>A@9H$@<?XSã?JQSHKLYSã»OK>A^íH$X¹JJ9LR<?O"!PF=XSè[@9åP@9J9H$^]ê\Q+F=@G@9åP@9J9H$^-F=@GàA<?@H$Y ãªX <]àA;=<?O !à ãª<WL!Yð<WõAõ+Lãª<?O!Q,ô,FeêH?ê,<?;=;YSãPOK>+^íH$XJ@GTQ+F=ORQ <WL!HOK>SLLH$XJ;Iå >+XAYSHKLNOpãªXA@F=YSHKL!<WJF=ãªX<WL!H½õÇ;=<?OpH$Y ãªX¹J9ã]JQ+H½àÇ;=<?O"!»à ãª<WL!Y <?X+Yð<WLHL!<?X&!?H$Yàå"JQSH$FIL(õ+L!FIã?L!F=JEå<?XAYYSH$<?Y+;=FéXSH$@Kê?\8QSH8YSãPOK>+^íH$XJJ9L!<?O !»F=X+è0@9åP@9J9H$^6F=@(@>Sõ+õ ã?LJ9H$Y½à»å"</TUã?L"!@>SõAõã?L!J@9åP@9J9H$^]ê \8Q+F=@@9å»@J9H$^ OpãªXJ<?F=X+@G<?;=;kXSH$OpH$@@<WL!å[LHKèª>+;=<WJF=ãªX+@KôÇ<X»>+^0à HKLã?â(@<?^íõA;=H$@KôÇ<?X+Y<Y+<WJ<<?O>AF=@FIJFIãªX @9å»@J9H$^JQ+<WJ½HPJ9L!<?OpJ@Kô J9L!<?X+@9âxã?L!^@$ô<?X+Y ;Iãª<?Y+@0YA<WJ< âxLãª^#ã?JQSHKL½Opãª;é;=<Wà ã?L!<WJF=XSè@9åP@9J9H$^@KêÇ\8QSHGTUã?L !ì@!>Sõ+õ ã?LJ@9åP@9J9H$^ õ+Lãî»FéYSH$@<?;=@9ã`@!>Sõ+õ ã?LJâuã?LNQ+<?X+Y+;=FéXSè0HSOpHKõ+JFIãªX+<?;OK<?@9H$@Kê

\8Q»>+@KôKJQ+H(XSHKT ;=F=âuHOK<?@9HOpãªX+@F=@J@ã?âS<?X/<Wõ+õA;=FéOK<WJFIãªX/YSH$;=F=î?HKLå<?X+Y/J9L!<?O"!PF=XSè;éFIâuHOK<?@H?ô<8YSãPOK>+^íH$XJQ+<?X+YA;=F=XSè³<?X+Y0<?@!@9H$@@^íH$XJ;éFIâuHOK<?@9H?ôW<?X+Y/<õA;=<?X+XAF=XSèSôp@O!QSH$YA>+;=F=XSè<?X+Y0TUã?L !G@!>Sõ+õ ã?LJ;=FIâxHOK<?@9H?ê\QSH$@9H;=FIâxH/OK<?@9H$@N<WLH^`<Wõ+õ H$Y]J9ãä@OpH$XA<WL!FIãª@Kô+TQ+F=O!Q <WLH/â>SLJQSHKL!ãªX[Opãª^0àÇF=XSH$Y FéX¹J9ã`<ä@F=XSèª;=H/@OpH$X+<WL!FIãSêÇ\8QSHJQSLHKHG@9õ H$OKFIöAO;=FIâxHOK<?@9H$@à H$Opãª^íHGî»F=HKT@ãªXJQSHGOpãª^0àÇF=XSH$YäãªXSH?êA>SLJQSHKL!^ã?LH?ôTHNã?àA@9HKLî?HNJQ+<WJ³JQSHXSHKT ;=FIâxH"OK<?@9HF=@Nâx<WL^íã?L!H½è?H$X+HKL!<?; JQ+<?X JQSH"õ+LHKîPFIãª>+@ãªXSHí<?X+Y Opãª>+;=Yà H½JQSH"àA<?@F=@Nâxã?L/<äè?H$X+HKL!F=O<Wõ+õA;éF=OK<WJFIãªXìõ+LãPOpH$@@FéXSè Þ áMê

, +× ØÙ 4 ,

?N@9HKL^íã»Y+H$;=;=F=XSè8QA<?@kORQ+<?XSè?H$Y½JQSH³YSHKî?H$;Iã?õA^H$X¹JkJ9ãQ>+^`<?XPBEOpãª^íõA>SJ9HKL F=XJ9HKLâ<?OpH$@Kô?<?X+Y<?;é;IãzT@J9ãGJ<?F|B;Iã?L(@å»@9J9H$^`@J9ã/JQSH>+@9HKL!@Kô?JQ+H$FIL(XSHKH$Y+@$ô¹<WàAF=;=F=JFIH$@KôW<?X+Yíõ+LHKâxHKLH$X+OpH$@$êW?@HKLU^íãPYSH$;=;=FéXSèNFé@àA<?@9H$YíãªX`JQSH@9õ H$OKFIöAOK<WJF=ãªXìã?âJQSH »÷pú ú9ù JQ+<WJ<?Y+YSL!H$@@9H$@³JQSH/ORQ+<WL!<?OpJ9HKL!F:9$<WJF=ãªX ã?âkJQSH/>+@9HKLzôP<?XAY]JQSH/@9õ H$O~BFIöAOK<WJF=ãªX ã?âUJQSH »÷pú ùWúpø 7pù ùíJQ+<WJGYSH$@OpL!F=àH$@JQSH">+@9HKLo@NJ<?@ !P@KôF=Xî?ãª;Iî?H$^íH$XJKô<?X+Y Opãª;é;=<Wà ã?L!<WJFIãªXãªX]JQSH0àA<?@F=@³ã?â JQSH/^Fé@@FIãªXã?â JQSH Þ á9M ê

noChp 0 p]X +# ChnáCX è?H$XSHKL!<?;eô>A@9HKLõ+Lã?öA;=H$@N<WL!H`@9õ H$OKFIö+H$YJQSLãª>+èªQ JQSH þ Rý?ø ù úCù 0àA<?@H$YðãªXð<?X F=X+@!FIèªQ¹JF=XJ9ãJQSH !PXSãzT;IH$YSè?H?ô(@ !PF=;=;é@Kô<?X+Y <WàAF=;=FIJF=H$@ã?âNõ ã?J9H$X¹JFé<?;8>+@9HKL!@$ôkJQ+H %(ùWú úCù `TFIJQ <ð@õH$OKF=öAOK<WJFIãªXã?âJQSH½@9õ H$OKFIöAO0TUã?L"![<WõAõ+Lãª<?O!Q+H$@ã?âU>+@9HKL!@Kô<?X+Y JQSH Kú!÷Kù Çý øû ú9ù NLHKõ+L!H$@9H$X¹JFéXSèJQSH"@9õ H$OKFIöAOõ+Lã?õ HKLJF=H$@³ã?âk>+@HKL!@Kê

( l 2[ KX & 0 p]X +# Chn \8QSH þ !ýªø ù ú9ù Fé@ORQ+<WL!<?OpJ9HKL!F:9KH$Y à»å[õ+L!ã?õHKL!JFIH$@8ã?à+J<?FéXSH$Y YA>SL!F=XSèH$Y+>+OK<WJF=ãªXôJ9LR<?F=X+F=XSèSô»<?X+Yã?JQSHKL³H$Y+>+OK<WJFIãªXA<?;<?OpJF=î»FIJF=H$@Kô»FsêH?êH$Y+>AOK<WJFIãªXôSOK<WõA<WàAF=;éFIJFIH$@Kô¹<?XAY<WõAõA;=F=OK<mBJFIãªX !PXSãT;IH$YSè?H?ê

\8Q+H þ Rý?ø ù F=@(ORQ+<WL!<?OpJ9HKL!Fé@9H$YàåíJQSHJ9H$O!Q+XAF=OK<?;Ç<?XAY`õ+L!ã?âuH$@@!FIãªX+<?;+J9LR<?F=X+F=XSè/<½>+@9HKLUè?ã?JKêS\H$ORQPBX+F=OK<?;J9L!<?F=X+F=X+èH$^õAQ+<?@F=@H$@GJQSH`>+X+Y+HKL!@9J<?X+Y+FéXSè]<?X+Yðõ+L!<?OpJFéOK<?;<Wõ+õA;=FéOK<WJFIãªX ã?â³àA<?@F=O"õ+LRF=X+OKFIõA;=H$@ã?â@OKFIH$XAOpHG<?XAY^`<WJQSH$^<WJF=OK@Kê (Lã?âuH$@!@FIãªX+<?;ÇJ9L!<?F=X+FéXSè0õA;é<?OpH$@^`<j;Cã?LH$^íõÇQ+<?@F=@>Sõ ãªXJQSHGJQSHKã?LRFIH$@KôS>+XPBYSHKL!@J<?X+Y+F=XSèSôÇ<?X+Y[õ+LRF=X+OKFIõA;=H$@F=X @>AO!Q ö+H$;=Y+@8<?@G@OKF=H$X+OpH?ôÇ<?X+Y H$XSèªF=X+HKHKL!F=XSèSê+áhJL!H$@>+;IJ@F=X[HKL!>AY+FIJFIãªXô!PXSãzT;=H$YSè?H?ôA<?X+Y];=F=J9HKL!<?Opå?ê ý ý¹ü ø ~÷/ã?âJQSH>+@9HKL0âxã?L0J<?@"! @9ãª;=>SJF=ãªX+@/<WLHäàA<?@9H$Y ãªX JQSH`<WJ9J<?FéX+^íH$XJã?âõ+L!ã?öAOKFIH$X+Opå F=X

@ !PF=;=;=@"@>AO!Q <?@>AX+YSHKL!@9J<?XAY+F=XSèJQSH[õ+L!ã?àA;IH$^ <WLH$<Pô(L!H$<?@9ãªX+F=XSèðOK<WõA<WàÇF=;=FIJFIH$@"ãªX <?X+<?;Iã?è?å?ôLH$<?;éF:9$F=XSè


îW<WL!F=<WJFIãªX+@Nã?âUJQSH"õ+Lã?àA;IH$^5@9ãª;=>+JFIãªXô @9ãª;IîPF=XSèì<?X+Y Q+<?X+Y+;=FéXSèõ+Lã?àÇ;IH$^@Kô Opãª^^½>+X+F=OK<WJFIãªX <WàAFé;=FIJFIH$@Kô<WàAF=;éFIJFIH$@âuã?L/HPõA;=<?FéX+F=XSèäLH$@>+;IJ@G<?X+Yð@ãª;=>SJFIãªX+@$ô <?XAYð<WàAF=;=FIJF=H$@âxã?L/F=XJ9HKè?L!<WJFIãªXðã?âõA<WLJF=<?; õALã?àA;IH$^@9ãª;=>+JFIãªX+@Kê

Rý?ø ù Çù% þ YSHKõ H$X+YA@8ãªX JQSH"<Wõ+õA;=FéOK<WJFIãªX Jråõ H?ô JQSHí<Wõ+õA;éF=OK<WJFIãªXYSãª^<?F=XôÇJQSHí<WõSBõA;=FéOK<WJFIãªX]@9J9L!>+OpJ>+L!F=XSè"à»å@>+à<;CH$OpJ@$ô+JQSH/Y+FIL!H$OpJ8@9J9L!>+OpJ>SL!H?ô+JQSH/YSH$@OpLRFIõ+JFIãªXôPJQSHOpãªX¹J9HPJ<?X+Y[H$X¹îPF|BLãªX+^H$X¹Jã?â JQSH/YSH$@!OpL!FIõ+JFIãªX,ô»JQ+H/õA<WL!<?^íHKJ9HKLR@ã?â JQSH/<Wõ+õA;=FéOK<WJFIãªXôS<?X+Y[<Wõ+õÇ;=F=OK<WJFIãªXìâ>+X+OpJFIãªXA@Kÿ

\8Q+H<Wõ+õÇ;=F=OK<WJFIãªX JEå»õ HìOpãî?HKL!@OpãªXSöAèª>SL!<WJFIãªXô õ+L!ã»Y+>AOpJFIãªXôOpãªX+@J9L!>+OpJFIãªXôYSH$@!FIèªXô F=X¹J9HKL!õ+LHKJ<mBJFIãªX,ô»HKL!Lã?L8<?X+<?;IåP@F=@KôLHKõA<?FIL³à»å`LHKõÇ;=<?OpH$^íH$XJKôSLHKàA>+F=;éY+F=XSèSôª<?X+Y]OpãªXA@9J9L!>+OpJFIãªX,ô»õÇ;=<?X+X+F=X+èSô¹@>Sõ HKL9BîPF=@FIãªX,ôW^ãªX+FIJ9ã?L!F=X+èSô?õ+LH$Y+F=OpJF=ãªXô?OK;=<?@@FIöÇOK<WJFIãªXô?LH$Opã?èªX+F=JFIãªXôªF=X+@J9L!>+OpJFIãªXôWJ9L!<?FéX+F=XSèSô?OpãªX+@>A;IJF=XSèSôOpã»ã?L!Y+F=XA<WJFIãªXôSOpãªX¹J9L!ãª;eô ;>+YSè?H$^íH$XJKôA<?X+Y]HKîW<?;=>+<WJF=ãªXê

\8Q+H/<Wõ+õA;=F=OK<WJF=ãªXY+ãª^<?F=X]OK<?X[à H<?@YAFIî?HKL!@9H<?@@!OKFIH$X+OpH?ôSH$XSèªF=X+HKHKL!F=XSèSôSH?êèSêAOpãªXA@9J9L!>+OpJFIãªX,ô+Opãª^"BõA>+J9HKLH$XSèªF=X+HKHKL!F=XSèSôz^H$O!Q+<?X+FéOK<?;ªH$XSèªF=X+HKHKL!F=XSèSô$J9H$;=H$Opãª^^>AX+F=OK<WJFIãªXôH$XSHKLè?å?ôH$X¹îPFILãªX+^H$X¹J<?;eôm<$îPF|B<WJFIãªX,ô(HKJOWêIô³F=X+@9JFIJ>+JFIãªX+@Kô è?ãzî?HKLRX+^íH$XJKôUàA>A@F=XSH$@@$ôH?êèSêU<?OKOpãª>+XJF=XSèSô³<?Y+^F=XAF=@9J9L!<WJFIãªX,ôköÇX+<?X+OpH?ôõ+L!ã»Y+>AOpJFIãªXô$õ HKL!@9ãªXAXSH$;eôzõALã»OK>+LH$^íH$XJKômY+Fé@9J9L!FIàA>+JFIãªXôKYSHKî?H$;Iã?õA^H$X¹JKô?YSH$@F=èªXô^<WJ9HKLRF=<?;eômLH$@9H$<WL!ORQôõA;é<?X+X+F=XSèSôP^<?X+<Wè?H$^H$X¹JKôÇHKJOWêIôÇ^F=;éFIJ<WLå?ôPã?Lc;9ãª>SL!X+<?;=Fé@^]ê

Ý õ+õA;=FéOK<WJFIãªX @9J9LR>+OpJ>SL!F=X+èíàå[JQ+H@>Sà;CH$OpJLHKâuHKLR@J9ãìJFIJ;IH?ôÇõA>SLõ ãª@9H?ôÇYSãª^<?F=XôAHKîm<?;=>A<WJFIãªXôàA<?@F=O!PXSãzT;IH$YSè?H?ôA<?X+Y[J9HKL!^F=XSãª;=ã?è?å?ê

\8Q+HY+FILH$OpJ0@J9L!>+OpJ>SLHOK<WõAJ>SLH$@ !PF=X+YA@Gã?â³<?@!@9ã»OKFé<WJFIãªX+@Kô,H?êèSêkXSHKJ@KôOK;é>+@9J9HKL!@KôL!H$;=<WJFIãªX+@Kô,YAF=^íH$XPB@F=ãªX+@Kô?Q+FIHKL!<WLRO!Q+FIH$@$ô?HKJOWêIô¹YSHKHKõã?LX+<WLLãT @9J9L!>+OpJ>SLRF=XSèGTFIJQ"ã?LTFIJQSãª>SJ LHKèª>+;é<WL!FIJEå?ô<?X+YíF=XJ9HKL!X+<?;@9J9LR>+OpJ>SL!F=X+è½ã?âkJQSH0<WõAõA;=F=OK<WJFIãªX,ê

Ý õ+õA;=FéOK<WJFIãªX@9J9L!>+OpJ>SLRF=XSèàåYSH$@OpL!F=õ+JFIãªX<?Y+YSLH$@!@9H$@"JQSH]LHKõ+L!H$@9H$X¹J<WJF=ãªX TFIJQYSHKõ+JQ,ôkTF=YSJQô;IHKî?H$;S<?XAY½YAF=^íH$X+@F=ãªXô@9ãª;é>SJFIãªX+@TFIJQ½@F:9KH<?X+YíOpãª^íõÇ;IHPF=JEå?ô !»FéX+Y+@ã?âÇQ+<?X+YA;=F=XSèSô$H?êèSê¹õ+LãPOpH$Y+>SL!<?;eôYSH$OK;é<WL!<WJFIî?H?ô+è?L!<WõÇQ+F=OK<?;eô+Opãª^àAF=XSH$Yìã?LN^F PH$YôS<?X+Y[X+<?^`F=XSèSê

\8Q+HOpãªXJ9H»J³ã?âJQSHGYSH$@OpL!F=õ+JFIãªXYSH$<?;é@TFIJQä<?@@9ãPOKF=<WJFIãªX+@UJ9ã½JQSH>+@HKL$ô<Wõ+õÇ;=F=OK<WJFIãªX+@$ô¹@9õA<?OpHG<?X+YJF=^H?ôÇYSHKõ H$X+YSH$XAOpH0<?X+Y HKîm<?;=>A<WJFIãªX[à»å]JQSH0è?H$X+HKL!<?;OpãªXJ9HPJKôL!H$<?@9ãªX+@KôõA>SLõ ãª@9H$@$ô+<?X+Y õÇ<WLJF=OK>PB;=<WLRFIJFIH$@Kê

\8Q+HH$Xî»F=LãªX+^íH$XJã?âUJQSH"YSH$@OpL!FIõAJFIãªX L!HKâuHKL!@NJ9ãìJQSHíF=^íH$XA@FIãªX[ã?âUJQSH"<Wõ+õA;=F=OK<WJF=ãªX F=X J9HKL!^@Gã?â@9H$<WLRO!Q <?XAY[@9ãª;=>SJF=ãªX]@9õA<?OpH?ê

<WL!<?^íHKJ9HKLR@ã?âkJQSH0<Wõ+õÇ;=F=OK<WJFIãªXìOK<?X[à HJF=^H?ô+@9õA<?OpH0<?X+Y[ã?JQSHKL!@Kê Ý õ+õA;=FéOK<WJFIãªXâx>+XAOpJFIãªX+@³<WLH/<?@8Y+F=î?HKL!@9H<?@8<?OKOK>+^½>+;IH?ôSã?àA@HKLî?H?ôSâuã?LR^]ôS@9J9L!>+OpJ>SL!H?ô];9>+Y+è?H?ô»TH$FIèªQJKô@>A^^<WL!F:9KH?ô<Wè?è?LHKèª<WJ9H?ôª<?Y];>+@9JKô$õ+L!ãzî?H?ômõ+LHKâxHKL$ôzYSHKJ9HKL!^`F=XSH?ô$H$@9JFé^<WJ9H?ôõALH$Y+F=OpJKôzOK<?;éOK>+;=<WJ9H?ôY+HKL!FIî?H?ôJ9L!<?XA@9âuHKLzômOpãªXJ9Lãª;eô?O!Q+H$O"!ô?õA;=<?XôW@9ãª;Iî?H?ôWJ9LH$<WJKô?Opãª^àAF=XSH?ô?<?X+<?;IåP@9H?ôWYSH$OKF=YSH?ômHPH$OK>SJ9H?ôª<?X+Y½âuHKH$Y+àA<?O"!ê

^ X>p # 0 p]X +# Chn \8QSH+%(ùWú ú9ù F=@"^<?F=XA;Iå O!QA<WL!<?OpJ9HKL!F:9KH$Y à»å JQ+HJ<?@"! @9ãª;=î»F=X+è !PXSãzT;IH$YSè?H<?X+Y@ !PF=;=;=@8FéX[JQSH½<Wõ+õA;=F=OK<WJF=ãªX <WLH$<PôFeêH?êÇJ<?@ ![HPõHKL!JF=@9H<?XAY HPõ HKL!FIH$X+OpH?ô@9å»@J9H$^ HPõ HKL!FIH$X+OpH?ô<?X+YF=XSâxã?L!^<WJF=ãªX]<?X+Y]F=XJ9HKL!<?OpJFIãªX[õALã?öA;IH$@Kê

\8Q+H øsým÷ púpø ÷½YSH$@OpL!F=àH$@0JQSH`HS<?OpJí<?X+Y õÇ<WLJF=<?; !PXSãT;IH$YSè?Hã?â8Y+<WJ<Pôkõ+LãPOpH$Y+>SLH$@Kô<?;Iè?ãWBL!FIJQA^@Kôzâ>+X+OpJF=ãªX+@KôOpãªXA@9J9L!<?F=XJ@KôW<?@@9ãPOKF=<WJFIãªX+@KômâxL!<?^íH$@Kômè?L!<WõAQ+@$ôm@ORQSH$Y+>+;=H$@KôzL!>A;IH$@KôOK<?;éOK>+;=FeôHP<?^íõÇ;IH$@Kôã?à<;9H$OpJ@Kô Y+F=<Wè?L!<?^@$ôAHKJOWê <WLJF=<?; !»XSãT;IH$YSè?H½F=@NO!Q+<WL!<?OpJ9HKLRF=@9H$Yàå]îW<Wèª>SH$XSH$@!@HPõ+LH$@!@9H$Y[îPF=<`>AX+OpHKL9BJ<?F=XJEå?ôF=X+Opãª^õA;IHKJ9H$XSH$@@$ôAF=XSHS<?OpJXSH$@@KôF=X+OpãªX+@!F=@9J9H$X+Opå?ô<?X+Y QSH$>+L!F=@9JF=OK@$ô+îm<WLRF=<?X¹J@ã?âLHKõ+L!H$@9H$X¹J<WJF=ãªX+@>+@FéXSè HKî»F=Y+H$X+OpH?ôHKîW<?;=>+<WJFIãªXôõALã?àA<WàAF=;éFIJEå?ôOpãªXSö+LR^<WJFIãªXôOpHKLJ<?FéX¹Jrå?ôUà H$;=FIHKâhôOpãªXSöAYSH$XAOpH?ô@>Sõ+õ ã?LJKôLãª>SèªQ @9HKJ@Kô+HKJOWêIôOK<?;=OK>+;=FeôSOpãª^^H$X¹J@KôÇOpãªX+@9J9L!<?F=XJ@Kô+HKJOWê

\8Q+Høsým÷ Kú F=YSH$XJFIö+H$@à ã?JQ]õ ãª@FIJFIî?HHPõ HKL!FIH$X+OpH?ôSH?êèSê<Wõ+õA;=F=OK<WàÇ;IH !PXSãT;IH$YSè?H?ôA@J9L!<WJ9HpBèªFIH$@Kô^íãPYSH$;=@G<?X+Y JQ+HKã?L!FIH$@Kô<?X+YðXSHKèª<WJF=î?HH»õ HKL!F=H$X+OpH?ô H?êèSê,YSHKî?H$;Iã?õA^íH$XJKô,@>SõAõã?L!Jã?L !PXSãzT;IH$YSè?HYSHKöAOKF=J@KôOpãã?õ HKL!<WJFIãªXð<?XAY õA;=<?X+X+FéXSèä@>+õ+õ ã?LJLH$YA>+OpJFIãªXôOK<WõA<WàAFé;=FIJEå èª<WõA@Kô,;=<?O ! ã?âUHH$OpJFIîPFIJrå?ôF=XPB@> äOKFIH$X¹J]Opãª^íõ HKJ9H$X+OpH$@$ô8HKJOWê8áCX·<?Y+Y+FIJFIãªX,ôUJQSHð>+@HKL!@³H»õ HKL!F=H$X+OpHðF=X·Opã?õAF=XSèTF=JQHKL!Lã?L!@Kô@9H$;IâuBã?Lèª<?X+F!9$<WJFIãªXô+õA;é<?X+X+F=XSèSôP<?X+Y]<WàA@J9L!<?OpJFIãªX OK<?X à HG@õH$OKF=ö+H$Yê


= ÷Rûm÷~ø Kú YSHKõ H$X+Y+@`ãªX JQSH@9åP@9J9H$^@äJ9ã à H HPõA;Iã?L!H$Y <?X+Y¿>+@9H$YêUárJF=@`;éF=^FIJ9H$Yà»åJQ+H>+@9HKL o@<WàAF=;éFIJFIH$@³J9ãìOpã?õHTFIJQ[FéXSâuã?LR^<WJFIãªX[YSH$;éFIî?HKLH$Y]à»å[<`@9åP@9J9H$^ <?X+Y @9åP@9J9H$^"BE@!>Sõ+õ ã?LJ9H$YOpãª;=;=<Wà ã?L!<WJF=ãªXôS<?X+Y]J9ãTã?L"!ìTFIJQ]@9åP@9J9H$^@F=XìõA<WL!<?;=;=H$; J9ãTUã?L !»F=X+èíTFIJQSãª>SJ@9åP@9J9H$^ @>Sõ+õ ã?LJKê

= o7pù?ú ý?ø ù ú9ù Fé@ìàA<?@9H$YßãªX·JQSH FéXSâuã?LR^<WJFIãªXßXSHKH$Y+@]ã?â"< >+@9HKL Y+F=@OK>+@!@9H$Y à H$;IãT/ôFeêH?êJQ+H F=XJ9H$X¹JF=ãªX+@F=X <WõAõ+Lãª<?O!QAF=XSè JQSH @9å»@J9H$^]ô(JQSH <?^íãª>+XJ`ã?âF=XSâxã?L!^<WJFIãªX < >+@9HKLäOK<?XOpã?õ HTFIJQ,ô,<?X+Y JQSHäOpãª^íõA;IHSFIJEå ã?âF=XSâxã?L!^<WJF=ãªXð< >+@9HKLOK<?X Q+<?XAY+;IH?ê\8QSH`FéXSâuã?LR^<WJFIãªX õ+Lã?öÇ;IHOK<?X à H^íãPYSH$;=;IH$Y àå¿Y+<WJ<WàA<?@9Hð@ORQSH$^<WJ<JQ+<WJ]<WLHHPJ9H$X+YSH$Yßà»å <>+@9HKLo@äõ+LHKâxHKLLH$YT<zåã?â0à+LãzT@F=XSèJQSLãª>+èªQ[F=XSâxã?L!^<WJFIãªX,ê

= Aø pú9ý$ø ù ú9ù íã?âG< >+@9HKLF=@íY+HKJ9HKL!^F=XSH$Y à»å Q+Fé@âxLH»>SH$X+Opå?ôF=XJ9H$X+@F=JEå?ô<?X+Y @9Jrå»;IH]ã?â>SJF=;éF:9$<WJFIãªX ã?âJQ+H Þ áMê ?N@9HKL!@í^F=èªQ¹Jíà H]HPõHKLRFIH$X+OpH$Y F=X Tã?L"!»FéXSèðTFIJQ@9HKî?HKL!<?;TUã?L !õA;é<?OpH$@íã?LTFIJQãªX+;Iå0ãªXSH?ôWH?êèSêW<G@FéXSèª;IH(àALãzT@HKL$êm\QSHFéX¹J9HKL!<?OpJF=ãªXõALã?öA;IH@>Sõ+õ ã?LJ@k<+HPF=àA;IH(Opãª^^½>+X+FéOK<WJFIãªXôOpã»ã?õHKLR<WJFIãªXô+<?X+Y[Opã»ã?L!Y+FéX+<WJFIãªXìã?â<íèªFIî?H$X[>A@9HKL$ê

0 Chp]noX& 24# K[ 0 p]X +# Chn \8QSH Kú!÷Kù Çý øû ú9ù ã?â <>+@9HKLO!QA<WL!<?OpJ9HKL!F:9KH$@UQ+F=@mQSHKL KúCý ú9ù púø ~÷RôQ+F=@mQSHKL õ+L!HKâuHKLH$XAOpH$@F=XíYSH$<?;=FéXSèTFIJQ"JQSH Þ áMôª<?X+YQ+Fé@mQSHKL ù ýWú øû ú9ù pô»TQ+FéO!Qí<?Y+YSL!H$@@9H$@õA@9åPO!Q+ãª;Iã?èªF=OK<?;õ+L!ã?õHKL!JFIH$@³ã?âk<`>+@9HKL$ê

NH$X+HKL!<?;õ+Lã?õ HKLJFIH$@(ã?â,JQSHG>+@9HKLã?L<">+@9HKLè?Lãª>Sõì<WLHNJQSH÷~øsý?ø »÷(F=XäJQSHNH$X¹J9HKLõAL!F=@9H?ô»Opãª^^>AX+FIJEåHKJOWêIô 7KùWú ý úCù púpø p÷í@!>+O!Q<?@íX+<?^íH?ô<?Y+Y+LH$@@KôkõA<?@@9Tã?L!YôkHKJOWêIôJQSH Rù Aø ¹ø³âuã?L"õ HKLâxã?L!^F=X+è <J<?@ !ì@>+ORQ]<?@³õãª@!FIJFIãªXôP<?;=;IãPOK<WJ9H$YìJ<?@ !P@8F=XYSHKî?H$;Iã?õA^íH$XJKô+Y+F=@J9L!FIàA>SJF=ãªX`<?X+Yì<Wõ+õA;éF=OK<WJFIãªXô»J<?@ !ì<WLH$<<?X+Y OK>+@9J9ãª^HKLNõALã?õ HKLJFIH$@KôÇJQSH ÷Rû = ù ù Rý ý Çþì÷S÷KùWúRû úCù púpø p÷GOK<Wõ+J>+L!F=XSèäî»F=@!FIãªXôÇQ+H$<WL!F=XSèSô^íã?J9ã?L!FéOOpãªX¹J9L!ãª;eôzF=XSâxã?L!^<WJF=ãªXõ+LãPOpH$@@F=X+èSôp@õHKH$Y/ã?âPFéXSâuã?LR^<WJFIãªX>Sõ+J< !?H?ôm<WJ9JFIJ>+YSHU<?X+Y/<?X SFIHKJEå?ôJQSHüýªúCù þ[ý Çþ Kú!÷Kù Çý øû 7KýzøsùWú!÷8OK<Wõ+J>+L!F=XSèF=XJ9H$XJFIãªX+@Kô+^íã?JF=îm<WJFIãªX,ô+H»õ H$OpJ<WJFIãªXA@KôAH$^íã?JF=ãªX+@KôHKJOWêIô øúCý `ý Çþ !þ !ý?ø ù +ô,ü = ý 7 ù Pú9ý ý?øeø púS÷U@!>+O!Qä<?@U<?OKOpHKõ+J<?XAOpHNã?â,@å»@9J9H$^3õ+Lã?õ HKLJF=H$@<?X+Y^íHKJQSãPY+@KôPú ú þ þªý kàå½QSH$;Iõí<?X+Y½J>SJ9ã?L!FéXSè@9å»@J9H$^@Kô?<?X+Y »÷pú8øû KôªFeêH?êWTQSHKJQSHKLFé@kOK<?@!>+<?;eô>+@9HKLzô&!»XSãT;IH$YSè?H$<WàÇ;IHã?L8HPõHKL!JKê

Sã?LNO!Q+<WLR<?OpJ9HKL!F:9$<WJFIãªX ã?â ÷pú ú 7pú ~÷½TUH^<$å]OpãªX+OpH$XJ9L!<WJ9H0ãªX JQSãª@9H/JQA<WJ<WLH0F=^õã?L!J<?X¹Jâxã?L Þ á9M0YSHKî?H$;Iã?õA^H$X¹Jk@>+O!Q<?@õALHKâuHKL!H$X+OpH$@,âxã?LF=X+õA>SJ,<?X+Y0ãª>SJ9õA>SJY+HKî»F=OpH$@k<?X+YY+F=<?;Iã?èª>SH$@$ê Sã?L F=XSõA>SJ<?X+Y ãª>SJ9õA>SJNYSHKî»FéOpH$@8JQ+F=@OK<Wõ+J>SLH$@JQSH = ý Çþ ù7½øû ~÷@>AO!Q<?@J9HPJKôÇõÇF=OpJ>SLH?ô+è?LR<WõAQ+F=OK@KôÇ<?>+Y+FIã<?X+YìîPF=YSHKãí<?X+YìJQSHGLH»>+FIL!H$Y@!>Sõ+õ ã?LJ(âxã?L8JQSH$@H?ôSJQSH ú 7Kú "ùI7G÷ 7pù?ú ½÷RôSH?êèSêÇO!Q+<WL!<?OpJ9HKLBô8;=F=X+HpBôTF=X+YSãTB"ã?L âxã?L!^"Bsã?L!FIH$XJ<WJFIãªX·TFIJQßõ+LH$@9H$XJ<WJFIãªX·õALHKâuHKL!H$X+OpH$@]âxã?L Opãª;Iãª>SL$ô8@!Q+<Wõ H?ô8@F:9KH?ôâxãªX¹JKô âxã?L!^<WJKô OpãªX¹J9L!<?@JKôHKJOWêIôJQ+Häú ú þ þªý `ý Çþ = þ Pú Sø8ùWú"ù Pø Pø OK<Wõ+J>+L!F=XSèJ>SJ9ã?L!FéXSèSô+HPõA;=<?X+<WJFIãªXA@Kô+<?;IJ9HKL!X+<WJF=î?H$@KôAHKJOWêIô !ù ,ý Çþ ú 7pú ~÷RôH?êèSêAJQ+HOpãª^^<?XAY @9Jrå»;IH?ô<?X+YJQSH Çþ púR÷~øsý Çþ ù70ø = Sø³ý Çþìù Sø Sø³øsým÷÷³YSHKõ H$X+YAF=XSè½ãªX]JQSH/;IHKî?H$;<?X+Y]OK<WõA<WàAF=;éFIJFIH$@Kê

(LHKâuHKL!H$X+OpH$@0âxã?L½JQSHäYSH$@!FIèªX ã?â8Y+Fé<?;Iã?èª>SH$@0OK<WõAJ>SLHþ ý ù ú9ù púpø ~÷@>AO!Q <?@0JQSHF=XSâxã?L!^<mBJFIãªX ;=ãª<?Yô*+HSFIàAF=;=F=JEå?ô Opãª^íõA;IHSFIJEå?ôHPõ+LH$@!@FIî?H]õ ãzTHKL$ô(F=XAFIJF=<WJ9H$Y<?OpJFIãªX+@KôUOpãªX+@F=@9J9H$XAOpå?ôâuHKH$Y+àA<?O"!ôHKJOWêIô(þ ý ù 7pù?ú ½÷`ý Çþ[÷~øû ~÷@>AO!Qð<?@OpãªXî?HKL!@<WJFIãªXô »>SH$@9JF=ãªX m<?X+@9THKLGâuã?L!^[ô FéXSõA>SJm<?OpJGâxã?L!^@<?X+Y îm<WLRFIãª>+@õ+LH$@9H$XJ<WJFIãªX @9JEåP;IH$@Kôþ ý ù í÷~øú zø Pú ?ôH?êèSêOK;Iãª@9H$YY+F=<?;Iã?èª>+H$@KôAã?õ H$XY+F=@OK>+@!@FIãªX+@Kô>+X+YAFILH$OpJ9H$Y »>SHKLåPF=XSèSô»F=XJ9HKLLã?èª<WJFIãªXô»HKJOWêIô,þ ý ù Rù Aøú9ù ãªX<?^ãª>+X¹JKô »>+<?X¹JF=JEå?ôPLH$;IHKîW<?X+OpH?ô»LHKõSBLH$@9H$XJ<WJFIãªXôAHKJOWêIôÇ<?X+Y þ ý ù ½÷ ùWúpøôH?êèSê+àåJ9ã»ãª;=@Kê

0 X# 2 p [ 0 p]X +#KCqn Þ H^<zå YSL!<zT @9õ H$OKF=<?; <WJ9J9H$X¹JFIãªX J9ã]JQ+H ù ý?ú øû ú9ù GJQA<WJGFé@N<õA<WL!JNã?âJQSH"õ HKL!@9ãªX+<?;éFIJEå]õ+L!ã?öA;IH?êÇ\QSH"õãª;é<WL!FIJEå]õALã?öA;IHè?ãzî?HKL!X+@/JQSHíYSHKî?H$;Iã?õA^íH$XJGã?â(;=<zå?ãª>SJ/<?X+YõA<WLJF=<?;é;Iå<?;=@9ãõA;é<$å?ãª>SJKêM»ãSô³TH ^`<$åOK;é<?@@FIâxå >+@9HKL!@ì<?OKOpã?L!YAF=XSèJ9ãJQSHð@OK<?;IHðF=XJQSH âuãª;=;=ãzTF=X+è J<WàA;IH?êMPF Y+F HKLH$XJOK<WJ9HKè?ã?L!FIH$@<?@à»å"JQSH8J<WàA;IHàH$;=ãzT ^<zåíàH8>A@9H$Yíâxã?Lå»Q+HO!Q+<WLR<?OpJ9HKL!F=@<WJFIãªX`ã?â>+@9HKL!@Kêª\QSH$@9HOK<WJ9HKè?ã?L!FIH$@N^<zåîW<WLåì<?X+Y]â>SLJQSHKLL!HKöAXSH$Y]>+@FéXSè"âx<?OpHKJ@Kê

qEc!~8c!tsloCd,!yÇ$tsRqegz?~c!qElojy|!q´½fCNwujyµRqs8c!tsloRj/$gzdtsfCd wmidscRRfjWc!gdelod §m¢mdelojfCdedeol f ¦ og$qslo9c! C~j$npfCjKtslo~jmcR ¦lj$npfhj$tslonpf¢mjmfhRtslo~jmcR ¦ de~¢myµ¢m C~Rj ¦fh¼$teqsfCfqEc!tslo~jmcR ¦ defCjmdeltslonpf Cpctsf9 ¦CK~C~jdelÉzfhqEc!tsf ¦ defCjmde¢mcR qsfColÉc!mof ¦fh¼zCfC¡tsloRjWcR

C~j$npfCjKtslo~jmcR ¦?~mfhlÉc!jCcRdedelo9cR ¦ $fhqsj teqEc~ltslo~jmcR ¦n~c!jm~¢mc!qElodehqsfhtsf ¦ jm~lodg ~ ¦ gK~¢jmcR~fhfhded ¦ $fhqsj C~oRqsofCded ¦pcR¢mzg9cRo ¦lodK¢mlofhtslojmRog fCnpfCjz¦étsfh¡?fhqsf9¦fh¼zCltsljjm~jC~ltetEc! ¦ ljKteqs¢deln~f yIcRloolc!q ¦¢mjmlojzy|RqsfC

de¡mlqsltsfhded ¦lonpfhogts~¢mR ¦ tsfCjWzfhq qs¢mdtslo ¦C~deR¡?~oltEcRjWc!qsde ¦ 8c9 lode jWc!ts¢zqEcR ¦ c!qetslºWClc!~fCRfhteqslo ¦ moK~(g C~tslode ¦defhqslo~¢mdºmqs ¦ fCo9 del¡of ¦C~¡fr¼qs~m¢dt ¦fColo9c!tsf lC¢ot ¦f9cRdgcRjmRof9 ¦ qs~¢mjm RqEcRhfhy|¢ ¦RqEcRhlof

\8Q+H$@9H/õ ãª;=<WL!FIJrå`õ+L!ã?õHKL!JFIH$@8^<zåà HLHKõALH$@9H$XJ9H$Y[à»åì:0FIî»Fé<WJè?L!<WõAQ+@Kê +ã?LNF=XA@9J<?X+OpH?ô FIèª>SLH `F=@Opãª^^íãªXA;Iå !»X+ãzTX âuã?L"O!QA<WL!<?OpJ9HKL!F=@FéXSè õ HKã?õA;IHäâuL!ãª^-JQSHìZ³<$îW<WL!F=< LHKèªFIãªX F=X NHKLR^<?X¹å?ê\8QAF=@/@9H$;IâuBõ HKL!OpHKõ+JFIãªX ^`<$åà H[>+@9H$Yâxã?LJQSH YSHKî?H$;=ã?õA^íH$XJíã?âG@JEåP;IHpBsèª>+F=YSH$@ã?LõA<WJ9J9HKL!X+@âuã?L`;é<$å?ãª>SJäã?âTHKàõA<Wè?H$@Kê

lojKteqs!n~fhqetsf9 fh¼$teqsnpfhqetsf9

¢mjdtEcRf

dtEcRmof

Wc!qsde,lo fCfCjog

olomllojmcRdeKClcRmofc!~!qsfCdedelonpf

.0/21 ²²¹¾ mfdefCyµ¦é¡?fhqshfC¡tslo~j!yPtsmfcnRc!qslc!j

C ! pjCqnoC%&[ 2[ X & X>Z noCqp 0 p]X +# Chn ?@9HKL½õ+Lã?öÇ;IH$@0OK<?X <?;=@9ã àHäYSH$@OpL!FIà H$Y FéX < @H$^F|Bsâxã?L!^<?;T³<$å]<?@8âxãª;=;IãT@Kÿ


P#"/ %/! ÿ )>A@9HKL8õ+Lã?öÇ;IHX+<?^íH,+B=C".D('" "! %/!9 ÿ )xè?H$X+HKL!<?;,YSH$@OpLRFIõ+JFIãªX0+

B=C".P("'" "! ÿ );éF=@9J³ã?âkY+HKè?LHKH$@:+ '%0' 5 "9# ÿ );éF=@9J³ã?âk@"!»F=;é;=@:+

! C=< ÿ )Y+H$@OpL!FIõ+JF=ãªXäã?â !PXSãzT;IH$YSè?H/F=XìJQSH<Wõ+õA;=F=OK<WJF=ãªX0+!/ %/! ÿ )xè?H$X+HKL!<?;,YSH$@OpLRFIõ+JFIãªX0+

;'9# "%9/= # ÿ )Y+H$@OpL!FIõ+JF=ãªXäã?â !PXSãzT;IH$YSè?H,+;'9# "%9/0D(" ÿ )xõ ãª@F=JFIî?H<?X+Y[XSHKèª<WJFIî?HH»õ HKL!F=H$X+OpH,+D#662 "%9/0D(" ÿ )xHPõ HKL!FIH$X+OpHTFIJQ]F=XSâxL!<?@9J9L!>AOpJ>SLHNõA;=<?X+XSH$YD+ !"/2D'"0! %/! ÿ )FéXSâuã?LR^<WJFIãªX]XSHKH$Y0+"/9'(0! %/! ÿ )FéX¹J9HKL!<?OpJF=ãªX]õ+Lã?õ HKLJFIH$@3+

-/0#! ' %/!9 ÿ )xè?H$X+HKL!<?;,YSH$@OpLRFIõ+JFIãªX0+ "/9' %/!% "/= " # ÿ );éF=@9J³ã?âk>A@9HKL8õ+Lã?õ HKLJF=H$@:+-@/=/P( # ÿ );éF=@9J³ã?âkFéXSõA>SJãª>SJ9õÇ>SJmY+F=<?;Iã?èª>+HNõALHKâuHKL!H$X+OpH$@:+-! '/06 %/!9 ÿ );éF=@9J³ã?âkORQ+<WL!<?OpJ9HKL!Fé@9JF=OK@:+

?/ 89' 5 %/!9 9# ÿ )xõALã?öA;IHYSH$@OpLRFIõ+JFIãªXì<?X+Y]H$X+âuã?L!OpH$^H$X¹J:+9(,./06 %/!9 ÿ )<?OKOpH$@!@OpãªXJ9Lãª;,<?X+Y[õ+L!FIîW<?Opå+@' " %/! ÿ )@!<WâuHKJråL!H>+F=LH$^íH$XJ@:+

F'9#@C 4 ÿ ) »÷pú ù$ý ÷M+F'9#@C 4 ÿ ) »÷pú0øû p÷M+

/. U[8X>p 0 p]X +#KCqnÞ Hè?Lãª>Sõí>+@HKL!@à»å0JQ+H$FILF=XSâxã?L!^<WJFIãªXYSH$^<?X+Y"<?X+Y½LH»>SH$@9J9H$Y"OpãªXJ9H$X¹JKôªJQ+H$FIL>SJF=;=F=@!<WJFIãªX/õA<WJ9J9HKLRX+@Kô<?X+YJQSH$FILk@9õ H$OKFIöAO(>+JF=;=F=@<WJF=ãªX/<?X+Y½OpãªX¹J9HPJKê?\8QSHU<WàÇ@9J9L!<?OpJFIãªX½ã?âA<è?Lãª>Sõ½ã?âA>+@9HKL!@kF=@OK<?;=;IH$Y½<?XýzøsùWú~êÝ OpJ9ã?L!@<WLH/ORQ+<WL!<?OpJ9HKL!F!9KH$Y[à»å`õ+Lã?öÇ;IH$@³<?X+Y]õ ã?LJ9âxãª;=FIãª@Kê+MP<?^íH/<?@âxã?L8>+@9HKLR@<?OpJ9ã?Lõ+Lã?öÇ;IH$@³OpãªX+@F=@9Jã?âJQSH !þ !ý?ø ù +ô %(ù?ú<?X+Y Kú!÷Kù Çý øûõ+Lã?öA;IH$@$ê(Lã?öA;IH$@<WLH8>A@9H$Y"âuã?LJQ+H8YSHKL!FIîW<WJFIãªX½ã?âÇõALHKâuHKL!H$X+OpH$@Kê\8QSH$@H½õALHKâuHKL!H$X+OpH$@/<WLH>+@H$Y âuã?L/<?Y+<WõAJ<WJFIãªXðã?â³@OpH$XSH$@J9ã[@9õ H$OKFIöÇO½<?OpJ9ã?LR@Kê Þ H`;Iã»ã!<WJJQ+H<?OpJ9ã?Lõ ã?LJ9âxãª;=FIãª@@9HKõA<WLR<WJ9H$;IåFéXìJQSH0XSHPJ@>SàÇ@9H$OpJFIãªXê

Ý OpJ9ã?L!@^<zå½<?OpJUF=X½JQSHLãª;IH³ã?âÇ<?X Çþ »÷Kúô?<?X[ý Aøsý ¹ù ÷~øôã?L<?XF=X+<?OpJF=î?H ù ý?ûKú = ýWú9ýø pú»êP\8QSHJQ+LHKHNOK<WJ9HKè?ã?LRFIH$@8<WLHGOpãª^^íãªX+;=åYSH$@OpL!FIà H$Y`àåJQ+H$FIL(õ+L!ã?õHKL!JFIH$@Kô¹JQ+H$FIL<WàÇF=;=FIJFIH$@$ôª@>Sà<;9H$OpJ@ã?â JQSH$FIL8<?OpJFIãªXA@KôA<?X+Y]à»åìO!Q+<?XSè?H$@JQSHKå]<WLH0F=^õãª@!F=XSèSê

\8Q+Hõ+Lã?öA;IHF=@<?;é@9ã/>+@9H$Yíâxã?LJQSH8Y+HKL!FIîW<WJFIãªX"ã?â JQSHG÷Pú øû úCù (ã?â JQSH8<?OpJ9ã?L!@KêárJFé@@9õ H$OKFIö+H$YãªXJQSH]àA<?@!F=@½ã?âJ<?@ !P@íJ9ãðà HìõHKL!âuã?L!^H$Y à»å JQ+H[<?OpJ9ã?L!@KôLãª;IH$@"JQ+HKå õA;é<$å?ô<?X+Y <?OpJFIãªX+@JQ+<WJ<WLHõ HKL!^FIJ9J9H$Yìã?Lâuã?LàÇF=Y+YSH$XêP\8QSH/@H$OK>SL!FIJråäõ+L!ã?öA;IHF=X+OK;=>AYSH$@³<?;=;,<?@9õ H$OpJ@ã?â@9H$OK>SLRFIJEå?ôAFsêH?ê

ýp÷!÷ !ù AøúCù ;éF=^FIJF=X+è0<?OKOpH$@@8ãªXA;IåJ9ã<?>SJQSã?LRF=@9H$YìF=X+Y+F=î»F=YA>+<?;=@ à»åä<Wõ+õA;=å»F=X+è0õ ãª;=F=OKFIH$@Uâxã?L8F=YSH$XPBJFIöÇOK<WJFIãªXô+<?>SJQSã?LRF:9$<WJFIãªXô+<?X+Y <?>SJQSH$XJF=OK<WJFIãªXô

ú 7 ý$û`÷ ùWúpø,à»åõALHKî?H$X¹JFéXSè>+X+<?>SJQ+ã?L!F:9KH$YìõA<WLJF=H$@âuL!ãª^ ã?à+J<?F=X+FéXSèí@9H$X+@FIJF=î?HGFéXSâuã?LR^<WJFIãªXôH?êèSêÇJQSLãª>SèªQ]@>+õ+õ ã?LJ³ã?â <?X+ãªX¹åP^FIJrå<?X+Y OpãªXSöAYSH$XJF=<?;=FIJrå?ê

\8QAF=@³õ+Lã?öA;=HG^`<$åìà HNHPJ9H$X+YSH$Y àåJQSHí÷Ký7Køû úCù KêÝ X <?OpJ9ã?LJ< !?H$@NõA<WL!JF=X @9ãª^íH"@OpH$XSH$@Nã?âJQSH"@9J9ã?Lå»àãª<WLRYêM mQSH½F=@NO!Q+<WL!<?OpJ9HKLRF=@9H$Yàå]JQ+HO!QA<WL9B

<?OpJ9HKL$ô(;=ã»OK<WJFIãªX,ôo<?OpJFIãªX+@KôF=XJ9H$XJFIãªXô<?X+Y OKFIL!OK>A^@9J<?X+OpH$@KôFeêH?êTQ+<WJíQ+<Wõ+õ H$XSH$Y à HKâuã?LH]@mQ+H[OK<?^íHJQSHKLH?ê H^½>+@9J³Y+F=@OpHKL!XJQSHN<?OpJF=ãªX+@UQ+HF=@(J< !»F=X+è½<?@UTUH$;é;A<?@JQSHLRQ¹å»JQ+^@(ã?â,JQSHTã?L"!<?@³</TQSãª;IH?ô<?X+YäQSH^½>+@9JUY+HKJ9HKL!^F=XSHTQ+<WJ(<?Y];>+@9J^H$X¹J@U^>+@J(à H^<?YSHNF=XQ+Fé@mQSHKL(@9J9ã?L!åà ãª<WL!Y`âuã?LUH$<?O!Qã?âJQSHã?JQSHKL0ORQ+<WL!<?OpJ9HKL!@$ê\8QSãª>+èªQ <?OpJ9ã?L!@0<WL!H`<WàA@9J9L!<?OpJF=ãªX+@ã?â³>+@9HKL/è?Lãª>+õA@KôTH^<$åðO!QA<WL!<?OpJ9HKL!F:9KHäJQSH$^à»åäJQSH$@H0<WàA@9J9L!<?OpJõ+Lã?õ HKLJFIH$@Kê

qEc!~8c!tsloCd,!yÇ$tsRqegz?~c!qElojy|!q´½fCNwujyµRqs8c!tsloRj/$gzdtsfCd wmidscRRfjWc!gdelod K

ý %HKJ>+@,OpãªX+@!F=YSHKL<?X0H$Y+>SJ<?F=X+^H$X¹J,@F=J9H?êzZ³<?@9H$Y/ãªX0JQSHõ+Lã?öÇ;IH TUHOK<?X0YSHKL!F=î?H<8X>A^0à HKLã?âõ+L!HKâuHKLH$XAOpH$@ã?âU;IH$<WL!XSHKL!@$êÇ\8QSHàA<?O"!»è?Lãª>+XAY !PXSãT;IH$YSè?H";IH$<?Y+@J9ã]Y+F HKLH$X¹JN@9õ HKH$Y <?XAY LH$OpHKõAJFIãªXã?â³OpãªX¹J9H$XJ0à»å JQ+H;IH$<WL!XSHKL$ê Þ ã?L ! <WàÇF=;=FIJFIH$@G<?X+YðQA<WàAFIJ@F=X&Ç>SH$X+OpH"OK>SLLH$XJTUã?L !Çê %H$<WL!X+F=X+èì@JEåP;IH$@Q+<zî?H0^<?Xå^<?Xåâx<?OpHKJ@YSHKõ H$X+Y+F=XSèãªXìJQSHõ+Lã?öÇ;IHGã?âJQSH/;=H$<WL!XSHKL$êS\8QSH@9ãPOKF=<?; H$Xî»F=LãªX+^íH$XJ³TFIJQOK>+;IJ>+L!<?;U<?XAY õÇ@9å»ORQSãª;Iã?èªF=OK<?;³Y+F HKLH$XAOpH$@KôJQ+Hì@!>Sõ+õ ã?LJ0âxã?L"J9LH$<WJ^íH$XJíã?âQ+Fé@9J9ã?Låðã?âJQ+Hì;=H$<WL!X+F=XSèõ+LãPOpH$@@TFIJQSãª>SJ<?X+XSãå»FéXSèLHKõ HKJFIJFIãªX+@$ôp<?XAYJQSHJQSH(OpãªXJ9H$XJO!QA<?XSè?HU^<?XA<Wè?H$^íH$X¹JTFIJQGã?L,TFIJQSãª>SJLHKâxLH$@Q]<WLH^<Wõ+õ H$YìJ9ãõ+LHKâxHKLH$X+OpH$@8TUH0<WõAõA;Iå`J9ã`JQSH0@9J9ã?Lå»à ãª<WL!Yê

\8Q+Hõ+Lã?öA;IH$@³ã?â <?OpJ9ã?L!@NOK<?X[à H@9õ H$OKFIö+H$Y]>+@!F=XSè"JQSHâxãª;=;IãzTF=XSè"J9H$^íõA;=<WJ9H?ÿ

1 (!/ %/!9 ÿ )<?OpJ9ã?Lõ+L!ã?öA;IHX+<?^íH,+ /!.=%P&9< (/06"/0' ÿ )O!Q+<WL!<?OpJ9HKLRF=@9JF=OK@ã?âkè?L!ãª>SõAF=XSè"ã?â >+@9HKL!@3+ =!/2D'" "! C,2P'69C ÿ )xè?H$XSHKL!<?;Y+H$@OpL!FIõ+JF=ãªX0+

0 #'" "! %0'=/ ÿ )xè?H$XSHKL!<?;Y+H$@OpL!FIõ+JF=ãªX0+6% (=9=( .0 =#"'" "! ÿ )xè?H$XSHKL!<?;Y+H$@OpL!FIõ+JF=ãªX0+1 (!/ (! ÿ )xè?H$XSHKL!<?;Y+H$@OpL!FIõ+JF=ãªX0+

(Lã?öA;IH$@OK<?X <?;=@9ãíà H/>+@9H$Y]âxã?LYSHKLRFIîm<WJF=ãªXìã?â»>+<?;=FIJråäL!H>+F=LH$^íH$XJ@³ã?â >A@9HKL!@Kê

ý Sã?L0<?XHpBEOpãª^^íHKL!OpH Þ áM TUHí^<zå YSHKL!F=î?H½<ìX»>+^0à HKLNã?â»>+<?;=FIJrå]LH»>+FILH$^íH$XJ@GYSHpBõ H$X+Y+F=X+è ãªX¿TQ+F=ORQ!PF=X+Y ã?â0àA>A@F=XSH$@@`JQSH Þ áMF=@@>Sõ+õ ã?LJF=X+èSêSã?L[F=XA@9J<?X+OpH?ô³FIâ/JQSH @9åP@9J9H$^ F=@ã?L!FIH$XJ9H$YJ9ãzT³<WL!Y+@@9H$;é;=F=XSè`<WâxJ9HKL/<?YSî?HKLJFé@9H$^íH$XJG<?XAY õ+L!H$@9H$X¹J<WJF=ãªX JQSH$X <?OpJ9ã?L!@GJQ+<WJ<WLH"<?OpJF=XSè]<?@OK>+@9J9ãª^HKL!@8<WLH0FéX¹J9HKLH$@J9H$Y[F=XìH$<?@9H/ã?â >+@9H?ô+@õHKH$Y,ô+<?OKOpH$@@FIàAFé;=FIJEå?ôPõ+L!HKî»FIHKTF=XSèSôS@>Sõ+õ ã?LJKôPOpãª^^½>+X+FIJrå?ô@<WâxHKJEå?ôS@9H$OK>SLRFIJEå?ôP<?X+Yäèª>+F=Y+<?X+OpH?êárâJQ+H Þ á9M`F=@U@>Sõ+õ ã?LJF=X+è/OpãªXSö+èª>SL!<WJF=ãªXä@<?;=H?ô¹H?êèSêPâuã?LJ9L!<zî?H$;eôSOK<WL!@JQSH$XìOK>+@9J9ãª^HKL!@³<WLHNFéX¹J9HKLH$@J9H$YFéX`OK>+@9J9ãª^`F:9$<WJFIãªXô»âuHKH$Y+àA<?O"!ô +HPF=àAF=;=FIJrå?ôªõ+LHKîPFIHKTFéXSèSôªàA<?O !è?Lãª>AX+YôOpãªXJ9L!<?OpJ@Kô@<WâxHKJEå?ô@9H$OK>SL!FIJrå?ô õ+L!FIîW<?Opå?ô<?X+Yèª>+F=Y+<?X+OpH?êáhâ(JQSH Þ á9M F=@G@>SõAõã?L!JF=XSèäYAFILH$OpJG@<?;IH"ã?LLHpB@9H$;=;éF=XSèSôzH?êèSêª<?>AOpJFIãªX+@Kômö+L!@9JCBEFéXPBsö+L!@9JCBsãª>+Jk@<?;=H?ôã?LLH$^`X+<?X¹J@<?;=HUJQSH$X½JQSH »>+<?;=FIJrå0OpL!FIJ9HKLR<JQA<WJ @!QSãª>+;=Yà H/@>Sõ+õ ã?LJ9H$Yì<WLH0H$<?@9H/ã?â>+@9H?ô+<?OKOpH$@@!FIàAF=;=F=JEå?ôSõ+LHKîPFIHKT/ôPâ>+X mOpãª^^½>+X+F=JEå?ôA<?;IHKL!JKô+<?X+Y]õ+L!F=îm<?Opå?ê

U[8X>p 0 X6p8[jZX# X>nÝ õ ã?LJ9âxãª;=FIã0Fé@UYSHKJ9HKLR^F=XSH$Y`àåJQ+HLH$@õãªXA@FIàAF=;éFIJFIH$@kãªXSHGQ+<?@U<?XAYäF=@UàA<?@9H$YäãªXì<X»>+^à HKL(ã?â,J<WLè?HKJ@$ê\8QSH`ý$øsùWú ùWúpø 7pù ù0TFIJQ+F=Xì<?X[<Wõ+õÇ;=F=OK<WJFIãªX]F=@³JQ»>+@àÇ<?@9H$Y]ãªX

<@HKJã?â J<?@ !P@<<?OpJ9ã?LQ+<?@ã?LNF=XJ9H$X¹J@J9ãäOpãª^íõA;=HKJ9H0<?X+Y]âxã?LTQAF=O!Q[@ãª;=>SJFIãªXìJQSH<?OpJ9ã?LNQ+<?@JQSH<?>SJQ+ã?L!FIJEåì<?X+Y[OpãªXJ9Lãª;eô

<Y+H$@OpL!FIõ+JF=ãªXäã?âF=Xî?ãª;Iî?H$^íH$XJ8TF=JQ+F=XJQSHJ<?@ !]@9ãª;=>+JFIãªXôS<?X+Y <Opãª;é;=<Wà ã?L!<WJFIãªXìJQ+<WJFé@8XSH$OpH$@@<WL!åäâxã?L@9ãª;IîPF=XSè"JQSH0J<?@ !Çê

\k<?@ ![^íãPYSH$;=;=FéXSè^íH$<?X+@J9ã>+XAYSHKL!@9J<?X+Y[TQ+<WJ<ä>+@9HKLT<?XJ@NJ9ãä<?OKOpãª^íõA;éF=@Q[TQ+F=;IHîPF=@FIJFéXSèíJQSHÞ á9Mê Ý JGJQSH@<?^HJF=^H?ôÇJ<?@ ! <?X+<?;IåP@F=@^`<$å ;IH$<?Y J9ãì<`LHKã?L!èª<?X+F=@<WJFIãªX ã?âJQSHTUã?L ![õ+LãPOpH$@@9H$@J9ãà H@!>Sõ+õ ã?LJ9H$Yê\QSH Þ áM @!QSãª>+;=Y @>Sõ+õ ã?LJ½@9J9LH$<?^;=FéX+F=XSè <?XAY <?>Sèª^H$X¹JF=X+èTQ+<WJ½>A@9HKL!@½YSãSê\<?@ !<?X+<?;IåP@F=@;=H$<?Y+@GJ9ã <[YSH$@!OpL!FIõ+JFIãªXã?âJQ+F=XSèª@>A@9HKL!@/YSã[<?XAY JQSãª@9HJQSHKå XSHKH$YðJ9ã !»XSãT/ê,áhJ/YSã»H$@/XSã?J@9õ H$OKFIâxå0QSãT JQSH³J<?@ !½Fé@k<?OKOpãª^õA;=F=@Q+H$Yêm\QSHUJ<?@"!»@@!>Sõ+õ ã?LJ9H$Yàå½< Þ áM½XSHKH$Y"J9ãà HULHKõALH$@9H$XJ<WJFIî?Hâxã?LJQSH<Wõ+õA;=FéOK<WJFIãªXôzF=^õã?L!J<?X¹J,TFIJQ+F=XJQ+HU<Wõ+õA;éF=OK<WJFIãªXôz<?XAYOpãª^íõÇ;IHKJ9H$;Iå/@>SõAõã?L!J9H$Yê$\<?@"!0@>Sõ+õ ã?LJOK<?X[à HGJ<?F=;Iã?L!H$Y[YSHKõ H$X+Y+F=X+èãªX]JQ+H/õ+Lã?öA;=HG<?XAYìJQSH0OpãªXJ9H»Jã?âkJQ+H/<?OpJ9ã?L!@Kê

~ cR¢d¦uklfrtsfhqkzEmfhfcRjWfhqsjWc!qE ¾ WcRofClo

@ 2 n# n Ý øsým÷"F=@G<>A@>+<?;=;Iå[<?@!@FIèªXSH$YõAFIH$OpH"ã?âTUã?L !Çô TQ+FéO!Qã?âuJ9H$XðQA<?@GJ9ã]àH½öAX+Fé@QSH$Y TFIJQ+F=X<OpHKLJ<?F=XJF=^Hà»åä<">+@9HKLã?L8<½@9HKJ³ã?â>+@9HKLR@UTQSãª@9HGY+>SJEåäF=@UF=J@Opãª^õA;IHKJFIãªXê»áhJ³Fé^íõA;=FIH$@TUã?L"!F=^íõ ãª@9H$Yà»å< >+@9HKLäFéX <?>SJQSã?L!F=JEå<?X+Y ã?àA;éFIèª<WJFIãªX ã?LäLH$@9õ ãªX+@FIàÇF=;=FIJråðJ9ã õ HKLâxã?L!^]ê Ý J<?@ ! ^<$å OpãªXA@F=@9Jã?â@>SàAJ<?@ !»@$ô@9ã½TUHG<?@@>A^íHJQ+<WJJ<?@ !P@³OK<?Xäà HNOpãªX+@9J9L!>+OpJ9H$YãªXJQSHàA<?@F=@Uã?âH$;IH$^íH$XJ<WLåJ<?@ !P@KêS\8Q»>+@Kô<íJ<?@ !]F=@ORQ+<WL!<?OpJ9HKL!F!9KH$Y à»åÇÿ0 p]X4$# C' n4[ 2[jC' C'&[Wb \k<?@ !»@G<WLH"<?@@9ãPOKF=<WJ9H$YJ9ãìõ+Lã?àA;=H$^@Kô+âxã?LGTQ+F=ORQ[ã?âxJ9H$X<OK;=<?@@Nã?â@9ãª;é>SJFIãªX

@9J9LR<WJ9HKèªFIH$@íF=@õ+LãzîPF=YSH$Y,ê Ý YAY+FIJFIãªX+<?;é;Iå?ôõ+Lã?àA;=H$^@/ã?âxJ9H$X LH>AFILHäOpãª;é;=<Wà ã?L!<WJFIãªX TFIJQ JQ+H;IãPOK<?;<?X+Y[èª;Iã?àA<?;,@9åP@9J9H$^@<?X+Y]TFIJQìã?JQ+HKL<?OpJ9ã?L!@Kê

@ 2 p>Ch[ n4[ 2[jChnNb Ý âuJ9HKL@>AOKOpH$@@9â>+;=;Iå]Opãª^íõA;=HKJF=XSèì<`J<?@ ! TUHí^<zå[ã?àA@9HKL!î?H"<ìORQ+<?XSè?HíF=X JQSH½@J<WJ9H?ê\k<WLè?HKJ0@9J<WJ9H$@<WLH@9õ H$OKFIö+H$Yà»å ^íH$<?XA@ã?âUJ<WL!è?HKJ0OpãªX+Y+FIJF=ãªX+@Kê,M»ãª^íHíã?â(JQ+HíJ<WLè?HKJ0OpãªX+Y+F=JFIãªX+@OK<?X àH]ã?õAJFIãªX+<?;eê áhâNXSã ã?õ+JFIãªX+<?;OpãªX+YAFIJFIãªX+@í<WLH èªFIî?H$X JQSH$X<?;=;OpãªX+Y+FIJF=ãªX+@í<WLH[ã?àA;éFIèª<WJ9ã?Lå?ê\k<WLè?HKJ@J<WJ9H$@Opã?LLH$@õãªXAY]J9ã`F=XJ9H$X¹J@$ê

_ & [ 82# n4[12[8CqnNb \8QSHìXSH$OpH$@@FIJrå âxã?L½J<?@"!»@½H$X+<?OpJ^íH$XJF=@àA<?@9H$Y ãªX JQSHFéX+@> `OKF=H$X+Opå ã?â8JQSHìOK>SL9BLH$XJ@9J<WJ9H[ã?âG<<?FIL!@Kê Ý Y+Y+FIJF=ãªX+<?;=;Iå?ôJ<?@ !H$X+<?OpJ^íH$XJ`OpãªX+Y+FIJF=ãªX+@"^<$å @9õ H$OKFIâxå?ô>+X+YSHKL"TQ+FéO!QOKFILROK>+^@9J<?X+OpH$@8TUH0OK<?X @9J<WLJ8J<?@"!HPH$OK>SJFIãªX,ê

0 p]X +# C! p]Chn8l ! ! X>noC'( ZX>p [ 2>n# UX "! # Ch[ X& b \8QSHOpãª^íõÇ;IHKJFIãªXðã?â<[J<?@"!L!H>+F=LH$@/@ !PF=;=;=@$ôÇH»Bõ HKL!FIH$XAOpH8<?X+Y !PXSãzT;IH$YSè?H8JQ+<WJ^>A@9Jà Hõ+LH$@>+õ+õ ãª@9H$Y"àå"JQSHN>+@9HKL$ô?TQSH$XSHKî?HKL(JQ+HJ<?@ !F=@è?ãªF=XSèJ9ãàH8<?OpJF=îm<WJ9H$Yê»\<?@"!»@U^<$åíà HH$^àH$YAYSH$YF=XJ9ã/<0OpHKLJ<?FéXíã?Lèª<?X+F:9$<WJF=ãªX+<?;AOpãªXJ9H»JKêP\8QSHõALã?öA;IH<?;=@ã[õ+LH$@>+õ+õ ãª@9H$@<[OpHKLJ<?F=X J9H$O!Q+X+FéOK<?;H$Xî»FIL!ãªX+^íH$XJKô,H?êèSêOpãª^^½>+X+FéOK<WJFIãªXô,F=XSâxã?L!^<WJF=ãªXô,<?X+YTã?L"!P@9õA<?OpH0@9åP@9J9H$^@$ê

_ &kn4[8p l C'&[jn ZX>p [ 2 n$# UX "! # Ch[ X& b \<?@ ! H$X+<?OpJ^H$X¹J½F=@/@>SõAõã?L!J9H$Y àå F=X+@9J9LR>+^íH$XJ@@>+O!Q <?@<?OpJFIãªXA@8<?X+Y]Y+<WJ<Pê (Lã?àA;IH$^@<WL!H/@9ãª;Iî?H$YìãªX]JQSHGàA<?@!F=@³ã?âk<?X]FéXSâuã?LR^<WJFIãªXìYSH$^<?X+Yì<?X+YìTFIJQ+F=X<½OK;=<?@@Uã?â,â>+X+OpJFIãªX+@(JQ+<WJ³^FIèªQJUà H>A@9H$Yâxã?L³J<?@ !`@9ãª;=>+JFIãªXê %HKJ9HKLãªXJQSHNFéXSâuã?LR^<WJFIãªX`Y+H$^<?X+YF=@0^<Wõ+õ H$Y J9ã Y+<WJ<WàÇ<?@9H`îPFIHKT@ã?L½^íH$Y+F=<ìã?à;CH$OpJ@Kêk\8QSHíâ>+X+OpJFIãªX >SJF=;=F:9$<WJF=ãªXFé@ã?Lèª<?X+F:9KH$Y ãªXJQSH0àA<?@F=@³ã?âkTUã?L ! +ãT@Kê

iX # # 2 X>p 2[ X& !kp]X +# C>b Ý J<?@"!^<$åíà H<?;é;Iã»OK<WJ9H$Y`J9ã½<@F=XSèª;=H>+@9HKLUã?L<0è?Lãª>Sõ`ã?â,Opãª;é;=<Wà ã?L!<WJF=XSè>+@HKL!@KêáCX JQSH;=<WJ9J9HKL0OK<?@9H?ôJQSH@>SàAJ<?@ !»@Gâxã?L/H$<?ORQ >+@9HKLzôJQ+Hã?àA;=FIèª<WJF=ãªX+@KôJQSHJF=^íHí<?X+Y ã?JQSHKLLH$@J9L!F=OpJFIãªX+@^½>+@9JàHGèªFIî?H$X,ê

l ! 6# 2 p UX& ( K[ X &DnNb \8QSH@9HKJ9J;éF=XSè/ã?â J<?@ !P@U^`<$åíà H8LH$@9J9LRF=OpJ9H$Yê¹\UåõÇF=OK<?;+<?> SF=;=F=<WL!åOpãªX+Y+F=JFIãªX+@<WLH"àA<?@H$Y ãªXL!F=èªQ¹J@âuã?LGJQSHíY+F=LH$OpJQ+<?XAY+;=F=XSèä<?X+YLHKJ9L!FIHKîW<?;eôAL!ãª;IH$@Nã?âJQSHí<?X¹J<Wè?ãªXAF=@9J<?X+YJQSHõ+L!ã?J<Wè?ãªX+F=@9JKôA<?XAY]ã?àA;=FIèª<WJF=ãªX+@³LH»>+FILH$YTQSH$X+HKî?HKL@9HKJ9J;=FéXSèí<íJ<?@ !êÞ H8HPJ9H$X+Y"J<?@ !P@à»å½< KúCý øsým÷ Rù Aø ªøPJQ+<WJOpãªX+@!F=@9J@ ã?âJQSHLH$;IH$<?@FéXSè<?OpJ9ã?Læ@RçRôªJQSH8<?OpJ9ã?LR@

J9ã½TQ+F=ORQ`J<?@ !äOpãª^íõA;IHKJFIãªX<?X+YäLH$@>+;=J@ã?âOpãª^íõÇ;IHKJFIãªX<WLHL!HKõã?L!J9H$Yô¹JQSHNã?Lèª<?X+Fé@<WJFIãªX+<?;>+X+FIJ(JQ+<WJOK<?;=;=@âxã?LkJ<?@"!0Opãª^íõA;IHKJF=ãªXôzJQSH³<?OpJFIîPFIJFIH$@kJQ+<WJ <WLHLH>AFILH$Y/à»å0>+@HKL!@KôzJQ+H<?F=YA@JQ+<WJOK<?X½à HU>+@H$Y0âxã?LJ<?@ !Opãª^íõÇ;IHKJFIãªXô¹<?XAYJQSH8Tã?L"!P@9õA<?OpHNJQ+<WJUFé@@>Sõ+õ ã?LJFéXSèGJ<?@ !Opãª^íõA;IHKJF=ãªXê¹\8QSH;=<WJ9J9HKLFé@^<Wõ+õ H$YJ9ã`@9H$@!@FIãªX[@>+õ+õ ã?LJUã?LJ9ãJ9H$^íõ ã?L!<WLåTã?L"!õÇ;=<?OpH$@ã?â>+@9HKL!@$ê

\k<?@ !P@ä<WLH<?@@9ãPOKF=<WJ9H$Y TFIJQ F=XJ9H$XJ@`< >A@9HKL`ã?L< è?Lãª>Sõã?â>+@9HKL!@äQ+<$î?H?ê³\8QSH FéX¹J9H$XJ@`<WLH H$F|BJQSHKLã?à<;CH$OpJ@0ã?L0J<WLè?HKJ@ìïósêáCXðJQSH;é<WJ9J9HKL½OK<?@9H?ôTUHäOK<?X Y+FIL!H$OpJ;Iå ^<Wõ JQSHJ<?@ ! @9õ H$OKFIöÇOK<WJFIãªX J9ãOpã?LLH$@õãªXAY+F=XSè½J<WLè?HKJ@Kê ý áCX <;IH$<WL!XAF=XSè Þ á9M[âuã?LGY+<WJ<ä^F=X+F=X+è;IH$<WL!XSHKL!@Q+<$î?H½î?HKLå YAFHKL!H$X¹J@"!»F=;é;=@KôSî?HKLå[Y+F=âéBâxHKLH$X¹JàA<?O !è?Lãª>AX+Y !PXSãT;IH$YSè?H?ô»î?HKLå`Y+F HKLH$XJU<WõAõ+Lãª<?O!Q+H$@UJ9ã";IH$<WL!XAF=XSèSô¹<?X+YäT³<?X¹JJ9ã½>A@9HN;=H$<WL!X+F=XSè@9åP@9J9H$^@TQSH$XSHKî?HKLNJQ+F=@F=@LH$<?;=;Iå]XSH$OpH$@@!<WLå?ê%HKJN>A@OpãªX+@FéYSHKLJ<?@ !P@NJ9ã>AX+YSHKL!@9J<?XAY]JQSH0H$@!@9H$X¹JFé<?;=@ã?âY+<WJ<^FéX+F=XSè"<?X+Y]@9HKH!P@8âxã?L<?X <?;=è?ã?L!FIJQ+^ JQ+<WJ@9HKLî?H$@QAF=@XSHKH$Y+@KêñWê\8Q+HU;IH$<WL!X+HKLk@9H$<WLRO!QSH$@kö+L!@J<?;Iè?ã?L!F=JQ+^@JQ+<WJk^`FIèªQ¹Jà HU<Wõ+õA;éF=OK<WàA;IHTFIJQ+F=XJQ+H<Wõ+õÇ;=F=OK<WJFIãªX/>AX+YSHKLOpãªX+@!F=YSHKL!<WJFIãªX,ê

qEc!~8c!tsloCd,!yÇ$tsRqegz?~c!qElojy|!q´½fCNwujyµRqs8c!tsloRj/$gzdtsfCd wmidscRRfjWc!gdelod ò»ê H»JJQSH0>+@9HKLXSHKH$Y+@J9ã`>AX+YSHKL!@9J<?XAYìJQSH0<?;Iè?ã?L!F=JQ+^ JQ+<WJ@9HKH$^`@8J9ãà HJQSH0^ãª@9J<Wõ+õ+L!ã?õ+L!F=<WJ9H?ê

?NX+YSHKL!@J<?X+Y+F=XSè <?;=@9ã FéX+OK;=>+YSH$@0;IH$<WL!X+F=X+è[JQSHäFéX¹J9HKLõALHKJ<WJFIãªX ã?â8LH$@>+;=J@/ã?à+J<?F=X+H$Y à»å <Wõ+õA;IåPF=XSèãªXSH ã?âJQSH <?;Iè?ã?L!FIJQ+^`@ìJ9ã JQSH ;IH$<WLRXSHKL!@[Y+<WJ<Pê Sã?L JQ+<WJKôJQSH ;IH$<WL!X+HKL ^<$åßö+LR@9J[;Iã»ã!ãî?HKLYSH$^ãªX+@9J9L!<WJFIãªXA@8<?X+Y[F=;é;=>+@9J9L!<WJF=ãªX+@(âxã?L8JQSHO!QSãª@9H$X <?;Iè?ã?L!FIJQ+^[ê

ê ãzT JQSH ;IH$<WL!X+HKLäHPõ HKL!F=^íH$XJ@`TFIJQ JQ+HY+<WJ<PêDG<WJ<<WLHð@9H$;IH$OpJ9H$Yß<?X+YßOpãªXSö+èª>+LH$Y âxã?LìJQSH<?;Iè?ã?LRFIJQ+^]ê+\8Q+H/<?;Iè?ã?L!FIJQ+^ Fé@³H»H$OK>SJ9H$Y<?X+YìLH$@!>+;IJ@8<WLHã?àAJ<?F=XSH$Yê

Sê F=X+<?;é;Iå?ôUJQ+H LH$@!>+;IJ@ì<WLH H»õÇ;=<?F=XSH$YJ9ã JQSHð;IH$<WL!XSHKLzêM mQ+H^<zå¿X+ãzT OpãªX¹JFéX>SH à»å@9H$;=H$OpJF=XSè<?XSã?JQ+HKL^íHKJQSãPY]ã?L<?;=è?ã?L!FIJQ+^ <?X+Y[ã?à+J<?F=X[<?Y+YAFIJFIãªX+<?; F=X+@!FIèªQ¹JF=XJ9ãíJQSH0YA<WJ<íJ9ãà H/<?X+<?;Iåq9KH$YêÞ H^`<$å"^<WõíJQSH$@9H8@>+à+J<?@ !P@J9ã0JQSHF=X¹J9H$XJ@Kÿ?HPõA;Iã?L!FéXSèNYA<WJ<^F=X+F=X+è<?;Iè?ã?L!F=JQ+^@KôW>+X+YSHKLR@9J<?X+YPB

F=XSèQ+ãzT J9ãõALHKõA<WLH/Y+<WJ<PôÇ;IH$<WL!X+F=X+è½J9ãäF=X¹J9HKL!õ+LHKJLH$@>A;IJ@³ã?à+J<?F=XSH$Y,êÝ JJQSH`@<?^íH`JF=^íHJQ+Fé@J<?@ !ð^<$åðà HíLH»>+FIL!H$Y àåð< ;éFIâuHíOK<?@9H ïósê Sã?L"F=X+@J<?X+OpH?ô,JQSH`;=H$<WL!XSHKL

Tã?L"!»@N<?@G<äOK;=HKL"![F=X <`àA<?X&![<?X+Y J9L!FIH$@J9ãö+èª>SLH/ãª>+JTQAF=O!Q ;Iãª<?X+@NQ+<$î?H½à H$Opãª^íHâ<?>+;IJrå[<?X+Y TQ+<WJF=@UJQSHNLH$<?@9ãªXâuã?LFIJKêáhXJQ+Fé@(OK<?@9H?ôPJQSHOK;IHKL"!íà H$Opãª^íH$@³<½;IH$<WL!XSHKL³<?X+YJ9L!FIH$@UJ9ãí;IH$<WL!XY+<WJ<½^F=X+F=X+è0<?@^½>+O!Q[<?@FIJ8F=@XSHKH$Y+H$Y]âuã?LJQSH/;=FIâxHOK<?@9H?ê

@ 2 n# !0C'WlD[ X& \8QSHäøsýW÷ Sø ù íùzþ Y+HKöAXSH$@8TQ+<WJKôATQ+H$XôÇQSãT/ôAà»å]TQSãª^[ôÇ<?X+Y TFIJQTQ+FéO!Q]Y+<WJ<íTã?L"!]Q+<?@J9ã`àH/Y+ãªXSH?ÿ

\k<?@ ! <?OpJFIîPFIJFIH$@½YSHKöAX+HäQSãT JQ+H`Tã?L"! F=@½<?OpJ>+<?;=;Iå Y+ãªXSH?ôH?êèSê à»å F=X+@9J9LR>+OpJF=XSè[JQ+H>+@HKL0ã?L"àåF=Xî?ã!PF=XSè<?X[<Wõ+õÇ;=F=OK<WJFIãªXê

\8Q+H OpãªX¹J9L!ãª; +ãT5YSHKöÇXSH$@íJQSH @H>SH$XAOpH ã?â<?OpJFIîPFIJEå HPH$OK>SJFIãªXêUDHKõ H$X+YAF=XSèðãªX JQ+H @9õ H$OKFIöAOÞ á9M¿@HKî?HKL!<?;/OpãªXJ9Lãª;/OpãªX+@9J9LR>+OpJ@]<WLH <$îW<?F=;=<WàÇ;IHð@>+O!Q·<?@]Y+H$OKF=@FIãªXô<?;IJ9HKLRX+<WJFIî?H?ôõA<WL!<?;é;IH$;=F=@^[ô;Iã»ã?õA@Kô+@J<WLJHPF=JOpãªX+Y+FIJF=ãªX+@KôS<?X+Y[Y+F HKLH$XJ !PF=X+Y+@ã?âOpãªX+@9J9L!<?FéX¹J@8@!>+O!Q[<?@YSH$<?Y+;=FéXSH$@Kê

\8Q+HGYA<WJ<,+ãzT @9õ H$OKFIöAH$@UQSãT Y+<WJ<,+ãT@³JQSLãª>SèªQìJQ+HNJ<?@"!Çê+DNHKõ H$X+Y+F=X+è0ãªXìJQSH Þ á9MäY+F HKLH$XJOpãªX+OpHKõAJ@8HSF=@9J8@>+ORQ <?@8FéXSõA>SJãª>SJ9õÇ>SJCBEOpãªX¹J<?FéXSHKLã?â<?OpJFIî»F=JFIH$@ã?L;IãPOK<?; èª;Iã?àÇ<?;îm<WLRF=<WàA;IH$@Kê

\8Q+H½ú ~÷ ø³ù7 Pø ù F=@³JQSH/@9J<WJ9Hã?â < <?F=L!@³LH$<?O!Q+H$Y[<?X+YìJQSH/@<WJFé@9âx<?OpJF=ãªXìã?âJ<WLè?HKJOpãªX+Y+F|BJFIãªX+@$ê\k<?@ !íH$X+<?OpJ^íH$XJFé@U@>+õ+õ ã?LJ9H$Yíà»åíõ+LHpBEYSHKJ9HKL!^`F=XSH$YíõA;é<?X+@Kê¹\8Q+H$@9HõA;é<?X+@<WLHN@OpH$X+<WL!FIãª@UTQ+FéO!QQ+<zî?H< X>+^à HKL0ã?â8@9J9ã?LRFIH$@/JQSHKå <WL!Hä@>SõAõã?L!JF=XSèSê Þ Hì^<$å >+@HàA;=<?O !à ãª<WL!Y+@0âuã?L½LH$Opã?L!YAF=XSè[ã?õ H$XJ<WLè?HKJ@Kê Þ QSH$X+HKî?HKL/<äJ<WL!è?HKJ0F=@GOpãª^íõA;IHKJ9H$Y <?X+Yð<J<?@ !F=@GOpãªX+@F=Y+HKLH$YJ9ãà Hí@>+OKOpH$@!@9âx>A;=;Iå]â>+;IöA;=;=H$YJQSH$XäTUHGYSH$;IHKJ9HJQ+F=@(J<?@ !âxLãª^6JQ+HàA;=<?O !à ãª<WL!Y,ê\8QSH 7 ù 7 AøAã?â,<?OpJ9ã?LR@³TFIJQ+F=X"JQ+HJ<?@ !ä@9ãª;=>PBJFIãªX+@F=@8àÇ<?@9H$Y[ãªX JQSH@9õ H$OKFIöÇOK<WJFIãªX]ã?âJQSHäúCù í<?X <?OpJ9ã?LGõA;=<$åP@Kô+JQ+H ýWúpø8JQ+H<?OpJ9ã?LNõA;=<$åP@8TFIJQ+F=XJQSH0@!OpH$X+<WL!FIãSô+<?X+Y[JQSHíú = øx÷<?X+Y ù¹ü ¹ýªø ù +÷<?X[<?OpJ9ã?LGQ+<?@TFIJQAF=XJQSHèªFIî?H$X[L!ãª;IH?ê

\8Q+H0Lãª;IH½@9õ H$OKFIö+H$@JQSH0à H$Q+<zî»F=ãª>SLHPõ H$OpJ9H$Y ã?âU<?X <?OpJ9ã?L$ê Ý L!ãª;IHF=@N<Opãª^íõ+LH$QSH$XA@FIî?H0õÇ<WJ9J9HKL!Xã?âàH$QA<$îPFIãª>SL<?X+Yð@9HKLî?H$@<?@/<]@9J9L!<WJ9HKè?å âxã?L0Opã?õAF=X+èTFIJQLH$OK>SLLH$XJ/@FIJ>A<WJFIãªX+@<?X+YðYSH$<?;éF=XSèTFIJQJQSHL!ãª;IH$@Gã?â³ã?JQSHKL!@Kê Ý Lãª;IHíL!H$^<?F=X+@GLH$;é<WJFIî?H$;Iå @9J<WàA;IH?ôHKî?H$X JQSãª>SèªQ Y+F HKLH$XJ/>+@9HKLR@Gã»OKOK>Sõ»å JQSHõ ãª@FIJFIãªX,ê Ý >+@9HKL/^<zåQA<$î?H`<]>+XAF >+H½@9Jrå»;=H½ã?âLãª;IHíHPH$OK>SJFIãªX,ôàA>SJGJQ+F=@GF=@GHSQ+FIàAF=J9H$Y TFIJQ+F=X JQSHà ãª>+X+Y+<WLRFIH$@/ã?â8JQ+HäHPõ H$OpJ9H$YàH$QA<$îPFIãª>SL½ã?â8JQSHì<?OpJ9ã?L$ê 8ãª;IHHPõH$OpJ<WJF=ãªX+@"F=X+OK;=>+Y+Hà ã?JQ <?OpJF=ãªX+@<?X+Y»>+<?;=FIJFIH$@$ÿâxã?LF=X+@9J<?X+OpH?ôSF=XäLH$<?;;=F=âuHN<"J9H$<?O!QSHKL^`<$å`à HGHPõH$OpJ9H$Y]X+ã?JãªXA;IåJ9ãíYSH$;=FIî?HKL;IH$OpJ>+LH$@Kô<?@@F=èªX`QSãª^íHKTã?L"!ô»<?XAYõ+LHKõÇ<WLHHS<?^F=X+<WJF=ãªX+@àA>+J(<?;=@9ãJ9ãà HYSH$YAF=OK<WJ9H$YôOpãªXAOpHKL!XSH$Yô»QSãªXSH$@9JKôP<?X+YLH$@9õ ãªX+@!FIàA;IH?ê

\8Q+HKLH<WL!HäJrTUã JEå»õ H$@½ã?â8Lãª;IH$@Kÿ YSH$OK;=<WLR<WJFIî?H<?XAY OpãªXJ9HPJ>+<?;³ãªXSH$@Kê \8QSHäâuã?L!^HKL½ãªX+H$@½Y+H$OK;=<WLHJQ+<WJ<?X <?OpJ9ã?L/F=@õA;=<$åPF=XSè<õA<WLJF=OK>+;é<WLLãª;IH?ôH?ôèSô,<?X <?OpJ9ã?Là H$F=XSèäFéYSH$X¹JF=ö+H$Y <?X+Y<?@<?XH$^íõA;Iãå?HKH?êãªXJ9H»J>A<?; Lãª;IH$@N@QSãzT QSãT&<?X <?OpJ9ã?L/<?OpJ@GTFIJQ+F=X JQSHíOpãªX¹J9HPJã?â(<ì@OpH$X+<WLRFIã<?XAY QSãT&<?X <?OpJ9ã?LF=@F=Xî?ãª;Iî?H$Y TFIJQ+F=X JQ+HOpãªXJ9H»Jìã?â0<?X+ã?JQSHKL]@OpH$X+<WL!FIãSêDNH$OK;=<WL!<WJFIî?H Lãª;IH$@^<zå à H ^íãPYSH$;=;IH$Y àå<?@@9ãPOKF=<WJF=X+èJQSH³<?OpJ9ã?LJ9ãN<Lãª;IHUJEå»õ H?ê³ãªX¹J9HPJ>+<?;Lãª;IH$@ <WLH³^íã»Y+H$;=;IH$Yà»å0<?@@9ãPOKF=<WJF=X+è<?X½<?OpJ9ã?LTFIJQ


JQSH³Tã?L"!0H ã?LJJQSH<?OpJ9ã?L(F=@ <?@@!FIèªXSH$Y"J9ã<?X+Yí<NLãª;IH³JEå»õ HYSH$@OpL!FIàÇF=XSè8JQSH8FéX¹î?ãª;Iî?H$^H$X¹J ã?âAJQ+H³<?OpJ9ã?Lzê\8QSH"Lãª;=HíJEå»õHíõALãzîPF=YSH$@G<]YSH$@OpLRFIõ+JFIãªXã?âJQSHíLãª;IHí<?X+YðOK<?X àHíQ+F=HKL!<WL!O!QAF=OK<?;=;Iå[@9J9LR>+OpJ>SLH$Yê ãª;IH$@^<zå`<?;=@9ãàHQ+FIHKL!<WL!ORQ+F=OK<?;=;=å½@9J9LR>+OpJ>SLH$Yê Ý JJQ+H@<?^íHJF=^íHLãª;IH$@^<$åíà HõÇ;=<$å?H$YF=X`Opãª;é;=<Wà ã?L!<WJFIãªXê

ý áhXì<?XìHpBsàA>+@!F=XSH$@@<Wõ+õA;=FéOK<WJFIãªXTHOK<?X]Y+F=@9JF=X+èª>+F=@QíL!ãª;IH$@³@>+O!Qì<?@³Tã?L"!?HKL$ôSOK>+@9J9ãª^HKL$ô<?X+YðL!ãª;IH$@TFIJQAF=XJQSH`Y+F=@J9L!FIàA>SJF=ãªX @OpH$XA<WL!FIãSê\8Q+HíTUã?L"!?HKLLãª;IHíH$XJ<?F=;=@L!ãª;IH$@0@>AO!Q <?@OpãªX¹J9L!<?OpJ9ã?LzôOpãªXJ<?OpJKô¹H$^íõA;=ãzå?HKH?ô¹<?X+Y"@9õ ãªX+@ã?L$ê?\8QSH³OK>+@9J9ãª^íHKLL!ãª;IH³J< !?H$@õA<WLJF=X½àAFé;=;=@,J9ãOK>+@9J9ãª^íHKL$ô?@QAFIõ"J9ã/OK>+@CBJ9ãª^íHKL$ô?<?X+Y½H$X+YSBE>+@9HKLOK>+@9J9ãª^íHKLzê Þ FIJQ+FéX0JQSH³Y+F=@J9L!FIàA>SJF=ãªX/@OpH$X+<WL!F=ãNTH^<$å½Y+F=@9JFéXSèª>+F=@Q0<?OpJFIî?H8<?X+Yõ+LãWBE<?OpJF=î?HNL!ãª;IH$@KôPFeêH?êJQ+HNY+Fé@9J9L!FIàA>+J9ã?L(<?X+Y<?X<Wè?H$XJKê+\8QSH$@HLãª;=H$@UOK<?X]<Wèª<?F=Xà HYAF=@9JF=XSèª>AF=@QSH$YíF=XJ9ã<?@@9ãPOKF=<WJFIãªX,ôAOpãª^íõ HKJFIJ9ã?L$ô+õÇ<WLJXSHKL$ô+õALãª@9õ H$OpJKô+LHKâxHKLLHKL$ôSL!HKèª>+;=<WJ9ã?Lå]<Wè?H$X+Opå?ô @Q+<WLH$Q+ãª;=YSHKL$ô+@>+õ+õA;=FIHKLzô<?X+Y]THKàA@F=J9Hî»F=@!FIJ9ã?L$ê

Ý JJQSH@!<?^íHJF=^H@9HKî?HKL!<?;ÇLãª;IH$@U<WLHNõA;=<$å?H$Y`àåíõ HKã?õA;=H8ã?LUã?L!èª<?X+F:9$<WJFIãªX+@UTFIJQAF=X"JQSHOpãªXJ9HPJã?âõ+Lã];9H$OpJ/^<?X+<Wè?H$^H$X¹JKê Ý õ HKL!@9ãªXã?L/ã?Lèª<?X+F!9$<WJFIãªXð^<$åà H"JQSHí@9õ ãªX+@9ã?L$ô Tã?L"!?HKL$ô,^<?X+<Wè?HKLzô,;IH$<?Yô<?YSîPF=@9ã?Lã?L>+<?;éFIJEå<?@@>SL!<?XAOpH0^<?X+<Wè?HKLâuã?L<õ+Lã];9H$OpJKê

?N@9HKL!@">+@>A<?;=;IåðãPOKOK>Sõå @9HKî?HKL!<?;³õ ãª@FIJFIãªXA@KôTQAF=O!Q ^<$å ã?L^<$å XSã?J"à HOpãª^íõÇ<WJFIàA;IHäTFIJQ ãªXSH<?XSã?JQSHKLzêkM»ã <?OpJ9ã?L!@½^<zåðõA;=<$å @9HKî?HKL!<?;ULãª;IH$@0<WJ0JQSH`@!<?^íHJF=^íH?êáhXðJQAF=@/OK<?@9H?ôJQSHKå ^>A@9J/Q+<$î?Hì<Opãª^àAF=XSH$Y]îPFIHKT ã?âJQ+H0<Wõ+õA;=FéOK<WJFIãªX]<?X+Y <`Opãª^0àAFéXSH$Y[<?OKOpH$@@NJ9ãJQSH$F=LOK<WõA<WàAFé;=FIJFIH$@KêS\8Q+HKLHKâuã?L!H?ô+JQSHÞ á9M^½>+@9Jõ+Lãî»F=Y+HJQSH<WàAFé;=FIJEå`J9ãä÷Kø <?X+Y ý Çý JQSH$@HLãª;IH$@KôP<?X+YìJ9ã!ù `ü /õ ã?LJ9âxãª;=FIãª@³@9ãJQ+<WJ8JQ+H0<Wõ+õA;=FéOK<WJFIãªXì^<?F=XJ<?F=X+@³J9ã`à HOpãªX+@Fé@9J9H$X¹Jâuã?L8H$<?ORQ <?OpJ9ã?Lzê

\8Q+H ýWúpø<?@@9ãPOKF=<WJ9H$@JQSH<WJ^íãª@9õAQSHKL!H?ôª^F=@@F=ãªXôã?à;CH$OpJFIî?H$@$ô<?X+Y"ã?à<;9H$OpJ@TFIJQ"JQSH8F=Xî?ãª;Iî?H$^íH$XJã?âkJQSH<?OpJ9ã?LF=Xì<í@OpH$X+<WLRFIãSêSárJF=@³L!HKöAXSH$YôPTQSH$XìOpãªXJ9H»Jã?âJQSH/FéX¹î?ãª;Iî?H$^H$X¹J8F=@³J< !?H$X F=X¹J9ãOpãªXA@F=YPBHKL!<WJFIãªX,ê \QSH0õA<WL!JGFé@àA<?@H$Y ãªX <ìOK<WJ9HKè?ã?L!F:9$<WJF=ãªXðã?â(JQSH½à H$Q+<$îPFIã?LGã?â(>+@HKL!@Kê Þ H"^`<$å Y+HKL!FIî?H½JQ+<WJ>+@9HKLR@GJ<?O"!P;=F=XSè[@9ãª^Hõ+Lã?àA;=H$^5Y+ã[XSã?J0;=F !?H"J9ã[T³<?FIJKê,\8Q+HíõA<WLJ/F=@YSH$@!OpL!FIà H$YJQSLãª>SèªQ JQSH !»F=XAY ã?âF=XJ9HKL!<?OpJFIãªX]<?OpJ9ã?L!@<WLHGõ+LHKâxHKLL!F=X+èâxã?LJQSHOK>SLLH$XJ³J<?@ !P@8<?X+YJQSHà H$Q+<$îPFIãª>SL³ã?âk<?OpJ9ã?L!@TH/XSHKH$YìJ9ã@>SõAõã?L!JKêP\QSHKLHKâxã?LH?ôSJQSH/à H$Q+<zî»FIã?LR<?;@9J9HKLHKã?JEå»õ HF=@Y+H$@OpL!FIà H$YJQSLãª>SèªQ[JQSH/õA<WLJKê

Ý L!ãª;IHäH$XJ<?F=;=@"OpHKLJ<?FéXßùü ý?ø ù S÷[<?X+Y¿ú = øx÷?ê(ëNàA;éFIèª<WJFIãªX+@<WLHìã?àA;=FIèª<WJ9ã?Lå J<?@ !»@$ô OpãªXAY+>+OpJKô@9HKLîPF=OpH?ô³ã?Lìâx>AX+OpJFIãªX+@äJQ+<WJ]<WL!F=@9HâxLãª^*JQSHð>+@9HKL!@äLãª;IH >+X+YSHKLì@9õ H$OKFIö+H$Y¿OpãªX+Y+F=JFIãªX+@Kê FIèªQJ@]<WLHè?L!<?XJ9H$Y<?@<Gõ H$OK>+;=Fé<WLà H$XSHKö+JKô?<?YSîW<?XJ<Wè?H?ô¹ã?Lâ<$î?ã?L(J9ã/<GL!ãª;IH?ê Þ H8@9õ H$OKFIâxå/L!FIèªQJ<?X+Y½ã?àA;=FIèª<WJF=ãªX+@<?@OpãªX+Y+F=JFIãªX+@JQ+<WJ<WLHU^<WõAõH$Y/J9ãOpãªX+Y+FIJF=ãªX+@ãªX0<?OpJF=ãªX+@<?X<?OpJ9ã?L OK<?XOK<?;=;ªF=X0<@OpH$X+<WLRFIãSêmëNàA;éFIèª<WJFIãªX+@<?X+YL!FIèªQJ@³F=X+OK;=>AYSH@>+ORQâuã?L³â>+X+OpJFIãªX+<?;éFIJEå?ô»âuã?LOpãª;=;é<Wàã?LR<WJFIãªXô»âuã?LOpãªXJ9H$X¹JKôA<?XAY`âxã?L8Y+F=@@H$^F=X+<WJFIãªXã?â+@>+ORQ/J9ãNã?JQSHKL <?OpJ9ã?L!@KêªëNàA;=FIèª<WJF=ãªX+@,<?X+Y0L!FIèªQJ@^<zå/F=X+OK;=>AYSH<?;=@9ã8JQ+HU@9õ H$OKFIöAOK<WJF=ãªX/ã?âSã?àA;=F=èª<WJFIãªX+@Kôõ HKL!^F=@!@FIãªX+@<?X+Y]õ+L!ãªQ+FIàAFIJF=ãªX+@UFéXìJQSH/OK<?@9H0ã?âkHSOpHKõ+JFIãªX+<?;@FIJ>+<WJFIãªXA@Kê

iX # # 2 X>p 2[ X& Ý OpJ9ã?LR@(OK<?XOpãª;=;é<Wàã?LR<WJ9Hâuã?L(@ãª;Iî»FéXSèGJ<?@ !»@$ê»MP>+ORQí< !ù ý¹üùWú9ý?ø ù F=@(@9õ H$OKFIö+H$Y½ãªXJQSH½àA<?@F=@ã?âJQSH"@9J9ã?Lå»à ãª<WL!YôÇJQSH½@JEåP;IHã?âOpãã?õ HKL!<WJF=ãªX <?X+YJQSH"Opã»ã?L!Y+F=X+<WJF=ãªX[â<?OKF=;=FIJFIH$@$ôA<?X+YJQSHLãª;IH$@ã?âJQSH½õA<WLJX+HKL!@KôAJQ+H$FILL!H$@9õ ãªX+@FIàAFé;=FIJFIH$@Kô»JQSH$FILNL!FIèªQJ@Kô<?X+Y JQ+Hõ+L!ã?J9ã»Opãª;=@NJQSHKå ^<$å[L!H$;Iå]ãªXêãª;=;é<Wàã?LR<WJFIãªX F=@/@9HKõA<WLR<WJ9H$Y F=XJ9ã !ù , !ý?ø ù +ô !ù$ùWú9þ Çý?ø ù +ô<?X+Y Rù$ù KúCýªø ù Aê ³ãª^^>AX+F=OK<mBJFIãªXìOK<?X]à HNàA<?@9H$YìãªXìOK;=<?@@FéOK<?;<WLRO!Q+FIJ9H$OpJ>+LH$@8@>SõAõã?L!JF=XSè0Opãª^^½>+X+FéOK<WJF=XSèí@9åP@9J9H$^@Kêã»ã?õ HKL!<WJFIãªXF=@(àA<?@9H$YãªXä<?XHPõA;=F=OKF=JQ+<?X+Y+;=FéXSèGã?âJQSH8Tã?L"!íõ+LãPOpH$@@9H$@Kô¹JQSHTã?L"!íã?Lèª<?X+F!9$<WJFIãªXô¹<?X+Y`ãªX`Tã?L"!PF=XSè@9õA<?OpH$@âxã?LOpãª;=;=<Wà ã?L!<WJF=XSèõA<WLJXSHKLR@Kê ã»ã?õ HKL!<WJFIãªXOK<?XàHG@9õ H$OKFIö+H$Y`àåä@9J9ã?Lå»àãª<WLRY+@Kê ³ãã?L!YAF=X+<WJFIãªX@>SõAõã?L!J@JQSH"OpãªX+@F=@9J9H$XAOpå]ã?âTUã?L"!]õALã»YA>+OpJ@Kô+ã?âTã?L"!]õ+L!ã?è?LH$@@Kô<?X+Y F=@N@>SõAõã?L!J9H$Y]àå[<?X HPõA;=F=O~BFIJ;Iåí@9õ H$OKFIöAH$YOpãªX¹J9LR<?OpJJQA<WJYSHKõ H$X+YA@ãªXäFéX¹J9H$XJFIãªX+@KôãªX`JQ+H>+@9HKLR@(Opãª^^½>+X+FIJrå<?X+YäãªX`JQSHN@9åP@9J9H$^@>SõAõã?L!JF=XSè"Opãª;=;=<Wà ã?L!<WJFIãªXê

ý ãª;=;=<Wà ã?L!<WJF=î?Hì;=H$<WL!X+F=XSè F=@í< J9H$<?ORQ+F=XSè @9J9LR<WJ9HKè?åFéX TQ+F=O!Q @!^<?;=;³;IH$<WL!X+FéXSè è?L!ãª>SõA@ã?â8;IH$<WL!X+HKL!@Kô,H$<?ORQ ã?â8Y+F HKLH$XJ0;IHKî?H$;é@/ã?â8<WàAF=;éFIJEå?ô>A@9H`<[îW<WL!FIHKJråðã?â8;IH$<WL!X+FéXSè[<?OpJFIîPFIJFIH$@/J9ãF=^íõ+L!ãzî?H


JQSH$FIL½>+X+YSHKLR@9J<?X+Y+F=X+èã?â8< @>Sà<;9H$OpJKê U<?O!Q ^íH$^àHKLã?â8< ;IH$<WLRX+F=XSè]è?Lãª>+õ F=@0LH$@9õ ãªX+@FIàÇ;IHíXSã?J0ãªX+;=åâxã?L½;IH$<WLRX+F=XSè]TQA<WJ0F=@/J<?>+èªQ¹JKôkàA>SJ0<?;é@9ã âxã?LQSH$;=õAF=XSè]è?Lãª>+õ ^íH$^à HKL!@/J9ã;IH$<WL!XôJQ>+@OpLH$<WJF=XSè<?X<WJ^íãª@9õÇQSHKLHðã?â ;CãªFéX¹J]<?O!QAFIHKî?H$^íH$XJKê%H$<WL!XSHKL!@]^<zå·<Wõ+õA;IåJQSH !»X+ãzT;IH$Y+è?HðJQSHKå¿QA<$î?H ã?àAJ<?F=XSH$YY+>SLRF=XSèì;IH$<WL!X+F=X+è@9J9HKõÇ@Kê.(<?ORQ @9J>+Y+H$X¹J^<zå <?OpJF=X Y+F HKLH$X¹Jè?L!ãª>SõA@F=X JQSL!HKHY+F HKLH$X¹JGLãª;=H$@KÿJQSHLãª;IHã?â <?X`H»HKLROKF=@9HJ9H$<?^ ^íH$^à HKL$ô?JQSHL!ãª;IH8ã?â<?X`<?YSîPF=@9ã?L(ã?L(HPõHKL!J(<?X+YJQ+H8Lãª;IH8ã?â<?X`HKîm<?;=>A<WJ9ã?L$ôTQSã ^<WL"!P@ì<?X+Y è?LR<?YSH$@JQSH L!H$@>+;IJ@`ã?â/JQSHJ9H$<?^]ê\8QSH Opãª;é;=<Wà ã?L!<WJF=XSè õA<WLJFIH$@Q+<$î?H JQSH$F=LäãTXOpã»ã?õHKLR<WJFIãªXô8Opãª^^½>+X+F=OK<WJF=ãªX <?X+Y Opã»ã?L!Y+F=XA<WJFIãªX·@9õA<?OpH?ê +ã?L F=X+@J<?X+OpH?ôJQSHðHKîW<?;=>+<WJ9ã?L <?XAY·JQSHJ9H$<?^@G@Q+<WL!H<è?L!ãª>SõOpãª^`^>+XAF=OK<WJFIãªX[õÇ;=<?OpH<?X+Y@9J9ã?LHJQSH$FILLH$@>+;IJ@F=X <?X<?X+@9THKLGYSH$;=FIî?HKLåìà ã ê\8QSHHKîW<?;=>+<WJ9ã?LNYSH$;=FIî?HKLR@<?@@FIèªX+^H$X¹J@J9ã`H»HKL!OKFé@9HJ9H$<?^@JQSLãª>SèªQìJQSH<?@@FIèªX+^H$X¹Jà ã ê

N[8X6p 0 X6p8[jZX# X>n 24& ( ZC 2 noCqn kã?LJ9âxãª;=FIãª@ L!HKöAXSH³JQSH@9õ H$OKFIöAOK<WJFIãªX"ã?â;=FIâxHOK<?@H$@Kô?TQ+F=ORQí<WLHOpãª;=;IH$OpJ9H$Y[àåäã?àA@9HKLîPF=XSè"LH$<?;;=F=âuHG@FIJ>+<WJF=ãªX+@³<?X+YìJQSH/Y+<WJ<í<?X+Y]<?OpJF=ãªX+ãzT FéXäJQ+H$^]ê+\8QSH;=FIâxHGOK<?@9HYSH$@OpLRFIõ+JFIãªX <?;=;IãT@J9ã Y+H$Y+>+OpJJQSH`Y+H$^<?X+Y+@Gâxã?L0Y+<WJ<Pôâx>+XAOpJFIãªX+@Kô õ HKLâxã?L!^<?X+OpH?ô,<?X+Yð@!>Sõ+õ ã?LJF=XSè<?F=Y+@@>+ORQì<?@ %(ù?ú÷ ý<?X+Y %(ùWú ý/÷ ùWúpø~ê+\8QSHNTUã?L !»@9õÇ<?OpHNF=@YSHKJ9HKL!^`F=XSH$YäàåJQ+Hõ ã?LJ9âxãª;=FIãSôFIJ@8@!>Sõ+õ ã?LJàåìJQSHõ+L!ã?öA;IHGã?â JQSH/<?OpJ9ã?L!@NF=X¹î?ãª;=î?H$Yê

ý & %,HKJ>+@³OpãªX+@F=Y+HKL<";=FIâxHOK<?@Híú ùRý?ø ù +êA\8Q+Hõ ã?LJ9âxãª;=FIãâuã?LJQ+Fé@U;=F=âuHNOK<?@9HF=@àA<?@9H$YãªX<0X»>+^à HKL(ã?â J<?@ !P@@!>+O!Qä<?@KÿORQ+<?XSè?HNàA<?@F=O8YA<WJ<0ã?âF=@@!>SHKL$ôªõ+L!ãzîPF=YSH<0î»FIHKTãªXJQSHNY+<WJ<J9ã<?;=;Aã?JQSHKLF=XJ9HKLH$@9J9H$YäõA<WLJFIH$@$ôF=X+F=JF=<WJ9H8J<?@ !P@(ã?â,<?@!@9ã»OKFé<WJ9H$Y;éFIâuHOK<?@9H$@KôP<WL!O!Q+F=î?Hãª;=YY+<WJ<0<?XAYäOK>SL!LH$X¹JO!Q+<?X+è?H$@KôQ+<?X+YA;IHHSOpHKõ+JFIãªX+<?;J<?@ !P@KôS<?X+YìO!QA<?XSè?H/Y+<WJ<"F=Xäã ÒKF=<?; YSãPOK>+^íH$XJ@Kê»\QSHN;éFIâuHNOK<?@9H/F=@Opãª^íõA;IHìY+>SHJ9ãJQSHä;=<WL!è?Hîm<WLRFIHKJEå ã?â8@!>Sà+J<?@ !P@Kô,JQSHF=X+FIJFé<WJFIãªX ã?âTQ+F=ORQ YSHKõ H$X+YA@ãªX JQSHF=@@>+HKL$ê\8QSH$@HJ<?@ !P@<WLHì<?@@9ãPOKF=<WJ9H$Y TFIJQ @!>Sà+J<?@ !P@0@>AO!Q <?@ORQSH$O"!PF=XSèSô TQSHKJQ+HKL<?;=;UXSH$OpH$@@<WLå YSã»OK>A^íH$X¹J@Q+<$î?Hìà HKH$X@>SõAõA;=FIH$Yô»@9õ H$OKF=<?;Q+<?X+YA;=F=XSè"^>A@9Jà H/<Wõ+õA;=FIH$Y,ôHKJOWê

Ý JJQ+H8@<?^íHJF=^íHTH8XSHKH$YíJ9ã/OpãªXA@F=YSHKLJQSH8FéX¹î?ãª;Iî?H$^H$X¹Jã?â <WJ(;IH$<?@Jâuãª>SLYAFHKL!H$X¹J<?OpJ9ã?L!@Kê\8QSHF=@@!>SHKLL!<?F=@9H$@JQSH0ORQ+<?XSè?H0ã?âY+<WJ<`J<?@ !]Q+<?X+Y+;=H$Yìàå]OKFIîPF=;@9HKLîW<?XJ@KêAáhâJQ+H0F=@@>+HKL8L!<?F=@9H$@8HPOpHKõ+JF=ãªX+@âxã?LNY+<WJ<J9L!<?XA@9âuHKLNJQSH$X@9õ H$OKF=<?;@!>Sõ+õ ã?LJF=@LH»>+FILH$Y àå[<?X <?OpJ9ã?LJQ+<WJG<?OpJ@G<?@G<äY+<WJ<õ+L!ã?J9H$OpJFIãªXã ÒKF=<?;sê F=X+<?;=;Iå?ôAJQSHY+<WJ<`ãªX[JQSHLH$;IãPOK<WJFIãªX<WLHYSH$;éFIî?HKLH$Y]J9ã<`X»>+^0à HKLã?â<?OpJ9ã?L!@JQA<WJõA;=<zå]JQSHLãª;IHã?âã ÒKF=<?;+à ãPY+FIH$@ ã?L³@>Sõ+õ ã?LJã?L!èª<?X+F:9$<WJFIãªX+@$ê¹\8QSH@H$OK>SL!FIJråíõ+Lã?öA;IH$@ã?âJQSHF=@@!>SHKL(<?X+Y`JQSHOKFIîPF=;@9HKLîW<?XJ@LH»>+FIL!H/<`@9ã?õAQAF=@9JF=OK<WJ9H$Y[YA<WJ<`^<?X+<Wè?H$^H$X¹JKô H?êèSêAJ< <?XAY @9ãPOKF=<?;@H$OK>SL!FIJråìYA<WJ<`^½>+@9Jà H!?HKõ+JFéX]F=@9ãª;=<WJFIãªXìâxLãª^ H$<?ORQ ã?JQ+HKL$ê

\8Q+H/^F=X+Y+^`<Wõ[F=X FIèª>SLH `@>+^^<WLRF=@9H$@<íõA<WL!Jã?âkJQ+H0;=FIâxH/OK<?@9H/LH$;=ã»OK<WJFIãªX,ô+JQSH/J<?@ !P@8L!H$;=<WJ9H$YJ9ãàA<?@!F=OO!Q+<?X+è?H$@KôAJ9ãÒRQ+<?XSè?H$@ã?â<?@@9ãPOKF=<WJ9H$Y[õA<WL!JFIH$@KôSJ9ãÒRQ+<?XSè?H0ã?âY+<WJ<ãzTXSHKLR@Q+FIõ,ôS<?X+Y[J9ãJ<?@ !P@ã?â<?@@9ãPOKF=<WJ9H$Y`;éFIâuHOK<?@9H$@$ê\8QSH8<?OpJ9ã?LR@(õA<WL!JF=OKFIõA<WJF=X+èGFéX"JQSH;=FIâxH8OK<?@9H<WL!H8LH$@9J9L!FéOpJ9H$YJ9ã/JQSHâuãª>SLU^<?F=XJEå»õ H$@ã?â<?OpJ9ã?L!@Kê\8QSH$FIL@>SàAJ<?@ !»@<WLH0Y+F HKLH$XJâuL!ãª^ JQSHJ<?@ !P@8ã?âkJQSH0F=@!@>SHKL$ê

DG>SL!FéXSèð<?X+<?;IåP@F=@"ã?â>+@9HKLà H$Q+<zî»F=ãª>SL< X»>+^0à HKLíã?âNõ+L!F=XAOKFIõA;IH$@½XSHKH$Y+@íJ9ã à Hã?àÇ@9HKLî?H$Yê(\QSH$@9Hõ+L!FéX+OKFIõA;IH$@Uâxã?L!^ JQSH ù?ú~ø 7Kù ù[ú p÷~øú zø ù +÷Wê X & ( Ch[8Chp/ & n X6Z lknoChp C<A 2 X6lkpWb Þ HXSHKH$YäJ9ãOpã?õ HNTFIJQä<?;=;+õ ãª@@F=àA;IH³ã?õ+JFIãªX+@UJQ+<WJ³<WLH

õA;é<?>+@FIàA;=H?ê Þ H YSã X+ã?J`<?@@9HKLJíJQA<WJ`<?X ã?õ+JFIãªXâxã?LHPH$OK>SJFIãªX TF=;=;UàH]âxãª;=;IãTUH$Y,ê \QSH]îm<WLRFIãª>+@>+@HKL0F=XJ9H$X¹J@<WLH`@9J9ã?LH$Y ãªX <]àA;é<?O"!»àãª<WLRY JQ+<WJ0F=@/>A@9H$YðJ9ã[LH$Opã?LRYðJ<?@ !P@0<?X+Y @!>Sà+J<?@ !P@J9ã à HOpãª^íõÇ;IHKJ9H$Yê

_ &[8C%&[ X& 2>noC ( C<A 2 X6lkpWb Þ H0^`<$å]<?@@>+^HNJQA<WJ8<í>+@9HKL8F=XJ9HKL!^FIJ9J9H$XJ;IåäJ9HKL!^F=X+<WJ9H/<?OpJF=ãªX+@<?@@9ã»ãªX <?@JQ+H$FIL`<?F=^@ä<?X+Y JQ+H$FILJ<WLè?HKJ@ìQ+<zî?H à HKH$X <?ORQ+FIHKî?H$Yê Ý JråõÇF=OK<?;F=^õA;IH$^íH$XJ<WJFIãªX@>+õ+õ ã?LJâxã?LJQAF=@(õAL!F=X+OKFIõÇ;IH8F=@ULH$<?;=F:9KH$YäJQSLãª>SèªQäJQSHG@>SàA^`FIJàA>SJ9J9ãªX,ê Ý âuJ9HKL8@!>SàA^FIJ9JFéXSè/Y+<WJ<½ã?L<WâxJ9HKLQ+FIJ9JFéXSè0JQSH/@!>SàA^FIJUàA>SJ9J9ãªXìJQSH>+@HKL8@9J<WLJ@<íXSHKT·@OpH$X+<WLRFIã"ã?L8<?XSã?JQSHKL@OpH$X+HG>AX+YSHKL³JQSH<?@@!>+^íõ+JFIãªXìJQA<WJ8JQSH/OK>SLL!H$X¹JFéX¹J9H$XJFIãªX]Q+<?@àHKH$X]<?ORQ+FIHKî?H$Yê


.0/21 ²ª²¹¾ mfoly|f9cRdef qsfhKCc!tslo~j,ltsGWc!delo tEcRd dCv?c!dedeKClc!tsf9NtEc!d dCvmcRjmGcRrtsRqsd

@ 2 n# X6p C%&[8C ( [8Cqp 6& 2 [ X& b Þ H½^<$å]<?@@>A^íH/JQ+<WJ<`>+@9HKL8TFé;=;AJ9HKLR^F=X+<WJ9H/JQ+H0OK>SLLH$XJ8F=XJ9HKL9B<?OpJFIãªX TQSH$XðJQ+H$FIL/TQSãª;=HíJ<?@ !ðQ+<?@/à HKH$X <?ORQ+FIHKî?H$YêáhX <?ORQ+FIHKîPF=XSè[<]J<WL!è?HKJKôk@>+àA@F=Y+Fé<WLå]J<?@ !P@^F=èªQ¹JàHUè?H$XSHKL!<WJ9H$Yê?\HKL!^F=XA<WJFIãªX0F=@àA<?@9H$Y½ãªXJ9HKL!^F=X+<WJF=ãªX0OpãªX+Y+F=JFIãªX+@Kê +ã?LF=X+@9J<?X+OpH?ôJQSH³>+@9HKLã?â<?X Ý \ ^<?O!Q+FéXSH/HPõH$OpJ@JQ+<WJTFIJQìJ9HKL!^F=XA<WJFIãªX]JQSH/àÇ<?X&!]OK<WL!Y F=@8LHKJ>SL!XSH$Y,ê+\8QSHKLHKâxã?LH?ôJQSH>+@9HKLTF=;é;QA<$î?H0JQ+H/OK<WL!Y <WâxJ9HKL8J9HKL!^FéX+<WJFIãªX]ã?âkJQSH Ý \ @OpH$XA<WL!FIãSê

C 2 U[6C CqA 2 KXlDphb ?N@9HKL!@ã?â8< Þ á9M <WLH`L!H$<?OpJF=XSè J9ã @9JF=^½>+;=F ã?L"^íH$@@!<Wè?H$@ã?âJQ+H Þ á9M JQSH>+@HKLUF=@(ã?àA@9HKLîPF=XSèSê <WJQSHKLJQ+<?X`@9õ H$OKFIâxåPF=XSèH$<?O!QLH$<?OpJF=ãªXäF=Xä<0@9HKõÇ<WL!<WJ9H$Y`âxã?L!^6TUHG>+@9H8è?H$X+HKL!F=Oâ>+X+OpJFIãªXA@âxã?LGJQSHí@9õ H$OKFIöAOK<WJFIãªX ã?âJQ+F=@à H$Q+<$îPFIãª>SLzê H$<?OpJFIî?Híà H$Q+<$îPFIãª>SLNOK<?X àH"^íãPYSH$;=;IH$Y ãªXJQSH0àA<?@F=@³ã?âkã?àA@9HKLîW<WJFIãªXPBsL!H$<?OpJFIãªX[õA<?F=L!@Kê

iX # # 2 X>p 2[ X& [ 2 p>Ch[ C<A 2 X6lkpWb \8Q+Hì>A@9HKLíH$X¹J9HKLR@<?X F=XJ9HKL!<?OpJFIãªXTF=JQ JQ+H !»XSãT;IH$YSè?H]ã?âJQSH`J<?@ ! YSHKõ H$X+YSH$XJãªX JQSH`J<WLè?HKJ@0JQA<WJ^½>+@9J/à HY+F=@!O!Q+<WLè?H$Y,ê\8QSHOpãª;=;é<Wàã?LR<WJFIãªXðJ<WLè?HKJ"F=@àA<?@H$Y ãªX <`õ+L!HpBEYSHKJ9HKL!^F=X+H$Y]õA;=<?X]JQA<WJNF=@ !»X+ãzTX F=X[<?YSîW<?X+OpH½J9ã`JQSH½>+@9HKL$êëGX+OpH<`J<WLè?HKJGQ+<?@à HKH$X[<?ORQ+FIHKî?H$Y[JQ+H0>+@9HKL8YSã»H$@8XSã?JH»õ H$OpJ8J9ã`X+HKH$Y]J9ãLHKõ H$<WJ8JQSH/<?OpJF=ãªX+@<Wèª<?F=X,ê

a C ! 2 p 2[ X& X>Z C%&[ 24# 24& ( !cA 0n 24# 2 N[ KX &DnUb Þ QSH$X+HKî?HKL JQSH >+@9HKL Opãª^`^FIJ@ J9ã·J< !PF=XSè <õAQåP@F=OK<?;³<?OpJFIãªXôJQSH$XJQAF=@"<?OpJFIãªX OK<?X+XSã?Jíà HìLHKî?ã!?H$Y <WâxJ9HKL`<ðOpHKLJ<?FéXõãªFéX¹JKêZHKâuã?L!H[YSãªF=XSèJQSH½õAQå»@!F=OK<?;<?OpJF=ãªX JQSH½>A@9HKLGè?H$XSHKL!<WJ9H$@GJQSH"@FIèªX+<?;k@9H$XJGâuLãª^5JQSH½à+L!<?FéX[J9ãìJQSHí^íã?J9ã?L!F=O½@9åP@CBJ9H$^]ê Þ H8@>+õ+õA;IåGJQSH>+@9HKL^íãPYSH$;àå½<Nèª>+<WL!YPBE<?OpJFIãªX"õÇ<?FILk;éF=X&!PF=XSè^íH$XJ<?;P<?OpJFIãªX+@ TF=JQ0õAQåP@F=OK<?;<?OpJFIãªXA@Kê

X X4!k[ X& 2>noC ( UX !$# CW[ X & b Ý >+@HKLä^<zå <Wà ã?LJä< @OpH$X+<WL!FIã TQSH$X JQSHKLH F=@`XSã <Wõ+õA<WLH$XJ<?OpJFIãªXJQSHN>+@9HKL³OK<?XJ< !?HNJQA<WJUTãª>+;=YäQSH$;Iõ`J9ã"Opãª^íõA;=HKJ9HJQSHJ<?@ !êáhâH?êèSêPJQSH>+@HKLUã?â<0L!<?F=;IT³<$åJF=O !?HKJF=XSè@9å»@J9H$^YSã»H$@/XSã?J/öÇX+YðJQSH`<WõAõ+Lã?õ+L!Fé<WJ9Híã?õ+JFIãªXôJQSH$X JQSH`>+@HKL0^FIèªQJèªFIî?Hä>+õ <?X+Y


^F=èªQ¹J"<?@@>+^H`JQ+<WJ½JQSHìF=X¹J9H$XJFIãªX+@½OK<?X+XSã?J½à Hä<?ORQ+FIHKî?H$Yê Þ H]^íãPYSH$;JQ+Fé@0ã?õ+õ ã?LJ>AX+FIJEå à»å <XSãWBsã?õAJFIãªXPBsàA<?@9H$Y <?Y+YSH$X+Y+>A^6JQ+<WJF=@³<?Y+YSH$YìJ9ãH$<?ORQ @OpH$XSHTQSHKLH<í>+@9HKL8^<zå;=H$<$î?H/JQSH/@J9ã?Lå?ê

C'# C %2& UC6b Ý >+@HKLGORQSã»ãª@9H$@G<?X<?OpJF=ãªX ãªXA;Iå?ôF=âJQ+F=@<?OpJF=ãªXð@9HKH$^@NJ9ãäà H½LH$;IHKîW<?X¹JNâxã?LN<?ORQ+FIHKîPF=XSèJQSHOK>SLLH$XJ;IåäOpãªXA@F=YSHKLH$YìJ<WL!è?HKJ@Kê

\8Q+H$@9Hõ+L!FéX+OKFIõA;IH$@ OK<?X0àHU^<Wõ+õ H$YJ9ã Rù Aøú9ù ú ~÷(ã?âSJQ+H(@9J9ã?Lå»à ãª<WL!Yê Sã?L F=X+@J<?X+OpH?ô$è?ãª<?;|BsàA<?@H$Yà H$Q+<$îPFIãª>SLF=@8^<Wõ+õ H$YìJ9ã<?OKOpHKõ+J<?X+OpH"OpãªX+Y+FIJFIãªXA@ã?â@OpH$XSH$@Kê\8QSH/F=XJ9H$X¹JF=ãªX+<?;,XSãªXPBEY+HKJ9HKL!^F=X+Fé@^ F=@LH+H$OpJ9H$Y FéX XSãªXSBEYSHKJ9HKL!^F=XAF=@9JF=O@!OpH$X+<WL!FIãª@Kê \k<?@ !¹Bsã?LRFIH$X¹J9H$YJ9HKLR^F=X+<WJFIãªX F=@"^<Wõ+õ H$Y J9ãðF=X¹îW<WL!F=<?XJ@ãªX @9J9ã?L!F=H$@Kôk@!OpH$XSH$@í<?X+Y@OpH$X+<WL!F=ãª@Kê+8H$<?OpJFIî?H]à H$Q+<zî»FIãª>+L½F=@½LHKõALH$@9H$XJ9H$YJQSLãª>SèªQ JQSHìJ9L!<?X+@!FIJFIãªX+@à HKJETHKH$X @OpH$X+H$@Kê(\8QSH[>A@9HKL^íãzî?H$@äTFIJQ <?X <?OpJFIãªX âxLãª^ ãªXSH[@!OpH$XSH[J9ã JQSH XSH»JKê\ã J9ã @ã JQSH<?OpJFIãªX^>+@JíàHìLH$;=H$<?@9H$Y à»å JQSH @9å»@J9H$^]ê Þ H >+@H[Opãª;=;=<Wà ã?L!<WJFIãªXJ<WLè?HKJ@`âuã?L`JQSH YSHKL!F=îm<WJFIãªXã?â<?OpJFIãªX+@"JQA<WJ^>+@J½à Hìõ HKLâxã?L!^íH$Y àå JQSH]>+@9HKL$ê\8Q+HìX+H$OpH$@@FIJrå ã?âN<?OpJFIãªX+@OK<?Xà H]^íãPYSH$;=;IH$Y ãªXJQSHàA<?@F=@ã?âY+HKãªX¹JF=O;Iã?èªF=OK@<?@YSH$@!OpL!FIà H$Y]F=X]JQSHõ+LHKîPFIãª>+@8ORQ+<Wõ+J9HKL!@$êÇ\8QSHKå]<WLH½^íãPYSH$;=;IH$Y]JQ+Lãª>SèªQ<?OpJFIãªX èª>+<WL!Y+@Kê Ý âxJ9HKL<íJ<WLè?HKJNQ+<?@à HKH$X[<?O!QAFIHKî?H$Y FIJ8Fé@³LH$^íãzî?H$Y âuL!ãª^ JQSH/J<?@ !ìàA;é<?O"!»àãª<WLRYêS\8QSHèª>+<WL!YSBE<?OpJFIãªX õA<?FILR@í;=F=X&!PF=XSè ^íH$XJ<?;8<?X+Y õAQåP@F=OK<?;<?OpJFIãªX+@`<WLH <?;=@9ã >A@9H$Yâuã?L`LHKöAXSH$^íH$XJíã?âGJQSH@9J9ã?Lå»à ãª<WL!YêSã?L/F=X+@9J<?XAOpH?ôÇFIâ<>+@9HKLGF=@X+ã?JLH$<?OpJFéXSèäTFIJQ+F=X[<OpHKLJ<?F=XJF=^H0âxL!<?^íH?ôJQSH$X TH"^<$å<?@@>A^íH0JQ+<WJNJQSH½OK>SLLH$XJèª>+<WLRYPBE<?OpJFIãªXF=@XSã?JNîW<?;=F=Y[<?X+Y JQ+<WJNJQSH>A@9HKLXSHKH$YA@<?OpJFIãªX @>+õ+õ ã?LJã?L<?OpJFIãªXäâuHKH$Y+àA<?O"!ê»\QSHXSãWBsã?õ+JF=ãªXPBsàA<?@9H$Y<?Y+YSH$X+YA>+^&F=@<?YAYSH$Y`J9ãH$<?O!Qì@OpH$XSHN<?@U<½YSHKâ<?>+;IJ<?Y+YAFIJFIãªXêÞ H^<$å`LHKöAXSHNJQ+F=@U<?Y+YSH$X+Y+>A^&à»å`<?OpJFIãªX+@JQ+<WJ³<>A@9HKL>A@9H$@L!<?X+YSãª^;=å"<WâxJ9HKL³à H$Opãª^F=XSè½OpãªXSâx>A@9H$YêÝ õ ãª@@FIàÇ;IHLHKöAXSH$^H$X¹Jã?âJQSH<?YAYSH$X+Y+>+^ F=@8JQ+H½F=XAOpã?Lõ ã?L!<WJFIãªX]ã?â(<`T<?F=Jâ>+X+OpJFIãªX,ê48H$;IHKîW<?X+OpH"F=@< »>+<?;=FIJråäOpL!FIJ9HKLRF=<½TUH0<WõAõA;Iå`Y+>+L!F=XSè"O!QSH$O !ìã?âH$<?ORQ @OpH$XSH?êÇëX+;Iå`L!H$;IHKîm<?XJ8<?OpJFIãªX+@^<$åà HNöALH$Yìàå<>+@HKL$ê

C ! pjCqnoC%&[ 2[ X &SX>Z 0 X6p8[jZX# X>n ã?L!J9âuãª;=F=ãª@8OK<?X]à H@9õ H$OKFIö+H$YìF=X]<í@9H$^FIBsâuã?L!^`<?; T<zå>+@!F=XSè"JQSHâxãª;=;IãzTF=XSè"J9H$^íõA;=<WJ9H?ÿ


1 (!/ %9!/=! "! ÿ )<?OpJ9ã?Lõ ã?LJ9âxãª;=FIãíX+<?^H,+;'9# ÿ )xè?H$XSHKL!<?;YSH$@OpL!FIõAJFIãªX0+

B@ #"! ! ÿ ) NH$XSHKL!<?;O!Q+<WL!<?OpJ9HKLRF=@<WJFIãªX ã?âJ<?@"!»@:+ >0'"/'(6/ #'"0! ÿ )xè?H$XSHKL!<?;YSH$@OpL!FIõAJFIãªX0+

&D ' #69' ÿ )O!Q+<WLR<?OpJ9HKL!F=@<WJFIãªX ã?â JQSH/F=X+FIJFé<?;@J<WJ9H,+;9'/<= #,9'" ÿ )O!Q+<WLR<?OpJ9HKL!F=@<WJFIãªX ã?â JQSHJ<WLè?HKJ@J<WJ9H,+-=/!9 ÿ )xõ+Lã?öA;=HNõALH$@>Sõ+õ ãª@9H$Yâxã?L@9ãª;=>+JFIãªX0+&P#6@/.20D# ÿ );=F=@9J³ã?âF=X+@J9L!>+^íH$XJ@âuã?LN@9ãª;=>SJFIãªXD+ ! ' 5 !"/9'0"! ÿ )@9õ H$OKFIöAOK<WJFIãªXìã?âOpãª;=;é<Wàã?LR<WJFIãªXìLH»>+FILH$Y0+1 . '/ ÿ );=F=@9J³ã?â<?> SF=;=F=<WL!å`OpãªX+Y+FIJF=ãªX+@:+

B9(&. "! ÿ );=F=@9J³ã?â<?OpJFIîPFIJFIH$@Kô+OpãªXJ9Lãª;eôÇY+<WJ<+ #&. ÿ )xöAX+<?;@9J<WJ9H?ô@<WJF=@9öAH$Y]J<WLè?HKJOpãªXAY+FIJFIãªX+@3+

1 (!/D# ,8! 8620 ÿ )xè?H$XSHKL!<?;YSH$@OpL!FIõAJFIãªX0+! ÿ )YSH$@OpL!F=õ+JFIãªXìã?âkLãª;IH,+-'"/= ÿ )xà H$Q+<$îPFIãª>SL!<?;OK<WJ9HKè?ã?LRFIH$@<?XAY[@9J9HKLHKã?Jråõ H$@:+

! ' 5 !/'"0! ÿ )xè?H$XSHKL!<?;YSH$@OpL!FIõAJFIãªX0+ !62=2.=D=('0! ÿ )xõ+Lã?J9ãPOpãª;=@8<?X+Y[HPORQ+<?XSè?H,+ !=!/=C &0'" "! ÿ )OpãªX¹J9LR<?OpJ@<?X+Y[H$XSâuã?LROpH$^íH$X¹J:+ !=!%9/'"0! ÿ ) +ãzT ã?âTã?L"!9+

#,=/0@( "!P# ÿ )xè?H$XSHKL!<?;YSH$@OpL!FIõAJFIãªX0+1 (!"/ /9#6@/0=(60! # ÿ )xè?H$XSHKL!<?;YSH$@OpL!FIõAJFIãªX0+B"806/!2D ÿ )xè?H$XSHKL!<?;YSH$@OpL!FIõAJFIãªX0+

F'9#@C 4 ÿ ) \YST W:IK:T3K:+F'9#@C 4 ÿ ) SYVDG T3V0GSUZ6V K:+F'9#@C 4 ÿ )U[=T3V0T:I\ GJIKML=K NDIQ=R@SUT3V W3T&N X*SYKKS Z6VPN@[=ZI\ +

0 X>pj[8ZX # X iX&[jC ! [ Zå HPõA;=F=OKF=Jä@9õ H$OKFIöAOK<WJF=ãªX ã?â/JQ+H ùWú~ø 7Kù ù !ù Aø ¹øTHðQ+<$î?Hð<O!QA<?X+OpHJ9ãðOpã?õ HTFIJQ CHKLLã?L!@" < >+@9HKLíOK<?X ^< !?H?ê\UåõÇF=OK<?;HP<?^íõÇ;IH$@"<WLHìJQSH]>+X+XSH$OpH$@@!<WLåL!HKõHKJF=JFIãªX ã?â<?X<?OpJFIãªXôN;>+^íõÇF=XSè"àA<?O"! àåìJQSH½>+@F=XSèíJQ+H0àA<?O !]àA>SJ9J9ãªX ã?âkJQ+H0à+LãT@9HKL$ôÇLHKî?HKL!@FéXSèJQSHã?L!YSHKLã?â<?OpJFIãªX+@$ômãª^`FIJ9JF=XSèGã?LYSH$;=<zå»FéXSèN<?OpJF=ãªX+@KôWLHKõA;=<?OKFéXSèãªX+H³<?OpJF=ãªXíàå½<?XSã?JQSHKL$ôWHPH$OK>SJF=XSè<?Xí<?Y+YAFIJFIãªX+<?;<?OpJFIãªXJQ+<WJGF=@NXSã?JL!H>+F=LH$Y[ã?LG>+XSLH$;é<WJ9H$Y J9ãJQSH"OK>SLLH$XJJ<WLè?HKJ@$ê Ý @NFIJFé@F=X+âuH$<?@F=àA;IHJ9ã]@>Sõ+õ ã?LJ>+@9HKLR@8F=X]<$î?ãªFéY+F=XSè<?;=; JQ+H$@9H CHKLLã?LR@"Pô+TH0@9õ H$OKFIâxå`JQSH/OpãªXJ9H»JJ9ã?è?HKJQSHKLNTFIJQìJQSH/õ ã?LJ9âxãª;=FIãSê

\8Q+HOpãªXJ9H»J/F=@>+@9H$Y âuã?LNJQSH"YSHKî?H$;Iã?õA^H$X¹JNã?âõ+LãPY+>+OpJF=ãªX[L!>+;=H$@8âxã?L Þ á9M F=^íõÇ;IH$^íH$XJ<WJFIãªXê ÝJEå»õAF=OK<?;;=F=@9J>+@9H$Y F=X]@9ãª^íHã?â ãª>SL8õALã];CH$OpJ@OpãªX+@F=@J@³ã?ârÿ l # Cqn ZX6p $# 2 # X42 p ( UX&[8p]X#Pb \QSH@OpH$X+<WL!F=ã8F=@Opãª^íõA;IHKJ9H$Y/TQSH$XSHKî?HKL,JQ+HàA;=<?O !à ãª<WL!YGã?âPJ<?@ !P@

à H$Opãª^íH$@H$^íõ+JEå?êÇ\8QSH/@OpH$XSHY+<WJ<^<zåà H/;Iã?è?è?H$Y ã?L8LH$^íãî?H$Yê l # Cqn ZX6p 6&kZX6p "2[ X& X& 2 N[ X &DnNb Ý OpJFIãªX+@/JQ+<WJ0<WLHXSã?J/FéX+FIJF=<WJ9H$Yà»å JQSH>A@9HKLàA>SJ<WLHã?â

F=XJ9HKLH$@9JJ9ã`Q+F=^mQ+HKL8XSHKH$Y]J9ãà HLHKõ ã?LJ9H$YìJ9ãJQ+H0>+@9HKL$ê l # Cqn ZX6p WX&[8p]X#cX pjC'! X>pj[6& 0b ?N@9HKL!@XSHKH$Y < OK;IH$<WL`F=XAY+F=OK<WJFIãªXôFIâJQSH]ã?L!YSHKL`ã?âG<?OpJF=ãªX+@

JQ+<WJOK<?X[à H/F=X+FIJFé<WJ9H$YìàåìJQSH0>A@9HKLF=@XSã?J<WLàAFIJ9L!<WL!å?ê Sã?LHS<?^íõA;=H?ô+<Opãª^^íãªX õ+L!<?OpJF=OpH0Fé@JQSH>SJFé;=F:9$<WJFIãªX`ã?â<XSHPJ»àÇ>SJ9J9ãªXê»árâ,JQ+HN>+@HKL³Y+ãH$@³XSã?J$!PXSãzTßTQ+<WJJQ+<WJ^íH$<?X+@JQSH$Xì@mQ+HGFé@U;IHKâxJF=X]OpãªX+âx>+@!FIãªXê

l # Cqn ZX6p WX&[8p]X#cXK[jA 6& n UC%& 2 p X>nNb Ý ;IJQ+ãª>SèªQ]<>+@9HKLOK<?X[O!QSã»ãª@9H0<?^ãªXSè`@9HKî?HKL!<?;ã?õSBJFIãªXA@âuã?L<?OpJFIãªX+@8TH0XSHKH$Y[J9ã`H$X+@>+LHGJQ+<WJ8ã?õ+JFIãªXA@8<WLH0X+<WL!LãzTH$Y YSãTX]J9ãJQ+ãª@9H/JQ+<WJ;=H$<?Y]J9ã^íH$<?XAF=XSè?â>+; @9J9ã?L!FIH$@Kê M»ãSôSã?õ+JFIãªX+@8JQ+<WJ<WLH0<zîm<?Fé;=<WàA;IHGJ9ãJQSH>+@9HKL<WLHL!H$Y+>+OpH$Y[<WJ8LR>+XPBsJF=^íH?ê

qEc!~8c!tsloCd,!yÇ$tsRqegz?~c!qElojy|!q´½fCNwujyµRqs8c!tsloRj/$gzdtsfCd wmidscRRfjWc!gdelod §

C +&DC% C'&[ X6Z ZC 2 n8Chn L!ã?öA;IH$@(<?XAYõ ã?LJ9âxãª;=FIãª@<WLHG>+@9H$Y`âuã?LUJQSHL!HKöAXSH$^íH$XJ(ã?â,;=F=âuHOK<?@H$@KêM»ã/â<WL$ô»;=FIâxH8OK<?@9H$@³<WLH@9õ H$OKFIöAH$Yíàåí<0è?H$XSHKL!<?;O!Q+<WL!<?OpJ9HKLRF=@<WJFIãªXôJQSH;éFIâuH8OK<?@H +ãT/ô¹öAèª>SLH$@Kô¹OpãªXJ9HPJKô<?X+Y LH>AFILH$^íH$XJ@Kê Þ FIJQ JQSHä<zîm<?F=;é<WàAF=;=FIJrå ã?âJQ+Hä>+@9HKL"^íãPYSH$;eô,FeêH?êJQSHõ+Lã?öA;IH$@0<?X+Y õ ã?LJ9âxãª;=FIã[ã?â>+@9HKLR@8<?X+Y]<?OpJ9ã?L!@KôÇTUH^<$åìHPJ9H$X+Y]JQSH0;éFIâuHOK<?@9H@9õ H$OKFIöAOK<WJFIãªXìà»åÇÿ

@ 2 n# n 2>nonoX 2[8C'( K[jA []ADC# ZPC2>noC>b %FIâxH"OK<?@H$@<WLHX+ã?L!^<?;=;IåXSã?JL!<?F=@H$YðF=XðF=@9ãª;=<WJF=ãªXôàA>SJ<WLH<?@@9ãPOKF=<WJ9H$Y TFIJQðJ<?@"!»@JQ+<WJ"Opã?LLH$@9õ ãªX+YðJ9ãõ+Lã?àÇ;IH$^@/<?X <?OpJ9ã?LíF=X¹J9H$XAY+@J9ã @9ãª;Iî?H?ê\QSH$@9HJ<?@ !P@]Q+<zî?H JQSH$FILãzTX·Y+HKõH$XAYSH$X+OKFIH$@Kê8M»ãSô³TH OK<?X·<?@!@9ã»OKFé<WJ9HðTFIJQ¿< ;=FIâxH OK<?@9Hðã?JQSHKL[Opã?L!LHpB@9õ ãªX+YAF=XSè;éFIâuHNOK<?@9H$@Kê+\8QAF=@U<?@!@9ã»OKFé<WJFIãªX]F=@³^<?F=X+;=å>+@9H$Yâuã?L8<?XHPJ9H$X+@FIãªXìã?âJQSH;=FIâxHNOK<?@HG>AX+YSHKLOpãªX+@!F=YSHKL!<WJFIãªX,ê

_ & 6X #6C% C%&[ X>Z X [jAkChp 2 N[jX>p]n 24& ( UX #6#824 X>p 2[ X& K[jAS[jAkC' b \QSH ;=F=âuH OK<?@9H +ãT F=@ LHpBöAX+H$Yà»å0JQ+H8Opãã?õ HKL!<WJFIãªXí@õH$OKF=öAOK<WJFIãªX½ã?â<?;é;»Opãª;é;=<Wà ã?L!<WJF=XSèG<?OpJ9ã?L!@Kê¹\QSHFéX¹î?ãª;Iî?H$^H$X¹JF=XAOK;=>+YSH$@Lãª;=H$@KôAL!F=èªQ¹J@Kô<?X+Y ã?àA;=FIèª<WJFIãªXA@Kê4(<?ORQ <?OpJ9ã?L!@GõA;=<zå»@<äOpHKLJ<?FéX õA<WL!JJQ+<WJGF=@LH$@9J9L!F=OpJ9H$Y à»å]JF=^íH?ôY+<WJ<PôAõ+LãPOpH$@@9H$@KôA<?XAY[@9õ H$OKFIöAONLH$@9J9LRF=OpJFIãªX+@³ã?â JQSHõ ã?LJ9âxãª;=FIãSê

Chn4[jp N[ X &Dn ( lkC [jX [jAkC ! pjX$# Cqn X6Z ! 2 p8[ 8 8! 2[6& 2 U[8X>p]nNb DG>SH"J9ãìJQSH"õ+Lã?öA;IH$@ã?âU<?OpJ9ã?LR@;=F=âuHìOK<?@9H$@í<WLH]HPJ9H$X+YSH$Y F=X ã?L!YSHKLíJ9ãð@>+õ+õ ã?LJ0JQSH$F=L"@õH$OKF=öAO`L!H>+F=LH$^íH$XJ@Kêk\QSHäõ HKL!@ãªX+<?;=FIJråõ+L!ã?öA;IH$@/<WLHì>+@9H$Y âuã?L½JQSH`è?H$X+HKL!<WJFIãªX ã?âLH>AFILH$^íH$XJ@0<?OKOpã?L!YAF=XSè[J9ãJQSHä<WJ^ãª@9õAQSHKLHäã?âJQSHÞ á9M êÇM»H$OK>SL!FIJråäõALã?öA;IH$@³LH$@J9L!F=OpJJQSH0FéX¹î?ãª;Iî?H$^H$X¹J8ã?â <?OpJ9ã?L!@Kê

iX &[8C ! [ n ! C 82# n 2 [ X& b \8QSHè?H$XSHKL!<?;OpãªXJ9H»J@9õ H$OKFIöAH$Y âxã?L< ;=FIâxHäOK<?@9H]OK<?Xà H<?YA<Wõ+J9H$Y <?O~BOpã?L!YAF=XSèíJ9ãJQSHõ ã?LJ9âxãª;=FIãí<?X+Y[JQSH/õ+Lã?öÇ;IH$@ã?âkõÇ<WLJF=OKFIõA<WJFéXSèí<?OpJ9ã?L!@Kê

ý \QSH;=F=âuH0OK<?@Hú ùRý?ø ù OK<?X à HLHKöAXSH$Y >+@F=XSèä<`õ ã?LJ9âxãª;=FIãJQA<WJNF=@@9õ H$OKFIöAO0âuã?LNJQSH@9J<WJ9H MPORQ+;IH$@9TFIèWB ãª;é@9J9H$F=X ã?Líâuã?L< OKFIJrå @>AO!Q<?@ ã?J9J9àA>+@$êkáhâJQ+HKLH]<WLH]<?@@9ãPOKF=<WJ9H$Y ;=FIâxHäOK<?@H$@íã?L@9õ H$OKF=<?; OK<?@9H$@KôAJQSH$X]<?XSã?JQSHKL8@9HKJã?âkJ<?@ !P@8F=@L!<?F=@H$Y]<?X+YìJQSHF=@@>+HKL³Fé@@9H$X+YJ9ã<íX>A^0à HKL³ã?âã äOpH$@Kê\8QSH OKFIJEå F=X+âuã?L!^`<WJFIãªX @9åP@9J9H$^ ã?â ³ã?J9J9àA>+@`@!>Sõ+õ ã?LJ@í@>+ORQ;éFIâuH[OK<?@H$@Kô(H?êèSêJQSH ãªX+H YSHKõAFéOpJ9H$Y F=X FIèª>SLH »êáhX JQ+Fé@OK<?@9H?ôJQSH;éFIâuHíOK<?@9H 3T3\UZW:IGSUZ6V F=@HPJ9H$X+YSH$Y àå <?;=;FIJ@/<?@!@9ã»OKFé<WJ9H$Y ;=FIâxHíOK<?@9H$@KêáCXã?J9J9àA>A@ãªXSH"<Wè?H$X+OpåF=@Q+<?XAY+;=F=XSè<?;é;J<?@ !P@Nâuã?LNJQSH"F=@@>+HKL$êM»ãSôJQSHFé@@>SHKLN>+@9H$@JQSH½Opãª;é;=<Wà ã?L!<WJFIãªXTFIJQJQSHOKF=JEå F=X+Q+<WàAF=J<?X¹J@<Wè?H$X+Opå?êáhX JQSHíàÇ<?O"!»è?Lãª>+X+YðJQAF=@G<Wè?H$X+OpåðOpãª;=;=<Wà ã?L!<WJ9H$@TF=JQ<?;é; ã?JQSHKL<Wè?H$X+OKFIH$@<?X+Y]LH$OKF=õAFIH$XJ@Kê

\8Q+H;=FIâxH"OK<?@H[ú ù !ý?ø ù OK<?Xðà HíL!<?F=@H$Y àåð<?XåOKFIJF!9KH$XêkM»ãSôJQSH`õ+Lã?öA;IH$@<WL!HíL!<WJQSHKL0è?H$X+HKL!<?;eêÞ H/OK<?X+XSã?J³HPõ H$OpJJQ+<WJ<?X]F=@@>SHKL³Q+<?@<"@9õ H$OKFIöAOH$Y+>+OK<WJF=ãªXäõALã?öA;IH?ô»àA>SJTUH/^`<$å`HPõ H$OpJ³JQ+<WJJQSHF=@@!>SHKLQ+<?@N<õ HKL!@9ãªXA<?;=FIJEåìõ+L!ã?öA;IH?ê+\8Q+Fé@8OK<?XàH>+@9H$Y[âxã?LNJQSH;=F=âuH/OK<?@9H +ãT/ôAH?êèSêâuã?LGO!Q+H$O"!PF=XSèö+L!@9JJQSH/HSF=@9J9H$XAOpHã?â Y+ã»OK>+^H$X¹J@JQA<WJ<WLH0XSH$OpH$@!@<WLå]<?X+YìJQSH$X]LR<?F=@F=XSè"JQSH0àA<?@F=OGO!QA<?XSè?H$@Kê

\8QAF=@³LHKöAXSH$^H$X¹Jã?â ;=FIâxHOK<?@9H$@Fé@³LH+H$OpJ9H$Y FéX]<?X]H»J9H$XA@FIãªX]ã?â JQSH/;=F=âuHOK<?@9HJ9H$^íõA;=<WJ9H?ÿ

= ('# ÿ );=FIâxH/OK<?@9H0X+<?^íH,+;'9# P# ÿ );=F=@9Jã?âkJ<?@ !P@<?@@9ãPOKF=<WJ9H$Y TFIJQìJQSH0;éFIâuHOK<?@9H,+1 (!/D# ,8! 8620 ÿ )YSH$@OpL!FIõAJFIãªXìã?â<?OpJ9ã?L!@F=Xî?ãª;Iî?H$^íH$XJ:+-@/! /9#6@/0=(60! # ÿ );=F=@9Jã?âkLH$@9J9L!FéOpJFIãªX+@8Y+>+HNJ9ãä<?OpJ9ã?L!@õALã?öA;IH,+ ! #&%99(@' #'"0! ÿ )OpãªX¹J9HPJH$^à H$Y+Y+F=X+è@+

HKöAXSH$^íH$XJã?â;=FIâxHOK<?@9H$@Gõ HKL!^`FIJ@8J9ã]YSHKL!F=î?HLH»>+FIL!H$^íH$X¹J@âxã?LNJQ+H Þ á9M YSHKî?H$;=ã?õA^íH$XJKê \QSH$@9HLH»>+FILH$^H$X¹J@G@>SõAõã?L!J8JQSHíYSH$@FIèªX+HKLà»å õ+L!ãzîPF=Y+F=XSèä<?XðF=XSõA>SJF=XSâxã?L!^<WJFIãªX J9ã]@ !?HKJO!QðJQ+H"Y+HKJ<?F=;IH$YOpãªXJ9H$X¹JN@9J9L!>+OpJ>SL!H?ô+JQSH0F=XJ9HKLâ<?OpH/âxL!<?^íH$@8<?X+Y[è?L!F=Y+@Kô+<?XAY]JQSH0^<?FéXìâx>+XAOpJFIãªX+<?;=FIJrå?ê ãªXJ9H$X¹JNYSHKî?H$;|Bã?õ HKL!@NF=X[J>SLRX OK<?X YSHKöAXSHJQSH"^<?F=X OpãªXJ9H$XJGY+H$^<?X+YXSHKH$YSH$Y âuã?LNJQSH Þ áMê \8QSHFéXSâuã?LR^<WJFIãªX]THèª<?F=X TF=;=; F=^íõÇ<?OpJ8ãªX[JQSH½OpãªX¹J9H$XJNJQSH Þ á9M[F=@è?ãªF=XSèäJ9ã`õ+L!ãzîPF=YSH?ôSJQSH½@9J9L!>+OpJ>SLRF=XSè"ã?âJQ+F=@8OpãªXJ9H$XJKôJQSHì<?OKOpH$@@íõA<WJQA@J9ã OpãªXJ9H$X¹JKôJQ+HX+<zî»F=èª<WJFIãªXôkJQSHìõ+LH$@9H$XJ<WJFIãªXôkJQSH]>+@9HKL½ã?õ HKL!<WJFIãªXôkJQSH Þ áM


ã?õ HKL!<WJFIãªXôS<?X+YJQSH/FéX¹J9HKL!<?OpJF=ãªXê&+>SLJQSHKLR^íã?LH?ôPJQSH$@9H/;=F=âuHGOK<?@9H$@8^<zåäà HG>+@9H$Y]<?@<"L!FéO!Qì@9ãª>SL!OpHGâxã?L>+@<WàÇF=;=FIJråHKîW<?;=>+<WJFIãªX,ê Þ HN^`<$å<?;=@9ã½>+@9HJQSH$@9HL!HKöAXSH$^íH$XJ@âxã?LYAF=@OK>+@@!F=XSèXSãªXPBsâ>+X+OpJFIãªXA<?;SLH»>+FILHpB^íH$XJ@Kô+TQAF=O!Q]<WLH>+@>+<?;=;=åH»õALH$@@9H$Y]ãªX[JQSH/àA<?@Fé@³ã?âk>+@HKL8H»õ H$OpJ<WJFIãªXA@Kê

\8Q+H<?OpJ9ã?LGõ+Lã?öA;=H/<?X+Y JQ+H<?OpJ9ã?LGõ ã?LJ9âuãª;éFIã`<WLH½<?;=@9ãä>A@9H$Y[âxã?LJQ+HYSHKL!F=îm<WJFIãªX ã?âLH»>+FILH$^íH$XJ@J9ãJQSH Þ áMê

^ X>p # n ! 2 UC6b Ý OpJ9ã?LR@XSHKH$YJQ+H$FILãzTX0TUã?L !»@9õÇ<?OpH(F=XGã?L!YSHKLJ9ãOpãª^íõA;IHKJ9HJQ+H$FILJ<?@ !P@Kêz\8Q+Fé@ TUã?L"!P@9õA<?OpH^<zå[à H0õ+L!ãzîPF=YSH$Y[J9H$^õã?LR<WL!F=;Iå?ôOK<?X à H/õÇ<WLJF=<?;=;Iå]<WL!ORQ+FIî?H$Yô <?X+YOK<?XàH½>+@9H$Y âuã?LGã?JQSHKLNJ<?@ !P@F=X JQSH½õã?L!J9âuãª;=F=ãã?âJQSH"<?OpJ9ã?L$êDHKõ H$X+YAF=XSèãªX JQSH"F=X¹î?ãª;=î?H$^íH$X¹JNã?â<?OpJ9ã?L!@GTQ+ãäOpãª;=;=<Wà ã?L!<WJ9HJ9ã@9ãª;=î?H0<íJ<?@ !ìJQSHTã?L"!P@9õA<?OpH0OK<?X <?;=@9ãíà H/<?OKOpH$@@FIàÇ;IHJ9ãã?JQSHKLN<?OpJ9ã?L!@Kê

a ChnonKX & n8l ! ! X6p8[Ub Ý OpJ9ã?L!@ <WLH@>Sõ+õ ã?LJ9H$Y0àå/@9H$@!@FIãªXPBEYSHKöÇXSH$Y0^íH$YAF=<ã?à<;9H$OpJ@KôWFeêH?êmOpHKL!J<?F=XOpãªXJ9H$XJ<?X+Y`âx>AX+OpJFIãªX+<?;=F=JEå"<?@(YSHKöAX+H$Y;=<WJ9HKL³F=XíõA<WLJ(ááá~êª\8QSH$@9H^H$Y+F=<ã?à<;9H$OpJ@<WLHè?H$XSHKLR<WJ9H$Y`TQ+H$XSHKî?HKLJ<?@ !P@<WL!H0@9J<WLJ9H$YôÇ<?X+Y[^<zåà H<?Y+<Wõ+J9H$Y J9ãJQSHõ+L!ã?öA;IHGã?â JQSH0<?OpJ9ã?L!@Kê

iX # # 2 X>p 2[ X& 6&DZPp12 no[8p]l N[jlkp]C>b ãª;=;é<Wàã?LR<WJFIãªX F=@ àA<?@9H$Y ãªX Opãª^^½>+X+FéOK<WJFIãªXôOpã»ã?L!Y+FéX+<WJFIãªXô<?X+YOpã»ã?õ HKL!<WJFIãªXã?âF=Xî?ãª;Iî?H$Y <?OpJ9ã?L!@$êáhX ã?L!YSHKLíJ9ãð@>SõAõã?L!JOpãª;=;=<Wà ã?L!<WJF=ãªX <?X F=X+âuL!<?@J9L!>+OpJ>SLHF=@½LH»>+FIL!H$Y JQA<WJF=@½H»J9H$X+Y+H$Yã?L`@QSL!FéX&!?H$Y TQSH$XXSHKT J<?@ !P@<WLH[@9J<WLJ9H$Yã?L`J<?@ !»@í<WL!H[Opãª^"BõA;=HKJ9H$Yê

ý ,ß\8Q+H8TUã?L !»@9õÇ<?OpH$@âxã?L(JQSHN;=FIâxH8OK<?@9H 3T3\ ZW:IGSUZ6V`YSHKõAF=OpJ9H$YäF=X FIèª>SLH 0<WLHYAFHKL!H$X¹Jâxã?LJQSH½<?OpJ9ã?L!@Kê \8QSH0F=@!@>SHKLY+ãH$@XSã?JXSHKH$Y<?Xå]TUã?L"!P@9õA<?OpH?ê\8QSH½<Wè?H$X+Opå <?OpJ9ã?L!@GQ+<zî?H½<`TUã?L"!P@9õA<?OpH½F=XTQ+FéO!Q`<X>A^0à HKLã?âJ<?@ !P@³^<$åíà H8àÇ>+X+Y+;IH$Y,êW\QSH$FIL(Tã?L"!P@9õA<?OpHNOK<?X`à Hã?L!èª<?X+F:9KH$Y`<?@<àA;=<?O"!»à ãª<WL!Yê\8QSHN<?OpJ9ã?L8@>Sõ+õ ã?LJFéXSè/Y+<WJ<õ+Lã?J9H$OpJFIãªXì^<zå`>+@9HG<Opãª^õA;IHKJ9H$;IåY+F HKLH$XJ(Tã?L"!P@9õA<?OpHNJQ+<WJF=@àÇ<?@9H$YãªX ^ãªX+FIJ9ã?L8J9H$ORQ+X+F »>SH$@KêA\QSH/F=@@>+HKLF=@8@>+õ+õ ã?LJ9H$Yìàå]@9H$@!@FIãªX]ã?à<;9H$OpJ@JQ+<WJ8õ HKL!@F=@J³>AX¹JF=;<?;=; J<?@ !P@ã?âJQSH";=FIâxH0OK<?@9Hí<WLHíOpãª^íõÇ;IHKJ9H$Yê ?@FéXSè`JQ+Fé@@9H$@@!FIãªX @!>Sõ+õ ã?LJ8JQSH"F=@@!>SHKLNOK<?XLH$@!>+^íH0JQ+HJ<?@ !P@G<WJ<?XåJFé^íH?ô,H?êèSêà»å õ+Lãî»F=YAF=XSè]XSHKT6Y+<WJ<Pêk\8QSH<?OpJ9ã?L!@ã?â³JQSH`<Wè?H$X+OKF=H$@Opãª;=;é<Wàã?LR<WJ9H`F=Xð<?OKOpã?L!Y+<?XAOpHTFIJQìJQ+H0;IHKèª<?;LH$@J9L!F=OpJFIãªX+@<?XAY]LHKèª>+;=<WJF=ãªX+@Kê

SÖ +×ßÜEÕ Ö?ÜEØÕ Ø - äØÕÖ Ö

\k< !»F=X+èJQSHGOpãª^^íãªXA;Iå<?OKOpHKõ+J9H$Y]^íH$<?X+FéXSè<"OpãªXJ9H»JO!QA<WL!<?OpJ9HKL!F=@9H$@³JQ+HN@F=J>+<WJFIãªXF=X`TQ+F=O!Qä<">+@9HKLöAX+YA@Q+F=^mQSHKLR@9H$;IâU<WJ½<[OpHKLJ<?F=X JF=^íH`FéX <]õA<WLJFéOK>+;=<WL/;IãPOK<WJFIãªXê,áCXðJQ+Fé@/@9H$X+@9HäOpãªX¹J9HPJ½Fé@/>+@>+<?;é;IåYSHKöAX+H$YðãªX+;Iå @9J<WJF=OK<?;=;=å LHKâxHKLL!FéXSèìJ9ã JQSHÒpãªXJ9H$XJã?â<[Y+<WJ<WàÇ<?@9H?ê ëGXA;Iå î?HKLå âxHKT3<WJ9J9H$^íõAJ@Q+<zî?Hà HKH$X[^<?YSH/@ãâx<WLJ9ãÒpãªX+@F=Y+HKL8OpãªX¹J9HPJã?â@OpH$X+<WLRFIãª@ã?L@9J9ã?LRFIH$@Kê

ã?LHè?H$XSHKLR<?;=;Iå?ôTHÒpãªX+@F=Y+HKL/OpãªX¹J9HPJ<?@HKî?HKL!åJQ+FéXSè]JQ+<WJ0@>+LLãª>+X+YA@<]>SJFé;=F=@<WJFIãªX @F=J>+<WJFIãªXã?â³< Þ áM àå <]>+@9HKL/<?XAYðOK<?X JQSLãzT3;=FIèªQJNãªXðF=J@^íH$<?X+F=XSèSê,\QSHKLHKâxã?LH?ôOpãªX¹J9HPJF=@GORQ+<WL!<?OpJ9HKL!F=@H$Yà»åF=X¹J9HKL!LH$;=<WJ9H$YOpãªX+Y+FIJFIãªXA@âuã?LJQSHNHPFé@9J9H$X+OpH<?XAY`ãPOKOK>SLLH$XAOpHã?â,JQSHN>SJF=;=Fé@<WJFIãªX@F=J>+<WJFIãªX`@!>+O!Q<?@JQSHíHPJ9HKL!X+<?;H$XîPFILãªX+^íH$XJKô JQSHF=XJ9HKL!X+<?;@9J<WJ9H?ô;Iã»OK<WJF=ãªXôJF=^íH?ô,Q+Fé@9J9ã?Lå?ô HKJOWê Sã?L Þ áMP@GTHXSHKH$YJ9ãQ+<?X+YA;IHJQ+HG^H$X¹J<?;OpãªXJ9H»JJQ+<WJ8F=@àA<?@9H$YìãªXìJQSHõALã?öA;IHã?âJQSH<?OpJ9ã?L8ã?L>+@9HKL$ô»JQSH/@9J9ã?Lå»à ãª<WL!YOpãªXJ9H»J/JQA<WJ/F=@GàA<?@9H$Y ãªX JQSH@J9ã?Lå ;IH$<?YAF=XSèJ9ã[<]@FIJ>+<WJFIãªX,ôJQ+H"YA<WJ<]OpãªX¹J9HPJ0JQ+<WJ/Fé@àÇ<?@9H$Y ãªXJQSH[<zîm<?F=;é<WàA;IH]Y+<WJ<PôJQSH[@J< !?H$QSãª;=YSHKLÒpãªXJ9HPJKô<?X+YJQ+H[Opãª;=;=<Wà ã?L!<WJFIãªX OpãªXJ9H»JKê\8QSH$@9H]Y+F HKLH$XJ!PF=X+Y+@ã?âUOpãªX¹J9HPJ@Q+<$î?Hí<?XF=X&A>+H$X+OpH/ãªX JQSH½Y+HKî?H$;Iã?õA^íH$XJã?âJQ+H½@9J9ã?L!åà ãª<WL!Y <?X+Y ^½>+@9JNJQ»>+@à HOpãªX+@FéYSHKLH$Yìâxã?L8JQSH0YSHKî?H$;=ã?õA^íH$XJ8ã?âJQ+H Þ áMê

ý %,HKJ8>A@OpãªX+@F=YSHKL<"J9L!<zî?H$;F=X+âuã?L!^`<WJFIãªXì@9å»@J9H$^]êSárJ8Fé@Uã?âxJ9H$X[YSH$@!FIL!<WàA;IHNJ9ãLH$@ãª;Iî?HJQSHOpãªXJ9H»J/ã?âU>SJ9J9HKL!<?X+OpH$@Kê Þ Q+F=;=Hà ã»ã!»F=X+èä<?Xð<?FIL!;éF=XSH/JF=O !?HKJJ9ã Z6VPRZ6V JQ+H½>+@HKLG^`<$åàH"<?@ !?H$Y âxã?LJQSH8<?FIL!õã?L!J OpãPYSH?ôªâxã?LTQ+FéO!Qí@mQSH8QA<?@</O!Q+ãªF=OpH8à HKJETHKH$X % Þ æ %ãªX+YSãªX G<WJrTF=O !SçRô% æ %,ãªXAYSãªXH$<WJ9LãzTNçRô %kë æ<?;é; %,ãªXAYSãªX <?FILõ ã?LJ@0F=X ?:½çRô MP\ æ %ãªX+YSãªX M»J<?XA@9J9H$YÇçRô<?XAY# ?-æ %,ãªXAYSãªXô

qEc!~8c!tsloCd,!yÇ$tsRqegz?~c!qElojy|!q´½fCNwujyµRqs8c!tsloRj/$gzdtsfCd wmidscRRfjWc!gdelod $ëGXJ<WL!FIãSô ³<?X+<?Y+<¹çRê \8QSH½OpãªX¹J9HPJã?âJQSH½J9L!<zî?H$; LH>+H$@9JNOK<?Xà H>A@9H$Y J9ãHSOK;=>+YSH½JQSH";=<?@9Jã?õAJFIãªXê\8QSH/OpãªXJ9HPJã?â JQSH0<?FILR;=F=XSHG>+@9H$Y[@ãíâx<WLNOK<?X]à H/>+@9H$Y]J9ãHSOK;=>+Y+HJETã`ã?â JQSHã?JQSHKL!@$êA\8Q+F=@OpãªXJ9HPJF=X];9H$OpJFIãªX]F=@8àA<?@9H$Y]ãªX]JQ+H/@9J9ã?LåìH$X¹îPFILãªXA^íH$X¹J8<?XAY]ãªX[OpãªXJ9H$X¹JNY+<WJ<Pê

iX &[8C ! [ a ! 2 UC Þ QSH$XYSHKJ9HKL!^`F=X+F=XSè/OpãªXJ9HPJTH<?;=LH$<?YSå !PXSãzT¿JQSH^`<j;Cã?L³;=FIâxHOK<?@9H$@THTãª>+;=Y;=F !?H½J9ã]@>Sõ+õ ã?LJKôÇJQSHíF=XJ9H$X¹JFIãªXA@N<?@!@9ã»OKFé<WJ9H$Y TFIJQ JQSH Þ áMô JQSHí>+@9HKLG<?X+Y <?OpJ9ã?L0O!QA<WL!<?OpJ9HKL!F=@<WJF=ãªXãªX JQSHàA<?@F=@ã?âõ+L!ã?öA;IH$@0<?XAY õ ã?LJ9âxãª;=FIãª@$ô<?X+Y JQSHJ9H$O!Q+X+FéOK<?;UH$XîPFILãªX+^íH$XJ½TUHì<WLHìè?ãªF=XSèJ9ãð>+@9H?ê\8QSH$@HLH$@9J9L!F=OpJF=ãªX+@³H$X+<WàA;IH/<`^íã?LHLHKöAX+H$Y[>+X+YSHKLR@9J<?X+Y+F=X+è0ã?âOpãªX¹J9HPJTFIJQ+F=Xì< Þ á9M ê

\8Q+HUTã?L"!FéXïzóAORQ+<WL!<?OpJ9HKL!F=@H$@< Þ áMàå0@!F F=XJ9HKLJETF=XSH$Y½Y+F=^íH$X+@!FIãªX+@Kô$ãªX+Hã?âÇTQ+F=ORQFé@kOpãªXJ9HPJKêÞ H0XSãT LH$;=<WJ9H/OpãªXJ9HPJJ9ãJQSHã?JQ+HKLY+F=^íH$XA@FIãªX+@KôPFeêH?êSJ9ãíJQSH/FéX¹J9H$XJFIãªX+@KôSJQ+H/>+@<Wè?H?ô+JQSH/OpãªXJ9H$XJKôJQSHâ>+X+OpJFIãªXA<?;=FIJEå?ôW<?X+Y"JQSHõALH$@9H$XJ<WJFIãªXê Ý @ õ+LH$@9H$XJ<WJFIãªXíLH$@!F=YSH$@kãªXí<;IãzTHKL(;IHKî?H$;Pã?â <WàA@9J9LR<?OpJFIãªXôFIJ½YSãH$@"XSã?J"Q+<zî?Hì<?X F=^íõÇ<?OpJãªX OpãªX¹J9HPJKêãªXJ9H$X¹Jí<?X+Y â>+X+OpJFIãªX+<?;éFIJEå TF=;é;à H>+@H$Y âxã?L½OpãªXJ9HPJLHKöAX+H$^íH$X¹JKôPTQAF=O!QäTUH<?Y+Y+LH$@@³;=<WJ9HKL$êAM»ãSôPTHNöAL!@9J³OpãªX+OpH$X¹J9LR<WJ9H/ãªX]F=XJ9H$X¹JFIãªXì<?X+Yì>+@!<Wè?H?êP\QSH>+@9HKL^íãPYSH$;eô JQSH@9õ H$OKFIöAH$Y@HKJã?â;=F=âuHíOK<?@9H$@Kô<?X+Y JQSHF=XJ9H$X¹JF=ãªXðOK<?Xðà H">A@9H$Y âuã?L<]Y+F=@<?^àAFIèª>+<WJF=ãªX ã?âJQSH^íH$<?X+F=XSè[<?XAY <?X F=X];9H$OpJFIãªXðã?â8OpãªXJ9H»JKêkáhX YSãªF=XSè @9ã THäY+Fé@9JF=XSèª>+Fé@Q JQ+H`âxãª;=;IãzTF=XSè]â<?OpHKJ@ã?âOpãªXJ9H»JKÿ

N[8X6p UX &[8C ! [Ub \8QSH Þ áM½F=@ >+@9H$Y½à»å0<?OpJ9ã?L!@âxã?L<GX>A^0à HKLkã?âAJ<?@ !P@F=X½<Nîm<WL!F=HKJEå0ã?âF=Xî?ãª;Iî?H$^íH$XJ@<?X+YTH$;=;>AX+YSHKL!@9J9ã»ãPY Opãª;=;=<Wà ã?L!<WJF=ãªXê\QSH$@9H <?OpJ9ã?LR@]F=^íõ ãª@9H JQ+H$FIL »>+<?;=F=JEå LH»>+FILH$^H$X¹J@äãªXJQSH Þ á9M>A@<Wè?Hí<?@YSH$@OpL!FIà H$Y àå JQSH$FIL@9H$OK>SLRFIJEå <?XAY õ+L!FIîW<?Opå]õ+Lã?öA;=H$@Kê\QSHKå XSHKH$Yð<?Y+YAFIJFIãªX+<?;<?> SF=;=Fé<WLå[Y+<WJ<]<?X+Yð<?> SF=;=Fé<WLå]âx>AX+OpJFIãªX+@Kê \8QSH"îW<WL!F=<WàAFé;=FIJEå]ã?â³>+@9HíF=@GL!H$@9J9L!F=OpJ9H$Y à»å JQSH<?OpJ9ã?L o@OpãªXJ9H»JKô¹TQ+F=ORQOpãî?HKL!@JQSH³<?OpJ9ã?Lo@@9õ H$OKFIöÇOJ<?@ !P@<?X+Y"@9õ H$OKFIöAOUY+<WJ<G<?X+Y½âx>+XAOpJFIãªXY+H$^<?X+YôW<?X+Yà»å O!QSãª@H$X F=Xî?ãª;Iî?H$^íH$XJKôkTQ+F=;IHíJQ+H`õ+Lã?öÇ;IHíã?â8<?OpJ9ã?L!@"F=^íõ ãª@9H$@0HPOpHKõ+JF=ãªX+@Kê\QSH`F=Xî?ãª;Iî?H$^íH$XJ<?X+Y Opãª;=;=<Wà ã?L!<WJFIãªXã?â<?OpJ9ã?L!@0Fé@GàA<?@9H$Y ãªX <?@@!>+^íõ+JFIãªXA@Gã?â@9ãPOKF=<?; à H$Q+<zî»FIãª>+L/<?X+Y LH$@9J9L!FéOpJFIãªX+@Y+>+HJ9ã0ã?Lèª<?X+Fé@<WJFIãªX+<?;+Y+H$OKF=@FIãªX+@$êW\QSH$@9H<?@@!>+^íõ+JFIãªXA@<?X+YíLH$@9J9LRF=OpJFIãªX+@<WL!HOpãª^íõ ãªXSH$XJ@ã?â JQSH<?OpJ9ã?Lo@NOpãªXJ9H»JKê

a [8X>p . X42>p1( UX&[jC ! [Ub \QSH^H$<?X+F=XSèã?âOpãªXJ9H$X¹J<?XAY â>+X+OpJF=ãªX+<?;=FIJråðJ9ã >+@9HKL!@½YSHKõ H$X+Y+@ãªXJQSH@9J9ã?LRFIH$@Kô TQ+F=ORQ <WL!H½àÇ<?@9H$Y ãªX @OpH$X+<WL!FIãª@GJQA<WJNL!H+H$OpJ;=FIâxH½OK<?@9H$@<?XAY JQ+H½õ ã?LJ9âxãª;=FIãª@ã?âU>A@9HKL!@Nã?L<?OpJ9ã?L!@$ê Ý OKOpã?LRY+F=XSèìJ9ã]JQSH"õ+Lã?öÇ;IHã?âUJQSH$@9H>+@HKL!@G<]X>+^à HKLGã?â»>+<?;=FIJrå LH»>+FILH$^H$X¹J@G@>+ORQð<?@õ+LRFIîm<?Opå?ôS@9H$OK>+L!FIJEåä<?X+Y]<$îW<?F=;=<WàAFé;=FIJEå^½>+@9Jà H@<WJF=@9ö+H$Y,ê»\8Q+HN<?OpJ9ã?Lo@@OpH$X+<WL!FIãíOpãªXJ9H»JYSH$@OpL!FIà H$@TQA<WJ½JQ+Hì<?OpJ9ã?LäXSHKH$Y+@"J9ãð>+X+YSHKLR@9J<?X+YF=X ã?L!YSHKLíJ9ã H `OKFIH$XJ;Iå <?XAY H H$OpJFIî?H$;Iå@9ãª;Iî?H]Q+Fé@mQSHKLJ<?@ !P@F=X JQSH<?OpJ>+<?;8õ ã?LJ9âxãª;=FIãSê\8Q+H <?OpJ9ã?Lo@ìYSHKJ9HKL!^FéXSH]JQSH õ ãª;=FéOpå âxã?L`âxãª;=;IãTF=XSèðõA<WL!JF=OK>+;=<WL@9J9ã?LRFIH$@Kê

a 0n4[8C% UX &[8C ! [Wb \8QSH Þ á9MF=@0YSHKî?H$;Iã?õ H$Y J9ã @>SõAõã?L!JG<]X»>+^à HKLã?âF=XJ9H$XJFIãªX+@Kê,\8Q+HíõA>SLõ ãª@9H$@<?X+YF=XJ9H$XJ@í;IH$<?Y J9ã <X»>+^à HKL½ã?âNYSH$OKF=@F=ãªX+@0ãªX JQSH Þ á9M <WLRO!Q+FIJ9H$OpJ>+LH?ô JQSHìJ9H$O!Q+X+FéOK<?;³H$X¹îPF|BLãªXA^íH$X¹JKôS<?X+YäJQSHGF=^íõA;=H$^íH$X¹J<WJF=ãªXê»\QSH Þ á9Mä<WL!ORQ+FIJ9H$OpJ>SL!HGQA<?@<?XìF=^õA<?OpJUãªXìFIJ@>SJF=;éF=@<WJFIãªXôTQAF=O!Q`ã?âuJ9H$X]F=@(ãªX+;IåF=^õA;=F=OKFIJ<?X+YJQ»>+@;IH$<?Y+@UJ9ã½XSã?J³>+X+Y+HKL!@9J<?X+Y+<WàÇ;IH8@9åP@9J9H$^@à H$Q+<$îPFIãª>SL$ê\8QSHJ9H$ORQ+X+F=OK<?;PH$Xî»F=LãªX+^íH$XJ LH$@9J9L!F=OpJ@ JQ+H8>+@9HKLY+>SH³J9ãLH$@9J9LRF=OpJFIãªX+@ F=^íõ ãª@9H$Y½à»å@9HKL!î?HKL$ôªO!Q+<?XAXSH$;S<?X+YOK;=F=H$X¹Jõ+Lã?õ HKLJFIH$@$ê Ý Y+<Wõ+J<WJFIãªXJ9ãíJQSHGOK>SLLH$XJH$X¹îPFILãªX+^H$X¹J³F=@³YSHKöAXSH$Y<?@³OpãªX¹J9HPJ<?Y+<WõAJ<WJFIãªXJ9ã JQSHäOK>SL!LH$X¹JO!Q+<?X+X+H$;eô,J9ãJQSH`OK;=FIH$XJ0F=X+âuL!<?@J9L!>+OpJ>SLH<?XAY J9ã JQ+H`@9HKLî?HKL";Iãª<?Yê Ý J½JQSH@<?^íHJF=^H0<`X»>+^àHKLã?â;=HKèª<?;YSH$OKF=@!FIãªX+@³àA<?@9H$Y ãªX[LHKèª>A;=<WJFIãªX+@Kô+;é<$T@<?X+Y[àA>A@F=XSH$@@³LR>+;IH$@Q+<zî?Hà HKH$XF=XAOpã?Lõ ã?L!<WJ9H$Y]F=XJ9ãJQSH Þ á9Mê

@ C' "! X6p124#UX &[8C ! [Wb \8QSHì>SJF=;=F=@!<WJFIãªX ã?âN< @OpH$XSHìàå <?X <?OpJ9ã?L`YSHKõ H$X+Y+@ãªX Q+F=@ mQSHKL½QAF=@9J9ã?Lå ã?â>SJFé;=F=@<WJFIãªX,ê Ý OpJ9ã?LR@/^<$åF=XJ9HKLL!>Sõ+JN<?X+Y LH$@>+^íH½JQSH$FIL<?OpJFIîPFIJFIH$@G<WJ<?Xå ^íãª^íH$XJGã?â(JF=^H?ê Ý @JQSHKå^<$åXSã?JàHGF=XJ9HKLH$@9J9H$Y]F=XäLHKõ H$<WJF=XSè½<?;=;õ+LHKîPFIãª>+@<?OpJFIãªX+@JQSHKåQ+<$î?H<?;IL!<?Y+å`@>+OKOpH$@@âx>+;é;IåOpãª^íõÇ;IHKJ9H$YômJQSHUJ9H$^õã?LR<?;»OpãªXJ9HPJ ^½>+@9Jkà H(J< !?H$XíF=XJ9ãG<?OKOpãª>+X¹JKêªDG>SHJ9ã<$îW<?F=;=<WàAFé;=FIJEåGã?âAOpãªXJ9H$XJ

p cR¢d¦uklfrtsfhqkzEmfhfcRjWfhqsjWc!qE ¾ WcRofClo

<?X+Yâ>+X+OpJF=ãªX+<?;=FIJrå JQSH[OK>SLL!H$X¹Jí>SJF=;éF=@<WJFIãªX ^<$å;IH$<?Y J9ã <ðYAFHKL!H$X¹Jí@9J9ã?Lå TFIJQAF=X JQ+H[@<?^íH@OpH$XA<WL!FIãSê

Þ HäTF=;=;Y+Fé@OK>+@@GJQSH$@H`îW<WL!FIãª>+@â<?OpHKJ@ã?â8OpãªX¹J9HPJ½FéX ^íã?LH`Y+HKJ<?F=;;=<WJ9HKL½F=XðJQ+F=@0@9H$OpJFIãªXêk\8Q+F=@H$XJFILHF=X+âuã?L!^`<WJFIãªX"âuã?LR^@JQSH Rù Aø ªøk÷ ýKô¹TQ+FéO!Qíà+LRF=XSèª@ J9ã?è?HKJQSHKLJQSH@9J9ã?L!åà ãª<WL!Y@õH$OKF=öAOK<WJFIãªX<?X+Y¿JQSH OpãªXJ9H»J>A<?;/F=XSâxã?L!^<WJFIãªX,êU\UåõAFéOK<?;»>SH$@9JF=ãªX+@JQ+<WJ[<WLHð<?X+@9THKLH$YßãªXßJQSH àA<?@Fé@äã?âJQSHOpãªXJ9H»JN@9õA<?OpH0<WLH?ÿ

Þ Q+<WJOpãªXJ9H$X¹JNF=@LH»>+FIL!H$Yäà»åìJQSH/OpãªXJ9H»JN@9õA<?OpH Þ Q+<WJ8â>+X+OpJFIãªXA<?;=FIJEåF=@³LH»>+FILH$Yìà»åJQSH0OpãªXJ9H»JN@9õA<?OpH Þ Q+<WJQ+<?@8J9ãà H/O!Q+<?XSè?H$Y âuã?LJQSH0;=FIâxHOK<?@9H$@Kô+JQ+H0@9J9ã?Lå»à ãª<WL!YôSHKJOWêIôÇF=âOpãªXJ9H»JNF=@8OpãªX+@FéYSHKLH$Y

Ý @ãª>+J;=F=XSH$Y[<Wà ãî?HJQSH"OpãªXJ9H»JG@9õA<?OpH"F=@Y+HKJ9HKL!^F=XSH$Y àåìJQSH"<?OpJ9ã?L!@KôJQSH½@OpH$X+<WL!FIãª@$ôAJQSH Þ áMFIJ@9H$;=ârô<?X+Y JQ+HJF=^H?êÇáhJ;IH$<?YA@J9ãì<@9õ H$OKF=<?;=F=@<WJF=ãªX[ã?âJQSH"OpãªX¹J9H$XJKô,@9J9L!>AOpJ>SL!F=XSèä<?X+Y â>+X+OpJF=ãªX+<?;=FIJråã?â JQSH/@OpH$XSH$@$ê Þ H0TFé;=;ÇYAF=@OK>+@@³JQAF=@@9õ H$OKF=<?;=F=@!<WJFIãªXìF=XìJQSH0;=<?@JõA<WLJã?â JQ+F=@ORQ+<Wõ+J9HKL$ê

ãªXJ9HPJF=@"<?@@9ãPOKF=<WJ9H$YTFIJQßþ~÷ ú9ý¹ü ú9ù Kú~ø ~÷ ã?âJQSH Þ áM @>+ORQ <?@ >+<?;éFIJEå OpLRFIJ9HKL!F=<<?X+Y@9H$OK>SLRFIJEå[<?X+Y õ+L!FIîW<?Opå]LH»>+FILH$^H$X¹J@KêG>+<?;=FIJrå]OpL!FIJ9HKL!F=<`@>+O!Q<?@N@>+FIJ<WàAFé;=FIJEåâxã?LJQSH½>+@9HKL!@ã?LN;=H$<WL!XPB<WàAF=;éFIJEå½õ+Lãî»F=Y+H8ã?àA;=FIèª<WJF=ãªX+@âxã?LUJQSH Þ áMíY+HKî?H$;Iã?õA^íH$XJ(õ+L!ã»OpH$@@$ê\8QSãª>+èªQJQSH$@9HNOpL!FIJ9HKL!Fé</<WLHLR<WJQSHKLâ>949Kå?ôAJQSHKå];IH$<?Y Y+FILH$OpJ;=å`J9ãä<`X>+^à HKL8ã?âF=^íõA;=H$^íH$X¹J<WJF=ãªX]ã?àA;=FIèª<WJF=ãªX+@JQ+<WJ^½>+@9JàH0âx>+;=öA;=;IH$Y<WJ;=<WJ9HKL@J<Wè?H$@KôÇFeêH?êATFIJQ+F=XJQSH/Y+HKî?H$;Iã?õA^íH$XJ8ãªX]JQSHF=^íõA;IH$^H$X¹J<WJFIãªX];é<$å?HKL$ê

Sã?LF=XA@9J<?X+OpH?ô ;IH$<WL!X+<WàAFé;=FIJEåì^íH$<?X+@GOpãª^íõALH$QSH$X+@F=àAF=;=FIJrå?ô+FeêH?êAJQ+H Þ á9M ^½>+@9JNàHH$<?@9å[J9ãì>+@9H?ôLHpB^íH$^à HKL$ôOK<Wõ+J>+LH<?XAY/âxã?LH$OK<?@9JKê?\8Q+F=@LH»>+FILH$@OK;=<WL!FIJråã?â+JQSH(îPF=@>A<?;ªLHKõ+L!H$@9H$X¹J<WJF=ãªXôõALH$Y+F=OpJ<WàAFé;=FIJEå?ôY+FIL!H$OpJXSH$@@(<?XAYäF=XJ>+FIJF=î?H$XSH$@@Kê¹\QSH$@9HõALã?õ HKLJFIH$@(<?;é;IãzTJQSHN>A@9HKL(J9ã"OpãªX+OpH$XJ9L!<WJ9HãªX`JQ+HJ<?@ !P@KêP\8QSHTã?L"! AãzT@³<?X+YäJQSHGY+F=@Opãª>SLR@9H@9J9LR>+OpJ>SLHNOpã?LLH$@9õ ãªX+YäJ9ãJQ+HHPõ H$OpJ<WJFIãªX+@³ã?â,JQSHG>+@9HKLR@U<?X+YYSã"XSã?J;IH$<?Y J9ã @!>SLõ+L!Fé@F=XSè`@!FIJ>+<WJFIãªX+@$ê \QSHKå OK<?Xðà H"àA<?@9H$Y ãªXð^íHKJ<WõAQSã?L!@0<?X+Yð^íã?JFIî?H$@0J< !?H$XðâuL!ãª^ JQSH<Wõ+õA;éF=OK<WJFIãªX0Y+ãª^<?F=XêáhX0JQSH@!<?^íHUT³<$åã?JQSHKL >+<?;éFIJEå/OpL!F=J9HKL!F=<OK<?X"<?;=@ãà HU^<WõAõH$Y0J9ãYSHKî?H$;Iã?õA^íH$XJã?àA;=F=èª<WJFIãªX+@Kê

ëNJQ+HKL½õALã?õ HKLJFIH$@½JQ+<WJí^<$å à Hì<?@!@9ã»OKFé<WJ9H$YTFIJQ OpãªX¹J9HPJLHKâxHKLíJ9ã JQSHìõã?J9H$XJF=<?;>SJFé;=F=@<WJFIãªXâxã?Läã?JQSHKLìJ<?@ !P@ãª>SJ@F=Y+H[JQSH @Opã?õ H ã?âJQSH @9J9ã?Lå»à ãª<WL!YêUáhX JQ+F=@OK<?@9H TH YSã XSã?JìF=XJ9HKè?L!<WJ9H JQSH<?Y+Y+F=JFIãªX+<?;J<?@ !P@½F=X¹J9ã JQSHä@9J9ã?L!åà ãª<WL!YôàA>SJ0F=XA@9J9H$<?Y @>+õ+õ ã?LJJQSH$@9HäJ<?@ !»@$ôFIâ³JQ+F=@0F=X <?OKOpã?L!Y+<?XAOpHTFIJQ`ãª>SL³F=X¹J9H$XJFIãªX+@$ê Sã?L8F=XA@9J<?X+OpH?ô¹THG^FIèªQJ(HPõH$OpJâ>SLJQSHKLUî»F=@!FIJ@J<WLè?HKJFéXSèí<WJOpã?LHGOpãªX+OpHKL!XA@Uã?âJQSH Þ áMê

ý MPãª^íHKJF=^íH$@UOK>+@9J9ãª^íHKL!@^<zåT<?XJ(J9ã">+@9H< Þ á9Míâuã?L³</õÇ>SLõ ãª@9HJQ+<WJYSãH$@XSã?J^íHKHKJJQSH@9å»@J9H$^ o@0^Fé@@FIãªXð@9J<WJ9H$^H$X¹JKê*Sã?L½HP<?^õA;IH?ô< OK>+@9J9ãª^íHKL½^<$å >+@H`<[àA<?X !»F=X+è Þ áM J9ã;IH$<WL!X<Wà ãª>SJíJQSH[;Iãª<?X àA>+@F=X+H$@@Kôkã?L`< à ãã!P@QSã?õ Þ á9M J9ã ;IH$<WL!X (X+èª;=F=@Qê ³;IH$<WLR;Iå?ô JQSH ;=<WLè?HKLíJQ+H[èª<Wõà HKJETHKH$XJQSH]<?OpJ>+<?;³OK>+@9J9ãª^íHKL o@íF=X¹J9H$XJFIãªX<?X+Y JQSH]@9åP@9J9H$^ o@"^F=@!@FIãªX @9J<WJ9H$^íH$XJF=@KôkJQSHQAFIèªQSHKLJQSHìHPõH$OpJ9H$Y Opãª@J@"TF=;=;(àHâxã?L"@!>Sõ+õ ã?LJF=XSè @>+O!Q OK>A@9J9ãª^íHKL!@KêkáhâFIJ"OK<?X àHHPõH$OpJ9H$YJQA<WJ@9ãª^íHOK>+@9J9ãª^HKL!@TFé;=;UFéX¹J9HKL!<?OpJäTFIJQJQSH Þ áM F=X < X+ãªXPBE@9J<?X+Y+<WLRYT<zå?ôU< Y+H$OKF=@FIãªX Q+<?@J9ã à H[^<?YSHTQSHKJQ+HKLJ9ã @>+õ+õ ã?LJ@>+ORQ F=XJ9H$X¹JFIãªXA@ã?LäX+ã?JKê(\8Q+F=@íFé^íõA;=FIH$@í< ^íã»YAFIöAOK<WJFIãªX ã?âGJQSH <?X¹JF=OKF=õA<WJ9H$YF=XSâxã?L!^<WJF=ãªX @9õA<?OpH?êáhJN@Q+ãzT@JQ+<WJGãª>SLNâuãPOK>+@ãªX <äàA>+@FéXSH$@@^ã»YSH$;âuã?LOpãªXJ9H»J^íãPYSH$;=;éF=XSèF=@NXSã?J<?;IT³<$åP@<@HKî?HKLH/LH$@9J9LRF=OpJFIãªXê

Þ H½^<$å]OpãªX+@FéYSHKLJQSLHKH0<?YAY+FIJFIãªX+<?; OpãªXJ9H»Jâx<?OpHKJ@$ÿ

0 p]X 8( Cqp WX&[8C ! [Ub L!ãzîPF=YSHKL!@<WLHO!Q+<WLR<?OpJ9HKL!F=@9H$Y0àåNJQSH$FIL^`F=@@FIãªX,ôpFéX¹J9H$XJFIãªX+@Kô$<?XAY/@9õ H$OKFIöAO õ ãª;=F|BOKFIH$@$ê Ý Y+Y+F=JFIãªX+<?;=;Iå?ôÇJ9HKL!^@Gã?âàA>+@FéXSH$@@N^<$å àHí<?Y+Y+H$Yê H$X+YSã?L!@XSHKH$Y J9ã[>AX+YSHKL!@9J<?XAY QSãT J9ãL!>AX JQSH Þ á9M H$OpãªXSãª^F=OK<?;é;Iå?êk\Uå»õAF=OK<?;UõA<WLJ@ã?â8JQ+F=@½OpãªX¹J9HPJ<WLHìF=XJ9H$X¹JFIãªXA@0ã?â8JQ+Häõ+L!ãzîPF=YSHKL$ô

qEc!~8c!tsloCd,!yÇ$tsRqegz?~c!qElojy|!q´½fCNwujyµRqs8c!tsloRj/$gzdtsfCd wmidscRRfjWc!gdelod JQSH$^H$@Uã?âJQSHTHKàA@FIJ9H?ôP^F=@!@FIãªXã?L³Opã?Lõ ã?L!<WJ9HF=YSH$XJFIJråíã?âJQSHN@!FIJ9H?ô»<?XAY`ãPOKOK<?@FIãªXì<?X+YäõA>SLõ ãª@9Hã?âJQSHíîPF=@FIJ@Gã?â³<?OpJ9ã?L!@Kê\Q>+@$ôõ+LãzîPF=YSHKLR@N^`<$å LH»>+FILH"<?Y+Y+FIJF=ãªX+<?; OpãªX¹J9H$XJ<?X+Y â>+X+OpJF=ãªX+<?;=FIJråY+>+HNJ9ãíJQ+H$FIL8^F=@@!FIãªXä<?XAYìõãª;éF=Opå?ê»\QSHKåä^<zå<WõAõA;Iå`JQ+H$FIL³J9HKL!^@³ã?âkàA>+@F=X+H$@@U<?XAY]^<$åLH»>+FILH<@õH$OKF=öAOG;=<$å?ãª>SJ<?X+Y]õA;=<zå?ãª>SJKêZ³<?@9H$YäãªXíJQ+F=@(F=XSâxã?L!^<WJFIãªXô?JQ+H Þ áM"F=@H»J9H$X+Y+H$Yà»å½õALãzîPF=YSHKL9BE@õH$OKF=öAO³OpãªX¹J9H$XJ<?XAYíâx>AX+OpJFIãªXPB<?;=F=JEå?êA\8Q+H/@9J9ã?Lå»àãª<WLRY[^<$åìà H<?;IJ9HKLH$Y <?OKOpã?L!Y+F=XSèíJ9ã`JQSH0F=XJ9H$X¹JF=ãªX+@ã?âkJQSH/õ+Lãî»FéYSHKL$ôS<?X+Y[;=F=âuHOK<?@9H$@"^<zåðà HH»J9H$XAYSH$Y ã?L½õA<WLJFé<?;=;Iå @>Sõ+õ ã?LJ9H$Yê (LãzîPF=YSHKLBsàA<?@9H$Y ORQ+<?XSè?H$@½J9ã õ ã?LJ9âxãª;=FIãª@<WLHJråõAFéOK<?;âuã?L Þ áMP@8F=XìHpBsè?ãî?HKL!X+^íH$XJG<?X+Y]HpBsàA>+@!F=XSH$@@<Wõ+õÇ;=F=OK<WJFIãªX+@$ê

C 6C%#KX! Cqp UX &[8C ! [Ub \8QSH Þ áM]F=^íõÇ;IH$^íH$XJ<WJFIãªX[YSHKõ H$X+Y+@³ãªX JQSH0OK<WõA<WàÇF=;=FIJråäã?âJQSHYSHKî?H$;Iã?õ HKL$ê\UåõÇF=OK<?;=;Iå/THXSHKH$YJ9ã/J< !?HF=XJ9ã/<?OKOpãª>+XJ(JQSHõ ã?J9H$XJF=<?;SH$Xî»FIL!ãªX+^íH$XJKô?H?êèSê¹Q+<WL!YPB<?XAYí@9ã?âuJrT<WL!H?ôOpãª^^½>+X+FéOK<WJFIãªX[O!QA<?X+XSH$;=@KôSJQ+H/F=XSâxã?L!^<WJFIãªX]@9åP@9J9H$^@JQ+<WJ8<WLH/J9ã`àH/FéX+Opã?Lõ ã?L!<WJ9H$YôSH$@9õ H$OKF=<?;é;IåJQSH<?@@9ãPOKF=<WJ9H$Y Y+<WJ<WàÇ<?@9H$@KôA<?X+Y[JQSHõ+Lã?è?L!<?^`^F=XSè"H$Xî»FIL!ãªX+^íH$XJ8YSHKî?H$;Iã?õ HKL!@8>+@H?ê

p 24& Kn 2[ X& 24# 24& ( noX 24# WX&[8C ! [Ub \8QSH ã?Lèª<?X+F=@<WJF=ãªX ã?âJ<?@ !@9ãª;=>SJFIãªXA@`F=@`ã?âuJ9H$X¿<?;ILH$<?YSåõ+L!H$YSHKJ9HKL!^F=X+H$Y]àåìJQSH½<Wõ+õA;=FéOK<WJFIãªX[YSãª^<?FéXê+áhJâxãª;=;IãzT@8ã?Lèª<?X+Fé@<WJFIãªX+<?;@9J9L!>+OpJ>SL!H$@8TFIJQAF=XìJQSHF=XA@9JFIJ>SJFIãªXA@F=Xî?ãª;Iî?H$Yê Þ HíOK<Wõ+J>SLH$Y <õA<WLJGã?âJQ+H$@9Hí@9J9L!>+OpJ>SL!H$@N<?;=LH$<?YSå ãªXJQSH"àA<?@!F=@ã?âUJQSHõ ã?LJ9âxãª;=FIã]<?X+Y ^íã»Y+H$;=;IH$Y FIJ/à»åOpãª;é;=<Wà ã?L!<WJFIãªXê,\8Q+Híã?JQSHKL0õA<WLR@âuã?LR^ JQSHã?Lèª<?XAF=@<WJFIãªX+<?;(OpãªXPBJ9HPJKê&³ãª;=;=<Wà ã?L!<WJFIãªX"ã?âõA<WL!JXSHKL!@(OpãªXA@F=@9J@(ã?â Opãª^`^>+XAF=OK<WJFIãªXô»Opãã?L!YAF=X+<WJFIãªXôª<?XAYÒpã»ã?õHKLR<WJFIãªXêã»ã?õ HKL!<WJFIãªXF=@½àA<?@9H$YãªX Opã»ã?õ HKL!<WJFIîPFIJEå?ôFeêH?ê JQSH]Y+Fé@9õ ãª@FIJFIãªX J9ã <?OpJF=X< T³<$å JQ+<WJíF=@½à H$@9JQSH$;=õ+âx>A;Pâuã?LUJQSHOpãª;=;é<Wàã?LR<WJFIãªXíõA<WLJX+HKL!@KôªJ< !PF=XSèJQSH$FIL(F=XJ9H$XJFIãªX+@KôJ<?@ !»@$ôF=XJ9HKLH$@9J@U<?X+Y`<WàAFé;=FIJFIH$@F=XJ9ã<?OKOpãª>AX¹JKê Ý JJQSHN@!<?^íHJF=^H?ôOpãª;=;=<Wà ã?L!<WJF=ãªX`F=@UH$@9J<WàA;=Fé@QSH$YF=X`ã?L!YSHKLJ9ã½<?ORQ+FIHKî?HG<Opãª^`^íãªXè?ãª<?;eê Ý OpJ9ã?L!@ORQSã»ãª@9H]JQSH$FILí<?OpJFIãªX+@`<?X+Y ã?Lèª<?X+F=@9HìJQSH$^ @>+O!Q JQ+<WJíJQ+H$FILíO!Q+<?X+OpH$@ã?âN@>AOKOpH$@@<WLHíã?õAJF=^F=@9H$YTF=JQ LH$@9õ H$OpJGJ9ã[JQSHíõ ã?LJ9âxãª;=FIãJQSHKå<WL!HíH$XSèª<Wè?H$Y F=X,ê Ý Y+Y+F=JFIãªX+<?;=;Iå?ôÇJQSH@9ãPOKF=<?;OpãªXJ9H»J½^<$åà H"J< !?H$X F=XJ9ã[<?OKOpãª>+X¹JKôTQ+F=ORQOpãªXA@F=@9J@Gã?â³F=XJ9HKL!<?OpJFIî?H<?X+Y LH$<?OpJF=î?Hõ+LH$@@!>SLH$@Kê\UåõÇF=OK<?;@ã»OKF=<?;kH$X+QA<?X+OpH$^íH$XJ@<WLH½@ã»OKF=<?;é;Iå[F=X+Y+FéOK<WJ9H$Y @F=J>+<WJFIãªX+@N@>+ORQ<?@NTH$;=Opãª^íH"è?LHKHKJF=X+èª@KôJQ+<?X !»F=X+èSô+<Wõãª;=ã?èªF=@F=XSèSôS<?X+Yìâ<WLHKTH$;=;è?LHKHKJFéXSèª@Kê

N[8X6p iX&[8C ! [ %,HKJ0>+@XSHPJ/J< !?Hä< YSHKHKõ HKL0;Iã»ã! FéX¹J9ã[JQ+Hâx<?OpHKJ@ã?â³JQSHÒpãªXJ9H»J"@9õA<?OpH?ôkFeêH?êHS<?^F=X+F=X+è½<?OpJ9ã?L$ô+@J9ã?Låà ãª<WL!Y,ôP@å»@9J9H$^ <?X+YJ9H$^íõ ã?L!<?;OpãªX¹J9HPJF=Xì^íã?L!HGY+HKJ<?F=;eêS\8QSHOpãªXJ9H»J8ã?âk<?X<?OpJ9ã?L"F=@GàA<?@9H$Y ãªX Q+F=@mQ+HKL/F=X¹J9H$XJFIãªX+@$ê Ý OKOpã?LRY+F=XSè]J9ã[JQ+H`<?OpJ9ã?Lo@õ+Lã?öA;IHí@mQ+H`XSHKH$Y+@/@!>Sõ+õ ã?LJGJ9ãâ>+;IöA; JQSHäH»õ H$OpJ<WJFIãªXA@0TF=JQðLH$@9õ H$OpJ/J9ãJQSH »>+<?;=FIJrå ã?â8F=XSâxã?L!^<WJFIãªX <?XAY Tã?L"!Çêk\8QSH`@ã»OKF=<?;U<?X+YF=XJ9H$;=;IH$OpJ>+<?;F=XJ9HKLH$@9J@8ã?âJQ+H½<?OpJ9ã?L^<zå[<?;=@9ã`à H/õÇ<WLJã?âJQSH½<?OpJ9ã?Lo@GOpãªX¹J9HPJKê\8QSH0<?OpJ9ã?L o@õALã?öA;IH^<zå½à H>A@9H$Yíâxã?L(<LHKöAX+H$^íH$X¹J(ã?âJQ+H<?OpJ9ã?Lo@OpãªX¹J9HPJ;=H$<?Y+F=XSèGJ9ã0JQ+H8âuãª;é;IãzTFéXSèGâuãª>SLU@9õ H$OKFIöAO$!PF=X+Y+@ã?âOpãªX¹J9HPJKÿ

N[8X6p ! pjX oC'N[ X & WX&[8C ! [Ub Ý OpJ9ã?L!@8^<zåä<?OpJ8ãªXìJQSH$F=LHPõ H$OpJ<WJFIãªX+@KêSáCXJQ+F=@³OK<?@9H?ô+JQ+HKåäF=XJ9H$XPB@F=ãªX+<?;=;Iå YSLã?õ õ ã?LJF=ãªX+@íã?âOpãªX¹J9H$XJìã?L`â>+X+OpJFIãªXA<?;=FIJEå<?X+Y õ+Lã];9H$OpJJQSH OK>+LLH$XJÒpãªX¹J9H$XJ]<?X+Yâ>+X+OpJFIãªXA<?;=FIJEå J9ã]JQSH 9XSã?LR^<?; ]OK<?@9H?ê\Q+F=@Nõ+Lã];9H$OpJFIãªX ;IH$<?YA@GJ9ã <?X F=^íõÇ;=F=OKFIJNOpãªX¹J9HPJKê Sã?L½F=XPB@9J<?XAOpH?ôTFIJQ+F=X < J9L!<$î?H$;G@OpH$XA<WL!FIã<?OpJ9ã?L!@ì<WLH HPõ H$OpJ9H$Y¿J9ã à H$Q+<zî?H;=F !?H[J9L!<$î?H$;é;IHKL!@Kê Ý X+ã?JQSHKL!PF=X+Y ã?â³õ+Lã];9H$OpJFIãªX Fé@õA<WL!<?^íHKJ9HKL½@>Sõ+õALH$@@FIãªX,ôF=X TQ+F=O!Q OK<?@9HÒpãªXJ9H$X¹J½ã?L/â>+X+OpJFIãªX+<?;éFIJEå^<$åà H/YSLã?õAõH$Yã?LNF=@XSã?JXSã?JFéOpH$Y]TQSH$XSHKî?HKLFIJà H$Opãª^íH$@8õA<WL!JF=<?;=;Iå`F=LLH$;IHKîW<?X¹JKê

N[8X6p 2 ! ! pjX ! 6 2 [ X& UX&[8C ! [Ub ëNâxJ9H$X <?OpJ9ã?L!@½XSHKH$YðöAL!@9J/<[OpãªX+Y+H$X+@9H$Yðã?L½<Wõ+õ+Lã PF=^`<WJ9H$Y F=XPBâxã?L!^<WJFIãªX¿JQ+<WJ[^`<$å à HLHKöAXSH$Yß;=<WJ9HKLzê³\Uå»õAF=OK<?;G@>+ORQ¿<WõAõ+LãSF=^<WJF=ãªX+@ì<WLHð<WJ9J9L!FIàA>SJ9HîW<?;=>SH<Wõ+õALãSF=^<WJFIãªXA@"ã?L`@9J9L!>+OpJ>+L!<?;8<Wõ+õ+L!ãSF=^<WJFIãªX+@$ê +ã?LäF=X+@J<?X+OpH?ôJQSH]âxã?L!^íHKLãªXSH$@ä^<$å<?;=;IãTJQSH Þ áMJ9ãõ+Lãî»FéYSHGö+L!@9J<?X[<Wõ+õALãSF=^<WJ9HîW<?;=>SHGâxã?L8JQSHã?L!FIH$XJ<WJFIãªX]ã?âkJQSH/>+@HKL$ê Ý Opãª^`^íãªX^Fé@>+@9HGã?â <Wõ+õ+Lã PF=^`<WJFIãªX]F=@³õ+L!FéOKF=XSè½àå 9@9J<WLJF=X+èíâuLãª^ PêÇM»J9L!>+OpJ>SLR<?;<Wõ+õ+Lã PF=^`<WJFIãªXìõ HKL!^FIJ@JQSH½>+@9Hã?âkJQ+H@<?^íH½@9åP^0à ãª;,âxã?LJQ+H0ã?L!FIèªFéX+<?;ã?à<;9H$OpJN<?XAY <?X<WàA@9J9L!<?OpJFIãªX,ôÇQSH$X+OpHH$X+<WàA;IH$@JQSH>+@!<Wè?H/ã?â@F=^íõA;=HKLL!HKõ+LH$@9H$XJ<WJFIãªX+@Kê


N[8X6p 24 6l K[ UX &[8C ! [Ub M»ãª^íHKJF=^íH$@,JQSHLHKâxHKLH$X+OpHã?âP<8@9åP^àãª;?OK<?X/àH>AX+<?^0àÇFIèª>Sãª>+@TFIJQAF=X<"X+<WLL!ãzT @Opã?õ H?ôSF=XäTQ+F=ORQOpHKL!J<?F=Xì;=F=^FIJ<WJF=ãªX+@U<WõAõA;Iå?ô»àA>SJ³<?^0àAF=èª>Sãª>+@³F=X<í;=<WLè?HKL@Opã?õ HGTFIJQPBãª>SJGJQSHí;=Fé^FIJ<WJFIãªX+@$ê Ý JråõAFéOK<?;k>AX+<?^0àÇFIèª>Sãª>+@@9å»^à ãª; F=@JQ+HX+H»J àA>SJ9J9ãªX F=XOK<?@9HíJQSHíXSHPJ@OpH$X+H/;=FIH$@TFIJQ+FéX`JQSHGHPõ H$OpJ<WJFIãªX+@ã?âJQSH/<?OpJ9ã?L$ê Ý XSã?JQSHKL8>+@9HGã?â <?^0àÇFIèª>+FIJråäOK<?Xìà H^<?YSHGàåORQSããª@!F=XSè`;IH$@!@8HPõ+LH$@@F=î?H/J9H»J>A<?;,LHKõ+L!H$@9H$X¹J<WJF=ãªX+@Kê +ã?LNF=XA@9J<?X+OpH?ôAF=X <;Iãª<?X <WõAõA;=F=OK<WJFIãªX[JQSHKLHF=@XSãXSHKH$Y]J9ã`OK;é<WL!FIâxå`JQ+<WJ8JQ+H/TUã?LRY oàA<?X&! +YSH$XSã?J9H$@<"öAX+<?X+OKF=<?;FéX+@9JFIJ>SJF=ãªXê

N[8X6p C'&[124# WX&[8C ! [Ub \8QSH^íH$XJ<?;OpãªXJ9H»JNOK<Wõ+J>SLH$@<WJ9JFIJ>AYSH$@<?X+Y!PXSãzT;=H$YSè?Hã?â<?OpJ9ã?L!@ã?Lã?JQSHKL !PF=X+YA@(ã?â<?;=J9HKL!X+<WJFIî?H@9J<WJ9H$@ã?âk< <?F=L!@³@>+O!Q]<?@öAOpJF=ãªX<?XAY>A@9HKL³H»õ H$OpJ<WJFIãªX+@$ê+\8Q+F=@UOpãªXPBJ9HPJNFé@YSH$@OpLRFIà H$Y[F=X]J9HKL!^`@ã?âõ+L!ãzî?H$X+<?X+OpH?ôFeêH?êÇLH$;=<WJF=X+èJ9ã`LH$<?;k;=FIâxH0OK<?@9H$@ã?LNJ9ãäHPõ H$OpJ9H$Y ;=F=âuHOK<?@9H$@$ê »õ H$OpJ<WJFIãªXA@ã?âU<?OpJ9ã?L!@Gã?L>+@9HKL!@NOK<?XàH½Opãª^0àÇF=XSH$Y TFIJQ ã?JQSHKL^íã?LH½è?H$XSHKL!<?;kLH»>+FILHpB^íH$XJ@Kê,\8Q+H !PXSãzT;IH$YSè?Híã?â(JQ+H"^H$X¹J<?;OpãªXJ9HPJ/TF=;=;LH$^<?F=X Q+F=èªQ+;Iå[F=X+Opãª^õA;IHKJ9H?ê(ãTUHKî?HKLzôFIJõ+L!ãzîPF=YSH$@<Q+<?XAY+;IHGâuã?LF=X+Opã?Lõ ã?L!<WJF=X+è">A@9HKL!@+<?X+Y <?OpJ9ã?L!@+HPõ H$OpJ<WJFIãªX+@Kê

\8Q+H <?OpJ9ã?L OpãªXJ9H»JF=@]F=XJ9H$;=;IH$OpJ>+<?;<?@ TUH$;=;<?@[HPF=@J9H$X¹JF=<?;sêárJ OpãªXJ9L!FIàÇ>SJ9H$@ìJ9ã H$X+<WàA;éF=XSèJQSH@OpH$X+<WLRFIãª@"<?X+Y JQ+HOpã?LL!H$@9õ ãªX+Y+F=XSè @9J9ã?L!FIH$@">+X+Y+HKLOpãªX+@FéYSHKL!<WJFIãªXêk\8QSHìF=XJ9H$;=;IH$OpJ>+<?;(õA<WLJ"F=@0àÇ<?@9H$YãªX JQSH"õ+Lã?öÇ;IHã?âUJQSHí<?OpJ9ã?L$ôãªXðQ+<WàAF=J@KôÇJ9LR<?Y+FIJFIãªX+@$ô !PXSãzT;IH$YSè?H?ô H»õ HKL!F=H$X+OpH?ô HKJOWêárJ^<zå à H"<?;=@9ãàA<?@9H$YìãªXìJQ+H »>+<?;=F=JEåLH»>+FIL!H$^íH$X¹J@<?X]<?OpJ9ã?LF=@³F=^íõ ãª@F=XSèSê»\8QSHG<?OpJ9ã?LOpãªXJ9H»JLH$@9J9L!F=OpJ@JQSH/>A@9HKL!@JQ+<WJG^FIèªQJN>A@9H0JQSH Þ á9MôJQSH½T<zå[JQSH"@9åP@9J9H$^5TF=;=;à H½>+@9H$Yô <?X+Y JQSHõ ã?LJ9âxãª;=FIãª@$ê+árJGF=@àA<?@9H$Y ãªXJQSHNF=X¹J9H$XJFIãªX+@(âuã?L>+@F=X+èJQSH@9åP@9J9H$^ <?X+YJQ+Hõ ã?LJ9âxãª;=FIãã?âJQSHN<?OpJ9ã?L$ôH?êèSê»J<?@ !P@KôFéX¹î?ãª;Iî?H$^H$X¹JKôP<?X+YJQSHGOpãª;=;=<Wà ã?L!<WJFIãªXA@(JQSHG<?OpJ9ã?L8F=@F=Xî?ãª;Iî?H$YìF=Xê\QSHHSF=@9J9H$XJF=<?;õA<WLJ³F=@<?;=@9ã½LH$;=<WJ9H$YäJ9ã½JQ+Hõ ã?LJ9âxãª;=FIã>+X+Y+HKLGOpãªXA@F=YSHKL!<WJF=ãªXê árJ/F=@NLH$;é<WJ9H$YðJ9ã]JQSHY+<WJ<[<?XAY âx>+XAOpJFIãªX+@GOK>SLLH$XJ;Iå <zîm<?Fé;=<WàA;IH"ã?L/õ+L!ãzîPF=YSH$Yô<?X+Y]JQ+HJ9H$O!Q+X+FéOK<?;,H$Xî»FIL!ãªX+^íH$XJKê

\8Q+H`@9õ H$OKFIöAOK<WJFIãªX ã?âJQ+F=@/@õH$OKF=öAO<?OpJ9ã?L"OpãªX¹J9HPJ"àH$Opãª^H$@XSH$OpH$@!@<WLåðTQSH$X+HKî?HKLTH`T³<?X¹JJ9ã@>SõAõã?L!J/JQSHTUã?L"!ðã?â<?OpJ9ã?L!@"JQ+<WJ"F=@0OK;Iãª@HäJ9ãðQ»>+^<?X Opãª^`^>+XAF=OK<WJFIãªXê >A^<?X Opãª^^½>+X+FéOK<WJFIãªXHPõA;IãªFIJ@ JQSHOpãªX¹J9HPJ(ã?âxJ9H$XJ9ã0<?XH»J9LH$^HYSHKè?LHKH?ô¹;=H$<$îPF=XSè/^<?XåJQAF=XSèª@F=^õA;=F=OKFIJKê Þ HYSã/X+ã?JXSHKH$Y<NOpãª^íõA;IHKJ9HYSH$OpãªXJ9H»J>A<?;=F=@<WJFIãªX"<?@ ;IãªXSèG<?@kJQSH<?OpJ9ã?LOK<?X"F=X¹J9HKL!õ+LHKJkJQSHOpãªXJ9H$XJ<?X+Y0â>+X+OpJF=ãªX+<?;=FIJråJQ+<WJ(Fé@õ+Lãî»F=Y+H$Y"àå½JQSH Þ á9M ê ãªX¹J9HPJ@Uõ+LãzîPF=YSH</^H$O!Q+<?X+Fé@^ à»åTQAF=O!Q"THOK<?X`>A@9HJQSH@Fé^íõA;IH$@9Jõ+LH$@H$X¹J<WJFIãªX,ô+OpãªX¹J9H$XJ<?X+Y[âx>+XAOpJFIãªX+<?;=FIJrå?ôSFeêH?êSJQSH/ãªXSH$@8JQ+<WJ^< !?H$@JQSHâuHKTH$@9JYAF=@9JF=X+OpJF=ãªX+@³^íãª@9Jã?âAJQ+HJFé^íH³TQ+F=;IHUJ9L!<?X+@OpH$XAY+F=XSèJ9ã/^íã?LH³H»õALH$@@FIî?Hõ+LH$@H$X¹J<WJFIãªX,ôWOpãªXJ9H$XJ(<?X+Y½âx>AX+OpJFIãªX+<?;=F=JEå/ãªX+;=åTQSH$X]X+HKH$YSH$Yê

DG>SH½J9ãäJQ+H$@9H½OpãªXJ9HPJ>+<?;<WàAF=;=F=JFIH$@TH½^<zå LH$@J9L!F=OpJõALH$@9H$XJ<WJFIãªXô OpãªX¹J9H$XJ<?X+Y â>+X+OpJF=ãªX+<?;=FIJråJ9ã JQ+ãª@9H âxH$<WJ>SLH$@`JQ+<WJä<WLH<WàA@9ãª;=>+J9H$;Iå X+H$OpH$@@<WLå?ê\8QSH$@9H[L!H$@9J9L!F=OpJFIãªXA@^<$å L!H$@>+;IJF=X õ+LH$@9H$XJ<mBJFIãªX õ+LRF=X+OKFIõA;=H$@8@>+ORQð<?@@9õA<WL!@9Hí>SJFé;=F=@<WJFIãªX ã?âU<?YAY+FIJFIãªX+<?;k<?X+Y XSã?J/Y+F=LH$OpJ;Iå[XSH$OpH$@@!<WLåOpãªXJ9H$XJ/ã?Lâ>+X+OpJFIãªX+<?;éFIJEåäã?L8H$OpãªXSãª^å[F=X]>SJF=;=Fé@<WJFIãªXã?âkOpãª;=ãª>SL!@Kô+^½>+;IJF=^H$Y+F=<½ã?à<;9H$OpJ@KôA<?X+Y]J9HPJ>SLH?ê ý %,HKJ >+@9H P<?^íõÇ;IH ñ âxã?L <?X F=;=;é>+@9J9L!<WJFIãªX¿ã?â½JQ+F=@]õAL!F=X+OKFIõÇ;IH$@Kê Ý X F=@!@>SHKL]ã?â"JQSHLH$;IãPOK<WJFIãªX];=F=âuHOK<?@9H/HPõ H$OpJ@JQ+<WJ8Q+Fé@Uõ HKL!@ãªX+<?;<?X+Y]F=YSH$XJFIöAOK<WJF=ãªXYA<WJ<í<WLH0<?;ILH$<?Y+åä@> äOKFIH$X¹J³âxã?Lõ+Lãî»FéY+F=XSè0QAF=^mQSHKL<?;=;ÇX+H$OpH$@@<WLå`Y+HKJ<?F=;=@KêSM»ãSôJQ+HNOpãªXJ9H»J8FéX`TQAF=O!Q`JQSHNFé@@>SHKLLH$<?OpJ@F=@UàA<?@9H$YäãªXõ+Lã];9H$OpJFIãªX <?XAY <?^0àÇFIèª>+FIJrå OpãªXJ9H»JKêárâTUHä>+@9HíJQSHF=X+âuã?L!^`<WJFIãªX JQSHíõA<?@@õã?L!JNã äOpH`õ+Lãî»FéYSH$@<?@õA>SàÇ;=F=OF=XSâxã?L!^<WJF=ãªX]âuã?LGJQSH½OKFIJEå ã `OpH?ôÇJQ+H$X TH½OK<?X <?Y+<WõAJJQSH";=FIâxH0OK<?@9H"Y+FILH$OpJ;=åJ9ãìJQSH½OK>SLLH$XJãªXSH?ê Ý J(JQSHN@<?^íHJFé^íH?ôªJQSHî»F=@!FIJã?â JQSHF=@!@>SHKL(^F=èªQ¹Jà HX+ã?JJQSHöAL!@9J(@>AO!Q`FéXQ+F=@mQ+HKL(;=FIâxH?êM»ãSôªTHOK<?XXSãzT·>+@9HJQSHNFéXSâuã?LR^<WJFIãªXíãªXäõ+LHKîPFIãª>+@U;=FIâxHOK<?@9H$@âuã?L³@OK<?;=FéXSè/JQSHN;=FIâxHOK<?@9HNJ9ãJQSHNHPõH$OpJ<WJF=ãªX+@JQSH0Fé@@>SHKLQ+<?@Kê

\8Q+H8<?Y+<Wõ+J<WJFIãªX`LH>AFILH$@@9ãª^íHàA<?O"!»è?Lãª>+X+Y !»XSãT;IH$YSè?HãªXíJQSHQ+<?XAY+;=F=XSèNã?â;=FIâxHOK<?@9H$@(F=Xã?JQSHKLOKFIJFIH$@$ôÇõ+L!HKî»FIãª>A@îPF=@FIJ@$ôÇ<?X+YJQSH½õ+Lã?öA;=Hã?âJQ+H"Fé@@>SHKL$ê Þ Hí^<$å JQSH$X >+@9H"<X»>+^à HKLã?â >SH$@JFIãªX+@J9ãìö+èª>SLHãª>SJKôTQ+F=ORQ â>SLJQSHKLG<?Y+<Wõ+JF=ãªX ã?LGLHKöAX+H$^íH$X¹JNã?âJQSH";=FIâxHOK<?@H"Fé@<Wõ+õA;éF=OK<WàA;IH?êMPF=X+OpH½@9ãª^íHY+<WJ< ãªX JQ+HF=@!@>SHKLOK<?XAXSã?Jà H@9J9ã?LH$Y F=X JQ+Hä@9åP@9J9H$^ Y+>SHäJ9ã LHKèª>A;=<WJFIãªX+@<?X+Y ;é<$T@TUHìXSHKH$Y J9ã

qEc!~8c!tsloCd,!yÇ$tsRqegz?~c!qElojy|!q´½fCNwujyµRqs8c!tsloRj/$gzdtsfCd wmidscRRfjWc!gdelod LHKõ H$<WJ9H$Y+;Iå0ã?à+J<?F=X½JQSH$@9HY+<WJ<PêM»ãSôWJQSHY+<WJ<NTHXSHKH$Y"J9ãOK<Wõ+J>SLH³TFIJQAF=X/JQSH;=F=âuHOK<?@9H8<WLH³H»J9H$XAYSH$Yà»å[Y+<WJ<`THX+HKH$Y âxã?LöAèª>SL!F=XSèíãª>+JTQAF=O!Q @9õ H$OKFIöAO;=FIâxH0OK<?@9H"F=@>+X+YSHKLNOpãªX+@F=YSHKLR<WJFIãªXê Ý JNJQSH"@<?^íHJF=^íHTH0^<zå]>+@9HJQ+F=@OpãªXJ9HPJF=XSâxã?L!^<WJF=ãªXìâuã?L<?YA<Wõ+JF=XSèíâ>+X+OpJFIãªXA<?;=FIJEåäJQ+<WJF=@³õALãzîPF=YSH$Yê

\8QAF=@U@õH$OKF=öAO<?OpJ9ã?LOpãªXJ9HPJ8F=@³Opãª^0àAFéXSH$YTFIJQäJQSHGõã?L!J9âuãª;=F=ã0LH$@9J9LRF=OpJFIãªX+@Kê Ý OpJ9ã?L!@³TFIJQ<"XSãªXPBYSHKJ9HKL!^`F=X+F=@9JFéOäà H$Q+<zî»F=ãª>SLYSã XSã?J>A@9H Q+FIèªQ <?^àAFIèª>AFIJEå ã?LäYSHKHKõõ+Lã];9H$OpJFIãªXê Ý JäJQSH @<?^íH JF=^íH?ôJQSH$FIL/^H$X¹J<?;UOpãªX¹J9HPJ<?X+Y JQSH$FIL/<Wõ+õ+L!ãSF=^<WJFIãªX OpãªXJ9HPJ^½>+@9Jà HíL!<WJQSHKL0@ã?õAQ+F=@9JFéOK<WJ9H$Yê Ý OpJ9ã?LR@<?OpJF=XSè ^íã?LHíãªX FéX¹J9H$XJFIãªXðF=XJ9H$X+@FIî?H$;=å>+@H<?;=; âuãª>+L !»FéX+Y+@Nã?â<?OpJ9ã?LOpãªXJ9H»J@Kê \k<?@ !¹Bsã?LRFIH$X¹J9H$Y <?X+YLH$<?OpJFIî?H½à H$Q+<$îPFIãª>SLLH>AFILH$@8@>+õ+õ ã?LJ³âuã?LG^íH$XJ<?;OpãªXJ9H»JKê Ý OpJ9ã?L!@<?OpJFéXSèäF=X Opãª;=;=<Wà ã?L!<WJFIãªX+@XSHKH$Y<?Y+Y+F=JFIãªX+<?;@>+õ+õ ã?LJâuã?L½JQSH$FIL½Opãª^^íãªXY+F=@!<?^0àAF=èª>+<WJFIãªXêáhâ<?OpJ9ã?L!@íYSã X+ã?JOpãª^íõA;=HKJ9H`JQSH$FILJ<?@ !P@TFIJQAF=X0ãªX+H8@9H$@@FIãªX,ômJQ+HKå½XSHKH$Y`<GTUH$;=;IBsõ+LHKõA<WLH$Y½õ+L!ã];CH$OpJFIãªXíOpãªXJ9HPJ(âxã?LJQSH8OK<?@9H8JQ+<WJ(JQSHKå0LH$@!>+^íHJQSH$FILGJ<?@ !P@Kê Þ H@Q+<?;é;;=<WJ9HKL^<WõðJQ+H$@9H"LH>AFILH$^íH$XJ@J9ã[<?YA<Wõ+J<WJFIãªX L!>+;=H$@<?X+Y OpãªXJ9Lãª; L!>+;=H$@âxã?L<?Y+<Wõ+J<WJF=ãªXê

a [8X>p . X42>p1( iX &[8C ! [ ãªXJ9H»JQ+<?@³<?;=@9ã"<½@9J9ã?Lå»àãª<WLRYäY+Fé^íH$X+@FIãªX,ê¹\8QSHN<?OpJ9ã?Lo@OpãªX¹J9HPJ8^½>+@9Jà H0Opãª^àAF=XSH$Y TFIJQ]JQSH½@9J9ã?Lå»à ãª<WL!YôA;=F=âuH/OK<?@9H"<?X+Y]õ ã?LJ9âxãª;=FIãäOpãªX¹J9HPJ@Kê \8QSH0;=<WJ9J9HKLNJETãì@9H$;IH$OpJFIî?H$;IåOpãªX+Y+F=JFIãªX JQ+H"@!FIJ>+<WJFIãªX+<?;kF=XJ9HKLH$@9JNã?â(JQSH"<?OpJ9ã?L0<?X+YJQSH"LH$;=HKîm<?X+OpH½ã?â(JQ+H½OK>SL!LH$X¹J@OpH$X+H½âxã?LGJQSH<?OpJ9ã?L$ê,Z³<?@9H$YðãªX JQ+H½L!H$;IHKîm<?XAOpHíTUHí^<zåF=Y+H$X¹JFIâxå[<?X+Yð>+@Hõ+L!ã?õHKLR;Iå[<?;=;kJQSHíOpãªX¹J9H$XJ/JQ+<WJ/@!QSãª>+;=YHPHKLJ`JQSH HKî?ãª;=>SJFIãªXã?âJQSH OK>+LLH$XJä@9J9ã?Lå?ê Þ H ^<$å XSãT5>A@9H[JQ+F=@äF=XSâxã?L!^<WJFIãªX âuã?LäH»J9L!<?OpJFéXSèTQSHKJQ+HKL"< @9H»>SH$X+OpHìL!>A;IH?ôkFsêH?êk<L!>+;=Häã?âJQSHäâxã?L!^ V _ L!H>+F=L!F=XSè[JQA<WJ< îPF=@F=J0ã?â@!OpH$XSH V@QSãª>A;=Y à Hâuãª;=;=ãzTH$Y à»å < î»Fé@FIJ0ã?â@OpH$XSH _ OK<?X àHì<Wõ+õA;éFIH$Y J9ã JQSHìOK>SLLH$XJ"@9å»@J9H$^ >A@<Wè?H?ê\8QSHL!>+;=HN^<zå]QSãª;=YìF=Xè?H$XSHKL!<?;eôSàÇ>SJF=@OpãªX+@F=Y+HKLH$YJ9ãà HGX+ã?J8<Wõ+õA;=F=OK<WàÇ;IHFIâJQSHHSF=@9J9H$X+OpHã?âkõ+LãPOpH$@@ V;IH$<?Y+FéXSèìJ9ã @OpH$XSH V YSã»H$@0XSã?J/Q+<zî?Hä<]à H$<WL!FéXSèìãªXðJQSHíHSF=@9J9H$X+OpHã?â³õ+L!ã»OpH$@@ _ ;IH$<?Y+F=XSèìJ9ã @!OpH$XSH _ ê \8QSHKL!HKâuã?LH?ôÇJQSH"F=X+Opã?Lõ ã?L!<WJFIãªX[ã?â(OpãªX¹J9HPJ<?X+Y JQSHYSHKLRFIîm<WJF=ãªX[ã?âLH$;=HKîm<?X+OpH½Q+<?@N^<?F=X+;IåìJ9ãìYSãTFIJQ @9H$;IH$OpJF=XSèäJQSH0à H$@9J@9J9ã?Lå]âxã?LJQSH½>+@9HKLN<?X+Y F=@JQ>A@>+@9H$Y âuã?LNJQSH½<?Y+<Wõ+J<WJFIãªX ã?âOpãªX¹J9H$XJ<?X+Yâ>+X+OpJFIãªX+<?;éFIJEå?ê

\8Q+H@9J9ã?Lå»à ãª<WL!YOpãªXJ9H»JOK<?Xà H>A@9H$Yíâxã?LUYSHKL!F=î»F=X+èNJQ+H^íãª@9JU<Wõ+õ+Lã?õ+LRF=<WJ9HOpãªXJ9H$X¹JKê Þ HN<?Fé^&<WJYSH$;=F=î?HKL!F=XSèJQ+HL!F=èªQ¹JNY+<WJ<J9ãäJQSH½L!FIèªQJG<?OpJ9ã?LTFIJQ[JQ+HL!F=èªQ¹JJ9ããª;=@G<?X+Y@Opã?õ H"<WJNJQ+HL!F=èªQ¹JJF=^íH?êÝ @(JQSHG@9J9ã?Lå»à ãª<WL!YÒpãªXJ9HPJõALãzîPF=YSH$@</è?ã»ã»Y@9ãª>SLROpHâxã?L<?YA<Wõ+J<WJFIãªXäã?âOpãªX¹J9H$XJ<?X+Yâ>+X+OpJF=ãªX+<?;=FIJråJ9ãJQSHOK>+LLH$XJ½@9J<Wè?Hìã?âJQSHì@OpH$X+<WLRFIã THìOpãª;=;IH$OpJ"OpãªX¹J9HPJ"TFIJQ+F=X JQSH@J9ã?Låà ãª<WL!Y <?X+Y <?Y+Y JQ+F=@OpãªXJ9H»J³F=XSâxã?L!^<WJFIãªX"J9ãJQSHOpãªXJ9HPJ@9õÇ<?OpH?ê\8Q+Fé@OpãªX¹J9HPJ<?;é;IãzT@U<J9LH$<WJ^íH$XJã?âJQ+HHPõH$OpJ<WJF=ãªX+@ã?â(JQ+H"<?OpJ9ã?Lzê,\8QSHKLHKâxã?LH?ô H$<?O!Qð@OpH$X+HF=X <ì@OpH$XA<WL!FIã]F=@õ+LãzîPF=YSH$YTF=JQ < ú r÷ !ù Çø ªø~ô ÷ !ù Aø ¹øRôÇ<?X+Y[< ùW÷~ø r÷ Rù Aø ¹ø~ê

\8Q+HNõALHpBE@OpH$XSH0OpãªXJ9HPJOpãªX+@F=@J@ã?âk<?;é;OpãªXJ9H$XJJQ+<WJ8Q+<?@<?;ILH$<?YSåäàHKH$X YSH$;=FIî?HKLH$YJ9ãJQ+H/<?OpJ9ã?Là HKâxã?LHJQSH<Wõ+õ H$<WL!XA<?OpH<WJJQSH<?OpJ>A<?;A@OpH$XSH?ê\8Q+F=@F=X+âuã?L!^`<WJFIãªXíOK<?Xà H8>+@9H$Y"J9ãLH$Y+>+OpH8OpãªXJ9H$XJYSH$;éFIî?HKLå]âxã?LG@!OpH$XSH$@Kê Ý JNJQ+H"@!<?^íHJFé^íH?ôÇJQAF=@OpãªXJ9H$XJ/OK<?X à H"@9J9ã?LH$Y F=X OpãªX+YSH$X+@9H$Yâxã?L!^ <?X+Y^<?Y+HU<$îW<?F=;=<WàÇ;IHJ9ãNJQSHU<?OpJ9ã?L TQSH$XXSHKH$YSH$YômFeêH?êzJQ+HU<?OpJ9ã?LOK<?X½LHKî»Fé@FIJJQSHUãª;=Y0OpãªXJ9H$X¹J TQ+H$XSHKî?HKLJQ+Fé@@9HKH$^@`J9ã à H XSH$OpH$@@!<WLå?ê$³;é<?@@F=OK<?;³à+L!ãzT@9HKLR@íãªX+;Iåõ+Lãî»FéYSH[< @9J9L!FéOpJ;Iå @H>SH$XJF=<?; oàA<?O"! àA>+J9J9ãªX[âxã?LJQ+F=@ !»F=XAYìã?â QAF=@9J9ã?Låì^<?X+<Wè?H$^íH$XJKê \8QSH/õ+L!HpBEOpãªX¹J9HPJã?â<@!OpH$XSH0JQ»>+@OpãªXJ<?F=X+@<?;=;îW<?;=>+<WàA;=HOpãªX¹J9H$XJ"JQ+<WJF=@0Opãª;=;IH$OpJ9H$Y Y+>SL!F=X+èì< @9J9ã?Lå?ôk<?X+Y èª>+<WLR<?X¹J9HKH$@½JQSH<$îW<?F=;=<WàAF=;éFIJEå ã?âJQ+F=@OpãªXJ9H$X¹JTQSH$X[X+HKH$YSH$Yê

\8Q+HNõ ãª@9JCBE@!OpH$XSH0OpãªXJ9H»JOpãªXA@F=@9J@ã?â <"õ ã?J9H$X¹JFé<?; õA;=<$å?ãª>+Jã?âk@OpH$X+H$@JQ+<WJOK<?X]à HGH$XJ9HKLH$Y[<WâxJ9HKLJQSH³OK>SLL!H$X¹Jk@OpH$XSH?êmárâ+<?X"<?OpJ9ã?LXSHKH$Y+@k@9ãª^íH³F=XSâxã?L!^<WJFIãªX0ãªX0JQ+HXSHPJ <?OpJFIãªX+@KômJQSH$XJQ+F=@OpãªXJ9HPJF=X+âuã?L!^`<WJFIãªXÒK<?Xà H>+@H$Yê¹\8Q+Fé@(F=XSâxã?L!^<WJF=ãªX`F=@(îm<?;=>A<WàA;IHâxã?LJQSãª@9HG<?OpJ9ã?L!@TQSãFéX¹J9H$X+YäJ9ã"YSLã?õãª>SJ0ã?âUJQSHä@9å»@J9H$^]ê,áhJ/F=@/<?;=@9ã[<[õA<WLJã?â³JQSHQSH$;Iõ F=XSâxã?L!^<WJFIãªXê\8Q+H½õ ãª@9JCBE@!OpH$XSHÒpãªXJ9H»J"OK<?Xà HGH$XSL!F=ORQSH$Yàå^íHKJ<mBEY+<WJ<Y+H$@OpL!FIàAFéXSè0JQSH/OpãªXJ9H$XJ8JQ+<WJ8F=@õ+Lãî»FéYSH$YìF=XJQSHXSH»J@9J9HKõÇ@ã?LJQSH


Y+<WJ<[J9ã]àH"õ+L!ã»Y+>AOpH$Y àå JQSH<?OpJ9ã?L$êáCX JQ+F=@GOK<?@9H?ô<?X F=XJ9H$;=;=FIè?H$XJF=X¹J9HKL!âx<?OpH^<zå âuã?LH$OK<?@J/JQSHF=X+âuã?L!^`<WJFIãªX]XSHKH$Y]âxã?L8â>SLJQSHKL8@9J9HKõÇ@ã?â JQSH0@9J9ã?Lå»à ãª<WL!Yê

U<?O!Q[@OpH$X+H/^<$å<?;=@9ã"à HNH$X+L!F=O!Q+H$Yäà»åä@!>Sõ HKL!F=^íõ ãª@9H$Yä^íHKJ<mBEY+<WJ<íãªXìJQSH@OpH$X+H?ôSTQ+F=ORQFéX+OK;=>+YSHHKî?HKLå»JQ+F=X+è JQ+<WJ"Opãª>+;=Y à H`LHKâxHKLH$X+OpH$Y TFIJQ+FéXðJQSHH»õ H$OpJ9H$YOpãªX+@>+^H$Y <?X+Y õ+LãPY+>+OpH$Y Y+<WJ<Pê\UåõÇF=OK<?;@>+ORQðLHKâxHKLH$X+OpH$@<WLHÒpãª;=;=<Wà ã?L!<WJFéXSè]<?OpJ9ã?L!@KôL!HKJ9L!FIHKîW<?;ã?L>SõY+<WJ9HíY+<WJ< ã?âUJQ+HÒK>SLLH$XJOpãªXJ9H$X¹JKô»<?X+YYSHKJ<?Fé;=@ J< !?H$XâxLãª^JQSH8;Iã?èã?âJQSHOK>+LLH$XJ @J9ã?Lå?ê F=X+<?;=;=å?ômJQ+H8@OpH$XSHOpãªXJ9H»JU^<$åF=XAOK;=>+YSH<?Y+^`F=X+F=@9J9LR<WJFIî?H(Y+<WJ<G@>+ORQ<?@ F=Y+H$X¹JFIöÇOK<WJFIãªX/ã?âAOpãªXJ9H$XJ OK>+LLH$XJ;Iå/>+X+YSHKLkOpãªX+@F=Y+HKL!<WJFIãªXêMPOpH$X+HOpãªXJ9H»JF=@UH$X+Q+<?X+OpH$Y`àåíè?H$X+HKL!F=ON@OpH$XSHFéXSâuã?LR^<WJFIãªXôªTQ+F=O!QäOK<?X`à HàA<?@9H$YäãªXäF=XJ9H$XJFIãªX+@ã?â,JQ+H Þ á9MêSã?LF=X+@9J<?XAOpH?ô<?YSî?HKLJ@³^<zåà H<WJ9J<?O!Q+H$Y]J9ã0H$<?ORQìã?âJQSHN@!OpH$XSH$@KêPDHKâ<?>+;IJF=XSâxã?L!^<mBJFIãªX @9HKL!î?H$@N<?@G<?XHSOpHKõ+JFIãªXðQ+<?X+YA;=F=XSèíâxã?L@OpH$XSH$@KêárâUOpãªX¹J9H$XJã?LGâx>+XAOpJFIãªX+@<WL!H"OK>+LLH$XJ;Iå[XSã?J<zîm<?F=;é<WàA;IH?ôSJQSH$X[Y+HKâx<?>+;=J8Y+<WJ<<WLH/õALãzîPF=YSH$Yê

a 0n4[8C% BX&[8C ! [ \8QSHN@9å»@J9H$^ OpãªXJ9HPJ³Fé@UYSHKJ9HKLR^F=XSH$Y`àåJQ+HNOpãªXJ9H$X¹J<?X+YäJQSHNâx>AX+OpJFIãªX+@(JQ+<WJ<WLH/õALãzîPF=YSH$Yìà»åäJQ+H/TUHKà F=XSâxã?L!^<WJFIãªX]@9åP@9J9H$^]êSáhJOpãªX+@!F=@9J@ã?â <WJ;IH$<?@9JJQSH/âxãª;=;IãzTF=XSè½âuãª>SLõA<WLJ@Kÿa X6lkp1UC24& ( 2 0l Kn [ KX & b MPãª>SL!OpH]<?X+Y<?O>AF=@FIJFIãªX F=@"<?X ã?LJQSã?è?ãªX+<?;Y+F=^íH$X+@!FIãªX ã?âJQSH Þ áMê

Ý Þ á9M F=@/@>SõAõã?L!J9H$Y àåð^íH$Y+Fé<ìã?à<;CH$OpJ@JQ+<WJ/à H$;IãªX+è]J9ã ^íH$Y+Fé<ìJEå»õH$@<?@/THTF=;é; H»õA;=ã?LHF=XYSHKJ<?Fé;F=XõA<WLJGááá~êÇáCXð<ìX>+J@QSH$;=;eô <]^íH$Y+Fé<`ã?à<;9H$OpJ/F=@YSHKöÇXSH$Yàå<?X H»J9H$X+Y+H$Yðî»F=HKT ãªX @9ãª^íH>+XAYSHKL!;IåPF=XSèY+<WJ<WàA<?@H?ô¹TQ+FéO!QÒK<?XäJQSH$Xä@9HKLî?Hâxã?L(õALãzîPF=@FIãªXã?â,OpãªX¹J9H$XJ<?XAYâ>+X+OpJFIãªX+<?;éFIJEå½ã?â,<?XH$;IH$^H$X¹J<WLå½@OpH$XSH?êª\8Q+HY+<WJ<WàÇ<?@9H$@>+@9H$Y½âxã?LkJQ+Hè?H$X+HKL!<WJFIãªX"ã?âAOpãªXJ9H$X¹J(âuã?L!^ JQSHOpãªXJ9H»Jã?âÇJQSH@OpH$XA<WL!FIãSê Þ H`^<zåð<?@@9ãPOKF=<WJ9HTFIJQH$<?ORQ @OpH$X+<WLRFIã]JQSH@>SàÇ@O!QSH$^`<WJ<ìã?âUJQSH$@H`Y+<WJ<WàA<?@9H$@/JQ+<WJ<WLH>+@H$Y`âxã?Lè?H$XSHKL!<WJFIãªXã?âkOpãªX+@>+^íH$YY+<WJ<½ã?Lâxã?L³FéX¹J9HKè?L!<WJF=ãªXäã?âkY+<WJ<½õ+LãPY+>+OpH$Yäàåä<?OpJ9ã?L!@F=XJQSH@OpH$X+<WL!FIãSê

nonoX 2[jC ( UX &[8C'&[Wb \QSHäY+<WJ< JQ+<WJ½<WLH>A@9H$Y âxã?L½OpãªXA@>+^íH$Y <?X+Y õ+L!ã»Y+>AOpH$Y F=XSâxã?L!^<WJF=ãªX YSãXSã?JäHPFé@9J`F=X Fé@9ãª;=<WJFIãªXê\QSHKå <WLH >+@>A<?;=;Iå <?@!@9ã»OKFé<WJ9H$Y TF=JQ ã?JQSHKLìY+<WJ< ãªX JQSH[àA<?@Fé@íã?â/F=XPBJ9HKè?L!F=JEå OpãªX+@J9L!<?F=XJ@/ã?L½HPF=@J9H$X+OpHäOpãªX+@J9L!<?F=XJ@KôF=X õA<WLJF=OK>A;=<WL/HSF=@9J9H$X+OpHOpãªX+@9J9L!<?F=XJ@0<WL!Häã?âxJ9H$XXSã?J½HPõA;=F=OKFIJ;=å LHKõALH$@9H$XJ9H$Y <?@"@>+ORQôkàA>SJ0<WLHH$^àH$YAYSH$Y FéX¹J9ã JQSHYA<WJ<WàA<?@9Hì@O!QSH$^`<WJ<>A@9H$YêSã?LF=XA@9J<?X+OpH?ô+TH½>A@>+<?;=;Iå<?@@9ãPOKF=<WJ9H½TFIJQ]ã?à<;9H$OpJ@GOpãª;=;IH$OpJ9H$YF=X[L!H$;=<WJFIãªX+@QAFIõ[OK;=<?@@9H$@JQSãª@9H½ã?àSB;9H$OpJ@8Opãª;=;IH$OpJ9H$Y F=XJQSH/Opãª^íõ ãªXSH$XJ8OK;=<?@@9H$@³ãªXìTQAF=O!QìJQSHKå<WLHàA<?@9H$Y,ê»áCXìJQ+F=@³OK<?@9H?ôATUH/<?@@!>+^íHJQ+<WJ`ã?à<;CH$OpJ@`F=X Opãª^íõ ãªXSH$XJOK;=<?@@9H$@íã?âNJQSH]LH$;é<WJFIãªX+@Q+F=õ Jråõ H[OpãWBsHSF=@9JTF=JQã?à<;CH$OpJ@`F=XJQSHLH$;é<WJFIãªX+@Q+F=õOK;=<?@@Kê Þ HNXSHKH$YäJ9ãOpãªXA@F=YSHKLUJQSHH$Xî»F=LãªX+^íH$XJ(ã?â,OpãªXJ9H$X¹JJQ+<WJ³F=@(OK>+LLH$XJ;Iå½>AX+YSHKLOpãªX+@!F=YSHKL!<WJFIãªXìJ9ã?è?HKJQ+HKLTF=JQìJQSH0Y+<WJ<íJQA<WJ<WLH0<?@@ã»OKF=<WJ9H$Y TFIJQìJQ+Fé@OpãªX¹J9H$XJKê

a0l ! ! X>pj[8C'( Z l & N[ X & 24# K[db +>+X+OpJFIãªXA@@>+õ+õ ã?LJF=XSè[JQ+H<?OpJFIãªXA@½FéX @OpH$XA<WL!FIãª@½<WLHìõ+LãzîPF=YSH$Y àåJQSH Þ áMê¹\8Q+H$@9H8â>+X+OpJFIãªX+@QA<$î?HJQ+H$FILãzTXÒpãªXJ9Lãª;+H$Xî»F=LãªX+^íH$XJKê¹\UåõAFéOK<?;S@>+O!QäOpãªX¹J9L!ãª;A^íH$ORQPB<?X+Fé@^@<WLH0;=ã?è?èªF=XSèSô+OpãªX+OK>SL!LH$X+OpåìOpãªX¹J9Lãª;sôA<?X+Y]LH$Opãî?HKLå[^<?X+<Wè?H$^H$X¹JKê

a C Wlkp [db M»H$OK>SLRFIJEå OpãªX+OpHKõAJ@]YSH$@OpL!FIà H >= Kú Çøä<?X+Y Kú~û ø ù æ !?HKå»@$ô³<?>+JQSH$X¹JFéOK<WJFIãªXô@F=èªX+<WJ>SLH$@KôXSã?J<WL!F=@<WJF=ãªXôzLãª>+JF=XSè8OpãªXJ9Lãª;eôW<?OKOpH$@@ OpãªX¹J9Lãª;sôY+<WJ<NF=XJ9HKè?L!FIJEå?ôm<?X+Y/J9LR< ÒõA<?YAY+F=XSèçâxã?LY+<WJ<íHSO!QA<?XSè?H?ê

@ C' "! X6p124# iX &[8C ! [ \8QSH"J9H$^íõ ã?L!<?;OpãªXJ9H»J½<Wõ+õ H$<WL!@/F=X <[X»>+^à HKLã?âUîW<WL!F=<?XJ@KôH?êèSê@9J9ã?LR<Wè?HJF=^íH?ôPîW<?;=F=Y+F=JEåJF=^H?ôPYAF=@9õA;=<zåíJF=^íH?ôS>+@9HKLBEYSHKöAXSH$YJF=^íH?ôPJ9L!<?XA@<?OpJFIãªX]JF=^H?ô»HKJOWê+\QSHGJ9H$^íõ ã?L!<?; OpãªXPBJ9HPJF=@<Wõ+õÇ;=F=OK<WàA;IHF=X]<`X>+^à HKL8ã?â Opãª^0àAFéX+<WJFIãªX+@KêÇMPãª^íHKJF=^íH$@FIJ8F=@8XSH$OpH$@!@<WLåìJ9ã`>+@9H/<?;é;ã?â JQSH$^]ôàA>SJã?âxJ9H$X[FIJ8Fé@ã?âuJ9H$X ã?àA@9HKLî?H$Y[JQ+<WJ8ãªX+;IåãªXSHîW<WL!F=<?XJ8ã?âkJQ+F=@OpãªXJ9H»JGF=@XSH$OpH$@@!<WLå?ê

HKL!@!FIãªX+@@QSãT JQSH8;=F=âuH³Opå»OK;=Hã?âÇJQSHã?à;CH$OpJ@>AX+YSHKLOpãªX+@F=Y+HKL!<WJFIãªXê Ý @@OpH$X+<WL!F=ãª@ TF=;=;»Q+<$î?HJQSH$FILãzTX ;=FIâxH[Opå»OK;=H]TUH OK<?XAXSã?J`<?@@>A^íH]JQ+<WJ`Y+<WJ<WàÇ<?@9H ORQ+<?XSè?H$@`<WL!H Y+FILH$OpJ;=å H$XSâxã?L!OpH$Y ãªX TUHKàA@!FIJ9H$@Kê ã?LHKãzî?HKL$ô FIJ8^<zåìàH>+@HKâx>+; J9ã`õ+LãzîPF=YSHJQ+Hãª;=Y[OpãªXJ9H$X¹JN<?@;IãªXSè<?@<?X <?OpJ9ã?LOpãªXJF=X»>SH$@8TFIJQìJQSH@<?^íH@9J9ã?Lå?ê HKL!@!FIãªX+@8OK<?X ã?âuJ9H$X]à H/@9åP@9J9H$^<WJFéOK<?;=;Iåì@9J9L!>+OpJ>SL!H$Yìàå þªý?øsýüým÷÷Rûm÷~ø 6= ým÷p÷?ÿ


\8Q+H ø ý ý?ø ù >= ým÷[õ HKL!^FIJ@0JQSHY+HKî?H$;Iã?õA^íH$XJã?âã?à<;CH$OpJ@"@9J9ã?LRF=XSè FéX+FIJF=<?;FéXSâuã?LR^<WJFIãªXêáCX¹J9HKè?LRFIJEå]OpãªX+@9J9LR<?F=X¹J@<WLH/<Wõ+õA;éF=OK<WàA;IHF=X]<í;=Fé^FIJ9H$Yâuã?LR^]ê

\8Q+H ú9ù$þ $ø ù 6= ým÷F=@JQSH½OpH$X¹J9LR<?;õAQA<?@9H?ô+TQ+FéO!Q[OpãªX+@!F=@9J@8ã?â L!>AX¹JF=^H >+HKLå»FéXSèSô+^íãPY+FIöAOK<mBJFIãªX,ôSJ9L!<?X+@<?OpJFIãªX ^<?X+<Wè?H$^íH$XJKôAHKJOWê

\8Q+H íý Aø Çý >= ýW÷NF=@>+@H$YíF=X½õ+LãPY+>+OpJFIî?HY+<WJ<WàA<?@H<Wõ+õA;=FéOK<WJFIãªX+@kâuã?LUOK;=<WL!FIöAOK<WJF=ãªXã?â@9ã?âxJOpãªX+@J9L!<?F=XJ@Kôª^<?F=XJ9H$X+<?X+OpH³ã?â OpãªX+@9J9L!<?F=XJ@ JQ+<WJQ+<zî?Hà HKH$XíOK>SJ ãª>SJâuL!ãª^ LR>+X¹JFé^íH^`<?F=X¹J9H$XA<?X+OpH?ô<?X+Y½O!QA<?XSèªF=XSèJQSH@J9L!>+OpJ>SL!FéXSè<?X+Y0âx>+XAOpJFIãªX+<?;=FIJråGã?â+JQSH(H$XJFILH³Y+<WJ<WàA<?@H@9åP@9J9H$^]ê <?F=X¹J9H$XA<?X+OpHõAQA<?@9H$@0<WLHä>+@9H$Y FéX Y+<WJ<[T³<WLH$QSãª>A@9H`<Wõ+õA;éF=OK<WJFIãªX+@Gâxã?L0LH$ORQ+<WLèªF=X+è JQSH`YA<WJ<[T³<WLH$QSãª>+@9H`TFIJQ<?OpJ>+<?;F=XSâxã?L!^<WJFIãªX,ê

\8Q+Hý?ú = 87 >= ým÷Fé@>+@9H$Y½âuã?L<WLRO!Q+FIîPF=XSèNJQSH8OpãªXJ9H$X¹J(ã?âÇ<Y+<WJ<WàA<?@H8F=X"<Gâuã?L!^JQA<WJ YA<WJ<GLH$;|BHKîW<?X¹J(âuã?L(QAF=@9J9ã?L!F=OK<?;SFéXSâuã?LR^<WJFIãªX"OK<?Xà H³H$<?@F=;IåLHKJ9L!FIHKî?H$Y,êãY+<WJ<^íãPY+FIöAOK<WJFIãªXíFé@ õHKLR^FIJ9J9H$Y(JQSH0ãªX+;Iåä^ã»Y+F=öAOK<WJFIãªXìã?õ HKL!<WJFIãªX[Fé@³J9ã`;Iãª<?Y[XSHKT O!Q+<?XSè?H$@J9ã`JQSH/<WLRO!Q+FIî?H?ê

C ! pjCqnoC%&[ 2[ X & X6Z iX &[8C ! [8n Þ H`^`<$åðXSãzT3Opãª^0àAFéXSHíJQ+F=@OpãªXJ9H»J½F=XSâxã?L!^<WJFIãªX >+@!F=XSèìJQSHâxãª;=;IãzTF=XSèí@9H$^F|Bsâxã?L!^<?; J9H$^õA;=<WJ9H?ÿ

! ÿ )OpãªX¹J9HPJNXA<?^íH,+B@ #"! ! ÿ ) NH$XSHKL!<?;OpãªX¹J9HPJ:+

1 (!/ (! ÿ )xè?H$XSHKL!<?;Y+H$@OpL!FIõ+JF=ãªX0+-@/! 7 9(60"! (! ÿ )xH»õ H$OpJ<WJFIãªX+@3+1 %=%/!92P'0! ("! @ ÿ )OpãªX+YSH$X+@<WJF=ãªX+@<?X+Y]<WàÇ@9J9L!<?OpJFIãªX+@3+1 2 5 <".D ("! @ ÿ )@Opã?õ H,+E' #,9' (! ÿ )xè?H$XSHKL!<?;Y+H$@OpL!FIõ+JF=ãªX0+ >0'"/'(6/ #'"0! ÿ )xè?H$XSHKL!<?;Y+H$@OpL!FIõ+JF=ãªX0+

!"/ 5 !'/C (! ÿ )xè?H$XSHKL!<?;Y+H$@OpL!FIõ+JF=ãªX0+-@/#@( ("! @ ÿ )Q+F=@9J9ã?Låã?â>+@<Wè?H,+-! #69#("9 (! ÿ )xõã?J9H$XJF=<?;OpãªX¹JF=X»>+<WJFIãªXD+("9 ("!@ ÿ )@>Sõ HKL!F=^íõ ãª@9H$Yì^íHKJ<mBEYA<WJ<+

D (! ÿ )xè?H$XSHKL!<?;Y+H$@OpL!FIõ+JF=ãªX0+!./ (" '69C '(".D#0! ÿ )@9å»@J9H$^ H$Xî»FIL!ãªX+^íH$XJ:+1 #=#!(="'"C (! ÿ )OpãªX¹J9H$XJH$XîPFILãªX+^íH$XJ:+6.=%=%9!/@@C ".@P( "!0' ÿ )xâx>+XAOpJFIãªX]H$Xî»FIL!ãªX+^íH$XJ:+9(,./06 ÿ )xLH>AFILH$Y]@9H$OK>SLRFIJEåìâ>+X+OpJFIãªX+<?;éFIJEå9+

;62% !/' ("! @ ÿ )xè?H$XSHKL!<?;Y+H$@OpL!FIõ+JF=ãªX0+/D#"!P,< ÿ )xè?H$XSHKL!<?;Y+H$@OpL!FIõ+JF=ãªX0+?8 !%2D %=>0'# ÿ )xè?H$XSHKL!<?;Y+H$@OpL!FIõ+JF=ãªX0+

-@/!"80C=/ ("! @ ÿ )xè?H$XSHKL!<?;Y+H$@OpL!FIõ+JF=ãªX0+?8 !% "/ ("!@ ÿ )xè?H$XSHKL!<?;Y+H$@OpL!FIõ+JF=ãªX0+4 /<'P=#"'0"!0' '69C #!(="' (! ÿ )xè?H$XSHKL!<?;Y+H$@OpL!FIõ+JF=ãªX0+F'9#@C 4 ÿ ) \YST W:IK:T3KON Z &G Z6\YSUZ+F'9#@C 4 ÿ ) KOW3T3V I SUZ6K3+F'9#@C 4 ÿ )U[=T3V0T:I\ GJIKL=KONPIQ=R@SUT3VPW3T +F'9#@C 4 ÿ ) X*SYKKS Z6VPN[=ZI\YK:+

KZ[6& C%# 2[ X&kn ³ãªX¹J9HPJ(HKî?ãª;Iî?H$@Uâxã?LU<?OpJ9ã?L!@Kô»@OpH$X+<WL!F=ãª@Kô¹@9åP@9J9H$^@Kô<?X+Yíãzî?HKLJF=^íH?ê Þ H^íãPYSH$;JQSH[L!H$;=<WJFIãªX à HKJETHKH$X YAFHKL!H$X¹JOpãªXJ9H»J@à»å 7~ø ú ý?ø ù S÷?ê (Lã?õ HKLJFIH$@íJQ+<WJä<WLH[îW<?;=F=Yâxã?Lä<


OpHKLJ<?F=XOpãªXJ9H»J/^<zå[à H;=F=âuJ9H$Y]J9ã]<?XSã?JQ+HKLNOpãªXJ9H»JKê,\Q+F=@J9L!<?XA@9âuHKLGOK<?Xà H0àA<?@9H$Y ãªX;Iã»OK<?;k^íãPYSH$;@9H$^<?XJF=OK@Kê

Sã?L"JQ+Fé@LH$OK<?;=;UJQ+<WJ< OpãªX¹J9HPJíF=@0Y+HKJ9HKL!^F=XSH$Y àå <?OpJ9ã?L$ô @9J9ã?Lå»à ãª<WL!Yôk@9å»@J9H$^<?X+Y J9H$^íõ ã?L!<?;OpãªXJ9H»J@KêMPã;=HKJ Y+H$XSã?J9H JQSHð@9HKJìã?â<?OpJ9ã?L!@Kô JQ+H @HKJã?â@OpH$X+<WL!FIãª@$ô JQ+H @HKJã?â½@9åP@9J9H$Ô!QA<WL!<?OpJ9HKL!F=@9JFéOK@KôÇ<?X+Y3JQ+H0@9HKJ8ã?â JF=^íH>+X+FIJ@KêS\8Q+H$X]TUH½OK<?X[J< !?H½<`@>SàÇ@9HKJ J9ãíLHKõ+L!H$@9H$X¹J8<í@HKJ8ã?âkOpãªXJ9HPJ@Kê+>SL!JQSHKL!^íã?LH?ôSTH/>+@9H/<"â<?^F=;=åã?âkOpãªXJ9HPJ@ 0<?X+Y[<â<?^F=;Iåìã?âU@J<WJ9H$^íH$X¹J/@HKJ@"æxã?LGJQSHKã?LRFIH$@Rç "! #$%íJQ+<WJG<WLHí<?@@9ãPOKF=<WJ9H$YTFIJQ JQSH$@9HíOpãªXJ9H»J@KêëGâOpãª>SL!@H?ô+JQSHJQSHKã?Lå&! YSH$@OpLRFIà H$@³JQSHõ+Lã?õ HKLJFIH$@³ã?â JQSH/OpãªXJ9HPJ' ê

ëGXäJQSH$@9Hè?Lãª>+X+YA@THN^<zå`>+@9HN;IãPOK<?;A^íãPYSH$;=@( *) + âuã?LH$<?O!Qã?â,JQ+H$@9HN@J<WJ9H$^íH$X¹J@9HKJ@<?@@>A^F=XSèJQ+<WJ³JQSH/^íãPYSH$;=@UTH/OpãªX+@F=YSHKL³<WLHH$X»>+^íHKL!<WJ9H$Yìà»å`JQ+HG@H$OpãªX+Y]F=X+YSH ê ã?LHõ+L!H$OKF=@9H$;Iå?ô»JQSH^íãPYSH$;=@(,-) +YSHKJ9HKLR^F=XSHJQ+H^íH$<?XAF=XSè ã?â8OpãªXJ9H$XJ"Y+L!<$TX âxLãª^#<;=<?XSèª>A<Wè?H/.âxã?L½Y+H$@OpL!FIàAFéXSè[OpãªX¹J9H$XJíF=XîPFIHKT ã?âUOpãªX¹J9HPJ0 ê\8QA<WJNF=@$ôATH½>+@H½<õA<WLJFé<?;^<Wõ+õÇF=XSè21 ÿ.3 $465#ôTQSHKL!H75 YSH$XSã?J9H$@<@9HKJ8ã?âkõ+LHpBEY+HKJ9HKL!^F=XSH$Y]^H$<?X+F=XSèª@âxã?LOpãªXJ9H$X¹JNF=X&.ê

Þ H^<zåX+ãzT&Y+F=@JF=XSèª>+F=@!Q]JQSHíâxã?L!^>A;=</8 ã»OKOK>+LL!F=XSèìOpãªXJ9H»J7 âuL!ãª^ JQ+H@<?^íH"âuã?LR^>+;é<`ãPO~BOK>SLLRF=XSè F=X <?XSã?JQSHKLíOpãªXJ9H»J"à»å OpãªX+@F=Y+HKL!F=XSè[JQ+HOpãªXJ9H»JíF=XAYSH$ôkFsêH?êTHOpãªXA@F=YSHKL½õA<?FIL!@æ98;:<CçRê%F=âuJF=X+è½L!H$;=<WJFIãªX+@OK<?X àH/^ã»YSH$;é;IH$YàåL!>+;IH$@³ã?â JQSHâxã?L!^

æ98 V :< V ç mæ98>=?:<@=+çæ98:<hç A

@9J<WJFéXSèJQ+<WJJQSHâxã?L!^½>+;=<WH/æ98 V :< V ç æ98 = :< = ç OK<?Xíà H;=FIâxJ9H$Y"J9ã`æ98:<hç>+XAYSHKL JQSH8@F=YSHOpãªX+YAFIJFIãªXA êáhX<?Y+YAFIJFIãªXôk<Opãª^õA<WJFIàAF=;éFIJEåðLH$;é<WJFIãªX<?^íãªXSè ;IãPOK<?;³^íã»Y+H$;=@Fé@½FéX¹J9LãPY+>+OpH$Y@Fé^F=;=<WLJ9ã ;=ã?èªF=OK@JQ+<WJ8OK<Wõ+J>+LHõ ãª@@FIàA;=HTã?L!;=Yì@9H$^<?XJF=OK@Kê+\8QAF=@UOpãª^õA<WJFIàAF=;éFIJEåL!H$;=<WJFIãªX]F=@³>+@9H$Yìâxã?LH$XJ<?F=;=^íH$XJ8<?X+Y@<WJF=@öA<WàAF=;=F=JEå?êª\8Q+Fé@<Wõ+õ+Lãª<?ORQ`<?;=;=ãzT@U>+@J9ãLH$<?@9ãªX;Iã»OK<?;é;Iå½<?XAYJQSH$X`J9ã0J9L!<?X+@âuHKLUJQSH !PXSãzT;IH$YSè?H8THèª<?F=XSH$Y[J9ãã?JQSHKLOpãªXJ9HPJ@Kê

Z³<?@9H$YãªX JQ+F=@Opãª<WLR@9H½OK;é<WL!FIöAOK<WJFIãªX ã?âàA<?@F=OXSã?J<WJFIãªX TUH"YSHKî?H$;Iã?õ <`X»>+^à HKLã?ââ<?OKF=;=FIJFIH$@<?X+YHPJ9H$X+Y]JQSH0@õH$OKF=öAOK<WJFIãªXìã?â JQSH Þ á9Mÿ

iX &[8C ! [ n ! 2 WC>b \8Q+H !ù Aø Aø !ù Çø ªø÷ ýF=@YSHKöAXSH$Y"ãªXJQSH8àA<?@Fé@ ã?âJQ+H8OpãªX¹J9H$XJ; ô¹@OpH$X+<WLRFIãª@ <?XAY]<?OpJ9ã?L!@BêPáhX P<?^íõÇ;IHGò/TUH/Opãª>+;éY>A@9HF=XSâxã?L!^<WJFIãªXãªXìJQSHJ9L!<zî?H$;,<?X+YìãªX]JQ+HG<?F=L!;=F=XSHJ9ã HSOK;=>+YSHã?õ+JFIãªX+@½JQ+<WJ"@9HKH$^ J9ã à H;=H$@@;éF !?H$;Iå?ê \8QSHìOpãªX¹J9H$XJOpãªX¹J9HPJ@9õA<?OpHìã?â< Þ á9M âxã?L<ìèªFIî?H$XðOpãªXJ9H$XJCBE^íH$<?X+F=XSè]õÇ<?FIL CD:<E çNOpãªXA@F=@9J@Gã?âUõ+LH$OKF=@9H$;=å[JQSãª@9HíOpãªXJ9H»J@Kô>+X+YSHKLGTQ+FéO!QJQSHõA<WL!JF=OK>+;=<WL8OpãªXJ9H$X¹JTF=;=; Q+<zî?H/JQ+<WJ8õÇ<WLJF=OK>+;=<WL8^H$<?X+F=XSèSô+FeêH?ê

F æGC:<E çHIæGJK: L:<MN:<OçB,1æGC:zæGJK: P:<M0:<O9ç9çHQER Ý Y+<Wõ+J<WJFIãªX ã?âOpãªX¹J9H$XJKôÇâ>+X+OpJF=ãªX+<?;=FIJrå?ô+<?X+Y[@OpH$X+<WLRFIãª@8J9ãäJQSH0OpãªXJ9H»JNJQ+<WJF=@OK>SLLH$XJ;Iåì<$îW<?F=;|B<WàA;=HF=@UàA<?@9H$YäãªX Rù Aø ªø o7÷ ù ê Ý õAõA;IåPF=XSèJ9L!<?X+@âuã?L!^`<WJFIãªX`LR>+;IH$@THORQ+<?XSè?HOpãªXJ9H$X¹JKôSâ>+X+O~BJFIãªXA@Kô»<?XAY`JQSHNõ+LH$@H$X¹J<WJFIãªX,ê»\8Q+HKLHKâuã?L!H?ôTHN>A@9HN<½OpãªXJ9H»J8@9õ H$OKFIöÇOK<WJFIãªX`âxã?LJQSHYSHKî?H$;Iã?õA^íH$XJã?âUH$XSâuã?LROpH$^íH$X¹JGL!>A;IH$@Kê \8QSH$@9H½L!>+;IH$@N^<zå LH$@9J9LRF=OpJN@!OpH$X+<WL!FIãª@NJ9ã[^íã?LH"@9õ H$OKFIöAO0ãªXSH$@Kô HPJ9H$X+Y ã?L@Q+L!F=X&!ÒpãªXJ9H$XJKô<?X+YìHPJ9H$X+Y ã?L8LH$^íãî?H0â>+X+OpJFIãªX+@$ê

KZPC 2 noC C ! [8C%&kn X& 24& ( n ! C' 24# n 2[ X & b \8Q+H`è?H$XSHKL!<?;;=FIâxHÒK<?@9H]@9õ H$OKFIöÇOK<WJFIãªX OK<?X ã?âxJ9H$X à H@9õ H$OKF=<?;éF=@9H$YôPFIâOpãªXJ9HPJNF=@³HPõA;=FéOKFIJ;Iå`F=X ;CH$OpJ9H$Yê Þ HXSHKH$Y]à ã?JQ]JQSH/^íã?L!Hè?H$XSHKL!<?;;éFIâuHGOK<?@9H$@N<?X+YJQSHNOpãªX¹J9HPJ>+<?;=Fé@9H$YãªXSH$@Kê Þ QSH$XSHKî?HKL³JQSH Þ áM`F=@LHKîPF=@9H$Y`ã?LUHPJ9H$X+YSH$Y,ôTHOK<?XLHKJ>SLRXJ9ã"^íã?LHè?H$XSHKLR<?;;=F=âuH/OK<?@9H$@N<?X+Y è?H$XSHKL!<WJ9H"<?XSã?JQSHKLOpãªXJ9HPJ>+<?;=F=@<WJF=ãªXêÇ\UåõÇF=OK<?;@9õ H$OKF=<?;éF=@<WJFIãªX+@OpãªXAOpHKL!XORQ+<?XSè?H$@FéXäJQ+H/;=FIâxHNOK<?@9H +ãzT/ê Þ H^<$åì@9õ H$OKF=<?;=F=@HJQSHY+<WJ<ÒpãªX+@>+^íH$Yìà»åä<?X <?OpJ9ã?LF=XìYSHKõ H$XPBYSH$XAOpHã?âJQSH/<?OpJ9ã?L o@OpãªXJ9H»JKêÇárâTUH !PXSãzT JQ+<WJ8<?OpJ9ã?L!@X+HKH$Y]@9õ H$OKF=<?;<?> SF=;=F=<WLåFéXSâuã?LR^<WJFIãªXã?LOpãªXî?HKL!@9H$;Iå]<?OpJ9ã?L!@à H$OK<?^íH0^íã?LH !PXSãT;IH$YSè?H$<WàA;=H/Y+>SL!F=X+èJQSH>SJF=;=F=@!<WJFIãªX`ã?â JQSH Þ áMô+JQSH$XìTH

qEc!~8c!tsloCd,!yÇ$tsRqegz?~c!qElojy|!q´½fCNwujyµRqs8c!tsloRj/$gzdtsfCd wmidscRRfjWc!gdelod §^<zåð<?Y+<Wõ+J/JQSHYA<WJ<]õ+Lãî»F=Y+H$Y âuã?L0OpãªXA@>+^íõ+JF=ãªXê Ý J/JQSH`@<?^HJF=^íH?ôTH`OK<?X @9õ H$OKF=<?;éF=@9H"JQSHö+èª>+LH$@³<?OKOpã?L!Y+F=XSè"J9ãíJQSHGèªFIî?H$X]OpãªXJ9HPJKê+áhXJQSH@<?^HNT³<$åì@9õA<WJFé<?;<?XAYäJ9H$^õã?LR<?;F=XSâxã?L!^<WJFIãªXõ+L!ãzîPF=YSH/<"àA<?@Fé@âuã?LLHKöAXSH$^íH$XJã?â;=FIâxHOK<?@9H$@Kê%FIâuHGOK<?@9H$@^<zå`à HNH»J9H$X+Y+H$YìJ9ã½L!H>+F=LH$^íH$XJ@UJQA<WJTHKLHOpãª;=;IH$OpJ9H$Y]FéX`JQSHOpãªXJ9H»J8@õA<?OpH?êS\8QSHOpãªXJ9H$X¹JOpãªXJ9HPJ^<$å LH>AFILH`< ^íã?LHH$;=<Wà ã?L!<WJ9H$YOpãªXJ9H$X¹JíJ9ã à H`õ+L!ãzîPF=YSH$Yêk\8QSHì@>Sõ+õ ã?LJ9H$Yâ>+X+OpJFIãªXA<?;=FIJEå]^<zå[LH»>+FILH<?Y+Y+FIJFIãªXA<?;âx>AX+OpJFIãªX+@KôÇOpãªX¹J9H$XJKô ã?LN<@9õ H$OKFIöAOõALH$@9H$XJ<WJFIãªXêáhXJ9H$XPBJFIãªXA@½^`<$å àHì^íã?LH]@9õ H$OKFIöÇO`>+X+Y+HKL"OpãªXA@F=YSHKL!<WJF=ãªX ã?âNOpãªX¹J9HPJKê Sã?L`FéX+@9J<?X+OpH?ôFIâTH]T<?XJ"J9ã@>+õ+õ ã?LJ<ðOpHKLJ<?FéX >A@<Wè?H]ã?â< Þ á9M JQ+<WJíT³<?@íXSã?J"ã?L!FIèªFéX+<?;=;IåðF=XJ9H$X+YSH$Y àA>SJ½à H$OK<?^íH[F=^íõ ã?L9BJ<?XJF=X ã?LRYSHKLGJ9ã^<?FéX¹J<?F=X âxLH>+H$X¹JNî»Fé@FIJ@KôÇJQSH$XJQSHã?LRFIèªF=X+<?;;=FIâxHOK<?@9HíF=@H»J9H$XAYSH$Yàå[JQ+ãª@9H<?@@ã»OKF=<WJ9H$Y ;=FIâxHOK<?@9H$@Kê

C 6C%#KX! C%&[ X>Z 2UX&[8C ! [ "24& 2 >CqpWb ãªXJ9HPJ½F=@½<?;=@9ã à ãª>+X+Y J9ã @OpH$XSH$@"<?X+Y JQ»>+@0HKî?ãª;=î?H$@TF=JQ+F=X[<@9J9ã?Lå?ê Þ Hí^<$å[HPõ H$OpJJQA<WJNOpãªXJ9H$X¹JGH$X+QA<?X+OpH$@GOpãªX¹J9HPJKê Sã?LGJQ+F=@LH$<?@9ãªXôTUH"F=XJ9LãWBY+>AOpH$YäJQ+Hõ+LHpBE@OpH$XSHOpãªXJ9H»JKêÇ\8QSHKLHKâxã?LH?ôS<í@>SàA@å»@9J9H$^ JQ+<WJ8^`<?X+<Wè?H$@JQSHOpãªXJ9H»JFé@X+HKH$YSH$Yê\8QAF=@GOpãªX¹J9HPJ^<?XA<Wè?HKL0>+@9H$@GJQSH;éFIâuJFéXSèäLR>+;IH$@GF=XJ9Lã»YA>+OpH$Y <Wàãî?Hâxã?L/J9L!<?X+@9âxHKLL!FéXSèOpãªXJ9HPJ/J9ãOpãªXJ9H»Jâxã?L@OpH$XSH$@KôOpãª;=;é<Wàã?LR<WJF=XSèä<?OpJ9ã?LR@Kô<?X+YJQSH Þ áM <?@G@>AO!Qê \8QSH"@9åP@9J9H$^ <?;=@9ãì@>Sõ+õ ã?LJ@JQSHGL!>A;IHpBsàA<?@9H$YìYSHKî?H$;Iã?õÇ^íH$X¹J³ã?âk;Iã?èªF=OK@ãzî?HKL8JFé^íH?ê Þ H/OK<?X+XSã?J³LH»>+FILHJQ+<WJJQSHGL!>+;IHN@9åP@9J9H$^ F=@Opãª^íõÇ;IHKJ9H?ôàÇ>SJ(FIJ^>+@J(à HOpãªX+@Fé@9J9H$X¹JKê Ý >+@9HKâ>+;SõALã?õ HKLJEåF=@UOpãª^^½>SJ<WJFIîPFIJEå?ôPFeêH?ê»JQSHLH$@!>+;IJ@ã?âö+LRF=XSèGL!>+;IH$@Y+ãH$@X+ã?JYSHKõ H$X+Y"ãªXíJQSH$FILã?LRYSHKL$êª\8QSH8OpãªXJ9HPJU^<?X+<Wè?H$^H$X¹J@9å»@J9H$^ H$X+Q+<?X+OpH$@(JQSHY+Fé<?;Iã?èª>SH^<?X+<Wè?H$^íH$XJ8@9åP@9J9H$^ à»åä<?Y+<WõAJF=XSè"<?X+Y]@9õ H$OKF=<?;=F=@!F=XSè/JQSHGõ+L!H$@9H$X¹J<WJF=ãªX[<?X+YìF=X];9H$OpJF=XSèOpãªXJ9H»JNF=XJ9ã`FIJKê

ý Ý JråõÇF=OK<?;OpãªXJ9HPJNHPJ9H$X+@F=ãªX J9ãâx>AX+OpJFIãªX+<?;=F=JEå]F=@<?@!@9ã»OKFé<WJ9H$Y TF=JQ[JQSH½õ+Lã?àA;=H$^ J9ã<$î?ãªFéY JQ+<WJ/>+@9HKL!@NJ9L!<WõðF=XJ9ã];Iãª@F=X+èWBsJ9L!<?O"!@FIJ>+<WJFIãªXA@KêMS>+O!Q @FIJ>A<WJFIãªX+YOK<?X àHíYSHKJ9H$OpJ9H$Y àA<?@9H$YãªXJQSH0>A@9HKLo@à H$Q+<zî»FIãª>+L$ôSH?êèSêÇF=Xî?ã!PF=XSèíJQSH0Q+H$;Iõ]âx>AX+OpJFIãªX]LHKõ H$<WJ9H$Y+;=åäãªX @F=^F=;é<WLJ9ã?õÇF=OK@Kô+LHKõ H$<WJ9H$Y+;=åõ ãª@FIJFIãªXAF=XSè½ãªX[õA<WLJFéOK>+;=<WL8;IãPOK<WJFIãªX+@8<?XAY]õ HKLâuã?LR^F=XSè"@F=^Fé;=<WL³ã?õHKLR<WJFIãªX+@ãªX @F=^F=;é<WL³YA<WJ<PôAHSOpH$@CB@FIî?H$;=å XA<$îPFIèª<WJF=XSèJQSLãª>SèªQ F=XSâxã?L!^<WJFIãªX @9õA<?OpHäTFIJQSãª>SJ½F=Xî?ã!»F=X+è <?X¹å LH$<?@9ãªX+<WàA;=H`â>+X+OpJFIãªX+<?;éFIJEå?ô;Iã»ã!»FéXSèìLHKõ H$<WJ9H$Y+;Iå âxã?L Ý G@/ãªXð@!F=^F=;=<WLGJ9ã?õAFéOK@Kô,<WJ9J9H$^íõ+JF=X+è]J9ã]H$X¹J9HKL½<]Y+F=@OK>+@!@FIãªX âuã?L!>A^]ô,<?X+Y@9H$X+YAF=XSè"H$^<?F=; J9ãJQ+H0@FIJ9H/<?Y+^`F=X+F=@9J9LR<WJ9ã?L$ê

?N@9HKL0<?F=Y JQ+<WJ0OK<?Xðà Híõ+Lãî»FéYSH$Y âuã?L;Iãª@F=XSèWBsJ9LR<?O"! @FIJ>+<WJFIãªXA@F=@èªFIîPF=XSè]<?OKOpH$@@0J9ã <]JQSH$@<?>+L!>+@ã?â³JQSH`@>+àA@9åP@9J9H$^ JQSH>+@9HKL0F=@0<?OKOpH$@@F=XSèSê+>SLJQ+HKL!^íã?LH?ô,JQ+HLH$@9õ H$OpJFIî?HàÇ>+@F=XSH$@!@^íã»Y+H$;^<$åðà HHPõãª@H$Y J9ã]JQ+H">A@9HKLGJ9ã?è?HKJQSHKL/TFIJQ<?X HPõA;=<?X+<WJFIãªXJQ+<WJF=@G<?Y+<WõAJ9H$Y J9ãì<õA<WL!JF=OK>+;=<WLG>+@9HKLJråõ H?êMPF=^`F=;=<WL!;Iå?ôW<?OKOpH$@@J9ã< Ý ;=Fé@9J@>+FIJ<WàÇ;IH³âuã?LJQSH>+@HKLU<?X+Y`JQSH<?OKOpH$@@9H$Yì@>+àA@9åP@9J9H$^&^<zåíàHèªFIî?H$Xê+>SL!JQSHKL!^íã?LH?ôUF=^íõ+Lãî?H$Y @9H$<WL!ORQ â<?OKF=;=FIJFIH$@í<?XAY HP<?^õA;IH$@íJ<WLè?HKJFéXSè <WJJQSH[@!>SàA@9åP@9J9H$^ <?OKOpH$@@H$Y^<zåà Hõ+L!ãzîPF=YSH$Yê

( 24!D[ K[ \8Q+HNF=Y+H$<0ã?âk<?Y+<Wõ+JFIîPFIJEåäF=@(J9ãíH»>+FIõJQSH@9åP@9J9H$^ TFIJQäH$XSãª>SèªQì<?Y+YAFIJFIãªX+<?;F=XSâxã?L!^<mBJFIãªX <?X+Y L!>+;IH$@JQ+<WJGTãª>+;=Y LH$X+YSHKLFIJõãª@!@FIàA;IH0J9ãH$X+è?H$X+YSHKLGJQSH"L!FIèªQJNOpãªXJ9H$XJ/<?X+Y â>+X+OpJF=ãªX+<?;=FIJråâxã?LJQ+HOK>SLL!H$X¹J³@FIJ>+<WJF=ãªXê\8QA<WJF=@$ô¹JQSHG@9åP@9J9H$^ F=@(@>+õ+õ ãª@9H$YJ9ãí<?OpJ<?OKOpã?L!Y+F=X+è0J9ã"JQSHGY+F=OpJ>+^ oå?ãª>J< !?H/OK<WLHã?âJQSH@9õ H$OKFIöAOK<WJFIãªXôP<?X+YìJQSH@9åP@9J9H$^ TFé;=;+J< !?H0OK<WL!HNã?âkFIJ@9H$;Iâ<?X+Yì<?Y+<Wõ+J³J9ãíJQSHOK>SLLH$XJ>+@9H Iê

\TãíOpãªX¹J9H$XJã?à<;9H$OpJ@C V : C _ <WLH÷Rû Çù Aûù »÷0F=XäJQSHGOpãªX¹J9HPJ F æGC V : ç H æGC _ : çRê\8QSHKåì<WLH`øsùªøsý û÷Rû Çù Aûù »÷"F æGC V : sçH æGC _ : sç³QSãª;=YA@âuã?L<?;=;,OpãªXJ9H»J@ kêÇ\8QSHKå]<WLH ÷pø Rý û"÷~ûù +û ù »÷GTFIJQ+F=X<½@OpH$X+<WLRFIã Nâxã?L<?Xì<?OpJ9ã?LJF æGC V : ç H æGC _ : çQSãª;éY+@âxã?L<?;=;OpãªXJ9H»J@ ð<?@@9ãPOKF=<WJ9H$Y[TF=JQ&Jä<?X+Y ªê

Ý õ+õA;=FéOK<WJFIãªX+@ã?âuJ9H$X LH»>+FILH<?Y+<Wõ+J<WJF=ãªX[ã?âkõ+LãPOpH$@@F=XSèOpãªXJ9HPJKôAH?êèSêAJ9ã

<?OpJ>+<?;H$X¹îPFILãªXA^íH$X¹J@@>+O!Q <?@8OK;=FIH$XJKôA@9HKLî?HKLzô+<?X+Y[OK>SLL!H$X¹J8Opãª^^½>+X+FéOK<WJFIãªX[O!QA<?X+XSH$;eô

¤p¥ cR¢d¦uklfrtsfhqkzEmfhfcRjWfhqsjWc!qE ¾ WcRofClo

>+@HKL8L!FIèªQJ@KôSLãª;IH$@$ôSã?àA;=FIèª<WJFIãªXA@KôS<?X+Y]õ+LãªQAFIàAFIJFIãªXA@Kô OpãªXJ9H$X¹JLH»>+FILH$Yìâxã?L8JQSH/õ ã?LJ9âxãª;=FIã"ã?âkJQSH0OK>SL!LH$X¹J8>A@9HKL$ô JQSH<?OpJ>+<?;,>+@9HKLTFIJQ]Q+F=@ mQSHKLõ+LHKâxHKLH$X+OpH$@Kô JQSH;IHKî?H$;ã?âkJ<?@ !]Opãª^íõA;IHKJFIãªX YSHKõ H$X+Y+F=XSè½ãªX]JQSH>+@9HKL$ô+<?X+Y JQSH>+@9HKLo@Opãª^íõÇ;IHKJFIãªX[Q+Fé@9J9ã?Lå?ê

ãªXA@F=YSHKL,âxã?LFéX+@9J<?X+OpHHpBE;=H$<WL!X+F=XSèã?LkHpBsè?ãzî?HKLRX+^íH$XJkTHKàA@F=J9H$@Y+F=@!OK>+@@9H$YF=XäïzóP<?X+Yäï|ñ ósê³F=JF:9KH$X+@^<zå <Wõ+õA;=å âuã?L<õ+LRF=^<WLåðõA;é<?OpHã?âLH$@F=Y+H$X+OpH?êáCX JQ+F=@"OK<?@9H?ôJQSH$F=L½õÇ<?@@9õ ã?LJ"^>+@J½à HìO!Q+<?X+è?H$Y(ã?JQSHKLTF=@9H?ô(XSã O!Q+<?X+è?HF=@`LH»>+FILH$YêFIJF:9KH$X+@íTFIJQ @ORQSã»ãª;|BE<Wè?HORQ+F=;=Y+LH$X ^<zå Q+<$î?HJ9ã Opãª^íõÇ;IHKJ9H<?Y+Y+F=JFIãªX+<?;,YSãPOK>+^íH$XJ@Kê³ãª^íõA;IHKJ9H$YYSãPOK>+^íH$XJ@^<zå]àH½YSH$Opãª^íõ ãª@9H$Y F=X¹J9ã<`@>AFIJ9H/ã?âYSãPOK>+^íH$XJ@Y+>SHJ9ã½;IHKèª<?;ÇLH$@9J9LRF=OpJFIãªX+@Kô¹H?êèSêà»å<0Y+<WJ<õ+Lã?J9H$OpJF=ãªXä<?OpJLH»>+FIL!F=X+èNJQA<WJY+<WJ<0âuã?L³OKFIJråíã ÒKF=<?;=@<?X+Y@9HKLîPF=OpHã ÒpH$@@>+ORQ[<?@8JQSH>+XSH$^íõA;=ãzåP^íH$X¹J<Wè?H$X+Opå[^½>+@9Jà H/@9HKõÇ<WL!<WJ9H$Yê

DNHKõ H$X+Y+F=X+è½ãªX[JQSHLãª;IHã?â>+@9HKLR@KôS@9J9ã?Lå]Opãª^íõA;IHKJF=ãªX]^<$åìà H/@O!Q+H$Y+>+;IH$Y]@9H»>SH$XJF=<?;=;Iåäâuã?L@9ãª^íH>+@9HKLR@³ã?LF=XìõA<WL!<?;é;IH$; âuã?Lã?JQ+HKL!@KêSã?LNF=X+@9J<?XAOpH?ô+OK;IHKL"!P@8F=Xì<OKFIJråäã ÒpH½^<$åìOpãªX+@FéYSHKL8YSãPOK>+^íH$XJ@8F=XõA<WL!<?;é;IH$;eôPTQ+F=;=HNOKFIJF!9KH$X+@8Opãª^íõA;=HKJ9H/JQSH$FIL8YSãPOK>+^íH$XJ@8F=X]<`@9H>+H$X¹JF=<?;^íã»Y+H?ê ý Ý Y+<Wõ+JFIîPFIJEå^<$åßà H LH>AFILH$Yß<WJ]L!>+XPBsJFé^íH?ê Sã?L F=X+@J<?X+OpH?ôõ HKã?õA;IHTFIJQßâxã?LH$FIèªXOKFIJF:9KH$XA@Q+FIõ ^<zå à H]LH»>+FIL!H$YJ9ã <Wõ+õA;Iå âxã?L`<ðLH$@FéYSH$X+OpH]õ HKL!^FIJKêd?N@9HKL!@^`<$å LH»>+FILH]<ðîW<WLåPF=XSè@>SõAõã?L!JYSHKõ H$X+Y+FéXSèãªXJQSH"H$X¹îPFILãªXA^íH$X¹JNJQ+<WJF=@N>+@9H$Yâxã?LNJQ+H½Opãª^íõÇ;IHKJFIãªXã?âUYSãPOK>+^íH$XJ@Kê ?@HKL!@@QSãª>A;=YàH/@!>Sõ+õ ã?LJ9H$YìTQSH$X+HKî?HKL8JQSHKåì<WLH0F=XJ9HKLL!>SõAJ9H$Y]Y+>SL!F=X+èJ<?@ !]Opãª^íõÇ;IHKJFIãªXê

\8Q+H$@9H LH»>+FIL!H$^íH$X¹J@;IH$<?Y¿Y+FILH$OpJ;=å J9ã JQSH LH>AFILH$^íH$XJ`J9ãYSHKî?H$;Iã?õß< â<?OKF=;=F=JEåâuã?L Søsý¹ü 'ýªþªý øsý¹ü ]÷ÇýWú ùW÷âxã?L½YAFHKL!H$X¹J½>+@9HKL!@Kôõã?L!J9âuãª;=F=ãª@Kô<?X+Y OpãªX¹J9HPJ@Kê Þ H]@Q+<?;=;L!HKJ>SL!X J9ãJQ+F=@0LHpB»>+FILH$^íH$XJ<WâuJ9HKLNF=XJ9Lã»YA>+OKF=XSè½J9H$^íõA;=<WJ9H$@F=XJQSH0XSHPJ8@9H$OpJFIãªX,ê+árJ8Fé@³ãª>SL8J<WLè?HKJJ9ã`YSHKî?H$;Iã?õ[è?H$X+HKL!F=O@OpH$X+<WLRFIãª@³JQ+<WJ8OK<?X]à HGLHKöAXSH$YìJ9ã@!OpH$X+<WL!FIãª@³à»åFéX];CH$OpJFéXSè½OpãªXJ9HPJKêÇ\8Q+Fé@<WõAõ+Lãª<?O!Q F=@³^íã?LHTF=Y+H$;Iå>+@9H$Yìâxã?L Þ á9MP@³JQA<?XìãªXSHTUãª>A;=YìH»õ H$OpJKê Sã?LF=X+@9J<?X+OpH?ô+<?;é^íãª@9J<?;=;F=XSâxã?L!^<WJF=ãªX@!FIJ9H$@³ã?âkOKF=JFIH$@<?X+YLHKèªFIãªXA@õ+Lãî»F=Y+H³<Gî?HKL!å"@!F=^F=;=<WL QSã?J9H$;Sã?L(HKî?H$X¹J@9H$<WL!O!Q,ê¹\8QSH³LH$<?@9ãªXäF=@XSã?JJQSHHSF=@9J9H$XAOpH8ã?â<0YSHKî?H$;|Bã?õA^íH$XJ^íãªXSã?õ ãª;IåíàA>+JUL!<WJQ+HKLJQSHHKî?ãª;é>SJFIãªXìã?â,JQSH$@HG@H$<WL!O!Q]â<?OKF=;=F=JFIH$@J9ã@9H$^`F|BE@9J<?X+Y+<WLRY+@Kê\QSH$@9H@9J<?X+YA<WL!Y+@<WLH0X+ã?J8ã ÒKF=<?;=;=åä<Wè?LHKH$YôAàA>SJ8Q+<zî?H0à HKH$Xìâuã?LR^íH$Y]à»åOpã?õ»å»FéXSè`@>+OKOpH$@!@9âx>A;@9ãª;=>SJFIãªXA@Kê

äØÕ(Û rÚ ,WÜsØÕ

[8X CUX "!$#KC% C'&[8C'(

- +× AÕUÛ% 4, fhqslIv v Ï qEc!tsfhqsjmcRolIv v?~j~lov vªAqEcRloc$v¹b v~8cRlIv v?cRjW/bGctsfhqEczv»b ÃrÆsÁRÐÁ|Ð ÅRÑéÅEÐmÑuÃrÐmÆsÁRÃ Ã ?À ÁIÄEÅ!ÑIÁ=ÍRÐmÆ bNRqs~cRjc!¢y|8c!jmj¹vWzcRj Ï qEcRjClodeCv¹ ¥~¥ RjWcRoofCj¹v Ê$ÁIÀoÎRÁµÐ Ã ?À Á=ÄsÅRÑIÁ=ÍRÐÆ+Á|Ñ klode~jz¦é´½fCdeofhgKv~dtsRjv? ¥~¥ f ¾ qs9gKfhq9v £ v~cRjm È fC¢mjf~v~ ´ $biR¢mdefhqe¦éCfhj$tsfrqsf9zfCdelo~j³fhts$yµRq+ fh³deltsfCd wujAÍRÌk WÊ$ÑuÃrËÃrÑÇÍRË! !ÆÅRÐWÎ"$# %#'&RÆsÑuÃrÌUÆ)(+* ËeÍ9ÄEÃsÃeÎRÁ|Ð,RÆÍxÂÑÃ.-Ñ/EÐmÑuÃrËEÐ?ÅRÑIÁ=Í!Ð?Å~À AÍRÐCÂ9ÃrËsÃrÐWÄrÃ 10 odefCn$lofhq9v §~§R¨ v?¡¡ ¨ 32 §!¤¤z ©.4¢fCoIv vzEKc!?f~vA vc!jW65klocRlojv bN$fhloj"loj$tsfrqEcRhtslo~jdcRjW`jWc9n$lopc!tsloRjìlojä fhìcR¡¡molo9c!tsloRjmd wxj

AÍRÐWÄEÃK WÑIÊÅ~À7Í9ÎKÃhÀ Á|Ð,³ÂCÍRË"89 Ê$ÆsÁ|ÐªÃrÆsÆÅ!Ð?Î½ÑmÃ ÃhvÇ ´ AÈ lÉof~v ( bGc9g$q9vÇcRjm Ç¾ WcRofCloGv 0 zd vnpR § $!y:;+<# z¡zqslojm~frqe¦=5AfhqscRzv? ¥~¥R¥ v?¡¡ ~ >2W9 ~¢m?fhjv!© ¦= vR c!qsjmczv v Ï qEcRdelojm9cq9v Ï v!c!jW5 zn@?c v 0 9 fhnpfCo~¡fCjKt»!ymdefC8c!jKtslA fClojyµRqs8ctslRjdgzdtsfCd wxjBAC$ÁµËeÎEÐÑuÃrËrÐWÅRÑIÁ=ÍRÐWÅ~À;AÍRÐCÂ9ÃrËsÃrÐWÄrÃ Í!Ð Ã8 ÐRÁ|Ð?ÃEÃrËEÁ|Ð,+()D 86EGFHFJI0¶é ¥R¥ ~¸rvKnp~ ~R RyK;+<#mv$¡qslojmRfhqe¦L5Çfhqsc!v¡m¡ R § 2 ¨z

È f~vR v fCjWzfhqsde~jz¦$fCoofhqsdCvp vpcRjm³©k¢v~ ´"fhfh¼$tsfCjdelRjmdPts i b È Rikdelojmtsmf,b5½teqslc~ wxjMAÍRÐ?ÄEÃK WÑIÊÅ~ÀÍ9ÎpÃhÀ Á|Ð(8ONPEFHFDEpvp z¡mcRC9c!¡mlofhteqEc$vK ~¾k bGc!qsEv~cRjmRQ c!mc9gKcRdemlIv 0 d vRnp~ ¥ RySK"<# z¡qsloj~fhqe¦5AfhqscRzv? ¥~¥ Kv?¡m¡ ¥ 32WR §z

qEc!~8c!tsloCd,!yÇ$tsRqegz?~c!qElojy|!q´½fCNwujyµRqs8c!tsloRj/$gzdtsfCd wmidscRRfjWc!gdelod ¤

bN!qslotsRv ¾k v~zEmfr f~v ¦é vcRjm ¾ mcRomfhlGv! $teqEc!tsfh~lo$zfColoj!ym fhUlojyµRqs8ctslRjUdgzdtsfCd EÐmÑuÃrËEÐ?ÅRÑIÁ=Í!Ð?Å~À ÍRÊ$ËEÐ?Å~À»ÍRÐ ÃEÐ9ÂhÍRËrÌ³ÅRÑIÁ=ÍRÐM#'&RÆsÑuÃrÌÆv ¤ ¶é ¥~¥ ~¸rv >2 §R¤

¨$ ~dedelIvP© vPzEKc!?f~v¹ v»c!jW È g$cqEfht9v Ï ´½fC"c!¡m¡lo9ctslo~j"$zfCodc!qsfRqsf(tsWc!j½CRjmCfC¡zts¢Wc!A$zfCod wxj,ÎJ!ÅRÐ?ÄEÃrÆÁ|Ð AÍ!Ð?ÄEÃK WÑIÊÅ~ÀSÍ9ÎpÃhÀ Á|ÐRv fCjNfhtc! v 0 zd vWnpR R !y:;+<# z¡zqslj~fhqe¦L5AfhqscRzvWfrqsloj¹v» §R§~§ v¡¡ § 2z~

§$ $rfh f~vP ¦é vPcRjW ¾ mcRomfCloGv+ ½È ly|fNCcRdefCdAjcR¡m¡zqspc!ríts0c~zqsfCdedU¡qEcRR8c!tsloCdUljítsfzfCdelo~jRy fhlojyµRqs8ctslRjGdgzdtsfCd de¢mltetsf98yµRq¡m¢molo9c!tsloRj

¥$ $rfh f~v ¦é vmc!jW ¾ mcRomfhlGvm ikdefrq$zfCodW C~jKteqslom¢ztslo~jNts³¡zqEcRR8c!tsloCd,RyPfCGlojyµRqs8ctslRjdgzdtsfCdzfCdelo~j de¢mltetsf98y|Rq¡¢mmolo9ctslRj

~ $rfh f~v ¦é v,c!jW ¾ mcRomfCloGv, ¾ mf0C!¦xzfCdelo~j cR¡¡qs~cRE[ts fh lojzy|Rqs8ctslo~j[dgzdtsfCdNzfCnpfCoR¡mfCjKt EÐÑuÃrËrÐWÅRÑIÁ=ÍRÐWÅ~À ÍRÊ$ËEÐ?Å~ÀPÍRÐ ÃEÐ9ÂCÍ!ËrÌ³ÅRÑIÁ=ÍRÐM# &!ÆsÑuÃrÌÆ!v¹¶é ¥~¥ R¸rv32W ¤z $rfh f~vp ¦é vpcRjW ¾ mcRomfCloGv$ RjmCfh¡ts¢Wc!W$fholojm!yfC8ljzy|!qs8c!tslo~j8dgzdtsfCd K Å!ÑéÅÅRÐ?ÎÐ?ÍJ,ÀÃeÎ>KÃ8 ÐRÁ|Ð?ÃsÃrËrÁ|Ð,zv?¶é ¥~¥ ~¸rvP ¤ >2m ¨R¨zI $rfh f~v ¦u v ¾ Wc!fCloGv v,ÇljfC8cRjj¦xªmcRj9,lh~v v cRdeEmf v v ¢dedCv ¾k v,cRjm ¾ derlof9fCIv CRjmCfh¡ts¢Wc!+nzlofh !y fCofCrteqs~jmloof9cqsjmlojmGdgzdtsfCd 8,ÎRÊÄEÅ!ÑIÁ=ÍRÐ`ÅRÐWÎEÐCÂCÍRËEÌÅRÑIÁIÍRÐPAªÃeÄ$$ÐWÍ~ÀoÍ RÁéÃrÆHFvAr¦x0¶é ¥R¥ R¸rv¨ @2WR ¥$ ¤z $rKc!?f~vª v¹cRjmRdedel=v»© j0RG?xfCht!qslfhj$tsfCc!¡m¡qs~cRE0ts8 fh¦éWc!def9c!¡m¡lo9ctslo~j"zfCdelo~j AG *#v ¤¶ §~§~¨ ¸rvª ¥ >2$~

¾ mcRomfCloGv~ v$cRjm 4¢dtsfhqsK4!yµt9v$ ª¾ mf¢def,RyªfhtEc!¡mm!qslo9cRdteqs¢mhts¢zqsfCdAyµRqÇloj$tsfrqsjmfhtAdeltsfCd K Å!ÑéÅ Ð?ÍJ,ÀÃeÎ>KÃ8 ÐRÁ|Ð?ÃsÃrËrÁ|Ð,/I"¶é ¥~¥R¥ ¸rv» $2W ¨R¥z ´½fCmdtsfhq djljfhtsNjfh C~oofCRlÉctsfzlohtslo~jWcqegKv §~§

Context Analysis: Toward Pragmatics of Web Information Systems

Design

Hui Ma1 Klaus-Dieter Schewe1 Bernhard Thalheim2

1Massey University, Department of Information Systems & Information Science Research CentrePrivate Bag 11 222, Palmerston North, New Zealand, email: [h.ma|k.d.schewe]@massey.ac.nz

2Christian Albrechts University Kiel, Department of Computer ScienceOlshausenstr. 40, 24098 Kiel, Germany, email: [email protected]

Abstract

On a high level of abstraction a Web Information Sys-tem (WIS) can be described by a storyboard, whichin an abstract way specifies who will be using thesystem, in which way and for which goals. Whilesyntax and semantics of storyboarding has been wellexplored, its pragmatics has not. This paper con-tributes context analysis as a step towards closing thisgap. We classify various aspects of contexts related toactors, storyboard, system and time, which make upthe context space, then analyse each of these aspectsin detail. This is formally support by lifting relations.Finally, we analyse how contexts impact on life cases,user models and the storyboard.

1 Introduction

A Web Information System (WIS) is an informationsystem that can be accessed through the world-wide-web. On a high level of abstraction a WIS can be de-scribed by a storyboard (Schewe & Thalheim 2005b),which in an abstract way specifies who will be usingthe system, in which way and for which goals. In anutshell, a storyboard consists of three parts:

a story space, which itself consists of a hierarchyof labelled directed graphs called scenarios, oneof which is the main scenario, whereas the oth-ers define the details of scenes, i.e. nodes in ahigher scenario, and a plot that is specified byan assignment-free process, in which the basicactions correspond to the labels of edges in thescenarios,

a set of actors, i.e. abstractions of user groupsthat are defined by roles, which determine obli-gations and rights, and user proles, which de-termine user preferences,

and a set of tasks that are associated with goalsthe users may have.

In addition, there are many constraints compris-ing static, dynamic and deontic constraints for pre-and postconditions, triggering and enabling events,rights and obligations of roles, preference rules foruser types, and other dependencies on the plot. De-tails of storyboarding have been described in (Schewe& Thalheim 2005b). An overview of our methodfor the design of WISs was presented in (Schewe &Thalheim 2005a).

Copyright c©2008, Australian Computer Society, Inc. This

paper appeared at the Fifth Asia-Pacific Conference on Con-

ceptual Modelling (APCCM 2008), University of Wollongong,

Wollongong, Australia. Conferences in Research and Practice

in Information Technology, Vol. 79. Annika Hinze, Markus

Kirchberg, Eds. Reproduction for academic, not-for profit pur-

poses permitted provided this text is included.

While syntax and semantics of storyboarding hasbeen well explored, its pragmatics apart from the useof metaphors (Thalheim & Dusterhoft 2000) has not.Pragmatics is part of semiotics, which is concernedwith the relationship between signs, semantic con-cepts and things of reality. This relationship maybe pictured by the so-called semiotics triangle. Mainbranches of semiotics are syntactics, which is con-cerned with the syntax, i.e. the construction of thelanguage, semantics, which is concerned with the in-terpretation of the words of the language, and prag-matics, which is concerned with the current use ofutterances by the user and context of words for theuser. Pragmatics permits the use of a variety of se-mantics depending on the user, the application andthe technical environment. Most languages defined inComputer Science have a well-defined syntax; someof them possess a well-defined semantics; few of themuse pragmatics through which the meaning might bedifferent for different users.

Syntactics is often based on a constructive or gen-erative approach: Given an alphabet and an set ofconstructors, the language is defined as the set of ex-pressions that can be generated by the constructors.Constructions may be defined on the basis of gram-matical rules.

Semantics of generative languages can be eitherdefined by meta-linguistic semantics, e.g. used fordefining the semantics of predicate logics, by proce-dural or referential semantics, e.g. operational seman-tics used for defining the semantics of programminglanguages, or by convention-based semantics used inlinguistics. Semantics is often defined on the basis ofa set of relational structures that correspond to thesignature of the language.

Pragmatics has to be distinguished from prag-matism. Pragmatism means a practical approachto problems or affairs. According to Webster (Web1991) pragmatism is the “balance between principlesand practical usage”. Here we are concerned withpragmatics, which is based on the behaviour and de-mands of users, therefore depends on the understand-ing of users.

The six characteristics of WISs that were discussedin (Schewe & Thalheim 2005b) can be mapped to con-ceptual structures that are used for storyboard spec-ification:

1. We start with the characteristics used for thestrategic layer. Main specification elements usedare intention and mission. They are mapped tometaphors, general goals, rhetorical figures, andpatterns and grids of web pages discussed later.

2. The scenarios reflect the utilisation by actors,for which we envision a number of stories thatcorrespond to real use. These scenarios may becaptured through observation of reality. Storyspaces and plots are recorded in various level of

HHHHY6

?

*

HHHj

Technical environment

of the user

User

Datarepresentation

Data Functions


HHHHY

AAAAU

HHHHj

Information

Story

*

HHHjContent

HHHYFunctionality

*CCCCCCO

Layout

AA

AAK

HHHHY

Playout

BBBBN

Information

metaphorsHHHHHY

Story and

functionality

metaphors


Pragmatic

sSyntactic

s

Figure 1.1: The Web Utilization Space Based On the Characteristics of WIS

detail through the methods discussed in (Schewe& Thalheim 2005b). The stories are reflected inthe storyboard.

3. Content specification is the basis for the mediatypes, i.e. data types and their functions, whichwill be introduced in part III. It combines dataspecification with user requirements and is re-flected in the content portfolio.

4. Functionality is provided by the media types asrequired by the storyboard. Typical standardfunctions are navigation, retrieval (search), sup-port functions, and feedback facilities.

5. Context is based on tasks, history, and envi-ronment. We use the specification of contextfor restructuring and functionality enhancement,which will form the basis of XSL transformationsand the onion approach (Binemann-Zdanowicz,Kaschek, Schewe & Thalheim 2004).

6. Presentation depends on the intention, theprovider, the technical environment available andthe users the WIS is targeting at. Presenta-tion results in the layout and the playout of theWIS. Layout requires the development of multi-media presentations for each page. Playout addi-tionally requires the development of functional-ity that supports visits of users depending on thestory they are currently following to achieve theirgoals. Layout and playout integrate the chosenmetaphors; they depend on chosen page patternsand grids as well as on quality requirements.

Conceptual structures and their association are de-picted in Figure 1.1. We may separate the syntacticsand pragmatics layers. Arrows are used for repre-senting part-of- or uses- or relates-associations. Forinstance, the story is based on the user and the func-tions. Information metaphors relate content to infor-mation.

We use the notions of information and contentin a specific manner. Information as processed byhumans, is carried by data that is perceived or no-ticed, selected and organized by its receiver, becauseof his subjective human interests, originating fromhis instincts, feelings, experience, intuition, commonsense, values, beliefs, personal knowledge, or wisdom,simultaneously processed by his cognitive and men-tal processes, and seamlessly integrated in his re-callable knowledge. Content is complex and ready-to-use data. Content management systems are infor-mation systems that support extraction, storage anddelivery of complex data. Content may be enhanced

by concepts that specify the semantic meaning of con-tent objects and by topics that specify the pragmaticunderstanding of users.

Therefore, information is directed towards prag-matics, whereas content may be considered to high-light the syntactical dimension. If content is enhancedby concepts and topics, then users are able to capturethe meaning and the utilisation of the data they re-ceive. In order to ease perception we use metaphors .Metaphors may be separated into those that supportperception of information and into those that supportusage or functionality.

Users are reflected by actors that are abstractionsof groups of users. Pragmatics and syntactics sharedata and functions. The functionality is providedthrough functions and their representations. The webutilisation space depends on the technical environ-ment of the user. It is specified through the layoutand the playout. Layout places content on the ba-sis of a data representation and in dependence of thetechnical environment. Playout is based on function-ality and function representations, and depends onthe technical environment.

The information transfer from a user A to a userB depends on the users A and B, their abilities tosend and to receive the data, to observe the data,and to interpret the data. Let us formalise this pro-cess. Let sX denote the function user by a user Xfor data extraction, transformation, and sending ofdata. Let rX denote the corresponding function fordata receival and transformation, and let oX denotethe filtering or observation function. The data cur-rently considered by X is denoted by DX . Finally,data filtered or observed must be interpreted by theuser X and integrated into the knowledge KX a userX has. Let us denote by iX the binary function fromdata and knowledge to knowledge. By default, we ex-tend the function iX by the time tiX

of the executionof the function.

Thus, the data transfer and information reception(or briefly information transfer) is formally expressedit by

IB = iB(oB(rB(sA(DA))),KB , tiX) .

message

sender

receiver

content

s-r-relationship

appeal to

receiver

presen-

tation

Figure 1.2: Dimensions of understanding messages

In addition, time of sending, receiving, observing,and interpreting can be taken into consideration. Inthis case we extend the above functions by a timeargument. The function sX is executed at momenttsX

, rX at trX, and oX at toX

. We assume tsA≤ trB

≤toB≤ tiB

for the time of sending data from A to B.The time of a computation f or data consideration Dis denoted by tf or tD, respectively. In this extendedcase the information transfer is formally expressed itby

IB = iB(oB(rB(sA(DA, tsA), trB

), toB),KB , tiB

) .

The notion of information extends the dimensionsof understanding of message displayed in Figure 1.2to a web communication act that considers senders,receivers, their knowledge and experience. Figure 1.3displays the multi-layering of communication, the in-fluence of explicit knowledge and experience on theinterpretation.

The communication act is specified by

the communication message with the content orcontent chunk, the characterisation of the rela-tionship between sender and receiver, the datathat are transferred and may lead to informationor misinformation, and the presentation,

the sender, the explicit knowledge the sendermay use, and the experience the sender has, and

the receiver, the explicit knowledge the receivermay use, and the experience the receiver has.

In this paper we approach the analysis of WIS us-age as the first important part of storyboarding prag-matics. WIS usage analysis consists of three parts:

1. Life cases capture observations of user behaviourin reality. They can be used in a pragmatic wayto specify the story space. The work on life caseswas reported in a previous publication (Schewe& Thalheim 2007a).

2. User models complement life cases by specifyinguser and actor profiles, and actor portfolios. Theactor portfolios are used to get a better under-standing of the tasks associated with the WIS.The work on user models was reported in a pre-vious publication (Schewe & Thalheim 2006).

3. Contexts complement life cases and user modelsby characterising the situation in which a userfinds him/herself at a certain time in a particularlocation. We classify various aspects of contextsrelated to actors, storyboard, system and time,which make up the context space, then analyseeach of these aspects in detail. This is formallysupport by lifting relations.

After a brief overview of the literature in Section2 we approach the specification of contexts in Section3. Formal aspects of contexts are then dealt within Section 5. In Section 6 we conclude with a briefsummary and a discussion of open issues.

2 Related Work

Storyboarding and also the preceding strategic mod-elling of WIS (Moritz, Schewe & Thalheim 2005) areunique to our approach to WIS modelling. Other ap-proaches to WIS engineering such as the object ori-ented OOHDM (Guell, Schwabe & Vilain 2000, Rossi,Schwabe & Lyardet 1999, Schwabe & Rossi 1998),WebML (Ceri, Fraternali, Bongio, Brambilla, Comai& Matera 2003), HERA (Houben, Barna, Frasincar &

Vdovjak 2003) and variants of UML (Conallen 2003,Lowe, Henderson-Sellers & Gu 2002) concentrate onproviding models of content, navigation and interac-tion by means of extended views, which in our ownwork is captured by so-called media types (Schewe &Thalheim 2005b). WSDM (De Troyer & Leune 1998)emphasises the additional need for a mission state-ment and a high-level description of processes andusers in the WIS. Quite often high-level modelling ofWISs is subject to UML-based methods, in particu-lar variants of use cases. The rationale underlying ourwork is that this is far too little to capture strategicand usage issues of WISs.

The integration of goals and soft goals into theinformation systems development process has beenproposed by (Mylopoulos, Fuxman & Giorgini 2000,Giorgini, Mylopoulos, Nicchiarelli & Sebastiani 2002).The detailed distinction of intentions as targets, ob-jects, objectives and aims is based on linguistics(Web 1991). The integration of the temporal dimen-sion is necessary because of the information systemscontext. The extension by the representational di-mensions has been made in order to specify aspectsof WISs.

Contextual modelling has found its own researchcommunity (Bouquet, Serafini, Brezillon, Benerecetti& Castellani 1999), but very little work has beendone to integrate contextual modelling into WISdesign. The work in (Mylopoulos & Motschnig-Pitrik 1995) uses contexts as an approach to mod-ularise conceptual models. The most advanced at-tempt to modelling context is the work on contex-tual information bases (CIB) (Akaishi, Spyratos &Tanaka 2002, Theodorakis, Analyti, Constantopou-los & Spyratos 1998, Theodorakis, Analyti, Constan-topoulos & Spyratos 1999). Roughly speaking, a CIB-context associates objects with a name and an op-tional reference to another CIB-context. Thus, boththe name and the reference depend on the usage his-tory. As shown in (Kaschek, Schewe, Thalheim &Zhang 2004) CIB-contexts in a slightly generalisedform can be combined with media types to provide aformal model of usage context. For this, instead ofonly associating merely a name with a location L alocation, i.e. a complex value, is associated with it.

3 Context Determination

Taking the commonly accepted meaning a contextcharacterises the situation in which a user findshim/herself at a certain time in a particular location.In this sense context is usually defined only staticallyreferring to the content of a database. Only very fewattempts have been made so far to consider contextof scenarios or stories.

More generally, we consider context as everythingthat surrounds a utilisation situation of a WIS by auser and can throw light on its meaning. Therefore,context is characterised by interrelated conditions forthe existence and occurrence of the utilisation situ-ation such as the external environment, the internalstate, location, time, history, etc. For WISs we needto handle the mental context that is based on theprofile of the actor or user, the storyboard contextthat is based on the story leading to a situation, thedata context that is based on the available data, thestakeholder context, and the collaboration context.These different kinds of contexts have an influence onthe development of the storyboard and must thus beconsidered for the development of the WIS.

Example 3.1 Let us consider a travel informationsystem. It is often desirable to resolve the context ofutterances. While booking an airline ticket to London

communicationact

sender

receiver

data(information, misinformation)

sender-receiver relationship

appeal to

receiver

formappearance,

gestaltpresentation

explicitknowledge

explicitknowledge

experienceexperience data

- -

- -

Figure 1.3: Dimensions of the communication act

the user may be asked for the airport code, for whichs/he has a choice between LGW (London Gatwick),LHR (London Heatrow), LON (all London airportsin UK), STN (London Stansted), and YXU (London,Ontario, Canada). The context of the travel requestcan be used to exclude the last option. The contextof the airline used so far can be used to exclude twoof the others. This context injection is based on thestory environment and on content data.

3.1 Context Space

When determining context we already know the ma-jor life cases we would like to support, the intentionsassociated with the WIS, the user and actor charac-terisation on the basis of profiles and portfolios, andthe technical environment we are going to use. Theserestrictions enable a more refined understanding ofcontext within a WIS.

The work in (Moritz et al. 2005) characterises aWIS by six intertwined dimensions, one of which iscontext. We now relate context to the other dimen-sions, i.e. to the intentions, the usage, the content,the functionality, and the presentation. As presenta-tion resides on a lower level of abstraction, it does nothave an impact on context. Content and functionalitywill be used for context refinement, which we addresslater. So, we first concentrate on intention and us-age. The user model, the specified set of life cases,and the intention can be used for a disambiguation ofthe meaning and an injection of context. In doing sowe distinguish the following facets of context:

Actor context: The WIS is used by actors for anumber of tasks in a variety of involvements andwell understood collaboration. These actors im-pose their quality requirements on the WIS usageas described by their security and privacy pro-files. They need additional auxiliary data andauxiliary functions. The variability of use is re-stricted by the actor’s context, which covers theactor’s specific tasks and specific data and func-tion demand, and by chosen involvement, whilethe profile of actors imposes exceptions. The in-volvement and collaboration of actors is based onassumptions of social behaviour and restrictionsdue to organisational decisions. These assump-tions and restrictions are components of the ac-tor’s context.

Storyboard context: The meaning of content andfunctionality to users depends on the stories,which are based on scenarios that reflect life casesand the portfolios of users or actors. Accordingto the profile of these users a number of qualityrequirements such as privacy, security and avail-ability must be satisfied. The actor’s scenariocontext describes what the actor needs to under-stand in order to efficiently and effectively solve

his/her tasks in the actual portfolio. The actor’sdetermine the policy for following particular sto-ries.

System context: The WIS is developed to supporta number of intentions. The purposes and in-tents lead to a number of decisions on the WISarchitecture, the technical environment, and theimplementation. The WIS architecture has animpact on its utilisation, which often is only im-plicit and thus leads to not understandable sys-tems behaviour. The technical environment re-stricts the user due to restrictions imposed byserver, channel and client properties. Adapta-tion to the current environment is defined as con-text adaptation to the current channel, to theclient infrastructure and to the server load. Atthe same time a number of legal decisions basedon regulations, laws and business rules have beenincorporated into the WIS.

Temporal context: The utilisation of a scene by anactor depends on his/her history of utilisation.Actors may interrupt and resume their activitiesat any moment of time. As they may not beinterested in repeating all previous actions theyhave alrady successfully completed, the temporalcontext must be taken into account. Due to avail-ability of content and functionality the currentutilisation may lead to a different story withinthe same scenario.

We will discuss these various facets of context inmore detail later in this section. This entire informa-tion forms the context space, which brings togetherthe storyboard specification and the contextual infor-mation. Typical questions that are answered on thebasis of the context space are:

What content is required by the context space?

What functionality is required by the contextspace?

What has to be changed for the life cases, thestoryboard, etc., if context is considered?

As outlined above the context space is determinedby the actors, the scenarios, the WIS itself, and thetime. It leads to a specialisation of the content, struc-turing and functionality of the scenes.

Context is associated with desirable properties ofthe WIS such as quality criteria and security and pri-vacy requirements. Quality criteria such as suitabilityfor the users or learnability provide obligations for theWIS development process. Though these criteria arerather fuzzy, they lead directly to a number of imple-mentation obligations that must be fulfilled at laterstages, i.e. within the development on the implemen-tation layer.

For instance, learnability means comprehensibil-ity, i.e. the WIS must be easy to use, remember,capture and forecast. This requires clarity of the vi-sual representation, predictability, directness and in-tuitiveness. These properties allow the user to con-centrate on the tasks. The workflows and the dis-course structure correspond to the expectations ofthe users and do not lead to surprising situations.They can be based on metaphors and motives takenfrom the application domain. In the same way otherquality criteria can also be mapped to developmentobligations.

Other properties that may be associated with con-text refer to the potential utilisation for other tasksoutside the scope of the storyboard. In this case we donot integrate the additional tasks into the storyboard,but instead support these tasks, if this in accordancewith our intentions. For instance, we might expectfurther visits targeting at core concerns of the WIS.

Example 3.2 Sometimes customers may want touse a WIS for a purpose that does not meet the sys-tem’s mission statement. For example, a customermay use a banking WIS to learn about the loan busi-ness, or a bookshop WIS to learn English. Clearly,the larger the gap between the actual customer’s in-tention and the system’s mission statement is, thehigher the expected costs will be for supporting suchcustomers. If it can be expected that some customerswill interact with the WIS in a ‘non-standard’ way,a decision has to be made whether to support suchintentions or not. This implies a modification of theanticipated information space. It shows that our fo-cus on a business model for context modelling is notalways a severe restriction.

3.2 Additional Aspects

We may consider three additional context facets:

Provider context: Providers are characterised bytheir mission, intentions, and specific policies.Additionally, terms of business may be added.Vendors need to understand how to run the WISeconomically. Typical parts of this context areintentions of the provider, themes of the web-site, mission or corporate identity of the site,and occasion and purpose of the visits of actors.Thus, providers may require additional contentand functionality due to their mission and pol-icy. They may apply their terms of business andmay require a specific layout and playout.Based on this information, the WIS is extendedby provider-specific content and functionality.The storyboard may be altered according to theintentions of the provider, and life cases may beextended or partially supported. Provider-basedchanges to portfolios are typical for WISs in e-government and e-business applications.

Developer context: The WIS implementation de-pends on the capability of the developer. Typi-cally we need to take into account the potentialenvironment, e.g. hard- and software, commu-nication channels, the information systems thatare to be incorporated, especially the associateddatabases, and the programming environmentdevelopers use.

Organisational and social context: The organi-sation of task solutions is often already prede-termined by the application domain. It followsorganisational structures within the institutionsinvolved. We captured a part of these struc-tures already on the basis of the portfolio and

modelled it by collaboration. The other parsform the organisational context. Collaborationof partners consists of communication, coordina-tion, and cooperation. Cooperation is based oncooperativity, i.e. the disposition to act in a waythat is best helpful for the collaboration partners,taking their intentions, tasks, interests and abil-ities into account. At the same time, collabora-tion is established in order to achieve a commongoal. Actors choose their actions and organisethem such that their chances of success are opti-mised with respect to the portfolio they are en-gaged in. Additionally, the social context maybe taken into account, which consists of inter-active and reactive pressures. Typical social en-hancements are socially indicated situations suchas welcome greetings, thanking, apologising, andfarewell greetings.

4 Details of Context Specifications

Let us next take a deeper look into the facets of thecontext space, i.e. examining actor, storyboard, sys-tem and temporal context in more detail.

4.1 Actor Context

The context of an actor is based on his/her intentions.According to the actor’s profile s/he needs support tofulfil the expectations with respect to the quality ofinformation and work. The social and intellectual in-terests of the actor may also be part of the actor’scontext. The actor’s profile may be used for a refine-ment of the actor’s context leading to the followingfour specific kinds of context:

Actor projection context: Actors may act ontheir expectations. In this case, they intension-ally drop portions of content or functionality andproject the current content and functionality tothe “normal” case. This projection leads to animplicit context. For instance, within a travelscenario actors are expected to behave like trav-ellers. Another kind of projection is parametersuppression, in which case content or functional-ity may be dropped or is not noticed whenever itbecomes partially irrelevant.

Actor approximation context: Often actors needfirst a condensed or approximated informationthat may be refined later. Typical such approx-imations are attribute value approximations orstructural approximations. For instance, the for-mer ones may allow the WIS to provide first anapproximate value for the orientation of the user.A common misuse of approximation is pricing by“starting from”. Structural approximation per-mits the use of the same symbol for the originalobject and an abstraction, hence enables the us-age of simpler representations.

Actor ambiguity context: Sometimes the refer-ence of a symbol can be unambiguous within anarrow scope, in which certain limitations apply,but ambiguous in a larger scope without the lim-itations. A typical unambiguous symbol is the‘next’ button in case the next scene lies withinthe expectations of the actor. Another use of am-biguity can be made by choosing less expressivetextual representations. For instance, in a loanapplication there is no need to clarify that theword ‘bank’ denotes a financial institution.

Actor mental context: The mental context cap-tures attitudes and knowledge of actors or other

kinds of alternative states of affairs such as fic-tion and user expectations. This context is de-scribed in terms of provenance, i.e. relating toreal life cases or to expected life cases. Expec-tations of actors or users can be combined withother more general requirements. The knowledgeof the mental context will remain highly incom-plete. However, it provides a handle for incorpo-rating users’ and actors’ expectations.

The actor context is intellectual as well as existen-tial. It contributes to enabling the scenarios and thecorresponding stories under consideration. The intel-lectual part is based on the profile of the actor, onhabits, traditions, knowledge, experience, etc. It maybe also based on the quality requirements an actor isimposing. The actor context restricts the users thatmight use the WIS, the way the system will be used,and the portfolios. It is based on the intentions forusing the system and the portfolio of the actor, e.g.tasks, involvement, and the collaborations the actoris involved in. The existential part is also related tothe portfolio under consideration. It is related to thedata and functions currently available or provided,and the technical environment.

The specification of this specific actor context be-comes necessary whenever we want to support thework of actors that is close to human communication.Human communication exploits the context often toan extreme degree, leaving many things implicit. Wedo not need a complete decontextualisation as longas the actor can interpret the content and functional-ity that is provided by the WIS. Contexts provide amechanism by which we can use the simplest presen-tation, content and functionality, i.e. the ones thatmakes the fewest distinctions most of the time whiletranscending to more expressive presentation, contentand functionality only when needed.

Due to these contextual abilities we may restrictpresentation, content and functionality to those fea-tures that are absolutely necessary. These restrictionsmay result in presentation principles such as sparseutilisation of additional and not directly necessarycontent or functionality or economy in utilisation ofcolours, multimedia objects, and texture.

Example 4.1 Let us use relocation as an examplefor an illustration of this principles. An issuer ofthe relocation life case expects that his personal andidentification data are already sufficient for provid-ing him/her all necessary details. So, the context inwhich the issuer reacts is based on projection and am-biguity context. If we use the information the pass-port office provides as public information for the cityoffice, then we can adapt the life case directly to thecurrent one. At the same time, the visit of the issuermight be not the first such in his/her life. So, wecan now use the information on previous life cases forscaling the life case to the expectations the issuer has.

The adaptation requires some background knowl-edge on the handling of life cases in other cities, pre-vious visits, and the profile of the issuer. We maythen use a number of questions to figure out, whichfurther adaption or refinement of the life case is appli-cable. Since some data on the issuer cannot be storedin the system due to regulations and laws we need torepeatedly obtain these data. So, the data we needto capture within the life case are extended by datawe need for figuring out which specific life case is un-der consideration. At the same time we may use thiscontext information for adapting functionality that isprovided.

This specific actor context is combined with theportfolio restrictions. Actors with a non-deterministic

behaviour do not use high ambiguity or deep projec-tion. At the same time, their mental context and theirapproximation context must be rather sophisticated.Actors acting more on intention intensively use allfour kinds of actor contexts. Task-oriented and re-active behaviour requires support for mental context.Actors acting in collaborations need additional sup-port for their common disambiguation. If actors donot complete their tasks within one session, they needa well-prepared projection context for the case thatthey resume their tasks. We shall later map these re-quirements to adaptation rules and control rules foradaptation.

4.2 Storyboard Context

Context has also a storyboard dimension. The ac-tor’s context must be combined with the storyboard,life case and portfolio contexts. The latter two selec-tively condition the situational interest of the actorand the relevance of the current scene for the actor.Based on the relevance we may identify and use prop-erly all the content that should exert the evolution ofthe current story. We may now use this informationfor extracting whether a sequence rule, i.e. a rule ofthe form s1 ⇒ s2 requiring that a visit of scene s1should be followed by a visit of scene s2 can be ap-plied to the current system usage. The rule may holdin general, but is considered to be not applicable if theexistence of process p1 leading to scene s1 does nothave a bearing on the existence of process p2 leadingto scene s2. Therefore, the incorporation of contextand the derivation of relevance has mainly to do withselecting the best story for the user and is thus usedfor the adaptation of content and functionality.

The storyboard context can be used for derivingthe most appropriate content. We aim at deliveringthe right data to the right actor with the right toolsand scope at the right time. As the storyboard con-text provides a good source for adaptation of contentand functionality to the current stage of the scenariowe collect context within the storyboard and add thiscontext information to the context space. This con-text allows a treatment of the expectations of the ac-tor. Therefore, each scene in a scenario is providedwith a pre-scene context , scene context , and a post-scene context . The pre-scene context consists of all content that

has already been delivered to the actor before theappearnace at the actual scene. This informationcan be used to reduce content delivery for scenes.At the same time, this content can be stored incondensed form and made available to the ac-tor when needed, i.e. the actor can revisit theold content whenever this seems to be necessary.Classical browsers only provide a strictly sequen-tial ‘back’ button for this kind of history man-agement. The pre-context of a scene thus con-tains all valuable content that is collected duringa story, and guarantees the availability of thiscontent when needed.

The post-scene context consists of a potentialplayout of scenes that can be entered after thecurrent scene. If an actor needs some informationon the next actions, then this context informa-tion can be used. This information is valuablefor those actors who intend to drop out of thesystem. It is also a part of the help information.The post-scene context can be enriched by meta-data describing the content that is provided inthe next steps or the data to be produced by theactor. In this case, an intelligent interface mayforecast the information need for further steps ofthe storyboard.

Each scene may also be enriched by superim-posed meta-data on the scene, which include ev-erything that could be referenced within the ex-pected consumed and produced data. Typicalsuch references are collaborating actors, retrievalor update data of the current content, and de-tails taken from the log of the current story. Fi-nally, the scene context may include administra-tive data such as identification of content cur-rently under consideration.Scene context is enhanced by generic scene in-formation, which can be based on intentions ofthe WIS. For instance, adverts may be attachedto each of the scenes. Default information servesas an exception handling for scenes. If contentor functions are currently not available, then de-fault data are provided.

4.3 System Context

The system context is determined by the content andthe functions that are provided by the web informa-tion system. It consists of at least the following fourparts:

Source and acquisition: Source and acquisition isan orthogonal dimension of the WIS. A WIS issupported by media objects that belong to me-dia types as we will explore in detail in part III.In a nutshell, a media object is defined by an ex-tended view on some underlying database, whichcan then serve for provision of content and func-tionality of an elementary scene. The databasesused for the generation of content form the con-text of the scenario. We may associate with eachscenario the subschemata of these databases thatare used for generation of consumed data or forintegration of data produced by actors in the sce-nario.

Associated content: The data that are used forconsumed and produced information do not ex-ist in isolation. They are usually associated withother data on the basis of integrity constraintsor existence constraints, in particular existenceconstraints are often not explicitly representedas such, but are embedded into the databaseschemata used. For instance, we usually asso-ciate with objects collected in relationship classesthose objects collected in the component classeson which they are based. In this case, we assumethat objects in component classes of the relation-ship type co-exist with objects in the relationshipclass. We need to consider the environment ofcontent that is currently under consideration to-gether with the data that are associated with thiscontent.

Supported functionality: Functions supportingthe actions in scenarios are provided by theWIS. These functions have their own controlenvironment. Typical such control mechanismsare logging, concurrency control, and recoverymanagement.

Security: Security concepts describe enciphermentand encryption (keys, authentication, signatures,notarisation, routing control, access control, dataintegrity, and traffic padding) for data exchange.

4.4 Temporal Context

The temporal context appears in a number of vari-ants, e.g. storage time, validity time, display time,user-defined time, transaction time, etc. The tempo-ral context is applicable in a number of combinations.

Sometimes it is necessary to use all of them, but of-ten it is often observed that only one variant of thiscontext is necessary.

Versions show the life cycle of the objects underconsideration. As scenarios will have their own lifecycle we cannot assume that database changes aredirectly enforced on websites. Moreover, it may beuseful to provide the old content as long as an actorcontinues with the same story. Versions can often besystematically structured by database system phases :

The initialization phase permits the developmentof objects storing initial information. Integrityconstraints are applicable in a limited form.

The production phase is the central phase, whichconsists of runtime querying, modification, trans-action management, etc.

The maintenance phase is used in productivedatabase applications for clarification of soft con-straints, maintenance of constraints that havebeen cut out from runtime maintenance, andchanging the structuring and functionality of theentire database system. Maintenance phases areused in data warehouse applications for recharg-ing the data warehouse with actual information.

The archiving phase is used for archiving the con-tent of a database in a form that data relevantfor historical information can be easily retrieved.No data modification is permitted; the only mod-ification operation is to load new changes to thearchive.

4.5 Context Templates

We may now combine this context information usingthe following semi-formal template:

Context:Extension of:

Actor context:Projection context:Approximation context:Ambiguity context:Mental state context:Characterisation:

Storyboard context:Pre-scene context:Post-scene context:Scene context:

WIS context:Source and acquisition:Associated content:Supported functionality:Security:

Temporal context:Versioning:Development phase:

Provider context:Developer context:Organisational and social context:Based On:Based On:Based On:Based On:

5 Formal Aspects of Context Modelling

Context evolves for actors, scenarios, systems, andover time. We model the relation between differentcontexts by lifting relations . Properties that are validfor a certain context may be lifted to another context.This transfer can be based on local model semantics.

For this recall that a context is determined by ac-tor, storyboard, system and temporal contexts. So letA denote the set of actors, S the set of scenarios, Wthe set of system characteristics, and T the set of timeunits. Then we can take a subset C ⊆ AS WTto represent a set of contexts. Furthermore, we usea family of contexts Ci ∈ C|i ∈ I and a family ofstatement sets (or theories) i|i ∈ I that are asso-ciated with these contexts. Of course, the theory i

describes the properties of the context Ci.

5.1 Lifting Relations

On these grounds we may use local models Mi,j foreach of these statement sets assuming that the mod-els we consider are enumerated by the second index.More precisely, the models Mi,j determine the mean-ing of content drawn from a language L for describingcontent in view of context Ci. That is, we use a par-tial mapping Ψ : LC →M, whereM denotes a setof pre-determined meanings for content in L.

We may now distinguish the formula occurringcontext Ci from the same formula occurring in an-other context by considering the context index i, i.e.we consider pairs (, i). Lifting relations can be mod-elled by rules of the form

(1, i1) . . . (n, in)(, i)

ϕ

stating that the formulae (1, i1) . . . (n, in) canbe lifted to (, i) under the side condition ϕ. In ad-dition, a compatibility relation among local modelsis introduced similar to logics that capture possibleworld semantics. This compatibility relation is usedfor entailment and satisfiability. This approach allowsus to reason locally and then to transfer the knowl-edge we gained to other contexts.

Based on this coarse clarification of basic notationwe develop a number of facilities and extend the spec-ification of the WIS:

Context space: The content context space is de-fined on the basis of the content C, scenarios Sand actors A. In Example 3.1 we could use in-formation on the travel and on the airline to ex-clude options that seem to be less likely. The con-tent context space of a WIS for a given content-meaning pair c,m) consists of precisely thosecontexts, under which the particular content willhave that particular meaning, i.e.

(c,m) = (a, s, w, t) ∈ C | Ψ(c, (a, s, w, t)) = m.

Adaptation of content, functionality, and scenar-ios to the context that is currently available isbased on context infusion. Applying transforma-tion rules we change content, functions, and thepresentation. Therefore, we use a context specifi-cation for the development of enforcement rules.These rules may restrict scenarios to more spe-cific ones, extend or shrink content, and extendor remove functions.

Life case extension and specialisation: Thegeneral life case specification can often bespecialised, if context is explicitly injected.We need both the more general life cases andthe contextualised ones. Whenever the WISis revised or extended, we can return to moregeneral life cases and generate another con-textualisation. Typical specialisations concernchanges in the life case flow. We may specialisethe data consumed by an actor in dependence

of the actor’s context. If we know that actorsneed special auxiliary information or converselyactors became more knowledgeable during theutilisation of the WIS, then we may adapt thedata provided for consumption. At the sametime, we can specialise the figures accordingto the given context. In the same way spatialand temporal information provide a basis forrefinement of life cases.Life cases may be extended to requirements thatwere collected in the context space. The con-tent context may require a more elaborated con-tent to be provided. The supported functional-ity may require additional functions, content, ora specific presentation. Intentions may be morespecific under consideration of context. For in-stance, if we want to support a certain usage of aWIS that was not originally intended but becameimportant in order to maintain frequent visits,then the original life case is extended by thoseassociated life cases.

Development of a context manager: Context isalso bound to scenes and thus evolves withina story. We may expect that content enhancescontext. For this reason, we introduced the pre-scene context. Therefore, a subsystem that man-ages the context is needed. This context manageruses the lifting rules introduced above for trans-ferring context to context for scenes, collaborat-ing actors, and the WIS as such. The systemalso supports the rule-based development of log-ics over time. We cannot require that the rulesystem is complete, but it must be consistent. Auseful property is commutativity, i.e. the resultsof firing rules does not depend on their order.The context management system enhances thedialogue management system by adapting andspecialising the presentation and injecting con-text into it.

Example 5.1 A typical context extension to func-tionality is associated with the problem to avoid thatusers trap into losing-track situations. Such situa-tiond can be detected based on the user’s behaviour,e.g. invoking the help function repeatedly on similartopics, repeatedly positioning on particular locationsand performing similar operations on similar data, ex-cessively navigating through information space with-out invoking any reasonable functionality, looking re-peatedly for FAQs on similar topics, attempting toenter a discussion forum, and sending email to thesite administrator.

User aid that can be provided for losing-track sit-uations is giving access to a thesaurus of the subsys-tem the user is accessing. Furthermore, the respectivebusiness model may be exposed to the user togetherwith an explanation that is adapted to a particularuser type. Similarly, access to a FAQ list suitable forthe user and the accessed subsystem may be given.Furthermore, improved search facilities and examplestargeting at the subsystem accessed may be provided.

5.2 Adaptivity

The idea of adaptivity is to equip the system withenough additional information and rules that wouldrender it possible to engender the right content andfunctionality for the current situation. That is, thesystem is supposed to act according to the dictum‘you take care of the specification, and the systemwill take care of itself and adapt to the current use’.

Two content objects c1, c2 are synonymous in thecontext Ci ∈ C iff ψ(c1, Ci) = ψ(c2, Ci). They are

totally synonymous iff ψ(c1, Ci) = ψ(c2, Ci) holdsfor all contexts Ci ∈ C. They are epistemicallysynonymous within a scenario s for an actor a iffψ(c1, Ci) = ψ(c2, Ci) holds for all contexts Ci ∈ Cassociated with a and s.

Applications often require adaptation of process-ing context, e.g. to

actual environments such as client, server, andcurrent communication channel,

user rights, roles, obligations, and prohibitions,

content required for the portfolio of the currentuser,

the actual user with his/her preferences,

the level of task completion depending on theuser, and

the user’s completion history.

Consider for instance e-learning or e-governmentwebsites discussed in (Moritz et al. 2005) and(Schewe, Thalheim, Binemann-Zdanowicz, Kaschek,Kuss & Tschiedel 2005). Citizens may apply for a pri-mary place of residence. In this case, their passportmust be changed; otherwise, no change is required.Citizens with school-age children may have to com-plete additional documents. Completed documentsmay be decomposed into a suite of documents due tolegal restrictions, e.g. by a data protection act requir-ing that data for city officials and service offices suchas the unemployment agency must be separated.

Depending on the role of users, story completionmay be scheduled sequentially for some users or inparallel for others. For instance, clerks in a city of-fice may consider documents in parallel, while citizenscomplete their documents in a sequential mode.

Example 5.2 Adaptivity may be required at run-time. For instance, people with foreign citizenshipmay be required to apply for a residence permit.Users may require a varying support depending on theenvironment that is used for the completion of docu-ments. Users should be supported whenever they areinterrupted during task completion.

These requirements lead directly to the require-ment to develop a facility for mutable, adaptable sce-narios for different users, portfolios, and contexts.We shall return to this requirement after introducingtemplates in the next section. It is our target to de-velop generic scenarios that can be refined to scenar-ios by injecting context. This approach is more widelyused for WISs than one would expect. For instance,almost all information sites of cities and regions pro-vide a very similar hotel or event search. The reasonis not the existence of a development monopoly butrather the evolution of these search facilities to semi-standards. These standards are not officially agreed,but have been formed by copying successful solutions.

6 Conclusion

In this paper we approached the pragmatics of WebInformation Systems (WIS) design focusing on themethod of storyboarding that is an integral part ofthe codesign approach to WIS design (Schewe &Thalheim 2005a, Schewe & Thalheim 2005b). A sto-ryboard specifies in an abstract way who will be usingthe WIS, in which way, and for which goals. Thus,the specification of a storyboard captures the navi-gation paths, i.e. the stories through the “scenes” of

the WIS, the action scheme accociated with the sto-ries, the actors appearing in the scenes, and the tasksthe actors accomplish. In addition, there are variousstatic, dynamic and deontic constraints governing thestoryboard.

While syntax and semantics of storyboarding havebeen well explored, its pragmatics has not. Whilemany methods for WIS design emphasise contentmodelling, we start from the very fundamental ob-servation grounded in semiotics that content refers toa syntactic dimension, whereas a pragmatic dimen-sion requires dealing with information. This led tothe objective to investigate in depth intentions as-sociated with a WIS. The facets of intention arisingfrom this form the basis for our technical developmentin this paper dealing with life cases, user models, andcontexts.

Life cases capture observations in reality, whichby means of abstraction can be used to derive sce-narios for the storyboard. Integrating these scenariosprovides a method for storyboarding. User modelsare by user and actor profiles, and actor portfolios.The latter ones provide a better understanding of thetasks associated with the WIS. Contexts can be clas-sified according to how they impact on the life cases,the user models, and the storyboard extracted fromthem.

This work on pragmatics of storyboarding con-tributes to closing a gap in the codesign methodologyfor WIS design. It links the formalism of storyboard-ing to the systems requirements, and provides guide-lines and means to derive the complex storyboardsfrom informal ideas about a WIS without any techni-cal bias. So, one one hand, this work on pragmaticsis a decisive part of the methodology, which does notjust consist of a collection of formally integrated mod-els, but also has to state how to use them. It wouldbe rather difficult mapping life cases or user mod-els directly to a conceptual model of a WIS, whichresides on a much lower level of abstraction as thestoryboard. So on the other hand this work empha-sises the need for storyboarding as the decisive toolfor high-level WIS engineering. As shown in (Schewe& Thalheim 2007b) this is also the basis for high-levelreasoning about WISs addressing such important is-sues as personalisation of functionality.

Despite the high relevance of pragmatics forthe completeness of storyboarding and the codesignmethodology as a whole, the work reported in thispaper is only part of the story, as it only addressesthe context analysis. Together lith life cases (Schewe& Thalheim 2007a) and user models (Schewe &Thalheim 2006) they capture usage analysis of WISs,which still does not completely exhaust the problemarea associated with pragmatics of storyboarding. Weare in the process of writing up a second part of sto-ryboarding pragmatics dealing with WIS portfolios,which combines content and utilisation portfolios thatgive rise to content and functionality chunks. Thecontent portfolio is used for collecting information re-quirements. It is based on information needs and de-mands, and links the storyboard to the lower-levelconceptual model of the WIS consisting of a collec-tion of media types. The utilisation portfolio is usedfor collecting functionality requirements. It describesintentions of users, specific needs and their context.

In addition to this follow-on part on storyborad-ing pragmatics we are also working on the pragma-tism of storyboarding, storyboard refinements, andquality evaluation. All this together plus the ongoingresearch on logical grounds of storyboarding and theirexploitation for reasoning and verification will com-plete our research on high-level WIS design within thecodesign framework.

References

Akaishi, M., Spyratos, N. & Tanaka, Y. (2002),A component-based application framework forcontext-driven information access, in H. Kan-gassalo et al., eds, ‘Information Modelling andKnowledge Bases XIII’, IOS Press, pp. 254–265.

Binemann-Zdanowicz, A., Kaschek, R., Schewe, K.-D. & Thalheim, B. (2004), Context-aware webinformation systems, in ‘APCCM’, pp. 37–48.

Bouquet, P., Serafini, L., Brezillon, P., Benerecetti,M. & Castellani, F., eds (1999), Modeling andUsing Context – Context’99, Vol. 1688 of LNAI,Springer-Verlag.

Ceri, S., Fraternali, P., Bongio, A., Brambilla, M.,Comai, S. & Matera, M. (2003), Designing Data-Intensive Web Applications, Morgan Kaufmann,San Francisco.

Conallen, J. (2003), Building Web Applications withUML, Addison-Wesley, Boston.

De Troyer, O. & Leune, C. (1998), WSDM: A user-centered design method for web sites, in ‘Com-puter Networks and ISDN Systems – Proceed-ings of the 7th International WWW Conference’,Elsevier, pp. 85–94.

Giorgini, P., Mylopoulos, J., Nicchiarelli, E. & Sebas-tiani, R. (2002), Reasoning with goal models, in‘ER’, pp. 167–181.

Guell, N., Schwabe, D. & Vilain, P. (2000), Modelinginteractions and navigation in web applications,in S. W. Liddle, H. C. Mayr & B. Thalheim,eds, ‘Conceptual Modeling for E-Business andthe Web’, Vol. 1921 of LNCS, Springer-Verlag,pp. 115–127.

Houben, G.-J., Barna, P., Frasincar, F. & Vdovjak, R.(2003), HERA: Development of semantic web in-formation systems, in ‘Third International Con-ference on Web Engineering – ICWE 2003’, Vol.2722 of LNCS, Springer-Verlag, pp. 529–538.

Kaschek, R., Schewe, K.-D., Thalheim, B. &Zhang, L. (2004), Integrating context in concep-tual modelling for web information systems, inC. Bussler, D. Fensel, M. E. Orlowska & J. Yang,eds, ‘Web Services, E-Business, and the Seman-tic Web’, Vol. 3095 of LNCS, Springer-Verlag,pp. 77–88.

Lowe, D., Henderson-Sellers, B. & Gu, A. (2002),Web extensions to UML: Using the MVC triad,in S. Spaccapietra, S. T. March & Y. Kam-bayashi, eds, ‘Conceptual Modeling – ER 2002’,Vol. 2503 of LNCS, Springer-Verlag, pp. 105–119.

Moritz, T., Schewe, K.-D. & Thalheim, B. (2005),‘Strategic modelling of web information sys-tems’, International Journal on Web Informa-tion Systems 1(4), 77–94.

Mylopoulos, J., Fuxman, A. & Giorgini, P. (2000),From entities and relationships to social actorsand dependencies, in ‘Conceptual Modeling - ER2000’, Springer-Verlag, Berlin, pp. 27–36.

Mylopoulos, J. & Motschnig-Pitrik, R. (1995), Par-tioning information bases with contexts, in‘Proc. CoopIS ’95’, pp. 44–55.

Rossi, G., Schwabe, D. & Lyardet, F. (1999), Web ap-plication models are more than conceptual mod-els, in P. Chen et al., eds, ‘Advances in Con-ceptual Modeling’, Vol. 1727 of LNCS, Springer-Verlag, Berlin, pp. 239–252.

Schewe, K.-D. & Thalheim, B. (2005a), ‘The co-design approach to web information systems de-velopment’, International Journal on Web Infor-mation Systems 1(1), 5–14.

Schewe, K.-D. & Thalheim, B. (2005b), ‘Conceptualmodelling of web information systems’, Data andKnowledge Engineering 54(2), 147–188.

Schewe, K.-D. & Thalheim, B. (2006), User models:A contribution to pragmatics of web informa-tion systems design, in K. Aberer, Z. Peng &E. Rundensteiner, eds, ‘Web Information Sys-tems – Proceedings WISE 2006’, Vol. 4255 ofLNCS, Springer-Verlag, pp. 512–523.

Schewe, K.-D. & Thalheim, B. (2007a), Life cases:An approach to address pragmatics in the de-sign of web information systems, in ‘ProceedingsWebIST’07’.

Schewe, K.-D. & Thalheim, B. (2007b), ‘Personalisa-tion of web information systems - a term rewrit-ing approach’, Data and Knowledge Engineering62(1), 101–117.

Schewe, K.-D., Thalheim, B., Binemann-Zdanowicz,A., Kaschek, R., Kuss, T. & Tschiedel, B. (2005),‘A conceptual view of electronic learning sys-tems’, Education and Information Technologies10(1-2), 83–110.

Schwabe, D. & Rossi, G. (1998), ‘An object ori-ented approach to web-based application design’,TAPOS 4(4), 207–225.

Thalheim, B. & Dusterhoft, A. (2000), ‘The use ofmetaphorical structures for internet sites’, Data& Knowledge Engineering 35, 161–180.

Theodorakis, M., Analyti, A., Constantopoulos, P.& Spyratos, N. (1998), Context in informationbases, in ‘Proc. CoopIS ’98’, pp. 260–270.

Theodorakis, M., Analyti, A., Constantopoulos, P. &Spyratos, N. (1999), Contextualization as an ab-straction mechanism for conceptual modelling,in ‘Conceptual Modeling – Proc. ER’99’, Vol.1728 of LNCS, Springer-Verlag, pp. 475–489.

Web (1991), ‘Webster’s ninth new collegiate dictio-nary’.

Intention-Driven Screenography

Thomas Moritz1, Rene Noack2,Klaus-Dieter Schewe3, Bernhard Thalheim2

1Brandenburg University of Technology, Institute of Computer ScienceCottbus, Germany [email protected]

2Christian Albrechts University Kiel, Department of Computer ScienceKiel, Germany noack|[email protected]

3Massey University, Information Science Research CentrePalmerston North, New Zealand [email protected]

Abstract: The design and reification of Web Information Systems is a complex task,for which many integrated development methods have been proposed. While all thesemethods ultimately lead to the construction of web pages, very little attention is paid tothe layout of these pages. The work report in this paper amalgamates knowledge fromart, cognitive psychology and scenography in an attempt to systematise WIS layoutand thus to complement development methods with this respect. We discuss princi-ples and rules for page layout that originate from knowledge of visual perception andcommunication, and then investigate how layout can support the intentions associatedwith the WIS. This amounts to guidelines for partitioning pages and using layout ob-jects, colour, light and texture to obtain rhythm, contrast and perspective as the carriersfor web page comprehension.

1 Introduction

A Web Information System (WIS) is an information system that is made accessible via theworld-wide web. Such systems can be of any size, but the primary focus of research inthis area is on large-scale systems that require the support of database technology for thecontent and are used by an unlimited number of users. Consequently, the number of webpages that are needed to present a WIS to its users is very high, and permanent changesto these pages have to be accounted for. Therefore, the design and reification of such sys-tems cannot be left to “HTML-hackers”. It has become subject to various developmentmethods such as OOHDM [SR98], WebML [CFB+03], WIS co-design [ST05a, ST05b],HERA [HBFV03], WSDM [DL98] and others, and also UML has been adapted to supportWISs [Con03, LHSG02].These methods differ in many respects, and we do not intend to discuss these differenceshere. However, whatever method is used, it finally boils down to the writing or genera-tion of web pages. So, whatever sophistication has been achieved through the method, apoor layout of the pages can easily destroy it. Nonetheless, astoundingly little effort hasbeen put into WIS layout. It may be argued that layout is the realm of HCI techniques[BGB98, Car91, Joh97, Val82], but then general HCI techniques are not coupled with spe-

cific development methods, and a lot of the HCI ideas have to be taken into considerationalready during WIS design, even at a very high level of abstraction. For instance, the par-titioning of pages and colour schemata are linked to the strategic decision on the desiredambience of the WIS as emphasised in [MST05].

Currently, WIS designers are mainly involved in modelling and implementation, whilelayout is not overly emphasised. However, late consideration of graphical issues may resultin inflexibility, and cause problems for extension and change management. Our aim is tosupport the systematic and early involvement of layout and playout, for which we developan approach to screenography , which adopts and generalises dramaturgy and scenography.Scenography has its roots in theatre, film and television, i.e. outside the web area, andcontains the composition of action space, plot and dramaturgy. Dramaturgy controls thesequence of scenes and determines the composition of information. Our claim is to showthat WIS layout also requires scenography and dramaturgy to facilitate the understandingand memorisation of content, and to support orientation within the WIS. Screenographyaims at providing interfaces of high utility that can be used by any user depending onhis/her intentions and tasks. So, we base screenography on a characterisation of tasks,intentions, and specific characteristics of the users, provided by means of user profilesand portfolios. Intentions and tasks determine a user’s expectations and interests; specificcharacteristics influence the patience in dealing with the WIS. As WISs are to provideneeded services, the users’ real needs and life stories have to be specified. We do this onthe basis of life cases that generalise, combine, extend and formalise business use cases.

Screenography captures the layout and playout of WISs. Layout addresses the graphicaldesign of pages in liaison with content to be conveyed and functionality to be providedby the WIS; it supports users depending on their profile. Playout is based on the storyspecification, the task portfolio of users, and the contexts of the WIS and its users.

The rationale of our work is to complement the WIS codesign method [ST05a] with asystematic approach to WIS layout that is grounded in knowledge from art, cognitivepsychology and scenography. In order to do so we start from a general architecture thatdetermines the WIS development needs. On these grounds we refine intentions and usethem to specify user profiles and portfolios [ST06a]. In Section 3 the screenography de-velopment process is described in detail. We start with the atmosphere that determines theglobal ambience type. Next we define patterns and refine them to grids that are used topartition the screen and reify the ambience through appropriate colour schemes [MST05].In Section 4 we discuss cognitive aspects of screenography. As known from art, photog-raphy and scenography the attraction of an observer is influenced by rhythm, contrast andperspective, so we have to use the layout elements in a way that supports the desired ef-fects and directs the attention of the users. We concentrate on layout aspects. Cognitiveaspects for playout may be considered in a similar way, but are omitted due to space limi-tations. Finally, in Section 5 we present a brief application case study, in which we discussimprovements of websites originating from screenography.

This paper introduces structural and cognitive concepts in detail. The intention behindstructural concepts of screenography has been sketched in [MNST07]. Open researchissues concern dimensions of web information systems such as representation advancedfunctionality and of highly structured content.

2 Development Prerequisites

A prerequisite of screenography is the analysis of a WIS on a high level of abstraction.So, we have to consider the intentions associated with the WIS, and characterise expectedusers. This is captured by a storyboard that specifies who will use the system, in whichway, for which tasks, and for which intentions. The motivation of user for WIS use isexplicitly specified through four facets of intentions: purpose (aims or objectives), in-tents (targets or objects), time (design, end or occasion) and representation (atmosphere ormetaphors). Roughly speaking, the first facet represents the ’what’, the second the ’how’and the third the ’when’ of an intention. Details of these facets were presented in [ST06a].

2.1 Development Architecture.

The Seeheim model for user interface management systems (UIMS) [Gre85] separatesthe presentation from the application components. Consequently, the development stepsregarding these components are separated, too.

The application component distinguishes levels for requirement prescription, specificationand implementation. However, for the presentation component only the specification andimplementation level are dealt with thoroughly at present. Nevertheless, the requirementlevel is also important for the presentation component. At this level we define the intentionto be supported by the presentation and characterise the WIS users. For instance, we maydefine the ambience of a decoration to be colour-independent, because the perception andimpression of colours depends on capabilities of users as well as cultural and religiousviews. On the specification level these global definitions acting as guiding conditions.

2.2 User Models.

User modelling is based on the specification of user profiles that address the characterisa-tion of the users, and the specification of user portfolios that describe the users’ tasks andtheir involvement and collaboration on the basis of the mission of the WIS [ST06b].

To characterise the users of a WIS we distinguish between education, work and personalityprofiles. The education profile contains properties users can obtain by education or train-ing. Capabilities and application knowledge as a result of educational activities are alsosuitable for this profile. Properties will assigned to the work profile, if they can be associ-ated with task solving knowledge and skills in the application area, i.e. task expertise andexperience as well as system experience. Another part of a work profile is the interactionprofile of a user, which is determined by his frequency, intensity and style of utilisation ofthe WIS. The personality profile characterises the general properties and preferences of auser. General properties are the status in the enterprise, community, etc., and the psycho-logical and sensory properties like hearing, motoric control, information processing andanxiety.

A portfolio is determined by responsibilities and is based on a number of targets. There-fore, the actor portfolio (referring to actors as groups of users with similar behaviour)within an application is based on a set of tasks assigned to or intended by an actor and forwhich s/he has the authority and control, and a description of involvement within the tasksolution [ST06b]. A task as a piece of work is characterised by a problem statement, initialand target states, collaboration and presupposed profiles, auxiliary conditions and meansfor task completion. Tasks may consists of subtasks. Moreover, the task execution modeldefines what, when, how, by whom and with which data a task can be accomplished. Toclassify tasks it’s possible to use existing task models, e.g. Concurrent Task Tree (CTT) orTask Object Oriented Description (TOOD). The result of executing a task should presentthe final state as well as the satisfaction of target conditions.

2.3 Life Cases.

For task completion users need the right kind of data, at the right time, in the right gran-ularity and format, unabridged and within the frame agreed upon in advance. Moreover,users are bound by their ability to verbalise and digest data, and their habits, practices, andcultural environment. To avoid intellectual overburdening of users we observe real appli-cations before the system development leading to life cases. Life cases help closing thepragmatic gap between intentions and storyboarding. Syntax and semantics of life caseshave already been well explored in [ST06a].

2.4 Demands for Presentation Development.

Intention, user and life case modelling are very important for screenography. For instance,for developing a satisfactory WIS atmosphere we have to consider the representation facetof the intention, which defines the ambience the presentation should have. It depends onthe application area of the WIS and the preferences of the user. The main challenge is theheterogeneity of web clients. Therefore, we specify the atmosphere already on a high levelof abstraction. In this area some work has been done and allows the designer to specifydevice independent the appearance of interaction elements. Examples are UIML (UserInterface Modelling Language), AUIML (Abstract UIML), and XUL (Xml User-interfaceLanguage). Particularly this approaches developed to realise the functionality aspects.

3 Essential of Screenography

Screenography extends web application engineering by scenographic and dramaturgic as-pects and intends to support the interaction between system and user. Screenography aimsat an individualised, decorated playout in consideration of intention, user profiles and port-folios, provider aims, context, equipment, functionality and the storyline progress.

3.1 Atmosphere

Defining the atmosphere is the first step of presentation development and a part of intentionspecification. Due to its definition on a high level of abstraction the atmosphere is inde-pendent of equipment features. The reification through page layout and the sufficiency ofthe available equipment to play out a specific atmosphere will be checked on a lower level.The atmosphere can be described by the ambience of the presentation, which is determinedby parameters such as shapes, material, illumination, and colour schema. Further, visualperception is always affected by the current mood and emotions of a viewer.According to [Mor06] we distinguish the ambience-types powerful, in the sense of dra-matic art and vitality, romantic, in the sense of romance and passion, elegant, in the senseof seriousness and dispassion, refreshing, in the sense of ease and transparency, balanced,in the sense of harmony and balance, and energetic, in the sense of phantasm and energy.Figure 1 presents some ambience examples. It shows background facets of the same appli-cation, in this case varying only by colour. The colour choice goes back to Goethe [Goe10]and Itten [Itt61]. Each facet consists of 3 colours, a three colour chord.

Figure 1: Facets of the same application: refreshing, energetic, romantic ambience

3.2 Layout Patterns

After the atmosphere, we have to specify layout patterns considering the prerequisites. Pat-terns are a powerful conceptual framework for building compelling, effective, and easy-to-use websites [vDLH02]. A pattern consists of visual and functional building blocks.According to [MST05] the functional building blocks realise the access to the presentedcontent and order these. The visual building blocks are important for perception and needto consider the colouring with respect to functionality and aesthetics, the perspective per-ception of the whole screen, and the visual alignment and partitioning of the screen.

The colouring aspect includes the colour schema development on the basis of the specifiedatmosphere. Therefore, we have to consider the emotions a user usually associates withcolours. The effect of colours can be warm, cool, cold, intensive, hot, light, dark, etc. Auser’s perception is also influenced by cultural aspects and age. According to [Mor06] thebasis of a colour schema can be a colour chord consisting of n colours (n ∈ 2, 3, 4, 6)that form a regular polygon in the CMY-based colour circle. The colour chords can becomplemented to a quality contrast [Itt61] by changing the saturation.

By using any kind of perspective it is possible to realise three dimensional decorations. Theperspective aspect of a pattern is mainly determined by the colour schema. In particular,

we have to consider the effect of the colours, because the objects coloured by warm coloursappear closer than those in cold colours. Warm colours are assigned to light, while coldcolours are assigned to shadow.

The visual alignment is based on a tiling of the screen as a two-dimensional surface. Ingeneral, we divide the horizontal and vertical axes using grid points xmin = x0 < x1 <... < xm = xmax and ymin = y0 < y1 < ... < yn = ymax. A tile is defined by arectangular region [xi, xj ]× [yk, y`]. Then we partition the whole screen into tiles. A verycommon tiling is obtained by using just 4 horizontal grid points x0 < x1 < x2 < x3, andonly 3 vertical grid points y0 < y1 < y2. Then we can define four tiles

up = [x0, x3]× [y1, y2] left = [x0, x1]× [y0, y1]middle = [x1, x2]× [y0, y1] right = [x2, x3]× [y0, y1]

Usually, the “up” tile is used for some menu bar, the “left” tile for navigation links, the“middle” tile for major content and the “right” tile for side options.

3.3 Grid Geometry

Grids were adapted from (conventional) graphic design and used for organising page lay-outs, e.g. newspapers, magazines and other documents [vDLH02]. The tiling describedabove is a very common but simple grid that only divides rows and columns, without anyother restrictions. More sophisticatedly, the size of visual building blocks can follow arhythmic structure that can be expressed by a sequence of positive integers. Then an ob-server perceives larger tiles of a sequence as being more important, in particular, if thesequence shows a monotonic pattern.

Due to its overwhelming use in art and architecture over centuries we are particularlyinterested in the Fibonacci sequence, which is defined by the recurrence fn+2 = fn+fn+1

with the starting values f1 = f2 = 1. This gives the well-known sequence 1,1,2,3,5,8,13,...It also gives rise to the number of golden section, which played an important role in artand architecture and appears naturally in nature.

Figure 2 illustrates the visual flags model as a simple use of Fibonacci sequence. In fact itdates back to Leonardo da Vinci and orders sections according to some functional criteria.In this example the Fibonacci numbers (multiplied with a scaling constant) are used ashorizontal grid points.

Figure 2: Rhythmic structure of visual building blocks (grid tiles)

Another use of the Fibonacci sequence is to place squares with increasing side lengthfi along a spiral as shown in the lower part of Figure 3. In doing so we obtain a very

nice tiling of the screen (golden square), in which the proportions of the square tiles aredetermined by the Fibonacci sequence. By combining with the visual flags we realise theso-called Fibonacci grid model (Figure 3).

Figure 3: The Fibonacci grid model

If each tile is associated with a colour of a well-chosen colour schema, this enables desiredatmospheric effects as specified in the strategic WIS model [MST05]. The thesis [Mor06]shows this combination of the Fibonacci grid with various colour schemata in differentweb application projects.

4 Cognitive Aspects of Screenography for Layout

Screenography bases screen and particularly WIS layout on cognitive psychology. Thelayout of WIS pages contains functional elements such as icons for navigation and func-tions, and visual elements for presentation of texts based on script and colour and of pic-tures and structures in different displays. The designed screen is regarded as a structuredcomposition of different elements and is defined as screen layout. Enhanced descriptionshow to design the user interface was depicted through Norman [Nor88] and Shneiderman[SP04]. Screenography uses three kinds of principles taken from cognitive psychology:principles of visual communication, of visual cognition, and of visual design.

4.1 Principles of Visual Communication

A clear and well-defined design of a screen layout helps to grasp and to understand thecontent and enables to select and to access the information. It is a precondition for the suc-cessful communication. Visual communication is based on the exchange of visual codeswith special meanings. Sender and recipient agree on the meaning of the communicationutterances which are typically expressions in a visual language adopted and understood byboth partners. A sophisticated specification of visual communication is one preconditionfor interaction support. It consists of three components:

• Vision supports users depending on their physical and physiological properties. Usersare used and are limited to certain colouring schemata, to different presentationstyles and to different reception styles.

• Cognition is based on the physiological and psychological abilities and skills ofusers. We must take into consideration the approach users take while reading contentand using functionality.

• Processing and memorising characteristics are based on the psychological ability toread, integrate, and reason about content provided by a page, and to memorise mainparts of the content – these vary a lot among users.

Visual communication starts with separating the visual entities on the screen into ele-mentary layout elements. This separation is an analytical process. Visual elements arecompared, processed and memorised after recognising them. The scenario for visual com-munication can be used for developing the layout, i.e. we reverse the order of visualcommunication. First, visual elements that should be memorised are developed and in-tegrated with the content and functionality necessary for their recognition. Next, theseelements are integrated into a draft of the layout. Finally, adornments, presentations, andplacements are added.

4.2 Principles of Visual Cognition

Principles of visual cognition and visual communication refer to ordering, effect delivery,and visualisation. Ordering is based on an arrangement according to the reading directionand on design according to foreground and background relation. The effect uses back-ground for formation of thematic and optical frame, and schemes of colours and structures.Visualisation is influenced by visual design features such as colour, contrast, composition,overlapping, and cuts [Goe10, Itt61].

We can use a number of principles of visual cognition in screenography. Users are limitedby their time, attention, scope, and task portfolio. These limitations must be taken intoconsideration for layout and playout development. We distinguish four principles thatshould be preserved:

• The principle of organisation requires that screens must be based on a simple, clearand consistent structure. The simplicity, clearness and consistency depends on thecultural background of users.

• The principle of economy requires that users should spend minimal effort for recog-nition and reasoning on visual elements. This principle is supported by minimisationof the set of tools. Users increase their effectiveness of recognition and reasoning.

• The principle of communication considers the abilities and the skills of users. Thisprinciple is well known from didactics, where content and functionality are adoptedto the capacity of users.

• Screen design standards allow the user to reuse their previous recognition and rea-soning results. These standards define the organisation and design of visual ele-ments.

4.3 Principles of Visual Design

We use a number of principles of visual design in screenography:

• The optical vicinity principle requires that elements are arranged close to each other,if they are related.

• The similarity principle is based on human cognition according to which elementsof similar shape are identified as a visual unit.

• Closeness is based on the human visualisation according to which objects need tohave a closed shape. Otherwise, missing elements are added.

• The symmetry principle uses units that consist of symmetrically assembled elements.Symmetric and asymmetric structures are visualised in the foreground, whereas allother asymmetric elements are taken to the background.

• The conciseness principle uses visualisation with simplified and consistent organi-sation of visual screen elements.

• The reading direction principle optically composes static elements (pictures, texts,icons) by the given reading direction. This leads to a shift of the optical focus. Wedistinguish between geometrical and optical centre. For instance, the thickness ofhorizontal lines is optically enhanced. Vertical lines seem to be thinner.

These principles help to organise the elements within a page in a way that correspondto human perception. Elements are always recognised within their context. Their valuediffers based on their syntax, i.e. the formal and aesthetic value, based on semantics, i.e.content and objective value, and based on pragmatics, i.e. ethic and applicability value.

5 Application of Screenography: Case Study

In this chapter we demonstrate the potential of the screenography approach, using a B2Cexample. This example indicates how we achieve an adaptive playout, considering theintention of the WIS, user profile and portfolio as well as existing lifecases. In general thisB2C-WIS offers company and product informations can described by following informa-tion pattern (who-what-to whom-what activity):

(company)information on products2(visitor, purchaser)inform,purchase

In our example acts a small business, producing hand-made collections of wood-figures.The aim of company is to distribute the collections via the web. The content per pageshouldn’t be oversized, because the carefully selected product choice and important role ofquality. Wood as basic material of all products of the company should be considered. Con-sidering the business philosophy, the presentation style have to be traditional and folksy.The ambience type ’balanced’ implies that.Before defining the ’balanced’-colours we have to characterise the user. That’s necessarybecause the perception and impression of colours depends on capabilities of a user ande.g. cultural as well as religious views. Moreover the age of a user plays an importantrole. In our example the user is a married european man in his thirties, without specialcolour preferences. The user prefers a conservative design resp. a adequate composition.In conjunction with the intentions we deduce a suitable colour chord illustrated in fig. 4.

Figure 4: colour chord - ambience type ’balanced’

Subsequent to the atmosphere determining, we have to choose a pattern. Pattern consist ofthree parts: visual alignment, colourising and perspective perception (section 3.2). Visualalignment is influenced by lifecases, perspective requirements and the user profile as wellas main properties and targets. For instance the content size and the navigation structureand depth influence the tiling. The example user acts deliberate and target oriented. Hehas no handicaps but don’t prefer very small interaction elements. We consider lifecasesto achieve the best possible orientation the user should have during the acting progress.Thus it’s possible to choose the Fibonacci grid for representation, illustrated in figure 3.The way of assigning the colours to the pattern mainly depends on chosen ambience type.The coloured pattern is illustrated in figure 5.

Figure 5: Fibonacci grid model with ambience type ’balanced’

The last step integrates the content. The representation of content considers user andprovider preferences. For instance an adequate picture-size to present details of the hand-made products. User portfolio and lifecases influence the story flow. Furthermore, de-pending on tasks they have influence in content representation, e.g. the type of progress.The result of the development process is illustrated in figure 6.

Figure 6: Sample page for ’balanced’ atmosphere

6 Conclusion

This paper presented screenography, a novel approach to layout and playout of Web Infor-mation Systems (WISs). Screenography transfers the accumulated knowledge in scenogra-phy and dramaturgy from its origins in theatre, film and television to the web area therebyexploiting results from creative arts, cognitive psychology, and stage scenography. Therationale behind our work is that layout and playout are not merely activities that start,when the major system design has been completed, but must be treated as integral partof WIS development from the very beginning; a poor layout can nullify all sophisticatedmodelling work, because the layout is the ultimate carrier of information in a WIS.Screenography is tightly intertwined with storyboarding, the method for WIS usage mod-elling on a high level of abstraction [ST05b]. It contributes to page partitioning and colourscheme definition in a holistic way.

Screenography is an attempt to turn WIS layout and playout from an art into a craft, i.e. itaims at enabling WIS designers to engineer systems that by virtue of their presentation areconceived as exceeding the expectations of its users. The work presented in this paper isa first step in this direction, yet still much more has to be done to extract knowledge fromarts and bring it into a form that can be used by WIS engineers.

References

[BGB98] D. Benyon, T. Green, and D. Bental. Conceptual modeling for user interface develop-ment. Springer, London, 1998.

[Car91] John M. Carroll, editor. Designing Interaction: Psychology at the Human-ComputerInterface. Cambridge University Press, Cambridge, England, 1991.

[CFB+03] S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, and M. Matera. DesigningData-Intensive Web Applications. Morgan Kaufmann, San Francisco, 2003.

[Con03] J. Conallen. Building Web Applications with UML. Addison-Wesley, Boston, 2003.

[DL98] O. De Troyer and C. Leune. WSDM: A User-Centered Design Method for Web Sites.In Computer Networks and ISDN Systems – Proceedings of the 7th International WWWConference, pages 85–94. Elsevier, 1998.

[Goe10] J. W. Goethe. Farbenlehre. Cotta, Stuttgart, 1810.

[Gre85] M. Green. Report on Dialogue Specification Tools. In: G. E. Pfaff (Ed.) “User InterfaceManagement Systems”. Springer Verlag, Berlin, 1985.

[HBFV03] G.-J. Houben, P. Barna, F. Frasincar, and R. Vdovjak. HERA: Development of SemanticWeb Information Systems. In Third International Conference on Web Engineering –ICWE 2003, volume 2722 of LNCS, pages 529–538. Springer-Verlag, 2003.

[Itt61] J. Itten. Kunst der Farbe. O. Maier, 1961.

[Joh97] S. Johnson. Interface culture. Harper, San Francisco, 1997.

[LHSG02] D. Lowe, B. Henderson-Sellers, and A. Gu. Web Extensions to UML: Using the MVCTriad. In Stefano Spaccapietra, Salvatore T. March, and Yahiko Kambayashi, editors,Conceptual Modeling – ER 2002, volume 2503 of LNCS, pages 105–119. Springer-Verlag, 2002.

[MNST07] T. Moritz, R. Noack, K.-D. Schewe, and B. Thalheim. Principles of Screenography.CAiSE Forum, 2007. 4 pages.

[Mor06] T. Moritz. Visuelle Gestaltungsraster interaktiver Informationssysteme als integrativerBestandteil des immersiven Bildraumes. PhD thesis, HFF Berlin-Babelsberg, 2006.

[MST05] T. Moritz, K.-D. Schewe, and B. Thalheim. Strategic Modelling of Web InformationSystems. International Journal on Web Information Systems, 1(4):77–94, 2005.

[Nor88] D. Norman. The design of everyday things. Doubleday, New York, NY, 1988.

[SP04] B. Shneiderman and C. Plaisant. Designing the User Interface: Strategies for effectivehuman-computer interaction. Addison-Wesley, x, 2004.

[SR98] D. Schwabe and G. Rossi. An Object Oriented Approach to Web-Based ApplicationDesign. TAPOS, 4(4):207–225, 1998.

[ST05a] K.-D. Schewe and B. Thalheim. The Co-Design Approach to Web Information SystemsDevelopment. International Journal on Web Information Systems, 1(1):5–14, 2005.

[ST05b] K.-D. Schewe and B. Thalheim. Conceptual Modelling of Web Information Systems.Data and Knowledge Engineering, 54(2):147–188, 2005.

[ST06a] K.-D. Schewe and B. Thalheim. Usage-Based Storyboarding for Web Information Sys-tems. Technical Report 0613, Christian Albrechts University Kiel, Germany, 2006.

[ST06b] K.-D. Schewe and B. Thalheim. User Models: A Contribution to Pragmatics of WebInformation Systems Design. In K. Aberer, Z. Peng, and E. Rundensteiner, editors, WebInformation Systems – Proceedings WISE 2006, volume 4255 of LNCS, pages 512–523.Springer-Verlag, 2006.

[Val82] E. Vale. The technique of screen and television writing. Simon and Schuster, New York,1982.

[vDLH02] D. K. van Duyne, J. A. Landay, and J. I. Hong. The Design of Sites: patterns, principlesand processes for crafting a customer-centered Web experience. Addison Wesley, 2002.

Quality Assurance in the Design of

Web Information Systems

Aleksander Binemann-Zdanowicz1, Klaus-Dieter Schewe2, Bernhard Thalheim1, Jane Zhao2

1Christian Albrechts University Kiel, Institute of Computer Science and Applied MathematicsOlshausenstr. 40, 24098 Kiel, Germany

[binemann|thalheim]@is.informatik.uni-kiel.de2Massey University, Information Science Research Centre & Department of Information Systems

Private Bag 11222, Palmerston North, New Zealand

[k.d.schewe|j.zhao]@massey.ac.nz

Abstract

Despite the fact that several integrated development

methods for web information systems (WISs) have been

proposed, quality assurance for such systems has hardly

been addressed. In this paper some quality criteria are

postulated and investigated by combining semi-formal

and formal methods. On a high level of abstractions

WISs can be described by abstract locations and tran-

sitions between them. These so-called story spaces can

be formalised using Abstract State Machines (ASMs),

which permit to verify, whether user-tailored versions

are compatible with user preferences. Furthermore,

ASMs provide a framework for refinement, which per-

mits the integration of story spaces with extended views

on databases. This leads to further proof obligations for

consistency that can be formalised in the logic associated

with ASMs.

Keywords. Abstract State Machines, Web InformationSystems, Quality Design, Re¯nement

Topics. software quality, formal methods, applications

1 Introduction

The ¯eld of web information systems (WISs) design hasrecently attracted a lot of research, and several inte-grated development methods such as WSDM [10], HERA[14], WebML [8], and Co-Design [18] have arisen fromthese e®orts.

Following [18] there are several levels of abstraction,on which such systems should be speci¯ed. On a highlevel of abstraction a WIS can be described by abstractlocations and transitions between them that are initi-ated by user actions. The technical term used for such

a speci¯cation is story space, and the abstract locationsare called scenes. Initially story spaces can be modelledby layered, edge-labelled directed graphs or equivalentlystatecharts [12]. Looking more at the °ow of actions anassignment-free process algebra can be used, e.g. thelanguage SiteLang from [20]. The algebraic expressionresulting from this is called the action scheme or plot

of the story space. It can still be visualised using stat-echarts. An implementation of SiteLang based uponAbstract State Machines (ASM) [7] has been proposedin [1, 4, 3].

On a lower level of abstraction the scenes are speci¯edin details using media types, i.e. views on some under-lying database schema that are extended by operationsand various options that enable adaptivity and tailoredpresentations. In particular, the operations re¯ne theactions of the story space including now updates to thedatabase.

In this paper we investigate quality of WISs startingfrom selected quality criteria. Among them is of courseconsistency of the speci¯ed operations with respect tovarious static and dynamic integrity constraints. In ad-dition, a speci¯c quality criterion for a WIS is its suit-ability for users. As users are not known in advance,hence can only be anticipated, it becomes necessary thatWISs can customise themselves to users. We formalisethis as customisation to the preferences of users. A par-ticular realisation of it is known as content conditioning

and is based upon the algebraic description of websitestoryboards [5, 2]. A third quality criterion concerns thedevelopment method as such, which should be scalableto WISs of various types and sizes.

The question is how these quality criteria can be satis-¯ed. As a general idea we propose using ¯rst integratedmodels on various levels of abstraction. This is partlysatis¯ed by the models of story spaces and the media

types, but still we have to verify that both models ¯t to-gether. In this paper we use the formalism of AbstractStae Machines (ASMs) [7] for this purpose. ASMs pro-vide a formal notion of re¯nement, which will allow us toconsider the detailed level of abstraction just as a resultof re¯nement. That is, we remain within the same for-mal framework. Furthermore, this framework of ASMs ispowerful enough to capture all our desiderate, as provenin [6, 11].

On the basis of ASMs we can formalise proof obli-gations and verify them. With respect to the customi-sation to users we add user-speci¯c information to theplots. Using also user preferences and goals we can themverify the compatibility with the user-speci¯c plots. Forconsistency we exploit the dynamic logic of ASMs.

2 Story Spaces

On a high level of abstraction we may think of a WIS asa set of abstract locations, which abstract from actualpages. A user navigates between these locations, and onthis navigation path s/he executes a number of actions.We regard a location together with local actions, i.e. ac-tions that do not change the location, as a unit calledscene.

Then a WIS can be decribed by a edge-labelled di-rected multi-graph, in which the vertices represent thescenes, and the edges represent transitions betweenscenes. Each such transition may be labelled by an ac-tion executed by the user. If such a label is missing, thetransition is due to a simple navigation link. The wholemulti-graph is then called the story space.

Scenes may be atomic or complex. In the latter casethe scene itself represents another set of abstract loca-tions, between which users can navigate. This gives riseto a multi-layer model. Roughly speaking, a story is apath in the story space. It tells what a user of a partic-ular type might do with the system.

The combination of di®erent stories to a subgraph ofthe story space can be used to describe a “typical” use ofthe WIS for a particular task. Therefore, we call such asubgraph a scenario. Usually storyboarding starts withmodelling scenarios instead of stories, coupled by theintegration of scenarios to the story space.

De¯nition 1 A scenario E = (S,A, ¾, τ) consists of

• a ¯nite set S of scenes,

• a ¯nite set A of actions,

• a scene assignment ¾ : A → S, i.e. each action α

belongs to exactly one scene,

• and a scene transition relation τ µ S × S × (A ∪skip), i.e. whenever there is a transition fromscene s1 ∈ S to scene s2 ∈ S, this transition isassociated with an action α ∈ A with ¾(α) = s1

or with α = skip, in which case it is a navigationwithout action, and we have (s1, s2, α) ∈ τ .

We can represent a scenario by an edge-labelled di-rected graph, in which the vertices correspond to thescenes, i.e. to S and the edges to the scene transitions,i.e. to τ .

Example 1

Consider an event calendar application, originally de-veloped as part of the project www.cottbus.de [19]. Itcomprises a series of steps allowing to enter event infor-mation and to perform operations upon a created event,e.g. releasing it for deployment, or canceling it. At ageneral re¯nement level, the simpli¯ed storyboard forthe event calendar application looks as follows.

t

K

Login

K

j

Addnew event

j Enterdetails

UView

ongoingevents

j

Releaseeventsetup

Cancelevent

Chooseevent

K

U

y

9

Archivepastevent

General Specification of Event Calendar

Figure 1: Re¯nable Scenario Speci¯cation

3 ASM-based Plots

So far our presentation of story spaces was centeredaround the scenes as abstractions of locations betweenwhich users navigate and on which actions are selectedand executed. Let us now look closer at the °ow of ac-tions, which leads to action schemes or plots giving usa detailed, yet still high-level speci¯cation of functional-ity. For this consider the language SiteLang [20], whichde¯nes an algebra that captures the details of plots. Wetake the set A of actions and the set S of scenes from ascenario E as the basis for de¯ning the set of processes

P = P(A,S) determined by A and S.

De¯nition 2 Let E = (S,A, ¾, τ) be a scenario. Theset of processes P = P(A,S) determined by A and S isinductively de¯ned as follows:

• Each action α ∈ A is also a process, i.e. α ∈ P.

• skip is a process.

• If p1 and p2 are processes, then also the sequence

p1; p2 is a process.

• If p1 and p2 are processes, then also the parallel

process p1‖p2 is a process.

• If p1 and p2 are processes, then also the choice p12p2

is a process.

• If p is a process, then also the iteration p∗ is a pro-cess.

• If p is a process and ϕ is a boolean condition, thenthe guarded process ϕp and the post-guarded pro-

cess pϕ are processes.

Then the plot of a scenario E = (S,A, ¾, τ) is speci¯edby a process p ∈ P(A,S). Using ASMs such a plot isnothing more than an update rule, in which there is noassignment [7]. As a consequence there is no need to pro-vide a signature, i.e. updatable functions, at the generalabstraction level. Furthermore, all atomic actions α ∈ Acorrespond to call-rules. Adding a signature and detailsto atomic actions is a re¯nement task.

Example 2 The following is the plot for the scenarioin Example 1. The postcondition notYetChosen ensuresthe same event has not been open for modi¯cations inanother session.

Login ; (Add new event ; Enter details) 2 skip) ; (View on-

going events ; Choose eventnotYetChosen ; Enter details)∗

; (View ongoing events ; Choose eventnotYetChosen ;

(Archive past event 2 Cancel event 2 Release event setup

))

4 Refinement of Scenarios and

Plots

Scenes in a scenario or the whole story space can beatomic or complex. In the latter case they represent adetailed dialogue of users with the system. Thus, theycan be speci¯ed by a scenario, and consequently also bya plot. We may then replace the scene s by its de¯ningscenario E(s) and redirect transitions that lead into s orstart from s.

Similarly, whenever the action α in the plot leads toscene s, the plot will be re¯ned by adding a SiteLang

process following α.

Example 3 We ¯rst re¯ne the scenario in Example 1.It is a (1, n) re¯nement [7] with respect to the processRelease event setup in Figure 1. Note this is a cor-rect and complete re¯nement of the general speci¯ca-tion. The general process Release event setup is replacedwith checking whether the permission is granted and ifso, with three actions executed parallely: publishing acommercial for the event, issuing ¯nal orders for neces-sary supplies, and archiving the released version of theevent information. The three latter actions are possi-bly performed by di®erent actors, but this aspect is notconsidered on this abstraction level.

t

K

Login

K

j

Addnew event

j Enterdetails

UView

ongoingevents

j

Checkrelease

permissionCancelevent

Chooseevent

K

U

y

9

Archivepastevent

Publishcommercial

9Ordersuppliers

UArchive

release

z

Refinement of Event Calendar at the Release Process

Figure 2: Re¯ned Scenario Speci¯cation

Accordingly, the following plot re¯nes the one in Ex-ample 2. The postcondition permissionGranted statesthe next steps can be accomplished as the relevant partof the re¯ned process Release event setup has been en-abled.

Login ; (Add new event ; Enter details) 2 skip) ; (View on-

going events ; Choose eventnotYetChosen ; Enter details)∗


(Archive past event 2 Cancel event 2 (Check release per-

missionpermissionGranted ; ( Publish commercial ‖ Or-

der suppliers ‖ Archive release )) ))

5 Verification of User Preferences

The major quality aspect on the level of story spaces isthe suitability of the speci¯ed system for its users. In

order to achieve this suitability, we de¯ne roles and user

types.A role is associated with certain rights and obliga-

tions, which is re°ected in the scenario by associatingactions with the corresponding roles. That is, only usersin these roles may execute the actions. Consequently,if r is a role, we can obtain a role-speci¯c scenario forr by ¯rst eliminating all actions that are not associatedwith r and then eliminating all isolated scenes. Further-more, the presence of roles permits a simpli¯cation ofthe associated plot.

Example 4 The following is a role-speci¯c scenario forrole Supplier Contact Person in the scenario in Exam-ple 1. As we can see, the new process Check whether re-

leased has been introduced. It is thus a correct but notcomplete re¯nement [7]. In order to obtain a completere¯nement, an appropriate union of re¯nements for theroles foreseen in the speci¯cation is performed accord-ingly. This procedure is also conform to the well-provenutilisation of the ASM-based SiteLang methodology [3].

t

K

Login

K

Viewongoingevents

j Chooseevent

U zEnterdetails

y

Ordersuppliers

Checkwhetherreleased

U

Specification Refinement for Supplier Contact Person

Figure 3: Role-Speci¯c Re¯nement

Accordingly, the following plot is speci¯c for thisrole. The precondition toSupply determines the respec-tive event is still to be provided with supplies and thusof relevance to this user role.

Login ; (View ongoing events ;

Choose eventnotYetChosen ; toSupplyEnter details)∗


Check whether released ; Order suppliers

Analogously, we may set up user types, for which wemay determine customised scenarios and plots in thesame way as for roles.

In addition, user types lead to preference rules. Theserules de¯ne equations on processes. We consider the fol-lowing types of preference rules:

• An equation of the form ϕ(α2β) = ϕα ex-presses that a user conditionally prefers action α

over action β, where the condition is expressed byϕ. The special case ϕ = true expresses an uncondi-tional preference.

• An equation of the form ¬ϕα = fail (or equiva-lently α = ϕα) expresses that the condition ϕ isa precondition for the action α.

• An equation of the form α¬ϕ = fail (or equiva-lently α = αϕ) expresses that the condition ϕ isa postcondition for the action α.

• An equation of the form αϕ = ϕα, whichis equivalent to ¬ϕα = α¬ϕ and toϕα¬ϕ2¬ϕαϕ = fail, expresses that thecondition ϕ (and so its negation ¬ϕ) is invariantunder the action α.

• An equation of the form ϕ ∧ Ã = false expressesthat the conditions ϕ and Ã exclude each other.

Here we used an additional process fail, which is neverde¯ned.

The presence of preference rules allows us to verifythe user-type-speci¯c plots. If p′ is such a plot for a usertype U , while p is the general plot, from which p′ wasderived, we have to show that p = p′ can be derived fromthe preference rules, the general rules that govern equal-ities between processes such as associativity of choice,sequence and parallelism, commutativity of choice andparallelism, neutrality of skip for sequence and paral-lelism and of fail for choice, etc., and the general rulesfor propositional logic.

Example 5

The following properties, i.e. user preference rules, canbe speci¯ed for the role-speci¯c storyboard in Example 4.

Preconditions and postconditions:

Choose event¬ notYetChosen = fail

¬ toSupplyEnter details

The veri¯cation of the event setup release conditiondoes not a®ect the event details obtained before (thisdesired property requires a further re¯nement of the sto-ryboard):

detailsEnteredCheck whether released =

Check whether releaseddetailsEntered

Once a supplies order has been accomplished, nodetails can be added to the event speci¯cation:

Order suppliers¬ detailsEditable

6 Refinement through Media

Types

The speci¯cation of WISs through story spaces resideson a propositional level, i.e. assignments are not yet con-sidered. When we proceed to a lower level of abstractionwe add media types, i.e. views on some database schemathat are extended by operations and other extensionsthat are not so important for us now.

In terms of ASM re¯nements the introduction of me-dia types ¯rst means to add a signature to the ASM.Each function symbol in this signature corresponds to atype in the database schema. The de¯ning queries of theviews give rise to expressions of the form Ix.ϕ denotingthe unique value x determined by formula ϕ.

The operations give rise to more complex ASM rulesde¯ning the action in the story space. In general, an op-

eration consists of a signature and a body . The signature

consists of an operation name O (which comes from thestory space), a set of input-parameter/type pairs ιi : tiand a set of output-parameter/type pairs oj : t′j . Thebody is an ASM rule built using the following constructs:

• skip and fail, denoting operations that do notchange anything or are not de¯ned, respectively, arerules

• An assignment f(t1, . . . , tn) := exp with an updat-able function f in the signature of arity n and anexpression of the same type as x is an ASM rule.Here we permit expressions Ix.ϕ corresponding toqueries.

• If p, p1 and p2 are ASM rules, the same holds for theiteration p∗, the choice p12p2, the sequence p1; p2,and the parallel rule p1‖p2.

• If p is an ASM rule and ϕ is a condition, then theguarded program ϕp and the postguarded program

pϕ are also ASM rules.

• If x is a variable and p is an ASM rule, then theselection @x • p is also an ASM rule.

Example 6

Consider the re¯nement of the process Re-

lease event setup as shown in Example 3. Its plotlooks as follows.

(Check release permissionpermissionGranted ; ( Pub-

lish commercial ‖ Order suppliers ‖ Archive release ))

It can be described by the following ASM.doCheck release permissionif permissionGranted(e) thenPublish commercialOrder suppliersArchive release

It is then re¯ned by specifying the correspondingviews PermittedRelease, CommercialState, Order (as-sumed updatable), Archive, Supply, and Requirements,as well as the new rule Generate archive view as follows.

doif Ix.(PermittedRelease(e)) 6= ∅ thenpermissionGranted(e) := true

;if permissionGranted(e) thenCommercialState(e) := releasedOrder(e) := @x • (Supply(x) ./ Requirements(e,x))Archive(e) := @x • (Generate archive view)

Note that we deviated slightly from the syntax in [7].So we now obtain a full-°edged ASM that speci¯es thedetails of the WIS. With respect to the connection tothe story space, the propositional conditions ϕ now haveto be re¯ned to conditions on the database schema.

7 Proof Obligations in the Logic

of ASMs

With the introduction of media types to support sceneswe can now exploit the dynamic logic of ASMs that hasbeen de¯ned in [7] to formalise consistency proof obliga-tions and to verify them. In this logic we look at formulaeof the form [p]ϕ with an ASM rule p and a formula ϕ.Informally, [p]ϕ means that after the successful execu-tion of p the formula ϕ necessarily holds. In addition,we use the shortcut 〈p〉ϕ ´ ¬[p]¬ϕ, so 〈p〉ϕ means thatafter the successful execution of p it is possible that theformula ϕ holds.

Using our recursive de¯nition above the following rulesapply to [p]Ã for a complex ASM rule p:

[skip]Ã ´ Ã

[fail]Ã ´ false

[x := t]Ã ´ Ãx/t (substitute all free occurencesof x in Ã by t)

[p1; p2]Ã ´ [p1][p2]Ã[p12p2]Ã ´ [p1]Ã ∧ [p2]Ã

[p∗]Ã ´ the weakest solution ϕ of ϕ↔ Ã ∧ [p]ϕ[ϕp]Ã ´ ϕ→ [p]Ã[pϕ]Ã ´ [p](ϕ→ Ã)

[@x • p]Ã ´ ∀x.[p]Ã

The equivalence for the iteration operator refers to theimplication order, i.e. if ϕ |= Ã holds, then Ã is calledweaker than ϕ. A more detailed de¯nition including fur-ther rules regarding the structure of Ã is given in [7].

In the sequel we will discuss two applications of thisdynamic logic:

• We take a look at proof obligations for the opera-tions that result from the speci¯cation of the storyspace.

• We take a look at proof obligations for the opera-tions that arise from static and dynamic integrityconstraints on the underlying database schema.

Let p denote the SiteLang expression that representsthe complete story space. If all conditions in p are re-placed by conditions on the database schema and all ac-tions are replaced by the ASM rules de¯ning the realisingoperations, we obtain an ASM rule, which by abuse ofnotation shall still be denoted p.

As a WIS has a general purpose, this can be for-malised by some post-condition Ã. Thus, [p]Ã describesthe weakest condition, under which the purpose of thesystem can be achieved. If ϕ characterises a precondi-tion that should be su±cient for the achievability of theWIS purpose, then we obtain ϕ→ [p]Ã as a general story

space proof obligation. In most cases we should expectϕ ´ true.

Similarly, we may concentrate on fragments p′ of thestory space expression of the form ϕpÃ, which corre-sponds to a Hoare triplet and thus gives rise to a special

story space proof obligation ϕ→ [p′]Ã.A static constraint on the underlying database schema

S is a condition ζ, in which the free variables are amongthe R ∈ S. Such constraints give rise to the request thatwhenever an operation is started in a database satisfy-ing ζ, then the database reached after successfully com-pleting the execution of the operation, must necessarilysatisfy ζ, too.

That is, for all operations p that are de¯ned on a pre-site and all static constraints ζ we obtain a static con-

sistency proof obligation ζ → [p]ζ.A dynamic constraint on the underlying database

schema S = R1, . . . , Rn is a condition ζ, in which thefree variables are among in S∪S ′ with S ′ = R′

1, . . . , R′n

and each R′i having the same type as Ri. The additional

variables R′i are used to distinguish between S-databases

db, on which an operation p is started, and S ′-databasesdb′ resulting after p has been successfully executed.

Obviously, a dynamic constraint ξ has to be inter-preted on a pair (db, db′) of databases. Following a stan-dard approach to dynamic consistency we associate with

ξ an abstract program

p(ξ) = @R′1, . . . , R

′n • ξ R1 := R′

1 . . . Rn := R′n.

Then dynamic consistency of an operation p with re-spect to ξ means that p must “specialise” p(ξ), i.e. werequire that [p(ξ)]Ã → [p]Ã for all conditions Ã on S.Fortunately, this proof obligation can be rephrased us-ing a renaming p′ of p(ξ) given by

p′ =@R′1, . . . , R

′n • ξR1/R

′′1 , . . . , Rn/R′′

n

R′′1 := R′

1 . . . R′′n := R′

n.

Then the dynamic consistency proof obligation for p

with respect to ξ becomes

([p′]〈p〉(R1 = R′′1 ∧ ¢ ¢ ¢ ∧Rn/R′′

n))R′′1/R1, . . . , R

′′n/Rn.

Example 7

8 Conclusion

In this paper we combined parts of a semi-formal de-velopment method for web information systems (WISs)[18] with the formal method of Abstract State Machines(ASMs) [7]. We showed that the assignment-free °ow ofactions – called plot – can be easily modelled by ASMs,which leads to three opportunities for quality assurance.

The ¯rst opportunity arises from considering user-customised plots, as ASMs permit the veri¯cation ofconsistency of these plots with user preferences. This isin accordance with the personalisation approach in [17],which was based on equational reasoning with Kleenealgebras with tests (KATs) [15]. It can also be appliedto quality-checking the localisation in [9].

The second opportunity arises from exploiting re¯ne-ments of ASMs, which permits the formalisation of WISson a lower level of abstraction, but staying within thesame formal framework. In particular, this capturesextended views on databases – called media types in[18]. This re¯nement-based approach guarantees thatthe lower-level model is consistent with the higher-levelone.

The third opportunity arises from the logic associatedwith ASMs, which permits the veri¯cation of further con-sistency proof obligations for detailed ASMs. This is inaccordance with the formalisation of proof obligationsfor WISs using higher-order dynamic logic [13] in [16].

This captures three important aspects of quality ofWISs: the suitability of a system for its users, the consis-tency of the system with respect to various constraints,and the scalability with respect to various applications.As the approach is based on ASMs, most common theo-rem provers can be used in accomplishing the veri¯cationtasks.

References

[1] Binemann-Zdanowicz, A. Towards information sys-tem modeling on the basis of asm semantics. InComputer Science Report I-12/2001, Brandenburg

University of Technology at Cottbus (2001).

[2] Binemann-Zdanowicz, A. Supporting di®eringlearning and perception styles with content condi-tioning. In Proc. ICALT’2004, Joensuu, Finland,

August/September 2004 (2004), pp. 485–489.

[3] Binemann-Zdanowicz, A., Kramer, Z., Schmidt, P.,and Thalheim, B. Asm support for the validationof speci¯cations: Lessons learned from an egovern-ment project. In Proc. Abstract State Machines

Conference (ASM 2005) (2005), Springer-Verlag.

[4] Binemann-Zdanowicz, A., and Thalheim, B. Model-ing information services on the basis of asm seman-tics. In Proc. ASM’2003, Lecture Notes in Com-

puter Science 2589 (2003), Springer, pp. 408–410.

[5] Binemann-Zdanowicz, A., Thalheim, B., andTschiedel, B. Storyboarding for adaptive contentgeneration for e-learning web services. In Computer

Science Report I-10/2003, Brandenburg University

of Technology at Cottbus (2003).

[6] Blass, A., and Gurevich, Y. Abstract state machinescapture parallel algorithms. ACM Transactions on

Computational Logic 4, 4 (2003), 578–651.

[7] Borger, E., and Stark, R. Abstract State Machines.Springer-Verlag, Berlin Heidelberg New York, 2003.

[8] Ceri, S., Fraternali, P., and Matera, M. Conceptualmodeling of data-intensive web applications. IEEE

Internet Computing 6, 4 (2002), 20–30.

[9] De Troyer, O., and Casteleyn, S. Designing lo-calized web sites. In Web Information Systems –

WISE 2004, vol. 3306 of LNCS. Springer-Verlag,2004, pp. 547–558.

[10] De Troyer, O., and Leune, C. WSDM: A user-centered design method for web sites. In Com-

puter Networks and ISDN Systems – Proceedings of

the 7th International WWW Conference. Elsevier,1998, pp. 85–94.

[11] Gurevich, Y. Sequential abstract state machinescapture sequential algorithms. ACM Transactions

on Computational Logic 1, 1 (2000), 77–111.

[12] Harel, D. Statecharts: A visual formalism for com-plex systems. Science of Computer Programming 8

(1987), 231–274.

[13] Harel, D., Kozen, D., and Tiuryn, J. Dynamic

Logic. The MIT Press, Cambridge (MA), USA,2000.

[14] Houben, G.-J., Barna, P., Frasincar, F., and Vdov-jak, R. HERA: Development of semantic web infor-mation systems. In Third International Conference

on Web Engineering – ICWE 2003 (2003), vol. 2722of LNCS, Springer-Verlag, pp. 529–538.

[15] Kozen, D. Kleene algebra with tests. ACM Transac-

tions on Programming Languages and Systems 19,3 (1997), 427–443.

[16] Schewe, K.-D. The power of media types. In Web

Information Systems – WISE 2004, X. Zhou, S. Su,M. P. Papazoglou, M. E. Orlowska, and K. G. Jef-fery, Eds., vol. 3306 of LNCS. Springer-Verlag, 2004,pp. 53–58.

[17] Schewe, K.-D., and Thalheim, B. Reasoning aboutweb information systems using story algebras. InAdvances in Databases and Information Systems,A. Benczur, J. Demetrovics, and G. Gottlob, Eds.,vol. 3255 of LNCS. Springer-Verlag, 2004, pp. 54–66.

[18] Schewe, K.-D., and Thalheim, B. Conceptual mod-elling of web information systems. Data and Knowl-

edge Engineering (2005). to appear.

[19] Thalheim, B., Binder, C., Feyer, T., Gutacker, T.,Roll, M., and Srinivasa, S. Data warehousing furregionalinformationsdienste - eine cottbuser kom-plettlosung. In 8. Leipziger Informatik-Tage (eds.

K.-P. Jantke, W. Wittig) (Sept. 1998).

[20] Thalheim, B., and Dusterhoft, A. SiteLang: Con-ceptual modeling of internet sites. In Conceptual

Modeling – ER 2001, H. S. Kunii, S. Jajodia, andA. Sølvberg, Eds., vol. 2224 of LNCS. Springer-Verlag, Berlin, 2001, pp. 179–192.

Strategic Modelling of Web Information SystemsThomas Moritz

BTU CottbusComputer Science Institute

Postbox 10134403013 Cottbus, Germany

EMail: [email protected]

Klaus-Dieter ScheweInformation Science Research Centre

& Department of Information SystemsMassey University, Private Bag 11222

Palmerston North, New ZealandEMail: [email protected]

Bernhard ThalheimChristian Albrechts University Kiel

Department of Computer Science andApplied Mathematics

Olshausenstr. 40, D-24098 Kiel, GermanyEMail: [email protected]

Abstract— The development of web information systems(WISs) requires modelling on various layers of abstraction. Basedon an abstract abstraction layer model (ALM) the work in thisarticle approaches the modelling on the highest layer dealing withstrategic modelling. Strategic modelling addresses a very generalcharacterisation of WISs in terms of its content, functionality,context, usage and presentation, and pragmatic guidelines forachieving these.

The article discusses branding, utilisation space modelling,utilisation portfolio modelling and atmosphere modelling as themajor parts of a strategic model. Furthermore, techniques basedon linguistic analysis, communication analysis and metaphorsmake up the informal means to approach WISs in strategic terms.

I. INTRODUCTION

The development of web information systems (WISs) re-quires modelling on various layers of abstraction. The co-design approach to WIS modelling in [28] emphasis a strategiclayer, a business layer, a conceptual layer, a presentation layer,and an implementation layer. Other methods such as HERA[16], WSDM [8], OO-H [13], OOHDM [30], HDM [12],ARANEUS [1], WebML [3] and UML [23] agree on the useof abstraction layers as such, but differ in the concrete use oflayers. In particular, higher layers dealing with strategic mod-elling and business-oriented modelling are often neglected.

The goal of this article is to discuss modelling on thestrategic layer of a WIS. Strategic modelling comprises twoparts. The first one addresses a very general characterisationof the system in terms of its content, functionality, context,usage and presentation. The second part addresses pragmaticguidelines for strategic modelling.

The strategic characterisation of a WIS starts from the verygeneral question what the WIS is about, i.e. the purpose(s) ofthe system, and what are criteria for the WIS being successful.The general answer to these questions gives rise to an informalmission statement, and a characterisation of the brand of theWIS. The latter one will follow the general classificationscheme for WISs.

Going more into details we first explore the kind of contentthat is to be presented in the WIS, and the kind of functionality,with which this content can be accessed, customised to theneeds of particular WIS users, and updated. This defines theutilisation space of the WIS.

We then explore the utilisation portfolio to gain even moredetails. This means to model the users (or actors) who will

use WIS, their goals, i.e. why they are supposed to use thesystem, and the tasks that have to be performed to reach thesegoals.

The fourth and last part of a strategic WIS model are generalrules for the formation of the WIS presentation. These addressthe gestalt, atmosphere and progression of the system basedon knowledge about the cognitive perception of form, colourand other style elements.

Taking these parts together we should keep in mind that therole of strategic modelling is to lay out the plan for the wholeWIS without drifting into technical details. As a consequence,the techniques applied on this level will be rather informal,whereas formalisation will be achieved on lower levels ofabstraction. We will discuss linguistic analysis using wordfields [10], the use of metaphors [32] and communicationanalysis [26] as the major methodological means for strategicmodelling.

The rationale behind our approach is an observation madein theoretical linguistics [4]: whenever a complex constructionhas to be explained, humans first think in terms of concepts,which are then mapped to a linguistic construct and onlyfinally translated into sentences. Carrying this idea over toWIS development means to first lay out the fundamentalconcepts that are to be captured by the system, then mapthem onto a conceptual model, before finally approaching animplementation using common available technology.

We will not go into the details of the conceptual mod-elling of WISs, as [28], [27] contain a detailed account ofstoryboarding, and content and functionality modelling. Wewill, however, show how the strategic model impacts on theformation of a WIS in terms of its layout and playout. Forthis we start from the means that are available for visualcommunication such as visual ordering, partitioning, colouringand perspective. We then go into more details discussing gridmodels and colour selection in accordance with the layout,atmosphere and progression patterns identified on the strategiclayer.

In Section II we describe the abstraction layers of the co-design method to put this article into context. In SectionIII we then address the first part of strategic modelling, i.e.the general characterisation of WISs in terms of content,functionality, context, usage and presentation. The second partconcerning pragmatic guidelines for strategic modelling will

be handled in Section IV. Finally, in Section V we discuss theimpact of strategic modelling on visual design patterns.

II. ABSTRACTION LAYERS IN WIS MODELLING AND

DESIGN

The methodology for the development of web informationsystems is based on an Abstraction Layer Model [28], whichis illustrated in Figure 1. The general ideas of this model willbe explained in this section.

! "

# $

% &' & $(

) * +, -/.+0, 1"2 34

5+367 8* 90:;<+17: : 2 34

) * - : 7>=?7 @2 32 * 2 +3

A B 8: 7 B 7 3 * 0 * 2 +3

Fig. 1. Abstraction Layers in Web Information Systems

We identify several layers of abstraction. The top layer iscalled the strategic layer. It is used to describe the system ina general way: What are the intentions? Who are the expectedusers?

The next lower layer is called the business layer, which isused to concretise the ideas gathered on the strategic layer.This means to get a clearer picture of the different kinds ofusers and their profiles. This may also include the differentroles of users and tasks associated with these roles. The majorpart of this layer, however, deals with the description of thestory board. Stories identify possible paths through the systemand the information that is requested to enable such paths. Sothe general purpose of the business layer is to anticipate thebehaviour of the system’s users in order to set up the systemin a way that supports the users as much as possible.

The central layer is the conceptual layer. Whilst the busi-ness layer did not pay much attention to technical issues,they come into play on the conceptual layer. The variousscenes appearing in the story board have to be analysed andintegrated, so that each scene can be supported by a unitcombining some site content with some functionality. Thiswill lead to designing abstract media types. The informationcontent of the media types must be combined to design thestructure of an underlying database.

The next lower layer is the presentation layer which isdevoted to the problem of associating presentation options

to the media types. This can be seen as a step towardsimplementating the system.

Finally, the lowest layer is the implementation layer. Allthe aspects of the physical implementation have to addressedon this layer. This includes setting up the logical and physicaldatabase schemata, the page layout, the realisation of func-tionality using scripting languages, etc. As far as possible,components on the implementation layer, especially web-pages, should be generated from the description on the higherlayers.

On each layer except the strategic layer, we identify twodimensions for the description of the system: focus andmodus. The focus dimension distinguishes between local andglobal components; the modus dimension distinguishes be-tween static and dynamic components. As this leads to fourcombinations, we distinguish between the following compo-nents:

• global and static components, which are addressed by adata specification,

• global and dynamic components, which are addressed bya function specification,

• local and static components, which are addressed by aview specification, and

• local and dynamic components, which are addressed bya dialogue specification.

Each layer is associated with layer specific modelling tasks.The transition from the strategic to the business layer isassociated with the activities of story boarding and user pro-filing. The transition from the business layer to the conceptuallayer is associated with conceptual modelling, which addressesdatabase modelling, operations modelling, view modelling,and media type modelling. The transition to the presentationlayer is associated with the definition of presentation styles.Finally, the transition to the implementation layer is associatedwith all implementation tasks.

The fact that these layers exist in the model and that themethodology is based on transitions between these layers doesnot imply that a development project must first finish the workassociated with one layer before it can proceed to the nextlower one.

In the following subsections we will discuss further severaldetails of the abstraction layers.

A. Strategic Layer

As already stated the purpose of the strategic layer is todefine the intentions of the web-based system and to identifythe target users. Intentions should be grouped into major andminor intentions. For each identified intention a time-scaleshould be determined as well.

For instance, a group system for organising a conferenceintends to provide

• general information about the conference, its history, itsscope, its location and dates, etc.,

• specific information for authors how to submit papers,uploading and downloading facilities, the reviewing pro-cess, etc., and

• easy mechanisms for the programme committee to uploadreviews, discuss about acceptance, generate feedback toauthors, etc.

The identification of target users does not yet aim at classi-fying them according to their profiles, i.e., the questions howusers access the system will not yet be addressed. However,distinguishing between internal and external users, users withspecific access rights and obligations, thus playing a specificrole, and identifying the tasks assigned to such users isconsidered as an activity on the strategic layer.

For instance, a group system for organising a conferencemay identify different user roles:

• The normal users are potential participants and authorsof papers. They should access the general conferenceinformation and have an interface for uploading abstractsand papers.

• The programme committee members and especially theco-chairs need a specific access to the reviewing systemas a subsystem, which allows papers to be downloaded,reviews to be uploaded and discussed, etc.

• The organisation committee members need a specificaccess to upload specific information of organisationalnature such as registation and travel information.

• The administrator is the one who can grant and revokeaccess rights for the other users.

A common technique applied to these tasks is to have abrainstorming session. On this level, intentions, target users,roles and tasks should be described by informal documentsusing just text or tabular representations. In the followingsections we will investigate the strategic layer in more detail.

B. Business Layer

Based on the findings of the strategic layer the developmentprocess will proceed with the tasks of story boarding and userprofiling. The emphasis is on anticipating the behaviour of thetarget users, i.e., how they will navigate through the system,which information they will need on their path(s) through thesystem, which information they will produce and enter intothe system, and which actions they will carry out. Therefore,the activities on the business layer are the following:

• Analyse roles and tasks of the intended users;• Classify users according to user profiles;• For the different roles and profiles describe stories, i.e.,

navigation paths through the system;• Integrate stories into scenarios, i.e., networks of scenes

and transitions between them;• For each scene describe the information the users con-

sume and produce, i.e., information taken from the systemand entered into the system, respectively;

• Describe the actions of the users for the different roles,tasks and profiles within the identified scenarios;

• Identify metaphors that may help a user to achievefamiliarity with the system.

The user roles that were identified on the strategic layeralready provide a first classification of users. This classification

refers to the rights and the obligations of the users. Forinstance, certain parts of the system may be reserved to specificroles. In the conference organisation example that we usedin the previous subsection, the paper reviewing sybsystem isexclusive to the members of the programme committee (andthe administrator), whereas the general information about theconference is open to all users.

Certain tasks are associated with each role. Identifyingthese tasks already gives an indication of different stories,as different roles should lead to different navigation paths.It is also possible that an individual user can have morethan one role. For instance, in the conference organisationexample, each programme committee member is of course alsoa “normal user”.

Defining roles and tasks is again a brainstorming activity,which will result in non-formalised documents. These docu-ments mainly identify the name of the role, a short textualdescription and a list of associated tasks. Each task shouldalso be given a short description, but it must be described inmore detail further on. This will lead to stories.

For each role the users have to be further classified leadingto user profiles. User classification can be done by identifyingseveral dimensions that are useful for the description of theusers’ behaviour and using scales for each of these dimensions.Each possible combination of values taken from these scalescould define a user profile, but it may be advisable to combinesome of them. Thus, user profiles could be described by amatrix-document.

For instance, in the conference organisation example theusers could be classified according to their interest in differentparts of the conference including the social programme. In aninformation service system dimensions for user profiling couldbe the familiarity with technical systems, the educational back-ground, the preferences with respect to information density,etc.

The roles and user profiles tell us who will use the system.Story boarding will analyse how the different users willnavigate through the system. In practice, we may think of astory as a sequence of web-pages visited by a user. However,story boarding does not start on the level of realised pages.It abstracts not only from presentational issues, but also to alarge extent from technical issues. The business layer is stilldealing with setting up the system in a way that non-technicalstakeholders will be able to assess, whether their goals can bemet.

Thus, instead of talking about pages we use the abstractterm of a scene. Story boarding identifies useful scenes andtransitions between them. This can be described by graphsor transition matrices. Such graphs can be easily sketchedin brainstorming sessions and interviews with stakeholders.Graphs, however, do not exhaust story boarding. For eachscene we may ask

• which information has to be provided to the user (thiswill be called information consumption),

• which information is to be requested from the user (thiswill be called information production),

• which actions can be carried out by the user to navigateto a successor scene including the possibility that thesuccessor scene is the same scene again, and

• which metaphors are useful to support the actions asso-ciated with a scene.

Providing information consumption, information productionand actions leads to enriched graphs or matrix representations.Furthermore, each transition can be coupled with informationthat is communicated between the two scenes. For the targetscene this is context information.

The most difficult activity in story boarding concerns theintegration of individual stories. Scenes that have nearly thesame information consumption but appear in different storiescould be combined into one scene. This leads to furtherenriched graphs (or matrices), which are called scenarios.

Finally, scenarios can be described with various levels ofdetail. Usually, we start with (non-integrated) scenarios, inwhich a lot of information is left out. Details are addedduring a process of information gathering. This may lead tocombining scenarios, introducing branches, replacing scenesby complete sub-scenarios, etc. These activities are subsumedunder the notion of story tuning.

Story tuning has achieved its objectives, when all the scenesin the scenarios can be transformed into media types, whichwill be discussed in the context of the conceptual layer (seethe next subsection for further explanation). In fact, the mediatypes are sufficient to describe the system. However, in orderto determine them story boarding and tuning are indispensible.

How is story boarding related to the dimensions that wediscussed in the previous subsection? Locally, we have toconsider the scenes appearing in the scenarios. The staticpart (view specification) of the scene, is determined by theconsumed and produced information, whilst the dynamic part(dialogue specification) is determined by the actions associatedwith a scene. Globally, we consider complete scenarios. Thedynamic part (function specification) is determined by thestories, whereas the static part (data specification) should bea description of all the information used in a scenario, whichis left implicit on this layer.

The results of these activities make up the storyboard, i.e.,the description of the business layer. Details on how to decribethe storyboard are handled in [28].

C. Conceptual Layer

Based on the scenarios that are defined on the businesslayer the development process continues with a conceptualmodelling activity aiming at the definition of media types.However, media types can be defined already during storytuning. The emphasis of the conceptual layer is on analysingthe data processed in the scenarios and the actions on thesedata in order to describe the content and functionalty aspects ina formalised way, and to develop database support. Therefore,the activities on this layer are the following:

• Group suitable data and specify operations for the actions,i.e., specify content and functionality.

• Specifying content and functionality leads to definingmedia types.

• Restructure the data in order to define connections todatabases.

• As database design follows different objectives (no redun-dancy, optimized access), the content specification shouldlead to views, i.e., transformations which turn the contentof a database into the content of a media type.

• Extend media types in a way that they can be tailoredto different users, different end-devices and differentcommunication channels without designing multiple sites.

• Link the media types with the scenarios and ensure thatall scenarios are adequately supported.

With respect to the static component, i.e., the data, the var-ious scenes will be analysed and the information consumptionwill be formalised using data types. This gives a local view onthe data that is present in the system. For example, a scene inour conference organisation example (associated with the roleof a programme committee member) might be devoted to lookat a completed review. So the information consumption is justthe description of reviews. The analysis may lead to describingthe parts of the review such as paper title, category, subjectarea, confidential comments, positive aspects, negative aspects,assessment of quality, assessment of readability, etc. This canbe described in an abstract way using data types such that allpossible reviews would become instances of that data type.Later on, such a data type will be called a content type.

Globally, however, we may need to organise the data in adifferent way. For instance, in the database of our conferenceorganisation system we might find additional information onthe programme committee member and additional reviewer(s)of a paper that are not visible to all programme committeemembers. However, it must be possible to map the databaseto the content type. Such a mapping is called a view. In ourexample we would simply have to extract just the informationon the review.

With respect to the dynamic component, we would have toadd operations. Locally, these operations are determined by theuser actions associated with a scene. Globally, we would needoperations on the database — to be precise, these operationswill be transactions — which realise the operations on themedia type. Of course, the information production, i.e., thedata requested from the user, must become the input of theoperations.

How is conceptual modelling related to the dimensions thatwe discussed in connection with the abstraction layer model?Globally, we now provide a database schema for the staticpart (data specification) and database transactions (functionspecification). Locally, we have the analog of media types.The static part (view specification) is defined by views on thedatabase schema; the dynamic part (dialogue specification) isgiven by the operations associated with a media type.

The result of this layer will be a media schema, i.e. acollection of media types, which adequately represent thescenarios. Details on media types are handled in [28].

D. Presentation Layer

The conceptual layer has produced the collection of mediatypes. The content and functionality of a system is alreadyfully determined by the media types. It has also been verifiedthat the intention and usage of the system is adequatelysupported by the media types. So, the remaining problem isthe presentation, which is addressed on the presentation layer.

In general, a media type defines a set of media objects.The actual media objects depend on the state of the database.Each of these media objects is an abstract representation of aweb-page. So, the major activity on the presentation layer isto specify style options for the pages. This will be done byenhancing the media types with the style options.

E. Implementation Layer

The implementation layer deals with all activities that areleft to transform the presentation enhanced media schema intoan executable and accessible web-based system. As a result ofthe higher layers we obtain a media schema, which consistsof a database schema and a collection of media types. Eachmedia type is defined by a view on the database schemaand operations. Furthermore, the media type is associatedwith presentation style options. Therefore, the activities onthe implementation layer are the following:

• Define a logical database schema and implement it by adatabase management system.

• Define the views of the media types using the databasequery language.

• Generate web pages (HTML-documents) from the mediatypes and the style options as far as possible.

• Implement the operations on media types using scriptinglanguages.

III. STRATEGIC CHARACTERISATION OF A WIS

The strategic layer of a WIS is meant to set the target forthe models that are to be developed at the lower layers. Wewill characterise a WIS by

• a mission statement describing in general terms what theWIS is about,

• a utilisation space describing content, functionality andcontext,

• a utilisation portfolio describing actors, goals and tasks,• and general principles describing the ambiente and de-

sired atmosphere of the WIS.

The last part will guide the formation of the WIS.

A. Mission Statement and Brand

The brand of a WIS is based on a rough classificationscheme for WISs. This classification scheme has the formPW2UA and represents in an extremely terse form the fol-lowing very general information:

• P stands for “provider”, and thus indicates which rolethe system plays. This specifies very roughly what kindof content can be expected from the system. For instance,if the provider is a bank, the provided services will most

likely center around accounts, investments, savings andloans.

• W stands for “what”, and thus adds more detail to thekind of content offered by the WIS. For instance, if theprovider is a bank, the provided content may just beaccounts, investments, savings, loans, and mortgages.

• U stands for “user”, and thus indicates to whom theservices offered by the WIS are directed. For instance,if the provider is a bank, the users are probably just thecustomers, enterprises or other banks.

• A stands for “actions”, and thus indicates the function-ality of the WIS offered to its users. For our exampleof a bank offering accounts, investments, savings, loans,and mortgages possible actions can be apply for loan,apply for mortgage, set up account, buy stock, etc.

The brand is usually the result of a brainstorming activitydiscussing the what, whom and for whom of the WIS. Theaim is to fill these general placeholders P , W , U and A withmeaningful terms that describe the WIS in very general, terseterms. We shall look at this brainstorming activity in moredetail in Section IV.

The brand gives a rough picture of the content and func-tionality of the WIS and its users using only descriptivekeywords. This is, however, a valuable source of informationfor refinement using linguistic methods. We will look at thesepragmatic methods for strategic analysis also in Section IV.

The mission statement complements the brand by an in-formal, textual description. The importance of having it wasemphasised in [7]. Each of the actions in the brand are takenas the major tasks. For each of them the mission statementdecribes, which types of users are involved, which activitiesthey are supposed to execute, which content will be providedfor them and requested from them, and what will be the resultsof these activities. However, no attempt is made to decomposethe tasks or to refine them, as this is left to storyboarding [28].

Furthermore, the mission statement contains metaphors thatturn out to be adequate for describing the activities associatedwith the WIS. These metaphors refer to the content andfunctionality keywords used in the brand.

In addition to its descriptive character the mission statementalso has an explanatory character in the sense that it containsthe reasons for setting up the WIS. That is, the missionstatement will describe what the major and minor purpose ofthe system is, how each task will contribute to these purposes,and what the benefits of the system for the provider and theusers will be.

Example 1: Let us consider the example of a WIS thatdeals with loan applications. In the case the provider is a bank,and the content will be centered around (personal) loans andmortgages. The only users we think of are customers, and thetasks they execute are applications for loans and mortgages,respectively. This leads to the following brand:

bankloan, mortgage2customerapply for loan, apply for mortgage

The mission statement is the following informal explanationfor the brand:

The mission of the system is to provide on-line access forcustomers to personal loan and mortgage applications. Thesystem will provide information about the available types ofloans including conditions for repayment, i.e. principal andinterest, conditions for creditworthiness, and intended purposesof the loans. For mortgages this further includes securitiesand conditions for bailsmen. The information about loans willbe complemented by easy loan examples. Then the systemwill allow customers to enter their personal data, select theappropriate loan, and check, whether their personal finances arein accordance with the rules for repayment.

The major purpose of the system is to open an additionalsales channel, which is addressing mainly those customerswho are capable of dealing with electronic systems, do notneed intensive advice, and therefore prefer the convenianceof avoiding personal contact at a branch office. A secondarypurpose is to improve the efficiency of banking in the loansector.

The expected benefits of installing the system for the bankare a closer binding of customers to the bank, the possibleattraction of new customers, and an improvement of cost ef-ficiency, while at the same customers benefit from increasedavailability of bank services.

In general, it is sufficient to formulate the mission statementusing free-form text as in Example 1, but it is also possibleto use semi-formal structured text. In doing so the brand andmission statement take the following form:

Content: 〈list of content items〉Users: 〈list of users〉Tasks: 〈list of tasks〉Major Purpose: 〈textual description〉Minor Purpose: 〈textual description〉Benefits: 〈textual description〉

Furthermore, we obtain the following informal descriptionfor each of the tasks:

Task: 〈task name〉Description: 〈textual descripton〉Participants: 〈list of users〉Required Content: 〈list of content items〉Produced Content: 〈list of content items〉Result: 〈textual descripton〉

Example 2: Using the tabular semi-formal description,we can rewrite the brand and mission from Example 1 in thefollowing way:

Content: loan, mortgageUsers: customerTasks: apply for loan, apply for mortgageMajor Purpose: open an additional sales channel

address technology-experienced,informed, goal-oriented customers

Minor Purpose: improve banking efficiency in loan sectorBenefits: closer binding of customers

attraction of new customersimprovement of cost efficiencyincreased availability of bank services

Furthermore, we obtain the following informal descriptionsfor the tasks apply for loan:

Task: apply for loanDescription: The system will provide information

about the available types of loansincluding conditions for repayment,i.e. principal and interest, conditionsfor creditworthiness, and intendedpurposes of the loans. The infor-mation about loans will be comple-mented by easy loan examples. Thenthe system will allow customers toenter their personal data, select theappropriate loan, and check, whethertheir personal finances are in accor-dance with the rules for repayment.

Participants: customerRequired Content: list of loans, loan conditions,

loan purposeProduced Content: loan application, customer dataResult: confirmed loan application

The description of the task apply for mortgage will looksimilar.

B. Utilisation Space

The term “utilisation space” is used as a metaphor tocharacterise the WIS as a space, through which a human usercan navigate. As such it has to cover mainly the content,functionality and context in general terms. The goal is toenable optimal orientation in the utilisation space, such thatsearching and finding information needed for certain tasks willbe facilitated.

The type of content is already characterised by the brand, tobe precise by its what-part. This gives a set of nouns describingthe content in coarse terms. Similarly, the what for-part of thebrand gives verbs describing the functionality, i.e. what to dowith the content.

The utilisation space will now add details to content andfunctionality, set the nouns and verbs used in the brand intorelation, and place both into a utilisation context. This will bedone in the following way:

• Refine the content keywords and place them in semanticrelationships. These relationships can capture speciali-

sation, part-of relationships, or associations of globalcontext with details. They indicate navigation facilitiesand order principles among the content. Word fields area valuable tool for the refinement (see Section IV).

• Refine the functionality keywords to discover variousfacets that can be placed in semantic relationships in thesame way as the content. Again, word fields are a valuabletool for the refinement.

• Relate the functionality with the content, i.e. specify inwhich context a particular content is needed, i.e. whichcontent is needed by which activity, which content isproduced by which activity, in which order (if any) thecontent will be used by an activity. In doing so, we obtaina progression model for the functionality.

Semantic relationships for content – and similarly forfunctionality – can be represented by rooted trees, where theroot is defined by a keyword taken from the brand. Thus, wecan obtain the following more detailed description of contentitems:

Content Item: 〈name〉Derived From: 〈content item〉Relationship: 〈description〉Usage: 〈list of tasks〉Description: 〈textual description〉

In the same way we obtain more detailed description oftasks:

Task: 〈task name〉Derived From: 〈task name〉Relationship: 〈description〉Description: 〈textual description〉Participants: 〈list of users〉

loan

personal_loan

conditions: interest

conditions: creditworthy

purpose: house_improvement

purpose: other

purpose: purchase_car

mortgage

Fig. 2. Semantic tree of content items in loan application

Required Content: 〈list of content items〉Produced Content: 〈list of content items〉Result: 〈textual description〉

The description of tasks may be extended by

Starting situation: 〈list of situation parameters〉Closing condition: 〈acceptance constraints〉Execution context: 〈textual characterization〉

Typical situation parameters are preconditions and trigger-ing conditions for task enactment, priorities among tasks,frequency of tasks, and repetition patterns. Acceptance con-straints are used for the internal control, whether a task canbe considered to be completed. The execution context is usedfor the description of duration restrictions, foreign interaction,scope, and robustness.

Example 3: Figure 2 represents a tree of content items withroot loan, which is specialised by personal loan and mortgage.Details for mortgages have been omitted, but for personal loansthe three decisice facets – conditions for obtaining the loan, i.e.creditworthiness, conditions for loan repayment, i.e. life span,principal and interest, and loan purpose have been indicated.

Similarly, Figure 3 represents a task tree withroot apply for loan, which again is specialised byapply for personal loan and apply for mortgage. Forthe latter one further details have been omitted. Forapply for personal loan the components contributing toselecting terms and conditions, outlining personal finances,declaring the purpose of the loan, and entering customerdetails are shown in the tree.

apply_for_loan

apply_for_personal_loan

terms&conditions

personal_finances

house_improvement

purchase purpose

apply_for_mortgage

income

obligations

customer_details

other

Fig. 3. Semantic tree of tasks in loan application

The decisive criterion for orientation in the utilisation spaceis the preservation of context. This can be achieved, if foreach task a mental model can be constructed. This modelcaptures the progression of content perception over a time axis.It represents a system map for the user showing informationthat has already been used and processed.

For strategic modelling it is important to reflect, whetherthe stages that represent perception of content are logically

connected. It is also important to see that later stages enablethe possibility to be redirected to information that was alreadyprocessed earlier.

If available, metaphors may help to set up this mental model.For instance, the “desktop” metaphor is a well-establishedtool that has significantly contributed to ease the use ofcomputer technology by technical laypersons. Similarly, the“shop” metaphor is frequently used in commerce applications.We will discuss metaphors in Section IV.

Example 4: We may regard the task of personal loanapplication in the loan application system from Example 1 as amatching problem. We have to match the needs of a customerwith the purposes of the available loans, and the paymentsarising from loan conditions with the payment latitude of thecustomer, which is determined by creditworthiness conditionsset by the bank and the personal finances, i.e. income andobligations, of the customer.

Thus, a suitable mental model consists of the set of loanoptions, i.e. loan type, conditions and purpose, and the im-plications of each option with respect to the payments. Thismodel develops over time in a way that non-suitable optionsare deleted first, then a selection is made, and finally organisa-tional data are added to turn the selected loan option into a fullloan application. This also indicates the required functionality,which must comprise selecting information about loan options,tentative and affirmative selection of such options and decisionaids.

Each characteristic aspect of a WIS can be associated witha specific context. In general, we distinguish between thefollowing different kinds of context:

• The general context associates certain characteristics ofmission, utilisation space, utilisation portfolio, and gen-eral principles to other characteristics of the WIS.

• The usage context associates scenarios that describe thebehaviour of users with other such scenarios.

• The website context specialises scenarios based on thesupported environment, the provider and software andhardware environments.

• The runtime context permits the incorporation of thecurrent situation and the information on the current usageof the WIS into the offered content and functionality.

The different kinds of context permit a layering andstepwise incorporation of context information into the WISbased on the abstraction layer model. The general contextis specified by content items, functionality, actors, goals andtasks as shown in Figure 4, thus can take the following form:

Content context: 〈list of related content items〉Functionality context: 〈list of functionality〉Actor context: 〈list of cooperating actors〉Goals context: 〈list of related goals〉Task context: 〈list of related tasks〉

C. Utilisation Portfolio

The utilisation portfolio complements the utilisation spaceemphasising the whom-part of the brand. Thus, it is mainlyconcerned with the WIS users, for which we will later adoptthe term “actor”, their goals and the tasks that have to beexecuted to achieve these goals.

Tasks correspond to the actions in the brand and theirrefinement in the utilisation space. So we can assume atask hierarchy emphasising specialisation between tasks anddecomposition of tasks into subtasks, as long as these can bedescribed in a simple way.

The users used in the brand and mission statement will beroughly classified according to roles they have with respectto the WIS. Each role has particular goals, and each of thesegoals corresponds to a task that is meant to achieve this goal.This does not mean that the task has to be executed by theuser in this role; it may well refer to tasks executed by usersin other roles. Tasks are broken down into subtasks to a levelthat elementary tasks can be associated with a single role. Inaddition, subtasks should refer to subgoals.

Furthermore, we obtain dependencies between goals,e.g. being a subgoal, a specialisation, or any other kind ofdependency. Thus, we complement the informal descriptionof the system by adding goals:

Goal: 〈goal name〉Derived From: 〈goal name〉Relationship: 〈description〉User: 〈role name〉Description: 〈textual description〉

actor_name task_name

goal_name relation

actor vertex task vertex

goal vertex task-goal-relationship or

goal-goal-relationship edge

subtask edge

task specialisation edge

actor-task-involvement edge or actor-goal edge

Fig. 5. Legend for Task-Goal graphs

The relationship between tasks, roles and goals can berepresented in a graph, which we call a task-goal graph.In these graphs we have three different types of verticesfor actors, tasks and goals, respectively. Furthermore, wehave five different kinds of edges for task-goal relationships,involvement of an actor in a task, goal-goal-relationships, aswell as for subtasks and task specialisation. Figure 5 showsthe legend for such graphs.

Example 5: The task-goal graph in Figure 6 illustratesgoals, tasks and actors in a loan application. In this casethe goal buy new car depends on obtaining a personal loan,i.e. on the goal personal loan. Sufficient for achieving this

Contentcontext

Actorcontext

Media types,meta-information

Actors, profile,payment, ...

Potential environment, information system, scenes, tasks, roles

Intention, theme, occasion, mission, purpose

Usage, goal, and task context

Website context (provider, supporter, SW/HW stakeholder)

Runtime context (situational, physical environment, social, policy, time)

Current scenario, history, current environment, user, goals, particular, culture

Fig. 4. Layers of context

goal is the successful execution of task approve personal loan,which has to be done by a bank clerk. However, this taskwill only be triggered by a task apply for personal loan tobe executed by the customer. This task is thus necessary forthe goal. Furthermore, the task decomposes into four subtasksselect conditions, enter customer details, declare purpose andset up budget.

bank_clerk

approve_personal_loan

buy_new_car

triggers

personal_loan

n e c e

s s a r

y

apply_for_personal_loan

necessary sufficient

customer

select_conditions

declare_purpose

enter_customer_ details

set_up_budget

Fig. 6. Task-Goal graph for loan application

A valuable tool for setting up the utilisation portfolio iscommunication analysis, which addresses how a user willcommunicate with the WIS and why this communication isthe best for the provider and the user. We shall discuss this inmore detail in Section IV.

D. The Atmosphere of a WIS

While the brand, mission statement, utilisation space andutilisation portfolio aim at the characterisation of content,functionality and usage of the WIS in strategic terms, the

atmosphere addresses the gestalt of the WIS, i.e. how the WISshould be configured. At the end the WIS will be implementedby and presented through web pages, which should convey auniform impression to the WIS users.

Categories characterising the impression of pictures canbe used such as energetic, romantic, elegant, refreshing, har-monic, or stimulating. Each of these categories will have impli-cations on the choice of form and colour [24]. On the strategiclevel the choice of one of these categories corresponds to thequestion which impression the WIS shall convey. The questionis, which atmosphere is best suited for the envisioned contentand functionality.

Example 6: In Example 4 we characterised the applicationfor loans as a matching problem. Choosing a harmonic pre-sentation for the WIS would suggest the intention to find an“optimal” solution for the customer and the bank. Choosinga stimulating atmosphere might suggest to encourage thecustomer in his/her application. An elegant atmosphere of theWIS may be chosen to convey confidence to the customer, i.e.that his/her financial affairs will be dealt with in the best way.

In addition, the atmosphere of a WIS is concerned with theprogression patterns for the tasks. These patterns reflect thelogical connection of information revealed to the user duringthe execution of a task. We distinguish between the followingprogression patterns:

• A circular progression pattern is centered around a par-ticular content item, the phases of which form the coreof the content to be delivered. At each stage details areadded.

• A loop progression pattern emphasises the iteration ofcontent, each time taking a different perspective. This issimilar to a circular pattern, however puts more emphasisto changes.

• An incremental progression pattern emphasises the devel-opment of several content items over time. At each stagesome of the items may be completed.

• An evolutionary progression pattern emphasises thestages of the content items, in particular those that areused in the result of tasks. At each stage content item

may still be incomplete.• A network progression pattern emphasises the flexible

treatment of content items during the development oftasks and the logical connection between various suchobjects.

Example 7: If we choose a circular progression pattern fora personal loan application, the presentation of informationwill be centered around the loan, each time gaining a clearerpicture of the result. In Example 4 we explained that it wouldbe a good idea to successively discard possible loan options.This is in accordance with circular progression.

An incremental progression pattern would emphasise thevarious components of a loan application, i.e. the customerdata, the conditions, and the budget. Each of these componentswould be treated as a separate item. While this is common inmany WISs that offer form-oriented access, it may not be thebest choices, because it does not support well the interactionbetween a tentative choice of conditions, the calculation ofrepayment costs and the personal financial situation of thecustomer.

An evolutionary progression would be very similar to anincremental one. However, each component could be leftincomplete. This would help with the problem of changingconditions.

A loop progression would be similar to a circular progres-sion. The difference is that the circular progression emphasisesmore the narrowing of options, while a loop progression wouldpermit returning to options that have already been discarded.

Finally, a network progression is again similar to an incre-mental one, but leaves much more flexibility, as to fixed orderof the components is presumed.

Progression patterns have a direct impact on the placementof content on web pages, thus on the tiling of pages and themapping of content to the tiles. Such a mapping of patternsto web page grids is discussed in detail in [24].

IV. STRATEGIC ANALYSIS

Let us now address guidelines for strategic modelling. Asalready indicated in Section III, we will discuss linguisticanalysis, communication analysis, and metaphors.

A. Linguistic Analysis

Linguistic analysis addresses the logical connections be-tween the tasks, the content and the goals of users usingtechniques that are applied to analyse natural language de-scriptions of users’ activities. The major source of informationused for developing information systems is a description ofprocesses, which may be delivered verbally or in the formof texts. Linguistic analysis considers such natural languagedescriptions and uses them for analysing the activities of theusers: What are these activities? Does the description indicateany sequencing or continuation? What data is needed for orused by the activities? What are the relationships betweenthese data? As user activities can be described by verbs, wesuggest analysing the corresponding word fields.

According to [14] a word is an abstract concept, which inorder to become concrete needs a word form carrying thegrammatical variants. Word fields are a much more generalnotion than word forms. Word fields combine different aspects:

• morphology, i.e. the forms of the written or spoken word,• phonology, i.e. the sound of the spoken word,• syntax, i.e. the construction of sentences using the word

forms,• semantics, i.e. the meaning(s) of the word, and• pragmatics, i.e. the usage of the word in written or spoken

language.

If we restrict ourselves to written language communicationconsidering the phonology becomes obsolete. Therefore, wetacitly assume that verbally communicated information in aformalised language usage context such as business commu-nication can also be delivered in textual form without loss ofsemantics. If we had to analyse everyday language, this wouldno longer be true.

A word field [19], [29] is a linguistic system in which similarwords that describe the “same” basic semen and are used inthe same context are combined to a common structure anddata set.

In contrast to common synonym dictionary, word fieldsdefine the possible and necessary actors, the actions and thecontext. Word fields can be used for verbs, nouns and adjec-tives. We focus on verb fields and extend the implementationsof the WordNet dictionary for verbs. Word fields are well-specified for a number of verbs. For each verb field we can atleast define the following abstract information:

• basic semen,• context of usage,• possible/necessary actors, actions and context, and• the star or snowflake specification, which comprises

– the logical structure specifying possible arguments,– the semantic description of relevant and irrelevant

valences, and the association with semantic type(colour, space, time etc.),

– the kernel semantics describing the word field withsemen, and

– example sentences providing additional informationusable for help desk systems.

Example 8: A typical example is the verb “inform”, forwhich we can differentiate between four major facets of theword field:

1) To bring/advice something to somebody’s attentionsomething: The word field is semantically characterizedby: objectivity; functional information; official infor-mation; explanation; to be associated with somethingin future; using different representational media andpresenters; with a degree of extraction from open or hid-den; variety of styles such as short content description,long pertinent explanation, long event-based description.Typical related verbs are: announce, notify, publicize,publish, explain, present, herald, report, describe, out-line, portray, passing a message, and scout.

2) To bring something that is unknown or hidden tosomebody’s attention: The word field has a variety ofpresentation varying from proving a statement, arguingon latent facts, or unintentionally stating away. Theassociation to the senders way of thinking and actingis more strict than within the first variant. It is morepersonalized. Typical synonyms or associated verbs are:explain, report, clarify, elucidate, prove, admit, confess,scout, and betray.

3) To react on events or statements: The reaction maybe positive or negative. Typical application pattern arenegotiations and adjustments. Typical associated otherword fields are: confirm, approve, dispute, negate, andprohibit. notify, state, announce, promise,

4) To make suggestions for future activities: A business siteor an advertisement site does not display informationwithout intention to generate surplus value. The inten-tion of displaying information within an entertainmentsite is often to attract readers to become involved.Typical related actions are described by words such aspropose, register, and offer.

We can generalise the theory of word fields as shown inFigure 7. Generalised word fields are significantly differentfrom word forms that carry the grammatical variants [14].

Under this premise we understand a word field to consist ofits intext, its context, its semantics and its pragmatics.

• The intext combines morphology and syntax. We aremainly interested in the latter one, especially for verbs.In this case we may ask for the basic syntactical form,various mandatory and optional arguments, variants ofthe arguments, extensions to the basic syntax, and rela-tionships and constraints between the arguments of theword when it is used in sentences.For instance, the verb “to give” uses a mandatoryargument “something” and an optional argument “tosomebody”. The basic syntactical form “Someone givessomething to somebody” expresses an action, specifiesthe actor and the receiver, and an object used in the action.

• The context refers to application areas. According to thecontext we may identify related words, concepts relatedto the arguments, categories of actors and actions, andfurther constraints.For instance, in a banking context the verb “to give” maybe used in a sentence such as “The bank gives a home loanto the user”. In this case we conclude that the object ofthe action is subject to contracted conditions regardingthe use of the money for the claimed purpose, paymentof principal and interest. A more precise statement wouldreplace the verb “to give” by “to grant” or would replacethe whole sentence by “The bank offers a home loancontract to the user”, in which case it would becomeclearer that a follow-on action, i.e. the acceptance of theoffer, is expected.

• The semantics refers to the meaning of a word in aparticular context. For example, the already used sentence“The bank gives a home loan to the user” includes the

meaning of setting up a contract.• The pragmatics refers to how the word is used in the

application context.Word fields have been investigated in more detail in [10]

extending work in [11].Example 9: In electronic commerce verbs describing ac-

tivities around contracts can to a large extent be consideredas specialisations of the verbs “to give”, “to take” and “tonegotiate”. We will concentrate only on the first two of these,as the treatment of negotiations leads to a field in its own right.

As to the intext, the basic syntactic form associated withthe verb “to give” is to give something to somebody. Thisindicates the existence of two roles, the giver and the taker,the involvement of an object, and an activity of the giverhanding over the object to the taker. Of course, this alsoindicates a follow-on action with interchanged roles, whichcan be described by using the verb “take”.

The verb “to give” is quite abstract leaving enough spacefor interpretation, i.e. variants and constraints. For instance,the activity may be unconditional or conditional. In ourexample sentence “The bank gives a home loan to the user”the action definitely requires the follow-on acknowledgementto happen, whereas a sentence such as “The company deliversthe ordered goods within 10 days.” — note that “to deliver”may be considered as a specialisation of “to give” — indicatesan unconditional action. Further variants of “to give” areconnected with specification of how the giving-action is tobe executed. Unless the respective conditions are explicitlystated or generic business conditions apply, all variants areadmissible. The verb itself does not express them.

The semantics of the verb “to give” depends on the contextin which it is used. In a banking context it refers to theobjects a bank can give to its users and vice versa, e.g.money, information, stock options, accounts, securities etc.In many cases the giving-action is coupled with choices andoffers, which are not self-contained, but require follow-onactions. According to the more specific objects involved in theactions, more specialised verbs such as “to offer”, “to inform”,“to grant”, “to propose”, “to present”, “to acknowledge”, “toconfirm” etc. are used. The related word fields for these verbsgive more details on the semantics of a sentence in the givecontext.

As to the pragmatics, the use of the verb “to give” usuallyindicates that a follow-on take-action is assumed. Dependingon the used specialisation, the continuation will also bespecialised. For instance — staying within the banking context— the use of the verb “to offer” can be followed by “to select”,“to choose”, “to accept”, but also negated forms such as “toreject” or questioning conditions for taking are possible.

The verb “to take” is almost dual to the verb “to give”.Therefore, we dispense with a detailed discussion of its wordfield.

Example 10: Let us look again at loan applications focus-ing on the task of setting up a budget. This scene arises froma sentence such as “The user and the bank set up a budget forthe requested loan”. Several word fields will be used in the

Word field

Kernelsemantics

Semen

Usage

Scene

Applicationpattern

History

HHHPlot

Actor

Time

Occasion

*

QQ

QQ

Description ofargumentsCharacteristics

OptionalityHHH

Object

Subject

Content

HH

Referentialdenotationalsemantics

@@@

Morphologicalgestalt

AAAAA

Semantic cases

Applicationarea

HHHHConstraints

@@

@

Actor categoryProcess category

Concepts

Syntax

@@@

Variants ofarguments

Argument pattern

Sender

Receiver

HHContent

Base form

Grammatical pattern

Constraints

HHString set

@@

Meaning Semantic invariants

PPPP

Distribution

ZZ

ZZ

Valence

Rigidity

JJJJModality

Fig. 7. The structure of a generalized word field

analysis of this sentence. Central will be the verb “to set up”,which in general means to collect all the details describingthe object argument, i.e. in this case “budget”. In the bankingcontext this refers to the collection of information about debitsand credits of the user including the payments for the loan.

This is determined by the word field of “budget”, whichimmediately leads to two components associated with the deb-its and the credits, respectively. Furthermore, the word fieldsfor “credit” and “debit” will indicate further specialisations,leading to the collection of information about salaries, rents,interests, rates, living expenses, etc.

B. Communication Analysis

Communication analysis addresses how a user will com-municate with the WIS and why this communication is thebest for the provider and the user. This helps to understanduser goal and set up the utilisation portfolio accordingly [26].Communication analysis is based on results in communicationtheory [5].

If a user can get the impression that guidance and infor-mation are as good as would be expected from a human, thesystem will more likely be accepted and thus be successful.From this we draw the conclusion that the WIS has to bedefined in a way that best reflects the user-business commu-nication in case there were no system support. Therefore, itappears to be a good idea to start with an analysis of thiscommunication.

Communication analysis summarises the activities and tech-niques that are applied to understand the typical human-to-human interaction in the application domain, and classifies typ-ical communication barriers [15]. We use certain dimensionsof understanding messages as a framework for understandingcommunication. These are used to identify communicationflaws. We proceed with identifying different types of com-munication barriers, which affect the communication. Then

we argue that using localisation abstraction and metaphorscan help to overcome communication barriers, implying thattheir use may enhance the user’s understanding and successfulnavigation through a WIS.

We may understand communication as an exchange of mes-sages. Here we deal with semantic and pragmatic aspects ofthese messages. In particular, we are concerned with successfulcommunication, i.e. communication by means of which bothpartners do meet their respective goals. We can distinguishfour main dimensions of understanding messages depicted inFigure 8:

• Content, i.e. what the message is about;• Presentation, i.e. what the sender tells about the message

and the sender him/herself;• Relationship, i.e. what the sender thinks about the re-

ceiver and their relationship, and what the receiver thinksabout the sender;

• Appeal, i.e. what the sender wants the receiver to do.

message

sender

receiver

content

s-r-relationship

appeal to

receiver

presen-

tation

Fig. 8. Dimensions of understanding messages

In WISs we mainly have to deal with written messages.These dimensions, however, apply to spoken messages, but canalso be applied to written messages. Assuming that a necessarycondition of non-successful communication is that at least onemessage is flawed with respect to one of the dimensions, wecan distinguish the following message flaws:

• Content flaw, i.e. the sender does not say what s/hewanted to say, or the receiver understands the utterance

differently;• Presentation flaw, i.e. what the sender tells about

him/herself is inaccurate, or the receiver understands itincorrectly;

• Relationship flaw, i.e. what the sender thinks abouthis/her relationship to the receiver is incorrect, or thereceiver understands it incorrectly;

• Appeal flaw, i.e. what the sender wants the receiver todo is not persuasive, or the receiver does not correctlyunderstand the (valid) appeal issued by the sender.

Clearly the above mentioned dimensions of message un-derstanding are not really independent in a formal sense andneither are the flaws. But as can be seen below, they help toformulate and classify communication barriers that appear tobe realistic.

Localisation abstraction addresses problem arising fromcontent, presentation and relationship flaws. As the commu-nication we are dealing with here is a mediated human-to-human interaction, various kinds of knowledge and abilityhave been represented inside the web information system asdata or program. The information system in response to auser’s inquiry chooses the data or program best suited. Thisrequires having a model of the user (type) represented insidethe web application. Given a particular inquiry and a usertype, the most suited data or functionality available may beselected or constructed and the user given access to it. The webinformation system further obtains an answer to the inquirythat can be just the identified data as it is stored in its database.However, it can also be the result of applying business func-tionality to these data. Finally, the application actually deliversthe answer to the user. Since the functionality required by theuser is distributed over the information system’s informationspace, the user might not be able to access it immediately, butmight first need to position him-/herself on the most suitablelocation. Thus communication gets mixed up with navigation.Therefore, simplifying navigation can result in significantlyreducing communication barriers. The simplification of choiceis realised by supporting tools.

At least the following navigation functions appear worthsupporting with tools:

• Position signalling, a function pointing out to the user hisor her actual position in application space.

• Heading determination, a function determining the direc-tion and also maybe the means best suited to approach acertain position.

• Short distance environment exploration, a function usedto explore the immediate neighbourhood of a givenlocation.

• Long distance environment exploration, a function usedto explore the regions of the application space that arefar away from a given location.

In a web information system these functions can be sup-ported by the use of localisation abstraction. A particularview on the system’s information space model is associatedwith a user and may be displayed to him or her. The user’s

location in the application space and his/her favourite locationsmay be part of this model. The model may be presented asa graph. Its vertices could represent locations and the edgesthe connections between them. The vertices could be labelledby the functionality, i.e. knowledge or ability that is availableat the specific location. After each navigation step the modelmust be updated. Algorithms are then needed for obtaining,updating and displaying the models. It should be possible toobtain the needed results on the fly if the intended model isnot too sophisticated.

Using the localisation abstraction properly can thus targetnavigation type barriers, as it reduces the perceived complexityof the information space and thus increases the users’ abilityto aim for his/her purpose. Reasonably chosen metaphors mayhelp the users to apply their knowledge and abilities in asituation (i.e. while working on the information space) theyare unfamiliar with. Using metaphors may cause users to bemuch more efficient in identifying the functionality requiredfor their purpose, move to there, invoke the functionality andthus meet their goals more efficiently.

Example 11: Let us look at communication flaws in asystem dealing with loan applications. Content flaws can bethe following:

• Users have a variety of knowledge levels concerningloan types offered, their application areas, the terms andconditions, the assessment criteria, etc.

• Users may or may not have a clear picture about whatthe loan is needed or going to be used for. Some mayhave only a vague idea of the purpose.

• Users may – depending on their level of education –easilyunderstand the differences between loan types and theirrespective suitability or not.

Presentation flaws in a loan application system can be asfollows:

• Users may have a clear mind about their financial capabil-ity, and thus be able to set up a reasonable budget. Othersmay over- or under-estimate their capability to affordthe payments that will be required in case of applicationapproval.

• Users may have sufficient computer literacy to handle anelectronic system without difficulties or need a lot of helpin doing so.

• Users might – due to their insufficient language fluency– need specific support while filling in the applicationform.

• Users might – due to their cultural or social background– not like to outline their financial details to the bank (ora computerised system).

Relationship and appeal flaws can take the following form:

• Users might – due to their personal background – tendto uncritically follow bank staff’s advice.

• Users might – due to their cultural background, or familyrelated reasons – not dare apply for a loan.

• Users might – due to their insufficient understanding ofbanking business or their difficult state of affairs – just

appeal for help and overlook the fact that the bank onlyin rare cases can afford not to benefit from accepting aloan application.

C. Metaphors

Metaphorical structures, i.e. metaphors, allegories,metonymies or synecdoches, can be used to help the scanningor zapping user to understand a page or a website. In general,metaphorical structures have a communicative or cognitivefunction [6], [9]. For example, many users do not realisethat within a computer context a trash often stands as ametaphor for the action of deleting files. The interpretabilityof metaphorical structures depends on the common experienceof the sender and the receiver. Metaphors such as folder, files,trash can, and recycle bin are common to computer users butnot so common to naive users. However, metaphors can alsomislead users, e.g. the use of a trash box for ejecting disks inan Apple environment or the use of a clipboard for singletonmessages in a Windows environment. Naive users are notacquainted to these metaphors. Thus, metaphorical structures,if they are to succeed, must be familiar to users. The userscan understand content, functionality, and intention intuitivelyvia using such metaphorical structures. WIS development canprofit from well-integrated metaphorical structures that aimat focusing on a deeper context explanation as well as on amore specific navigation and selection.

Metaphorical structures can be used in the context of WISdesign for supporting the scanning or zapping user and forthe set-up of a story for the WIS. They can help introducingthe content, style and “the feeling inside” of a complex webpresentation. Mental models are also used in [31] to definepersistent internet-metaphors: digital library, electronic mail,electronic marketplace, and digital world. These metaphors arebased on ancient myths and archetypes that have influencedhuman thinking for thousands of years: keeper of knowledge(the digital library), communicator (electronic mail), the trader(electronic marketplace), and the adventurer (digital world).The internet representation of these metaphors is a matter ofcommon knowledge, but the fact of using metaphors is mostlynot known to users.

Metaphorical structures lead to more sophisticated user in-terfaces [17], [22] which are intuitively understandable, whichcan be used intuitively, whose “philosophy” or “mission” canbe captured within seconds by novel users and need not belearned – a requirement sometimes called “grandma-safe”.

Metaphors should meet requirements such as simple inter-pretation, common sense of the meaning, abstraction in theright (user-centered) way and integrability into the dialogue[25]. In our daily language, metaphorical structures have greatpower, so why should we not use them within WISs? In orderto do that, we have to integrate the metaphorical structuresinto the complete WIS development.

The summary of [21] in [18] states that metaphors refer toproperties of concepts rather than words. Consequently theirfunction is to help understand concepts rather than being justaesthetic or artistic expressions. Metaphors are an intrinsic

and indispensable part of everyday language; they are easilyused by “ordinary” people, and they are inevitable in humanthought and reasoning. This is rephrased in [20] saying thatthe new view of metaphors takes imaginative aspects of reason– metaphor, metonymy, and mental imagery – as central toreason rather than as a peripheral and inconsequential adjunctto the literal. Thus, we may say that human communication isessentially metaphorical.

In general, a metaphorical structure [32] is the unusual us-age of a language expression, i.e. using a language expressionin a meaning that is not expected in the application context.The language expression is used as a language pictorial whichworks on the basis of a similarity of two objects/words. Theseobjects/words are described by some dominant properties [2].

For metaphors there are two different definitions. Accordingto the traditional definition a metaphor is characterised bya substitution of names. For instance, the notion “virus”stands for a “damaging computer programm”. A second, moremodern definition characterises a metaphor as generating anew coherence of meanings. That is, two word fields are putinto a similarity relation.

Example 12: Consider the sentence “URLSnoop is a Tro-jan Horse that gathers email addresses secretly”. In this casethe characteristics of an event in ancient Greek mythology isprojected onto the computer. In doing this the characteristicsof the computer update the ancient myth leading to a modernserial of the Troy story.

An allegory is an extended metaphor that stands for acomplex idea.

Example 13: “Orchestra” is used as an allegory for agroup of people working together, e.g. a company. Relatedmetaphors are the “conductor” for the executive manager ofthe company, the “first violin” for the star designer or the chiefprogrammer, and “playing together” for working together.Thus, the allegory “orchestra” generates a complex field ofseveral related metaphors.

A metonymy is a replacement of a term by something that isrelated to this term. The relation can be real, mental, factual,or causal.

Example 14: In the sentence “This Kafka is interesting”the author Kafka stands for one of his books. In “The Kielerswill win the German League” the citizens of Kiel are standingfor the Kiel handball team.

Synecdoches are closely related to metonymies. In contrastto a metonymy a synecdoche stands for a part-whole-relation.For instance, in the phrase “to start a computer” the notion“computer” stands for its operating system.

In addition to these four further metaphorical and rhetoricalstructures are known such as synonyms, paraphrases, analo-gies, oxymorons, emphases, or ironies.

The generation of metaphors could be supported by logi-cally decomposing the information space into a small numberof domains that appear homogeneous with respect to theoffered functionality. This allows one to relate the domains touser types and expected user actions. Generation of metaphorsappears then as being connected to finding characterizing

names for the three valued relationships mentioned betweenuser types, expected user action and domain. It might be usefulfor this to omit user related information from the user type thatappears not to be relevant for the expected behavior. Further,methods from requirements engineering such as role-playingor brainstorming can be applied to generate first ideas on themetaphors to use. Clearly one must avoid, for a given usertype, having too many, conflicting or contradicting metaphorsbuilt into the web information system.

In order to use an appropriate linguistic representation fora metaphorical structure the following questions has to beconsidered:

• Who will the user be (experiences, age, knowledge etc.)?• What kind of communication is used (verbal communi-

cations vs. written communication vs. internet communi-cation etc.)?

• What are the possible communication objects (e.g. verbalcommunications have the gestures; the internet commu-nication has the colours and icons)?

• Which connotations (i.e. social and emotional side con-ditions) should not be used?

• Which cultural background does the user have?

In general, metaphorical structures are used with differentintentions. They can be predicative or persuading. Attributive,genitive, and apposition metaphorical structures add someinformation. Icons or colors illustrates properties. Thus thechoice of a representation form is restricted. It is not possiblethat all cognitive characteristics can have all representationforms.

Metaphorical structures can be classified as follows:

• conventional metaphorical structures on the basis ofstereotypes such as a phone icon;

• ex-metaphorical structures in technical terminology;• creative metaphorical structures which require greater

reasoning abilities from the user;• re-metaphorical structures through activation of images

with modification.

Example 15: Let us continue Example 11 and exploremetaphors that could be used in loan applications. Thesemetaphors correspond to message flaws to be dealt with below.These flaws are consequences of specific perceptions of theapplicant itself, the bank and its staff. Since we are dealingwith a quite formalized business we think these perceptionsshould be based on a conceptualization of this business. Weidentify three main roles (besides the decision-making) playedby bank staff. The first role is that of an information provider,which leads to the dictionary metaphor. The second role isthat of a helpful assistant who answers questions on how tofill in the form. This gives an operations manual metaphor.The third role is that of an adviser who provides advice aboutthe most suitable loan type or the acceptability of the user fora particular loan. This gives an adviser metaphor.

The communication between a user applying for a loan anda bank employee dealing with loan applications is mainlydetermined by the metaphors described above, and some

communication barriers. Recall that the identified metaphorsmainly relate to the role of bank staff as seen by the user. Tosome degree this is a consequence of the fact that the loanapplication processing is highly rule based and only leaves alittle latitude to bank staff.

Let us finally briefly consider communication barriers im-pacting the traditional loan application process. The levelof education may be a barrier to successful communicationbetween a user and bank staff. This is reflected in the userdimensions and should lead to further explanatory systemcomponents. Another severe communication barrier is theuser’s fear or bluff as its counterpart. A user might fear theloan application not being accepted, especially if the loan isessential and the financial situation is tough. Communicationbarriers may also arise due to gender, age, ethnicity, culturalor family background.

Dealing with bluff and fear requires the system to beas transparent as possible and to emphasize the identifiedadvice component. Inabilities with respect to language canbe dealt with based on a multi language feasible design.Cultural background and ethnicity up to some degree can bereflected by the system supplying the applicable general legalregulations. Age and gender may be addressable by design andlayout issues as well as focussing on the most required loanapplication areas and amounts.

V. VISUAL DESIGN PATTERNS

We will now discuss how the decisions made on the strategiclevel impact on the formation of the WIS presentation. Wemay assume that the result of conceptual WIS modelling isavailable, i.e. there is a clear specification, which content is tobe presented, and how the different content units are logicallylinked together. This is captured by the media schema in [28].So our focus now in on how the WIS content and functionalityis to be presented to its users. We concentrate on the visualdesign, though audio design could be tackled as well.

A. Basic Principles

Visual design patterns are composed of visual and functionalbuilding blocks. The visual building blocks correspond to thegeometric partitioning of the screen, whereas the functionalbuilding blocks realise the access to the presented content.Thus, the functional building blocks correspond directly tothe represented content and its organisation along the strategicprogression patterns. They order the content, whereas thevisual building blocks place the content on the screen usinga flexible graphical structure with constant colour coding andrepeating elements that reflect the functional order.

Within the limitations of this paper we concentrate on thevisual building blocks.In doing so, we have to consider thefollowing three aspects:

• the visual alignment and partitioning of the screen;• the colouring with respect to funcionality and aesthetics;• and the perspective perception of the whole screen.

The visual alignment is based on a tiling of the screen asa two-dimensional surface. In general, we can divide the hor-izontal and vertical axes using grid points xmin = x0 < x1 <

· · · < xk = xmax and ymin = y0 < y1 < · · · < y` = ymax. Atile is defined by a rectangular region [xi, xj ] [yi′ , yj′ ]. Thenuse a partition of the whole screen into tiles.

Example 16: A very common tiling is obtained by usingjust 4 horizontal grid points x0 < x1 < x2 < x3, and only 3vertical grid points y0 < y1 < y2. Then define four tiles

up = [x0, x3] [y1, y2] left = [x0, x1] [y0, y1]middle = [x1, x2] [y0, y1] right = [x2, x3] [y0, y1]

Usually, the “up” tile is used for some menu bar, the“left” tile for navigation links, the “middle” tile for the majorcontent, and the “right” tile for side options.

The colouring scheme will be the major instrument toachieve the desired atmosphere as specified in the strategicmodel. For the perception of the presentation by a user theinteraction of colours is decisive. The basis can be a colourchord consisting of n colours (n ∈ 2, 3, 4, 6) that form a reg-ular polygon in the colour circle. These are complemented byadding grey tones enabling to achieve contrast between lightand dark colours. A quality contrast results from brighteningthe coulours of a chosen ground chord in the same way.

From the theory of colour harmonics it is known that thechoice of colour chord impacts directly on the perceptionleading to the sensations such as warm, cool, cold, intensive,hot, light, dark, etc. Conversely, the desired sensation indicatesguidelines for the choice of the colour scheme.

The colouring scheme also impacts on achieving a three-dimensional impression (if desired) or not. The technicalmeans for achieving a perspective perception are contrast,colour perspective, depth of sharpness, and the differentiationof motif [24].

B. Grid Geometry

Following the general principles the grid geometry ad-dresses the visual alignment. We now leave the simple tilinginto several columns and rows aside and concentrate on grids,in which the visual building blocks have sizes following arhythmic structure that can be expressed by a sequence ofpositive integers. Such grid models can then be combined withcolour schemes in a way that the rhythmic proportions of thecolours conform to the desired atmosphere.

Fig. 9. The grid model of visual flags

We are particularly interested in the Fibonacci sequence,which is defined by the recurrence fn+2 = fn + fn+1 with

the starting values f1 = f2 = 1. This gives the well-known sequence 1, 1, 2, 3, 5, 8, 13, . . . Solving the recurrenceequation gives

fn =1√

5

(1 +√

52

)n

−1√

5

(1−√

52

)n

involving the two roots of the equation x2−x−1 = 0. Thepositive root is known as the number of the golden section,which played an important role in art and architecture, andappears naturally in nature.

A simple use of the sequence leads to the model of visualflags, which in fact dates back to Leonardo da Vinci. Thisis illustrated in Figure 9. The flags enable the selection ofsections that are ordered according to some functional criteria.

In terms of tiling we simply use the Fibonacci numbers asthe horizontal grid points, and do not bother about verticalgrid points at all. Multiplying the Fibonacci numbers with aconstant can be used to define a partition of the screen width.

Fig. 10. The Fibonacci grid model with flags

Another use of the Fibonacci sequence is to place squareswith increasing side length fi along a spiral as shown in thelower part of Figure 10. It is therefore called the Fibonacci gidmodel. In doing so we obtain a very nice tiling of the screen, inwhich the proportions of the square tiles are determined by theFibonacci sequence. If each tile is associated with a colour of awell chosen colour scheme this enables to achieve the desiredatmospheric effects as specified in the strategic model. Thethesis [24] shows this combination of the Fibonacci grid withvarious colour schemes in different web application projects.

The Fibonacci grid can be combined with visual flags asshown in Figure 10. In doing so we obtain a visual alignmentwith the following characteristics:

• It can be combined with a harmonic colouring due to theproportions of the tiles that are defined by the Fibonaccisequence. This has been often exploited in art.

• Its visual flags can be exploited for global navigationaccording to the functional specification.

• The implicitly given Fibonacci spiral can be used as aline along which the content progresses.

Fig. 11. Sample Page for Stimulating Atmosphere

C. Atmospheric Effect of Colour Schemes

On the strategic level we specified the desired atmosphereof a WIS. For this we used categories such as energetic,romantic, elegant, refreshing, harmonic and stimulating. Allthese categories refer to a desired sensation that the WISpresentation should convey to the users. The question is, whichcolour schemes can be identified to support these desiredeffects.

For each category we first need a ground colour chord,which is extended to a quality contrast. In particular, colourswill be brightened uniformly. Based on these base decisionswe develop an ordering of colours. The colour ordering incombination with the association to grid tiles determines theoverall effect of the colour scheme. The colour ordering isbased on formal and functional criteria:

• Formally, the order is determined by the placement of thecolours in the colour circle. It is known that equi-distantcolours harmonise better.

• Functionally, the order of colours is determined by thesubjective sensation and associations of a viewer. Thisis taken from psychological studies and centuries ofexperience in art.

An energetic or powerful atmosphere can be achieved usinga three-colour chord with bright and high-croma colours suchas a blueish purple with green and orange. The blueish purplecolour with increasing brightness can be used for the visualflags. Orange with increasing brightness can be applied to theinitial squares on the Fibonacci spiral, where green is reservedfor the largest tile. However, a tile will always inherit thecolour of its corresponding flag.

A romantic atmosphere can be achieved using a three-colour chord with pastell colours such as (light) blue, pinkand yellow. Similarly to the energetic atmosphere yellow andblue in increasing brightness would be used for the flags andthe initial tiles along the Fibonacci spiral, where pink wouldbe reserved for the largest tile.

An elegant atmosphere can be achieved using a two-colourchord, e.g. red and green, in combination with grey. As before,grey would be reserved for the largest tile in the Fibonaccigrid, while the other colours in increasing brightness wouldbe used for the initial tiles and the flags, respectively.

A refreshing atmosphere can be achieved using a three-colour chord with light colours in a “temperature contrast”,i.e. the individual colours show opposite effects with respect toassociated temperature. For instance, we might choose (light)purple, yellow-orange, and a blueish green such as cyan. Theuse on the Fibonacci is as before with yellow-orange for thelargest tile.

A harmonic or balanced atmosphere can be achieved usinga two-colour chord, e.g. dark blue and ochre, in combinationwith grey with grey being used for the largest tile. Similarly,a stimulating atmosphere can also be achieved using a two-colour chord, e.g. yellow-green with red-purple, in combina-tion with grey. Figures 11 and 12 show sample pages for theseatmospheric effects.

Fig. 12. Sample Page for Harmonic Atmosphere

VI. CONCLUSION

In this article we discussed the strategic modelling of webinformation systems on the basis of the abstraction layer modelfrom [28]. The starting point is an informal mission statementand a characterisation of the brand of the WIS, the latterone following a general classification scheme. Both togetherdescribe what the WIS is about, i.e. the purpose(s) of thesystem, and both result from brainstorming.

Going more into details we presented models of utilisationspace and utilisation portfolio, which describe in very general

terms the content that is to be presented in the WIS, thefunctionality, with which this content can be accessed, as wellas the users of the WIS, their goals, and the tasks that haveto be performed to reach these goals. The fourth and last partof a strategic WIS model are general rules for the gestalt,atmosphere and progression of the system based on knowledgeabout the cognitive perception of form, colour and other styleelements.

The strategic model complements the conceptual modelof WISs that was presented in [28]. Furthermore, it shiftsinterface design to a higher-level of abstraction in a way thatpermits intentions, metaphors and context information to beexploited from the very beginning, whereas it is usually leftonly to the generation of pages using style patterns. Thisenables a much tighter coupling of the abstraction layers inWIS development.

REFERENCES

[1] Atzeni, P., Gupta, A., and Sarawagi, S. Design and maintenance ofdata-intensive web-sites. In Proceeding EDBT’98, vol. 1377 of LNCS.Springer-Verlag, Berlin, 1998, pp. 436–450.

[2] Bußmann, H. Lexikon der Sprachwissenschaft. Kroner, Stuttgart, 1990.[3] Ceri, S., Fraternali, P., Bongio, A., Brambilla, M., Comai, S., and Matera,

M. Designing Data-Intensive Web Applications. Morgan Kaufmann, SanFrancisco, 2003.

[4] Chomsky, N. Lectures on Government and Binding. Mouton de Gruyter,Berlin, 1993.

[5] Cragan, J. F., and Shields, D. C. Understanding Communication Theory.Allyn and Bacon, 1998.

[6] Danesi, M. The neurological coordinates of metaphor. Communication& Cognition 22, 1 (1989), 73–86.

[7] De Troyer, O. Designing well-structured websites: Lessons learned fromdatabase schema methodology. In Conceptual Modeling- ER’98, T. Ling,S. Ram, and M. Lee, Eds., vol. 1507 of LNCS. Springer-Verlag, 1998,pp. 51–64.

[8] De Troyer, O., and Leune, C. WSDM: A user-centered design methodfor web sites. In Computer Networks and ISDN Systems – Proceedingsof the 7th International WWW Conference. Elsevier, 1998, pp. 85–94.

[9] Debatin, B. Metaphors and computers. Semiotic Review of Books 3, 1(1991).

[10] Dusterhoft, A., and Thalheim, B. Linguistic based search facilities insnowflake-like database schemes. Data & Knowledge Engineering 48(2004), 177–198.

[11] Fellbaum, C. The English verb lexicon as a semantic net. InternationalJournal of Lexicography 3 (1990), 278–301.

[12] Garzotto, F., Paolini, P., and Schwabe, D. HDM - a model-basedapproach to hypertext application design. ACM ToIS 11, 1 (1993), 1–26.

[13] Gomez, J., Cachero, C., and Pastor, O. Modelling dynamic personal-ization in web applications. In Third International Conference on WebEngineering – ICWE 2003, vol. 2722 of LNCS. Springer-Verlag, 2003,pp. 472–475.

[14] Hausser, R. Foundations of Computational Linguistics. Springer-Verlag,Berlin, Germany, 2001.

[15] Hirschheim, R., Klein, H. K., and Lyytinen, K. Information SystemsDevelopment and Data Modeling: Conceptual and Philosophical Foun-dations. Cambridge University Press, 1995.

[16] Houben, G.-J., Barna, P., Frasincar, F., and Vdovjak, R. HERA: Devel-opment of semantic web information systems. In Third InternationalConference on Web Engineering – ICWE 2003 (2003), vol. 2722 ofLNCS, Springer-Verlag, pp. 529–538.

[17] Johnson, S. Interface culture. Harper, San Francisco, 1997.[18] Kovecses, Z. Metaphor: A Practical Introduction. Oxford University

Press, Oxford, UK, 2002.[19] Kunze, J. Generating verb fields. In Proc. KONVENS (1992), Informatik

Aktuell, Springer, pp. 268–277. in German.[20] Lakoff, G. Women, Fire and Dangerous Things. University of Chicago

Press, Chicago, U.S.A., 1987.

[21] Lakoff, G., and Johnson, M. Metaphors We Live By. University ofChicago Press, Chicago, U.S.A., 1980.

[22] Lansdale, M. W., and Ormerod, T. C. Understanding interfaces, ahandbook of human-computer dialogue. Academic Press, London, 1994.

[23] Lowe, D., Henderson-Sellers, B., and Gu, A. Web extensions toUML: Using the MVC triad. In Conceptual Modeling – ER 2002,S. Spaccapietra, S. T. March, and Y. Kambayashi, Eds., vol. 2503 ofLNCS. Springer-Verlag, 2002, pp. 105–119.

[24] Moritz, T. Visuelle Gestaltungsraster interaktiver Informationssysteme.PhD thesis, BTU Cottbus, Cottbus, Germany, 2005. to appear.

[25] Persson, G. Meanings, models and metaphors; a study in lexicalsemantics in english. Umea Studies in the Humanities 92, UmeaUniversity, lmquist & Wiksell, 1990.

[26] Schewe, K.-D., Kaschek, R., Wallace, C., and Matthews, C. Emphasizingthe communication aspects for the successful development of electronicbusiness systems. Information Systems and E-Business Management 3,1 (2005), 71–100.

[27] Schewe, K.-D., and Thalheim, B. The co-design approach to web infor-mation systems development. International Journal on Web InformationSystems 1, 1 (2005), 5–14.

[28] Schewe, K.-D., and Thalheim, B. Conceptual modelling of webinformation systems. Data and Knowledge Engineering 54, 2 (2005),147–188.

[29] Schreiber, H., Sommerfeld, K.-E., and Starke, G. Deutsche Wortfelderfur den Sprachunterricht: Verbgruppen. VEB Verlag Enzyklopadie,Leipzig, 1990.

[30] Schwabe, D., and Rossi, G. An object oriented approach to web-basedapplication design. TAPOS 4, 4 (1998), 207–225.

[31] Stefik, M. Internet Dreams; Archtypes, Myths, and Metaphors. The MITPress, 1997.

[32] Thalheim, B., and Dusterhoft, A. The use of metaphorical structures forinternet sites. Data & Knowledge Engineering 35 (2000), 161–180.

Thomas Moritz studied graphic design and scenographyfor television at the University of Arts in Berlin (Germany).During 1978 and 1994 he worked as scenographic designer,computer artist and as supervisor of animation at differenttelevision channels. Between 1995 and 1997 he wasvisiting professor for scenography at the University ofFilm and Television in Potsdam (Germany). In 1998 hewas representing professor for media design and mediapsychology at Anhalt University of Applied Sciences. Since2000 as visiting professor for media design at BrandenburgianTechnical University at Cottbus (Germany). Major fields ofinterest are web design and graphical user interfaces.

Klaus-Dieter Schewe studied mathematics and computerscience at Bonn University (Germany). In 1985 he receivedhis Ph.D. in Mathematics from Bonn University. During1985 and 1990 be worked with large industrial companiesin the fields of Artificial Intelligence, Software Engineeringand Office Information Systems. Returning to HamburgUniversity in 1990 he worked on Formal specifications andsemantics and Database Theory. In 1995 he received theHabilitation (= D.Sc.) in Theoretical Computer Sciencefrom the Brandenburgian Technical University at Cottbus(Germany). From 1994 to 1999 he worked at the ComputerScience Department of the Technical University Clauthal.Since 2000 he is Chair of Information Systems at MasseyUniversity in New Zealand. Since 2003 he is also the Directorof the Information Science Research Centre at MasseyUniversity. Since his habilitation his major fields of interestare Formal specifications and semantics, Logic in Computer

Science, Database Theory, Distributed Object Bases andDesign of Integrated Information Systems.

Bernhard Thalheim studied mathematics and computerscience at the Technical University Dresden and then atMoscow State University Lomonossov, from which he re-ceived a Ph.D. degree in 1979. Back in Germany he completedhis Habilitation (= D.Sc.) in Theoretical Computer Scienceat the Technical University Dresden in 1986. After that heheld full professor positions at Rostock University and theBrandenburgian Technical University at Cottbus. Since 2003he is Chair for Databases and Information Systems at ChristianAlbrechts University Kiel. His major research interests areDatabase Theory, Logic in Computer Science, Design Method-ologies for Integrated Information Systems, in particular WebInformation Systems, and Database Component Ware.

Databases of Personal Identifiable Information

Sabah S. Al-Fedaghi Bernhard Thalheim Kuwait University - Kuwait Kiel University - Germany

[email protected] [email protected]

Abstract

This paper explores the difference between two

types of information: personal identifiable information (PII), and non-identifiable information (NII) to argue that security, policy, and technical requirements set PII apart from NII. The paper describes databases of personal identifiable information that are built exclusively for this type of information with their own conceptual scheme, system management, and physical structure. 1. Introduction

This paper explores the privacy-related differences between types of information to argue that security, policy, and technical requirements set personal identifiable information apart from other types of information, which involves establishing a PII database with its own conceptual scheme, system management, and physical structure.

Different types of information of interest in this paper are shown in Figure 1. We will use the term infon to refer to “a piece of information” [4]. The parameters are objects, and the so-called anchors assign these objects such as agents to parameters. Infons can have subinfons that are also infons. Let INF the set of infons in the system. Four types of infons are defined: 1. So-called “private” information is a subset of INF. “Private” information is partitioned into two types of information: PII and PNI. 2. PII = the set of pieces of personal identifiable information. We use the term pinfon to refer to this special type of infon. 3. PNI = the set of pieces of non-identifiable information. 4. NII = (INF – PII). We use the term ninfon to refer to this special type of infon.

NII is the set of pieces of non-identifiable information and includes all pieces of information except personal identifiable information. 2. Related Works

Separating “private” data from “public” data has already been adopted in privacy-preserving systems. However, these systems do not distinguish explicitly personal identifiable information. The Platform for Privacy Preferences (P3P) is one such system that provides a means for privacy policy specification and exchange but “does not provide any mechanism to ensure that these promises are consistent with the internal data processing” [3]. It is our judgment that “internal data processing” requires recognizing explicitly that “private data” is of two types: personal identifiable information and personal non-identifiable information, and this difficulty is caused by the heterogeneity of data. Hippocratic databases have been introduced as systems that integrate privacy protection within relational database systems [1]. Nevertheless, in principle, a Hippocratic database is a general DBMS with a purpose mechanism. Purposes can be declared for any data item that is not necessarily personal identifiable information.

Figure 1. Types of information..

Information (INF)

Private/personal information

PII

PNI

3. Infons

This section reviews the theory of infons, and simultaneously presents it in the PII context in anticipation of materials (e.g., examples) developed in the remaining part of the paper that introduce a theory of PII infons.

The theory of infons provides a rich algebra of construction operations that can be applied to PII. An infon is a discrete item of information and may be parametric. The parameters represent objects. Anchors assign objects to parameters. PII infons are distinguished by the mandatory presence of at least one proprietor, an object of type identifiable person.

Infons in an application domain such as personal identifiable information are typically interrelated with each other; they partially depend on each other, partially exclude each other, and may be (hierarchically) ordered. Thus we need a theory that allows constructing a “lattice” of infons (and PII infons) that includes basic and complex infons while taking into consideration their structures and relationships. In such a theory, we identify basic infons that cannot be decomposed into more basic infons. This construction mechanism of infons from infons should be supported by an algebra of construction operations. We generally may assume that each infon consists of a number of components. The construction is applied in performing combination, replacement, or removal of some of these components; some of them may be essential (not removable) or auxiliary (optional).

Infons may also be related to each other. We use predicates that relate infons with each other. Since infons may consist of infons, then binary predicates are sufficient to describe relationships among them. Thus, the world of infons can be specified as the triple: (A;O;P) as follows.

- Atomic infons A - Algebraic operations O for computing complex

infons such as combination ⊠of infons, abstraction ⊡of infons by projections, quotient ⊟of infons, renaming of infons, union ⋓of infons, intersection ⋒of infons, full negation ¬ of infons, and minimal negation of infons within a given context.

- Predicates P stating associations among infons such as the subinfon relation, a statement whether infons can be potentially associated with each other, a statement whether infons cannot be potentially associated with each other, a statement whether infons are potentially compatible with each other, and a statement whether infons are incompatible with each other.

The combination of two infons results in an infon that has all components of the two infons. The abstraction is used for a reduction of components of an infon. The quotient allows concentrating on those components of the first life that do not appear in the second infon. The union takes all components of the two infons and does not combine common components into one component. The full negation allows generating all those components that do not appear in the infon. The minimal negation restricts this negation to some given context.

We require that the subinfon relation is not transitively reflexive. The compatibility and incompatibility predicates are not contradictory. The potential association and its negation must not conflict. The predicates should not span all possible associations among the infons but only those that are meaningful in a given application area. We may assume that two infons are either potentially associated or cannot be associated with each other. The same restriction can be made for compatibility.

This infon world is very general and allows deriving more advanced operations and predicates. If we assume the completeness of compatibility and association predicates we may use expressions defined by the operations and derived predicates. The extraction of application-relevant infons from infons is supported by five operations.

1. Infon projection narrows the infon to those parts (objects or concepts, axioms or invariants relating entities, functions, events, and behaviors) that are of concern for the application relevant infons. For example, a projection operation may produce the set of proprietors from a given infon, e.g., Mary, John from John loves Mary.

2. Infon instantiation lifts the general infons to those that are of interest within the solution and instantiates variables by values that are fixed for the given system. For example a PII infon may be instantiated from its anonymized version, e.g., John is sick from Someone is sick.

3. Infon determination is used for selecting those traces or solutions to the problem under inspection that are the most perspective or best fitting for the system envisioned. The determination typically results in a small number of scenarios for the infons that are going to be supported. For example, infon determination to decide whether an infon belongs to a certain piiSphere (PII of a proprietor – to be discussed later).

4. Infon extension is used for adding those facets that are not given by the infon but by the environment or the platforms that might be chosen or that might be used for simplification or support of the infon (e.g., additional data, auxiliary functionality). For example,

infon extension to related non-identifiable information (to be discussed later).

5. Infons are often associated, adjacent, interact, or fit with each other. Infon join is used to combine infons into more complex and combined infons that describe a complex solution. For example, joining atomic PII to form compound PII and a collection of related PII information.

The application of these operations allows extraction of which subinfons, which functionality, which events, and which behavior (e.g., the action/verb in PII) is shared among information spheres (e.g., of proprietors). These shared facilities provide cross-cutting concerns among all information spheres of relevant infons. They also hint at possible architectures of information and database systems and on separation into candidate components. For instance, entity (say, non-person entity) sharing describes which information flow and development can be observed in the information spheres.

The theory of PII infons can be applied in several areas such as the technical and legal aspects of information privacy and security.

4. Personal Identifiable Information

It is typically claimed that what makes the data “private” or “personal” is either specific legislation, e.g., a company must not disclose information about its employees, or individual agreements, e.g., a customer has agreed to an electronic retailer's privacy policy. However, this line of thought blurs the difference between personal identifiable information and other “private” or “personal” information. Personal identifiable information has an “objective” definition in the sense that it is independent of such authorities as legislation or agreement.

PII infons involve relationships (e.g., possession) with their proprietors, persons but non-proprietors, and non-persons such as institutions, agencies, or companies: For example, a person may possess PII of another person, or a company may have the PII of someone in its database. However, proprietorship of PII is reserved only to its proprietor regardless of who possesses copy of it.

To base personal identifiable information on firmer ground, we turn to stating some principles related to such information. For us, personal identifiable information (pinfon) is any information that has referent(s) to uniquely identifiable persons. In logic, reference is the relation of a word (logical name) to a thing.

Following Devin’s formalism [4] an infon has the form <<R, a1, ... , an, 1>> and <<R, a1, ... , an, 0>>. R

is an n-place relation and a1, . . . , an are objects appropriate for R. 0 and 1 indicate these may be thought objects do, respectively, do not, stand in relation R. For simplicity sake, we may write an infon <<R, a1, ... , an, 1/0>> as <<a1, ... , an>> when R is known or immaterial.

A PII infon, pinfon, is an infon such that at least one of the objects is a singly identifiable person. Any singly identifiable person in the pinfon is called proprietor. The proprietor is the person about whom the pinfon communicated information. If there is exactly one object of this type, the pinfon is an atomic pinfon; if there is more than one singly identifiable person, it is a compound pinfon. An atomic pinfon is a discrete piece of information about a singly identifiable person. A compound pinfon is a discrete piece of information about several singly identifiable persons. If the infon does not include a singly identifiable person then it called a ninfon.

The following is a series of propositions that establish the foundation of the theory of personal identifiable information. The symbol “→” denotes implication. 1. Inclusivity of INF σ ∈ INF ↔ σ ∈ PII ∨ σ ∈ NII 2. Exclusivity of PII and NII σ ∈ INF ∧ σ ∉ PII → σ ∈ N σ ∈ INF ∧ σ ∉ N → σ ∈ PII 3. Identifiability Let ID denote the set of (basic) pinfons of type << is, Þ, 1>> and Let þ be a parameter for a singly identifiable person. Then << is, Þ, 1>> → << is, Þ, 1>> ∈ INF 4. Inclusivity of PII Let nσ denote the number of uniquely identified persons in the infon σ, then σ ∈ INF ∧ nσ > 0 ↔ σ ∈ PII 5. Proprietary For σ ∈ PII, let PROP(σ) be the set of proprietors of σ. Let PERSONS denote the set of (natural) persons. Then, σ ∈ PII → PROP(σ) ∈ PERSONS 6. Inclusivity of NII σ ∈ INF ∧ nσ = 0 ↔ σ ∈ NII 7. Combination of non-identifiability with identity Let ID denote the set of (basic) pinfons of type: << is, Þ, 1>>. Then, σ1 ∈ PII ↔ <<σ2 ∈ NII ⊠ σ3 ∈ ID) >>

assuming σ1 ∉ ID. “⊠ ” here denotes the “merging” of two subinfons. 8. Closability of PII σ1 ∈ PII ⊠ σ2 ∈ PII → (σ1 ⊠ σ2) ∈ PII

9. Combination with non-identifiability σ1 ∈ NII ⊠ σ2 ∈ PII → (σ1⊠ σ2) ∈ PII 10. Reducibility to non-identifiability σ1 ∈ PII ⊠ ′ σ2 ∈ ID ↔ σ3 ∈ NII

where σ2 is a subinfon of σ1. “⊠ ′′” denotes removing σ2. 11. Atomicity Let APII = the set of atomic personal identifiable information. Then, σ ∈ PII ∧ nσ = 1 ↔ σ ∈ APII 12. Non-atomicity Let CPII = the set of compound personal identifiable information. Then, σ ∈ PII ∧ nσ > 1 ↔ σ ∈ CPII 13. Reducibility to atomicity σ ∈ CPII ↔ <<σ1, σ2, …, σm >>, σi ∈ APII, m = nσ, and 1≤i≤ m, and PROP(σ1) , PROP(σ2), …, PROP(σm) = PROP(σ).

Next we discuss each of these propositions. Inclusivity of INF σ ∈ INF ↔ σ ∈ PII ∨ σ ∈ NII That is, infons are the union of pinfons and ninfons. PII is the set of pinfons (pieces of personal identifiable information), and NII is the set of ninfons (pieces of non-identifiable information). Exclusivity of PII and NII σ ∈ INF ∧ σ ∉ PII → σ ∈ N σ ∈ INF ∧ σ ∉ N → σ ∈ PII That is, every infon is exclusively either pinfon or ninfon. Identifiability Let þ be a parameter for a singly identifiable person, i.e., a specific person, defined as Þ = IND1|<< singly identifiable, IND1, 1>> where IND indicates the basic type: an individual [4]. That is, Þ is a (restricted) parameter with an anchor for an object of type singly identifiable individual. The individual IND1 is of type person defined as << person, IND1, 1>> Put simply, þ is a reference to a singly identifiable person. We now elaborate on the meaning of “identifiable.”

Consider the set of unique identifiers of persons. Ontologically, the Aristotelian entity/object is a single, specific existence (a particularity) in the world. For us, the identity of an entity is its natural descriptors (e.g., tall, black eyes, male, blood type A, etc.). These descriptors exist in the entity/object. Tallness, whiteness, location, etc. exist as aspects of the existence of the entity. We recognize the human entity from its natural descriptors. Some descriptors form identifiers. A natural identifier is a set of natural descriptors that facilitates recognizing a person uniquely. Examples of identifiers include fingerprints, faces, and DNA. No two persons have identical natural

identifiers. An artificial descriptor is a descriptor that is mapped to a natural identifier. Attaching the number 123456 to a particular person is an example of artificial descriptors in the sense that they are not recognizable in the (natural) person. An artificial identifier is a set of descriptors that is mapped to a natural identifier of a person. By implication, no two persons have identical artificial identifiers. If two persons somehow have the same Social Security number, then this Social Security number is not an artificial identifier because it is not mapped uniquely to a natural identifier.

We define identifiers of proprietors as infons. Such definition is reasonable since the mere act of identifying a proprietor is a reference to a unique entity in the information sphere. Hence, << is, Þ, 1>> → << is, Þ, 1>> ∈ INF That is, every unique identifier of a person is an infon. These infons cannot be decomposed into more basic infons. Inclusivity of PII

Next we position identifiers as the basic infons in the sphere of PII. The symbol nσ denotes the number of uniquely identified persons in the infon σ. Then we can define PII and NII accordingly: σ ∈ INF ∧ nσ > 0 ↔ σ ∈ PII That is, an infon that includes unique identifiers of persons is personal identifiable information. From (3) and (4), any unique personal identifier or piece of information that embeds identifiers is personal identifiable information. Thus, identifiers are the basic PII infons (pinfons) that cannot be decomposed into more basic infons. Furthermore, every complex pinfon includes in its structure at least one basic infon, i.e., identifier. The structure of a complex pinfon is constructed from several components: - Basic pinfons and ninfons, i.e., the pinfon John S. Smith and the ninfon Someone is sick form the atomic PII (i.e., PII with one proprietor) John S. Smith is sick. This pinfon is produced by an instantiation operation that lifts the general infons to pinfons and instantiates the variable (Someone) by a value (John S. Smith). - Complex pinfons form more complex infons, e.g., John S. Smith and Mary F. Fox are sick

We notice that the operation of projection is not PII-closed since we can define projecting of ninfon from pinfon (removing all identifiers). This operation is typically called anonymization.

Every pinfon refers to its proprietor(s) in the sense that it “leads” to him/her/them as distinguishable entities in the world. This reference is based on his/her/their unique identifier(s). The relationship between persons and their own pinfon is called proprietorship [1]. A pinfon is proprietary PII of its proprietor(s).

Defining pinfon as “information identifiable to the individual” does not mean that the information is “especially sensitive, private, or embarrassing. Rather, it describes a relationship between the information and a person, namely that the information—whether sensitive or trivial—is somehow identifiable to an individual” [5]. However, personal identifiable information (pinfon) is more “valuable” than personal non-identifiable information (ninfon) because it has an intrinsic value as “a human matter,” just as privacy is a human trait.

To exclude such notions as confidentiality that are applicable to the informational privacy of non-natural persons (e.g., companies), the next proposition formalizes that pinfon is applied only to (natural) persons.

For σ ∈ PII, we define PROP(σ) to be the set of proprietors of σ. Notice that |PROP(σ ∈ PII)| = nσ. Multiple occurrences of identifiers of the same proprietor are counted as a single reference to the proprietor. In our ontology, we categorize things (in the world) as objects (denoted by the set OBJECTS) and non-objects. Objects are divided into (natural) persons (denoted by the set PERSONS) and non-persons. A fundamental proposition in our system is that proprietors are (natural) persons. Proprietary σ ∈ PII → PROP(σ) ∈ PERSONS That is, pinfons are pieces of information about persons. Inclusivity of NII σ ∈ INF ∧ nσ = 0 ↔ σ ∈ NII That is, non-identifiable information (ninfon) does not embed any unique identifiers of persons. Combination of non-identifiability with identity Next we can specify several transformation rules that convert from one type of information to another. These (privacy) rules are important to decide what type of information applies to what operations (e.g., information disclosure rules).

Let ID denote the set of (basic) pinfons of type << is, Þ, 1>>. That is, ID is the set of identifiers of persons (in the world). We now define construction of complex infons from basic pinfons and non-identifying information. The definition also applies to projecting pinfons from more complex pinfons by removing all or some non-identifying information. σ1 ∈ PII ↔ <<σ2 ∈ NII ⊠ σ3 ∈ ID) >> assuming σ1 ∉ ID. That is, non-identifiable information plus a unique personal identifier is personal identifiable information and vice versa. Thus the set of pinfons is closed under operations that remove or add non-identifying information. We assume the empty information ∅ is in

NII. “⊠ ” here denotes “merging” two subinfons. We also assume that there is only a single σ3 ∈ ID added to σ2 ∈ NII; however, the proposition can be generalized to apply to multiple identifiers. An example of proposition 7 is σ1 = << John loves apples>> ↔ <<σ2 = Someone loves apples ⊠ σ3 = John>> Or, in a simpler description: σ1 = John loves apples ↔ σ2 = Someone loves apples ⊠ σ3 = John

Proposition can also be applied to the union ⋓ of pinfons. Closability of PII

PII is a closed set under different operations (e.g., merge, concatenate, submerge, etc.) that construct complex pinfons from more basic pinfons. Hence, σ1 ∈ PII ⊠ σ2 ∈ PII → (σ1 ⊠ σ2) ∈ PII That is, merging personal identifiable information with personal identifiable information produces personal identifiable information. Also, PII is a closed set under different operations (e.g., merge, concatenate, submerge, etc.) that construct complex pinfons by mixing pinfons with non-identifying information. Combination with non-identifiability σ1 ∈ NII ⊠ σ2 ∈ PII → (σ1⊠ σ2) ∈ PII That is, non-identifying information plus personal identifiable information is personal identifiable information. Reducibility to non-identifiability

Identifiers are the basic pinfons. Removing all identifiers from a pinfon converts it to non-identifying information. Adding identifiers to any piece of non-identifying information converts it to a pinfon, σ1 ∈ PII ⊠ ′ σ2 ∈ ID ↔ σ3 ∈ NII where σ2 is a subinfon of σ1. Proposition 10 states that personal identifiable information minus a unique personal identifier is non-identifying information and vice versa. “⊠ ′′” here denotes removing σ2. We assume that there is a single σ2 ∈ ID embedded in σ1; however, the opposition can be generalized to apply to multiple identifiers such that removing all identifiers produces σ3 ∈ NII. Atomicity Furthermore, we define atomic and non-atomic (compound) types of pinfons. Let APII = a set of atomic personal identifiable

information. Each piece of atomic personal identifiable information is a special type of pinfon called apinfon. As we will see later, cpinfons can be reduced to apinfons, thus simplifying the analysis of PII.

Formally, the set APII is defined as follows. σ ∈ PII ∧ nσ = 1 ↔ σ ∈ APII That is, an apinfon is a pinfon that has a single human referent. Notice that σ may embed several identifiers of the same person, yet the referent is still one. Notice that apinfons can be basic (a single identifier) or complex (a single identifier plus non-identifiable information). Non-atomicity Let CPII = a set of compound personal identifiable information. Each piece of compound personal identifiable information is a special type of pinfon called cpinfon. Formally, the set CPII is defined as follows. σ ∈ PII ∧ nσ > 1 ↔ σ ∈ CPII That is, a cpinfon is a pinfon that has more than one human referent. Notice that cpinfons are always complex since they must have at least two apinfons (two identifiers).

The apinfon (atomic personal identifiable information) is the “unit” of personal identifiable information. It includes one identifier and non-identifiable information. We assume that at least some of the non-identifiable information is about the proprietor. In theory this is not necessary. Suppose that an identifier is amended to a random piece of non-identifiable information (noise). In the PII theory the result is (complex) atomic PII. In general, mixing noise with information preserves information. Reducibility to atomicity Any cpinfon is privacy-reducible to a set of apinfons (compound personal identifiable information). For example, John and Mary are in love can be privacy-reducible to the apinfons(?) John and someone are in love and Someone and Mary are in love. Notice that our PII theory is a syntax (structural) based theory. It is obvious that the privacy-reducibility of compound personal identifiable information causes a loss of “semantic equivalence,” since the identities of the referents in the original information are separated. Semantic equivalency here means preserving the totality of information, the pieces of atomic information, and their link.

Privacy reducibility is expressed by the following proposition: σ ∈ CPII ↔ <<σ1, σ2, …, σm >>, σi ∈ APII, m = nσ, and 1≤i≤ m, and PROP(σ1) , PROP(σ2), …, PROP(σm) = PROP(σ). The reduction process produces m atomic personal identifiable information with m different proprietors. Notice that the set of resultant apinfons is a compound pinfon. This preserves the totality of the original cpinfon through linking its apinfons together as members of the same set.

5. Categorization of atomic personal identifiable information

In this section, we identify categories of apinfons. Atomic personal identifiable information provides a foundation for structuring pinfons since compound personal identifiable information can be reduced to a set of apinfons. We concentrate on reducing all given personal identifiable information to sets of apinfons. Justification for this will be discussed later. 5.1. Eliminating ninfons embedded in an apinfon

Organizing a database of personal identifiable information requires filtering and simplifying apinfons to more basic apinfons in order to make the structuring of pinfons easier. Proposition (9) tells us that pinfons may carry non-identifiable information, ninfons. This non-identifiable information may be a random noise or information not about the proprietor directly. Removing random noise is certainly an advantage in designing a database. Identifying information that is not about the proprietor clarifies the boundary between PII and NII.

A first concern when analyzing an apinfon is projecting (isolating, factoring) information about any other entities besides the proprietor. Consider the apinfon John’s car is fast. This is information about John and about a car of his. This apinfon can be projected as: ⊡ (John’s car is fast) ⇒ The car is fast, John has a car, where ⇒ is a production operator. John’s car is fast information embeds the “pure” apinfon John has a car and the ninfon The car is fast. John has a car is information about a relationship that John has with another object in the world. This last information is an example of what we call self information. Self information (sapinfon = self atomic pinfon) is information about a proprietor, his/her aspects (e.g., tall, short), or his/her relationship with non-human objects in the world. So, it is useful to further reduce apinfons (atomic) to sapinfon (self).

Sapinfon is related to the concept of “what the piece of apinfon is about.” In the theory of aboutness, this question is answered by studying the text structure and assumptions by the source about the receiver (e.g., reader). We formalize aboutness in terms of the procedure ABOUT(σ), which produces the set of entities/objects that σ is “talking” about. In our case, we aim to reduce any self infon σ to σ´ such that ABOUT(σ) is PROP(σ´).

Self atomic information represents information about: • Aspects of proprietor (identification, character, acts, etc.) • His or her association with non-person “things” (e.g. house, dog, organization, etc.) • His or her relationships with other persons (e.g. wife, friend, employee, etc.)

With regard to non-objects, of special importance for privacy analysis are aspects of persons that are expressed by sapinfon. Aspects of a person are his (physical) parts, his character, his acts, his conditions, his name, his health, his color, his handwriting, his blood type, his manner, his intelligence, etc. Their existence depends on the person, in contrast to (physical or social) objects associated with him/her such as his/her house, dog, spouse, job, professional associations, etc.

Let SAPII denote the set of sapinfons (self personal identifiable information). 14. Aboutness proposition σ ∈ SAPII ↔ ABOUT(σ) = PROP(σ) That is, atomic personal identifiable information σ is said to be self personal identifiable information (sapinfon) if its subject is its proprietor. The term “subject” here means what the entity is about when the information is communicated. The mechanism (e.g., manually) that converts APII to SAPII has yet to be investigated. 5.2. Sapinfons involving aspects of proprietor or relationship with non-person

We further simplify sapinfons. Let OPJ(σ ∈ SAPII) be the set of objects in σ. SAPII is of two types depending on the number of objects embedded in it: singleton, ssapinfon and multitude, msapinfon. The set ssapinfons, SSAPII, is defined as: 15. Singleton proposition σ ∈ SSAPII → σ ∈ SAPII ∧ (PROP(σ) = OPJ(σ)) That is, the proprietor of σ is its only object in p. The set msapinfons, MSAPII, is defined as: 16. Multitude proposition σ ∈ MSAPII → σ ∈ SAPII ∧ (|OPJ(σ)| > 1) That is, σ embeds other objects beside its proprietor. We also assume logical simplification that eliminates conjunctions and disjunctions of PIIS.

Now we can declare that the sphere of personal identifiable information (piiSphere) for a given proprietor is the database that contains: 1. All ssapinfons and msapinfons of the proprietor, including their arrangement in super-infons (e.g., to preserve compound personal identifiable information).

2. Related non-identifiable information to the piiSphere of the proprietor as discussed. 5.3. What is related non-identifiable information?

Consider the msapinfons Alice visited clinic Y. It is msapinfons because it represents a relationship (not aspect of) the proprietor Alice had with an object, the clinic. Information about the clinic may or may not be privacy related information. For example, year of opening, number of beds, and other information about the clinic are not privacy related information. Thus, such information ought not to be included in Alice’s piiSphere. However, when the information is that the clinic is an abortion clinic, then Alice’s piiSphere ought to include this non-identifiable information about the clinic. 6. Justifications for PII databases

We concentrate on what we call PII database, PIIDB, that contains personal identifiable information and information related to it. Security requirement: We can distinguish two types of information security: (1) Personal identifiable information security, and (2) Non-identifiable information security. While the security requirements of NII are concerned with the traditional system characteristics of confidentiality, integrity, and availability, PII security lends itself to unique techniques that pertain only to PII.

The process of protecting PII involves: (1) Protection of the identities of the proprietor, (2) Protection of the non-identity portion of the PII. Of course, all information security tools such as encryption can be applied in this context, yet other methods (e.g., anonymization) utilizing the unique structure of PII as a combination of identities and other information can also be used. Data-mining attacks on PII aim at determining the identity of the proprietor(s) from non-identifiable information: for example, determining the identity of the patient from anonymized information that gives age, sex, and zip code in health records (k-anonymization). Thus, PII lends itself to unique techniques that can be applied in protection of this information.

Another important issue that motivates organizing PII separately is that any intrusion on PII involves information besides the owner’s information (e.g., a company, proprietors, and other third parties, e.g., privacy commissioner). For example, a PII security

system may require immediate alerting of the proprietor of intrusion on his/her PII.

An additional point is that the sensitivity of PII is in general valued more highly than the sensitivity of other types of information. PII is more “valuable” than non-PII because of its privacy aspect, as discussed previously. Such considerations imply a special security status for PII. Policy requirements. Policies that are applied for PII are not applicable to NII (e.g., consent, opt-in/out, proprietor’s identity management, trust, privacy mining). While the NII security requirements are concerned with the traditional system characteristics of confidentiality, integrity, and availability, PII privacy requirements are concerned also with such issues as purpose, privacy compliance, transborder flow of data, third party disclosure, etc. Separating PII from NII can reduce the complex policies required to safeguard sensitive information where multiple rules are applied, depending upon who is accessing the data and what the function is.

In general, PIIDB goes beyond mere protection of data: 1. PIIDB identifies proprietor’s piiSphere and provides security, policy, and tools to the piiSphere. 2. PIIDB provides security, policy, and tools only to proprietor’s piiSphere, thus conserving privacy efforts. 2. PIIDB identifies inter-piiSphere relationships (proprietors’ relationships with each other) and provides security, policy, and tools to protect the privacy of these relationships. 7. Personal Identifiable Information Database (PIIBD)

The central mechanism in PIIDB is an explicit declaration of proprietors in a table that includes unique identifiers of all proprietors in the PIIDB. The principle of uniqueness of proprietor’s identifiers requires that the internal key is mapped one-to-one to the individual's legal identity or physical location.” This is an important feature in PIIDB to guarantee consistency of information about persons. This “identity” uniquely identifies the piiSphere and distinguishes one piiSphere from another.

PIIDB obeys all propositions defined previously. Some of these propositions can be utilized as privacy rules. As an illustration of the applications of these propositions, consider the case of privacy constraint that prohibits disclosing σ ∈ PII. By proposition (9) above, mixing (e.g., amending, inserting, etc.) σ with any other piece of information makes the disclosure constraint apply to the combined piece of information. In this case a general policy is: Applying a protection rule to σ1 ∈ PII implies applying the same protection to (σ1⊠ σ2) where σ2 ∉ PII.

8. Conclusion The theory of PII infons can provide a theoretical foundation for technical solutions for protection of personal identifiable information. In such approach, privacy rules form an integral part of the design of the system. PII can be identified (hence becomes an object to privacy rules) during processing of information that may mix it with other types of information. We proposed to analyze and process PII as a separate database with clear boundary lines with non-identifiable information. This facilitates meeting the unique requirements of PII. 9. References [1] R. Agrawal, J. Kiernan, R. Srikant, and Y. Xu, “Hippocratic databases”, In 28th International Conference on Very Large Databases (VLDB), Hong Kong, China (August, 2002). [2] S. Al-Fedaghi, G. Fiedler, and B. Thalheim, “Privacy Enhanced Information Systems”, in Information Modelling and Knowledge Bases XVII, Vol. 136. Frontiers in Artificial Intelligence and Applications, Edited by Y. Kiyoki, J. Henno, H. Jaakkola, and H. Kangassalo. IOS Press, February 2006. [3] J. Byun, E. Bertino, and N. Li, “Purpose Based Access Control of Complex Data for Privacy Protection”, SACMAT’05, June 1–3, 2005, Stockholm, Sweden. [4] K. Devlin, Logic and Information. New York: Cambridge UP, 1991. [5] J. Kang, “Information Privacy in Cyberspace”, Transactions, 50 Stanford Law Review 1193 (1998), 1212-20.

Privacy Enhanced Information SystemsSabah S. Al-Fedaghi1, Gunar Fiedler2, and Bernhard Thalheim2

1 Computer Engineering Department, Kuwait University, Safat 13060, [email protected]

2 Kiel University, Computer Science Institute, 24098 Kiel, Germanyfiedler | [email protected]

Abstract. Privacy is becoming a major issue of social, ethical and legal concern onthe Internet. The development of information technology and the Internet has majorimplications for the privacy of individuals. Studies of private or personal informationhave related it to such concepts as identifiably, secrecy, anonymity, control, etc. Fewstudies have examined the basic features of this type of information. Also, databasemodels (e.g., ’Hippocratic’ [AKX02] database) for this type of information have beenproposed. This paper studies the nature of private information and develop a new con-ceptual model for databases that contain exclusively private information. The modelutilizes the theory of infons to define “private infons”, and develops taxonomy of theseprivate infons based on the notions of proprietary and possession. The proposed modelalso specifies different privacy rules and principles, derives their enforcement, and de-velops and tests architecture for this type of databases.

1 Introduction

1.1 Information Privacy

The notion of privacy is becoming an important feature in all aspects of life of modern society.“[ P]rivacy will be to the information economy of the next century what consumer protectionand environmental concerns have been to the industrial society of the 20th century.” [Gle96]One of the most important factors that contributed to this increasing significance of the con-cept of privacy has been the appearance of global computer networks. They have allowedinformation to be moved around the world and made national boundaries irrelevant to mosttypes of communication. This has raised concerns about privacy in the on-line environmentand has affected different aspects of dealing with private information in the areas of security,commerce, government, etc.

We distinguish today between media privacy, territorial privacy, communication privacy,bodily privacy, and information privacy. The first four forms of privacy are now well sup-ported by laws, constitutional rights and other legal frameworks. Although a number of lawsprotecting information privacy have been introduced in most developed countries, informa-tion privacy is challenged and not well protected due to the technological development, e.g.the commercial success, misbehavior, tools for the “glass box customer” and WWW misuse.Already [Wes67] coined principles of privacy that must be preserved by any system: opennessand transparency, individual participation, collection limitation, data quality, use limitation,reasonable security, and accountability.

1.2 Database Privacy

Protecting sensitive and classified data stored in database management systems requires mea-sures beyond controlling access to files managed by operating systems. An example in thiscontext is the problem of inference, which is the deduction of unauthorized information fromthe observation of authorized information - where unauthorized information is deduced fromthe legitimate responses. There is a lot of research work in the area of applying privacy protec-tion in the context of databases. In the medical field, a great deal of interest is in anonymizingtextual information. Sweeney’s pioneering work [Swe96] is based on removing the person-ally identifying information from the text so that the integrity of the information remainsintact even though the identity of the persons remains confidential. The problem in this caseis identification detection problem where identifiers of persons are detected and anonymized.Sweeney’s recognition methodology aims at detecting information that can personally iden-tify any person. One important issue is the definition of “personal information.” Is it thewhole text, the paragraph, the sentence, the phrase or only the word that denotes the identity?For tabular data, several techniques are proposed at the relation level. For example, the k-anonymization technique [Sam01] assumes that a relational table with a prime key that refersto a person is “personal information”. Its main concern is anonymizing entries in the table inorder to block any attempt to reach “identifiablity” that stems from these entries. Systems thatuse such techniques aim at protecting individual identifiable information and simultaneouslymaintaining the entity relationship in original data. Still, the definition in these works of “per-sonal information” is not clear. Implicitly, it is understood that the privacy aspect comes fromassociating the attribute name with the identifying key of the relation. Statistical Databasesaims at providing statistical information without compromising sensitive information aboutindividuals. However, statistical databases goal is to prevent disclosure of private informationand is limited to implied information. Agrawal et al. [AKX02] is first in proposing ‘Hippo-cratic’ database systems that put privacy as central concern. They articulate what it means fora database system to responsibly manage private information under its control. Nevertheless,Their proposed model can be considered as an extension of the relational database model. Itlacks modeling features that put privacy as a central concern of the conceptual schema.

Generally, in database design the conceptual schema encompass the enterprise’s view thatencompasses all types of information. We concentrate on building conceptual schema exclu-sively for private information. We envision a system where not only enterprises have ‘privateinformation’ databases but every individual has his/her own ‘private information’ databasethat includes his/her own private information and other’s private information possessed byhim/her. Our approach is comprehensive in terms of analyzing the overlapping between dif-ferent conceptual schemas. Suppose that we have one enterprise and 2000 individuals. Ourmodel is concerned with developing a framework of 2001 conceptual schemas and their sub-schemas. In the e-environment the corresponding (private) databases interact with each otherutilizing the knowledge in their schemas. Private information agents in all databases work onbehalf of their owners to facilitate private information transactions. For example, the agentof individual x accesses the database of the enterprise to update its owner’s private informa-tion, then the agent record in the individual’s database that such information is consented tothe enterprise’s database. Or, the agent of the enterprise communicates with the individual’sdatabase to verify that the private information it has about the individual, is consented.

1.3 Our Contribution

Our approach aims at developing a systematic methodology that proceeds from a workingdefinition of “private information” to a complete set of conceptual schemas that includesprivacy-based decomposition and constraints. We achieve this goal through:

Framework: This paper introduces a formalism to specify informational privacy assertionsbased on a theoretical foundation. We introduce a new definition of private informationand categories of this type of information to entangle issues of compound private in-formation (John and Mary use contraceptivesis ‘private’ information of bothJohnandMary). We also introduce a classification of relationships of “private information pieces”to its possessors and proprietors. The proprietor here refers to the person identified ininformation pieces.

Model: Our theoretical framework is applied to the restrictions and conditions of possession.Thus, the private information in possession of z can be classified according to whether thispossession is according to: consent/no-consent of the proprietor, legal/illegal possessionof private information, and awareness/no-awareness of the proprietor of private informa-tion of this possession.

1.4 Related Work

The comprehensiveness of our approach extends from the system’s level (e.g., conceptualschema design) to the specification level that includes functionalities of subsystems such asconstrains and policies. At the system level, J. Biskup introduced in his recent script [Bis05]a general approach for development of security preserving systems. According to his modelparticipantsin the information society include nearly every individual, group, institution, as-sociation or private company. Informational activities among participants must be in someway based ontrust. Orthogonally we distinguished between known and unknown servicesprovided[Gib05]. An individual is seen as an actor being involved in a large variety of differ-ent social roles including determining which personal information he/she is willing to share.Since there are potentially conflicting interests, the design of a security system takes intoconsideration the specific needs and wishes of communities of participants. We visualize thegeneral architecture of this system as shown in Figure 1. Participants are threatened by certainenvironments and explicitly forbid services in other environments. Services are provided bya system in a selected environment. Participants may trust service provider(s) and require aservice. We may add other restrictions such as acquiring only trusted services.

The correctness properties of a secure system may be specified by three path constraintsin the security preserving system:

• A security system isreliable correct if all the participants’ requests can be handled byservices in which the participant has trusts.

• The system is aconfinesystem if no illicit services pop up with services used.

• The system is atrustedsystem if whenever a service pops up with the requested services,it is whitelisted.

Privacy system is not a subsystem of the security system. Some security measures maycompromise privacy protection as in network monitoring. Nevertheless, the security toolsused by a security system are very important for any privacy system since they can provide

¾

k

+

6

?

ThreatenBy

Requires

k

j

6

BoundWith

6

¾ -ProvidedBy

¾

-Checked6

Forbidden

Y

Whitelisted

?

TrustsIn

System

Environment

Service

Participant

Known

j

¾

MalwareService

¼

DisclosureLegislation

ª

ProsecutedService

Y

Figure 1: The structure of a security system model.

mechanisms to facilitate the privacy aspects of a system. Generally, data security involvesprotecting the information itself against various risks, such as the risks of being accessed ormodified by unauthorized persons. ‘Data security’ is not an aspect of ‘privacy protection’unless the involved data represents ‘private information’. Consequently, in our model partic-ipants in the ‘private information society’ include every individual and enterprise. This ‘so-ciety’ could be a hospital and its patients or it could be the whole society with all individualsand enterprises participating in private information exchanges.

At the technicalities level, there is a great deal of work in the area of protecting privateinformation. In authentication systems (e.g., Microsoft Passport) the private information isgenerally limited to identification/contact information. Some published works propose agentsthat are trusted by a user to store and make available private information such as user pro-files, other published works propose vocabularies for composing policies to allow or denyaccess to the private information [Lee02]. The Platform for Privacy Preferences (P3P) hasprovided tools and services that improve trust and offer an automated way for users to gainmore control over the use of their private information. APPEL (A P3P Preference ExchangeLanguage) can be used by the user agent to make automated and semi-automated decisionsregarding the acceptance of privacy policies from P3P enabled Web sites. P3P enhancementsalso allow negotiating for a different privacy policy that can be the used in any subsequentrelease of private information. Recent works in this field address semantic issues for privacymanagement. It is pointed out that a standard method of exchanging privacy policies (a pri-vacy ontology) is needed for the Semantic Web [KHM02, TDT04]. P3P Project extensionsallow data and conditions to be expressed in an RDF privacy policy [W3C02]. There are alsoseveral projects that exploit the development of privacy protection agents using semantic webtechnology and the W3C’s Platform for Privacy Preference protocol [Gre02].

These works lack an encompassing model for private information databases. This situa-tion is similar to if we had relational constraints, operations, policies, etc. without having theunderling relational database model. A basic step in developing a private information modelis building ontology to identify general types of private information. Our proposed ontologyprovides a deeper level of meaning of sub-categorization of private information. For exam-ple, these general types of private information are used in analyzing the relationship betweenprivacy and ethics [AF05b] and in refining the notion of anonymity in the context of private

information [AF05a].

1.5 Problems Found In A Privacy Project

Private information includes sensitive information that many people consider it deserving thestrongest protection. We give here one case related to health information. The collection andprocessing of medical information have witnessed great changes since the early 90’s. Thesetting for information began to shift quickly from manual forms to electronic medium. Thishas raised concerns about protecting the privacy of medical records.

The German government issued in 2002 the health card project as a competitive projectbetween the German states. The Schleswig-Holstein health card project is considered themost advanced [LSH]. All relevant patient data are stored on the SIM1 of a health identitycard. The data must be protected by one pin and, additionally, might be centrally stored. Datato be stored on the card consist of personal health condition, all data associated with medicaltreatment, physician visits, and specific disease and disorder information. Moreover, accesskeys are provided to read the full medical record prepared by doctors.

The German health card project is currently based on a simpleaccess modelthat consistsof:

Assigning views to each rolesuch as the pharmacist view, and

Securing and encrypting information based on pin codesmanaged by patients.

Thestorage modelused in the Schleswig-Holstein is based on:

Central storage of all relevant information that is accessible by everybody who has the ac-cess portfolio, and

Local partial storage of any recent information on the personal health card of each patient.

The patient information is accessible by those who are permitted to access it either byusing the health card of the patient directly or by a pin number provided by the patient andpointer to the central storage.

We regard these models to be not appropriately designed to handle private information.They are not ‘private information models’ but general database models designed for any typeof data such as inventory data, maintenance data, budget data etc. This generality may causedifficulties in controlling the flow of private information. For example, once information hasbeen retrieved, the patient has no control on, or even knowledge of, its distribution. In ourcase we envision cooperating among private information databases with their software agentsthat check each other and report abnormal situations. A person can examine his/her privateinformation in an enterprise just as he/she can check his/her account in a bank.

2 Infons Owned by Agents

2.1 Infons of Agents

Infonshave been introduced by [Dev91], to represent possible facts and are extensively usedin situation theory [She96]. The theory of infons can be understood as a generalized theory of

1SIM=Subscriber Identity Module, a chip with a processor and some memory. SIMs are typically used foruser identification, encryption and data storage.

notions introduced in [Kau67]. They are less rigid than concepts considered in [GW98]. Anexample of an infon might be the predicatePatient(Bernhard, Thalheim,...,100352422728)orthe dual (negated) predicate¬ Village(Dresden,Saxony). Infons can be composed of infons,e.g., the infonPossesses(A100352422728,¬ Village(Dresden,Saxony))which says that the agentA100352422728 possesses the infon¬ Village(Dresden,Saxony).

An infon is a discrete item of information and may be parametric. Theparametersareobjects, and the so-calledanchorsassign these objects such as agents to parameters. Anactionresults in changing many infons in the world, and the change in an infon is essentiallydependent on the situation where the action occurs.Primary infon setsI are (temporary,epistemic) subsets of the set of all infons with the restriction that all dual infons (same infonswith different polarity) also belong to I and that all instantiations of parameters of an infonI

are inI. More formally the second condition says that forA ∈ I and an anchorf the infonA(f) is obtained by replacing each parameterx ∈ (para(A) ∩ dom(f)) by the objectf(x)in A.Infons not belonging to a primary infon set are called secondary.

An infon constraint relationy is a subset of the Cartesian product of the set of all infonsand the set of all secondary infons. We may use [Kau67] to develop a general logic of infons.Infons can be ordered by the generalization/specialization orderA 4 B specifying thatA isat least as specific asB. Similarly, < is the opposite relation. The relationu specifies thattwo infons are similar. We can now derive operations:

Homogeneity of two infons defines the relationA∃e B := ∃X(A < X ∧ B < X), i.e. two

infons can be homogenized if a more specific infonX exists.

Inhomogeneity of two infons is the opposite, i.e.,A∃6e B := ¬∃X(A < X ∧B < X).

Compatibility of two infons requires the existence of a more general infon, i.e.,A∃d B :=

∃X(X < A ∧X < B).

Compatibility of two infons is given throughA∃6d B := ¬∃X(X < A ∧X < B).

Derived predicates are

divergencyg :=∃e ∧

∃6d

isolation!:=∃6e ∧

∃6d

potential homogenizabilityG:=∃e ∧ ∃

d ∧ 6< ∧ 64 and

heterogeneityf :=∃d ∧

∃6e .

We may directly derive a number of general laws and other operators:

• ` A∃e B ↔ ∃x∀y(x < y → (A < y ∧B < y))

• ` A∃d B ↔ ∃x∀y(x 4 y → (A 4 y ∧B 4 y))

• Product: C = A ¡ B := ∀Y (C < Y ↔ (A < Y ∧B < Y )))

• Sum: C = A ¢ B := ∀Y (C 4 Y ↔ (A 4 Y ∧B 4 Y ))

• Thenegation specifies the negation of all properties of the infon but not the infon itself:

B = A := ∀x(x < B ↔ x∃6d A).

• Thedifference between two infons is given through all those properties that are containedin the first infons but form an infon that is incompatible with the second infon:

C = A ¯ B := ∀x(C < x ↔ (A < x ↔ B∃6d x))

This general logic and general computation theory can be used to infer new infons based onthe set of primary infons.

AgentsA from a general agent setZ are divided into two disjoint sets:individuals V

and non-individuals N. An individual represents a natural person while a non-individualrepresents an artifical person like a company, a government agency, etc.

We may, furthermore, model that an infon belongs to an individual or agent by using thegeneral predicates. The relationship between infon and the setsV andN is categorized asfollows:

• Possesses is a relation between members inZ and primary infons. Possesses(z ∈ Z, f)means that infonf is possessed byz. For example, an individual may possess privateinformation of another individual or, a company may have in its database, private infor-mation of someone.

• Knows is a relation between individuals inZ and primary infons. Knows(v ∈ V, f)means thatv has knowledge thatf is in possession ofz ∈ Z. The predicate can becombined with itself, for instance, we can stateKnows(A100352422728,Possesses(A100352422729,¬ Village(Dresden,Saxony)))that is,A100352422728 KnowsthatA100352422729 possesses the misinformationVillage(Dresden,Saxony). Also,Knows(A180753, Knows(A100352422728,Possesses(A100352422729,¬ Village(Dresden,Saxony)))).

• Belongs is a relation between entities inZ and primary infons. Belongs(v ∈ V, f) meansthatv is a referent inf . For example, iff is John is an alcoholic, thenf “belongs” to John.The infonf is a private information assertion that identifies John, hence, Belongs(John ,f).

Infons are similar to memes discussed in [Bla99]. Memes are the units of cultural evolutionand selection. They can be folded and be used for derivations. We will use situation theoryfor development of a theory of information flow. This paper focuses on infons that representprivate information.

2.2 Private Infons

We propose anInformation Privacy Model (IPM) that focuses on linguistic forms of privateinformation taking infons as its basic components. A ‘model’ here refers to abstractions rep-resenting the knowledge, organization, expressions, and constraints acquired from the worldaround us. The realization of this model means introducing a set of rules and data structuresfor which the rules are true. The model in this case, is formed from certain graphs, calledschemata, that serve as patterns or frames for the model. The schema is ‘conceptual’ in thesense that, it represents a ‘mental’ model that is built from concepts and conceptual rela-tions. ’Language’ is the main vehicle that describes entities, actions and states in the domainof knowledge, which in our case is informational privacy. Linguistic elements will be ourstarting point in identifying the meaning of ‘private’ information.

Infons are categorized according to the number of their referents as follows:

Zero infon is an infon that has no referent that signifies a single individual (person)A ∈ V.For example,Spare part number 54321 is in slot a-2, is a zero infon because it doesnot refer to a person. The zero infon is not private information because it refers to non-individual object inN. Some zero infons may be embedded into private information. Forexample,This dog with collar belongs to Johnembeds the zero infonThe dog has a collar,and the non-zero assertionJohn has a dog.

Atomic infon is an infon that has a single referent that signifies a single individualA ∈ V.

Compound infon is an infon that has more than one referent that signifies individuals inV.

Let A be an infon. IfA is true thenA is said to beinformation . Consequently, there arezero information, atomic information, andcompound informationaccording to the numberof the referents. Atomic (compound) information becomesprivate if it refers to identifiableindividual(s).

Private information is also related to who possesses it. A single piece of atomic privateinformation may have many possessors; where its proprietor (i.e., the referent in the privateinformation assertion) may or may not be among them. Atomic infons can be possessed byany agent inZ. Individuals can have private information of other individuals. Companiesand government agencies can possess a great deal of private information about individuals.“Ownership” of atomic private information is limited in IPM to the subject of the assertion,i.e., the individual about whom the atomic private information refers. IfA is atomic privateinformation ofA ∈ V; i.e.,A is its subject, thenA is proprietaryprivate information ofAandA is its proprietor.

Every piece of private information has its proprietor. A proprietor of private informationmay or may not be its possessor and vice versa. Individuals can be proprietors or possessors ofprivate information; however, non-individuals can only be possessors of private information.The notion of proprietorship here is different from the legal concept of ownership. The ‘legalowning’ of a thing is equated with the exclusive possession of this thing with the right totransfer this ownership of the thing to others. “Proprietorship” of private information is non-transferable in the absolute sense. Others may possess or (legally) own it but they are neverits proprietors (i.e., it cannot become their proprietary data).

Two or more individuals “have” the same piece of compound assertion when each indi-vidual has at least one atomic assertion embedded into the compound assertion. For example,John, Jim and Alice hate each otheris a compound assertion ofJohn, Jim,andAlice. It em-beds the atomic assertionsSomeone hates someone, wheresomeonecan beJohn, Jim,orAlice. These compound assertions can be represented by the three atomic assertions and themeta-assertion that states that they are components of a single compound assertion. In logic,we have the predicateshates(John, y), hates(Jim, x),andhates(Alice, z)that are mapped to thepredicatehates(x, y, z) with objectsJohn, Jim,Alice. It is not possible that two individ-uals have identical atomic private information because simply they have different identities.Atomic private information is the “source” of privacy. Compound private information is “pri-vate” because it embeds atomic private information. Also, the concept ofproprietorshipisapplied to compound private information, which represents ‘shared proprietorship’ but notnecessarily shared possession or ‘knowing’.

2.3 Reducing Compound Infons to Atomic Infons

A piece of compound private information is not a collection of atomic private information.Compound private infons are fundamental structures obtainable from relations and individu-als. The infonInLove(A1,A2) does not have the same ’collectivity’ or compositionality as theinfonsIn(A1, London)andIn(A2, London). The latter is pseudo (not real) compound privateinformation. It is a collection of the atomic private information. The structure of compoundprivate information is important if we are interested, not only in breaking up the compound as-sertion into its embedded atomic assertions, but also in reconstructing the original compoundassertion. For example,John, Jim and Alice hate each othercan be reconstructed uniquelyfrom its atomic assertions, while the pseudo compound assertionJohn and Jim hates Aliceisnot. Notice that the later embeds the atomic assertion x andsomeone hates someone.

A compound infon isreducibleto a set of atomic infons but it has more than that. The‘compound’ characterization refers to compound identities. If the atomic private informa-tion InLove(A1, x) is composed in the compound private informationInLove(A1,A2) thenthe possessor of the remaining part,InLove(y,A2), has no private information of A1. If theinfon John and Alice are in loveis partially anonymized and released asSomeone and Al-ice are in love, then no private information of John is released. That is the reason that wehave concentrated on atomic private information. Atomic infons are “pure” private informa-tion while compound information is not proprietary information of a single individual. It isshared privacy, thus its control is shared among its proprietors. Nevertheless, “pure” com-pound information (the part that connects the resultant atomic infons) is an essential part ofprivacy-based databases.

Suppose that we have the compound private infonA(A1,A2, ...,An) whereA1, A2, ...,An refer to different identifiable individuals (e.g., hates(John, Jim, Alice). Privacy-reducibilityof A(A1,A2, ...,An) refers to producingn atomic private infons and the

zero infon: Infon 1 ¢ Infon 2 ¢ ... ¢ Infon n .For example,John, Jim and Alice hate each otherembeds the atomic assertionsx hates some-one, wherex can be John, Jim, or Alice and the meta-assertion that states that they are com-ponents of a single compound assertion. The process of breaking up the compound infon toits atomic infons is a straightforward procedure. It can be described as follows: For eachAj ,produce its atomic private infon by replacing allAi (i 6= j) in A(A1,A2, ...,An) by the non-identifiable description ofAi. Additionally, we introduce the zero-information meta-infondescribed previously. Notice that the zero-information meta-infon is a zero infon because itrefers to assertions not individuals.

Thus, we have isolated the private information of each individual and at the same timehave preserved the “possibility” of recovering any compound private information. In the re-strictive structure of databases, reconstructing the original compound private information re-quires access to the n + 1 databases (n atomic infons plus one zero infon). For example,consider the relational schema MARRIED(HUSBAND, WIFE), WIFE-INFORM(NAME,AGE), and HUSBAND-INFORM(NAME, AGE). The first table contains zero privacy infor-mation that links tuples in the other two ’private information’ relations. So the original com-pound infonJohn whose age is 40 is married to Alice whose age is 30can be represented bythe atomic infons: (1)(John whose age is 40) is married to (someone whose age is 30)and (2)(Someone whose age is 40) is married to (Alice whose age is 30). MARRIED(HUSBAND,WIFE) includes exclusively pointers and releasing it does not compromise the privacy of anyhusband or wife in the database. For example, if John is the 4th tuple in HUSBAND-INFORM

and Alice is the 9th tuple in WIFE-INFORM, the tuple (4, 9) can be one way of implementingthe zero privacy information that links John and Alice.

The methodology of syntactical construction of the original assertion is not of centralconcern here. Whether the resultant set of atomic assertions is semantically equivalent tothe original one is an interesting problem. The reduction process of the original compoundprivate infon is utilized here to identify “privacy centers” and use these ‘centers’ in differentprivacy related applications.

2.4 Possession and Property of Infons

Every individual has his/her stock of private information. Some of this information is his/herown and some is in his/her possession. In this section we study different types of atomicassertions associated with a single individual in order to identify their relationships to theproprietor. We divide the set into two disjoint sets of atomic assertions Individual.Proprietaryand Individual.Possession as shown in Figure 2. Each set is defined as follows:

Not know(the individual)

Not knownby other individuals

Shared with othersby contracts

Knownthrough consent

Public toothers

Known by other individuals

Known by individual

Proprietary infons Possession(infons of others)

Infons of individuals

Figure 2: The taxonomy of infons of an individual.

1. Possession: This is the set of pieces of atomic private information of the others that arein the possession of an individual. For example if individualA knows that individualA′

has cancer then this information is in the set Individual.Possession.A of A′.

2. Proprietary: This is the set of atomic private assertions (atomic infons) of the individualhim/herself. It has two categories:

(a) Not Know (NKnow): This is the set of atomic private information, which the pro-prietor does not know about it, e.g. results of medical analysis. This set is includedin the tree for completeness sake. We often assume that if the object Individual (as adata structure) represents an entity of type individual then this set should be empty.However Individual can be part of another schema, in this case NKnow may not beempty.

(b) Known: This is the set of atomic private information assertions (infons) that theproprietor does know about it. It includes two types of atomic private informationassertions as follows.

(b1) Not Known by other individuals: This is the set of atomic private informationassertions that are known only by their proprietor and not known by others.

(b2) Known by other individuals: This is the set of private information assertionsthat the individual knows that it is known by others (in possession of others). Itis divided into many sets of pieces of atomic information that are in possessionof subsets of others:

(b21) Infons that are shared with others by contracts. The contracting schemadepends on the individuals.

(b22) Infons that are shared with others: (1) with the consent of the individual or,(2) against his/her will. An example of the latter type is private information(e.g., names) of victims obtained from a publicly released police report.

(b23) Infons that are shared with everybody and are thus public.

Contractsare specified through the “who-how-whom-what-onwhat basis” frame of con-tracting. Contracts may be built using parametric secondary infons. The basis for contracts ofinformation sharing is usually another contract. We may envision that contracts use cases ofinformation sharing in the style of UK jurisprudence. The ‘who-whom’ specification mightuse a specification of collaboration between individuals or non-individuals. The style of in-formation sharing is based on a specification of workflows which might include messagepassing activities whenever an infon is used by an agent who is not its proprietor.

2.5 States of Possession of Infons

We have developed a general theory of infons, agents, possessions and property. Let ussharpen the requirements for a privacy enhanced information system. The general state ofpossession of infons is displayed in Figure 3.

State of possession Legality of possession

Consent of possession

Awareness of possession

-

6

¼

Figure 3: States of possession of infons monitored by the privacy enhanced system.

We distinguish three perspectives of possession:Legality of possessionthat ranges in the hierarchy of private information from proprietary

through Known by contract to Known illegal.

Awareness of possessionthat can be recorded for each individual.

Consent of possessionthat may be based on contracts, on consent or be none.

We will concern with non-individual entities or agents (companies, government agency, etc.)that possess private information about individuals. Each non-individual agent as ‘an enter-prise’. By our definition of private information an ’enterprise’ cannot be a proprietor of pri-vate information. We will use paths within the schemas to identify sets of atomic infons. For

instance,Az.Possession.Ax produces all private infons ofAx in possession ofAz.

The states of possession of private information by enterprises may be restricted as follows:

Awareness of the individual: This constraint indicates that the individual should be awareof any private infons in the possession of the enterprise. This fact can be embedded intothe conceptual schemas structures.

The consent of the individual: This constraint indicates that the individual should give his/her consent of any private information in the possession of an enterprise. The consentimplies awareness, however, awareness may not indicate consent. For example, privateinformation about an ex-patient may be in the possession of the hospital without his/herconsent.

Greedy deletion of information: This constraint indicates that any information, which isstored without the consent or without awareness of the individual must be deleted fromthe system.

Restrictions on visibility of information impact: This constraint concern implied informa-tion. An enterprise agent is, in general, able to draw an inference of what certain infor-mation holds if the agent knows the bearing of other information to the information theagent seeks. For instance, a conclusion could be drawn by a health insurance company ifa patient requests medicine for sexually transmitted diseases.

A typical situation of possession is displayed in Figure 4.

t

Consent

Known Not Known

No Consent

AV ... ... ...

Possession

AZ

Figure 4: Conceptual structure of private information with the notions of consent and awareness.AV denotes apossessor and t denotes an infon.

Additionally, this model allows representing other states of possession, e.g. illegal posses-sion. Consider the case of a police detective, sayAZ , who has authority to watch a suspect,sayAV , secretly. The collected private information of the suspectx would be stored in

AZ .Possession.AV .NConsent.NKnowwhere NConsent denotes the set of non-consented infons and NKnow denotes its subset ofinfons that the proprietor does not know that the detective possesses them.Now suppose that the detective forced the suspect to surrender his ID card. All informationin the ID card will be stored in

AZ .Possession.x.NConsent.Know

because the suspect, in this case, knows this fact.AV denotes a possessor andt denotes aninfon.

We notice here that this discussion assumes that we are modeling the state of privateinformation in the universe under consideration. Each entity in this universe has its own pri-vate information corpse of data classified according to our model. For example, if the universecontains two individuals and one enterprise, then the “universal” conceptual schema has threesub-schemas. One of the individuals may not keep track of his/her private information state.Still, he/she has in his/her possession private information of others, has his/her proprietary in-formation which includes information he/she knows that it is in possession of the enterprise,information in possession of the other individual illegally, etc.

2.6 The Model of Possession Management

Possession management can be supported by an information system that encapsulates theinformation obtained from other agents. We may envision distributed privacy enhanced in-formation systems and systems with a centralized storage engine. Since there is no conceptualdifference between the two approaches we concentrate in this paper on the centralized engine.The structure of the infon management schema2 is displayed in Figure 5.

Kind ofsharing

¾ -through⊕

Contract

µ

Consent

6

?

-Known byothers

Agent =Non-individual·∪ Individual

?

Individual

¾

6

possesses

6

Knownpossession

¾ Signifies

^

Infon

compound: card = (2,n)atomic: card = (1,1)

zero: card = (0,0)

¾

6

applies

Privacyclassification

schema

Information

]

true

6

Trivialinformation

derivable

Figure 5: The infon management schema for privacy support.

The database restricts the infons known by others to those which the individual knows.An infon belongs (signifies in the figure) to one individual (atomic infon), to a number ofindividuals (compound infon), or none (zero infon). True infons are information (i.e., theinformation type is a subtype of the infon type). Derivable information is considered to be

2The development of the database schema is based on the higher-order entity-relationship model [Tha00a]that supports co-design of structuring and functionality of information systems by a high-level specificationlanguage.

trivial depending on the derivation system. Individuals and non-individuals may possess in-fons which belong to an individual forming thus an association between thesignifiesrelation-ship types and either non-individuals or individuals. We may assume that each owned infonis also possessed by its proprietor (it may however not be the case in applications such asthe health card since some infons (e.g., having cancer) may be withheld from individuals).The possession may be known (recorded through thepropertyKnown class) or unknown.Known possessed infons may be known by other individuals or non-individuals dependingon whether the sharing of information is consented or contracted sharing. Additionally infonsmay be classified within a privacy classification schema.

3 Management of Infons of Individuals

Infon management is based on the separation of matters of concern that include the following:

Data are managed by the database systems of individuals and non-individuals. The databasesystems of the individuals is equipped with an export facility for data that might be pro-vided to other agents. The export is based on predefined private information schemasor views. The result of an export enactment is small units of content that includes datatogether with meta-data describing the data and its possible usage.

Infons are small units of content and are classified according to their truth and the applicableclassification schema.Compound private informationextends the infons of an agent.

Agents have their own profile [Tha00b] (consisting of private data (if applicable), accessrestrictions, and privacy and security profiles) and their own portfolio [Tha01] (consistingof permitted tasks, forbidden services, access rights, applicable contracts and consent).

Deliverables are generated by the privacy enhanced information system upon requests byagents.

3.1 The Model of Infon Possession Management

The playout of content is based on a view management system. This system binds the in-fons to individuals depending on the kind of possession, proprietorship, and the strategy fororchestration in the system. The general structure is shown in Figure 6.

The strategy for privacy orchestration is based on a workflow specification. Each work-flow step uses views that are defined in terms of infons. These views compile compoundprivate information that consists of two spheres of private information:1. Atomic private information embedded into compound private informationC. So in gen-

eral: C(AV1 ,AV2 , ...,AVn) Ã subsetof atom(AV1) ∧ subsetof atom(AV2) ∧ ...∧ subsetof atom(AVn).

For example, in the view of a husband we can find the atomic private information that heis married, date of marriage, marriage certificate number, etc. but the identity of the wifeis excluded.

2. Zero-information that links two or more atomic information in atomic databases.

Thus, in general an individual has:(A) Proprietary database: This database includes proprietary private information as described

previously.

applicablerules /

principles

stage / epistemic truth

proprietorship / identification / truth

Individual

Kind of privacy/possessionproperty

Strategy forprivacy

orchestration

Infony

¾

6

?

-Supportedusage

-Zeroprivacy infon

¾ Atomicprivacy infon

jShared

privacy infon

derived information

Figure 6: Views in infon possession management: Main data structures.

(B) Possession database: This database includes others’ private information in possession ofthe individual as described previously.

(C) Compound database: This zero-information database facilitates linking shared private in-formation as described previously.

Further, a non-individual has:(B) Possession database: This database includes others’ private information in possession of

the individual as described previously.

(C) Compound database: This zero-information database facilitates linking shared private in-formation as described previously.

3.2 System Support

The architecture of the envisioned enhanced privacy information system is displayed in Fig-ure 7.

Although any database management system could be used as a basis for an enhanced pri-vacy information system we chose the content management system CoreMedia SCT (SmartContent Technology) [Cor04] for the implementation of our experimental prototype. Core-Media SCT supports generation, maintenance and controlled delivery of complex contentstructures. The system components of CoreMedia SCT like the storage engine or the deliv-ery server are designed to support scaleable, highly performant, highly available, and secureinformation systems for a distributed collaboration of its users.

CoreMedia SCT repositories are used for storing the content. Due to the possibilities ofthe SCT document model and programming interface, state of the art, encryption technologycan be seamlessly integrated. Additionally, we propose an infon possession tracking system.

Content managed by the CoreMedia SCT might be the suite of encrypted infons, theworkflow content that manages agents, atomic information, the signification, the possession,the known possession, or the sharing of infons. CoreMedias playout facilities deliver thiscontent to individuals and non-individuals depending on the profile and portfolio of agents.

...

Content Management SystemPrivacy Enhanced Information System

Tracker

Filter

Pre-pro-cessorSCT Server

EncryptedDBS

SCT Server

EncryptedDBS

Infon Tracker

InfonPossessionTracking

DBS

--

¾¾¾

-?

?¾

Agent

request

deliverable

Figure 7: The general architecture of our privacy supporting system.

The preprocessor controls the legitimacy of requests issued by agents. It adds the portfolioand profile of the issuer to the request. Depending on the strategy for privacy orchestration,the extended request is issued to the content management system. The filter is based on theview depicted in Figure 7. The delivery to an agent is recorded in the content managementsystem.

3.3 Recording Possession of Infons

Within an enhanced health card project we separate six private information schemas: patient,hospital, doctor, pharmacist, insurance and information desk schemas. These schemas arelimited to private information and embeds in their structure information about proprietaryof, possession of, and knowledge of private information. The actual complete database mayexist in one system (e.g., hospital database) or may be scattered on different computers (e.g.,patient’s laptop, doctor’s laptop) or in-between situation.

All parties participate in this comprehensive picture of the patient’s private information. Itis a portion of a global picture of any individual’s private information. When a person intro-duces new data that requires the possession of his/her private information, the correspondinginfons, views and usage data are generated. The patient’s computer and the hospital’s systemcan exchange information and check each other according to their schemas.

This multi-view of private information that is designed according to possession, knowl-edge, etc. is not limited to enterprises but -in a comprehensive database- applies also to indi-viduals. Thus, the system, upon receiving a request to add new private informationAV .t toits database, would activate certain procedures to ensure thatAV is aware thatAV .t is now inthe possession ofAZ .

On his/her part, the individualAV can be permitted to accessAZ .Possession.AV to lookat all private information about him/her in possession ofAZ . So the relationship betweenAV andAZ is reciprocal with regard to possession of private information. Various scenarioscan be incorporated in this relationship with regard to updating the private data, correctingit, etc. In ideal situationAZ .Possession.AV should always be equal toAV .Known.AZ . Thus,the individual and the enterprise have identical copy of the private information of the indi-vidual that is in possession of the enterprise. This can also be applied for sub-schemas ofthe enterprise that contain portions of this private information. Several routines can be per-formed automatically on both sides, the proprietor and possessor, and appropriate reports ofdiscrepancies can be produced.

The enterprise schema ofAZ may have “hidden data” inAZ .Possession.NKnow that

includes private information that is legally hidden from the proprietor of that information.For example, in a hospital DB system, the patient may be aware ofAZ .Possession.Know.AV

but is not aware ofAZ .Possession.NKnow.AV .

4 Conclusion

This paper introduces a formalism to specify information privacy infons based on a theo-retical foundation. The resultant formalism is then applied to the notions of awareness ofpossession, consent, and certain known privacy rules. Current privacy research lacks suchformalism. The new formalism can benefit in two areas. First in introducing precise defi-nitions of informational privacy notions. It also, can be used as a base to develop a formaland informal specification language. Informal specification language can be used as a vehiclein specifying different privacy constrains and rules. Further work can develop a full formallanguage that can be used in privacy systems.

In this paper we report the findings, the constructs and the implementation for an enhancedhealth card project that is currently finalized [Fie04] in a project of the Kiel informationsystems engineering group. The experience we gained has shown that further development onthe basis of security meta-profiles, on patient information facilities, infon tracking functions,and encryption mechanisms is necessary. We have shown that in a protected environmentthese requirements can be satisfied. We are in doubt that a completely satisfying solutioncan be provided in open environments although most systems that can be envisioned or arecurrently used will be open systems.

Our current investigation are centered around development of reliable correct systemssimilar to [WLT05] by providing a framework that traces and protects users against ‘bad’ ser-vices displayed in Figure 1. We preferred closed privacy supporting systems. Alternatively,open privacy supporting systems may be developed using enforcement techniques [Tha00a]or information wallets [AF05b]. The change management for infons has been extended inorder to cope with changes from zero to private, from private to zero infons. The logics ofknown infons, possessed infons and not known infons can be extended to trusted, whitelisted,known, and forbidden services using modal epistemic intuitionistic logics. We plan to inves-tigate privacy keeping through noising.

References

[AF05a] S. S. Al-Fedaghi. A systematic approach to anonymity. In3rd Int. Workshop on Security in Infor-mation Systems WOSIS-2005, Miami, May, 2005.

[AF05b] S.S. Al-Fedaghi. The ’right to be let alone’ and private information. InProc. 7th Int. Conf. EnterpriseInformation Systems, Miami, 2005.

[AKX02] R. Srikant Agrawal, J. Kiernan, and Y. Xu. Hippocratic databases. InProc. 28th VLDB, pages143–154, 2002.

[Bis05] J. Biskup. Information systems security. Lecture script http://ls6-www.cs.uni-dortmund.de/issi/teaching/lectures/skript-sicherheit/, 2005.

[Bla99] S. Blackmore.The Meme Machine. Oxford University Press, Oxford, 1999.

[Cor04] CoreMedia. Homepage of the CoreMedia AG. http://www.coremedia.com, 2004.

[Dev91] K. Devlin. Logic and Information. Cambridge University Press, 1991.

[Fie04] G. Fiedler. Description of the health card development practicum. System development practicumcollocated with the program “Intelligent Information systems”, http://www.is.informatik.uni-kiel.de/∼fiedler/teaching/ws2005/iis/Praktikum.pdf, Oct. 2004.

[Gib05] S. Gibson. Spyware was inevitable.CACM, 48(8):37–40, August 2005.

[Gle96] J. Gleick. Behind closed doors; big brother is us.New York Times, Sept. 29 1996.

[Gre02] D. Green. When the web starts thinking for itself. http://www2.vnunet.com/Ebusinessadvisor/1137710,2002. 20-12-2002.

[GW98] B. Ganter and R. Wille.Formal concept analysis - Mathematical foundations. Springer, Berlin,1998.

[Kau67] R. Kauppi. Einfuhrung in die Theorie der Begriffssysteme.Acta Universitatis Tamperensis, Ser. A,Vol. 15, Tampereen yliopisto, Tampere, 1967.

[KHM02] A. Kim, L. J. Hoffman, and C. D. Martin. Building privacy into the semantic web: An ontologyneeded now. InSemantic Web Workshop, Hawaii, USA, 2002. http://semanticweb2002.aifb.uni-karlsruhe.de/proceedings/.

[Lee02] R. Lee. Personal data protection in the semantic web. ME Thesis, MIT, 2002.

[LSH] Landesregierung Schleswig Holstein. Project information Gesundheitskarte Schleswig-Holstein.http://www.gesundheitskarte-sh.de.

[Sam01] P. Samarati. Protecting respondents’ identities in microdata release.IEEE Transactions on Knowl-edge and Data Engineering, 13(6), November/December 2001.

[She96] J. Seligman and D. Westerstahl (eds). Logic, Language and Computation. CSLI Lecture Notes,Stanford, CSLI Publications, 1996.

[Swe96] L. Sweeney. Replacing personally-identifying information in medical records, the scrub system.Journal of the American Medical Informatics Assoc., pages 333–337, 1996.

[TDT04] A. Tumer, A. Dogac, and I. H. Toroslul. A semantic-based user privacy protection frameworkfor web services. http://www.srdc.metu.edu.tr/webpage/publications/2004/TumerDogacToroslu.pdf,2004.

[Tha00a] B. Thalheim.Entity-relationship modeling – Foundations of database technology. Springer, Berlin,2000. See also http://www.is.informatik.uni-kiel.de/∼thalheim/HERM.htm.

[Tha00b] B. Thalheim. The person, organization, product, production, ordering, delivery, invoice, accounting,budgeting and human resources pattern in database design. Technical Report Preprint I-07-2000,Brandenburg University of Technology at Cottbus, Institute of Computer Science, 2000. See also:http://www.is.informatik.uni-kiel.de/∼thalheim/slides.htm.

[Tha01] B. Thalheim. Abstraction layers in database structuring: The star, snowflake and hierarchi-cal structuring. Technical Report Preprint I-13-2001, Brandenburg University of Technol-ogy at Cottbus, Institute of Computer Science, 2001. See also: http://www.is.informatik.uni-kiel.de/∼thalheim/slides.htm.

[W3C02] W3C. W3C Note 25, An RDF schema for P3P. http://www.w3.org/TR/2002/NOTE-p3p-rdfschema-20020125/, January 2002.

[Wes67] A.F. Westin.Privacy and Freedom. Atheneum, New York, 1967.

[WLT05] M. Warkentin, X. Luo, and G.F. Templeton. A framework for spyware assessment.CACM, 48(8):79–84, August 2005.

Acknowledgement. The authors thank the reviewers for their comments and Joachim Biskup forhis advices that led to improvement of the paper.

LIFE CASESAn Approach to Address Pragmatics in the Design of Web Information Systems

Klaus-Dieter ScheweMassey University, Department of Information Systems & Information Science Research Centre, Palmerston North, New Zealand

[email protected]

Bernhard ThalheimChristian Albrechts University Kiel, Department of Computer Science, 24098 Kiel, Germany

[email protected]

Keywords: storyboarding, pragmatics, life case, application domain description

Abstract: On a high level of abstraction a Web Information System (WIS) can be described by a storyboard, which inan abstract way specifies who will be using the system, in which way and for which goals. While syntax andsemantics of storyboarding has been well explored, its pragmatics has not. This paper contributes the firststep towards closing this gap. For this we present life cases, which capture observations of user behaviour inreality. We discuss the facets of life cases and present a semi-formal way for their documentation. Life casescan be used in a pragmatic way to specify a story space, which is an important component of a storyboard.

1 Introduction

A Web Information System (WIS) is an informa-tion system that can be accessed through the world-wide-web. On a high level of abstraction a WIS can bedescribed by a storyboard, which in an abstract wayspecifies who will be using the system, in which wayand for which goals. In a nutshell, a storyboard con-sists of three parts:• a story space, which itself consists of a hierarchy

of labelled directed graphs called scenarios, oneof which is the main scenario, whereas the oth-ers define the details of scenes, i.e. nodes in ahigher scenario, and a plot that is specified by anassignment-free process, in which the basic ac-tions correspond to the labels of edges in the sce-narios,

• a set of actors, i.e. abstractions of user groups thatare defined by roles, which determine obligationsand rights, and user profiles, which determine userpreferences,

• and a set of tasks that are associated with goalsthe users may have.In addition, there are many constraints compris-

ing static, dynamic and deontic constraints for pre-and postconditions, triggering and enabling events,rights and obligations of roles, preference rules for

user types, and other dependencies on the plot.While syntax and semantics of storyboarding has

been well explored, its pragmatics apart from the useof metaphors (Thalheim and Dusterhoft, 2000) hasnot. Pragmatics is part of semiotics, which is con-cerned with the relationship between signs, seman-tic concepts and things of reality. Main branches ofsemiotics are syntactics, which is concerned with thesyntax, i.e. the construction of the language, seman-tics, which is concerned with the interpretation of thewords of the language, and pragmatics, which is con-cerned with the current use of utterances by the userand context of words for the user. Pragmatics permitsthe use of a variety of semantics depending on theuser, the application and the technical environment.

This paper contributes the first step towards prag-matics of storyboarding. For this we present lifecases, which capture observations of user behaviourin reality. The idea is that these observations give riseto both a concrete scenario for the usage of the WISincluding roles and user profiles. We then derive thecandidate scenarios by abstraction. Further integra-tion and refinement of these scenarios gives rise to thestory space. We deal with the problem of extractinguser models in a separate article. The third componentof the storyboard, the tasks, has already been subjectof strategic modelling. The life cases permit the re-finement and further decomposition of these tasks.

2 Related Work

Most methods for web application engineer-ing such as OOHDM (Schwabe and Rossi, 1998),WebML (Ceri et al., 2003), HERA (Houben et al.,2003), WSDM (De Troyer and Leune, 1998) and vari-ants of UML (Conallen, 2003; Lowe et al., 2002) paylittle or even no attention to high-level modelling. Therationale underlying our work is that this is far too lit-tle to capture strategic and usage issues of WISs. Theintegration of goals and soft goals into the informa-tion systems development process has been proposedby (Mylopoulos et al., 2000; Giorgini et al., 2002).The detailed distinction of intentions as targets, ob-jects, objectives and aims is based on linguistics. Theintegration of the temporal dimension is necessary be-cause of the information systems context. The ex-tension by the representational dimensions has beenmade in order to specify aspects of WISs.

Life cases extend and formalise scenarios usedin software engineering and user modelling (Courageand Baxter, 2005). Early work like already discov-ered that human computer interfaces can be devel-oped in techniques of movie writing or play devel-opment (Vale, 1982). Life cases have already beenenvisioned in (Carroll, 1991). Scenarios as definedin software engineering are examples of interactionsessions. This kind of scenario starts with an outlineof the interaction, and during requirements elicitation,details are added to create a complete description ofinteraction. They are specified by a general descrip-tion of the start and termination states of the system,a description of the normal flow of events, and a de-scription of concurrent events (Sommerville, 2004).Later scenario research has been integrated into ag-ile programming. Customer involvement is one of therequirement of agile methods. Customers should beintegrated as early as only possible into the develop-ment process (Ambler, 2002). Both approaches are tomuch oriented towards systems and do not considerlife cases as we do. Scenario development has beenapplied to development of websites in (Rosenfeld andMorville, 1998).

In (Harel and Marelly, 2003) life cases were in-tegrated into the entire software engineering pro-cess. Recently, software engineering research de-veloped an engineering approach to simple life case.Business use cases (Robertson and Robertson, 2006)generalise the requirements shell of (Robertson andRobertson, 1999) that is based on verbal descriptionof event/use cases, requirement types, the rationale,originator, fit criterion, customer (dis)satisfaction,supporting materials, and the history. Our life casespecification is not as complex as these business use

cases. They combine intention, users, actors, con-straints/assumptions/scope or context, tasks, migra-tion, risks, costs, documentation, testing, and require-ments for functions, data, look and feel, usability,humanity, operating, maintenance, support, security,culture, politics, legal and performance. We concen-trate on the requirements the user has as such.

3 Facets of Intention

The description of intention is based on a clear un-derstanding of aims and targets of the WIS including aspecification of long-range and short-term targets, ex-pected visitors, characteristics of this audience, tasksperformed by the users, necessary and unnecessarycontent, and finally an understanding of restrictionsof usage.

Utilisation scenarios are developed on the basis ofintentions. An intention specifies what one purposesto accomplish or do, i.e. one has in mind to do orbring about. It has four facets that are based on thegeneral characteristics of WISs:Purpose facet: The purpose of stakeholders speci-

fies an anticipated outcome that is intended or thatguides the planned actions. It may be based ontwo additional pieces of information: The aimsspecify what is intended to be attained and what isbelieved to be attainable. The objectives are moregeneral than the aims. They specify something to-ward which an effort is directed, e.g. goals or endsof an action.The purpose is already specified at the strategiclayer. It depends on the audience intended for theWIS, and is influenced by the mission that is de-termined by the WIS provider.

Intent facet: The intent suggests a clearer formula-tion or greater deliberateness. It distinguishes be-tween the following two aspects: The targets ofstakeholders specify the steps of a plan and its ter-mination or satisfaction conditions. The object ofstakeholders is related to wishes or needs of users,and specifies an effort or activity of a user in orderto satisfy the need.The intent facet is related to tasks the user wantsto accomplish. The intent may be ordered intomajor intents specifying the main uses of the sys-tem and minor intents that may be only partiallyof interest. Intents may be generalized to themesthat represent classes of intents.

Time facet: The time facet is used for specificationof the general time restrictions such as the design,which implies a more carefully calculated plan,

and the end, which stresses the intended effect ofan action, often in distinction or contrast to theaction or means as such. Time facets may be verygeneral. In this case, we use occasions to repre-sent an entire class of time frames.

Representation facet: Intentions are described orannotated through utterances, words or pictures.The word representation is related to word fieldsused in the strategic model. The icon representa-tion is based on metaphors. Word fields may bespecialised to concept fields discussed later in thischapter. Representation is deeply dependent onthe cultural environment and the community thatuses the WIS. Intentions can be supported by pro-viding stimuli that rouse or incite activity.Intentions may be restricted by a scope. The scope

allows to concentrate on the main aspects. Typicalrestrictions are the cultural environment, education orother profile properties of potential users, or specifictime facets for utilisation of the WIS.

The first two facets of intention have a generalform (objective, object) and a more concrete form(aim, target). The purpose facet depends on the mis-sion and the audience, whereas the intent facet de-pends on the tasks. Therefore, the first facet specifiesthe ‘what’, the second the ‘how’, and the third facetthe ‘when’ of an intention. We may either concentrateon a more general specification or a more concreteone.

The different facets may be considered separatelyor altogether in a condensed form. The detailed con-sideration is necessary, whenever a fastidious audi-ence requires sophisticated content. High demandscome into consideration due to the content provided,the community that must be satisfied, the sophisti-cated functionality required for the WIS, or the highattention the WIS gains.

Example 3.1 The purpose facet is often consideredto cover ‘soft intentions’ or by ‘business rules’. Inan information service a user may be interested orbecoming more interested in some content. The intentfacet is different and mainly driven by tasks the usertries to solve.

Similarly, we may derive a number of intentions auser has in mind whenever s/he visits an edutainmentsite:Aim: An aim of an edutainment user may be to ob-

tain a certificate that proofs the success of learn-ing. Aims of providers of edutainment sites mightalso be binding the learner to some products suchas the software of a supporter of the website. Typi-cal general aims within an edutainment site are togrant equal rights to everybody; nobody shouldhave higher rights than other learners.

Objectives: Typical objective of using an edutain-ment site are greater ease of learning, greaterpleasure or satisfaction during leraning, andmore fun. Another general objective is secu-rity and privacy. Edutainment applications alsohost confidential information, e.g. information onprogress and errors. The learners need to be sureof the security and privacy of their data. Theyshould be informed of the security precautions.The audience of an edutainment site may be rather

unspecific or more specific such as students of a col-lege or analysts of a bank.

The mission of an edutainment site is to sup-port learning by providing easy-to-grasp knowledge.At the same time, the provider may be interestedin increased visitor-to-customer conversion rate, in-creased number of returning customers, and in-creased revenue.

The intent is related to the more concrete tasks auser has in mind while visiting a WIS.

Example 3.2 Intents come directly from analysingthe needs and the demands of users. Some possibletasks a user may want to accomplish in an edutain-ment site are the following:• A user realises that certain knowledge or infor-

mation is necessary for solving a task. For in-stance, an analyst of a bank wants to know whatthe changes are in the customer community thatled to a rise of faulty credits.

• A student in a college needs to know methods foranalysing data. The student is interested in a datamining course that provides material on his/hereducational level, permits learning the content in-teractively, and is comparable to the material thestudent is currently working with in the college.Possible intents in an edutainment site are the fol-

lowing:Objects: There are a number of objects such as

faster task completion, successful completion ofmore tasks, or commission of fewer errors.

Targets: In the bank analyst case, the analyst needsto know data mining methods, to capture theachievements and the disadvantages and pitfallsof such methods.

The themes in the bank analyst case could be the in-terest in learning association methods, preprocessingof data, and prediction methods.

The time facet represents general time restrictionssuch as the time or the interval for visits of the WIS,the time and the interval of repeated visits, or the tem-porality that may force a user to leave the site. The

representation facet represents the flavour or atmo-sphere of a site, which is largely determined by theother three facets.

The set of intentions we should consider may berather large. Moreover, the faceted representationmay become too difficult to manage and to satisfy.The order we may use depends on the audience andon the provider. The audience is oriented towardssolving tasks. The provider has a ‘mission’. We canuse these two restrictions to figure out which kind ofwebsite supports this profile, to harmonize our under-standing with the corporate identity, to order the targetrealisation (short-term, long-term), and finally to de-velop an understanding how the site will look like intwo years from now on.

Example 3.3 The intention prepare for a visit isbased on a number of intents such as addressing vis-itors beforehand for some purpose, use, or activity.It includes the aim to put the visitor of the WIS in aproper state of mind. A task associated with prepara-tion may be to work out the details of a plan in ad-vance. The task may be extended by putting piecesof information together into a compound form orpreparing a report. The time facet may range from‘now’ until ‘next opportunity’. Typical metaphorssupporting this intention are baskets, descriptions,and cultural journals.

The intention prepare for a cinema visit extendsthe intention of prepare for a visit by a certain content,a refinement of the time facet to the next possible visit,and a refinement of the purpose facet now targeting atentertainment.

We can combine the description of intentions in asemi-formal way as follows. The items in the list areoptional except the first one.Intention space : 〈intention name〉Purpose : 〈outcome description〉

Aims : 〈list of aims〉Objectives : 〈list of objectives〉

Intents : 〈outcome description〉Targets : 〈list of weighted targets〉Objects : 〈list of weighted objects〉Themes : 〈class of intents〉

Time : 〈outcome description〉Design : 〈general flow〉End : 〈effects, termination conditions〉Occasion : 〈list of objectives〉

Presentation : 〈general style guide〉Atmosphere : 〈general description of

atmosphere〉Metaphors : 〈list of metaphors〉

Based On : 〈tasks, audience, mission, goal〉

4 Life Cases

Life cases allow to overcome the informationoverload and lost in the hyperspace syndromes typ-ically observed for WISs. For completion of tasksusers need the right kind of data at the right momentof time, in the right dose, of the right form, in thecomplete extent, and within the restrictions agreedupon in advance. Moreover, users are limited in theirabilities for verbalisation and digestion of data, andby their habits, practices, and cultural environment.

These limitations may cause intellectual overbur-dening of users. Most systems that require sophisti-cated learning courses for their exploration and uti-lization did not consider these limitations and did notcope with real life situations. The approach we usefor avoiding overload is based on observation of realapplications before developing the system.

We may extract life cases from observations in re-ality, which are very useful source, whenever a WISis going to be developed from scratch or is required toprovide a ‘natural’ behaviour. In the latter case usersare not required to learn the behaviour of the WIS.Instead, the user can continue using a ‘classical’ be-havioural pattern.

Example 4.1 As a motivating example let us considerthe life case relocation of a person, which consists of• the change of basic relocation data including the

possible removal of data on the old location,• the change of official documents such as the pass-

port,• the optional change of relation enhancements

such as the registration of pets, relocation of cars,

• the change of personal specific data such as fam-ily enhancements, or relationships to religiousbodies,

• the change of data for additional relocation an-nouncements such as tax, insurance changes, and

• specific additional tasks such as applications forhousing allowances.The person acts in the role of an issuer. We ob-

serve that relocation is enhanced by the profile of theissuer, by the specific tasks related to the relocation ofthe issuer, by specific laws and regulations, and by ad-vanced functionality required for associating the lifecase with other life cases.

The life case relocation consists of steps such aschange of address data, change of data for associatedpeople, change of registration data for cars, pets, etc.,change of specific data, e.g. data for public author-ity responsible for aliens, change of data for social

aid, etc. These steps are bundled together due to theirrelationship to one person and to one life case. Theassociations may be represented by adhesion of dif-ferent steps, e.g. representing the association of stepsby a hypergraph.

4.1 The Concept of Life Case

Life cases are characterized by:Observations: We are interested in the collection

and assessment of behaviour relating to the spe-cific application. This would typically involve anobservation of behaviour of users in real environ-ments, including a background check that relatesusage to intentions, goals or tasks.

Processes: This involves arranging all the actions ob-served in an application into a main logical andcoherent pattern. In some case, deviations of themain pattern must be modelled through excep-tions. In most cases, we can use parallel executionof independent actions.

Assessment: This involves the reconstruction of thesequence of actions and specific behaviour ofusers. This will aid in understanding the role eachindividual has within the story. It assists in devel-oping the user profile.

Individual profiles: A list of background includingphysical, and behavioural characteristics of indi-viduals is conducted. This list can also be usedfor deriving the most appropriate interview tech-nique we discuss below.

Interpersonal coherence: A variation in the activitywill relate to variations of other life cases.

Significance of time and place: The choices madealso depend on mobility, surrounding, and sched-ules of events of interest.

Characteristics of the life case: Individuals using aservice may be grouped by characteristics. Basedon this grouping a similar behaviour is observed.

Experience and skills: Individuals may have theirown experience with services provided in real lifeand thus use different behavioural pattern of ser-vice employment.

In general, life case studies are designed to producea picture of service employment that is as accurateas possible. Determining why, how, where, when andwhy a service is called using what data provides a bet-ter picture for utilisation scenario. As life cases areused for quality control, we must carefully record ourobservations. We either use a natural language speci-fication or a semi-formal one as described later.

Example 4.2 Let us consider the support of hotelsearch within an information service. In this casewe may observe the behaviour of individuals in travelagencies while seeking for hotels. We observe that inmost cases search based on associations is preferredover search by main properties such as name, addressor facilities. Associations may be of a large variety,e.g. convenience to reach a hotel, location in certainmaps, places of interest, or events that have causedthe search. Other search criteria may be bargain orbundled offers. At the same time we observe that ho-tel search is combined with other intentions of userssuch as visiting cultural institutions. It may dependon results for search of other individuals.

Another example of a life case study is the book-ing of train tickets depending on individuals, offers ofrailway companies, circumstances of individuals areusing trains, etc.

4.2 Life Case Development

Life cases may be developed and interpreted step bystep:1. The first step during life case collection is the sur-

vey of possible application cases we might con-sider. The observations could have more than onemeaning and may follow a variety of user-relatedgoals. In this case we consider the most likelymeaning.

2. The second step involves a deep assessment of thelife cases. We extract the different execution or-ders, the relationship among actions, and the rolesindividuals play these actions.

3. The third step extracts those life case characteris-tics that are distinguishing features and are rele-vant for time and location. At the same time wesearch for similarities within these life cases.

4. The final step is concerned with the characteriza-tion of potential users, their behavioural patterns,and their roles in various stages of the life case.Collectively, this information will produce a pic-

ture of the life case we are intending to support bya WIS. This may produce further life cases, or mayaid in reducing the amount of development. It mayresult in a prioritisation of life cases under consider-ation, assist in the linkage of potentially related lifecases, assist in assessing the potential of the WIS de-velopment, provide the WIS developers with relevantleads and strategies, and keep the WIS developmenton track and undistracted. These life case are mappedto scenarios in the sequel. The integration of scenar-ios can also be based on life cases.

Example 4.3 Let us consider life cases of an infor-mation service for a city or a region:• Attracting visitors: The information we are pro-

viding is based on some information need visitorsmay have. The life case follows those that we ob-serve during marketing activities.

• Inhabitants information: The life case is based onselected information chunks that may be of inter-est to individuals, an ordering of the correspond-ing available information, and a derivable per-sonal newspaper.

• Informing tourists: The life case is similar tothose observed in city information centres.

• Providing official city information to inhabitants:This life case follows the message board metaphorthat is used for newspaper information.During the development of city information ser-

vices such as the service www.cottbus.de we havemade a life case analysis for city information servicesand detected around 30 different life cases. We cancategorize these life cases by the content and infor-mation demand of individuals. We distinguish:• life cases related to tourist content for inhabitants

permanently living in the city, for inhabitants tem-porarily living in the city, for short-term touristsand business people on short term trip, for vaca-tionists planning a trip for more than 5 days, forteenagers with uncertain wishes, for seniors withparticular interests, for week-end visitors, for vis-itors of highlights, festivals, etc.;

• life cases related to official content for inhabitantson search through directory of public authority,for inhabitants on search for emergency cases,for inhabitants orienting themselves before apply-ing at public offices, for inhabitants interested inproblems of city management, etc.;

• life cases related to business content, e.g. for in-vestors considering engagement in the area.For the collection and development of life cases

it is normally a good idea to interview the personnelcurrently providing the service.

Life case should be checked against sufficy. Asthey may have a variety of traces, we add two stagesto life case analysis:Exploration: The actual life case is provided to WIS

customers and incorporated into their processes.Life case exploration can be conducted in normalenvironments of the user such as home or work.Then users can show the actions while they areexplaining their aims and targets.

Apprehension: Finally, cross checking of life casesand utilisation scenario is used for correction, ex-

tension and affirmation of the developed utilisa-tion scenarios.During life case elicitation and specification users

are confronted with sketches of scenarios. We askwhat users think about these conceptualisations. Thefeedback is used for the refinement of life cases. Wemay use affinity diagramming, in which case we ar-range the individual conceptions we discover on ablackboard, associate them, and discuss their rela-tionship to the general characteristics of WISs. An-other technique is based on card sorting similar tothe model-view-control cards used in software engi-neering. In this case cards represent simple life situa-tions. Their associations are then used for organisingthe conceptions. These sketches can also be used fordiscussing deviations from the normal case and forsearch of exceptional life cases. Instead of directingusers to specific life cases we can show them two ormore alternatives for the problem solution.

Life case analysis goes beyond task analysis. It issimple and easy to carry out, lightweight and straight-forward to understand, and yet quite accurate in iden-tifying the real demands users of a WIS might have.While observing real life cases and mapping them tolife cases that must be supported by the WIS we carryout a user-centered development. Additionally, wemay identify and resolve conflicting or competing in-tentions. These conflicts can be resolved on the ba-sis of life cases by accommodating both intentions,i.e. fulfilling the stakeholder intentions and support-ing the demand of users.

Besides observation of real life situations life casedetection can also been based on interview tech-niques. Research on artificial intelligence has also re-sulted in a number of interview techniques:• Unstructured interviews can be considered as an

informal and explorative conversation on goals auser is following and on tasks a user has to com-plete. Unstructured interviews observe the rulesthat are applied to brainstorming. All interrup-tions should be avoided. The questions askedmust be short and simple to answer and should beopen-ended questions. Interview partners shouldshare their thoughts and experiences. There isno judgement, confrontation or condescension.Users should not be lead toward a certain sce-nario. Unstructured interviews should only be in-terrupted if clarification is required. They needconsecutive feedback in order to give the inter-viewees the impression that the interviewer is lis-tening. While the interviewees are talking, every-thing that seems to be important is written downand used for later questions.

• Structured interviews are based on query plans.

These plans can be based on the general charac-teristics of WISs. We start with easy questionson data and main functions and continue with thelife cases of their utilization. Context and inten-tions are more difficult to capture. Structured in-terviews are also based on features, which can beshown to users for a rating of their importance.

• Life cases can also be detected by observing andcritically analysing products of competitors. Elic-itation of life cases from existing solutions isbased on specifications, results from interviewswith business users, excerpts from documents andspreadsheets, analyzed messaging and transac-tions, knowledge on the solutions that are cur-rently used, meta-data and context information onthe utilization within the current framework, andthird party information. As reasons for restric-tions cannot be captured, the copying of alreadyexisting solutions can only be used in exceptionalsituations.

• Users may also use protocols of “loud thinking”,in which case they are provided with a real-lifeproblem of a kind that they deal with during theirworking life, and asked to solve it. They imag-ine that they are solving the problem presentedto them. As they do so, they are required to de-scribe each step and the reasons for doing whatthey do. The transcript of their verbal account isthe protocol. In this case, they work and explaintheir current work. These protocols can be the ba-sis for capturing a scenario. This interview tech-nique should be combined with other interviewtechniques.

• There are other interview techniques that might beuseful for life case elicitation such as the ladder-ing or grid techniques. In these cases, a hierarchi-cal structure of the application domain is formedby asking questions designed to move up, down,and across the hierarchy.

4.3 Semi-Formal Representation of LifeCases

Although it is sufficient for life cases to be statedin natural language, we may use a semi-formalrepresentation instead using the following template:Life case : 〈life case name〉Characterisation : 〈outcome description〉

Tasks : 〈list of user tasks〉Problems : 〈list of problems〉Background : 〈general characterisation〉Objectives : 〈list of objectives〉

Life case flow : 〈general graphicaldescription〉

Milestones : 〈graph of milestones〉Content consumed : 〈consumed content items〉Content produced : 〈produced content items〉Themes : 〈class of intents〉

Figures : 〈actors list〉Expected profile : 〈general profile description〉Collaboration : 〈general collaboration

description〉Context : 〈general context

description〉Time : 〈temporality limitations〉Place : 〈assignment of places〉Legacy : 〈names of documents〉WIS : 〈general WIS context〉

Representation : 〈general behavior〉Approaches : 〈general description of

approaches〉This template captures the following components

of life cases:Characterisation: Life cases are characterised on the

basis of strategic issues, the problem statement,background and objectives for the life case, themethodology that is used for solving the life case,and by describing the basic modules that are usedfor solving the life case. The characterisation isharmonized with intentions, tasks and goals.

Life case flow: The life case flow combines the ob-servations we made, the processes involved, andthe data which are consumed or produced. Thelife case flow is mapped to a scenario.

Figures: We develop profiles, especially those of in-dividuals, as part of the WIS utilization portfolio,and interpersonal coherence specifications.

Context: Time and location is explicitly describedfor life cases. The applicability of life cases isrestricted by regulations, laws, and orders. Theserestrictions are seldom given in an explicit form.In addition, the context of life cases is given bythe provider, the intended audience, the utilizationhistory, and the availability of data due to the tech-nical environment. We also use this informationfor the context specification.

Requirements: Life cases are restricted by habits,general approaches, good practices, and boundaryconditions for their application. They presupposeexperiences and skills of the users involved.Note that life case we intent to support by a WIS

can be completely different in real life. Sometimes weneed a complete reorganisation of the business activi-ties. In this case we should not map the real life caseto a suite of associated scenarios, but rather envision

a better organisation of the tasks and goals and thenmap these to a new envisioned hypothetical life case.

Let us now outline briefly how life cases can beused in a pragmatic way to specify a story space.More precisely, we just want to derive a prototypi-cal scenario. Other scenarios may result from otherlife cases, and the scenarios collected this way can beintegrated and then be subject to further refinement.Let us concentrate on the life case relocation again.

Example 4.4 In the case of the relocation of a personthe steps identified in Example 4.1 give immediatelyrise to scenes in a scenario, i.e. in addition to anentry scene, say start, we obtain scenes for change ofaddress data, change of data for associated persons,change of registration data, change of specific data,change of data for social aid. For a start we only havea single actor citizen.

In principle, the visit of any of these scenes is op-tional, which gives rise to a classification of actorsinto citizens with children, citizens with pets, foreignresidents, etc. The life case of a citizen with childrengives rise to a scenario for the change of data for as-sociated persons, while the life case of a citizen withpets gives rise to a scenario for the change of specificdata, etc.

5 Conclusion

In this paper we introduced the concept of lifecases as a contribution to supporting pragmatics ofstoryboarding, which closes a gap in our developmentmethodology. The general idea is to start from reallife observations and to characterize them in a semi-formal way. This gives rise to prototypical scenarios,tasks, roles and user profiles by abstraction. Severalof such prototypes can then be integrated and refinedto obtain the desired storyboard.

The concept of life cases is new and original. Ithas already successfully been applied in our web in-formation system projects, e.g. for information ser-vices (e.g., www.cottbus.de ), for edutainment sys-tems (e.g., DaMiT ), and for community services (e.g.,SeSAM ). Use cases in UML (Conallen, 2003) and busi-ness use cases (Robertson and Robertson, 2006) sharesome similar intentions, but are far too simplistic tocapture the same information as the novel life cases.However, life cases still contribute only a part of sto-ryboard pragmatics. They have to be complementedby user models, which should give rise to a deeper un-derstanding of actors, and contexts. Both topics willbe addressed next and published in due time.

REFERENCES

Ambler, S. W. (2002). Agile Modeling: Effective Practicesfor eXtreme Programming and the Unified Process.John Wiley & Sons.

Carroll, J. M., editor (1991). Designing Interaction: Psy-chology at the Human-Computer Interface. Cam-bridge University Press, Cambridge, England.

Ceri, S., Fraternali, P., Bongio, A., Brambilla, M., Comai,S., and Matera, M. (2003). Designing Data-IntensiveWeb Applications. Morgan Kaufmann, San Francisco.

Conallen, J. (2003). Building Web Applications with UML.Addison-Wesley, Boston.

Courage, C. and Baxter, K. (2005). Understanding yourusers: a practical guide to user requriements - meth-ods, tools & techniques. Morgan Kaufman, Boston.

De Troyer, O. and Leune, C. (1998). WSDM: A user-centered design method for web sites. In ComputerNetworks and ISDN Systems – Proceedings of the 7thInternational WWW Conference, pages 85–94. Else-vier.

Giorgini, P., Mylopoulos, J., Nicchiarelli, E., and Sebas-tiani, R. (2002). Reasoning with goal models. In ER,pages 167–181.

Harel, D. and Marelly, R. (2003). Come, Let’s play:Scenario-based programming using LSCs and theplay-engine. Springer, Berlin.

Houben, G.-J., Barna, P., Frasincar, F., and Vdovjak, R.(2003). HERA: Development of semantic web infor-mation systems. In Third International Conferenceon Web Engineering – ICWE 2003, volume 2722 ofLNCS, pages 529–538. Springer-Verlag.

Lowe, D., Henderson-Sellers, B., and Gu, A. (2002). Webextensions to UML: Using the MVC triad. In Spac-capietra, S., March, S. T., and Kambayashi, Y., edi-tors, Conceptual Modeling – ER 2002, volume 2503of LNCS, pages 105–119. Springer-Verlag.

Mylopoulos, J., Fuxman, A., and Giorgini, P. (2000). Fromentities and relationships to social actors and depen-dencies. In Conceptual Modeling - ER 2000, pages27–36, Berlin. Springer-Verlag.

Robertson, J. and Robertson, S. (1999). Mastering the Re-quirements Process. Addison-Wesley.

Robertson, J. and Robertson, S. (2006). Requirements-LedProject Process. Addison-Wesley.

Rosenfeld, L. and Morville, P. (1998). Information Archi-tecture. O’Reilly, Cambridge.

Schwabe, D. and Rossi, G. (1998). An object orientedapproach to web-based application design. TAPOS,4(4):207–225.

Sommerville, I. (2004). Software Enginering. AddisonWesley, San Francisco, seventh edition.

Thalheim, B. and Dusterhoft, A. (2000). The use ofmetaphorical structures for internet sites. Data &Knowledge Engineering, 35:161–180.

Vale, E. (1982). The technique of screen and television writ-ing. Simon and Schuster, New York.

Facets of Media Types

Klaus-Dieter Schewe1, Bernhard Thalheim2

1 Massey University, Information Science Research CentrePrivate Bag 11 222, Palmerston North, New Zealand

2 Christian Albrechts University Kiel, Department of Computer ScienceOlshausenstr. 40, D-24098 Kiel, Germany


Abstract. The concept of media type is central to the codesign ap-proach to Web Information Systems (WISs). By means of views on somedatabase schema it permits a separation of global content from local con-tent that is to support particular scenes of a WIS. By means of variousextensions such as cohesion, hierarchies, style options and associated op-erations it enables interface abstraction and adaptivity to users, channelsand end-devices. It can further be used for modelling collaboration, ses-sion support and contextual information, and by means of an associateddynamic logic provides the basis for formal reasoning about a WIS de-sign. In this paper we give a brief survey of the potential of media typesas a very powerful abstraction mechanism for WISs.

1 Introduction

A Web Information System (WIS) is a data-intensive system that is accessible viathe world-wide web (WWW). As such the design of such systems has attracteda lot of attention by researchers in the area of conceptual modelling, and variousmodelling languages and design frameworks have been developed so far [2–4, 6,7, 15, 16], all having their individual merits but none giving a complete answer,how all the challenges in WIS modelling (see [13]) are addressed.

In this paper we give a brief survey of the potential of the concept of mediatype, the central notion in the codesign approach to WISs [15]. The naming ofthe concept relates to the common understanding of “media” as means for masscommunication suggesting that the WWW has become such a means. “Types”then refer to the classification and formal abstraction from content and func-tionality of such communication means.

As such a media type is first an interface abstraction related to and extendingthe notion of dialogue type introduced in [14]. The rough idea is that the globaldata content of a WIS is captured by means of an instance of a conceptualdatabase schema, while content needed at the interface is modelled by meansof views. As emphasized in [13] this includes the modelling of the navigationstructure, which in various other approaches is treated as a separate add-onfeature. Furthermore, same as with dialogue types operations expressing the

2 Klaus-Dieter Schewe, Bernhard Thalheim

functionality of the WIS, are coupled with the views. In this way, media typescapture form-based interfaces [5, 9] in an abstract way.

In doing so, media types provide a perfect mechanism to refine the scenesand actions of the storyboard that result from analysing and modelling the us-age of the WIS [15], thus linking the conceptual model to the identified systemsrequirements. By means of associated style options [11] they also provide themechanism for system implementation including a structural part (XML clus-ters), a behavioural part (scripts) and a layout part associated with page grids.

However, media types are more than just interface abstractions. By means ofhierarchical versions they subsume OLAP-like features allowing users to switchbetween representations at various levels of granularity. By means of cohesionthey allow an automatic split of information adhering to the restrictions imposedby channels, end-devices and user preferences. In this sense media types enablederivable adaptivity. Furthermore, as outlined in [12] consistency and person-alisation with respect to content and functionality can be achieved by logicalreasoning about media types.

Most WISs are centred around the actions of individual users, whereas theneed may arise to support collaboration. This can also be captured by mediatypes using associated exchange frames [1] that support cooperation, commu-nication and coordination within user groups. This is related to the fact thatmedia objects, i.e. instances of media types, can be used to capture informationabout sessions, which are linked to complex scenes in the storyboard.

Finally, media types permit dealing with the often mentioned phenomenonof “loss in cyber space”, which actually is a loss of navigation context. Adaptingan idea from Contextual Information Systems [18] we obtain query macros thatallow a user to traverse back a path in the storyboard and to explore alternativeaccess paths, respectively [8].

2 Interface Abstraction

In the following let S denote some conceptual database schema. The introductionof media types in [15] was based on the higher-order Entity-Relationship model(HERM) [17], but we already emphasised that the choice of data model is ofminor importance. A model (such as HERM) with richer structuring mechanismswill simplify the definition of views, while a poorer model – even if it has thesame expressive power – will require more sophistication in the queries thatdefine views.

Furthermore we assume a type system comprising base types and varioustype constructors, e.g.

t = b | 1l | (a1 : t1, . . . , an : tn) | t | [t] | 〈t〉 | (a1 : t1) ⊕ · · · ⊕ (an : tn)

would define a type system with not further specified base types b, a trivial type1l, and constructors for records, finite sets, lists and multisets, and disjoint unions.Usually, we assume that among the base types there is a type URI representingabstract surrogates for URIs.

Facets of Media Types 3

The semantics of such types is primarily defined by their domains, i.e. witheach type t we associate a set of values dom(t). For a base type the domain isassumed to be countably infinite. For the trivial type the domain is a singleton set1. For constructed types we use the usual recursive definitions. Furthermore,we associate basic (fixed) operations with the type system, e.g. projection onrecord types, union for sets, etc., but we dispense with listing them here.

The type system forms the basis for the definition of content type expressions.We simply extend the type system permitting r : M to appear in lieu of a basetype, with r and M being names for a reference and a media type, respectively,both taken from some unspecified countable pool of names. Replacing r : M byURI results in a proper type, called content representation type.

The core of a media type M is defined by an interaction type, which comprisesa content type expression ct(M) (with corresponding content representation typetM , a query qM defined on S with output type (id : URI, value : tM ), and a finiteset OpM of operations – more formal details can be found in [15]. An interactionschema I is a finite set of interaction types that is closed under references, i.e.whenever r : M appears in a content type expression ct(M ′) with M ′ ∈ I, thenM ∈ I must also hold.

The semantics of interaction types and schemata is defined by means of thedefining queries. Take an instance db of the database schema S and executethe queries qM for all M ∈ I, which will result in sets db(M) with values thatare actually pairs (u, v) with a URL u and a value v of type tM . We requestthat whenever a URL u′ appear in such a value corresponding to the referencer : M ′ in the content type expression ct(M), then db(M ′) must contain a value(u′, v′). Furthermore, URLs must be globally unique. In this way we obtainan abstraction from the structure at the interface. The value (u, v) ∈ db(M)represents the content v at the abstract URL u including references to otherunits of content, i.e. including the navigation structure. In its simplest form thisis abstraction from web pages, but as we shall see later it can be more than that.As emphasised in [15] and discussed with respect to different query languages,the abstract definition of interaction types requires the use of query languagesthat are able to create abstract identifiers, i.e. the URLs, and in many cases willneed a fixed-point construction.

Operations associated with an interaction type permit updating the under-lying database and to open and close interaction objects. For this, we require asignature describing input- and output-parameters as well as a selection type,and an operation body that can be defined by means of usual programming lan-guage constructs. The selection type specifies, which part of the content valuemust be selected as a precondition for the operation being excuted. In [9] weillustrated that this form of interaction types, which is more or less the same asthe dialogue types in [14] captures form processing in a natural way and on areasonably high level of abstraction, but it is not limited to this.

For this, consider storyboarding, the precursor of conceptual modelling in thecodesign approach to WISs. A storyboard consists of three parts: (1) the storyspace describing scenes, the transition between scenes, actions associated with


these transitions, and the plot, i.e. the detailed action scheme, (2) the actorsdescribing roles, right and obligations associated with roles, user profiles, andpreferences associated with these profiles, and (3) the tasks describing meaning-ful chunks of WIS usage, the actors involved, their goals, the scenes associatedwith tasks, and the actions required for task execution. Scenes are hierarchicallyorganised in the sense that each non-elemetary scene gives rise to a scenario,which is composed in the same way as the whole story space, in particular giv-ing rise to sub-scenes.

The basic interface abstraction mechanism described above associates a me-dia type with an elementary scene leading to page abstraction as outlined above.However, there is no formal reason not to associate media types also with non-elementary scenes, thus leading to inferface abstraction on a higher-level. Wewill discuss the benefits of this high-level interface abstraction in the followingsections.

Before doing this, let us first take a look at some other facet of media types.Media types are extended interaction types, and one of the extensions refers tolayout and playout style options. For the layout the primary question is how theabstract content of a media object, i.e. a value of type tM , is to be represented.Exploiting that types give rise to a lattice, this first leads to a decomposition by

means of a Sperner set of types t1M , . . . , tkM withk⊔

i=1

tiM = tM . Using canonical

projections from dom(tM ) to each dom(tiM ) we obtain values v1, . . . , vk thatjointly represent the content of some WIS unit. For each of the types tiM a styleoption specifies how records, sets, lists and multisets are to be represented usingmaybe tables, itemized lists, forms or other layout elements, which colours areto be used, which font families and sizes are to be used, which adornments suchas background images should be added, etc. In the same way the playout ofoperations is handled, i.e. how are operation names to appear, how is input fromthe user collected using forms or dialogue boxes, how is correctness of data entryensured, etc.

With respect to the actual system implementation, the content representationtype of a media type gives rise to a cluster of XML templates, while the definingquery has to be mapped to a query resulting in a cluster of XML documents.The style options then give rise to translators from XML to HTML, while theoperations give rise to scripts implemented in the preferred scripting language.In this way, most of the actual implementation of the WIS results from pagegeneration with the actual content defined by the current database instance.

Furthermore, media types permit the easy use of the container metaphor. Byusing this metaphor the content representation type tM is only considered as thetype describing the content at the server-side, while the demand at the clientside may be expressed by a different type t. In this case, the meet tM t definesthe part of the content that is to be shipped in a “container” to this client. Anymissing part has to be obtained from other media types. Style options on theclient side then define how the content of various containers is to be assembled.


3 Adaptivity

Two other extensions of interaction types (turning them into media types) ad-dress the granualarity of the represented data, and the adaptivity to users, chan-nels and end-devices. The former one adopts ideas from on-line analytical pro-cessing (OLAP), while the latter one addresses splitting and condensation ofinformation. Both extensions exploit the type lattice.

In order to address granularity we take the lattice defined by the supertypest′ of tM . To stay consistent with the use of join and meet above let the order besuch that t′ ≤ tM holds. In particular, tM is the smallest type in that lattice.Now take a subset H(M) of types in the lattice that defines a tree with root tM– this will be called a set of hierarchical versions. In earlier versions of our workwe actually requested a chain instead of a tree. Obviously, be means of canonicalprojections from dom(tM ) to dom(t) for each t ∈ H(M), we obtain for each valuev of type tM and each t ∈ H(M) a version vt of type t. Furthermore, due to thefact that we use a tree, we also get canonical up and down navigation operationsbetween these versions. As tM itself represents very condensed information, thehierarchical versions vt represent lighter versions. Which version is the preferredone to start with depends on the preferences of the user. We should remark thatthere is no need to define specific style options for the hierarchical versions, asthese carry over by means of the meet operation in the type lattice. In the sameway, other OLAP-like operations, e.g. slicing and dicing are already defined bythe content type expression, and there is no need to specify them.

With respect to adaptivity, we start from restrictions on the amount of datathat is to be presented to a user. A value v of type tM corresponds to the fullamount of data represented by the media type M , but this may not be neededor requested by a user, or considered to be not suitable due to network or end-device restrictions, e.g. restricted band-width, limited presentation capacity invideotext or simply user preference. The extension to interaction types dealingwith these restrictions is cohesion, which permits a controlled splitting of a valuev of type tM into a sequence of values v1, . . . , v of types t1, . . . , t such that

⊔

i=1

ti = tM , vi is the canonical projection of v, i.e. the decomposition is lossless,

each vi contains a reference to vi+1, and each vi is a higher importance thanvi+1. As discussed in [15] this can be achieved in basically two different ways,either by means of a cohesion pre-order, which extends the order defined by thetype lattice to a total pre-order, or by means of proximity values for each pairof types in a specified maximal antichain in the type lattice.

The main difference between the two approaches to cohesion is that proximityvalues use an a priori decomposition of tM , i.e. an anti-chain of types t1, . . . , tk

such thatk⊔

i=1

ti = tM . Then the types in the cohesion sequence are either these

a priori given types or result from applying the join operator to some of them.The guideline for defining the types in the cohesion anti-chain is that the jointtype must be maximal within the limitations defined by the end-device, channel


or user preferences, and the sum of proximity values must be maximal. In thisit is guaranteed that those ti with the highest cohesion will stay together.

The alternative of using a cohesion pre-order does not assume an a prioridecomposition of tM . Then the guideline for selecting t1 and thus define the valuev1 is to be maximal within the limitations defined by the end-device, channel oruser preference and also maximal with respect to the cohesion pre-order. Theprocess is then repeated recursively with a maximal type t′ complementing t1,i.e. t′ t1 = tM .

Formal details of hierarchies and cohesion were presented in [15]. It is nottoo difficult to see that cohesion, hierarchies and style options are orthogonalextensions that can be mutually combined, i.e. for each hierarchical version thecohesion decomposition can be applied, and for each value in a cohesion sequence(for whatever hierarchical version) the style options can be applied.

4 Session and Context Support

As already sketched above media types enable interface abstraction non only onthe level of elementary scenes, but can also be used for non-elementary scenes inthe storyboard. In doing so media types can be used to support the concept of asession. Informally, a session comprises all scenes visited by a user from enteringthe systems until leaving it. Exploiting the hierarchies of scenes, a session can berepresented itself by a non-elementary scene. That is, entering a session refers tothe creation of the corresponding media object, which is linked to the elementarymedia objects used for defining subscenes. Technically, we model this by linksfrom the media types associated with the elementrary scenes to the overarchingsession scene. Such links can be modelled as being hidden, i.e. they actually donot appear as part of the navigation structure. The session object may representdata that is carried around through the session. A typical example is the shoppingcart in e-commerce systems. It is deleted by means of garbage collection, i.e. whenno more media object exists that links to it.

Another use of media types for complex scenes is the support of navigationcontext, for which the basic idea from contextual information bases has beenadopted [18]. According to this a context is a set of object identifiers each havingseveral names, and each of these names may be coupled with a reference toanother context. There may be names for objects that are not referencing toother contexts. More formally, a context C is a finite set of triples (o, n, r),where o is an object identifier, i.e. a value of some base type ID , n is a name,i.e. a value of type STRING , and r is either a reference → C ′ to a contextC ′ or nil, the latter one indicating that there is no such reference. We writeC = n1 : o1 → C1, . . . , n : o → C. If there is no reference for the i’th name,i.e. we have (oi, ni,nil) we simply omit → Ci and write ni : oi.

The idea of working with contextual information bases is that a user queriesthem and thus retrieves objects. In order to describe these objects in more detailss/he accesses the context(s) of the object, which will lead to other objects by


following the references. In addition, a particular information encoded by thename is associated with each of these references.

Bringing together media types and contextual information bases, the obviousquestions are: What are the object identifiers that are required in contextualinformation bases, if we are given media types? What are the references thatare required in contextual information bases? Is it sufficient to have names fordescribing objects in a context or should these be replaced by something else?

The natural answer to the first question for generalising the notion of objectidentifiers in contexts is to choose the unique URLs of the media objects. Sup-porting navigation context requires access to path information, so we may wantto reference back to the various media objects that we have encountered so far.These media objects are placed in several contexts, one of which is the right onecorresponding to our path. However, we may also have different references, whichlead to different contexts. So, the contexts we asked for in the second questionare just the contexts for the media objects, which themselves are represented bymedia objects for paths, i.e. again non-elementary scenes.

As to the third question, we definitely want to have more information thanjust a name. Fortunately, the concept of media type is already based on theassumption of an underlying type system. Thus, we simply have to replace thenames by values of any type permitted by the type system. Having defined suchextended contexts, we can exploit query macros to traverse back a path in thestory board and to explore alternative access paths, respectively.

However, one important aspect of media types is the use of classification ab-straction. Conceptually, we do not define a set of media objects, but we generatethem via queries defined on some underlying database schema. Therefore, wealso need a conceptual abstraction for contexts. In order to obtain this concep-tual abstraction, we assume another base type Context , the values of which arecontext names. Instead of this, we could take the type URL, but in order toavoid confusion we use a new type.

Then a context consists of a name C, i.e. a value of type content, a type tCand a defining query qC , which must be defined on the media schema, i.e. theset of media types, such that

((id : URL, value :tC , reference : Context), qC)

defines a view. Thus, executing the query qC will result in a set of triples (u, v, r),where u is the URL of a media type, v is a value of type tC , and r is the nameof a context. If this context is undefined, this is interpreted as no reference forthis object in this context.

5 Collaboration

In [1] we started an investigation of collaboration frameworks for distributedWISs addressing the problem that we may have tasks that are to be solvedby collaboration of several users, e.g. using group work in e-learning systems.


Collaboration is understood as combining cooperation, communication and co-ordination. The ground idea for capturing collaboration in WISs therefore is todefine another extension of media types by means of exchange frames, whichcombine an exchange architecture addressing communication and cooperation,and a coordination specification, which consists of supporting programs, coop-eration style coordination facilities, roles of collaborators, their responsibilitiesand rights, and the protocols they rely on.

Exploiting again the idea of media types supporting complex scenes we canabstract from the actor representing an individual user to actors representing agroup of users. The exchange architecture for cooperation and communicationwithin a group can be modelled by means of a workspace, which again is nothingbut a media object associated with the group action, and consequently mediaobject used by individuals in the group contain hidden links to the group object.

6 Reasoning about Media Types

Following our previous work in [12] we can formalise the operations associatedon media types using the following language of abstract programs:

– 1 and 0 are abstract programs meaning skip and fail, respectively.– An assignment x := exp with a variable x and an expression of the same

type as x is an abstract program. The possible expressions are defined by thetype system. In addition, we permit expressions P with a logic program P,assuming that P contains a variable ans. The expression P is interpretedas the result of the logic program bound to ans.

– If p, p1 and P2 are abstract programs, the same holds for the iteration p∗,the choice p1 + p2 and the sequence p1 · p2 = p1p2.

– If p is an abstract program and ϕ is a condition, then the guarded programϕp and the postguarded program pϕ are also abstract programs.

– If x is a variable and p is an abstract program, then the selection @x • p isalso an abstract program.

On these grounds we introduce a higher-order dynamic logic, where the or-der comes from the intrinsic use of the set constructor and the logic programsin queries. In fact, instead of using logic programs with a semantics defined byfixed-points, we could use directly higher-order logic enriched with a fixed-pointoperator. As a consequence, we may consider a logic program P as a represen-tative of a higher-order logical formula, say ϕP . If P is used as the right-handside of an assignment, then it will correspond to a term Ians.ϕP denoting theunique ans satisfying formula ϕP . That is, all conditions turn out to be formulaeof a logic L, which happens to be a higher-order logic with a fixed-point opera-tor. From the point of view of expressiveness the fixed-point operator is alreadysubsumed by the order, but for convenience we do not emphasise this aspecthere. Furthermore, by adding terms of the form Ix.ϕ with a formula ϕ and avariable x all assignments in operations are just “normal” assignments, wherethe left-hand side is a variable and the right-hand side is a term of L.


We now extend L to a dynamic logic by adding formulae of the form [p]ϕ withan abstract program p and a formula ϕ of L. Informally, [p]ϕ means that afterthe successful execution of p the formula ϕ necessarily holds. In addition, we usethe shortcut 〈p〉ϕ ≡ ¬[p]¬ϕ, so 〈p〉ϕ means that after the successful execution ofp it is possible that the formula ϕ holds. Using our recursive definition of abstractprograms the following rules apply to [p]ψ for a complex abstract program p:

[1]ψ ≡ ψ

[0]ψ ≡ 0[x := t]ψ ≡ ψx/t (substitute all free occurences of x in ψ by t)[p1p2]ψ ≡ [p1][p2]ψ

[p1 + p2]ψ ≡ [p1]ψ ∧ [p2]ψ[p∗]ψ ≡ the weakest solution ϕ of ϕ ↔ ψ ∧ [p]ϕ[ϕp]ψ ≡ ϕ → [p]ψ[pϕ]ψ ≡ [p](ϕ → ψ)

[@x • p]ψ ≡ ∀x.[p]ψ

As outlined in [12] we can formulate proof obligations for the operationsthat result from the the specification of the story space, in particular for consis-tency with respect to static and dynamic integrity constraints on the underlyingdatabase schema. Furthermore, we can extend WIS personalisation in the lightof dynamic logic.

7 Conclusion

In this survey we outlined in compact form the potential of the concept of mediatype emphasizing its use for interface abstraction supporting adaptivity to users,channels and devices, collaboration among user groups, session and context sup-port, and serving as the conceptual bridge between identified requirements, theusage model of the WIS, the layout and playout, and the implementation on thebasis of XML clusters and scripts. The versatility of media types are a majorreason for the success of the codesign approach to WIS design as demonstrated invarious large-scale applications. Furthermore, it is worth exploring the conceptof media types in more depth, in particular with respect to the logical inferencesas started in [12] on the basis of dynamic logic, the connection to deontic con-straints on the storyboard and their refinement to the level of media types [13],and their embedding in layout and playout by means of screenography [10].

References

1. Binemann-Zdanowicz, A., Schewe, K.-D., and Thalheim, B. Development of col-laboration frameworks for distributed web information systems. In Proc. 7th Inter-national Conference on Information Integration and Web-Based Applications andServices (IIWAS 2005), vol. 2, G. Kotsis et al., Eds. Osterreichische ComputerGesellschaft, 2005, pp. 551–562.


2. Ceri, S., Fraternali, P., Bongio, A., Brambilla, M., Comai, S., and Matera, M.Designing Data-Intensive Web Applications. Morgan Kaufmann, San Francisco,2003.

3. Conallen, J. Building Web Applications with UML. Addison-Wesley, Boston, 2003.4. De Troyer, O., and Leune, C. WSDM: A user-centered design method for web sites.

In Computer Networks and ISDN Systems – Proceedings of the 7th InternationalWWW Conference. Elsevier, 1998, pp. 85–94.

5. Draheim, D., and Weber, G. Form-Oriented Analysis –A New Methodology toModel Form-Based Applications. Springer Verlag, 2004.

6. Guell, N., Schwabe, D., and Vilain, P. Modeling interactions and navigation in webapplications. In Conceptual Modeling for E-Business and the Web, S. W. Liddle,H. C. Mayr, and B. Thalheim, Eds., vol. 1921 of LNCS. Springer-Verlag, 2000,pp. 115–127.

7. Houben, G.-J., Barna, P., Frasincar, F., and Vdovjak, R. HERA: Developmentof semantic web information systems. In Third International Conference on WebEngineering – ICWE 2003 (2003), vol. 2722 of LNCS, Springer-Verlag, pp. 529–538.

8. Kaschek, R., Schewe, K.-D., Thalheim, B., and Zhang, L. Integrating context inconceptual modelling for web information systems. In Web Services, E-Business,and the Semantic Web, C. Bussler, D. Fensel, M. E. Orlowska, and J. Yang, Eds.,vol. 3095 of LNCS. Springer-Verlag, 2004, pp. 77–88.

9. Ma, H., Noack, R., Riaz-ud-Din, F., Schewe, K.-D., and Thalheim, B. Capturingforms in web information systems. In Innovations in Information Technology 2007– Web Applications and Services. IEEE, 2007.

10. Moritz, T., Noack, R., Schewe, K.-D., and Thalheim, B. Intention-driven screenog-raphy. In Information Systems Technology and its Applications (ISTA 2007),vol. P-107 of Lecture Notes in Informatics. GI, 2007, pp. 128–139.

11. Moritz, T., Schewe, K.-D., and Thalheim, B. Strategic modelling of web infor-mation systems. International Journal on Web Information Systems 1, 4 (2005),77–94.

12. Schewe, K.-D. The power of media types. In Web Information Systems – WISE2004, X. Zhou, S. Su, M. Papazoglou, M. Orlowska, and K. Jeffery, Eds., vol. 3306of LNCS. Springer-Verlag, 2004, pp. 53–58.

13. Schewe, K.-D. The challenges in web information systems development. In In-formation Systems Technology and its Applications (ISTA 2005), R. Kaschek,H. Mayr, and S. Liddle, Eds., vol. P-63 of Lecture Notes in Informatics. GI, 2005,pp. 204–215.

14. Schewe, K.-D., and Schewe, B. Integrating database and dialogue design. Knowl-edge and Information Systems 2, 1 (2000), 1–32.

15. Schewe, K.-D., and Thalheim, B. Conceptual modelling of web information sys-tems. Data and Knowledge Engineering 54, 2 (2005), 147–188.

16. Schwabe, D., and Rossi, G. An object oriented approach to web-based applicationdesign. TAPOS 4, 4 (1998), 207–225.

17. Thalheim, B. Entity-Relationship Modeling: Foundations of Database Technology.Springer-Verlag, 2000.

18. Theodorakis, M., Analyti, A., Constantopoulos, P., and Spyratos, N. Context ininformation bases. In Proc. CoopIS ’98. Springer-Verlag, 1998, pp. 260–270.

Towards Semantic Wikis: ModellingIntensions, Topics, and Origin in Content

Management SystemsGunar Fiedler, Bernhard Thalheim

Department of Computer Science, Christian-Albrechts University at KielOlshausenstr. 40, 24098 Kiel, Germany

fiedler, [email protected]

Abstract. Content management is the process of handling information within an or-ganization or community. Therefore, content management systems have to providegeneric functionality for generation, extraction, storage, and exchange of digital as-sets. Because of the heterogeneity and complexity of content, a sufficient semanticaland user-oriented annotation of content is crucial. Although semantical annotation bymetadata and ontologies together with reasoning support has been extensively studiedfor a long time, commercially available content management systems provide only ba-sic support for semantic modelling. Conceptual aspects of content users and supportof user specific intensions are neglected. In this paper we will analyze the mismatchbetween the requirements of content management and semantical description and pro-pose a data model for content which treats semantic information not only as describingmetadata but incorporates the data itself, the intension behind the data, the usage ofdata and the origin of data on the same level.

1 Introduction

Content Management

Content in its actual definition is any kind of information that is shared within a commu-nity or organization. In difference to data in classical database systems content usually refersto aggregated macro data which is complex structured. Structuring of content can be distin-guished:

• The structure of the aggregated micro data is preserved but micro data was combined tobuild larger chunks of information. Examples are scientific data sets such as time seriesof certain measurements. There is a common (or even individual) structuring and mean-ing for each sampling vector but the compound of all sampling vectors adds additionalsemantics.

• The structure of content is only partially known. A typical example is the content of Webpages: structuring is known up to a certain level of detail which may also be varyingwithin one instance.

• Content may be subsymbolic, such as pictures, videos, music or other multimedia content.

Aggregation of content usually takes place by combining reusable fragments provided bydifferent sources in different formats such as texts, pictures, video streams or structured datafrom databases. Content is subject to a content life cycle which implies a persistent changeprocess to the content available in a content management system (CMS).

Currently, many systems claim to be content management systems. A recent overview ofthe German market (www.contentmanager.de, viewed June 12th, 2007) reveals hundreds ofproducts related to tasks of content management. Most products are related to Web contentmanagement. These products organize content for Web pages with a strong orientation oneditorial components such as texts and pictures.

The more generic ones agree in a major paradigm: the separation of data managementand presentation management. Data management reflects the process of supporting contentcreation, content structuring, content versioning, and content distribution while presentationmanagement grabs the data for delivering it to the user in various ways. Only content whichis generated following this separation can be easily shared, distributed, and reused.

Following new trends and developments in Web technologies, e.g., in the context of Web2.0 or the Semantic Web the automated processing of content becomes more and more im-portant. Because content represents valuable assets it may be reused in different contexts(content syndication) or has to remain accessible for a long time.

The semistructured or even unstructured nature of content requires annotations to enablesearch facilities for content. Expressing semantics in a machine interpretable way has beenunder investigation since the early days of artificial intelligence, see e.g., [12] for a survey ofknowledge representation techniques such as logical theories, rule-based systems, frames orsemantic nets. Today systems handle semantical descriptions as metadata describing certaincontent instances. There are different ways for associating data and metadata:

• A conceptual, logical, or physical schema is defined and instances are created accordingto this schema. This is the usual way for classical databases. The modelling languagestrongly restricts the capabilities of this description facility. Common languages such asEntity-Relationship Modelling or UML focus on structural properties with support ofselected integrity constraints.

• Defining a schema is not applicable (or only in a restricted way) to semistructured orunstructured content. For that reason content instances are annotated. An annotation isa triple (S, P, O) where S denotes the subject to be annotated, P a predicate denotingthe role or purpose of this annotation, and O the object (or resource) which is associatedwith S. The vocabulary for annotations is organized in ontologies and thesauri. A typicallanguage for expressing annotations in the context of the Semantic Web is the ResourceDescription Framework (RDF, [20]) while the Web Ontology Language OWL ([19]) maybe used to express semantic relationships between the concepts and resources used forannotation. There exist myriads of ontologies and parameter definitions for different ap-plication domains such as the Dublin Core parameters [3]) for editorial content.

Content Management and Semantic Annotations

Semantic annotation in current content management systems is usually restricted to prese-lected ontologies and parameter sets. Rich conceptual data models are only available in moresophisticated systems. Because most generic CMS are focused on Web content management

semantic annotation is usually restricted to editorial parameters. Specialized content manage-ment systems which are adapted to certain application domains incorporate preselected andtailored ontologies. Especially for XML-based content there exist several annotation plat-forms which incorporate semantical annotation either manually or semi-automatically; see[11] for a survey on available platforms.

Automated processing of semantical metadata is usually restricted to search facilities, e.g.,searching for the author of an article. Because ontologies are preselected for most systems afull-featured reasoning support is usually not available. Especially for OWL ontologies thereare reasoning tools based on description logics such as Racer ([7]) or FaCT which enableT-box (but also A-box) reasoning about semantic relationships between annotation concepts.

Applying generic semantical annotation and classical reasoning facilities to content man-agement suffers from several drawbacks:• Content as aggregated macro data is only partially analysable. The purpose of metadata

is the description of properties which cannot be concluded from the data itself. The verysimple annotation frame of (S, P, O) triples does not allow one to express complex prop-erties. For that reason this information has to be kept in the underlying ontology by defin-ing appropriate concepts. The support of user-specific concepts increases the size of theontology significantly and makes reasoning support even harder. Ad hoc definitions ofuser-specific concepts is not supported in this annotation model.

• Annotation with respect to arbitrary ontologies implies general purpose reasoning supportby the system. Reasoning for even simple languages suffers from its high computationalcomplexity (e.g., NEXPTIME for the restricted OWL-DL dialect, [9].) Dealing with highworst-case complexities implies a small size of input data but this is a contradiction toexpressible ontologies and the definition of content as complex structured macro data.Especially the size of content instances is a crucial factor because A-box reasoning is acritical point for automated content processing ([8].)

But there are advantages, too:• Usually, it is possible to distinguish between different points of view on content instances.

Not every property is important while looking from every point of view. The macro datamay encapsulate and hide properties from its aggregated micro data. Reasoning about theproperties of the compound can be separated from the properties of the elements as wellas the properties of interconnections between content instances.

• Typical application scenarios determine important properties and suggest evaluation strate-gies. So ontologies may be decomposed to enable a contextualized reasoning, e.g., on thebasis of Local Model Semantics ([6]). Local reasoning may rely on a language that isjust as expressive as needed in this context. Contexts relying on less expressive languagesmay support automated reasoning while contexts relying on more expressive languagesmay be used for manually interpreted information. Soundness and completeness of thereasoning process are not of primary interest as long as the reasoning result is acceptablein the application domain.

• The separation between annotations relying on common knowledge, user-specific annota-tions and (especially) usage-specific annotations reduces the size of incorporated ontolo-gies significantly.

• If semantic annotations themselves are given a more sophisticated internal structure rea-soning can be adapted to the requirements of the application domain.

The major disadvantage of current semantic description in content management is thetreatment of knowledge over content instances as metadata on a secondary level in a stronglyrestricted language. In the following sections we will introduce a data model for contentwhich handles the semantic part on the same level as the content itself and gives additionalstructure to the semantic description. We will start with the definition of content chunks assemantically enriched content instances in Section 2. In Section 4 we will introduce the notionof a schema for content chunks to incorporate typical functionality of content managementsystems such as content generation, content delivery, or content exchange.

As an example for a content management system we will take a look at a (simplified) Webshop application which sells products to customers via a website. The usual functionalityshould be supported: customers are able to search and browse for products, manage theirprofiles, shopping carts, and wish lists and order products.

2 Content Chunks

If we consider the HERM ([14]) schema fragment in Figure 1 we see a modelled list ofproducts.

pos

consistsof

Product

No Descr

PriceList

No

(0,*) (0,*)

Figure 1: Schema Fragment: List of Products

This modelling reveals certain structural properties such as attributes of the entity typesand the connection between the list and the products. But the purpose of this model is missing.What kind of list was modelled: a shopping cart, a wish list, a list of stock items? Why wasit modelled? What does the modeler expect? All this information is missing in the modelledfragment but is crucial if content instances of this schema are processed: if the list representsa shopping cart, pricing information may be collected. If it represents a wish list, there maybe the need for additional functionality for discovering related products. It is obvious thatexpressing all this information by (S, P, O) annotations will increase greatly complexity ofeach content instance and prevents a sophisticated semantic handling.

Modelling the semantics behind the data needs as much attention as modelling the struc-tural properties of content. For that reason we propose a content data model which integratesstructure, intension, usage, and origin on the same level. We start with the definition of con-tent instances in this model.

Definition 1. A content chunk is a tuple C = (D, I, T, O) where D is the structural represen-tation of a content instance, I an intensional description, T a topic description expressing theusage of content, and O the specification of the context where the content instance is used.The state of a content system is a finite set of content chunks.

Figure 2 visualizes the four dimensions of content chunks. Each content chunk expressesthe association identifying ‘what (structure) is used by whom (origin, context) in which way(topic) under which assumptions and thoughts (intension)’. In the following paragraphs wewill refine these notions.

origin

structure topic

intension

Figure 2: Dimensions of Content Chunks

The Structure Dimension

The structural part of a content chunk reflects the classical notion of a content instance. De-pending on the nature of the content data may be represented using an instance of a databaseschema formulated in ERM or UML, a semistructured resource such as a XML document, ora subsymbolic resource such as a picture.

Definition 2. Let L be a set of (supported) modelling languages, SL the set of all schemataexpressible with a certain modelling language L ∈ L and ΣS the set of all possible states ofa certain schema S. The structural component D of a content chunk C is a triple (L, S, I)denoting a modelling language L ∈ L, a schema S ∈ SL, and an instance I ∈ ΣS .

In our example, (′HERM ′, s, i) is the structural part of a content chunk if s denotes theschema in Figure 1 and i an instance which associates e.g., the entity type List with the entityset No : 1, the entity type Product with the set No : 134, Descr : Book, Price :16.99, No : 521, Descr : CD, Price : 9.95, and the relationship type consistsOf withthe relationship set List.No : 1, P roduct.No : 134, pos : 1, List.No : 1, P roduct.No :521, pos : 2.

The structure dimension of content chunks is based on the theory of media types [?].Media types [?] combine views and their functions into one type. Media types may be linkedto other media types. For instance, we may distinguish input data for the workflow, retrievaldata for the workflow, output data of the workflow, display data suites for each stage of theworkflows, and escorting data supporting the understanding of each stage of the workflow.

Media objects may be structured, semi-structured, or unstructured by the media types.They are data that are generated from underlying databases, ordered, hierarchically repre-sentable, tailorable to various needs and enhanced by functionality for its usage. Since usershave very different needs in data depending on their work history, their portfolio, their profileand their environment media types are packed into containers. Containers provide the fullfunctionality necessary for the application and use a special delivery and extraction facility.The media type suite is managed by a system consisting of three components:

Media object extraction system: Media objects are extracted and purged from database, in-formation or knowledge base systems and summarized and compiled into media objects.Media objects have a structuring and a functionality which allows to use these in a varietyof ways depending on the current task.

Media object storage and retrieval system: Media objects can be generated on the fly when-ever we need the content or can be stored in the storage and retrieval subsystem. Sincetheir generation is usually complex and a variety of versions must be kept, we store thesemedia objects in the subsystem.

Media object delivery system: Media objects are used in a large variety of tasks, by a largevariety of users in various social and organizational contexts and further in various envi-ronments. We use a media object delivery system for delivering data to the user in formthe user has requested. Containers contain and manage the set of media object that aredelivered to one user. The user receives the user-adapted container and may use this con-tainer as the desktop database.

This understanding closely follows the data warehouse paradigm. It is also based on theclassical model-view-control paradigm. We generalize this paradigm to media objects, whichmay be viewed in a large variety of ways and which can be generated and controlled bygenerators.

The Topic Dimension

The topic part of a content chunk is the conceptual counterpart to the presentation facilitiesof content management systems. Available systems offer template mechanisms (e.g., basedon XSLT or scripting languages such as PHP or JSP) which transform a content instance to aphysical representation ready for delivery through an output channel, e.g., HTML Web pages,e-mails, or PDF documents. Instead of coding presentation on the level of rendering templatesa more abstract approach should be used. Topic maps ([10, 17]) provide the general datastructure for a user-dependent view on content on the conceptual level. Expressing contentvia topic maps fulfills the following tasks during content delivery:

• The data structure is transformed to local vocabulary, e.g., according to a corporate iden-tity or internationalization. In our example attribute names may be changed to languagedependent labels. The prices of our products may be converted to local currencies or maybe recalculated according to different tax regulations.

• The content is embedded into the usage context. The onion approach for a stepwise gen-eration of delivered content ([15, ?]) defines different kinds of embeddings depending onthe profile of a user (characterization of the properties of the user such as language, skilllevel, or preferences) and portfolio (tasks which have to be, should be, and can be fulfilledby the user, see [5].) This information is obtained from the specifications of workflowsand storyboards for interaction and added to the topic map as supplementary content.There are different kinds of supplementary content:

– static content, e.g., the logo of the company or statically linked elements such asadvertisement banners,

– decorative content which is dependent on the current usage context but has no mean-ing to the application such as contextual help or integrated services such as a con-textual weather forecast,

– additionally delivered content such as information about manufactures or links torelated products in our Web shop example, and

– navigational events such as navigational links allow the user to interact with thesystem.

– Multiple topic maps may be merged for multi-modal applications.

Supplementary content is incorporated in the topic map by parameterized queries on theset of content chunks and user specifications which characterize the occurrences of topicsdefined in the topic map. These queries are evaluated during content delivery and produce thetopic map which can finally be rendered.

The topic part of a content chunk in our example may be the topic map depicted in Figure3. This topic map reflects our product list in the context which supplies additional informationon these products. This topic map can be transformed to a physical representation (e.g., aHTML page) using the usual techniques mentioned above.

action

product list

is listedcategory

can be ordered

action

has part

browsemay beproduct

has

see also

No:134 521

manufacturer

http://www.acme.com/

/?browseCategory=5

1

non−deliverable

/?orderList=1

http://www.anotherstore.com/

Figure 3: Topic Map for the ‘Product List’ Content Chunk

Topic parts of a content chunk thus serve for several purposes: to represent ideas or un-derstandings; to represent a complex structure of content chunks and their related chunks;to communicate complexes of content chunks; to aid understanding by explicitly integratingnew and old content chunks; and to assess understanding or diagnose misunderstanding.

The Origin Dimension

To express content syndication information about the origin of content has to be stored. Theprovenance of data was already studied on the instance level ([2, 22, 1]) especially for scien-tific data sets. We can adapt these results for our purposes. We choose a finite set C from auniverse UC of contexts. Each context in C represents a point of view on the application areaunder consideration. These points of view may be different points of view of the same user ormay belong to different users. Because all these contexts are views on the same universe ofdiscourse they are related: data, intensions, and topics may be exchanged between contexts.Actions in one context may affect other contexts.

Definition 3. Let UC be a universe of contexts and let C ⊂ UC be a finite set of contexts.Further, let A = A1, ..., An be a set of content chunks. The origin part of a content chunkC is a tuple (c,A) with a context c ∈ C where the content chunk C resides and a set A ofcontent chunks which are considered to be the ancestors of this chunk. The graph implied bythis ancestor relationship between content chunks has to be acyclic.

Connections between content chunks enable the exchange and transformation of data,intensions, and topics between different contexts. In our example we may define a contentchunk representing our product list together with a topic map for rendering a shopping cart.By adapting the topic map as well as the intension we may construct a content chunk whichrenders an order confirmation.

The origin dimension also reflects the purpose of the content chunk. Content chunks havea function such as to give an instruction, to control behaviour, to transmit ideas in a memo-rable form, to enhance social cohesion, or to give users a better understanding. For example,a content chunk that reflect a piece of knowledge may start with a mystery that leads to aconflict situation, may continue with an explanation of the solution or of the discovery asthe turning point and may conclude with a resolution of the conflict situation. Context [?]injection must thus be an integral element for content chunk processing.

Our origin model for content chunks extends the usage thesis of [?] that mainly reflect thecommunication act between a sender and receiver with their intentions, backgrounds, culturesand relationships. Usage context should also consider excluded receivers, value of contentchunks to receivers, groups or societies. Content chunks are thus generically [?] enhanced bycontext, refined by intended specifics and instantiated by their specific usage.

The Intension Dimension

The intention dimension is based on concepts. They are the building blocks in human think-ing and reasoning, and as such highly flexible. They can be general or specific, concreteor abstract, natural or technological, artistic or scientific. They can apply to things that arereal or imaginary. They provide a help for distinguishing between things we observe in theworld, or ideas such as truth and falsity, appearance and reality and continuity and disconti-nuity. Abstract concepts are useful for characterisation of observations, thoughts and expres-sions. Typical abstract concepts are truth and falsity, sameness and difference, wholes andparts, subjectivity and objectivity, appearance and reality, continuity and discontinuity, senseand reference, meaningful and meaningless and problem and solution. They govern differentkinds of human thinking at a fundamental level.

Concepts are vital to the efficient functioning of semantic Wikis. They are organised bun-dles of stored knowledge which represent an articulation of events, entities, situations, and soon experience. Concepts are necessary for an understanding, for the organisation, for sharingWikis and for communication. We may assume a simple association between the componentsof Wikis and concept. The associations may form a complex multi-dimensional network.They may be of specific types such as kind-of, is-part-of, is-used-for and of variable strength.Associations typically correspond to concepts of a more schematic kind than the conceptswhich they serve to connect.

The classical approach to concepts is based on description of necessary and sufficientcriteria for content-concept association. We notice however that most concepts characterisingcontent chunks cannot be captured by means of a set of necessary and sufficient features.Many natural concepts are fuzzy and contextually flexible. Therefore we need to extend theapproaches typically assumed for formal semantics to natural semantics. Additionally, theassociation of content to concepts must not be strict. Some content may be a better exampleto a concept than other content.

The prototype approach for concept-content association is also limited. Ratings or se-

lections of prototypes are strongly context dependent, e.g., culture dependent and actor de-pendent. Prototypes are given with certain preference, frequency, sample extraction, learningbackground, level of verifiability, and under time pressure. The degree of association mayvary over time, may be dependent on the concrete usage, and bound by the representationlanguage chosen. Prototype content may also be more or less specific or general for concepts.

Concepts are typically expressed through propositions. The meaning has typically twoparts: an element of assertion and something that is asserted. What is asserted is called propo-sition. The simplest type of proposition consists of an argument and a predicate. Semanticalunits or propositions are interrelated by entailment. Entailment is different from material im-plication and relates propositions by forward propagation of truth and backward propagationof falsity. Propositions can be contraries, contradictories, or independent. They may belongto a category or genre of expression, are given in a certain style or manner, are often based onstereotypical norms of expression, depend on ideas and values that are employed to justify,support or guide the expression, reflect aspects of culture or social order, are shaped accordingto the community that uses them, and are configured by theories or paradigms.

We also may distinguish between the existential approach to meaning based on a cor-relation of expressions in a language with aspects in the world. The intentional approachassociates some kind of representation with concepts as the main constituents of the senseand depends on the cultural context. Whenever content is difficult to interpret then we needto consider concepts, deep structures, unconscious foundations, hidden symbols, annotationsor underlying pattern supporting it. If content seems to transparent then we do not need tolook for these things. It is often surprising how much background information is necessaryfor understanding content even such content that appear on the surface to be wholly trans-parent. There are various connotations and denotations that content may have. We have toconsider the arrangements and laws for constructing content phenomena (langue) as well asthe various instances that are constructed by constructors and laws (parole). Content can becoded in various ways, e.g. based on different representation such as text or multimedia el-ements. Content can be differently categorized and organised. We may use conventions thatdraw on common forms of knowledge. Furthermore, we need to devise different ways forunderstanding and for association of concepts to content.

The intension of a content chunk expresses the purpose of the content as well as mean-ings and thoughts about the content chunk. Thoughts about some object may be expressedusing a general description frame. A sophisticated and generic frame was given by Zachmanin the context of specifications in software engineering ([23, 13]): each thought is expressedby formulating the facets who, what, when, where, how, and why. Each facet is specifiedby a concept. A concept itself is a small logical theory. We base our notion of concepts onintensional logics, especially on a restricted version of Transparent Intensional Logic (TIL)introduced by Tichy ([4]). TIL introduces the notions of intensional functions which mapmodalities (time, place, object identity, possibility, etc.) to values and intensional construc-tions building the intension of more complex expressions out of its components.

In our example we may introduce the concepts of customers, products, shopping carts,wish lists, product orders, etc. The concept shopping cart implies an intension of what ashopping cart is: it is a list of products selected from the offers in our Web shop. Theseproducts may be purchased in the future.

TIL analyses the intension of a concept down to the objectual base (calculating valuationsof the intension behind the sentence ‘Products are associated with a description and a price’considers all possible valuations of product, description, price, associated with and even and

in ‘one shot’.) This is not the natural way of thinking. We modify the TIL approach in thefollowing way:

• We introduce different types of individuals in the objectual base. TIL defines a single classι of individuals. Introducing multiple (disjunct) classes ι1, ..., ιn together with operationsand predicates (such as ordering relations) corresponds to the definition of data types forattributes in classical database modelling. As defined in TIL there is at least one class o oftruth values (true,false) with the usual operations and predicates. The intension behindthese operations and predicates is no longer transparent in terms of TIL.

• We support different types of modalities. TIL is specialized on modalities object iden-tity and time and defines each intensional function on these modalities. Because thereare other modalities (especially the possibility of a fact) and some intensions may beexpressed in a more compact way if e.g., the time modality is omitted we will defineintensional functions over arbitrary modalities from a given universe Ω of modalities.

• The objectual base consists of all first order types defined in TIL:

– ιi, o, and ωi are first order types,

– each partial function α1 × αk → β with first order types αi and β is a first ordertype,

– nothing else is a first order type.

Definition 4. An intensional function is a function f : ωi1×ωik → α mapping possible worlds(wi1 , ..., wik) to instances of a first order type α. An intensional function is called non-trivialif there are two possible worlds (w1, ..., wk), (v1, ..., vk) with f(w1, ..., wk) 6= f(v1, ..., vk).

All first order types which are no intensional functions are called extensions.

Intensional functions can be used to express the usual type constructors: classes can berepresented by their characteristic function, attributes by functions mapping to individuals,associations between objects by functions mapping to object identities.

In contrast to TIL we consider different kinds of intensional functions. The first kind isdefined in a non-transparent way. Typical examples are extensional objects such as operationsand predicates on the objectual base. Other non-transparent functions may be obtained fromexternal data sources. For example, the concept of a customer may be represented as a char-acteristic function over modalities ω (object identity) and τ (time): isCustomer : ω×τ → o.The valuation of this function may be determined by coupling the function with the customerdatabase of our Web shop: isCustomer(w, t) = true if and only if the object with identifierw is registered as a customer in our customer database at time t. Non-transparent intensionalfunctions may be evaluated but do not reveal the internal structure of the valuation or theirrelationship to other intensional functions.

The second kind of intensional function is built in a transparent way: an intensional con-struction is used to relate valuations of the function with valuations of other first order types.Tichy introduced four types of constructions: variables of type α, trivialization (using objectsin constructions), composition (application of values to a function) and closure (creation offunctions.)

Definition 5. We consider a single context c ∈ C. We organize intensional functions on stratain the following way:

• Operations and predicates on the objectual base (such as boolean connectives) as wellas all non-transparent intensional functions and all intensional functions imported fromcontexts other than c are considered to be functions on stratum 0.

• Let k be an intensional construction with free variables xi and a total mapping p : X →F from variables X = x1, ..., xn to intensional functions F = f1, ...fm where thestratum of fj is at most s− 1. The intensional function constructed by k is considered tobe a function on stratum s.

The layering of intensional functions implies the independence of intensional functionson lower strata from intensional functions on higher strata and especially from their usage inconstructions. This enables the determination of valuations of intensional functions on higherstrata by first fixing the valuations of intensional functions on lower strata. This restricts ex-pressiveness with respect to TIL. The strict monoton layering may be relaxed to constructionsout of functions from the same stratum. Functions can be lifted to higher strata by using iden-tity constructions, so we will allow the direct assignment of functions to strata higher thangiven by the definition.

Intensional constructions represent the terminological knowledge in traditional ontolo-gies. Constructors such as ‘is-a’, ‘part-of’, or ‘union-of’ represent a fixed, preselected, andnot configurable set of intensional constructions.

Building intensions by intensional constructions does not associate valuations of this in-tensional function with concrete objects. Beside intensional (T-box) reasoning based on con-structions, properties of valuations of intensional functions have to be revealed.

Definition 6. Let c be a context, F = f1, ..., fn a set of intensional functions, L a logicallanguage and T a theory with sentences from L formulating the knowledge about the valua-tions of F with respect to the layering of intensional functions in c. The tuple B = (F , T ) iscalled a concept in context c.

In our Web shop example we might consider intensional functions isCustomer : ω ×τ → o, defined in a non-transparent way as mentioned above. Assuming that a customerwill remain to be a customer for all the time we can express this in our small theory aboutcustomers:

isCustomer(w, t) =⇒ (∀t′ > t)(isCustomer(w, t′))

In another example shopping carts (isShoppingCart : ω × τ → o) might become anorder list (isOrderList : ω × τ × η → o for possibilities η):

isShoppingCart(w, t) =⇒(∃n′ ∈ η, t′ ∈ τ)(isOrderList(w, t′, n′))

With the definition of concepts we can finally construct content intensions:

Definition 7. Let F be a set of facets (e.g., according to the Zachman framework). A contentintension is a set of functions i : F → B mapping facets from F to concepts from B =B1, ..., Bn in the current context.

3 Query Facilities for Content Chunks

The definition of content chunks as combinations of data, intension, topic, and origin enablesseveral kinds of query facilities in content management systems. In the rest of the paper weuseD for the set of all structure definitions in the state of the CMS, I for the set of all definedintensions, T the set of all defined topic maps, and C for the set of all contexts. Typicalexamples for query functions are:

• Structural queries remain unchanged. Depending on the modelling language(s) the usualquery facilities are present, e.g., return all products from a certain product list.

• The function explain : D → 2I returns all intensions associated with a certain datainstance.

• sample : I → 2D returns all data instances associated with a certain intension.

• express : D × I × C → 2T returns all topic maps associated with the given data objectunder the given intension in the given context.

• understand : T × C → 2I×D returns data instances together with an intension for thegiven topic map and context.

• find : C → 2C returns the contexts which incorporated content from this context.

• T-box reasoning in a generalized fashion is available by evaluating the intensional con-structions. There is additional reasoning support, as depicted in Figure 4.

T3

concept A1

concept A2

context c 2context c 1

theory T1

theory T2

context c 3

construction

imported concepts

theory

Figure 4: Imported Concepts, Constructions, and Local Theories

Properties of a concept relevant within a context are expressed in small local theories.We do not assume that this theory is a complete description of the concept but revealsrelevant aspects. Concepts may be imported by other contexts while possibly differentproperties may become important. This is expressed by associating a different theoryto the corresponding intensional function. For example, in a certain context it may beimportant to have a conception about the time when a person became a customer. An

additional intensional function customerRegistrationDate : ω → τ may be introducedon a stratum lower than isCustomer while the local theory of the concept customer isenhanced by the constraint

(∀w ∈ ω)(∀t < customerRegistrationDate(w))(isCustomer(w, t) = false)

Evaluation of properties follows this construction strategy:

– First, the theory locally defined within the current context is used to prove the desiredproperty.

– If the local proof was not successful, the intensional construction is investigated andreasoning is delegated to original contexts where the concept was imported from.

It is obvious that reasoning in this fashion does not ensure decidability but enables thedelivery of precalculated relevant aspects which may not be accessible by pure intensionalreasoning.

4 Content Schemata

In Section 2 we defined the building blocks of content as arbitrary tuples (D, I, T, O). Con-sidering typical application scenarios of content management systems arbitrary associationscan be restricted to support additional content management functionality:

• There are relationships between intensions and structural properties. Reasoning about in-tensional properties is reflected by certain values of the associated data instances. Forexample, reasoning about prices should be reflected by appropriate attributes in the struc-tural definition. Non-transparently defined intensional functions must be directly com-puted from data.

• Information expressed in a topic map should be related to the underlying data and viceversa.

• Information can only be expressed or understood if there is an appropriate intension. Onthe other side, every intension should be expressible.

• Content which is imported from different contexts may not be completely revised buttransformed.

• Not every intensional construction should be allowed. To restrict complexity a config-urable set of construction templates has to be defined which incorporates the conceptualtheories from the sources to build theories in the target context.

Restrictions may be expressed by constraint relations between the four dimensions ofcontent chunks. To support content management functionality a mapping approach is better.There are three general tasks which have to be fulfilled during content management: content iscreated, selected content is delivered to the user, and content is exchanged between differentcontexts. Content creation in terms of our data model is the mapping of a topic map within acontext to combinations of an intension and a data instance. Content delivery is the mappingbetween a data instance and an intension within a context to a topic map. Content translationmaps content chunks from one context to another.

Definition 8. A content schema is a tuple (generate, deliver, exchange) with a functiongenerate : T ×C → 2D×I , a function deliver : I ×D×C → T , and a function exchange :D × I × T × C × C → D × I × T × C.

These functions are defined for each context separately. First, a set of base intensions isdefined. These base intensions rely on concepts (such as customer or shopping cart) whichmay be defined transparently or non-transparently. These base intensions are associated witha data schema (L, S) (where L is a modelling language and S is a schema expressed in thislanguage), a topic map template incorporating the data by associated data queries and a datatemplate defining the data instance by queries on the topic map.

Definition 9. Let k1, ..., kn be a set of intensional constructions. An intensional construc-tion template is a tuple (k1, ..., kn, p, m) with intensional constructions ki for each facet inthe intension specification frame, a parameter assignment specification p : X → B mappingvariables from B = x1, ..., xk to concepts from B = B1, ..., Bl restricting valuations forvariable substitutions in ki to the given concepts, and a merging function m which creates

• the logical theory T out of the theories associated to X ,

• the data schema out of the data schemata of X ,

• the topic map template out of the topic map templates of X , and

• the data template out of the data templates of X .

The definition of the data schema, the topic map template, and the data template impliesthe content generation and content delivery functions. The creation of the logical theory outof other concepts is given by a compatibility relation between models of these theories asdefined by the Local Model Semantics framework ([6]).

5 Semantic Wikis: Enabling Collaborative Content Annotation and Foundation

Communities form an interacting group of various actors in a common location, commonintension, and common time. They are based on shared experience, interest, or conviction, andvoluntary interaction among members with the intension of members welfare and collectivewelfare. They can have more or less structure and more or less committed members.

A wiki is a collaborative web site set up to allow user editing and adding of content by anyuser who has access to it. Wikis have changed access and habits of internet users. The rightand wrong usage of wikipedia is already widely studied in literature, e.g. the journal FirstMonday provides a detailed study of Web 2.0 in issue 13, March 2008 and of wiki misuse inmore than a three-score papers in various issues. The main functionality provided for wikis is

• management of content chunks with their structure, intention, origin and topic,

• annotation management for users depending on their role, rights and obligations,

• explanation, exploration and knowledge elicitation and gathering support for readers ofcontent chunks,

• presentation of information in a variety of ways and for a variety of environments,

• user management depending on the roles, functions and rights a user may have on thecontent,

• security and safety management for integrity of content and information, and

• history and evolution management that allows to show the development of the wiki andto restore previous versions.

We concentrate the remaining part of the paper to the first three main functionalities of wikisystems. These three functionalities are backed by our approach to semantic wikis. Presen-tation may also include generic adaptation to the user environment and features for markingcontent [?]. Wiki systems should integrate features that have been developed for customermanagement. Wikis are generally designed with a functionality that makes it easy to cor-rect mistakes. Since this functionality is a target for attacks on content and on the system,wiki systems are extended by security and quality management features. Thus, they providea means to verify the validity of recent additions, changes, corrections, replacements etc. tothe content. History and development information can be maintained through dockets [?] andand the diff feature that highlights changes between two revisions. Wiki systems are specialweb information systems. They support information seeking life cases [?, ?], are based onstoryboards for creation and consumption of information [?] and require a sophisticated userprofile and portfolio model [?].

Wiki systems share and encourage several features with generalized content managementsystems, which are used by enterprises and communities-of-practice. They are maintained,developed and enriched by communities of leisure, interest or practice. Community membersare allowed to instantly change the content (usually Web pages.) There are some minimalrequirements to the content chunk for wikis. The name or annotation of a content chunk istypically embedded in the hyperlink and interlinked with other chunks. Content chunks canbe partially created or edited at anytime by anyone (with certain limitations for protectedarticles). They are editable through the web browser. Their evolution history is accessiblethrough a history/versioning vie, which also supports version differencing (”diff”), retrievingprior versions and summary of most recent additions/modifications. Additionally, easy revertof changes is possible. We can extend this conception of Wikis and look forward on howfunctionality of Wikis may evolve by incorporating topically annotated and intensionallyfounded content.

Semantic wikis1 enhance content that is displayed in the web with fully considered andperfected concepts or verified knowledge and with user annotation or topics. It thus formalisesthe notion of wikis enhanced by ontologies [?], clarifies the knowledge basis and providesa basis for using data from the web in a form that corresponds to the user demands, theirinformation portfolio and their personal profile.

Using Communities for Content Generation

Content creation and content annotation are resource-intensive processes. Introducing a user-and usage-centric approach to content handling as presented in this paper, these processes canbe distributed through a social network, adapting the notions of the Web 2.0 initiative. Oneof the most severe requirement to wiki evolution is trustworthiness of the wiki. Everybody

1Our concept of semantic wikis should not be mistaken as a concept of Web 3.0. Web 3.0 or semanticweb aims in annotation of content on the basis of an ontology which is commonly accepted by a community.Proposals such as the Sematic MediaWiki add a fixed annotation to concepts similar to tagging in websites suchas delicio.us.

who uses wiki systems such as wikipedia observes that the competence level, the educationprofile, the work portfolio, the biases, the intensions (e.g., trolling) and the psychographicallevel of wiki creators has a huge impact on the quality of a wiki. Wikis that can be created byalmost everybody are typically of lower quality than those that can only be created by expertsin the area. As an example we accessed the entry ‘Dresden’ in wipipedia.org. In the average,each second sentence was not completely correct.

Wiki systems are considered to be special content management systems which allow theuser to instantly change the content (usually Web pages.) We can extend this notion to se-mantically enriched content:

• Content may be loaded into the system. This reflects the usual process of editing pagesin a Wiki. The load process results in stored data instances in the CMS which can be ex-tracted via search templates or associated with metadata in the usual sense (e.g., editorialparameters).

• Data instances may be associated with intensional descriptions such as copyrights andaccess rights.

• The user may annotate the content after searching for it, e.g., making recommendations onproducts in our Web shop example. A recommendation can be expressed by an additionalintension on the content chunk expressing that the current user interprets the data as aproduct recommendation. The local theory expresses the fact, that this user has boughtthese products or might buy these products in the future.

• Another user may explore the notion of a ‘recommendation’ from the context of the firstuser if he sees the same data instance and looks for associated intensions. Afterwards, thisuser may use this concept to annotate other data instances.

• Users may refine the local theory of a concept to incorporate knowledge which was hiddenso far.

• Users may associate new topic maps to content to create different (e.g., localized) ver-sions.

Modelling Wiki Functionality Based on Content Chunks

Beside supporting content generation and annotation by social networking, semantically anduser-specifically enriched content chunks are the base for modelling collaboration withina network of users. Collaboration is seen ([?, 21]) as a process of interactive knowledgeexchange by several people working together towards a common goal. Collaboration canbe characterized ([15]) by three facets: communication, cooperation, and coordination. Thecommunication facet defines the exchange protocols of content between users. The coopera-tion facet relies on the workflow of the collaboration by specifying who (actor) has to deliverwhich results to whom. The coordination facet defines the task management and synchroniza-tion between the collaborating partners to fulfill the cooperation goals.

Collaboration in social networks is usually defined in an implizit and decentralized way,so classical workflow management systems with fixed process definitions cannot be applied.The content data model defined in this paper can be used to annotate content with the specifiedcollaboration frame to express

• the history of content and content changes,• the purposes of content changes and content usage,• future tasks on content chunks and therefore• access rights on content chunks.

In the context of collaboration the specification of users becomes important. Conceptually,users are handled by a set of concepts A called actors (such as administrator, moderator,registered user, unexperienced user, guest user, etc.) Actors define roles of users and thereforeimply a grouping on the set of users. According to our definition of concepts each actor isassociated with a small logical theory expressing the properties which are common to allusers in the user group of the actor.

Communication between users takes place by topics. Topic map fragments have to bedefined in the content schema to express tasks in the collaboration frame characterized above.Figure 5 shows an example for a topic map concerning a product within our Web shop. Atypical task which can be done by users is to write a comment. The topic map for expressingthe product incorporates only comments fulfilling the intension of a proofread comment. Towrite a comment the topic map is merged with a topic map requesting comments from users.Occurrences of these topics are linked with dialog specifications that offer access to the CMSservices to fulfill the desired task.

... merge

topic mapconcerning the product task specific topic map

topics

intension

will be proofreadby the moderatorafterwards

commented product

product comment

can have

commentproduct

134

comment writer

text

product

134 ‘ Great!’ John Smith

provencomment

Figure 5: Topic Map with Task Specification

These topic map fragments which express task specifications are associated with an inten-sion according to our collaboration frame (who wrote a comment on which product.) in thecontent schema. Coordination is done by expressing obligations (e.g., adoptions of [18]) onthe content chunk in the local theory of the intension, e.g., a moderator has to proofread thecomment after the comment was written and before the comment is published. For that reasonthere is a topic map defining the proofreading task for moderators which can be merged withthe topic map associated with the intension of commented products. This merging processcreates the intension of a proofread comment, characterized by the fact in the local theorythat at a time point t the proofreading task took place:

isProofReadComment(w) :=(∃w′, t < now)(moderator(w, t) ∧ proofread(w,w′)

From Wikis to Semantic Wikis: Extended Functionality

The new query functionality on content with topic annotations and intensional foundationsenables additional high-level functionality for content management systems in social envi-ronments to support more sophisticated content management services:

• Sophisticated and automatically generated graphical user interfaces such as WYSIWYGeditors rely on a user-centric topic-based content annotation to provide information in theright fashion at the right time.

• Community services such as contributions to communities, joining communities, meet-ings, publications, or community organization as well as their integration can be inten-sionally modelled.

• Online collaboration support active discussion and interaction among participants as wellas content exchange.

• Content changes within a collaborating environment may be conflicting. Expressing thepurposes of changes may help to solve these conflicts.

• Task annotations support modelling of interaction scenarios and coordination facilitiessuch as schedules to enable project management functions.

• Secretarial functions such as filtering or ordering can be intensionally expressed and en-forced by appropriate topic map definitions.

• Blackboard facilities support tracing of tasks, members, schedules, and documents. Re-port functions may be incorporated for non-members of the community.

• Ad hoc (and implicit) communities are supported. Members can conduct their own com-munities, interests, tasks, and portfolios by defining private workspaces.

• Asynchronous as well as synchronous collaboration is supported depending on the han-dling of annotations and intensions.

6 Conclusions

In this paper we are introducing a data model for content management systems which handlescontent as associations between the data itself, the intension behind the data, the usage of dataand the origin of data. Content annotation is treated according to its purpose: terminologywhich is common sense in a community is shared in ontologies. Concepts which are onlyrelevant to certain users or in certain situations are definied locally and removed from theglobal ontologies to make reasoning about global terminology easier. Local concepts may beexchanged and adapted between different usage contexts. For that reason concepts are seennot only as notions from an ontology but as small logical theories. Additionally, intensionalannotation is separated from usage annotation to allow different expressions of the same dataunder the same intension.

Because of the reduced size of annotation ontologies, the local definition of conceptsand the suggested evaluation strategies according to the origin definitions of the content, theseparation of concerns within the data model allows a better automated reasoning supportthan simple (S, P, O) annotation frameworks although decidability as well as soundness andcompleteness of the reasoning process cannot be guaranteed. The user-centric approach to-gether with the facility of explicitly incorporating and exchanging hidden knowledge into

local theories behind a concept ensure the usability within known application scenarios whenautomated reasoning fails. Adding local and user-specific semantics to content chunks is aprerequisite for distributing content over social networks and therefore extends current Web2.0 technologies in a natural way. While today Wikis support open communities mainly inter-ested in free-form changes of content, Semantic Wikis may also support transaction orientedcommunities with the need of at least partially controlled collaboration.

References

[1] O. Benjelloun, A. Das Sarma, A. Halevy, and J. Widom. ULDBs: Databases with Uncertaintyand Lineage. In Proceedings of the 32nd International Conference on Very Large Data Bases,pages 953–964, September 2006.

[2] P. Bunemann, S. Khanna, and W.-C. Tan. Data Provenance: Some Basic Issues. Foundations ofSoftware Technology and Theoretical Computer Science, 2000.

[3] Dublin Core Metadata Initiative. Dublin Core. http://dublincore.org/, June 2007.[4] M. Duzı and P. Materna. Constructions. http://til.phil.muni.cz/text/constructions duzi materna.pdf,

2000.[5] G. Fiedler, A. Czerniak, D. Fleischer, H. Rumohr, M. Spindler, and B. Thalheim. Content Ware-

houses. Preprint 0605, Department of Computer Science, Kiel University, March 2006.[6] C. Ghidini and F. Giunchiglia. Local Models Semantics, or Contextual Reasoning = Locality +

Compatibility. http://citeseer.ist.psu.edu/481285.html, April 2000.[7] V. Haarslev and R. Moller. Racer: An OWL Reasoning Agent for the Semantic Web. In Proceed-

ings of the International Workshop on Applications, Products and Services of Web-based SupportSystems, in conjunction with the 2003 IEEE/WIC International Conference on Web Intelligence,Halifax, Canada, October 13, pages 91–95, 2003.

[8] V. Haarslev, R. Moller, and M. Wessel. Description Logic Inference Technology: LessionsLearned in the Trenches. In I. Horrocks, U. Sattler, and F. Wolter, editors, Proc. InternationalWorkshop on Description Logics, 2005.

[9] I. Horrocks, P. F. Patel-Schneider, and F. van Harmelen. From SHIQ and RDF to OWL: TheMaking of a Web Ontology Language. Journal of Web Semantics, 1(1):7–26, 2003.

[10] ISO/IEC JTC1/SC34. Topic Maps - Data Model. http://www.isotopicmaps.org/sam/sam-model/,June 2006.

[11] L. Reeve and H. Han. Survey of semantic annotation platforms. In SAC ’05: Proceedings ofthe 2005 ACM symposium on Applied computing, pages 1634–1638, New York, NY, USA, 2005.ACM Press.

[12] J. F. Sowa. Knowledge Representation, Logical, Philosophical, and Computational Foundations.Brooks/Cole, a division of Thomson Learning, Pacific Grove, California, 2000.

[13] J. F. Sowa and J. A. Zachman. Extending and Formalizing the Framework for InformationSystems Architecture. IBM Systems Journal, 31(3):590–616, 1992.

[14] B. Thalheim. Entity-relationship modeling – Foundations of database technology. Springer,Berlin, 2000. See also http://www.is.informatik.uni-kiel.de/∼thalheim/HERM.htm.

[15] B. Thalheim. Co-Design of Structuring, Functionality, Distribution, and Interactivity of LargeInformation Systems. Technical Report 15/03, Brandenburg University of Technology at Cottbus,2003.

[16] B. Thalheim. The conceptual framework to user-oriented content management. In EJC’06,Trojanovice, May 2006.

[17] TopicMaps.org. XML Topic Maps. http://www.topicmaps.org/xtm/, Sep 2006.[18] F. Voorbraak. The logic of actual obligation. An alternative approach to deontic logic. Philo-

sophical Studies, 55, Issue 2:173–194, 1989.[19] W3C. Web Ontology Language Overview. http://www.w3.org/TR/owl-features/, Feb 2004.[20] W3C RDF Core Working Group. Resource Description Framework (RDF).

http://www.w3.org/RDF/, 2004.

[21] Wikipedia. Collaboration. http://en.wikipedia.org/wiki/Collaboration, June 2007.[22] A. Woodruff and M. Stonebraker. Supporting Fine-grained Data Lineage in a Database Visual-

ization Environment. In ICDE, pages 91–102, 1997.[23] J. A. Zachman. A framework for information systems architecture. IBM Systems Journal,

38(2/3):454–470, 1999.

A Conceptual View of Web-Based E-Learning Systems

Klaus-Dieter Schewe1, Bernhard Thalheim2,Aleksander Binemann-Zdanowicz2, Roland Kaschek1,Thomas Kuss3, Bernd Tschiedel4

1Massey University, Department of Information Systems &Information Science Research CentrePrivate Bag 11 222, Palmerston North, New Zealand[k.d.schewe|r.h.kaschek]@massey.ac.nz2Christian Albrechts University KielDepartment of Computer Science and Applied MathematicsOlshausenstr. 40, D-24098 Kiel, Germany[thalheim|binemann]@is.informatik.uni-kiel.de3Freiburg University, Center for Cognitive Science, [email protected] Technical University at CottbusDepartment of Computer Science,Universitatsplatz 1, 03044 Cottbus, [email protected]

Abstract. Starting from a general framework for web-based e-learning systemsthat is based on an abstraction layer model, this paper presents a conceptual mod-elling approach, which captures the modelling of learners, the modelling of courses,the personalisation of courses, and the management of data in e-learning systems.Courses are modelled by outline graphs, which are further refined by some formof process algebra. The linguistic analysis of word fields referring to an applicationdomain helps to set up these course outlines. Learners are modelled by classifyingvalue combinations for their characteristic properties. Each learner type gives riseto intentions as well as rights and obligations in using a learning system. Intentionscan be formalised as postconditions, while rights and obligations lead to deonticconstraints. The intentions can be used for the personalisation of the learning sys-tem to a learner type. Finally, the management of data in an e-learning system isapproached on two different levels dealing with the content of individual learningunits and the integrated content of the whole system, respectively. This leads tosupporting databases and views defined on them.

Keywords: e-learning systems, course modelling, learner modelling, personalisa-tion, content management

Computing Reviews subject classification: [K.3.1] Distance Learning [H.5.3]Web-based Interaction [H.3.5] Web-based Services

1. Introduction

More and more education institutions aim at providing e-learning sys-tems, and more and more people take advantage of these offers as a

c© 2004 Kluwer Academic Publishers. Printed in the Netherlands.

EIT-Kluwer.tex; 22/10/2004; 19:32; p.1

2 K.-D. Schewe et al.

chance to advance their knowledge. It is envisioned that there is a hugemarket potential for learning technologies. Therefore, there is an in-creasing demand for adequate e-learning systems of highest standards,and a requirement for powerful techniques supporting agile and con-sistent learning. Expectations, chances and quality requirements arehigh. In particular, it still has to be proven that e-learning systemscan provide the same (or nearly the same) teaching quality as contactclasses with human teachers and adequate resources. In order to meetthese high expectations professional design and development supportfor e-learning systems will be a crucial success factor.

The challenge in e-learning addresses at least two parts: the dissem-ination of information and the concept of teaching. In this article weconcentrate on the first aspect, which reduces the problem to

− deciding, which information is to be presented in which form;

− enabling learners to chart individual routes through this informa-tion in accordance to their preferred learning style;

− adapting the information to different learner types.

We acknowledge that the concept of teaching is wider. For instance,didactics is more than outlining the content of a course. There isa considerable discussion in education regarding this wider perspec-tive. However, learning technology has not yet reached a stage, whereall the desiderata of e-learning systems can be supported. Our workemphasises the conceptual design of feasible systems and thus willdemonstrate what can already be done with available technology, whichis already more than is available in many systems on offer.

Our research interest concerns mainly those e-learning systems thatare offered via the world-wide web. These e-learning systems can beconsidered as specific web-based information systems with a focus onthe provision of knowledge to learners. In analogy to the B2C andB2B patterns that are well known in electronic commerce, we may usea pattern T2S for e-learning systems, where T represents a teacher asthe service provider and S represents a student as the service consumer.More precisely, following the classification pattern in (Thalheim andDusterhoft, 2000; Thalheim and Dusterhoft, 2001), we have a pattermTk2Sl with k standing for knowledge as the service that is provided, andl standing for learning as the major activity supported by the system.

In this article we start from a general framework for web-based e-learning systems that is based on an abstraction layer model (Kascheket al., 2003; Kaschek et al., 2004b). We present a conceptual modellingapproach, which captures the modelling of courses, the modelling of

EIT-Kluwer.tex; 22/10/2004; 19:32; p.2

A Conceptual View of Web-Based E-Learning Systems 3

learners, the personalisation of courses, and the management of data ine-learning systems. This exceeds the capability of approaches in (Atzeniet al., 1998; Ceri et al., 2003; Conallen, 2003), which are based ona hypertext-extension of traditional development methods for data-intensive systems, and approaches such as (Van Duyne et al., 2002),which concentrate only on the presentation aspect.

Many learning systems that are currently offered are based on cur-riculum sequencing, where the learner has to follow a well-definedsequence of learning steps. To some extent this follows the principlesof didactic preparation as described in detail in (Kerres, 2001). Thisis not always adequate, as learning should be better based on activerequest, i.e. e-learning systems should support self-organised learningon demand. Systems should restrain the learners as little as possible,and offer instead as much support as possible to support their indi-vidual learning styles. Consequently, it is important to anticipate thebehaviour of learners and to design systems according to their needs.This includes outlining courses in such a way that the sequence oflearning units, and the style of presentation is personalised to thetype of learner. More abstractly speaking, for each learner type wehave to anticipate how they will navigate through the system. Eachpossible sequence of learning units followed by a learner correspondsto a particular course outline, so the most challenging problem is todetermine these sequences and to describe them in an abstract andintegrated way. We will show that this can be modelled by some formof process algebra.

This approach is similar to storyboarding in web information sys-tems (Binemann-Zdanowicz et al., 2004; Kaschek et al., 2004b; Scheweand Thalheim, 2001), which has been applied to e-commerce (Binemann-Zdanowicz et al., 2003a; Schewe et al., 2002; Thalheim et al., 2003),e-learning (Binemann-Zdanowicz et al., 2003b; Jantke et al., 2003;Rostanin et al., 2002), and information services (Feyer et al., 2000).The SiteLang process algebra has been introduced in (Thalheim andDusterhoft, 2001). A short description of outline graphs also appearedin (Binemann-Zdanowicz et al., 2004).

We also address the problem how to discover the best outline graphs.We observe that an atomic learning unit is always centered around asingle learner activity by the learner, and this activity can be describedby a verb. Therefore, the idea is to analyse verbs. Fortunately, thenumber of verbs in a language such as English is relatively small, soit is not an intractable approach. In particular, we suggest to analysethe word fields of verbs, which combine aspects of morphology, i.e. theforms of the written or spoken word, phonology, i.e. the sound of thespoken word, syntax, i.e. the construction of sentences using the word

EIT-Kluwer.tex; 22/10/2004; 19:32; p.3


forms, semantics, i.e. the meaning(s) of the word, and pragmatics, i.e.the usage of the word in written or spoken language. This gives riseto determining the data needed to perform the activity, the guidancehow to perform the activity, and the explanation of the effect of theactivity.

The use of linguistic analysis for the design of web informationsystems has already been proposed in (Ravenscroft and Matheson,2001; Thalheim and Dusterhoft, 2004) based on computational lin-guistics (Hausser, 2001). In addition, the use of metaphors has beenproposed in general in (Thalheim and Dusterhoft, 2000) and investi-gated in (Schewe et al., 2002) for applications in e-banking, and in(Rostanin et al., 2002) for e-learning.

Furthermore, the quality of e-learning systems crucially depends onthe designers’ understanding of the learners and their needs. Therefore,it is necessary to first obtain an idea of the expected learners. This maylead to certain learner profiles. Such profiles may be determined by thedifferent goals of the learners, their different intentions, their differentbehaviour, their information needs, their levels of required support, etc.However, we go further and discuss dimensions that are closer to theparticular interest of modelling learners instead of users of arbitraryweb information systems or banking customers. However, similar tothe existing work found in the literature we will obtain a learner space.We then discuss how points in this space can be combined into learnertypes.

Our approach adopts the whole-person approach from (Martinez,2001) and the work on user profiling by Kaschek et al. (Kaschek et al.,2004b) as far as we base it on learner dimensions. Also (Hubscher,2001; Merrill, 1983; ONTO-LOGGING Consortium, 2002) discusseslearner modelling. A short description of learner modelling appearedin (Kaschek et al., 2004a).

Furthermore, each learner type will give rise to intentions as wellas rights and obligations in using a learning system. Intentions canbe formalised as postconditions, while rights and obligations lead todeontic constraints. The intentions can be used for the personalisationof the learning system to a learner type. We will discuss personal-isation based on subgraphs, but there are other techniques such asproviding different granularities through splitting and merging units.Reduction to subgraphs can be formally supported by Kleene algebraswith tests (Kozen, 1997). Splitting of units based on cohesion pre-orders was investigated in (Feyer et al., 2000) and briefly describedin (Binemann-Zdanowicz et al., 2004).

Finally, we address the problems associated with the system’s con-tent, and partly with its functionality. We assume that learner types

EIT-Kluwer.tex; 22/10/2004; 19:32; p.4


have been determined, and a course outline consisting of learning unitsand navigation links between them has been set up. While these alreadydetermine the functionality in a rough way, our interest is looking at thesystem from a more systems-oriented perspective and asking how wecan support the learning units. As e-learning systems are data-intensivesystems, we adopt the approach by Feyer et al. in (Feyer et al., 2000),which approaches the data management problem in web informationsystems in an integrated way. According to this we obtain two levels ofdata management: a global level that is captured by a global databaseschema, and a local level that is captured by views, which representthe data content of the learning units.For both levels conceptual datamodels such as the Higher-Order Entity-Relationship model (Thalheim,2000) are useful.

Among the more specific literature on e-learning, especially web-based e-learning systems very little attention is paid to the aspect ofcontent modeling. Bergstedt et al. in (Bergstedt et al., 2003) study sim-ilarities between content management systems (CMSs) and e-learningsystems and conclude that using CMSs in e-learning would improve thequality of e-learning systems. The work in (Qu and Nejdl, 2003; Sessinket al., 2003) investigates the metadata standard SCORM. Sessink etal. in (Sessink et al., 2003) identify the need for supporting databasesthat are not in the SCORM 1.3 standard. Qu and Nejdl in (Qu andNejdl, 2003) use XML to encompass incompatibilities between RDFand SCORM metadata. Mohan and Brooks in (Mohan and Brooks,2003) address the problem of discovering learning objects from thesemantic web and argue that this will improve learning. However, thisdepends on the semantic understanding of the web, which despite themerits of the research efforts in this area is still beyond reality. A shortdescription of our approach to data modelling in e-learning systemsappeared in (Rostanin et al., 2004).

We present our general framework in Section 2. Then we addressthe modelling of courses via outline graphs in Section 3, followed by adiscussion of linguistic analysis in Section 4 as a means for setting upadequate course outlines. Section 5 is then devoted to the classificationof learners following the whole-person approach from (Martinez, 2001).In addition, we discuss intentions, rights and obligations that are as-sociated with learner types. These link the learner types to the courseoutlines. Furthermore, intentions of learners can be used to personaliselearning system to the needs of the learners. This will be describedin Section 6. Finally, in Section 7 we describe how the data in thevarious learning units can be modelled by using a two-level approach.We conclude with a brief summary in Section 8.

EIT-Kluwer.tex; 22/10/2004; 19:32; p.5


2. General Design Considerations

E-Learning Systems are large web-based information systems, and assuch they share a lot of similarities with web information systems ingeneral. Consequently, systems can be largely designed along the sameprinciples that apply to traditional information systems. However, aparticular focus has to be put onto the fact that the system will beweb-based, and that its major purpose is to support learning.

This leads to important questions such as “Who are the learners?”,“Which learner intentions and behaviour shall be supported?”, “Whichtechnical devices will be used by the learners?”, etc. We will now lookat these questions into more detail focussing on five different aspects:purpose, usage, content, functionality and presentation.

2.1. Aspects of E-Learning Systems

The purpose aspect is a very general one centered around a missionstatement for the system. The primary question is: what is the purposeof the system? In e-learning systems the major purpose may be toprovide learning material to students including useful hints and links tosupplementary literature. A second related question is this: Are thereseveral minor purposes as well? In commercial e-learning systems aminor purpose may be to attract students to book further courses, inwhich case the system would be a mixture of an e-learning and an e-commerce system. A third question associated with purpose concernstheir time-scale. Some of the intentions may be long-term others short-term.

Once some clarity with respect to the purpose of the e-learningsystem has been obtained, the question arises by whom and how thesystem will be used. As a web-based system it is usually open, so itis important to anticipate the behaviour of the learners. Therefore, itis necessary to first obtain an idea of the expected learners. This maylead to certain learner profiles. Such profiles may be determined bythe different intentions of the learners, their different behaviour, theirinformation needs, their levels of required support, etc.

So, the activity of learner profiling will lead to a list of profilesof expected learners who are to be supported by the system. Thisinfluences the content of the system’s pages, their logical organisation,the enabled navigation links between these pages, and maybe even theirpresentation. More abstractly speaking, for each learner profile we haveto anticipate how they will navigate through the system. Each possiblesequence of pages followed by a learner corresponds to a particular

EIT-Kluwer.tex; 22/10/2004; 19:32; p.6


course outline, so the most challenging problem is to determine thesesequences and to describe them in an abstract and integrated way.

The usage of an e-learning system depends on whether the controlof the learning process is left to the learner or the system. In bothcases, however, it is assumed that the learners are willing to learn andmatch the required prerequisites. Learners normally enter the systemmore than once continuing a specific learning programme. This requiressome authentication mechanism, especially if the learning progress iscontrolled by the system. Quality criteria are set by the teaching qual-ity, and in the end, by the increase of knowledge on the side of thelearners.

The content aspect is central to the development of the system, asit concerns the question: “Which information should be provided?”,which is coupled with the problem of designing an adequate database.However, the organisation of data that is presented to the learner viathe web-interface is significantly different from the organisation of datain a database. So, organising the data content of the system means toinvestigate the decomposition, structuring and classification of data insuch a way that the course outline(s) can be adequately supported.

Thus, modelling the content of a system has to be addressed on atleast two levels: a logical level leading to databases, and a conceptuallevel leading to the content of pages. Both levels have to be linkedtogether. Furthermore, in both cases abstraction mechanisms shouldbe used. While such abstraction mechanisms are established in the areaof databases, they are still a matter of research for web-based systemsand in particular for e-learning systems.

Modelling content must take into account that information must bepresented in different ways to different learners. This depends on thelearner profile, the communication channel, and the available devices.Modelling content has to provide mechanisms to tailor the contentautomatically according to these parameters.

The functionality aspect is coupled with the question, whether thee-learning system should be passive or active. A passive system wouldonly allow a learner to navigate through the pages without any activity.In these cases the major problem associated with functionality is to setup an adequate navigation structure.

In an active system, however, information would also be requiredfrom the learner. From a conceptual point of view, the main purposeof functionality modelling is to identify functions that are availableto support the activities of the learners, which were identified in thecourse outline. Such functions can be system-specific functions in orderto process learner input or general support functions.

EIT-Kluwer.tex; 22/10/2004; 19:32; p.7


functionality specification

repositoryspecification

contentspecification unit

specification

Implementation Layer

Presentation Layer

Tutorial Layer

Didactic Layer

Definition Layer

Implementation

Style Definition

Conceptual Modelling

Course Outline

?

?

?

?

Figure 1. Abstraction Layers in Web-based E-Learning Systems

The functionality of e-learning systems mainly supports the nav-igation through the learning material. In contrast to other types ofweb-based systems, this navigation is a long-term process with usuallymany interruptions. More sophisticated systems would provide system-driven repetition and feedback. Also, personal information needs canbe supported by providing an interface to e-mail.

Finally, the presentation dimension concerns the realisation by webpages. This depends on the support of technical end-devices such ascomputer screens, television, cell phones, etc. and set layout prefer-ences. This is partly done in accordance to results from learning psy-chology trying to direct the attention of the learners to the most rele-vant parts first. This will give them the impression of a well-organisedsystem.

2.2. Abstraction Layers in E-Learning Systems

In this section we present a framework for the design of e-learningsystems. The framework is based on an Abstraction Layer Model , whichis illustrated by Figure 1. From top to bottom we identify a definitionlayer, a didactic layer, a tutorial layer, a presentation layer, and animplementation layer.

The general ideas of this model are as follows. We identify severallayers of abstraction:

− The top layer is called the definition layer . It is used to describethe system in a general way: What is the purpose? What are thecourse goals? Who are the expected learners?

EIT-Kluwer.tex; 22/10/2004; 19:32; p.8


− The next lower layer is called the didactic layer , which is used toconcretise the ideas gathered on the definition layer. This meansto get a clearer picture of the different learners and their profiles.The major part of this layer, however, deals with the outline of thecourse. That is to identify course units and paths through theseunits.

− The central layer is the tutorial layer . Whilst the didactic layerdid not pay much attention to technical issues, they now comeinto play. The various units appearing in the course outline haveto be analysed and integrated, so that each unit can be supportedby a combination of some data content with some functionality.

− The next lower layer is the presentation layer which is devoted tothe problem of associating presentation options. Finally, the lowestlayer is the implementation layer , which addresses all aspects ofthe physical implementation.

On each layer except the definition layer we identify two dimensionsfor the description of the system: focus and modus. The focus dimen-sion distinguishes between local and global components; the modusdimension distinguishes between static and dynamic components.

Global and static components will be addressed by a repository spec-ification, which covers all aspects of central data storage and retrieval.Global and dynamic components will be addressed by a functionalityspecification, which covers all operation on the stored data.

Local and static components will addressed by a content specifica-tion, which covers all aspects of the content of course units. Finally,local and dynamic components will be addressed by a unit specification,which covers the learner activities associated with the learning units.

Each layer is associated with layer specific modelling tasks. Thetransition from the definition to the didactic layer is associated with de-veloping the course outline(s) and the identification of learner profiles.The transition from the didactic layer to the tutorial layer is associatedwith conceptual modelling, which addresses database modelling, opera-tions modelling, view modelling, and unit content modelling. This addsmore details to the design, as we look at single course units, whereas thecomposition of the course as such has been dealt with on the didacticlayer.

The transition to the presentation layer is associated with the defini-tion of presentation styles. Finally, the transition to the implementationlayer is associated with all implementation tasks.

EIT-Kluwer.tex; 22/10/2004; 19:32; p.9


Introduction

Learner Profiling

Course Outlining Data Management

Style Definition

Implementation

?

??

?

?

-

Figure 2. Course Outline (sketch)

3. Course Modelling

Let us now look at ways to describe the navigation of learners throughan e-learning system, for which we may exploit finite, directed graphsfor this purpose.

Thus, an outline graph is a finite, directed graph G = (V,E), i.e. Vand E are finite sets with E ⊆ V ×V . The vertices, i.e. the elements ofV , are called learning units, and the edges, i.e. the elements of E arelinks between these units.

Take for example a course dealing with e-learning systems. Thenwe might have learning units such as Introduction, Learner Profiling,Course Outlining, Data Management, Adaptivity, Style Definition, andImplementation. Figure 3 gives a rough picture of the correspondingcourse outline with links naturally represented by edges.

3.1. Outline Graphs

With each learning unit u ∈ V we associate a view Cu describing thedata content of this learning unit. In addition, we may also associatelearner types LT u

1 , . . . , LTunu

with the learning unit. These indicate thatthe learning unit is suitable for learners of this type only. We willdescribe learner types in Section 5.

Each link ` ∈ E from u1 to u2 corresponds to a possible transitionfrom the source learning unit u1 to the target learning unit u2. Such atransition should be triggered by an action initiated by the learner. Thisaction can simply be a navigation, but in general we may think of morecomplicated actions. Therefore, each link is associated with the name of

EIT-Kluwer.tex; 22/10/2004; 19:32; p.10


an action that can be issued in that learning unit. In addition, it is alsoassociated with a data type expressing the information communicatedfrom learning unit u1 to learning unit u2.

Actions on a learning unit may depend on the successful completionof the learning unit by the learner. According to our view this is partof the action specification, and should be left for further refinement ofthe outline.

From a more conceptual point of view we model learner interac-tion with an e-learning system according to two primitives: transitionbetween learning units and using the functionality offered at a givenlearning unit. This allows for a two-step modelling procedure to beapplied. First at a coarse-grained level learning units and navigationlinks are modelled. Then in a refinement step the actual activities ofthe the learners are added. This procedure allows for a good separationof concern with respect to personalisation and localisation.

At first the usage of the system by a particular learner type ismodelled. This already reduces the complexity of the problem. Thenthe learner behaviour is dealt with locally, i.e. with respect to a givenlearning unit, which further reduces complexity. The price for thisadvantage is the need to integrate the various outlines and the dataused within them.

Instead of emphasising the transitions between learning units andthe triggering learner activities as sketched in Figure 3, we may wantto emphasise the data communication between learning units. As weassume that for any two learning units ui, uj ∈ V there is at most onelink from ui to uj , the outline graph can be represented by its adjacencymatrix A = ai,j1≤i,j≤n with

ai,j =

1 if there is a link from ui to uj

0 else

Using this representation has the advantage that we get rid of cross-ing labelled edges in diagrams. However, we use it in a modified form.

First we use a table T with n columns and rows to represent thematrix. We further fill the table’s cells T (i, i) for all i = 1, . . . , n withthe name of learning unit ui and fill the table cell T (i, j) with the labelsattached to the edge from ui to uj .

The learner types associated with the learning unit ui will be addedat the right side of the table in the form of an additional column. Thisextended adjacency matrix will be called the communication matrix ofthe course outline.

Figure 3.1 contains a sketch of the communication matrix for thecourse outline from Figure 3. We abbreviated the names of the learning

EIT-Kluwer.tex; 22/10/2004; 19:32; p.11


Intr •

LP

•

•

CO

•

•

DM •

SD •

Impl

LTx

LTx

LTx

LTx

LTx

LTx

Figure 3. Communication Matrix (sketch)

units in the obvious way. As we did not yet indicate, which learner activ-ities trigger the navigation links, we only put a • into the correspondingcell of the matrix. Similarly, as we left the learner types open so far,we could only add LTx into the corresponding cell of the matrix.

3.2. Algebraic Modelling of Course Outlines

Let us take now a closer look at the process algebra SiteLang from(Thalheim and Dusterhoft, 2001). So, let S = s1, . . . , sn be a set oflearning units, and let A = α1, . . . , αk be a set of (atomic) actions.Furthermore, assume a mapping σ : A → S, i.e. with each action α ∈ Awe associate a learning unit σ(α).

This can be used to define inductively the set of learning processesP = P(A,S) determined by A and S. Furthermore, we can extend σto a partial mapping P → S as follows:

− Each action α ∈ A is also a learning process, i.e. α ∈ P, and theassociated learning unit σ(α) is already given.

− 0 and 1 are learning process, for which σ is undefined. 1 is acontent-less learning process, while 0 stands for a failed learningprocess.

− If p1 and p2 are learning processes, then also the sequence p1 · p2

is a process. Furthermore, if σ(p1) = σ(p2) = s or one of the pi

is 1, then σ(p1 · p2) is also defined and equals s, otherwise it isundefined.

EIT-Kluwer.tex; 22/10/2004; 19:32; p.12


− If p1 and p2 are learning processes, then also the choice p1 +p2 is alearning process. Furthermore, if σ(p1) = σ(p2) = s or one of thepi is 1, then σ(p1 + p2) is also defined and equals s, otherwise it isundefined.

− If p is a learning process, then also the iteration p∗ is a learningprocess with σ(p∗) = σ(p), if σ(p) is defined.

− If p is a learning process and ϕ is a boolean condition, then theguarded learning process ϕ ·p and the post-guarded learning processp · ϕ are learning processes with σ(ϕ · p) = σ(p · ϕ) = σ(p), if σ(p)is defined.

We also use conjunction ϕ · ψ, disjunction ϕ + ψ and negation ϕfor boolean conditions. Furthermore, let 1 represent ‘true’ and 0 ‘false’.Then the set P of learning processes carries the structure of a Kleenealgebra with tests (Kozen, 1997), i.e. the following rules hold:

− + and · are associative, i.e. for all p, q, r ∈ P we must have p +(q + r) = (p+ q) + r and p(qr) = (pq)r;

− + is commutative and idempotent with 0 as neutral element, i.e.for all p, q ∈ P we must have p+q = q+p, p+p = p and p+0 = p;

− 1 is a neutral element for ·, i.e. for all p ∈ P we must have p1 =1p = p;

− for all p ∈ P we have p0 = 0p = 0;

− · is distributive over +, i.e. for all p, q, r ∈ P we must have p(q +r) = pq + pr and (p+ q)r = pr + qr;

− p∗q ist the least solution x of q + px ≤ x and qp∗ is the leastsolution of q + xp ≤ x, using the partial order x ≤ y ≡ x+ y = y.

We further adopt the convention to write pq for p · q, and to assumethat · binds stronger than +, which allows us to dispense with someparentheses. It is also known that the double use of · for sequence andconjunction and of + for choice and disjunction, respectively, does notcause any problems. Obviously, if we restrict to boolean conditions only,then the laws of Boolean algebras apply to conjunction, disjunction andnegation.

Furthermore, the association of learning units with learning pro-cesses implies that we also have sorts. As processes associated withdifferent scenes express concurrency, we claim that p1p2 = p2p1 holdsfor all p1, p2 ∈ P with σ(p1) 6= σ(p2), which leads to a many-sortedKleene algebra with tests (Schewe and Thalheim, 2004).

EIT-Kluwer.tex; 22/10/2004; 19:32; p.13


Example 1 The following expression may express a course outlinewith actions αi and conditions ϕi.

α1((ϕ0α2 + ϕ1α3(α5 + 1)ϕ3 + ϕ2α4(α6 + 1)ϕ4)∗ϕ5)(α7ϕ6 + α13ϕ7)(ϕ6α8(α8 + 1)α9α10α11α12ϕ8+

ϕ7α8α∗8α14α15α

∗16α11α17(ϕ12α18α19)∗ϕ12α18ϕ9)α20(ϕ10 + ϕ11)

In addition we may have the following assignment of learning unitssi to the actions

σ(α1) = s1 σ(α2) = s2 σ(α3) = s2 σ(α4) = s3 σ(α5) = s2




with the learning units

s1 = Introduction s2 = Learner Profiling s3 = Course Outlinings4 = Data Management s5 = Style Definition s6 = Implementation

4. Linguistic Analysis

Linguistic analysis summarises the activities and techniques that areapplied to analyse natural language descriptions of learners’ activities.The major source of information used for developing e-learning systemsis a description of curriculae, which may be delivered in the form oftexts or verbally.

Linguistic analysis takes such natural language descriptions anduses them for analysing the activities of the learners: Which are theseactivities? Does the description indicate any sequencing or continua-tion? What data is needed for or used by the activities? What are therelationships between these data?

As learner activities can be described by verbs, we suggest to anal-yse the corresponding word fields. We will show that word fields area valuable source for centering the outline graph around the centrallearner activities.

EIT-Kluwer.tex; 22/10/2004; 19:32; p.14


4.1. Word Fields

According to (Hausser, 2001) a word is an abstract concept, which inorder to become concrete needs a word form carrying the grammaticalvariants. Word fields are a much more general notion than word forms.Word fields combine different aspects:

− morphology, i.e. the forms of the written or spoken word,

− phonology, i.e. the sound of the spoken word,

− syntax, i.e. the construction of sentences using the word forms,

− semantics, i.e. the meaning(s) of the word, and

− pragmatics, i.e. the usage of the word in written or spoken lan-guage.

Our restriction to written language communication makes consider-ing phonology obsolete. Under this premise we understand a word fieldto consist of its intext, its context, its semantics and its pragmatics.

− The intext combines morphology and syntax. We are mainly in-terested in the latter one, especially for verbs. In this case we mayask for the basic syntactical form, various mandatory and optionalarguments, variants of the arguments, extensions to the basic syn-tax, and relationships and constraints between the arguments ofthe word when it is used in sentences.

For instance, the verb “to teach” uses a mandatory argument“something” and an optional argument “to somebody”. The ba-sic syntactical form “Someone teaches something to somebody”expresses an action, specifies the actor and the receiver, and anobject used in the action.

− The context refers to application areas. According to the contextwe may identify related words, concepts related to the arguments,categories of actors and actions, and further constraints.

For instance, in a learning context the verb “to teach” may beused in a sentence such as “The teacher teaches e-commerce tothird-year students”. In this case we conclude that the object ofthe action is subject to an assessment of whether (s)he has learntand understood the learning object “e-commerce”. It also impliesthat a follow-on action, i.e. the study by the student, is expected.

EIT-Kluwer.tex; 22/10/2004; 19:32; p.15


− The semantics refers to the meaning of a word in a particularcontext. For example, the already used sentence “The teacherteaches e-commerce to third-year students” includes the meaningof the teacher delivering and explaining material and the studentworking through it and reflecting it in a critical way.

− The pragmatics refers to how the word is used in the applicationcontext.

4.2. Word Fields and Outline Graphs

Using word fields for the design of dialogues has already been suggestedin (Thalheim and Dusterhoft, 2004). We suggest a compositional ap-proach to outline graph design based on generalised phase structuregrammars with applicability rules such as immediate dependence andlinear precedence rules (Hausser, 2001).

We propose to exploit word fields in an analytic way starting withthe syntactic analysis of sentences. For this of course we also needa sophisticated parsing theory (Hausser, 2001) to obtain the syntaxtrees. Within such a tree we can identify the main verb and the usedarguments. The verb can be used as a descriptor for the main activity.The word field of the verb will tell us, which arguments are expected.This will give us hints for detecting the required information and thelearners involved.

Finally, the various constraints indicate relationships to other ac-tivities, e.g. follow-on activities described by other sentences or re-lationships to objects used in these other sentences. This gives riseto determine links in the outline graph and the communicated dataassociated with these links. It may also indicate that the learning unitis still too broad and needs to be refined. For instance, we may exploitthe specialisation of verbs or objects that are used as their argumentsto the refinement of learning units.

4.3. Metaphors

According to (Thalheim and Dusterhoft, 2000) metaphors are languageexpressions used in an uncommon language context. Properly applied,they can simplify the task of communicating complex ideas and resultin enthusiastic users.

We already pointed out that generating the best learner supportdepends on having a model of the learners, i.e. being able to grouplearners into reasonably constructed learner types. The e-learning sys-tem must be designed such that it stimulates questions by the learners

EIT-Kluwer.tex; 22/10/2004; 19:32; p.16


that can be answered relatively easily. Metaphors can help in this re-gard. They can help learners to understand what they can, should, orshould not attempt to do next, and allow the learner to master his/herown learning style.

Human communication is largely metaphorical. It is likely that thelack of metaphors in traditional human-computer interaction is respon-sible for some of the problems of this interaction. Improving human-computer interaction by augmented use of metaphors has the poten-tial to reduce the number of communication barriers as well as theirimplications.

Recall that computer applications have at least three language levels:

tool language: This is the language in which the learner interfacesignals the customer the semantics of its functionality.

discourse language: This is the language used in the universe ofdiscourse to identify problems, their solutions and quality criteriaof all of them.

metaphor language: This language helps the learners understandthe state of affairs in the universe of discourse and what interfacefunctions can be used to achieve their goals.

The generation of metaphors could be supported by logically decom-posing the learning space into a small number of domains that appearhomogeneous with respect to the offered functionality. This permitsrelating the domains to learner types and expected learner activities.The generation of metaphors appears then as being connected to find-ing characterising names for the relationships bewteen leaner types,expected learner activities and domain.

5. Learner Modelling

In this section we focus on the learner model following an inspiration bythe whole-person-approach from (Martinez, 2001). In this approach acomprehensive set of human factors for learner modelling is considered.This leads to conceptual modelling of learners by learner profiles, i.e.value combinations for a list of learner characteristics. A complete listof such characteristics will of course depend on the learning domain.Therefore, we concentrate on selected reasonable characteristics.

EIT-Kluwer.tex; 22/10/2004; 19:32; p.17


5.1. The Learner Space

We follow (Martinez, 2001) in considering cognitive, conative, and affec-tive personality aspects of individuals as key regarding the outcomes oftheir learning processes. These psychological aspects impact the learn-ing outcome. Increasing the learning performance of most learners, ifbased on adaptation of e-learning systems to learners, thus appears torequire learner characteristics being identified that relate to the men-tioned personality aspects. We shall distinguish between characteristicsof the learning style, the learner as a person, the learning task at hand,and the preferred examination style. The following lists are assumed tobe non-exhaustive.

For the learning style we have the following general characteristics:

Guidance: The degree to which the learner prefers being guided ornot in the learning process.

Visual Modality: The degree to which the learner prefers a presen-tation in visual manner. We follow (Rostanin et al., 2002) in usingthe characteristic modality.

Auditory Modality: The degree to which the learner prefers apresentation in auditory manner.

Textual Code: The degree to which learners with visual learningstyle prefer having access to text.

Illustrational Code: The degree to which learners with visual learn-ing style prefer having access to images.

Example: The degree to which the learner prefers learning deduc-tively or inductively.

Characteristics that refer to the learners are:

Persistency: The degree to which the learner in general can or cannotmentally cope with new material.

Retentivity: The degree to which the learner in general can or cannotmemorize learned material.

Computer literacy: The degree to which the learner has or has notacquired skills in using modern computing infrastructure for a taskat hand.

Curiosity: The degree to which the learner in general is or is not fondof learning new material.

EIT-Kluwer.tex; 22/10/2004; 19:32; p.18


Learning task related characteristics are the following:

Prerequisites: The degree to which the learner has or has not learntthe required subjects.

Performance: The degree to which the learner has or has not per-formed well regarding background subjects, required subjects orsubjects in general.

Motivation: The degree to which the learner is or is not interestedin efficiently mastering the learning task at hand.

Confidence: The degree to which the learner believes to be capableor incapable of successfully mastering the learning task.

Characteristics that apply to the examination style are:

Kind: The degree to which the learner either prefers his knowledgeor his skills or a combination of both being checked.

Control: The degree to which the learner prefers his increment inknowledge or skills being checked.

Evaluation strategy: The degree to which the learner prefers hissolution to an examination problem being evaluated right after itssubmission or whether he / she prefers all problem solutions beingevaluated at the same time.

Feedback: The degree to which the learner prefers receiving full ex-planations of the assessments of his / her problem solutions orwhether he / she prefers being notified of the correct results only.

We believe that the chosen grouping of characteristics is obviousand that the characteristics we have defined are obvious and plausiblecandidates for characteristics in real learning tasks. We further believethat at least extreme scores in scales for the characteristics result inmanifest options in designing and presenting learning units. We thusdo not discuss these issues here in more detail. Clearly, persistency andretentivity are cognitive; curiosity and motivation are conative; andguidance, evaluation strategy and feedback are affective personalityaspects. Thus indeed our characteristics for the key personality aspectsgives at least a hint on how to break them down and make use of thesefor e-learning systems.

EIT-Kluwer.tex; 22/10/2004; 19:32; p.19


5.2. Formalising the Learner Space

In order to describe learner profiles we identified general and subject-specific characteristics of learners. So formally, we obtain a non-emptyset C of learner characteristics. In addition, for each of these learnercharacteristics we obtain a linearly ordered set of values, which fromnow on will be called the scale of the characteristic. Formally, for eachcharacteristic c ∈ C we have a scale S(c) and a linear order ≤ definedon it.

For example, if the characteristics are abstraction, perception andmemory, we may use a numerical scale, say the integer interval [0, . . . , 5],for each of them.

− A low value for abstraction indicates a learner who needs moreconcrete examples in order to be able to understand the learn-ing material, whereas a higher level indicates a better ability ofabstract thinking.

− A low value for perception indicates a need for visualisation, whilea higher value indicates that the learner can cope with textual andmaybe even formal writing.

− A low value for memory indicates that the learner often needs toreview larger parts of the learning material, whereas a higher valueindicates that this is not needed or that the learner only needs abrief reminder in a very condensed form.

The learner space LS is the cartesian product of the scales, i.e.

LS =∏c∈C

S(c).

Thus, each element of the learner space is a tuple, and each compo-nent of this tuple indicates the value of a certain learner characteristic.That is, the learner space captures our knowledge about the differentcombinations of learner characteristics.

Figure 5.2 illustrates a learner space with two characteristics, i.e.C = c1, c2, and the scales S(c1) = v1, v2, v3, v4 with v1 < v2 <v3 < v4, and S(c2) = v′1, v′2, v′3 with v′1 < v′2 < v′3. The learner spaceLS = S(c1)× S(c2) contains 12 tuples.

5.3. Learner Types

Thus, the learner space is an adequate way to represent the differentlearners. However, we have also seen that there are not so few char-acteristics of learner types, and for each of them we obtain quite a

EIT-Kluwer.tex; 22/10/2004; 19:32; p.20


-

6

c1

c2

v1 v2 v3 v4

v′1

v′2

v′3

LT1

LT4

LT3

LT6

LT5

LT2

Figure 4. Convex Learner Types

few different values to be taken into account. This bears the risk of acombinatorical explosion of the learner space.

In order to personalise a system to learners, we would have to param-eterise each learning unit and each navigation link by the elements ofthe learner space or provide functions that map units and links betweenthem to a personalised course outline. This is only feasible, if either thelearner space is small or the personalisation will be the same for manyelements of the learner space.

For instance, if we have 10 different characteristics and each comeswith only two different values in their scale, then we would alreadyhave 210 = 1024 elements in the learner space. This is far too much.

Therefore, we have to bundle points in the learner space, i.e. insteadof attempting to personalise the system to each combination of charac-teristic values, we would personalise it only to learner types. In general,a learner type should correspond to several points in the learner space.We now discuss two different ways to combine elements of the learnerspace to learner types.

A convex learner type LT is a cuboid in LS. In other words, if C =c1, . . . , cn, then take intervals [vi, v

′i] ⊆ S(ci) for all scales i = 1, . . . , n

and define

LT =n∏

i=1

[vi, v′i] ⊆ LS.

Look again at Figure 5.2. Here we defined six convex learner types:

LT1 = v1 × v′1, v′2 LT2 = v2 × v′2LT3 = v2, v3 × v′1 LT4 = v1, v2 × v′3LT5 = v4 × v′1 LT6 = v3, v4 × v′2, v′3

In other words, for learners with value v1 for characteristic c1 we donot make a distinction between the values v′1 and v′2 anymore, as thiswill not have an effect on the system design.

EIT-Kluwer.tex; 22/10/2004; 19:32; p.21


-

6

c1

c2

0 2 3 5

0

1

4

LT1

LT3

LT2

LT4

LT3

Figure 5. Aggregate Learner Types

Alternatively, we may apply aggregation functions to the learnerspace. In this case we assume that the scales are sets of integers, e.g.intervals S(ci) = [mi,Mi]. An aggregate function on the learner spaceis an integer valued function f : LS → N.

An aggregate learner type is a subset of LS of the form

LT = ` ∈ LS | m ≤ f(`) ≤M

for some integer interval [m,M ].For instance, in Figure 5.3 we have taken the integer scales S(c1) =

0, 2, 3, 5 and S(c2) = 0, 1, 4. Then the aggregation function is asimple addition, i.e. f(v, w) = v + w. We then define four aggregatelearner types:

LT1 = (v, w) ∈ LS | 0 ≤ f(v, w) ≤ 1LT2 = (v, w) ∈ LS | 2 ≤ f(v, w) ≤ 3LT3 = (v, w) ∈ LS | 4 ≤ f(v, w) ≤ 6LT1 = (v, w) ∈ LS | 7 ≤ f(v, w) ≤ 9

These learner types are illustrated as well in Figure 5.3.

5.4. Intentions, Rights and Obligations

The presence of different learner types indicates different usage of thesystem. An obligation of a learner type specifies what a learner of thattype has to do. A right specifies what a learner of that type is permittedto do. Both obligations and rights together lead to complex deonticintegrity constraints. We use the following logical language L for thispurpose:

− All propositional atoms are also atoms of L.

EIT-Kluwer.tex; 22/10/2004; 19:32; p.22


− If α is an action on learning unit s and r is a learner type associatedwith s, then O do(r, α) is an atom of L.

− If α is an action on learning unit s and r is a learner type associatedwith s, then P do(r, α) is an atom of L.

− If α is an action on learning unit s and r is a learner type associatedwith s, then F do(r, α) is an atom of L.

− For ϕ,ψ ∈ L we also have ¬ϕ, ϕ ∧ ψ, ϕ ∨ ψ, ϕ ⇒ ψ and ϕ ⇔ ψare also formulae in L.

The interpretation is standard. In particular, O do(r, α) means thata learner of type r is obliged to perform action α, P do(r, α) means thata learner of type r is permitted to perform action α, and F do(r, α)means that a learner of type r is not allowed to perform action α.

Example 2 If action α8 represents an indispensible part of the course,e.g. a compulsory assignment, each learner will have to take it, onceone of the actions α7 or α13 have been executed (condition ϕ6 or ϕ7).Furthermore, assume that in case of ϕ7 the learner is obliged to executeactions α16 and α17, i.e. we obtain the deontic constraints

ϕ6 ∨ ϕ7 ⇒ O do(learner, α8)

and

ϕ7 ⇒ O do(learner, α16) ∧O do(learner, α17)

The intention of a learner can be expressed by goals, which canbe modelled by postconditions to the learning space, which itself isdescribed by an expression in the algebra discussed in Section 3.

6. Course Personalisation

Let us now discuss some techniques for the personalisation of outlinegraphs: reduction to a subgraph, and splitting of learning units.

6.1. Reduction to a Subgraph

According to the definition of outline graphs each learning unit is as-sociated with a set of learner types. As a consequence, given a certainlearner type only those learning units that are associated with it, areaccessible for a learner of this type. This leads to the definition of thesubgraph spanned by a learner type.

EIT-Kluwer.tex; 22/10/2004; 19:32; p.23


Formally, let LT be some learner type, and let G = (V,E) be anoutline graph. Then the set of learning units that are accessible tolearners of type LT is

V (LT ) = u ∈ V | u is associated with LT.

The outline graph G(LT ) = (V (LT ), E(LT )) with

E(LT ) = E ∩ (V (LT )× V (LT ))

defines the subgraph spanned by LT , i.e. we only consider those links,for which the starting and the target learning unit are in the set oflearning units that are accessible to learners of type LT .

Of course G(LT ) is an outline graph, and all its links are associatedwith the learner type LT . In fact, this subgraph models exactly thepart of the outline graph that corresponds to the permitted navigationfor learners of type LT .

We may also exploit the algebra from Section 3 to compute a sub-graph by equational reasoning. The general approach is to formulatea problem by using equations or conditional equations. Furthermore,we obtain (conditional) equations, which represent application knowl-edge. This application knowledge arises from events, postconditionsand knowledge about the use of the system for a particular purpose.We then apply all equations to solve the particular problem at hand.

The application knowledge contains at least the following equations:

1. If an action p has a precondition ϕ, then we obtain the equationϕp = 0.

2. If an action p has a postcondition ψ, we obtain the equation p = pψ.

3. If an action p is triggered by a condition ϕ, we obtain the equationϕ = ϕp.

4. In addition we obtain exclusion conditions ϕψ = 0 and tautologiesϕ+ ψ = 1.

The problem of personalisation according to the preferences of aparticular learner can be formalised as follows. Assume that p ∈ Prepresents the learner space. Then we may formulate the preferences ofa user by a set Σ of (conditional) equations. Let χ be the conjunctionof the conditions in Σ. Then the problem is to find a minimal processp′ ∈ P such that χ⇒ px = p′x holds for all x ∈ P. Preference equationscan arise as follows:

1. An equation p1 + p2 = p1 expresses an unconditional preference ofaction (or process) p1 over p2.

EIT-Kluwer.tex; 22/10/2004; 19:32; p.24


2. An equation ϕ(p1 + p2) = ϕp1 expresses an conditional preferenceof action (or process) p1 over p2 in case the condition ϕ is satisfied.

3. Similarly, an equation p(p1 + p2) = pp1 expresses another condi-tional preference of action (or process) p1 over p2 after the action(or process) p.

4. An equation p1p2 + p2p1 = p1p2 expresses a preference of order.

5. An equation p∗ = pp∗ expresses that in case of an iteration it willat least be executed once.

Example 3 Let us continue Example 1. Assume that we have to dealwith a learner who knows ϕ5. This can be expressed by the applicationknowledge equation xϕ5 = x for all x ∈ K. Furthermore, assume threeadditional exclusion conditions:

ϕ5ϕ0 = 0 ϕ5ϕ1 = 0 ϕ5ϕ2 = 0

Taking these equations to the first part of the expression in Example1 we obtain

α1((ϕ0α2 + ϕ1α3(α5 + 1)ϕ3 + ϕ2α4(α6 + 1)ϕ4)∗ϕ5)x =α1((ϕ0ϕ5α2 + ϕ1ϕ5α3(α5 + 1)ϕ3 + ϕ2ϕ5α4(α6 + 1)ϕ4)∗ϕ5)x =α1((0α2 + 0α3(α5 + 1)ϕ3 + 0α4(α6 + 1)ϕ4)∗ϕ5)x =α11ϕ5x =α1x

That is, the whole learning space can be simplified to

α1(α7ϕ6 + α13ϕ7)(ϕ6α8(α8 + 1)α9α10α11α12ϕ8+

ϕ7α8α∗8α14α15α

∗16α11α17(ϕ12α18α19)∗ϕ12α18ϕ9)α20(ϕ10 + ϕ11)

Personalisation also means satifying the intention of a particularlearner. Let this intentions be formalised by the postcondition ψ ∈ B.Furthermore, assume that the learning space is represented by someprocess expression p ∈ P. Then the problem is to find a minimal processp′ ∈ P such that pψ = p′ψ. In order to find such a p′ we have to useagain the application knowledge.

Example 4 Let us continue Example 1 and look at a user with in-tention ϕ10. Then we express application knowledge by the equationsϕ10ϕ11 = 0, ϕ10ϕ9 = 0 and ϕ6ϕ7 = 0.

EIT-Kluwer.tex; 22/10/2004; 19:32; p.25


Then we can simplify pϕ10 with the expression p from Example 1step by step. First we get (ϕ10+ϕ11)ϕ10 = ϕ10, which can then be usedfor

(ϕ6α8(α8 + 1)α9α10α11α12ϕ8

+ ϕ7α8α∗8α14α15α

∗16α11α17(ϕ12α18α19)∗ϕ12α18ϕ9)ϕ10 =

ϕ6α8(α8 + 1)α9α10α11α12ϕ8ϕ10

+ ϕ7α8α∗8α14α15α

∗16α11α17(ϕ12α18α19)∗ϕ12α18ϕ9ϕ10 =

ϕ6α8(α8 + 1)α9α10α11α12ϕ8ϕ10

Then finally we get

(α7ϕ6 + α13ϕ7)ϕ6α8(α8 + 1)α9α10α11α12ϕ8ϕ10 =α7ϕ6ϕ6α8(α8 + 1)α9α10α11α12ϕ8ϕ10

+ α13ϕ7ϕ6α8(α8 + 1)α9α10α11α12ϕ8ϕ10 =α7ϕ6α8(α8 + 1)α9α10α11α12ϕ8ϕ10

This means that the story space can be simplified to

α1((ϕ0α2 + ϕ1α3(α5 + 1)ϕ3 + ϕ2α4(α6 + 1)ϕ4)∗ϕ5)α7ϕ6α8(α8 + 1)α9α10α11α12ϕ8α20ϕ10

6.2. Splitting of Learning Units

The reduction to a subgraph obviously leads to an outline graph thatis completely associated with the given learner type. However, it doesnot change any of the data content of the involved learning units. Thisproblem is addressed by the splitting of learning units.

Roughly speaking, if we are given a learning unit in an outline graphthat is associated with a given learner type, we may replace this unit bya whole outline graph such that all learning units in this new outlinegraph are associated with the given learner type. Furthermore, thecombined data content of the units in this replacement outline graphshould be equivalent to the data content of the original learning unit.

Formally, let LT be some learner type, and let G = (V,E) be anoutline graph. Let u ∈ V be a learning unit associated with LT . Nowtake another outline graph Gu = (Vu, Eu) with the following properties:

− V ∩ Vu = ∅, i.e. the two outline graphs have no common learningunits;

− all learning units v ∈ Vu are associated with the learner type LT ;

EIT-Kluwer.tex; 22/10/2004; 19:32; p.26


− the join of the data contents Cv for all v ∈ Vu is equivalent to thedata content Cu;

− there is a distinguished starting learning unit v0 ∈ Vu such that alllearning units v ∈ Vu can be reached from v0;

− there is a distinguished final learning unit vf ∈ Vu, which can bereached from all learning units v ∈ Vu.

The first three properties express our intention to replace u by thegraph Gu without losing data content. The last two properties are oftechnical nature to ensure that this replacement is formally correct.

So, we obtain a new outline graph G = (V ,E) with V = (V −u)∪Vu, i.e. we replace the learning unit u by all learning units in Vu.Furthermore, a link (u′, u) ∈ E must be replaced by a link (u′, v0) ∈ Epreserving all data types and actions associated with it. Finally, a link(u, u′) ∈ E has to be replaced by a link (vf , u

′) ∈ E preserving all datatypes and actions associated with it.

However, if we want to preserve the learning unit u for other learnertypes, we would first have to double it in G ensuring that one copy isassocated with LT , and the other copy with all other learner types.

The splitting of a learning unit requires a more detailed specificationof the content of learning units. We will therefore postpone a moretechnical discussion of splitting to end of the Section 7.

7. Data Management

The content aspect of e-learning systems concerns the question: Whichinformation should be provided? This is tightly coupled with the prob-lem of designing an adequate database. However, the organisation ofdata that is presented to the user via the pages in an e-learning systemdiffers significantly from the organisation of data in the database. Weconclude that modelling the content has to be addressed on at leasttwo levels: a logical level leading to databases, and a conceptual levelleading to the content of pages. Both levels have to be linked together.

As pages correspond to learning units, an abstract description ofsuch a learning unit would be a pair (u, v), where u is a URL and v isa complex value based on the use of some type system. We decide tocall such a pair a learning object . The term ‘object’ is used, becausepairs constructed out of an abstract identifier and a complex value arecalled ‘objects’ in the context of object oriented databases.

Using classification abstraction as usual in data modelling, we obtaincontent types. In general, every data type can become a content type of

EIT-Kluwer.tex; 22/10/2004; 19:32; p.27


a learning unit . Thus, if U denotes a learning unit, the learning objectsof type U are pairs (u, v) consisting of a value u of type URL and avalue v of the content type of U .

A little subtlety comes in here, which makes the definition still abit more complicated. When a value of type URL appears inside thecontent value v, this may be a URL somewhere outside the web infor-mation system that we want to develop. However, in the case where theURL is an internal one, it will be the URL of another learning object,say of type U ′.

Therefore, we extend content types in such a way that instead ofthe type URL we may also use links ` : U ′ with a unique link name `and a name of a learning unit U ′.

In order to obtain a learning object we would have to replace thelinks ` : U ′ by the data type URL first. However, the link ` : U ′ wouldforce us to use only values of type URL that are URLs of the learningunit U ′.

Learning objects support an individual learner and only provide asection of the data of the system. The question arises how the datacan be described globally. In fact, we would need to combine all thecontent types and set up a database schema. Designing such a databaseschema underlies completely different quality criteria. For instance, fordatabases we would like to avoid redundancies as much as possible. Wewould also have to pay much attention to providing fast and concurrentaccess to the data.

Therefore, we use a separate level defined by database types. Thus,we obtain a description of the static components on two levels: theglobal or database level, and the local or information unit level. Onboth levels we employ the same type system.

Database types are more or less defined in the same way as thecontent types.

7.1. Content Databases

In order to define underlying databases we could refer to any datamodel. Due to its convenience we prefer to adopt a variant of the Entity-Relationship model (Thalheim, 2000). According to this model we havedatabase types on various levels k ≥ 0. Usually, the types of level 0 arecalled entity types, whereas types on higher levels are called relationshiptypes.

A database type of level k has a name E and consists of

− a set comp(E) = r1 : E1, . . . , rn : En of components withpairwise different role names ri and names Ei of database types,

EIT-Kluwer.tex; 22/10/2004; 19:32; p.28


− a set attr(E) = a1, . . . , am of attributes, each associated with adata type type(ai), and

− and a key id(E) ⊆ comp(E) ∪ attr(E),

such that the database types Ei ∈ S are all on levels lower than kwith at least one database type of level exactly k−1. In the following weoften write E = (r1 : E1, . . . , rn : En, a1, . . . , am, id(E)) to denotea database type. The first component in this triple is the componentset comp(E). The second component is the attribute set attr(E). Thethird component is the key id(E).

We use this notation to associate two data types with each databasetype E. These data types are called the associated data type of E andthe associated key type of E. These types are defined as follows:

− The associated data type of E, denoted as type(E), is

(r1 : key-type(E1), . . . , rn : key-type(En),a1 : type(a1), . . . , am : type(am))

− The associated key type of E, denoted as key-type(E), is definedanalogously with the difference that only those ri and aj are con-sidered that occur in id(E).

In particular, if we have a database type E of level 0, then comp(E)is the empty set. This implies that that there are no fields labelled byri.

Let us now conclude the presentation of the global database bydefining database schemata. A database schema is simply a collectionof database types. Of course, if Ei is a component of a database typeE, and E is defined in the schema, then Ei must also be defined in theschema.

Formally, we can define a database schema as follows:A database schema S is a set of database types satisfying the fol-

lowing condition: If E ∈ S is a database type, then for all componentsri : Ei ∈ comp(E) we must also have Ei ∈ S.

We define the semantics of database schemata by the collection ofpossible databases prescribed by the database schema. Thus, let S bea database schema. For each database type E ∈ S we have defined anassociated data type type(E) and an associated key type key-type(E).As these two are indeed data types, they define fixed sets of values,which we call the set of objects of type E and the set of keys of type E,respectively:

Obj(E) = dom(type(E)) and Key(E) = dom(key-type(E))

EIT-Kluwer.tex; 22/10/2004; 19:32; p.29


As the key id(E) in a database type E is a subset of comp(E) ∪attr(E), each object of type E can be projected to a key of type E. LetO[key-type(E)] ∈ Key(E) denote the projection of the object O ∈ Obj(E)to the value of its key.

We use the sets of objects and keys for the database types E ∈ S todefine a database over S as follows:

A database db over S assigns to each database type E ∈ S a finite setdb(E) ⊆ Obj(E) of objects of type E such that the following conditionsare satisfied:

1. Key values are unique, i.e. there cannot be two different O1, O2 ∈db(E) with O1[key-type(E)] 6= O2[key-type(E)].

2. Component values exist in the database, i.e. for each O ∈ db(E)and each r : E′ ∈ comp(E) there must exist some O′ ∈ db(E′) suchthat r : O′

[key-type(E′)] is part of O.

7.2. Learning Units

The core of a learning unit is defined by a view. A view V on a databaseschema S consists of a view schema SV and a defining query qV , whichtransforms databases over S into databases over SV .

The underlying datamodel itself is not relevant. The defining querymay be expressed in any suitable query language, e.g. query algebra,logic or an SQL-variant, provided that the queries are able to createlinks.

This leads to the definition of data unit based on some type system.The type system must provide base types and type constructors, e.g.record, set and list type constructors. Arbitrary type expressions arebuilt by nesting these constructors.

A data unit has a name M and consists of a content data typecont(M), which is an extended type expression, in which the place of abase type may be occupied by a pair ` : M ′ with a label ` and the nameM ′ of a data unit, and a defining query qM such that (tM, qM ) definesa view. Here tM is the type arising from cont(M) by substitution ofURL for all pairs ` : M ′.

In order to model functionality operations are added to data units.An operation on a data unit M consists of an operation signature, i.e.,name, input-parameters and output-parameters, a selection type whichis a supertype of cont(M), and a body which is defined via operationsaccessing the underlying database.

In order to allow the information content to be tailored to specificlearner needs and presentation restrictions, data units are extended

EIT-Kluwer.tex; 22/10/2004; 19:32; p.30


to learning units. The most relevant extension is cohesion, which in-troduces a controlled form of information loss. Formally, we define apartial order ≤ on content data types, which extends subtyping in astraightforward way such that references and superclasses are takeninto consideration.

If cont(M) is the content data type of a data unit M , then letsup(cont(M)) denote the set of all larger content expressions, i.e. allexpressions exp with cont(M) ≤ exp.

A total pre-order M on sup(cont(M)) extending the order ≤ oncontent expressions is called an cohesion pre-order . Clearly, cont(M)is minimal with respect to M .

Small elements in sup(cont(M)) with respect to M define infor-mation to be kept together, if possible. An alternative to cohesionpreorders is to use proximity values, but we will not consider themhere.

A learning unit is a data unit M extended by operations and acohesion pre-order M . There are other extensions beyond cohesion,but these are not relevant for context modelling.

If the defining query is evaluated for a learning unit M , we obtaina complex value v of type tM . Together with a generated URL u thisdefines a learning object of type M .

Cohesion enables a controlled form of information decomposition,which can be exploited for the splitting of learning units as indicatedin the previous Section 6. If we want to decompose a learning unit or ifwe are forced to decompose according to user requirements or technicalrestrictions, then we may choose a minimal elements t1 ∈ sup(cont(M))with respect toM such that it satifies the representation requirements.Note that if we only provide a preorder, not an order, then there maybe more than one such t1.

Taking just t1 instead of cont(M) means that some information islost, but this only refers to the first data transfer. When transferringt1, we must include a link to a possible successor containing detailedinformation. In order to determine such a successor we can continuelooking at all content data types t′ ∈ sup(cont(M)) with t1 6M t′.These are just those containing the complimentary information thatwas lost. Again we can choose a least type t2 among these t′ withrespect to M that requires not more than the available capacity. t2would be the desired successor.

Proceeding this way the whole communication is broken down intoa sequence of suitable units t1, t2, . . . , tn that together contain theinformation provided by the learning unit. Of course, the cohesion pre-order suggests that the relevance of the information decreases, whileprogressing with this sequence. The learner may decide at any time

EIT-Kluwer.tex; 22/10/2004; 19:32; p.31


that the level of detail provided by the sequence t1, . . . , ti is alreadysufficient for his/her needs.

8. Conclusion

In this article we presented a conceptual view of web-based e-learningsystems. Starting from a general abstraction layer model we addressedthe modelling of courses, the modelling of learners, the personalisationof courses, and the management of data in e-learning systems. Coursesare modelled by outline graphs, which are further refined by some formof process algebra. This process algebra actually gives rise to a many-sorted Kleene algebra with tests, which can be used to fomally reasonabout the whole learning space.

The linguistic analysis of word fields refering to an application do-main helps to set up these course outlines. Learners are modelled byclassifying value combinations for their characteristic properties. Eachlearner type gives rise to intentions as well as rights and obligations inusing a learning system. Intentions can be formalised as postconditions,while rights and obligations lead to deontic constraints. The intentionscan be used for the personalisation of the learning system to a learnertype. We showed that we can use equational reasoning in the Kleenealgebra to reduce the learning space to a subgraph that represents thelearning needs of a particular learner type.

We approached the management of data in an e-learning system ontwo different levels dealing with the content of individual learning unitsand the integrated content of the whole system, respectively. This leadsto supporting databases and views defined on them. Furthermore, wedemonstrated that the adaptivity feature of the learning units can beused to set up a simple algorithmic approach to personalisation basedon the splitting of learning units. Our ideas have been partly realised inthe DaMiT system (Binemann-Zdanowicz et al., 2003a; Jantke et al.,2004; Jantke et al., 2003; Rostanin et al., 2002), a system that addresseslearning in the area of data mining.

We believe that the integrated conceptual nature of our approachand its coupling with rigorous mathematical foundations will help toimprove e-learning system in a way that learner-driven learning ondemand will be better supported. However, we do not claim that ourmethodology is a panacea for all problems related to e-learning. Weacknowledge that not all of the educational discussion in the field hasentered our work nor the work of others, as the technological challengesarising from these discussions have not yet found adequate answers. In

EIT-Kluwer.tex; 22/10/2004; 19:32; p.32


other words, we will continue our research in order to further improveour approach.

References

Atzeni, P., Gupta, A., and Sarawagi, S. (1998). Design and main-tenance of data-intensive web-sites. In Proceeding EDBT’98, volume1377 of LNCS, pages 436–450. Springer-Verlag, Berlin.

Bergstedt, S., Wiegreffe, S., Wittmann, J., and Moller, D. (2003).Content management systems and e-learning systems: a symbiosis? InProceedings ICALT 2003, pages 155–159. IEEE Computer Society.

Binemann-Zdanowicz, A., Kaschek, R., Schewe, K.-D., and Thalheim,B. (2004). Context-aware web information systems. In Hartmann,S. and Roddick, J., editors, Conceptual Modelling 2004 – First Asia-Pacific Conference on Conceptual Modelling, volume 31 of CRPIT,pages 37–48, Dunedin, New Zealand. Australian Computer Society.

Binemann-Zdanowicz, A., Schewe, K.-D., and Thalheim, B. (2004).Adaptation to learning styles. In Kinshuk, Looi, C.-K., Sutinen, E.,Sampson, D. G., Aedo, I., Uden, L., and Kahkonen, E., editors, Pro-ceedings of the IEEE International Conference on Advanced LearningTechnologies – ICALT 2004, pages 121–125. IEEE Computer Society.

Binemann-Zdanowicz, A., Schulz-Brunken, B., Thalheim, B., andTschiedel, B. (2003a). Flexible e-payment based on content andprofile in the e-learning system DaMiT. In Proceedings of E-Learn2003, Phoenix (Arizona), USA. Association for the Advancement ofComputing in Education.

Binemann-Zdanowicz, A., Thalheim, B., and Tschiedel, B. (2003b).Logistics for learning objects. In Proceedings of eTrain 2003.

Ceri, S., Fraternali, P., Bongio, A., Brambilla, M., Comai, S., and Mat-era, M. (2003). Designing Data-Intensive Web Applications. MorganKaufmann, San Francisco.

Conallen, J. (2003). Building Web Applications with UML. Addison-Wesley, Boston.

Feyer, T., Kao, O., Schewe, K.-D., and Thalheim, B. (2000). Designof data-intensive web-based information services. In Li, Q., Ozsuyoglu,

EIT-Kluwer.tex; 22/10/2004; 19:32; p.33


Z. M., Wagner, R., Kambayashi, Y., and Zhang, Y., editors, Proceed-ings of the 1st International Conference on Web Information SystemsEngineering (WISE 2000), pages 462–467. IEEE Computer Society.

Hausser, R. (2001). Foundations of Computational Linguistics.Springer-Verlag, Berlin, Germany.

Hubscher, R. (2001). What’s in a prerequisite? In Okamoto, T., Hart-ley, R., Kinshuk, and Klus, J. P., editors, Proceedings ICALT 2001,pages 365–368. IEEE Computer Society.

Jantke, K.-P., Lange, S., Thalheim, B., Tschiedel, B., Grieser, G., andGrigoriev, P. (2004). Learning by doing and learning when doing:Dovetailing e-learning and decision support with a data mining tu-tor. In Proceedings of the 6th International Conference on EnterpriseInformation Systems, Porto, Portugal.

Jantke, K.-P., Memmel, M., Rostanin, O., Thalheim, B., and Tschiedel,B. (2003). Decision support by learning-on-demand. In ProceedingsDSE 2003, CAISE Workshops, pages 317–328.

Kaschek, R., Matthews, C., Schewe, K.-D., and Wallace, C. (2003).Analyzing web information systems with the Abstraction Layer Modeland SiteLang. In Proceedings of the Australasian Conference onInformation Systems (ACIS 2003).

Kaschek, R., Schewe, K.-D., Thalheim, B., Kuss, T., and Tschiedel, B.(2004a). Learner typing for electronic learning systems. In Kinshuk,Looi, C.-K., Sutinen, E., Sampson, D. G., Aedo, I., Uden, L., andKahkonen, E., editors, Proceedings of the IEEE International Confer-ence on Advanced Learning Technologies – ICALT 2004, pages 375–379.IEEE Computer Society.

Kaschek, R., Schewe, K.-D., Wallace, C., and Matthews, C. (2004b).Story boarding for web information systems. In Taniar, D. and Rahayu,W., editors, Web Information Systems. IDEA Group.

Kerres, M. (2001). Multimediale und telemediale Lernumgebungen:Konzeption und Entwicklung. Oldenbourg-Verlag.

Kozen, D. (1997). Kleene algebra with tests. ACM Transactions onProgramming Languages and Systems, 19(3):427–443.

Martinez, M. (2001). Key design considerations for personalizedlearning on the web. Educational Technology and Society, 4(1).

EIT-Kluwer.tex; 22/10/2004; 19:32; p.34


Merrill, M. D. (1983). Component display theory. In Reigeluth,C. M., editor, Instructional-Design Theories and Models: An Overviewof Their Current Status, pages 279–333. Erlbaum, Hillsdale, NJ.

Mohan, P. and Brooks, C. (2003). Learning objects on the semanticweb. In Proceedings ICALT 2003, pages 195–199. IEEE ComputerSociety.

ONTO-LOGGING Consortium (2002). User mod-elling issues in the context of knowledge management.http://www.ontologging.com/deliverables.htm.

Qu, C. and Nejdl, W. (2003). Searching SCORM metadata in a RDF-based e-learning P2P network using Xquery and Query-by-Example.In Proceedings ICALT 2003, pages 81–85. IEEE Computer Society.

Ravenscroft, A. and Matheson, M. P. (2001). Carpe diem: Models andmethodologies for designing engaging and interactive e-learning dis-course. In Okamoto, T., Hartley, R., Kinshuk, and Klus, J. P., editors,Proceedings ICALT 2001, pages 74–77. IEEE Computer Society.

Rostanin, O., Schewe, K.-D., Thalheim, B., and Tretiakov, A. (2004).Managing the data in electronic learning systems. In Kinshuk, Looi, C.-K., Sutinen, E., Sampson, D. G., Aedo, I., Uden, L., and Kahkonen, E.,editors, Proceedings of the IEEE International Conference on AdvancedLearning Technologies – ICALT 2004, pages 395–399. IEEE ComputerSociety.

Rostanin, O., Tschiedel, B., and Thalheim, B. (2002). Szenario-basiertes e-Learning fur adaptive Inhaltsprasentation. In Jantke, K.-P.,Wittig, W., and Herrmann, J., editors, Proceedings LIT 2002, pages330–338. Infix Publishers.

Schewe, K.-D., Kaschek, R., Matthews, C., and Wallace, C. (2002).Modelling web-based banking systems: Story boarding and user profil-ing. In Mayr, H. C. and Van den Heuvel, W.-J., editors, Proceedingsof eCoMo 2002, Springer LNCS, Berlin. Springer-Verlag.

Schewe, K.-D. and Thalheim, B. (2001). Modeling interaction andmedia objects. In Metais, E., editor, Proceedings of 5th Int. Conf.on Applications of Natural Language to Information Systems (NLDB2000), pages 313–324, Berlin. Springer Verlag, LNCS 1959.

Schewe, K.-D. and Thalheim, B. (2004). Conceptual modelling of webinformation systems. Technical Report 3/2004, Massey University.

EIT-Kluwer.tex; 22/10/2004; 19:32; p.35


Sessink, O., Beeftink, R., Tramper, J., and Hartog, R. (2003). Author-defined storage in the next generation learning management systems.In Proceedings ICALT 2003, pages 57–61. IEEE Computer Society.

Thalheim, B. (2000). Entity-Relationship Modeling: Foundations ofDatabase Technology. Springer-Verlag.

Thalheim, B., Binemann-Zdanowicz, A., and Tschiedel, B. (2003).Content modeling for e-learning services. In Proceedings of the 7thWorld Multi-Conference on Systemics, Cybernetics and Informatics(SCI 2003).

Thalheim, B. and Dusterhoft, A. (2000). The use of metaphori-cal structures for internet sites. Data & Knowledge Engineering,35:161–180.

Thalheim, B. and Dusterhoft, A. (2001). SiteLang: Conceptual mod-eling of internet sites. In Kunii, H. S., Jajodia, S., and Sølvberg, A.,editors, Conceptual Modeling – ER 2001, volume 2224 of LNCS, pages179–192. Springer-Verlag, Berlin.

Thalheim, B. and Dusterhoft, A. (2004). Linguistic based searchfacilities in snowflake-like database schemes. Data & KnowledgeEngineering, 48:177–198.

Van Duyne, D. K., Landay, J. A., and Hong, J. I. (2002). The Designof Sites. Addison-Wesley, Boston.

EIT-Kluwer.tex; 22/10/2004; 19:32; p.36

LOGISTICS FOR LEARNING OBJECTS

Bernd Tschiedel, Aleksander Binemann-Zdanowicz, Bernhard ThalheimBTU Cottbus, LS Datenbanken Informationssysteme

bernd.tschiedel | binemann | [email protected]

Abstract An auspicious technology in the area of e-Learning is the assignment of learningobjects. Nowadays, learning object is a common vocabulary in the meaningof content that has to work up to small independent content units which areconnected with some semantic signification. A postulating advantage of learningobjects is to improve the information quality of service, the provision of content.The aspects of information quality are described in the three main principles ofinformation logistics. The correct content in the right place to the right time.This we have realized in the DaMiT Project. Rationale was the utilization ofSiteLang, a methodology originally developed for specifying entire websites andenhanced for designing web-based learning systems.

Keywords: SiteLang, e-Learning websites, adaptive e-Learning, information logistics

1. IntroductionIn many scientific papers and working group specifications the fundamental

insight was outlined, that a high granularity of learning units leads to higher user-adaptive systems. One guideline is to deal with a lot of different types of unitsfrom the same topic. Users, in our case learners, just want best-suited contentdelivered just in time and to the right place and device. They should not beconfronted with wasteful content. Therefore, some services are needed to fulfillthe learner’s needs. In the information logistics one finds acceptable strategieswhich satisfy the requirements of a delivery of the right unit of information. Thegoals of information logistics are well-adoptable for the e-Learning challenge.

1.1 Types of LearningA new hope is born, since e-Learning profits from the new technologies

related to the internet and permanently increasing bandwidth. A hope withhigh demands on human and technical resources, which are involved in makingthe dream true to let everybody learn at any time, everywhere and whatever.But if we simply say "learn", we face a lot of problems and solutions comingfrom classroom learning, which are not easy adoptable for a computer-basedlearning system. Let us look at only one methodical aspect of learning and

2

teaching, the social aspect. In [Ott01]one can find organizational types whichdetermine the interaction and communication possibilities.

Frontal teaching: a teacher presents a learning unit and works on it to-gether with the pupils, students. Single working place: every pupil, student isself-responsible for planning, solving, checking problem solutions. Classmateworking: exactly two pupils, students are responsible for their product of ac-tions. Cooperative, collaborative working: a group (3-6, autonomous) workson the instructions and creates an own product of actions. It is to divide intocommon group tasks and separated group tasks.

Not only the obvious difficulty to model these social environments but alsothe classical problems like adaptivity, multi-usage of content, the necessaryunderlayer of developing social aspects are still in the scope of research. Thesenatural characteristics of interactive working are controlled by a teacher, whoevaluates and analyzes the needs and learning history of the pupils and basingon this knowledge he generates a learning scenario, which can be adapted atlearn-time according to pupils’ progress and evolving needs.

1.2 Information logisticsInformation logistics serves for providing optimized information to users

[Lie01]. Optimized means that textually correct and needed information willbe served at the right time and place. The information should always be trans-formed depending of user preferences and communication facilities. Derivedfrom this definition [Lie01]explains some basic principles in information logis-tics which also concern e-Learning.Several information sources: The use of several content sources, in dependence of the ac-

tual user needs. The user looks for additional or extended information in distributed,correlated content bases. At the moment we restrict this to one database of one domain.

Information on the tick: Information at the right time depends on the value of the informationand the user context. The value depends on the deliverable content in the knowledgebases. High value demands a detailed description of the content. Users of an e-Learningsystem may interact with the system in different roles with special characteristics. Thisis the primary context for the user. Thus, on these conditions the system has to chooseon demand or on click what the preferred content for the user is at this moment.

Consideration of user preferences: Applications of information logistics must be able tosatisfy individual needs of the users. User needs must be specified for optimal operation.This must be implemented in an explicit and an implicit way. Explicit data, like preferredpresentation style or difficulty, must be treated as granularly as possible. Implicit dataare the user’s history, current and recorded interaction and utilization behavior.

Flexibility of presentation: Users have (depending on their working place and working con-text) different communication devices and channels. The system automatically rec-ognizes the user’s system, his network connection and application. In any case, thepresentation style must be adapted with respect to the individual working context.

The working place and context are features of information logistics. Theydo not belong to a web-based e-Learning environment, as they depend on theinternet access. The described particularities are related to the challenges ourdepartment faced during the development of the SiteLang approach.

3

1.3 Challenges in e-LearningWhile creating a computer-based learning application you face certain chal-

lenges which have already been investigated and used in some prototypes. Wealso have to restrict the mentioned aspects of information logistics from above.in the following aspects.Full flexibility: E-learning services require full flexibility of learning scenarios. The set of

scenarios necessary to be supported looks graphically similar to a complete graph. Itis possible in such cases to use any menu point and to jump to any other dialogue step[Cau00]. The usage of a proven scenario theory for the application development is abasic assumption to realize full flexibility.

Multiple usage of content: Authors of content must be able to index, research, reselect,recombine and update existing content. There is the need of a flexible data structure inorder to comply with these demands. Thus, in the area of e-learning we use the approachof learning objects, based on the Reusable Learning Object Strategy [Cis01].

Adaptivity: Learners want to get content depending on their specific information requirementsand demand. There are some general user profiles in the area of content format liketext or formula-oriented learners. These can be used as pre-made scenarios with alreadyassociated learning objects. To realize user adaptation fully, learning objects should beenhanced at run-time with specific user information from the current user profile.

1.4 Overview of the PaperThis paper gives a short overview of the SiteLang methodology which is being

used to develop parts of the DaMiT e-Learning system. Principles of informa-tion logistics are part of this design concept. The language has an operationalsemantics based on entity-relationship structuring and Abstract State Machines[Gur95]. It allows to specify entire websites by means of their structuring,behavior, information support, interaction and story space. The theoreticalbackground of this work generalizes the approaches [FOS00]and [Tha00].

2. The SiteLang MethodologySiteLang has been developed to enable developing interactive web services

in a systematic way, allowing to verify the behavior of an information servicebefore its actual implementation. SiteLang supports the stepwise developmentof a website according to the CoDesign abstraction layer model [FOS00]. Itallows to specify database behavior and user interaction of the system in parallel.

The major goals achieved with SiteLang are the refineability of obtainedSiteLang specifications and the possibility to execute and validate an abstractspecification on any abstraction level. This has been achieved thanks to theoperational semantics of Abstract State Machines [Gur95]SiteLang is basedon. The development of analysis methods in the SiteLang methodology is alsosupported by the developments in the ASM community.

The SiteLang language comprises constructs for specifying database func-tionality (database schema, database operations, transaction management, in-tegrity constraints, database content), as well as user interaction (event-driveninteraction model, multiple users and devices, scenes, dialogue steps with trans-

4

damituser

ident

secur

compet

goal

access

course2group

1:1billing

0:n

course:learnobjectn:0

n:1

1:n

session1:n

0:1

0:1

address

contact

n:0

n:0

0:1

0:1

0:n

1:n

history

1:n

unit:learnobject

path2

userrole

1:n

usergroup

Figure 1. Simplified ER-Schema for DaMiT users

action semantics, dialogues, media objects) [DuT01]in parallel. It allows tospecify distributed system architectures. The user interaction model of Site-Lang is event-driven; the event frame differs from the classical ECA model andcomprises well-founded transaction semantics.

SiteLang has been successfully used for specifying interactive services ofa set-top-box-based tv platform which has been developed by an industrialconsortium in cooperation with our database group. The positive experience ofSiteLang has proven its suitability for specifying data-intensive applications. Itis also suitable for specifying and validating systems in which the interactionflow is reciprocally influenced by semantic content structures.

3. The Data Mining Tutor ProjectThe focus of the DaMiT project is the development of a computer-based tutor

system to support learning and teaching in the area of Knowledge Discoveryand Data Mining. Another important focus is put on the creation of content.

The main goal of DaMiT is to realize user adaptivity. Derived sub-goalsare: content generation, creating coherent and consistent content, generating asemantic network using the domain Data Mining, integrating applications foron-line data mining, keeping an architecture open for extensibility and updating,as well as obtaining a knowledge basket adoptable to other projects.

4. SiteLang Usage in the ProjectA SiteLang specification of DaMiT is obtained stepwise, starting with the

Motivation Layer and the Requirements Acquisition Layer. The next step is theBusiness User Layer. It is the basis of further modeling and is then refined ontoConceptual Layer and the Implementation Layer. As an example we brieflypresent the user model and then focus on content modeling.

4.1 Modeling the UserFor user adaptivity it is essential to analyze the most typical characteristics,

operations and expectations of users who are to work and interact with theplanned web service. Some of the characteristics are attributes and operationswhich form the adaptive interface of the user. This concerns the area of rights,educational classification and utilization behavior. So we defined at the BULroles (Content Provider, Teacher, Administrator, Tutor, Learner with the sub-roles Anonymous, Pseudonymous, Standard, Manager), metadata and added

5

functionality, e.g. Payment, Rights Management (of courses, with respect tolearner groups), as well as user-role-dependent interface and system functions.The transformation process towards the Conceptual Layer led us, through the(partially depicted) ER schema, to an appropriate relational database schema.

4.2 Modeling ContentContent and content-related user interaction is modeled in SiteLang on vari-

ous abstraction levels. Content can be seen as a semantic structure with associ-ated metadata. This semantic structure is modeled in SiteLang on the BusinessUser Layer (BUL). In the stepwise refinement process of SiteLang, the BULis mapped onto the Conceptual Layer, the semantic structure is mapped to anappropriate relational schema. On this layer, a more thorough validation of thesystem behavior is possible, as we deal with well-defined database structuresand a ripe story specification. The Conceptual Layer itself can be then refined tothe Implementation Layer, on which implementation-related details are added,e.g. architecture, information containers exchange etc.4.2.1 Modeling on Business User Layer. The semantic structure of con-tent is modeled on BUL by means of a content graph G = (V, E, tv, te, vv, ve, p, Σ),with E ⊆ V × V , vv : V → Γ, ve : E → 2Γ, p : V → 2Properties.The sets V and E represent vertices and edges. The functions vv, ve determineversion numbers of a node or a set of version numbers to an edge, respectively.Γ is just a set of consecutive version numbers. The function p assigns a setof properties to a node. The type functions tv, te, the constraint set Σ andthe set Properties are application-dependent. A content graph is valid if allconstraints from Σ are fulfilled. For modeling e-learning content we define:

tv : V → content, unit, topicte : E × Γ → deleted, requires, is required by, see also,, has part, is part of, ...Properties = lecture, course, unit group, mmedia obj, text obj, applet obj.

The set Σ contains restrictions on the content graph:α0 := ∀(e, γ) ∈ dom(te) : γ ∈ ve(e)

α1 := ∀v1, v2 ∈ V : (v1, v2) ∈ E ⇒ (tv(v1) = topic ∧ tv(v2) = topic)

∨(tv(v1) = topic ∧ tv(v2) = unit) ∨ (tv(v1) = unit ∧ tv(v2) = content))

α2 := ∀e ∈ E : [∃γ ∈ Γ : te(e, γ) = deleted ⇒ ∃γ′ ∈ ve(e) : γ′ > γ]

α3 := ∀v ∈ V : (course ∈ p(v) ⇒ (∀v′ ∈ V : E∗(v, v′) ⇒ course ∈ p(v′)))

The content graph is similar to the concept of semantic networks. It is,however, particularly suitable for modeling content on BUL.4.2.2 Modeling on Conceptual and Implementation Layers. TheBUL is essential for modeling semantic structures of e-Learning content. Itallows to validate system behavior before the actual database schema has beenmodeled. In order to simulate both database behavior and user interaction, BULneeds to be refined to Conceptual Layer.

For this purpose, the content graph is mapped to a database schema. Classesof objects of the same type in the content graph are mapped to relationship types,

6

Topic Topic1 Unit1

Content2

Content3

Unit2 Content5

Content6Unit3

Content9

Topic5 Topic6 Unit4

Content10

Content11

Content12Unit5

Content13

requires

requires

see also

Lecture=TRUE

UnitGroup=TRUE

Figure 2. Simplified content graph

links between objects are mapped to relationship types of a higher order. Theresulting schema depends on the types of links between nodes on the BUL andof their semantics with respect to learning scenarios, as well as on e-learningcontent type and paramount manipulation operations performed on the content.As a result we get a complete relational database schema with the correspondingmetadata and the user information.

User interaction is specified explicitly on Conceptual Layer. As learning sce-narios are generated along links between content objects, topic and unit nodesfrom the BUL are transformed to scenes and dialogue steps. The navigationstructure (dialogue step specification) results from the link structure of the re-spective node and of its parent nodes (topics). Navigation through content isrealized as an execution of a series of scenes; navigation steps through a singleunit by means of dialogue steps of a single scene. Content graph modificationsat run-time result in scene changes on Conceptual Layer.

Having obtained the Conceptual Layer specification, we can refine it ontoImplementation Layer, e.g. by including further implementation details and byadding constructs describing system distribution.4.2.3 Modeling Metadata. Metadata in DaMiT is modeled accordingto commonly known concepts like in [IMS01]. It is modeled in SiteLang on theBUL directly by means of the HERM model [DuT01]. On Conceptual Layer,the metadata schema is then transformed to a corresponding relational schema.

4.3 Content GenerationE-Learning content in DaMiT is generated according to the user’s needs and

is closely related to content adaptivity. The generation is done in twofold ways.Content-to-Profile Matching: the existing content structure is matched with theuser’s preferences and history. The generated content is assembled from thematching topics and units, chosen from the content graph and is presented to theuser as a lesson. It is being realized in our prototype by means of parameterizedviews, mappings of profile-dependent generation rules.

Semantic Content Evolving: the content structure is enriched by new sub-graphs built on the basis of common learning objects. The new lessons can bemore valuable to the learner, as they have new semantic relationships previouslynot present in the content graph; they are also reusable for later usage.

7

Representing content generation rules on BUL is subject to further research,so that SiteLang can support specifying the rules for both generation methodsmentioned above.

4.4 Content Versioning with SiteLangIn the learning process, it is essential to provide every user with the a content

version corresponding to his needs. The following needs to be considered:Content Stability: After the user has begun a course, any changes on the course content must

not be released to the user as long as he has not completed it. This intuitive conditioncannot be realized in a trivial manner, i.e. just by freezing the course version, as it wouldcause an overhead when dealing with massive amounts of users.

History Continuance: It may be necessary to keep older content versions for later usage.Therefore, it must be possible to recall any older content version at any time.

Similarity Versioning: Depending on the user’s knowledge and usage history, it may be nec-essary to use parallely different versions of the same content, which are assigned to thesame unit. For instance, there may exist different difficulty versions of the same content,e.g. "basic", "intermediate", "advanced". Such parallel versions may also be subject to"classical" versioning in terms of updating content, e.g. for improvement purposes.

4.4.1 Content Modification Versioning. Course modifications, i.e.content modifications, are realized on the Business User Layer by integrat-ing a new subgraph into the existing content graph, by deleting a subgraph orby updating a node. When a course modification is performed, it must notaffect yet not completed interactions related to the respective course, in orderto preserve Content Stability. Also, new interactions related to that course maybe started after the modification: the new version should be applied to them.The following rules define how e-Learning content versioning is realized withSiteLang by means of BUL.Course Versioning: Each course is versioned separately from the other ones.Extending courses: Adding a subgraph into a course (into the content graph) increases the

course version number. All vertices and edges of the subgraph also get the increasedversion number. The new edge leading from the existing graph into the added subgraphalso receives the new version number.

Removing course parts: Removing a subgraph from a course increases the course versionnumber and adds another edge of type deleted from the subgraph’s father to the subgraph.

Updating courses: Updating a node in a course (a topic, a unit or a content node) increases theversion number of the course and creates a new node of the same type. This new node isconnected with the same nodes and by new edges of the same type as the original node;the version number of the new edges is the increased version number.

4.4.2 Maintaining Parallel Unit Versions. Similarity Versioning is animportant aspect of user adaptivity on e-Learning content, as it is necessary toprovide users with content of appropriate difficulty level. Therefore, multipleunits with similar content of varying difficulty are grouped in a topic which isspecially marked with the property unit group. In this way, a group of unitson the BUL can be identified as "similar units". The transformation into theConceptual Layer is analogous to the one of the entire content graph.

8

5. SummaryIn our work we have presented a methodology for specifying information

logistics for e-learning applications. It is based on the operational semantics ofAbstract State Machines and has proven suitable for specifying content adap-tivity in the DaMiT project.

Our further research will be focused on deeper aspects of adaptive contentgeneration. Applying and enhancing the SiteLang methodology for an enhancedmodeling of content structures and navigation rules - the new challenges thatarose during the development - will be subject to further development as well.

Actually it is playtime with the DaMiT prototype. Users can login as learn-ers, switching their educational preferences for adaptive content navigation todifferent levels of difficulty or presentation. The system is accessible to thepublic under http://neumann.dfki.uni-sb.de/damit.

AcknowledgmentsThe authors wish to thank the active participants of the DaMiT-Project Oleg

Rostanin, Martin Memmel and Klaus P. Jantke for their encouragement andsupport, as well as other colleagues not mentioned here by name.This research was partially supported by the DFG, Berlin-Brandenburg Grad-uate School in Distributed Information Systems (DFG grant no. GRK 316).

References[Ott01] B. Ott: Grundlagen des beruflichen Lernens und Lehrens. Ganzheitliches Lernen in der

beruflichen Bildung., Cornelsen Verlag, 2000[Lie01] C. Lienemann: Informationlogistik-Qualität im Fokus, Symposion Publishing, 2001

Institute of Computer Science, Cottbus, 2000[Cau00] J. Caumanns: Automatisierte Komposition von wissensvermittelnden Dokumenten für

das World Wide Web, PhD thesis, BTU Cottbus, Cottbus, 2000[Cis01] Cisco Systems Inc.: Reusable Learning Object Strategy, Nov. 2001, Ver. 4.0[Bin01] A. Binemann-Zdanowicz: Towards Information System Modeling on the Basis of ASM

Semantics, Computer Science Report 12/01, BTU Cottbus, CS dept., Cottbus, 2001[DuT01] A. Dusterhoft, B. Thalheim: Conceptual modeling of internet sites, Proc. ER’2001,

LNCS 2224, Springer, Berlin, 2001, pp. 179-192[FST98] T. Feyer, K.-D. Schewe, B. Thalheim: Conceptual design and development of infor-

mation services, Proc. ER’98, LNCS 1507, Springer, 1998, pp. 7-20[FOS00] T. Feyer, K. Odey, K.-D. Schewe, B. Thalheim: Design of data-intensive web-based

information services, Proc. WISE’2000, IEEE, 2000[Gur95] Y. Gurevich: Evolving Algebras 1993: Lipari Guide, Specification and Validation Meth-

ods, Oxford University Press, 1995, pp. 9-36[IMS01] Global Learning Construction Inc.: Meta Data Specifications,

http://www.imsglobal.org/metadata/index.cfm[LST99] J. Lewerenz, K.-D. Schewe, B. Thalheim: Modeling data warehouses and OLAP ap-

plications by means of dialogue objects, ER’99, LNCS 1728, Springer, 1999, pp. 354-369[ScT00] K.-D. Schewe, B. Thalheim: Conceptual development of internet sites, Full-day tuto-

rial, Conf. ER’2000, Salt Lake City, 2000[Tha00] B. Thalheim: Entity-Relationship Modeling - Fundamentals of Database Technology,

Springer, Berlin, 2000

Towards Generative Engineering of Content-Intensive

Applications

-Submission to PRISE 2004-

Aleksander Binemann-Zdanowicz

Kiel UniversityComputer Science and Applied Mathematics Institute

Olshausenstr. 40, 24098 Kiel, GermanyEmail: [email protected]

Keywords behaviour anticipation, query generation, information retrieval,metadata, model management, software specifications

1 Introduction

Aspect-oriented software development has gained much importance in the re-cent years [22]. The term aspect means an abstraction localizing a cross-cuttingconcern of a software system. The idea of aspect-oriented programming is thusto develop the class structure of an object-oriented software system in parallelwith the aspects containing the cross-cutting code [26]. In parallel, the idea ofgenerative programming has been successfully pursued as a measure for speci-fying software features [15]. The comprised field of application domain analysisallows to specify so called feature models reflecting common characteristics ofclasses of the developed software as well as the dependencies between softwarefeatures.

Along with the development of web-based applications the significance ofpersistence of information has been paid increasingly much attention. Softwareengineering concepts for supporting the interaction between software behaviourviewed from the user perspective and persistent data are sought [16,3]. Content-intensive systems require a sound specification of both classes and methods ofthe software itself (in object-oriented software development) as well as of theunderlying database model. Moreover, the complexity of interaction betweenthe user and the content-intensive system requires an anticipation of the systembehaviour on both application and database sides [3,13,5,8,11].

Unfortunately, a generic architecture for content-intensive software systemsis missing. Thus, the development of a web-based information system requiresthe development of classes and methods as well as of the underlying databasemodel virtually from scratch. In order to tackle this problem, an approach tospecifying the user-related software behaviour is needed. On the other hand theapproach has to allow to obtain the specification of the underlying databasestructure upon the needs of the user.

Storyboarding techniques have proven a convenient measure for specifyingsoftware behaviour. Storyboarding is a notion developed originally in linguistics

and in movie business [16,11]. The story of interaction between the user and thewebsite is the ’intrigue’ or ’plot’ of the narrative work or an account of events.Stories can be played in different scenarios. A story space is a set of scenarios.A story space [16,13,5] can be modeled by means of a many-dimensional (multi-layered) graph:Story-space(Site) = ( scene , E , λ, κ)

transitions E ⊆ scenes × scenes λ : scene → sceneDescriptionκ : E → events × ifCond × postCond

A scene is an abstraction that distinguishes a certain general activity. Ascene is associated with a media object, with a set of involved actors, contextof the scene, applicable representation styles and a dialogue step expression forthe specification of the scene. A media object is (roughly speaking) a possiblycomplex object generated from the database. It corresponds to an extended viewon the database [28]. Typical media objects are images, sounds, videos, texts,simple web pages and so on. The context of a scene is expressed by means of metainformation regarding the media objects of the scene and its usage. A scenariois a run through a system by a set of actors [13,5]. A scenario can be sequentialor cyclic.

A graphical representation of an example login scene developed in the scopeof the Data Mining Tutor project [13,5] is given in Figure 1.

EnterLogin

:

U

Changepayment or

profile Y

j

Adaptation forinteractivelearning

Anonymous

login

j

:

Extendby addingpayment

K

Programm

selection

jModuleselection

UUnit

selection

Learnerlogin

Ky

j

U

:

Joincooperating

group

Joinsupervisedprogram

Adaptation forexperiments

with data

Login Scene With Adaptation of System Facilities

Figure 1. Dialogue Scene for Login Into the DaMiT System

During the software engineering process, database views (i.e. media objects)required by the dialogues comprised by the storyboard specification have to bedefined. In order to specify these views, a metadata description of the underlying

database content needs to be provided. In many cases existing database contenthas to be reused for the generation of such views [6,8]. Moreover, the generatedviews have to be specified differently for varying user characteristics [4,13,5,8,9].

Thus, queries constituting the media objects of scenes in a software behaviourspecification have to be obtained dynamically upon the metadata description ofthe content of the underlying database. This way of view query specification hasbeen known e.g. in the data warehousing area [19].

The natural way of query specification is to traverse the metadata structure[23]. During the traversal of metadata the query is specified with respect toits relevant dimensions. For instance, typical dimensions known from the datawarehousing area are the spatial, factual and temporal dimensions [19]. Thus,one of the challenges to be addressed in the engineering of content-intensivesoftware systems is the specification of content metadata in such a way that thistraversal can be performed generically. Despite the variety of existing standardsfor metadata, an appropriate approach to metadata modeling as part of thesoftware engineering process has been missing so far.

In this work we propose a formalized solution for obtaining metadata spec-ifications. The respective aspects related to the utilization of content in theapplication, e.g. by means of the specific content-related functionality offered tothe user, can be easily supported.

2 Example Application

The motivation example for our approach comes from the e-learning projectDaMiT (Data Mining Tutor) [8,4]. It has been realized by 10 German univer-sities as part of the German Research Society support program ’New Mediain Education’. The aim of the project was to build an interactive Web-basede-learning platform for learning Data Mining technology. The system was to im-plement context-aware content generation and delivery, under consideration ofthe skills and abilities of the learner and of his usage history. Payment functional-ity for billing only the personalized and needed content was to be implemented aswell. The developed solution should be generic and applicable to other e-learningcontent. An example session of the DaMiT is demonstrated in Figure 2.

The main identified issue was to provide appropriate content for differentlearner types, in order to achieve the goal of learning a certain topic. The ’ap-propriateness’ of content was initially measured by means of presentation anddegree of difficulty for the learner [4].

Beyond the initial project requirements it was then figured out that cus-tomized content should comprise not only appropriate presentation and diffi-culty matching learner’s abilities, but should also be optimally structured withrespect to the efficiency of the learning process for the particular learner. Thus,for achieving the same learning goal, different learning styles should be sup-ported, e.g. learning by examples or learning by formal proofs. Morevoer, for thesake of cost efficiency it should be possible to generate different scenarios off thesame content objects. The following three example learner types were identified:

Figure 2. Screenshot of the DaMiT System

Alf Smart prefers formal thinking and systematic working. Finds exam-ples not crucial, requires precise explanations instead.

Tina Creativa thinks more in pictures than in formulae. Prefers a joyfulstyle of learning, with many possibilities to divert and come back to main topiclater on. Example-oriented and not focused on details.

Joe Hacker is characterized by a high degree of pattern recognition abil-ity. Prefers examples, finds them helpful to recognize entire structures. Does notrequire full proofs.

Automated content generation for such different learner types (off the samecontent objects) could not be realized using existing approaches [14,16]. Due tothe different, strongly diverting attitudes to learning and to learning material,a unified good-for-all learning scenario cannot be created. Although the learn-ing goal is the same, different paths leading to it through the content must begenerated and followed. For instance, for Joe Hacker a learning scenario of typeSimpleExample → ComplexExample → ComplexExample2 → Theorem isoptimal, whilst the same scenario is inappropriate for Alf Naseweis, who ratherprefers the scenario Theorem → Proof → Example → Corollary.

In order to support the different utilization scenarios for varying user types,a metadata specification is needed that allows to specify the content of theparticular domain of interest, i.e. in this case the e-learning material on datamining.

Having specified a metadata schema, we realize the queries constituting themedia objects of our storyboard (i.e. database views) still need to be gener-ated by hand. In order to automatize this, a query generation mechanism mustbe introduced. As already mentioned, we obtain our queries by traversing themetadata structure in order to settle the parameters on relevant query dimen-sions [19]. However, the respective procedure is specific to a particular model ofcontent metadata, in this case the metadata of the DaMiT system.

3 Towards Generative Content Specifications

In our approach we propose a well-founded specification method for contentmetadata models on the basis of category theory [2]. Classes of objects [17]are thus defined by means of categories. Functions applicable to objects of ametadata model are modeled as functors. A brief excerpt of an abstract metadatamodel looks in our approach as follows.1

The sorts of objects we consider here are database types, attributes, andqueries. Database types may be given or derived upon existing ones [29,28].Attributes represent ’units of information’ that may be of interest for the user.Attributes can be flat or nested. They correspond to labeled subtrees of databasetype definitions. Groups of attributes may be distinguished in order to stresstheir semantic relationships. Attributes and attribute sets together with respec-tive integrity constraints can be seen as analogous to those of the relationalmodel. Queries are logic programs that return value sets of corresponding types.

Let the categories CTY PES , CATTRS , and CQUERIES be introduced. In thefollowing we will refer to the set of objects of a category C by Obj(C) and to itsset of morphisms by Mor(C).

Objects of CTY PES are database type definition terms [28]. Morphisms f :B ← A are embeddings of type A in B. The composition g f : C ← A of twomorphisms f : B ← A, g : C ← B is defined as an embedding of the embeddedtype B in C. An identity morphism idA : A ← A is additionally defined for eachobject as an intrinsic embedding of a type in itself.

Objects of CATTRS are attributes, uniquely identified by name. Morphismsf : B ← A are inclusion relations A ⊆ B [21]. The composition of morphisms isstraightforward. An identity morphism idA : A ← A is given by the reflexivityof ⊆.

Objects of CQUERIES are simple queries [29]. Morphisms f : B ← A deter-mine the construction of new queries by applying query algebra operations as in[29]. The composition g f : C ← A of two morphisms f : B ← A, g : C ← B

is defined as a superposition of the query construction. An identity morphismidA : A ← A is defined as (A,A, ε). The respective associativity and identityproperties of are obvious.

We have already identified the categories of objects necessary to express con-tent metadata information. The relationships holding between these categoriesare represented as functors [2].2 Thus, we have defined a category that representsthe relevant content metadata information. It is then mapped to a concrete con-ceptual model, e.g. Entity-Relationship. This is performed in a straightforwardmanner by implementing categories as star schemata [31] and by implementingfunctors as (updatable) views on these. This way we can benefit from havingspecified the abstract essence of metadata on a higher level.

1 Due to the size limitations of this abstract we focus on content metadata in the strictsense here. This work is an excerpt of a larger framework embedding the approachdiscussed here, though.

2 For the sake of brevity we omit the functor definition here.

The above approach allows to generate queries specifying the media objectsof a storyboard by means of operations known from the category theory. Thus,traversing metadata is generically realizable by means of pushouts/pullbacks,and limits/colimits [2].

4 Summary

In this work a novel approach to representing content metadata for generativeengineering of content-intensive applications has been proposed. It allows to cap-ture differing versions of application-specific metadata specifications in a unifiedmanner.

Our approach allows to specify content queries for storyboarding content-intensive applications. A content query is obtained by means of traversing the ab-stract metadata representation. The respective operations are realized by meansof operations developed in the category theory.

This work is embedded in the current development of a general framework forspecifying content-intensive applications. A larger proof-of-concept applicationof the approach is planned in the future.

References

1. M. Albrecht, M. Altus, M. Steeg. Conceptual Data Modeling, Implementation Pro-totyping, Transformation and Application Design - An Animating Approach usingRADD. Proc. ADBIS’97, St. Petersburg, Sept. 2-5, 1997. Vol. 1, Nevsky Dialect,1997, pp. 231-240.

2. M. Barr, C. Wells. Category theory for computing science. Prentice-Hall, 1990.3. A. Binemann-Zdanowicz, B. Thalheim. Modeling Information Services on the Basis

of ASM Semantics. Proc. ASM’2003, Lecture Notes in Computer Science 2589,Springer, 2003, pp. 408-410.

4. B. Tschiedel, A. Binemann-Zdanowicz, B. Thalheim. Logistics for Learning Ob-jects. Proc. eTrain’2003, Kluwer, Pori, July 2003.

5. A. Binemann-Zdanowicz, B. Thalheim, B. Tschiedel. Content Modeling for E-learning Services. Proc. SCI’2003, Orlando, Florida, USA, July 2003.

6. A. Binemann-Zdanowicz, B. Schulz-Bruenken, B. Tschiedel, B. Thalheim. Flexiblee-Payment based on Content and Profile in the e-Learning System DaMiT. Proc.eLearn’2003, Phoenix, Arizona, USA, November 2003.

7. A. Binemann-Zdanowicz, R. Kaschek, K.-D. Schewe, B. Thalheim. Context-AwareWeb Information Systems. Proc. APCCM’2004, January 2004.

8. A. Binemann-Zdanowicz. SiteLang::Edu - Towards a Context-Driven E-LearningContent Utilization Model. Proc. SAC’2004 (ACM SIGAPP), Nicosia, Cyprus,March 2004.

9. A. Binemann-Zdanowicz, K.-D. Schewe, B. Thalheim. Adaptation to LearningStyles. Proc. ICALT’2004, Joensuu, Finland, August/September 2004.

10. J. Sonnberger, A. Binemann-Zdanowicz. KOPRA - ein adaptives Lehr-Lernsystemfur kooperatives Lernen. Proc. GMW’2004, Graz, Austria, Sept. 2004.

11. A. Binemann-Zdanowicz. Supporting Differing Learning and Perception Styleswith Content Conditioning. Proc. ICALT’2004, Joensuu, Finland, Au-gust/September 2004.

12. A. Binemann-Zdanowicz. Towards Information System Modeling on the Basis ofASM Semantics. Computer Science Report I-12/2001, Brandenburg University ofTechnology at Cottbus, 2001.

13. A. Binemann-Zdanowicz, B. Thalheim, B. Tschiedel. Storyboarding for Adap-tive Content Generation for e-learning Web Services. Computer Science ReportI-10/2003, Brandenburg University of Technology at Cottbus, 2003.

14. P. Brusilovsky. Adaptive Hypermedia. User Model. User-Adapt. Interact. 11(1-2):87-110 (2001).

15. K. Czarnecki, U. W. Eisenecker. Generative Programming: Methods, Tools, andApplications. Addison-Wesley, 2000.

16. A. Dusterhoft, B. Thalheim. Conceptual modeling of internet sites, in: S. Kunii etal. (Eds.): Proc. of ER 2001, LNCS 2224, Springer, Berlin, 2001, pp. 179-192

17. Hesse, W., Mayr, H. C., Highlights of the SAMMOA Framework for Object Ori-ented Application Modelling, Proc. of 9 Int. Conf. on Database & Expert SystemsApplications, Aug. 98, LNCS 1460, pp. 353-373

18. IMS. http://www.ims.org.19. M. Jarke, M. Lenzerini, Y. Vassiliou, P. Vassiliadis. Fundamentals of Data Ware-

houses. Second edition, Springer, 2003.20. R. Kaschek, K.-D. Schewe, B. Thalheim. Context Modeling for Web Information

Systems.21. R. Kauppi. Einfuhrung in die Theorie der Begriffssysteme. Acta Universitatis Tam-

perensis, Ser. A, Vol. 15, Tampereen yliopisto, Tampere, 196722. G. Kiczales, J. Irwin, J. Lamping, J.-M. Loingtier, C. Videira Lopes, C. Maeda,

A. Mendhekar. Aspect-Oriented Programming. Xerox Palo Alto Research Center,1997.

23. H.-J. Lenz. A Rigorous Treatment of Micro, Macro and Meta Data. Proc. COMP-STAT, Physica-Verlag, 1994.

24. E. Lippe, A.H.M. ter Hofstede. A Category Theory Approach to Conceptual DataModeling. RAIRO Theoretical Informatics and Applications, 30(1):31–79, 1996.

25. A. I. Malcev. Algebraic systems. Springer, 1973.26. A. Rashid, E. Pulvermueller. From Object-Oriented to Aspect-Oriented Databases.

Proc. DEXA’2000, 2000.27. Resource Description Framework. http://www.w3.org/RDF/28. B. Thalheim, K.-D. Schewe. Web Information Systems: Usage, Content, and Func-

tionally Modelling. Technical report 0405, Christian Albrecht University at Kiel,Institute of Computer Science and Applied Mathematics, Kiel, April 2004.

29. B. Thalheim. Entity-Relationship Modeling - Foundations of Database Technology.Springer, 2000.

30. B. Thalheim. Informationssystem-Entwicklung. BTU Cottbus, Computer ScienceInstitute, Technical Report I-15-2003, Cottbus, 2003.

31. B. Thalheim. Abstraction Layers in Database Structuring: The Star, Snowflake andHierarchical Structuring. Computer Science Institute, Brandenburg University ofTechnology at Cottbus, Preprint I-13-2001, Cottbus, 2001.

32. M. Yaseen, B. Thalheim. Practical Database Design Methodologies. Kuwait Uni-versity, Faculty of Science, 1989.

1 of 9

Adapting to Changing Times and NeedsUNESCO - SEAMEO Conference, Bangkok, May 27-29, 2004

CULTURALLY ADAPTIVE LEARNING OBJECTS:CHALLENGES FOR EDUCATORS AND DEVELOPERS

Authors:

Dr. Paul Nicholson *(contact author)Faculty of Education, Deakin University221 Burwood Highway, Burwood Australia 3125phone: +613 9244 6922fax: +613 9244 [email protected]

Prof. Dr. Bernhard ThalheimInstitute of Computer Science and Applied MathematicsUniversity of Kiel, Olshausenstr. 40.D-24098 Kiel, [email protected]

AbstractAs globalisation and internationalisation increasingly impact on Education,there is an emerging awareness that there are significant economic benefitsin adopting pre-designed (mainly western) ‘learning objects’ as the basis ofcurriculum design and implementation over developing locally createdcurricula and content. The potential dangers of such an approach includeloss of cultural heritage and diversity, and consequent social dislocation,loss of intellectual capital, and forced alignment with externally imposedcurricula. In this paper we argue that the major problem facing localcourseware developers is that of representing cultural artefacts in theircourseware. We discuss an emerging learning-object model that can beadopted to address this problem by providing a systematic way to approachimplementing and representing cultural artefacts in courseware. This alsoprovides a basis for some aspects of computer-based cultural preservationinitiatives. We argue that while this approach may have higher short termdevelopment costs, the potential long term benefits to the society faroutweigh short term considerations.

Culturally Adaptive Learning Objects: Challenges for Educators and Developers

Paul Nicholson Bernhard ThalheimDeakin University, Australia University of Kiel, Germany


AbstractAs globalisation and internationalisation increasingly impact on Education, there is anemerging awareness that there are significant economic benefits in adopting pre-designed(mainly western) ‘learning objects’ as the basis of curriculum design and implementation overdeveloping locally created curricula and content. The potential dangers of such an approachinclude loss of cultural heritage and diversity, and consequent social dislocation, loss ofintellectual capital, and forced alignment with externally imposed curricula. In this paper weargue that the major problem facing local courseware developers is that of representing culturalartefacts in their courseware. We discuss an emerging learning-object model that can beadopted to address this problem by providing a systematic way to approach implementing andrepresenting cultural artefacts in courseware. This also provides a basis for some aspects ofcomputer-based cultural preservation initiatives. We argue that while this approach may havehigher short term development costs, the potential long term benefits to the society faroutweigh short term considerations.

Background: prior concerns with ICT-based educationIt has been conservatively estimated that there will be between 30 and 80 million onlinestudents in the world by 2025. Globally, but particularly in the West, universities, schools, andschool systems are investing huge resources in the development of ubiquitous online educationprograms in order to either compete in the global education marketplace, or to achieve as yetunrealised productivity improvements and cost savings. The investment in classroom-basedInformation and Communications Technology (ICT) is presumably larger but has occurredover the past 40 years and has now assumed a mainstream role in many countries. The issueswe discuss in this paper (other than specific aspects of online communications) apply equallyto both classroom-based and online learning. The wide-scale investment in ICT-based online courses (in particular) has beenaccompanied by questions about their nature, efficacy and quality. However, while investmentin ICT-based education has increased, much of this has focused on infrastructure and littleattention has been paid to developing appropriate pedagogical practices. The result has beenthe implementation of simple instructional design models and platforms such as IntelligentTutoring Systems that often produce ‘…visually appealing and interactive screens behindwhich there is a shallow representation of content and pedagogy.’ (Lesh, Byrne, & White,2003; Murray, 1999). This has been to the detriment of quality teaching, and has led toincreasing concerns about the quality of online courses. (e.g., Gartner Inc, 2001; Oliver, 2001;Symonds, 2001). Concerns about the influence of quality assurance driven models on thestructure and quality of these programs, and their ability to deliver meaningful pedagogicallystructured learning experiences, have also been raised (e.g., McGorry, 2003; Stone Wiske,Sick, & Wirsig, 2001; Suthers, Hundhausen, & Girardeau, 2003). Many online learners feelisolated from tutors and peers, suffer from a lack of tutor support, convenient and effectiveinteraction, and a lack of strategies for actively involving them in their online learning. Manyof these concerns also apply to face-to-face ICT-based classrooms: romantic notions of goodteaching and charismatic pedagogy are not supported by research into the use of ICT ineducation. These concerns highlight the need to pay more attention to implementing effectiveteaching strategies and to meeting students’ learning needs.

The concerns about quality and pedagogical issues discussed above are largelyembedded in a default western educational paradigm that assumes common educational andcultural norms (e.g., Grey, 2001) in which issues of culture are largely minimized (cf. Braak,2000) or ignored other than in some attempts to ‘localize’ content so as to make it morerelevant or interesting to specific situations (e.g., Bennett, 2000). This situation has arisenbecause of the greater and more extensive use of ICT in education in western countries overthe past 40 years. Now that the West is, and always will be, the minority player on the Internet,there are increasing pressures to examine the underpinning cultural assumptions about ICT usein Education, These inherent limitations are increasingly being recognised in a number ofexploratory studies that attempt to identify what might kinds of entities might need to beadapted for the successful adoption of ICT-based learning in a range of cultural settings (e.g.,Brown & Hedberg, 2001; Leonard, 2000). The problems associated with accommodating cultural considerations in face-to-facewestern classrooms (n.b., an idealised notion) are both complex and problematic, even at thelevel of basic classroom management where issues such as cultural diversity and culturallyresponsive pedagogies have to be addressed (Weinstein, Tomlinson-Clarke, & Curran, 2004).In many cases individual teachers are able to adapt, mediate and facilitate students’ learning indifferent cultural contexts, but the level of cultural adaptation within a particular classroomdepends largely on the teacher’s multicultural competence, experience and insight intopotential issues, problems and effective pedagogical approaches (cf. Buzzelli & Johnston,2002). However, when wider socio-cultural issues such as class, colour, ethnicity, gender,language, race and religion are considered, the level of complexity in such classroomsincreases enormously (Kurilof & Reichert, 2003). While many teachers find such classroomsdifficult to manage, others thrive in the rich multicultural milieu. In general, it is fair to say thatthe response from course developers and content providers has been to largely ignore culturalissues in ICT-based learning contexts and to offer products, such as courses or ‘learningobjects’ (computer-based curriculum materials packaged according to particular standard) thatare based on the idealised western classroom. As globalisation and internationalisation increasingly impact on Education, there is anemerging awareness that there are significant economic benefits in adopting pre-designed andtested learning objects as the basis of curriculum design and implementation over local contentdevelopment. This is becoming increasingly obvious in the educational marketplace where wesee the rapid proliferation of westernised learning objects that offer the promise of reusable,low cost, and tested materials (e.g., Nevile & Smith, 2003). The potential dangers of such anapproach include loss of cultural heritage and diversity, and consequent social dislocation, lossof intellectual capital, and forced alignment with externally imposed curricula. The contemporary educational fascination with learning objects is based in economictheory, not in Education. Learning objects do have the potential to deliver significant costsavings if their cost of development can be amortised over many clients. For example, imagineif every Chinese teacher used one learning object per week – that would be an enormousmarket with a high rate of return on the investment needed to create the object. There wouldalso be a related cost reduction for those educational authorities who no longer needed to createand distribute the educational resource that the learning object has replaced. Ordonez arguesthat ‘Governments must swim against the current in the free market competition, avoid this‘race to the bottom’ in providing incentives and cutting on government revenues, and ensureminimum government support for social safety nets, and for basic education to start with.(Ordonez, 2001, p.96) This cannot be overemphasised – the potential for western learningobjects to dominate and subvert individual cultures is enormous. As a loose analogy, Ordonezreminds us of how the ubiquitous uptake of television has impacted on peoples’ expectations ofmedia and ‘…lowered our tolerance for anything not spellbinding’. The contemporary

manifestations of this are evident in almost every western classroom, as well as in those ofmany other cultures. The relevance of his point for this paper is that many, perhaps most,locally produced educational content struggles to be as ‘glossy’ and vibrant as commerciallyproduced materials – while it may, in fact, be far superior culturally and educationally. At whatcost do we discard local educational and cultural knowledge and authenticity for globalisedmedia products?

The challenge of cultureCulture is a complex multi-faceted construct with dimensions including class, colour,

customs, ethnicity, gender, language, moral codes, power-distance, religion and socialconventions (and many more). How these and other elements impact on educational practice –curricula, the nature and role of the teacher and the learner etc. — is ill defined andproblematic as there is no one model of ‘culture’ that can be used to compare and relate suchcultural elements to educational practice. Obviously there are major influences, such asreligion, an historical connection to land, and politics, that can have significant recognisableand definable effects on education, but these are the exception rather than the norm; culturalpervasion of learning can be both overt and subtle. For designers of ICT-based learningmaterials, identifying and accommodating cultural issues for a specific cultural group seems tocurrently involve addressing political and religious sensitivities, using appropriate language,and targeting presumed preferred learning styles. For example, whereas western students areassumed to cope with constructivist learning materials, Chinese students are presumed toprefer instructivist materials and are often assumed to adapt easily to traditional westerncourses. Such responses do not address the real complexity of incorporating culturalconsiderations into learning environments in a holistic way, but rather serve as add-ons that aregenerally derived from western psychological models of learning styles and education. Thisshould not be taken to mean that they are therefore not useful starting places — indeed theyare! The problem with them is simply that they are not an integral part of a more inclusive androbust model of ‘culture’ that can be mapped onto entities such as learning objects – which iswhat is needed to systematically identify and address cultural considerations in ICT-basedenvironments. Unfortunately there is no such single holistic model available for such use. It’salso idealistic to expect such a comprehensive model to exist at all! Our central argument here is that there is a need for significant development to occur inthis area if there is really going to be an attempt to seriously and systematically accommodatecultural elements in software, let alone redress the issues described previously. The followingexample attempts to suggest some reasons why this is so. China has recently made e-learning(both online and face-to-face) a national priority area in an attempt to address concerns aboutfuture access and equity issues. Hidden in this is the issue of how to meet the needs of China’s56 ethnic groups – each with a distinct culture, and those of the majority Han people. A‘simple’ first-order approach might be to develop a common content repository and to thenprovide 56 different language versions online. However, unless the intention is to deliver acommon national curriculum, including values, attitudes, culture etc., the very notion of such arepository is problematic because of the diversity of culturally-situated knowledge of eachethnic group. This is a challenge that is far beyond educators, course developers or technicalexperts. Its eventual solution will require partnerships between centres of cultural expertise,education, politics, computer scientists and various technical folk.

The need for agile modelsThe social sciences inherently accommodate complexity and uncertainty in ways that

are quite different from the physical sciences. This is evident in the kinds of models that each

produces, and how they get produced, with the social sciences embracing a more inclusiverange of research paradigms and methodologies. In the context of this paper, Agile Models areparticularly attractive for attempts to model cultural artefacts. These are models that ‘..fulfiltheir purpose, are understandable, and are sufficiently accurate’ and which are ‘…anabstraction that sufficiently describes one or more aspects of a problem, or a potential solutionto a problem.’ (Ambler, 2001a, 2001b) As such, they allow for iterative development andimprovement over time as researchers and developers increase their understandings of theartefacts they are modelling.

The really significant aspect of building culturally-adaptive ICT-based learningmaterials around agile models is exactly this issue — they embrace both a realistic perspectiveon the complexity of the task and allow for its ongoing improvement by all kinds of culturaland technical experts in common sense ways. This is arguably in stark contrast to many ICTdevelopments where precise definitions and boundaries are locked in at the start of thedevelopment process which then simply implements those agreements. For cultural andeducational academics and other experts, agile models facilitate both an entrée and adevelopmental pathway for them to work in partnership with technical personnel. Many of theissues discussed at the beginning of this paper have their origins in the failure of such adialogue to occur. This apparently simple issue may well be one of great importance if wide-scale cultural adaptation is to occur in a meaningful, partnership-based model.

Tentative steps in designing for cultureIn the following we give an example of how combining research from Computer Science andEducation can provide more holistic understandings of the kinds of issues that need to beidentified and modelled in developing culturally-adaptive ICT-based learning environments.This is not yet an example of an agile cultural model, but it will hopefully provide theunderpinning technical framework around which such a model might be developed.

1. Educational perspectives:When educators create classroom-based learning environments, they are generally

focused on content, pedagogy and assessment. Somehow these seem to be diminished in ICT-based learning environments where the nature and use of the technology itself often dominatesdesign processes and pedagogical aspects are minimised (cf. Cornu, 2001; Nicholson & White,2001; Watson, 2001). This is often due to the large technical overheads involved in developingcourses in commercial learning management systems (e.g., WebCT) ‘swamping’ technicallyinexperienced educators; it’s often seen as relief just to get basic course materials into thesystem. There is also the common problem that most of these commercial systems don’t havepedagogically-oriented design and development processes for use by educators in developingtheir online courses. In response to this and related issues, the Layered-design Model(Nicholson & White, 2001) was developed to help educators to focus on important learner-oriented aspects of course development by drawing their attention to the layers above the basictechnical design. Figure 1 shows the basic components (layers) of this model.

Figure 1: Basic elements of the layered-design model. (Nicholson & White, 2001)

Each ‘layer’ represents a different set of design decisions and foci (see Table 1). Byfunctionally separating design decisions into the categories of basic design, interaction, learnerexpertise and culturally sensitive assessment, we join technical considerations with theiroperationalisation in the classroom, decouple the ways in which learners interact with content,teachers and each other, and how they develop to their maximum potential in this environment.In this layers it is necessary to consider issues such as pedagogy, mentoring, scaffolding andcoaching, all of which help to ensure a learner-centred, active learning environment is createdon top of the basic technology. In previous works, we have articulated this new approach todesigning learning environments that is particularly attractive for online learning (Nicholson,2004; Nicholson & White, 2002).

Table 1: The layered-design model for E-Learning (Nicholson & White, 2001)Layer What it focuses on

Basic design Selection and implementation of technology; choosing the instructionaldesign architecture; content selection or development; curriculum design.

InteractionIdentifying the models that will guide the ways in which users interact withstudents, staff & content; process facilitation design—mentoring models,use of discussions etc.

Learner expertise Elements that contribute to the learners’ optimal cognitive development.

Culturally sensitiveassessment

Developing an assessment protocol that allows for a diverse range ofcultural and educational responses.

The power of this model is not in its ability to prescribe a particular instructionaldesign, but rather, to keep the instructional design process focusing on designing for learners.The focus on culturally sensitive assessment is currently a key element of our strategy toensure that the whole design process does not revert to a traditional instructional designexercise, and that at a very basic level, we begin to address cultural issues, To add moreextensive cultural elements (as discussed above) to this model requires that the items in each ofthe layers be interpreted in culturally appropriate ways. Of course this requires extensivecultural insights into the targeted culture, and even with such insight, this is not an easy task todo. This is a key area where educators and cultural experts need to have extensive ongoingpartnerships. This challenge is even more daunting when it becomes obvious that this processalso needs to be systematized and implemented in ways that can be meaningfully implementedand operationalised in software environments; scholarly, hand-crafted learning environmentsare too slow and expensive to create, and may not be readily scaled up in learning managementsystems. A fundamental problem is that educators often do not have the requisite technicalknowledge to bridge the gap between their educational understandings, desires and intents forlearning environments, and those of the technically savvy courseware developers. There is aurgent need to find ways to bridge this knowledge and epistemological divide.

In many ways, the layered-design model is a step in this direction as it can not onlyguide educators in their course development, but also forms a conceptual framework for ageneralised learning object (at a course level) that contains higher-order entities such asscaffolding and coaching. This begins to have use for both educators and developers as itprovides a reference framework that can be understood by both. However, there is still theissue of actually implementing the aspects of the model in software. A possible strategy toaddress this issue is to here is a real need for partnerships between educators and computerscientists to develop ways of modelling and implementing such ‘soft’ educational constructs as

coaching, mentoring and scaffolding in ways that current development systems, and educators,can make use of.

2. Technical perspectivesFrom a computer science perspective, creating a learning object that incorporates culturalelements is essentially the same as creating one without cultural elements – identifying,structuring and linking together the various entities in a structured database. However, thedifference between them is that nature and complexity of cultural entities and theirrelationships with one another are vastly more complex than the typical instructional entitieswe find in contemporary learning objects. Technically, the challenge revolves largely aroundbeing able to model the higher-order entity-relationships that characterise many educationalentities.

Developments in this direction have arisen from concerns about knowledge,information and learning environment models, some of which are similar to those discussedabove, from within the computer science field (e.g., Binemann-Zdanowicz, Thalheim, &Tschiedel, 2004). Serendipitously, some of these developments can be mapped onto thelayered-design model, creating the possibility of creating entity-relationship models of someeducational constructs such as coaching, mentoring and scaffolding that might form the basisof further exploration of their potential to be used in creating culturally-adaptive versions.However, the complexity of this challenge should be underestimated, as the following exampleshows. Teachers often provide cognitive scaffolding (Vygotsky, 1962) to help students toovercome difficulties with specific content and ideas. This takes the form of short-term supportstrategies that will help the student to better understand the ideas in question. With the aid ofthis temporary support (hence the term ‘scaffold’), the student’s learning can progress. Inaddition to the teacher’s initial diagnosis of a problem, scaffolding consists of providing thelearner with increased support in the form of tools (such as concept maps, computers, books),peer support, adult guidance, or particular information management and synthesis strategies.After this support has been given, and the student has begun to learn the material, the level ofsupport is reduced (‘faded’) so that the learner again operates independently with this newlyacquired knowledge. To do this well is difficult in a face-to-face classroom; to do this in anonline environment, for example, is highly complex. It is even more complex to attempt toautomate or systematize this in an LMS or learning object because so much of this simpleconcept revolves around the teacher’s ability to diagnose problems and to select and implementappropriate scaffolding mechanisms. The implications of trying to develop culturally-sensitivescaffolding models — assuming that this is a valid thing to do — require that we also addressthe complex cultural issues discussed above.

ConclusionsThere is great potential for major advances in the development of culturally-adaptive

learning environments and associated learning objects. Such advances will depend on targetedand well-funded partnerships between educators, course developers and computer scientists.While the expected development costs are high (but with low usage costs), their economic costmust be measured against the societal and socio-cultural benefits of adopting a culturallyadaptive model.

Globally, minority groups are seeking recognition of their diversity at the same time asglobalisation is threatening to homogenise large parts of the world’s populations. The issuesraised in this paper provide a starting point for realising these and other kinds of culturalaspirations by providing a starting point for implementing a culturally sensitive developmentframework for E-Learning in accordance with UNESCO’s vision for the transformative use oftechnology in education.

References

Ambler, S. W. (2001a, May 01). When is a model agile? Part 1: What agile models should accomplish.Retrieved from http://www-106.ibm.com/developerworks/webservices/library/co-tipam2.html

Ambler, S. W. (2001b, May 01). When is a model agile? Part 2: Traits agile models should have.Retrieved from http://www-106.ibm.com/developerworks/webservices/library/co-tipam3.html

Bennett, J. A. (2000). Technology and the Navajo - Its Time Has Come. In Proceedings of the Societyfor Information Technology and Teacher Education International Conference (pp. 262-263).[Online]. Available http://dl.aace.org/486

Binemann-Zdanowicz, A., Thalheim, B., & Tschiedel, B. (2004). Logistics for Learning Objects. In P.S. Nicholson, B. Thompson, M. Ruohonen & J. Multisilta (Eds.), E-Training practices forprofessional organisations. New York: Kluwer.

Braak, J. (2000). Cultural and gender differences in computing among secondary school children. InProceedings of the World Conference on Educational Multimedia, Hypermedia andTelecommunications (pp. 1534-1535). [Online]. Available http://dl.aace.org/1647

Brown, I., & Hedberg, J. (2001). Recognition of Cross-Cultural Meaning When Developing OnlineWeb Displays. In Proceedings of the 2001 World Conference on Educational Multimedia,Hypermedia and Telecommunications (pp. 202-206). [Online]. http://dl.aace.org/8424

Buzzelli, C., & Johnston, B. (2002). The Moral Dimensions of Teaching: Language, Power, andCulture in Classroom Interaction. New York:: Routledge/Falmer.

Cornu, B. (2001). Winds of Change in the Teaching Profession (Report of the French NationalCommission for UNESCO). Paris: UNESCO.

Gartner Inc. (2001). E-Learning: Pedagogical Revolution in Higher Education? (Report).Grey, D. (2001). The Internet in school (2nd ed.). New York ; London: Continuum.Kurilof, P., & Reichert, M. C. (2003). Boys of class, boys of color: negotiating the academic and social

geography of an elite independent school. Journal of Social Issues, 59(4), 751-770.Leonard, C. (2000). How does one evaluate the effectiveness of electronic learning in a South African

context? In Proceedings of the World Conference on Educational Multimedia, Hypermedia andTelecommunications (pp. 1419-1420). [Online]. Available http://dl.aace.org/1596

Lesh, R., Byrne, S. K., & White, P. (2003). Research in Technology and Distance Learning inEducation: Focusing on Complexity, Collaboration, and Communication: Not JustTransmission of Information. In T. M. Duffy & J. Kirkley (Eds.), Learner Centred Theory andPractice in Distance Education: Cases From Higher Education. Mahwah: Lawrence Erlbaum.

McGorry, S. Y. (2003). Measuring quality in online programs. The Internet & Higher Education, 6(2),159-177.

Murray, T. (1999). Authoring Intelligent Tutoring Systems: An analysis of the state of the art.International Journal of Artificial Intelligence in Education, 10, 98-129.

Nevile, L., & Smith, E. (2003, July 5-9). Better Object Descriptions to make Education moreAccessible. Retrieved 25/02 from http://ausweb.scu.edu.au/aw03/papers/nevile/paper.html

Nicholson, P. S. (2004). E-Training or E-Learning? Towards a synthesis for the knowledge-eraworkplace. In P. S. Nicholson, B. Fraser, M. Ruhoenen & J. Multisilta (Eds.), Elearningsolutions for professional organisations. New York: Kluwer.

Nicholson, P. S., & White, G. (2001). Teaching for Quality Learning Online: A layered Design Modelfor Higher-order Thinking. In D. Watson & J. Andersen (Eds.), Computers in Education (pp.49-58). Copenhagen, DK: Kluwer.

Nicholson, P. S., & White, G. (2002). A framework for facilitating higher-order strategic thinking inonline management development. In R. Tranmuller (Ed.), Information Systems: The E-BusinessChallenge (pp. 199-207). Dordrecht: NL: Kluwer.

Oliver, R. (2001, 2–4 September). Assuring the quality of online learning in Australian highereducation. Paper presented at the Moving online conference, Gold Coast, Queensland AU.[Online]. Available http://www.scu.edu.au/schools/sawd/moconf/

Ordonez, V. (2001). The Way Ahead. In UNESCO-ACEID (Ed.), Information Technologies inEducational Innovation for Development: Interfacing Global and Indigenous Knowledge (pp.96-98). Bangkok: UNESCO. [Online]. Availablehttp://www.unescobkk.org/ips/ebooks/documents/aceidconf6/index.htm

Stone Wiske, M., Sick, M., & Wirsig, S. (2001). New technologies to support teaching forunderstanding. International Journal of Educational Research, 35(5), 483.

Suthers, D., Hundhausen, C., & Girardeau, L. (2003). Comparing the roles of representations in face-to-face & online computer supported collaborative learning. Computers & Education, 41(4), 335.

Symonds, W. C. (2001, December 3). Giving it the old online try. Business Week online.Vygotsky, L. S. (1962). Thought and Language. Cambridge, MA: MIT Press.Watson, D. (2001). Pedagogy before Technology: Re-thinking the relationship between ICT and

Teaching. Education and Information Technologies, 6(4), 251-266.Weinstein, C. S., Tomlinson-Clarke, S., & Curran, M. (2004). Toward a conception of culturally

responsive classroom management. Journal of Teacher Education, 55(1), 25-39.

Storyboarding Concepts for EdutainmentWIS

Klaus-Dieter Schewe1 and Bernhard Thalheim2

1 Massey University,Department of Information Systems & Information Science Research Centre,

Private Bag 11 222, Palmerston North, New Zealand2 Christian Albrechts University Kiel,

Department of Computer Science, D-24098 Kiel, Germany


Abstract. Edutainment web information systems must be adaptable to the user, to thecontent currently available, to the technical environment of the user, and to the skills,abilities and needs of the learner. This paper provides conceptions that support thiskind of adaptivity and sophisticated support.

1 Introduction

1.1 Edutainment Web Information Systems

E-learning is now nearly as popular as e-commerce and e-business. The providers range fromuniversities over non-profit organisations to professional training institutions. Furthermore,sites of museums, exhibitions, etc. can be counted as learning web information systems. Ingeneral, every data-intensive information system that is realised in a way that users can accessit via web browsers will be called a web information system (WIS).

The major intention of a learning WIS should be to support learning. In the case of so-called edutainment systems the provided knowledge is usually easy to grasp. The message isthat learning can be fun. The usage of a learning system depends on whether the control ofthe learning process is left to the user or the system. In both cases, however, it is assumed thatthe users are willing to learn and match the required prerequisites.

The content of a learning site depends on the area that is to be taught. Learning sessionsare used as structural means, and navigation through these sessions may be organised in linearform or as a directed acyclic graph [ST05].

Systems may be completely passive allowing only material to be read or downloaded.Other systems may involve upload mechanisms for assessment of the learning progress. Ac-cording to the progress made, a system may even provide feedback to its user. We concentrateour work on active learning.

The functionality of learning sites mainly supports the navigation through the site, i.e.,the navigation through the learning material. In contrast to other systems, this navigation isa long-term progress with usually many interruptions. More sophisticated systems providesystem-driven repetition and feedback. Apparently, the functionality of such systems is stilla matter of research. Also, personal information needs can be supported by providing aninterface to e-mail.

1.2 Achievements and Challenges of Edutainment WIS

A large number of websites provide learning and edutainment services has already been de-veloped. Examples of technology-supported learning include computer-based training sys-tems, interactive learning environments [DN03], intelligent computer-aided instruction sys-tems [RK04, BGW92], distance learning systems, and collaborative learning environments.Developers have learned a number of lessons. Edutainment should neither be considered tobe yet another presentation from for classical instructionistic learning nor a means for pre-sentation of content that has been used for lecturing.

Edutainment should not be understood as the enrichment of learning by multimedia fa-cilities but must concentrate on content that is presented in a pleasing form, that is easy touse and to understand, that is enriched by functionality which corresponds to the content, andthat allows to control the progress in learning.

Edutainment might support everybody to participate in learning activities on any placeat any time within any team. Learning cultures will however limit this globalisation claim.Learner have their profile and their portfolio.

Main kind of learning stories are complementary learning, self-organised learning andcontinuing education on demand. Learner must thus be supported in developing their ownlearning space and in understanding and developing their learning abilities.

Controlling and assessment cannot be completely automatised. Each user is different fromthe other. The context differs. The learning history is different. At the same time, learnersoften need an immediate feedback.

Edutainment can be supported by a number of devices ranging from computers and PDA’sto mobile phones. We thus distinguish between electronic learning (e-learning) systems andmobile learning (m-learning) systems. Mobile phones and mobility in general are changingpeople’s way of working, communication and learning. The differences between formal learn-ing, informal learning and way of working will diminish. The real added value of m-learningis in the area of informal learning whereas e-learning may cover formal and informal learning.

Scenarios and content are multifaceted, depend on the presentation device, and must beadaptable to the learner, to the learning community. The type of learning will be differentfrom classical ones. The style of learning changes to pro-active formal learning with selfstudy content, virtual classroom and trainer based facilitation. Learning is social, arguing,reflecting, articulating, and debating with others.

Majority of learning in the web is informal learning. It is based on ad-hoc informationsharing and on communications and collaboration. The functionality of edutainment WIS isalso based on functions such as participation, contribution, and annotation.

1.3 Scope of this Paper

This paper introduces some new conceptions we have already used in our edutainment WISprojects: DaMiT (a data mining tutoring workbench), KoPra (cooperative learning of databaseprogramming), and Learning Lusitia (continuing life-long learning for engineers and alum-nis). We extend the classical concept of learning objects [LOM00, LTS00] to open learningobjects, show how scenario development [For94] leads to sophisticated support for didac-tics, and provide an insight into development of appropriate functionality. Additionally weshow how brands of edutainment WIS, actor specification, learning scenarios, content andfunctionality can be developed for sophisticated edutainment WIS.

2 The Five General Characteristics of Edutainment WIS

2.1 The Brand of Edutainment WIS

The pattern or brand of the edutainment WIS PW2UA (Provider P , knowledge W , user U ,activities A) generalises the classical who-to-whom pattern (e.g. B2B). It is specialized foredutainment WIS:

Provider: Providers are currently mainly educational institutions or educational communi-ties. In future, we will observe commercialisation of education. So, main providers aregoing to be companies. If a provider is a singleton person then this provider plays the roleof the teacher.

Product dimension: Since control and assessment of learning progress is a still unsolvedissue and appropriate presentation of complex information is often not feasible, edutain-ment WIS concentrate on easy-to-understand information or easy-to-grasp knowledge.The associated auxiliary scenarios are based on functions such as validate, control and advice.Therefore, the brand can be characterised byPK2Clearn,validate,control,advice.

User dimension: Users of edutainment WIS are mainly private people. They may be pupilsor students, people seeking for continuing education, workers in companies with specificportfolio, or just people interested in auxiliary information. Users can be also groups. Themain behavior of users is characterised by the role of the learner or of student.

Activity dimension: Activities are currently centered around learning, searching for content,collecting content, and solving exercises. Activities also include to ask questions, to actin teams for problem solving, and to discuss issues associated with the learning material.

Edutainment (learning) sites (BK2Clearn, CK2Clearn) are then specialized to the brands:Teachercontent chunks2Studentreceive,respond,solve in teams,raise questions,possibly apply

Teachercontent chunks2Studentrecognise,listen,work on it,solve exercises,ask urgent questions

TeacherKnowledge2Studentdiscuss,get feedback,work on it

TeacherKnowledge2Student Groupdiscuss,get feedback,work on it andTeacherWisdom2Studentdiscuss,get feedback,work on it .

2.2 Actors in Edutainment

Edutainment WIS are currently mainly or exclusively supporting the pupil or student actor.The behaviour of actors might however be more complex:

Pupils obtain knowledge through teachers, their schedules, and their abilities. They needguidance, motivation, and control.

Collaborating or cooperating students act in a collaboration depending on a cooperationprofile and rights and roles.

Communication partners exchange content, discuss and resolve questions, seek for hintsor for better understanding.

Supporting and motivating partners are users with control, motivation and supporting func-tions.

Teachers act in various roles, obligations, rights, and in a variety of involvement.

The nature of the activities that constitute teaching depends more on the age of the personsbeing taught than on any other one thing. Users are different in their history. We distinguishbetween learner that initially seek to increase their knowledge and skills and users that areseeking continuing education. The first group of learners needs some guidance. Therefore,the learning style is based on pedagogic teacher-based learning. The latter are self-organised.We call then andragogic learners. The differences between the two learning styles are givenin the following table:

andragogic self-organized learning pedagogic teacher-based learningindependent learner dependent learnerself-regulated learning not necessarily self-regulated learningself-motivated learning need to be motivatedreflective needs help for learningarguably needs help for learninganalytical needs help for learningsituated in real world context structured engaged with knowledge

2.3 Learning Scenarios and Stories

Modelling of e-learning scenarios is more difficult due to the variety of didactic approach,to the variety of learners, to the variety of tasks and the context of the site. For this reason,modelling of dialogue scenes and dialogue steps is more generic than modelling of simpleinteraction steps that usually lead to deterministic runs through the story space. We, thus,distinguish a number of associations among steps and scenes depending on the content of thelearning element.

Our solution to this challenge is based on generic parameters that are instantiated depend-ing on the learner, the history, the context etc. Each learning unit is specified by a context-free expression with a set of parameters. These parameters are instantiated depending on thelearner profile, the learner task portfolio, the media objects, the learner computational envi-ronment, the data to be used in exercises or algorithms, the presentation environment, and theavailable and accessible learning elements.

Learning scenarios (learn) are classically based on general learning styles:

Sequenced learning is based on a curriculum sequencing in active or passive scenariosbased on classical pedagogical approaches. Typical established pedagogical approachesare conditioning, operated learning, model learning, cognitive approaches. Sequencing isextensively studied based on classical didactics. Active scenarios model behaviour of ac-tive actors. A typical metaphor to be applied is the shopping bag. Passive scenarios didnot get the success that has been expected during the 80ies and 90ies. Tutoring systemsare applicable for advisory systems, for help desks, or for training physical skills.

Interactive learning is either based on self-organized or content-sequenced or habit-regulatedor publish-subscribe scenarios.

Group learning is based on a cooperative setting (integrated sub-tasks, black boarding) or ina collaborative setting (cooperation, discussion, development of solution by all members).

Sequenced learning is currently mainly based on didactic approaches, i.e. on instructions,classical content and classical hermeneutics. Due to the sequential way dependencies amonglearning units are rather simple. Learning scenes use reception techniques, explication of thelearning content, context association, deriving understanding and interpretation, and finallyintegrating the essence of the content into the knowledge of the learner.

2.4 Content in Edutainment

Content used in edutainment WIS is mainly easy-to-grasp and easy-to-understand informa-tion or knowledge. Most important associated scenarios are validate, control and advice. Contentis given in a large variety. We need therefore to consider the kind of content, the activitiesthat can be associated with the content, the characterisation and annotation of content, andfinally the quality characteristics of content. Edutainment content delivery, storage, retrieval,and extraction is still an open research issue.

Edutainment WIS provide content to learners depending on their learning task, theirpersonality, their working environment, their learning history and the policy of the contentprovider. This challenge is more complex than the challenge to generate “content”. Contentcan be represented by media objects. Content for learning must have high adaptivity. Wedistinguish a variety of content or generally knowledge:• knowledge and abilities for orientation, e.g., explanation, presentation, history, facts, sur-

veys, overview;

• knowledge and abilities for application, skills, abilities rules, procedures, principles, strat-egy, and laws;

• knowledge and abilities for explanation, e.g., ‘why’-knowledge (proof, causal) and ‘what’-knowledge (definition, description, argument, assumption, reflection);

• knowledge and abilities on sources, e.g. archives, documents, citation, reference, andlinks;

• knowledge and abilities for solving problems, e.g., sample solutions, analogs, trainingsolutions, discovery solution, and examination.

All media objects can be provided independently of the learner. We need however to consideralso differences. Background knowledge leads to different speed and reception by the learner.Work abilities and habits influence current work. The learning style must be considered inmany facets. The social environment is based on cultural and psychological differences. Thehistory of the learning process should be considered if we want to avoid annoying repetitions.The learning portfolio influences occasion, intention and motivation. The learning objectpresentation is or is not acceptable depending on the profile of the learner. The learningenvironment is modelled by many technical facets. Content change management allows toprovide content with or without refresh. The payment profile may result in content reduction.

Learning objects are elements of a new type of computer-based instruction influenced bythe object-oriented paradigm of computer science. Learning objects are defined here as anymedia object which can be used, re-used or referenced during technology supported learning.Examples of learning objects include multimedia content, instructional content, learning ob-jectives, instructional software and software tools, and persons, organizations, or events ref-erenced during technology supported learning. The IEEEs Learning Technology Standards

Committee has developed an internationally recognized definition of “learning object”: “anyentity, digital or non-digital, that can be used, re-used, or referenced during technology sup-ported learning”. This definition is extraordinarily broad.

A large variety of learning elements is used in edutainment WIS. Course elements arelecture notes and comments. Exercise material may be given in a textual or in an interactiveform Illustration material is often based on animations, complex multimedia elements or onlinks. Algorithms can be provided in an executable form, as virtual machine or via an interfaceto the server. Input data for algorithms can be provided with the learning elements or throughother elements in the network.

2.5 General Functionality Based on Word Fields

During requirements capture WIS design and development we use natural language descrip-tions for analysing the activities of the users: What are these activities? Does the descriptionindicate any sequencing or continuation? What data is needed for or used by the activities?What are the relationships between these data? As user activities can be described by verbs,we suggest analysing the corresponding word fields.

A word field [Kun92, SSS90, BZKK+05] is a linguistic system in which similar wordsthat describe the “same” basic semen and are used in the same context are combined toa common structure and data set. In contrast to common synonym dictionary, word fieldsdefine the possible and necessary actors, the actions and the context. Word fields can be usedfor verbs, nouns and adjectives.

Functionality of edutainment WIS is also determined by the main word fields we observefor learning. Main word fields applied in learning are:

Learn: Learning is a very complex activity. It includes to gain knowledge or understandingof or skill in by study, instruction, or experience. Additionally, learning is associatedwith memorizing, to come to be able to perform some task, and to know this ability.Learning is based on obtaining content and discover the concepts behind. It is also basedon facilities for annotation, ordering, and integrating A user obtains the role of a learner orstudent. Learners are usually supported by other actors who teach and instruct. Learnersdetermine content with certainty, usually by making an inquiry or other effort. They checkthe content, find out whether it is useful or they need additional content.

Know: Learning is based on skills, abilities, and knowledge. It target on their improvement.The improvement should be measurable. The learning success is then examined. To knowmeans to be cognizant or aware of a fact or a specific piece of information and to pos-sess knowledge or information about. It may include also to know how to do or performsomething. The learner obtains firsthand knowledge of states, situations, emotions, or sen-sations. The change in knowledge is acknowledged and recognized by other actors whocan accept to be what is claimed. The word field know used in learning is different fromone used in identity or information WIS.

Master: Learning is usually intending to master problems and to become completely profi-cient or skilled in an area. This mastership is closely related to practise and experimentwith the new knowledge. The learner has a firm understanding or knowledge of and is ontop of of a problem.

Skill: Skills are abilities that have been acquired by training, e.g. abilities to produce solu-tions in some problem. A user acting as a learner is possibly trained until he/she obtainedthese skills.

Study: The learner is engage in study and undertakes formal study of a subject Studying re-quires an endeavor and a try. In learning WIS studying is based on read in detail especiallywith the intention of learning. Therefore the presentation of the material and the story-board is an essential part. Studying does not only mean to view content but to check over,to check up, to con, to examine, to inspect, and to survey it. This activity is performedattentively and in detail. Learners need to mind, to perpend, to think (out or over), and toweigh. Therefore, users need time and workplaces. Studying can be performed by oneselfwithout any teacher, supporter, or observer. Studying is often based on the existence of aspecific workplace and of a specific workspace. Learners may thus have a study place andworkplaces which are given to them, which might be rented and which can be exportedto the user.

We observe that these word fields have a more complex structure. They lead to functionswhich require support functions. The difference to the word fields discussed for business WISis their iterative application. This kind of behaviour has already been observed for commu-nity services. Additionally, learning can be performed within temporal communities. Otherrelated word fields are discover, ascertain, catch on, determine, teach, educate, judge, evalu-ate, advise, innovate and discuss.

Learning word fields can be combined and thus form a didactic story. Learning wordfields are going to be combined with reasoning word fields such as analogise, analyse, cause,classify, conjecture, counter-example, formalise, generalise, sharpen, specialise, unknown,and weaken. General activity word fields that appear in any story are folded into our learn-ing word fields. Typical general activities are characterised by answer, comment, compose,decompose, define, draw, effect, example, extend, fact, inquire, instantiate, and reduce.

3 Novel Concepts of the Edutainment WIS DaMiT, KoPra, and Learning Lausitia

The DaMiT system [JMR+03] supports sequenced and interactive learning. Interactive learn-ing is still an open research issue. We have developed and extensively used an implementa-tion in the KOPRA project [SBZ04]. Learners act in a collaborative setting depending on theirneeds and the goals of the learning program in the project Learning Lausitia.

3.1 Supporting Didactics by SiteLang

The website description language SiteLang has been introduced in [TD01]. A scenario isan application-oriented view of parts of the storyboard. The storyboard consists of a set ofscenarios, one of which is the main scenario, whereas the others define scenes, a plot specifiedby a SiteLang process, a set of roles, a set of user types, a set of tasks each associated with agoal, and a set of constraints comprising deontic constraints for the rights and obligations ofroles, preference rules for user types, and other dependencies on the plot. We may distinguishfour main kinds of general scenarios for the three learning styles:

Content scenarios are centered around the content chunks or content suites to be deliveredto the learner, to be received by the learner, and to be integrated into his/her knowledge.

Control scenario are based on assessment or control of the success of learning. They involveat least two different actors: learners and controllers. A third actor involved may be theadvisor.

Workspace scenario are auxiliary scenario that help the learner to organise the learning ma-terial, that enhance the learner content space with memos, with excerpts, own solutions,and collaboration notes.

Collaboration scenario support the learner to learn in groups, to communicate with theirpartners and with other actors such as teachers and advisors, to coordinate activities andto cooperate during solution of exercises, content reception and development of solutions.

These four general scenarios can be seen as relatively independent scenarios that can becombined with each other depending in the learning style. We develop the story space by thedidactic scenario quadruple in Figure 1 on the basis of relatively independent scenarios andin the second step through their combination.

control scenario

contentscenario

collaborationscenario

workspace scenario

Figure 1: The didactic scenario quadruple

Edutainment didactics is currently developed for most learning WIS from scratch and bydoing. We decided to develop such didactics systematically. Edutainment didactics can bebased on general learning storyboards. Since learning is one of the most complex activitieswe support a number of additional general stories within the story space:

Teaching: Teaching is a complex activity that goes beyond instruction, that includes a pro-cess of formal training, that is based a body of specialized knowledge, and satisfies a setof standards of performanceintellectual, practical, and ethical. Teaching intends to learnerto know something, to know how to accustom to some action or attitude, and to know theconsequences of some action.

Educating: Education is similar to teaching but more intention based. It includes trainingby formal instruction and supervised practice especially in a skill, trade, or profession.It targets to persuade or condition to feel, believe, or act in a desired way. Learners arementally, morally, or aesthetically educated especially by instruction.

Judging and evaluating: Edutainment also is often oriented to form an opinion about throughsome weighing of evidence and testing of premises and to decide a matter as a judge.Learner are trained in determining or fixing the value of a matter, in determining thesignificance, worth, or condition of usually by some kind of appraisal and study.

Advising and discussing: Advising and discussion scenarios are similar to those we have al-ready considered for community WIS. Advising means to be able to use the background

knowledge of the learner or the knowledge given by the content chunks for generation ofadvices or information or for consulting. Discussion techniques are applied in edutain-ment whenever we need to investigate by reasoning or to argument or to discourse aboutin order to reach conclusions or to convince. Discussion is an exploration technique thatimplies a sifting of possibilities especially by presenting considerations pro and con.

Innovating: Innovation introduces a new idea, new content or a new activity in order toeffect a change.

These different learning scenarios can be compiled or integrated within the story space. Weuse for integration, ordering and hierarchical presentation of scenarios the theory of KAT’s.This combination is necessary whenever we need to consider different didactic approaches:

Critical-constructive didactics see learning through interaction via goals.

Learn-theoretical didactics consider learning through dialogues between actors.

Goal-oriented learning is based on a separation of the intention space into subspaces withsub-processes.

Cybernetical didactics uses regulated processes for story development.

Critical-constructive didactics are based on interactions, repetitions, and obstruction.

Curriculum planing extends classical sequenced or blended learning by schedules, goals,and steps.

3.2 Storyboard Pattern

Scenario typically proceed in one or (usually) more scenes. Scenario are describing the wayshow the work is performed and are based on didactics, goals, user purposes, and content. Astoryboard contributes to achieving a purpose or goals.

Scenes are composed of other scenes. We assume that scenes can be hierarchically formedbased on basic scenes. Typical basic scenes are the information seeking scene, the collabora-tion scene, the assessment scene, the result integration scene and the problem solution scene.Scenes can be composed with another scene based on sequential, parallel, alternative etc.composition operators.

It seems to be obvious that these scenes have a common structure and a common be-haviour. We thus can extract general stories or scenarios. These general stories use generalscenes or scene pattern. Patterns represent recurring solutions to software development prob-lems within a particular context. These scene pattern are refined to the concrete scenes.

Let us consider a typical scene pattern that involves a number of learners. Problem solu-tion scenes are one of the most complex scenes in edutainment WIS. They typically consistof an orientation or review subscene, of a problem solution scene performed in teams, and ofa finalisation subscene. Problem solution scenes are composed of a number of subscenes thatcan be classified into:

• Review of the state-of-affairs: The state of the problem solution is reviewed, evaluated,and analysed. Obligations are derived. Open problem tasks can be closed, rephrased orprioritised.

• Study of documents and resources: Available documents and resources are checked whetherthey are available, adequate and relevant for the current scene, and form a basis for thesuccessful completion of the scene.

• Discussions and elicitation with other partners: Discussions may be informal, interview-based, or systematic. The result of such discussions is measured by some quality criteriasuch as trust or confidence. They are spread among the partners with some intention suchas asking for revision, confirmation, or extension of the discussion.

• Recording and documentation of solutions: The result of the scene is usually recorded inone solution proposal.

• Classification of solutions, requirements, results: Each result developed is briefly exam-ined individually and in dependence of other results from which it depends and to whichit has an impact.

• Review of the problem solution process: Once the result to be achieved is going to berecorded the solution is examined whether is has the necessary and sufficient quality,whether is must be revised, updated or rejected, whether there are conflicts, inconsis-tencies or incompleteness or whether more may be needed. If the evaluation results inrequiring additional scenes or subscenes then the scene or the subscene is going to beextended by them.

This classification is based on the general problem solution framework discussed in [PP45].Problem solution scenes are usually iterative and thus cyclic as displayed in Figure 2. The

j Application areaunderstanding

j

Y

Phenomenonunderstanding

U

Solutionpreparation

U

K

Solutiondevelopment

y

Evaluationof solutions

U

K:

j

z

Deploymentof solutions

Problem solution scene

Figure 2: The subscenes in the edutainment problem solution scene

general frame to problem solution is then based on the problem solution or search problem:

Problem characterisation with abstracting from non-essential parts;

Context injection for simplification of the problem and of the solution;

Tools and instruments for solution based on constructors, associations, collections, and clas-sification;

Specification/prescription/description as the results of the problem solution problem.

Analysis and solution formation and problem solution are two specific activities that dependon each other. Development aims in forming solutions as well as discovering inconsistenciesand conflicts and resolving incompleteness. Solution formation is based on the mapping ofproperties, requirements or phenomenons into WIS solutions. Solutions may have alternativesolutions. These alternative solutions can be used at a later scenes instead of the given one.Typical techniques for problem solution and formation are exploration and experimentation,skeptical evaluation, conjecturing and refuting. Additional techniques are investigative onesthat use resources.

In the evaluation phase we show whether the problem solution result is correct, and if sowhat kind of tests etc. ought to be devised. We do not require completeness since this is arelative issue.

Solution validation is the process of inspection of each solution with reference to solutionsit is based on. It is based on the application area description and checks whether the rightsolutions are developed. Validation produces a report that constitutes the correctness and thatproduces the extensions and updates necessary for the base solutions.

Verification analyses solutions in order to ascertain whether what has been developed sat-isfies a number of obliged properties. It checks whether the solutions developed so far are cor-rect according to some correctness criteria and according to proof or verification techniquesthat are currently applicable. Techniques may be informal, i.e., based on verbal arguments ortests, qualitative, i.e. based on abstraction and qualitative reasoning, or formal, i.e. based onmodel checking and proof techniques.

Each of the subscenes can be refined depending on the application, the user, the content,collaboration and the control:

User refinement: Each user has a personal profile and a task portfolio. The website shouldonly use those dialogue scenes the learner is assigned to.

Learning objects refinement: Learning objects are under constant change. Whether thischange is shown to the user depends on the user profile. However, in general refinementto available content is generated for the user.

Learning objects refinement: Learning objects have prerequisites, support learning goals,and are associated to other learning objects. These associations must be made availableby the system.

Scenario refinement: The edutainment WIS also supports an adaption of the entire storycurrently requested by the user depending on the user and the completion of tasks.

Usage refinement: Users are annoyed whenever they did not complete a task and they mustbegin from scratch after resuming. For this reason, the edutainment WIS must supportalso refinement to the current usage.

It is obvious that such refinement cannot be generated by random application of refinementrules. We observe however that this can be layered. The approach to layering used in the

Learningobject space

Learning objectcorrelates

Edutainment WIScontent

Edutainment WIScontext

Edutainment WIS story enrichmentEdutainment WIS user profile and portfolio enrichment

Explicit story refinementUser refinement

Current usage refinement

Edutainment WIS on demand enrichment

Figure 3: Layering of generation and filtering against learning units

system is displayed in Figure 3. We generate first the learning scene together with its learningobjects for each of the dialogue scenes. Next we extend the set of learning objects by allassociated objects. This set of learning objects cannot be delivered to the learner in any order,e.g. prerequisites must be shown first. Some of the learning objects may be shown in anyorder, i.e., in parallel. Next we filter this set against the storyboard and generate now learningobject sequences depending on the scenes. Now we are able to take into consideration theuser refinement such as the technical equipment, the channel information such as capacity,the web browser currently in use. Based on this information, we can adapt the website to thecurrent refinement. Finally, we may now enhance the scenes to the specific demands.

3.3 Open Learning Units for Content

Classically learning objects are composed elements. Comparing the existing standards suchas LOM, SCORM we extract the following basic units:

Learning elements are basic components providing the content for singleton learning steps.Typical learning elements are definitions, remarks, proofs, lemmata, illustrations, moti-vational remarks etc. Learning elements may be associated with learning intentions andrequire basic skills and knowledge from the learner. These requirements form the con-text of learning elements. Semantics context specifies the prerequisites and the piecesof knowledge that can be learned. Execution context restricts the utilisation of learningelements, e.g., the environment.

Learning modules are the main supporting media objects for lectures. They may be en-hanced by indexing, annotation or search functionality. Actors may only call an entiremodule. Modules may consist of learning elements. Typical composition expressions areregular expressions. The utilisation of learning modules may be based on a number ofexecution styles such as blackboard execution. Learning modules are typically not mate-rialised.

This distinction is too rough for practical usage. Learner may stop learning in any module,may resume learning at a later stage and may define their own way of visiting modules. Wethus need a sophisticated, flexible and adaptable mechanism for structuring and composi-tions of learning modules. We distinguish between learning elements that are simply specificmedia objects with an additional characterisation, and learning units that can be understood

as combined learning elements, which are dependent on the learning element and thus onlyupdateable through the learning element.

Learning elements can be understood as simple media objects such as text elements, videoclips, images etc. Learning units are composed of learning elements, cf. Figure 4.

Contained Elements

Meta-data on Unit u

Associations to Units uHeaderContent

Identification

NameOfUnit u

...

Meta-data on Element e1

Associations to Elements eContent of Element e1

Identification

NameOfElement e1

...Meta-data on Element ek

Associations to Elements eContent of Element ek

Identification

NameOfElement ek

...

Figure 4: Hierarchical composition of learning elements to learning units

For composition of learning units we extend the specification by metadata, additionalfunctionality, specific scenarios, specific representation styles, filters for playout, a character-isation of learning units spaces that can be associated, and context. The onion playout facilitybased on XSL rules [TD01] supports the generation of the right content, at the right time,in the right representation, by the right costs, and within the right learning history for eachlearner.

Learning elements and learning units are commonly characterised by

• a name of the unit,

• a general annotation called header content,

• metadata that provide additional information on the unit, and

• associations among the media objects.

Additionally, learning units are characterised by

• expression hierarchically combining learning elements or learning units into the givenone,

• reusability conditions describing the degree of ease with which constituent media objectsmay be individually accessed and reused,

• common function describing the manner in which the unit is generally used,

• extra-object dependence describing whether the unit needs information (such as locationon the network) about learning units other than itself,

• functions of algorithms and procedures within the media object,

• potential for inter-contextual reuse describing the number of different instructional con-texts in which the learning unit may be used, that is, the unit’s potential for reuse indifferent content areas or domains, and

• potential for intra-contextual reuse describing the number of times the unit may be usedwithin the same content area or domain.

The above discussed theory of learning elements, learning units and learning modules isnow becoming the state-of-the-art in most edutainment WIS. We are additionally interestedin support of learning scenarios which are adaptable in most of the forms discussed above. Inorder to cope with such requirements we introduce the concept of open learning units. Theseobjects are learning units extended by

parameters instantiable by information used in general learning modules such as pre-requisites, supporting knowledge for better understanding of the unit, and associatedunits,

parameters for links to other content elements, comments,

parameters for replacements strategies depending on availability of content objects,

parameters for associating units to ontology objects for flexible classification of learn-ing objects and bottom-up collection of learning scenarios,

parameters for learner profile integration through which the open learning unit can be re-placed by objects that are more appropriate for the current learner type,

parameters keeping track on the learning history and which can be used for adaptationof the unit to the learner’s history, and

parameters used to keep track on the payment profile of the learner.

Open learning units can be specialized to learning units by instantiating all parameters. In thisprocess, user-specific learning units are generated by step-wise instantiation, extension andspecialization of the given open learning unit. This procedure is based on rules which can bespecified as attribute grammar rules and which can be transformed to XSL rules. These XSLrules are used to transform the given learning unit that is given as XML document to morespecific XML documents. We need, however, to clarify whether an arbitrary specializationorder is applicable.

Furthermore, the representation style can be added. This adaptation approach has beenextensively discussed in [TD01]. Since we change step-by-step the learning unit to be trans-ferred to the learner we call this generation approach the onion generation style.

The delivery of open learning units is based on container functions that support derivedlearning units by filters which support

• enrichment of each unit by other learning elements or learning units,

• contraction of units to essential material, e.g., for repetition of units already visited, and

• cut of learning units to new units according to the restrictions that are applicable.

This approach has already been used in the DaMiT system. Since DaMiT was centered arounddata mining material and has been mathematically oriented, a number of specific filters havebeen developed:

• Repetition filters contracted the units to essential definitions and to the informal state-ments of theorems in the unit.

• Definitions filters provided the definitions of the together with all associated definitionsused in the statements and theorems of the unit.

• Examples filter compiled examples in the unit to consecutive examples with references tostatements and definitions.

• Quick reminder filter are extracting those elements of the units that ar marked as abso-lutely essential.

• Proposition-and-theorems filters summarised all theorems and statement of a unit togetherwith sketches or ideas of their proofs.

3.4 Enhancements of Edutainment Stories

Edutainment WIS authoring is considered to be one of the most difficult tasks. This difficultyis increased by the current approach to develop content and stories from scratch. Classroomteaching does not follow this approach. It is mainly based on sequenced or curriculum-ruledlearning approaches. These approaches are easier to use due to the high level of reuse, dueto the high-level of similarity within the teaching scenario, and due to the homogeneity ofteams after the class has been formed. The last advantage cannot be used in edutainment WISsince the auditory is very heterogeneous, is changing over time, does not follow any timedschedules, has a brought variety of preliminary knowledge and is self-organised. The first twoadvantages may however be incorporated into edutainment as well.

Meanwhile it is well acknowledged that general purpose, general content and general sto-ryboard systems are not feasible. Since any area of knowledge has its specific approaches tolearn that knowledge we need specific storyboards for edutainment systems. General purposelearning systems are replaced by specific purpose systems, e.g. learning application of certainknowledge. Any content needs its specific representation. Therefore, we must specialize fromone hand side and must be very general for any kind of story required. We shall show that ourapproach supports these requirements.

Authors of content for edutainment may base their storyboard on general “pattern” ofscenario that might be useful for the given topic. This general scenario can be then refined bythe author. We are interested in such scenario that can be composed from given scenarios. So,the author selects first a general scenario or a storyboard. Next he/she uses pattern for refine-ment of their scenes. Educational material is assigned to scenes based on the storyboard. Thismaterial is modelled by media types [ST04]. Finally, collaboration, control and workspacescenario are folded into the developed scenario.

Let us demonstrate the integration based on the experience we gained in one of our edu-tainment WIS project. Data mining is one of the challenging topics. First, users must learn ina rather interactive form. Second, the outcome of the learning process must be evaluated andinterpreted. Third, the data used for data mining are often private or secured data. Therefore,

the user should not transfer the data. Instead the user must understand how to prepare for thedata mining process. Additionally the demand for data mining appears as a part of the dailybusiness of users.

In a large project integrating research groups in ten German universities and applica-tion groups in half-dozen German software companies we developed the edutainment sys-tem DaMiT (data mining tutoring) that educates users to such extent that they can evaluatewhether the results of decision support systems are generating correct results and whetherresults will lead to correct conclusions. The system supports decision learning

• by learning basic and advanced topics on data mining on demand,

• by applying data mining algorithms to test data for training of users, and

• by finally applying these data mining algorithms to data of the application engineer.

Surprises, data warehousing, and complex applications often require sophisticated data anal-ysis. The most common approach to data analysis is to use data mining software or reasoningsystems based on artificial intelligence. These applications allow to analyse data based on thedata on hand. At the same time data are often observational or sequenced data, noisy data,null-valued data, incomplete data, of wrong granularity, of wrong precision, of inappropriatetype or coding, etc. Therefore, brute-force application of analysis algorithms leads to wrongresults, to losses of semantics, to misunderstandings etc.

The storyboard in Figure 2 gives only a general description of the main part of the datamining storyboard. It must be enhanced to become a complete story for learning data min-ing. We thus need general frameworks for data analysis beyond the framework used for datamining.

The enhancement procedure may be based on general story descriptions. In our applica-tion approaches known from mathematics for the general mathematical problem solving havebeen used for derivation of a data analysis framework:

Elaboration of needs: Modelling of the tasks and problems and their data requirements.

Elaboration of opportunities: Selection of possible appropriate analysis algorithms, cate-gorisation of their outcome and pitfalls within the task and problem scope, developmentof an application frame for application of the chosen algorithms.

Extraction, transformation, and loading of data: Categorisation, extraction of macro- andmeta-data, adaption of the data to the analysis needs and modelling of data semantics andpragmatics.

Problem solution: Extraction, transformation and loading of macro-data for the chosen anal-ysis algorithms, including cleansing and adaption of the data.

Refinement of problem solution: Application, stepwise refinement and correction of the anal-ysis algorithms.

Interpretation of analysis: Modelling of the obtained analysis results with their semanticsand pragmatics.

The general data analysis framework has been developed for data mining tasks. It considersmodelling of data analysis algorithms, description of their requirements to data, meta-data oftheir functionality for analysis and transformations of the data.

This general framework can be now refined in a number of ways. A typical refinementis displayed in Figure 5. Users learn the opportunities of data mining based on case studies.They explore good and bad studies, get an explanation based on the theory background, andbecome familiar with modelling techniques.

K

Survey oncase studies

j

K

Disselectcase

U

j Empty listof cases

j Deficitsin the application

domain

zSelected case

studyY

U z

j

Hall of famefor solutions

K

Modelsurvey

y :

RelatedcasesY

Theorybehind

9

Elaboration of opportunities by analogy

Figure 5: The scenes for elaboration of opportunities for active learning in the DaMiT system

The framework is classically enhanced by scenario that support training of users to datamining based on exercises, examples, case studies etc.

3.5 Context Space Enhancements

When determining context we already know the edutainment scenarios we would like tosupport, the intentions associated with the WIS, the user and learner characterisation on thebasis of profiles and portfolios, and the technical environment we are going to use. Theserestrictions enable a more refined understanding of context within a WIS.

[MST05] characterises a WIS by six intertwined dimensions: the intentions, the usage,the content, the functionality, the context, and the presentation. We must thus relate contextto the other dimensions. As presentation resides on a lower level of abstraction, it does nothave an impact on context. Content and functionality will be used for context refinement.The user model, the specified edutainment scenarios, and the intention can be used for adisambiguation of the meaning and an injection of context. In doing so we distinguish thefollowing facets of context:

Learner context: The WIS is used by learners for a number of tasks in a variety of in-volvements and well understood collaboration. These learners impose their quality re-quirements on the WIS usage as described by their security and privacy profiles. Theyneed additional auxiliary data and auxiliary functions. The variability of use is restrictedby the learner’s context, which covers the learner’s specific tasks and specific data and

function demand, and by chosen involvement, while the profile of learners imposes ex-ceptions. The involvement and collaboration of learners is based on assumptions of socialbehaviour and restrictions due to organisational decisions. These assumptions and restric-tions are components of the learner’s context.

Storyboard context: The meaning of content and functionality to users depends on the sto-ries, which are based on scenarios that reflect learning scenarios and the portfolios ofusers or learners. According to the profile of these users a number of quality requirementssuch as privacy, security and availability must be satisfied. The learner’s scenario con-text describes what the learner needs to understand in order to efficiently and effectivelysolve his/her tasks in the actual portfolio. The learner’s determine the policy for followingparticular stories.

System context: The edutainment WIS is developed to support a number of intentions. Thepurposes and intents lead to a number of decisions on the WIS architecture, the technicalenvironment, and the implementation. The WIS architecture has an impact on its utilisa-tion, which often is only implicit and thus leads to not understandable systems behaviour.The technical environment restricts the user due to restrictions imposed by server, channeland client properties. Adaptation to the current environment is defined as context adapta-tion to the current channel, to the client infrastructure and to the server load. At the sametime a number of legal decisions based on regulations, laws and business rules have beenincorporated into the WIS.

Temporal context: The utilisation of a scene by an learner depends on his/her history ofutilisation. Learners may interrupt and resume their activities at any moment of time. Asthey may not be interested in repeating all previous actions they have already successfullycompleted, the temporal context must be taken into account. Due to availability of contentand functionality the current utilisation may lead to a different story within the samescenario.

This entire information forms the context space, which brings together the storyboard spec-ification and the contextual information. Typical questions that are answered on the basis ofthe context space are:

• What content is required by the context space?

• What functionality is required by the context space?

• What has to be changed for the life cases, the storyboard, etc., if context is considered?

As outlined above the context space is determined by the learners, the scenarios, the WISitself, and the time. It leads to a specialisation of the content, structuring and functionality ofthe scenes.

Context is associated with desirable properties of the WIS such as quality criteria andsecurity and privacy requirements. Quality criteria such as suitability for the users or learn-ability provide obligations for the WIS development process. Though these criteria are ratherfuzzy, they lead directly to a number of implementation obligations that must be fulfilled atlater stages, i.e. within the development on the implementation layer.

For instance, learnability means comprehensibility, i.e. the WIS must be easy to use, re-member, capture and forecast. This requires clarity of the visual representation, predictability,

directness and intuitiveness. These properties allow the user to concentrate on the tasks. Theworkflows and the discourse structure correspond to the expectations of the users and do notlead to surprising situations. They can be based on metaphors and motives taken from the ap-plication domain. In the same way other quality criteria can also be mapped to developmentobligations.

Other properties that may be associated with context refer to the potential utilisation forother tasks outside the scope of the storyboard. In this case we do not integrate the addi-tional tasks into the storyboard, but instead support these tasks, if this in accordance withour intentions. For instance, we might expect further visits targeting at core concerns of theedutainment WIS.

4 Open Issues and Challenges for Edutainment WIS

Learning content must be properly handled. It turns out that this task is one of the mostdifficult tasks. For this reason, any edutainment WIS must be combined with an authoringWIS that supports authors during appropriate development of content.

Quality control of learning objects is necessary since low quality data harms the learningsuccess. We may distinguish a number of reasons for low quality and development strate-gies for improvement of quality: Incomplete content, mixed content, wrong content, complexassociations among content, and mutated content.

Functionality development for edutainment WIS also includes the development of verysophisticated supporting facilities for the actors, the content, the context, and the presentation.

Most edutainment systems are currently based on scenarios of sequenced learning. 3rd

generation systems are aiming in providing best-suited content just in time to the right user,place and device with the best pricing. They challenge current technology. Research is soughton didactics, content integration and delivery, storyboarding, adaptation and context integra-tion, and success control. Open learning objects provide a sophisticated facility for contentmanagement. The theory of open learning units should be integrated with didactics based onstoryboarding, content adaptation and delivery, and content development. In future, they willbe extended with context, e.g., story space, actor, user, payment, portfolio, association, his-tory, etc. Control functionality should be provided for open learning units in the same fashionas we know it already for exercises, tests, and exams for self-control or certification.

References

[BGW92] R. M. Briggs, L. J. Gagne, and W. W. Wager. Principles of Instructional Design. ThomsonLearning, 1992.

[BZKK+05] A. Binemann-Zdanowicz, R. Kaschek, T. Kuss, K.-D. Schewe, B. Thalheim, and B. Tschiedel. Aconceptual view of electronic learning systems. Education and Information Technologies, 2005.

[DN03] S. Dohi and S. Nakamura. The development of the dynamic syllabus for school of informationenvironment. In ITHET03, pages 505–510, 2003.

[For94] H. I. Forsha. The Complete Guide to Storyboarding and Problem Solving. ASQ Quality Press,1994.

[JMR+03] Klaus P. Jantke, M. Memmel, O. Rostanin, B. Thalheim, and B. Tschiedel. Decision support bylearning-on-demand. In Proc. of the 15th Conf. on Advanced Information Systems Engineering(CAiSE ’03), Workshops Proc., Information Systems for a Connected Society. CEUR WorkshopProc. 75, pages 317–328. Technical University Aachen (RWTH), 2003.

[Kun92] J. Kunze. Generating verb fields. In Proc. KONVENS, Informatik Aktuell, pages 268–277.Springer, 1992. in German.

[LOM00] LOM. orking draft v4.1. http://ltsc.ieee.org/doc/wg12/LOMv4.1.htm, 2000.

[LTS00] LTSC. Learning technology standards committee website. http://ltsc.ieee.org/, 2000.

[MST05] T. Moritz, K.-D. Schewe, and B. Thalheim. Strategic modelling of web information systems.International Journal on Web Information Systems, 1(4):77–94, 2005.

[PP45] G. Polya and G. Polya. How to solve it: A new aspect of mathematical method. Princeton Uni-versity Press, Princeton, 1945.

[RK04] W. J. Rothwell and H. C. Kazanas. Mastering the Instructional Design Process: A SystematicApproach (Third Edition). Pfeiffer, 2004.

[SBZ04] J. Sonnberger and A. Binemann-Zdanowicz. Kopra - ein adaptives Lehr-Lernsystem fur kooper-atives Lernen. In GMW’2004, Graz, Austria, Sept. 2004, pages 274–285, 2004.

[SSS90] H. Schreiber, K.-E. Sommerfeld, and G. Starke. Deutsche Wortfelder fur den Sprachunterricht:Verbgruppen. VEB Verlag Enzyklopadie, Leipzig, 1990.

[ST04] K.-D. Schewe and B. Thalheim. Web Information Systems, chapter Structural media types in thedevelopment of data-intensive web information systems, pages 34–70. IDEA Group, 2004.

[ST05] K.-D. Schewe and B. Thalheim. Conceptual modelling of web information systems. Data andKnowledge Engineering, 54:147–188, 2005.

[TD01] B. Thalheim and A. Dusterhoft. Sitelang: Conceptual modeling of internet sites. In Proc. ER’01,volume 2224 of LNCS, pages 179–192. Springer, 2001.

Pragmatics of Storyboarding – WebInformation Systems Portfolios

Anonymous

Somewhere

Abstract

A Web Information System (WIS) can be described by astoryboard, which on a high level of abstraction specifieswho will be using the system, in which way and for whichgoals. Syntax and semantics of storyboarding have beenwell-elaborated. Pragmatics is the necessary complementaddressing what the storyboard means for its users. Thepart of pragmatics concerned with usage analysis bymeans of life cases, user models and contexts has beendealt with before. In this paper we complement usageanalysis by WIS portfolios, which comprise two parts:the information portfolio and the utilisation portfolio.The former one is concerned with information consumedand produced by the WIS users, which leads to contentchunks; the latter one captures functionality requirements.

Keywords. Pragmatics, Web Information System, Infor-mation Portfolio, Utilisation Portfolio

1 Introduction

A Web Information System (WIS) is an information sys-tem that can be accessed through the world-wide-web. Sofar, many approaches to WIS conceptual modelling havebeen developed, e.g. (Ceri, Fraternali, Bongio, Brambilla,Comai &Matera 2003, De Troyer & Leune 1998, Houben,Barna, Frasincar & Vdovjak 2003, Lowe, Henderson-Sellers & Gu 2002, Rossi, Schwabe & Lyardet 1999,Anonymous 2005a), most of which are centered aroundcontent and navigation modelling, occasionally coupledwith specific requirements models.In (Anonymous 2005a) we characterised a WIS by

strategic characteristics such as purpose, mission, inten-tions and ambience (more details in (Anonymous 2005b)),usage characteristics such as tasks, users and stories, con-tent and functionality characteristics, context, and presen-tation, which leads to an abstraction layer model for WISdevelopment. Central to this approach to WIS develop-ment is the method of storyboarding, which on a high levelof abstraction specifies who will be using the system, inwhich way and for which goals. In a nutshell, a storyboardconsists of three parts:

• a set of tasks that are associated with goals the usersmay have,

• a set of actors, i.e. abstractions of user groups de-fined by roles that determine obligations and rights,and user profiles determining preferences, and

• a story space, which itself consists of a hierarchy ofscenarios describing scenes and actions, and is ac-companied by a plot describing the action scheme.

Syntax and semantics of storyboarding including cus-tomisation to preferences have been well elaboratedin (Anonymous 2005a, Anonymous 2007a, Anonymous

2009). However, in order to link storyboarding to the sys-tems requirements and to provide guidelines and means toderive the complex storyboards from informal ideas abouta WIS without any technical bias, this has to be comple-mented by pragmatics, which according to (Web 1991) isthe “balance between principles and practical usage”.In (Anonymous 2007b) we addressed the pragmatics

of storyboarding focusing on usage analysis. Based onintentions we investigaed life cases, user models and con-texts. Life cases, capture observations of user behaviourin reality, and can be used in a pragmatic way to spec-ify the story space. Life cases have already been en-visioned in (Carroll 2004) and integrated into the entiresoftware engineering process in (Harel & Marelly 2003).They generalise business use cases as in (Robertson &Robertson 2006). User models that are specified by userand actor profiles, and actor portfolios.They are used toget a better understanding of the tasks associated with theWIS, and the goals of users. Goals have been identifiedas a crucial component of requirements engineering in(Giorgini, Mylopoulos, Nicchiarelli & Sebastiani 2002).Task descriptions are also used in participatory design,e.g. in (Carroll 2004, Kensing & Blomberg 1998, O’Neill& Johnson 2004). Contexts characterise the situation, inwhich a user finds himself at a certain time in a particularlocation. For WISs we must handle different kinds of con-texts and analyse the way they impact on life cases, usermodels and the storyboard.In this paper we extend our work on WIS pragmatics

focusing on WIS portfolios, which address the pragmaticsassociated with content and functionality. We distinguishbetween information as processed by humans and data asits carrier that is perceived or noticed, selected and orga-nized by its receiver. Content is complex and ready-to-usedata, and may be enhanced by concepts that specify the se-mantic meaning of content objects, and topics that specifythe pragmatic understanding of users.Thus, information is directed towards pragmatics,

whereas content may be considered to highlight the syn-tactical dimension. If content is enhanced by conceptsand topics, then users are able to capture the meaningand the utilisation of the data they receive. Analogously,functionality refers to functions offered by the system,thus highlists the dynamic aspects of the syntactic dimen-sion, whereas utilisation is linked to the stories supportingusers’ life cases, thus is directed towards pragmatics. Thisdistinction is illustrated in Figure 1.Accordingly, a WIS portfolio consists of two parts:

the information portfolio and the utilisation portfolio.The former one is concerned with information consumedand produced by the WIS users, which leads to contentchunks. We will elaborate on this in Section 2. The latterone captures functionality requirements. We will elabo-rate on this in Section 3 focusing on utilisation portfoliosfor learning and communities.

PRAGMATICS

Technical environmentof the user

User

Datarepresentation

Data Functions


Information

Story

Content

Functionality

Layout

Playout

°°

°

Informationmetaphors

Story andfunctionalitymetaphors


SYNTACTICS

Figure 1: The Web Utilization Space Based On the Characteristics of WIS

2 Information Portfolios

A WIS portfolio consists of an information portfolio anda utilisation portfolio. They are mapped to content andfunctionality specifications, respectively. in doing so wedistinguish between content provided by the WIS and in-formation, which is related to an actor or user.

2.1 Consumption and Production of InformationFollowing (Anonymous 2005a) on a high level of abstrac-tion we may think of a WIS as a set of abstract locations,which abstract from actual pages. A user navigates be-tween these locations, and on this navigation path s/he ex-ecutes a number of actions. We regard a location togetherwith local actions, i.e. actions that do not change the loca-tion, as a unit called scene.Then a WIS can be described by an edge-labelled

directed multi-graph, in which the vertices representthe scenes, and the edges represent transitions betweenscenes. Each such transition may be labelled by an ac-tion executed by the user. If such a label is missing, thetransition is due to a simple navigation link. The wholemulti-graph is then called the story space.A story is a path in the story space. It tells what a

user of a particular type might do with the system. Thecombination of different stories to a subgraph of the storyspace can be used to describe a “typical” use of the WISfor a particular task. Therefore, we call such a subgrapha scenario. Usually storyboarding starts with modellingscenarios instead of stories, coupled by the integration ofscenarios to the story space.Each WIS user who enters the system with a particu-

lar goal has information needs that have to be satisfied bythe system. In addition, an active WIS will also requestinformation from its users. We use the term informationconsumption for the information provided by the system toits users, and information production for the informationentered by a user into the system.When a user enters the WIS, the information needs are

usually not known in advance. Part of the needed informa-tion may depend on other parts, on decisions made whilenavigating through the WIS, and even on the informationprovided by the actor him/herself. That is, the informationconsumption and production depends on the path throughthe WIS, i.e. in our terminology on the story. There-fore, information consumption and production is associ-ated with each scene of the story space. Assuming thatthere is a database for the data content of the WIS withdatabase schema S, information consumption on a scenes definitely accounts for a view Vs over S. That is, wehave another schema SV and a computable transforma-tion from databases over S to databases over SV . Such atransformation is usually expressed by a query qV .

• With each scene s we associate a view Vs =(SV , qV ) called information consumption view. El-ements of qV (db) for some database db represent theinformation consumption of an actor.

• With each action α we associate a data type tα calledinformation production type. Values of type tα rep-resent the information production by an actor.

Information consumption and information productionof an actor for all scenes together define the informationportfolio of the actor.

2.2 Information Need and DemandWe distinguish between the information need and the in-formation demand. The former one refers to a perceivedlack of something desirable or useful, while the latter oneresults from an act of demanding or asking.The information need is generally related to objectives

such as becoming informed. It is based on the intuitiveinsight that the current information and knowledge is in-sufficient for the task under consideration, or the neces-sary information cannot be easily derived from data thatis currently available, or the uncertainty, indefiniteness,fuzziness, and contradictions do not permit drawing con-clusions.The information need can be considered to be subjec-

tive, but at the same time it can be the reason for a certainuser visiting a website without an intention that is relatedto a life case. The information need is based on the con-ceptual incongruity in which a user’s cognitive structureis not adequate to a task, e.g. when a user recognizes thatsomething wrong in their state of knowledge and desires toresolve the anomaly, when the current state of knowledgeis less than what is needed, when internal sense runs out,or when there is insufficient knowledge to cope with gaps,uncertainties or conflicts in a knowledge area. Therefore,as the behaviour of actors is mainly related to life casesand the portfolio, we have to distinguish between informa-tion provided for support of life cases and auxiliary con-sumed information that is provided to visitors as a service.The information demand is related to the portfolio un-

der consideration and to the intents. We may distinguishbetween information that is necessary, desirable, or fea-sible. The information demand is mapped to the viewsdefining information consumption and production for eachscene of the story space as defined above. The informa-tion demand is characterised by information that is miss-ing, unknown, necessary for task completion, and directlyrequested.We can distinguish between the information demand

of an actor and the information demand of a user. As ac-tors represent groups of users, the information demand ofa user contains the information demand of an actor. While

2

the information demand of actors is determined by theportfolio, the additional information demand of a user isdetermined by the user profile.

2.3 The Concept of PersonaThe information demand is used to derive the informa-tion consumption of each user. This is related to the def-inition and meaning of information for the user based onreceived / requested data, which has to be organized, in-terpreted, understood, and integrated into his/her knowl-edge. In general, this would require to model the user,the specific request of the user, the ability to understandthe data, and the skills, which is infeasible. However, asthe information demand of actors is a subset of the one ofusers represented by the actor, we can use prototypes ofindividuals called personae to determine the informationdemand. In addition, we model a task-oriented life case ofthese individuals, and derive the information demand, datarequirement, and the specific utilisation requirements.A persona is characterized by an expressive name, pro-

fession, intents, technical equipment, behaviour, skills andprofile, disabilities, and specific properties such as hobbiesand habits. A persona is a typical individual created to de-scribe the typical user based on the life cases, the context,the portfolio, and the profile. User models characterizeprofiles for education, work, and personality. This charac-terization can be extended by

• identity with name, pictures, etc.,• personal characteristics such as age, gender, location,and socio-economic status,

• characterization of reaction to possible users error,• specific observed behaviour including skill sets, be-havioural pattern, expertise and background, and

• specific relationships, requirements, and expecta-tions.

EXAMPLE 1 Let us consider an information service of acity and focus on business people. For these we developthe following specific portfolio:

User profile: Jack-of-all-trades is a business man. He in-tends to visit the city through a short-term visit. Heis interested in culture and history. He likes short dis-tances and 4-star or better hotels. He is usually in ahurry. He likes good dining and talking. Addition-ally, he is familiar with technology.

Intention and information demand: Jack-of-all-tradesvisits the information site for business trip prepa-ration. His information demand includes hotelinformation, spare time information for the evenings,and information on the central traffic.

Content requirements: The information demandmay bemapped to general city information, information onrestaurants, traffic, culture, business clubs, and gooddining addresses. Therefore, the information con-sumption of Jack-of-all-trades must be supported bythe corresponding databases. At the same time, Jack-of-all-trades requires a handy booking service.

Life case: The life case we envision includes a brief sur-vey on the city including places to see, the selectionof a convenient hotel, a survey of events of interest,the booking procedure for events, a search for gooddining places, and some information what else to seeand whom to talk to.

Specific utilisation: The collection of data is similar to abasket collection. Jack-of-all-trades prefers shallownavigation and fast search. He is also interested inhighlights for the period he is considering.

Jack-of-all-trades can be exemplified to be a specificpersona:

Personal: name: Bernhard Karlowics, age: 48, male,married, lives in northern Germany, profession: busi-ness assistant, income: around Euro50.000 per year

Robustness: errors are not taken as own errors, downloadtime is critical

Kind of user: kind but pretentious, makes quick deci-sions, interested in history, culture, classical musics,usually in a hurry

Specific behaviour: resumes story also after hours

Specific interactivity: works alone, with interruptions,no time for concentrated reading, final results ex-pected

Profile: middle level manager, Masters degree in busi-ness and computer engineering, workoholic (around60 hours per week)

Portfolio: collection of travel details with confirmationand payment, prefers hotels with four-stars or higher,checking through direct connection to booking ser-vices

Life case: preparing for travel, single use of the system,email confirmation necessary, spare time informa-tion, events of interest, dining places, business clubs

Context: business environment, typically client-servercomputers at workplace, occasionally mobile phonefor contact while on the move

For the persona the following specification templatecan be used:

Persona: hpersona nameiIdentity: hfirst and last name, photoiDemography of persona: hage, gender, location, statusiRobustness of WIS usage: hcriticality of errorsiKind of user: hgeneral descriptioniSpecific behaviour: hgeneral descriptioniSpecific interactivity: hgeneral descriptioniBased On User Profile: hnamei

Refined education profile:hgeneral descriptioni

Refined work profile: hgeneral descriptioniRefined personality profile:

hgeneral descriptioniBased On Portfolio: hnamei

Refined task: hgeneral descriptioniRefined involvement: hgeneral descriptioniRefined collaboration: hgeneral descriptioniRefined restrictions: hgeneral descriptioni

Based On Life Case: hnameiRefined characterisation:

houtcome descriptioniRefined life case flow: hgeneral graphical descriptioniRefined figures: hactors listiRefined context: hgeneral context descriptioniRefined representation: hgeneral behaviori

Based On Context: hnameiRefined persona context:

hgeneral descriptioniRefined storyboard context:

hgeneral descriptioniRefined WIS context: hgeneral descriptioniRefined temporal context:

hgeneral descriptioni

3

The explicit specification of personae has several ben-efits. They provide communication means within the de-velopment team, focus on a specific target set of actors,and help to make assumptions about the target audience.Thus, personae may augment the WIS portfolio specifica-tion, but should not be overused.

2.4 Content ChunksIn order to model the information portfolio we collect theinformation demand of all actors we would like to support.In addition, we can include some specific information de-mand of users matching with the groups of users. This in-formation demand can be combined into a single contentchunk that is demanded by all actors of similar steps in thelife case. This information demand can later be modelledwithin a database model.This combination turns around the viewpoint we have

taken so far. We try to envision which content is necessaryfor which actors or users. We may start with the intentionwhy an actor may demand a given content. The content-centered view allows us to derive a specification of stepsin which a certain chunk of content is requested.The content-centered analysis is used during brain-

storming sessions in which we try to derive scenarios, in-tentions, and the information need of users. At the sametime we can derive the service kind, utilisation, actors,presentation, content, and functions supporting this con-tent. We can also derive directly the intersection amongthe content chunks, which provides a basis for the devel-opment of queries to extract the content demanded fromthe WIS.Content chunks are arranged within content-extended

scenarios, in which each scene is associated with a contentchunk. This content chunk combines the consumption ofactors, auxiliary content that is provided for the supportof users, and the content that is additionally provided dueto the intentions of the WIS provider and the context ofthe current scene. We further enhance this scenario bydata that is produced by the actor or that stems from theenvironment.

EXAMPLE 2 Let us continue Example 1 and consider thebooking scene. If the actor has decided to choose a par-ticular hotel, then we may associate with the choice ac-tion the selection of an identification for the hotel, whichextends the booking scene with the content that providesinformation to the actor on hotels. With the choice of ahotel the actor leaves this scene and produces the selec-tion data. In the next scene the actor can be asked aboutthe payment.The same scene can also be used in a different scenario,

in which the actor first collects all choices in a basket andlater confirms those choices, which are the most appropri-ate.

The information portfolio is also enhanced by infor-mation that depends on the WIS context. This can definecontent associated with control, which normally is internalto the WIS and not accessible by applications, content thatis used to determine the transitions and to control the WIScontext, e.g. for the pre- and post-scene conditions, tran-sition conditions depending on the databases used, or as-signment for collaborating actors, etc., content that mightbe useful as reference, e.g. meta-information on time,responsibility, and links to other WISs, or application-specific data that is not accessible by the WIS.The content set required for each step in a life case may

become too large. So we must prioritise the developmentof content chunks. There are two perspective for prioritis-ing:

• In the usability perspective we evaluate the impactthe content has for the the WIS portfolio. The impactis based on the occurrence the content has in steps

and activities and on the number of actors requiringthis content. The impact is high if the majority ofusers need it frequently or cannot continue their workif the content is missing.

• In the economic perspective we evaluate thecost/benefit relation. Since projects have limitedbudget, contract commitments, resource restrictions,technological constraints, marketplace pressures, anddeadlines we must limit the efforts. We may classifythose content chunks which have high impact intostrategic, high value, targeted and luxuries.

EXAMPLE 3 The www.cottbus.deWIS provides in-formation on hotels, booking services, etc. For the deci-sion, which information should be provided we may usea classification along usability and economic perspectiveas in Figure 2. We can then assign final decisions to theevaluation such as approved (

√), under review (¶), and

rejected (6 ¶).

Targeted

Luxuries

High value

Strategic

low

high

low high

cost rating

user importance

6 ¶ Activities around

√Sign-up for frequentvisitor program

√Book room

√Compare hotels

¶ Read hotel reviews

Figure 2: The cost/benefit evaluation of the hotel data inan information service

In a similar way we may evaluate all content chunkswe discovered. The evaluation is used for deciding whichcontent is to be developed and to which extent.

Content chunks are often composed only of data, i.e.they relate to media objects on the conceptual model(Anonymous 2005a). The description of the data is basedmedia types, viewpoints, and adaptation facilities. Con-tent is also based on semantics, i.e. associated conceptscapturing basic pieces of knowledge or their annotations,and restricted by pre- and postconditions. Content mustalso be annotated using a commonly agreed vocabularyor a dictionary. This agreement is bound to actors orcommunities. We denote items of dictionaries by topics.The pragmatics also reflects the context of potential usage.As content is often used in a form that combines contentchunks with other content chunks we also specify relatedcontent chunks. In summary, we may use the followingspecification template for content chunks:

Content chunk: hcontent chunk nameiDescription: hspecificationi

Media types: hlist of media typesiViewpoints: hlist of views over the typesiAdaptation: hdescriptioni

Semantics: hgeneral description and knowledgeiConcepts: hlist of associated conceptsiPrecondition: hconditioniPostcondition: hconditioni

Pragmatics: hgeneral description and contextiActor: hlist of actorsiTopics: hlist of associated topicsi

Delivery: hgeneral description of utilizationiContainer: hnames of associated containersiAdditional content:

hlist of content chunksiUsage: hstory space annotationi

Enabling Intention:

4

hlist of intentionsiSupporting Content:

hspecificationiSupporting Functions:

hspecificationiContext: hcontext spacei

Cost-benefit rating:husability, costs and benefitsi

Additional content: hlist of content chunksi

2.5 Content Chunks for the Entry SceneThe entry scene is associated with a specific content chunkthat will give rise to the home page of the WIS. Therefore,it must be developed with greatest care. It must containall essential information of the WIS on the setting, the en-vironment, the characterisation, the main intentions, ac-tivities that can be played with, etc. Therefore, we mustbalance the list of supported tasks in such a way that theybecome displayable.The entry scene concerns the initial situation, the emo-

tional environment, and the main intentions a user mayhave while visiting the WIS. At the same time, the actormust understand what s/he has to expect when entering theWIS. Objectives of the entry page are to introduce the con-text and essential actions of the WIS, provide informationon collaborating actors, show the theme of the WIS, de-fine the kind of scenario to be played, and support an easymatch with the information demand of a user or actor.The attraction of users requires suspense in the open-

ing, as the first impression decides whether a casual usercontinues within the WIS. Branding, navigation, contentand usage must be balanced. Rules for the entry scenemust be based on the characteristics of WIS, i.e. on inten-tions, especially objectives, aims and the target audience,on specifics of supported life cases such as need in guid-ance, feedback, explanation, specific content, and func-tionality, on complexity of content, which directly leads tothe need to support surveyability, ease of use, and decom-position of content chunks, on variety of functions thatmust already be provided by the entry scene, on adaptationto user and actor profiles, which requires a rough separa-tion of actors according to their education, work, person-ality of security profiles, on properties of portfolio such ascomplexity of problems, need in collaboration, and sup-port for workspace and workplace, and on integration ofcontext, and adaptation of content, functionality, and sce-nario to the context.These rules permit the derivation of the general atmo-

sphere and the main intention of the entry scene. Typicalexamples are categories such as “traditional and serious”for business and work pages, and “energetic” or “vital”providing a flavour of progression and innovation.

EXAMPLE 4 The entry page must accommodate the largevariety of visitors and their information needs, for whichwe can identify a number of content items that must beprovided:

• Immediately and clearly communicate the purposeto the visitor: Each visitor must be supported bydescriptive wording and images that are easy andquickly to understand independent from whether thevisit is the first or a repeated one. The values of theWIS must be easily detectable. Visitors’ positive im-pressions depend on the trustworthiness and the val-ues of the WIS.

• Creating an identity of the WIS (branding): Usersneed to quickly capture whether a WIS holds a valu-able promise, whether they can trust it, and what con-tent is offered.

• Attract by content: A visitor judges a WIS withinseconds of entering it. Therefore, content must beattractive, well-organised, easy to browse, and sum-marized.

• Personalization of content: The WIS should be tai-lored to the portfolio and profiles of their visitors. Inthis case, the system does not require users to learnand memorize its facilities.

• Provide an orientation to the visitor: Navigation mustbe easy to use and may be based on an explorationmetaphor. Users should quickly comprehend how toget around, should be not be forced to guess what canbe done next.

• Balanced content and functionality: The trade-off be-tween space used for content or functionality can beresolved by developing patterns that support fast de-tection of items the user is seeking for, by focusing onthe tasks of the user, and by branding in a constrictedform.

• Establishing a cohesive and logical layout: The mostimportant information chunks must be immediatelyidentifiable and located. For this the reading andrecognition culture of the users must be taken intoaccount.

The pages of aWIS, especially the home page are oftendesigned by graphics experts who tend to use a large num-ber of multimedia features. However, layout and play-out have to be in accordance with the rules developedabove, which leads to the request to apply screenography(Anonymous 2007c, Anonymous 2008). This is, however,beyond the scope of this article.Finally, the entry scene must be considered as one of

the main advertisement instruments of the WIS. For thisreason, a clear statement of the values of the WIS is thebasis for deriving content that conveys these values withthe users’ first impressions. Typical value properties are

• reliability, availability, actuality, speed, responsive-ness, alternatives, ease of use, managing complexity,(filtering) levels, completeness, links, flexibility, sup-port, export, privacy, and guidance for informationservices, or

• user adaptation, learning styles and preferences, sim-plicity, support, flexibility, guidance, accessibility,consistency, motivating, clear goals, and responsive-ness, or

• portability, speed, shared resources, previewing,alertness, awareness, versioning, mail management,multi-threading, report generation, feedback, men-toring, distribution, flexibility, security, and safety forcommunity sites.

These values of the entry page are a part of the brandof the WIS and must match with the aims and objects thathave already been specified for the entire WIS while cap-turing intentions (Anonymous 2007b). We can now com-bine these requirements for an abstract description of theentry scene using the following template:

Entry scene: hentry scene nameiEntry scene value:

hmain propertiesiIntentions: hlist of main supported intentionsiContent: hlist of main content, headlines and blurbsiFunctions: hlist of main functions and their representationi

Shortcuts: hanchored list of shortcuts to sub-scenarioiLinks: hcontent or function anchored list of linksiGeneral navigation:

hcontent or function anchored list of linksiActor: hlist of actors, rights, rolesi

5

Story space: hgeneral description of the story spaceiPresentation: hmain properties of the presentationi

Presentation style:hgeneral descriptioni

Presentation expression:hscenography and choreographyi

Performance: hmaximal time and sequence of downloadiContext: hderived specifics of the context spacei

3 Utilisation Portfolios

The second constituent of the WIS portfolio is the utili-sation portfolio, which can be considered to be a collec-tion of requirements for functionality and WIS utilisationin general. It describes the intentions of the users, theirgoals, their context, and their specific requirements, andas such is based on the life cases that were modelled be-fore, and the profiles and the portfolio of the users andactors. Furthermore, the actor context must be taken intoaccount. Therefore, we first discuss the utilisation portfo-lio and then derive its impact on the functionality requiredby the user.The utilisation portfolio combines the actor or user per-

spective to the WIS. We already know intentions of users,their profiles, and their life cases. Users are grouped toactors for which portfolios have already been developed.Based on the portfolio and the context specification lifecases were extended.The WIS utilisation portfolio cannot be described in

general for all different categories of WIS such as e-business, learning and edutainment, communities, etc.,though these categories are mixed in real applications.The separation into categories eases, however, the descrip-tion of the WIS utilisation portfolio. In the following wewill describe the development of the WIS utilisation port-folio for learning WISs and group/community WISs.

3.1 Learning PortfoliosA large number of WISs provide learning and edutain-ment services. Examples of technology-supported learn-ing include computer-based training systems, interactivelearning environments, intelligent computer-aided instruc-tion systems, distance learning systems, and collaborativelearning environments. The general brand PW2UA of aWIS (Anonymous 2005b) has to be specialised for edu-tainment WISs:

Provider P: For the time being providers are mainlyeducational institutions or educational communities.Then the provider plays the role of a teacher.

ProductW: Since control and assessment of learningprogress is a still unsolved issue and appropriatepresentation of complex information is often notfeasible, edutainment WISs concentrate on easy-to-understand information or easy-to-grasp knowledge.

Users U: Users of edutainment WISs are mainly stu-dents, people seeking for continuous education,workers in companies with a specific portfolio, peo-ple interested in auxiliary information, or groups ofsuch users. The main behavior of such users is char-acterised by the role of the learner.

Activities A: Activities are mainly centered aroundlearning, searching for content, collecting content,and solving exercises. Activities also include to askquestions, to act in teams for problem solving, and todiscuss issues associated with the learning material.

Thus, typical learning WIS brands take the form

TeacherW2LearnerA,

where W stands for content chunks or knowl-edge, and A can be one of receive, respond,solve in teams,raise questions, possibly apply,learn, validate, control, advice, recognise, listen,work on it, solve exercises, ask urgent questions,discuss, get feedback, work on it, etc.Edutainment WIS are currently mainly or exclusively

supporting student actors. Students obtain knowledgethrough teachers, their schedules, and their abilities; theyneed guidance, motivation, and control. The behaviourof actors may, however, be more complex, in particularin case of learning groups, in which the collaboration ofstudents depends on a cooperation profile with rights andobligations. Communication partners exchange content,discuss and resolve questions, seek for hints or for bet-ter understanding, supporting and motivating partners areusers with control, motivation and supporting functions.Furthermore, teachers have various obligations and rights,and are involved in a variety of roles.In order to derive the utilisation portfolio we analyse

the word fields associated with common verbs in the learn-ing context such as learn, know, master, study and nounssuch as skill. This gives rise to stories and consequentlydetermines the functionality requirements.

Learn: Learning is a very complex activity that includesgaining knowledge, understanding, obtaining skills,etc. by studying, instruction or experience. In addi-tion, learning is associated with memorizing, beingable to perform some task, and to know this ability.Learning is based on obtaining content, discoveringthe concepts behind them, annotation, ordering, andintegration. Learning is associated with the role ofa learner or student, who are usually supported byother actors who teach and instruct. Learners deter-mine content with certainty, usually by making an in-quiry or other effort. They check the content to findout whether it is useful or whether additional contentis needed.

Know: As learning aims at improving skills, abilities,and knowledge, the improvement should be measur-able and learning success examined. Knowing meansto be cognizant of a fact or a specific piece of in-formation and to possess knowledge or informationabout. It may also include to know how to do some-thing. Learners obtain first-hand knowledge of states,situations, emotions, or sensations, and the change inknowledge is acknowledged and recognized by otheractors.

Master: Learning usually intends to enable masteringproblems and to become proficient and skilled insome area. This mastership is closely related to prac-tising and experimenting with the new knowledge.

Study: Studying refers to the activities associated withlearning, i.e. reading learning content, excercis-ing, checking, examining, inspecting, surveying, etc.Therefore, the presentation of the learning materialand the storyboard are essential. Furthermore, learn-ers need to mind, perpend, think (out or over), andweigh, which requires time and workplaces. Study-ing can be performed by oneself without any teacher,supporter, or observer.

Skill: Skills are abilities that have been acquired by train-ing, e.g. abilities to produce solutions to some prob-lems. A learner is trained until s/he obtains theseskills.

These word fields have a complex structure, whichleads to functions requiring other support functions as-sociated with related word fields such as discover, ascer-tain, catch on, and determine. One difference to the wordfields for e-business is their iterative application. The

6

word fields are extended by the learning style to be sup-ported. The three different learning styles – sequencedor blended learning, interactive learning, and group learn-ing – result in rather different scenarios. So far, only se-quenced learning approaches have received the necessarytheoretical basis in pedagogical research and didactics. In-teractive learning is still an open research issue.

EXAMPLE 5 The KOPRA project within the GermanUniversity Notebook Initiative was aiming at the supportof adaptive and collaborative learning, focusing on practi-cal training in database programming. The system is sup-porting communication and interaction of learners, orga-nization and coordination of collaborating communities,free access to material depending on the progress, rolesand portfolios of partners, and the stepwise developmentof training material. Learners act in a collaborative settingdepending on their needs and the goals of the learning pro-gram.The analysis of the word fields above highlighted the

utilisation of importance of exercising of crucial part ofthe WIS. While often only multiple-choice exercises aresupported, complex exercises have a more complex pat-tern. Figure 3 shows the derived scenario for exercisetraining for this case. Learners are allowed to choose ei-ther their own data or data provided by the system. Learn-ers may also choose an algorithm that can be used for solv-ing the exercise.Using the storyboarding language SiteLang

(Anonymous 2005a) we can represent the entire scenarioby the following expression:

% T ; ( (D (C ; P )) k ( I ; U ) ) ;H ; (R ;H ; )∗ ; A ; ((S skip ) ;

E ; J ; N ; H ; (R ;H)∗; A)+ ; S &

with the complex actions T (task delivery), D (deliv-ery of prepared data), C (collection of users data), I (in-formation on applicable algorithms), P , (preparation oflearners data), U (code upload and installation), H (for-mulation of learners hypotheses), A (computation of as-sociation through mining), S (submission of competitivesolution), E (evaluation of submitted solution), J (inspec-tion of sample solution and comparison with evaluationsof competitors),N (preparation for next trial for solution),and R (reminder on learning element on hypothesis). Fur-ther, the symbols % and & are used for denoting theentry and the termination of the whole exercise scene.

3.2 Community PortfoliosCommunities and leisure groups are gathering places forregistered members, who form an interacting communityof various actors with common location, intentions, andtime. They are based on shared experience, interests orconviction, and voluntary interaction among members to-wards common goals. In the case of work communitiesthey deal with issues affecting the legal profession, and areconcerned with furthering the best interests of their mem-bers. Communities often employ leadership and hosting.Membership requirements and obligations, resources andamenities, member characteristics, community policies,and activity style and pattern create a large variety of com-munity/group WISs.The utilisation portfolio is based on the community or

group member profiles. The general brand PW2UA mustalso be specialized for community and group services.The provider and the users may coincide for communityWIS.The actions depend on the kind of the community or

group. The life cases of these communities and groupsvary very much. Nevertheless, we can identify severaltypes of typical scenarios. Active scenarios (act) are ac-tivities by the receiving actor(s). Information scenarios

(inform) or more specifically ask and search are mainly gov-erned by the provider. Participation scenarios (attend) re-quest the interaction of receiving actors. Community andgroup WIS are mainly following the Group2Groupact orthe Group2Visitorinform,act brand.Discussions are another kind of action. We may dis-

tinguish chat-oriented, collaboration-based, and topic-centered discussion groups. The first group does not limitcontributions. Main actions are initiate, respond, inform,summarise, and close. Collaboration-based discussionsfollow a collaboration pattern and preserve a collabora-tion style agreed in advance. The main metaphor usedis the “meeting”. Main actions are open, close, proposeagenda, issue discussion, contribute, and inform. Topic-centered discussion groups are based on a topic and pre-serve dialogue acts. Actors may be authors, responders,organisers, or supporters. Authors are typically classifiedand have a number of privileges, while responders respondto some data and use a response pattern and preserve a re-sponse style. Tokens are a convenient vehicle for supportof topic-centered discussions often generalising commu-nication protocols.

EXAMPLE 6 The process for finding a group decision istypical example for topic-centered discussions. For in-stance, members of a program committee of a conferencecollaborate during decision making, whether a paper is tobe accepted or rejected. They act either as reviewers or asordinary members of the program committee. Reviewersof one paper may revise their review, comment on the re-views of other members, and exchange messages withinthe subgroup of the program committee comprising thereviewers. An ordinary member of the program commit-tee may comment on the reviews and request a change ofevaluation.All members will make a common decision that de-

pends on the other discussion topics, i.e. on the decisionsfor all papers. Opinions may be stated with a certain con-fidence. Opinions may be distributed to all or selectedmembers of the program committee. Authors of papersare excluded from all discussions on their papers. Theactions of a member of the PC may be mandatory, op-tional or not permitted. So, we specify these obligationsand rights using deontic constraints.

Web2.0 sites provide other examples of enhanced com-munity or group WISs that are even more user-driven. Ex-amples are GoogleActSense, Wikipedia, Flickr,etc. Communities may share their opinion or beliefs orpartial knowledge (e.g. Wikipedia), their diary or visits(e.g. del.icio.us), their intentions of internet utilisa-tion (e.g. 43thing.com), and more. While these com-munities are currently more or less leisure communities,they will evolve into large bodies requiring lead enhancedutilisation portfolios for communities.In particular, support for collaboration and participa-

tion will be needed. This gives rise to collaboration util-isation portfolios. Collaboration means to work togethertowards a common goal, i.e. it combines of three aspects:

Cooperation takes parts of actions into account thatjointly define a group action.

Coordination of actions of individual actors is necessaryto achieve the desired result in a cooperative action.

Communication between actors involved in the samegroup action is indispensable for coordination. It ap-pears in a variety of facets, e.g. as an act or instanceof transmitting a verbal or written message, a pro-cess by which information is exchanged between in-dividuals through a common system of symbols, oras a technique for expressing ideas effectively (as inspeech) using the technology of the transmission ofinformation (as by print or telecommunication).

7

selectionof exerciseportfolio

remindingbackground

hints& tricks

discussionof request &explanation

③

②

answeringworksheet

evaluationof results &analysis

②

presentationof solution

presentationof collectedgradings

Figure 3: KoPra scenario for training with optional exercises

So, the main word fields associated for the utilisationportfolio are the following ones:

Contribute: Amember of a community gives or suppliesa document to the community and shares it with thecommunity subject to certain obligations and respon-sibilities. Obligations include modification obliga-tions such as updating and removing the document.The member of the community becomes an authorand has a role as owner. The community, however,obtains or possesses the contribution. Responsibili-ties of the author include quality obligations for thecontribution.

Join: Users may join a community and thus obtain a roleof a member of the community. The membership re-quires the commitment to the coordination style andcoordination pattern of the community. This commit-ment implies a certain behaviour and collaborationwith the members of the community. For instance,members agree on regular occurrence or logical rela-tions. The membership may be public or hidden tovisitors.

Meet: Members of a community come together at a par-ticular time or place, entering into conference, argu-ment, or personal dealings with other members of thecommunity or the general auditory. During the meet-ing they receive or greet in an official capacity of thecommunity. Members may form coalitions before,during and after meetings.

Organize: Becoming a member of a community bringsrights and obligations. The member may be permit-ted to develop a unit within the community and hasa function during this development. In this case themember becomes a coherent functioning whole, andcontributes with own profile and portfolio. Organisa-tions often require to arrange by systematic planningand united effort.

Publish: The author makes his/her contributions gener-ally known. The community decides, whether thecontribution can be disseminated to the public basedon the rules of the community. The contribution isthen produced or released for distribution.

Subscribe: Communities often have their own publica-tion lines. A member subscribes to some of themaccording to the rules of the community. The sub-scribed services are (periodically and regularly) re-ceived by the actor. The member of the community

agrees to purchase and pay for securities. The sub-scription can also be extended to new offerings.

Withdraw: The members of a community should havethe right to cancel the membership of the commu-nity or part of the subscriptions. In this case the usermay loose the ownership of contributions s/he made.The withdrawal may require particular official proce-dures.

3.3 Portfolios for Entertainment and Gaming Sys-tems

Web-based entertainment systems are less data-intensivethan systems in the other categories of WISs. They aretherefore less important for us, but we include this briefdiscussion of entertainment WISs for the sake of com-pleteness.Entertainment systems aim at evoking feelings and

thoughts. They are usually combined with (personal) e-business sites. Sometimes, they are also embedded intoeducational sites. They are similar to real life entertain-ment. The general brand PW2UA is specialized by ac-tive scenarios (act) with activities taken by the receivingactor(s) and by the products of entertainment. The prod-ucts are usually associated with fun (F ). Therefore, thebrand of entertainment (fan) sites is given by BF2Vact orVF2Vact with B for business and V for visitor.Entertainment sites suffer from incompatibilities and

unstable technology. As CD-ROM sophistication hasdried out all singleton player entertainment sites, the em-phasis is now on interactive or collaborating games. Theaspect of collaboration is analogous to community/groupWISs. The placement of functionality and content followshowever the gaming approach, i.e. links to a guided tour,room or apartment metaphors for placement of items, ex-hibits, and setting expectations very well before breakingthe rules.Entertainment sites can be classified into a number

of kinds, genres, and classes such as head and expert,develop, or fight. Kinds such as tournaments, n-playergames, board games are specified by a number of criteriathat are not subject to interpretation or understanding ofthe user and are not dynamic. Genres classify the experi-ence the player gains, e.g., reasoning, reacting. Classescharacterize the storyboard of the game, e.g., develop-ment, deduction, shooting, trading. Additionally, the sto-ryboard has in entertainment a special situation: conflictsand conflict resolution.

8

Strategy games are the most important entertainmentWIS beside action games, adventure and role games, sportgames, and puzzle games. Since strategy, tactics, and rolegames may also be used for edutainment we discuss thesein more details. They are often based on puzzle-solvingscenarios where a player has certain targets such as a re-naturation or area development target. The space of ap-plicable steps has a high dimensionality. Applicable stepsare dependent on each other and have a number of re-,rely-, guarantee- and post-conditions and distant and sideeffects.Scenarios can be based on word fields such as de-

cide, explore and detect, and ask. They represent oftencomplex, network and dynamic situations. The completeinformation on the situation cannot be retrieved by theplayer. Player must often follow patterns of causal andhypothetical reasoning, i.e. development of targets, col-lection of data and development of a model, analysis of thecurrent situation and its opportunities, prognostic elabora-tion and extrapolation, planing of activities, and control ofthe effect. Targets and goals may have positive or negativeeffects. Sometimes, negative effects are preferable. Goalsmay be preferable or avoidable, general or specific, sim-ple or complex, and implicit or explicit. Data have theirown characterisation ranging from important in the givensituation to neglectable.This gives rise to a number of utilisation scenarios.

Games are specified by• the intention of the game by a variable and quantifi-able outcome that can be valorized, e.g., the purposefor the player, the intent of the player,

• a number of transition rules with content parameters,with function parameters, and with states to be trans-formed,

• the player effort for the game depending on the pro-file and the portfolio of the player, e.g. abilities, edu-cation, tasks, collaboration, and

• the context of the game, e.g., hardware and soft-ware context, actor context, storyboard context, tem-poral context, organizational and social context, andprovider contextThe attachment of the player to the outcome may

change the game behaviour. Consequences of steps theplayer is taking may also be under negotiation. Games aremainly flat and linear scenarios that follow a game story.Additional information, tricks, tips, customer treatment,contracting, workspace supply, communication support,group and game rooms, help/tips, downloads, payment,conditions of usage extend the playout of the scenarios.Hobby sites use scenarios similar to information or com-munity sites. In this case, hobby description, links, doc-uments and other media objects are provided. Fun andhumor site often do not have any scenario. They mainlyconsist of links and documents.The storyboard of games and scenes can be generally

specified by the scene intention in Figure 4. Players ofgames do not have the full control and the full knowledgeof the state of the art. At the same time, they have the illu-sion of full control, of full vision, and of full functionality.

self-determination indetermination

framing, vision, view

fascination of control, mental effects

scene

Figure 4: The characterization of the intention of sceneswithin entertainment

Functionality of entertainment WIS is often very so-phisticated. It ranges from simple click and point func-tions to story instantiation or story restructuring functions.

The navigation is based on simple tree or graph structurewhereas the structuring depends on categories/rubrics orontology. Personal entertainment site, advice sites, andsurvey sites also do not have any scenario. They followmainly approaches we discuss for corporate identity andforum. Their navigation structure is rather simple, of-ten only a one-level structure. They follow metaphors ofshow-business presentation. Similarly experiment presen-tation sites are built. Special entertainment sites provide agroup service, use a pay-per-view payment and are basedon journal or presentation metaphors. They provide a col-lection of media data, customer data, and contracts. Onlythe last case can be described through word fields suchas survey, billing, condition, order, member service, andlinking.Entertainment WIS are based on a sophisticated actor

specification. Actors are often highly demanding in theirrequirements. Their quality requirements include accessi-bility, art/mechanics, downloads, easy exploration, feed-back, (sophisticated) functionality, guidance, immersion,integration, and (narrative) storytelling.Actors are associated to portfolio that consists of tasks

of certain degree of difficulty, with certain effects, dura-tion for completion and benefits and penalties for theircompletion. Tasks are structured, ordered, and prioritized.Context is often deeply elaborated in entertainment

WIS. They are providing all illusions and functions knownfor virtual reality.Since virtual reality is considered to be an image of the

reality, it is also characterized by history, folks, organisa-tions, realms, and ambitions for further development.The results of execution of a scene is related to tasks

currently under consideration with their pre-determinedplans and scenarios, with time management, with man-agement of state changes, with resources, functions, andcollaborating actors. The tasks are structured and orderedand follow a certain plan. For their solution a number ofresources must be provided and a level of resistance mustbe overruled. Activities can be described by word fieldsfor all major verbs in our language. Tasks may be open,completed, under completion, under repetition, etc. En-tertainment WIS usually reward players for successful ex-ecution. Scene change follows general stories envisioned.The involvement of actors in task completion is pre-

specified on the basis of characters, i.e. the roles an actormay potentially play, the part the actor plays within thescenario, rights an actor obtains during execution, obliga-tions an actor must obey within a given role or within a setof roles.We expect that future edutainment WIS will inherit a

number of these features and neatly integrate them into thestoryboard, into the content management of the WIS, andinto the support for activities of actors.

4 Conclusion

In this paper we extended our previous work on prag-matics of Web Information Systems. We introduced WISportfolios, which are composed of an information port-folio and a utilisation portfolio. The information portfo-lio captures information consumption and production byusers in the scenes of the story space. This is linked to theinformation needed by a user to understand the task andthe information demand to perform the appropriate action.Modelling information demand of all potential users is in-feasible, but the concept of persona permits to deal withprototypical users instead. The integration of informationdemands leads to content chunks.Likewise, the utilisation portfolio consists of tasks

users might wish to accomplish within the system, andgoals they want to achieve by this. It can be considered asthe necessary means for collecting functionality require-ments. Different from the information portfolio the utili-sation portfolio depends on the application category. Here

9

we focused on the categories of learning WISs and groupor community WISs.WIS portfolios complete the research onWIS pragmat-

ics, which is an independing connector element betweensystems requirements and conceptual models. In this pa-per, due to space limitations we had to omit many details,which we plan to report elsewhere in an extended version.

References

Anonymous (2005a), ‘——’. details hidden for double-blind reviewing.

Anonymous (2005b), ‘——’. details hidden for double-blind reviewing.

Anonymous (2007a), ‘——’. details hidden for double-blind reviewing.

Anonymous (2007b), ‘——’. details hidden for double-blind reviewing.

Anonymous (2007c), ‘——’. details hidden for double-blind reviewing.

Anonymous (2008), ‘——’. details hidden for double-blind reviewing.

Anonymous (2009), ‘——’. details hidden for double-blind reviewing.

Carroll, J. M. (2004), Participatory design of commu-nity information systems - the designer as bard, in‘COOP’, pp. 1–6.

Ceri, S., Fraternali, P., Bongio, A., Brambilla, M., Comai,S. & Matera, M. (2003), Designing Data-IntensiveWeb Applications, Morgan Kaufmann, San Fran-cisco.

De Troyer, O. & Leune, C. (1998), WSDM: A user-centered design method for web sites, in ‘Com-puter Networks and ISDN Systems – Proceedings ofthe 7th International WWW Conference’, Elsevier,pp. 85–94.

Giorgini, P., Mylopoulos, J., Nicchiarelli, E. & Sebastiani,R. (2002), Reasoning with goal models, in ‘ER’,pp. 167–181.

Harel, D. & Marelly, R. (2003), Come, Let’s play:Scenario-based programming using LSCs and theplay-engine, Springer, Berlin.

Houben, G.-J., Barna, P., Frasincar, F. & Vdovjak, R.(2003), HERA: Development of semantic web infor-mation systems, in ‘Third International Conferenceon Web Engineering – ICWE 2003’, Vol. 2722 ofLNCS, Springer-Verlag, pp. 529–538.

Kensing, F. & Blomberg, J. (1998), ‘Participatory design:Issues and concerns’, Computer Supported Cooper-ative Work 7(3/4), 167–185.

Lowe, D., Henderson-Sellers, B. & Gu, A. (2002),Web extensions to UML: Using the MVC triad, inS. Spaccapietra, S. T. March & Y. Kambayashi, eds,‘Conceptual Modeling – ER 2002’, Vol. 2503 ofLNCS, Springer-Verlag, pp. 105–119.

O’Neill, E. & Johnson, P. (2004), Participatory task mod-elling: users and developers modelling users’ tasksand domains, in ‘TAMODIA’, pp. 67–74.

Robertson, J. & Robertson, S. (2006), Requirements-LedProject Process, Addison-Wesley.

Rossi, G., Schwabe, D. & Lyardet, F. (1999), Web appli-cation models are more than conceptual models, inP. Chen et al., eds, ‘Advances in Conceptual Mod-eling’, Vol. 1727 of LNCS, Springer-Verlag, Berlin,pp. 239–252.

Web (1991), ‘Webster’s ninth new collegiate dictionary’.

10

Extended Entity-Relationship Model

Bernhard ThalheimChristian-Albrechts University Kiel, http://www.informatik.uni-kiel.de/∼thalheim

SYNONYMSEERM, HERM; higher-order entity-relationship model; hierarchical entity-relationship model

DEFINITIONThe extended entity-relationship (EER) model is a language for defining the structure (and functionality) ofdatabase or information systems. Its structure is developed inductively. Basic attributes are assigned to base datatypes. Complex attributes can be constructed by applying constructors such as tuple, list or set constructors toattributes that have already been constructed. Entity types conceptualise structuring of things of reality throughattributes. Cluster types generalise types or combine types into singleton types. Relationship types associatetypes that have already been constructed into an association type. The types may be restricted by integrityconstraints and by specification of identification of objects defined for a type. Typical integrity constraints ofthe extended entity-relationship model are participation, look-across, and general cardinality constraints. Entity,cluster, and relationship classes contain a finite set of objects defined on these types. The types of an EER schemaare typically depicted by an EER diagram.

HISTORICAL BACKGROUNDThe entity-relationship (ER) model was introduced by P.P. Chen in 1976 [1]. The model conceptualises andgraphically represents the structure of the relational model. It is currently used as the main conceptual model fordatabase and information system development. Due to its extensive usage a large number of extensions to thismodel were proposed in the 80’s and 90’s. Cardinality constraints [1, 3, 4, 8] are the most important generalisationof relational database constraints [7]. These proposals have been evaluated, integrated or explicitly discarded in anintensive research discussion. The semantic foundations proposed in [2, 5, 8] and the various generalisations andextensions of the entity-relationship model have led to the introduction of the higher-order or hierarchical entity-relationship model [8] which integrates most of the extensions and also supports conceptualisation of functionality,distribution [9], and interactivity [6] for information systems. Class diagrams of the UML standard are a specialvariant of extended entity-relationship models.The ER conferences (annually; since 1996: International Conference on Conceptual Modeling,http://www.conceptualmodeling.org/) are the main forum for conceptual models and modelling.

SCIENTIFIC FUNDAMENTALSThe extended entity-relationship model is mainly used as a language for conceptualisation of the structure ofinformation systems applications. Conceptualisation of database or information systems aims to represent thelogical and physical structure of an information system. It should contain all the information required by theuser and required for the efficient behavior of the whole information system for all users. Conceptualisation mayfurther target the specification of database application processes and the user interaction. Structure descriptionare currently the main use of the extended ER model.

An example of an EER diagram.The EER model uses a formal language for schema definition and diagrams for graphical representation of the

schema. Let us consider a small university application for management of Courses. Proposed courses are basedon courses and taught by a docent or an external docent within a certain semester and for a set of programs.Proposals typically include a request for a room and for a time and a categorisation of the kind of the course.Theses proposals are the basis for course planning. Planning may change time, room and kind. Planned coursesare held at the university. Rooms may be changed. The example is represented by the EER diagram in Figure 1.

Course

CourseID

Title

URLSemester

Term Date(Starts,Ends)

CollaborationPartner

Name Company Contact

©©©©HHHH

©©©©HHHH

-Professor

Chair

Person

DateOfBirth

PersNo

Login URL

Contact Address

Name

Room

Capacity

Number

Building©©©©HHHH

©©©©HHHH

¾

6

Proposed

Course

Kind

[SpecSchedule] Regulations

ID

©©©©HHHH

©©©©HHHH

¾

6

CourseHeld

Reassigned

[ ]

StartDateEndDate

AssistedBy

©©©©HHHH

©©©©HHHH

¾

6

PlannedCourse

Reassigned

[ ]

Reassigned

[ ]

TimeFrame TermCourseID

Program

ID

DepartmentResponsible

Name

URL

Set2Time(Proposal,SideCondition)

Request

Proposal

ExternalDocent

Docent

¡¡

¡¡µ

L»»»»»»»»»»»»»»»:

QQ

QQ

QQQk

-

©©©©©©©©©*´´

´´

´+

Figure 1: Extended Entity-Relationship Diagram for Course Management

Entity types are represented graphically by rectangles. Attribute types are associated with the correspondingentity or relationship type. Attributes primarily identifying a type are underlined. Relationship types are repre-sented graphically by diamonds and associated by directed arcs to their components. A cluster type is representedby a diamond, is labelled by the disjoint union sign, and has directed arcs from the diamond to its componenttypes. Alternatively, the disjoint union representation ⊕ is attached to the relationship type that uses the clustertype. In this case directed arcs associate the ⊕ sign with component types. An arc may be annotated with a label.

The definition scheme for structures.The extended entity-relationship model uses a data type system for its attribute types. It allows the constructionof entity types E $ (attr(E),ΣE) where E is the entity type defined as a pair — the set attr(E) of attribute typesand the set ΣE of integrity constraints that apply to E. The definition def of a type T is denoted by T $ def .The EER model lets users inductively build relationship types R $ (T1, ..., Tn, attr(R), ΣR) of order i (i ≥ 1)through a set of (labelled) types of order less than i, a set of attribute types, and a set of integrity constraintsthat apply to R. The types T1, ..., Tn are the components of the relationship type. Entity types are of order 0.Relationship types are of order 1 if they have only entity types as component types. Relationship types are oforder i if all component types are of order less than i and if one of the component types is of order i− 1.Additionally, cluster types C $ T1

.∪ ....∪ Tn of order i can be defined through a disjoint union

.∪ of relationshiptypes of order less than i or of entity types.Entity/relationship/cluster classes TC contain a set of objects of the entity/relationship/cluster type T . The EERmodel mainly uses set semantics, but (multi-)list or multiset semantics can also be used. Integrity constraintsapply to their type and restrict the classes. Only those classes are considered for which the constraints of theirtypes are valid. The notions of a class and of a type are distinguished. Types describe the structure andconstraints. Classes contain objects.The data type system is typically inductively constructed on a base type B by application of constructors such asthe tuple or products constructor (..), set constructor .., and the list constructor < .. >. Types may be optionalcomponent types and are denoted by [..].The types T can be labelled l : T . The label is used as an alias name for the type. Labels denote roles of the type.Labels must be used if the same type is used several times as a component type in the definition of a relationship

2

or cluster type. In this case they must be unique.An entity-relationship schema consists of a set of data, attribute, entity, relationship, and cluster types whichtypes are inductively built on the basis of the base types.Given a base type system B. The types of the ER schema are defined through the type equation:

T = B | (l1 : T, ..., ln : T ) | T | <T > | [T ] | T.∪ T | l : T | N $ T

Structures in detail.The classical four-layered approach is used for inductive specification of database structures. The firstlayer is the data environment, called the basic data type scheme, which is defined by the system or is theassumed set of available basic data types. The second layer is the schema of a database. The third layeris the database itself representing a state of the application’s data often called micro-data. The fourth layerconsists of the macro-data that are generated from the micro-data by application of view queries to the micro-data.

Attribute types and attribute values.The classical ER model uses basic (first normal form) attributes. Complex attributes are inductively constructedby application of type constructors such as the tuple constructor (..), set constructor .., and the list constructor< .. >. Typical base types are integers, real numbers, strings, and time. Given a set of names N and a set ofbase types B, a basic attribute type A :: B is given by an (attribute) name A ∈ N and a base type B. Theassociation between the attribute name and the underlying type is denoted by :: . The base type B is oftencalled the domain of A, i.e. dom(A) = B. Complex attributes are constructed on base attributes by applicationof the type constructors. The notion of a domain is extended to complex attributes, i.e. the domain of thecomplex attribute A is given by dom(A). Components of complex attributes may be optional, e.g., the Title inthe attribute Name.Typical examples of complex and basic attributes in Figure 1 are

Name $ (FirstNames <FirstName>, FamName, [AcadTitles], [FamilyTitle]) ,PersNo $ EmplNo

.∪ SocSecNo ,AcadTitles $ AcadTitle ,Contact $ (Phone(PhoneAtWork, private), Email, URL, WebContact, [Fax(PhoneAtWork)] ) ,PostalAddress $ (Zip, City, Street, HouseNumber)for DateOfBirth :: date, AcadTitle :: acadTitleType, FamilyTitle :: familyTitleAcronym, Zip :: string7,

SocSecNo :: string9, EmplNo :: int, City :: varString, Street :: varString, HouseNumber :: smallInt.The complex attribute Name is structured into a sequence of first names, a family name, an optional complexset-valued attribute for academic titles, and an optional basic attribute for family titles. Academic titles andfamily titles can be distinguished from each other.

Entity types and entity classes.Entity types are characterized by their attributes and their integrity constraints. Entity types have a subset Kof the set of attributes which serve to identify the objects of the class of the type. This concept is similar to theconcept of key known for relational databases. The key is denoted by ID(K). The set of integrity constraints ΣE

consists of the keys and other integrity constraints. Identifying attributes may be underlined instead of havingexplicit specification.Formally, an entity type is given by a name E, a set of attributes attr(E), a subset id(E) of attr(E), and a setΣE of integrity constraints, i.e.

E $ (attr(E), ΣE) .The following types are examples of entity types in Figure 1:

Person $ ( Name, Login, URL, Address, Contact, DateOfBirth, PersNo )Course $ ( CourseID, Title, URL , ID( CourseID ) ),Room $ ( Building, Number, Capacity , ID(Building, Number ) ),Semester $ ( Term, Date(Starts, Ends) , ID( Term ) ).

An ER schema may use the same attribute name with different entity types. For instance, the attribute URL inFigure 1 is used for characterising additional information for the type Person and the type Course. If they needto be distinguished, then complex names such as CourseURL and PersonURL are used.Objects on type E are tuples with the components specified by a type. For instance, the object (or entity)(HRS3, 408A, 15) represents data for the Room entity type in Figure 1.

3

An entity class EC of type E consists of a finite set of objects on type E for which the set ΣE of integrityconstraints is valid.

Cluster types and cluster classes.A disjoint union

.∪ of types whose identification type is domain compatible is called a cluster. Types are domaincompatible if they are subtypes of a common more general type. The union operation is restricted to disjointunions since identification must be preserved. Otherwise, objects in a cluster class cannot be related to thecomponent classes of the cluster type. Cluster types can be considered as a generalisation of their componenttypes.A cluster type (or “category”)

C $ l1 : R1

.∪ l2 : R2

.∪ ....∪ lk : Rk

is the (labelled) disjoint union of types R1, ..., Rk. Labels can be omitted if the types can be distinguished.The following type is an example of a cluster type:

Teacher $ ExternalDocent : CollaborationPartner.∪ Docent : Professor .

The cluster class CC is the ‘disjoint’ union of the sets RC1 , ..., RC

k . It is defined if RC1 , ...RC

k are disjoint on theiridentification components. If the sets RC

1 , ..., RCk are not disjoint then labels are used for differentiating the

objects of clusters. In this case, an object uses a pair representation (li, oi) for objects oi from RCi .

Relationship types and relationship classes.First order relationship types are defined as associations between entity types or clusters of entity types.Relationship types can also be defined on the basis of relationship types that are already defined. This constructionmust be inductive and cannot be cyclic. Therefore, an order is introduced for relationship types. Types can onlybe defined on the basis of types which have a lower order. For instance, the type Professor in Figure 1 is of order1. The type ProposedCourse is of order 2 since all its component types are either entity types or types of order1. A relationship type of order i is defined as an association of relationship types of order less than i or of entitytypes. It is additionally required that at least one of the component types is of order i− 1 if i > 1. Relationshiptypes can also be characterized by attributes. Relationship types with one component type express a subtype oran Is-A relationship type. For instance, the type Professor is a subtype of the type Person.Component types of a relationship type may be labelled. Label names typically provide an understanding ofthe role of a component type in the relationship type. Labelling uses the definition scheme Label : Type. Forinstance, the Kind entity type is labelled by Proposal for the relationship type ProposedCourse in in Figure 1.Cluster types have the maximal order of their component types. Relationship types also may have cluster typecomponents. The order of cluster type components of a relationship type of order i must be less than i.Component types that are not used for identification within the relationship type can be optional. For instance,the Room component in Figure 1 is optional for the type PlannedCourse. If the relationship object in thePlannedCourse class does not have a room then the proposal for rooms in ProposedCourse is accepted. A specificextension for translation of optional components may be used. For instance, Room in Figure 1 is inherited toPlannedCourse from ProposedCourse if the Room component for a PlannedCourse is missing.Higher order types allow a convenient description of types that are based on other types. For example, considerthe course planning application in Figure 1. Lectures are courses given by a professor or a collaboration partnerwithin a semester for a number of programs. Proposed courses extend lectures by describing which room isrequested and which time proposals and which restrictions are made. Planing of courses assigns a room to acourse that has been proposed and assigns a time frame for scheduling. The kind of the course may be changed.Courses that are held are based on courses planned. The room may be changed for a course. The following typesspecify these assertions.

ProposedCourse $ ( Teacher, Course, Proposal : Kind, Request : Room, Semester, Set2 : Program , Time(Proposal, SideCondition) , ΣProposedCourse),

PlannedCourse $ (ProposedCourse, [Reassigned : Kind ] , [ Reassigned : Room ], TimeFrame, TermCourseID , ΣPlannedCourse),

CourseHeld $ (PlannedCourse, [ Reassigned : Room ], StartDate, EndDate, AssistedBy ,ΣCourseHeld).

The second and third types use optional components in case a proposal or a planning of rooms or kinds is changed.Typically, planned courses are identified by their own term-specific identification. Integrity constraints can be

4

omitted until they have been defined.Formally, a relationship type is given by a name R, a set compon(R) of labelled components, a set of attributesattr(R), and a set ΣR of integrity constraints that includes the identification of the relationship type by a subsetid(R) of compon(R) ∪ attr(R), i.e.

R $ (compon(R), attr(R), ΣR) .It is often assumed that the identification of relationship types is defined exclusively through their componenttypes. Relationship types that have only one component type are unary types. These relationship types definesubtypes. If subtypes need to be explicitly represented then binary relationship types named by IsA between thesubtype and the supertype are used. For instance, the type Professor in Figure 1 is a subtype of the type Person.An object (or a “relationship”) on the relationship type R $ (R1, ..., Rn, B1, ..., Bk, id(R), ΣR) is an elementof the Cartesian product RC

1 × ... × RCn × dom(B1) × ... × dom(Bk). A relationship class RC consists of a finite

set RC ⊆ RC1 × ... × RC

n × dom(B1) × ... × dom(Bk) of objects on R for which id(R) is a key of RC and whichobeys the constraints ΣR.

Integrity constraints.Each database model also uses a set of implicit model-inherent integrity constraints. For instance, relationshiptypes are defined over their component types, and a (relationship) object presumes the existence of correspondingcomponent objects. Typically only finite classes are considered. The EER schema is acyclic. Often names orlabels are associated with a minimal semantics that can be derived from the meaning of the words used for namesor labels. This minimal semantics allows us to derive synonym, homonym, antonym, troponym, hypernym, andholynym associations among the constructs used.The most important class of integrity constraints of the EER model is the class of cardinality constraints. Otherclasses of importance for the EER model are multivalued dependencies, inclusion and exclusion constraintsand existence dependencies[7]. Functional dependencies, keys and referential constraints (or key-based inclusiondependencies) can be expressed through cardinality constraints.Three main kinds of cardinality constraints are distinguished: participation constraints, look-across constraints,and general cardinality constraints. Given a relationship type R $ (compon(R), attr(R), ΣR), a component R′

of R, the remaining substructure R′′ = R \R′ and the remaining substructure R′′′ = R′′ uR compon(R) withoutattributes of R.The participation constraint card(R, R′) = (m, n) restricts the number of occurrences of R′ objects in therelationship class RC by the lower bound m and the upper bound n. It holds in a relationship class RC iffor any object o′ ∈ R′C there are at least m and at most n objects o ∈ RC with πR′(o) = o′ for the projectionfunction πR′ that projects o to its R′ components.Participation constraints relate objects of relationship classes to objects of their component classes. For instance,the constraint card(ProposedCourse, SemesterCourse) = (0, 3) restricts relationship classes for proposalsfor courses per semester to at least 0 and at most 3, i.e. each course is proposed at most three times ina semester. There are at most three objects o in ProposedCourseC with the same course and semesterobjects. The integrity constraint card(ProposedCourse, DocentSemester) = (3, 7) requires that each docentis giving at least 3 courses and at most 7 courses. External docents may be obliged by other restrictions, e.g.,card(ProposedCourse, ExternalDocentSemester) = (0, 1) .Formally, the integrity constraint card(R,R′) = (m,n) is valid in RC if m ≤ | o ∈ RC : πR′(o) = o′ | ≤ nfor any o′ ∈ πR′(RC) and the projection πR′(RC) of RC to R′.If card(R, R′) = (0, 1) then R′ forms an identification or a key of R, i.e. ID(R′) for R. This identification canalso be expressed by a functional dependency R : R′ −→ R′′ .The lookup or look-across constraint look(R, R′) = m..n describes how many objects o′′′ from R′′′C maypotentially ‘see’ an object o′ from R′C . It holds in a relationship class RC if for any object o′′′ ∈ dom(R′′′)there are at least m and at most n related objects o′ with πR′(o) = o′, i.e. m ≤ | o′ ∈ πR′(RC) : o ∈RC ∧ πR′(o) = o′ ∧ πR′′′(o) = o′′′ | ≤ n for any o′′′ ∈ Dom(R′′′). Typically, look-across constraints are usedfor components consisting of one type. Look-across constraints are not defined for relationship types with onecomponent type.Look-across constraints are less intuitive for relationship types with more than 2 component types or with attributetypes. For instance, the look-across constraint look(ProposedCourse, DocentSemester) = 0..7 specifies that forany combination of Teacher, Room, Kind, and Program objects there are between 0 and 7 Docent and Semester

5

combinations. The lower bound expresses that there are Teacher, Room, Kind, and Program which do not havea Docent and Semester combination.Look-across constraints for a binary relationship type which component types form a key of the relationshiptype can equivalently expressed by participation constraints, i.e. look(R, R1) = m1..n1 if and only ifcard(R,R2) = (m1, n1) . Similarly, look(R,R2) = m2..n2 if and only if card(R, R1) = (m2, n2) . Thisequivalence is neither valid for binary relationship types which cannot by identified by their components and norfor relationship types with more than 2 components.Participation and look-across constraints can be extended to substructures and intervals and to other typessuch as entity and cluster types. Given a relationship type R, a substructure R′ of R, R′′ and R′′′ as above.Given furthermore an interval I ⊆ N0 of natural numbers including 0. The (general) cardinality constraintcard(R,R′) = I holds in a relationship class RC if for any object o′ ∈ πR′(RC) there are i ∈ I objects o withπR′(o) = o′, i.e. | o ∈ RC : πR′(o) = o′ | ∈ I for any o′ ∈ πR′(RC).The following participation, look-across and general cardinality constraints are examples in Figure 1:

For any R′ ∈ Semester, Course, Kind card(ProposedCourse,R′) = (0, n),card(ProposedCourse, Semester Course Teacher) = (0, 1),card(CourseHeld, P lannedCourse) = (1, 1),card(PlannedCourse, ProposedCourse[Semester] Room TimeFrame) = (0, 1),card(ProposedCourse, Docent Semester) = 0, 3, 4, 5, 6, 7.

The first constraint does not restrict the database. The second constraint expresses a key or functionaldependency. The types Semester Course Teacher identify any of the other types in the type ProposedCourse, i.e.

ProposedCourse: Semester, Course, Teacher −→ Request, Time, Proposal, Set2 .The third constraint requires that any planned course must be given. The fourth constraint requires that roomsare not overbooked. The fifth constraint allows that docents may not teach in a semester, i.e. have a sabbatical.If a docent is teaching in a semester then at least 3 and at most 7 courses are given by the docent.Look-across constraints were originally introduced by P.P. Chen [1] as cardinality constraints. UML uses look-across constraints. Participation and look-across constraints cannot be axiomatised through a Hilbert- or Gentzen-type logical calculus. If only upper bounds are of interest then an axiomatisation can be found in [3] and[4]. General cardinality constraints combine equality-generating and object-generating constraints such as keys,functional dependencies and referential integrity constraints into a singleton construct.Logical operators can be defined for each type. A set of logical formulas using these operators can define theintegrity constraints which are valid for each object of the type.

Schemata.The schema is based on a set of base (data) types which are used as value types for attribute types.A set E1, ...En, C1, ...., Cl, R1, ..., Rm of entity, cluster and (higher-order) relationship types on a data schemeDD is called schema if the relationship and cluster types use only the types from E1, ..., En, C1, ...., Cl, R1, ..., Rmas components and cluster and relationship types are properly layered.An EER schema is defined by the pair D = (S, Σ) where S is a schema and Σ is a set of constraints. A databaseDC on D consists of classes for each type in D such that the constraints Σ are valid.The classes of the extended ER model have been defined through sets of objects on the types. In addition to sets,lists, multi-sets or other collections of objects may be used. In this case, the definitions used above can easily beextended [8].A number of domain-specific extensions have been introduced to the ER model. One of the most important isthe extension of the base types by spatial data types such as: point, line, oriented line, surface, complex surface,oriented surface, line bunch, and surface bunch. These types are supported by a large variety of functions suchas: meets, intersects, overlaps, contains, adjacent, planar operations, and a variety of equality predicates.The translation of the schema to (object-)relational or XML schemata can be based on a profile [8]. Profilesdefine which translation choice is preferred over other choices, how hierarchies are treated, which redundancy andnull-value support must be provided, which kind of constraint enforcement is preferred, which naming conventionsare chosen, which alternative for representation of complex attributes is preferred for which types, and whetherweak types can be used. The treatment of optional components is also specified through the translation profileof the types of the schema. A profile may require the introduction of identifier types and base the identificationon the identifier. Attribute types may be translated into data formats that are supported by the target system.

6

The EER schema can be used to define views. The generic functions insert, delete, update, projection, union,join, selection and renaming can be defined in a way similarly to the relational model. Additionally, nesting andunnesting functions are used. These functions form the algebra of functions of the schema and are the basis fordefining queries. A singleton view is defined by a query that maps the EER schema to new types. Combinedviews also may be considered which consist of singleton views which together form another EER schema.A view schema is specified over an EER schema D by a schema V = S1, ..., Sm, an auxiliary schema A and a(complex) query q : D ×A → V defined on D and A. Given a database DC and the auxiliary database AC .The view is defined by q(DC ×AC).

Graphical representation.The schema in Figure 1 consists of entity, cluster and relationship types. The style of drawing diagrams isone of many variants that have been considered in the literature. The main difference of representation is thestyle of drawing unary types. Unary relationship types are often represented by rectangles with rounded cornersor by (directed) binary IsA-relationship types which associate by arcs the supertype with the subtype. Toolsoften do not allow cluster types and relationship types of order higher than 1. In this case, those types can beobjectified, i.e. represented by a new (abstract) entity type that is associated through binary relationship typesto the components of the original type. In this case, identification of objects of the new type is either inheritedfrom the component types or is provided through a new (surrogate) attribute. The first option results in theintroduction of so-called weak types. The direct translation of these weak types to object-relational models mustbe combined with the introduction of rather complex constraint sets. Typically, this complexity can be avoided ifthe abstract entity type is mapped together with the new relationship types to a singleton object-relational type.This singleton type is also the result of a direct mapping of the original higher-order relationship type.The diagram can be enhanced by an explicit representation of cardinality and other constraints. If participationconstraints card(R, R′) = (m,n) are used for component consisting of one type R′ then the arc from R to R′ islabelled by (m,n). If look-across constraints look(R,R′) = m..n are used for binary relationship types then thearc from R to R′ is labelled by m..n.

KEY APPLICATIONSThe main application area for extended ER models is the conceptualisation of database applications.Database schemata can be translated to relational, XML or other schemata based on transformation profiles thatincorporate properties of the target systems.

FUTURE DIRECTIONSThe ER model has had a deep impact on the development of diagramming techniques in the past and is stillinfluencing extensions of the unified modelling language UML. UML started with binary relationship types withlook-across constraints and without relationship type attributes. Class diagrams currently allow n-ary relationshiptypes with attributes. Relationship types may be layered. Cluster types and unary relationship types allow fordistinguishing generalisation from specialisation.ER models are not supported by native database management systems and are mainly used for modelling ofapplications at the conceptual or requirements level. ER schemata are translated to logical models such as XMLschemata or relational schemata or object-relational schemata. Some of the specifics of the target models are notwell supported by ER models and must be added after translating ER schemata to target schemata, e.g., specifictype semantics such as list semantics (XML) or as special ordering or aggregation treatment of online analyticalprocessing (OLAP) applications.The ER model has attracted a lot of research over the last 30 years. Due to novel applications and to evolutionof technology old problems and novel problems are challenging the research on this model. Typical old problemsthat are still not solved in a satisfactory manner are: development of a science of modelling, quality of ERschemata, consistent refinement of schemata, complex constraints, normalisation of ER schemata, normalisationof schemata in the presence of incomplete constraint sets. Novel topics for ER research are for instance: evolvingschema architectures, collaboration of databases based on collaboration schemata, layered information systems

7

and their structuring, schemata with redundant types, ER schemata for OLAP applications.Structures of database applications are often represented through ER models. Due to the complexity ofapplications, a large number of extensions have recently been proposed, e.g., temporal data types, spatial datatypes, OLAP types and stream types. Additionally, database applications must be integrated and cooperate ina consistent form. The harmonisation of extensions and the integration of schemata is therefore a never endingtask for database research.ER models are currently extended for support of (web) content management that is based on structuring ofdata, on aggregation of data, on extending data by concepts and on annotating data sets for simple referenceand usage. These applications require novel modelling facilities and separation of syntactical, semantical andpragmatic issues. The ER model can be extended to cope with these applications.The ER model is mainly used for conceptual specification of database structuring. It can be enhanced byoperations and a query algebra. Operations and the queries can also be displayed in a graphical form, e.g. onthe basis of VisualSQL. Most tools supporting ER models do not currently use this option. Enhancement ofER models by functionality is necessary if the conceptualisation is used for database development. Based onfunctionality enhancement, view management facilities can easily be incorporated into these tools.ER models are becoming a basis for workflow systems data. The standards that have been developed for thespecification of workflows have not yet been integrated into sophisticated data and application management tools.

URL TO CODEhttp://www.informatik.uni-kiel.de/∼thalheim/HERM.htmhttp://www.is.informatik.uni-kiel.de/∼thalheim/indeeerm.htm

Readings on the RADD project (Rapid Application and Database Development)Authors: M. Albrecht, M. Altus, E. Buchholz, H. Cyriaks, A. Dusterhoft, J. Lewerenz, H. Mehlan,M. Steeg, K.-D. Schewe, and B. Thalheim.

CROSS REFERENCEI. DATABASE FUNDAMENTALS

a. Data models (including semantic data models)b. Entity-Relationship (ER) modelc. Unified modelling language (UML)

III. THEORETICAL ASPECTSb. Relational Theory

RECOMMENDED READINGBetween 3 and 15 citations to important literature, e.g., in journals, conference proceedings, and websites.

[1] P. P. Chen. The entity-relationship model: Toward a unified view of data. ACM TODS, 1(1):9–36, 1976.[2] M. Gogolla. An extended entity-relationship model - fundamentals and pragmatics. LNCS 767. Springer, Berlin, 1994.[3] S. Hartmann. Reasoning about participation constraints and Chen’s constraints. In ADC, volume 17 of CRPIT,

pages 105–113. Australian Computer Society, 2003.[4] S. Hartmann, A. Hoffmann, S. Link, and K.-D. Schewe. Axiomatizing functional dependencies in the higher-order

entity-relationship model. Inf. Process. Lett., 87(3):133–137, 2003.[5] U. Hohenstein. Formale Semantik eines erweiterten Entity-Relationship-Modells. Teubner, Stuttgart, 1993.[6] K.-D. Schewe and B. Thalheim. Conceptual modelling of web information systems. Data and Knowledge Engineering,

54:147–188, 2005.[7] B. Thalheim. Dependencies in relational databases. Teubner, Leipzig, 1991.[8] B. Thalheim. Entity-relationship modeling – Foundations of database technology. Springer, Berlin, 2000.[9] B. Thalheim. Codesign of structuring, functionality, distribution and interactivity. Australian Computer Science

Comm. 31, 6 (2004), 3–12. Proc. APCCM’2004.

8

Specialisation and Generalisation

Bernhard ThalheimChristian-Albrechts University Kiel, http://www.informatik.uni-kiel.de/∼thalheim/HERM.htm

SYNONYMSrefinement, abstraction, hierarchies;clustering, grouping, inheritance

DEFINITIONGeneralisation and specialisation are main principles of database modelling. Generalisation maps or groups typesor classes to more abstract or combined ones. It is used to combine common features, attributes, or methods.Specialisation is based on a refinement of types or classes to more specific ones. It allows developers to avoidnull values and to hide details from non-authorised users. Typically, generalisations and specialisations form ahierarchy of types and classes. The more specialised classes may inherit attributes and methods from more generalones. In database modelling and implementation clusters of types to a type that represents common propertiesand abstractions from a type are the main kinds of generalisations. Is-A associations that specialise a type to amore specific one and Is-A-Role-Of associations that considers a specific behaviour of objects are the main kindsof specialisations.

MAIN TEXTSpecialisation introduces a new entity type by adding specific properties belonging to that type which are differentfrom the general properties of its more general type. Generalisation introduces the Role-Of relationship or the Is-A relationship between a subtype and its general type. Therefore, the application, implementation, and processesare different. For generalisation the general type must be the union of its subtypes. The subtypes can be virtuallyclustered by the general type. This tends not to be the case for specialisation. Specialisation is a refinement orrestriction of a type to more special ones. Typical specialisations are Is-A and Has-Role associations. Exceptionscan be modelled by specialisations.Different kinds of specialisation may be distinguished: structural specialisation which extends the structure,semantic specialisation which strengthens type restrictions, pragmatical specialisation which allows to separatethe different usage of objects in contexts, operational specialisation which introduces additional operations, andhybrid specialisations. Is-A specialisation requires structural and strong semantic specialisation. Is-A-Role-Ofspecialisation requires structural, pragmatical and strong semantic specialisation.Generalisation is based either on abstraction or on grouping. The cluster construct of the extended ER modelis used to represent generalisations. Generalisation tends to be an abstraction in which a more general type isdefined by extracting common properties of one or more types while suppressing the differences between them.These types are subtypes of the generic type. New types are created by generalizing classes that already exist.Structural combination typically assumes the existence of a unifiable identification of all types. Semanticalcombination allows the disjunction of types through the linear sum of semantics. Pragmatical generalisation isbased on building collections whenever applications require a consideration of commonalties.


a. Data models (including semantic data models)

REFERENCESB. Thalheim. Entity-relationship modeling – Foundations of database technology. Springer, Berlin, 2000.J. H. Ter Bekke. Semantic data modelling. Prentice-Hall, London, 1992.

1

Abstraction

Bernhard ThalheimChristian-Albrechts University Kiel, http://www.informatik.uni-kiel.de/∼thalheim/HERM.htm

SYNONYMScomponent abstraction, localisation abstraction, implementation abstraction;association, aggregation, composition, grouping, specialisation, generalisation, classification

DEFINITIONAbstraction allows developers to concentrate on the essential, relevant or important parts of an application. Ituses a mapping to a model from things in reality or from virtual things. The model has the truncation property,i.e. it lacks some of the details in the original, and a pragmatic property, i.e. the model use is only justifiedfor particular model users, tools of investigation, and periods of time. Database engineering uses constructionabstraction, context abstraction and refinement abstraction. Construction abstraction is based on the principlesof hierarchical structuring, constructor composition, and generalisation. Context abstraction assumes that thesurroundings of a concept are commonly assumed by a community or within a culture and focuses on the concept,turning away attention from its surroundings such as the environment and setting. Refinement abstraction usesthe principle of modularisation and information hiding. Developers typically use conceptual models or languagesfor representing and conceptualising abstractions. The enhanced entity-relationship model schema are typicallydepicted by an EER diagram.

MAIN TEXTDatabase engineering distinguishes three kinds of abstraction: construction abstraction, context abstraction andrefinement abstraction.Constructor composition depends on the constructors as originally introduced by J. M. Smith and D.C.W. Smith.Composition constructors must be well founded and their semantics must be derivable by inductive construction.There are three main methods for construction: development of ordered structures on the basis of hierarchies,construction by combination or association, and construction by classification into groups or collections. Theset constructors ⊂ (subset), × (product) and P (powerset) for subset, product and nesting are complete for theconstruction of sets.Subset constructors support hierarchies of object sets in which one set of objects is a subset of some other set ofobjects. Subset hierarchies are usually a rooted tree. Product constructors support associations between objectsets. The schema is decomposed into object sets related to each other by association or relationship types. Powerset constructors support a classification of object sets into clusters or groups of sets - typically according to theirproperties.

Context abstraction allows developers to commonly concentrate on those parts of an application that are essentialfor some viewpoints during development and deployment of systems. Typical kinds of context abstraction arecomponent abstraction, separation of concern, interaction abstraction, summarisation, scoping, and focusing ontypical application cases.Component abstraction factors out repeating, shared or local patterns of components or functions from individualconcepts. It allows developers to concentrate on structural or behavioral aspects of similar elements of components.Separation of concern allows developers to concentrate on those concepts that are a matter of developmentand to neglect all other concepts that are stable or not under consideration. Interaction abstraction allowsdevelopers to concentrate on those parts of the model that are essential for interaction with other systems orusers. Summarisation maps the conceptualisations within the scope to more abstract concepts. Scoping istypically used to select those concepts that are necessary for current development and removes those conceptsthat do not have an impact on the necessary concepts.Database models may cover a large variety of different application cases. Some of them reflect exceptional,

1

abnormal, infrequent and untypical application situations. Focusing on typical application cases explicitlyseparates models for the normal or typical application case from those that are atypical. Atypical applicationcases are not neglected but can be folded into the model whenever atypical situations are considered.The context abstraction concept is the main concept behind federated databases. Context of databases can becharacterized by schemata, version, time, and security requirements. Sub-schemata, types of the schemata or viewson the schemata, are associated by explicit import/export bindings based on a name space. Parametrisation letsdevelopers to consider collections of objects. Objects are identifiable under certain assumptions and completelyidentifiable after instantiation of all parameters.Interaction abstraction allows developers to display the same set of objects in different forms. The view conceptsupports this visibility concept. Data is abstracted and displayed in various levels of granularity. Summarisationabstraction allows developers to abstract from details that are irrelevant at a certain step. Scope abstractionallows developers to concentrate on a number of aspects. Names or aliases can be multiply used with varyingstructure, functionality and semantics.

Refinement abstraction is mainly about implementation and modularisation. It allows developers to selectivelyretain information about structures. Refinement abstraction is defined on the basis of the development cycle(refinement of implementations). It refines, summarises and views conceptualizations, hides or encapsulates detailsor manages collections of versions. Each refinement step transforms a schema to a schema of finer granularity.Refinement abstraction may be modelled by refinement theory and infomorphisms.Encapsulation removes internal aspects and concentrates on interface components. Blackbox or grayboxapproaches hide all aspects of the objects under consideration. Partial visibility may be supported bymodularisation concepts. Hiding supports differentiation of concepts into public, private (with the possibility tobe visible to ‘friends’) and protected (with visibility to subconcepts). It is possible to define a number of visibilityconceptualizations based in inflection. Inflection is used for the injection of combinable views into the givenview, for tailoring, ordering and restructuring of views, and for enhancement of views by database functionality.Behavioral transparency is supported by the glassbox approach. Security views are based on hiding. Versioningallows developers to manage a number of concepts which can be considered to be versions of each other.


a. Entity-Relationship Model, Extended Entity-Relationship Model, Object Data Models,Object Role Modeling, Unified Modeling Language

REFERENCESB. Thalheim. Entity-relationship modeling – Foundations of database technology. Springer, Berlin, 2000.J. M. Smith and D.C.W. Smith. Data base abstractions: Aggregation and generalization. ACM Transactionsof Database Systems, 2, 1977, 2, 2.E. Borger. The ASM Refinement Method. Formal Aspects of Computing, 15, 2003, 237-257

2

web information systems analysis, design, development, and

Documents