Volgende: Using Ontologies and bcoWeb: Omhoog: Case studies Vorige: Introduction Inhoudsopgave
This section starts off with a first experiment for creating an OWL-based Ontology, followed by an improved approach using the FU/TS paradigm: bcoWeb. The goal is to see if this works better than the single big Taxonomy from eConstruct's case.
A first test for a web-based Ontology was done in co-operation with graduate student Wouter van Vegchel [48]. The aim was to get more familiarity with web-based Ontology technologies, work that was partly started in eConstruct (see section 4.4.2). The prototype was implemented to support the owners of private dwelling houses to consider the feasibility of the realisation of an extension of their living space. The idea was to create a tool that can support the on-line evaluation of alternative technical solutions.
A reason to start with an OWL-based Ontology was the wish to experiment multiple separate, cooperating Ontologies instead of one single huge Ontology, as was done in eConstruct. OWL uses the NG Internet's GUID mechanism described in section 4.2.1. With this mechanism, items in various Ontologies can be connected--thereby making it possible to use a divide-and-conquer approach at creating Ontologies (see figure 8.1).
| 12#12 |
The mechanism was used in this first OWL test, resulting in several small Ontologies of about 10 classes each. The Ontologies could be connected without any problems, validating the OWL approach in that respect.
Protégé, the tool used to create the Ontologies, is a very powerful tool that already exists for a decade. Protégé is extremely powerful as an information modeling tool, though it basically mainly supports the subclass relation as object structuring mechanism. This experiment's implementation added a limited part-of relation, as it was needed. Using Protégé, the main structure of the home extension Ontology consisted of small two-level hierarchies. Each two-level hierarchy focused on a particular end-user choice. The subtypes were mainly technical solutions for a more generic concept. The more generic concept was often used as the target for either a relation or a part-of relation.
Protégé contains a lot of functionality, but it is therefore intimidating for casual users. The Ontologies developed in this first scenario were mostly created with a UML-like plugin for easy graphical editing, like seen in figure 8.2. For large-scale Ontology creation with cooperation from BC-expects that are not ICT-experts, a more restricted editor seems more suited. In this respect, web-based editors are normally easier and simpler.
The Ontologies created were ad-hoc. The only objective was to support the selection of alternative technical solutions. The small modeling needs of the case study provided the classes for the Ontologies.
Using the subclass-relation worked fine for structuring similar kinds of objects, like different kinds of houses or different kinds of doors. Those small hierarchies were mostly just one level deep, perhaps two. Extending this small-scale structuring mechanism to the scale of an entire, BC-spanning Ontology appears to be much more difficult, as shown in chapter 3.
There are several alternatives for structuring Ontologies. The FU/TS paradigm proposed in the GARM [54], see section 6.2.4, seems attractive and useful, but it needs to be tested with a sizable set of data. This also directly draws attention to the part-of relation Semantics. Taking just eConstruct's Ontology as example, it was never clarified whether the parts indicated in the Ontology were a definitive list, just a suggested list of common parts, or a set of obligatory parts. FU/TS includes the decomposition of a technical solution into a few smaller functional units and so could be a good basis for a clarification.
As discussed in section 6.2.4, the GARM provides a meta schema approach to information modeling that nicely suites the needs of the BC industry. Though the original model has not yet been applied to Ontology building, the core constructs can easily be used to capture the separation between what is required (`what') and what can be provided for (`how'). This distinction between functional and technical perspective can be used to improve the information needed for and provided by both the Demand side and the Supply/Offering side.
The implementation of the bcoWeb editor is discussed in the previous chapter, section 7.3. BcoWeb was created, content-wise, with help of graduate student Noor Hellemans. The original content was all in Dutch. The English content as seen here was made especially for the thesis and carries much less weight in numbers than the Dutch content.
It was felt that creating something simple would be the best course of action [62], likewise something that was dynamic by nature. So a simple version of the GARM was made with just TSs and FUs and their relations. You have a desire for something, you want a function, you want something you can describe the function of, a FU. This can be fulfilled by one or more things that are an answer to your question, a solution for your problem, a TS. Such a technical, physical solution itself normally consists of parts that can be exchanged for other parts. These parts can again be seen as a FU for which you need a TS, starting the sequence afresh. By using the GARM as the basis for this development the road towards greater functionality, if needed in the future, is more or less clear.
A second subject of interest regarding Ontologies is the specialisation hierarchy. This mechanism is very useful, especially for data reduction. From a scientific viewpoint it is interesting to try to combine the specialisation hierarchy with FU/TS decomposition using multiple, smaller, Ontologies as shown in this research.
Reinout van Rees 2006-12-13
