Lore

  Although Haystack provides us with the interface to a variety of information retrieval systems, it is necessary to find a suitable database and hypertext system. We were lucky to discover a system that would provide us with a capability for both built-in. The Lightweight Object REpository (Lore) system from Stanford's database group [32] is a DBMS capable of querying and indexing semi-structured information. This ability satisfies our need to store objects that do not have a pre-defined schema. Lore is an extension to the Object Database Management Groups (ODMG) database standard. The language used to interact with Lore is known as Lorel (Lore language) [1] and extends the Object Query Language (OQL) language (which in turn extends the SQL standard).

  
Figure: A Sample OEM Graph

Lore data structures are based entirely Object Exchange Model (OEM) objects. These data structures can take on atomic values such as integer, real, string, etc. OEM objects can also be complex. Complex OEM objects contain named links to other OEM objects. Additionally, all OEM values carry a unique ID (OID). The structure formed by a Lore database can therefore be an arbitrarily complex graph structure.

We will return to the specifics of Lore when discussing its intergration into Haystack (see Chapter ). However, as some basic knowledge of Lore is required for the next chapter, some examples may help. Figure  is a sample graph of a Lore database. The text on the connections between OEM nodes indicate the named relationship between the parent (the higher node) to the child (the lower node). The number inside the nodes is the OID of the object. The atomic values for those OEM that have them are shown below the node in italics.

There are a number of important things to note about the graph structure we generated. The first, is the ability of OEM objects to hold any number of ``children'' of a given type. By not pre-defining a schema we can connect any number of named links to an object (Address for example). Additionally, it is the link which is named (i.e. is of a specific type) rather than the object it points at. This gives us the ability to connect to a number of objects with the same link name regardless of how the objects are represented. For example, one of the Address nodes for the ``Eytan'' object is a complex OEM object pointing at three other OEM objects: Street, City, and Zip. The other Address object is an atomic object with a string component. Finally, we note the ability to explitly name objects, and to set points to those objects.

  

  < HaystackPeople::HaystackPeople {
   < GroupMember {
    < Name ``Eytan'' >
    < AD1: Address ``NE43-309'' >
    < Address {
     < Street ``Freeman St.'' >
     < City ``Brookline'' >
     < Zip 02146 >
    } >
    < Supervisor &Lynn >
    < Supervisor &David >
  } >
   < GroupMember {
    < Name ``Mark'' >
    < Address &AD1 >
  } >
   < Lynn: GroupMember {
    < Name ``Lynn'' >
    < Phone 2663 >
  } >
   < David: GroupMember {
    < Name ``David'' >
    < PhoneNumber ``6167'' >
  } >
 } >
Figure: A textual representation of the OEM graph

Figure  is the corresponding textual OEM model that is used to generated the graph. An OEM ``object'' consists of a link name followed by some value, between the signs ;SPMlt; and ;SPMgt;. For example, we create the Name node by specifying: ;SPMlt;Name ``Eytan'';SPMgt;. To create a complex object, we place the ``children'' in braces: ;SPMlt;linkName {oemObject1, oemObject2, ...};SPMgt;. Finally, we can name objects by using placing a name followed by a colon in the OEM ``constructor.'' For example: ;SPMlt;AD1: Address ``NE43-309'';SPMgt; binds the name AD1 to the object pointed at by the Address link (i.e. NE43-309). To point at a named object we use the ampersand followed by the name of the object. For example, in the ``Mark'' object, we point the Address at AD1 by using: ;SPMlt;Address &AD1;SPMgt;. It is not necessary to use the same link name in pointing to the same object. We could have, for example, said: ;SPMlt;Office &AD1;SPMgt;. This would have created an Office link pointing at the NE43-309 object.

Now that an OEM representation has been created, it is possible to start asking Lore for information about this structure. The Lorel query syntax looks suprisingly like SQL.

SELECT a FROM b WHERE c₁ AND c₂ AND ....

The variable a is the view we want to take of the returned data (i.e. how much of the data we want to see). The data we query against is limited to the set b, and we impose additional constraints with the predicates c₁. For example we can issue the query:

 
select X.PhoneNumber from HaystackPeople.GroupMember X

		where X.Name = ``David''

This statement creates a set X of GroupMembers, we then sonstrain the set to those group members whose Name is David. Out of the result set, we select the object pointed at by the PhoneNumber link. In this case, we return ``6167.'' A slighly more complex example is:

 
select X.#.Phone% from HaystackPeople X

		where X.GroupMember.Name = ``David''

The two characters # and % are wildcard chracters. The # is a path wildcard charcater which will match any link name. In the above examples the # evaluates to: GroupMember (only a single path in this example). The Phone% means that we are looking for links starting with the string Phone. In this case, Phone and PhoneNumber both satisfy the requirement. However, the where clause limists us to the ``David'' GroupMember, and we again return ``6167.'' A complete specification of Lorel is available in [1].

The final aspect of Lore that requires some discussion is the concept of DataGuides [19]. Lore has the built in ability to take a snapshot of the current database and produce a new database representing the schema of the original. Such a tool is highly useful for visualizing the domain in which a user can query. A user can, for example, fill in differnt fields within the graph in order to perform a query against the database. This would allow a user to perform queries without necessarily understanding the structure of the database. A DataGuide for the graph before is represented in Figure .

  
Figure: A DataGuide Graph