Rule-based Approach for Context Inconsistency Management in Ubiquitous Computing

Page 1

2010 IEEE/IFIP International Conference on Embedded and Ubiquitous Computing

Rule-based Approach for Context Inconsistency Management Scheme in Ubiquitous Computing Yong-jae Lee, Jaehyoung Lim, Soon J. Hyun, and Dongman Lee Department of Computer Science Korea Advanced Institute of Science and Technology Daejeon, Korea {jxherb, theagape, sjhyun, dlee}@kaist.ac.kr

<Tim, hasActivity, Cooking> by specifying condition contexts: <Tim, isLocatedIn, Kitchen>, <GasStove, hasState, On>, and <KitchenLight, hasState, On>. When the system detects all the condition contexts true, the resulting context will be deduced as <Tim, hasActivity, Cooking>. While a great deal of effort has been reported in context modeling, acquisition, and reasoning, little has been reported on context consistency management to cope with the dynamic nature of context changes. Solving the context inconsistency problem is an important issue as inconsistent contexts that are stored in the repository can cause incorrect decision-making and hence will trigger wrong application services. It will also cause a processing overhead in the reasoning operations due to the redundant context data remaining in the repository. The inconsistency problem may take place for two reasons: untimely (early or late) elimination of invalid contexts and ignoring the co-existence relationships among deduced contexts. As an example in the former: the context <Tim, hasActivity, Cooking> may be deleted only when another activity context of Tim is detected although Tim finished cooking quite a while ago (i.e., late elimination). Likewise, Tim moves out of kitchen for a short while to get some food so that the cooking context is deleted simply because a partial condition <Tim, isLocatedIn, Kitchen> turns ‘not true’ (i.e., early deletion). The latter problem is derived by a wrong proposition that there is only one deduced context at a time for an entity (Tim). However, both <Tim, hasActivity, Cooking> and <Tim, hasActivity, AnsweringPhone> can be valid at the same time so that the system must retain both as active. Therefore, all cooking services must be continued until Tim really finished the cooking activity. In this paper, we propose our rule-based context inconsistency management scheme to solve the problems addressed above. To eliminate the invalid contexts, we identify condition(s) with a principal impact on the corresponding activities in terms of an elimination rule. The well-described conditions will prevent valid contexts from being deleted improperly. Also, semantic relationships of a deduced context with others can be specified based on the theoretical

Abstract—Context data are updated frequently due to the dynamic changes of the various sensor values and the situations of application entities. Without a proper management, the stored contexts will become different from those of the realworld. Those invalid contexts will cause context inconsistency problems and thus should be eliminated at the right time and in an appropriate manner. In this paper, we propose a context inconsistency management scheme based on context elimination rules that describe the semantics of context invalidity to solve context inconsistency problems. The proposed rule-based scheme will enable users to easily specify elimination conditions for inconsistent contexts. Our performance evaluation shows that the rule processing overhead is compensated for by virtue of the well-maintained repository of the stored contexts. Keywords-context-aware computing; ubiquitous computing; context inconsistency management; rule descriptions

I. I NTRODUCTION Context-awareness is the key concept to user-centered ubiquitous computing services. It enables mobile and ubiquitous (or pervasive) computing applications to proactively provide users with smart services by capturing the contexts of application entities. The context can be defined as the situation of service entities [1]. The context-aware systems must provide proper services by capturing correct contexts that represent the situations of the real-world entities (e.g., users, services, etc.). Contexts can be classified into three categories based on the paths of production: sensed, defined, and deduced contexts [2]. Sensed contexts are directly acquired from sensors. Defined contexts are those that are created by designers or users, and deduced contexts are generated by the system through the rounds of inference operations. To model the contexts and their semantic relations, many context-aware systems employ ontology in that contexts are described using the Subject-Predicate-Object (S-P-O) template, such as <Tim, hasActivity, AnsweringPhone>. The ontology facilitates context reasoning using standard semantic descriptions and built-in rule specifications. Many context-aware systems adopt rule-based inference, and a rule is represented by condition contexts on the lefthand side and a resulting (i.e., deduced) context on the right-hand side. For example, we can design a rule to infer 978-0-7695-4322-2/10 $26.00 © 2010 IEEE DOI 10.1109/EUC.2010.27

120

foundation of the context lifecycle management scheme, in that multiple deduced contexts may co-exist when a user participates in more than one activity [3]. The rest of this paper is organized as follows. Section II presents previous researches in this track. In Section III, we define context inconsistency problems and show how they are associated with the real-world applications. Section IV presents our proposed scheme. Section V shows the development of our context inconsistency manager (CIM), and Section VI gives the performance evaluation. Finally, we conclude this paper in Section VII.

II. R ELATED W ORK There have been a few researches on managing context inconsistency problems to maintain the accuracy of the stored contexts against those of the real-world [4], [5], [6], [7]. Schmidt and Laerhoven introduced an abstraction of sensors called Cue [4]. In their layered architecture of a context-aware system, Cue tries to capture raw context data accurately by blocking inaccurate contexts from entering into the system. The blocking operation is determined by statistical functions and maximizes the reliability of sensor values. Henricksen and Indulska presented a context model that can help capture the qualities of contexts [5]. They claim that it is not always true to assume that contexts are reliable or complete. So they incorporated quality indicators into their context model to label the quality level on contexts. Both models focused on acquiring reliable sensed context data from sensors and hence were not directly related to inconsistency management. A couple of researches have been reported on inconsistency problems with deduced contexts [6], [7]. Bu et al. proposed a strategy based on their claim that a context becomes invalid when one of the condition contexts turns false [6]. For instance, let us suppose a deduced context <Tim, hasActivity, Cooking> is produced because all the condition contexts, such as <Tim, isLocatedIn, Kitchen>, <GasStove, hasState, On>, and <KitchenLight, hasState, On> are found in the context repository. Their scheme will delete the deduced context from the repository when any of the condition contexts is found false (or not existing). However, this proposition does not support all cases because the change of a partial condition context does always mean the deduced context is ‘not true.’ In other words, the simple negation of one condition is not sufficient to remove the deduced context. For example, Tim may get out of the kitchen temporarily, and the context <Tim, isLocatedIn, Kitchen> will change into <Tim, isLocatedIn, LivingRoom>. Then the system will drop the deduced context, <Tim, hasActivity, Cooking> although he is still in cooking. Xu et al. proposed the drop-bad strategy to cope with the problem [7]. This scheme marks ‘bad’ on a context that brings about context inconsistency. Then, a context that carries the highest number of ‘bad’ marks is considered as

! " # !$ % & ' ( $ ' ) % $ ' ) %

$ *! ( %

! " ( %

$ *! ( %

! " ( % & ' ( $ ' )++%

" , !

! " - % - . $ ' % - $ $ ' ) % - $ ' )!! %

$ *! ( % $ *! ( ' %

Figure 1.

Example of context inconsistency

the most inconsistent and thus removed. Therefore, the dropbad strategy can detect and resolve inconsistent contexts more accurately than the previous work. However, this scheme does not support timely deletion of inconsistent contexts. Also it is hard to justify the threshold number of ‘bad’ marks and determine the time window in which the marks are counted. In the following section, we analyze the causes and problems of context inconsistency in detail. III. C ONTEXT I NCONSISTENCY P ROBLEM Context inconsistency refers to as the situation in which contexts in the context-aware system differ from the contexts in the real-world. Such inconsistency is caused by the invalid context data retained in the system until they are forced to be removed from the context repository. Therefore, we need a policy to keep the stored context data in perfect sync with the contexts in the real-world. The task will focus on timely deletions of invalid contexts based on (1) interpretations of deletion conditions, and (2) identifying the semantic relationships between multiple activities. There are three different types of context production that are associated with context inconsistency. With sensed context, the new context is always true in that it reflects the most up-to-date context of an entity. Hence the new context data can simply replace the previous data of the same entity. The defined contexts, such as <GasStove, isLocatedIn, Kitchen> hardly change in nature, and thus are only modified manually. The deduced context should be carefully managed for context consistency, and this is the key motivation to our proposed idea. We have defined two possible inconsistency problems as shown in Figure 1 and Figure 2. Figure 1 demonstrates that the context data (e.g., cooking) is dropped either earlier or later than the real state of the context. The problem occurs when a context is removed without considering the real-world situation and the result is an

121

to the notion that a user can participate in more than one activity concurrently. Therefore, it is possible for more than one context to reflect concurrent activities. Let us suppose a few typical user activities at home, such as cooking, sleeping, watching TV, and answering the phone. We know that the user may answer the phone while cooking. This implies that identifying the semantic relationships between those activity contexts will help the context management system maintain the accuracy of its stored contexts. We devised our proposed rule-based context inconsistency management by designing the deletion context conditions and relationships between activity contexts as described in the following section.

/ !$ 0

/ !$ 0

! " # !$ % & ' ( $ ' ) % $ ' ) %

$ *! ( %

! " ( % $ $ ' )!! %

$ *! ( % $ *! ( * 1$ %

! " # !$ % $ $ '

)!! %

$ *! ( * 1$ % $ *! ( %

& ' ( $ ' )++% $ ' )++%

$ *! ( %

Figure 2.

IV. C ONTEXT E LIMINATION RULE A PPROACH A. Design Consideration

Example of context inconsistency

To solve the context inconsistency problems discussed above, we use context elimination rule (CER). This implies that the policy of context elimination is expressed in terms of rules that contain condition part and an action part. We also designed the co-validity relationships among activity contexts into the elimination rules so that the current activity context will not be blindly replaced by new one. Two of the XML-based rule description languages for semantic web services are SWRL and RIF [8], [9]. Some other XML-based rule languages, such as JessML, have been designed for their specific inference systems [10]. With their generic features, these languages can be used for rule descriptions in context inconsistency management. However, we found that they cannot fully support the needed rule expressions to solve all the context inconsistency problems stated in this paper because they are not capable of notating co-validity relationships of contexts. This motivated the design of a new rule description language for our proposed context inconstancy management scheme. Before we discuss our rule description in the following section, we point out a few design considerations in designing our rule language. First, a context can have an elimination rule in which the context is defined as a target context, and an elimination rule can be uniquely identified by its name. Second, the elimination rule must be able to describe the user-defined elimination conditions. Third, the co-validity notions of multiple contexts should be described on the basis of activity relationships between deduced contexts.

untimely context elimination. For instance in Figure 1, we describe the problematic situation that cooking activity ends at t3 in the real-world, but the context may be discarded from the system earlier at t2 due to the change of a partial condition on Tim’s location. Similarly, the context can be eliminated later at t4 by a newly inserted context on the same entity as Tim’s new activity is captured after he really finished the cooking activity at t4 . The other problem is caused by not considering the covalidity notions of two or more contexts on the same entity. For example, both ‘cooking’ and ‘answering-the-phone’ can be valid during the same time interval as shown in Figure 2. This notion of context co-validity has been modeled in our previous work under the subject of context lifecycle management [3]. According to modeling context lifecycle, a context can have relationships with others in the status of active, inactive, or paused. In consequence, without this context co-validity notion, the system may simply replace the previous one with a new one. Figure 2 illustrates this problem where services for cooking activity are discontinued while Tim answers the phone from t2 to t3 . As a matter of fact, both activities would better be served as co-valid contexts for the duration of the activity. The key idea to solve the problem is to deliver accurate and timely information about when and how to remove the inconsistent contexts. The specifications are initially made when the corresponding production rules are specified. For instance, the context inconsistency manager (CIM) can delete Tim’s cooking context only when the gas stove is turned off. This requirement can be specified as an elimination rule on the cooking context, and the system can delete the context of cooking activity when the system recognizes that the specified condition is met. On the other hand, we need to take co-validity relationship notions into account to cope with the problem shown in Figure 2. The context relationships are defined according

B. Context Elimination Rule In this section, we present our context elimination rule (CER) description. CER is written in XML and structured in a condition-action format. The CER schema is illustrated in Figure 3. An elimination rule consists of five elements: RuleName, Context (target), DefaultAction, EliminationCond, and CovalidityCond, as shown in Figure 3(a). With the RuleName

122

2

'28 23 2

2

3

+

4

2

. + *!

+

2

2

,(

; < ; 3 < 2 ;= 3 < ; < ;! 4 < ; 9: ! < ;= 9: ! < ; ! <$ *! ( ;= ! < ; 9: ! < ;= 9: ! < ;=! 4 < ;= < ; + *! <1 ;= + *! < ; < ;! : !

!

! ( >? @< ;! 4 < ; 9: ! <& ' ( ;= 9: ! < ; ! <$ ' ;= ! < ; 9: ! <)++;= 9: ! < ;=! 4 < ;=! : ! < ;= < ; < 6 ;= < ; ! < ; $ 5 - < ;! 4 < ; 9: ! < ;= 9: ! < ; ! <$ *! ( ;= ! < ; 9: ! <* 1$ ;= 9: ! < ;=! 4 < ; ! <1 ;= ! < ;= $ 5 - < ;= ! < heightheight ;= <

67

+

/$ 5 -

2

4

'28 23 2

2

' 9: !

2

1 !

2

)9: ! 9 4

2

2

*

2

: !

*

! (

*

+

: !

67

+

4

2

2

/$ 5 -

*

+

4

2

*!

*! (

/$ 5 -

Figure 3.

Schema of context elimination rule description

element, our context inconsistency manager (CIM) can identify the rules. A rule should contain a Context element as the target context for the rule to eliminate, as shown in Figure 3(b). The CIM can avoid unnecessary evaluation of the elimination conditions by simply checking the target context first. The DefaultAction specifies the action of the target context when the new context on the same entity is not specified in the Co-validityCond element below it. For example, the default action of the ‘watching TV’ context would be ‘paused’ and that of ‘cooking’ would be ‘terminated’ for safety. The rule schema has two condition elements: one is for elimination conditions and the other is for co-validity conditions. In the EliminationCond element shown in Figure 3(c), contexts can be specified as conditions with conjunctions, ‘and,’ ‘or,’ and ‘none.’ When all the condition contexts are found in the system, the target context is deleted. The Co-validityCond element shown in Figure 3(d) is used to define the needed actions for the target context (i.e., paused, terminated or co-active) when the new activity on the same entity comes into the system. Figure 4 shows an example context elimination rule for the ‘cooking’ context written in XML. Registered into the CIM, the target context <Tim, hasActivity, Cooking> will be eliminated when the gas stove is turned off. On the other hand, when Tim moves momentarily to answer the phone while cooking is in progress, the system will not eliminate the cooking context but keep both valid.

Figure 4.

An example of context elimination rule description

C. Algorithm When an elimination rule is registered, its elimination conditions and/or co-validity conditions are added to the condition mapping table. In the table, a condition context can be linked to more than one rule. In other words, an elimination rule can have links to a number of associated condition contexts. Each link has two labels, one used to check whether a condition is satisfied, and the other used to indicate an elimination condition and/or a co-validity condition. If all the links of the elimination conditions of the rule are marked ‘satisfied,’ then the target context will be deleted. Likewise, when the co-validity condition label is marked ‘satisfied,’ the target context will be treated according to its relationship with the new activity. Figure 5 shows the entire process of our proposed context inconsistency management. The procedure starts when a new context is detected either directly from sensors or deduced by the inference engine. When a new context is detected, the CIM searches the condition mapping table for an elimination rule that contains context(s) as an elimination condition. When the system discovers a rule, it asks the inference

123

B

'

"B 4 8

* ! 4 !

4 8 1 ! 2(

" + ! 2

" $ !

$ ! 4 ! A *3. " $ $ + $

$ A

3)

9 2 4 . (

C2' . $ !

$ ! 4

! A

4

C2'

* $ !

+ $ + A C2'

B 9

3)

B $ !

+ $ !! $

! 4 3)

2(

$ $ + $

!! $

Figure 6.

1

Functional architecture of the CIM

5 $ ( $

and notifying the CM of deletion of a target context respectively. Figure 6 shows the functional architecture of the CIM. From the analysis of CER description in the previous section (see Figures 3 and 4), we can consider an elimination rule as a set of sub-rules. This is because its elimination conditions and co-validity conditions can be treated as individual rules on the same target context for efficient management in the condition mapping table. When a new elimination rule is registered, the rule parser analyzes the rule and divides it into two parts: one for the elimination conditions and the other for the co-validity conditions. A new context (i.e., sensed or deduced) is delivered from the CM to the CIM. The CIM then searches its condition mapping table for elimination rules that contain the incoming context as their condition context. The table then returns the su-brule(s) of the matching elimination rule. Finding the sub-rule(s), the CIM marks links between the sub-rule(s) and the condition context if a target context of the rule exists in the context repository. This marking information is used to check whether or not all the conditions in an elimination rule are satisfied. When all the conditions of a sub-rule are satisfied, the CIM asks the CM to delete the target context. On the other hand, when the delivered context matches one of the contexts in the Co-validityCond element, the target context is not replaced but acts as specified in the element, such as paused, terminated, or co-active. The process of co-validity condition checking is identical to elimination condition checking. Note that there is a possibility of conflict between elimination and co-validity actions when a condition context for elimination is used as a co-validity condition in the same rule. In this case, the CIM does not remove the target context of the rule but takes the co-validity action specified in the Co-validityCond element until the co-validity

2

Figure 5.

Context inconsistency management procedure

engine to check whether the target context exists in the context repository. If the target context does not exist in the system, the procedure terminates. This is useful because it is a waste of time to search the entire repository for a non-existing context. The next step is to figure out whether the context is one of the elimination or co-validity conditions. If the context is determined to be a co-validity condition, then the CIM will perform an action according to the activity relationships specified in the Co-validityCond element of the rule. If the context is one of the elimination conditions, then there are repeating steps to confirm that all the conditions of the rule are satisfied to remove the target context. To do that, we mark links with ‘satisfied’ and check whether all the specified condition contexts of the rule exist in the repository. When all the condition contexts are confirmed ‘satisfied,’ then the elimination rule is fired to delete the target context. V. I MPLEMENTATION We implemented our scheme in Java SE 6 on top of the Context Manager (CM), which is part of our previous development of a ubiquitous computing middleware system called Active Surroundings [11]. The CM plays the roles of context gathering, aggregating, inferring, and disseminating contexts. We used OWLJessKB and Jess for first-order logic inference over the ontology-based context model [12], [13]. The context inconsistency manager (CIM) consists of three functional components playing the roles of detecting signs of inconsistent contexts, managing elimination rules,

124

action becomes terminated. By doing so, the overall context inconsistency management works in a more conservative manner.

VI. E VALUATION In this section, we present the performance evaluation of our proposed idea and the development of the CIM. In addition to accuracy, we also evaluated the processing overhead to demonstrate that the extra processing of the elimination rules causes negligible performance degradation due to optimal repository management. We used an Intel Core2 Duo 3.0 GHz CPU and a 3.5 GB memory PC running Linux operating system as the evaluation environment. We constructed an ontology for a smart home environment with approximately 1,000 context triples. To measure the processing overhead, we registered 100 production rules and the same number of context elimination rules, i.e., an elimination rule for a production rule. In our experiment, all the registered production rules and elimination rules are fired so that a maximum of additional 100 contexts can be deduced according to the number of fired production rules. In addition, we designed 100 context elimination rules in a way to eliminate 100 target contexts as the result of rule processing in an attempt to measure the maximum work load. For the experiment we used a typical application scenario in a ubiquitous home domain as follows: (1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11)

Figure 7. Comparison of processing overhead between context-aware systems with CERs and without CERs Table I T HE EVALUATION RESULT

Situation

Tim went to bed at 11 PM last night. In the morning, Sara, his daughter, opened his bed room door but closed it soon seeing her father was sleeping. After an hour, he comes out of his bedroom and sits on the sofa in the living room. Then he turns on the TV and starts to watch today’s morning news. After turning off the TV, he enters the bathroom. He starts taking a shower, however in the middle of his shower, suddenly the telephone starts ringing. So drying his body on a towel cursorily, he gets out of the bathroom. He answers the phone and hangs up soon to finish showering. He returns to the bathroom and finishes showering. In order to have breakfast, he goes to the kitchen and starts to make toast and scrambled eggs. While cooking his breakfast, he turns on the TV and watches today’s weather from the news.

Context Repository CERA scheme

Bu’s scheme

(1)

Sleeping

Sleeping

(2)

Sleeping

None

(3)

None

None

(4)

WatchingTV

WatchingTV

(5)

None

None

(6)

TakingShower

TakingShower

(7)

TakingShower

None

(8)

TakingShower

AnsweringPhone

AnsweringPhone (9)

TakingShower

TakingShower

(10)

Cooking

Cooking

(11)

Cooking

WatchingTV

WatchingTV

of approximately 60 ms to process 100 CERs, which means approximately 0.9% of performance overhead for processing the rules. Next, we examined the accuracy of our proposed scheme in comparison with Bu’s approach as shown in Table I. The result shows that Bu’s scheme overly and at the wrong time eliminated some contexts that are consistent with the real-world situations and thus must not be eliminated. This is because their scheme did not have the needed policy to accommodate real-world semantics for context elimination and the relationships between activity contexts. Their scheme simply replaced the current context with the following context without considering co-validity features between the contexts. To cope with such problems, our scheme employed a rule-based context elimination policy to better maintain the context repository in sync with the

First, we measured the performance overhead for processing the elimination rules. The result shows that our scheme has negligible processing overhead as shown in Figure 7. In the experiment, we measured response time by increasing the number of CERs with 200 context triples. Each rule had an average of four elimination conditions and covalidity conditions. As shown in the figure, it took an additional time

125

real-world as shown in Table I.

[3] H. Kim, I. Park, S. Hyun, and D. Lee, “Dynamic activity lifecycle management in ubiquitous computing environments,” in Proceedings of the 7th IEEE International Conference on Computer and Information Technology, Aizu-Wakamatsu, Fukushima, Oct. 2007, pp. 985–990.

VII. C ONCLUSION In this paper, we proposed a rule-based context elimination scheme for context inconsistency management. We designed a rule language to describe the context elimination rules called CERs which represent context elimination conditions, co-validity relationship semantics, and so forth. Using the rules, condition contexts can be defined to eliminate inconsistent contexts from the repository. In addition, context co-validity can be explicitly described based on the relationships between deduced contexts. We implemented our proposed ideas into a context inconsistency manager (CIM) to keep the context repository in sync with the real-world contexts. Our performance evaluation showed improved accuracy and negligible processing overhead. As a part of our future work, we will extend the CIM to have an intuitive user interface for users to easily describe the userdefined elimination rules to better represent real-world semantics. We also plan to improve the CER schema by introducing more vocabulary words to deal with more sophisticated requirements of context repository management.

[4] A. Schmidt and K. van Laerhoven, “How to build smart appliances?” IEEE Personal Communications, vol. 8, no. 4, pp. 66–71, Aug. 2001. [5] K. Henricksen and J. Indulska, “Modelling and using imperfect context information,” in Proceedings of the 2nd IEEE Annual Conference on Pervasive Computing and Communications Workshops, Mar. 2004, pp. 33–37. [6] Y. Bu, T. Gu, X. Tao, J. Li, S. Chen, and J. Lu, “Managing quality of context in pervasive computing,” in Proceedings of the 6th International Conference on Quality Software, Washington, DC, USA, Oct. 2006, pp. 193–200. [7] C. Xu, S. Cheung, W. Chan, and C. Ye, “Heuristics-based strategies for resolving context inconsistencies in pervasive computing applications,” in Proceedings of the 28th International Conference on Distributed Computing Systems, Los Alamitos, CA, USA, Jun. 2008, pp. 713–721. [8] W3C. (2010) SWRL: A Semantic Web Rule Language Combining OWL and RuleML. [Online]. Available: http://www.w3.org/Submission/SWRL/

ACKNOWLEDGMENT This work was supported at the IT R&D program of MKE/KEIT under grant KI001877 [Locational/Societal Relation-Aware Social Media Service Technology].

[9] ——. (2010) RIF Overview. http://www.w3.org/TR/rif-overview/

R EFERENCES

[Online].

Available:

[10] E. J. Friedman-Hill. (2010) Jess and XML. [Online]. Available: http://www.jessrules.com/docs/70/xml.html

[1] A. Dey, G. Abowd, and D. Salber, “A conceptual framework and a toolkit for supporting the rapid prototyping of contextaware applications,” Human-Computer Interaction, vol. 16, no. 2, pp. 97–166, 2001.

[11] D. Lee, S. Han, I. Park, S. Kang, K. Lee, S. Hyun, Y. Lee, , and G. Lee, “Ontology based context modeling and reasoning using owl,” in Proceedings of the 14th International Conference on Artificial Reality and Telexistence, Oct. 2004, pp. 291–298.

[2] J. Lee, I. Park, D. Lee, and S. Hyun, “An applicationoriented context pre-fetch method for improving inference performance in ontology-based context management,” in Proceedings of the 1st International Workshop on Contexts and Ontologies: Theory, Practice and Applications at AAAI, vol. 5, 2005, pp. 41–48.

[12] J. Kopena. (2010) OWLJessKB: A Semantic Web Reasoning Tool. [Online]. Available: http://edge.cs.drexel.edu/assemblies/software/owljesskb/ [13] E. J. Friedman-Hill, Jess in Action : Java Rule-Based Systems. Greenwich, CT: Manning Publications, 2003.

126

Turn static files into dynamic content formats.

Create a flipbook
Issuu converts static files into: digital portfolios, online yearbooks, online catalogs, digital photo albums and more. Sign up and create your flipbook.