wilamowski-b-m-irwin-j-d-industrial-communication-systems-2011

Semantic Web Services for Manufacturing Industry 65-5
the ontology. Here, again, it will be important to specify the functionality, geometrical aspects and the
source of the component whether in-house fabricated or externally sourced. The first step is to understand
the concepts and requirements of an ontology for a multisite production development environment,
or stated another way, the ontological content.
First, we begin by properly defining the concept of a valid ontology in the specified domain. We
need to ensure that the defined ontology conceptually represents the perceived domain knowledge
through its concepts, attributes, taxonomies, relationships, and instances. However, in addition to
this, other previously developed taxonomies for each of the manufacturing will also provide important
inputs. Next, we also need to define the restrictions that need to be applied to the above definitions in
order to ensure that it is practically usable. This is a refinement process of the high level abstractions
defined earlier.
Secondly, the most appropriate representation to model the ontologies is needed. OWL will be useful
at the implementation level; however, it will be necessary to use a graphical representation of ontologies
at a higher level of abstraction to make it easier for the domain experts to understand and critique, and
importantly, this model should be able to capture the semantic richness of the defined ontology In our
previous work, we have developed such a notation [Wongthongtham 06] and utilized it successfully
for the development of several ontologies including the Trust and Reputation Domain [Chang 06,07],
the Software Engineering Domain [Pornpit 05,06], the Disease Ontology [Hadzic 05], and the Protein
Domain [Sidhu 05,08]. We intend to utilize this for our representation language for the modeling phase.
The implementation will then be carried out using OWL classes.
Next, we define the ontology-based architecture. The ontology-based architecture is grounded on the
notion of a base ontology sub-ontologies [Wouters 02,03] or commitments [Jarrar 02, Spyns 02]. These
sub-ontologies are used as independent systems (in functionality) for the various decentralized development
teams. This would allow for a very versatile and scalable base for multisite production.
As our intention is to work with numerous sub-ontologies that provide custom portals for different
expert groups to access information and communicate with other groups (at different locations), a
solid representation becomes crucial as each sub-ontology can be viewed as an independent functioning
ontology [Wouters 02, Jarrar 02], all of them have their own distinct representation, which is related or
similar to the original but not necessarily the same and possibly not even a straight subset of elements
of the general base ontology. Our previous work has provided a rigorous basis for doing this [Wouters 02].
A number of key issues are given here and some small examples of how extensions are added to the base
ontology, whether new elements or existing external ontologies. These sub-ontologies define the essential
elements of the ontology-based architecture.
Awareness of what work is being done by others becomes a problem in a multisite environment.
Different teams might not be aware of what tasks are carried out by others potentially leading to issues
such as two groups performing the same tasks, or tasks not performed at all, or incompatibilities
between tasks (ignorance of who to contact to get proper details about a certain task). If everyone
working on a certain project is located in the same area then situational awareness is relatively straightforward
but the overheads in communication to find answers to the same question in a multisite environment
can become very large. The proposed base ontology will deal with this on a conceptual level.
Not only modeling the development process, but also the development methodology is the key. In this
case, it would mean that the ontology not only provides the lower level concepts (such as a component
that needs to be developed) but it also models concepts and semantics on the level of the interaction of
the development team such as Task Responsibility. In practice, this allows teams to always be aware of
who is performing each task.
Secure access control, which is another issue, considers the appropriateness of groups to access data.
This is also a major issue in the single location development, but an issue that is easier to control, as the
physical closeness automatically allows for a tight monitoring. In a multisite environment, it is easy to
lose track of what the exact responsibilities are, and who should or should not access certain parts. The
monitoring that is often taken for granted in a single site environment can become a huge problem.
© 2011 by Taylor and Francis Group, LLC