Computational Origami Environment on the Web - Amazon Web ...

Computational Origami Environment on the Web Asem Kasem and Tetsuo Ida Department of Computer Science University of Tsukuba {kasem, ida}@score.cs.tsukuba.ac.jp

Abstract. We present a computing environment for origami on the web. The environment consists of the computational origami engine Eos for origami construction, visualization, and geometrical reasoning, WebEos for providing web interface to the functionalities of Eos, and web service system Scorum for symbolic computing web services. WebEos is developed using Web2.0 technologies, and provides a graphical interactive web interface for origami construction and proving. In Scorum, we are preparing web services for a wide range of symbolic computing systems, and are using these services in our origami environment. We explain the functionalities of this environment, and discuss its architectural and technological features.

Keywords. Computational origami, symbolic web services, origami theorem proving, symbolic computation.

1

Introduction

Computational Origami is a branch of the science of shapes, in which we study computational and mathematical aspects of origami [4]. As part of our research in computational origami, we are developing a software system, called Eos (Eorigami system) [10, 12]. The system has capabilities of symbolic and numeric constraint solving, visualization of origami constructions, and assists the user in proving geometric theorems about the constructed origami by symbolic computation methods, such as of Gr¨obner bases and cylindrical algebraic decomposition. During the development of Eos, we became increasingly interested in providing origamists, who are interested in computational origami, with the facilities to use our system, so that they can experiment with it, and make use of its variety of functionalities. To reach larger number of potential users, we wanted to provide the functionalities of Eos through the web, and thus, we have built a web origami environment that includes: interactive interfaces that enable users to easily construct origami pieces using web browsers, and a system for symbolic computation web services that allows them to reason about origami constructions, and gives access to various useful symbolic computations. In this paper, we will present the outcome of our efforts to build this environment.

2 The paper is organized as follows. In Section 2, we will give an overview of our computational origami environment. In Section 3 we briefly explain the usage of Eos system with an illustrative example. In Section 4, we present WebEos system that interfaces Eos to the web, and explain how to use it for origami construction and proving. In Section 5, we discuss the design issues and the implementation of WebEos, and in Section 6 we discuss Scorum system for symbolic computation web services. In Section 7, we review some related works, and then we summarize our results and point out further research themes in Section 8.

2

Overview of the Computational Origami Environment

Figure 1 shows the overview of the computational origami environment, which we call Origamium. It consists of the following parts: – Eos: origami construction, visualization, and reasoning engine [12], – WebEos: web application that interfaces Eos to a web browser [15], – Scorum (Symbolic Computation Forum): light-weight middleware for symbolic computation web services [21], – Symbolic computation services accessed over the network using each API (application program interfaces), and – Web server(s) that runs WebEos and Scorum.

Fig. 1. Overview of Origamium

3 Among the above components, Eos is most important. Eos is developed using Mathematica [25], as we need a language for symbolic and algebraic computation, as well as for numeric and graphics computation. Eos is organized as a collection of Mathematica packages. They are the implementations of basic geometrical algorithms for computational origami constraint solving, visualization of origami, and assistance of geometrical theorem proving. Users of Eos usually access Mathematica through its frontend, called notebook, which is the main user’s interface to its functionalities. Users load Eos packages and interact with Eos using text-based commands. In Fig. 1, we note the following: – Eos is accessed from Mathematica notebook situated in user’s client computer. The dashed-dotted arrow from Mathematica notebook to Eos shows possible direct calls from Mathematica frontend to programs within the same environment. – The dashed arrows show possible calls made to web services using standard protocols, whether from web interfaces or from Mathematica itself. – Normal arrows show possible calls from Java code to Mathematica programs. – Eos runs in the kernel of Mathematica situated in the server (possibly networked)1 . This approach of accessing Eos would be limited in applicability unless every interested origamist has Mathematica installation in his/her computer, and further has the Eos packages that undergo frequent revisions. Either of the two conditions are not necessarily satisfied when we started to think about providing Eos services to its users. Therefore, we decided to provide the services of Eos on the web. This new approach enabled us to exploit new web technology, often collectively called Web2.0, and web services technology. Web2.0 technology enables users to use their web browsers with a richer enhanced user-computer interactivity, and the web services broaden the scope of usable computing services.

3

Origami Construction and Reasoning with Eos

Eos provides two methods for origami folding: classical fold and mathematical folds. The former method represents traditional artistic fold method, by which we construct origami art pieces, e.g. crane (see the right pane of the window in Fig. 6). We have implemented inside-reverse, outside-reverse, and squash folds. The latter method is based on the axiomatic definition of origami folds given by Huzita [9]. Eos has a complete implementation of Huzita’s six fold operations and the 7th operation added by Hatori [8]. Those operations are called Huzita’s axioms2 . The axioms are in essence declarative statements about the existence 1 2

The notebook and the kernel can be in the same machine, but not necessarily. Strictly speaking, these operations are not axioms, since the 5th and 6th fold operations are not always possible. Nevertheless, we use the word Huzita’s axioms, as they are commonly used in the literature.

4 of lines along which we can make a fold satisfying certain geometrical properties. For instance, Huzita’s axiom 4 states that: “Given one line and one point, you can fold making the crease perpendicular to the line, and passing through the point (perpendicular footing)”. Finding the fold line which satisfies it is equivalent to finding a perpendicular to the line, which passes through the point. We transform those axioms into Mathematica programs. These programs prescribe a solving method for a constraints problem, i.e. to determine fold lines according to the constraints specifications given by each axiom. The constraints are solved numerically to compute a specific data structure representing an origami, which is then visualized. Furthermore the constraints are stored symbolically as geometric properties representing the folds, and are used later for reasoning about the construction. Below, we will explain some of the basic functions of Eos using an example of constructing an equilateral triangle. We start the construction always by the following function call. BeginOrigami[ ] The function call creates the initial origami structure and returns the graphic object representing the origami structure. The graphic object is visualized on the notebook as shown in Fig. 2.

D

C

A

B

Fig. 2. Visualized graphic object representing an initial origami computed by BeginOrigami[ ].

Huzita’s operations are realized as the generic function Fold. For example, the 4-th operation is realized by the function call Fold[A,Perpendicular → {P, s}] This call makes a fold of the current origami along the line perpendicular to line s and passing through point P. This call further stipulates that point A is to be moved to make a valley fold along the fold line. An Eos command in the form of a function call such as the one above is typed in the Mathematica notebook, and it is then sent to the Mathematica

5 kernel running Eos. The result of the evaluation of the function call is returned to the notebook and is visualized on it. Based on this result, we perform the next step of construction. It is important to note that this process is necessarily interactive since we rely on the shapes of the previous steps, especially on the names of the points which are automatically generated by Eos. The parameter specification of the next function call of Fold requires those points. Figures 3∼5 show the interaction with Eos after the call of BeginOrigami[ ] for the construction of an equilateral triangle. In Fig. 3, we make folds to bring point A to D, and then A to B. Note that the position of point A has been changed by the previous fold. Next, we unfold the origami to its initial shape. In Fig. 4, two possible folds are suggested by Eos when it evaluates Fold[D, GH, Through → A], which tries to make a fold along the line that passes through A, to bring D to be on the line extending the segment GH. By re-evaluating Fold[D, GH, Through → A, Case → 1] (with added parameter Case → 1) we can make the fold along the line specified in case 1, and create the line AK. Similarly we construct the line AL. Finally, we call Fold[C,Along → KL] to complete the construction of the triangle, by folding along the line KL.

A

B

F

E

H

D D

H

C

G

F F

G

E

A

I

B

Fig. 3. Result of evaluating Fold[A, D], Fold[A, B], and UnfoldAll[ ]

After constructing the triangle, we want to prove that it is indeed equilateral. The automated proof using Eos proceeds in the following way: 1. Model the construction algebraically and generate the algebraic relation satisfying the constraints that have been solved during the construction. The algebraic relations are represented as a system of polynomial equalities and inequalities. It forms the premise P of the theorem to be proved. 2. Represent the conclusion C of the theorem also as a system of polynomial equalities and/or inequalities. 3. Form the logical implication P =⇒ C, i.e., the theorem to be proved. The theorem means that under the premise, the conclusion holds (which we want to verify). To prove the theorem, we use algebraic proof methods. When the formula representing the theorem contains only equalities and disequalities,

6 Case 1

Case 2

D

H

C

D

H

C

F

G

E

F

G

E

A

I

B

A

I

B

Fig. 4. Result of evaluating Fold[D, GH, Through → A], suggesting two possible fold lines K

C

H

K

H

D

K

C D

H

D

B G

F

E

G

F

E

G

F

B I

A

I

B A

L

C

I

E

L

A

Fig. 5. Result of evaluating Fold[D, GH, Through → A, Case → 1], Fold[B, GE, Through → A, Case → 2], and Fold[C, Along → KL]

we can use the Gr¨obner bases method. When the formula contains inequalities, we may need more powerful (but computationally expensive in general) methods such as the method of cylindrical algebraic decomposition. 4. Depending on the method we use, further preprocessing of the formula may be necessary. For example, in order to use the Gr¨obner bases method, we need to negate the formula P =⇒ C and check its unsatisfiability. In this case, obtaining {1} as the result of the Gr¨obner bases computation tells that the theorem is proved. Note that except for the conclusion formulation, all the proving steps are performed automatically.

4

WebEos for Constructing and Reasoning

Recall that Eos is implemented in Mathematica. When a user has Mathematica installed on his/her computer, all that (s)he has to do is to invoke Mathematica,

7 load the Eos packages, and then call the functions of Eos which implements origami operations. Now we consider providing the services of Eos to those who are interested in computational origami, but do not necessarily have Mathematica installation, nor the Eos packages. WebEos realizes these requirements.

Fig. 6. The login interface of WebEos.

In order to access the functionalities of Eos over the web, we will perform the following: 1. 2. 3. 4.

start our web browser (e.g Internet Explorer 7), visit the home page of WebEos http://www.score.cs.tsukuba.ac.jp/webeos, construct/reason about the origami piece work, access the web services for symbolic computation, if necessary.

We will perform the same construction and reasoning as we did with Eos in the previous section. When we visit the home page of WebEos, we see the page shown in Fig. 6. On this page, we can log in to Eos and declare the initial origami, which was shown before by the call of BeginOrigami function in Eos. On the web page, we can provide better interface. We can specify the parameters of BeginOrigami by the user interface components of the system. At the time of the function call of BeginOrigami[ ] in the previous section, we did not specify the parameters of BeginOrigami, since we used the default values of the optional parameters. We could have specified the color of the front and back sides of the faces of the origami, and the size of the origami (can be rectangular). With the web browser interface, specifying the color is made much simpler since the web page shows the color palettes from which we can choose the colors. The input

8 boxes are automatically filled in by the color values if we select the colors in the palettes. After this, we press the button NewOrigami.

Fig. 7. Classical folds input panels, and the output of BeginOrigami.

WebEos then updates the page to the one shown in Fig. 7, where we see the initial origami on the right side. This is the same shape we obtained by the evaluation of BeginOrigami[ ] (with appropriate specification of the parameters). The window of Fig. 7 is the basic interface with WebEos. It has two panes: the left is the interaction pane, and the right is the origami pane. In the origami pane we always see the current origami. Using the panels of the interaction pane, we can specify various combinations of parameters for the fold operations as well as other operations.

Fig. 8. Mathematical axioms input panels, and the explanation of axiom 4.

9 In the interaction pane, we can see in the tabs different classical fold methods, such as valley and mountain folds (cf. Fig. 7). By clicking on each tab, suitable input fields for the parameters will appear. There are also a variety of auxiliary origami operations, such as unfold, turnover, delete points and duplicate points. Those can be accessed from the tabbed panels at the bottom of the interaction pane. The user can also view the mathematical fold operations, i.e. Huzita’s axioms, by selecting “Mathematical Axioms” from the dropdown menu of the fold methods. Then, the input panels will change to show the tabbed panels of the 7 axioms, as shown in Fig. 8. If the user clicks on the ’ ?’ mark of each axiom, a help message will pop up to explain about the selected axiom and its parameters. An example of axiom 4 is shown in the same figure. Using these panels, we can perform the previously explained steps of the construction of the equilateral triangle on the web. An intermediate construction step is shown in Fig. 9. The final equilateral triangle is shown in Fig. 10 by unfolding the origami to its initial shape.

Fig. 9. Execution of axiom 5 through WebEos Note that we can view the possible fold lines (in this case, there are two possible lines) by clicking the hyperlinks in the upper left corner of the origami pane.

Finally, if the user wants to reason about the constructed origami (e.g. to prove that the triangle is really equilateral), WebEos can generate the polynomials that represent the geometrical properties of the construction. This can be done using the Proof panel. We specify the desired parameters and then press the button Execute. The origami pane will show the mathematical expressions representing the polynomial equations as seen in Fig. 11. To prove the theorem, WebEos redirects the user to Scorum web pages, where (s)he can use the generated MathML as a parameter for algebraic proof methods, such as Gr¨obner bases method. This will be explained in more details in Section 6.

10

Fig. 10. Execution of UnfoldAll We select UnfoldAll from the panel of “Other operations” and press Execute, then WebEos shows the equilateral triangle on the unfolded origami in the origami pane.

5 5.1

Architecture of WebEos Overview

Figure 12 shows the architecture of WebEos. It consists of the following three software components: 1. Client-side interface: it is a collection of HTML pages and JavaScript programs generated by Google Web Toolkit (GWT ) [6]. 2. Server-side web application: it is a collection of Java Servlets which handle the client’s requests. It is deployed on a Tomcat web server. 3. Name Space Manager: it is a Mathematica package that handles the name space of Eos for concurrent multi-user access. In WebEos, we use webMathematica [24] libraries to facilitate interactions between the Mathematica system and our web application deployed on the Tomcat web server . The workflow for using WebEos is summarized as follows: 1. Using the graphical user interface of the web browser provided by WebEos, the user accesses the system and asynchronously sends a request to the server, asking for specific origami operation. 2. On the server-side, WebEos analyzes the request and acquires an available Mathematica kernel from a pool of available kernels, using webMathematica. 3. The kernel then executes the requested operation using Eos and the name space manager and generates the output. 4. The web server asynchronously returns the output to user’s web browser. 5. The web browser visualizes the output for the user.

11

Fig. 11. Polynomials generation for the geometrical properties of the construction. The user can switch between the usual mathematical expressions and the standard MathML representation

5.2

Evaluation of the earlier system

WebEos is the revision of our earlier system webOrigami [14]. webOrigami was developed with the same objectives, but with different technologies. Basically, it was a client-server web application developed using the standard Java technologies for web development, Java Servlets and JSP, in cooperation with webMathematica technology, and used Javascript to program the graphical user interface. With webOrigami we had problems in the process of software development and maintaining the quality of web pages. As the development of the whole system kept progressing, we always needed to add new features to the web system or to modify existing ones. The direct use of HTML and JavaScript, to program rich and interactive interfaces with evolving requirements, made it difficult to maintain and update the system. Maintaining many web pages with huge number of lines of code of Javascript programs was not an easy task, especially in the absence of static type checking and good debugging facilities. The lack of portability among web browsers also posed problems and made the implementation more time consuming and error-prone. We also wanted to improve origami construction on the web, by eliminating the full refresh of web pages (or frames in the web page). At each construction step, a new entire web page (or frame) should be brought from the web server, even though a small portion of this web page has only been changed. This caused more traffic between the web browser and the web server than we would need. Besides, the transition from one origami image to the next one was clumsy, or unnatural to say the least. For this, we wanted to adopt Web2.0 technologies, such as Ajax (Asynchronous JavaScript and XML) and WebServices, to have a

12

Fig. 12. Architecture of WebEos

better interactive interface with easy-to-modify capabilities, and to enable users to reason about origami construction directly through WebServices for symbolic computation. These reasons motivated us to develop WebEos, the new web interface of Eos.

5.3

Design Considerations

User Interface To improve the graphical user interface using a web browser, we use Ajax for the following reasons. Ajax allows asynchronous communication with the server. It furthermore gives additional advantages such as freedom from page refresh, less work on the server-side to format outputs and less traffic to transfer these formatted results [23, 27]. On the primitive level of programming with Ajax, we used JavaScript to handle Document Object Model (DOM) and XMLHttpRequest. However, the direct use of JavaScript has the same problems and drawbacks of direct JavaScript programming discussed in the previous subsection. With the increasing popularity of Ajax on the Internet, tools that help to overcome these difficulties are now available. Google Web Toolkit (GWT ) [6] and other tools help to reduce the difficulties of building Ajax-enabled web sites. GWT is an open source toolkit to develop Ajax applications using Java instead of direct use of JavaScript. It supports rapid client/server program development and advanced debugging facilities in any Java IDE. Moreover, it provides various widgets to facilitate graphical user interface programming, and introduces libraries and design patterns to improve programming productivity and overcome common problems in web scripting programming. In the deployment phase, the GWT compiler translates a working Java application into equivalent JavaScript one that is compatible with many web browsers.

13 Session Management An important issue that we have to tackle is the data persistency during the whole session of origami construction. The WebEos server receives requests from various origamist users on the web in an unpredictable order, possibly simultaneously, each working on his/her own origami piece. This is a situation that we do not encounter when we use Eos from a Mathematica notebook. Therefore, when it is called from WebEos, Eos has to identify users sessions and to use the private data for each user’s construction. In other words, each user’s computation has its state that has to be maintained during the whole session. Each user’s state should be saved either at the client side or at the server side. If the state is small in size, we could have stored the state on the client side in cookies. However, the state of origami structures is large and complex, and keeping it in cookies is not practical. In conclusion, we have taken the approach of keeping the state stored in Mathematica kernel on the server side throughout the session. This imposes heavier burden of responding to multiple users’ requests on Mathematica kernels and on the kernel allocation management. When a kernel is allocated to a user session, all subsequent requests from the same user must be processed in the same kernel that stores the state for that session. This solution further requires the name space management of user’s computation. To ensure this, we provide a separate user name space within each kernel. We implemented this name space separation using Mathematica’s context switching mechanism. The idea is that we first identify the variables whose values have to be persistent over the sessions for each user. The names of those variables are added to a new context generated from the session identifier, so that copies of those variables exist for each user. Since Mathematica is an interpreterbased language, the context management of this kind is relatively easy. When WebEos server is invoked for the first time, it loads the name space manager, and then it interacts with Eos through this manager. With careful design and implementation, we did not need special program modification of Eos to implement this solution of sessions management.

6 6.1

Scorum and Symbolic Computation Web Services Motivation

Symbolic computations for many practical applications require large amount of processing time and memory space, which are often unpredictable. Full exploitation of the power of symbolic computation is sometimes hampered by the limitations of the resources available on a single machine. One of the approaches for overcoming these limitations is to make use of networked resources which can be shared and deployed on demand. We can dedicate some network resources for symbolic computations, which are offered as web services. In essence, Scorum is a light-weight middleware for symbolic computation web services, which we believe are effective in this field for the following reasons.

14 First, the research in symbolic computation for several decades has produced wide range of high quality software systems, both of academic and commercial such as Mathematica, Maple [18], CoCoA [3], and SINGULAR [26] to name a few. Using web services technology, we can make important functionalities of these systems accessible to users through the web, where they can share their expertise of using them in many fields of science and technology. Secondly, new experimental systems and algorithms for symbolic computation are emerging and experimental use of these systems and algorithms can be facilitated if they are provided as web services. Thirdly, due to the variety of systems and algorithms, they usually lack compatibilities among each other, both in usage as well as in data representation. The web services system can remove some of the incompatibilities, especially those related to the representation of mathematical data. In our computational origami environment, in particular, reasoning about origami constructions is very important. For instance, how do we know that the example we showed in Section 3 is the correct construction of an equilateral triangle? Moreover, can we answer the question whether the constructed triangle is maximal in area inscribed in the origami paper? As a research tool of computational origami, we would like to provide web functionalities that support origamists in reasoning about such geometrical properties of a construction. Reasoning about a constructed origami needs algebraic and symbolic manipulation of polynomials and of logical formulations. Some symbolic computations require a highly interactive mode of processing, whereas others require large amount of computing time without the intervention of users. To distinguish degenerate cases and to eliminate some variables, we need the former kind of operations. The computation of Gr¨obner bases needs the latter kind of operations. In both cases, we often need to have several trial runs. A system that organizes our work and facilitates the interaction with the symbolic computation services will help us to focus more on each problem and properly utilize our available resources. Scorum is implemented with this immediate application in mind, although it is designed to be a more general framework to serve the above mentioned purposes. 6.2

Requirements on Scorum

The preceding discussions make clear the following requirements on Scorum: – Scorum users are not required to install many software products on their machines, nor to care about the necessary configuration details. Instead, they should be able to access the software through interactive web interfaces, and to experiment with the services that the system offers. To solve problems, users might try different methods, and compare the efficiency and precision of the solutions delivered by different software products. – Scorum should enable users on the web to submit requests for symbolic computations using standard web service protocols. The requests are processed by dedicated servers on a network that have specific capabilities of services and resources, matching the requirements of the submitted requests.

15 – There are two kinds of symbolic computations, i.e. interactive and time consuming computations. Time consuming computations are not suited for web service interaction due to the time out problems. Therefore, Scorum should offer two kinds of computation services. One is the interactive service for the computations that are expected to finish within allowed time slice. The other is non-interactive service for the time consuming computations. To use the latter service, a user submits a request and receives an acceptance notice which can be used later to check the status and the result of the requested computation, through web interfaces or via other special services such as emails. – We should have a common interface for similar tasks, even if their implementations have different syntax, parameter specifications, function names and algorithms. 6.3

Architecture and Implementation

The architecture of Scorum is based on SOA (Service Oriented Architecture), where we depend on the standards of WSDL (Web Services Description Language) and communication protocol SOAP (Simple Object Access Protocol). The functionalities of the serviced systems are offered as web services. Figure 13 shows the architecture of Scorum. There are four kinds of major modules in the system: web service repository, database, computation manager and computing system. Web services repository The services repository is a catalogue of all the services implemented in Scorum. It contains the description of the service, and the specifications and capabilities of the machines that executes it. The repository is used by the web client to obtain the information about the available services. Database The database is used to save users profiles and data, such as personal information, activities log, submitted requests, computation results, and other related information which are necessary for services execution. Computing systems The computing systems are those where the real computing for the requests takes place, like Mathematica, Maple, or CoCoA. Those systems are installed and configured on networked machines with specific resources. They are called by each corresponding computation manager. Computation manager The computation manager is a special program deployed on a web server, and interacts with a specific computing system. It sends computation requests read from the database to its computing system, waits for the execution to complete, and saves the result back to the database. The manager is responsible for scheduling the requests and selecting the next computation to perform. For each computing system, we should provide implementation for the corresponding computation manager, as each of them has its own API, interaction protocol, syntax for computation call, and data representation.

16

Fig. 13. Architecture of Scorum

We use MathML to represent mathematical expressions for the services. The use of MathML is essential to maintain interoperability and communication over the Internet, and allows us to use utility tools to input and output mathematical data on the web. To view mathematical expressions written in MathML, we use Java applet libraries provided by WebEQ [13]. The Java applets run on the web browser of the client and visualizes the mathematical expressions. WebEQ also provides graphical pallets for users to directly input the mathematical expressions. 6.4

Operations of Scorum

We explain two modes of operations in Scorum for the two services; noninteractive computing services and interactive computing services. Non-interactive services Scorum provides several web services for the same problem, depending on the computing system. For example, Scorum offers several web services for Gr¨obner bases computation implemented in several software systems. The web service is accessed in the following way:

17 1. The user accesses the web page of the service, provides the required parameters, and selects the computing system and the machine. Then, the user calls the service. 2. The web service checks the parameters and the availability of the chosen implementation. 3. If the request is adequate and the implementation is available in the repository, the web service saves the request in the database and notifies the appropriate computation manager that a new request is submitted. 4. The web service returns the ID of the saved request or issues an error message telling that the request has not been accepted. The computation manager communicates with a specific computing system in a machine, and provides the implementation details for a given computation service. When notified about a new request, the computation manager obtains the requests from the database, sorts them according to its scheduling policy, and then calls the computing system with the proper parameters. After submitting the request to the computing system, it waits for the execution to complete (or a time quota to expire3 ). When the computation manager gets the result from the computing system, it saves the result in the database and notifies the user (possibly by email). Interactive services For the interactive requests, we provide special web services that are assigned a small time quota for their execution. Those services return the results directly to the clients. If the computation takes more time than the given time quota, the web client will get an error message of “over allocated time”. Those services are directly handled by a computation manager running on the appropriate machine. The manager checks the validity of the request and starts the computation, without scheduling the requests or saving the data in the database. Currently, for Mathematica and Maple services, we make use of the the ability of these systems to limit the computation within specific time quota. For instance, in Mathematica, TimeConstrained[expr, t] function evaluates expression expr, and stops after t seconds. If the evaluation does not complete before the specified time, the kernel aborts the evaluation and returns ’$Aborted’ symbol. Maple also has a similar functionality. CoCoA system provides GBasisTimeout function for the computation of Gr¨obner bases only. The functionality of specifying the time quota for execution might not be provided by other mathematical systems, and we might need to implement our own mechanism to abort computation when the time quota is exhausted. 6.5

Example

We show an example of the use of the web service of Gr¨obner bases computation in Scorum. This web service is called from the web browser. The following steps explain how we use it: 3

See the paragraph on interactive services.

18

Fig. 14. One of the web pages of Scorum for Gr¨ obner bases computation

19 1. 2. 3. 4. 5. 6. 7. 8.

9.

10.

11.

12.

13.

6.6

We access the home page of Scorum site (http://www.score.cs.tsukuba.ac.jp/scorum) 4 . We log in using our user name and password. We are shown the list of available services. We choose the Gr¨obner bases computation from the listed services. We are directed to the Gr¨obner bases service page as shown in Fig. 14. The web page describes the service and the parameters it needs. We are asked to give a name to the computation for later handling. We have to choose one of the two implementations; Mathematica or Maple. Another feature which is not yet implemented would be the possibility to choose the machine specifications where the computation should take place. For example, the user would be provided with a list of machines to choose one. This list may contain a pentium machine with 4 GB of memory running Windows, a pentium machine with 16 GB of memory running under Linux, etc. To enter polynomials, we can just copy and paste MathML representation and have the expressions visualized in usual mathematical form. Alternatively we can use the input control of WebEQ applets to input mathematical expressions using its pallet, and then generate the MathML representation. If we choose Maple implementation, we can specify other optional parameters for the algorithm. Maple provides additional monomial order possibilities over Mathematica, and thus, users will have the opportunity to test their computations with both systems, using different algorithm parameters. When we commit the request, we are redirected to a page telling that the request has been accepted and are given the ID of our computation. In case that the request is not accepted or an error occurs, an error message is shown. We can use the given ID in another web page to check the result. On that web page we can browse all the submitted requests and see their results and/or execution status (pending, running, completed). We receive an email of notification when the computation is completed with the result or the URL of the page where we can view the result. Using Scorum to reason about origami constructions

To answer the questions we asked to ourselves in Subsection 6.1, and as explained in Section 4, we designed WebEos to be able to generate the polynomials that represent what an origamist has constructed through the web. The output is sent as a MathML text, with the possibility to forward this output to the web page of Gr¨obner bases computation. From there, the user can formulate the conclusion (e.g the lengths of the sides of the triangle are equal) and proceed as explained in the previous subsection. It is important to observe that formulating a conclusion requires some knowledge about the construction, which can not be inferred on Scorum web pages. WebEos should provide helpful interfaces to formulate a desired conclusion. This feature can be implemented in our environment in the future. 4

The system is in preparation to be available for research communities.

20 To prove the maximality of the constructed triangle, we need to reason with inequalities over the domain of reals. In [11], we showed how to prove the maximality using the cylindrical algebraic decomposition (CAD) method. For applications that need reasoning with inequalities, we provided a web service in Scorum for cylindrical algebraic decomposition. Figure 15 shows a snapshot of the web page of CAD web service. The page explains about its functionality and required parameters, and allows users to submit computation requests.

Fig. 15. Web page of cylindrical algebraic decomposition service

6.7

Security

Scorum is a web-based system that uses standard web service protocols. Hence at least we have the same problems and measures for the security as the web service applications. However, we need stronger security measures than usual

21 web service applications, as users should not be allowed to make any function calls that access/modify critical portions of the computing system. For example, users who would like to access Mathematica computations should not be allowed to execute commands or evaluate expressions which are considered as threats, such as ReadList[ "/etc/passwd"] or Run["telnetd -d"], by passing these commands in the parameters list instead of the expected ones. These security checks are not yet implemented, and it is one of the important issues of our future work (refer to Section 8). Currently we have implemented the following security measures: authentication of users and simple XML validity check. A user is authenticated by the user name and password, and any access to the system services needs this authentication.

7

Related Works

We give related works in three categories in the following three subsections. 7.1

Computational Origami Systems

An early work on simulating origami folding on computers has been done by Robert Lang in the 1980s [17]. The functionalities of this system were restricted to basic mountain and valley folds, turnover, and rotation of origami. It is a pioneering work on origami simulation by computers. It is intended to be a design tool for assisting origami by hands. Jack Fastag developed a system for virtual paper folding and diagramming software, called eGami [5]. eGami simulates the sequential folding of flat origami models in real time, and has an interface designed to suggest the natural feel of actually folding a piece of physical paper. However, it does not have functionalities of studying the mathematical aspects of origami. Other implementations of origami computer systems are by Miyazaki [20] and Mitani [19]. Their systems are designed for visualization of origami on computers and not intended to be a research tool for mathematical study of origami. All the related works mentioned above are complementary, in approach, to computational origami, and it would be interesting to incorporate some of their components to Eos to improve the quality of the interaction between computers and origamists. 7.2

Origami Construction on the Web

As far as we know, there is no other system for computational origami that is designed especially for web users. There are many web sites for origami world wide. Some of the sites are extremely rich in contents [1, 16]. However, none of those origami sites provide dynamic construction of origami’s by web visitors.

22 7.3

Symbolic Computation Web Services

There has been interesting researches going on in the field of symbolic computation services that make use of networked resources, and more specifically, in the field of symbolic computation as grid services. While grid services have different goals from pure web services, a grid service is basically a web service with useful additions: stateful services, service instantiation, named service instances, two-level naming scheme, a base set of service capabilities, lifetime management and so on. In our web environment for computational origami, we were more interested in the services that origamists are interested in. Our targeted set of symbolic computations is restricted to these which help users of our environment to proceed with their research and experiments of origami construction and reasoning. Thus, the requirements of our symbolic computation services are different from those of general grid services. Besides, building a grid environment, configuring and tuning its system components, require considerably difficult work and time to make the services available. For these reasons, we decided to provide the services as web services rather than building or integrating a complete grid solution. For more information on web and grid based symbolic computing services, see the work on SymGrid [7, 2]. For more comprehensive review, refer to the chapter of Symbolic Computations on Grids, in the book “Engineering the Grid” [22].

8

Conclusion and Future Work

In this paper, we presented the Eos, WebEos, and Scorum systems, which are the main components of the computational origami web environment Origamium. Since WebEos and Scorum are research tools, we are constantly extending their functionalities and experimenting new ideas, and therefore our efforts so far are focussed on extending their functionalities. We enumerate below the subjects of further research. Our plan to extend the functionalities includes providing WebEos with interfaces that help users to formulate conclusions about origami constructions. Currently, users can submit the conclusion in the form of polynomials. However, to formulate more sophisticated geometrical properties, WebEos should give further assistance by providing the users with a richer set of defined functions to generate these polynomials in a visually interactive way. We also want to enhance the visual interaction with WebEos, by enabling users to use mouse clicks on the visualized origami of their web pages, to select the points and lines for origami operations. In Scorum, as an initial project, we have implemented web services for Groebner basis computation in Mathematica and Maple, and for cylindrical algebraic decomposition computation in Mathematica, along with the web interfaces to call these services and to provide the functionalities that the user needs. To extend the functionalities, we need to work on several issues: First, implementing

23 new web services for symbolic computations which we think will be useful for our origami environment, and for the users who access Scorum services. Second, integrating other mathematical computing systems into Scorum. Currently, we can access only Mathematica and Maple systems. Adding another system needs careful study for its functionalities, programming languages that access its API, data representation, and security level. As the community aspect is a distinguishing feature of Web2.0, we also aim at having a community building aspect in our systems. For example, a collective repository of origami constructions can be built by users who log in, create origamis and share them with the community. Besides, users who access Scorum services and experiment with specific computations, find interesting results, or face difficulties, should be enabled to share their findings, expertise, and problems with the users in community. Security is another important issue to be addressed. WebEos has full access to the Mathematica kernel that performs origami operations. Naturally, user interactivity involves accepting user’s parameters and input. This input is considered as a vulnerable bridge that allows users to embed malicious code which can access the resources of the machine running Mathematica kernel, and allows them to delete or expose critical information. Similar problem appears in the requests for symbolic web services of Scorum. User’s submitted data must be checked and analyzed before computation, based on the functionalities, syntax, and security measures of each computing system. One interesting approach to solve this problem is to analyze user’s input using software verification.

Acknowledgements This research is supported by the JSPS Grants-techniques-Aid for Scientific Research (B) No. 17300004 and for Exploratory Research No. 19650001. We also would like to thank the anonymous reviewers for their valuable comments and suggestions.

References 1. E. M. Andersen. Origami and math. http://www.paperfolding.com/math. PaperFolding website. 2. A. Carstea, M. Frincu, G. Macariu, D. Petcu, and K. Hammond. Generic access to web an grid-based symbolic computing services. In 6th International Symposium on Parallel and Distributed Computing (ISPDC), pages 143–150, Hagenberg, 2007. IEEE Computer Press, Los Alamitos. ISBN 0-7695-2917-8. 3. CoCoATeam. CoCoA: a system for doing Computations in Commutative Algebra. Available at http://cocoa.dima.unige.it. 4. E. D. Demaine and M. L. Demaine. Recent results in computational origami. In Thomas Hull, editor, Origami3 : Third International Meeting of Origami Science, Mathematics and Education, pages 3–16, Natick, Massachusetts, 2002. A K Peters, Ltd.

24 5. J. Fastag. egami: Virtual paperfolding and diagramming software. In Proceedings of 4th International Conference on Origami, Science, Mathematics and Education, page 68. 4OSME, 2006. Caltech, Pasadena CA. 6. Google. Google Web Toolkit. http://code.google.com/webtoolkit/, 2006. 7. K. Hammond, A.Al Zain, G. Cooperman, D. Petcu, and P. Trinder. Symgrid: A framework for symbolic computation on the grid. In A.M. Kermarreca, L. Bouge, and T. Priol, editors, Proceedings of Parallel and Distributed Computing, EuroPar, volume 4641 of LNCS, pages 447–456. Springer-Verlag, Berlin, 2007. ISSN 03029743. 8. K. Hatori. K’s origami: Origami construction. http://origami.ousaan.com/library/conste.html, 2006. 9. H. Huzita. Axiomatic Development of Origami Geometry. In H. Huzita ed., editor, Proceedings of the First International Meeting of Origami Science and Technology, pages 143–158, 1989. 10. T. Ida, D. T ¸ epeneu, B. Buchberger, and J. Robu. Proving and Constraint Solving in Computational Origami. In Proceedings of the 7th International Symposium on Artificial Intelligence and Symbolic Computation (AISC 2004), volume 3249 of LNAI, pages 132–142, 2004. 11. T. Ida, H. Takahashi, M. Marin, F. Ghourabi, and A. Kasem. Computational construction of a maximal equilateral triangle inscribed in an origami. In Mathematical Software - ICMS 2006, volume 4151 of Lecture Notes in Computer Science, pages 361–372. Springer Berlin / Heidelberg, 2006. 12. T. Ida, H. Takahashi, M. Marin, A. Kasem, and F. Ghourabi. Computational Origami System Eos. In Proceedings of 4th International Conference on Origami, Science, Mathematics and Education, page 69. 4OSME, 2006. Caltech, Pasadena CA. 13. Design Science Inc. WebEQ developers suite. http://www.dessci.com/en/products/webeq/, 2007. 14. A. Kasem, T. Ida, H. Takahashi, M. Marin, and F. Ghourabi. E-origami system Eos. In Proceedings of the Annual Symposium of Japan Society for Software Science and Technology, Tokyo, Japan, 2006. JSSST. 15. A. Kasem, H. Takahashi, M. Marin, and T. Ida. weborigami2 : A system for origami construction and proving using web 2.0 technologies. In Proceedings of the Annual Symposium of Japan Society for Software Science and Technology, Nara, Japan, 2007. JSSST. 16. R. J. Lang. Intersections between origami, mathematics, and science. http://www.langorigami.com/science/science.php4. ORIGAMI website. 17. R. J. Lang. Origami simulation. http://www.langorigami.com/science/origamisim/origamisim.php4. 18. Maplesoft. Maple system. http://www.maplesoft.com/, 2007. 19. J. Mitani. Recognition, modeling and rendering method for origami using 2d bar codes. In Proceedings of 4th International Conference on Origami, Science, Mathematics and Education. 4OSME, 2006. Caltech, Pasadena CA. 20. S. Miyazaki, T. Yasuda, S. Yokoi, and J. Toriwaki. An origami playing simulator in the virtual space. In The Journal of Visualization and Computer Animation, volume 7(1), pages 25–42, January 1996. 21. M. Naifer, A. Kasem, and T. Ida. A system of web services for symbolic computation. In Tetsuo Ida, Qingshan Jiangand, and Dongming Wang, editors, Proceedings

25

22.

23. 24. 25. 26.

27.

of the 5th Asian Workshop on Foundations of Software, pages 145–152. Beihang University, 2007. Xiamen, China. D. Petcu, D. T ¸ epeneu, M. Paprzycki, and T. Ida. Symbolic Computations on Grids. In Beniamino di Martino, Jack Dongarra, Adolfy Hoisie, Laurence Yang, and Hans Zima, editors, Engineering The Grid: status and perspective, chapter 6, pages 91–107. American Scientific Publishers, ISBN: 1-58883-038-1, January 2006. W3C Technical Reports. The xmlhttprequest object. http://www.w3.org/TR/XMLHttpRequest, 2007. Wolfram Research. webMathematica 2. http://www.wolfram.com/products/webmathematica, 2006. Wolfram Research. Mathematica. http://www.wolfram.com/products/mathematica/, 2007. SINGULAR team. SINGULAR computer algebra system. http://www.singular.uni-kl.de/index.html, 2007. Department of Mathematics of the University of Kaiserslautern. Wikipedia website. Ajax (programming). http://en.wikipedia.org/wiki/Ajax %28programming%29, 2007.