軟件工程外文英文文獻翻譯面向邏輯框架的WEB編程

《軟件工程外文英文文獻翻譯面向邏輯框架的WEB編程》由會員分享，可在線閱讀，更多相關《軟件工程外文英文文獻翻譯面向邏輯框架的WEB編程（17頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、 單位代碼 01 學 號070112058 分 類 號 TP393

2、 密 級____ ___ _ 文獻翻譯 面向邏輯框架的WEB編程 院（系）名稱 信息工程學院 專 業(yè) 名 稱 軟件工程 學 生 姓 名 指 導 教 師 黃河科技學院畢業(yè)設計(文獻翻譯) 第 7 頁 英文譯文 面向邏輯框架的WEB編程 朱利奧，安德里亞，恩里科 摘 要 萬維網(wǎng)作為一個開發(fā)平臺盡管流行，但是設計一個恰當描述它的結構原則和設計標準被確立僅僅在過去十年里，通過引入代表性的狀態(tài)轉換構造風格，其定義了以資源為核心的抽象信息。被用的語言和

3、工具作為 Web 程序規(guī)劃，通常很難理解缺乏適當它的結構和設計的拘束，從抽象不匹配，使其難以充分利用網(wǎng)絡的潛力。 敘述式語言適當?shù)臑榫幊滔到y(tǒng)瞄準一個的合適網(wǎng)絡架構和原理。在邏輯技術中，tuProlog 已經(jīng)明確地被設計是以英特網(wǎng)為基礎的基礎設施的促成元件之一:其工程特性在web,在運行時間內允許適當?shù)男薷倪壿嬀幊藤Y源。因此，本文中我們提出一個開發(fā)基于這個模型的設計Web資源和概述一個框架web應用程序的 Prolog的邏輯模型。 關鍵字：萬維網(wǎng)，語境，tuProlog，Prolog 1 介紹 盡管流行的網(wǎng)絡平臺的開發(fā)和實現(xiàn)多以互聯(lián)網(wǎng)為基礎的系統(tǒng)，但設計了一個恰當?shù)拿枋鼍W(wǎng)站的設計原則和

4、建筑標準僅僅在過去十年里已經(jīng)達到，通過引入代表性的狀態(tài)轉換(其他)結構風格為超媒體系統(tǒng)[1]。以其他資源為重點，定義了抽象的信息溝通和互動,規(guī)定在資源發(fā)生時，通過一致的接口轉換代表性的資源現(xiàn)狀。 然而,從早期程序上的CGI腳本到現(xiàn)代的面向對象的框架，web應用程序編程一直集中在不同的抽象概念上，如頁面[6]、控制器[15]和最近的服務器[11]，從而面對不協(xié)調，使得很難開發(fā)可能的網(wǎng)站結構特性。事實上，一個網(wǎng)頁是計算涉及一個或更多資源的結果，并且處理結果僅僅在表現(xiàn)問題的客戶端；另一方面，一個控制器恰好是(僅僅)一個程序框架的抽象，共享幾乎沒有任何其潛在的網(wǎng)絡平臺。相反，忽視網(wǎng)絡標準如URI和H

5、TTP，因此他們從不獲得利益而言，其余架構依據(jù)可緩存性、連通性、可尋址行、一致性和互操作性[14]。 作為一個事實, 聲明程序設計在網(wǎng)絡邏輯語言的主流中從未被接受，盡管研究人員表示他們能有效地處理基于網(wǎng)絡環(huán)境[1]的溝通和協(xié)調和邏輯技術已經(jīng)成功用于智能設計元件為核心的網(wǎng)絡基礎設施[2]。然而，其余的集中在以資源再現(xiàn)為主要驅動的相互作用，并給出了相應的網(wǎng)絡計算模型，在架構以資源為目標的應用程序中聲明語言能發(fā)揮了重要的作用。利用元素的優(yōu)勢從邏輯編程語言比如Prolog既有代表性的基礎網(wǎng)絡計算模型：一個資源的聲明可以被操作，在子句開始并給出了程序的解釋，在資源涉及到運算時直接被解釋器執(zhí)行。 在本

6、文中，我們討論一個資源編程模型、Web邏輯編程(WebLP)[13]，把與元素與之相適應的邏輯范例和邏輯技術相結合 (例如tuProlog引擎[2])，來定義一個Web應用程序框架釋放快速原型當支持網(wǎng)絡架構特性比如可擴展性和可變性。 2 WEB邏輯編程 WEB邏輯編程(WebLP)[13]是一種基于Prolog的邏輯模型，其應用于系統(tǒng)約束的萬維網(wǎng)架構的交互作用。 起初網(wǎng)絡邏輯編程描述的事其主要的數(shù)據(jù)類型抽象，然后定義它的計算模型。 2.1 資源 定義了一個資源，為任何其他概念的目標的超鏈接文本。任何信息，那可命名為是一種資源，包括虛擬(如文件)及不是實質上(例如一個人)的物體。從如

7、此抽象的定義、主要性質的資源可以很容易地確定：一個名字(URI的形式)；數(shù)據(jù)代表著資源狀態(tài)和行為，以用來改變的狀態(tài)或管理與企業(yè)的其他資源的交互作用。在界定的資源可以輕易的將元素映射到元素的邏輯編程語言，比如Prolog：對于每個資源R，其名稱N(R)可以被指定為單一資源的URI引用原子含有標識符，當數(shù)據(jù)和行為可以進一步確認為事實和規(guī)則，分別在一個邏輯理論T(R)包含了知識庫相關資源。 特別地,如果它是描述性的名字，采用資源在可預知的方式[14]中有明確的結構變化，它們有一個共同的特征是一個有趣的特性，對他們自己的：任何路徑，可以解釋為包括一套資源的名稱。證明這條線，我們說一個資源的名字，如：

8、 http : // 涵蓋的其他資源的名字——也就是說，那些可能相關的項目包括提高子路徑域的根源URI: http : // http : // http : // We denote this by writing: N(R) ? N(R1) ? . . . ? N(Rn) 每個N(Ri)是指相應的資源Ri。 這個命名結構強調資源并不是孤立的，而是在一個信息化環(huán)境中由資源相關資源的名字里面的名字。 為了說明網(wǎng)絡計算的復雜性，可能涉及的信息比它是封閉在一個隔離資源更多，上下文C(R)介紹了消失的計算與相關各資源。這樣一個背景下，然后是定義所組成的理論與之相關聯(lián)的名字是資源與

9、資源的名字里面的理論，包括與之關聯(lián)的資源本身。 因此，比如，上下文C(R)向關聯(lián)的表示以上資源R命名為N(R)產(chǎn)生： C(R) = T (R) · T (R1) · . . . · T (Rn) 任何理論T(Ri)，含有知識庫相關資源的Ri，可以為空——例如，當沒有實體實際上有關的名字N(Ri)。 2.2 計算模型 根據(jù)WEB計算模型圍繞交易的HTTP協(xié)議。每個事務都從一個請求開始，含有WEB計算的兩個主要成份：方法信息，表明寄件人如何期望接收器處理應用，范圍信息，表明部分數(shù)據(jù)集接收器將申請方法[14]。該方法在Web中，信息都包含在這HTTP請求的方法(例句GET, POST)和

10、范圍的信息資源的URI是要定向請求。 網(wǎng)絡計算的結果是一種響應，告知請求成功或失敗，隨機包含表示新狀態(tài)的目標資源。 采用一種邏輯編程計算模型，每個網(wǎng)絡 HTTP協(xié)議的要求可以被解釋為一個推論信息映射到目標的范圍和方法理論，信息發(fā)布到了一個適當?shù)倪壿嬆繕?。然后，計算在服務器端發(fā)生HTTP協(xié)議，在語義中聯(lián)系目標資源的請求。目標信息的解決方案是造成最終翻譯轉化為一個合適的陳述，返回HTTP響應。 它允許用戶調用它，而目標計算的一種資源R觸發(fā)G的演繹成G對語境C(R)。這篇構圖的理論形成C(右)然后經(jīng)過一個非常類似的方式作為單位在語境的邏輯編程(CtxLP)中[9]。目標G依次詢問每個理論: 如

11、果沒有找到任何理論解答，這個目標失敗，或一旦解決了利用知識庫中的一種理論T(國際扶輪)則成功。 此外，在理論中當目標G被子目標替換成相匹配的規(guī)則，計算所得的理論從C(Ri)而不是從最初的上下文被重新啟動。這一現(xiàn)象的原因可能的選擇是，如果計算已達到C(Ri)，必要的信息以繼續(xù)進行，最有可能出現(xiàn)在別的任何地方——因為它是典型的假定語境邏輯編程[8]；然而，不同的操作(例如，延遲綁定策略)需要的時候也可以很有用。 例如,讓我們考慮一個書架共享應用,在用戶jdoe的書架是由URI確定 books/1最終是調用在B當一個獲取請求簽發(fā)這個資源。 如果斷定挑選取biology books/1依賴于選擇

12、books/3確定是拿書在B或是S，理論上是C(B)越過向后的資源，作為描述，如圖1，在那里一個合適的定義來取books/3并最終找到。根據(jù)上述(期望)策略，定義為其他屬性調用然后從上下文的根源，而不是C(B)，在該計算最初開始。 圖1書架上的jdoe/shelf/biology得到響應HTTP請求而最終調用選biology book/1，依次挑選書籍books/3。語境是直到恰當定義，因為它是發(fā)現(xiàn)——在這里，在這個/資源。 值得注意的是，無論如何，不像語境邏輯編程，它可能將或流行單位在運行時從上下文堆棧，固定結構的URIs為資源標識符使組成的理論形成了一個上下文是靜止的。此外，結構的

13、標識符、資源的網(wǎng)絡架構的高低決定了獨特的方向理論的相關資源組成了一個上下文可以穿越——那就是，從最外層(與之關聯(lián)的資源在計算已被調用)到最深處，經(jīng)過理論屬于每個組成資源,直到主資源是最后參與。 2.3 動態(tài)資源特性 資源特性動態(tài)下可以看作是兩個獨立的方面。首先，兩個或兩個以上的URIs可以表示在任何時間相同資源的聯(lián)系：即名字為N1(R)、…，Nm(R)可確定為同一資源R，因此同樣的知識庫中包含T(R)相關理論的資源。每一個不同的名字的Ni(R)也用來識別不同環(huán)境下的Ci(R)，同一資源R可能經(jīng)歷在里面(見圖2)，因此，判斷應用于T(R)但未定義行為有可能以不同的方式給出定義，通過上下文資

14、源是訪問。 圖2邏輯理論問題的一種資源代表銷售額為2004年第四季度的可被兩個不同的名字識別，因此住進兩個不同的上下文環(huán)境。 第二個動態(tài)方面的資源來自于行為規(guī)則的表達能力，一個邏輯編程語言的抽象：一方面，眾所周知邏輯機制規(guī)定操作(the assertz/1 and retract/1判斷)可以被利用，改變知識庫的相關資源；另一方面，HTTP協(xié)議本身通過PUT請求的方法允許改變一個資源，其內容應考慮作為一種經(jīng)過改良的目標資源來代替(或合并)最初版本居住在服務器上的資源。 例如，讓我們想象一個閱讀期望列表在之前的書架上的應用。通常，當新增加一本書，該資源代表著希望的列表可以檢查當?shù)貓D書館

15、的圖書的有效性，并可能借它用戶的身份：如果沒有找到書，這個資源可以檢查其在網(wǎng)上書店可用性、應為用戶將來采購報告其價格。然而，在銷售時間，當一個網(wǎng)上書店提供折扣，期望清單資源應該對插入的新書首先檢查儲存。 實現(xiàn)這種功能，網(wǎng)絡應用程序然后能被指導去改變行為的期望清單資源的請求，簽發(fā)HTTP把修改計算表示這些資源。這將要求將進行新規(guī)則的內容，所以期望清單會修改他們的知識庫資源進行相應的調整。應用終于可以恢復舊的行為結束的時候，折扣期限內發(fā)送另一個程序中含有以前把要求每一個愿望清單規(guī)則集的資源。 3 tuProlog：邏輯控制技術對網(wǎng)頁 tuProlog[3]是一個最小的基于Java的系統(tǒng)，明

16、確設計整合可配置的和可擴展的Prolog成分，在標準的網(wǎng)絡應用程序中，并被用來作為核心技術提供基本協(xié)調能力成為復雜的網(wǎng)絡基礎設施[2]。除了配置性和可擴充性，tuProlog是專為特寫的其他工程性質,特別適合于分布式系統(tǒng)架構——那就是，解除部署、輕盈和互操作性的標準操作規(guī)程(按照RMI，CORBA，TCP/IP)。這些特性是與構建屬性描述相匹配，使tuProlog成為一個好的候選的核心推理機來處理資源計算和它們之間的相互作用。 為了支持WebLP框架，一個tuProlog引擎將需要是有著概念可擴展(及相關運算符)類似于邏輯脈絡，由于各種實現(xiàn)技術的存在，他們從最小的嵌入解釋元虛擬機來有效提高。

17、在記憶中有這樣一個目標，tuProlog重新設計在過去幾年來有效地支持延展性[12]，特別重要的是在允許一臺輕量級Prolog重要技術來擴展具有相似緩解Prolog要素的執(zhí)行模型可擴展的純語言方面。 全面整合tuProlog Prolog和Java之間的特點是另一種關鍵方面，由于可以使所有的Java技術立即可得到WebLP開發(fā)框架。例如，現(xiàn)有的Apache Tomcat網(wǎng)絡服務器/容器可以作為一個多線程有效平臺開發(fā)整合tuProlog，以至于開發(fā)組件的生命周期的管理和HTTP統(tǒng)一的接口實現(xiàn)。JavaServer page是另一個可擴展技術，這種技術能被利用來生產(chǎn)資源陳述只限在客戶端網(wǎng)絡應用程

18、序。 Java/servlets，相反，構成一個有趣的反例，他們由于不相匹配的抽象和其余的構造風格：事實上，Java/servlets用作于申請控制器被排除或重復用于不同的目的(例如僅僅作為HTTP調度程序)。 4 相關的問題和進一步的工作 使用Prolog，而比較普遍的是描述性語言，在過去幾年中網(wǎng)絡已經(jīng)被開發(fā)應用于各個方面[7]，從大范圍的語義網(wǎng)(包括OWL/RDF處理,格式翻譯等等)，到GUI框架設計[5、10]。然而，使用Prolog框架內的網(wǎng)絡技術覆蓋的看起來相當少——一個最近期的現(xiàn)有貢獻[16],提出了一個架構是相通的,其他的Prolog部件在網(wǎng)絡應用程序通過HTTP、支持語法

19、分析,描述和產(chǎn)生大型的HTML,XMLand RDF文件,包括語義網(wǎng)RDF加工。 因此,我們的計劃,進一步發(fā)展WebLP框架, 通過擴展的編程模型的基礎上，建立起某種經(jīng)驗進行測試的應用程序，并完成了其實現(xiàn)tuProlog編程框架。 摘自：朱利奧，安德里亞，恩里科. 面向邏輯框架的WEB編程.人工智能5 (2011) 151–155 DOI 10.3233/IA-2011-0019 IOS出版社， 2011.5 黃河科技學院畢業(yè)設計(文獻翻譯) 第 16 頁 附：英文原文 Towards a logic framework for Web Pro

20、gramming Giulio Piancastellia, Andrea Omicinia and Enrico Dentib,? aAlma Mater Studiorum-Universit`a di Bologna, Cesena, Italy bAlma Mater Studiorum-Universit`a di Bologna, Bologna, Italy Abstract. Despite the popularity of the World Wide Web as a development platform, a proper description of it

21、s architectural principles and design criteria has been established only in the last decade, by the introduction of the REpresentational State Transfer (REST) architectural style, which defines the resource as the key abstraction of information. Languages and tools used for Web programming generally

22、 suffer from a lack of proper understanding of its architecture and design constraints, and from an abstraction mismatch that makes it hard to fully exploit the Web potential. Declarative languages are well-suited for a programming system aimed at being respectful of the Web architecture and princi

23、ples. Among logic technologies, tuProlog has been explicitly designed to be one of the enabling components of Internet-based infrastructures: its engineering properties make it suitable for use on the Web, where logic programming allows modification of resource behaviour at runtime. Accordingly, in

24、this paper we present a Prolog-based logic model for programmingWeb resources, and outline a framework for developing Web applications grounded on that model. Keywords: World Wide Web, REST, Contextual Logic Programming, tuProlog, Prolog 1. Introduction Despite the popularity of the Web platform

25、for the development and fruition of many kinds of Internetbased systems, a proper description of the Web architectural principles and design criteria has been achieved only in the last decade, by the introduction of the REpresentational State Transfer (REST) architectural style for hypermedia system

26、s [4]. REST defines the resource as the key abstraction of information,and prescribes communication and interaction among resources to occur through a uniform interface by transferring a representation of a resource current state. Yet, from the early years of procedural CGI scripts to the modern da

27、ys of object-oriented frameworks, Web application programming has always focussed on different abstractions, such as page [6], controller [15],and more recently service [11], thus suffering from a mismatch that has made it difficult to exploit the full potential of the Web architectural properties.

28、In fact, a page is just the result of a computation involving one or more resources, and deals only with representation issues on the client side; on the other hand, a controller happens to be (just) a programming framework abstraction, sharing almost nothing with the underlying Web platform. Servic

29、es, in their turn, disregard Web standards such as URI and HTTP, so they do not get the benefits of the REST architecture in terms of cacheability, connectedness, addressability, uniformity, and interoperability [14]. As a matter of fact, declarative programming has never been accepted into the Web

30、 mainstream, even though logic languages have shown they could effectively handle both communication and co-ordination in a network-based context [1], and logic technologies have been successfully used to engineer intelligent components at the core of Internet-based infrastructures [2]. However, the

31、 REST focus on resource representations as the main driver of interaction, and the corresponding Web computational model, suggest that declarative languages could play a significant role in the construction of resource-oriented applications. The advantage of using elements from logic programming lan

32、guages such as Prolog lies in the representational foundations of theWeb computational model: a declarative representation of resources may be manipulated and, given the procedural interpretation of Prolog clauses, directly executed by an interpreter when a resource is involved in a computation. In

33、 this paper, we discuss a resource programming model, Web Logic Programming (WebLP) [13], which puts together elements of the logic paradigm with suitable logic technologies (i.e., the tuProlog engine [2]), to define a Web application framework easing rapid prototyping while supportingWeb architectu

34、ral properties such as scalability and modifiability. 2. Web Logic Programming Web Logic Programming (WebLP) [13] is a Prologbased logic model to program resources and their interaction in application systems following the constraints of the World Wide Web architecture. Describing WebLP amounts at

35、 first characterising its main data type abstraction, then defining its computational model. 2.1. Resources REST defines a resource as any conceptual target of a hypertext reference. Any information that can be named can be a resource, including virtual (e.g. a document) and non-virtual (e.g. a pe

36、rson) objects. Starting from such an abstract definition, the main properties of resources can be easily determined: a name (in the form of an URI); data, representing the resource state; and behaviour, to be used to change the state or manage the interaction with other resources. The defining eleme

37、nts of resources can be easily mapped onto elements of logic programming languages such as Prolog: for each resource R, its name N(R) can be specified as the single quoted atom containing the resource URI identifier, while data and behaviour can be further recognised as facts and rules, respectively

38、, in a logic theory T (R) containing the knowledge base associated to the resource. In particular, if the resource names adopted are descriptive and have a well-defined structure varying in predictable ways [14], they feature an interesting property on their own: any path can be interpreted as incl

39、uding a set of resource names. Following this line, we say that a resource name such as: http : // encompasses the names of other resources – namely, those possibly associated to the included sub-paths –up to the domain at the root of the URI: http : // http : // http : // We denote this by wr

40、iting: N(R) ? N(R1) ? . . . ? N(Rn) where each N(Ri) denotes the name of the corresponding resource Ri. This naming structure highlights that resources do not live in isolation, but in an information context composed by the resources associated to the names encompassed by the resource name. In o

41、rder to account for the possible complexity of Web computations that may involve more information than it is enclosed in a single isolated resource, the context C(R) is introduced as the locus of computation associated with each resource. Such a context is then defined by the composition of the theo

42、ries associated with the resources linked to names which are encompassed by that resource name, including the theory associated with the resource itself. So, for instance, the context C(R) associated to the above resource R named N(R) is generated as: C(R) = T (R) · T (R1) · . . . · T (Rn) Where

43、any theory T (Ri), containing the knowledge base associated to the resource Ri, can be empty – for instance when there is no entity actually associated to the name N(Ri). 2.2. Computational model According to REST, the Web computational model revolves around transactions in the HTTP protocol. Each

44、 transaction starts with a request, containing thetwo key elements of Web computations: the method information, which indicates how the sender expects the receiver to process the request, and the scope information, which indicates on which part of the data set the receiver should apply the method [1

45、4]. On theWeb, the method information is contained in the HTTP request method (e.g. GET, POST), and the scope information is the URI of the resource to which the request is directed. The result of a Web computation is a response, telling whether the request has been successful or not, and optionally

46、 containing the representation of the newstate of the target resource. Adopting a logic programming viewof theWeb computational model, each HTTP transaction request can be interpreted as a deduction by mapping the scope information onto the target theory, and the method information onto a proper lo

47、gic goal. Then, the computation takes place on the server side of the HTTP transaction, in the context associated to the resource target of the request. The information resulting from goal solution is finally translated again into a suitable representation and sent back in the HTTP response. A comp

48、utation invoked by a goal G on a resource R triggers the deduction of G on the context C(R). The composition of theories forming C(R) is then traversed in a very similar way as units in Contextual Logic Programming (CtxLP) [9]. The goal G is asked in turn to each theory: the goal fails if no solutio

49、n is found in any theory, or succeeds as soon as it is solved using the knowledge base in a theory T (Ri). Furthermore, when the goal G is substituted by the subgoals of the matching rule in the theory, the computation proceeds from C(Ri) rather than being restarted from the original context. The r

50、eason for this choice is that, if the computation has reached C(Ri), the necessary information to proceed is most likely found there than anywhere else – as it was typically assumed in Contextual Logic Programming [8]; however, different operators (for instance, for late binding policies) could also

51、 be used whenever needed. As an example, let us consider a bookshelf sharing application, where user jdoe’s shelf is identified by the URI let us call this shelf resource S. Let us also suppose that the resource B for biology books lives at /jdoe/shelf/biology, and that predicate pick biology book

52、s/1 is ultimately invoked on B when a GET request is issued for that resource. If predicate pick biology books/1 depends on a pick books/3 predicate that is neither defined inB nor in S, the theory chain inC(B) is traversed backwards up to the resource, as depicted in Fig. 1, where a suitable defi

53、nition for pick books/3 is finally found. According to the above-stated (eager) policy, definitions for other predicates invoked by it are then searched starting from the context of the root resource, rather than C(B) where the computation originally started. Fig. 1. The /jdoe/shelf/biology resou

54、rce responds to a HTTP GET request by eventually invoking the pick biology book/1 predicate, which in turn calls pick books/3. The context is traversed until a proper definition for it is found – here, in the / resource. It should be noted, however, that unlike Contextual Logic Programming, where i

55、t was possible to push or pop units from the context stack at runtime, the fixed structure of URIs as resource identifiers makes the composition of theories forming a context static. In addition, the structure of identifiers and resources in the Web architecture also dictates a unique direction in w

56、hich the theories associated to resources composing a context can be traversed – that is, from the outermost (associated with the resource on which the computation has been invoked) to the innermost, passing through the theories belonging to each of the composing resources, until the host resource i

57、s finally involved. 2.3. Dynamic resource behaviour The behaviour of a resource can be regarded as dynamic under two independent aspects. First, two or more URIs can be associated to the same resource at any time: that is, the names N1(R), . . . , Nm(R) may identify the same resource R, thus the s

58、ame knowledge base contained in the theory T (R) associated to the resource. Each different name Ni(R) also identifies a different context Ci(R) that the same resource R may live within (see Fig. 2); therefore, predicates that are used in T (R) but not defined there may behave in different ways base

59、d on the definition given by the context where the resource is called. The second dynamic aspect of a resource comes from the ability to express behavioural rules as firstclass abstractions in a logic programming language: on the one hand, well-known logic mechanisms for state manipulation (the a

60、ssertz/1 and retract/1 predicates) can be exploited to change the knowledge base associated to a resource; on the other, the HTTP protocol itself allows changing a resource by means of a PUT request, whose content should be considered as a modified version of the target resource that has to replace

61、(or be merged with) the original version residing on the server. Fig. 2. The logic theory of a resource representing sales for the fourth quarter of 2004 can be identified by two different names and therefore live in two different contexts. As an example, let us imagine a reading wish list in the

62、 previous bookshelf application. Usually, when a book is added, the resource representing the wish list could check local libraries for book availability, and possibly borrow it on user’s behalf; if no book can be found, the resource could check its availability in online bookstores, reporting its p

63、rice to the user for future purchase. However, during sales periods, when an online bookstore offers discounts, the wish list resource should react to the insertion of new books to check that store first. To implement this behaviour, the Web application could then be instructed to change the behavi

64、our of wish list resources by issuing HTTP PUT requests that modify the computational representation of those resources. The PUT requests would carry the new rules in the content, so that wish list resources would modify their knowledge base accordingly. The application could finally restore the old

65、 behaviour at the end of the discount period programmatically, by sending another PUT request containing the previous rule set for each wish list resource. 3. tuProlog: Logic technology for the Web tuProlog [3] is a minimal Java-based system explicitly designed to integrate configurable and scalable Prolog components into standard Internet applications, and to be used as the core enabling technology for the provision of basic coordination capabilities into complex Internet-based infra