Article Preview
Top1. Introduction
End-users are more and more able to build mashups of Web services, local resources and processes, and other distributed information sources, into newly envisaged, and often personalized applications. While the tools that end-users may use have increased in number and accessibility over the last decade, the methods and design techniques that are targeted at end-user programmers, have not followed suit. This paper describes an end-user-friendly method called TANDEM (Goschnick et al., 2006) and demonstrates the use of it in detail, by way of the design of a mashup of services that solves the so-called movie-cinema problem. An implementation of the newly designed movie-cinema app is then built within an end-user-friendly development environment called the DigitalFriend (Goschnick, 2006). While many publications targeted at end-user programmers making mashups, have promoted imperative programming languages for the task, such as JavaScript, PHP and Python (e.g. Orchard, 2005; Feiler, 2008), the DigitalFriend uses CoLoG, a built-in logic programming language. CoLoG features overlap a substantial subset of the Prolog language (Sterling & Shapiro, 1994; Colmerauer & Roussel, 1993), together with added extra-logical predicates concerned with character-based I/O and the GUI interface in order to interact with an end-user, together with some features of a Constraint Logic Language (Marriott & Stuckey, 1998). The use of logic languages is more often associated with AI (Artificial Intelligence) and agent-oriented software development environments, then it is with IDEs (Integrated Development Environments) targeting end-user programmers; nonetheless, logic languages could have a big role to play in end-user programming, hopefully foreshadowed by the approach taken here. And although the DigitalFriend is usable as a multi-agent system (MAS), it was envisaged from the outset of its development, as an IDE targeted at end-user programming (Goschnick, 2006), via a methodology grounded upon people-oriented programming (Goschnick, 2009).
Even from the early days of Prolog it was recognized as a language that could be used to bring together code, additively over time, that included both descriptive logic (data structures) and procedural logic (algorithms), as Ceri & Gottlob (1986) noted: “Prolog makes possible an integrated description of data structures (‘facts’) and algorithms (‘rules’), where the algorithms are produced and presented additively, as small ‘granules‘ of the overall system.” Although the authors went on to describe incremental development on one computer, the quote remains descriptive of how we use CoLoG today, to bring together data records (facts) from multiple local and distributed Web-based sources, including Relational DBMS, often in real-time, and combine them with rules that have been devised for the purpose of a mashup, in the DigitalFriend IDE.
Given that logic programming is not widely used as compared to imperative programming (e.g. JavaScript, Python, PHP), particularly with respect to making mashups, and that some appreciation of the highly compact expressive-power of it, is useful to the reception of this paper, two small sample logic programs written in CoLoG are given here: one procedural logic, and the second one mostly descriptive logic. This first example given in Figure 1 is all procedural in its logic and quite cryptic, as procedural logic often is. Whereas the second example given in Listing 1 is mostly descriptive logic, made up by a single procedural rule at the top that is supplemented by the many facts (hundreds of data records), coming from various data sources, that follow it. Note: Those lines in Listing 1 consisting of an ellipsis only (...), indicates the omission of many similar facts, for example the lines starting with countryCurrency each represent one country, and there are 248 such lines in the full program, needed to cover all countries.
Figure 1. A small logic program running in the DigitalFriend