1. Penelope Syntax by Examples.

Penelope is a declarative language that allows the generation of Web sites from relational databases. The structure of the target site pages can be defined by suitable statements that describe page-schemes. A set of page-schemes is a site-scheme. The reference data model for describing page-schemes is the Araneus Data Model (ADM).

1. The Araneus Data Model

The Araneus Data Model is a logical model for Web hypertexts. In ADM, each page is a URL-identified nested object. Pages are in fact described by attributes, which may be atomic, that is, text, images ot links to other pages, or complex, that is nested lists of tuples. The features of the model will be illustrated in more details in the following. For further details on the data model, consult the Araneus publication page at URL http://poincare.dia.uniroma3.it:8080/Araneus.

2. Scheme Definition.

The following Penelope statement defines a site-scheme:

Address is the target site address, that is, a URL of the form:

• http://HostName/HostDir for a site accessible through a HTTP server,
• file:/FileSystemDir for a site not directly accessible through a HTTP server, which is to be stored in the file system.

Style is a style file to be used by Telemaco (see the Telemaco user manual) to generate and customize the graphical layout of pages in the site.

Database specifies the name of the data source, usually an ODBC data source, containing the (relational) database in which data to be published are stored.

In the following, Penelope statements will be presented with the help of examples that refer to the following Department relational database scheme:

1. Page-Scheme Definition.

A site-scheme is defined by a bunch of Penelope statements, one for each page-scheme in the site. Each definition specifies, for a given page-scheme, in which way page attributes are to be mapped to database attributes. Consider the following Penelope statement:

It specifies how to generate a bunch of pages that are instances of the ADM page-scheme GraduateCorsePage, whose structure is reported in Figure 2. Data are taken from table Course in Figure 1.

CourseName	Description	Instructor	Type
Compilers	..........	Riccardo Torlone	undergraduate
DatabaseSystems	..........	Paolo Atzeni	graduate
OperatingSystems	Principles of operating...	Alessandro Micarelli	graduate
InformationSystems	...........	Paolo Atzeni	undergraduate

From Example 1, we can see how a Penelope statement has several clauses:

• the DEFINE PAGE clause,
• the STYLE clause,
• the AS clause,
• the USING clause,
• the ORDER BY clause,
• the WHERE clause.

These clauses will be discussed in the following paragraphs.

1. The DEFINE PAGE clause.

The DEFINE PAGE clause primarily specifies the name of the page-scheme the statement refers to. It is also used to specify the HTML title to be given to instances of the page-scheme, as it will be discussed in the following. The database tables from which data should be extracted are listed in the USING clause. The statement in Example 1 defines how to generate instances of a page-scheme called GraduateCoursePage based on tuples in the Course table in the database. Features of the USING clause will be discussed in more detail in the following.

2. The style clause

The style clause is an optional clause used to associate a presentation, i.e. a graphical layout, with instances of a given page scheme. This clause is ignored by Penelope. The process of specifying the HTML layout for pages is in fact taken care of by another software module, called Telemaco; (see the Telemaco User Manual). When generating pages, Penelope relies on "Attribute Style Files" (.ATS) generated by Telemaco. If .ATS files are not available, a default presentation style will be used for pages in the site.

3. The AS clause.

The AS clause specifies how page-scheme attributes are to be mapped to attributes of tables listed in the USING clause. In particular, this clause specifies:

• how to assign URLs to instances of the target page-scheme;
• how to generate attribute values for instances of the target page-scheme.

Let us discuss the second point first. As you can tell from Example 1 and Figure 2, for each attribute of the page-scheme there is an item in the AS clause. In fact, the CoursePage page-scheme has three TEXT attributes: Name, Description and Type. Attribute values for each page instance are values of the Course table (see Figure 1), as specified in the USING clause. Each page-scheme attribute is associated with a relation attribute, whose name is enclosed by a pair of acute brackets ("<" and ">"). For example, the clause specifies that values for the Name attribute in instances of CoursePage come from values of the CourseName attribute in the Course relational table.

1. The URL function.

URLs are assigned to pages using the URL() function. The URL() function creates distinct addresses based on a number of parameters. These parameters come from values of table attributes. The URL() function for the page-scheme of Example 1 is the following:

 

URL(<CourseName>)

 

The formal parameter is a key attribute of the Course table. The Penelope interpreter builds, for each tuple in the table, a page instance having a URL that is obtained from the CourseName attribute value. For example, the Database Systems course page URL will be:

site-path\CoursePage\DatabaseSystems.html

Note that a page address is generated by juxtaposing the site-path, the page-scheme name and the value obtained from the function parameter.

 

For unique pages, the URL() function can be given a constant value:

 

URL("index.html")

 

Here, an URL is generated directly from the parameter value. The URL() function may take more than one argument:

URL("index", <CourseName>)

 

Here, the URL() function builds an URL for each value of the <CourseName> attribute. A string is created from the combination of parameter values and is used for URL generation. In our example, the pairs of values are:

 

"index" "Compilers"

"index" "DatabaseSystems"

......................

"index" "Operating Systems"

 

A similar mechanism is used also to define in the DEFINE PAGE clause the special attribute title, corresponding to the HTML title of a page. Values for the title can either be constant strings or come from database attributes. For instance, in Example 1, instances of page-scheme CoursePage will have titles generated from the <CourseName> attribute of the database table. In other cases, pages might have constant titles, like the following:

DEFINE PAGE CoursePage: "Sample Site: Courses"

This option is particularly useful for titles of unique page-schemes, i.e., page-schemes having a single instance (like, for example, the Home Page).

2. The USING clause.

The USING clause specifies the relational tables from which data are extracted. These tables can be either base database tables, or views. In Example 1, the Course base table is specified. The statement in the following example generates the same set of pages, but uses a view called GradCourse as a data source for the page-scheme:

Example 2:

DEFINE PAGE GraduateCoursePage : <CourseName>

AS URL(<CourseName>);

Name : TEXT = <CourseName>;

Description : TEXT = <Description>;

Type : TEXT = <Type>;

USING GradCourse : ( Select Course.*

From Course

Where Type = "Graduate")

DISTINCT

END

Relational views may be defined by any SQL statement. The query in the USING clause of Example 2 generates a table, GradCourse, by selecting those tuples in Course referring to graduate courses. The view will be temporarily materialised in the database, and then removed after all instances of the page-scheme have been generated.

 

GroupName	Topic
Database and Information Systems	Databases and the Web
Database and Information Systems	Heterogeneous databases
Database and Information Systems	CASE technologies
Database and Information Systems	Active databases
Database and Information Systems	Database languages
Database and Information Systems	Medical computer science
Database and Information Systems	Requirement engineering
Artificial Intelligence	Logic for knowledge representation
Artificial Intelligence	Automated deduction
Artificial Intelligence	Modal and temporal logic
Artificial Intelligence	Abductive reasoning
Graph Drawings	Computer aided design
Graph Drawings	Geometric modelling & programming
Graph Drawings	Computer graphics
Symbolic Computation	Experimentation with algebraic methods

Figure 3 The "ResearchGroup" relational table

3. The DISTINCT Directive in the USING Clause.

In the page-scheme definition of Example 2, the DISTINCT directive is used. This directive can be associated to both base tables and views. It is used to specify that duplicates are to be removed when data are extracted from the database. The directive should be used with care. In fact, for some ODBC drivers (for example Microsoft Access), it is not possible to have duplicate elimination over tables with BLOB or MEMO attributes.

4. The ORDER BY Clause

The ORDER BY clause is used to specify which ordering strategy should be used when inserting data inside pages. For example:

Example 3:

DEFINE PAGE ResearchGroupListPage : "ResearchGroupListPage"

AS URL("researchGroupList.html");

GroupList : LIST-OF (

ToGroup : LINK-TO ResearchGroupPage(

URL (<GroupName>);

GName : TEXT = <GroupName>;

);

);

USING ResearchGroup DISTINCT

ORDER BY GroupName

END

According to the above statement, data are extracted from tuples in the ResearchGroup table and inserted inside a single page (it has a constant URL) containing a list of research-groups, with a link for each group to the corresponding page. Essentially, the statements nests data coming from table ResearchGroup inside the single instance of page-scheme ResearchGroupListPage. Suppose table ResearchGroup is the one in Figure 3. To avoid having duplicates in the list, we use the DISTINCT directive. Moreover, we specify that list items should be ordered based on values of attribute GroupName.

5. The WHERE clause.

The WHERE clause can be used to specify a conjunction of conditions to be used to filter data to be inserted in a page. It takes as an argument a boolean expression. The WHERE clause of Example 1 was in fact:

Here, the Penelope interpreter compares, for each tuple of the Course table, the value of the Type attribute and the constant string after the LIKE keyword and it selects only the tuples for which the condition is satisfied. It essentially allows to perform horizontal partitions on database data and to bring into Web pages only the set of tuples that satisfy a given condition.

1. TEXT attributes.

The association between a page-scheme attribute and a database attribute allows the Penelope interpreter to create page instances. Nevertheless, it is possible to associate constant values to TEXT attributes. For example, we may be interested in adding a constant attribute to the page-scheme of Example 1, in order to include in our page instances the string "Web Master: Paolo Rossi". We then have the following Penelope statement:

Example 4:

DEFINE PAGE CoursePage : <CourseName>

AS URL(<CourseName>);

Name : TEXT = <CourseName>;

Description : TEXT = <Description>;

Type : TEXT = <Type>;

WebMaster : TEXT = "WebMaster: Paolo Rossi";

USING Course

END

2. IMAGE Attributes.

Let us consider the following Penelope statement:

This statement specifies how to generate instances of the page-scheme in Figure 4 starting from values in the Professor relation of Figure 5.

In the page-scheme of Example 5 an IMAGE attribute is used. The syntax to define this type of attribute is similar to the one for TEXT attributes. The corresponding values are extracted from the Professor table of Figure 5. So, for example, the value of the Photo attribute in Prof. Micarelli’s page is ../icons/mic.jpg. The value of an IMAGE attribute must specify the name of a file storing the corresponding image. The file path may be defined in two different ways:

• it may be a relative path with respect to the path of the page instance;
• it may be an absolute path with respect to the site root.

In the previous example, the file name is mic.jpg while its relative path is ../icons.

1. LINK-TO Attributes.

Penelope allows to define LINK-TO attributes, in order to link site pages. A LINK-TO attribute is composed by an URL and an anchor. Let us consider the following Penelope statement:

It creates the instances of the CoursePage page-scheme, which is described by the ADM scheme of Figure 10. The corresponding values are extracted from the Course relation.

The definition of the ToInstructor attribute has several parts:

• it specifies the name of the target page-scheme, which the link points to (ProfessorPage, see Example 7);
• then, it specifies the URL of the target page; values for the URL are obtained also in this case using the URL() function. Note that there has to be a referential integrity constraint between the Course and Professor relations, on the Name and Instructor attributes. The URLs of the ToInstructor attribute will be so created from the same values from which the URLs of professor pages are created. For example, both the URL of prof. Atzeni page and the URLs of the ToInstructor attribute in the "Database Systems" and "Information Systems" pages are created from the same value ("Atzeni") and they will hence give rise to the same result (site-path/ProfessorPage/Atzeni.html). This simple URL generation mechanism, if correctly used, allows a powerful management of link consistency in complex sites.
• Finally, the definition of the link attribute specifies which anchor should be used for displaying the link. The anchor for a link is a list of TEXT or IMAGE attributes. In the above example the anchor is the InstructorName attribute.

1. External Links.

Penelope allows also the generation of links to pages that don’t belong to the site we are developing. Those links already exist and they have a known URL. An example of external link is in the following page-scheme:

The essential differences between internal and external links are:

• the name of the target page-scheme is arbitrary, in the example it is "ExternalPage";
• the URL() function parameter must correspond with the address of the target page (for example http://www.uniroma3.it/DiBattista/Publications); that value may be stored in the database or may be specified as a quoted string. The URL function is such that it recognises database values that are ready-made references to external pages, and do not modify them. Therefore, the URL returned by the function on the value above will be the value itself, that is: Errore. L'origine riferimento non è stata trovata.; a similar mechanism is used for email addresses (strings starting with prefix mailto:), references to files (strings starting with prefix ../ or /), or ftp addresses (strings starting with prefix ftp://).

LIST-OF attributes in pages may be arbitrarily nested lists of tuples. Let us consider the following Penelope statement:

It generates a Web page having the structure described by the ADM scheme of Figure 9. Values are taken from the Course relation (see Figure 1).

In the statement, we essentially specify that values of attribute Name in tuples coming from relation Course have to be nested inside attribute CourseList. A page definition may have several levels of nesting. For example, we might have a list attribute containing more list attributes, as follows:

In this case, we are defining a unique page containing the list of all research groups. For each item in the list, we also report the list of members, with a link to the corresponding pages (PersonPage). As it can be seen, attribute GroupList is nested. Penelope allows in fact to define arbitrarily nested attributes, with some subtleties:

• first, data at different levels of nesting may come from possibly distinct sources in the USING clause; with respect to example above, data come from two different tables in the database. The first one, ResearchGroup, has one tuple for each group. The second one is a view PersonGroup. Penelope uses a natural join semantics to correlate data at different levels; in the page defined above, the two tables ResearchGroup and PersonGroup will be joined based on common attributes (GroupName) before nesting data;
• second, to improve performances and use the SQL engine as much as possible, there is a constraint on nested attributes, namely that for each level of nesting, all non-nested attributes must come from a single table or view in the USING clause; in the example above, values for all non-nested (i.e., text, images or links) attributes in GroupList -- Name and Topics -- come from table ResearchGroup; similarly, in the nested attribute MemberList, values for all non-nested attributes -- ToMember and Member -- come from view PersonGroup. Note that, to be correctly joined with table ResearchGroup above, PersonGroup needs also to have an attribute GroupName.

1. Advanced Features

In the following paragraphs we briefly discuss some advanced features of Penelope. Another feature already available in the prototype -- namely forms -- will be described in a forthcoming version of this manual.

1. Links with OFFSET.

In order to describe how to define links with offset in Penelope, let us consider the following statements:

Example 9

DEFINE PAGE EducationPage : "EducationPage"

AS URL("education.html");

CourseList : LIST-OF (

Name : TEXT = <CourseName>, OFFSET(<CourseName>);

Description : TEXT = <Description>;

ToInstructor : LINK-TO ProfessorPage(

URL (<Instructor>);

InstructorName : TEXT = <Instructor>;

);

);

USING Course

END

 

Example 10:

DEFINE PAGE ProfessorPage : <Professor.Name>

AS URL(<Professor.Name>);

Name : TEXT = <Professor.Name>;

Email : TEXT = <email>;

Phone : TEXT = <Phone>;

Photo : IMAGE =<Photo>;

CourseList: LIST-OF(

ToCourse : LINK-TO EducationPage (

URL("Education.html" # <CourseName>);

Course : TEXT = <CourseName>;

);

);

USING Professor,

MyCourse: (SELECT CourseName, Instructor AS Name

FROM Course )

END

 

The ToCourse link has ProfessorPage as the target page-scheme, with an offset that is defined by the <CourseName> parameter, which is preceded by the terminal symbol ‘#’. In order for that addressing method to work, it is necessary to create a reference into each instance of EducationPage. The Name attribute declaration is then followed by the OFFSET function, which must be given as a parameter the same offset parameter that is passed to the URL() function of the ToCourse attribute.

2. The UNION Clause.

Consider the following Penelope statement:

It generates all instances of the page-scheme described in Figure 12, extracting data from the Course relational table of Figure 13. The CourseListPage page-scheme is unique: it has just one page instance. That page gives access to each course page by means of a list of links. In this example we use the UNION clause in the ToCourse link definition. The target page-scheme of that link may be UnderGraduateCoursePage or GraduateCoursePage. In order to use the UNION clause, the base relational table must have an attribute that allows to distinguish undergraduate course tuples from the graduate course tuples. The IF condition allows the Penelope interpreter to link an instance of the proper page-scheme. The first branch of the union is considered as a default, hence the corresponding condition may be omitted to modify the statement as follows:

ToCourse : LINK-TO

...

2. Penelope Semantics.

In this section the Penelope language semantics will be presented. In particular, we will show how each statement in the language maps to an expression in a nested relational algebra with URL invention. Operators of the algebra are briefly described in the following. Basic notions of the classic relational algebra are then requested in order to fully understand the Penelope algebra.

1. The Penelope algebra

The Penelope algebra is essentially a nested relational algebra extended with an URL invention operator, which allows an identifier manipulation mechanism to create complex hypertext structures. The operators of the algebra work on relations and return nested objects that represent Web pages, as follows:

• nest, n_{A -> B}, is an operator that groups together tuples which agree on all the attributes that are not in a given set of attributes, say B. It forms a single tuple, for every such group, which has a new attribute, say A, in place of B, whose value is the set of all the B values of the tuples being grouped together;
• generate URL, URL_{I -> K}, is an operator that takes as input a relation R(K,X). It adds a new attribute, I, to R; the values of I are identifiers. They can be page URLs or links to other pages. Each value is the result of the application of a Skolem function to the values of the attributes in K;
• other relational operators (selection, projection and join) are defined as usual.

1. Building a Web Page from a Relational Database

Let us take as an example the following ADM scheme describing undergraduate course pages:

Suppose also that in our example database we have the following relation, describing lessons:

The Penelope statement describing page instance generation is the following:

The first operation performed by the Penelope interpreter is the natural join of the tables specified in the USING clause:

Then, given the following table instances:

The relation resulting from the join operation is:

According to the Penelope statement, all the needed URL attributes are added to the relation. The URL values are generated by the URL function from the values of the CourseName and InstructorName attributes.

The resulting relation is the following:

After URLs generation, the proper selection operations are performed, in order to satisfy the conditions in the WHERE clause of the Penelope statement.

R₃ = s_{Type = ‘UG’}(R₂)

The resulting relation now contains only undergraduate course tuples.

Now we need to get rid of all the attributes that are not useful for page instance generation, i.e. those database attributes that are not associated to any page attribute in the page-scheme (the Type attribute in this case). This is done by means of an ordinary projection operation.

R₄ = p_{PageURL, InstrURL, CourseName, Description, InstructorName, Date}(R₃)

The resulting relation is:

Now, the relation is ready to be transformed in a set of nested tuples, each of which corresponds essentially to a site page. Nesting operations are performed starting from inner level lists, so, in this case, the first nesting is performed on the Date attribute.

R₅ = n_{LessonList<-Date}(R₄)

A new attribute (LessonsList) is created, whose values are lists of dates. Each nested list correspond to the lessons given by an instructor.

The final nesting is performed in order to create the InstructorList attribute:

R₆ = n_{InstructorList<-(InstructorName, ToInstructor, LessonList)}(R₅)

and each nested tuple of the resulting relation corresponds to a page instance: