=Paper=
{{Paper
|id=Vol-1936/paper-09
|storemode=property
|title=Towards Contextualized Rule Repositories for the Semantic Web
|pdfUrl=https://ceur-ws.org/Vol-1936/paper-09.pdf
|volume=Vol-1936
|authors=Felix Burgstaller,Christoph Schütz,Bernd Neumayr,Dieter Steiner,Michael Schrefl
|dblpUrl=https://dblp.org/rec/conf/semweb/BurgstallerSNSS17
}}
==Towards Contextualized Rule Repositories for the Semantic Web==
https://ceur-ws.org/Vol-1936/paper-09.pdf
Towards Contextualized Rule Repositories
for the Semantic Web
Felix Burgstaller, Christoph G. Schuetz, Bernd Neumayr, Dieter Steiner,
Michael Schrefl
Department for Business Informatics - Data & Knowledge Engineering
Johannes Kepler University Linz, Austria
firstname.surname@jku.at
Abstract. Central to the semantic web are ontologies: shared concep-
tualizations 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 repos-
itories – 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 aeronauti-
cal domain. Furthermore, we compare SPIN-based contextualized rule
repositories to a context-unaware SPIN implementation.
Keywords: Context, ontologies, business rules, SPIN
1 Introduction
Ontologies and ontology languages are at the heart of the semantic web. Ontolo-
gies are shared conceptualizations of domains of interest expressed in machine-
readable formats, i.e., ontology languages [16]. Among the most common ontol-
ogy languages for the semantic web are RDF(S) and OWL. Companies increas-
ingly employ semantic web technologies to build semantic information systems,
leading to corporate semantic webs [12].
Large heterogeneous knowledge repositories are rendered manageable by the
introduction of context. A context constrains the validity of contextualized knowl-
edge. Typically, contexts are hierarchically organized. A theoretical foundation
for representing contextualized knowledge and reasoning about contexts was in-
troduced by McCarthy [11]. The CYC project, a knowledge base containing
100,000 general concepts, employs contexts to organize its knowledge [10]. Con-
texts are also employed in the semantic web, e.g., the metaview approach [17]
which introduces a framework to manage metalevel information of OWL axioms.
A more recent approach are contextualized knowledge repositories [15] where
the meaning of ontological concepts depends on the context. Concepts propagate
from more general contexts to more specific contexts. A context is characterized
by attributes from different context dimensions. For example, aeronautical con-
cepts may be interpreted differently depending on geographic region and govern-
ing body. In this case geographic region and governing body are the dimensions
that determine context.
In the semantic web stack [1], rules and rule languages complement ontologies
and common ontology languages such as OWL, which typically trade expressive-
ness for general decidability. Rules enable, for instance, inference of properties
or extra-logical operations such as calculations. In the corporate semantic web,
rule languages may express business rules. A W3C recommendation for a rule
language is the Rule Interchange Format (RIF) [18], an XML language primarily
designed to exchange rules. RIF provides different dialects, catering to different
needs in rule definition, e.g., production rules. The most common rule languages
for the semantic web are SWRL and SPARQL-based languages.
Complementing ontologies organized in contextualized knowledge reposito-
ries 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 contextual-
ization, tailored specifically to the particularities of rules, is necessary. Such a
mechanism are contextualized rule repositories [5, 4].
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 seman-
tic web. We provide an implementation of contextualized business rules [5] using
the semantic web technologies OWL and SPARQL Inferencing Notation (SPIN)
[9]. Furthermore, we investigate, using a real-world use case from the aeronau-
tical domain, the feasibility of a SPIN-based contextualized organization and
execution of rules and compare it to a solution without contexts.
The remainder of this paper is structured as follows. Sect. 2 provides back-
ground 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 Background
In this section we present the conceptual framework for contextualized rule repos-
itories [5] and related work.
2.1 Contextualized Business Rules
We previously introduced a generic conceptual context model for contextualized
business rules [5]. This context model is multi-level, i.e., it can be instantiated to
a specific domain, e.g., the aeronautical domain, and subsequently to a particular
application within the domain, e.g., filtering aeronautical messages. A simplified
version of this model is depicted in Fig. 1. The preceding “/” indicates a derived
Fig. 1. The generic context model for business rule management.
relationship, the superscript numbers indicate the potency (default 1 ), i.e., how
many levels below the attribute or relationship must be instantiated.
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 busi-
ness vocabulary (businessVocab) applying for them. Parameter value hierar-
chies 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 , 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 re-
solved, 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 .
2.2 Related Work
A Contextualized Knowledge Repository (CKR [15]) for the semantic web or-
ganizes ontological concepts in a space of hierarchically-ordered contexts. Each
context is characterized by a set of attributes from different context dimensions.
The attributes of the context dimensions can be hierarchically ordered. The hier-
archical order of contexts is derived from the hierarchical order of the dimension
attributes. Concepts of more general contexts propagate to the more specific
contexts. The same concept may assume a different meaning in different con-
texts. Since rules in the semantic web are commonly represented using OWL or
RDF(S), a CKR may also serve to organize sets of rules. In that case, however,
rule execution must be taken care of by another component. Furthermore, CKRs
lack a mechanism for automatic determination of relevant contexts for a business
situation that initiates rule execution.
Apart from the semantic web, many commercial business rule management
systems (BRMSs) offer the possibility to organize rules into rulesets. These com-
mercial 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 [7] or regarding business dimensions like con-
cerned business objects [13]. More sophisticated approaches organize rules by
multiple attributes, e.g., by situation [14] or linking business rules with goals
[8]. These systems typically lack support for free definition of attributes, and
often support only inclusion relationships between rulesets. Thus, compared to
these approaches contextualized rule repositories are more flexible with respect
to context parameters and enable automatic context-specific execution of rules.
3 Use Case: Classification of Aeronautical Messages
We previously demonstrated usefulness of contextualized business rules in the
aeronautical domain [5] as part of the Semantic NOTAM research project (Sem-
NOTAM [3]). In particular, we applied contextualized rules to relevance and
importance classification of aeronautical messages for flight operations person-
nel. SemNOTAM must be seen in the wider context of System Wide Information
Management (SWIM [6]). SWIM’s vision is to create a shared understanding of
information and to provide relevant information to SWIM consumers. In this
sense, SWIM can be considered a corporate semantic web application for the
aeronautical domain. Relevance and importance classification of aeronautical
messages is essentially classification by rules which can be represented using se-
mantic web rule languages. We employ SemNOTAM as use case for a feasibility
study of contextualized rule repositories in the semantic web.
Apart from the aeronautical domain, the proposed approach can be applied
to other domains as well. For example, a person’s eligibility for retirement de-
pends 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 SemNO-
TAM instantiating the general model in Fig. 1. This model focuses on clas-
sification 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: mete-
orological condition (MeteoCond) and aircraft type (AircraftType). Other pa-
rameters 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 proper-
ties 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.
Fig. 2. A context model for rule-based message filtering in the aeronautical domain
and a concrete application instantiation.
We instantiate the presented domain-specific context model to an application-
specific 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 con-
ditions (IMC) and rotary aircrafts. Besides these contexts, we specify a con-
crete 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 case-
specific 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 Contextualized Rule Repositories using SPIN
SPIN is a SPARQL-based rule and constraint language integrating concepts from
rule-based systems, query languages, and object-oriented languages. SPIN en-
ables formal description of object behavior, i.e., SPIN statements are assigned
1 CONSTRUCT { spin : _this highImportance ? n . }
2 WHERE { ? n rdf : type notams : A e r o d r o m e L i g h t i n g N O T A M . }
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 : A e r o d r o m e L i g h t i n g N O T A M . }
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 [9] comprises the SPIN modeling vocabulary and an
RDF representation of SPARQL. The SPIN modeling vocabulary supports in-
ference rules (spin:rule), constraints on classes (spin:constraints), and construc-
tors (spin:constructor). These are specified using SPIN’s RDF representation of
SPARQL. For instance, the SPARQL representation of the rule from our use
case defining aerodrome closure NOTAMs (AerodromeLightingNOTAM) to be of high
importance (highImportance) within context IMCMeteoRotary is shown in Listing 1;
Listing 2 depicts the corresponding context-unaware rule. SPIN rules can be or-
ganized into rule libraries. Furthermore, the SPIN modeling vocabulary supports
user-defined execution orders of SPIN-rules, user-defined rule templates, and
user-defined functions. The latter two features increase rule readability and pro-
mote reuse of rules. Implementing contextualized rule repositories using SWRL
would require workarounds as for example rules cannot be assigned to classes
and thus rule execution of only relevant rules is difficult. Furthermore, since we
consider businesses, the use of standards, such as SPARQL, is preferable.
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. Param-
eters 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 hier-
archies using a reasoner. The two ontology variants are:
1. Ctx: employing object properties (Listing 3) as modeled in [5, 4] and
2. SCtx: subclassing (Listing 4) presumably faster in evaluation.
1
http://topbraid.org/spin/api/
1 Class : IMCMeteoRotary
2 EquivalentTo :
3 InterestSpec
4 and meteo some MeteoCond
5 and aircraft some RotaryAircraft
6 SubClassOf :
7 Context
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 de-
scribing properties as contexts do, i.e., either by subclassing or using object
properties. In the simplest configuration, describing properties instantiate or re-
fer 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 multi-
ple 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 [5] also consider business vocabulary. Thus,
SPIN-based contextualized rule repositories should enable contextualized vo-
cabulary as well. One option is to represent the entire vocabulary using SPIN
rules. In this case, however, a reasoner would have to first execute the vocabulary
rules before making inferences. Modeling vocabulary explicitly, one ontology per
context containing the context’s vocabulary is necessary. These ontologies must
be imported in Ctx and SCtx respectively to enable their use in SPIN rules, i.e.,
1 Individual : iSpec1
2 Types :
3 InterestSpec
4 Facts :
5 aircraft BellAugusta ,
6 meteo Fog
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 [15].
We expect the proposed SPIN implementation of contextualized rule reposi-
tories to outperform context-unaware solutions. Nevertheless, as this implemen-
tation 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 Feasibility Study
To demonstrate the feasibility of our proposed SPIN-based contextualized rule
repositories for the semantic web, we evaluate our hypotheses utilizing SemNO-
TAM 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 , messages of are of 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 as-
sume that the complexity of rules influences context-aware and context-unaware
ontology variants alike; an empirical evaluation of this assumption is outstand-
ing. Regarding interest specifications we assume the simple configuration, i.e.,
parameter values are directly assigned. The complex configuration requires ad-
ditional 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 cor-
responding ontology variants. Furthermore, random interest specifications need
to be generated in order to find the suspected threshold. Consequently, we con-
structed a generator accepting six parameters determining the size and com-
plexity 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), pa-
rameter 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 per-
formance in preliminary tests. Ontology metrics for two sample context models
are depicted in Table 1 . We measured the time for loading and for SPIN infer-
ence 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 sim-
plest, i.e., they contain the fewest terms. Analyzing the loading times for the
different ontology variants in detail showed that the average time mainly de-
pends 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
Table 1. Ontology variant metrics for two sample context models.
Ontology Variant # Contexts # Rules # OWL Axioms Size
SCtx 3,300 53.7 kB
16 160
(S)NoCtx (4,200) 6,000 (78.7 kB) 114.7 kB
SCtx 2,200,000 53 MB
1,800 180,000
(S)NoCtx (4,300,000) 7,900,000 (111 MB) 187 MB
Fig. 3. Average response time vs. total number of rules grouped by rules per context.
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 in-
ference 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 num-
ber 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. Further-
more, 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-per-
context 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. Further-
more, 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)
1.14 × 102 × numCtx + 2.05 × 10−8 × totalRules × numCtx
6 Conclusion
We implemented contextualized rule repositories for the semantic web using
SPIN, based on previous work on contextualized business rules [5]. This SPIN
implementation feeds inferred knowledge directly into the ontology. Knowledge
inferred by rules is then available for ontological and rule based reasoning.
Contextualized rule repositories using SPIN render large rulesets manage-
able. 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 re-
alizes only a subset of the contextualized business rule model. Future work will
investigate the implementation of additional relationships for contexts and pa-
rameter values as well as modification operations [4]. Worth further consideration
is the integration of contextualized rule repositories in the formal framework of
contextualized knowledge repositories [15]. Furthermore, we consider implemen-
tations using different rule languages such as SWRL and SPRINGLES [2].
Acknowledgments. Supported by the Austrian Ministry of Transport, Inno-
vation, and Technology under grant FFG-839006 (SemNOTAM).
References
1. Berners-Lee, T.: Semantic web and linked data (2009), https://www.w3.org/2009/
Talks/0120-campus-party-tbl/
2. Bozzato, L., Serafini, L.: Materialization calculus for contexts in the semantic web.
In: Informal Proceedings of the 26th International Workshop on Description Logics.
pp. 552–572 (2013)
3. Burgstaller, F., Steiner, D., Schrefl, M., Gringinger, E., Wilson, S., van der Stricht,
S.: AIRM-based, Fine-grained Semantic Filtering of Notices to Airmen. In: Inte-
grated Communication, Navigation, and Surveillance Conference (ICNS). pp. D3–
1–D3–13 (2015)
4. Burgstaller, F., Neumayr, B., Schuetz, C.G., Schrefl, M.: Modification operations
for context-aware business rule management. In: 2017 IEEE 21st International
Enterprise Distributed Object Computing Conference (EDOC) (2017), (in press)
5. Burgstaller, F., Steiner, D., Schrefl, M.: Modeling Context for Business Rule Man-
agement. In: 2016 IEEE 18th Conference on Business Informatics (CBI). pp. 262–
271 (2016)
6. Eurocontrol: System Wide Information Management (SWIM) (2017), http://www.
eurocontrol.int/swim
7. Hamza, H., Fayad, M.: A novel approach for managing and reusing business rules
in business architectures. In: The 3rd ACS/IEEE International Conference onCom-
puter Systems and Applications. pp. 973–978 (2005)
8. Kardasis, P., Loucopoulos, P.: Expressing and organising business rules. Informa-
tion and Software Technology 46(11), 701–718 (2004)
9. Knublauch, H., Hendler, J.A., Idehen, K.: SPIN - Overview and Motivation (2011),
https://www.w3.org/Submission/spin-overview/
10. Lenat, D.B.: CYC: A large-scale investment in knowledge infrastructure. Commun.
ACM 38(11), 33–38 (1995)
11. McCarthy, J.: Notes on formalizing context. In: Proceedings of the 13th Interna-
tional Joint Conference on Artifical Intelligence. vol. 1, pp. 555–560 (1993)
12. Paschke, A., Coskun, G., Heese, R., Luczak-Rösch, M., Oldakowski, R.,
Schäfermeier, R., Streibel, O.: Corporate Semantic Web: Towards the Deployment
of Semantic Technologies in Enterprises, pp. 105–131. Springer, Boston (2010)
13. Rai, V.K., Anantaram, C.: Structuring business rules interactions. Electronic Com-
merce Research and Applications 3(1), 54–73 (2004)
14. Schäfer, A., Kreher, M.: Wie strukturiere ich meine Business Rules für eine
effektive Pflege und Steuerung von kritischen, komplexen und dynamischen
Geschäftsprozessen. In: GI Jahrestagung, vol. 1, pp. 213–218 (2010)
15. Serafini, L., Homola, M.: Contextualized knowledge repositories for the semantic
web. Web Semantics: Science, Services and Agents on the World Wide Web 12–13,
64–87 (2012)
16. Staab, S., Studer, R.: Handbook on Ontologies. Springer Publishing Company,
Incorporated, 2nd edn. (2009)
17. Tran, T., Haase, P., Motik, B., Grau, B.C., Horrocks, I.: Metalevel information in
ontology-based applications. In: Proceedings of the 23rd National Conference on
Artificial Intelligence - Volume 2. pp. 1237–1242 (2008)
18. World Wide Web Consortium (W3C): RIF Overview (Second Edition) (2013),
https://www.w3.org/TR/rif-overview/