The research presented in this paper aims at realising an automated ontology evolution process based on feedback without a human inspection. For that, a generic adaptation strategy consisting of a feedback transformation strategy and an ontology evolution strategy is formulated. It decides when and how to evolve by evaluating the impact of the evolution in the precedent feedback cycle. These strategies are implemented in a feedback transformer component and an adaptation manager component respectively, constituting a new adaptation layer. The adaptive ontology is evaluated with an experiment and validated with a real-world conversational content-based e-commerce recommender system as use case.
Design,
In order to get the system user-driven, user feedback is gathered by unobtrusively monitoring user needs. The more information is available from a user, the better the adaptation to her needs can be. Hence, implicit and explicit feedbacks provided via feedback channels are evaluated. Implicit feedback is given by the user as a side-effect of her usage behaviour, e.g. by clicking on the product recommended. Explicit feedback could be provided by answering questions about her satisfaction with the application. As this effort cannot be expected from a user, an alternative is to extract feedback from the Web that could also deliver new information and aspects about the products offered. In order to focus this research on developing an automated ontology evolution, the feedback is assumed to be given.
On a more abstract level, this research aims at realising an automated ontology evolution process based on feedback without a human inspection.
Topics of the SEMAIS 2011 workshop related to this research: •
What are the major technical challenges for developing or generating user interfaces based on semantic models? This paper aims to answer the above question with a generic approach. • For which kind of systems or applications are semantic models particularly useful? The use case in this paper is a recommender; for which other systems or applications can it be useful? • Additional question: Which ontological information and its changes (properties, etc.) are requested by adaptive interactive systems?
Previous approaches to the topic of this research can be found in
concepts for ontology evolution like formulated frameworks for
ontology evolution, e.g. [
The approaches to the identified recommender systems [
For realising an automated ontology evolution, a generic adaptation strategy consisting of a feedback transformation strategy and an ontology evolution strategy is formulated. It decides when and how to evolve by evaluating the impact of the evolution in the precedent feedback cycle. The first question defines the (temporal and causal) trigger initiating the ontology change. Basically, this is receiving and transforming the feedback into ontology input and will be addressed with a feedback transformation strategy (confer chapter 3.1).
The second question defines the changing of the ontology
including instance data. This is denoted by ontology evolution
referring to the activity of facilitating the modification of an
ontology by preserving its consistency [
By following the principles of adaptive systems [
In order to automatically process feedback, i.e. transforming it into ontology input, an adequate feedback transformation strategy has to be formulated and implemented. It has to allow for different feedback channels as well as different kinds of feedback. This strategy is implemented in the feedback transformer component depicted in figure 1. In the Feedback Transformer the ontology affected by the feedback reported is identified, the feedback is analysed and transformed, and eventually get related to the precedent feedback.
Ad 2. The feedback ontology is a prerequisite for the meaningful
analysis of the feedback [
For the feedback type “product rating” the RDF feedback includes the product name and rating but no new potential property. The feedback is transformed with a feedback evaluation algorithm. In the first step, the impact of the ontology evolution on the KPI (e.g. conversion rate and click-out rate) is calculated for each product and feedback channel. In the next step, all feedback channels are aggregated at the product level. Finally, a trend metric is calculated relating the current transformed feedback to the one in the precedent cycle.
For the feedback type “new property” the RDF feedback includes the product name and a new potential property to be eventually added to the product ontology, e.g. information like aspects or relevant features of a product. This feedback type is not covered by the feedback evaluation algorithm. A new sub-property for the aspect/ feature is created in the feedback ontology and its count gets related to the count of all properties in the respective PDO. When reaching a defined threshold, the new property is added to the respective PDO.
The semantic feedback log captures the exact sequence of the reported feedbacks. Each feedback is associated with the respective product (i.e. the RDF feedback contains the corresponding product name) and represented as instances of the sub-concepts of “Feedback”. These instances contain the product name, feedback channel, date and time of the feedback, rating, and the certainty of the rating as well as the number of properties contained in the product ontology. The log allows the analysis of the feedback development.
Ad 3. After having transformed the different feedback types, the calculated metrics relating the current feedback to the feedback in the precedent cycle are reported to the next component, i.e. the Adaptation Manager.
The ontology evolution strategy defines how the PDO change. It associates the transformed feedback values to evolution actions and ensures a consistent new version of a PDO. This strategy is implemented in the adaptation manager component depicted in figure 2. In the Adaptation Manager the structure of the respective ontology get dynamically analysed with SPARQL SELECT statements and the ontology changes (e.g. switching individuals, switching annotation property labels and comments, changing annotation property priorities, adding new properties) are executed with SPARQL CONSTRUCT rules according to predefined evolution strategies. Ad 4. In each feedback cycle the transformed feedback gets reported to the Adaptation Manager. The feedback is based on the product level. Each reported feedback is captured in a trend log at the product level.
Ad 5. The central task of the ontology evolution strategy and the
Adaptation Manager is to choose the right evolution, i.e. ontology
changes, for the transformed feedback.
[
Derived from user scenarios, evolution strategies are defined reflecting different behaviours and associating ontology changes, namely: • •
Risky Evolution (“always evolve differently”): Regardless of the feedback trend between two consecutive feedback cycles, other complex ontology change operations are executed Progressive Evolution (“learn from the past”): Depending on the leap of the trend, same or different complex ontology change operations are executed; in case of a negative trend, it is optional to either do a different complex ontology change operation or a rollback; additionally, with a threshold indicating the increase of the trend between the current and the precedent cycle the “risk” of the evolution can be adjusted and the strategy tuned towards the Risky Evolution (with a higher threshold) Safe Evolution (“only revert negative trends”): In case of a negative trend, a rollback is executed 2 Basic ontology change operations modify only one specific feature of an OWL ontology • • • •
Rollback (“undo the ontology changes”): Reverts the ontology changes from the precedent feedback cycle and is based on any reason or decision of the manager; it is executed only once but can be manually chosen multiple times Ad 6. After having chosen the ontology change operations to be executed, the ontology has to evolve depending on rules and by retaining its consistency to finally provide its knowledge to the application layer.
The existing research about ontology evolution is based on the
work about data schema evolution but focuses on the specific
needs of ontologies, e.g. [
To execute ontology changes, an ontology evolution algorithm has to be formulated. The following prerequisites have to be respected:
The basic and complex ontology change operations have to
be defined formally
It has to be defined when an ontology is inconsistent, i.e. an
ontology consistency model has to be formulated; the
preconditions and postconditions of the change operations
have to be checked before execution
The options for a consistent ontology evolution have to be
identified and the “best” evolution path chosen; in the
present research the belief revision principle of minimal
change will be followed [
The preferred concept of ontology versioning is change-based
versioning (i.e. each state gets its own version number and
additionally stores information about the changes made), because
it facilitates change detection, integration, conflict management
[
The semantic change log captures the exact sequence of the
ontology changes executed. Each change is represented as
instances of the sub-concepts of “Change”. The log allows the
analysis of the change development including realising a rollback.
The whole adaptation strategy and its implementation via the
components Feedback Transformer and Adaptation Manager
allow eliminating both manual steps in the six phase evolution
process of [
Phase “Implementation” (ontology changes are manually approved before execution): Nobody has to do that, as the ontology evolution is seen as a complete feedback cycle – an insufficient ontology change is indicated by decreased KPI and gets revised according to the evolution strategy chosen Phase “Validation” (performed changes can get manually validated): As the ontology changes are predefined, only valid changes are executed, and nobody has to validate them
The automatically evolved ontology is going to be compared with
a manually evolved one by setting up and evaluating an
experiment with ontology experts. Those analyse the feedbacks
delivered and decide the ontology changes to be executed.
Eventually, the ontology resulted from this manual evolution is
compared with the automatically evolved one regarding the
evaluation criteria consistency, completeness, conciseness,
expandability, and sensitiveness [
The validation of this research is done with a use case by utilising a real-world conversational content-based e-commerce recommender system and two feedback channels – the Web application and information extracted from Linked Open Data. As the recommender is already used in live e-commerce applications, the evaluation of the system adaptations is a real-world scenario. The recommender is based on PDO that semantically describe the products offered in e-commerce applications according to the GoodRelations ontology.3 The success of such a system is usually defined by analysing KPI like the achieved conversion rate (i.e. customers-to-recommender users ratio) or click-out rate (i.e. clicks-to-recommendations ratio).
The evaluation scenario is to test and evaluate the impact of the ontology evolution by utilising the formulated evolution strategies, i.e. Risky Evolution, Progressive Evolution, and Safe Evolution.
The impact of the ontology evolution will be analysed and evaluated with regard to the respective KPI at the application level after each to be defined number of accomplished recommendation processes and reported to the ontology. According to the respective results and feedbacks reported, the ontology evolves. The ontological knowledge is provided to the application layer, and eventually adapted recommendations are presented to the customer. The feedback circle of the automated system concludes with re-evaluating the KPI after having again reached the defined number of recommendation processes. The intended results are a highly adaptive system and eventually better recommendations given to the user leading to an increase of the defined KPI. The expected business impacts are a higher 3 www.purl.org/goodrelations customer satisfaction and loyalty and eventually increased revenue for the provider of the application.
This evaluation procedure will be executed for all three evolution strategies and evaluated analogously.
An interesting result of the evaluation scenario would be that one of the three evolution strategies leads to a higher increase of the KPI.
In case a predominant evolution strategy is identified, it can be interpreted that the historic development of changing the ontology (i.e. doing the same change again versus doing a different change) has a significant influence on the customer satisfaction. Though, this can in the case of same changes only be valid within a realisable frame, e.g. it is not possible to move up a sub-concept in the concept hierarchy infinitely times.
The need for automatically updating and evolving ontologies is urging in today’s usage scenarios. The present research tackles an automated process for the first time (to the best knowledge of the author). The reason for that can be found in the ontology definition “formal, explicit specification of a shared conceptualisation”. “Shared” means the knowledge contained in an ontology is consensual, i.e. it has been accepted by a group of people. Entailed from that, one can argue that by processing feedback in an ontology and evolving it, it is no longer a shared conceptualisation but an application-specific data model. On the other hand, it is still shared by the group of people who are using the application. It may even be argued that the ontology has been optimised for the usage of that group (in a specific context or application) and, hence, is a new way of interpreting ontologies: They can also be a specifically tailored and usage-based knowledge representation derived from an initial ontology – an ontology view, preserving most of the advantages like the support of automatically processing information. Thus, this changed way of conceiving ontologies could facilitate the adoption and spread of using this powerful representation mechanism in the real world, as it is easier to accomplish consensus within a smaller group of people than a larger one.
The research presented in this paper is funded by the Austrian Research Promotion Agency (FFG) and the Federal Ministry of Transport, Innovation, and Technology (BMVIT) under the FITIT “Semantic Systems” program (contract number 825061).