Lorel Addendum

The paper on Lore's query language, Lorel, appeared in the first issue of the Journal of Digital Library. The postscript version can be found here (372k). In addition the Lorel language has undergone another transformation to handle the capabilities given in the XML specification. These changes are described in the paper From Semistructured Data to XML: Migrating the Lore Data Model and Query Language (196k).

This note is a complement. Some subtle aspects of the language are clarified. Some typos are corrected. Lorel has been implemented in the Lore system. (Please, visit the online demo available off of the main Lore web page.) Differences between Lorel as implemented in Lore and as described in the paper are explained in this note.

• Clarification of some aspects of Lorel
• What is really implemented
• Typos in the DILIB paper

1. Clarifications of some aspects of Lorel

• Treatment of simple paths
• The update language

1.1 Treatment of simple paths

The treatment of Lorel select-from-where expressions starts by creating a from clause if one was missing from the original query. Then path expressions are canonicalized into an OQL-like form.

When the from clause is missing, the system will generate one based on the contents of the select clause. If the select clause is a single simple path expression then this path expression becomes the from clause as well. For example the first query below is transformed into the second.

select A.B.C


select A.B.C
from   A.B.C

select A.B.C, A.B.D


select A.B.C, A.B.D
from   A.B

Repeated simple paths: every simple path or prefix of a simple path that occurs in the from clause and is not specified by a variable, is understood as a variable ranging over the set specified by that simple path. If this simple path occurs elsewhere (in the select, from, or where clause), it is replaced by that variable. For example: the first query below is translated automatically to the second one:

select A.C.E                      
from   A.B x, A.C, A.C.E, A.C.F y   
where  A.C.E = 5 and A.C.F = 10    


select u
from   A.B x, A.C t, t.E u, t.F y
where  u = 5 
       and exists y' in t.F : ( y' = 10 )

1.2 The update language

The keyword for constructing a new oem object is oem (or xml when dealing with XML data) and not new_oem. In specifying the value of a complex object, the keyword struct is no longer necessary. Last, the types, the labels and the keyword oem are optional. In the case of an omitted label, the system attempts to find the appropriate label. Otherwise, default is used as the label.

Examples:

oem(int,5)                            
5
oem(complex,(a:{oem(int,5)},b:{X,Y})) 
(a:5,b:{X,Y})
(a:5,b:X,b:Y)                                      

The first two and the last three are equivalent.

Subtlety: (5) is understood as oem(int,5) and not as oem(complex,oem(int,5)) and {5} as oem(complex,default:{oem(int,5)}).

A query can be used any place where a set is expected. The following two queries are equivalent.

U := select X       
     from F.A X     

U := oem(complex,A: select X   
                    from F.A X)

More generally, if a query is used without specifying the labels, the system will try to attach labels to all resulting objects and use these labels in the created complex object, e.g., the equivalent updates:

V := oem(complex, select X from F.# X)
V := select X from F.# X   

create an object with possibly many distinct labels. This is a case where it is simply not possible to specify the labels.

2. What is really implemented

• 2.1 Base types in Lore
• 2.2 Equality in Lore
• 2.3 Lorel features not yet supported

2.1 Base types in Lore

INTEGER
REAL
STRING
TEXT
POSTSCRIPT
GIF
JPEG
HTML
URL
AUDIO_URL
VIDEO_URL
IMAGE_URL
POSTSCRIPT_URL
PATH

2.2 Equality in Lore

Lore only uses one symbol for equality, namely "=". In a first approximation, it has the meaning of "==" and not of "=".

To be more precise, Lore "=" coincides with Lorel's "==" with the exception that on complex objects it corresponds to Lorel's "=".

The rational is that:

• most of the time users want to use "==" and not "="; and
• on complex objects "==" is usually not what's desired, while object equality is usually sufficient.

2.3 Lorel features not yet supported

Language features whose implementation is still underway include external predicates and functions, group by and order by clauses. In addition, general path expressions currently require that a regular expression operator be applied over a path of length one. This supports path expressions like: A.B(.C|.D)*.E but not A.B(.C.D.E)* . We have found that the subset that is implemented is used almost exclusively in practice.

3. Typos in the DILIB paper

• In Section 3.2: When comparing value or atomic object against set of objects:
  where exists Z in X : Z = "Chef Chu"
  should be:
  where exists Z in X.name : Z = "Chef Chu"
• In Section 4.3: The 4th query shown in the paper as:
  Select R From Guide.Restaurant R Where ...
  should be:
  Select R.name From Guide.Restaurant R Where ...
  The above is equivalent to:
  Select (select x from R.name x) From Guide.Restaurant R Where ...
  This last query is what the Lore implementation will actually execute.