English (United Kingdom)

https://curated-unify.zendy.io/wp-json/zendy-region/v1/featured_content/oa?rat=en

https://curated-unify.zendy.io/wp-json/zendy-region/v1/highlighted_journal/

Global: Zendy Plus annual

Presents the access of premium content as premium feature

Premium Content

Presents the keyphrase highlighting as premium feature

Keyphrase Highlighting

Presents the summarisation as premium feature

Summarisation

Insights

Presents the pdf analysis as premium feature

PDF Analysis

Presents the zaia usage as premium feature

ZAIA

Global: Zendy Plus monthly

Global: Zendy Tools annual

Global: Zendy Tools monthly

Global: Zendy Free Plan

Broisin, Vidal, Meire, and Duval (2005) identified the interoperability gap that exists between Learning Management Systems (LMS) and Learning Object Repositories (LOR). Briosin et al. (2005, p. 478) aptly observed, "It is clear that some sort of interface between the two components (LMS & LOR) is required to enable a system to benefit from the other one." LMSs are independent computer systems that manage and deliver course content to students via a web interface. In contrast, LOR functionality includes storage, cataloging of metadata, inquiry, and retrieval of Learning Objects (LOs) for design, maintenance and reuse. Therefore, the purpose and functionality of LMS software in comparison to LOR software is very different. LMSs and LORs exist on public and private networks located in many different countries. These disparate, independent networks are often only connected via the Internet and leverage a variety of different software and hardware technologies. The first phase of this research study gained a consensus of CIS experts regarding the functional requirements for a new middleware application that would resolve the interoperability gap between LMSs and LORs (Mason & Ellis, 2011). The second phase of the study involved the development of a Service Oriented Architecture (SOA) middleware prototype that provided a solution for the data movement interoperability gap that exists between LMSs and LORs. Prior research by Krishnamurthy (2006), Sartipi and Dehmoobad (2008), and IMS (2009) suggested that SOA is a sound architecture to resolve the data movement interoperability gap that exists between LMSs and LORs. Mason and Ellis (2010) argued that SOA was the best alternative for a middleware architecture because it provided: (a) loose coupling via message only communication that is conducted at the inter-organizational level, (b) the strongest adaptability and modifiability of the six middleware alternatives that they reviewed, and (c) open standards that support interoperability. Therefore, SOA was the premise for the high-level architecture that is described in the next section. High-Level Architecture The high-level architecture of the LMS and LOR Middleware Application (LLMA) prototype consisted of five major components: (a) a Web-based user interface, (b) a Web Service Coordination Program (WSCP), (c) an Oracle 11gR2 Metadata Repository, (d) an open source LMS called Moodle (Modular Object-Oriented Dynamic Learning Environment), and (e) an open source LOR called FLORI (Fedora Learning Objects Repository Interface). Figure 1 shows the five LLMA components. [FIGURE 1 OMITTED] Prototype Development One of the first steps during the analysis and design process of the prototype was the identification and documentation of 14 high-level use case diagrams. The use case diagrams and functional requirements were then leveraged as input for the modeling of an entity relationship diagram (ERD) to support the Metadata Repository. The data model was created using the third normal form and served as the foundation for the construction of tables, constraints and indexes that were instantiated within an Oracle 11gR2 database. The use of the third normal form model avoided data redundancy and data integrity errors that can occur when using denormalized tables. The Metadata Repository consisted of 20 tables, 33 indexes, 3 stored functions, 147 constraints, and 7 sequences. The design process continued with the creation of a UML state processing chart for the Web Service Coordination Program (WSCP). The WSCP was designed as an event processing engine to interface with external applications via Web Services and exchange SOAP messages. The UML state processing chart was an appropriate tool to model the high-level processing mechanism for the WSCP and this approach was supported by the research methodology. Each state that was modeled in the diagram was later coded into a section of the WSCP program using the Hypertext Preprocessor (PHP) programming language (version 5. …

issues in informing science and information technology/issues in informing science and information technology education

A Research Study for the Development of a SOA Middleware Prototype that used Web Services to Bridge the LMS to LOR Data Movement Interoperability Gap for Education