"A simple, clear purpose and simple, clear principles give rise to complex and intelligent behaviour. Complex rules and regulations give rise to simple and stupid behaviour." - Dee Hock" |
This chapter describes the underlying design of the vocabulary: the models. Each model is depicted using an Unified Modelling Language (UML) diagram. For those unknown to this graphical notation, please read Appendix C for a quick introduction.
The chapter starts with listing the requirements for the vocabulary and the prototype. Next, the structure of the entire vocabulary is outlined, followed by the three parts it consists of.
The vocabulary (Chapter 6) and the prototype (Chapter 7) have two goals:
The concept consists of the most interesting parts of ebXML, GEN and the LexiCon. These interesting parts have been mentioned in last chapter's conclusions (see the section called Conclusions in Chapter 5). The prototype and the vocabulary have to prove that this concept is usable.
The prototype and vocabulary serve to illustrate the working of the concept. Therefore it should be easy to understand, also for people without much experience in civil engineering informatics.
The following requirements serve as a guideline in designing the vocabulary and the prototype.
In order to make the concept clear, the vocabulary and prototype have to be simple. Stated bluntly: a proof-of-concept is no proof if the proof is not understood.
ebXML provides a basic set of tags (the Core Components) containing generic data like names and addresses. Industry specific tags are added to these core components to get the full range of tags needed to communicate. Divide and conquer. (the section called Semantic level in Chapter 5).
The LexiCon meta-model provides the functionality needed to communicate in multiple languages, which is very important for eConstruct. As one of the main points of this graduation project is testing this multi-lingual exchange of building and construction data, the LexiCon meta-model is mandatory.
The vocabulary must use the context mechanism as used in ebXML. With this mechanism, a core set of tags is modified according to a certain context (the section called ebXML's context mechanism in Chapter 5). After the modification, the core set has been enhanced with tags that are needed to communicate in that context.
ebXML uses specified Business Processes to aid in the processing of requests and answers. A message should not have to include more information besides just the name of the business process in effect and the current step in that business process. The system should be able to process the message based solely upon that information.
The interface of GEN (Figure 5-3) will be used by ceXML. Using a tree-like representation of a classification to select the needed item is the most straightforward and simple way of handling the interaction with the user. A list of characteristics of the selected item must be displayed next to the tree-view.