d5.4 - final report on open toolkit for knowledge networks...

IP CASCADAS “Component-ware for Autonomic, Situation-aware Communications, And Dynamically Adaptable Services”

D5.4

Bringing Autonomic Services to Life

of 91

D5.4 - Final Report on Open Toolkit for Knowledge Networks and on Advanced Knowledge Networks Concepts and Models

Status and Version: Version 3, Final Integration

Date of issue: December 15, 2008

Distribution: Project Deliverable R+P

Author(s): Name Partner

Matthias Baumgarten UU

Franco Zambonelli UNIMORE

Gabriella Castelli UNIMORE

Nicola Bicocchi UNIMORE

Rico Kusber UniK

Nermin Brgulja UniK

Checked by: Antonio Manzalini TI

Corrado Moiso TI

Abstract

This document represents the textual part of the Deliverable D5.4. It provides an updated overview of the Knowledge Networks released toolkit and it illustrates new features added during the third year.

It also includes an extensive evaluation and result discussion of the released toolkit.

Moreover a report about the main results achieved during the third year of the Cascadas Project has been added.

The source code of the final version of the prototype is available as open source on SourceForge at http://sourceforge.net/projects/acetoolkit/.


D5.4


of 91

Table of Contents

1 Introduction 3

1.1 Purpose and Scope 3

1.2 References 4

1.3 Document History 6

2 Knowledge Networks: Summary of Key Goals and Achievements 7

2.1 Overall Summary of WP5 Achievements over the 3 Years 7

2.2 Summary of WP5 Achievements for the 3rd Year 7

2.3 Joint activities with other WPs 9

3 Knowledge Networks Extensions for the ACE Toolkit 10

3.1 Status of the Toolkit at M24 and New Features Added 10

3.2 Components of the Toolkit: an Updated Overview 12

3.3 Major Extensions and Design Modifications 15 3.3.1 Cross Network Query Service (CNQ Service) 15 3.3.2 Concurrent Querying Mechanisms 16 3.3.3 ACE Parameterisation 17 3.3.4 GUI Optimisations 18 3.3.5 GN/GA – KNetwork Visibility within the ACE World 19 3.3.6 Liveliness Supervision of KN Components 21 3.3.7 Knowledge Distribution and Caching 22

3.4 The W4 Model and Flexible Aggregation 24 3.4.1 Aggregator Components‘ rationale 24 3.4.2 Extension and Modification since M24 25 3.4.3 The integration of the W4 Model within the Knowledge Network Toolkit 25 3.4.4 The final implementation of Aggregator Components 27 3.4.5 Examples of aggregation along spatio-temporal dimensions 28 3.4.6 On-Demand Aggregation 29

3.5 Context Verification 30 3.5.1 What is Context Verification 30 3.5.2 Requirements 32 3.5.3 Knowledge Organisation 32 3.5.4 Possible Context Verification results 34

3.6 An Example 35

4 Performance Evaluation 35

4.1 Performance Tests 36 4.1.1 Intranet based Performance Evaluation 37 4.1.2 Internet based Performance Evaluation 40 4.1.3 Buffer Size and the ACE Communication Model – Stepping Behaviour 42


D5.4


of 91

4.1.4 Payload Evaluation 43

4.1.5 Summary 46

4.2 An Empirical Study on the Traversal of Dynamically Constructed Knowledge Networks 47

4.2.1 Knowledge Network Topologies 47 4.2.2 Evaluation 49 4.2.3 Summary 53

5 Algorithmic and Scientific Advances 54

5.1 Handling Knowledge Generation and Knowledge Overflow 54 5.1.1 The W4 Data Model 55 5.1.2 W4 Knowledge Networks 56 5.1.3 The Knowledge Overflow Problem 57 5.1.4 A Self-Organizing Approach to Controlling Overflow 60 5.1.5 Simulation Results 61 5.1.6 Conclusion 63

5.2 Learning in Heterogeneous Sensing Systems 63 5.2.1 Description of the System 64 5.2.2 Implemented Use Case 65 5.2.3 Experimental Results 68 5.2.4 Related works 70

5.3 Stigmergic Linking 71 5.3.1 Stigmergic Linking for Optimising and Reasoning Over Information Networks 71 5.3.2 Stigmergic Linking: the WP5 Approach 74 5.3.3 Conclusions 86

5.4 Towards a Cognitive Model of Stigmergy 86

6 Conclusions, Self-assessment, and Future Work 90

1 Introduction

1.1 Purpose and Scope This document represents the M36 deliverable for the CASCADAS WP5 ―Knowledge Networks‖. Starting, it shortly summarizes some key aspects of knowledge networks and the key achievements. Secondly, it describes the final version of the developed ACE-based ―knowledge network toolkit‖, in particular w.r.t. the new features added since M24. Thirdly, it also reports on the M24-M36 advances on the study of advanced algorithms and approaches to knowledge networks. A self-assessment of three years of work of WP5 and an overview the areas for further research beyond CASCADAS is also reported at the end of the document.

This deliverable is accompanied by the software package containing the various components and packages of the ACE-based knowledge network toolkit individual algorithms and packages that reflect the final release of the KN toolkit. This can be found on the CASCADAS SourceForge page at: http://sourceforge.net/projects/acetoolkit/

The document is structured as follows. Section 2 summarizes the key goals of WP5, and the key achievements of the first year, the second year, and of the final year. Section 3 focuses

http://sourceforge.net/projects/acetoolkit/


D5.4


of 91

on the ACE-based KNs toolkit, and presents the new features added in it during the final year. Section 4 reports on performance evaluation experiments performed to assess the effectiveness of the implemented software. Section 5 reports on the main results obtained from the scientific viewpoint, i.e., related to algorithmic studies on various knowledge networks aspects. Section 6 concludes with a self-assessment and an identification of open research directions.

1.2 References [Bal07] D. Balzarotti, P. Costa, G.P. Picco, "The LighTS Tuple Space Frawework and its

Customization for Context-Aware Applications", International Journal on Web Intelligence and Agent Systems, Vol. 5, Number 2, 2007

[BCD+06] Babaoglu, O., Canright, G., Deutsch, A., Di Caro, G., Ducatelle, Gambardella, F., Ganguly, N., Jelasity, M., Montemanni, R., Montresor, A. and Urnes, T. ―Design Patterns from Biology for Distributed Computing‖, ACM Transactions on Autonomous and Adaptive Systems, 1 (1) (2006) 26 – 66.

[BHL01] Berners-Lee, T., Hendler, J. and Lassila, O. ―The Semantic Web: A new form of Web content that is meaningful to computers will unleash a revolution of new possibilities‖, Scientific American, May (2001).

[BM98] A. Blum and T. Mitchell. ―Combining labeled and unlabeled data with co-training‖. In COLT: Proceedings of the Workshop on Computational Learning Theory, Morgan Kaufmann Publishers, 1998.

[BrPa04] Breukner, S. and Van Dyke Parunak, H. ―Self-Organising MANET Management‖, G. Di Marzo Serugendo et al. (Eds.): AAMAS 2003 Ws ESOA, Lecture Notes in Artificial I ntelligence (LNAI) 2977, 2004, pp. 20 – 35.

[D1.4] CASCADAS D1.4, ―Integrated Prototype (release 2)‖, (July 2008).

[D2.5] CASCADAS D2.5, ―Long-term supervision and integrated supervision pervasion (final prototype)‖, (December 2008).

[D5.1] CASCADAS D5.1, ―Knowledge Networks Specifications, Mechanisms, and Alpha Software Release‖, (January 2007).

[D5.2] CASCADAS D5.2, ―Extended Beta Release Software for Knowledge Networks‖, (June 2007).

[D5.3] CASCADAS D5.3, ―Open Toolkit for Knowledge Networks‖, (December 2007).

[Cas07] G. Castelli, A. Rosi, M. Mamei, F. Zambonelli, ―A Simple Model and Infrastructure for Context-aware Browsing of the World, International Conference on Pervasive Computing and Communication‖, White Plains (NY, USA), 2007.

[CasMZ08] G. Castelli, M. Mamei, F. Zambonelli, ―Engineering Contextual Knowledge for Pervasive Autonomic Services‖, International Journal of Information and Software Technology, 50(1-2), 2008.

[CCP05] R. Cucchiara, C. Grana, A. Prati, and R. Vezzani. ―Probabilistic posture classification for human behaviour analysis‖. IEEE Transactions on Systems, Man, and Cybernetics, Part A: Systems and Humans, 35(1):42–54, Jan. 2005.

[CTB04] Cameron, M. A., Taylor, K. L. and Baxter, R. ―Web-Service Composition and Record Linking VLDB Workshop on Information Integration on the Web‖ (IIWeb-2004) Toronto, Canada, 2004.

[DBT00] Dorigo, M., Bonabeau, E., and Theraulaz, G. ―Ant algorithms and stigmergy‖, Future Generation Computer Systems, 16 (2000) 851 – 871.


D5.4


of 91

[DGY05] Dragan, F., Gardarin, G. and Yeh, L. ―MediaPeer: a safe, scalable P2P architecture for XML query processing, Database and Expert Systems Applications‖, Proceedings. Sixteenth International Workshop on, 22-26 Aug. 2005, pp. 368- 373.

[DMG05] D. M. Gavrila. ―The visual analysis of human movement: A survey‖. Computer Vision and Image Understanding, 73(1):82–98, Jan 1999.

[DP03] R. W. DeVaul and S. Pentland. ―The mithril real-time context engine and activity classification.‖ Technical Report, MIT Media Lab, 2003.

[Fu99] Fu, L. ―Knowledge Discovery based on Neural Networks‖, Communications of the ACM, 42 (11) (1999) 47 - 50.

[GBMN07a] Greer, K., Baumgarten, M., Mulvenna, M., Curran, K., and Nugent, C. ―Autonomic Supervision of Stigmergic Self-Organisation for Distributed Information Retrieval‖, Workshop on Technologies for Situated and Autonomic Communications (SAC), at 2nd International Conference on Bio-Inspired Models of Network, Information, and Computing Systems, BIONETICS 2007, December 10-13, Budapest, Hungary, (2007a).

[GBMN07b] Greer, K., Baumgarten, M., Mulvenna, M., Nugent, C and Curran, K.. ―Knowledge-Based Reasoning through Stigmergic Linking‖, International Workshop on Self-Organising Systems IWSOS‘07, 11 -13 September, Lecture Notes in Computer Science (LNCS), Eds. David Hutchison and Randy H. Katz, Vol. 4725, 2007b, pp. 240 – 254, Springer-Verlag.

[Gra59] Grassé P.P. « La reconstruction dun id et les coordinations internidividuelles chez Bellicositermes natalensis et Cubitermes sp. », La théorie de la stigmergie: essais d‘interprétation du comportment des termites constructeurs, Insectes Sociaux, 6 (1959) 41-84.

[HeBo02] Heylighen, F. and Bollen, J. Hebbian, « Algorithms for a Digital Library Recommendation System », Proceedings of the International Conference on Parallel Processing Workshops (ICPPW‘02), 2002, pp. 439-.

[HFR06] A. Hilton, P. Fua, and R. Ronfard. ―Foreword: Special issue on modeling people: Vision-based understanding of a persons' shape, appearance, movement, and behaviour‖. Computer Vision and Image Understanding, 104(2-3):87–89, 2006.

[Jos02] Joseph S. NeuroGrid: ―Semantically Routing Queries in Peer-to-Peer Networks‖. In Proceedings of the International Workshop on Peer-to-Peer Computing (co-located with Networking 2002), Pisa, Italy, May 2002.

[KIH07] I. Kim, S. Im, E. Hong, S. Ahn, and H. Kim. „Adl classification using triaxial accelerometers and rfid‖. In International Conference on Ubiquitous Computing Convergence Technology. Beijing, China, 2007.

[KPP+05] Koloniari, G., Petrakis, Y., Pitoura, E., and Tsotsos, T. ―Query workload-aware overlay construction using histograms‖, Proceedings of the 14th ACM International Conference on Information and Knowledge Management, 2005, pp. 640 – 647.

[MBL+06] Mano, J-P., Bourjot, C., Lopardo, G. and Glize, P. ―Bio-inspired Mechanisms for Artificial Self-organised Systems‖, Informatica, Vol. 30, 2006, pp. 55 - 62.

[MeMi04] Melcher, B., Mitchell, B. (2004). ―Towards An Autonomic Framework: Self-Configuring Network Services and Developing Autonomic Applications‖. Intel Technology Journal, Vol. 8., No. 4, 2004.

[MMTZ06] Mamei M., Menezes R.,Tolksdorf R., and ambonelli F. ―Case studies for self-organization in computer science‖. Journal of Systems Architecture, 52(8-9):443–460, 2006

[MPG06a] Michlmayr, E., Pany, A., and Graf, S. ―Applying Ant-based Multi-Agent Systems to Query Routing in Distributed Environments‖, in Proceedings of the 3rd IEEE Conference On Intelligent Systems (IEEE IS06), September 2006a.

http://ieeexplore.ieee.org/search/searchresult.jsp?disp=cit&queryText=(dragan%20%20f.%3cIN%3eau)&valnm=Dragan%2C+F.&reqloc%20=others&history=yes

http://ieeexplore.ieee.org/search/searchresult.jsp?disp=cit&queryText=(%20gardarin%20%20g.%3cIN%3eau)&valnm=+Gardarin%2C+G.&reqloc%20=others&history=yes

http://ieeexplore.ieee.org/search/searchresult.jsp?disp=cit&queryText=(%20yeh%20%20l.%3cIN%3eau)&valnm=+Yeh%2C+L.&reqloc%20=others&history=yes

http://ieeexplore.ieee.org/xpl/RecentCon.jsp?punumber=10080

http://ieeexplore.ieee.org/xpl/RecentCon.jsp?punumber=10080


D5.4


of 91

[MPG06b] Michlmayr, E., Pany, A., Kappel, G. ―Using Taxonomies for Content-based Routing with Ants‖, 2nd Workshop on Innovations in Web Infrastructure (IWI2006), Co-located with the 15th International World-Wide Web Conference, May 2006b, Edinburgh.

[MW06] Menezes R., Wood A. ―The fading concept in tuple-space systems‖. In Proceedings of the 2006 ACM Symposium on Applied Computing, pages 440–444, Dijon, France, 2006.ACM, ACM Press.

[NS-2_SIM] NS (2006) Network Simulator http://www-nrg.ee.lbl.gov/ns/

[RBS06] Rooney, S., Bauer, D., and Scotton, P., ―Techniques for Integrating Sensors into the Enterprise Network‖. IEEE ETransactions on Network and Service Management, Vol. 2, No. 1, 2006

[RpIn03] Robinson, R. and Indulska, J. ―Superstring: a scalable service discovery protocol for the wide-area pervasive environment‖, Networks, 2003. ICON2003. The 11th IEEE International Conference on, 2003, pp. 699- 704, ISSN: 1531-2216, ISBN: 0-7803-7788-5.

[Par97] Parunak H.V.D. ―‗Go to the Ant‘: Engineering principles from natural agent systems‖. Annals of Operations Research, 75:69–101, 1997.

[RR06] N. Robertson and I. Reid. ―A general method for human activity recognition in video‖. Computer Vision and Image Understanding, 104(2-3):232–248, 2006.

[RWL+06] Raschid, L., Wu, Y., Lee, W., Vidal, M., Tsaparas, P., Srinivasan, P., and Kumar Sehgal A. ―Ranking Target Objects of Navigational Queries‖, 8th ACM International Workshop on Web Information and Data Management WIDM ‘06, 2006, pp. 27 – 34.

[SMGC04] Sartiani, C., Manghi, P., Ghelli, G. and Conforti, G. XPeer, ―A Self-organising XML p2p Database System‖, http://www.di.unipi.it/~ghelli/papers/SarManGhe04-p2pdb.pdf, 2004.

[VRM04] Vidal, M., Raschid, L. and Mestre, J. ―Challenges in Selecting Paths for Navigational Queries: Trade-off of Benefit of Path versus Cost of Plan‖, Seventh International Workshop on the Web and Databases (WebDB 2004), 2004, pp. 61 – 66.

[WLT06] J. Ward, P. Lukowicz, G. Troster, and T. Starner. ―Activity recognition of assembly tasks using body-worn microphones and accelerometers‖. IEEE Transactions on Pattern Analysis and Machine Intelligence, 28(10):1553 – 1567, 2006.

1.3 Document History

Version Date Authors Comment

0 04/11/2007 FZ Document Created and draft ToC sketched

1 13/12/2008 All partners All contributions received and integrated

2 18/12/2008 FZ Document harmonized & checked

http://www-nrg.ee.lbl.gov/ns/


D5.4


of 91

2 Knowledge Networks: Summary of Key Goals and Achievements

The effective design and execution of autonomic services requires leveraging assessed models of simple context-awareness, in which services are given access to isolated pieces of contextual data, to a model of ―situation-awareness‖, in which services are given access to properly elaborated and organized information representing, in much more expressive (yet simple to be exploited) ways, comprehensive knowledge related to a ―situation‖.

The idea of ―knowledge networks‖, key subjects of investigation in WP5, has the goal of identifying models and tools to analyze and organize pieces of contextual information (i.e., knowledge atoms) into sorts of structured collections (i.e., knowledge networks) of related knowledge items, so as to support application and services in reaching high-levels of awareness about the surrounding situations, and eventually become highly adaptable and autonomic.

2.1 Overall Summary of WP5 Achievements over the 3 Years During the first year of the project (year 2006), WP5 completed the investigation of the state of the art; identified the set of structural knowledge network specifications and released and alpha software for knowledge networks (in the following of this deliverable simply KNs); extensively studied and experimented with advanced self-organizing mechanisms for knowledge aggregation along the spatial dimension. All of these are discussed in detail in [D5.1].

The specific goals for the second year of the project (year 2007), were instead focused at: advancing implementation work by producing a beta software for KNs and at subsequently porting it into an ACE-based implementation; at investigating both algorithms for knowledge aggregation and management along the spatial and semantic dimension other than the spatial one, and mechanisms for advanced knowledge querying; at studying and putting at work for detecting and managing inconsistent situations in KNs. All of these are discussed in detail in [D5.2] and [D5.3].

Finally the goals for the third year of the project (year 2008) were mainly focused at finalizing the ACE-based implementation of the knowledge networks software. In particular, in developing, from previous investigations about knowledge aggregation and management, additional components delegated to knowledge caching, and knowledge aggregation have been produced, the components for knowledge consistency verification have been integrated in the software, and the overall ACE-based implementation of KNs have been improved and finalized. Also, analysis of KNs software performances have been performed in a distributed testbed. From the more scientific viewpoints, concepts related to knowledge overflow management, management of data coming from heterogeneous sensors and extraction of data from them, and concepts of stigmergic knowledge querying and cognitive stigmergy, have been extensively analysed and experiments (although not fully integrated in the software toolkit).

Overall, the results of WP5 are in line with those foreseen in the project planning.

2.2 Summary of WP5 Achievements for the 3rd Year Let us overview more in detail the specific results of WP5 for year 2008, all of which extensively described in this deliverable.


D5.4


of 91

Concerning the implementation and the experimentation of the ACE-based knowledge network toolkit.

Continuing the implementation of additional components for the knowledge networks toolkit. Several components devoted to ease the data access from motes sensor boards and for realising different mechanisms of knowledge aggregation have been finalized and integrated in the main toolkit. Moreover, building on the results coming from prior investigations about knowledge aggregation, and management have been developed and integrated in the toolkit. Assessing, evaluating and integrating the W4 data model into the knowledge networks toolkit. In this way, the effective model of data representation studied in general terms in WP5 has become an integrated part of the toolkit, as indeed planned. Integrating the algorithms and tools for knowledge consistency verification studied in the previous years in the KNs toolkit. This activity also included developing proper demo examples to verify their effectiveness.

Studying and implementing strategies and mechanisms for management of distributed knowledge and distributed KNs. To this end, a flexible mechanism of knowledge caching have been provided in the toolkit to speed up knowledge access in distributed settings, and novel mechanisms to enable cross-querying across distributed and independent have been enabled to facilitate access to distributed knowledge sources. Performing detailed performance evaluation studies on the behaviour of the knowledge networks toolkit in distributed environment. To this end, we have involved several of the CASCADAS partners by asking them to locally run at their sites instances of KNs and by performing a set of distributed querying session. Concerning scientific and algorithmic studies of various aspects of KNs. Studying innovative algorithms for handling the problem of knowledge overflow. In particular, based on the W4 model, and its associated knowledge extraction methods, we measured the production rate of W4 knowledge atoms when the KN tries to correlate them. We also defined novel mechanisms to constrain/steer this production rate. Finally all the outcomes have been integrated into the KN software and several examples of W4-based algorithmic components have been defined and implemented. Investigating algorithms for self-learning based on redundant ad heterogeneous sensors (sensor networks and camera data flow into the KN and report on the same phenomena from different viewpoint; this can enable to extract higher-level knowledge from such redundancy). A multi-modal distributed classification system able to extract high-level context information by combining different sensors (body-worn accelerometers and smart cameras) has been implemented. Advanced algorithms for situation recognition have been studied and experimented. Continuing and extending the study of advanced mechanisms for stigmergic knowledge querying. These algorithms aims gets inspirations from swarm intelligence principles and, by linking knowledge components with each other based on the patterns of knowledge access, aims at enabling a sort of indirect communication among services that can facilitate


D5.4


of 91

and improve access to knowledge. Also, such studies have been the starting point of a more general study related to the concept of cognitive stigmergy. It is worth outlining that all the above activities, and specifically those related to the implementation of the KNs toolkit, have been carried on via a strict cooperation and coordination among all the WP5 partners.

2.3 Joint activities with other WPs WP5 has always worked in cooperation with WP1 over the three years of the project to ensure the full and fruitful interoperability of the mechanisms and tools developed by these WPs. In any case, the most tangible results of this cooperation are in a set of features that have been integrated in the ACE toolkit based on feedbacks from WP5 and extensively exploited in the KNs toolkit. In particular:

ACE parameterisation. Knowledge Networks consist of a multitude of similar ACEs like KN ACEs, Knowledge Atoms or Knowledge Containers. Individual instances of these ACEs differ only slightly in terms of GNs, GAs or KN to contact. Nevertheless, all KAs for example belong to the same ACE type (KA ACE) and the same applies for all other components of a KN. In order to improve the reusability of KN ACEs WP1 enabled to equip ACEs with initial parameters, like GN, GA or other variables, that can be defined in an application‘s aces.xml. Endowed with the ACE parameterisation feature, users can now utilise the general types of KN ACEs and specialise them by adding individual parameters. The following example illustrates the value gained by ACE parameterisation. A user wants to establish three KNs, each represented by a KN ACE that can achieve an individual GA. The GA of the first KN is ―KN_weather_Britain‖ the GA of the second KN is ―KN_weather_Italy‖ and the GA of the third KN is ―KN_weather_Germany‖. Without ACE parameterisation three different kinds of ACEs would have been necessary. Using parameters, one and the same ACE type (KN ACE) can be instantiated three times by equipping each instance with a dedicated GA within the aces.xml file of the concerned application.

Parallel plans. Discussions among WP1, WP5, and other WPs led to the conclusion that a facility to separate parts of the behaviour of ACEs would add notable value to the ACE Toolkit. In consequence, WP1 developed the concept of parallel plans. WP5 exploited this concept in various ways. The KN ACE, for example, utilizes parallel plans to separate its multiple tasks like serving contracts, registering KAs or processing queries. The Context Verifier ACE applies parallel plans to control multiple requests for context verification and to ensure correct separation and resetting of data. Users of the KN Toolkit are equipped with template plans which can be included in any other ACEs Self-Model to, for example, publish knowledge within the KN or to contract and query a KN without interfering with the actual tasks an ACE has to fulfil. In consequence, the parallel plan feature provided by WP1 increases code modularisation as well as reusability, and eases for ACE developers the access to KNs in general.

Dynamic contract modification. In order to enable migration, which WP5 and other WPs requested from WP1, a mechanism to dynamically modify contracts was introduced. This enables changing the addresses, reassigning the roles of a contract, and notifying all involved ACES. In terms of KNs, that new feature opens up the opportunity to create knowledge groups where such a knowledge group consists of a dedicated number of ACEs which share a contract. By establishing knowledge groups, it can be ensured that information is distributed only among a limited number


D5.4


of 91

of participating contract partners. Furthermore, the group members are not fixed but can be dynamically modified, which means that participating ACEs can be exchanged. The concept of knowledge groups has not yet been exploited to a large extend. At the moment, this is just a theoretical idea where we see further research potential within the scope of KNs.

In cooperation with WP2 a specific supervision mechanism has been implemented into the KN toolkit extension that supervises the availability of knowledge networks components. This functionality ensures that the KN structures remain stable over time and that components that have become unavailable will be removed from the network also unregistering all references thereof. This functionality has been implemented as a specific service and has been realised as a distinct plan that is available in each KNetwork ACE. For this functionality to work properly, supervised components have to expose KN related interfaces such as the KAtom interface. In particular, the ―isAlive‖ method has to be exposed which is the method relevant for this feature. If not implemented, then a component cannot respond to a supervision request and as such, after a timeout event has been triggered, will be removed from the KNetwork component that acts as the supervisor.

With regard to the cooperation with WP6, these have mainly constituted in agreeing upon a set of functionalities that WP5 should have been provided to WP6 to support the proper implementation of the application demonstrator and to show, within the demonstrator, the power of the KNs toolkit. This ended up in the implementation of knowledge network components capable of gathering data form RFID tags, and making these available through different organisations (knowledge views).

Cooperations with WP3 and WP4 have been mostly of an informative nature, aimed at ensuring the full integrability of the self-organization algorithms of WP3 and of the security solutions of WP4 with the knowledge networks concepts and implementations. It is in any case worth mentioning that intensive discussions have taken place between WP3 and WP5 with regard to the possibility of exploiting some of the knowledge aggregation algorithms studied in WP5 in the context of WP3, and viceversa.

3 Knowledge Networks Extensions for the ACE Toolkit In this part of the document we describe the overall architecture of the implemented ACE-based KNs toolkit, with a particular focus on the additional features that have been integrated in the toolkit since its M24 release.

3.1 Status of the Toolkit at M24 and New Features Added The overall architecture of the implemented ACE-based KNs toolkit as it was released at M24 is shown in Figure 1, and it was already extensively described in [D5.1].

The new release of the KNs toolkit embeds a number of additional features and components that aims at improving the overall usability and flexibility of the toolkit and its effectiveness in handling distributed knowledge management. In addition, extensions to the knowledge networks toolkit have aimed at integrating the W4 model in it and related knowledge aggregation algorithm, as well as at more tightly integrating the knowledge consistency verificator. In Figure 2 we have tried to graphically summarize – by using the M24 release as a reference – the key extensions that have been made to the KNs toolkit during the period M25-M36.


D5.4


of 91

Figure 1: The M24 Architecture of the Knowledge Networks Toolkit

In a nutshell (see also Figure 2), the extensions that have been made and that are described in detail in the following of this section include:

The possibility of parameterise all components, there include the parameterisation of the GN/GA protocols, which adds notable flexibility to the overall toolkit

The extension of the querying mechanism to allow for cross-querying across distributed instances of the knowledge networks, which enables higher degrees of distribution in knowledge networks.

The integration of a transparent caching mechanism for knowledge atoms, which allows for queries relating distributed knowledge atoms to be performed much effectively.

The integration of a mechanism, borrowed from WP2, to supervise the liveness of knowledge networks components.

The integration of the W4 model into the KNs toolkit and the implementation of several aggregator components to elaborate data according to such model. Overall, this makes it possible to exploit the potentials of the W4 model into the KNs toolkit.

The full integration of the context verificator component into the KNs toolkit, which enable to perform in a single query actions both the access to knowledge and the verification of its consistency.

In addition (which cannot be appreciated from Figure 2) some improvements have been made to the Graphical User Interface of the toolkit, to make it more usable and to make it possible to access to the new features.


D5.4


of 91

Figure 2: The M36 Extensions of the Knowledge Networks Toolkit

3.2 Components of the Toolkit: an Updated Overview This Section provides a short summary of all components of the knowledge network extension of the ACE toolkit. Although most of these components were already present in the M24 release, the possibility that we have added to parameterize the components of the knowledge network has enabled add a bit more flexibility in these components too, other than in the new ones added. Also, configuration parameter can be used to initialise the components and to specify respective GN/GAs.

KNetwork Component

The KNetwork ACE is the core component of the knowledge network as it (a) provides a means for knowledge sources to register with; (b) a generic interface to query the KN for knowledge, (c) for semantic based self-organisation of KN components and (d) allows to host functionality related to supervision and ACE communication. It is a specific implementation of the knowledge container component which provides for a, b and c. As depicted in Figure 3, it embraces six individual plans to provide various functionality for the operation of the KNetwork itself and for the interface to other ACEs.


D5.4


of 91

Figure 3: KNetwork Selfmodel

Given the fact that it is now possible to parameterise the components, to configure a KNetwork ACE within the ACE world the following has to be included in the ACE configuration file (see WP1 on how to start ACEs).

<ace name="[Network ID]" type="[Location of the ace-type.xml file]"> <param id="registerGUI" type="boolean">True</param> <param id="GA" type="java.lang.String">KNetwork.KNetwork1</param> <param id="BUFFERSIZE" type="java.lang.String">20</param> <param id="USE_CACHE" type="java.lang.String">True</param> </ace>

The parameters to be specified include the Network ID and the location of the ace-type.xml file which include the location of the selfmodel and the specific functionality available for this component. In addition to this the following parameters are available to configure the component itself:

o registerGUI: Allows to specify the display of a GUI for this component or not [True | False];

o GA: Specifies the GA this component publishes [String value]; o BUFFERSIZE: Events are send in batches of BUFFERSIZE which can be

specified here (as integer value specified as a String); o USE_CACHE: Enables or disables the caching of knowledge within the

KNetwork component [True | False];

Cross Network Query Service Component

This component allows the querying of any number of KNetwork ACEs depending on the GN/GA configuration of either component.

<ace name="[CNQ Service ID]" type="[Location of the ace-type.xml file]"> <param id="registerGUI" type="boolean">true</param> <param id="GN" type="java.lang.String">KNetwork</param> <param id="GA" type="java.lang.String">KNQService</param> </ace>

Except for the ID and the ace-type.xml file it allows the specification of a GN that corresponds to the KNetwork‘s to be queried, a GA specifying the service provided and the possibility to display or hide a GUI for this component.


D5.4


of 91

AtomRepository Component

Within the context of the knowledge network, generic knowledge access is achieved either via specific Atom ACEs or alternatively via the knowledge repository, which is a dedicated component provided in order to easy the access to legacy systems as well as to low level sensor access for which individual ACE implementations would be to heavyweight. Simplified an AtomRepository is an ACE which hosts specific java based realisations of type Atom. Publishing a specialisation of the Atom interface it allows passing an identification parameter that uniquely addresses a single atom within the repository on which a given method call is executed. Internally, specific functionality may be executed that lies within or outside the scope of knowledge networks or the overall ACE toolkit, respectively. Thus registered atoms can be handled in the same way as full Atom ACE implementations. Details on how to create and register specific atom realisations have been discussed in previous deliverables.

<ace name="[AtomRepo Service ID]" type="[Location of the ace-type.xml file]"> <param id="registerGUI" type="boolean">true</param> <param id="GN" type="java.lang.String">KNetwork001</param> <param id="BUFFERSIZE" type="java.lang.String">20</param> </ace>

Except for the ID and the ace-type.xml file it allows the specification of a GN that corresponds to the KNetwork this repository is attached too and to which atoms will be registered too. In addition, as far as configuration is concerned, the component can now made it possible specify the BUFFERSIZE that limits the number of interactions with other KN components the possibility to display or hide a GUI for this component.

ContextVerifier Component and Extended User Interface

Although the ContextVerifier component has not substantially changed over the previous M24 release, the component is now completely integrated in the toolkit, in that it can be automatically queried when a query is submitted to the knowledge networks, and it can automatically enrich the knowledge network answer with the indication of whether or not the answer is consistent.

Aggregator Component

A larger number of aggregator components have been integrated, to manage and aggregate data according to the aggregation mechanisms made it possible by the W4 model of contextual data.

KAtom Interface Component

As detailed in previous deliverables, other ACEs can use the Atom interface in order to publish knowledge into the scope of the knowledge network. In fact it is a means to allow generic access to knowledge from within the knowledge network and from outside. The interface is realised as a distinct plan to be easily incorporated by other ACEs. The new release makes it possible for atom to model data accordingly to the W4 model.


D5.4


of 91

User Interface Component

Similar to the Atom interface the user or query interface can be implemented by other ACEs to query the knowledge network for knowledge. The complete interface is provided through the examples published as part of the final release, and it has been extended to reflect (and access to) the new features added.

3.3 Major Extensions and Design Modifications

This Section details the major extensions and design modifications implemented since the M24 release. In addition to this work the overall KNs toolkit was revised constantly to accommodate for modifications and extensions to the underlying ACE toolkit, user requests and toolkit instabilities. However, until stated otherwise, specifications and interfaces of individual components still holds as outlined in previous deliverables.

3.3.1 Cross Network Query Service (CNQ Service) The knowledge retrieval mechanism implemented within the KNs toolkit extension is based on a semantic based querying mechanism that utilises the semantic descriptions provided through the KAtom interface. While the KNetwork component organises KAtoms according to their individual descriptions the query service utilises the same set of information to identify and extract desired knowledge from the network. This further underlines the concept of the knowledge network to act as a middle-layer between knowledge providers and knowledge users that not only optimises the access to knowledge but also extracts new knowledge which is in again published into the scope of the knowledge network. This mechanism however, is transparent to the user which, if desired, could also directly access the knowledge sources. The first prototype as released in M24 included only a limited querying mechanism that only allowed querying a single KNetwork ACE at a time. For obvious reason such a limited service is not sufficient as knowledge can be distributed over any number of KNetwork ACEs. In addition the querying of specific sub-network that may include any number of KNetwork ACEs was a requirement from the outset. In order to provide this functionality a dedicated cross network query service has been devised that provides a mechanism (a) to be specifically targeted towards individual groups of ACEs as organised through their GA (see GN/GA – KNetwork Visibility within the ACE World) and (b) relay a query to any number of KNetwork ACEs, collecting their responses and merging them before returning the reply to the user that has initiated the query.

Figure 4: Cross Network Querying Service


D5.4


of 91

The schematic workflow of this service is depicted in Figure 4. As can be seen a user or application ACE may query the CNQ service which has been implemented as a distinct ACE. Moreover, the query interface exposed by this service is identical to the query interface exposed by the KNetwork ACE. Thus the process of querying individual KNetwork ACEs directly or via the CNQ is identical. Depending on configuration, the CNQ service sends out a GN targeting only those KNetwork ACEs that belong to the sub-network it wants to query. Note that if a GN is used that reflects a GA that is shared by all KNetwork ACEs than the knowledge network as a whole will be queried. Alternatively, the CNQ service will also pick up GN‘s of KNetwork ACEs that are send at any time registering them to the set of ACEs to be queried. Once started the CNQ will wait until queried after which it will relay the query to all registered KNetwork ACEs. It will subsequently wait for a response from each of the networks and after all responses have been retrieved the service will merge them into a single result set which is send to the user that has initiated the query. Duplicates, if exist, will be removed from the result. To improve system resilience, a timeout mechanism has been implemented to safeguard that the service is able to reply to the user ACE even if not all KNetwork ACEs respond to the query request. Thus, the service can be guaranteed even if single KNetwork ACE becomes temporarily unavailable.

3.3.2 Concurrent Querying Mechanisms One of the original objectives for the KN toolkit extension was to generate new knowledge from within the network itself to be utilised again either outside or again to generate more knowledge. With respect to the KN architecture this translates directly into the requirement that an ACE can be both, a knowledge consumer as well as a knowledge provider. In order to achieve this an ACE simply needs to expose both of the interfaces as specified in [D5.3]. However, for this philosophy to work each KNetwork ACE must be able to operate fully asynchronous as it needs to handle nested queries. For instance, a dedicated aggregator component may wants to provide the mean temperature of a certain region, e.g. Italy. To do so when queried it needs to send a query itself to the network requesting all sources that provide a temperature reading of places within the geographical region of Italy. Once received it could calculate the mean value of all sources, which would relate to the mean temperature in Italy. Note that for simplicity we assume that there is only a single KNetwork available to which all KAtoms are registered.

Figure 5: Concurrent Querying Problem


D5.4


of 91

The required components and the associated workflow with respect to querying for the avg. temperature of Italy are depicted in Figure 5. Query 1 reflects the request for the avg. temperature and query 2 requests the actual readings from the sensor ACEs while the aggregator ACE provides the functionality to calculate the means value also publishing the avg. temperature via the KAtom Interface. The workflow can be summarised as follow:

Step 1: User ACE sends query 1 to Network ACE (e.g. Average Temperature Italy); Step 2: Network ACE determines that the KA0 can provide the knowledge desired and

calls the ‗getValue‘ method on this component (KAtom interface); Step 3: KA0 requires information from the Network and send query 2

(e.g. Temperature Italy); Step 4: Network ACE determines that KAx with x > 0 do provide such information and

calls the ‗getValue‘ method on these componets; Step 5: All KAx with x > 0 that have received the request reply by providing the

information they serve; Step 6: The Network ACE collects the replies from all KAx with x > 0 and forwards

them to KA0; Step 7: Query 2 is complete; Step 8: After having received the desired information KA0 calculates the mean values

of all readings received (the number of atoms responding to the request is obviously dynamic) and provides this via its own atom interface to the Network ACE as a reply to Step 2;

Step 9: The Network ACE receives the reply of KA0 and forwards it to the User ACE in reply to query 1.

Step 10: Query 1 is complete;

The key aspect here is that query 1 initiates the first request from the KNetwork as it reflects the knowledge desired by the user. As such it is queued to be processed before query 2 is even send out. However, in order to be processed query 2, once it has been sent, has to be processed before query 1 can be finalised. This concept, referred to as nested queries, can exist to various depths and may or may not result in a deadlock of the processing system depending on the number of components involved and the type of processing itself. This problem is particular hazardous for systems that (a) operate solely sequential, (b) where the complexity of the query cannot be fully resolved and (c) where resources need to be locked to avoid data inconsistencies. In short it is a problem for the knowledge network architecture or at least for the release at M24 which did operate in a sequential fashion. In a nutshell, the M24 release was based on the principle that the result of a query was returned by the function that did sent the query to the KNetwork. Thus blocking the scope of execution until the query process was complete. This problem was been resolved in the second prototype released in M30. For that two plans have been incorporated in the selfmodel that allow concurrent processing of queries independent of their depth and complexity following the above workflow. In addition, both the query interface and the atom interface have been updated as required and new templates have been provided. Furthermore, an example aggregator ACE has been implemented that indeed calculates the mean value and if used within the context of the weather example does provide the average temperature of a certain geographical region to be specified by the user.

3.3.3 ACE Parameterisation A recent extension provided by WP1 is the possibility to pass parameter to ACE‘s within the ace configuration par of the toolkit (please see WP1 from more details on this feature). The KN toolkit takes full advantage of this feature and for that all components have been


D5.4


of 91

modified to take relevant configuration parameters from the configuration file as specified in Section Components – Overview. Note that in the previous version configuration parameters were provided from within the selfmodel such that a separate selfmodel had to be created for each ACE component to be deployed. This is no longer required for the current version. In fact only a single selfmodel implementation is needed / provided which can be deployed and configured via the ACE configuration file (see WP1 documentation on the ACE configuration file). This latest feature has eased the deployment of ACEs dramatically and is regarded as one of the most useful extensions to the ACE toolkit.

3.3.4 GUI Optimisations The GUI of the two main KN components (KNetwork and the Atom Repository) have been introduced in [D5.3]. Since then several optimisation and extensions have been incorporated which are summarised in this Section:

KNetwork (see Figure 6): o Revising the underlying jittering algorithm as well as the general paint

methodology has optimised the general runtime performance of the KNetwork GUI. The results are directly visible in a way that more objects can be displayed within a single instance.

o A context menu has been added that allows to stop / resume the animation and to remove components at runtime.

o Another slide bar has been implemented that allows manipulating the distraction force between objects displayed.

o Toggle the display of Atom nodes from the context menu to reduce the number of displayed objects.

Figure 6: KNetwork GUI

Atom Repository (see Figure 7) o Functionality has been added to simulate the disabling of atoms at runtime.


D5.4


of 91

o Functionality has been added to dynamically load randomly generated test Atoms.

o Functionality has been added to remove Atom selected in the Atom Tree o Functionality has been added to explore the structure, content and operation

of Atoms from within the Atom Repository Explorer Tree.

Figure 7: Atom Repository GUI

Ace Explorer (see Figure 8): o A specific panel has been added that lists all registered ACE‘s. Note that this

has been added as part of the WP5 activity and is currently only used by ACE‘s that are part of the KN Toolkit.

Figure 8: ACE Explorer Panel

3.3.5 GN/GA – KNetwork Visibility within the ACE World As originally envisioned, the KN toolkit is an extension to the Cascadas ACE toolkit with the objective to provide useful and pre-organised knowledge. Realised through the concept of ACE‘s it takes maximum advantage of the functionalities provided by them. Strictly speaking, a knowledge network is build upon two components; (a) Knowledge Atoms, which are an abstract concept that allows other ACE‘s to publish knowledge into the scope of a knowledge network; (b) knowledge containers, which organise knowledge semantically. Within the ACE world, any ACE implementation may publish knowledge into the scope of the knowledge network or may query the knowledge network as a whole or any part thereof for knowledge. Thus, a knowledge network is a service that is available to all other ACE‘s independent if they are application, system or service ACE‘s and, most importantly, including the knowledge network itself.


D5.4


of 91

Figure 9: GN/GA Framework

In order to access and to structure individual KNetwork ACE‘s within the global and distributed ACE world the KN toolkit takes advantage of the GN/GA discovery model provided by the ACE toolkit. As depicted in Figure 9, they are two conceptually different ways of structuring / utilising knowledge networks: publicly or privately

Public Knowledge Networks: All components and the knowledge they embrace is publicly available and as such may be accessed by all ACE‘s. For that the identifier to register / query the network is standardised and shared by all components. For instance, if the GA of all KNetwork ACE‘s starts with ―KNetwork‖ then of these ACE‘s can be discovered and accessed by sending a GN request using the same identifier.

Private Knowledge Networks: Network components are distinct at an individual or group level. For that, only the stakeholders that utilise these components know relevant identifiers to register or query such a ―private‖ part of the network. Although not compulsory it is recommended that, for maintenance purposes, at least one shared identifier is always used by all knowledge network component.

As defined by WP1, the communication between ACE‘s is contract based utilising the GN/GA protocol as a means of identification. Consequently, the identification of knowledge network components is based entirely on the GN/GA protocol and as such depends on the configuration of each component (see ACE parameterisation). To efficiently, construct flexible knowledge structures the following dot delimited structure is proposed for public knowledge networks. For the construction of private knowledge networks a user may feel free to use a similar format but, obviously, different identifiers.

KNetwork[.Sub-Network identifier].[Specific UUID]

The proposed format as depicted above is structured as follows. First, the term ―KNetwork‖ is used to associate a given component with the knowledge network as a whole. Secondly, any number of identifiers may be used subsequently to specify groups of KN components at various levels of granularity, which from a structural point of view translate into networks of networks. Finally a component specific UUID may be used to uniquely identify a particular component (KA or KC). As depicted in Figure 10, complex relations can be established between any KNetwork components that result in hierarchical or network like organisations that are ideal for publishing / accessing knowledge at various granular levels. Although not yet implemented, these relations can also be used to control the physical hosting of


D5.4


of 91

KNetwork ACE groups. For instance, ACE‘s that belong to the same sub-network could be hosted ―close‖ together to improve communication among them.

Figure 10: Hierarchical Organisation of Knowledge Network Components

Using the above structure within the GN/GA protocol enables to register components to (a) specific container components (ACE‘s), (b) specific knowledge sub-nets or (c) to the knowledge network as a whole. Querying can be performed at similar levels and as such queries can be specifically targeted at certain parts of the network or to a private sub-network. This concept also provides a flexible means of distributing knowledge among any number of KNetwork components that make up a given sub-network. For instance, if a GN is send out that can be acknowledged by a number of KNetwork ACEs (e.g. an KAtom ACE wants to register with a particular sub-network) then only the KNetwork that replies first will be used. In turn, networks with little workload, close physical proximity together with high and uncongested communication lines are likely to respond faster than other. Thus the network and any sub-part thereof would, to a certain degree, manage its workload autonomically based on the response agility of other related components. Although this seems to be just a beneficial side effect of the GN/GA protocol it can be further controlled through the internal logic each ACE provides. E.g. if an ACE recognises, either internally or through dedicated WP2 based supervision, that it has a high workload than certain services such as the GA relevant to the registration of new KAtom components can be suspended or delayed. Thus, preference would be given to other components, which have a lower workload yet overall functionality would be maintained.

3.3.6 Liveliness Supervision of KN Components In collaboration with WP2 a dedicated supervision service has been implemented as an autonomous service within the Knowledge Network toolkit extension. The objective of this service is to remove components from the scope of a knowledge network ACE that are no longer available or are otherwise unable to serve the purpose / knowledge they have been


D5.4


of 91

designed for. Taking advantage of the ACE specific functionality extension mechanism a specific interface has been specified which needs to be incorporated by all KNetwork components (KAtoms and KContainers). This function consists simply of an isAlive method that will be called randomly from KNetwork ACE‘s the component is registered with. If the component returns false or does not return within a given time then it will be removed from the network component, which in turn updates all its internal references to this component. This allows each component to utilise its own self-testing mechanisms to be used to determine the functional correctness of the component yet also allowing for components that are unable to respond at all. This workflow has been schematically depicted in Figure 11 where the respective plan of the selfmodel is also given in an abstract format.

Figure 11: KN Component Supervision - Liveliness

The above plan is an integral part of each KNetwork ACE component and is implemented to operate as a background service. In order to validate this functionality a specific demonstrator has been developed which is discussed in more detail in [D2.5].

3.3.7 Knowledge Distribution and Caching Knowledge access is by default distributed based on the concepts discussed in Section ―GN/GA – KNetwork Visibility within the ACE World‖. However since the concept of knowledge networks is reference-based, the actual data that represents the knowledge is not distributed. In other words, knowledge access points are redundantly available in a distributed fashion depending on the structure of the underlying knowledge network but the data itself only exist within the atom representation of the knowledge source. That is in a single instance. For reasons of performance and resilience it may be beneficial if the data itself is replicated or cached within the reference architecture of the network. While this would lead to a more heavyweight implementation of the knowledge network it would improve the operation thereof by (a) optimising response times by preloading / caching atom values; and (b) improve the distribution and availability of knowledge throughout the network.

The former is of particular interest to atoms that rely on knowledge from within the network, which implies the execution of nested queries which are often time consuming thus resulting in slow response times. For instance, considering an aggregator atom that has to query the network for knowledge from which it calculates e.g. the mean value to be provided as a new form of knowledge into the network. In some cases the number of atoms responding to the aggregator component can be quite large which would increase the response time of the aggregator component accordingly. If caching is used and a timeout configured at e.g. 1


D5.4


of 91

seconds then the aggregator component would automatically reload it‘s ―knowledge‖ at the selected interval. If queried, the aggregator component could reply immediately with the

value that is locally cached which in turn has a freshness factor of 0 timeout. Obviously, this feature becomes even more relevant if components rely on queries that are nested to levels greater than 1 where slow response times could render a system impractical. The latter, improves the reliability of the overall system by inducing a certain degree of redundancy. For instance, if an atom becomes shortly unavailable due to network problems high workload etc. then the cached value could be used instead. Furthermore, knowledge could be cached at the point of use, which again decreases response times as well as network traffic.

Implementation

In order to address the above a dedicated caching mechanism has been implemented directly into the KNetwork component of the Knowledge Network toolkit extension and except for the timeout parameter to be provided by the knowledge sources requires no further configuration / action.

<Model timeout=‖LONG VALUE‖> <Keywords> <Key Type="Include"></Key> </Keywords> </Model>

Figure 12:Atom Description (getModel Interface)

As shown above, the timeout parameter can be provided by each KAtom via its atom model and is defined to be an attribute by the name ―timeout‖ which is attached to the Model Element of the xml structure returned by the ‗getValue‘ interface that is compulsory for each KAtom. The timeout value itself is optional and if not provided will be set to 0, which means that caching is disabled for this particular atom. Consequently, if this atom is queried a new value will be requested each time. Thus, options that lead to a refresh of a cached knowledge source are defined as follows:

- the value is queried for and has not been retrieved before; - the timeout value is set to 0; - the value has expired which is defined by the difference of the current time and the

time the value has been last set.

The control mechanism that initiates the reload is implemented as a distinct plan within the selfModel of the KNetwork ACE and will be started automatically. The interval for the invocation of this service can be set in the corresponding plan with a default interval of 3 seconds. Note that this plan only initiates the request of the ‗getValue‘ interface of each KAtom registered to the corresponding KNetwork. The response will be processed by a different plan of the selfModel.

Using the Caching Mechanism

The caching mechanism is specific to individual KNetwork ACE instances and is designed to operate in an autonomous fashion. If enabled within the ACE configuration file (see Figure 13) the appropriate plan will be started and caching will be enabled. Values will be refreshed depending on the timeout parameter specified by the underlying knowledge source.

<ace name="KNetwork001" type="conf/aces/KNetwork/ace-type.xml"> <param id="registerGUI" type="boolean">true</param> <param id="GA" type="java.lang.String">KNetwork.KNetwork001</param> <param id="BUFFERSIZE" type="java.lang.String">20</param>


D5.4


of 91

<param id="USE_CACHE" type="java.lang.String">True</param> </ace>

Figure 13: KNetwork Configuration Parameter

A natural extension of the above, which has been partially implemented, is the provision of a freshness factor to the application that has requested the knowledge. Considering the likelihood that knowledge is gathered from a diverse and highly distributed environment and may also, subsequently pre-processed before submitted to a knowledge requester it becomes obvious that a mechanism is required to indicate the freshness of the knowledge provided. That is the time when it has been produced. At its simplest level, such functionality may be provided by publishing knowledge along with a timestamp that refers to the time the knowledge has been generated. Along with the time of retrieval, this relates directly to the freshness a given knowledge entity has at the time of use. This can be used with or without the caching functionality which, if used, would only improve the freshness factor.

<Data atomUUID=‖[Atom Identifier]‖ TimeStamp=‖[time of creation]‖> <Type/> The type of the value published e.g. java.lang.String <Value> The Value itself </Value> </Data>

Figure 14: Updated Atom Interface (getValue) For this, it is proposed to extend the current KA communication interface by extending the XML structure of the ―getValue‖ method as published via the specific functionality of each KA. The extended format is shown in Figure 14 and is optional.

3.4 The W4 Model and Flexible Aggregation The following section explains what are Aggregator Components and how the implementation and the overall integration with the KNs toolkit improved since M24. Several examples of aggregation along spatio-temporal dimensions are also presented.

3.4.1 Aggregator Components’ rationale While the Knowledge Organisation component is capable of pre-organize the whole Knowledge in the System based on provided Keywords, Aggregator Components access Knowledge Atoms in an associative fashion, to self-organize Knowledge along semantic dimensions in order to build specific ―Knowledge Views‖ and to make it possible to obtain specific information on the data currently stored in the view. Multiple Aggregator Components can be run in the same System, each of them embedding a specific aggregation algorithm and therefore capable of building disparate Knowledge Views. The idea behind Aggregator Components work is to get a more concise description of the Knowledge in the Network and also to improve the amount of available Knowledge exploiting hidden linkages between KAs. Aggregator‘s components rationale was already presented in [D5.3]. While the fundamental idea didn‘t change since M24, the implementation and the integration with the overall Knowledge Network Toolkit took advantage of both the toolkit improvements and the integration of research results about the W4 Data Model and Algorithms. Extensions and Modifications are presented in the following section.


D5.4


of 91

3.4.2 Extension and Modification since M24 In the [D5.3] implementation, component‘s required Knowledge Atoms to implement a specific service (and a related plan in the selfmodel) in order to expose their knowledge in an associative way. Once loaded, an Aggregator Components was in charge to gather items contacting itself all interesting KA though GN/GA.

The current implementation aims to fully exploit the improvements in the KNs Toolkit, in particular the improvements in query mechanism and the distribution and caching mechanism. This is reached querying the Knowledge Network to retrieve the data required for the aggregation algorithm instead of the KAs themselves. In this way is no longer necessary for the KAs to expose a specific functionality to be accessed in an associative way, in particular this improves also the overall integration for the toolkit as no specific functionality are required to KAs to be used by Aggregators.

Moreover, during the third year of CASCADAS the W4 Approach (both the Data Model and Algorithms) presented in [D5.3] was integrated in the Knowledge Network Toolkit. This implied the creation of some KAs that embed knowledge organized accordingly to the W4 Model (see Section 3.4.3 for a complete description of those KAs). In order to fully exploit the potentiality of the W4 Approach, W4 inspired algorithms were embedded in Aggregator Components. As a result, Aggregator Components included in the final toolkit release and presented in this document work with W4 Data. However, the Aggregators idea is of general relevance and may be successfully used with different data representation.

This Section summarized the main reason for the modification in the Aggregation behaviour, the definitive implementation of Aggregator Components in presented in Section 3.4.4.

3.4.3 The integration of the W4 Model within the Knowledge Network Toolkit

As already introduced in the previous Section, during the third year of CASCADAS the W4 Approach introduced in [D5.3] was integrated within the Knowledge Network Toolkit. In particular, the Data Model was integrated by some that Knowledge Atoms that organize their knowledge accordingly to the W4 Data Model. Two Knowledge atoms were created: W4Sensor_ACE and W4User_ACE.

In the W4 Model a piece of Knowledge consists of four data fields, which are ―Who‖, ―What‖, ―Where‖, and ―When‖. In term of ACE, this means that the Value elements contains an XML fragment that contains the ―Ws ‖ elements.

W4Sensor_ACE simulates a sensor that exposes its knowledge accordingly to the W4 Model. The Ws fields are dynamically generated every time that the getAtomValue_service is called. In the next Figure the getAtomValue_Service and getModelValue_Services are shown. Suppose that the KA represents a sensor that measures a temperature value. The keywork ―W4‖ in the atom model is of fundament importance to know KAs that expose data accordingly to the W4 Data Model.

<Data> <Type>org.jdom.Element</Type> <Value> <W4> <Who> sensor:12293633213665250</Who> <What> ambient-light:21</What> <Where> (44.687607773816,10.6672599875568)</Where> <When> 15/12/2008 19:6:00 </When> </W4> </Value>


D5.4


of 91

</Data>

Figure 15: getAtomValue_Service Return.

<Atom> <UUID>[The Atoms Identifier]</UUID> <Model> <Keywords> <Keys>W4.Sensor</Keys> </Keywords> </Model> </Atom>

Figure 16: getAtomModel_Service Return.

W4User_ACE simulates a user that exposes its knowledge accordingly to the W4 Model. The Ws fields are dynamically generated every time that the getAtomValue_service is called. In the next Figure the getAtomValue_Service and getModelValue_Services are shown. Suppose that the KA represents a sensor that measures a temperature value.

<Data> <Type>org.jdom.Element</Type> <Value> <W4> <Who> user:12293644222362476</Who> <What> doing:something</What> <Where> (44.6878616446444, 10.6675087473186)Where> <When> 115/12/2008 19:7:54</When> </W4> </Value> </Data>

Figure 17: getAtomValue_Service Return.

<Atom> <UUID>[The Atoms Identifier]</UUID> <Model> <Keywords> <Keys>W4.User</Keys> </Keywords> </Model> </Atom>

Figure 18: getAtomModel_Service Return.

Knowledge Atoms that embeds the W4 Data Model are fully integrated in the Knowledge Network Toolkit, in particular the GUI recognizes the XML structure of the Value of the KA and enables to browse it as shown in Figure 19. Moreover their W4 structure can be fully exploited by Aggregator Components in order to aggregate and manipulate the data based on the Ws fields.


D5.4


of 91

Figure 19: The GUI showing W4 Knowledge Atoms.

3.4.4 The final implementation of Aggregator Components Knowledge Aggregators included in the Knowledge Network Toolkit works with W4 data and exploit the W4 structure in order to build aggregations and views of the data in the network. As Aggregator Components presented in [D5.3], an Aggregator has a private tuple space. In this final release the tuple space used is a ―W4 Tuple Space‖ that is a specific implementation based on [Bal07] capable of working with W4 tuples.

An Aggregator has embedded in its code a W4 representation of the aggregation that wants to perform, and the query that it wants to submit to the Knowledge Network in order to retrieve interesting piece of knowledge to aggregate. Once specified these data, an Aggregator Component works as follow.

Once loaded, the Aggregator sends a query to the Knowledge Network in order to retrieve w4 data to manipulate. The query sent to the Knowledge Network should at least contain the keyword ―W4‖ in order to retrieve data formatted accordingly to the W4 Data Model. Further refinements in the query can reduce the computational cost for the Knowledge Network and the Aggregator itself. E.g., an Aggregator that wants to aggregate data about sensors, should query the Knowledge Network for ―W4 Sensor‖. In this way, the Knowledge Network is in charge to retrieve requested KAs and the cache mechanism and the query improvements can be fully exploited. The retrieved data are then manipulated by the Aggregator that turns the XML fragments in W4 Tuples and fills its private W4 Tuple Space with them. Once the tuple space is fed with new tuples, the specific aggregation algorithm is executed over the tuples and the result is shown in the GUI. This process is performed continuously by the Aggregator Component, in order to pre-organize the aggregation. Figure 20 shows the GUI for an Aggregator Components.


D5.4


of 91

Figure 20: The GUI interface showing the aggregation results.

From the implementation view point a DefaultAggregatorAce has been created. It must be estended in order to create a specific Aggregator. The DefaultAggregatorAce creates an Aggregator_Panel in order to display aggregation results. In the toolkit configuration an Aggregator can be included as follow:

<ace name="[Aggregator ID]" type="[Location of the ace-type.xml file]"> <param id="GN" type="java.lang.String">KNetwork</param> <param id="millisecs" type="java.lang.String">5000</param> </ace>

The Aggregator_ACE will perform an aggregation every millisecs seconds.

3.4.5 Examples of aggregation along spatio-temporal dimensions

In the final Knowledge Network Toolkit, four example of Aggregator Components that perform aggregation along spatio-temporal dimensions have been release: AggregatorWhere1_ACE and AggregatorWhere2_ACE that perform aggregation along the spatial dimension (i.e., exploiting mainly the Where field of the W4 structure), AggregatorWhen1 and AggregatorWhen2_ACE that perform aggregation along the temporal dimension (i.e., exploiting mainly the When field of the W4 structure).

AggregatorWhere1_ACE aggregates KAs whose Where field is inside a specified area. The W4 Tuple that represents the aggregation is the following:

Who: * What: * Where: exhibition: Cascadas_Exhibition When: *

AggregatorWhere2_ACE aggregates KAs whose Where field is within 1 km from a specified point described by its latitude and longitude.

The W4 Tuple that represents the aggregation is the following:

Who: * What: *


D5.4


of 91

Where: in(centre(44.68786164441, 10.66750874731866), radius: 1km) When: *

AggregatorWhen1_ACE aggregates KAs whose When field was updated in 10 seconds. The W4 Tuple that represents the aggregation is the following:

Who: sensor:* What: * Where: * When: > 10 sec ago

AggregatorWhen2_ACE aggregates KAs whose When field was updated ―today‖, i.e. this example uses a contextual expression that is parsed to a java.util.Date before submitting the query to the tuple space. The W4 Tuple that represents the aggregation is the following:

Who: sensor:* What: * Where: * When: today

The examples included in Knowledge Network final release are only some example, in fact the W4 Model enables a variety of expressive query in a W4 Tuple Space and so a variety of possible aggregation. In order to give the user the possibility to test other query, an On-Demand Aggregator has been included in the toolkit; it is described in Section 3.4.6.

3.4.6 On-Demand Aggregation On-Demand Aggregation works like standard Aggregators Components except they don‘t perform periodically a fixed aggregation, but waits for the user to submit a W4 aggregation query and then executes the submitted query once.

On-Demand Aggregation has the utility to let the user play around with the W4 Model possibility, and to serve the ace world with on the fly aggregation. In particular this can be useful for aggregation operation that are not require often.

Figure 21 shows the GUI interface for On-Demand Aggregators.

Figure 21: the GUI inteface for the On-Demand Aggregator Component.


D5.4


of 91

3.5 Context Verification The following section explains the Context Verification mechanism. The information flow, possible verification results, requirements, and a proposal for proper knowledge organisation are presented.

3.5.1 What is Context Verification Context Verification (CV) is part of the WP5 Knowledge Network (KN) Toolkit and is a mechanism to test the plausibility of data. It enables to evaluate if a certain datum is valid with respect to a set of reference data. The datum under verification as well as the reference data have to be so called Context Patterns. Such Context Patterns are built of multiple Context Elements where each element represents a sensor or other type of contextual information. The code block below shows an example of a Context Pattern that consists of three Context Elements ―hobby”, ―gender”, and ―dress code”. A detailed definition of the related terminology and a description of the CV algorithm are presented in [D5.3].

<ContextPattern> <ContextElement Count="1">

<Name>hobby</Name> <Value>cars</Value>

</ContextElement>

<ContextElement Count="2"> <Name>gender</Name>

<Value>female</Value>

</ContextElement> <ContextElement Count="3">

<Name>dresscode</Name>

<Value>business</Value> </ContextElement>

</ContextPattern>


D5.4


of 91

Context data and reference data are organised by Knowledge Networks. In order to use the context verification service, other ACEs need to search (to send a GN=‖context_verification‖) and contract a Context Verifier ACE. Once contracted, the Context Verifier ACE can be queried for the data to be verified. Base on the query, the Context Verifier will contact a KN and perform all necessary actions. As result, it will return information on the plausibility of the data under verification with respect to the reference data received from the KN. The sequence diagram in Figure 22 shows all steps of interaction between the Context Verifier, the Knowledge Network and the user.

Figure 22: Interaction between Context Verifier, Knowledge Network and user.

The CV algorithm woks in a probabilistic manner which means that it is not able to determine the absolutely correct verification result. Instead, the result of a CV process is correct with a certain probability. Because of that fact, this result can either be that data seems to be valid or that it seems to be suspicious.

User ACEContext Verifier

ACEKnowledge

Network ACE

GoalNeededEvent(CV, myAddress)

sd context verification

ContractEvent(user, provider, ID)

ServiceCallEvent(CV)

ServiceResponseEvent(...)

CancelContractEvent(ID)

User ACE

GoalAchievableEvent(CV)

GoalNeededEvent(KN, myAddress)

ContractEvent(user, provider, ID)

GoalAchievableEvent(CV)

ServiceCallEvent(query)


ServiceCallEvent(query reference data)


CancelContractEvent(ID)

AceLocalEvent(restartCV)


D5.4


of 91

3.5.2 Requirements In order to perform Context Verification, the executing system must be able to run the CASCADAS ACE Toolkit (cf.[D1.4]). Furthermore, a Knowledge Network structure must be available which is used to organise, among others, the data that should be verified and the reference data utilised for verification. The following list specifies the minimum required components for context verification.

A Knowledge Network ACE needs to be started. Its task is to organise the context as well as the reference data, and to process queries for knowledge.

Knowledge Atoms and/or Atom Repositories must be available. These components provide the context and the reference data and can be accessed by the Knowledge Network ACE when processing a query.

A Context Verifier ACE is necessary that answers to GNs requesting context verification. Once this ACE has been contracted, it works as an interface between the user and the Knowledge Network taking all inputs and performing every calculation that is necessary for the evaluation of contextual data.

A user ACE that requests context verification must be started. That ACE will send an according GN and will contract an available Context Verifier ACE. Thereafter, the user ACE can trigger the verification processes by using the Context Verifier ACEs services. A user ACE is not directly part of the CV mechanism. It rather is the consumer of the offered CV service. Furthermore, the number of user ACEs as well as the number of Context Verifier ACEs is not restricted to one. Multiple instances can exist and operate at the same time. The more CV ACEs are available, the more user requests can be served.

3.5.3 Knowledge Organisation To start a context verification process, the Context Verifier ACE needs two queries as input. First, the user ACE has to place a query that is used to find in the KN the data that should be verified. Second, it is necessary to query for the reference data that represent experiences based on which the data in question is seen. Furthermore, the user ACE must provide information about which KN should be queried. After this information has been provided, the Context Verifier ACE will search the chosen KN, place all queries, evaluate the query results, and will finally send the results as well as the outcome of the verification process back to the user ACE.

To ensure that data is properly organised in a KN, the user intending to utilise context verification should – if possible – take care about providing appropriate keyword models for all involved Knowledge Atoms. Data that have been approved to be correct can be used as reference data and should be organised accordingly. The following example illustrates how keywords can be used in order to reach optimal CV performance.

Example. During an exhibition, information about the hobbies of the visitors is collected. This information should be reused later and therefore be organised by a KN. Every hobby value that is collected is described by the following keyword model.

<Model> <Keywords> <Key Type="Include">ContextPattern.Hobby.[hobby]</Key> <Key Type="Include">ContextData</Key> </Keywords> </Model>


D5.4


of 91

Here, [hobby] has to be replaced by any hobby of the visitors, e.g. cars, clothes or football. Those hobby values that have been proven to be correct and should be used as reference data are represented by atoms with the keyword model below.

<Model> <Keywords> <Key Type="Include">ContextPattern.Hobby.[hobby]</Key> <Key Type="Include">ReferenceData</Key> </Keywords> </Model>

A user that wants to verify a hobby datum with regard to the reference data collected, needs to contract a Context Verifier ACE, specify the KN were the data is organised, and query for the following expressions.

Query: ContextPattern Hobby [hobby] ContextData Query for reference data: ContextPattern Hobby ReferenceData

Again, [hobby] has to be replaced by any hobby value that should be verified. If necessary, a more detailed description of data by using larger keyword models can be applied.

The keyword models listed above have the task to describe specific KAs and their values. In order to be able to verify context data represented by KAs, these have to expose a Context Pattern as value. This pattern can either be the direct and only value of an atom or it can be embedded into a W4 model. The code block below shows a KA exhibiting a Context Pattern value directly.

<Model atomUUID="Atom_286"> <Keywords> <Key Type="Include">ContextPattern.DresscodeGenderHobby </Key> <Key Type="Include">ReferenceData</Key> ... </Keywords> </Model> <Data atomUUID="Atom_286"> <Type>org.jdom.Element</Type> <Value> <ContextPattern> <ContextElement Count="1"> <Name>dresscode</Name> <Value>business</Value> </ContextElement> </ContextPattern> ... </Value> </Data>

As already introduced in Section 3.4.3, the W4 model consists of four data fields, which are ―Who‖, ―What‖, ―Where‖, and ―When‖. Within the W4 model a Context Pattern is represented by the “What” field. The other three fields are not restricted and can contain any data. The ―What‖ field, in this case, must contain exactly one Context Pattern. During the CV process, only the pattern stored in the ―What‖ field is regarded. All other fields, i.e. ―Who‖, ―Where‖, and ―When‖, are not relevant for Context Verification. The following example illustrates a Context Pattern that is embedded into a W4 model.

<Model atomUUID="Atom_351e5aeb-746b-41ee-907f-0ed80c7bc428"> <Keywords> <Key Type="Include">W4.Who.alice</Key> <Key Type="Include">W4.Where.exhibition:Cascadas_Exhibition</Key> <Key Type="Include">W4.When.05/12/2008 16:22:22</Key> <Key Type="Include">W4.What.ContextPattern.DresscodeGenderHobby</Key> <Key Type="Include">ReferenceData</Key> ... </Keywords>


D5.4


of 91

</Model> <Data atomUUID="Atom_351e5aeb-746b-41ee-907f-0ed80c7bc428"> <Type>org.jdom.Element</Type> <Value> <W4> <Who>alice</Who> <Where>exhibition:Cascadas_Exhibition</Where> <When>05/12/2008 16:22:22</When> <What> <ContextPattern> <ContextElement Count="1"> <Name>dresscode</Name> <Value>business</Value> </ContextElement> </ContextPattern> </What> </W4> </Value> </Data>

3.5.4 Possible Context Verification results According to the available reference data, the following “ContextVerificationResult” can be returned.

"context is valid" or "context is suspicious" is returned after a successful verification process. These answers are related to a single entry of the complete query result, i.e. each query result entry has an own ContextVerificationResult ―valid‖ or ―suspicious‖. A ContextVerificationResult is valid, if the Context Verifier ACE concludes that the query result is not suspect with regard to the reference data query result. A ContextVerificationResult is suspicious if the Context Verifier ACE concludes that the query result is suspect with regard to the reference data query result. In order to better understand why a context is valid or suspicious, the Verifier also returns information about the verification threshold (which is a CV algorithm internal parameter), the name and the value of the most suspicious Context Element, and the number of suspicious neighbours of that element within the regarded Context Pattern (see Figure 23).

"Unable to verify context: no query reply." is retuned if the Context Verifier ACE does not get any data as reply to the query. In that case, CV could not be performed.

"Unable to verify context: no reference data reply." is retuned if the Context Verifier ACE does not get any data as reply to the reference data query. In that case, CV could not be performed.

"Unable to verify context: no query reply and no reference data reply." is retuned if the Context Verifier ACE does not get any data as reply to any query. In that case, CV could not be performed.

"Unable to verify context." is returned if any error occurred for which no reason could be determined. In that case, CV could not be performed.

Figure 23 presents an excerpt of a return value after a successful CV process. In this example, a query was placed that returned several results. Each of these results was verified with respect to s set of reference Context Patterns. Depending on the outcome of the verification, the query results are marked to represent a valid or a suspicious context.


D5.4


of 91

Figure 23: Excerpt of a CV result – the context under verification is regarded to be suspicious.

3.6 An Example In order to show the fully integration and the potential of the final KnowledgeToolkit release, we developed an integrated scenario to be used to test the integration achieved by the Aggregator Components and the Context Verificator trough the W4 Data Model.

The scenario is supposed to be an Exhibition, and simulated data are supposed to be related to this scenario. In particular, Sensors and Users that expose W4 data are simulated. Users and Sensors have different update time and their what, where and when fields are dynamically filled every time that KAs are accessed. Moreover, some Users KA also expose data suitable for Context Verification (accordingly to the Context Patterns introduced in Section 3.5. This example shows that the same KAs enable the execution of both Knowledge Aggregators and the Context Verificator, supported by the underlying Knowledge Networks infrastructure.

A demonstration of the above example is available.

4 Performance Evaluation In order to assess the performance behaviour of the KN toolkit extension within the ACE world a number of tests have been designed and executed that specifically address the following factors:

- Lab. vs. real world network environments; - Local vs. remote data sources (increased communication efforts); - Number of sources (Atoms); - Increased payload of the sources; - The use of various degrees of caching; - Dependencies to the ACE communication mechanism.

Initial considerations that are based on the design of both the KN framework and the underlying ACE toolkit expect that the performance behaviour is linear increasing with an increasing number of knowledge sources and with an increasing payload. Naturally, it is also


D5.4


of 91

expected that performance is better within a lab infrastructure than it is on a real network simply because of higher bandwidth and less, more predictable network traffic within a small and controlled network environment. Thus, if caching mechanisms are excluded, the key factor expected to influence the performance behaviour is the available bandwidth of the underlying network and the ACE communication model on which all interaction of KN components is based upon. For a detailed performance evaluation of the latter please consult performance evaluations related to WP1. Finally, an empirical study is presented at the end of this Section that evaluates the impact of different physical network architectures and associated routing techniques in an attempt to identify suitable physical network structures were the KN approach could be deployed upon. For obvious reason, experiments associated to this study have been performed in a simulated fashion.

4.1 Performance Tests All tests performed utilise the final KN toolkit extension as published on Sourceforge in December 2008 and evaluate the response time to a simple query on individual KNetwork ACEs and on the Cross Network Query Service (CNQ) which reflects the overall response time to a query.

For all tests a number of KNetwork ACEs have been used on various physical resources as detailed for each individually for each experiment. Considering the overhead required to create and control individual Atom ACEs, knowledge sources have been simulated via the Atom Repository for each KNetwork ACE. Thus, each KNetwork ACE will have an Atom Repository attached to it that is used to register knowledge atoms to it. Depending on the test configuration the associated AtomRepo will be either in the same physical resource as the KNetwork ACE or on a central AtomRepo Server hosted @ UU premises. The former relates to local knowledge sources whereas the latter is referred to as remote knowledge sources. In addition to this a User ACE has been configured that always initiates a query to be processed by a CNQ ACE that takes care of querying all KNetworks. Independent of specific configuration or the physical location of resources the associated workflow for executing a query process is always the same and can be can be summarised as follows:

Step 1: The User ACE sends the query to the query service; Step 2: The query service forwards the query to all KNetwork ACEs; Step 3: Each KNetwork ACE calls the ‗getValue‘ method on each registered KA (the

system and the query have been configured that all atoms are always part of the result set);

Step 4: Each KA replies to the request by forwarding its information to the corresponding KNetwork ACE;

Step 5: Each KNetwork ACE collects the replies and if all replies have been received the query result is forwarded to the query service;

Step 6: The query service collects the results form all KNetwork ACEs and after all results have been received it merges them before forwarding the final result to the User ACE;

The time to answer each query is monitored in each KNetwork ACE and within the query service by monitoring the time the query is received and answered. The difference represents the response time of the component concerned. Note that there is an additional overhead involved to send the final result from the CNQ ACE to the user ACE, which, however, requires no additional processing efforts from the knowledge network and as such, is excluded in these experiments. To achieve a higher confidence each query is executed at least 3 times and the average or the minima and maxima thereof are used for the


D5.4


of 91

performance evaluation. In the sequel the ACE configuration for each test is outlined before the test results are presented and discussed. A summary of all experiments and the conclusions thereof are presented at the end of this Section.

4.1.1 Intranet based Performance Evaluation For this set of tests two scenarios have been devised in order to analyse the impact in query response times if, firstly, the number of atoms is increased and, secondly, an increased communication effort is required to retrieve the actual values from the sources forwarding them to each network and eventually to the user. Until stated otherwise all ACEs are hosted on different physical recourses that are within the same physical sub-network. That is that all computers are connected to the same network hub. This configuration ensures high bandwidth as well as no congestion and as such reflects an idealised network configuration.

4.1.1.1 Local Data Sources

The test configuration for this scenario is depicted in Figure 24 and reflects the fact that knowledge sources are local with respect to the KNetwork ACE. That is that they are on the same physical machine as the KNetwork ACE, which should reduce network traffic and thus optimise query response times.

Figure 24: Test-Bed Configuration – Intranet, Local Data Sources

As can be seen in Figure 25, the number of atoms / KNetwork is increased in steps of 10 which results in an overall number of atoms of 500 (100 atoms / KNetwork). Queries are executed at the same interval and the response time of the query service is monitored. As can be seen the time is increasing in a linear fashion but following a sort of stepping behaviour between each interval. That is that an actual increase is only observed at every second interval. This strange behaviour has been observed in most of the tests that follow but can be explained through the design of the KN ACE communication method and will be discussed further in ―Section Buffer Size and the ACE Communication Model – Stepping Behaviour‖. Response times are displayed in three series A, B and C which reflect the average execution time of three individual queries which again have been averaged for the ―Avg.‖ data series. Times monitored range from about 1 second to just over 6 seconds and are acceptable considering that in the end 500 knowledge sources had to be queried individually before the results could be merged and send to the user.


D5.4


of 91

Figure 25: Response Time – Query Service

Figure 26 shows the minimum and maximum response times for each KNetwork, which are obviously always smaller than the overall response of the CNQ (Approximately by 1 second). While individual response times do vary, a linier increase with respect to the number of atoms is clearly visible which is however also interrupted by the stepping behaviour between intervals. Again this will be discussed later.

Figure 26: Min. & Max. Response Times – KNetwork 1 - 5

4.1.1.2 Remote Data Sources

The same set of tests have been performed for the scenario that is depicted in Figure 27 and which reflects the fact that knowledge sources are remote with respect to the KNetwork ACEs. That is that they are on different physical machines as the KNetwork ACE they are registered with. For that, another server has been configured that hosts all atom repositories and as such, all knowledge sources for all KNetworks. Note that this configuration implies a certain bottleneck with respect to communication workload, as this server is in fact a central sink for all knowledge sources and as such will receive all requests from each KNetwork ACE to which it also has to reply. Nevertheless, the delay is expected to be, on average, equal to all KNetwork components and as such should not obscure the evaluation too much. Following the workflow presented earlier this should result in an increased communication effort that also should increase response times as more data have to be send over the physical network.


D5.4


of 91

Figure 27: Test-Bed Configuration – Intranet, Remote Data Sources

Response time for the CNQ and all KNetworks are shown in Figure 28 and Figure 29 respectively and range from just over 1 second to approximately 6.3 seconds if all 500 atoms are registered to the various KNetworks. This shows that response times for this scenario are more or less the same as for the previous example where knowledge sources were on the same physical resource. Although not expected initially, it shows that the communication effort between local and remote ACEs is relatively equal assuming an optimised underlying network infrastructure. Although not as regular as in the previous scenario, the stepping behaviour is also clearly visible and will be discussed later on.


Figure 29: Min. & Max. Response Times – KNetwork 1 - 5


D5.4


of 91

4.1.2 Internet based Performance Evaluation As depicted in Figure 30, the configuration of this test scenario is identical to the previous one except that the physical resources that host ACEs are no longer within the same physical sub-network. Instead, as detailed in Figure 30, a number of partners each host an individual KNetwork instance, which are connected via a REDS Server that is hosted @ UU premises. This scenario utilises the Internet infrastructure such that bandwidth, network traffic etc. between components cannot be guaranteed or controlled. Thus the objective of this test is to evaluate the impact a real world Internet based network has on the response time of the KN toolkit. Note that the test has been devised to include another partner synchronising the number of components with the tests performed in the previous Section. However, at the time a connection to the fifth KNetwork ACE could not be established so that this test only includes 4 KNetwork instances. However, the test results are still comparable as the response times of individual KNetwork instances are unrelated to each other and the response time of the CNQ is mainly influenced through the slowest KNetwork rather than the number of KNetworks queried. Another aspect to be stressed for this configuration is that four of the resources involved are still on the same sub-network (User ACE, CNQ ACE, KNetwork ACE [UU-Belfast] and the Atom Repo server hosting all atoms for all KNetworks). Considering that response times over the Internet are expected to be slower that the response times achieved in local sub-network configurations the UU KNetwork ACE should perform best.

Figure 30: Test-Bed Configuration – Internet

As can be seen immediately in Figure 31, response times for the CNQ service have been increased approximately by a factor of 10. Still increasing in relation to the number of Atoms registered, response times have become more erratic which further underlines the dynamicity of a real world network. For visibility a linear regression has been overlaid that shows that the system does perform vary stable and liner up until about a workload of 200 atoms (50 per KNetwork). Afterwards, response times become more irregular which is most likely caused by the ever-increased communication efforts.


D5.4


of 91


The erratic response time becomes even more visible when analysing the results on a KNetwork level as shown in Figure 32. The chart shows the minimum and maximum response times and as can be seen they vary drastically between networks. However, looking in more detail on the response time of the FOKUS KNetwork shows that it is relatively linear in its minimum (up until a workload of approximately 40 atoms) and also relatively linear with respect to its maximum response times. Even more the gap between the minimum and maximum response times also widens in relation to the workload.

Figure 32: Min. & Max. Response Times – KNetwork UU, Bute, Fokus, Unimore

Alternatively, analysing the response times of the UU KNetwork ACE show that it is mostly the fastest with respect to the minimum response times but can also be among the slowest for the maximum response times. This can only be explained that, independent of the optimised connection between the UU KNetwork ACE and the Atom Repo, some requests from the UU ACE may have been answered last. This in turn can be explained on the workload of the component having to process all requests. Thus, another influencing factor for the response times of each KN component and of the response time as a whole is the response time of each individual component has. This becomes even more visible when analysing the response times dependencies as shown in Figure 33. The chart shows the averaged minimum and maximum response times of the KNetwork ACEs and of the QNC. As can be seen, minimum and maximum of the KNetworks vary significantly whereas the response times of the QNC (QS) are nominal. Again this is due to the fact that response times depend on the slowest component in the overall query chain and that delays will be accumulated throughout.


D5.4


of 91

Figure 33: Response Times Dependencies

4.1.3 Buffer Size and the ACE Communication Model – Stepping Behaviour

Within the previous experiments a sort of stepping behaviour has been observed that showed that response times were increased only at certain intervals with respect to the number of atoms added to the test environment. While this behaviour seems strange it can be explained through the way KNetwork (and Atom Repo) communication has been implemented in relation to the underlying ACE toolkit. As outlined in WP1, the underlying ACE communication is event based in a way that events are send by one ace to be processed by another. Received events are queued until processed or discarded if the queue buffer is not large enough to accommodate all incoming events. In order to improve resilience of the KN toolkit extension and to avoid the rejection of events a buffer mechanism has been implemented in the KNetwork and the Atom Repository components that limits the number of events to be send at a single dispatch. To be configured during start-up the dispatch mechanism is invoked at certain intervals and only sends out a maximum number of events. While this slows down execution times it improves stability and resilience of the overall system.

In order to evaluate the impact of this mechanism a test has been devised were the buffer size of the KNetwork ACE and the Atom Repo ACE have been increased from 10 to 100 at steps of 10, 20, 30, 50 and 100. The number of atoms also has been increased from 0 to 100 in intervals of 110. The configuration of the test system is similar to the previous tests and comprised a User ACE, a KNetwork ACE and an AtomRepository ACE that are executed within a controlled sub-network. The dispatch delay for both components has been set to 1 second.


D5.4


of 91

Figure 34: Response Time – KNetwork

The results are shown in Figure 34 were response times range from over 9 seconds to just under one second. As can be seen at a buffer size of 10 the system is behaving linear without any stepping behaviour visible. Also visible is that at each interval (increase in atoms) the response time increases by about 1 second which correlates to the dispatch delay set by the user. As for a buffer size of 20, although not very distinct there is a stepping behaviour visible at 30, 50, 70 and 90 which results in a response time at about 4.5 seconds if all 100 atoms are registered. Again this correlates to (a) the buffer size and (b) the associated dispatch delay. A similar behaviour is visible for a buffer size of 30 where response time increases at 40, 70 and 90. However the stepping is most visible for the test were the buffer size has been set to 50. As can be clearly seen for this series the response time increases by approximately 1 second if 60 atoms have been registered to the system. This is a direct result of the fact that the system sends first only 50 events then pauses for 1 second before sending the remaining 10 events. As can also be seen, stepping is completely avoided if the buffer size is set to 100 which also represents the fastest response time. At first it seems odd to limit the system at all as it directly slows it down with respect to response times. However, there is a maximum number of events a system can handle and as such it is always recommended to limit communication in support of system resilience.

4.1.4 Payload Evaluation Another factor that will clearly influence the response time of a query is the payload the knowledge sources have. For that it has to be stressed that, unlike other query or search engines, knowledge networks do provide the knowledge itself in response to a query and not just the location thereof. Thus larger payloads would slow down the response times depending on the size but also on the bandwidth available. In order to analyse the dependency test configuration has been devised involving two KNetworks as depicted in Figure 35. While all atoms of KNet1 carry only a few bytes payload, atoms registered to KNet2 carry approximately 400KB of payload. Note that any overhead related to ACEs or even KN components communication has been excluded. The only factor relevant to payload is the actual size of the knowledge published by the atom.


D5.4


of 91

Figure 35: Test-Bed Configuration – Payload

Again atoms have been registered in steps of 10 up until a maximum of 100 per KNetwork. The response times for both are shown in Figure 36 and as can be seen there is a linear dependence with respect to the number of atoms involved and only a minor difference between the two payloads which, however, could be aided by the high speed network the test was executed on. Nevertheless, the response time of the high payload network increased dramatically after about 70 atoms have been registered. The exact reasons for this behaviour are not known yet but are likely to be network dependent. For a full explanation a more detailed study of all of the underlying network communication efforts would be required which will be the focus of a future investigation.

Figure 36: Response Time – Payload Caching

One of the last services incorporated into the KNetwork toolkit was that of being able to cache knowledge sources in order to increase query performance but also to improve resilience in case knowledge sources would become shortly unavailable. For this, a dedicated service has been developed and integrated into the KNetwork component, which now provides atoms with the possibility to have their knowledge cached depending on their own configuration. While the technical details on this service are given in Section ―Knowledge Distribution and Caching‖, this section evaluates the runtime benefits that can be achieved by enabling the caching mechanism. For that the test configuration depicted in Figure 37 has been established comprising three KNetwork ACE, a User Ace, QNC ACE and an Atom Repo ACE that serves the atoms and the knowledge they publish.


D5.4


of 91

Figure 37: Test-Bed Configuration – Caching

On the test-bed defined above three test have been performed and the results thereof are presented in Figure 38, which show the response times for each KNetwork ACE and of the overall response time as provided by the CNQ. Overall 10 queries have been performed for each test with 100 atoms registered at each KNetwork.

In (a) the response time is shown with caching disabled resulting in an average response time of around 5 seconds for each KNetwork and a round 6 seconds for the CNQ. Except for the peak for query 6, the performance varies little showing neither increase or decrease in response times. For (b), caching has been enabled and atoms have been configured to ―expire‖ at a randomly generated time with an interval of 0 – 10 seconds. As can be clearly seen in (b) there is a significant drop in response times after the first query has been executed. This is expected as for the first query no information has been cached yet whereas only a reduced number of atoms need to be queried again in subsequent queries. The latter obviously depends on the timeout specified for each atom. The randomly generated timeout factor is also visible in the irregular response times of each individual KNetwork that indicates different timeout values among the set of registered atoms. Nevertheless, the most important factor is the achieved optimisation of the CNQ response time of just over 2 seconds to around 4 seconds.

(a)

(b)


D5.4


of 91

(C)

(d)

Figure 38: Caching Performance – (a) No Caching; (b) Avg. Caching; (c) Full Caching; (d) Overview

(c) shows the response times if full caching is configured. That is that all sources are cached infinitely and as such are never reloaded. Although there are cases where knowledge will never change such a configuration should be avoided. Knowledge sources even if static should be updated at certain intervals even if it is just for the purpose to test the operation of the system itself. However for this scenario, the two extremes of caching behaviour are ―no caching‖ and ―full caching‖. Having already analysed the former, the response times for the latter are shown in (c). As can be seen, after an initial load of the sources the caching allows each KNetwork for very quick response times which in turn allows for optimised response times of the CNQ reducing the average time to answer a query to under 2 seconds which represents an optimisation of more than 70% compared to the response times if caching is disabled. An overview about the three tests and the optimisations achieved per component is shown in (d). As can be seen, caching can optimise response time drastically and can also include system resilience as outlined earlier. Nevertheless, caching also makes knowledge structures more heavyweight so that the use thereof should be decided upon individual requirements rather than as a general solution to performance optimisation.

4.1.5 Summary The above experiments have shown that the performance of the KN toolkit extension depends on a number of factors which cannot always be controlled to an extent that the systems behaviour becomes fully predictable. On the contrary, if used within real network structures response times are largely unpredictable and can vary greatly between components. While factors such as workload and payload have a linear impact on the performance of the system other factors such as the underlying ACE communication mechanism or KN design choices can influence the performance to various degrees. Overall, however, the response times measured are satisfactory especially when considering that knowledge sources are queried directly and as such do provide up to date knowledge or if caching is enabled knowledge that satisfies a given freshness factor.

If knowledge network structures are to be realised as part of a physical network architecture additional factors such as routing services also have to be taken into account. Initial research in this area has highlighted some interesting aspects that could lead to design decisions that could influence the performance greatly. For that an imperial study has been performed which is discussed next.


D5.4


of 91

4.2 An Empirical Study on the Traversal of Dynamically Constructed Knowledge Networks

One of the goals of autonomic networks is to automatically manage the complexity inherent within both the physical (hardware level) and virtual (knowledge level) relations of the network. Self-configuration within networks is the capability of a system to configure its own network services and relations in response to the environment. Flexibility of location, varied administration control and the requirement to distribute knowledge globally all contribute to the complexity of the task of autonomic configuration [MeMi04]. Thus it becomes obvious that advanced routing services, again physical and virtual, are essential to autonomic networks. This Section evaluates the results of traversing a knowledge network by various routing methods – thus addressing the question as to which is the most effective means of traversing knowledge structures in a large-scale dynamic and autonomic network in relation to the knowledge network architecture. For that, several simulated experiments have been performed using the ns-2 simulation environment [NS-2_SIM].

4.2.1 Knowledge Network Topologies In order to retrieve information from a construct such as the knowledge network it is obvious that some sort of querying mechanism is required that traverses the relations that, as a whole, make up the knowledge network itself. Considering that the granularity of such a network is reflected through the vertical organisation thereof, which, by nature, is highly heterogeneous and also highly distributed, efficient means have to be employed to traverse both the virtual relations of the KN as well as the underlying physical network. Thus efficient routing methods are not only relevant to traverse physical network nodes but also and equally important to efficiently traverse the virtual relations that organise the underlying knowledge. A querying system can take advantage of the knowledge network‘s hierarchical, lightweight and autonomous structure. For that, required ontology information may be integrated into the network itself, making use of the elements that already exist. This also means that no separate ontology document must be accessed, which could become a bottleneck in the querying process. Extra information in the form of keywords and links are simple structures and so are also relatively lightweight. The data sources however may be more heavyweight with regard to querying, as they may have to query complex XML documents. Thus it is desired to identify and transmit only those data sources that are relevant to a queries response. The stigmergic querying process discussed in [D5.3] suggests two initial stages – one to traverse the network and one to query the sources. For the former, the search will largely be guided by the hierarchical structure of the network where the search can move to the node that closest matches the query specification based on e.g. keyword similarity. This knowledge network querying system is the process that we have modelled in the experiments that follow. We seek to address primarily the issues of the most efficient method of traversing the hierarchical network structure in order to seek the node that closest matches the query specification based on keyword similarity for example in the shortest time.


D5.4


of 91

Figure 39: Knowledge Network Topologies

For that, a variety of topologies have been evaluated which are depicted in Figure 39 and categorised as follows:

a). The direct method involves directly accessing the knowledge source and returning the results. This is the ideal method. It presupposes that the application has complete knowledge of the properties of each particular source and can navigate directly to that node without any overheads due to ‗lookup time‘. In practice this method may be limited to specific applications, however it is still possible to implement. (see Figure 39(a)).

b). The node by node method involves traversing to the first node and returning, then the second node and returning and so forth until the actual knowledge atom is accessed. This form of traversal may be necessary where the result of each node has to be evaluated by the requesting node before a decision can be made on how to proceed. This may be practical in situations where the nodes at the extremes of a large knowledge network take some time to reach and where information at each of the intermediary nodes is required in order to continue e.g. building up a snapshot of traffic along a route. (see Figure 39(b)).

c). The hash table structure approach uses a hash table structure in order to find the location of the data node that contains the information desired. In sensor network deployment scenarios, there can often be a small maximum acceptable delay between event occurrence and message reception. Indeed, data nodes can also be too simple to buffer messages. Here the message rate at the application is largely determined by the peak rates of all nodes and this can potentially be very large [RBS06]. Response time is a priority for many distributed applications and thousands of concurrent streams attempting to traverse an already congested network are unlikely to be solved in the short-term by network upgrades. Therefore techniques such as this one and particularly the edge server technique, which follows, are methods to reduce the load on the source application. (see Figure 39(c)).


D5.4


of 91

d). One method to reduce the load on the requester node is to deploy edge servers. These are entities that are logically located at the networks edge and physically residing between the data nodes and the querying node. Edge servers can be viewed as application level relay devices which process data before forwarding to each application ultimately reducing the amount of data sent through the network through a filtering/aggregation process. The principle of the Edge Server can be applied to any web-based information but it is especially suitable in the dynamic hierarchical knowledge network approach. We see it as being particularly useful in distributing the demands on network and indeed system resources, as we will be capable of assigning the knowledge atoms (i.e. sensors) in a knowledge container to a specific edge server. Here for example, one edge server might aggregate and forward requests from weather/temperature sensors in England and another might aggregate and forward requests from servers in Northern Ireland. The edge servers in England and Northern Ireland collect the requests and relay them to the origin server. Commercial edge servers exist such as Oracle‘s Sensor Edge Server1 and IBM‘s WebSphere2 both of which are tasked with extending the reach of an enterprise software infrastructure to include information from sensor technologies. (see Figure 39(d)).

4.2.2 Evaluation The ns-2 simulation environment offers excellent flexibility in investigating the characteristics of autonomous systems as it already possesses flexible models for scalable ad hoc autonomic networks. In the ns-2 environment, an autonomic network can be built with many of the same protocols and characteristics as those available in the real world. By leveraging these modules, we added the capability of simulating an autonomic context-aware network. The software includes a library, demultiplexers, multiplexers, broadcast agents and a basic class definition of the context-aware network nodes. The library also includes timer functions, packet manipulation functions, network I/O, buffering and QoS functionality. Ad hoc on-demand distance vector routing (AODV) is utilised which is a reactive routing protocol designed for ad hoc mobile networks. It is an on demand algorithm, meaning that it builds routes between nodes only as desired by source nodes. It maintains these routes as long as they are needed by the sources. A node in this autonomic network has the capability of responding to network requests dynamically. Most requests will be generally application dependent, but will typically also be a function of network control information. Hence the simulated knowledge atom component provides the hooks for a monitor stack element to be inserted tailored to an application which has in place means to monitor the data and manage the bandwidth usage of the system when the data requirements of the various media exceed the available bandwidth. The prerequisite for initiating autonomic led reconfiguration are functions, which allows the system to detect network congestion. This is achieved by monitoring end-to-end delay and packet loss rate. When a packet arrives, a monitor queue object notifies the bandwidth manager object of this event. The bandwidth manager using this information monitors the queue. A packet has an expected arrival time and a packet arriving later than expected indicates congestion. We calculate the expected arrival time as the ‗logical arrival time‘ of the previous packet plus the stream period. The logical arrival time is the arrival time observed when bursts are smoothed out, that is, when early packets are artificially delayed

1 http://www.oracle.com 2 http://www-306.ibm.com/software/webservers/appserv/was


D5.4


of 91

such that the stream rate is not exceeded. The goal here is to monitor the knowledge atoms as they are ferry requests to and from across the knowledge network. The quality of network packet delivery delivered is quantified in the experiments by using loss rate and adaptive mechanism comparative techniques. The simpler mechanism is the loss rate which is a good indication of quality. There is a deliberate policy to intensify interference to emulate behaviour in extremely adverse conditions in order to ascertain the robustness of the network.

Figure 40: Knowledge-Weather Simulation

As the network does not distinguish between normal data packets and knowledge network control packets - beacon messages, and binding requests are likely to be frequently lost when applications/users send requests at a higher rate than the available bandwidth. Knowledge of this is imperative for an acceptable throughput distribution of competing requests. Applying priorities to knowledge atom control packets can be achieved by using two separate queues for data and control packets with a higher priority being assigned to the knowledge atom control packet queue. Figure 40 illustrates the conceptual organisation of the test-bed setup of a simulated knowledge network weather scenario. Whereas Figure 41 illustrates three of the scenarios that we have modelled in order to simulate the traversal of the constructed knowledge network.

1.1.1.1.1.1.1.3 D

es

ti

na

1.1.1.1.1.1.1.1 S

ou

rc

e

1.1.1.1.1.1.1.2 N

od

e


D5.4


of 91

Figure 41: Experimental scenarios a, b and c

Figure 42 shows the edge server scenario (d) where application level relay nodes process data before forwarding to each application ultimately reducing the amount of data sent through the network through an intelligent aggregation process. It is important to note that the edge server technique is not incorporated simply as an alternative strategy but rather seen as been a core infrastructural component of the network of knowledge. A network of knowledge will contain a number of distributed nodes that store information and to successfully use this information, the nodes need to be organised in a meaningful way. If the correct associations between the knowledge can be made then information can be efficiently retrieved. The linking of nodes in a network can be done stigmergically, using an experience-based method of updating weight values until they reach a certain threshold. The network can autonomously update weight values for links between nodes based on the input values that the network is currently reading and every node can store a structure that references nodes related to it through these inputs. If the weight value for a related node becomes greater than a threshold value, then this node can form a link between it and the related node. If the node in question is then queried again, it can indicate that it has a link to the other node, which might produce an answer to the query. If the links can provide an answer, then the query process does not need to search the whole network, thus reducing the amount of search required. The philosophy of this network is that it should remain as lightweight as possible. Because of this, heavyweight algorithms would not be preferred, nor would centralised algorithms. The knowledge retrieval should be done in a distributed manner with relatively simple comparisons at each node. Thus simple links can not do much more than optimise for information retrieval and we have found that the edge server approach is a good fit.

Figure 42: Edge Server (d) scenario

In experiments performed, we assumed that the top tier connections of the topology (i.e. connections between the UK node and England node) would be the faster connections therefore we allocated a bandwidth of 2Mb/s and latency of around 10ms. The second tier connections (i.e. connections between Northern Ireland and Western and Eastern Regions) were given slightly less bandwidth (1.7Mb/s) and higher latency (around 12ms). The third tier connections have slightly less bandwidth again (1.1Mb/s) and lower latency (around 15ms).


D5.4


of 91

Ping-type agents are attached to each of the nodes in the topology for measuring the roundtrip time for packets traversing the network. Each timing agent has two core methods a receive method and a send method. The receive method receives the ping request/echo from another agent, whereas the send method is used to initially send the request or to reply to a request. The packet size for agents is set to 64 bits. For scenario A, results were averaged at 92ms and 96ms. The reason for this difference is because the link between node 18 (UK) and node 17 (Northern Ireland) was 12ms whereas the link between node 18 and node 16 (England) was 10ms. This 2ms difference resulted in one half of the topology to have slightly faster traversal times than the other half, and because of this 2ms difference in the links this results in a 4ms difference in the overall roundtrip time. Using the following data we can ascertain that the average ping to an end node directly in our knowledge network was 94ms. The results for scenario A are illustrated in Figure 43 where we can see the increase in time when node 6 is reached.

Figure 43: Scenario A, B, C and D results

For scenario B, Figure 43 illustrates the scenario of travelling to an intermediate node and returning the results and so forth. Again as the linkage between node 18 and node 17 is 2 ms slower than that of the link between node 18 and node 16, we can expect one half of the knowledge network to be around 4 ms slower. The average roundtrip time for each node is 157.1 ms, the highest being 161.1 ms and the lowest being 153.1 ms. There is a difference of 8ms between the highest and lowest times because of the difference in delay between at the level 1 nodes. From these results it is safe to assume that this method of traversing a sensor network is slower than scenario A. The increase in time at node 5-6 is to be expected, as the topology at the particular part is 2ms slower. The results for scenario C were quite similar to Scenario A (direct method) with the only difference being the additional overhead of the hash table lookup. The hash table lookup overhead was 10ms. Here, results were averaged at 104ms for traversing both sides of the knowledge network. Again, the reason for this difference is because the link between node 18 (UK) and node 17 (N. Ireland) was 12ms whereas the link between node 18 and node 16 (England) was 10ms. This 2ms difference resulted in one half of the topology to have slightly faster traversal times than the other half. The results from scenario D in figure 9 illustrate that the average roundtrip time


D5.4


of 91

per end node ping is 84 ms which is shorter than scenario A‘s results. The edge lookup is the key to why this is such a fast method. It can be seen that the method used to traverse the network in scenario B is less efficient than that of scenario A, C and D. It must be remembered that the edge servers‘ process data before forwarding to each application ultimately reducing the amount of data sent through the network through this intelligent aggregation process.

4.2.3 Summary It can be argued that robustness and economy demand the deployment of a tested autonomic supporting infrastructure whenever possible. Industrial systems middleware is generally modular and adaptive however it can be demanding of bandwidth and indeed computational resources. Ideally we would like to map the cleanly designed real-time resource constrained embedded systems onto autonomic smart-world supporting infrastructures. This empirical evaluation has been performed to investigate the peculiarities of node behaviour when traversing knowledge network relations in such a network. Underlying all of this however is that there is a problem in the real-world associated with connecting smart networked devices which comes from a fundamental problem in the underlying Internet architecture and that the problem is here to stay until a solution emerges. To summarise, we found that the fastest method was (d) utilising edge servers. The next fastest method was found to be the direct method (a) followed closely by the hash table approach (c). The slowest approach was node by node (b) which has to traverse the network continuously forth and back until all nodes have been visited. While this seems awkward it may in some cases be necessary. In particular if intermediate nodes hold information that is required to identify other nodes, either by location or by concept. Nevertheless, as this is the slowest method it should be avoided where possible. Again, the edge server technique was not adopted randomly as an alternative strategy but rather is seen as been a core infrastructural component of a stigmergic network of knowledge. A network of knowledge will embrace a large number of distributed nodes that store information and to successfully use this information, the nodes need to be organised in a meaningful way. On a conceptual level this has been achieved vie the concept of knowledge containers that are used to cluster source nodes (knowledge atoms) based on the semantic concepts their support. However, finding these virtual nodes within the scope of a fully distributed knowledge network does require intelligent routing mechanism. Furthermore, once identified, additional routing mechanisms are required to access the underlying knowledge source (e.g. a sensor component) and to retrieve the knowledge thereof. If knowledge containers would also represent edge server itself then the second routing procedure would be obsolete and knowledge retrieval could be optimised. The philosophy of this knowledge network is that it should remain as lightweight as possible and we believe that the edge server approach would be a good fit for realising the knowledge network approach as an integral part of a physical network infrastructure thus allowing fast and reliable access.


D5.4


of 91

5 Algorithmic and Scientific Advances In this part of the document we report on the scientific investigations having been made during 2008, in particular related to algorithms, models and applications for aggregating knowledge, self-learning in heterogeneous sensing systems, and algorithms for stigmergic knowledge querying. With regard to this latter, this section reports also about the general studies that we have performed concerning the concept of stigmergic knowledge linking and of cognitive stigmergy.

We emphasize that, while all scientific and algorithmic results described in previous deliverable have been eventually found their way into the KNs toolkit, it is rather clear that the results described here in the following, having been studied at a later stage of the project, could not find the time for being properly integrated into the KNs toolkit. This, however, does not undermine in any way the importance of the results from the scientific viewpoint.

5.1 Handling Knowledge Generation and Knowledge Overflow In D5.3 – Section 8 Aggregating and Networking Knowledge: Models, Algorithms, and Applications, a novel data model to represent context information, the so called W4 Data Model, and some algorithmic approach to analyse W4 data in W4 Knowledge Networks and generate new knowledge has been presented. In this final report we discuss the knowledge overflow issue (i.e., the generation of new knowledge exacerbates the problem of dealing with vast amount of knowledge) and present a self-organizing approach to manage knowledge generation. Some simulation results are also presented.

One of the key motivations of this research activity is that future pervasive and autonomic communication services must evolve from a simple model of ―context-awareness‖, in which they access isolated pieces of heterogeneous contextual data and are directly in charge of digesting and understanding them, towards a model of ―situation-awareness‖, in which services access properly structured and organized information reflecting comprehensive contextual knowledge related to a ―situation‖ of interest and which can be exploited in a standardized fashion. The idea is to make available to services a simple yet expressive interface via which to access contextual knowledge, and encapsulate behind such interface all the algorithms and tools to engineer contextual data (i.e., to represent, organize, prune and aggregate it).

The W4 Data Model, as already introduced in Section 3.4.3, was developed during the second year of CASCADAS as novel data model to represent context information, which as the potential to act as a general-purpose model to handle several kind of context information. The model is based on the consideration that most information about the world (i.e., about facts occurring in the world) can be simply represented in terms of four ―W‖s – Who, What, Where, When. Despite its simplicity, such a representation enables for very expressive and flexible data usages. In particular, W4 data can be easily queried and accessed by services, tolerate the effective execution of semantic data organization and data aggregation, and can be effectively used to represent both primitive data and high-level knowledge related to a situation.

Further we integrated in our data model general-purpose mechanisms and policies to link together knowledge atoms, and thus forms W4 knowledge networks in which it will be possible to navigate from a W4 tuple to the others. Our idea is that, by querying such a knowledge network instead of a flat W4 tuple space, one can obtain much higher knowledge, as resulting from the analysis, manipulation and inference upon the link structure


D5.4


of 91

of the knowledge network. In particular, new information could be produced by navigating the knowledge network and combining and aggregating existing information into new knowledge atoms (i.e., producing new W4 atoms in more elaborated fashion that earlier exemplified).

In this final report we address the problem of the management of the knowledge generation by W4 Knowledge Networks. Indeed, the possibility of generating higher-level knowledge from raw data, although it can possibly facilitate access and understanding of data, does not necessarily solve the problem of having to deal with unmanageable amounts of information. Rather, it can be the case that the continuous generation of higher-level knowledge from raw data even exacerbates the problem, by making available very large amounts of higher-level knowledge pieces that complicate knowledge extraction and are of no use to anyone. In this context, the contributions of this paper are to unfold the above issues and to explore a self-organized solution for adaptively control the generation of knowledge from raw data in order to limit the amount of new knowledge generated (i.e., to avoid knowledge overflow). The need for a self-organizing approach to knowledge generation [Par97] is clearly required by the inherent decentralized nature of the pervasive computing scenarios in which such data is generated, and in which it has be managed in an adaptive way and based on local information. In our approach, specifically, biologically-inspired self-organization is used to adaptively drive the process of knowledge generation based on the queries taking place in the system, i.e., the more some knowledge is queried the more the generation of similar knowledge items is reinforced. The result, which we discuss and validate with the help of simulation figures, is that the number of new knowledge generated can be effectively controlled without any a priori information and without undermining the possibility for services and users to access the needed knowledge.

5.1.1 The W4 Data Model Our proposal for a novel, simple yet effective, data model for expressing contextual knowledge about the world starts from the consideration that any elementary data atoms as well as any higher-level piece of contextual knowledge, in the end, represents a ―fact‖ which has occurred. Accordingly, our proposal simply accounts that any of such facts – and therefore any data/knowledge atom – can be expressed by means of a simple yet expressive 4-fields tuple (Who, What, Where, When): “someone or something (Who) does/did some activity (What) in a certain place (Where) at a specific time (When)”. Some knowledge atoms generating W4 data are already included in the Knowledge Network toolkit.

W4 knowledge atoms may be created by proper knowledge atoms ACEs associated to data sources or sensors (but, more in general, we can think at any kind of software agents). Their four-fields structure is flexible and general enough to uniformly deal with information coming from sources as diverse as embedded devices, cameras, users, other ACEs, or Web 2.0 sites, and can account for adaptation to context and incomplete information (i.e., some of the four fields being unspecified). W4 knowledge atoms, can be stored in suitable shared data spaces, whatever distributed and implemented. In the ACE based toolkit, there are specific Aggregator Components that to store and manipulate W4 atoms and making them available services. The four-fields Who, What, Where, When of the W4 data model each describes a different aspect of a contextual fact:

The Who field associates a subject to a fact, and may represent a human person


D5.4


of 91

or an unanimated part of the context acting as a data source. E.g.,‖user:Tom‖, ―sensor:#123‖;

The What field describes the activity performed by the subject. This information can either come directly from the data source, or be inferred from other context parameters, or it can be explicitly supplied by the user. Context-dependent expressions can be defined (e.g., ―here‖, ―within:300 m‖) and can be used for context-dependent querying. E.g., ―work: pervasive group‖, ―temperature: 20°C‖;

The Where field field associates a location to the fact. In our model the location may be a physical point represented by its coordinates (longitude, latitude), a geographic region, or it can also be a logical place.

The When field associates a time or a time range to a fact. Context-dependent expressions can be defined (e.g., ―now‖, ―today‖, ―yesterday‖, ―before‖) and can be used for context-dependent querying.

The way it structures and organizes information makes the W4 data model general enough to represent data coming from very heterogeneous sources and simple enough to promote ease of management and processing (although we are perfectly aware that it cannot capture each and every aspect of context).

It is fundamental to define a simple API for services to access to contextual knowledge and enabling data sources and services to inject new data in the knowledge network layer.

From the viewpoint of the toolkit, this implies the existence of a specific ACE (the Aggregator ACE) in the knowledge network that provides access to a sort of virtual data space where W4 knowledge atoms are stored. Since knowledge atoms are stored in the form of W4 tuples in a shared data space owned by the aggregator ACE (or in multiple data spaces owned and coordinated by multiple aggregator ACEs, this is not relevant at the moment), such aggregator ACE should make available an interface that can be inspired to that of tuple space approaches ―à la Linda‖, i.e.,:

void inject(KnowledgeAtom a); KnowledgeAtom[] read(KnowledgeAtom a);

The inject operation is equivalent to a tuple space ―out‖ operation: an agent accesses the shared data space to store a W4 tuple there. The read operation is used to retrieve tuples from the data space via querying. A query isrepresented in its turn as a W4 tuple with some unspecified or only partly specified values (i.e., a template tuple). Upon invocation, the read operation triggers a pattern-matching procedure between the template and the W4 tuples that already populate the data space. In the W4 system the pattern-matching operation works differently from the traditional tuple-space model since it exploits diverse mechanisms for the various W4 fields and it also enforce context-aware queries.

5.1.2 W4 Knowledge Networks Although pattern-matching techniques proved rather flexible to retrieve context information, the key idea is to exploit the W4 structure to perform some semantic data organization, aggregation and pruning in order to extract meaningful knowledge from existing data. In this way the tuple space acts as a sort of "live layer" turning raw it data atoms into expressive knowledge atoms representing a situation from a higher-level perspective.


D5.4


of 91

In particular, new information could be produced by navigating the space of W4 tuples, linking together existing tuples (to create sorts of knowledge networks), and consequently combine and aggregating existing tuples into W4 tuples. Such new knowledge could also arise from the analysis of the historical context (e.g., the location where a person spends 8 h every day could be his workplace) or from a wide analysis over the whole W4 repository (e.g., If nobody go to work on 2007/12/25, it could be an holiday).

The W4 knowledge networks approach is based on the consideration that a relationship between knowledge atoms can be detected by a relationship (a pattern-matching) between the information contained in the atoms fields.

In particular, for the W4 model, we can identify two types of pattern matching correlations between knowledge atoms:

Same value - same field: We can link together W4 tuples belonging to the same user, about the same place, activity or time (or, more in general, those W4 tuples in which the values in the same field match according to some pattern-matching function). Matching two or more same value -- same field relationships, we can render complex concepts related to groups of W4 tuples, e.g. All students (same subject) who are attending a class (same activity) at the same room (same location).

Same value - different field: We can link atoms in which the same information appears in different fields. This kind of pattern matching can be used for augmenting the expressive level of the information contained in the W4 tuples. For example, a knowledge atom having When: 18/09/2008 can be linked with another atom like Who: Fall Class Begin, When: 18/09/2008 to add semantic information to that date.

Exploiting those correlations it is possible to find all relationships between one particular W4 tuple with all other tuples in the data space and this may be used as the basis for more elaborated inference and reasoning and for eventually creating new W4 tuples. In fact, the links between W4 tuples usually enables to build a higher-level, more expressive tuple. More examples can be found in [D5.3] and [CasMZ08].

5.1.3 The Knowledge Overflow Problem The W4 system and assumes a naive approach to knowledge inference. In essence, it constantly generates knowledge from current atoms (raw data) independently of the knowledge being required at a particular point in time. Whenever a W4 tuples are linked together, the system tries to generate a new tuple expressing the higher-level concept derived from the merging of the tuples. The result could be an overflow of tuples inferred by the system which may or may not be needed in the future. In fact, with this approach, while useful tuples are indeed generated, also a lot of tuples generating ―useless‖ knowledge are of course generated. In the worst case scenario, the knowledge inference process produces a number of tuples as specified by equation (1), which indicates that the number of atoms (tuples) at time t + 1 is the accumulation of the number of atoms in the previous step t plus the number of new tuples that can be inferred (knowledge inference) .

𝑁(𝑎)𝑡+1 = 𝑁(𝑎)𝑡 + 𝑁(𝑎) (1)

where

∆𝑁 𝑎 = 𝑁(𝑎)𝑡∗(𝑁 𝑎 𝑡−1)

2 (2)


D5.4


of 91

Obviously, the equation (2) assumes that all current atoms can be combined among themselves—this should be seen as the worst case scenario. It accounts for all pairs of tuples being considered in the generation of a new tuple (inferred knowledge).

Figure 44: This figure depicts the worst-case scenario of knowledge generation.

Figure 44 shows tuples being generated as part of a naive inference mechanism as implement in W4 currently. As one can see the number of tuples in the system grows very rapidly (Note that for clarity, not all arrows are shown in the transition from the second to the third step). This redundant generation not only is unnecessary but, if not corrected, can cause the W4 system to lose efficiency because it has to deal with a very large number of tuples.

The alternative to this is to have a mechanism that uses self-organization to drive the inference of tuples. In essence one can assume that at every time step, not all tuples are used in the inference process. Which means that that the ∆N(a) in Equation 1 is changed to consider only some of the tuples in the space rather than all of them. The number of tuples used in each time iteration t does not have to be fixed and may depend on W4 system factors.

Figure 45: This depicts a case where just some of the tuples participate in the knowledge inference at every step.

In Figure 45 we see the effect of having just a few tuples being used in the generation of new knowledge. In the first step, out of 4 tuples, 2 were used to generate knowledge, and in the second step we considered 3 tuples out of the 5 that were present in the system. The obvious outcome is that significantly less tuples are present in the end (step 3). Note that we are not considering the quality of the information generated. Some quality is achieved based on the self-organized mechanism that can consider the type of knowledge that is needed in the system but for now we want to concentrate on a mechanism to avoid the unnecessary generation of too many tuples.

We have run some experiments in W4 to demonstrate that what we describe above does indeed happen in practice. We have simulated what happens in a standard day at the


D5.4


of 91

Engineering Campus of UNIMORE (Reggio Emilia site). The Engineering campus is supposed to be tagged with a number of RFID tags, each tag containing a W4 tuple describing a point of interest or a location at different levels of granularity such as offices, class rooms, etc. People acting in the campus (students, professors, staff) are supposed to carry a PDA equipped with a short-range RFID tag reader, a GPS and a WI-FI connection, as the system described in [Cas07]. The PDA is in charge of periodically (in the simulation every 5 minutes) creating a W4 tuple describing the situation in which the user is, the W4 tuple is then sent to a W4 centralized remote tuple space. W4 tuples come also from agents that analyze the faculty web site and create tuples with classes schedules, buildingsinformation, events and so on. In the experiments the W4 knowledge network continuously scans the tuple space to retrieve tuples that:

are in the campus area (based on GPS coordinates in the where field)

are in the campus area (based on a logic description in the where field)

are in a building (based on a logic description in the where field)

refer to attending a class (based on the where and when fields)

happens in a day of the week (based on the when field)

We have simulated a campus environment by keeping trace of the tuple space size at the end of each W4 knowledge networks iteration. Figure 3 shows the cumulative value for the tuple space: during the first iterations the number of tuples increase quickly, then it continues to increase (as new tuples are continuously injected and the knowledge networks act on those tuples) but at lower rate.

Figure 46: The knowledge overflow effect on the W4 system: cumulative values

Figure 47 shows the generation rate for the same data depicted in Figure 46. It is clearly visible that the generation of tuples is growing fast in the beginning, and then it adjusts to a constant trend. It has to be noted that the knowledge overflow effect is clearly visible even in a small-scale scenario as the campus we simulated. In a bigger campus, i.e. a campus with more students and more infrastructures, it should be even more prominent.


D5.4


of 91

Figure 47: The knowledge overflow effect on the W4 System: the generation rate

The previous graphs show that even when dealing with a small number of tuples and a limited Knowledge Network activity the number of tuples quickly increases and can rapidly become overwhelming.

5.1.4 A Self-Organizing Approach to Controlling Overflow The simple examples described in Section 5.1.3 show that, if no action is taken to curtail the generation of knowledge, pervasive systems are likely to become impractical since the amount of data present at any given point can be overwhelming (at least for real-time exploitation of such data by pervasive context-aware services) it is clear that big data centres can perfectly manage such amounts of data in an off-line fashion. This problem is even more pertinent if we assume that pervasive environments are made of many devices whose computational power is limited. Therefore one has to control the influx of data from knowledge generation as well as improve the visibility of data that is required in the system.

The question then is how to control data generation and visibility in pervasive systems. Given the sheer scale of such environments, it is impossible to have a centralized process in charge of making decision about what should and should not be generated. The proposed approach introduced in this paper is to let the system self-organize in response to request being made. In other words, the knowledge generation process of W4 should be driven by system activity and by user needs for certain types of knowledge.

When one talks about self-organization it has to identify the particular metaphor that is being used. There are many metaphors inspired by a diverse set of biological and physical phenomena [MMTZ06]. In our case, we have adopted an approach based on ant foraging. As described in [MMTZ06] this approach uses a marker-based approach where individuals stochastically explore possibilities and self-organize their activities of searching for food.

In particular, we maintain markers about the need for tuples based on queries. The system then stochastically decides to generate knowledge based on these markers. In essence this means that the self-organized process in the system will tend to infer knowledge that are needed in the system (based on current queries). Obviously, as in most self-organized approaches a second force needs to drive the self-organized behaviour. The queries act as positive feedback that is used to drive knowledge generation of a particular format, but the markers used to drive the generation need to have a time-to-live otherwise a burst of queries of a certain format can forever drive the system in that direction. Accordingly, the markers are updated using a known rule proposed in ant-colony systems, as from equation (3), which


D5.4


of 91

states that the amount of marker for a given query format M(qf) is decreased by a rate ρ and increased by an amount ∆M(qf) which accumulated in the last iteration of the system.

𝑀 𝑞𝑓 𝑡+1 = 𝜌𝑀(𝑞𝑓)𝑡 + 1 − 𝜌 ∆𝑀(𝑞𝑓) (3)

Our self-organized approach to tuple generation with overflow control uses all the markers for all query types to decide which type of knowledge is currently needed in the system. This decision is stochastically and proportional to the amount of a particular marker in relation to all the markers in the system.

5.1.5 Simulation Results To evaluate the improvement introduced by our approach we performed simulations based on the scenario introduced in Section 5.1.3.

We used a query generator submitting non-destructive queries to the system every 250 milliseconds. For the sake of implementation we considered markers of the following kind:

<student:id, - , - , - >

where the marker is identified by the value of who field. To analyze the performance and the reactiveness of our approach system we considered two non overlapping pools of tuples: poolA and poolB (both are made up of three tuples). The query generator works accordingly the following pattern:

• phase 1: 90% of queries are about students in the poolA, remaining are uniformly distributed among students that are not in poolA

• phase 2 (transition phase): 60% of queries about students in the poolB, 30% of queries about students in the poolA, 10% of queries uniformly distributed among students that are not in poolB

• phase 3: 90% of queries are about students in the poolB

The W4 tuple space engine has been modified to keep track of the most relevant markers. This has been done introducing a system hash table that keeps the number of queries for each queried marker, and modifying the read operations to update the hash table every time a query is submitted to the system. Every time that a tuple is inferred by the system, the thread that is in charge of managing that new tuple will actually inject the new tuple in the system accordingly to the generation percentage calculated on the hash table. So, inferred tuples relating to highly queried markers are likely to be generated and inferred tuples relating to low queried markers are not likely to be actual generated. To better evaluate the improvement introduced by the self-organizing generation of new knowledge we considered the particular case in which the W4 knowledge networks scans the tuple space to retrieve tuples to meet one single relationship. We chose the ―attending a class‖ relationship. The following graphs are relative to this particular case.


D5.4


of 91

Figure 48: Cumulative number of tuples in the tuple space when the W4 Knowledge Network scans the systems to meet a single relationship.

Figure 48 shows the cumulative value for the tuple space and compares the value with the the upper bound (i.e. inferred tuples are always injected in the system, this is the W4 system behavior depicted in Figure 46 and with the lower bound (i.e. inferred tuples are never injected in the system). Figure 48 clearly show that the amount of inferred tuples is a way lower than the upper bound.

Figure 49 shows the number of tuples generated and injected in the iteration time. The graph shows that after the initial peak the number of tuples grows based on the query pattern. In particular it is clear that the number of tuples grows a little at the first iterations of each query phase when there is not a highly preferred marker and all markers have a low generation rate.

The previous graphs show the situation regarding to the whole tuple space. We also analyzed the trend of tuples in poolA regarding to tuples in poolB.

Figure 49: Number of tuples generated and injected in the iteration time when the W4 knowledge networks scan the systems to meet a single relationship.

Figure 50 shows the number of tuples generated and injected in the iteration time for tuples in poolA and tuples in poolB. In those simulations the system has memory, i.e. the value ρ in 3 is zero. The yellow lines indicate the beginning of a new query phase, as explained at the beginning of this section. The number of tuples in poolA is greater in both the first and the


D5.4


of 91

second phases, while in the third phase the number of tuples in poolB increase quickly. This system has a slow response as we would like the number of tuples in poolB increasing since phase 2.

Figure 50: Number of tuples generated and injected in the iteration time, tuples in the poolA Vs tuples in the poolB.

5.1.6 Conclusion In this Section we discussed the knowledge management issues that may affect pervasive computing systems, in which high-level information are combined and inferred from raw data, thus possibly leading to knowledge overflow. We have proposed a self-organized approach to control the knowledge generation process and provide promising evaluation results for a specific pervasive framework based on the W4 contextual data model. In particular, we have shown that a self-organization approach have proven to significantly reduce the number of tuples (i.e., exactly those not very useful) that are being generated as part of the knowledge inference process.

However, in our system, the number of tuples present in the system is still non-decreasing except for tuples that are removed as part of explicit destructive queries. For long-running systems, this can represent a problem. Accordingly, we plan to experiment with a concept of knowledge tuple fading, as introduced in [MW06], to W4. There, tuples would decrease in importance and hence be less likely to be considered in the knowledge inference process. The more a tuple is required in the system, the more visible it is, which means that tuples that are not being used become less visible (they fade). We are currently working on the implementation of this concept in W4 and we are confident this will improve the system‘s ability to infer knowledge that is required by processes in a true self-organized fashion.

5.2 Learning in Heterogeneous Sensing Systems The aim of this research thread in WP5 is to experiment with the idea of a general approach to embed self-training capabilities within the knowledge networks, i.e., within the knowledge atoms (or the sensors corresponding to them – for the discussion in this section we can use the two terms indistinguishably).

The basic idea is having sensors to exchange information and to learn a model of some environmental properties under observation. Such a model can then be used to classify events of interest and take actions on the basis of a high-level representation of the system context. This would allow pervasive information and communication systems using the


D5.4


of 91

model to autonomously adapt to highly dynamic and open environments. In particular, as depicted in Figure 51, different sensors can exchange information to build a representation of what is happening in the environment. Once the model has been built, some information can be spread to help other sensors to construct a model to interpret their data readings in turn.

More in detail, the approach we propose lets sensors cooperate to create a model to classify some signals. For example, a ―trained sensor‖ (one having already a classification model) can provide ground truth information to an ―untrained sensor‖ (one able to produce raw data only) to enable it running a learning algorithm on its data and become a ―trained sensor‖ itself. The core idea is to use labels coming from on sensor type to train another sensor type.

Figure 51:A user moves between two distinct pervasive environments, this allows pervasive information and communication systems using the model to autonomously adapt to highly

dynamic and open environments.

5.2.1 Description of the System In our framework, every kind of sensor is modelled by means of three modules: (i) a data acquisition module dedicated to raw data sampling, (ii) a learning module that collects the training data set pairing raw data with external data labels, and runs a learning algorithm to create a classification model of the data, (iii) a classification module that takes the model from the learning module and use it to classify new raw data (see

Figure 52).

All the components participating the process can be divided among three categories:

• Trained sensors. These sensors successfully completed the training phase of their classification algorithm or do not have a training phase at all (i.e., the classification algorithm is hard-coded). Trained sensor can sample data from the environment and produce high level events based on the classification of their inputs. These events are pushed towards a tuple space (described below).

• Untrained sensor. These sensors are not trained yet. They sample data from the environment and store them into a buffer. Each entry of this buffer is composed by two elements. The first one is the feature vector, while the second one is initially empty and should be filled with a classification label. The training process ends when enough entries of the circular buffer are properly filled with a feature vector and the corresponding label, and the learning algorithm has been executed. At this stage, the


D5.4


of 91

sensor can start to sample, classify and publish brand new events (i.e., it has become a trained sensor).

• Tuple spaces. Every pervasive environment has to be provided with a tuple space. It receives high level events from trained sensors and forwards them to every untrained sensor that can use them. To avoid broadcast communication while keeping the overall system easy and clear, tuple space‘s information access is arbitrated by a publish-subscribe mechanism. Trained sensors can freely publish their events. Untrained sensors have to subscribe a template to define the events which they are going to use. Due to this, it is possible to realize a complex environment populated by a huge number of sensors monitoring different aspects of the environment. It is worth noting that, using this mechanism, multiple trained sensors can be coordinated to jointly train multiple untrained sensors.

The combined use of the above components (together with standard learning algorithms) allows to fulfill the idea of a self-training sensors‘ ecosystem outlined in the introduction. In particular different sensors can exchange information to build a model of what is happening in the environment by means of the tuple spaces.

Figure 52: Functional blocks of the system.

5.2.2 Implemented Use Case

To verify in practice our ideas, we implemented a specific use case: train a body-worn accelerometer sensor to recognize motion states starting from a trained camera sensor. We are basically interested in recognizing the following motion states: ―walking‖, ―running‖, ―standing still‖ and ―falling down‖. These states can be recognized either by a camera sensor running a video analysis algorithm [CCP05] or by analyzing the acceleration patterns collected by the body-worn low-power accelerometer sensor [DP03].

We used a PC with attached an analogue camera and a Crossbow MicaZ mote equipped with the MTS310 sensor board. In particular:

• The tuple space runs on a dedicated server.

• The camera sensor acquires data and forwards it to a server running the classification module.

• The accelerometer sensor consists of two coupled MicaZ motes able to acquire data and to run the classification module. The motes send data to a server where the learning module is executed. The fact that the classification module of the accelerometer sensor actually runs on one of the MicaZ devices allows to classify the acceleration data even without the availability of any supporting infrastructure.


D5.4


of 91

It is worth noticing that functional modules depicted in Figure 52 can be spreaded over the tuple spaces. By this way, load intensitive tasks (e.g., computer vision algorithms and EM) can be executed over high-performing devices and lighter processes (e.g. online classification)over mobile and low-performing ones.

We deployed a trained camera sensor able to recognize the aforementioned motion states and configured it to upload arising events to the tuple space. Then, we introduced a second, untrained, body-worn accelerometer sensor. Once it first enters the camera field of view, it subscribes to the tuple space to receive the labels coming from the camera with information about the user motion state. Acceleration data and camera-based classification are paired together and a model to classify the user motion state on the basis of the sampled acceleration data is built on the fly.

Thanks to the labels coming from the camera, the whole system uses an unsupervised learning algorithm, therefore, no manual intervention is required.

From that moment on, the accelerometer becomes a trained sensor: other than producing raw data, can produce high-level labels describing the user motion. This classification can proceed even when the sensor exits the area covered by the camera.

5.2.2.1 Accelerometer Sensor

Learning Module

Accelerometer signal is aligned with the camera one. Once an event is detected by the camera, it is notified to all the subscribing sensors with neglibile communication delays.

The output signal T = {ax, ay, az} provided by the accelerometer consists of the separate accelerations along the three axes x, y and z. To simplify the representation and reduce the dimensionality, the magnitude A of the sum vector is obtained. In addition, processing the non-oriented scalar magnitude would produce results independent on the actual way the accelerometer is worn and, thus, its orientation.

As stated in [DP03], the power spectrum of the magnitude A can be a good feature to use. First, the time series AS = {A} provided by the accelerometer is analyzed in the frequency domain through the FFT (Fast Fourier Transform) transform. To reduce the computational load, a small 64 element window with 32 samples of overlap is used. From these 64 elements, one 32 element power spectrum is produced. Ultimately, the DC component is cancelled since it affects numerical stability. Summarizing, this procedure converts a time series AS defined in the spatial domain on R to a time series X defined in the frequency domain on R31.

Our cooperative learning approach assigns automatically a label/class to untrained sensor data using the posterior-based classification provided by the trained sensors. Thus, data coming from both types of sensors are paired to build the training set TS = {S1,S2, .., Sntr}, where ntr is the total number of samples in the training set and represents the i-th sample and is composed by the 31-dimensional accelerometer observation X and the corresponding label C provided by the camera with a majority-voting process.

Following a generative model, we first solve the inference problem of determining the class-conditional densities p(X|Ci) for each class Ci individually. Thus, let Xc be the set of accelerometer observations in the training set associated in the labelled data to the class Ci. This likelihood can be modelled with a 31-variate mixture of Gaussians (MoG).

In order to estimate its parameters, we employ the well-known EM algorithm and chose to keep the number of MoG components K fixed to two. This choice has been validated by a


D5.4


of 91

thorough experimentation which demonstrates that increasing K brings no benefit to the performance.

One important optimization we performed is to force the MoG 31x31 covariance matrices to be diagonal, thus assuming that the 31 Fourier components are statistically independent. This notably reduces the size of the parameter set A used to represent the model, making A storage on the tiny memory of the body-worn sensor possible.

Classification Module

The set A of estimated parameters is stored in the mote to be used for motion pattern classification during the on-line testing phase. Since the accelerometer is now trained the on-line classification of a new sample is simply performed by applying Bayes rule and MAP (Maximum A Posteriori) framework:

Cnew = Cs s = arg max p (Cr |Xnew , A) (1)

where, assuming uniform sample‘s priori, the posterior class probability can be written as:

p (Cr |Xnew , A) ∝ p (Xnew |A, Cr ) p (Cr |A) (2)

The first term in the right-side of equation 2 corresponds to the MoG for a given class Cr with parameters ACr, while the second term can be simplified as p(Cr ) since there is no dependency of the class on the MoG‘s parameters. The term p(Cr ) represents the prior of class Cr and can be computed as the normalized occurrence of that class in the training set.

5.2.2.2 Camera Sensor

Our system is also provided with a standard fixed color camera. The classical computer vision flow considers first to segment moving objects (segmentation), then to track them on the field of view of the camera (tracking), and ultimately to analyze the objects to classify them and to infer their behavior (object analysis).

In order to define a general-purpose approach, we have defined a framework where visual objects are classified into three classes: actual visual objects, shadows, or ―ghosts‖, i.e. apparent moving objects typically associated with the ―aura‖ that an object that begins moving leaves behind itself.

Here, we describe an approach of appearance-based probabilistic tracking, specifically conceived for handling all occlusions. The algorithm uses a classical predict-update approach. It takes into account not only the status vector containing position and speed, but also the Appearance Memory Model AMM and the Probabilistic Mask PM of the shape. AMM represents the estimated aspect (in RGB space) of the object‘s points: each value AMM(p) represents the ―memory‖ of the point‘s appearance, as it has been seen up to now. In the probability mask PM(p) each value defines the probability that the point p belongs to the object.

Without going into much details, these two features are used both to perform the matching between the existing tracks and the objects detected in the current frames, and to detect the presence of occlusions. Occlusions are detected by analyzing a measure of confidence and likelihood computed on the probability mask PM.

Classification Module

Given the observation, the algorithm bases its classification on the analysis of the tracked person. It is worth noting that the computer vision algorithm is capable to track multiple targets but needs to associate that (or those) target(s) wearing the accelerometers with the corresponding target ID(s). Thanks to sophisticated tracking algorithms, the distinction


D5.4


of 91

between ―standing still‖ (class S), ―walking‖ (class W) and ―running‖ (class R) is almost straightforward. Given that the frame rate is constant, the movement speed can be easily estimated, even though perspective distortion can affect strongly the estimation. Let h and v be the height of the bounding box and the velocity of the tracked person, respectively. The velocity is estimated through the distance (in pixels) covered by the person‘s centroid. Finally, the classification of falling people is performed by looking at the variation of the height of the bounding box.

Figure 53: A snapshot of the multi-sensor training set we used. Camera‘s classification labels and ground truth are superimposed over acceleration time series.

5.2.3 Experimental Results To evaluate the performances of our system we did several tests.

First, we recorded with the camera a person moving inside our department, acting in several motion states. At the same time, the same person wore the accelerometer sensors on his belt. While the scene was recorded, we manually collected the ground truth. The camera sampled at 30Hz, while the accelerometers at 100Hz. We reported in Figure 53: A snapshot of the multi-sensor training set we used. Camera‘s classification labels and ground truth are superimposed over acceleration time series. a snapshot of the data we collected in this experiment. This plot shows the three accelerations (on X, Y and Z direction) with superimposed both the ground-truth and the camera classifications, in order to show the correspondence of accelerations‘ changes with motion variations.

Fall Stand Walk Run

Fall 84.27% 8.70% 4.76% 2.28% Stand 0.00% 86.43% 13.00% 0.57% Walk 2.71% 0.48% 94.81% 2.00% Run 0.43% 9.12% 1.72% 88.73%

Table 1: Confusion matrix of camera sensor classification.

We used these data in two ways. First, we compared the labels produced by the camera with the ones manually collected to measure the computer vision algorithm performances (see Table 1). Looking at the reported confusion matrix of the camera sensor classification, it is possible to see that the vision algorithm works pretty well, having a precision of 88.59% and a recall of 88.56%.


D5.4


of 91

Second, we measured the classification performance of the accelerometer, once it has been trained with the labels coming from the camera. We compared the labels produced by the accelerometer with the ground truth to obtain the confusion matrix reported in Table 2: Confusion matrix of accelerometer sensor classification. Overall the classification has a precision of 85.25% and a recall of 69.50%. The poor performance on detecting falls (that contributes also to decrease the overall recall of the system) is due to the fact that the falling action is composed of a transient phase in which the accelerometer values can vary significantly. A more correct modelling of this action is to take the sequence of observations into account, for instance with a HMM.

Figure 54: Graph showing accelerometer classification performance with respect to the camera classification errors.

Although accelerometer classification performance is quite good, it is possible to see a reduction of performance with respect to the vision classification. This is due to two simple facts: first, a belt-worn accelerometer produces a signal that is less descriptive than a full-fledge video sequence. Accordingly, the features extracted from the acceleration signal are less capable of discriminating among high-level behaviours (e.g., falling and walking) than the video sensor. Second, the accelerometer is trained with labels coming from the camera sensor and thus it is affected also by the errors coming from the camera.

However these considerations have to be applied only to the algorithms we used in this use case which are not the main contribution of this paper. It is worth considering that the framework we propose can support a multitude of others algorithms which would perform much better.

Fall Stand Walk Run

Fall 15.00% 21.25% 63.75% 0.00% Stand 0.00% 77.63% 22.37% 0.00% Walk 0.00% 1.96% 97.20% 0.84% Run 0.79% 0.79% 10.24% 88.19%


D5.4


of 91

Table 2: Confusion matrix of accelerometer sensor classification.

To better understand the contribution of this latter source of errors, we conducted another experiment aimed at evaluating the robustness of the approach with respect to the camera classification errors.

We run a number of learning phases of the accelerometer data, passing to the accelerometer learning module increasingly corrupted class labels: we corrupted the ground truth information with errors sampled accordingly to the camera sensor confusion matrix reported in Table 2. Then, we tested the accelerometer classification performance. The graph in Figure 54 shows on the x-axis the percentage of errors introduced, varying from 0 to 100 percent. Precision and recall are reported on the y-axis. As expected, classification capabilities are highly correlated with the quality of training data. Introducing an error of 20% halves the precision and recall levels.

To summarize the discussion about the performances of the system it is possible to see that: (i) the algorithms proposed to track moving persons and classify their motion state are suitable for this application scenario; (ii) the algorithm we choose to classify acceleration data is working properly; (iii) our idea of a self-training sensor ecosystem is feasible and could help to reduce resources needed to deploy near-coming smart cameras and sensor networks infrastructures.

5.2.4 Related works In [BM98] was first proven that under certain condition is possible to exploit classification labels coming from a classifier to train another one. Since unlabeled samples can be obtained significantly easier than labelled samples the main goal would be to take advantage of the statistical properties of the labelled and unlabeled data by using a semi-supervised approach. Hence, a seed classifier that was trained from a smaller number of labeled samples, can be improved by taking into account a large number of available unlabeled samples.

The work described in [WLT06] presents a multi-modal, multi-sensor classification system using body-worn microphones and accelerometers. Sensors‘ outputs are independently classified and their values are merged together using different kinds of information fusion mechanisms. Other than the choice of sensors being used (we use cameras instead of microphones), the main conceptual difference between this and our work is that we combine sensors also in the learning phase, following the cooperative learning paradigm described above. Moreover, our system has been designed to allow also the individual sensors (especially the accelerometer) to work in isolation.

Another interesting work in the direction of multi-modal multi-sensor motion classification is presented in [KIH07]. This work combines accelerometer-based classification with data coming from a RFID-glove reporting information about the (RFID tagged) objects touched by the user (e.g., if the user is touching a tooth-brush, it is unlikely that he is running). The main difference with our proposal is that while this work focuses only on the classification algorithms we propose a general framework not tied with specific solutions.

Although the general idea of the training sensor ecosystem is not bounded to specific pattern recognition algorithm, it is worth reporting some works at the state of the art in this area. In fact, our proposal is intended to let these algorithms to cooperate with each other seamlessly.


D5.4


of 91

The analysis of human movements has been a very active research area in the computer vision community. Gavrila in [DMG05] surveyed the existing approaches to whole-body or hand motion analysis. Generally speaking, most of the reported approaches focus on specific human motions and are heavily based on a model used for the system training.

Ultimately, recent advances in statistical pattern recognition and computer vision techniques contribute to a new era of research on human motion understanding, as demonstrated by the quite recent special issue on Computer Vision and Image Understanding journal [HFR06]. As an example among the many existing proposals, Robertson and Reid [RR06] model human behaviors as a stochastic sequence of actions and evaluate the likelihood by using HMM. The observations come from position, velocity and motion descriptors and matching is performed against a labelled database of actions.

5.3 Stigmergic Linking Stigmergy is a term that is used to describe the actions of simple entities that, by reacting to their environment, can collectively achieve more intelligent behaviours.

In [D5.3] – Section 9 Stigmergic Knowledge Querying, an initial report has been presented addressing the use of stigmergic principles in order to self-optimise query response times. This work has been extended to address additional stigmergic-based network optimisation and reasoning capabilities. The final report of this research, including a detailed evaluation of the principles discussed is presented in this Subsection, is followed with additional results on the application of stigmergic knowledge principles (in Subsection 5.4), and is concluded (in Subsection 5.5) by introducing a cognitive model for dynamic networks that could allow for a higher level of reasoning within such networks. While this work has been undertaken within the context of autonomic context aware services and information networks it has not yet been incorporated into the ACE Model or the Knowledge Network toolkit extension.

5.3.1 Stigmergic Linking for Optimising and Reasoning Over Information Networks

The aim of this work is to evaluate a mechanism to allow an information network to optimise itself dynamically. One objective of the work is that the network structure should remain lightweight and so the organising mechanism should also be lightweight. To this end stigmergic links are used. Stigmergy is an experience-based mechanism of learning from its environment. The context of the work is to use stigmergic links to optimise the network with regard to querying. In other words, the network will learn what nodes to link together in order to optimise the querying process. These source clusters will represent the knowledge of the users of the system and will optimise knowledge retrieval by indicating specific sources to retrieve. Thus knowledge will be entered into the system without the need for an internal knowledge-based algorithm. This is appealing because the use of the network may not be known beforehand, or may change through time and so some form of dynamic knowledge construction will be able to adapt to a changing situation. The types of network to be considered are distributed information-based networks, such as the Internet or a Mobile or Ad-hoc network (MANET), where a user would typically be required to query the sources to retrieve information from such a network. Another fitting example is that of Knowledge Networks. The rationale of the knowledge network is to act as a middle layer that connects to a multitude of sources, organises them based on various concepts and finally provides well-structured, pre-organised knowledge to individual services and applications. The main features of this structure are its generic, lightweight and service-based architecture. The service-based architecture allows for services to be added that can perform any kind of


D5.4


of 91

functionality over the network knowledge. This is very flexible and will allow many different kinds of network to be constructed from certain base components. The knowledge network will organise itself in an autonomous manner through the results of query requests, to create temporary views that reflect the use of the system. Figure 55 is an example of a knowledge network related to the concept of Sport.

Figure 55: Sport Knowledge Network

This network is clearly hierarchical in structure, where it is organised based on the semantics of the contents. Thus a Football node is a sub-node of a Sport node and Premier and Sunday-league are sub-nodes of the Football node. These semantics provide a relatively lightweight and distributed ontology in which to describe the network contents. The hexagonal structures at the bottom represent actual information sources that bring information of any kind into the network.

The challenges faced for querying the knowledge in this type of network are as follows:

For the emerging pervasive/sensor-based environment, a lightweight framework is being considered. Ontologies, typically used to represent knowledge, thus need to be created in a relatively lightweight way.

The querying needs to be distributed, retrieving information from several sources. This requires the query to be constructed dynamically from partial results as it is executed.

The organisation must be autonomous and should not assume any prior knowledge of the environment. The system is to be generic, stigmergic and self-organising.

The potential size of the network could be huge, so some query optimisation, directing the search to the most relevant sources, would make a querying process more practical.

While the hierarchical structure is useful for permanent organisation of the knowledge based on semantics, it does not provide complete organisation. One problem is the potential number of similar sources. For example, Figure 55 shows two sources related to the Cricket node. Each source, for example, might represent a different team. If a user asks about Cricket, then the network might need to look at all teams. However, if through links certain sources can be indicated, then the query process can be significantly reduced. The other problem with this ontology construction is that it is still knowledge-based. Stigmergic links will also be able to link sources that are not obviously related through semantics or other comparisons and so can dynamically link what would otherwise be completely unrelated concepts. For example, maybe a Football and Rugby Club use the same stadium. This adds an extra dimension to the optimisation process and so long as the links are sensible, they can be reliably used. One potential application area might be the health service, as has already been suggested by Cameron et al. [CTB04].

Sport

Cricket Football Rugby

Premier Sunday-league

International

Club

Knowledge Container


D5.4


of 91

This environment might have a large number of databases with records of patients etc. that could be electronically retrieved and linked through queries. Another area is the Semantic Web [BHL01]. Instead of a user asking to retrieve a single web page, he may ask for information that relates to several web pages. These pages would need to be retrieved and associated together. Thus a way of selecting the best pages to use and link would be useful. This report will also suggest a new cognitive model strongly based on the stigmergic linking principles that will allow for different levels of reasoning over the stored information. Thus the information will become more useful and the network will be able to autonomously carry out intelligent acts by itself.

Mano et al. [MBL+06] have discussed the principles this work is based upon for linking with respect to stigmergy, self-organisation and reinforcement. While this paper has described the process as being stigmergic, others might argue that it is more like the Hebbian learning rule, which states that concepts that are activated simultaneously become more strongly associated. This method has been used by Heylighen and Bollen [HeBo02], although their method of clustering seems to require manual user interaction rather than an automatic query process that compares specific values. Stigmergy has been used widely to self-organise in MANETs. These networks are highly dynamic and need a flexible and robust mechanism that can adapt and allow them to self-organise. As these systems can be on a massive scale, some centralised controlling mechanism may not be practical. Babaoglu et al. [BCD+06] and Breukner and Parunak [BrPa04] are papers that discuss this problem. This self-organisation may not lead directly from the querying process but would involve information sharing, though Babaoglu et al. [BCD+06] discusses organising through queries that contain sets of keywords. The architecture of Sartiani et al. [SMGC04] is close to the network architecture suggested in this paper. Although, wherever possible, they do clustering based on schema similarity, they note that it is also possible for peers with unrelated schemas to be clustered together. Their super-peers also allow for a hierarchical structure. However, the organisation is slightly different as the super-peers do all of the autonomic clustering. The source clustering tested in this paper is not hierarchical, but there is no reason that container nodes could not also cluster using the links. Dragan et al. [DGY05] is also relevant, as the dynamic linking of sources will also in effect reroute queries. Another example can be found in Vidal et al. [VRM04] or Raschid et al. [RWL+06]. They apply linking to the problem of optimising routes through web resources in the area of Life Sciences. In this set of resources, there are known to be different routes to different resources that may answer the same query.

An example of linking based purely on the query experiences includes Koloniari et al. [KPP+05]. They try to cluster nodes in a peer-to-peer network based on query workloads. They measure how similar a node‘s content is to a type of query, which will mean that it is more likely to return an answer to that type of query. They then try to cluster nodes with similar workloads together in workload-aware overlay networks. They describe that the mechanism for calculating the workload value is still an open issue and could be based on a node storing statistics on the queries that pass through it. Michlmayr et al. [MPG06a,b] is also along the lines of Kolonari et al., where they stigmergically create links between nodes based on query requests. The requests consist of sets of keywords and they try to cluster documents in repositories and optimise routes based on the requests. Another system that tries to associates nodes based on the query experience is called NeuroGrid [Jos02]. Robinson and Indulska [RpIn03] describe a service discovery protocol called ‗Superstring‘. Superstring is used to discover services in an extremely dynamic environment but with a stable central core of nodes. This is exactly the environment that we envision for our system. The lightweight framework allows for a dynamic MANET environment, for example, but the


D5.4


of 91

stable central core allows for stigmergic principles to work. They also build up a partial hierarchy based on the semantics of the concepts being searched. These examples however may be more along the lines of a search engine than the evaluation queries tested in this report.

5.3.2 Stigmergic Linking: the WP5 Approach The term stigmergy was first used by the biologist Grassé [Gra59] to describe the behaviour of termites as they coordinate their nest-building activities. An example of stigmergy in Artificial Intelligence is the Ant Colony Optimisation algorithm, for example, Dorigo et al. in [DBT00]. ACO works by copying the actions of ants as they try to find the optimal route from one position to another. They randomly select a number of routes and leave a pheromone behind indicating the route that they took. The shortest route will build up the strongest pheromone amounts and so the other ants will be stimulated to take this route. The ants do not know what the optimal route is, but rather discover it through the experience of all the routes that all ants take. Their reasoning does not require any intelligent knowledge, but only to be able to read the pheromone trail.

A standard ‗Select-From-Where‘ statement can be used to retrieve information. This allows a user to select certain values from certain source types where certain conditions are true. The querying process being adopted here is a two stage process. The first stage searches for potential sources that can answer the query and the second stage then queries the sources to retrieve their values. The first stage can also be used as a search engine, where source references can be stored. Thus if the sources are dynamic (sensors for example) it is better to store the reference and then retrieve dynamically the information when needed. For example if a user asks for sources about International Rugby teams, then the first stage can provide a search of the network and retrieve the path references. A user however can also ask for specific values, for example:

Select Premier.team From Premier, Sunday-league Where Premier.goals GT Sunday-League.goals

The network needs to be fed information that it can use to manage the links and it is proposed that this can be done by using the results of the querying process. The nodes that were used to answer each query can be informed and can update their related link values. Each source can store a structure that records the sources related to it through the querying process. This structure can monitor related sources at different levels by assigning weights to them and allows it to recognise when a new source reference should be included or an old source reference removed. In the context of source linking, a weight is simply a numerical amount associated with a source. It can be incremented or decremented and compared to threshold values. If the weight value becomes greater than a threshold value, then the source reference can move up a level in a linking structure. If a source is found to be used in the same query that the current source was used in, then its reference can be added to a link table in the current source. In one set of tests there was also another entry stored for each link path. This was just a single entry that could store a new source before it was moved into the link table itself. This single additional entry was found to have a significant improvement with regard to quality of answer, but as it was stored for each new linking branch, it was difficult to control the amount of memory used when it was included. Thus it has since been made an optional feature and all new entries can be stored directly in the link structure instead if that is possible. Thus each node can know and manage the exact number of entries that it stores. Only the sources referenced in the top level structure are


D5.4


of 91

considered to be reliable links that should be returned as sources to look at. So there needs to be some degree of consistent association before a source is returned as a link.

5.3.2.1 Linking Methodology

The tests have used a linking structure with three levels. These levels are separate structures that represent possible sources, monitored sources and linked sources. The possible sources structure records new sources that may possibly become links. They need to be associated several more times before they can be called links. The monitor structure is an intermediary structure that stores more advanced possibilities. Having two levels here (possible and monitor) may not be necessary, but it can be helpful for resource management or may allow for initial communication when a source is shown to be related. For example, specific sources can reinforce links when they reach the middle level, even if the whole query is not answered. The linked level is the top level that then stores the references to sources that are actual links. It is these sources that are returned as possible answers when the appropriate query is executed. Each structure can be assigned a limited amount of memory, or number of allowed references, ensuring that it stays lightweight. When this allocation is reached, to add a new reference it must first remove an existing one. Source references are stored with weight values that can be either incremented or decremented. The weight values determine in which level the source references are stored. The weight values must reach a certain threshold value before they can be moved up a level. For example, for the simplest case, say we have a weight increment value of 0.1 and a threshold for the next level of 0.5. If a particular source is associated with the current source 6 times in a row, then its weight reaches the value 0.6, which is greater than the threshold and so its reference can be moved up to the next level. If the same query type is run again however and the source is not used, then its value can be decremented, when it will subsequently be moved down a level if it then falls below the threshold. Additional features are also possible. For example, sources can borrow memory from each other. This means that the total amount of memory stays the same but it is better distributed. More heavily used sources can be allocated a larger amount of memory and thus can more effectively optimise. Learning algorithms might also be included to try and autonomously learn certain parameters, such as the best weight increment or decrement values.

5.3.2.2 Linking Structure

The linking structure itself is meant to record related sources for similar queries. However, it is not a caching mechanism where it stores the whole query with the sources used. It is slightly more lightweight and flexible, where it matches parts of new queries to the structure. The structure can allow for any level of nesting that may be suitable to the current problem. For example, say we have a Premier-league team being linked to Sunday-league teams. If different queries have asked for comparisons related to goals or fouls, then partial query paths like the ones shown in Figure 56 can be stored. At the end of these paths there is a thresholds structure that stores the linked sources at the different levels for the specified path.

Figure 56: Example of paths relating to links for partial queries.


D5.4


of 91

For a distributed environment, the source path will also include a URL to define a remote server, so that there will not be any confusion as to exactly what source is being referenced. The linking structure is a reference-based structure that stores the addresses of nodes rather than the nodes themselves and can be used in at least two different ways. One way is globally in the network itself. It can be used to link sources that typically answer the same type of query. Then when one of the sources is queried, it can return the sources it is linked to and these can be looked at instead of needing to look at all potential sources. The links stored globally thus optimise the whole network and can be shared between all users. The other possible use is as a local view. A particular application may want to store locally references to the nodes that it typically visits for the queries that it typically answers. These may be a subset of the whole network. A description of the nodes visited by a particular application can be stored locally and monitored in the same way as the source links. Then when a new query is executed, the local view can be searched first and if it contains any relevant information this can be used instead of having to search the whole network. This paper will present results of tests evaluating the performance of both the global source linking and local view.

5.3.2.3 Reasoning over the Information

It will also be shown that it is possible to use the links to provide some level of reasoning over the stored information. Queries could be generated to answer questions such as:

what is the best value based on other values?

does a value exist based on other values?

If the user is asking if a certain solution exists, then the query engine can simply check that an answer is possible. If the user is asking for the best answer, then the query engine can average all possible solutions to produce a final answer. In generating these answers, the linking mechanism can be used to provide the knowledge required to reason over the information. The links represent the knowledge of the users of the system. They show what pieces of information the users requested and grouped together. Thus it should be possible to use the links in more knowledge-intensive queries. For example, a user might ask how to get to the next game in the Winter season against a London club. The query might look like:

Select Best Transport.Type From Transport, All_Teams Where (Transport.Destination Equals All_Teams.Team_Location) And (All_Teams.Team_Location Includes „London‟) And

(All_Teams.Game_Season Equals „Winter‟)

Thus through simple mathematical operators such as ‗average‘, a basic distributed reasoning engine can be generated. This has been discussed in more detail in [GBMN07b].

5.3.2.4 Evaluation

Evaluating the impact of stigmergic relations within dynamic information networks requires a large number of objects which can be associated with each other in a very flexible and dynamic fashion. The effort required to realise and evaluate such an environment via ACE‘s has been deemed to high and as a consequence a dedicated test environment has been developed that is specifically tailored to test a Stigmergic based querying process within dynamic information network. The data used to evaluate the tests was generated in a random manner. This includes the network configurations and the queries to be executed. With specified configurations, networks can be randomly generated that are hierarchically structured, as shown in Figure 55. The queries are also generated in a random manner. The tests however require some control over the similarity of the queries to be executed, to


D5.4


of 91

determine how well the linking will do. Distribution bands thus need to be specified for the source and value types. For example, if we have 10 different source types, it is possible to specify that one of three source types should be selected 70% of the time and one of the remaining 7 source types 30% of the time. When a query is randomly constructed, this will skew the specification towards particular query types. The linking specification also needs to be entered, such as threshold values, increment and decrement weight values, or the number of allowed entries in the linking structure. The user also specifies a linking method. This can indicate the type of search process (for example, full search with links), whether to include the comparison operator or single reserve entry in the linking structure, or whether to allow borrowing of memory or learning. The user can also indicate whether to construct and use a view as part of the search process. Note that a separate linking specification can be entered for the view if desired.

5.3.2.5 Test Objectives

With parameters specified it is possible to randomly generate a number of queries and execute them on the network. Each query is evaluated on the network and the statistics that are generated, such as node count or level of accuracy, are stored. When all queries have been executed the statistics can be retrieved and analysed. The objectives of this testing are as follows:

To show that in certain situations, stigmergic linking can be effectively used as part of a query self-optimisation process.

To estimate at what kind of configuration, with regard to query or network variation, might allow effective linking.

To indicate any definite conclusions that can be made from this initial set of tests, with regard to link structure, size and performance.

5.3.2.6 Testing Methodology

[GBMN07a] and [GBMN07b] outline the main algorithms used in the test procedures. These are essentially the query process and linking mechanism. Results from similar linking methods seem scarce, so these tests have compared node count and quality of answer between searches that use links and searches that do not (called a full search). Note that the full search is still guided by the hierarchical structure and storage of previous query evaluations. The only difference is that it will not try to retrieve linked sources. The search strategy was as follows: Two different searches were performed for each query. The first was a full search only and the second was a linked search. The node count and quality of answer from these two searches could then be compared. However, if the linked search did not return an answer and the full search did then the full search node count would need to be added to the linked search node count as part of the linked search. It was assumed that a full search would then be performed to try and return an answer.

The performance of the linking was measured as the amount of reduction in node count and also as the quality of answer returned. The percentage of reduction in number of nodes visited could be measured by comparing a node count from a full search only with a node count from a linked search. The queries requested values from sources that were of the integer type. The evaluation function then tried to maximise the sum total for all source values requested to produce the best quality of answer. As the network is service oriented, the term Quality of Service (QoS) is used to mean the same as quality of answer. The full search has access to all source instances and so should return the best answer. For a linked search, the number of sources looked at would be reduced and so you would expect this


D5.4


of 91

maximum value also to be reduced. However, if the correct links have been established, then a good answer should still be returned. This percentage of reduction was taken to be the reduction in quality of service. When measuring QoS reduction, only queries answered through a linked search were included. If a linked search required a further full search to find an answer, then the answer value would not be included in the statistics. The values were all of type integer, but this is equally suitable for text or concept matching as for numerical comparisons. For example, 10 different integer values can be compared in the same way as 10 different textual words. Then the equivalence matching can apply equally for numbers or for text.

5.3.2.7 Test Cases

Following are the results of tests that give an indication of how effective the linking is likely to be. The tests revealed that changes in configuration parameters could affect the performance and so it is not possible to give a definitive evaluation. The tests also suggested that configuration would require tuning if trying to achieve optimal performance, as linking parameters, such as memory allocation, increment/decrement weight values or threshold values need to be specified or learned. Each value measured was averaged over at least three test runs. The testing focused mainly on the type of query being executed and conclusions will be given at the end of the tests sections. The network configuration was not tested as much. For the linking, the most critical factor is the variety in the query and so this was the main evaluation consideration.

5.3.2.7.1 Test1: Tests with Queries skewed by a 70:30 Distribution

One set of tests was for queries that were skewed with a 70:30 distribution. The linked search either included the extra single entry in a reserve position (reserve entry), or alternatively a view. The reserve entry was a single additional entry for each branch of the linking structure and could be considered as a sort of benchmark that other setups without it should try to achieve. The number of queries executed ranged from 5000 to 50000 queries. This set of tests performed two evaluations.

It compared the reserve entry to a view.

It considered linking effectiveness with respect to text or concept matching in particular.

The network configuration for these tests was as follows:

There were a total of 300 sources in a network with 315 nodes.

There were 10 different source types and 5 different value types.

There were a total of 30 instances of each source type, where each source instance contained all 5 value types.

Each value type could have a range of integer values from 1 to 10.

The distribution for the queries was 0.7:0.3. So for the sources, 70% of the time a source would be selected from one of 3 source types and 30% of the time from one of the remaining 7 source types. For the values, 70% of the time a value would be selected from one of 2 value types and 30% of the time from one of the remaining 3 value types.

For the linking methods, each link level (possible, monitor and link tables) was allowed a total of 50 entries for each source. The monitor level threshold was 0.1 and


D5.4


of 91

the link level threshold was 0.4. The increment value was 0.1, while the decrement value was 0.05 times the increment.

The view size allowed 100 entries for each of the three link levels.

Each query was made up of a maximum of 2 sources in the ‗Select‘ clause and 3 sources in the ‗From‘ clause. If the ‗Select‘ clause had 2 sources, the ‗From‘ clause had 2 or 3 sources.

The queries contained ‗Where‘ clause comparisons with only the equivalence operator. For example A ‗EQ‘ B. No other operators (GT, GE, LT etc) were used.

The reduction in number of nodes searched and reduction in QoS were measured.

Figure 57 and Figure 58 are an example of the results that can be achieved. One of the trends in the graph is for a set of tests where the reserve position was included (reserve) and the other is for a set of tests where the reserve position was omitted but a view was allowed (view). While the reserve entry seems to produce a much better QoS, the view produces a better reduction in node count. The view can limit the number of nodes used as part of the first source retrieval, thus reducing the search afterwards as well.

Figure 57: Skewed Query Test (70:30). Percentage of reduction in the number of nodes searched for queries with the equivalence operator only. Link structures with either a reserve

entry or a view are included.

Figure 58: Skewed Query Test (70:30). Percentage of reduction in quality of service for queries with the equivalence operator only. Link structures with either a reserve entry or a

view are included.


D5.4


of 91

5.3.2.7.2 Test2: Tests with Queries skewed by a 90:10 Distribution

This set of tests tried to determine if more skewed queries could effectively link sources that answered queries with all types of comparison operator. If this is possible then numerical data can also be linked. But because this increases the complexity of the query, the source and value types may need to be skewed more to compensate for this. The reserve entry was not included in these tests but a view was allowed. The network configuration and linking structure was the same as for the previous tests with the 70:30 skewing (Section 5.3.2.7.1). This set of tests:

Compared queries with equivalence only comparisons to those with all comparison types.

Also considered memory borrowing as part of the linking process.

To show the importance of the configuration values, tests were also run with a maximum of 100 entries at the possible links level for each source and 200 allowed link entries in the view. These results were averaged over 6 test runs each. Figure 59, Figure 60 and 5 give the results of these tests.

Figure 59: Skewed Query Test (90:10). Percentage of reduction in the number of nodes searched for queries with the equivalence operator only (eo) or all comparison operators

(ac). Link structures with a view that do (v_bor) or do not (v) borrow memory are included. Number of entries at the possible links level either 50 or 100.

Figure 60: Skewed Query Test (90:10). Percentage of reduction in quality of service for queries with the equivalence operator only (eo) or all comparison operators (ac). Link

structures with a view that do (v_bor) or do not (v) borrow memory are included. Number of entries at the possible links level either 50 or 100.


D5.4


of 91

When considering search reduction, it can be seen that increasing the number of allowed entries at the possible links level has had an effect on the performance. There appear to be optimal levels that then reduce as more queries are executed. For the equivalence only queries, these graphs suggest that increasing the number of updates after 10000 queries or so might actually have a detrimental effect on the effectiveness of the linking and for the all comparison queries, it is after 20000 – 30000 queries. The QoS stays roughly the same, but the search reduction starts to decrease. The reason must be that extra links are being added that are not then helping with the search process. However, if there are only 50 allowed entries at the possible links level then there is not the same reduction in performance. Figure 61 shows the average number of link references stored for all sources, but does not give any indication of the distribution over each source. This number of links can be compared with the percentage of search reduction shown in Figure 59.

Figure 61: Skewed Query Test (90:10). Average number of source links stored for queries with the equivalence operator only (eo) or all comparison operators (ac). Link structures with

a view that do (v_bor) or do not (view) borrow memory are included.

As might be expected, this comparison shows that increasing the number of stored links improves performance, but only up to a point. Figure 61 shows that the link numbers do not reach the maximum of 50 on average that is allowed; but this measurement does not consider individual sources, when more important sources might be expected to store more links. In addition there appears to be an upper limit on the amount of memory that should be used, or even possible performance that this particular linking mechanism can provide. The extra entries at the possible links level must have allowed more variety in the references that make the link level, or alternatively, having fewer allowed entries at the possible links level has concentrated the variety at the link level.

5.3.2.8 Test3: Increase the Network Variability

Other tests tried to test how increasing the network variability might affect the performance. This was done in two different ways. The first was to increase the query range by having more source types or value ranges. The other test increased the number of instances of each source type. The results showed that increasing the source type and value ranges from 5 types and a range of 1 to 20, to 20 types and a range of 1 to 20, showed that performance remained relatively stable. Increasing the number of source instances to 90 also showed the performance remaining relatively stable.


D5.4


of 91

5.3.2.9 Reasoning Tests

This set of tests evaluated the potential of the linking mechanism to provide some level of reasoning over the information stored in the network. To test this, queries that asked the ‗best‘ or ‗exists‘ queries were generated. It proved relatively easy to do this. The query generator would place the keyword ‗best‘ or ‗exists‘ in front a standard information retrieval query. For example:

Select Best A.val1 From A, B Where (A.Val2 LT B.Val3)

The keyword would then tell the query engine to average all of the possible answers to give the best total. Thus all possible solutions would be retrieved and then their values averaged to provide the final answer. For the ‗exists‘ queries, the engine would check that any answer existed. Tests for this used the test 1 setup but varied the skew from 70:30 – 80:20 – 90:10. Figure 62 shows the results of this.

Figure 62: Reasoning test. Percentage range of average answers for a linked search compared to a full search for varying query skewing. Equivalence only (eo) or all comparison

(ac) queries tested.

The results provide an interesting conclusion. The average answers range from values larger than the best answer for a single solution, to values less than that. For the ‗best‘ queries, results showed that the QoS ranged from maybe 10-30% better to around 5-10% worse. The QoS metric tries to maximise the answer total and so larger totals would be preferred. This suggests that the linking ‗intelligently‘ prunes the lower total answers from the search, which the full search would also return. Thus the linked search provides a better QoS as well as node count, depending on your measurement. The assumption here is that the evaluation function considers larger totals as being better. The links are created based on this metric and all queries evaluated using it. Thus if the reasoning queries return larger totals then this is considered as being better. If some other metric is used for the reasoning queries, for example the user wants purely the average of all possible solutions without any sort of skewing, then this metric would not be helpful. There also does not appear to be a direct correlation between the number of answers returned with larger values and the overall percentage value. The number could vary by quite a large amount, with the percentage value varying by much less.

5.3.2.10 Discussions

It is useful to make some initial numerical calculations, to try and determine the relative size of the linking structure compared to possible query variations that could be used. These calculations can be done for the test configuration specified in test1. As there are 10 source types and 5 value types in total, this gives 50 possible combinations. For a completely


D5.4


of 91

random query, each source/value combination thus has a 2% chance of being selected. When the queries are skewed, they can either be skewed by 70:30 or 90:10, where the source split is 3:7 and the value split is 2:3. Table 3 gives the probability that an individual source or value will be selected for a part of the query based on Equation 1. These combinations lead to 4 different bands to which a source/value combination might belong. Table 4 indicates the relative frequency by which a combination from one of the 4 different bands will be selected. The frequency is calculated by Equation 2 and Equation 3 respectively:

Equation 1: probability of being selected = probability for band / number in band.

Equation 2: probability a source/value combination will be selected = (probability source band selected * number in band) * (probability value band selected * number in band) /

(number of sources in band * number of values in band).

Equation 3: frequency = probability for the band / probability for the lowest valued band.

70:30 90:10

Source Value Source Value

Band1: 0.7

Band2: 0.3

Band1: 0.7

Band2: 0.3

Band1: 0.9

Band2: 0.1

Band1: 0.9

Band2: 0.1

P N P N P N P N P N P N P N P N

0.233 3 0.04 7 0.35 2 0.1 3 0.3 3 0.014 7 0.45 2 0.033 3

Table 3: Table showing the probability (P) that a source or value will be selected depending on the band it is in and the probability skew. Also indicated is the number of source or value

types (N) to which this probability relates.

70:30 90:10

Value Value

Band1:0.7 Band2:0.3 Band1:0.9 Band2:0.1

Source F N F N Source F N F N

Band1:0.7 20.25 6 5.75 9 Band1:0.9 293 6 19 9

Band2:0.3 3.5 14 1 21 Band2:0.1 15 14 1 21

Table 4: Table showing the frequency (F) that a source/value combination will be selected from one of the 4 bands by, based on the number in each band and the skew probability. Also indicated is the number of all source/value combinations (N) to which this frequency

relates.

The percentage of all possible links that a source or view can store can also be calculated. As there are 30 instances of each source type, assuming a ‗value-source‘ path for a view entry, a view can store 10 * 30 * 5 = 1500 link combinations. Assuming a ‗value1-source-value2-comparison-source_instance‘ path for a source entry - if a query allows equivalence only queries, then the total number of possible links is 299*5*5 = 7,475 link combinations. If all comparison operators are allowed, this increases to 299*5*5*6 = 44,850 link combinations. From this we can tell that 200 entries in the view means 13.3% of all possibilities can be stored as actual links. For the sources – for equivalence only queries, each source can store 50 references, or 0.7% of all possibilities, while for queries with all comparison operators, this reduces to 0.1%. The actual number stored in the top level as


D5.4


of 91

links rose to around 25, which is 0.33% or 0.06% respectively. These numbers indicate that the linking can be quite effective. For the 90:10 split, Table 4 indicates that a combination from the highest valued band will be selected with a frequency of 293. Although the tests show that the variation is much greater than this, if we reduce the queries to just this upper band we get 29 * 3 * 2 = 174 (source instances number * source types * value types) possibilities for the equivalence only queries, or 29 * 3 * 2 * 6 = 1044 (include different comparison operators) possibilities for the all comparison queries. Test2 thus suggests that the average number stored as links in each source is just under 15% (25 / 174) of all possibilities for the worst case. For these tests the view is used only to retrieve links for the first source evaluated. Thus, a comparison with the source links only here looks reasonable. This suggests that the linking is an effective optimisation technique, providing an appreciably greater than 1:1 relation with memory allocation. If around 15% of all possible combinations are stored as links, a much greater than 15% improvement in performance would be expected. Measurements here show 80-90% search reduction, for example. This does not mean however that adding more link entries will automatically improve performance by the same amount. As well as the upper limit that has been suggested there is also not a direct correlation. For example, the test 1 configuration with the same view but only 25 entries at the link level reduced search performance by only around 2-3%. The conclusion is simply that if you store a certain percentage of the possibilities as links you would expect to get a much better improvement than that in performance.

The following sections will summarise individual test results and make comparisons to tests performed by other researches in related areas. As this type of query mechanism has not been evaluated before, the comparisons cannot be direct comparisons, but only indicate the sort of performance numbers that can be involved.

5.3.2.11 Summary of Test 1 Results - Skewed Query Test (70:30)

The test1 set of tests was for queries that considered the equivalence operator only and show a significant reduction in node count with a reasonable QoS. This would be useful for text or concept matching, for example. The reserve entry provides a good QoS, but the view provides a better search reduction. If both are combined however, rather than benefiting from both, it acts more like a view. The initial filtering from the view seems to have reduced the QoS unless the queries are sufficiently skewed. One other test tried this configuration without a reserve or view. This then performed more like the reserve option, with a search reduction of around 76% and QoS reduction of around 6% (compared to under 5% with a reserve) for the test 1 configuration.

5.3.2.12 Summary of Test 2 Results - Skewed Query Test (90:10)

When considering search reduction, the test2 tests seem to show a significant conclusion. If the equivalence only queries can achieve a certain level of accuracy after 20000 queries, then adding more links after this might only increase the search without further helping to find a better answer. But this is strongly dependent on the configuration. So the system might need to monitor this and determine an upper bound on the memory allocation. This would also be a limiting factor on the possible effectiveness provided by the links. This monitoring could be done as part of the supervision system inherent in autonomic systems. This would be an interesting area for more monitoring, to determine when to stop adding new links and has been written about in Greer et al. [GBMN07a]. A drop in performance when new links are added could indicate an upper bound on the memory allocation. Figure 60, showing the QoS, indicates a very good quality for the equivalence only queries and reasonably good for queries with all comparison operators. A generally prevailing rule


D5.4


of 91

through all tests would be that a larger search would produce a better quality of service. However, as shown by the reserve results for test1, when the links being added are key, both factors can be improved. Figure 61 shows that the link numbers levels out at around 25 for all sources, although it is still increasing slowly. This is an average value however and does not consider the exact distribution over the skewed sources. Statistics also show that the proportion of references to queries for the more popular source or value types increases with increasing query numbers. Thus, if these types are queried more and have more links, then this would increase the search size. This is an estimate for the whole source or value type and not individual instances. The link numbers also suggest that even with high skewing the large numbers of queries are sufficiently random to allow a large amount of variation. It might also suggest that the current parameters make incrementing links much easier than decrementing them, so that sources reach the link level relatively easily. The test2 results show that borrowing memory gives a clear improvement in QoS for the all comparison queries. This should be because of the more flexible memory distribution.

5.3.2.13 Summary of Test 3 Results – Query Range and Network Variability

Test3 tests show reasonably good consistency over increasing the value ranges, suggesting that some scaling up is possible there. However, scaling up the number of source instances is not as convincing as was anticipated. The linking performance seems to hold its own, but does not really improve. The original supposition was that a larger ratio of source instances to source types would be favourable, because the linking process selecting specific source instances would then be more effective. However, this does not seem to be the case. Having more instances with the same range of values means that there is more chance that a full search will find a source with the optimum set of random values for each query part. Thus the linking has to be more accurate in this case to provide the same level of QoS. Also, the process used to answer the queries could have a normalising effect on the number of nodes visited as it limits the number from one query part to the next.

5.3.2.14 Summary of Test 4 Results - Reasoning

The initial reasoning tests in test 4 show that using links is beneficial. The links can ‗intelligently‘ prune the worse solutions from the search space while still leaving an answer. Thus a better average value will be calculated and so both search reduction and QoS will be improved.

5.3.2.15 Related Test Results and Other Conclusions

There appears to be little directly related test results available. Koloniari et al. [KPP+05] indicate that their tests showed that 60% more queries could be answered in the same amount of time when nodes were clustered using their algorithm. These tests have not quite reached 60% but QoS is also indicated. Michlmayr et al. [MPG06a] state that in the space of 2000 to 10000 queries, the number of links travelled to find an answer reduces from 60.44 to 53.02 (12% reduction) and the number of documents retrieved increases from 1.82 to 3.95 (over twice as many). In Michlmayr et al. [MPG06b] they provide a different set of results for a search using taxonomies. They formulate queries consisting of single keywords taken from a taxonomy. A number of source documents are created, where each peer is an expert in a particular topic based on a percentage value. For example, a Pexpert value of 60% means that 60% of the peer‘s documents relate to the concept that it is expert in and 40% are random. The hit rate for the number of relevant documents retrieved for a particular time interval is then measured. They note that their most significant result is an improvement of 39.5% for a Pexpert value of 60%, while for a Pexpert value of 80%, the improvement is 38.2%. These


D5.4


of 91

values might be compared to the query distributions with search reduction, as this also measures improvement over variety.

5.3.3 Conclusions The aim of this work has been to evaluate a mechanism to allow an information network to optimise itself dynamically. One objective is that the network structure should remain lightweight and so the organising mechanism should also be lightweight. To this end stigmergic links have been used. A weight value and reference between two nodes is very lightweight and the total amount of memory can also be controlled. It should also be flexible as we do not know exactly what information will be stored. Thus the results of previous queries can be used to optimise the network, as this is completely dynamic, reflecting the system use. It does however require a certain amount of consistency with respect to the type of query that is executed for it to be effective. The intention of the tests in Section 5.3.2.7 is to show that stigmergic linking can fulfil the optimisation requirements. The links represent the knowledge held in the network and so together with some form of semantic organisation, could largely replace a centralised ontology to describe the knowledge in the network. The exact type of query being executed or the exact network structure is not so important. This sort of query, linking sources through comparisons, may be unusual in an XML-based information network, but the intention is to produce a richer or more complex type of query. The linking mechanism is generic, but the test results are tied into the query procedure that is used. Hyperlinks that link related Web pages might be a similar sort of application, or comparing values suggests some sort of record-based system. For example, Cameron et al. [CTB04] suggest a linking mechanism for database records, such as those in health care, retrieved from Web services. Another area could be the Semantic Web e.g. Berners-Lee et al. [BHL01], when queries will retrieve information from several related web pages rather than from a single Web page.

Stigmergic linking can clearly be used as part of a self-optimisation process and introduce new knowledge into the network. Query variation rather than network configuration has been tested, as either should determine the linking effectiveness. Querying a network with more variety in its node types should lead to the same query variation. The tests suggest that retrieving links can produce a worse performance when there are either too many or too few links, and so the optimal configuration is important. With a certain level of confidence however, it can be stated that provided a good configuration is found, the linking should improve performance by something appreciably larger than a 1:1 relation with memory allocation. Some other results in similar areas have been found, but it is difficult to make direct comparisons, due to the differences in the type of query that is executed. While these test results seem new, the indexing and retrieval mechanism of query parts might be the most novel aspect of this work, providing the desired lightweight and flexible framework.

This ends the main contribution of this report, which was to describe and evaluate a linking mechanism for optimising a knowledge network. The report will finish however by suggesting an overall model that uses this stigmergic principle to create a network that could obtain even higher levels of reasoning. This model will be the focus of future work and shows the potential of this sort of architecture.

5.4 Towards a Cognitive Model of Stigmergy The previous work has shown how stigmergy can be used as part of an autonomous system to efficiently self-optimise and also providing some level of reasoning. This section will extend the model further to provide higher levels of reasoning and suggest how a new


D5.4


of 91

cognitive model might be developed from it. While this section will focus on a local small-scale network, the principles would apply to a large distributed network also. Fu [Fu99] is an important paper with respect to this area and notes many of the problems that this model would solve. It also considers knowledge discovery and self-organisation in neural networks and bridging the symbolic-distributed gap. A neural-like structure that can understand what its nodes represent is a key feature of the model.

A smaller local network could receive inputs from its environment and then form associations between them. The environment of the network can be defined simply as its inputs and outputs. This can be controlled by an external system, or alternatively, in an autonomous system, the network could read its environment through electronic signals, for example sensors or image recognition. While humans with real intelligence can be selective with what they associate, a computer would also need an ‗understanding‘ of its environment to do the same thing. The network would need to associate the related nodes and use a reinforcement algorithm such as stigmergy to form links between them. As the network receives inputs from its environment, it must be able to select the concepts to associate with each other. By associating certain concepts together it is creating higher level and more complex concepts. The network can define the higher-level concept by using stigmergy or reinforcement to form links between the related lower level concepts to create a single path through all of them. Each link in this path is also assigned a unique key. In this way the network can recognise that this set of concepts actually represents something. This design is not only flexible with regard to the concepts that can be learned, but also with regard to the number of nodes, types of nodes and general organisation of the nodes. If a new concept is introduced, then a new node can simply be created to represent it and added to the network. An alternative way to index higher-level concepts would be to create a hierarchical network as discussed previously, where a node at a higher level would reference nodes at lower levels that make up the concept. With this architecture, you could even have two higher-level concepts being combined to an even higher one, and so on. It might only be a matter of convenience whether you use links with unique keys or hierarchical networks. Labelling higher-level nodes is then an issue and they may also require more memory for storing. But in some cases they may improve search time as they clearly define paths through the network to the source concepts.

Integrating Rules

This network structure however is still restricted to limited reasoning over the concepts that it contains. In a knowledge-based system for example, there are sets of rules that allow the system to derive new knowledge. For example, say we have a set of relation concepts and we know that Susan is John‘s mother and David is Susan‘s brother. These relations are shown by the stigmergic links in Figure 63.


D5.4


of 91

Figure 63: A network with stigmergic links between the concepts Susan, John and David.

If a user asks if John has an uncle however, the network cannot answer this, because this information is missing. If we have the rule that ‗the brother of a mother is an uncle‘, then the system can derive that David is John‘s uncle. Through direct information retrieval, stigmergic links cannot answer this, but there are two ways in which a system can use the links to answer this type of query. One way to do it is to have a query-rewriting tool that re-writes the query [GBMN07b] so that it can be executed on existing data. For example, this reasoning query could be re-written as:

Select exists brother From mother, son, brother Where (mother.brother EQ David) And (son.name EQ John) And (son.mother EQ Susan)

This could then be executed on the network as a standard query, but the re-writing is a centralised approach. The alternative would be to code the rule into the network structure itself. This cannot be done through a stigmergic reaction and so a central algorithm is still required to code the uncle concept into the network, but after this the use is distributed. The concept of uncle does not exist, so the network might query a knowledge-base, which returns the rule that the brother of a mother is an uncle. A higher level concept can then be created between the nodes mother, brother, son and a new node called uncle. The mother, brother and son nodes also store data of people that have these roles, while the uncle node links to the brother node. This type of rule is shown in Figure 64.

Figure 64: A rule that can be autonomously triggered through links.

The query reasoning keyword ‗exists‘ can then be used to ask if an uncle exists based on the queried information. If links between mother and son, and mother and brother can be established based on the input values, then there is a complete chain and the uncle concept can be realised. This is a slightly different query process to the one discussed previously but still relatively simple and could be implemented. A more interesting possibility would be for the higher level concept of mother, brother and son to trigger the uncle concept when they are all active. After the rule is created, the links that determine when it is fired are still generated stigmergically and so this is still the main organising mechanism. This method would also mean that the network could autonomously realise concepts for itself without being queried about them. For example, if one concept is satisfied, then this could trigger another concept. If the other concept did not have all values then the system could ask the environment for values and evaluate them. These values might then trigger other concepts, and so on. This kind of autonomous triggering of one concept after another might be the beginning of thinking.

Generalisation

Concepts could also be generalised, as shown by the example illustrated in Figure 65. Consider this figure, where there are two higher level concepts defined by the chains A-B-C-

Son

Uncle

Fire rule

link

link


D5.4


of 91

D and C-D-E. The event A-B-C-E-D then occurs. This will also form a chain but it is not recognised as a valid concept. To recognise that this is not actually a concept, each link in a concept can check its keys, where all concepts in the path must have at least one key the same. Then there is no chance of an alternative route being considered as valid. If a new route is found to be acceptable however, then either a new key is added to all links in the route, or the two routes can be given the same key to indicate alternative valid possibilities This might be beginning to generate some understanding, where the same concepts can be applied to different situations or slightly different concepts can be recognised as being essentially the same. Although, the probabilistic algorithms and similarity measures required to make this decision would be complex. It would also be possible to form the higher level concepts based on specific values, when the links would be from a specific value of one concept to another and not all potential links. If the concept was used again but the values were different then this could be recognised.

Figure 65: Example network with two higher-level concepts A-B-C-D and C-D-E.

Hierarchical Architecture

This model for a neural network has revealed three different hierarchical levels of knowledge, as shown in Figure 66. The source nodes that are associated through stigmergic links represent the first level which represent information that can be directly retrieved. The second layer has been discussed in Section 5.3.2.3. It allows for basic reasoning over the information sources through simple mathematical operators. On top of this, a third layer could be represented by chains of the source concepts, where each chain represents a higher level concept. This would allow for more sophisticated reasoning and understanding of the information stored in the network. It may also allow for the autonomous triggering of rules, where the network can realise associations among nodes for itself and in turn can translate them into an antecedent consequent format. This model thus represents a flexible way in which a network can begin to understand its contents and even reason autonomously over them. While the third level has yet to be proven, this offers genuine opportunities for introducing intelligence into dynamically constructed information networks and as such provides a multitude of research directions for future work.

A D

E


D5.4


of 91

Figure 66: Knowledge-representation architecture with three levels.

6 Conclusions, Self-assessment, and Future Work As WP5 has reached the end of the project, the defined objectives have been fully reached.

From the scientific viewpoint, a number of aspects, algorithms and solutions related to the general idea ―situation-awareness‖ have been investigated, leading to the production of relevant scientific and technical publications, some of which being already exploited by other research project (i.e., the WORKPAD project having absorbed the idea of the W4 data model). In particular, most of the scientific aspects originally identified in the original CASCADAS DoW and in its subsequent adjourns have been deeply investigated. It is also worth emphasizing that all these studies have contributed in properly framing a number of innovative concepts related to context-awareness, situation-awareness, and next generation service and data ecosystems. The result of this conceptual work will eventually find its way through a major scientific publication (a long paper on knowledge networks co-authored by all WP5 researchers and now undergoing the second round of reviews on the IEEE Transactions on Systems, Man, and Cybernetics).

From the technological viewpoint, a working knowledge network toolkit has been produced. Such toolkit is organized around a modular and sound architectures, and includes ACE-based libraries to collect data coming from a general environment (i.e., from a variety of devices) and to organize them into data structures suitable to be exploited by traditional, pervasive, and mobile software services to achieve context-awareness. The sample applications developed using this toolkit, together with the experiments performed on it to verify its effectiveness, confirm both that the knowledge networks approach is a suitable one for modern autonomic services, and that the ACE-based toolkit can indeed propose itself as a general-purpose toolkit to implemented not also user services but also system-level services (as knowledge networks are).

The only aspect in which WP5 could have done a bit better than it actually has is related to distribution aspects, i.e., the study and implementation of those aspects related to knowledge distribution management. In fact, although the knowledge network implementation supports distributed knowledge networks and distributed knowledge networks, the study and experimentation of strategies for managing knowledge distribution have been mostly limited at mechanisms and strategies for knowledge caching. We would have liked to study – within the project timeframe – the possibility of exploiting strategies for migration and replication of knowledge network components, in order to make the distributed


D5.4


of 91

shape of a knowledge network more dynamic and more capable of adapting to changed conditions than it is possible with caching strategies only.

Although, with the end of CASCADAS, the WP5 research activity has reached a reasonably stable fixed point, the areas for potentially interesting and impactful research are far from being exhausted. First, we think that more studies would be worth to push the ideas of automated knowledge generation by linking and extracting higher-level information by W4 data atoms. Second, we think we have only started exploring the potential of exploiting heterogeneous sensors to enforce forms of self-learning between sensors. In particular, the idea of having knowledge networks become a tools for autonomic services to be able to automatically learn recognizing complex situations, together with the possibility of apply commonsense reasoning in this activity, is potentially disrupting. Third, additions aspects related to distributed knowledge management would be worth exploring, such as concepts of knowledge evaporation to deal with knowledge overflow and more elaborated algorithms for stigmergic knowledge networking – the latter possibly leading to a more general model of cognitive stigmergy.

As a final note, we think that all the studies and experimentation performed within WP5 can provide a solid ground on which to push rather the idea of situation-awareness, i.e., towards ―self-aware‖ autonomic systems.

d5.4 - final report on open toolkit for knowledge networks...

Documents