Developing an Ontology for Teaching Multimedia Design and Planning

Transcription

1 Jakkilinki, Sharda, Georgievski 1 Abstract Developing an Ontology for Teaching Multimedia Design and Planning Roopa Jakkilinki, Nalin Sharda, Mladen Georgievski School of Computer Science and Mathematics Victoria University PO Box 14428, Melbourne City, MC Victoria 8001, Australia (s): roopaj29@hotmail.com, Nalin.Sharda@vu.edu.au, mladeng@sci.vu.edu.au Meta-design frameworks provide an efficacious pathway for the design of a specific system. An example of such meta-design framework is Multimedia Design and Planning Pyramid (MUDPY). Semantic web technologies are suitable for implementing meta-design frameworks for specific design domains. To develop meta-design frameworks, and implement these using Semantic web technologies we need to build appropriate ontologies. Our investigations revealed that the Uschold & King Methodology is suitable for developing the MUDPY ontology, and Protégé 2000 is the most suitable development tool. We believe that development of the MUDPY ontology will facilitate web-based teaching of multimedia design. Keywords: Ontology, Multimedia Design, Multimedia Planning, Semantic Web, Meta-Design, Teaching Multimedia Design. 1. Introduction Web based teaching has gained popularity in the last few years as online education can reach many more people. This has led to the development of many web based tutoring systems, which are based on ontologies. Multimedia Design and Planning Pyramid (MUDPY) model is a meta-design framework that facilitates successful creation of multimedia projects and supports teaching multimedia design and planning. The MUDPY model is implemented on the semantic web by creating an ontology for it. MUDPY ontology will further help develop intelligent tools, which can guide the students through the process of multimedia design and planning. Ontology means a specification of a conceptualization. That is, an ontology is a description of the concepts and relationships that can exist for an agent or a community of agents (Gruber, T. 1993). Historically, ontologies arose from the branch of philosophy known as metaphysics, which deals with the nature of reality of what exists. The traditional goal of ontological inquiry, in particular, is to divide the world "at its joints," to discover those fundamental categories or kinds that define the objects of the world. So viewed, natural science provides an excellent example of ontological inquiry. For example, a goal of subatomic physics is to develop taxonomy of the most basic kinds of objects that exist within the physical world (e.g., protons, and electrons). Similarly, the biological sciences seek to categorize and describe the various kinds of living organisms that populate the planet (Knowledge Based Systems, Inc.2003). We can classify ontologies as Domain Ontologies and Theory Ontologies (Swartout, B. et al. 1997). Domain Ontologies provide a set of terms for describing some domain, such as medicine, air campaign planning, or computer maintenance. Where as, Theory Ontologies provide a set of concepts for representing some aspect of the world, such as time, space, causality, or plans.

2 Jakkilinki, Sharda, Georgievski 2 MUDPY ontology is a domain ontology, which will describe the terms in the domain of multimedia planning and design and the relationships between them. In section 2 of this paper we present the MUDPY model. Section 3 describes the various methodologies available to develop ontologies and in Section 4 we provide a comparative analysis of some tools available to develop ontologies. In Section 5 we present the methodology we follow and the tool being used to develop the MUDPY ontology. Section 6 explores the educational implication of MUDPY ontology, and in section 7 we provide a summary of our conclusions. 2. The MUDPY model Multimedia Design anthed Planning Pyramid (MUDPY) (Sharda, N. 2004) is a meta-design framework that facilitates the creation of multimedia content for standalone as well as online multimedia presentations and systems. This architecture is represented by a pyramid shaped model, and hence its name. Figure 1 depicts the MUDPY architecture and the processes used in planning, design and production of multimedia. This pyramid consists of five levels. In the planning phase we traverse the pyramid from level 5 to level 1. In the following we provide further details of each level in the MUDPY model. Bottom-Up Approach Used for Implementation Top Down Approach Level 5 Used for Concept Planning Goals Aim Objectives Level 4 Requirements Tasks, Treatment Target Audience Level 3 Specifications Task Modeling Story Board, Navigation Production: Content Gathering, Integration, Testing Level 2 Level 1 Figure 1: Design Molecules of MUDPY - Concept Statement: The apex of the pyramid represents the concept statement. The concept statement should give an overview of the entire project. All decisions at lower levels of the project must relate to the concept statement. - Goals: From the project s concept statement we derive the project s goals. We define goals in terms of aims and objectives. Aim is a short statement that embodies the intention and purpose of the project, where as, objectives give a list of outcomes that need to be attained. - Requirements: Having articulated the goals of the project the next step is to derive the system requirements. This is done at level 3 of the MUDPY architecture. The three design molecules widely used for deriving the requirements are tasks, treatment and target audience. - Specifications: Often, written specifications become the main form of documentation articulating the contractual obligation for all players of the project. The main specification tools used for systematic design are storyboard, navigation and task modeling. - Production: The bottom level of MUDPY architecture is the production phase. The three main design molecules at this level are content gathering, integration and testing. Content

3 Jakkilinki, Sharda, Georgievski 3 gathering implies getting hold of multimedia content. Integration is combining all the elements to create a working system. Testing is an ongoing process, and each section needs to be tested as it is created. 3. An overview of Methodologies to develop the ontology At present developing ontologies is an art rather than a science. This situation is changing with the advent of well defined ontology development methodologies (Jones, D., et al. 1998). Methodology refers to the techniques and methods to be followed in order to develop an ontology. A number of methodologies have been suggested to develop Ontologies (Fernandez Lopez, M. 1999). In the following subsections we provide further details of some of the widely used methodologies Uschold & King Methodology The Uschold & King methodology was developed with the experience of building Enterprise ontology. The guidelines provided by Uschold and King to develop an ontology are as follows (Uschold, M., King, M. 1995). - Identify the purpose leads to a clear understanding of why the ontology is being built and who the intended users are. - Building the ontology consists of ontology capture, coding and integrating existing ontologies. Ontology capture is identifying key concepts and relationships in the domain and producing definitions for the concepts and definitions. Coding is representing knowledge in a formal language. Integrating existing ontologies is thinking of how to reuse existing ontologies. - Evaluation is to make a technical judgement of the ontologies, their associated software environment, and documentation with respect to a frame of reference. - Documentation provides guidelines to documenting ontologies; these differ according to the purpose and the type of ontology. Generally, ontologies for business domains have been developed using this methodology Gruninger & Fox Methodology Gruninger & Fox methodology was developed based on the experience of Toronto Virtual Enterprise (TOVE) ontology project. Essentially, it involves building a logical model of knowledge that is to be specified by means of the ontology (Gruninger, M., Fox, M. S., 1994). The methodology consists of the following steps (Fernandez Lopez, M. 1999): - Capture of motivating scenarios: Development of ontologies is motivated by scenarios that arise in the application. A motivating scenario also provides a set of intuitively possible solutions to the scenario problem. These solutions provide an informal intended semantics for the objects and relations that will later be included in the ontology. - Formulation of informal competency questions: These questions are based on the scenario and the ontology should be able to answer these questions. These questions facilitate the ontology in meeting its requirements. - Specification of the terminology of the ontology within a form language: A set of terms are extracted from the questions and this terminology is specified using a formalism such as the Knowledge Interchange Format (KIF). - Formulation of formal competency questions using the ontological terminology: Once the informal competency questions are designed and the terminology is defined, formal competency questions are defined to see that the ontology answers the questions and meets its requirements.

4 Jakkilinki, Sharda, Georgievski 4 - Specification of axioms and definitions for the terms in the ontology: Axioms must be provided to define the semantics of the terms in a formal language. - Establish conditions for characterizing the completeness of the ontology: Once the formal competency questions have been defined, conditions under which the competency questions is answered should be stated. This methodology was used to develop the TOVE ontology project, which included Enterprise design ontology, Project ontology, and Scheduling ontology Berneras et al Methodology The approach adopted by Berneras et al towards developing Ontologies is conditioned by its application development process. Every time an application is built the required ontology that represents the application is also built. The following series of steps are carried out everytime the application is built (Fernandez Lopez, M. 1999). - Specification of application: This provides a view of the components the application tries to model. - Preliminary design based on relevant top level ontological categories: Previously developed Ontologies are searched and are extended to be used in the new application. - Ontology refinement and structuring: The principles of minimum coupling can be used to assure that the modules are not much dependent on each other, and that they are as coherent as possible. Ontologies on electrical networks have been developed by using this methodology Methontology Methodology This methodology was developed at the laboratory of artificial intelligence at Polytechnic University of Madrid. The Methontology framework enables the construction of ontologies at the knowledge level and includes: the identification of the ontology development process, a life cycle based on evolving prototypes, and particular techniques to carry out each activity. Methontology consists of two main phases (Fernandez Lopez, M. 1999). Which are Ontology development process and Ontology life cycle. These two phases are described in detail below: - Ontology development process: Activities that are carried out while developing the ontology are assembled as the ontology development process. These activities can be classified as project management activities, development-oriented activities and support activities. Project management activities include planning, control and quality assurance. Development-oriented activities include specification, conceptualization, formalization and implementation. Support activities include knowledge acquisition, evaluation, integration, documentation and configuration. - Ontology life cycle: This includes the set of stages through which the ontology moves during its lifetime. It describes activities performed in each stage and the relations between them. Some of the ontologies developed using this methodology are Chemicals ontology, Environmental pollutants ontology, Reference ontology etc Sensus Methodology Sensus ontology was developed for natural language processing and was developed at the Information Sciences Institute, natural language group, to provide a broad based conceptual structure for developing machine translators (Swartout, B., et al. 1997). Its content was developed by merging Penman Upper Model, Ontos, WordNet and semantic categories from electronic

5 Jakkilinki, Sharda, Georgievski 5 dictionaries. Sensus has more than 50,000 concepts organized in a hierarchy. The methodology consists of a series of steps (Fernandez Lopez, M, 1999).These steps are as following. - Step 1: A series of terms are taken as the seed terms. - Step 2: The seed terms are linked by hand to Sensus. - Step 3: All concepts in the path from the seed terms to the root of Sensus are included. - Step 4: Terms that could be relevant within the domain and have not yet appeared are added. - Step 5: For nodes that have large number of paths through them, the entire sub-tree under the node is sometimes added. An ontology for military air campaign has been developed by using SENSUS, this includes ontologies on weapons, fuels etc. 4. Tools for Ontology Development Several ontology development editors have been developed in the last few years. Comparison of all the tools available was beyond the scope of this project. After preliminary investigations, we chose to study in more detail three tools for developing the MUDPY ontology, which are Ontolingua, Protégé 2000, and OntoEdit free Ontolingua Ontolingua has been developed by Knowledge Systems Laboratories in Stanford. Ontolingua ontology development environment is available as a World Wide Web service. It provides for ontology editing, browsing, and a search facility. It supports distributed and collaborative editing of ontologies, collaborative work is allowed through multi user sessions and group access. Ontolingua allows authoring ontologies from scratch or extend ontologies available from the library. Ontologies from the library can be reused in four different ways (Farquhar, A., et al. 1996), which are inclusion, polymorphic refinement, restriction and cyclic inclusion Protégé 2000 Protégé has been developed by Stanford Medical Informatics (SMI). It is a graphical tool for ontology editing and knowledge acquisition, it facilitates think about domain models at conceptual level, without knowing the syntax of the language ultimately used on the web. Protégé uses a frame-based approach for knowledge acquisition, and is a tool for developing domain Ontologies. It provides automatically generated forms as a user knowledge acquisition tool, and this knowledge acquisition tool can be further customized. It allows populating instances through forms (Protégé 2003). Protégé s features can be summarized as follows (Knublauch, H., 2003): - Class modelling: Protégé provides a Graphical User Interface (GUI) that models classes (domain concepts) and their attributes and relationships. - Instance editing: From these classes, Protégé automatically generates interactive forms that enable the developer or domain experts to enter valid instances. - Model processing: Protégé has a library of plug-ins that helps define semantics, ask queries, and define logical behavior. - Model exchange: The resulting models (classes and instances) can be loaded and saved in various formats, including Extensible Markup Language (XML), Unified Modeling Language (UML), and Resource Description Framework (RDF). Protégé also provides a highly scalable database back-end.

6 Jakkilinki, Sharda, Georgievski OntoEdit free OntoEdit free is developed by Ontoprice, Karshrue University. It allows the development and maintenance of ontologies by using graphical interfaces. OntoEdit is built on top of a powerful internal ontology model. The tool is based on a flexible plug-in framework. This allows extending the functionality in a modularized way and for user-friendly customization to adapt the tool to different usage scenarios. Each plugin provides features to deal with the requirements of an ontology developer, the plugins provided by ontoprise differs for various versions, the free version called OntoEdit free is the tool we tested. It was limited in its capabilities, as it can support only 50 concepts, 50 relations and 50 instances (OntoEdit tutorial, 2003). In the following sections we provide a set of criteria for comparing these ontology editing tools Comparison criteria We carried out a comparative analysis of the three tools, in order to select the most appropriate one. An ontology development editor can be evaluated based on two broadly classified aspects (Corcho et al., 2003; Duineveld, A. et al., 1999), namely usability aspects and ontological aspects. A comparison of usability and ontological aspects of these tools follows Usability aspects The usability aspect deals mainly with the user friendliness of the tool, its stability during usage, and the features provided by the tool. The following criteria are considered for usability aspects: - What is the clarity of the user interface? This verifies whether all components are designed such that their meaning is unambiguous. - How is the consistency of the user interface? Consistency states that same conventions and rules are applied to all elements of the GUI. If the interface is inconsistent it limits the predictability of the outcomes of user actions. - Are the meanings of the commands clear? This involves checking if the commands are clear and easy to understand, clear commands lead to ease of use. - Is it possible to locally install the software? If it is possible to locally install the software or it must be located on a remote server. - How fast are the updates reflected in the ontology? Reflects the responsiveness of the system, that is, the promptness with which the interface informs the users about the results of their actions and the interface status. - Evaluating the help system involves checking whether the help system provided by the software is easy to understand and use. - Is there a good overview of the ontology? This determines whether a complete overview of the ontology is being provided in a hierarchical tree like manner. - Stability of the tool: This involves verifying that the software is stable or if it has had crashes, or unexpected interruptions. - Is user support being provided? User support refers to the support provided by the developers in solving the problems faced by the users while using the tools and answering user queries to clarify user doubts. - Does the free version provide all the features? If the free version of the software provides all the features and capabilities of the commercial software. - How good is the visualization? Visualization is a graphical representation of the ontology. A visualizer should allow the user to browse and edit the ontology via a graphical interface. Each of the preceding criteria is rated on a scale of 0 to 5. Zero indicates that the feature is not implemented. Five indicates that the feature is very well implemented.

7 Jakkilinki, Sharda, Georgievski 7 Criteria Ontolingua Protégé OntoEdit Clarity of interface Interface Consistency Meaning of Commands Local installation Updating speed Help system Ontology overview Stability of the tool User support Features of free version Visualization Total Implementation Level 0 = Nil 1= Poor 2 = OK 3 = Good 4 = Very Good 5 = Excellent Table1: Comparison of usability aspects The table 1 lists the points awarded to the various usability aspects of the three tools investigated. The totals calculated based on the points awarded are: 31 points for Ontolingua, 53 points for Protégé, and 42 points for OntoEdit free. We can see that the Protégé system is excellent on all criteria, but for commands and speed. Nonetheless, it is very good in these aspects as well Ontological aspects Ontological aspects deal with features of the ontology itself, such as multiple inheritance, exhaustive decomposition, disjoint decomposition and availability of ontological library. The following criteria are considered for comparing the ontological aspects. - Does the editor allow multiple inheritance? Multiple inheritance is the ability of a class to have more than one super class. - Does it allow exhaustive decomposition? Exhaustive decomposition is present if all instances of a class are also instances of one of the subclasses in the decomposition. - Does it allow disjoint decomposition? If two concepts are disjoint it means there cannot exist instances that instantiate both concepts. - Are there example ontologies available in the tool? Verifies whether the editor provides example ontologies to guide the user with ontology development. - Does the editor provide library of ontologies that can be reused? Determines if the editor provided a library of ontologies that can be reused. - Is the tool Java based? Determines whether the ontology editor has been developed using Java. A java-based tool allows creation of custom plugins in an easy fashion by modifying existing classes. - Does it allow using a database backend? Ascertains whether the editor allows saving the ontology as a database. Saving the ontology as a database allows sharing of ontologies between different applications.

8 Jakkilinki, Sharda, Georgievski 8 Each of the preceding criteria is rated on a scale of 0 to 5. Zero indicates that the feature is not implemented; five indicates feature is very well implemented. Criteria Ontolingua Protégé OntoEdit Multiple inheritance Exhaustive decomposition Disjoint decomposition Example ontologies Ontology Library Java based Database Backend Total Implementation Level 0 = Nil 1= Poor 2 = OK 3 = Good 4 = Very Good 5 = Excellent Table 2: Comparison of ontological aspects Table 2 lists the points awarded to the ontological aspects of the three tools evaluated. The total points awarded are: 21 points for Ontolingua, 28 points for Protégé, and 10 points for OntoEdit free. While Protégé is rated highly on most criteria, its lack of exhaustive decomposition is of some concern. 5. Methodology and tools for developing MUDPY Ontology In this section we render details of the methodology followed to develop MUDPY ontology and the tool selected to develop MUDPY ontology. We also describe why we chose Protégé as our ontology development tool and some of its important terminology. Identify the purpose Ontology Capture Coding Intra-coding refinement Extra Coding refinement Testing Maintenance Figure 2: Methodology adopted to develop MUDPY

9 Jakkilinki, Sharda, Georgievski Methodology to develop MUDPY ontology The methodology we follow is very much similar to the one proposed by Uschold and King. Nonetheless, we are also guided by the other methodologies. The Figure 2 is an overview of the methodology followed for developing MUDPY ontology. The steps of the methodology include: identifying the purpose, ontology capture, coding, refinement, testing and maintenance. Each of these steps are described in some detail in the following subsections Identify the purpose to develop the ontology In order to identify the purpose it is important to answer the following questions: - Why is the ontology being built? - What is its intended use? - Who are its users? MUDPY ontology will contain knowledge in the domain of multimedia design and planning. It is being built to guide neophytes through the process of multimedia planning and design. It will teach multimedia design and planning by answering queries on the various elements of the MUDPY architecture and their relationships Ontology capture mechanism Ontology capture consists of three different stages: - Determining the scope of the ontology - Selecting a method to capture the ontology - Defining the concepts in the ontology Determining the scope involves identifying all the key concepts and relationships in the domain. The method used for ontology capture will be object oriented analysis and design. The process of defining concepts in Ontology is also called categorization, which involves taking closely related terms and grouping them as concepts or categories. We selected a top-down approach for categorization for the following reasons: - The domain we are trying to develop the ontology for comprises a hierarchical structure of layers. It uses a top down approach to provide abstraction. Therefore, its layers, and the elements in these layers will represent the concepts in our ontology, linked in a top-down manner. - Once all the higher level classes are derived, all other lower level classes can be derived from this Coding the ontology Coding means representing the ontology in a formal language. A number of ontology editors are available to develop ontologies. A suitable editor to develop the ontology must be selected based on the requirements of the ontology. The main classes in the ontology are entered as concepts and their attributes and slots are created. Suitable tools to query the ontology are also required. Ontology development is an iterative process; it involves developing a preliminary ontology which is refined with time Refinement Refinement consists of two phases: Intra-coding refinement, and Extra-coding refinement. Intracoding refinement involves the refinement done during the coding phase. As the code is being

10 Jakkilinki, Sharda, Georgievski 10 developed, if either some errors are discovered or new requirements come up, the code is refined to correct the errors or fulfil the new requirements. Extra-coding refinement refers to the changes done to overcome the errors that are uncovered during testing and maintenance Testing Testing uncovers defects in functional logic and implementation, and is carried out at all stages of development. A knowledge base of the various elements and processes in the MUDPY model will facilitate multimedia design. Once the knowledge base has been created, tests will be carried by the end users to uncover defects in the ontology and/or the knowledge acquisition tool. Depending upon the problems encountered, appropriate changes will be carried out to the ontology and the knowledge acquisition tool to overcome the shortcomings Maintenance Maintenance is the most important aspect of developing any software including ontologies. Maintenance can be corrective, adaptive or perfective (Pressman, R. S., 1999). Corrective maintenance involves considering the problems faced by the users while querying the ontology and correcting the ontology to overcome these problems. Adaptive maintenance involves modifying the ontology to fulfil new requirements in the future. Perfective maintenance involves improving the ontology, to further refine it. Hence maintenance of the MUDPY ontology will be ongoing process Protégé methodology For the development of a successful Protégé-2000 project, a series of steps have been proposed (Protégé 2000, user guide), namely: - Step1: Plan for the application and expected uses of the knowledge base. This usually means working with domain experts that have a set of problems that could be solved with knowledge-base technology. - Step 2: Build an initial small ontology of classes and slots. - Step 3: When the ontology has been built, use forms to enter instances into the ontology. Protégé 2000 automatically generates forms in its role as a knowledge-acquisition tool generator. - Step 4: These forms can be used to acquire values for the test sequences, and then shown to domain experts and end users so that their feedback can be used to make any revisions if necessary. - Step 5: Forms can be customized to form a refined knowledge-acquisition tool, while doing this further design problems in the original ontology may become apparent. If necessary revise the ontology and repeat step 4. - Step 6: Build a larger knowledge base that can be tested with the application or problemsolving method. - Step 7: Test the full application with end-users. This step can lead to further revisions to the ontology and the knowledge-acquisition forms Why select Protégé? We assessed Ontolingua, Protégé 2000 and OntoEdit free and compared their features. This study indicated that Protégé 2000 and OntoEdit were far superior in their usability and ontology aspects as compared to Ontolingua, and they can be locally installed. Both Protégé 2000 and OntoEdit free version2.6 have user friendly interfaces. OntoEdit borrows its user interface partially from Protégé. Both tools allow plug-in frame-work, but the short coming of OntoEdit free is that it does not provide a query tool, and a basic axiom feature (in its free version), where as Protégé does. Protégé also has a Protégé discussion mailing list where considerable time and effort is spent in

11 Jakkilinki, Sharda, Georgievski 11 answering queries and providing technical support to the users. We also discovered that the our methodology is very much similar to the Protégé methodology for developing projects. Therefore, we decided on using Protégé as our ontology editor Protégé terminology Some of the terms which form the basis of Protégé 2000 are classes, instances, slots and forms (Knublauch, H., 2003). These terms are described in the following: - Classes are named concepts from the domain that can have attributes and relations. Protégé classes are comparable to Java or UML classes but without attached methods. Protégé supports multiple inheritance, and classes can be abstract or concrete. Only concrete classes have instances. - Instances are specific entities of a given class. Protégé automatically generates forms that can be used to populate the instances. - Slots are attributes or relationship between classes. A slot has a name and a value type. Protégé supports the primitive value types Boolean, integer, float, and string. Apart from primitive values; slots can also refer to the model's instances and classes. You can use slots to build relationships and associations between instances and these slots store either single or multiple values. Slots are similar to object oriented attributes and relations, the difference being that slots can be attached to multiple classes. - Forms are automatically generated to populate the instances; these graphical forms contain text fields, radio buttons, check boxes, combo boxes, lists, and other widgets to make editing as convenient as possible. These automatically generated forms are not always perfect, but the user can change the types of widgets and their layout with a little effort. Protégé 2000 is a Java based ontology editor; it allows ontology implementation as an applet on the World Wide Web. This permits multiple users to share the ontology. The resulting ontology, which is implemented as an applet, is read-only. Users can read the ontology and perform queries on it, but the changes made by the users are not saved. 6. Educational implication of MUDPY ontology To develop successful multimedia projects it is very important to follow a systematic approach. The MUDPY model has been developed to teach students the process of multimedia project development from scratch, by guiding them through the various phases of project development life cycle. Web-based teaching has gained popularity in recent years. Additionally, teaching multimedia design and planning through the web can reach many more students. Presently one of the impediment is that web-based applications lack intelligence and adaptivity. Ontologies help overcome this problem by allowing the development of intelligent systems. The MUDPY model can be implemented on the semantic web by developing MUDPY ontology. MUDPY ontology will further allow the development of tools which can operate on the knowledge bases and facilitate sharing of knowledge with other web-based education systems. 7. Conclusions There is a need for formalising the processes involved in multimedia planning and design, especially for teaching the same. Multimedia Design and Planning Pyramid (MUDPY) ontology is required for developing an intelligent, sematic web based multimedia design system. From a systematic comparison of a number of ontology development methodologies we concluded that the Uschold & King Methodology is most suitable for developing the MUDPY ontology. A comparative study of three ontology creation tools, namely, Ontolingua, Protégé 2000, and OntoEdit free revealed that Protégé 2000 is most suitable for developing the MUDPY ontology.

12 Jakkilinki, Sharda, Georgievski 12 Protégé 2000 is far superior in its usability and ontological aspects as compared to the other tools. Finally, development of the MUDPY ontology is the way forward in creating a sematic web based meta-design framework for teaching multimedia design. References Corcho, O., Fernández-López, M. & Gómez-Pérez, A. (2003). Methodologies, Tools and Languages for Building Ontologies. Where is the Meeting Point?, Data and Knowledge Engineering 46(1): July 2003 Duineveld, A., Stoter, R., Weiden, M. & Kenepa, B. & Benjamins, V. (1999). Wondertools? A Comparative Study of Ontological Engineering Tools, Proceedings of the 12th Banff Knowledge Acquisition for Knowledge-Based Systems Workshop, University of Calgary/Stanford University, Farquhar, A., Fikes, R. & Rice, J. (1996). The Ontolingua Server: A Tool for Collaborative Ontology Construction, Proceedings of the Tenth Knowledge Acquisition for Knowledge-Based Systems Workshop. Banff, Canada. November 9-14, Fernandez Lopez, M. (1999). Overview of Methodologies for Building Ontologies, The Proceedings of the IJCAI-99 Workshop on Ontologies and Problem Solving Methods, Sweden August Gruber, T. (1993). A Translation Approach to Portable Ontologies, Knowledge Acquisition, 5(2): , Gruninger, M., Fox, M. S. (1994). The Role of Competency Questions in Enterprise Engineering, Workshop on Benchmarking Theory and Practice, Trondheim, Norway, Jones, D. M., Bench-Capon, T. J. M. & Visser, P. R. S (1998). Methodologies for Ontology Development, Proceedings of IT&KNOWS Conference for the 15th IFIP World Computer Congress, Budapest, Knowledge Based Systems, Inc. (2003). IDEF5 Ontology Description Capture Overview, Accessed Sept 9, 2003 from Knublauch, H. (2003). An AI Tool for Real World: Knowledge Modelling with Protégé, Retrieved Nov 20, 2003 from Ontoedit Tutorial. (2003). How to Work with OntoEdit, Retrieved Oct15, 2003 from Pressman, R.S. (1997). Software Engineering, A Practitioner s Approach. 4th Edition European Adaptation by D. Ince, McGraw-Hill. Protégé 2000 User Guide, Retrieved Nov 10, 2003 from Stanford Medical Informatics, Protégé 2000: What is it, Retrieved Nov 10, 2003 from Sharda, N. (2004). Creating Meaningful Multimedia with the Multimedia Design and Planning Pyramid, The 10 th International Multi-Media Modelling Conference, January 5-7, 2004, Brisbane, Australia. Swartout, B., Patil, R., Knight, K. & Russ, T. (1997). Towards Distributed Use of Large Scale Ontologies, Symposium on Ontological Engineering of AAAI. Stanford, California, 1997.

13 Jakkilinki, Sharda, Georgievski 13 Uschold, M., King, M. (1995). Towards a Methodology for Building Ontologies, Workshop on Basic Ontological Issues in Knowledge Sharing, Held in Conjunction with IJCAI-95, Montreal, Canada, 1995.