Information Technology Reference
In-Depth Information
pacts) as roles. Moreover, inter-actor relations (e.g., delegation, trust, monitoring) are
encoded as concepts as well, since they are ternary relations. Later, we discuss some
considerations that underlie our formalization.
In the following, we discuss some issues that have arisen while formalizing concept-
s/relations of the language in terms of DL concepts/roles.
Role versus Subsumption.
The relationship between a goal and its subgoals could
have been represented as a subsumption relationship or a role, say
hasSubgoal
:
Subgoal
Goal vs. hasSubgoal.Goal
But instances of a subgoal do not need to also be instances of the parent goal (for exam-
ple, consider goal “schedule meeting” and subgoal “collect timetables”). Accordingly,
we chose to go with the second option.
Ternary/n-ary relations.
Since OWL-
,
we decided to represent such relationships in terms of a concept and several roles. For
example,
DL
does not support N-ary relations,
N
≥
3
DelegationOnExecution
≡
DelegationOnExecution
(
hasDelegator
=1)
(
hasDelegatum
=1)
(
hasDelegatee
=1)
Consider Fig. 1, where
Team Sector
delegates execution of
manage traffic in the
sector
to
Executive Controller
.IntheABox,adelegationonexecutioninsucha
setting is represented as follows:
DelegationOnExecution
(
Del-exec1
)
hasDelegator
(
Del-exec1
,
Team Sector
)
hasDelegater
(
Del-exec1
,
Executive Controller
)
hasDelegatum
(
Del-exec1
,
Manage traffic in sector
)
4.2
Understanding and Formalizing a Pattern as a Query
Once designers specify the pattern language in the DL TBox, the next step is under-
standing the essence of the pattern description and formalizes the context in terms of
OWL queries (i.e., using terms specified in the DL TBox). Designers need to be aware
that some patterns are very generic and sometimes vague, (e.g., patterns described in
natural language in [8]), and others are rather restrictive because of the limitation of
the pattern language (e.g., patterns described using a modeling language, such as [6]).
In this phase, we leave it in the hands of the designers to decide how much detail they
want to put into the patterns or how generic the pattern should be.
In [6], the context of the patterns is modeled in terms of an “abstract” SI* model
that includes variables (denoted by identifiers with capitalized letters). For instance in
