A LOGIC PROGRAMMING MODEL FOR WEB RESOURCES

Giulio Piancastelli and Andrea Omicini

ALMA MATER STUDIORUM – Universit`a di Bologna, via Venezia 52, 47037 Cesena, FC, Italy

Keywords:

Representational State Transfer, Resource-Oriented Architecture, Contextual Logic Programming, Prolog.

Abstract:

In the latest years, substantial achievements have been obtained in the description and formalization of the

architectural principles and design criteria underlying the World Wide Web. First, the Representational State

Transfer (REST) architectural style for distributed hypermedia systems was introduced, deﬁning the resource

as the key abstraction of information; then, the Resource-Oriented Architecture (ROA) was presented as a

REST-based set of guidelines and best practices for implementing services on Web resources. However, a

resource programming model is still missing, since procedural and object-oriented web programming fo-

cussed on different abstractions, such as page, controller, and service. Instead, we adopt the logic declarative

paradigm to deﬁne our model for resource-oriented programming, also showing how its peculiar features lead

to novel possibilities for dynamic modiﬁcation and extension of resource behavior at runtime. In this pa-

per, we ﬁrst map novel REST and ROA abstractions onto elements of structured logic programming. Then,

we present Web Logic Programming as a Prolog-based language for the World Wide Web embedding the

core REST and ROA principles, by deﬁning its computation model and discussing a bookshelf sharing web

application example.

1 INTRODUCTION

Despite the World Wide Web being increasingly used

as a successful platform for open distributed sys-

tems of heterogeneous nature, a proper description,

understanding, formalization, and divulgement of its

architectural principles and design criteria has been

achieved only recently. In the latest years, ﬁrst the

Representational State Transfer (REST) architectural

style for distributed hypermedia systems was intro-

duced (Fielding, 2000); then, the Resource-Oriented

Architecture (ROA) was presented as a REST-based

set of guidelines and best practices for implement-

ing services that exploit the full potential of the Web

(Richardson and Ruby, 2007). Both REST and ROA

focussed on the resource as the main data abstraction,

deﬁned as any conceptual target of a hypertext ref-

erence; they also prescribed communication amongst

resources to happen through a uniform interface by

transferring a representation of a resource’s current

state.

However, a resource programming model is still

missing. From the early years of procedural CGI

scripts to the modern days of object-oriented frame-

works and platforms, web application programming

focussed on abstractions such as page (Lerdorf et al.,

2006), controller (Thomas et al., 2006), and more re-

cently service (Alonso et al., 2003), which are differ-

ent in nature from resources, despite seldom sharing

some similarities. Instead, the World Wide Web com-

putation model and the REST focus on resource rep-

resentations as the main driver of interaction suggest

that declarativelanguagescould play a signiﬁcant role

in the construction of resource-oriented applications.

We adopt the logic declarative paradigm to de-

ﬁne our model for resource-oriented programming

for three main reasons. First, the mapping between

logic programming elements and the World Wide

Web computation model is natural and straightfor-

ward. Then, the foundational idea of treating pro-

grams as data, leading to resource representations

that are directly executable, allows the abstractions

to stay simple without reducing their expressiveness

and computational power. Finally, this verysame idea

opens the novel possibility for dynamic modiﬁcation

and extension of resource behavior at runtime.

The purpose of our research is to build a logic

framework for engineering web applications, design-

158

Piancastelli G. and Omicini A. (2008).

A LOGIC PROGRAMMING MODEL FOR WEB RESOURCES.

In Proceedings of the Fourth International Conference on Web Information Systems and Technologies, pages 158-164

DOI: 10.5220/0001524501580164

 SciTePress

ing it so as to frame it within the principles and con-

straints of the World Wide Web architectural style. In

this paper, we ﬁrst recall WWW concepts that are rel-

evant to our resource programming model. Then, we

show how to map those concepts onto elements of

structured logic programming (Monteiro and Porto,

1993; Brogi et al., 1994; Bugliesi et al., 1994) accord-

ing to REST and ROA principles. Finally, based on

this mapping, we present the ﬁrst fundamental brick

of a logic web framework in terms of a logic language

extension speciﬁc to the domain of web applications,

named Web Logic Programming (WebLP). Notewor-

thy programming examples from a bookshelf sharing

application are delivered through the whole paper.

2 CONCEPTS AND PROPERTIES

OF REST AND ROA

The Representational State Transfer style (Fielding,

2000) is an abstraction of the architectural elements

within a distributed hypermedia system. The princi-

pal data element and key abstraction of information

is characterized as a resource: any conceptual target

of a hypertext reference. Any information that can

be named can be a resource, including a document,

an image, a temporal service, a collection of other re-

sources, and a non-virtualobject (e.g. a person). More

precisely, a resource is a conceptual mapping to a set

of entities, not the entity that corresponds to the map-

ping at any particular point in time. Each resource

is further identiﬁed by a unique name, used to refer-

ence to the entities involved in an interaction amongst

componentsof a hypermediadistributed system archi-

tecture. It should be noted that, even in the context of

the Web, the REST style only deals with the abstract

deﬁnitions of a resource and its external representa-

tions, imposing constraints on the uniform interface

of resources whilst leaving the implementation of in-

formation sources free for the web application devel-

oper to design.

The Resource-Oriented Architecture, nomen

omen, recognizes resources, identiﬁers, and represen-

tations as key concepts to designing web applications

respectful of the REST architectural style constraints

(Richardson and Ruby, 2007). The most interesting

novel ROA proposal is that a resource and its Uni-

form Resource Identiﬁer (Berners-Lee et al., 1998)

ought to have an intuitive correspondence; in other

words, that URIs should be descriptive. According

to ROA best practices, identiﬁers should also have

a deﬁnite structure, and that structure should vary

in predictable ways. This addressability property of

web applications is accompanied by the connected-

ness property, that is the quality of resources to be

linked to each other in meaningful ways, so as to

follow REST’s prescription to exploit hypermedia as

the engine of the application state (Fielding, 2000).

Also in the case of ROA, as it has been noted for

REST before, the architectural guidelines do not

impose any sort of constraint on the engineering of

resource systems.

According to REST and ROA, the World Wide

Web computation model revolves around transac-

tions in the HyperText Transfer Protocol (HTTP), a

document-orientedprotocolaimed at transferring rep-

resentationsof a resource current state (Fieldinget al.,

1999). Each transaction starts with a request; the re-

quest contains the two key elements of web compu-

tations: the method information, that indicates how

the sender expects the receiver to process the request,

and the scope information, that indicates on which

part of the data set the receiver should operate the

method (Richardson and Ruby, 2007). On systems re-

spectful of REST principles, the method information

is contained in the HTTP request method (e.g. GET,

POST, PUT, DELETE), and the scope information is

the URI of the resource to which the request is di-

rected. Computations, then, happen on the receiving

side of the HTTP transaction, where the resource that

is the request target needs to perform the operation

represented by the method information. The result of

a web computation, triggered by the HTTP transac-

tion, is a HTTP response, telling whether the request

has been successful or not. Typically, the most signiﬁ-

cant HTTP responses contain the representation of the

target resource new state as the result of the computa-

tion.

3 FROM RESOURCES TO

CONTEXTS

Starting from the abstract deﬁnitions described in

Section 2, the main properties of resources can be im-

mediately identiﬁed: resources have a name, which in

the case of the World Wide Web is a unique

iden-

tiﬁer as deﬁned by the URI standard (Berners-Lee

et al., 1998); resources have data representing their

state; and resources have behavior, to perform actions

such as changing their state and building up their rep-

The uniqueness is to be intended in the sense that the

same identiﬁer cannot be associated to two or more re-

sources at the same time; however, more than one name

can identify the same resource at any point in time. For

example (Richardson and Ruby, 2007), the sales numbers

available at

http://example.com/sales/2004/Q4

might

also be available at

http://example.com/sales/Q42004

A LOGIC PROGRAMMING MODEL FOR WEB RESOURCES

159

resentations, or to manage interaction with other re-

sources. In particular, when carefully designed fol-

lowing the ROA best practices about structure and

predictability, resource names feature an interesting

property on their own: each name typically encom-

passes the names of other resources, and ultimately

the name of the resource associated with the domain

at the root of the URI. For example, given a bookshelf

sharing application, the name of the resource identi-

fying a particular book on the shelf of a speciﬁc user:

http://example.com/users/jdoe/shelf/5

encompasses the following names:

http://example.com/users/jdoe/shelf

http://example.com/users/jdoe

http://example.com/users

http://example.com

respectively identifying the list of books (that is, the

shelf) for the

jdoe

user, the

jdoe

user herself, the list

of users in the system, and the web application.

This naming structure suggests that each resource

does not exist in isolation, but lives in an informa-

tion context composed by the resources associated to

the names encompassed by the name of that resource.

Since more than one name can identify the same re-

source, the context of a resource has to be associated

with its name rather than directly with the resource it-

self. Thus, a resource may live in different contexts at

the same time, and feature different behavior accord-

ing to the context where the interaction with other el-

ements of the system takes place.

From the point of view of logic programming,

the properties of web resources can be easily mapped

onto elements of well-known languages such as Pro-

log (Sterling and Shapiro, 1986). For each resource

R we specify its name N(R) as the atom containing

the resource URI identiﬁer; data and behavior can be

further recognized as facts and rules, respectively, in

a logic theory T(R) containing the knowledge base

associated to the resource. In the bookshelf sharing

example, the

http://example.com/users

resource

is the target of HTTP POST requests aimed at creat-

ing new users in the system; as such, its logic the-

ory contains a

create user

rule, declaring the ac-

tions needed to perform the creation of a new user,

and a series of

user

facts, storing data for each user

of the application. The advantage of using logic pro-

gramming elements lies in the representational foun-

dations of the World Wide Web computation model.

The declarative representation of resource data and

behavior as logic axioms can be directly executed by

an inferential interpreter when a resource is involved

in a computation, given the procedural interpretation

of Prolog clauses.

To account for the possible complexity of web

computationsthat may involve more information than

it is enclosed in a single isolated resource, we intro-

duce the contextC(R) as the locus of computation as-

sociated with each resource. Following the sugges-

tions given by ROA best practices with respect to re-

source naming structure, a resource context is deﬁned

by the composition of the theories associated with the

resources linked to names which are encompassed by

the name of that resource, including the theory associ-

ated with the resource itself. Given a resource R with

a name N(R) for which it holds that:

N(R) ⊆ N(R

) ⊆ . . . ⊆ N(R

)

then, the associated context C(R) is generated by the

following composition:

C(R) = T(R)· T(R

) · . . . · T(R

)

where any T(R

) can be empty, for instance when

there is no entity associated to the name N(R

4 WEB LOGIC PROGRAMMING

Web Logic Programming (WebLP) is a language to

programresources, as thekey abstractionof the World

Wide Web, and their interaction, in application sys-

tems following the Resource-Oriented Architecture.

After the characterization of the structure of our main

data type offered in Sect. 3, we now need to deﬁne the

resource computation model underlying the language,

while maintaining compatibility with the constraints

of the REST architectural style (Fielding, 2000).

A computation in logic programming is a de-

duction of consequences of a set of facts and rules

deﬁning relationships between entities (Sterling and

Shapiro, 1986). Sets of facts and rules are called

logic theories (also known as knowledge bases), and

logic queries (also called goals) are used to trigger

the application of deduction rules on a theory. An-

swering a query with respect to a theory is determin-

ing whether the query is a logical consequence of the

theory. Queries are also a means of retrieving infor-

mation from a logic theory. A query asks whether a

certain set of relations holds between the entities de-

scribed in the theory. When a querycontains free vari-

ables, the uniﬁcation algorithm at the core of the logic

programming computation model may bound them to

entities that augment the boolean result of a deduction

telling whether the query has been successful or not.

Adopting a logic programming view of the World

Wide Web computation model described in Sect. 2,

for each HTTP transaction the request gets translated

to represent a deductionby retaining the request scope

WEBIST 2008 - International Conference on Web Information Systems and Technologies

160

informationto indicate thetarget set offacts and rules,

and by mapping the request method information onto

a logic goal. Then, the computation takes place on the

receiving side of the HTTP transaction, in the context

associated to the resource target of the request, as al-

ready stated in Sect. 3. Finally, the information result-

ing from goal solution is translated again to a suitable

representation, in order to be sent back as the payload

of the HTTP response. Therefore, to invoke a com-

putation represented by a goal G on a resource R, we

adopt the following syntax:

N(R) : G (1)

which, using logic symbols, can be expressed as:

C(R) ⊢ G (2)

implying the triggering of a query answering process

by means of the application of the deduction rules on

the theories composing the context.

In the bookshelf sharing case study,

a HTTP POST request directed to the

http://example.com/users

resource repre-

sents the invocation of a computation to create a new

user in the system. That request is translated to the

logic query:

’http://example.com/users’:post(Request,

Response,

View)

which, in the successful case, is handled by the fol-

lowing rule, contained in the theory associated to the

http://example.com/users

resource:

post(Request, Response, _) :-

create_user(Request),

param(Request, (user, User)),

user_url(User, Url),

header(Response, (location, Url)),

status(Response, (201, created)).

where

user url/2

is a commodity rule deﬁned in the

application resource.

Being the contextC(R) the composition of a num-

ber of theories, the computation is carried on so that

the query G is asked in turn to each theory. The goal

fails if nosolution is found in any theory; the goalsuc-

ceeds as soon as it is solved using the knowledgebase

contained in a theory T(R

). Furthermore, when the

goal G gets substituted by the subgoals S

(G) of the

matching rule in the theory, the computation proceeds

from the context of the resource R

rather than being

restarted from the original context. The computation

steps can be expressed as follows:

T(R

) ⊢ G (3)

C(R

) ⊢ S

(G) ∧ . . . ∧ S

(G) (4)

As a more elaborated example involving the book-

shelf sharing case study, we consider a computation

on a typical resource pattern that is one of the bases

of modern web applications, involving lists and list

items. When the user

jdoe

is logged in, her shelf

is represented by the S resource, identiﬁed by the

URI

http://example.com/jdoe/shelf

. Each

book is ﬁled under one of more category subjects.

The resource B for biology books, for instance, lives

http://example.com/jdoe/shelf/biology

When a GET request is issued for that resource,

a predicate to pick the list of biology books is

ultimately invoked on B, such as:

pick_biology_books(Books) :-

parent_id(Shelf),

pick_books(Books, Shelf,

category(biology)).

where

parent id/1

is a predeﬁned predicate return-

ing the identiﬁer of the parent resource in the path

of the current context. The

pick books/3

predi-

cate is deﬁned neither in B nor in S, since it is an

application-wide functionality. The theory chain in

the context for B is then traversed backwards up to

the

http://example.com

resource, where a suitable

deﬁnition for

pick books/3

is found:

pick_books(Books, Shelf, category(C)) :-

findall(B, Shelf:book(B), AllBooks),

filter(AllBooks, C, Books).

and works by supposing that the shelf stores books by

means of

book/1

facts. According to the computation

steps expressed in (3) and (4), a working deﬁnition for

the

filter/3

predicate is searched starting from the

content of the

http://example.com

resource rather

than the context of B where the computation origi-

nally started. The ﬁnal representation of the biology

books in the shelf further depends on some informa-

tion stored in the user resource, mapped on the URI

http://example.com/jdoe

: for example, the name

of the user, and a setting to decide how the book view

is ordered.

Contexts as compositions of theories can be

seen as having a layered structure. The deﬁnition

of a generic computation G as given in (2), (3),

and (4) dictates a unique direction in which those

layers can be traversed: from the outermost (the

theory associated with the resource on which the

computation has been invoked) to the innermost,

passing through the theory belonging to each of the

composing resources, as the social bookmarking

computation example shows, passing from the

http://example.com/jdoe/shelf/biology

re-

source to the

http://example.com/

resource ﬁrst

and to the

http://example.com/jdoe

resource

A LOGIC PROGRAMMING MODEL FOR WEB RESOURCES

161

afterwards. It must be noted that the moving direction

strictly follows the path in the URI identifying the

resource context where the computation has started.

Given a resource and its URI, the resource ancestors

in the URI path are always known, because of an

architectural constraint in the naming system of

the World Wide Web; on the contrary, the resource

descendants are unknown, unless it is the resource

itself that stores those data, because of a speciﬁc re-

quirement of a particular web application. Therefore,

the moving direction between theories within the

same context that makes sense to enforce as a default

at the language level is the one coherent with the

WWW architecture, that is the direction following a

resource ancestors up to the root of its path.

The N(R) : G syntax described in (1) is also the

preferred method to invoke a computation on a re-

source external to the path associated with the current

context. Switching context instead of merging pre-

serves the encapsulation of information that the repre-

sentation of resources as separated logic theories en-

courages. The assumption underlying both the Web

and the WebLP system is that resources encompassed

by a single path form a set of entities so strictly re-

lated that they get composed in a new entity called

context, where knowledge sharing and behavioral in-

ﬂuence are favored. Resources external to a context

do not enjoy the same treatment with respect to that

context.

4.1 Dynamic Resource Behavior

The structure of identiﬁers and resources in the Web

architecture simpliﬁes computations in that no need

for a dynamic context augmentation is envisioned.

When a resource R

needs to ask a goal on a resource

i−1

on the same path, it has to invoke that compu-

tation directly on the R

i−1

resource by using the no-

tation described in (1). As a consequence, compu-

tations are self-contained in the context where they

are resolved rather than invoked, making every goal

callable from every resource in the application space,

without performing artiﬁcial inclusion of (or exten-

sion to) the knowledge base of outer resources. The

order in the composition of theories forming a context

imposes the direction of computations within it.

However, the behavior of a resource can be re-

garded as dynamic under two independent aspects.

First and foremost, two or more URIs can be asso-

ciated to the same resource at any point in time: that

is, the names N

(R), . . . , N

(R) may identify the same

resource R, thus the same knowledge base contained

in the theory T(R) associated to the resource. Each

different name also identiﬁes a different context that

the same resource may live within; therefore, predi-

cates that are used in T(R), but are not deﬁned there,

may behave in different ways following the deﬁnition

given by the context where the resource is called to

perform a computation.

The second dynamic aspect of a resource sprouts

from the ability to express behavioral rules as ﬁrst-

class abstractions in a logic programming language:

on one hand, it is thus possible to exploit well-

known stateful mechanisms (e.g. the

assertz/1

and

retract/1

predicates) to change the knowledge base

associated to a resource; on the other hand, the HTTP

protocol itself allows changing a resource by means

of the PUT method, wherein the entity enclosed as

the request payload should be considered as a mod-

iﬁed version of the one residing on the origin server

(Fielding et al., 1999). Hence, it becomes possible to

imagine behavioral changes triggered at runtime not

only from peer resources, but also from external ac-

tors by using the resource uniform interface, accord-

ing to the architectural principles of the Web.

As an example of dynamic resource behavior,

imagine a bookshelf placed alongside of a reading

wish list. Under usual circumstances, when a book

is added to the wish list, the resource representing the

wish list could check local libraries for book avail-

ability, and eventually borrow it on user’s behalf; if

it is not possible to ﬁnd the book, the resource could

check its availability in online bookstores, reporting

its price to the user for future purchase. This behavior

is codiﬁed by the following rules:

check(Book) :- library(L),

available(Book, L), borrow(Book, L), !.

check(Book) :- bookstore(S),

available(S, Book, Price).

Now imagine an online bookstore (e.g. Amazon) of-

fering discounts for a speciﬁc period of time. For that

period, the wish list resource should react to the inser-

tion of new booksso as to check that store ﬁrst instead

of libraries, directly placing an order if the possibly

discounted price is inferior to a certain threshold, and

to avoid checking other online stores. The new behav-

ior, relative to the store offering discounted prices, is

represented by the following rule:

check(Book) :-

available(amazon, Book, Price),

Price < Threshold,

place_order(amazon, Book), !.

The bookshelf sharing web application could then

be instructed to change the behavior of wish list re-

sources on a per user basis by issuing HTTP PUT re-

quests that modify the computational representation

of those resources. Those PUT requests would carry

WEBIST 2008 - International Conference on Web Information Systems and Technologies

162

the new rule and the rule dealing with libraries in the

payload,so that wish list resourceswould accordingly

modify their

check/1

predicate by adopting that new

deﬁnition. The web application could then program-

matically restore the old behavior at the end of the

discount period, by sending another PUT request for

each wish list, with a payload adequately set up to the

check/1

rule set.

Finally, note that, with a proper hierarchy of iden-

tiﬁers, the behavioral changes described in the ex-

ample could also be carried out in an application-

wide fashion, by issuing PUT requests to a root re-

source common to all wish list contexts, and relying

on the WebLP compositional computation model to

have wish list resources ﬁnd the appropriate actions

to perform when a new book is added.

5 RELATED WORKS IN LOGIC

PROGRAMMING

The primary concern of the Web Logic Programming

(WebLP) language was to follow the principles and

capture the key abstractions of the World Wide Web

as described by the REST architectural style (Field-

ing, 2000) and the Resource-Oriented Architecture

(Richardson and Ruby, 2007). We mapped the re-

source abstraction to a logic theory, and maintained

the addressability property by using URIs with the

purpose of identifying theories and labeling queries

to be asked to speciﬁc resources. We respected the

uniform interface and let it access logic theories by

triggering deductions as a means of exchanging in-

formation. Finally, we embraced the connectedness

property by tightly binding together, in the notion of

context, all resources along a single URI path.

The representation of resources as logic theories

has been analyzed at the programming model level;

yet, in the construction of a WebLP framework, that

representationcould just play an intermediate role be-

tween the resource execution environment and the

data persistence system. Resource data could be

stored in a variety of different forms; for this pur-

pose, the use of a deductive database system (Ra-

mamohanarao and Harland, 1994) could also be en-

visioned. However, those systems are almost exclu-

sively based on a restricted logic programmingmodel,

which could be suitable for some particular applica-

tion domains, but neither for the general case of het-

erogeneous web applications, nor for the WebLP ex-

tension of the logic computation model.

Since the resource programming model embodied

in WebLP is rooted in logic programming, we con-

sider most relevant for the remain of the present dis-

cussion to compare it with computation models that

extended the basic logic model described in Sect. 4

with abstractions such as contexts, modules, and ob-

jects. By using contexts as its primary computation

metaphor, the WebLP language is heavily indebted

with previous treatments on the topic, especially Con-

textual Logic Programming (CtxLP) (Monteiro and

Porto, 1993). Despite being a well-known abstrac-

tion, logic programming contexts on the World Wide

Web are a complete novelty, when built on resources

encompassing URIs as in WebLP fashion. Their in-

troduction would have not been possible without the

insights and best practices gathered around the deﬁni-

tion of Resource-Oriented Architecture.

The constraints of the REST architectural style al-

lowed several simpliﬁcations of contexts with respect

to their original deﬁnition. For example, there is no

need of including logic variables in identiﬁers. In

CtxLP, the parameterization of names inﬂuences unit

identiﬁcation and conﬁguration. However, in WebLP

any identiﬁcation problem is already intrinsically re-

solved, since names are already unique for each re-

source without the need for parameters; besides, re-

source conﬁguration mechanisms should be exploited

at the moment of constructing new resources, without

having any impact on the identiﬁcation process.

The requirement for context isolation lets WebLP

also drop many of the characteristics related to logic

modules (SC22, 2000; Brogi et al., 1994; Bugliesi

et al., 1994), which were extensively used by CtxLP.

The need for a restriction to forbid arbitrary imports

from a resource to any other resources (perhaps exter-

nal to its living context)led us to decide that the subdi-

vision of the application in logic theories correspond-

ing to web resources, and the navigation mechanisms

offered by our notion of context, were good enough

as modularization features for the WebLP language.

Indeed, resources are an abstraction simple

enough to consider WebLP as a radical simpliﬁcation

of CtxLP, when applied to the domain of the World

Wide Web, rather than an extension, such as lan-

guages adding features from concurrency (Mello and

Natali, 1992) or object-orientation (Omicini and Na-

tali, 1994). In particular, resources are not objects in

the object-orientedsense, no more than object method

calls follow message passing in the distributed sys-

tems sense. For instance, the resource abstraction

does not bring any notion of inheritance with itself:

accounting for polymorphism, or adding explicit lazy

and eager binding operators, would have meant to

forcibly superimpose other programming metaphors

on a web-oriented language.

LogicWeb (Loke, 1998) is an example of web-

oriented logic language that predates the simpler

A LOGIC PROGRAMMING MODEL FOR WEB RESOURCES

163

Modular Logic Programming model (Brogi et al.,

1994) without dealing with more complex software

engineering paradigms. LogicWeb is also the web-

oriented logic language most resembling Web Logic

Programming. However, it is designed to be exploited

on the client side of the web: instead of resources,

it models pages as HTML documents, which are but

just one possible representation of a resource; besides,

it unfortunately lacks the insight on the intrinsic rela-

tionship amongst resources encompassed by a single

URI that have been only achieved so recently, and that

have been included in modeling the WebLP language.

6 ONGOING AND FUTURE

WORK

We presented a logic programming language exten-

sion called Web Logic Programming, designed to

model resources, as the key abstraction of the World

Wide Web, and their interaction. WebLP is the

ﬁrst web-oriented logic language to beneﬁt from the

architectural speciﬁcation of hypermedia distributed

systems as described by the Representational State

Transfer style (Fielding, 2000), and from the insights

and principles of the Resource-Oriented Architecture

(Richardson and Ruby, 2007).

The Web Logic Programming language is in-

tended to exploit the full potential of declarative tech-

nologies by representing the foundation of a logic

programmingframework for engineering applications

on the World Wide Web so as to follow its archi-

tectural principles and design criteria. To fulﬁll this

broaderaim, ongoingwork is devoted on the one hand

to achieve a clear integration between the WebLP lan-

guage and Prolog, of which WebLP has been designed

as an extension; on the other hand, to explore the

possible ways of integrating interpreters of logic lan-

guages and server-side web technologies, and to study

suitable patterns of application architecture to lay on

top of the WebLP language.

In the future, more complex web applications

will be constructed, in order to iterate on the frame-

work building process and eventually ﬁnd useful re-

ﬁnements of the WebLP programming model. Ap-

plications will also serve the purpose to both per-

form an expressiveness and usability comparison with

other languages(Lerdorfet al., 2006) and frameworks

(Thomas et al., 2006) now popular in the mainstream,

and showcase the full potential of the novel and pecu-

liar features of Web Logic Programming.

REFERENCES

Alonso, G., Casati, F., Kuno, H., and Machiraju, V. (2003).

Web Services: Concepts, Architectures and Applica-

tions. Springer-Verlag.

Berners-Lee, T., Fielding, R. T., and Mainster, L. (1998).

Uniform Resource Identiﬁers (URI): Generic Syntax.

Internet RFC 2396.

Brogi, A., Mancarella, P., Pedreschi, D., and Turini, F.

(1994). Modular Logic Programming. ACM Trans-

actions on Programming Languages and Systems,

16(3):1361–1398.

Bugliesi, M., Lamma, E., and Mello, P. (1994). Modular-

ity in logic programming. Journal of Logic Program-

ming, 19-20:443–502.

Fielding, R. T. (2000). Architectural Styles and the Design

of Network-based Software Architectures. PhD thesis,

University of California, Irvine.

Fielding, R. T., Gettys, J., Mogul, J., Frystyk, H., Masinter,

L., Leach, P., and Berners-Lee, T. (1999). Hypertext

Transfer Protocol – HTTP/1.1. Internet RFC 2616.

Lerdorf, R., Tatroe, K., and MacIntyre, P. (2006). Program-

ming PHP. O’Reilly.

Loke, S. W. (1998). Adding Logic Programming Behaviour

to the World Wide Web. PhD thesis, University of Mel-

bourne, Australia.

Mello, P. and Natali, A. (1992). Extending Prolog with

Modularity, Concurrency and Metarules. New Gen-

eration Computing, 10(4):335–360.

Monteiro, L. and Porto, A. (1993). A Language for Con-

textual Logic Programming. In Logic Programming

Languages: Constraints, Functions, and Objects. The

MIT Press.

Omicini, A. and Natali, A. (1994). Object-oriented com-

putations in logic programming. In Tokoro, M.

and Pareschi, R., editors, Object-Oriented Program-

ming, volume 821 of LNCS, pages 194–212. Springer-

Verlag. 8th European Conference (ECOOP’94),

Bologna, Italy, 4–8 July 1994. Proceedings.

Ramamohanarao, K. and Harland, J. (1994). An introduc-

tion to deductive database languages and systems. The

VLDB Journal, 3(2):107–122.

Richardson, L. and Ruby, S. (2007). RESTful Web Services.

O’Reilly.

SC22, J. T. C. I. J. (2000). Information technology — Pro-

gramming languages — Prolog — Part 2: Modules.

International Standard ISO/IEC 13211-2.

Sterling, L. and Shapiro, E. (1986). The Art of Prolog. The

MIT Press.

Thomas, D., Heinemeier Hansson, D., Breedt, L., Clark,

M., Davidson, J. D., Gehtland, J., and Schwarz, A.

(2006). Agile Web Development with Rails. Pragmatic

Bookshelf.

WEBIST 2008 - International Conference on Web Information Systems and Technologies

164