=Paper=
{{Paper
|id=Vol-1420/wois-paper3
|storemode=property
|title=Experiences from Ontology Development for Service Innovation in Transportation Industries
|pdfUrl=https://ceur-ws.org/Vol-1420/wois-paper3.pdf
|volume=Vol-1420
|dblpUrl=https://dblp.org/rec/conf/bis/KocLS15
}}
==Experiences from Ontology Development for Service Innovation in Transportation Industries==
https://ceur-ws.org/Vol-1420/wois-paper3.pdf
Experiences from Ontology Development for Service
Innovation in Transportation Industries
Hasan Koç, Birger Lantow and Kurt Sandkuhl
University of Rostock, Institute of Computer Science,
Chair Business Information Systems
Albert-Einstein-Str. 22, 18059 Rostock, Germany
{hasan.koc, birger.lantow, kurt.sandkuhl}@uni-rostock.de
Abstract. Many industries experienced a shift in sourcing and logistics
strategies, the industrial demand for more dynamic logistics solutions with
adequate IT support is increasing. Due to advances in wireless sensor net-
works and technologies, the transportation area in logistics industry is the
most promising application field for new types of innovative services. The
emerging applications in this field require an integrated knowledge base to
provide enhanced customer services. The aforementioned trends will lead to
service innovation if the adaptation of business models is ensured. Our ear-
lier work focused on adaptable business models [1] and argued that
knowledge representation techniques are suitable concepts to improve self-
organization [2]. In this paper we introduce the core component of the
knowledge architecture represented as ontologies and report experiences
from the development process. The contributions of this paper are (a) a de-
tailed description of the ontology construction process based on a real-
world scenario, (b) experiences from the development process and, (c) pro-
posed adaptations of an established ontology engineering approach.
Keywords: Service innovation, experience report, transportation surveil-
lance, information logistics, enterprise ontology.
1 Introduction
The logistics industry has changed under the impact of the internal European mar-
ket and of an increasing globalization into a high-technology industry, making in-
tensive use of modern information technology. At the same time, the industrial
demand for more dynamic logistics solutions with adequate IT support is increas-
ing. Within the logistics industry, the transportation area is the most promising ap-
plication field for new types of intelligent services, since advances in wireless sen-
sor networks and sensor/actuator technologies allow for new ways of tagging and
tracking goods and vehicles.
From the perspective of enterprises offering transportation services, the above
technology trends will only lead to successful service innovation if the underlying
Copyright © 2015 by the authors. Copying permitted for private and academic purposes.
This volume is published and copyrighted by its editors.
136
business model can be adapted to new opportunities and the organizational and IT-
infrastructure provide adequate support. In earlier work we showed that self-
organizing systems contribute to adaptability of business models [1] and that
knowledge architectures and knowledge representation techniques are suitable
concepts to improve self-organization [2]. This paper will focus on the engineer-
ing process of the actual core component of the knowledge architecture: an ontol-
ogy for transportation surveillance (OTS).
Ontology-based modeling approaches are frequently applied when the models
to be developed are supposed to contribute or be the basis for knowledge-based
systems in enterprises. Experience reports and practice in the field of ontology en-
gineering usually focus only on construction principles for the ontology, the use of
certain modeling languages or ways to avoid flaws (see section 3.2). Experiences
with ontology engineering methods, the integration of enterprise stakeholders or
work distribution are rarely reported. The aim of this paper is to contribute to the
body of knowledge in ontology engineering for service innovation by reporting
from a project in ontology development for transportation, which is supposed to
be used for new kinds of services based on wireless sensor networks and an adapt-
able knowledge base. The contributions of this paper are (a) a description of the
ontology construction process based on a real-world scenario, (b) experiences
from the development process and, (c) proposed adaptations of an established on-
tology engineering approach.
The remaining part of the paper is structured as follows: section 2 introduces
the industrial application case including requirements to the knowledge base. Sec-
tion 3 summarizes the background for the work from the area of ontology engi-
neering. Section 4 describes the ontology engineering process performed in much
detail. Section 5 discusses experiences from the ontology engineering project. Sec-
tion 6 summarizes the work and draws conclusions.
2 Application Case: Trailer Surveillance in Transportation
The application case from transportation industries selected for this paper (see Fig.
1) is based on an industrial research and development project from transport and
logistics industries. One of the world’s largest truck manufacturers is developing
new transport related services based on an integration and orchestrated interpreta-
tion of different information sources, such as on-board vehicle information sys-
tems, traffic control systems and fleet management systems. The aim is to use
wireless sensor networks (WSN) in trailers for innovative applications. The wire-
less sensor network is installed in the position lights of a trailer. Each position
light carries a sensor node able to communicate with neighboring nodes and
equipped with a radar sensor. The radar sensor could be used for protecting the
goods loaded on the trailer against theft, offering additional assistance to the driv-
er of the truck (e.g. blind spot support) or for surveillance of the goods (e.g. seal-
137
ing different compartments of the trailer). The wireless sensor network in the posi-
tion lights is controlled by a gateway in the trailer, which communicates with the
back-office of the owner of the trailer or the owner of the goods.
Fig. 1: Simplified Architecture of the Application Case
One of the use cases defined in the project is a new service, which is offered to
protect the goods loaded on the trailer against theft. More precisely, the main
doors of the trailer are equipped with an additional “electronic” seal. An analysis
of current work procedure in the case study showed that when transporting expen-
sive goods, the sending unit of a hauler mounts a physical seal on the trailer’s
doors and takes a picture of this seal. At the destination, the receiving unit checks
whether the seal is broken and compares it with the picture taken at the destina-
tion. This error-prone manual sealing process would be improved with an elec-
tronic seal. If the electronic seal protection service is booked by the trailer owner,
the goods are loaded on the trailer, doors closed, and seal device is activated,
which also activates the protection mode for the trailer. At arrival, the responsible
person sends the “unlock” request. If the authorization process for the responsible
person is successful and the person is in the close vicinity of the trailer, the elec-
tronic seal is de-activated. In order to implement such service, various kinds of
knowledge need to be available; observations acquired through the different sen-
sors in the trailer have to be combined with information coming from other
sources, like an authentication service for the driver’s identity. Furthermore, we
have to detect potential critical events by inferring new knowledge, according to
what is offered to the customers by the booked IT services. For this purpose, the
knowledge base had to accommodate basic transportation domain knowledge, the
sensors and their observation possibilities, and a conceptual model for situations.
138
3 Background
As a background for the work presented in this paper, we will describe relevant
work in the area of ontology engineering.
3.1 Ontology Engineering Methodologies
Ontology construction is a challenging task and ontology engineers are in need of
methods and guidelines to increase the possibility of the project success ([8], [9]).
Due to the fact that the methodologies for ontology development have been sub-
ject to research during a number of years there has been a series of approaches
proposed for developing ontologies [3]. We share the view that ontology devel-
opment methodologies can be classified as experience-based methodologies and
evolutive prototypes [10]. Both types consist of two phases on a very high level;
the specification phase to acquire informal knowledge on the domain, and the
conceptualization phase, which structures and represents this knowledge formally.
These are normally followed by additional phases, such as evaluation, actual im-
plementation, deployment and integration with a usable system.
Under the investigated approaches for ontology engineering, we selected the
method of Noy & McGuinness mainly due to our experiences from earlier ontolo-
gy development projects. The approach was extended in the development of the
Ontology for Trailer Surveillance (OTS) by two more steps. After creating in-
stances, the rules for more powerful reasoning need to be formulated, which also
provide a consistent knowledge base. Next, the concept of defined classes is ap-
plied, i.e. if an individual fulfills the necessary and sufficient conditions given by
the defined class, then it is inferred to be a member of this class. Table 1 summariz-
es the analyzed approaches and the reasons why they were not applied in the on-
tology development.
Table 1: Analyzed Methods for the engineering of OTS
Method Name Method Type Reason for including or excluding
Uschold&King’s meth- Experience- Evaluation step was not part of the project as-
od [4]. based signment
TOVE [22]. Experience- Formal specification of important concepts de-
based creases the understandability of concepts by
stakeholders
METHONTOLOGY Evolutive Very detailed and complex for the project pur-
[5] pose
Noy&McGuinness [20] Evolutive Ease of use and experiences from earlier appli-
cations
139
3.2 Practices in Ontology Engineering
There is only a number of articles that reflect practices from ontology engineering
and provide the results of applying a development method, most of the work re-
ports experiences with ontology development methods in the conclusion sections,
if at all. [8] discusses strong points and weakness of the Systematic Approach for
Building Ontologies (SABiO) ontology development approach and proposes im-
provement opportunities. [9] develops an ontology based on the guidelines pro-
vided by METHONTOLOGY, examines the method utility and addresses the
drawbacks. [11] presents results of the practice of ontological engineering without
addressing any specific method. [10] reflects experiences from merging different
ontology development methods and best practices in software engineering. Finally
[12] reports on lessons learned during the development of an ontology using the
EXPLODE method for value-added publishing. As a result of these findings we
argue the necessity of experience reports in ontology engineering domain.
4 Development of the Ontology for Trailer Surveillance
In this section we describe the development of a knowledge base represented
by the Ontology for Trailer Surveillance (OTS) for the transportation use case pre-
sented in section 2. In this section, we first motivate the basics of the OTS and
then construct the knowledge base that provides the required features.
4.1 Basics of the Ontology for Trailer Surveillance
As discussed in section 2, the ontology needs to be able to capture knowledge
about sensors, situations and the application domain of transportation as such. For
this purposes different information models in sensors, observations, situation
(awareness) and time domains are investigated. Utilizing the reusable components
of these models, the domain model should be able to conceptualize the knowledge
base for offering services in transportation sector. Moreover it should serve a basis
to prepare a list of important terms for the particular domains, which could be
used as classes and/ or properties.
Part of the domain model covers the sensors in the trailers and the control hier-
archy, which at least consists of the sensor nodes and the trailer gateways and the
trailer fleet of a customer of a service type. For the trailer-WSN related part of the
domain model, The Open Geospatial Consortium (OGC) sensor web enablement,
in particular the observations and measurements (O&M) and The Starfish Fungus
Language (*FL) [7], was taken as starting point to allow expressing the sensing
procedures. Both specifications assure a possible integration with Sensor Observa-
tion Service (SOS), a standard that allows querying observations, sensor metadata
as well as representations of observed features. In this respective, concepts from
140
an observation ontology, Semantic Sensor Observation Service (SemSOS or
O&M-OWL), are adopted, which takes the advantages of representing the sensor
data in OWL and enabling reasoning over sensor observations [19].
OTS adopts the situation awareness paradigm, which describes the state of af-
fairs by observing the relations between objects or entities, as the relations be-
tween subjects constellate various situations [21]. A subject is aware, if he is ca-
pable of observing some objects and making inferences from these observations.
To represent various situations and the relations between them, Semantic Web
Rules Language (SWRL) is used, which provides the ability to add Horn-like rules
expressed in terms of OWL concepts [6].
Table 2: Modelling domains and selected approaches
Domain Selected Approaches
Modelling Rules SWRL
Modelling Time Allen´s Model
Information Valid Time Model
Modelling Sensors and OGC Standards
Observations SemSOS
Modelling Situations Situation Awareness
OWL provides minimal support for modeling the temporal relations as well as
temporal information. As a result, ontologies often cannot fully express the tem-
poral knowledge needed by applications, users and engineers develop ad hoc solu-
tions. OTS adopts Allen’s time intervals algebra that has six basic time intervals
constituting a sum of 13 temporal interval relations [17]. On top of this, the valid-
time temporal model is applied [18], which represents the time information by
providing a lightweight temporal model. The selected approaches as well as their
application domains are illustrated in Table 2.
4.2 Application of Noy & McGuinness Approach
Step 1: Determine the domain and scope. In this step the requirements for the
ontology to be developed are listed. In addition to the requirements presented in
section 4.1, the OTS should cover the transportation domain with a primary focus
on the surveillance of the transportation instances at ground (haulage), i.e. trucks
and trailers. OTS aims to serve as a knowledge base to offer flexible customer
services to protect the transport instances from thievery by processing contextual
knowledge, which may arise from different situations. In order to specify the re-
quirements on the ontology, we put together a list of competency questions. As
shown in Table 2, the questions are classified in accordance with their abstraction
level, which is detailed in section 5.
141
Table 3: Competency questions and their classification
Concept Code Abstraction Level
Domain-Level Application Level
Observation OCQ 1 Which observations are propagated Give me the observations
from a feature of interest? which are assessed from a
particular trailer instance
Sensor SeCQ 1 Which sensors provide the observa- Which sensor instances
tions? provide information about
the velocity?
Event ECQ 3 Which events are captured from the Is trailer 1 in a safe loca-
features? tion?
Situation SCQ 1 What is the temporal property of a When was the e-seal of
particular situation? trailer1 broken?
Step 2: Consider reusing existing ontologies. We searched for the existing on-
tologies that might be reused, i.e. refined or extended. Unfortunately neither
transport domain ontologies nor information models for the truck-trailer surveil-
lance domain were identified. Nevertheless the reviewed models were to some ex-
tent reusable, e.g. through the models, ontologies and approaches introduced in
section 4.1, it was practicable to identify important terms & controlled vocabular-
ies (Step 3), to define the classes, class hierarchies as well as the relationships be-
tween them (section Step 4&5). Hence, it is possible to reuse existing ontologies
or even models as an instrument to identify semantic specifications in the domain.
This also offers the possibility to align the ontology to the existing knowledge
base or standards in the future.
Step 3: Enumerate important terms in the ontology: Although it has not been
prescribed in Noy & McGuinness Methodology the terms utilized in the
knowledge base should semantically be explained in order to create a basic termi-
nology and a common understanding among the users as well. For this purposes,
we defined some key concepts in trailer surveillance domain such as Event (con-
cepts which are caused by observations [16]), Feature (representation or the ab-
straction of the real world entity that exists in physical reality [15]), Observation
(act of observing a property [7]), Phenomenon (a physical property that can be ob-
served and measured [7]), Sensor (a source producing a value within a value space
representing a phenomenon in a given domain of discourse [14]). In this step, we
mostly used the approaches that were introduced in section 4.1 alongside with the
ontologies that we have searched for reusability purposes.
Step 4: Define the classes and the class hierarchy. Important concepts like Ob-
servation, Event, Sensor, Situation or Feature are represented as classes. For nam-
ing the classes the CamelCase naming convention is applied. The situation
classes define and implement the customer services. Hence they are the most im-
portant classes in the OTS. The situation class has six defined subclasses -
four of which represent the services (see Fig. 2). New services can emerge in the
future, which require the assessment of different situations. For instance, the El-
ementarySituation class has no direct function in the OTS whereas it might
142
be used in the future to exploit customer’s preparedness to pay for the services,
e.g. booking an elementary situation can be provided at a lower price than booking
a complex situation, which is represented by ComplexSituation class. Such
services can be realized by adding more rules to the knowledge base. An excerpt
from the class hierarchy is illustrated in Fig. 2.
Fig. 2. Class hierarchy in OTS
Step 5 & 6: Define the properties and cardinalities. The classes alone cannot
provide enough information in an ontology, the properties of these classes are also
necessary to constitute the OTS. Due to the low support of OWL concerning the
modeling of temporal relations (see section 4.1), we applied the object properties
“before, during, equal, meets” following Allen´s temporal intervals. To
represent the time information in intervals, hasBegin-hasFinish data type
properties are used. The object property deliversIn is used to capture infor-
mation about the trailers that deliver the goods in particular cities, which are en-
tered manually by the trailer or goods owner to the information base. After defin-
ing the properties, the Noy & McGuinness Methodology determines the
cardinality of the properties, which can be carried out parallel to step 5.
Step 7: Create instances, rules and defined classes. This step extends the Noy &
McGuinness Methodology by not only creating instances, but also specifying rules
and defined classes. The rules are mainly created to provide consistent time repre-
sentation such as “if an event meets a second event, which in turn meets a third
event, then the first event is before the third event” or to contribute to the con-
sistency of the ontology.
The defined classes have necessary and sufficient conditions that have a defini-
tion. Classes, all of whose individuals satisfy this definition, can be inferred to be
subclasses of a defined class. In the OTS, the concept of the defined classes is
used for defining certain event and situations. As an example, a “distance event” is
represented by the following conditions: i) there is an individual, which is a mem-
ber of an event class that is created based upon an observation and ii) the observa-
tion has at least one result and iii) the result has at least one hasDistance data
type property with an integer value greater than “1”. The first and second condi-
tions are named as “pattern conditions” since most of the defined classes reuse,
extend and build upon them. We argue that identification of such reusable frag-
ments are beneficial for the ontology engineer when creating rules and conditions.
143
5 Experiences from Ontology Engineering
Experiences and recommendations presented in this chapter were based on the
industrial case introduced in section 2 and the engineering process described in
section 4. The experiences include the areas of ontology development method, on-
tology reuse and tool selection.
Ontology Development Method
Developing an ontology is necessarily an iterative process with several interrela-
tionships between the process elements. To maintain the overview, relate the out-
comes of the different phases of ontology development and to determine the im-
provement points method application is required. The ontology engineer should
consider the use case requirements to decide which method provides the best sup-
port and in some situations and the methodology must allow the engineer to carry
out minor adaptations. In this respective, the method of Noy & Mc Guinness was
chosen, which consists of 7 steps. This approach is extended applying two more
steps as described in section 3.1.
The most important step in the ontology development is determining the scope.
For which purposes is it being developed? What are the competency questions that
an ontology has to answer? Such questions specify the requirements that the de-
veloped ontology should meet. When constructing the competency questions, the
necessity of classifying the questions and giving them an explicit structure became
apparent. Therefore we classified the competency questions as high-level and low-
level questions. Questions with a high-level abstraction can be adapted to various
domain ontologies, which conceptualize observation models and they can be re-
ferred as "domain-level questions". The choice of word ”domain” is intentional
and designates the reusability aspect of high-level competency questions by other
ontology engineers. The concrete implementations of high-level questions are re-
alized with the help of low-level questions. These are relevant for an application in
a given domain, for which the ontology needs to be developed respectively. Thus,
the low-level questions are referred as ”application-level questions”. For instance,
in a scenario where an engineer develops an ontology for an ecological domain to
sustainably manage the natural environment, the engineer would probably need to
model the observed data, identify their relevancy and appropriately integrate the
sensory information. Therefore domain-level questions, such as "what is being ob-
served" or "which sensors propagate the observations" has to be answered. The
”application-level questions” on the other side would relate to the ontology use.
Due to time and resource restrictions the investigation in transportation domain
was not executed in detail and thus the domain specific competency questions
were formulated on a rather general level (see also following subsection). This had
consequences in the latter stages of the ontology development, e.g. domain specif-
ic transportation terms were not specified in detail in OTS.
Ontology Reuse
Even though the early development phases of the ontology included an extensive
investigation of existing ontologies and their possibilities of reuse in the relevant
144
fields such as situation awareness, observing and measuring sensory information
and time representation, we were not able to use an off-the-shelf ontology. The
identified ontologies were only to some extent suitable to meet the competency
questions. Thus, we recommend developing clearly defined competency questions
also for supporting the selection of reusable ontology parts. Nevertheless, the ex-
tensive search process for relevant models and ontologies has given an idea of
how to name the concepts and relate them to each other (steps 4, 5 and 6). To
some extent, this can be considered as reuse of concepts and relations from ontol-
ogies rather than as reuse of ontology parts. As a result the ontology engineer
should think of reusing existing ontologies also as an instrument to identify se-
mantic specifications of the relevant domain, e.g. situations, observations and sen-
sors. Such specifications would also enhance the interoperability of the knowledge
base to the existing ontologies or standards. Also from the standardization point of
view our investigation in the transportation logistics domain did not result in sig-
nificant outputs, i.e. no guidelines were identified including the semantic of the
terms in the domain, models and frameworks were not publicly accessible.
Tool selection
Exact specification of the ontology requirements has an important impact on the
development process. This was the case during the tool selection. As there was no
support to carry out a requirement analysis in Noy & McGuinness method, the
Protégé 4.x was chosen as the ontology development tool at the beginning of the
project based on the positive experiences in the past. In fact, using the 4.x versions
instead the 3.4.x version affected the modeling of the temporal information. We
applied the valid-time temporal model represented in [18], which is compatible
with SWRL and can be queried with SQWRL. However the temporal built-ins re-
quired for querying temporal data were not supported in Protégé 4.2. We recom-
mend defining the requirements that a tool has to fulfill after formulating the com-
petency questions and searching for reusable ontologies.
6 Summary and Future Work
Based on an industrial research and development project, the paper describes
experiences from an ontology development process for offering innovative ser-
vices in transportation industry. The developed ontology will form the basis for
various services offered by an enterprise active in the transport domain with the
intention to exploit the potential of new types of sensor and actuator systems for
the purpose of information logistics and security services. The main limitation of
the research is that the empirical grounding should be improved by evaluating the
ontology as well as increasing the number of cases applying the OTS.
Future activities will have to include work on the ontology as such and on ser-
vices using the ontology. The ontology so far was not constructed as a complete
enterprise ontology for the enterprise under consideration but as an application on-
145
tology for the defined purpose. The main reason for this differentiation is that an
enterprise ontology for the remaining part of the business does not yet exist and
will have to be developed. Converting the documented business processes into on-
tology parts might be a suitable way to start this development. Furthermore, addi-
tional services on top of the trailer surveillance might require adjustments in the
ontology for accommodating other sensor types or situations to recognize.
From a service development perspective, we also developed the overall
knowledge architecture for all knowledge-based services using the ontology and
its instantiation, the knowledge base (cf. [13]). However, the architecture primari-
ly identifies the building blocks of the knowledge base and the interfaces between
potential applications and is not presented in this paper due to space limitations.
Implementation of new services, like the electronic fence and electronic seal, re-
quires additional work. We expect that the development activities also will result
in update request for the ontology and insights in adaptation needs in the process.
References
1. Sandkuhl, K.; Borchardt, U.; Lantow, B.; Stamer, D.; Wißotzki, M. (2012) Towards
Adaptive Business Models for Intelligent Information Logistics in Transportation. In:
Perspectives in Business Informatics Research - 11th International Conference, BIR
2012, Nizhny Novgorod, Russia, September 24-26, 2012. Satellite Workshop & Doc-
toral Consortium Proceedings.
2. Smirnov, A.; Sandkuhl, K.; Shilov, N. (2013): Multilevel self-organisation of cyber-
physical networks: synergic approach. In International Journal Integrated Supply Ma-
nagement 8 (1/2/3), pp. 90–106.
3. Corcho, Ó.; Fernández-López, M.; Gómez-Pérez, A. Methodologies, tools and lan-
guages for building ontologies: Where is their meeting point? Data Knowledge Engi-
neering, 46(1):41–64, 2003.
4. Uschold, M.; King, M. (1995). Towards a methodology for building ontologies. Arti-
ficial Intelligence Applications Institute, University of Edinburgh, Edinburgh.
5. Lopez, F.M.; Perez, A.G. and Juristo, N. (1997) Methontology: from ontological art
towards ontological engineering. In Proceedings of the AAAI97 Spring Symposium,
pages 33–40, Stanford and USA.
6. O’connor M, Knublauch H, Tu SW et al. (2005) Writing rules for the semantic web
using SWRL and Jess. Protégé With Rules WS, Madrid.
7. Cox, S. (2013) Geographic information — Observations and measurements V2.0.
OGC Abstract Specification. http://portal.opengeospatial.org/files/?artifact_id=41579.
Accessed 10 July 2015
8. Falbo, R.A. (2004) Experiences in Using a Method for Building Domain Ontologies.
In: 16th International Conference on Software Engineering and Knowledge Engineer-
ing (SEKE 2004), International Workshop on Ontology in Action (OIA 2004), Alber-
ta, Canada, pp 474–477
9. Park, J.; Sung, K.; Moon, S. (2008) Developing Graduation Screen Ontology Based on
the METHONTOLOGY Approach. In: Networked Computing and Advanced Infor-
146
mation Management, 2008. NCM ’08. Fourth International Conference on, vol 2,
pp 375–380
10. Brusa, G.; Caliusco, M.L. and Chiotti, O. (2006) A Process for Building a Domain
Ontology: An Experience in Developing a Government Budgetary Ontology. In: Pro-
ceedings of the Second Australasian Workshop on Advances in Ontologies - Volume
72. Australian Computer Society, Inc, Darlinghurst, Australia, pp 7–15
11. Mizoguchi, R. (2001) Ontological Engineering: Foundation of the Next Generation
Knowledge Processing. In: Web Intelligence: Research and Development, vol 2198.
Springer Berlin Heidelberg, pp 44–57
12. Hristozova M.; Sterling L. (2003) Experiences with ontology development for value-
added publishing. In: Proceedings of the 3rd Workshop on Ontologies in Agent Sys-
tems (W11 OAS 2003), held in conjunction with the 2nd International Conference on
Autonomous Agents and Multi-Agent Systems (AAMAS 2003). International Founda-
tion for Autonomous Agents and Multiagent Systems, pp 17–24
13. Sandkuhl, K. (2013) Pattern Use in Knowledge Architectures: An Example from In-
formation Logistics. Proceedings 12th International Conference on Perspectives in
Business Informatics Research, Warsaw, Poland, September 23-25, 2013. LNBIP 158,
pp. 91-103, Springer.
14. Neuhaus, H.; Compton, M. (2009) The Semantic Sensor Network Ontology: A Gener-
ic Language to Describe Sensor Assets, AGILE 2009 Pre-Conference Workshop Chal-
lenges in Geospatial Data Harmonisation, 02 June 2009, Hannover, Germany.
15. Probst, F. (2007) Semantic Reference Systems for Observations and Measurements.
PhD, University of Münster
16. Yau, S.S.; Liu, J. (2006) Hierarchical Situation Modeling and Reasoning for Pervasive
Computing. In: Proceedings of the The Fourth IEEE Workshop on Software Technol-
ogies for Future Embedded and Ubiquitous Systems, and the Second International
Workshop on Collaborative Computing, Integration, and Assurance (SEUS-
WCCIA’06). IEEE Computer Society, Washington, DC, USA, pp 5–10
17. Hemalatha, M.; Uma, V. and Aghila, G. (2012) Time ontology with Reference Event
based Temporal Relations (RETR). International Journal of Web & Semantic Tech-
nology 3(1)
18. O’Connor, M.; Das, A. (2011) A Method for Representing and Querying Temporal In-
formation in OWL. In: Biomedical Engineering Systems and Technologies, vol 127.
Springer Berlin Heidelberg, pp 97–110
19. Henson, C.A.; Pschorr, J.K.; Sheth, A.P. et al. (2009) SemSOS: Semantic Sensor Ob-
servation Service. In: Proceedings of the 2009 International Symposium on Collabora-
tive Technologies and Systems. IEEE Computer Society, Washington, USA, pp 44–53
20. Noy F. N.; McGuinness, D.L. (2000) Ontology development 101: A guide to creating
your first ontology. Development, 32(1):1–25, 2000.
21. Kokar, M.M.; Matheus, C.J. and Baclawski, K. (2009) Ontology-based Situation
Awareness. Inf. Fusion 10(1): 83–98.
22. Fox M (1992) The TOVE project towards a common-sense model of the enterprise. In:
Industrial and Engineering Applications of Artificial Intelligence and Expert Systems,
vol 604. Springer Berlin Heidelberg, pp 25-34
147