Chapter 3
Semantic Modeling


3.1 Introduction

In Chapter 2, we talked about purely reactive worksheets - in which behavior is defined directly in terms of visible features and user gestures.

In this chapter, we look at semantic modeling - where behavior is defined in terms of relationships among objects in the application area of the worksheet (e.g. people, places, movies, and so forth). We look at how we can use operator definitions to update this semantic data, and we look at how we can use view definitions to define visible features in terms of semantic information.

3.2 Relating Syntax and Semantics

Consider a course scheduling worksheet that is laid out as follows. In this layout, the multi-valued selectors have identifiers course1, course2, course3, and course4, and they have options autumn, winter, spring, and summer.

Course 1 Course 2 Course 3 Course 4

If a user of this worksheet selects the options autumn and spring in course1, then the factoids holds(course1,autumn) and holds(course1,spring) are added to lambda. Semantically, this means that the user has selected course1 for both the autumn and spring quarters.

Now, consider the alternative layout of this course scheduling worksheet shown below, where the selectors have identifiers autumn, winter, spring, and summer and where they have options course1, course2, course3, and course4 (denoting the courses that may be taken in a quarter).

Autumn Winter Spring Summer

In this alternative layout, the user's course selections correspond to the facts holds(autumn,course1) and holds(spring,course1). Note that these facts are different from the ones stored in the previous worksheet i.e. holds(course1,autumn) and holds(course1,spring). However, at a conceptual level, nothing has changed! In both cases, the user has selected course1 for both the autumn and spring quarters.

The difference between the states of these two conceptually identical worksheets is due to the difference in their layout. One way to design a semantic model of a worksheet is to separate out what is stored in a worksheet's state from what is rendered, e.g. style, value, holds facts.

The first step is to write out operation definitions for the gestures involving the worksheet's widgets and have the effects correspond to semantically meaningful relations.

For example, in the first course scheduling worksheet, we would use the following operation definitions.

select(Course,Quarter) :: taken(Course,Quarter)
deselect(Course,Quarter) :: ~taken(Course,Quarter)

In the second course scheduling worksheet, which is conceptually identical to the first one, we use these operation definitions

select(Quarter,Course) :: taken(Course,Quarter)
deselect(Quarter,Course) :: ~taken(Course, Quarter)

The second step in creating a semantic worksheet is to define the layout of the worksheet as a view over the semantically meaningful relations.

For example, in the first course scheduling worksheet, define holds as a view over taken as follows.

holds(Course,Quarter) :- taken(Course,Quarter)

In the second course scheduling worksheet, define holds as a view over taken as follows.

holds(Quarter,Course) :- taken(Course,Quarter)

Now, suppose a user selects course1 in autumn and spring quarters. The facts stored in both worksheets would be identical.

taken(course1,autumn)
taken(course1,summer)

The upshot is that the rules on each sheet, in effect, constitute a stylesheet for displaying and updating that data. One important benefit of this is that the application data implicit in a worksheet can be exchanged with other worksheets that manage the data in different ways.

3.3 Semantic Relationships

In designing the semantic model of a worksheet, it may turn out be the case that some semantic relations can be described more simply as views of other semantic relations.

As an example of this, consider the small family tree described in the dataset shown below.

parent(alice, john)
parent(bob,john)
parent(martha,alice)
parent(dennis,alice)
parent(claire,bob)
parent(simon,bob)
 
grandparent(martha,john)
grandparent(dennis,john)
grandparent(claire,john)
grandparent(simon,john)

In this dataset, facts of the form parent(X,Y) denote that X is a parent of Y, and facts of the form grandparent(X,Z) denote that X is a grandparent of Z.

Instead of explicitly writing out grandparent facts, we could model a state of the family tree by defining the grandparent predicate as a view of the parent predicate as shown below. We say that X is a grandparent of Z if and only if X is a parent of Y and Y is a parent of Z.

grandparent(X,Z) :- parent(X,Y) & parent(Y,Z)

Defining the grandparent predicate as a view of the parent predicate has the following benefits. (1) We no longer have to add or remove grandparent facts when the family tree is updated; the grandparent facts are automatically computed in each state as a function of the parent facts. (2) The number of facts stored in a worksheet's state is smaller than in the previous model, and this difference increases as more parent facts are added.