Re: Definition of Navigational (was: The wisdom of the object mentors)

From: Neo <>
Date: 24 Jun 2006 17:02:16 -0700
Message-ID: <>

> > ... persons can be located in a building, on a floor of a building, in a room of a floor of building, etc.
> Do you mean in some cases we don't know the room number, but know the floor number?

In order to demonstrate flexibility, the example assumes the location of a thing can be specified by any container (universe, planet, city, building, floor, room, cabinet, drawer, etc). In some applications such as a robot in a factory, application specific constraints might limit choices to one of 3 similar bins. In other applications, the constraints might be less restrictive.

> Such can be modeled in a schema if it is really needed, but I've never encountered it in practice.

I guess it depends on the application's scope. Dbd is meant for AI-type applications where an andriod might be told Judge is in Courthouse1, Clark is on floor1 of Courthouse1, Cobly is in room1 of floor1 of Courthouse1, etc.

> It is not much use to anybody to store the fact that they are on Floor 4, but nobody knows where on the floor.

If the application is an android, this type of situation can arise and we don't want to bring it back to the lab to update its db's schema.

> If it is not known, then sometimes one is assigned to the receptionists desk (office) such that the receptionist can help out finding somebody.

Not known vs on floor4 can be quite different in an andriod application. In AI-type of applicaitons, specific data structures and constraints may not be known in advance.

> ...generally in biz we focus on logical modeling where the viewpoints or grouping need to change depending on need. For example, somebody's physical location and their function/job-title may be completely unrelated. Organizing by one makes it hard to sift/query by the other. I suppose one could traverse the whole tree to search for such, but you are essentially bypassing the structure more or less, not using it. You now require one approach to sift by one aspect (physical decomposition) and another different approach to find some kind of logical grouping or search. Why reinvent the wheel twice?

Frequently when persons unfamiliar with dbd see the tree view in its interface (it has a grid view also) they automatically assume the underlying data must be stored and limited to trees. Such isn't the case. Dbd can represent a thing in any number of "lists", "tables", "trees", "graphs", "networks", etc simultaneously without redundancy.

Frequently when persons unfamiliar with dbd see the tree view in its interface they automatically assume user must navigate node-by-node to find a specific set of thing. While this option is available (an especially easy for dummies), user can also find them via high-level queries, some that are higher in abstraction than SQL's (see examples below).

I have updated Courthouse/Judge Example so that persons are in multiple lists, tables and hierarchies as described below (I would be interested to see an equivalent representation/queries with an RMDB):

This example represents a subset of the following: There are 1 to many courthouses.
Each courthouse has 1 to many floors.
Each floor has 1 to many rooms.
Persons in the courthouse can have 1 to many classifications
(ie judge, clerk, coordinator, bailiff, court reporter, assistant,
Each person can have 1 to many names, phone numbers and emails. Each person can have 1 to many employees. Each person can have 1 to many bosses.
The location of a person can be specified by a building, floor, room, etc.

More specifically, the example represents the following persons:

Judge Judy (phone# 333-5555 / JDG-JUDY, email / who has following employees: clerk Clark, coordinator Colby, bailiff Brandy and court reporter Courtney each with various attributes. Assistant clerk Ashley is an employee of Clark and Colby.

Courthouse1 has two floors.It's first floor has room1. It's second floor has room1 and room2. Above persons are located in different parts of Courthouse1.

The first figure above displays Courthouse1's parts. The second figure displays attributes of various persons. The third figure displays nodes higher in hierarchies than Ashley.

Example queries. Note that expressions starting with "(;" are comments.

(; Find all persons)
(; Finds judy, clark, colby, brandy, courtney, ashley)
(select person instance *)

(; What does Courthouse1 have?)
(; Finds floor1, floor2, Courtney)
(select courthouse1 has *)

(; Find Ashley's bosses)
(; Finds Clark and Colby)
(select ashley boss *)

(; Find a judge's employee whose employee phone# is 737-5588)
(; Finds clerk Clark, coordinator Colby)
(and (select (select judge instance *) employee *)

     (select * employee (select * phone# 737-5588)))

(; Which person in Courthouse1's floor2's room2

   has an employee named Clark
   and an employee whose email is
(; Finds judge Judy)
(and (select (nodeElem (select (nodeElem (select courthouse1 has

                               has room2))
             has *)
     (select person instance *)
     (select * employee clark)
     (select * employee (select * email

For details, see Received on Sun Jun 25 2006 - 02:02:16 CEST

Original text of this message