A.1 Basic Information
Effective personalization and (automatic) user modeling rely on the availability and quality of evidence about a user’s interaction with an adaptive system. Therefore, it is imperative that precise data about user actions are recorded and that its associated semantics are preserved for further processing by inference agents in the user modeling process.
Traditional logging approaches focus on server-side logs produced by web servers, which contain data incoming client-side requests (e.g., timestamp, URL addresses). On the other hand, SemanticLog employs another logging approach that stresses logging from the actual application that processes requests into responses and vice versa, both on the server side and on the client side.
A.1.1 Basic Terms
An ontology that describes the possible events that can occur in a system as results of user interaction together with their attributes and their mapping onto specific users and user sessions.
The logging of defined events resulting from user actions (user interaction) together with semantic metadata that describe what exact events occurred along with their attributes based on an event ontology.
A.1.2 Method Description
The logging method used by SemanticLog is based on three principles:
The key part of the used logging method is related to the event ontology, which describes events and their attributes in a flexible and extensible way (Fig. 1), so that they can be used for successive analysis of user behavior for personalization. Each event is associated with a unique user and user session thus including support for multiple simultaneous user sessions (bottom left). For each event a recursive set of associated eventAttributes can be stored describing events and their context in more detail (bottom right). Both events and their attributes have defined types.
Fig. 1. The relational data model corresponding to the used event ontology schema.
To further support the processing of logs by (user model) inference agents, the state of the user interface at the time an event occurred is logged. This includes the displayState before and after an event occurs (left). Each display state is composed of displayedItems and their attributes, which comprise the respective user interface visible to the user and thus provide the state of the world based on which the user made his decision to cause an event (top right).
A.1.3 Scenarios of Use
SemanticLog can be used to log and integrate user interaction evidence in the form of semantic events occurring both on the server side and client side of a system. Thus the possible usage scenarios are as follows:
§ Client side user interaction logging, e.g., moving the mouse, hovering on links.
§ Server side user interaction logging, which is usually associated with the processing of client requests into responses sent back to the client. For example, a faceted browser can log application specific details server side events such as SelectRestriction based on what links the user clicks in the user interface.
SemanticLog should not be used in following cases:
§ There is no event ontology available for the respective application.
§ There is no consumer for the logged data.
§ Tvarožek, M., Barla, M., & Bieliková, M. (2007). Personalized Presentation in Web-Based Information Systems. In J. Van Leeuwen, G. F. Italiano, W. van der Hoek, H. Sack, C. Meinel, & F. Plášil (Ed.), Lecture Notes in Computer Science: Proceedings of SOFSEM 2007 - Theory and Practice of Computer Science. LNCS 4362, pp. 796-807. Harrachov, Czech Republic: Springer-Verlag, Berlin Heidelberg.
§ Andrejko, A., Barla, M., Bieliková, M., & Tvarožek, M. (2006). Softvérové nástroje pre získavanie charakteristík používateľa. In P. Vojtáš, & T. Skopal (Ed.), Proceedings of DATAKON ‘06, (pp. 139-148). Brno, Czech Republic.
§ Hibernate, object-relational mapper, (http://www.hibernate.org/).
§ Log4J, Java-based logging utility, Apache Software Foundation. (http://logging.apache.org/log4j)
§ Tomcat, a Java servlet container, Apache Software Foundation. (tomcat.apache.org)
A.2 Integration Manual
SemanticLog is developed in Java (Standard Edition 5) as a library, which uses relational persistence via Hibernate and MySQL. It should be used in conjunction with other applications that need to log user interaction evidence for further processing. The distribution of SemanticLog consists of these parts:
SemanticLog uses these external tools and libraries:
Deploying SemanticLog with other applications involves these steps (Java Integrated Development Environment should be used):
1. Including the SemanticLog jar archive into the project.
2. Adding the SemanticLog and dependency jar archives to the classpath.
3. Adding the optional SemanticLog.jar file to the root project directory.
4. Adding logging data for the log4j.properties file and the hibernate.cfg.xml file.
SemanticLog must be configured to use a suitable relational database (hibernate.cfg.xml), and Log4J service (log4j.properties).
The optional SemanticLog.properties file contains the following values:
§ CallLogAnalyzer – true if LogAnalyzer should be invoked (default = false).
§ LogAnalyzerMessageThreshold – the number of events after which LogAnalyzer is invoked if it is enabled (default = 1).
The log4j.properties file should contain configuration for the semanticlog logger, the hibernate.cfg.xml file must contain connection data to a valid and initialized MySQL database, where log data is to be stored.
Additionally, the metadata level of event types and their respective attributes should be initialized before their first use as these are required during the logging process.
A.2.4 Integration Guide
SemanticLog is used to log events caused by user interaction. The typical usage scenario involves first a user login (method LogEventUserLogin), next zero or more application events (method LogEvent) and lastly a user logout (method LogEventUserLogout). For detailed description of individual logging methods see the accompanying javadoc documentation.
Most errors originate either from bad configuration and/or initialization (e.g., non-existing database, event or attribute types), or from caching, connection pooling and session issues in MySQL used by associated tools.
If an error is too serious or unknown and thus cannot be reasonably handled, an exception is thrown. Otherwise, a log entry via log4j is made.
A.3.1 Tool Structure
SemanticLog consists of a single package: sk.fiit.nazou.semanticlog.
A.3.2 Method Implementation
The implementation of SemanticLog is relatively straightforward. Its operation consists of two primary stages. First, during initialization the existing event, attribute and display state types are loaded. Next, during normal operation SemanticLog waits for incoming events and logs them as they arrive.
The respective logging methods first create an object model of the incoming event in memory and then store it in a relational database via Hibernate. For faster processing, a set of hash map tables are used to speed up seeks of event and attribute types and sessions.
A.3.3 Enhancements and Optimization
Originally, SemanticLog was implemented as a Web service running in the Axis Web service container. However, during evaluation we identified a significant performance bottleneck related to the constant serialization and deserialization of displayStates. Thus the design was changed to a library, which was invoked directly alleviating this problem. However, this quick workaround effectively almost negated the original intention to integrate events from various sources since each source effectively had its own instance of SemanticLog (i.e., events from the same session may not be combined).
To fix this problem we devised yet did not implement a hybrid approach that used a Web service for the initial logging of basic event data (user, session, event) and a jar library for the logging of complex displayState data (only available on the server side).
Otherwise, the performance of SemanticLog is near optimal with the exception of event evaluation via LogAnalyzer, which is invoked synchronously thus slowing down the logging process. Thus an interesting optimization prospect would be to invoke LogAnalyzer asynchronously, possibly as a Web service.
A.4 Manual for use in Other Application Domains
The use of SemanticLog in other application domains requires solely the definition of events, event types and the corresponding attributes, attribute types and display states relevant for the particular domain. As this can be done without any code and configuration changes by solely preparing the required data offline and then population the log database, there are no application changes required for the use of SemanticLog in another application domain.
A.4.1 Configuration for use in Other Application Domains
No domain specific configuration, other than the one described in the configuration section in necessary. Solely the definition of the respective events and corresponding entities in the database is required.
Apart from LogAnalyzer, all dependencies are effectively domain independent. Furthermore, LogAnalyzer itself is not explicitly required by the logging method as such, but is a dependency out of convenience where log evaluation is invoked automatically when new data are available. Any other inference agents specific for a particular domain can be used instead of LogAnalyzer provided that it accepts the created logs as input (i.e., “understands” the event ontology).
Detailed information about LogAnalyzer domain dependency is described in its respective documentation. It may require some domain specific adjustments, although the inference rules that are used are more dependent on the navigation model of a faceted browser rather than on the application domain itself. However, as some additional domain specific rules may be used, domain specific adjustments may be useful.