SMashup Personal Learning Environments Mohamed Amine Chatti1, Matthias Jarke1, Zhaohui Wang1, and Marcus Specht2 1 Informatik 5 (Information Systems), RWTH Aachen University {fchatti,jarke,wangg}@dbis.rwth‐aachen.de, 2 Open University of the Netherlands, Netherlands marcus.specht@ou.nl Abstract. Mashups have become the driving force behind the development of Personal Learning Environments (PLE). Creating mashups in an ad hoc manner is, however, for end users with little or no programming background not an easy task. In this paper, we leverage the possibility to use Semantic Mashups (SMashups) for a scalable approach to creating mashups. We present the conceptual and technical details of PLEF‐Ext as a flexible framework for mashup‐driven end‐user development of PLEs. PLEF‐Ext uses the Service Mapping Description (SMD) approach to adding semantic annotations to RESTful Web services, and leverages the SMD annotations to facilitate the automatic data mediation and user‐friendly creation of learning mashups. 1 Introduction Recently, the mashup concept has emerged as a core technology of the Web 2.0 and social software movement. A mashup indicates a way to create new (Web) applications by combining existing data and services from several sources. In the past few years, Web mashups have become a popular approach towards creating a new generation of customizable Web applications. The popularity of Web mashups has mainly been driven by the increasing popularity of lightweight RESTful Web services, AJAX, and JSON that build core technologies in the Web 2.0 movement. Mashup development has also become a very popular re‐ search topic in TEL. Many TEL researchers recognized the value of mashups and have already adopted the mashup concept for Personal Learning Environment (PLE) development. The idea behind mashup PLEs is to let learners create their very own learning mashups that leverage components and content generated by learning service providers and other learners around the Web. Yet, most of the proposed mashup PLE approaches are based on widgets. In this paper, we go a step further toward supporting the mashup of RESTful services and the use of semantic approaches to deal with service integration and mediation within mashup PLEs. We propose a mashup PLE framework, called PLEF‐Ext, that enables a user‐friendly creation, management, sharing, and reuse of learning mashups. The paper proceeds as follows. In Section 2, we discuss how mashups can provide a powerful tool to build PLEs. In Section 3, we provide an overview of some popular and representative mashup development tools and frameworks, and summarize the main problems in mashup development today, focusing specifically on the data mediation and integration challenges. In Section 4, we highlight the benefits of using semantic mashups for a scalable and flexible mashup development. Section 5 presents the Semantic Mapping Description (SMD) approach to adding semantic annotations to RESTful Web services and shows the benefits of adopting a semantic mashup approach based on SMD. We follow in Section 6 with the conceptual and technical details of PLEF‐ Ext, a mashup PLE frame‐ work that can help learners share, find, integrate, reuse, and easily remix learning services based on a semantic description of the same. And finally, we summarize our findings in Section 7. 2 Mashup Personal Learning Environments A Personal Learning Environment (PLE) is a learner's gate to knowledge. From a technical point of view, a PLE can be viewed as a self‐defined collection of services, tools, and devices that help learners build their Personal Knowledge Networks (PKN), encompassing tacit knowledge nodes (i.e. people) and explicit knowledge nodes (i.e. information). Thus, mechanisms that support learners in building their PLEs become crucial. Mashups provide an interesting solution to developing PLEs. We differentiate between two types of mashups: 6 • Mashups by aggregation simply assemble sets of information from different sources side by side within a single interface. Mashups by aggregation do not require advanced programming skills and are often a matter of cutting and pasting from one site to another. Personalized start pages, which are individualized assemblages of feeds and widgets, fall into this category. • Mashups by integration create more complex applications that integrate different application programming interfaces (APIs) in order to combine data from different sources. Unlike mashups by aggregation, the development of mashups by integration needs considerable programming expertise. Most of the state‐of‐the‐art mashup PLE solutions only focus on the first type of mashups, i.e. mashups by aggregation. These solutions mainly support learners in juxtaposing content from different sources (mainly feeds and widgets) into a single interface. Examples include PLEF1, MUPPLE2, and ‐ although not designed as educational technology ‐ Personalized Start Pages such as iGoogle3 and Netvibes4. In the next section, we discuss the current status of mashup development with a focus on the second type of mashups, i.e. mashups by integration. 3 Mashup Development The Internet and its related technologies have created an interconnected world in which we can easily exchange and reuse information in unforeseen, unexpected ways. Web services are emerging as a major technology for deploying automated interactions between distributed and heterogeneous applications [2]. In the Web 2.0, services based on the representational state transfer (REST) paradigm [3] are increasingly popular for Web development. RESTful services often take the form of RSS/Atom feeds and AJAX based lightweight services, which explains their greater success compared to heavyweight services, which are based on the Web Services Description Language (WSDL) and SOAP. The output formats of RESTful services, often in the form of Extensible Markup Language (XML) or the more lightweight form JavaScript Object Notation (JSON), make RESTful services ideal for AJAX‐based mashups. Developing mashups is however not an easy task. In general, mashup development is still very much an ad hoc activity. Mashups are often generated manually using normal Web development technologies such as HTML, CSS and JavaScript [4]. Creating a mashup in a manual manner is a very time consuming task and impossible for the typical Web user [5]. A key difficulty in creating mashups is data mediation between the services to be mashed up. Typically, in order to create a mashup, the user would need to understand not only how to write code but also the APIs and descriptions of data formats of all the services that need to be included in the mashup [6]. To lower the barrier of creating a Web mashup, leading companies are now actively developing different mashup building tools and platforms, that require little to no programming knowledge from the user. Yahoo! Pipes5, Microsofts Popfly6 and Google Mashup Editor7 are some well‐known examples of mashup platforms that users have largely adopted. In general, these platforms provide a higher level of abstraction and use visual programming techniques to facilitate the creation of mashups. For instance, Yahoo! Pipes provides a visual editor to wire different graphical elements to each other, based on different kinds of data processing operations such as regular expressions, 1 http://eiche.informatik.rwth‐aachen.de:3333/PLEF/index.jsp 2 http://mupple.org 3 http://www.google.com/ig 4 http://www.netvibes.com/ 5 http://pipes.yahoo.com/ 6 http://www.popfly.com/ 7 http://code.google.com/gme/ 7 filters, sorting or looping instructions. Similarly, Microsoft Popfly provides a Web‐based GUI, where the user can connect different Web services to each other by dragging the blocks representing them into the main display and drawing wires to connect those services. Google Mashup Editor (GME) provides a higher level JavaScript API for manipulating data programmatically. A detailed description and comparison of these and other mashup development tools is provided in [7]. Google Mashup Editor has not been designed to be used by end users without background in programming. It is more suitable for amateur and professional mashup programmers. And, other mashup editors, such as Yahoo! Pipes and Microsoft Popfly, that are intended for non‐professional mashup developers suffer from two main limitations. First, most of the mashup tools are restricted to services that have standard types of outputs, such as RSS or ATOM. These mashup tools are particularly capable at processing and creating new feeds. A common feature is (1) pull data from external RSS and Atom feeds, (2) filter, sort, and combine many feeds into one, (3) grab the output as RSS, JSON, KML, and other formats, and (4) include the result as a widget in other Web sites. Second, the usage scope of these mashups tools is often limited to services that are internal to the company where the mashup tool was developed (Yahoo! Pipes, for example, adds Yahoo! Maps to any pipe containing GeoData). And, in most cases these mashup tools are restricted to a set of few of popular services such as Flickr, Digg, or popular map, traffic or weather services. As a consequence, a plethora of existing (RESTful) services cannot be used by these mashup tools. If one of the companies behind the aforementioned mashup tools, for some reason, would be willing to add a new external service to their supported service pool, it would be necessary to implement a new wrapper in order to accommodate the new service. This is, however, not a scalable solution due to the rate at which new services are coming online [6]. Moreover, it would be extremely difficult to work with a service whose inputs and outputs are in a different format. This makes it difficult to address issues related to data interoperability, integration, and mediation [5]. The concept of Semantic Mashups (SMashups) [8] addresses these limitations by proposing the semantic annotation of Web services as a solution to the service integration and mediation challenges. 4 Semantic Mashups (SMashups) The challenges of service interoperability, reuse, integration, and mediation have led to several proposals for Semantic Web services. Several research projects have looked at semantics for traditional (WSDL or SOAP) Web services to help address heterogeneity, reuse, and mediation challenges, and the community took a step toward supporting semantics for Web services by adopting Semantic Annotation for WSDL (SAWSDL)8 as a W3C recommendation in 2007. The SAWSDL specification enables semantic annotations for Web services using and building on the existing extensibility framework of WSDL [2, 9]. In SAWSDL, se‐ mantic annotations describing inputs, outputs, operation, interfaces, and faults, are embedded as properties in the WSDL [5]. Recently, driven primarily by the popularity of lightweight RESTful Web services, AJAX, and JSON that build core technologies in the Web 2.0 movement, attention has shifted to using semantics to annotate RESTful Services. For instance, [5, 6] proposed a framework called Semantic Annotation of REST (SA‐REST) to add semantics to RESTful services. SA‐REST builds upon the authors' original ideas in WSDL‐S [10], which was the primary input of the W3C recommendation SAWSDL. The key difference between SAWSDL and SA‐REST is that unlike SAWSDL, where annotations are 8 http://www.w3.org/2002/ws/sawsdl/ 8 added directly in the WSDL of the service, SA‐REST annotations have to be embedded into the HTML page that describes the service. Consequently, SA‐REST uses microformat‐based approaches such as RDFa9 and Gleaning Resource Descriptions from Dialects of Languages (GRDDL)10 to add and capture annotations via properties of HTML elements [6]. The major drawbacks of an SA‐REST approach to add semantic annotations to RESTful services are threefold: First, semantic annotation with SA‐REST requires the use of microformats. Microformats, however, come in many different competing forms. And, even the process of adding semantics with standardized microformats such as RDFa or GRDDL is not straightforward. For instance, to annotate a HTML page with GRDDL the service provider needs (1) to embed the annotations in any, not necessarily standardized, microformat, (2) add the URL of the GRDDL profile to the head element in the HTML document, and (3) add to the head element a link tag that contains the URL of an XSLT that translates the GRDDL profile into SA‐REST specific RDF triples [5]. The complexity of these microformats makes it hard for SA‐REST to be adopted by service providers for the semantic annotation of their RESTful services. Second, the annotation of a concept (e.g. input, output, operation) in SA‐REST is a way to tie together the concept to a class that exists in an ontology [5]. SA‐REST, thus, presumes an agreement among all service providers on a common ontology. This is however not realistic, since it would be impossible to get all service providers to agree on a single ontology to describe their concepts. Third, besides linking a concept to an ontology class, data mediation in SA‐REST requires the specification of a lifting and lowering schemas, that is mapping of the data structure that represents the input and output of a given service to the data structure of the ontology. The use of lifting and lowering schemas means, on the one hand, extra complicated work for the service provider to work with XSLTs or XQueries to specify and keep up‐to‐date its lifting and lowering schemas, and, on the other hand, higher server workload and additional server‐side code in order to deal with parsing and applying the lifting and lowering mappings between the services to be mashed up and the ontology. Recently, Kris Zyp [11] has proposed a more lightweight and standards‐based approach to adding semantics to RESTful services, called Semantic Mapping Description (SMD). 5 Service Mapping Description (SMD) In this section, we discuss the Service Mapping Description (SMD) approach to adding semantic annotations to RESTful Web services. SMD is a flexible and simple JSON representation describing Web services. A wide array of web services can be described with SMD including RESTful services and JSON‐RPC services. SMD uses JSON Schema to provide a definition for a variety of available services, and document how to call the services, what parameters are expected, and what to expect in return [11]. Figure 1 shows the Yahoo! search service semantically annotated with SMD. Similar to SA‐REST, SMD facilitates data mediation between the services to be mashed up, since it provides a thorough description of how a service can be invoked, the type of data that should be passed to the service and what will be returned from it. The main advantage of SMD, as compared to SA‐REST, is that it is based on JSON. JSON is a lightweight data interchange format whose simplicity has resulted in widespread use among Web developers. JSON offers two major advantages over XML. First, JSON‐encoded data is less verbose than the equivalent data in XML. XML uses duplicate start and end tags to wrap data values. A JSON object, by contrast, is simply a series of comma‐separated name:value pairs wrapped in curly braces. This yields better performance of the JSON‐based Web 9 http://www.w3.org/TR/xhtml‐rdfa‐primer/ 10 http://www.w3.org/TR/grddl/ 9 applications because JSON data downloads more quickly than XML data. JSON's second benefit is that it's easy to parse using any programming language, and its structures map more directly onto the data structures used in modern programming languages. Because it is essentially a string representation of a JavaScript object (hence the name), browsers can parse JSON data simply by calling the JavaScript "eval" function. Any field of the JSON object can then be directly accessed by name. Fig. 1. Semantic Annotation of RESTful Web Services with SMD JSON is also the basis of a very powerful technique for building client‐based (in‐browser) mashups, namely JSON with Padding (JSONP), which was created as a workaround to the Same‐Origin Policy (SOP) problem. In Web 2.0, Asynchronous JavaScript and XML (AJAX) is becoming the driving force behind mashups. In AJAX, data is retrieved using the XMLHttpRequest function, which is an API that lets client‐side JavaScript make HTTP connections to a server. The SOP, however, prevents the AJAX code from making an XMLHttpRequest call to a URL that is not on the same domain as the current page, because of the cross‐domain attacks that could result. The normal way around SOP is to have the Web server behave as a proxy. The Web page then requests data from the Web server it originates from, and the Web server handles making the remote call to the third‐party server and returning the results to the Web page. Although widely used, this technique isn't scalable. Another way to overcome the SOP limitation is to insert a dynamic script element in the Web page, one whose source is pointing to the service URL in the other domain and gets the data in the script itself. It works because the same‐origin policy doesn't prevent the insertion of dynamic script 10 elements into the Web page and treats the scripts as if they were loaded from the domain that provided the Web page. This is actually how JSONP works: load the JSON response within a