Ontology-Specific API for a Curricula Management System Adelina Tang Dept. of Computer Science & Networked Systems Sunway University Petaling Jaya, Malaysia adelina.tang@ieee.org Jason Hoh Dept. of Computer Science & Networked Systems Sunway University Petaling Jaya, Malaysia 08015703@imail.sunway.edu.my Abstract The ontology approach is used as the basis of a Computing Curricula Management System. Owing to the limitations of the Protégé platform, manipulation of ontological knowledge was found to be limited. A customized Application Programming Interface (API) is proposed to improve the knowledge manipulation and extraction capabilities of the system. However, the API can only operate effectively if the ontology is treated as an XML document. This paper discusses the API design and development. It then concludes with its contribution, limitation and future work. Keywords computing ontology; curricula management; API; ontology manipulation; XML I. INTRODUCTION An ontology facilitates the sharing of knowledge, making it the ideal tool for automating knowledge sharing and dissemination over the Internet. Gruber [1] defines the ontology as a specification of a representational vocabulary for a shared domain of discourse. This shared domain of discourse would consist of classes, relations, functions, and similar objects of interest. Such sharing may be developed using the extensible Markup Language (XML) to form the basis of the Semantic Web envisaged by Berners-Lee et al. [2]. One of the ways to develop successful Semantic Webs applications is to ensure that knowledge-sharing is carried out with little or no human intervention. Hence this forms the motivation of creating online versions of existing non-web applications. An example of such an application is the Computing Ontology project by Cassel et al. [3, 4], which in turn motivated the Computing Curricula Management System (CCMS) project which utilized the Protégé ontology editor to build the Sunway University Computing Ontology (SUCO) [5]. However, certain limitations were discovered during the development of the CCMS [6] which affected the manipulation and extraction of key information from the SUCO. This paper will provide an overview of the CCMS. Then, it will focus on the design and development of the Application Programming Interface (API) that overcomes the limitations discovered in [6]. It will conclude with the contribution, limitation and future work possibilities. II. OVERVIEW OF THE CCMS Cassel et al. [3] proposed their Computing Ontology to relate typical computing topics with curricula development and planning. They had also proposed an additional web-based utility to enable a module developer to select and/or create outcomes as well as to select suitable topics to achieve those outcomes [4]. Their suggested scheme (see Fig. 1) was adopted and their ideas were enhanced in [5] to develop the SUCO of the CCMS on the Protégé platform. However, [6] uncovered limitations in manipulating and extracting crucial curricula knowledge from the CCMS. A possible action to overcome this limitation was identified as a customized Application Programming Interface (API), with appropriate API features proposed to fulfill requirements in [7]. In Fig. 1, the Existing Curriculum is fixed and not editable by the larger Computing community. The Curriculum Wiki is an editable environment which allows suggested additions and revisions to be introduced into a copy of the existing curriculum, i.e. a working/discussion copy. These activities are made transparent to all members of the Computing community. The third component, the Discussion Forum, enables discussions regarding the aforementioned additions and revisions. Thus far, the SUCO is in place. Any view of the current SUCO is considered the Existing Curriculum. III. METHODOLOGY Extending the original scheme from Fig. 1, the API that was identified in [7] to overcome the limitation is proposed to be placed between the Ontology (the SUCO) and the Curriculum Wiki (see Fig. 2). The two major responsibilities required of this API include information retrieval and content editing. However, some preliminary work is required in defining the architecture of the API (see Fig. 2), after which the API would be created according to these responsibilities. Java is chosen as the development tool to create the API.
Fig. 1. The scheme proposed by Cassel et al. [4]. b) Simple API for XML (SAX): This is an event-driven approach that reads XML files on-the-go, i.e. reading can commence without loading the entire document. Therefore, SAX requires lower memory resources compared with the DOM approach. However, only read operations are allowed. This makes SAX inappropriate for the API development. 2) Content editing: This involves effecting changes in the syllabus of a particular subject. Such changes include renaming, adding and/or removing subjects, pre-requisites, topics, sub-topics, and programme learning outcomes. B. OWL-XML flat file The SUCO was built on Protégé which does not have a flexible means of extracting user-requested information. Instead, any request to obtain specific information would indiscriminately reproduce the entire ontology. Clearly, an alternative extraction method would be needed. Consider Fig. 3. Fig. 2. Proposed API extending the scheme from [4]. The two major responsibilities required of this API include information retrieval and content editing. However, some preliminary work is required in defining the architecture of the API (see Fig. 2), after which the API would be created according to these responsibilities. Java is chosen as the development tool to create the API. A. SUCO API Architecture Information retrieval incorporates the search, patternmatching and text extraction processes that are intrinsic to every information retrieval procedure. Content editing is conducted after successful information retrieval. 1) Search, Pattern-match and Text extraction: There are two major approaches in implementing this on XML documents using Java [8]: a) Document Object Modeling (DOM): The XML file is treated as a document and creates a tree-model out of its data. DOM enables both read and write operations on the XML file. Memory requirements are high as the entire document, in this case the SUCO, must be loaded before any read/write operation can commence. Fig. 3. SUCO viewed in Protégé (top). SUCO in XML form (bottom). This alternative was a straightforward solution of saving the Protégé-based SUCO in its basic form as an OWL-XML flat file, the equivalent of an ASCII text file. The resulting XML tagged structure would make the ontology easily read and manipulated (see Fig. 3). Therefore, saving the SUCO in its XML form would greatly facilitate the information retrieval procedure. C. SUCO Structure The SUCO structure consists of the following object entities: 1) Subjects: Each has its own topics and subtopics, prerequisites, year of study and learning outcomes, which, in turn, are also viewed as object entities in their own right. 2) Object properties: These define the relationships that must exist between object entities.
Note that the SUCO structure in its XML form is consistent with its original Protégé form. This greatly simplifies viewing the SUCO in Protégé, exporting it to its XML form, manipulating it, and importing it back to be viewed as a Protégé ontology, without any loss of knowledge integrity. D. SUCO API User Interface (UI) A simple UI is required for initial testing purposes to ensure that the core processes function as planned. IV. DEVELOPMENT The DOM approach is selected to develop the search, pattern-match and text extraction processes as it enables both read and write operations on XML files [8]. Content editing will be described in the context of the API functionalities. The main menu opens with a choice of Subjects, Object Properties, Learning Outcomes, and Release Log (see Fig. 4). Fig. 4. Main menu of the SUCO API. A. Subjects menu This allows a search for subjects or subtopics, and to add new subjects. 1) Search Subjects/Subtopics: A successful search would return the matching subject with accompanying properties such as Programme Learning Outcomes (PLOs), prerequisites, and topics. A subtopic is a subclass of any subject. At this point another sub-menu would enable the following operations: a) Rename/remove subject, change subject s year of study, add/remove topics, programme learning outcomes, prerequisites, designate subject as core/elective. b) Rename subtopic. 2) Add new Subject: This requires proper planning as it will affect the curricula structure. B. Object Properties 1) Rename an Object Property: This allows an existing object property to be renamed, e.g. hastopic to hasmoretopics. 2) Add new Object Property: This creates a new property. 3) Set/replace/remove inverse property: An inverse property is merely the opposite of a regular property, e.g. hastopic has the inverse property istopicof 4) Remove an existing Object Property: The inverse property is not affected by the removal of an object property. C. Learning Outcomes 1) Display all PLOs: A PLO is typically associated with at least one MQF LO Domain [9, 10]. This function displays the descriptions of individual PLOs together with the particular MQF LO Domain description. 2) Rename a PLO: Currently, the PLOs are identified by numbers. However, future changes may require them to be designated differently. This feature enables such changes. 3) Edit the contents of a PLO: This enables PLOs to be manipulated in several ways: a) Add/remove MQF LOs. b) Change description MQF LOs. 4) Add a new PLO: This feature requires that at least one MQF LO Domain be associated with the new PLO. 5) Remove an existing PLO: This feature allows the removel of a PLO that has been rendered inappropriate owing to a significant change in the subject syllabus. D. Release Log The Release Log enables the viewing of recent changes to the curricula as well as search keywords to view changes of specific subjects and topics. 1) View recent changes: Any changes would be logged in a text file. A request to view recent changes would display the three latest changes. 2) Search via keywords: This offers greater detail in viewing changes. a) Date: This allows the search sorted by date, and displays five latest results. b) Items of interest: This sorts results by subjects, object properties, or learning outcomes. V. DISCUSSION A. Results and Contribution The API functions underwent rigorous testing and all requirements were fulfilled. In doing so, it has added great value to the existing access and manipulation capabilities of the SUCO to overcome some of the shortcomings identified in [6].
B. Limitation However, Protégé s Ontograf visualizer s inability to display more than one universal restriction is still not solved. Fig. 5 shows PLO 4 with no associations with any MQF LOs, whereas it actually is associated with Communication leadership and team skills and Social skills and responsibilities. Nevertheless, the possible cause of this problem could be Protégé s treatment of an object having more than one universal restriction, in which an additional tag of <ObjectUnionOf> encloses the <Class> tags identifying the object, causing the Ontograf visualizer to ignore all entries that are enclosed by the <ObjectUnionOf> tags. Fig. 6 shows the XML code depicting PLO 3 with one MQF LO, and PLO 4 with two MQF LOs. A comparison of Figs. 5 and 6 indicate the inconsistency in Protégé s treatment of single and multiple universal restrictions. Another limitation is the simple text-based UI that is currently functional but visually not as pleasing as the Ontograf visualizer. Fig. 5. PLO 3 with one MQF LO, PLO 4 is missing its MQF LOs. C. Future Work Owing to the limitations highlighted above, it is proposed that a Graphical UI (GUI) be developed to visualize any number of universal restrictions. This GUI must be compatible with the API functions, as well as incorporate full API functionality. Ideally, it should also enable a new ontology to be created within its system. However, this level of functionality would entail creating another ontology editor, thus resulting in the project re-inventing the wheel. Therefore, priority should be focused on the task of developing the GUI to take care of the API functions first. In the meantime, the Protégé ontology editor can still be used to create any number of ontologies as necessary as the XML and Protégé form are compatible. REFERENCES [1] T. R. Gruber, A translation approach to portable ontology specifications, Knowledge Acquisition, vol. 5, no. 2, Jun. 1993, pp. 199 220, doi:10.1006/knac.1993.1008. [2] T. Berners-Lee, J. Hendler, O. Lassila, The semantic web, Scientific American, May 17, 2001, ScientificAmerican.com, http://www.sciam.com/print_version.cfm?articleid=00048144-10d2-1c70-84a9809ec588ef21. [3] L. N. Cassel, L. N. Sloan, G. Davies, H. Topi, A. McGettrick, The Computing Ontology Project: The computing education application, Proc. 38 th SIGCSE Technical Symposium on Computer Science Education (SIGCSE 2007), ACM, Mar. 2007, pp. 519 520, doi:10.1145/1227310.1227486. [4] L. N. Cassel, G. Davies, R. LeBlanc, L. Snyder, H. Topi, Using a Computing Ontology as a foundation for curriculum development, Proc. Sixth International Workshop on Ontologies & Semantic Web for E-Learning (SWEL 08), Jun. 2008, pp. 21 29, http://compsci.wssu.edu/iis/swel/swel08/papers/cassel.pdf. [5] A. Tang and A. Lee, A computing curriculum wiki Analysis and modeling using the MAS-CommonKADS agent-oriented methodology, Sunway Academic Journal, vol. 7, 2010, pp. 1 15. [6] A. Tang, A. Abdur Rahman, Proof-of-Concept design of an ontologybased computing curricula management system, Proc. Digital Information and Communication Technology and Its Applications (DICTAP2011), CCIS (LNCS) vol. 167, H. Cherifi, J.M. Zain, E. El- Qawasmeh, Eds. Heidelberg: Springer, 2011, pp. 280 292. [7] A. Tang, Towards the use of a Computing Ontology: A curricula management system proposal, International J. of Digital Information and Wireless Comm., vol. 1, Nov. 2011, pp. 94-108, http://sdiwc.net/digital-library/web-admin/upload-pdf/00000100.pdf. [8] E. R. Harold, Choosing between SAX and DOM, http://cafeconleche.org/books/xmljava/chapters/ch09s11.html [viewed 23 April 2012]. [9] R. M. Fernandez-Chung, Presentation on MQF in Programmes, Malaysian Qualifications Agency, Ministry of Higher Education, Malaysia, 15 Oct. 2008. [10] Malaysia Qualifications Framework. Malaysian Qualifications Agency, Ministry of Higher Education, Malaysia, http://www.mqa.gov.my/portal2012/dokumen/malaysian%20qua LIFICATIONS%20FRAMEWORK_2011.pdf. Fig. 6. PLO 3 with one MQF LO without the <ObjectUnionOf> tags, PLO 4 s two MQF LOs enclosed by <ObjectUnionOf> tags.