Central to the semantic web are ontologies: shared conceptualizations of domains of interest expressed in an ontology language such as OWL. Rule languages complement ontology languages. For large heterogeneous bodies of knowledge on the semantic web, contextualized knowledge repositories facilitate the organization of ontological concepts. In this paper we propose a similar mechanism - contextualized rule repositories - for organizing and executing large sets of context-specific rules. We investigate feasibility of a SPARQL Inferencing Notation (SPIN) based implementation using a real-world use case from the aeronautical domain. Furthermore, we compare SPIN-based contextualized rule repositories to a context-unaware SPIN implementation.
Ontologies and ontology languages are at the heart of the semantic web.
Ontologies are shared conceptualizations of domains of interest expressed in
machinereadable formats, i.e., ontology languages [
Large heterogeneous knowledge repositories are rendered manageable by the
introduction of context. A context constrains the validity of contextualized
knowledge. Typically, contexts are hierarchically organized. A theoretical foundation
for representing contextualized knowledge and reasoning about contexts was
introduced by McCarthy [
A more recent approach are contextualized knowledge repositories [
In the semantic web stack [
Complementing ontologies organized in contextualized knowledge
repositories by rules, it is sensible to organize the rules in a similar fashion to promote
efficient management. Contextualized knowledge repositories, however, are not
designed for organizing and executing rules. Thus, a mechanism for
contextualization, tailored specifically to the particularities of rules, is necessary. Such a
mechanism are contextualized rule repositories [
In this paper, we investigate the potential of contextualized rule repositories
as tool to organize and execute large sets of context-specific rules in the
semantic web. We provide an implementation of contextualized business rules [
The remainder of this paper is structured as follows. Sect. 2 provides background on contextualized business rules and related work. Sect. 3 presents the demo case from the aeronautical domain used to illustrate the approach. Sect. 4 describes the implementation of contextualized rule repositories using SPIN. Sect. 5 presents results from feasibility experiments. We conclude the paper with a summary and an outlook on future work. 2
In this section we present the conceptual framework for contextualized rule
repositories [
We previously introduced a generic conceptual context model for contextualized
business rules [
ContextClass and Parameter are instantiated to domain-specific context classes and parameters on the domain level; on the application level they are instantiated to specific contexts and hierarchically ordered parameter values (covers). Specific contexts state the business rules (businessRules) and business vocabulary (businessVocab) applying for them. Parameter value hierarchies are used to derive the hierarchy of contexts (specializes). Business rules and vocabulary propagate along this specializes relationship. Besides these hierarchical relationships, it is possible to define further context and parameter value relationships by instantiating ctxRelationship or valueRel respectively.
For a specific business case (an instance of an instance of BusinessCaseClass) described by <describingProps>, we infer its parameter values (paramValues) for each Parameter. These parameter values identify the most specific context(s) relevant to the given business case. Using the hierarchy of contexts all relevant contexts can be determined (relevantContexts). Depending on the semantics of the employed context relationships, e.g., specializes inherits business rules and business vocabulary, conflicts, e.g., due to multi-inheritance, need to be resolved, e.g., more specific business rules/terms prevail. Therefore, a new context containing only relevant business rules and business vocabulary with conflicts resolved is derived (caseSpecificContext). The effects of business rules are modeled using the placeholder <derivedProps>. 2.2
A Contextualized Knowledge Repository (CKR [
Apart from the semantic web, many commercial business rule management systems (BRMSs) offer the possibility to organize rules into rulesets. These commercial systems typically lack a mechanism for declaratively describing which ruleset should be invoked in which situation. Concerning the representation of relationships between rulesets, only inclusion is commonly supported.
Other approaches propose grouping of business rules by single attributes,
e.g., regarding the rule objective [
We previously demonstrated usefulness of contextualized business rules in the
aeronautical domain [
Apart from the aeronautical domain, the proposed approach can be applied to other domains as well. For example, a person’s eligibility for retirement depends on the country of residence, country of workplace, age, years of work, etc. Furthermore, the computation of monthly retirement payment differs.
Fig. 2 (upper part) illustrates a simple domain-specific model for SemNOTAM instantiating the general model in Fig. 1. This model focuses on classification of highly important NOTAMs only (highImportance). Aeronautical Information Management (AIM) contexts (AIMContext) are, in our use case, described by two parameters of seven identified so far in pilot interviews: meteorological condition (MeteoCond) and aircraft type (AircraftType). Other parameters identified include the role of the user and the aviation type (e.g. cargo, passenger, military, etc.). In SemNOTAM, only inheritance relationships are of importance, i.e., covers and specializes. The BusinessCaseClass interest specification (InterestSpec) describes a flight plan, with the describing properties weather (weather) and type of aircraft used (aircraft), for which messages have to be grouped by importance. Note that temporal and spatial attributes, e.g., the used flight segments, are not shown for comprehensibility.
We instantiate the presented domain-specific context model to an applicationspecific model in Fig. 2 (lower part). In particular, we define two exemplary contexts: anyMeteoAnyAircraft and its specializing context imcMeteoRotary. Context anyMeteoAnyAircraft contains rules and vocabulary applying for any interest specification whereas rules and vocabulary in context imcMeteoRotary apply only for interest specifications regarding instrumental meteorological conditions (IMC) and rotary aircrafts. Besides these contexts, we specify a concrete interest specification iSpec1 with aircraft Bell Augusta, a helicopter, and weather fog, a specific IMC. Using this information, the contexts relevant to ispec1 can be derived: anyMeteoAnyAircraft and imcMeteoRotary. The casespecific context rIMCMeteoRotary is, as contexts anyMeteoAnyAircraft and imcMeteoRotary do not conflict, the union of these two contexts. Notam n1 is determined to be of highImportance due to the rule in context imcMeteoRotary. 4
SPIN is a SPARQL-based rule and constraint language integrating concepts from rule-based systems, query languages, and object-oriented languages. SPIN enables formal description of object behavior, i.e., SPIN statements are assigned
Listing 1. The rule from context imcMeteoRotary. 1 CONSTRUCT { spin : _this highImportance ?n. } 2 WHERE { spin : _this meteo some MeteoCond . 3 spin : _this aircraft some RotaryAircraft . 4 ?n rdf : type notams : AerodromeLightingNOTAM . }
Listing 2. The rule from context imcMeteoRotary in its context-unaware form.
to classes and apply to individuals of their assigned classes only. The SPIN
W3C member submission [
A common implementation of SPIN is TopBraid’s Jena-based SPIN API1. In order to evaluate SPIN-rules, the corresponding RDFS/OWL ontology needs first to be loaded and subsequently prepared for rule inference. Any changes to SPIN rules in an ontology require a new inference preparation. Any other changes, e.g., new individuals, even if resulting from SPIN rules, are immediately considered in the current SPIN rule evaluation.
In order to implement contextualized rules using SPIN, context classes and
contexts, their parameters and parameter values, as well as business case classes
and business cases need to be represented in RDF(S) or OWL. Each context,
utilizing SPIN’s object orientation, is represented as an OWL class with its rules
assigned, e.g., Listing 3 depicts context IMCMeteoRotary from our use case.
Parameters and their parameter values form subsumption hierarchies. The assignment
of parameter values to contexts can be represented in two ways. Regardless the
variant, the hierarchy of contexts can be derived from the parameter value
hierarchies using a reasoner. The two ontology variants are:
1. Ctx: employing object properties (Listing 3) as modeled in [
Listing 3. Context IMCMeteoRotary with object properties (Ctx). 1 Class : IMCMeteoRotary 2 EquivalentTo : 3 InterestSpec 4 and IMCMeteo 5 and RotaryAircraft 6 SubClassOf : 7 Context 9 Individual : IMCMeteoRotary 10 Facts : 11 spin : rule _ :1 Listing 4. Context IMCMeteoRotary with subclassing (SCtx) including a SPIN rule.
Each business case class is represented as an OWL class and defines its describing properties as contexts do, i.e., either by subclassing or using object properties. In the simplest configuration, describing properties instantiate or refer to the parameter values directly. In more complex configurations, parameter values must first be derived from describing properties using OWL or SPIN.
This approach enables an OWL reasoner to determine the relevant contexts for a given business case. For instance, interest specification iSpec1 (Ctx) relates to individuals BellAugusta (instance of Rotary) and Fog (instance of IMCMeteo) using the object properties aircraft and meteo respectively. Thus, iSpec1 is reasoned to be an individual of IMCMeteoRotary by Listing 3. As IMCMeteoRotary is a subclass of AnyMeteoAnyAircraft by hierarchies of parameter values, iSpec1 is an individual of AnyMeteoAnyAircraft as well. Since a business case can be an individual of multiple contexts, the rules of several contexts are evaluated when performing SPIN evaluation. Thus, conflicting conclusions can be derived, e.g., a NOTAM could be classified both relevant and irrelevant. To resolve this, a cautious resolution rule could be defined: a NOTAM is relevant as soon as one rule classifies it as relevant. In other cases, most specific rules may have precedence. A detailed analysis of conflicts and their resolutions is considered future work.
Contextualized business rules [
Listing 5. The Manchester representation of interest specification iSpec1 (Ctx).
all vocabularies are accessible in all contexts. Creating one SPIN rule library per
context would theoretically allow to define terms local to a context by defining
them in the corresponding rule library. In practice, however, non-SPIN triples
relevant to rule execution are not allowed in SPIN rule libraries. Another option,
left for future work, is to integrate contextualized knowledge repositories [
We expect the proposed SPIN implementation of contextualized rule repositories to outperform context-unaware solutions. Nevertheless, as this implementation introduces additional organizational overhead, we suspect that this is only the case if the number of rules and contexts exceeds some threshold. Thus, we postulate the following hypotheses regarding SPIN-based contextualized rule repositories which we evaluate in the following section.
H1 The system applies for given business cases all and only relevant rules. H2 There exists a threshold above which the average response time (the time between providing a business case and being returned the business case with rules applied) is lower compared to SPIN-based context-unaware solutions. 5
To demonstrate the feasibility of our proposed SPIN-based contextualized rule repositories for the semantic web, we evaluate our hypotheses utilizing SemNOTAM as use case. To this end, we employ TopBraid’s single-threaded SPIN API. To test hypothesis H1, we consider simple rules of the kind “In <situation/context>, messages of <type> are of <level> importance” as well as more complex rules which include, for instance, restrictions on aircraft characteristics like its weight or wingspan. To test hypothesis H2 we employ simple rules only as we assume that the complexity of rules influences context-aware and context-unaware ontology variants alike; an empirical evaluation of this assumption is outstanding. Regarding interest specifications we assume the simple configuration, i.e., parameter values are directly assigned. The complex configuration requires additional rules which derive the parameter values. Using SPIN’s ability to define an execution order of rules, the only difference in the configurations is the total number of rules affecting all ontology variants to the same extent. Hypothesis H1 To test H1, we represented our use case using SPIN-based contextualized rule repositories. We employed four parameters, namely, flight phase, flight rule, meteorological condition, and time of day, of the seven we have identified in pilot interviews. Each of these parameters defines three parameter values, i.e., one root element and two children, resulting in 3 × 3 × 3 × 3 = 81 potential contexts for which we can define specific rules. So far, we have elicited rules for 17 of these 81 contexts regarding 22 different aeronautical message types. Testing various interest specifications covering the 81 potential contexts, we could verify that only relevant as well as all relevant rules were applied. Thus, hypothesis H1 is supported by our experiments.
Hypothesis H2 To test hypothesis H2 we derive context-unaware ontology variants from our contextualized ontology variants SCtx and Ctx and represent them using SPIN. Therefore, we incorporate the parameter values of each context into its contained rules, i.e., the rule in Listing 1 is rewritten to the rule in Listing 2. Consequently, for a single context model we have two context-aware variants (SCtx and Ctx) and two context-unaware variants (SNoCtx and NoCtx).
A single context model is not sufficient to test hypothesis H2, a generator is needed to create context models of various sizes and complexity and their corresponding ontology variants. Furthermore, random interest specifications need to be generated in order to find the suspected threshold. Consequently, we constructed a generator accepting six parameters determining the size and complexity of the generated ontologies: (1) number of parameters, i.e., instances of Parameter in Fig. 1 (two in our use case in Fig. 2), (2) parameter value hierarchy depth, i.e., number of levels of covers (two plus in Fig. 2), (3) parameter value hierarchy width, i.e., instances of covers at one level (two plus in Fig. 2), (4) context density, i.e., the percentage of potential contexts actually instantiated (2 in 4 for the named parameter values and contexts in Fig. 2), (5) number of rules per context, i.e., cardinality of attribute businessRules (one plus in Fig. 2), (6) and number of message types (one in Fig. 2).
For the tests we used Intel Core i7-4770s with 16 GB RAM. We ran the generator for different configurations covering number of parameters (2-5), parameter value hierarchy depth (1-2) and width (2-5), context density (25 %, 50 %, 75 %), rules per context (12, 25, 50, 100), and number of message types (70). The latter parameter was not varied as it had no direct influence on the number of rules or contexts. The configurations were chosen in such a way that we tested up to about 12,000 contexts. Tests of Ctx were excluded due to its weak performance in preliminary tests. Ontology metrics for two sample context models are depicted in Table 1 . We measured the time for loading and for SPIN inference preparation as well as the average response time for 25 randomly generated interest specifications for the ontology variants SCtx, SNoCtx, and NoCtx.
Regarding loading time and inference preparation times we expect SCtx to perform best as its ontology variants are the smallest and its rules are the simplest, i.e., they contain the fewest terms. Analyzing the loading times for the different ontology variants in detail showed that the average time mainly depends on the total number of rules (totalRules). The time (in seconds) necessary for loading an SCtx ontology variant can be predicted using avgT ime = 2.15 × 10−4 ×totalRules. This linear regression has an R2 value of 0.99, i.e., 99 % of the variance in loading time is explained by it. SNoCtx takes about twice as long and NoCtx about 3.5 times as long. The time needed for inference preparation also mainly depends on the number of rules: SCtx avgT ime = 1.6×10−4 ×totalRules (R2 = .99), SNoCtx about thrice as long and NoCtx about 3.75 times as long. Consequently, the SCtx ontology variant is fastest considering loading and inference preparation confirming our expectation.
Considering the average response time, we expect SCtx to outperform NoCtx and SNoCtx for larger number of rules and contexts. Fig. 3 depicts the average response time versus the total number of rules (left column) and versus the number of contexts (right column) grouped by the number of rules per context. Note that due to the additional expressions in rules for context-unaware ontologies, tests of these ran out of memory when using more than 450,000 rules. Furthermore, NoCtx, surpassing SCtx only for 12 rules per context and performing worse than SNoCtx in any case, is not shown for readability. The left column in Fig. 3 reveals that the average response time of context-unaware ontologies only slightly depends on the number of rules per context. For SCtx, on the other hand, there is a strong dependency. The threshold above which SCtx’s average response time surpasses SNoCtx’s is about 40 rules per context. For rules-percontext ratios below 40, the additional administrative effort seems to outweigh the benefits. Depicting the average response time versus the number of contexts (right column) we see that SCtx and SNoCtx for 25 rules per context have almost identical average response times up to approximately 3,000 contexts. Furthermore, we can see that the more contexts are employed the larger the gap between the average response time of SCtx and SNoCtx becomes.
In conclusion, SCtx outperforms SNoCtx and NoCtx in any case regarding loading time and inference preparation time. Regarding the average response time, SCtx outperforms SNoCtx when more than 40 rules per context are used. Thus, hypothesis H2 is supported by our experiments.
Predicting the Average Response Time Employing Pearson’s correlation coefficient we found the average time for SCtx significantly correlated with the total number of rules (ρ = .91) and the number of used contexts (ρ = .92) most. Performing linear regression using these variables we are able to predict the average time for SCtx (in seconds) with R2 = .97 (Equation 1).
avgT imeSCtx = −1.64 + 1.57 × 10−5 × totalRules+ 1.14 × 102 × numCtx + 2.05 × 10−8 × totalRules × numCtx (1) 6
We implemented contextualized rule repositories for the semantic web using
SPIN, based on previous work on contextualized business rules [
Contextualized rule repositories using SPIN render large rulesets manageable. Concerning execution performance the granularity of the contexts matters. Fine granularity of contexts negatively affects, coarse granularity of contexts positively affects average runtime of rulesets. In our use case the threshold for positive impact of context granularity was approximately 40 rules per context. The threshold may vary depending on the use case, rule complexity, hardware configuration, and software configuration.
The current SPIN implementation of the contextualized rule repository
realizes only a subset of the contextualized business rule model. Future work will
investigate the implementation of additional relationships for contexts and
parameter values as well as modification operations [