The World Wide Web is a vast, mildly curated repository of information. While search engines fairly accurately filter the Internet based on content, they are less effective at filtering based on functionality. For example, they lack options to identify mobile-capable sites, sites that provide certain interoperability mechanisms, or sites related to certain industries or with certain content rating levels. There is a space where such a model already exists: the “app stores” that pervade the native mobile app landscape. In addition to the app itself, these hubs have deep awareness of application metadata, such as mobile and/or tablet support. Another deficit of search engines is their inability to allow organization-based configuration, defining a worldview with trust relationships, filters and transformations to curate the results they present to end users. Native app stores use a star (hub-and-spoke) topology with a central hub for publishing, which lacks this fine-grain customizability, but an alternative peer-to-peer topology, as is used for autonomous systems across the Internet, restores this freedom.
ECTG is working with IMS-GLC to create the Community App Sharing Architecture (CASA) as a standard and example for publishing and sharing web applications with metadata about features and functions; further, it includes mechanisms for filtering and transforming this data during the publishing and sharing processes. This enables the construction of affinity-focused environments that may connect with peers to which it may share apps and publishers from which it may receive apps. Use cases for CASA include an LTI Tools store, a K-12 website or an organization’s mobile dashboard, such as UCLA Mobile.
The Community App Sharing Architecture (CASA) enables the sharing of web apps and associated metadata (“mi casa es su casa”) through the URI Sharing Environment (USE) Protocol. CASA is comprised of three modules which represent an implementation of the USE Protocol. The first module is the CASA Engine, which queries other CASA Engine publishers that share modules with peers based on its organization-specific configuration. The second module is the CASA Engine Manager which provides an administrative user interface for the management of the engine’s organization-specific configuration, including peering relationships, filters and transformations; and allows the entity to set and manage their preferences and filters for content. The third module is the CASA Storefront, which provides an “app store” user interface for easy user access to apps received by or published into the CASA Engine. The initial CASA storefront will be developed for Moodle, but given differences in consumer environments, it is expected that eventually numerous versions of the CASA Storefront will exist.
For questions regarding CASA, please contact Rose Rocchio at email@example.com